Running Out of Tokens Halfway Through a Build: How to Make Your Context Last

Short focused conversations cut token use more than any other change. Start there before touching models, plans or settings. Start a new conversation per task. When a feature is done and committed, close the chat. The next task does not need the transcript of the last one. This is the single biggest saving available and it costs nothing. Name the files. "Edit components/JobList.tsx only" stops the agent opening six files to orient itself. Exploration is the most expensive thing an agent does when you already know where the code lives. Keep the codebase small. Delete the screens you are not using. Remove the example code the scaffold shipped with. Agents pay to read dead code exactly like live code. Ask for plans, not rewrites. "Tell me what is wrong with this function" costs a fraction of "rewrite this file". Diagnose in cheap turns, then spend on one targeted fix. Applied together, these usually stretch a session by several hours of working time. None of them require a different tool or a different plan. They are habits, and they are the same habits that make agents produce better code, because a focused agent with a small context makes fewer mistakes.

Treat the conversation as a workspace you tidy, not a log you accumulate. Everything in it is being paid for on every turn, so what stays should earn its place. Worth keeping in context: - The current task and its definition of done. - The one or two files you are actively changing. - The exact error text you are chasing. - Your project conventions, ideally in a file the agent reads rather than pasted repeatedly. Worth dropping: - Failed attempts. They cost tokens and actively degrade output, because the agent treats its own bad code as an example. - Files from the last task. - Long log output pasted in full. Paste the ten relevant lines. - Whole schemas or documents when a summary would do. When a conversation feels heavy, do a handover: ask the agent to write a short summary of where the work is up to and what remains, then start fresh with that summary. You keep the useful state and drop the freight. A project instructions file earns its keep here. Stack, conventions and standing rules live in one place the agent reads on demand, instead of being retyped into every conversation and re-sent on every turn.

Capture your state before you do anything else. A limit that lands mid-task is only a disaster if the context you built up disappears with it. The procedure: 1. Commit whatever works. Even half-finished, even ugly. Uncommitted work is the only thing you cannot get back. 2. Write a handover note. Three lines: what you were doing, what was working, what to try next. Save it in the repo. Future you will not remember. 3. Note the exact error. If you were chasing a bug, save the error text and the file it came from. 4. Switch to the work that does not need an agent. Test what you have built. Try to break it. Write down what you find. This is the highest-value use of a blocked hour, and most people skip it. On rate limits specifically, which is a different problem: the answer is usually batching and caching rather than more requests. The registrant hitting scraping rate limits wanted throughput without paying for residential proxies. The realistic answers are caching results so you never fetch the same page twice, backing off on failure rather than retrying immediately, and running the job over hours rather than minutes. Patience is cheaper than infrastructure.

Not every step needs your most capable model. Routing the easy work to a faster model is the difference between running out mid-afternoon and finishing the day. Work that rarely needs a frontier model: renaming things, writing boilerplate, formatting data, generating test fixtures, writing copy for a page, explaining what an error message means. Work that does: designing how the pieces fit together, debugging something you have already failed to fix twice, reasoning about auth and data access rules, anything where a wrong answer is expensive to discover later. The practical habit is to notice which category you are in before you send. Most builders run everything through the heaviest option out of caution, then run out of capacity during the part of the day that actually needed it. A second habit worth having: stop asking the agent to redo work you can do yourself in a minute. Changing a string, deleting a file, renaming a variable in one place. Round-tripping through an agent for a ten-second edit is the most common invisible drain on a session. buildAcademy covers this as part of the working method, because managing context and capacity is a real constraint on what you can ship in a session, not a footnote.

Does starting a new conversation lose all my progress? No. Your progress lives in your files and your commits, not in the chat. Write a three-line handover note and the new conversation picks up where you left off. Why does a small change use so many tokens? Because the agent re-reads context to make it. A one-line change in a file the agent must first open, plus a conversation carrying twenty earlier turns, is not a one-line cost. Is a bigger context window the answer? It raises the ceiling and does not fix the burn rate, and output quality generally drops as context fills with irrelevant material. Short focused sessions beat large stuffed ones on both cost and quality. How do I handle a codebase too big to fit in context? Work in one area at a time and tell the agent explicitly which files matter. Agents do not need the whole codebase to change one feature, they need the right slice of it. What should I do while I am rate-limited? Test what you built, write down every bug you find, and plan the next task in writing. You will move faster when access returns than you would have by prompting through the block.