A Practical Guide to Reducing Token Spend · Adam Jacob Skip to content<br>Embedding complex workflows and logic into AI Agents through skills alone is a dramatically inefficient way to work. By using a swamp workflow instead of the skill alone, I dropped the token usage 8x, and decreased the run time by 2x for a complex code review workload. For a lot of use cases, it’s the single best thing you can do to reduce your token spend.

What Happened

My (friend? acquaintance? long time social media conversationalist? Hi David!) David Cramer of Sentry fame wrote a post titled “We Cant Afford Your Inference”. In it, he details how he spent north of $10,000 on tokens in a week, across multiple models and workloads. His conclusion was essentially: new models are too expensive to use broadly at Sentry:

For Sentry I’m not really sure how we’re going to approach this. We estimated an average spend of $1,000/week/developer, not $1,000/day. Fable is truly an impressive model, but it simply is not affordable to use when you pay for tokens. Sol is more approachable, but there appear to be enough footguns that we’re amplifiying costs to an unsustainable degree (albeit GPT 5.5 was not that much better).

I think the (near-term) future is faster and more affordable models, that bring this year’s Opus-level intelligence to the masses. I dont need models to be coordinators when I can build that myself. I need the raw outputs to be better, I need them to sustainably fit in budgets, and I need them to be as fast as (and faster than) Composer.

He attributed a significant part of the spend to how the models ran his Garfield skill - which, in my words, not David’s, is basically an adaptive code review framework designed to ensure coding policy was adhered to after an agent edits source code.

Here is how David’s skill executed when I triggered it in Codex with a representative problem:

The Garfield skill used ~4.5 million tokens, ran for ~12 minutes, and used 23 total sub-agents. It used a coordinator agent to dispatch a rolling series of sub-agents to review the code according to the policy/standards in the repository. Each review cycle dispatched sub-agents to review the work, and passed their verdict back to the coordinator to adjudicate the findings. Then it ran one final verification pass to ensure the resulting code also passed things like tests, formatting, and lint.

What’s great about Garfield as designed is that it uses the LLMs own intelligence to evaluate the code, then re-evaluate its own work, and ultimately to judge if it has achieved the outcome it wanted. It also will inspect the repository you use it in, discovering specific policy for that individual code base. This would have been essentially impossible to build even two years ago. It’s miraculous in many ways.

It also uses a ton of tokens and wall-clock time, because it’s asking a non-deterministic adjudicator to evaluate the results of other non-deterministic processes in order to perform all the work. It’s the most expensive loop possible, basically, because it puts the LLM in the hot path, when in fact it doesn’t need to be. My metaphor for this design is that it’s using 100% of the possible intelligence to solve every part of the problem, even those that computers have been great at doing reliably since they were invented.

I was pretty sure I could dramatically alter the economics by translating his skill into a swamp extension, keeping all the existing functionality intact. Here is what it looked like to get identical functionality, only with swamp:

The Garfield swamp workflow used ~500 thousand tokens, ran for ~6.5 minutes, and used 3 agents total. That’s ~8x fewer tokens overall, and it cut the runtime in half. It built a swamp extension that turned the coordination workflow described in the skill into a single swamp model type. The swamp model handles the work of the coordinating agent as deterministic code, farming out work to agents when we need their intelligence, and evaluating their work deterministically. It stores the results of each sub-agent as versioned, typed data - giving complete visibility into every step, and enabling sub-agents to see the past history of their own work (avoiding costly re-work cycles.) It also has a few optimizations that I couldn’t resist - for example, it adds a risk review phase that slides the scale of how intense the review should be. But the vast majority of the savings was simply in removing the tax of the coordinator.

How to do it yourself

Step 0: Install swamp and initialize your swamp repo

To install swamp:

curl -fsSL https://swamp-club.com/install.sh | sh<br>Then I recommend going to the source code checkout where you have your current agent/skills implemented, and initializing it as a swamp repo:

$ swamp repo init --tool codex<br>The --tool option specifies which harnesses you are using - it helps the initialization process customize things like skills for particular harnesses.

Tip<br>Make sure you create an...