In August 2026, the community reverse-engineered Grok Bot 0.18.0 and made its source code public on GitHub. Grok Bot is a desktop agent product built by Anysphere, the company behind Cursor. The previous article used this codebase to break down the capability layer: how tools expand on demand, and why Cursor provides full tool definitions for only a subset of tools to the model. This article breaks down the context layer: how the system prompt is assembled, how it remains stable, and what to do when it runs out of space. Two facets of the same leak.
This offers a rare opportunity: a direct look at the real internal orchestration code of a production-grade harness, rather than high-level claims in a blog post.
Examining the source code reveals that its design principles align closely with the domain’s best practices. Such alignment typically stems from one of two possibilities: coincidence or imitation. How do we tell the difference? By comparing it with Manus from a year earlier. In July 2025, the Manus team published Context Engineering, detailing how they manage an agent’s context. When two teams design independently and converge on the exact same constraints, those constraints are almost certainly forced by underlying fundamentals, not stylistic preferences.
If you put dynamic content like memory and current state into the system prompt and re-render it every turn, the resulting string changes between consecutive turns. Grok Bot’s design takes a different path.
FrozenMemorySnapshot stores two fields: the rendered
string render and an integer compactionEpoch.
Each time resolveFrozenMemoryPrompt is invoked, it checks
the cache first: if the cache exists and the cached epoch equals the
current epoch, it directly returns render without calling
renderLive or querying memory again. Only during the
initial turn, or when compaction occurs and increments the epoch, does
it perform a fresh recall + render, writing the new render
and updated epoch into the cache.
The agent profile uses the same mechanism.
AgentProfilePromptSnapshot also uses
compactionEpoch as its freeze key. When identity changes
occur, the profile section preserves the original text and merely
appends an update snippet at the end, layering the changes on top.
The result: within the same epoch, no matter how many turns the conversation runs, the byte-level content of the memory and profile sections in the system prompt remains completely unchanged. Only when context compaction occurs and increments the epoch is the prompt regenerated.
Why did Cursor go through the trouble of freezing the prompt? Wouldn’t reassembling it every turn reflect the current state more accurately?
Because the prompt serves as the cache prefix, sitting at the very front of the token stream seen by the model. Every time it changes, the entire prefix’s KV cache is invalidated. This is an economic necessity, not aesthetic purity.
For every token processed, the model computes its key and value. During subsequent generation, attention reads the KV representations of all preceding tokens; precomputed values can be reused. Across requests, there is an additional layer: if an opening sequence of tokens in the current request is identical to that of the previous request, the KV cache for that segment is reused directly and billed at the cached rate—which is 10x cheaper than the base price. For Claude Sonnet, cached input tokens cost $0.30 per million tokens compared to $3.00 for uncached tokens; Anthropic’s prompt caching documentation details this pricing and its invalidation rules.
During agent execution, the ratio of input tokens to output tokens is roughly 100:1. At every step, the context grows while the output is merely a short function call, meaning the vast majority of the cost lies in the input. At this ratio, the stability of the prefix directly determines the operational cost.
The autoregressive nature of LLMs dictates that if even a single token in the prefix changes, the KV cache from that token onward is entirely invalidated. When token p changes, its key and value change; token p+1 then attends to a modified token p and changes as well, cascading all the way down. Consequently, the cache can only be reused up to token p-1. Since the system prompt sits at the very beginning, altering it forces the entire prefix to be recomputed on every turn, incurring full base pricing.
The Manus Context Engineering article gave a concrete anti-pattern: placing a second-accurate timestamp at the beginning of the system prompt so the model knows the current time. This drops the cache hit rate to zero, forcing a complete recomputation from scratch every turn. Just to know what time it is, they paid full base price on all input tokens.
This economic reality also leads to two accompanying constraints:
context must be append-only, never modifying historical actions and
observations; and serialization must be deterministic, as unstable JSON
key ordering in many languages can silently bust the cache. Both are
direct corollaries of prefix invalidation, as is the constraint covered
in the previous article (the serialized tool surface must remain
stable). Tool schemas reside in the tools parameter, which
providers serialize at the very front of the context; modifying them
even once invalidates everything. The previous article detailed how
Manus’s “Mask, Don’t Remove” and Grok Bot’s hint + meta-dispatch solve
this constraint in their respective ways. Grounded in this economic
foundation, Grok Bot implemented three concrete disciplines in
production code, each corroborated by independent causal reasoning from
Manus.
The first discipline is freezing dynamic prefixes to compaction
boundaries. Grok Bot uses resolveFrozenMemoryPrompt to
check compactionEpoch, ensuring that within the same epoch,
the memory section remains byte-level stable and does not fluctuate with
each turn of dialogue. AgentProfilePromptSnapshot follows
the same structure: when announcedIdentity changes, an
update text snippet is appended to the profile section. Treating the
system prompt as a cacheable prefix and only permitting it to change
across compaction boundaries is a first-class design constraint, not an
implementation detail. In harnesses without freezing, any change in
dynamic content invalidates the entire prefix cache, causing costs to
surge back to the full base price.
Manus presented the exact same causal relationship in their July 2025 article, stating verbatim: “Keep your prompt prefix stable”. Grok Bot independently implemented this in August 2026 production code using compaction epoch freezing. Two teams, a year apart, reaching the same solution—proving that this constraint is driven by underlying fundamentals, not arbitrary design preference.
Freezing comes with a tradeoff: the prompt no longer reflects the latest state in real time. If memory changes, the prompt remains stale until the next compaction. Does this risk causing the model to make decisions based on outdated information?
Freezing applies to parts that should remain stable, not everything.
getMcpDiscoveryStatusSection makes this distinction
explicit: if MCP discovery fails in the current turn due to a backend
error, an <mcp_status> block is injected into the
prompt, reading:
Your MCP tools are temporarily unavailable: discovering the user’s MCP connectors from the backend failed for this turn. This does not mean the user has no MCP connectors; do not claim there are none or that a specific connector is missing. If the user requests MCP tools, inform them that MCP is temporarily unavailable and to try again later.
This is a runtime guard, not a static instruction. The prompt reflects not only product policies, but also what happened in this specific turn.
This does not contradict freezing. What gets frozen is the stable portion of the prefix; dynamic injection is reserved for parts that must reflect current state. The entire purpose of invalidation boundaries is to distinguish between these two categories: what can be frozen, and what must be updated every turn.
Manus’s article implied the same principle: context content must reflect current state, but the approach was to externalize state to the file system rather than reassembling the prompt each turn. Grok Bot opted for lighter-weight runtime injection. Currently, this discipline has only one direct implementation in Grok Bot, with Manus providing a high-level conceptual counterpart rather than independent convergence.
While the prompt can now reflect runtime state, the context itself continuously swells. Web page contents and large JSON payloads returned by tools inevitably inflate the context. What should be done when everything can no longer fit?
If the result of GetMcpTools exceeds 12KB
(FILE_OUTPUT_THRESHOLD_BYTES = 12_000), Grok Bot writes the
payload to the agent-tools/ directory on the box and
returns the file path for the model to Read. Only the path remains in
the context, not the full payload.
Even more critical is verification:
checkMcpToolDefinitionRead uses hasReadPath to
track whether the model has actually read that schema file, rejecting
invocations if it has not. Whether it was read is a verifiable state,
not a self-attestation by the model.
Manus articulated the foundational principle behind the same mechanism: the file system is the ultimate context, “unlimited in size, persistent by nature, and directly operable by the agent itself”. Compression strategies should be “always designed to be restorable”: web page contents can be dropped from the context as long as URLs are preserved; document bodies can be omitted as long as file paths remain in the sandbox. Why must compression be restorable? Manus explains that an agent must predict its next step based on all prior states; you cannot reliably predict which observation will become critical ten steps later, so any lossy, irreversible compression carries inherent risk.
The previous article mentioned this mechanism briefly from the capability perspective: GetMcpTools results exceeding 12KB are written to disk, keeping only the path. This article examines it from the perspective of context capacity management and restorable compression. The same mechanism, viewed through two facets.
This discipline also shows independent convergence: Manus provided
the principle—the file system serves as the ultimate context, and
compression must be restorable; Grok Bot provided the implementation—a
12KB threshold paired with hasReadPath validation. Two
teams, a year apart, adhering to the same externalization
discipline.
All three Grok Bot disciplines (stability, append-only, externalization) have corroborating evidence. The Manus article contains three additional disciplines that are not directly reflected in Grok Bot’s source code; they belong to the same context engineering paradigm, but currently rely on Manus as a single chain of evidence.
When tackling complex tasks, Manus creates a todo.md, continuously rewriting it and checking off items one by one. This is deliberate attention steering, not merely a cosmetic quirk. In a typical task averaging 50 tool calls, models easily drift and lose sight of global objectives across long execution loops. By repeatedly rewriting the todo list, Manus recites global goals near the tail of the context, pushing them into the model’s recency attention to combat lost-in-the-middle effects and goal misalignment. Biasing attention toward task goals via natural language requires zero architectural changes.
Agents make mistakes; this is a reality, not a bug. In multi-step tasks, failure is an intrinsic part of the loop, not an exception. The common instinct is to clean traces, retry, and reset state, but erasing failures eliminates evidence—and without evidence, the model cannot adapt. Retaining errors in the context allows the model to see failed actions and stack traces, implicitly updating its beliefs and reducing the likelihood of repeating the same mistake. Manus considers error recovery one of the clearest hallmarks of agentic behavior, yet it remains underrepresented in most benchmarks.
LLMs are exceptional imitators that replicate behavioral patterns present in their context. If the context is saturated with repetitive action-observation pairs, the model will lock onto that pattern even after it ceases to be optimal. Manus illustrates this with an example: while batch-reviewing 20 resumes, the agent falls into a rhythm, mechanically repeating similar actions, leading to drift, overgeneralization, and occasionally hallucinations. The solution is injecting structured variation: diverse serialization templates, alternate phrasing, and subtle noise in ordering and formatting. The more uniform the context, the more brittle the agent becomes.
These three mechanisms currently have only Manus as a single chain of evidence and are not directly observed in Grok Bot’s source code, marking them as not independently verified.
Treat prompts and contexts as first-class engineering objects, not configuration strings. Here is the complete set of six disciplines:
| Dimension | What to Do | Causal Mechanism | Independent Convergence Evidence |
|---|---|---|---|
| Stability | Freeze prefix to compaction boundaries | KV cache 10x | Manus causal reasoning + Grok Bot compaction epoch freezing |
| Append-Only | Append-only, deterministic serialization | Prefix change invalidates everything | Manus causal reasoning + Grok Bot no reassembling |
| Externalization | Spill large artifacts to file system, restorable compression | Context capacity + irreversible compression risk | Manus principles + Grok Bot 12KB spill + hasReadPath |
| Recitation | Recite goals at context tail | Combat lost-in-the-middle | Manus recitation |
| Retention | Retain errors in context | Model implicitly updates beliefs via evidence | Manus keep-wrong-stuff-in |
| Variation | Inject structured variation into serialization | Combat few-shot stereotyping | Manus don’t-get-few-shotted |
The first three disciplines (Stability, Append-Only, Externalization) converged independently across both teams and are load-bearing. The latter three (Recitation, Retention, Variation) currently rest on Manus as a single chain of evidence and remain without independent verification.
A parting takeaway for harness builders: treat the system prompt as an engineering object with explicitly managed invalidation boundaries. What should be stable, what should be append-only, what to externalize, what to recite, what to retain, and what to vary—each choice is rooted in clear causal mechanics, not stylistic preference. When two independent products converge on the exact same set of disciplines, those disciplines provide the benchmark for deciding what is truly worth adopting.
Two facets of the same leak: