Measured: Claude Code Built Games Nine Times — Which Token Tips Actually Save Money

A Rigorous Token Consumption Experiment: Nine Builds, Three Strategies

A developer ran a fascinating real-world test with Claude Code: having the AI build three games — Breakout, Snake, and Space Invaders — three times each, for nine builds total. Each build used the exact same five prompts, hit the real API, and had every cent logged by a proxy.

The three build strategies were:

• Build A: The most typical approach — one long session, no CLAUDE.md, MCP servers installed, screenshots to convey designs, switching to the Opus model midway
• Build B: Following all ten popular token-saving tips — a brief-response instruction in CLAUDE.md, clearing between every step, no MCP, text descriptions for design, Opus in a fresh session, testing delegated to subagents
• Build C: Only three changes on top of Build A — add the brief-response instruction, filter noisy output, open a new session when switching models

The results were surprising: all nine games ran, all matched their designs, and all tests passed — but the cheapest build was never the one following all the tips.

The Bill for Three Games: Switching Models Is the Biggest Cost

Breakout: 42 cents vs 73 cents

Build A produced a playable game with levels and sound effects after just the third prompt. Then it ran /model Opus — and that step alone cost 39 cents. The reason: Opus can't read Sonnet's cache, so it rewrote the entire conversation, billing nearly 28,000 tokens at Opus prices. What fewer people mention: when switching back to Sonnet to run tests, the conversation had grown longer, and Sonnet rewrote everything again.

Build B's clearing between every step sounds thrifty, but each clear made Claude Code re-write the project context and re-read the game code, making steps 2 and 3 more expensive than Build A.

Build C kept a single session and only opened a new one when switching to Opus. The final bills for the three Breakout builds were 73, 59, and 42 cents.

Snake: One Bug Exposed the Side Effects of clear

The same pattern reappeared: Build A's mid-session switch to Opus cost 44 cents, and switching back to Sonnet cost another 14 cents; Build B's repeated clears made the middle steps more expensive.

Build B's Snake also had a real flaw — the snake starts moving the moment the page opens, so the player can lose before even pressing a key. Build C's Snake waits for an arrow key. The bills: 71, 51, and 39 cents — Build C was again the cheapest.

The wall rendering in the third level also diverged: A and C drew long strips, while B scattered them into individual blocks. The same prompt, three interpretations.

Space Invaders: The Gap Narrows

This was the largest of the three games. Build A used 10 requests and 16 cents on the very first prompt, and another 43 cents switching to Opus.

This time Build C won by little — its Opus step used 10 requests, the most requests of any polish step in the entire test, nearly eating up the whole gap. The bills: 84, 50, and 49 cents — B and C nearly tied.

Build A's Invaders also included things nobody asked for: a title screen and a mute key, with a 16KB file nearly twice the size of B and C.

Prompt Caching is the key mechanism for understanding these bills. The Claude API allows marking a conversation prefix (system prompt, message history) as cacheable; when subsequent requests hit the cache, those tokens are billed at roughly 1/10 to 1/20 of the original price rather than full price. But the cache is bound to the model: a cache written by Sonnet can't be read by Opus, and vice versa. So the article's "the entire conversation was rewritten" after /model Opus is the direct consequence of a cache miss — nearly 28,000 tokens all re-billed at Opus input prices. The cache also has a TTL (time to live), and Claude Code requests a 1-hour cache, which explains why "it still read from cache after being away for six minutes." Understanding this makes clear why "open a new session when switching models" works: a new session loses context, but it avoids rewriting all the history with the more expensive model.

Verifying Ten Tips One by One: Only Three Hold Up

The developer also used the same logging proxy to test ten popular recommendations one by one on small-scale real sessions.

Debunked or Outdated Tips

"The 10th message costs 11x the 1st" — Across 10 short questions, the 1st cost 2.4 cents and the 10th cost less than half a cent. Most of the content came back from cache, priced at only one-twentieth of the original. This one doesn't hold.

