Scroll any AI dev feed and you’ll see a trend emerging. Monthly spends on AI agents, posted with a shrug emoji. “I burned 40M tokens this week. Let’s goooo!”
I’m not going to tell you that’s wrong. Sometimes it is worth it. But nobody brags about their compile times with that caption, and token spend is the same kind of number: a process. We started treating it as an output because it correlates loosely with effort, and effort feels like progress.
One question to ask yourself (and your team) should be, how much of your last 40M tokens produced code that’s still being used? Not code that got written. Code that survived. If you and your agent built a data layer, rewrote it, rewrote it again when feature three exposed a bad assumption, and shipped version four, you paid for four and kept one. That’s a 75% waste rate, and on your usage graph it looks exactly like productivity.
How can we become more efficient at leveraging AI to write code? Read on.
Where the spend actually goes.
Agentic cost doesn’t scale with code produced. Much of it scales with how much your agent has to re-derive before it can write a single line of code.
Your agent is a brilliant, tireless intern who reads the entire codebase every conversation and retains none of it for the next conversation. Every session it crawls models.py, then the serializers, then the viewsets, and rebuilds the relationships from scratch. You pay for that reconstruction. Then it goes home and forgets, and tomorrow you buy the same conclusions at full price.
Which means the biggest lever isn’t your model, your prompt style, or your context tricks. It’s whether the thing you’re building has a stable, machine-readable data contract. Without one, every session opens with archaeology.
| Tokens | API cost | Supervised hours | |
|---|---|---|---|
| Schema-as-you-go | 15–40M | $30–150 | 60–120 |
| Against an existing contract | 5–12M | $10–40 | 15–35 |
Costs assume Sonnet with prompt caching. Error bars are wide; take ±50%.
Note the dollar delta is about a hundred bucks, which is the real answer to the bragging question. If you’re flexing on spend, you’re flexing on a hundred dollars. What you actually spent was 60 hours, and nobody screenshots that, because no tool shows it to you and it doesn’t feel like it’s leaving while it’s leaving.
Here’s what those 60 hours look like.
Same task, two agents
The task: a manufacturer discontinued a part. Show me every site affected and what replacing it costs.
Agent A starts from a blank repo.
Turn 1. "I'll create a comprehensive data model." Produces Asset, Site, Project. Reasonable. ~180k tokens.
Turn 4. You mention some sites are built to a standard spec. It adds a Prototype model. Doesn't version it. Nobody notices. ~700k.
Turn 9. You mention there's a design intent set and an as-built set. It adds a stage field to Project. This is wrong. It will stay wrong for two weeks. ~1.4M.
Turn 15. Your dashboard reports 147 displays installed. You own 49. Agent adds DISTINCT. Now it says 32. Somewhere, procurement is thrilled. ~2.6M.
Turn 22. Agent independently invents the Snapshot model. This is genuinely correct! The migration touches every serializer, every test, every fixture. You now have Asset, AssetItem, AssetInstance, and AssetInstanceRecord, and only one of them is used. ~4.1M.
Turn 31. You revise the standard from 6 displays to 9. Every existing site turns red. You explain versioning. It begins again. ~6M+.
Agent B opens a repo that already has a contract.
Turn 1. "Read AGENTS.md and openapi.yaml. Do not read the app source. Summarize the domain model, then stop." It comes back knowing that projects hold multiple snapshots, that standards are versioned, and that drift is measured against the version a site declared. ~30k tokens.
Turn 2. "Which endpoint answers exposure to a discontinued part?" It finds GET /api/assets/{id}/summary/, returns installed count, affected sites, replacement vendor, unit cost, and estimated total in one call — and flags that the response includes totals.basis, because the endpoint counts the newest snapshot per project and says so. The triple-count bug that cost Agent A eleven turns doesn't exist here. It was closed in the schema. ~12k.
Turn 3. "Build the React page." ~90k.
Done. ~140k total.
Figures are illustrative, modelled on how these sessions typically go rather than measured from a single run. The shape is the claim: spend jumps in steps at schema discoveries, and reading a contract collapses the whole curve. Want your own numbers? Claude Code logs per-turn token counts to ~/.claude/projects/*.jsonl, and /cost gives you session totals.
Agent B isn’t smarter. Both wrote fine code. However, Agent A spent six million tokens discovering a data model that already existed, and paid full retail for every wrong turn along the way.
Example: Deploying and building on Ephany rather than starting from scratch.
The framework in question is Ephany — Django/DRF, for tracking a standard kit of parts across a portfolio of sites. Data centres, retail chains, coworking floors. Anywhere the same catalog lands in many places and someone eventually has to answer what is actually where. It commits openapi.yaml to the repo root, so an agent reads the entire contract without running the server or opening a single .py file. That file is the compression.
Two caveats, because you’d want them. It’s AGPL-3.0, so network use triggers source disclosure — that matters far more than tokens if you’re building something closed. And if your domain doesn’t map onto assets, projects, and versioned snapshots, extending someone else’s schema costs more than greenfield. You’ll spend real money watching an agent argue with a model you disagree with, which is a genuinely humbling way to hit a rate limit.
Being Agent B
git clone https://github.com/TripleZeroLabs/Ephany-Framework.git cd Ephany-Framework && pip install -r requirements.txt python manage.py migrate && python manage.py seed_demo claude
This repo includes the script seed_demo which loads 15 sites and ~4,000 asset instances with deliberate inconsistencies baked in, so your agent reasons against messy data instead of an empty database that agrees with everything.
1. Orient before building. The most expensive turn is the one where you let it wander.
Read
AGENTS.mdandopenapi.yamlat the repo root. Do not read the app source. Summarize the domain model in ten bullets, then list every endpoint you’d need for a dashboard showing installed quantity per site. Then stop.
2. Build against the spec, not the source.
Build a React page that calls
GET /api/assets/{id}/summary/and renders the sites table. Use only the response shape inopenapi.yaml. Do not read the Django source. If a field you need isn’t in the spec, stop and tell me instead of guessing.
That last sentence is the whole trick. It converts a silent hallucination into a cheap question.
3. Make schema changes explicit and reviewable.
I need a
warranty_expiresdate on the asset instance. Make the model change, the migration, and the serializer field, then regenerate the spec withpython manage.py spectacular --file openapi.yaml --validate --fail-on-warn. Show me the diff toopenapi.yamlbefore you touch anything else.
One diff to review instead of five files and a vibe.
4. Copy a working integration instead of inventing one.
Read
examples/smartsheet_sync/. I have a nightly CSV drop instead of Smartsheet. Follow the same STEP structure: declare the mapping, fetch, diff, write only what changed. Keep all CSV-specific code in one module.
5. Put the rules in CLAUDE.md so you stop paying to repeat yourself.
## Rules - The data contract is openapi.yaml. Read it, not the ORM. - Never change a serializer without regenerating openapi.yaml in the same commit. - If a task requires a schema change, stop and ask before writing code. - Prefer one API call over three. Check for an existing aggregate endpoint first.
No framework, starting cold? Same discipline, and it’s free:
Before any implementation: design the data model for [your domain], write it as an OpenAPI 3 spec, and stop. No code. I want to review the contract first.
So is high spend bad?
No. Sometimes it’s exactly right. Exploratory work, real research, throwaway prototypes where letting the agent flail is genuinely the fastest path — burn away. High spend on a hard problem is fine.
The narrower question is whether you can tell which kind of spend you’re doing, because the graph looks identical either way. Six million tokens reinventing Snapshot renders exactly like six million tokens solving something new.
Maybe the flex isn’t the number going up. Maybe it’s being able to say what it bought.
More About Ephany
Want to try out the Ephany Framework yourself? The codebase is open-source and available on GitHub: https://github.com/TripleZeroLabs/Ephany-Framework
Leave a Reply