Taken from WeatherBug and The Weather Network. The page snapshots carried no timestamp and disagree a little, which is why the rain figure is a range. For a forecast you can trust, use weather.gov (NWS Mobile/Pensacola).

Who computed what, in order

Each step, with its inputs and outputs

1. Harness · no model

   0 · Build the prompt

   reads

   Claude Code's system prompt and tool definitions, your three CLAUDE.md files, the memory index, the summary of our earlier conversation, file-change notices, and your question.

   does

   Joins them into one long text and turns it into tokens.

   why it's cheap

   Almost all of it matches the previous turn, so its KV state likely comes from the prefix cache. It's the same mechanism projects/15 used to time pure decode.

2. Opus 5.5 · round 1

   1 · Decide a tool is needed

   prefill

   One forward pass over the new, uncached tokens. Most of the time to first token is spent here.

   decode

   One token at a time: a short reasoning trace, then a tool call. WebSearch was deferred: I knew its name but not its definition, so I had to fetch that first.

   emits

   ToolSearch("select:WebSearch")

   stops

   Generation ends at the tool call. The harness runs ToolSearch locally and returns the definition. No model runs here.

3. Opus 5.5 · round 2

   2 · Write the search

   prefill

   Only the appended tool definition. Everything before it is cached.

   decode

   The date comes from the context the harness supplies (2026-10-09). The model has no clock of its own.

   emits

   WebSearch(query="Destin FL weather today October 9 2026", mode="standard")

4. Search backend+ unseen model

   3 · Search and summarize, server side

   search

   Claude Code's documentation says WebSearch "returns result titles and URLs. It doesn't fetch the result pages." Nine links came back. Five were low-quality SEO pages on one domain. The others were WeatherBug and two Weather Network pages (city and airport).

   summary

   Yet the result reached me with prose attached: a digest saying the snapshots were undated and contradicted each other, and an instruction to cite sources. The docs don't describe that step. I didn't write it, so something on the server side did, most likely a model; I can't see which one, its size, or its prompt. This is an observation from this session, not documented behaviour.

   lesson

   The facts went through two models before you saw them: summarized once by that model, then again by me. Neither one checked a weather API.

5. Opus 5.5 · round 3

   4 · Write the answer

   prefill

   The search result.

   decode

   The reply you read. It kept the rain chance as a range, flagged that the pages were undated, and pointed to weather.gov, all because the sources disagreed.

   emits

   Text, streamed to your terminal token by token.

The bill of compute

The small models around the big one

A chat product is rarely one model. Around the large model that writes the answer sit smaller ones doing quick, narrow jobs: naming the conversation, digesting a web page, summarising a session so it can be resumed, deciding whether a request is safe. "Small" means fewer parameters, which means fewer bytes to read for every token. That makes them faster and cheaper, and for a narrow job the extra reasoning a large model brings goes unused.

What Claude Code documents, and what it doesn't

Quotes from code.claude.com (environment variables, model configuration, costs, tools reference and permission modes pages), read 2026-10-10.

Six jobs a small model does well, with examples from this session

illustrative The inputs come from this conversation. The outputs are written for this page to show the shape of each job; they were not captured from Claude Code.

Where small models sit in other systems

• Routers: a classifier picks which model answers, sending easy requests to a cheap model.
• Safety and moderation classifiers screen inputs and outputs before and after the main model.
• Retrieval: embedding models (often well under 1B parameters) turn documents and questions into vectors; a reranker orders the hits; only the best few reach the large model.
• Speculative decoding: a small "draft" model guesses the next few tokens and the large model checks them all in one forward pass. Accepted guesses cost a fraction of a large-model step, and the output matches what the large model would have produced alone. Here the small model speeds up the large one instead of doing a separate job.

Why small is cheap: the arithmetic

Generating a token reads every weight once, so on one request decode speed is roughly memory bandwidth divided by the size of the weights. Anthropic doesn't publish its models' sizes, so these numbers use open models on one H100.

For one title the difference is milliseconds. Across millions of conversations, and with the small model often running on cheaper hardware, it is the difference between a background feature that costs almost nothing and one that costs as much as the answers. That is the "bigger vs overkill" trade in practice: a title doesn't get better with more parameters, so a product spends them only where they improve the answer.