"The cache expires after 5 minutes" — Claude Code requests a 1-hour cache on every request. After being away for six minutes, the next question still read 18,000 tokens from cache. At least in the API key scenario, this doesn't hold.

"Changing effort breaks the cache" — After running /effort high, the next question still read 19,000 tokens from cache. Doesn't hold — but it does store high as the default for all future sessions.

"Disable unused MCP servers" — Claude Code now lists tools by name and loads them on demand. Playwright adds only 700 tokens per request. This tip is outdated.

"Subagents save tokens on small searches" — A subagent carries its own instructions and tools, costing 2.4x more than doing it directly. On small tasks it backfires.

"Screenshots are expensive" or "screenshots save tokens" — The same page presented as text, a screenshot, and a PDF took roughly 500, 1,100, and 1,400 tokens respectively. Neither claim is accurate.

MCP (Model Context Protocol) is an open protocol introduced by Anthropic that lets Claude connect to external tools (such as Playwright browser automation, databases, file systems, etc.) through standardized servers. In early implementations, the tool definitions of all MCP servers were injected into the context of every request at once, so the more servers, the greater the fixed overhead — which is why "disable unused MCP" was once good advice. But Claude Code now lists tools by name and loads full definitions on demand, so Playwright adds only about 700 tokens per request. This is a classic case of "engineering optimization making old tips obsolete": the tip itself wasn't wrong, the tool simply solved the problem it targeted. Similarly, a subagent carries its own system instructions and toolset, so on small search tasks its fixed cost exceeds doing it directly — hence the 2.4x overhead measured in the article.

Tips That Actually Work

"Open a new session when switching models" — The only conclusion repeatedly confirmed across all nine builds. A single Opus question in a small session cost 18 cents, 20 to 60 times a normal question.

"Tell Claude to answer briefly" — A one-line instruction halves output tokens and cuts the bill by about one-sixth. In the games it also made the code shorter: Build A's Breakout file was about 11KB, while B and C were about 8KB. Saying less also means writing less code.

"Filter verbose tool output" — Sonnet often adds pipe filters itself, and Claude Code already caps oversized output, but manual filtering still saves a round trip.

On clear — On short tasks, continuing the conversation costs 1.5 cents, clear costs 3 cents, and compact costs 4.5 cents. clear only pays off when the old conversation is both large and complete; on small tasks it backfires.

Practical Advice: Just Do Three Things

Three builds plus ten single-point tests point to the same conclusion: most popular tips are either outdated or over-generalized. Only three things are truly worth doing:

1. Open a new session when switching models — the single biggest cost driver, and the one that held across every game
2. Add a one-line brief-response instruction to CLAUDE.md — it saves money and makes the code leaner at the same time
3. Filter noisy command output — still delivers real gains

As for whether text descriptions can replace screenshots, the test gives a clear yes: text descriptions worked just as well as screenshots.

One trade-off to watch: the brief-response instruction makes Claude write less code. That costs nothing for small games, but as projects grow you'll need to check whether something got lost.

(This article is based on a real-world test publicly released by a YouTube creator; all figures come from their logging proxy records.)

Background Notes

clear, compact, and continuing the conversation are the three ways Claude Code manages context, each with a different cost structure. Continuing the conversation carries all the history, but the history can hit the cache, so incremental billing is low; clear wipes the session, so the next request must re-write the project context and re-read files — effectively rebuilding the cache; compact has the model compress the history into a summary, which itself consumes a generation request and then adds the subsequent rebuild cost on top. That's why the bills for the three on short tasks are 1.5, 3, and 4.5 cents. The criterion isn't "how big is the context" but "is the old context still useful": for a large conversation that's complete and no longer referenced, clear avoids carrying redundant history on every request; for a small task still in progress, clear instead creates rebuild overhead. This is precisely the root cause of why Build B's clearing between every step was more expensive.