Analysis · 2026-08-22 · 8 min read

Y Combinator's Garry Tan on AI Token Burn: "Burn, Baby, Burn"

YC CEO Garry Tan tells founders to max out token budgets — "load a million tokens in" and you get to live in 2028. Uber and Cognition disagree. Here's the actual math on when burning tokens pays and when it just burns runway.

TL;DR

Y Combinator CEO Garry Tan told founders worried about AI spend to "burn, baby, burn" on the a16z podcast — tune agents all the way up, "load a million tokens or 800,000 tokens in," and you "get to live in 2028."
The counter-camp is loud: Uber's tech chief Praveen Neppalli Naga says the next phase "will not be characterised by who spends the most tokens, but about how people use them as efficiently as possible." Cognition CEO Scott Wu warns teams have "gotten carried away," even ranking engineers by tokens spent.
Both are right, for different companies. Token burn is R&D when it buys discovery, and waste when it repeats a solved task.
Tan's own second step is the part everyone skips: let the agent burn to solve it once, then convert the winning run into reusable instructions.
At $2–$36 per million output tokens, a 1M-token context agent turn costs between $2 and $12 just to read the prompt. Do the math before you tune it all the way up.

!OpenAI

!Anthropic

!xAI

!Moonshot Kimi logo

1. What Tan Actually Said

Speaking on a16z's podcast, Tan pushed back on founders rationing agent budgets. His argument isn't "money doesn't matter" — it's that capability you can buy today with brute-force context is capability everyone else gets for free in two years. Paying for it now is a time-machine trade:

> "You have to tune it all the way up. You're just, like, let me load a million tokens or 800,000 tokens in. When you do that, I think that you basically get to live in 2028."

Then the qualifier that got much less airtime: Tan recommends first letting agents use whatever resources they need to finish the task, then converting successful processes into reusable instructions. That's not unlimited burn. That's exploration followed by compression — expensive discovery, cheap repetition.

Source: Times of India coverage of the a16z podcast.

2. The Other Camp

Silicon Valley is split on tokenmaxxing — deliberately letting agents consume enormous context instead of optimizing usage down.

Wu's jab lands hardest because it's a measurement critique, not a spending one. Tokens consumed is an input metric. We wrote about why that breaks the moment it hits a performance review in Token Counts Make Terrible Performance Reviews.

3. The Actual Cost of "Load a Million Tokens In"

Tan's advice has a price tag that changes by 6x depending on which model you point it at. One agent turn with a 1M-token context, before a single output token:

Cache-hit column assumes a stable prefix and published cache-read discounts; verify current rates in the live pricing table.

Now multiply by a real agent loop. A 40-turn session that re-sends a growing context is not one $2 call — it's 40 of them, and the last twenty are the expensive ones. That's the token explosion problem in one sentence.

A single engineer running "tuned all the way up" agents eight hours a day can post a five-figure monthly bill. Tan is fine with that when the alternative is shipping six months later. Your CFO is fine with it only if you can show what the burn bought.

4. When Burning Tokens Is Actually Correct

Burn is justified when the token spend is buying information you don't have:

Novel problems with no known-good procedure. First migration, first integration, first time an agent touches a legacy service.
Whole-repo reasoning where retrieval keeps missing the relevant file and a 1M-token window just sees everything.
Search-style tasks where 20 parallel attempts at $0.50 each beat one engineer-day at $600.
Time-to-market races where two weeks earlier is worth more than $8,000 of inference.

The honest framing: this is R&D spend, not COGS. It should show up on a discovery budget with a hypothesis attached, and it should stop when the hypothesis resolves.

5. When It's Just Burning Runway

Repeating a solved task at full context. If the same workflow ran successfully yesterday, running it "tuned all the way up" today is paying discovery prices for a known answer.
No caching. Re-sending an identical 800K prefix at full rate is the single most common six-figure mistake we see. Fix it with a stable prefix and prompt caching before you touch anything else.
Frontier models on classification. Extraction, routing, tagging, and summarization never needed the top tier. A flash model at $0.06/$0.18 does it at ~1% of the cost.
Per-seat spend with no output metric. If you can't tie the burn to shipped work, you're funding a habit. That's exactly the enterprise token apocalypse pattern.

6. The Synthesis: Burn Then Compress

Tan's two-step is the practical policy, and it maps cleanly onto a routing stack:

1. Discovery lane — burn allowed. Frontier model, full context, parallel attempts. Time-boxed and budget-capped per project, not per person.

2. Capture the win. When a run succeeds, extract the prompt, tool sequence, and context set into a reusable spec. This is the step Tan names and most teams skip.

3. Production lane — compressed. Replay that spec on a cheaper model with a trimmed context and a cached prefix. Typically 80–95% cheaper than the discovery run that produced it.

4. Escalation only on failure. A quality gate kicks the hard 5% back up to the frontier tier. Coinbase cut its AI bill in half running exactly this shape.

Concretely: discovery at $6/M input, production at $0.18/M output on a flash tier, with escalation for the tail. You keep Tan's upside and Uber's unit economics.

7. What to Measure Instead of Tokens

Wu's warning about ranking engineers by token spend deserves a replacement metric. Track:

Cost per completed task (not cost per engineer, not tokens per engineer).
Discovery ratio — share of spend in the exploration lane. Healthy teams see this fall over time as wins get compressed.
Cache hit rate — anything under 60% on a repeated workflow is unclaimed money.
Escalation rate — how often the cheap lane fails the quality gate. Rising means your compression was too aggressive.

Model the numbers for your own traffic in the cost calculator or the Agent Loop Cost Estimator, and compare model rates side by side on the LLM Leaderboard.

Bottom Line

"Burn, baby, burn" is good advice for a seed-stage founder racing to find out whether something works, and bad advice for a platform team running the same pipeline ten thousand times a day. The disagreement between Tan, Uber, and Cognition isn't really a disagreement — it's two different lanes of the same stack. Burn to discover, compress to operate, and measure output rather than tokens. Do that and you get Tan's 2028 without Uber's bill.