Everyone optimizes the wrong variable.
Cheaper models.
Shorter prompts.
Compressed context.
That all helps a little.
But look at Anthropic's rate card instead, and one asymmetry jumps out: output tokens cost 5x input tokens on every current model. Claude Fable 5 is $10 per million tokens in, and $50 per million tokens out.
Which means the most expensive thing your AI agent does is write code as output.
Magic is architected so it doesn't.
And rather than argue this in the abstract, we let Claude build a complete full-stack app on our hyperlambda.dev cloudlet — while measuring everything.
The rate card, straight from Anthropic
These are Anthropic's official API prices, per million tokens, fetched from their pricing documentation on August 6, 2026:
| Model | Input | Output |
|---|---|---|
| Claude Fable 5 | $10 | $50 |
| Claude Opus 5 / 4.8 | $5 | $25 |
| Claude Sonnet 5 (intro, through Aug 31) | $2 | $10 |
| Claude Sonnet 4.6 / Sonnet 5 (from Sep 1) | $3 | $15 |
| Claude Haiku 4.5 | $1 | $5 |
Two things are worth staring at.
First, the output multiple is universal. Every tier charges 5x more for what the model writes than for what it reads.
Second, Anthropic's newer tokenizer — used by Claude 4.7 and later — produces roughly 30% more tokens for the same text. Round-tripping source code through a model's context literally got more expensive this year.
Prompt caching and the Batch API can discount those rates. But a discount on waste is still waste. The interesting question is why the tokens are being spent at all.
Where a coding agent's tokens actually go
A conventional coding agent building a backend runs a loop.
Read files. That is input.
Write code. That is output, at 5x.
Read the error. Input again.
Rewrite. Output again.
Re-read to verify. Input again.
Every debug iteration compounds, and the compounding happens at the most expensive rate on the card. The model is not reasoning in most of those moments. It is acting as a very costly transport layer for source code.
I have written before about how Hyperlambda changes these economics and measured roughly 80 percent savings on a Fable-priced build. This article is about the mechanism underneath those numbers — and a fresh build with its own receipts.
What we built to prove it
We asked Claude to build Token Ledger: an LLM spend tracker.
Yes, that is deliberately meta. Claude built a token-cost dashboard while its own token cost was being metered.
The deliverable: a SQLite database with three linked tables — providers, models, and a usage log — seeded with Anthropic's actual rate card from the table above. Fifteen HTTP endpoints, every one of them role-secured. Two aggregation endpoints feeding charts. And a designed, dark, authenticated dashboard.
Look at the dashboard's own numbers for a moment. The second KPI card reads "output share of spend: 37%" — on a realistic mixed workload, over a third of the bill is output tokens. And the spend-by-model chart shows Fable 5 dwarfing everything else, because at $50 per million output tokens, it does.
The app is arguing the article's thesis from inside the screenshot.
The build ledger
Wall-clock time was measured with timestamps, not estimated.
| What | Number |
|---|---|
| Live secured backend — database, schema, seed data, 15 endpoints | 222 seconds |
| Complete working app, including the hand-written frontend | 431 seconds |
| Backend lines of code generated | 669 |
| Backend lines of code hand-written | 0 |
| Claude output tokens spent on backend code | 0 |
The last row is the entire article.
The backend was produced by twelve calls to Magic's CRUD generator and three calls to its SQL endpoint generator. Each call is a compact declarative argument — a table name, a column list, a role restriction, an SQL statement. Around a hundred tokens each, roughly 1,500 tokens of arguments in total.
Not one of the 669 generated lines passed through Claude's output stream at $50 per million tokens. The platform wrote them, server-side, using the same battle-tested generators the Magic dashboard uses.
Honest scope on the numbers: the 222 seconds include reading the platform's guides and setting up the design tokens. Screenshots and end-to-end verification came after the 431-second mark and included two pauses waiting for human tool approval, so they are excluded from the build figures.
That login screen is not decoration. Every endpoint behind it is gated by Magic's built-in RBAC — no hand-rolled JWT handling anywhere, because there is no hand-written backend anywhere.
The five mechanisms
Why does this architecture starve the token meter? Five reasons, each visible in the build above.
1. Declarative calls replace emitted code
One CRUD-generator call is roughly a hundred output tokens of arguments. It produces a complete endpoint — paging, sorting, filtering, validation, auth — of sixty to a hundred and twenty lines. Streaming the equivalent as source code is thousands of output tokens, usually across multiple attempts. In this build, 1,500 tokens of arguments bought 669 lines of backend.
2. Code generation happens server-side
When something bespoke is needed, Magic's Hyperlambda Generator takes a plain-English prompt and writes the file on the server. The code never enters Claude's output stream or its input stream. Claude pays for a sentence, not a source file. And here is the stronger version of that point: this particular build needed zero generator calls. The declarative tools covered the entire backend.
3. Code never round-trips through context
Magic's operating rules forbid the agent from reading generated Hyperlambda back. Verification goes through live HTTP invocation and the OpenAPI spec. A conventional coding agent re-reads its files constantly — every read is input tokens, every edit is output tokens. On Magic, that loop is not discouraged. It is structurally impossible.
4. No debug spirals
The generators are deterministic. There is no generate, error, paste-the-stacktrace, regenerate cycle — the invisible multiplier on every agent bill. This build's complete bug ledger: one entry, a headless-browser viewport quirk while taking screenshots. Zero bugs in 669 generated backend lines.
5. One-call grounding
At session start, one call returns who the agent is, what backend it is on, and its full operating instructions. One more call returns the exact list of capabilities that exist on the instance. Compare that with an agent grepping directories and reading files to discover what a codebase can do — all of it billed as input, none of it producing anything.
The accounting: same app, two architectures
Take the same deliverable — the Token Ledger backend, fifteen secured endpoints — and price both paths at Anthropic's current rates.
The Magic column is this build. The coding-agent column is a calibrated estimate for the same result via a conventional file-editing agent — scaffold, routes, auth, validation, and the customary debug loops — consistent with the roughly 140,000-versus-25,000-token gap measured in the July benchmark, with the backend-code share broken out.
| Claude on Magic (measured shape) | Claude with generic tooling (estimate) | |
|---|---|---|
| Output tokens spent on backend code | 0 | ~30,000 |
| Total output tokens, backend slice | ~2,000 | ~35,000 |
| Total input tokens, backend slice | ~30,000 | ~180,000 |
| Cost at Fable 5 ($10 / $50) | ≈ $0.40 | ≈ $3.55 |
| Cost at Opus 5 ($5 / $25) | ≈ $0.20 | ≈ $1.78 |
| Cost at Sonnet 4.6 ($3 / $15) | ≈ $0.12 | ≈ $1.07 |
Call it roughly 9x on this app, and the estimate columns are labeled as exactly that — estimates. The ratio is not a constant of nature. It is a consequence of one design decision: source code, the most expensive thing a model can emit, never enters the token stream.
And notice what happens as the app grows. A CRUD-generator argument is about a hundred tokens whether the table has three columns or thirty. Hand-written code is not. The gap widens with size.
Where 10x holds — and where it is 5x
Now the honest fine print.
The July benchmark measured roughly 80 percent — 5x — across a full session, because a real session also contains reasoning, planning, schema decisions, and verification, and those do not compress. The frontend in this build was hand-written by the agent, at normal output rates, and took as long as the entire backend.
The 10x figure belongs to the code-emission slice of the work: the backend, the endpoints, the auth, the data layer. On backend-heavy agentic workloads that slice dominates, and the blended number climbs toward it. On reasoning-heavy work, expect the 5x, not the 10x.
Both numbers are worth having. Neither requires exaggeration.
Conclusion
The standard advice for cutting Claude costs is to pick a smaller model, cache your prompts, and batch your jobs. All fine. All discounts on the same architecture.
Magic changes the architecture. The agent stops being a code emitter paying $50 per million tokens for the privilege, and becomes an operator of a platform that already knows how to build backends — declaratively, server-side, with security enforced by the runtime instead of regenerated per project.
We measured it: a live, role-secured, fifteen-endpoint backend in 222 seconds, 669 lines generated, zero lines through the token meter.
Claude is a great engineer. Stop paying it by the line.
Magic is MIT-licensed and open source — the repository is at github.com/polterguy/magic, with documentation at docs.ainiro.io.
Originally published at hyperlambda.dev.
Top comments (0)