The 70–90% token saving your chat window won’t let you have

Mara Ellison
Mara Ellison August 13, 2026 · 5 min read
Left: a chat column where each of ten small questions drags its own huge context block. Right: one document with ten anchored comment pins sharing a single context block.

A checklist has been making the rounds on X — half a million views via @DeRonin_ — opening with a line attributed to Andrej Karpathy: “90% of AI coding cost is unnecessary.” What follows is ten ways senior engineers stop paying for tokens that do nothing: prune the fifty files that auto-load for a thirty-line change, stop sending a frontier model to fix lint, stop re-sending the whole repo on every retry. Nine of the ten are configuration or discipline. Tip #9 is different — and it's the one your tooling has quietly decided for you.

The tip, paraphrased: if you're asking ten small questions one at a time, batching them into a single run cuts the cost by 70–90%. Simple. Nobody does it. It's worth understanding both halves of that sentence.

A “small question” costs the whole conversation

A language model is stateless per call. Every time your agent takes a turn, the entire working context goes back in the front door: the system prompt, the instructions, the plan, the files it loaded, the history so far. Your question may be fifteen words; the bill is the fifteen words plus everything underneath them. On a working session with a real document and a few source files in play, that floor is tens of thousands of tokens — per turn, before the model says a single useful thing.

Now ask ten small questions, one per turn. You pay that floor ten times — and it isn't even a flat floor, because each turn's history contains the previous nine exchanges. Prompt caching softens the repeat reads when nothing upstream changed, but any edit, any tool call, any reordering breaks the prefix — and the meter starts over. Ask the same ten questions in one turn and you pay the floor once. That's not a micro-optimization; that's the 70–90% the thread is talking about, and it's the same arithmetic behind its other tips — the “just in case” files (#6) and the full-repo retries (#3) are all ways of re-paying context that didn't need re-paying.

Rough numbers. Ten questions, ~60k tokens of live context:

one at a time   ≈ 10 × 60k = 600k tokens in
batched         ≈ 1 × 60k + ten answers ≈ 65k

≈89% saved on the question-and-answer phase — squarely inside the thread's 70–90% claim, from structure alone.

Everyone nods. Nobody batches. The interface decides.

If the fix is this mechanical, why does anyone ask one at a time? Because a chat window is a single scroll. Your ten questions are not about one thing — they're about ten different places: the datastore choice in section 2, the retry policy in section 4, the naming in section 7. Put all ten in one message and you get a wall of text whose answers come back interleaved, half-addressed, misattached to the wrong section. Ask them one at a time and each exchange stays clean — at ten times the price. The chat interface offers you exactly that trade, and readability wins every time.

Discipline loses to the interface every time. If batching costs readability, nobody batches.

So the real question behind tip #9 isn't “why don't engineers batch?” It's: what would an interface look like where ten parallel questions stay readable? That interface already exists, and you've used it — on every document you've ever reviewed with a colleague.

Anchor the questions. Batch the turn.

Comments. Anchored to the exact span they're about, each with its own thread, resolved independently. That's how inplan structures the whole conversation between you and your coding agent. The agent drafts the plan and parks every open question as an inline comment on the span it concerns — with choices attached where the answer is a pick — in one turn. You answer them in the editor: any order, your pace, each answer sitting at the line it's about. Then you hit Finish turn once, and the agent receives all ten answers in one context load.

Ten conversations. Two context payments. Nothing interleaves, because the document — not the scroll — is the thread structure: each question lives where its subject lives. And it runs both directions — your ten questions about the agent's draft go the same way, as anchored comments the agent answers in a single wake. The turn-based cadence isn't just a collaboration nicety; it is tip #9, made structural. You don't remember to batch. The workflow batches.

Routing, not skill

The thread closes with a line worth keeping: a year from now, the gap between the developer spending $200 a month and the one spending $4,000 won't be skill — it'll be routing. Which model gets which job, and how many times you pay for the same context. Most of the ten tips are routing decisions you have to keep making, every session, forever. The interesting ones are the ones you can make once — by choosing a workflow where the cheap path is the default path. Batching your questions is exactly that kind of decision, and it comes with a bonus the checklist doesn't mention: an agent that gets all ten answers at once builds against a resolved plan instead of a drip-feed of partial clarifications.

The cheapest token is the context you didn't resend

Karpathy's number lands because everyone has felt it: the meter runs hottest on ceremony, not on thinking. Tip #9 is the rare item on the list where the fix isn't vigilance — it's picking a conversation shape where questions congregate naturally. Anchor the questions to the document. Answer them in a batch. Pay for the context once.

Ten questions, one turn

inplan is where you and your coding agent resolve a plan through anchored comments — the agent raises all its questions in one turn, you answer them all in one pass, and nobody pays for the same context ten times. Free and open source.

inplan on GitHub inplan.ai
← All posts inplan.ai GitHub