How I Optimized Token Usage in My Coding Projects

For my first months working with AI on my coding projects, I treated it almost like a friend with superpowers. I'd open a chat and write in it for hours — questions, code, corrections, new ideas, all in the same conversation. At first the answers were solid. But over time, in that same conversation, the model would start to hallucinate, mixing contexts that had nothing to do with each other anymore, and by the end of the day I'd burned through a good chunk of my token quota without noticing exactly when it got away from me.

That pattern repeated so many times that it stopped feeling like bad luck and started feeling like a design problem — mine, not the model's. So I took matters into my own hands, and with the changes I'll walk through here I cut token consumption in my projects by 70%. But the real value wasn't the savings themselves: it was no longer losing time correcting hallucinations, and being able to focus purely on the business logic — which is the work I actually care about doing.

The first change, and the most important one, was putting an end to infinite chats. Every development project has information that should always be present — the base architecture, the stack, the team's standards — and information that only applies to one specific part of the business. Mixing the two into a mile-long history is exactly what ends up confusing the model. The fix was to split that knowledge into `.md` files: one global file with the base rules, and a separate one for each business domain. At its core, it's applying Domain-Driven Design principles to prompting — dividing the context instead of dragging the whole thing into every conversation.

With the context already split, I stopped using a traditional chat. Instead, I spin up agents that start from a blank slate, acting as specialists, and instead of copying code or context into them by hand, I give them skills — tools they use themselves to go find and read only the `.md` file for the domain they're working in. The agent pulls the information on demand, solves the task with surgical precision, and the savings in input tokens are massive compared to dragging the whole project into every message.

The third change was accepting that not every task needs the smartest — or most expensive — model. For mechanical tasks, like typing data or making simple changes, I use a lightweight model. For complex debugging, I assign the heavier one. Distributing the load based on what each task actually demands turned out to be one of the changes with the most direct impact on the budget.

The rest are smaller adjustments, but they add up: configuring the AI to answer concretely, without padding; writing instructions in English and in a direct tone, without unnecessary courtesies, because tokenizers spend fewer tokens per word in English than in Spanish; leaning on a skill that turns documentation into a navigation graph so the agent finds what it needs without over-reading; taking advantage of prompt caching by keeping the start of my prompts stable; and, above all, asking for only the relevant piece of code — one function, one specific error — instead of pasting entire files.