What is Tokenmaxxing?

Our development team has hired some new colleagues recently. They’ve helped us ship code faster than ever, though none of them appear directly on the payroll. Of course, I’m talking about AI agents. We use them to write code, scope new features, review our work and bounce ideas around. These days, I rarely go more than a few hours without typing a prompt.

I’d happily put them to work all day, freeing my own brain for the more important parts of the job (like responding to support tickets 😩). But agents are hungry, and their favourite food is tokens. This post is about tokenmaxxing: what it is, and how it’s possible to get useful work from agents without sending costs through the roof. I’ll share what I’ve tested, what has worked, and how to keep the resulting code clean and maintainable.

Quick definitions

Before we go any further, here’s a list of definitions for some of the technical terms referenced throughout the article.

• Token: A small unit of data that an AI model processes, such as a word, part of a word, or punctuation.

• Agent: An AI system that can independently perform tasks and take multiple steps towards a given goal.

• Usage: A measure of how much of an AI service you consume, often based on the number of tokens processed.

What even is “Tokenmaxxing”?

Tokenmaxxing is shorthand for using AI agents to accomplish as much of your work as possible; more simply, maximising your use of tokens.

In practice, carelessly throwing every task at the most powerful AI model available is unlikely to be a sensible use of money. The real opportunity is to make extensive use of AI while still getting a worthwhile return on that usage.

We've established that tokens are essentially the chunks of text an AI model processes. An agent might read files, search a codebase, run tests, revise its work and try again, with each step potentially triggering another model call. Context, reasoning, retries and subagents can all add to the cost, and even cached input may still carry a charge. OpenAI's agent usage guide explains the breakdown in more detail.

We can cite the GPT-6 Astra API rates (retrieved September 2026) to demonstrate how quickly unchecked usage can add up:

• One coding task using one million input tokens and 100,000 output tokens would cost about $15.

• Five developers each running five similarly sized tasks a day, over 20 working days, would spend $7,500 a month, or $90,000 a year.

Caching, model choice, tools and subscription terms can drastically change the real cost, so this is an illustration rather than a typical bill.

For a small or medium-sized business, sufficiently heavy and inefficient usage could begin to compete with the cost of hiring another developer. Used well, an agent can help a developer investigate, implement and test more work while they remain responsible for its quality.

Therefore, the goal we want to achieve is to maximise the amount of valuable work AI can take on, whilst ensuring costs remain realistic.

So, how do we do it?

Our developers have AI credits through our JetBrains organisation, giving us access to agents in our IDEs and a budget to work within. At first, usage was uneven: some of us burned through credits on broad requests, while others barely used them. A JetBrains article on spec-driven development gave us a more deliberate way to work. We adapted its example prompt to suit our team, and we now begin our coding session by writing a specification.

We give an agent a high-level feature request alongside our `spec-driven-development-prompt.md` file which is attached as context. Before proposing a solution, it inspects the existing code and conventions, then challenges the request. What happens when a user lacks permission? What if a step fails halfway through? Which edge cases have we missed? When an answer would materially change the feature, the agent asks us instead of quietly choosing for us. More often than not, this discussion reveals a use case we had not considered.

A feature request and our prompt in Junie. We start at Phase 0 and work through the specification one stage at a time.

Together, we turn that discussion into three linked documents:

1. Requirements (`requirements.md`) describes the behaviour we want.

2. Plan (`plan.md`) explains how it fits the existing system.

3. Tasks (`tasks.md`) breaks the work into ordered, verifiable steps.

We review the documents before implementation, then work through the tasks in small stages, checking the code and tests as we go. That gives both the developer and the agent a shared record of what has been decided and what remains to be done.

We usually choose a more expensive frontier model for this planning stage. It is worth spending more tokens to uncover a missing requirement or a risky assumption before either becomes code. Once the work is clearly scoped, we can choose an appropriate model (at this stage, usually a far cheaper one) for each task and avoid paying for repeated attempts to solve the wrong problem.

The benefits

Clarity before coding. Requirements give us a shared definition of what the feature should do, while the plan lets both the developer and the agent question the scope and approach. It is much cheaper to remove an unnecessary step here than to spend tokens building it and then ask the agent to undo it.

More deliberate spending. A powerful model is most valuable when the problem is still ambiguous. Once the requirements and approach are clear, cheaper models can handle focused implementation tasks without repeatedly spending expensive tokens to re-engineer a solution.

Useful history. The documents outlive the conversation. A developer returning to the feature later can see what was intended, why a particular approach was chosen and how the work was divided, without having to reconstruct those decisions from the code alone.

The drawbacks

More to maintain. Three planning documents can feel like a lot of files for a small change. If we let the process grow beyond the problem, the agent can over-engineer a simple task and leave us with more code to maintain. The specification needs to stay proportional to the work.

Review takes time. We still need to check the documents, read the code and verify that the result meets the requirements. If we change direction halfway through, the plan and task list need updating too. That time is well spent on complex features, but it can outweigh the benefit for a quick, well-understood fix.

Conclusion

Just because we can, doesn't mean we should throw as many tokens as possible at every problem. The aim is to put agents to work wherever they can provide value, while being deliberate about how those tokens are spent. We spend more on the thinking that prevents costly mistakes, then give the agent focused tasks and review what it produces. When the work is small, we keep the process light.

The developer still decides what matters and takes responsibility for the code that ships. Done well, this approach lets a small team make better use of its time and AI budget, accomplish more without immediately adding headcount, and leave behind software that others can maintain.

That's when an agent earns its tokens.