Firstpass v0.2.1
GitHub
DocsGuaranteeBenchmarksCLIGitHub

Docs / How Agents Talk to Models / A Claude Code session

Part A · The core pathModule 7 of 13

A Claude Code session

A coding-agent session is every core-path module running at full tilt. At launch the harness assembles a base context — system prompt + your CLAUDE.md + every tool schema — and that base rides along as input on every request. One instruction (“add a test”) becomes a loop of many requests; subagents run their own transcripts and bills; and when the window fills the harness compacts older turns into a summary. It's the most expensive shape precisely because every earlier module compounds inside it.

When you run claude in a terminal, it feels like a conversation. Underneath it's the exact machinery of the core path, just more of it. Nothing here is Firstpass — this is how any capable coding agent spends. Walking one session end to end makes every earlier module concrete.

What's loaded before you type anything

The moment a session starts, the harness builds a base context it will send on every request for the rest of the session:

Add it up and the base context is often several thousand input tokens before your first word — and by multi-turn's rule, it is re-sent and re-read on every request in the session. That's exactly the stable prefix caching exists to cache, which is why a coding agent is the textbook case for prompt caching.

One instruction becomes many requests

You type one line — “add a null-check test for handle().” That is not one model call. It kicks off the the tool loop loop: the agent reads files, writes a test, runs it, reads the failure, fixes it — each step a separate request, each carrying the base context plus a transcript that grew since the last step. A single instruction routinely spends five, ten, twenty model calls before it reports back:

A sequence diagram showing one Claude Code instruction becoming a loop of many model requests. At session launch a base context is assembled once from the system prompt, CLAUDE.md, and tool schemas — several thousand tokens before your first word. You type one instruction. The agent sends request 1 (base context plus instruction, billed as input); the model replies with a tool_use block (billed as output); the agent runs the tool locally (no model call, unbilled); the tool returns its result. The agent then sends request 2, which resends the entire base context again plus the growing transcript and the tool result — billed as input, and already larger than request 1. After several more such round trips the model returns a final answer. Two callouts note that when the context window fills the harness compacts older turns, and that a spawned subagent runs its own separate base context, transcript, and bill, returning only a compact summary to this session. One instruction → many requests · base context re-sent in full every time session launch — base context assembled once system prompt · CLAUDE.md · tool schemas → several thousand tokens before your first word you · terminal model local tools you type: "add a null-check test for handle()" ① request 1 · base ctx + instruction $ input · base ctx billed ② tool_use · Read(orders.py) $ output ③ run Read locally ④ file contents returned ③ – ④ never touch the model · unbilled ⑤ request 2 · base ctx RESENT + transcript + result $ input · bigger than ① ⑥ Edit · pytest · … · final answer $ output · ×N more trips window fills → compaction older turns summarized to free room; loop continues · prompt-cache prefix invalidated spawned subagent its OWN base context + transcript + bill; returns just a compact summary to this session
One typed instruction, many billed requests — every request re-sends the whole base context (system prompt + CLAUDE.md + tools). Steps ③–④ run locally with no model call. The fatter arrow at ⑤ reflects the larger input after the transcript grows. This stacks multi-turn compounding on top of a fat fixed prefix — which is why caching matters most in a coding session.

Subagents spend on their own tab

When the agent delegates — “search the codebase for every caller of parse()” — it can spawn a subagent. That subagent gets its own base context and its own transcript, runs its own tool loop, and returns only a compact result to the main session. This is deliberate: it keeps the main thread's context lean (the subagent's twenty file-reads never pollute your window). But make no mistake — those tokens are billed. A session that spawns three subagents is running four independent Module-4 loops, four bills, that happen to roll up into one task.

When the window fills: compact — or clear

Every model has a context ceiling, and a long session eventually nears it. You have two ways to bring the input back down, and they are opposites.

Compact (automatic near the ceiling, or /compact) summarizes older turns into a digest and continues the same task — you keep the thread. Two costs follow:

Clear (/clear) does the opposite: it wipes the conversation entirely and starts fresh. The base context (system prompt, CLAUDE.md, tool schemas) reloads, but every turn of history is gone. No summary is made — it's the cheapest possible reset, and the right move when you switch to an unrelated task rather than continue the current one.

/compact/clear
Keeps the thread?Yes — summarizedNo — wiped
Costs a model call?Yes (the summary)No
Input right afterbase + summary + new turnsbase + your next turn only
Reach for it whensame task, running longmoving to a new task
Key idea — both reset the meter, differently Multi-turn cost climbs because the transcript only grows. Compact caps it by swapping old turns for a shorter summary — you keep the thread, pay one summarization call, and lose the old prompt cache. Clear zeroes it by dropping the thread outright — cheapest, but you start from scratch. So: long sessions cost less than linear growth suggests, but they aren't free at the seams — and a well-timed /clear before an unrelated task is the cheapest context you'll ever send.

So what does a session cost?

Put the pieces together for a realistic half-hour of pair-programming — a handful of instructions, each fanning into a tool loop, over a fat base context:

~5k
base-context input tokens re-sent every request (illustrative)
50–200
model calls across a busy 30-min session
≈90%
of input is the repeated prefix — the caching target
tier
the one lever that scales the whole thing up or down
Key idea A coding-agent session is where all seven earlier modules land at once: a fat fixed prefix (M1/M4/M5), re-read every request (M3), across a high call count (M4), on whatever tier you picked (M2), with caching as the main relief valve (M6). The single biggest knob is still which tier answers each call — and in a session of 50–200 calls, the vast majority are easy (read a file, apply a small edit) while a few are hard (design the fix). Paying the strong tier on all of them is the reflex Part B targets.
Under the hood This is why “my Claude Code bill is higher than my chatbot bill” is expected, not a bug. A chatbot turn is one call over a short prompt. A coding-agent instruction is dozens of calls, each over a multi-thousand-token base context plus a growing transcript. The per-token price is identical; the token count is one to two orders of magnitude larger. Everything Firstpass does in Part B is aimed at the tier those tokens are billed at.
A Claude Code session runs the core path at scale: a fat base context re-sent every request, one instruction fanning into many calls, subagents billing separately, and compaction capping the growth — the most expensive shape, and the one with the most to gain from cheaper tiers.

The seven modules above are the main road — the path our one task actually walked. These five are the turns a real agent takes off it: streaming responses, machine-readable output, images, MCP servers, and the failures that happen when you make hundreds of calls. Each is a dedicated module; take them in any order.