Fewer Tokens, Better Outcomes: How to Run Agents Well on a Small Budget
When people start using AI agents to build software, the first money question is almost always "which model is cheapest?" That is the wrong question. A cheap model that gets the job wrong three times costs more than a strong model that gets it right once - and it costs you an afternoon on top.
I run a portfolio of apps that agents build, test, and ship every day. Over the last year I learned that efficiency has very little to do with picking the smallest model. It comes from what the agent has to read, what it has to figure out from scratch, and what you hand it ready-made. This post is the set of habits I wish someone had given me on day one, written so a newcomer can copy them on a $20 plan.
Efficiency is tokens per good outcome
A token is a chunk of text, roughly three quarters of a word. Everything the agent reads and writes is counted in tokens, and tokens are what your plan or your bill measures. So it is tempting to treat every token as a cost to cut.
The number that matters is different: how many tokens did it take to get one thing done, correctly, that you did not have to redo? I call that tokens per good outcome. Measured that way, the cheapest path is usually a capable model with a small, clean context and a clear job - not a weak model with a messy one.
Context is the real budget
An agent's context is everything it holds in mind for one session: your instructions, the files it opened, every command it ran, and every answer it gave. Here is the part nobody tells you: on every new message, the agent re-reads the whole session so far. A long session is not one big cost. It is a cost that grows on every single turn.
When I measured a month of my own usage in Anatomy of a Token Bill, 96% of the tokens were the agent re-reading context it had already seen. Caching makes those re-reads cheap, but cheap times a huge number is still the biggest line on the bill. The habits that help:
- One task, one session. When a task is done and shipped, close the session and start the next one fresh. Yesterday's file dumps should not ride along into today's bug fix.
- Set a ceiling. My rule is that a session past about 500 tool calls is re-reading a mountain on every message. A small hook prints a warning at 400 calls. The chart below shows how often my sessions still crossed it.
- Never read the giant files. Lockfiles, generated code, and full reports go into context and never leave. Read a slice, or run a script and read its summary table.
- Memory lives in the repo, not the chat. Decisions, the product doc, and the backlog are files. A fresh session reads them in seconds. A chat that "remembers" is just an expensive, fragile copy of those files.
- Keep the always-on part tiny. My global instruction file is short: the stack, the writing rules, the non-negotiables, and pointers to everything else. Detail loads only when the task needs it.
Skills: stop paying to re-learn the same job
Every time an agent starts a familiar job cold - "how do we deploy here?", "how is a market report laid out?" - it spends tokens searching, reading, and guessing. Then it does it again next week. A skill fixes that. It is a short instruction file for one kind of task: the steps, the gotchas, the house style, and the scripts to run.
The clever part is how skills load. The agent always sees a one-line description of each skill, which costs almost nothing. The full instructions load only when a task matches. So you can have dozens of skills on hand and pay for the one you use.
A few of mine, to make it concrete:
- project-briefing answers "where do we stand?" from the project's docs and backlog instead of scanning the code.
- market-research runs a competitor review and always ends in the same branded PDF, so no session invents its own format.
- todo-spec writes a short spec before any real change, so the build session starts with a clear target.
Tools: let a script do what does not need a brain
A lot of agent work is not thinking. It is counting, fetching, formatting, and checking. A model can do that, but a twenty-line script does it faster, the same way every time, and for zero tokens.
My monthly usage review is a good example. It reads a month of session logs, checks seven rules, and files a todo for anything that trips. It is a script, not a session: no model call, no tokens. When I want an agent's opinion on the results, it reads the one-page summary, not the raw logs.
| Job | Agent does it by hand | Agent runs a tool |
|---|---|---|
| Check a deploy | Opens pages, reads HTML, guesses | Runs a smoke test, reads pass or fail |
| Count usage | Reads thousands of log lines | Reads one summary table |
| Update the backlog | Builds API calls from scratch | Calls one command with an ID |
| Create a database | Looks up flags each time | Runs one script that has a test |
The pattern: the agent decides, the tool executes, and the tool's output is short. A good tool is shaped so its answer fits in a few lines of context.
Helper agents: keep the mess out of the main room
Some jobs need a lot of reading, like "find every place we send email." If your main session does that, all those files sit in its context for the rest of the day. Instead, hand the search to a helper agent (a subagent). It reads in its own separate context and hands back the answer in a paragraph. Your main session keeps the conclusion, not the dump.
Helpers are not free, though. Each one starts from zero and only knows what you tell it. Use one for a wide search or truly parallel work. For a single file you already know the name of, just open it yourself.
Pick the model for the job, not for the price tag
Smaller models are great at small, clear jobs: fix a typo, bump a version, rename a thing, tidy formatting. My process even marks these "mechanical" and lets them skip the spec step, because the paperwork would cost more than the change.
Anything that needs judgment - designing a feature, tracking down a bug, deciding what to cut - goes to a strong model. A weak model on a judgment call does not save money. It produces confident wrong work that you pay to read, pay to undo, and pay to redo.
The trick is that the earlier sections make strong models cheaper. A strong model with a short context, a skill to follow, and tools to call spends far fewer tokens than the same model wandering around a messy session. That is how you afford the good model on a small plan.
A starter path for a new person on a small budget
If you are new to agentic development and on a basic plan, do these in order. Each one pays for the next.
- Write a short instruction file for your project. What it is, how to run it, and three rules you care about. Keep it under a page.
- Keep notes in files. A product doc and a decisions file. When you start a new session, point the agent at them instead of re-explaining.
- One task per session. Finish, commit, close. Start fresh for the next thing.
- Watch your context. Most tools show how full the context is. When it gets heavy, wrap up and restart rather than push on.
- Turn your second repeat into a skill. Deploy steps and release checklists are perfect first skills.
- Turn your third repeat into a script. If the agent keeps running the same five commands, make them one command.
- Use the strong model for thinking. Drop to a small one only for jobs you could describe in one line.
Here is a first message that sets a new session up well:
Spend tokens on thinking, not on re-reading
The small-budget mistake is to buy a weaker brain. The small-budget win is to give a strong brain less junk to read, fewer things to rediscover, and simple tools for the boring parts. Do that, and the same $20 plan ships more real work than a bigger plan used carelessly.