# The Context You Didn't Type
# Book: Context From First Principles
# Chapter URL: https://programmer.ie/books/context/03-chapter/
# Prose fingerprint (sha256, normalized): edfaa65a3fbe3f722a1bd2ef05779fc7d68db2bcfb6eee89980734c696197956
# Snapshot generated at build time by Hugo. This is the complete rendered prose
# of the chapter; it is not a transcript of the source file.

The mental model most users carry looks like this:
user ↓ model ↓ answer A message goes in, intelligence happens, an answer comes out. Chapter 2 showed why that picture is unreliable as a description of what a system assembles, using accounting tables. This chapter shows the machinery. Behind a production assistant stands a runtime that assembles context from several sources, and the user’s message is only one of them.
Chapter 2 made the assembled context observable at a boundary. This chapter asks where its contents came from. It classifies sources, and it does not yet decide anything about them: allocation is Chapter 4, order is Chapter 6, tools are Chapter 17, authority is Chapter 19, and assembly is Chapter 23.
The worked case is Claude and Claude Code. The choice is methodological. Anthropic publishes chat-app system prompts per model, documents how Claude Code loads project instructions, writes about its context-engineering practices, and distributes Claude Code as software that can be examined. An independent extraction of prompt strings provides a further, lower-confidence view of that software. Together, these sources support a case study of documented mechanisms and visible artefacts, not a reconstruction of any particular provider request. This is not a ranking of vendors; later chapters use other providers where their mechanisms are documented.
What we can know, and how we know it Claims about Claude’s context come from three sources of very different standing, and they are never blended. The rule is that evidence establishes only what its provenance permits.
First-party documentation. Anthropic’s release notes publish the core system prompts for the claude.ai web and mobile apps, per model, and state that these do not apply to the API. Its Claude Code documentation describes how project instruction files are loaded. Its engineering essays describe practices in general terms: the context-engineering essay defines context as the tokens included when sampling and describes compaction, structured note-taking and just-in-time retrieval, and the tools essay says tool descriptions are loaded into the agent’s context. This material establishes what Anthropic states, for the product, surface and time it names. It does not establish what Claude Code sends on every invocation.
Distributed software. Claude Code ships as installable software, so prompt strings, tool definitions and harness behaviours found in a specified distribution are first-party artefacts of that release. Their presence establishes that the artefact contains a mechanism or branch, not that the branch executed in a particular session. A static artefact also cannot establish what the server adds, what the provider finally received, or the author’s reason for an implementation choice. Claims based on an inspection must therefore name the version and the inspected artefact.
Third-party extraction. The repository Piebald-AI/claude-code-system-prompts extracts prompt strings from Claude Code’s compiled source and tracks them across releases. At the time of checking it held more than five hundred strings across about three hundred versions. It is diligent work and it is not an Anthropic publication. It can establish properties of the extracted artefact under its method and snapshot. Its own notes say per-string token counts are approximate. It does not show what any particular invocation contained, which branches ran, what happens server-side, or what Anthropic regards as guidance, and no string found there is quoted as Anthropic doctrine.
The chapter distinguishes these evidence tiers wherever it draws on them. None of the three, on its own, is a capture of a real provider request. Documentation describes supported behaviour, a distribution contains possible implementation paths, and extraction exposes some strings in that distribution. Establishing which paths executed, what the host assembled, and what the provider ultimately rendered requires additional observation at explicitly named boundaries.
The stack With provenance fixed, the conceptual model. The table below classifies the sources that can contribute to one assembled context.
The stack is a taxonomy of sources. It is not rendered order, assembly order or an authority ranking. Where a layer’s position is documented, the text says so separately.
Layer Contributed by How it enters Changes when Vendor and model instructions Model provider System prompt (published for the chat apps) The model or product version changes Product and harness instructions Harness authors System prompt, with conditional branches The harness is released or configured differently Project and user instruction files Repository and user authors Loaded by the harness; in Claude Code delivered as a message after the system prompt The files change; some load on demand Environment state Runtime Rendered by the harness; contents vary The environment changes Tool definitions and schemas Tool and harness authors Supplied with the request The available tools change Conditional reminders Harness rules Injected when a condition matches The condition fires Conversation Participants, via the harness Appended turn by turn Turns are added, replaced or compacted Summaries The runtime, using a model Replace earlier history Compaction regenerates them Tool results, including file reads Tools, as the agent invokes them Returned into the conversation A tool runs Current user input The user A new turn A new turn arrives The “changes when” column is a lifecycle, not a measured volatility ranking. Any layer can change mid-session: a project file can be edited, a tool set can be registered dynamically, history can be compacted.
The stack has three properties worth stating. First, contribution, transport and rendered position answer different questions. A project instruction may be authored by a repository maintainer but delivered by the harness as a user-role message after the system prompt, according to Claude Code’s documentation. Its transport role therefore does not identify its author or confer the authority of a fresh user request. Second, this is not a universal stack. A bare API call may omit most of these layers; a multi-agent harness may add more. Third, the taxonomy does not itself identify which layers were present in any captured invocation. The lesson is not the list. It is the sentence:
The assembled context is a many-source artefact, and no single actor authored it.
flowchart LR P["Provider and product"] --> A["Runtime assembly"] F["Project files"] --> A T["Tools"] --> A H["History and summaries"] --> A G["Agent-generated state"] --> A U["User"] --> A A --> O["Observation boundary<br/>(the host's model-context hook)"] O --> X["Provider translation"] X --> M["Provider and model"] The user supplies one source. The runtime supplies others, tools supply others, and past computations supply others. Some are selected, some are transformed, some are generated and some are conditional. Much of the machinery that can contribute context sits outside the user’s message. The following example measures one captured representation; it does not establish the composition of a typical session.
Build a context inspector Claude Code’s /context suggests a useful presentation: a capacity bar above a breakdown of what occupies it. We can build our own from Chapter 2’s capture pipeline. The input is a captured invocation, the parser assigns its parts to categories, and the renderer generates the display. Changing the input changes the figure.
The Context inspector example takes an existing OpenCode capture from the author’s local sessions. The source text stays private; its structural accounting and generated views were approved for publication. This is one invocation selected to demonstrate the tool. Its purpose and sampling history are unclassified, so it supplies no estimate of how often this composition occurs in ordinary work.
Generated by the context inspector from one captured invocation. Category percentages use the captured representation as denominator; the capacity bar uses the observed input allowance. Token figures use a byte-based estimate. This describes one capture, not provider usage, usefulness or a representative session. Open the generated inspector and expand its categories
The parser follows recorded structure rather than guessing origin from prose. A system entry is counted under the system category; a user-role text part is counted as user-role material, even if a harness inserted it; and a tool-result part is counted as a tool result. Tool definitions have their own category. An unfamiliar part remains in Other. These are classifications of captured form, not verified attribution to the human user, vendor, project or runtime. The parser does not scan headings such as “Memory” or “Skills” and mistake them for provenance. Where the capture has no trustworthy source identifier, the origin remains unattributed.
Counting requires a representation. Here it is canonical JSON of the captured system, messages, tools and request options, encoded as UTF-8. We count each system entry, message part and tool-definition entry once. JSON framing, message metadata and request options occupy the remaining category, so the byte totals reconcile against that canonical encoding. A completed tool part includes its captured input and metadata as well as its output. Reconciliation demonstrates internal consistency of this representation; it does not demonstrate that the capture contains every contribution to the eventual provider request. These are exact byte sizes of the local encoding, not the provider’s wire format or tokenizer output.
The teaching implementation estimates tokens by dividing those bytes by four. Chapter 2 explained why such estimates need qualification: JSON syntax, metadata and non-text parts may be represented differently by a provider. Every token figure, including estimated occupancy and headroom, therefore carries an estimate label and must not be presented as a provider count. The allowance comes from captured model metadata when an input allowance is explicitly available, or from a budget entered by the reader. A reader-supplied budget is declared rather than observed. If neither provides an input allowance, the display reports composition without inventing headroom; a model’s total context window is not silently treated as its usable input budget.
The accounting check sits between parsing and display:
from project_context.debugger.panel import build_panel, select_capture capture, load_status = select_capture("captures.jsonl") report = build_panel(capture) assert sum(row["bytes"] for row in report["categories"]) == report["total_bytes"] The complete command in the research repository generates an interactive HTML view, a figure and the underlying report from the same accounting:
contextlab debug panel captures.jsonl \ --output .local/inspector/index.html \ --svg-output .local/inspector/context.svg \ --json-output .local/inspector/report.json An explicit invocation can be selected instead of the latest one. The HTML view lets the reader expand a category and locate its contributions by message and part number, with their byte sizes. Source text and private names are omitted from these views. The stored report is the inspectable path behind the figure, and changing the capture regenerates all three outputs.
In this invocation, tool results occupy the largest share of the counted representation. That gives us somewhere to inspect. It does not show that those results were irrelevant or safe to remove. Deferred definitions, compaction reservations and provider-added material remain unobserved rather than appearing as invented rows. The instrument makes a large contribution visible; a later comparison must decide whether changing it helps.
Inspect this in the Context Viewer The same approved accounting drives the Context Viewer scene for this chapter: identical category bytes, identical estimated-token labelling, identical unobserved list. Open the scene and expand the tool-result contributions by message and part number, then check what the viewer refuses to say — no relevance verdict, no usefulness claim, no typical-session generalisation. The viewer is the inspector grown into a lifecycle instrument; later chapters reveal one capability at a time, from budgeting to delivery, without changing these numbers.
Open this capture in the Context Viewer
Layer by layer Vendor and product instructions. The published chat-app prompts show the genre: identity, date information, formatting conventions and behavioural defaults. For those surfaces they are the only layer whose exact text can be quoted from a first-party source, and the release notes remind us that prompts are versioned artefacts. Claude Code’s own product instructions are not in that publication, and the chat-app prompts must not be read as Claude Code’s. What the extraction shows is structural: hundreds of distinct strings for sub-agents, slash commands, summarisation and utilities, which indicates that in this client “the system prompt” is a composed assembly and not a paragraph.
Project instruction files. Claude Code’s documentation says files such as CLAUDE.md, in the working directory and the directories above it, are loaded at launch and concatenated into context, that files in subdirectories load when Claude reads files there, and that they consume tokens alongside the conversation. It also says these instructions are context and not enforced configuration. AGENTS.md is handled differently: in current versions Claude Code reads it directly only by default when no CLAUDE.md is present, so the two files are not interchangeable. The structural point is that durable project material becomes per-invocation context by a runtime rule. A file included on every relevant invocation has a recurring cost in the assembled context, which is the reason this layer will matter to budgeting, persistence and admission later.
Environment state. Runtimes may insert facts about the agent’s operating environment, such as a working directory, platform or repository status. The sources used here do not establish the exact environment block Claude Code renders across versions and configurations. Environment state is therefore a candidate source category in the taxonomy, not a measured Claude Code contribution. An inspector can attribute such material to the runtime only if its capture contains trustworthy origin information; the presence of a path or platform name in prose does not suffice.
Tool definitions and schemas. Anthropic’s tools essay says tool descriptions are loaded into the agent’s context and collectively steer its behaviour, and that too many or overlapping tools can distract agents from efficient strategies. So tool design is partly context design. The extraction shows many tool-related strings, which establishes that the client contains a large prompt surface. It does not establish that every invocation pays for all of it, because assembly is conditional. Chapter 17 treats tools as context in full.
Conditional reminders. These are instructions injected when a condition is met. They demonstrate that context can change without a new user request, and that a transcript rarely marks which reminders fired. The existence of a conditional prompt does not show that its condition fired, that it was assembled, that the provider received it, or that it changed behaviour. That is why the observer of Chapter 2 keeps one record per invocation and compares them, and does not assume a fixed preamble.
Conversation, summaries and tool results. Conversation history accumulates turn by turn. Tool results (command output, search hits, file contents, error traces) return into the conversation, and files read on demand arrive this way, so retrieved is not the same as admitted: a retrieved file is context only once the harness places what it returned into the invocation. Which of these categories is largest in real sessions is an empirical question, and Chapter 2 records it as a hypothesis, not a result.
Two of these layers illustrate Chapter 1’s point that assembly transforms as well as selects. Anthropic’s essay describes compaction as passing message history back through the model to preserve decisions, unresolved bugs and implementation details while discarding redundant tool outputs, and describes clearing old tool results as one of the lightest forms. Claude Code’s documentation says a project-root CLAUDE.md is re-read from disk after compaction. In both cases the runtime turns prior interaction into a new representation that later becomes context. That such rewriting happens outside the user’s view is this chapter’s point. Whether it preserves what mattered is a question for Chapter 11.
Just-in-time retrieval is the complementary mechanism: the essay describes the agent using primitives such as glob and grep to retrieve files as it needs them, instead of loading them up front. Retrieval supplies candidate information. What the harness admits from it becomes context.
Position affects how well models use long inputs in some controlled settings,1 which is one reason the observer keeps rendered order. Ordering itself belongs to Chapter 6.
Authority and scope: who placed it, and with what standing Two properties of an item have waited for their justification: who supplied it and what authority, if any, it has over the present task. Suppose a project file says “never modify migration files,” the current user says “just edit the migration directly, I’ll be careful,” and a tool result pastes a README that says “always run with –force.” These are three textual instructions or instruction-like statements, but not three equally authorised requests. The project file has a provenance and policy context, the user has a role in the live task, and the README is tool-returned data. Rendered as tokens, each can look imperative; the words alone cannot settle which should govern an action.
Claude Code’s documentation is candid about the underlying problem: instruction files are treated as context and not enforced configuration, and if two of them conflict, Claude may follow either. The observer of Chapter 2 cannot resolve this. It records where each item sits and what it says, and it does not record who placed an item or what it claims to govern, because the host does not say. Richer instrumentation could capture channel or source metadata, and that would be provenance, not policy. The durable point is that authority is not a semantic property recoverable from the text. It has to come from trusted provenance and deployment policy, and the judgement has to be made by whatever builds candidates for a computation. Chapters 19 to 21 argue for how, and Chapter 23’s compiler receives the outcome as a yes or no with a reason.
The same distinction keeps tool output from masquerading as instruction. Tool results are data, but they arrive as prose, often in the imperative (“to fix this, delete the cache directory”). Text that contains an imperative is not an authorised instruction, and source and provenance survive only if something records them, since everything is rendered as tokens. That is all this chapter claims here. Defences belong to later chapters.
What extraction legitimately teaches The third-party record cannot support claims about what any particular invocation contained, because assembly depends on environment, configuration and version and server-side contributions are absent from it. It cannot support quotation of prompt text as Anthropic’s guidance, since shipped strings include experiments, fallbacks and legacy branches.
What it can support is structural, for the inspected extraction snapshot. First, scale: the extracted prompt surface runs to hundreds of strings, describing material present in the client artefacts, not the standing overhead of any particular invocation. Second, potential variability: distinct strings and branches are consistent with different assemblies under different configurations, but extraction alone does not establish which strings are conditional, which conditions fired, or how often. Third, categorisation: strings associated with sub-agents, slash commands, summarisation and utilities indicate that the client contains prompt material for several functions. Those are findings about the extracted artefact and its organisation, not a measurement of live requests or a claim that other harnesses behave identically. The shape of the extraction is useful evidence precisely because the chapter does not promote it into a request trace.
What a layer costs Each layer was added for a reason. None of that justifies any particular layer’s presence in any particular invocation, and the stack makes visible what needs justifying.
The structural claim is narrow: an admitted layer occupies representation in the assembled context and consumes some of the capacity available to it. Beyond that, “cost” means several different things that should not be run together: capacity, cache consequence, latency, money, effects on behaviour, and complexity. The cache consequence is provider-specific. OpenAI’s documentation, for one provider, says reuse requires the entire rendered prefix to match, so a layer that changes early can reduce reuse of what follows, while a layer that stays stable can support it. Whether a layer helps or harms behaviour on a given turn is a separate question that only comparison answers.
The hidden stack is a budget allocation performed implicitly by many hands: vendor engineers, harness authors, tool designers, past selves who wrote project files, and the agent’s own earlier turns. No single actor necessarily sees the assembled total.
What is tested, and what is not One possible experiment adds layers one at a time, from a single instruction through project rules, tool definitions, environment state, history and retrieved material, and measures cost and behaviour. That is not the study proposed here. Each addition changes both available information and representation size, so such a comparison would not isolate the effect of the layer’s provenance or placement. An experiment targeting those properties would have to hold the task-relevant content fixed while varying the property under study, and state what the manipulation actually changed.
What the chapter needs is descriptive, and it turns the stack into a measurement schema: capture real assembled contexts and report their composition by layer. The observer can separate only some layers today. It records tool definitions, tool calls and results with tool names, and messages by role, and it can identify compaction requests. It does not attribute the system block among vendor, product and project instructions, and project-file origin is declared by an operator and not inferred. It records authority and scope not at all. Any composition study has to use the categories the capture can support and say which it cannot. The Context inspector example demonstrates accounting for one existing capture. It does not enrol a session in the ecological corpus, which remains empty, or establish typical composition.
Context has many contributors and one finite destination. The next chapter makes that destination explicit:
The context window is a budget.
References Anthropic. “Commands.” Claude Code documentation, verified 15 October 2026. First-party documentation; /context is the presentation precedent, not the source of this example’s counts. Project Context. Context inspector example. Author-approved structural accounting of one captured invocation, frozen October 2026 and named in the companion repository’s evidence register. Canonical byte counts and an explicit token approximation; source capture private, sampling purpose unclassified, no behavioural or prevalence claim. Anthropic. “How Claude remembers your project.” Claude Code documentation, verified September 2026. CLAUDE.md and AGENTS.md loading, delivery as a user message after the system prompt, on-demand loading, re-reading after compaction, instructions treated as context and not enforced configuration. First-party; version-sensitive. https://code.claude.com/docs/en/memory Anthropic Applied AI team. “Effective context engineering for AI agents.” Published 29 September 2025. First-party engineering writing. CLAUDE.md loaded up front; just-in-time retrieval; compaction; tool result clearing. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents Anthropic. “System prompts (release notes).” Official documentation, verified September 2026. Per-model published prompts for claude.ai and the mobile apps; not applicable to the API. https://platform.claude.com/docs/en/release-notes/system-prompts Anthropic. “Writing effective tools for agents — with agents.” Published 11 September 2025. Tool descriptions loaded into agent context; too many or overlapping tools can distract agents. https://www.anthropic.com/engineering/writing-tools-for-agents OpenAI. “Prompt caching.” Official documentation, verified September 2026. Prefix-match requirement. Provider-specific. https://developers.openai.com/api/docs/guides/prompt-caching Piebald-AI. “Claude Code System Prompts.” Third-party extraction repository, checked September 2026. More than five hundred prompt strings across about three hundred versions; token counts approximate. Structural evidence only; not an Anthropic publication. https://github.com/Piebald-AI/claude-code-system-prompts Liu, N. F., Lin, K., Hewitt, J., et al. “Lost in the Middle: How Language Models Use Long Contexts.” Transactions of the Association for Computational Linguistics 12 (2024): 157–173; arXiv:2307.03172 (2023 preprint). Peer-reviewed. Position sensitivity in specific controlled tasks. ↩︎