Where your prompt goes and how it works
Follow one prompt through Claude Code: out of your terminal, across the internet, through the model, back into your files and around again until the job is done. Every step is tagged with where it runs.
One prompt, end to end
Every step has its own interactive visualization below. Hover a step for a summary, click to jump to it or just scroll.
Your prompt is read on your computer first
Claude Code is a program running on your machine. Before anything goes to a model, it checks your input for special syntax, and some input never leaves your computer at all. Try it:
The model only knows what is packed in
The model has no memory between requests and can't see your disk. So on every request, Claude Code packs everything it needs into one bundle, the context window: instructions, tools, project notes and the whole conversation so far.
Models read tokens: common words, word pieces and punctuation, each mapped to a number. English averages roughly 3–4 characters per token. Context limits, prices and speeds are all counted in tokens.
managed CLAUDE.md~/.claude/CLAUDE.md · ~/.claude/rules/./CLAUDE.md · .claude/rules/*.md./CLAUDE.local.mdsrc/api/CLAUDE.md, when Claude reads files thereMEMORY.mdAll of these are plain files on your disk. Claude Code reads them at the start of a session and adds them to the context.
Claude Code does not upload or embed your repository. There is no vector index. The model finds code as it works, by searching and then reading files, the way a developer would. Only what those tools return enters the context, and only that is sent.
One HTTPS request carries it all
The bundle becomes a single JSON Messages API request, encrypted with TLS. Claude Code asks for a streamed reply so text can appear while the model is still writing.
- IDWho you are. With a Claude subscription, Claude Code sends the OAuth token it saved when you logged in. Otherwise an API key, or your AWS, Google Cloud or Azure credentials.
- ⇄Stateless. Our example makes 6 requests for one prompt, and each one resends the entire conversation.
- ⚙Your choices ride along:
/modeland/effortgo with every request.
Check the request at the door
Before any model runs, the provider's API front end checks who you are and whether you have capacity, then routes the request to servers running the model.
Authenticate
Valid token or key? Which organization and plan?
Limits
Within your rate limits and plan usage?
Validate
Well-formed JSON? Fits the context window?
Route
To one of many copies of the model in the provider's data centers.
Inside the neural network
Embed looks up each token's starting list of numbers in a table the model learned. Prefill then runs every prompt token up through the layers, computing a key/value pair for each token at every layer based on the model's weights. Decode writes the reply one token at a time, picking each one from the odds computed at the top of the previous token's column.
The reply streams back
Tokens flow back over the same connection as server-sent events, and the terminal shows text the moment it arrives. A tool call arrives as JSON in pieces and only runs once complete. Thinking, if it's shown at all, arrives as a summary. Each event lights up what it produced.
Answer or tool call?
Every reply ends with a stop_reason. It is the switch that drives everything: if the model stopped to use tools, Claude Code runs them and calls the model again. If it's finished, you get the answer.
A reply can ask for several tools at once. Each one still passes the permission gate, and read-only ones, like reading or searching files, run at the same time.
The permission gate
Whether a requested tool actually runs is decided locally, by a fixed chain of checks. One is your hooks: your own scripts that Claude Code runs at set moments, such as before each tool. They're plain code, so the model can't talk its way past them. Pick a tool call, a mode and some rules. Then drop it through the gate.
Sandboxing (optional) also fences commands into your project at the operating-system level.
Tools do the work
Each tool is code inside Claude Code (or an MCP server) with the schema the model saw in step 02. The bar on each tile shows where it runs. Code reaches the model as plain text, never a parse tree: Claude finds its way with search, not a pre-built index. Hover a tool.
The answer lands
The final reply streams in as formatted Markdown. Any Stop hook you've set up runs (it can even send Claude back to work if tests still fail). The whole session is written to disk locally.
Resume with claude --continue or --resume. Edits made with Claude's file tools are checkpointed: EscEsc or /rewind rolls them back. Files changed by shell commands, deploys and database writes can't be undone this way.
The agentic loop
Steps 03 → 09 repeat: each tool result joins the conversation, the whole conversation goes back to the model and it picks the next move. Drag through our prompt (run in Manual mode with npm test allowed by a rule, so you'll see Claude ask only before editing). Esc interrupts at any point.
Subagents: loops inside the loop
For broad research the model can call the Agent tool. Claude Code starts a subagent: a fresh conversation with its own context window, system prompt and tools, running its own loop of API calls. Only its final report returns.
Subagents can run in parallel or in the background, with fewer tools or a cheaper model. You can also define your own.
When the window fills up: compaction
Long sessions grow toward the limit. Near it, Claude Code auto-compacts: it first clears old tool outputs, then asks the model to summarize the conversation and continues from that summary plus recent messages. Keep working and watch.
/compact summarizes on demand and /clear starts fresh. After compaction your project notes are loaded again, so standing instructions aren't lost.
What leaves your computer and what doesn't
Only what crosses the internet lane leaves your machine. Everything else stays local.
- To the model provider: your prompts and images, Claude Code's instructions and tool definitions, CLAUDE.md and memory, and everything tools return (file contents, search hits, command output, fetched pages)
- Usage metrics and error reports, which you can turn off
- WebFetch safety check: the hostname only, sent to Anthropic before a fetch
- Remote MCP traffic goes to that MCP server, not to the model provider
- Feedback you choose to send with
/feedback
- Files Claude never reads; there's no repo upload or index
- Execution: every edit and shell command runs locally
- Permission rules, hooks and the sandbox, all enforced locally
- Transcripts and checkpoints in
~/.claude - Local MCP servers and their credentials
Server-side retention depends on your account: commercial accounts default to 30 days; consumer accounts depend on your model-training setting.
References and further reading
Product details here were checked against Anthropic's documentation in October 2026. What happens inside the provider's data centers (steps 04–05), including where the model runs and how cached results are stored, is described from public documentation and standard techniques for serving large models. Anthropic doesn't publish its internal implementation, so the real details may differ.
Claude Code documentation
- How Claude Code works: the agentic loop, tools and sessions
- Explore the context window and How Claude remembers your project (step 02)
- Hooks reference (steps 08, 10)
- How Claude Code uses prompt caching (step 05)
- Choose a permission mode, Configure permissions and Sandboxing (step 08)
- Tools reference and MCP (step 09)
- Subagents (step 12)
- Model configuration: context windows, compaction thresholds, effort (steps 03, 13)
- Checkpointing (step 10) and Data usage (what leaves your computer)
Claude API documentation
- Tool use (steps 03, 07, 09)
- Errors and Rate limits (step 04)
- Prompt caching and Pricing (step 05)
- Thinking (step 05)
- Streaming messages (step 06)
- Handling stop reasons (step 07)
Anthropic engineering
Background: how transformers run
- Vaswani et al., Attention Is All You Need (2017): attention, keys, values and MLP layers (step 05)
- Pope et al., Efficiently Scaling Transformer Inference (2022): prefill vs. decode and the KV cache (step 05)
- Kwon et al., Efficient Memory Management for LLM Serving with PagedAttention (2023): storing and reusing KV caches (step 05)
- Server-sent events, HTML Living Standard (step 06)
- Model Context Protocol (step 09)