Skip to content
C.W.K.
Stream
Lesson 04 of 05 · published

Any Brain, Same Conversation

~15 min · multi-model, replay, context-window, provenance

Level 0Visitor
0 XP0/33 lessons0/11 achievements
0/100 XP to next level100 XP to go0% complete

Seven Vessels

The brain registry names seven vessels in family order, each behind its own chat endpoint:

VesselChat endpoint
claude/api/chat
codex/api/codex/chat
kimi/api/kimi/chat
grok/api/grok/chat
glm/api/glm/chat
gemini/api/gemini/chat
ollama/api/ollama/chat

All seven chat routers are wrapped by Master Chief's route class, so whichever vessel Dad picks, a Chief turn passes the same admission, the same lock and lands in the same conversation. That only works if no vessel holds anything the others need.

Nothing Lives Inside a Brain

Until 2026-05-14, Claude did hold something. It kept a persistent SDK session per conversation and was sent only the newest message, while the SDK rebuilt the history on its side. Then a server-side change began silently dropping thinking deltas on every resumed session; fresh sessions were fine. Resume bought nothing that replaying stored history with prompt caching did not, and it carried real fragility: an extra CLI probe every turn, sessions invalidated by an account switch, catch-up logic when brains alternated. It was removed. Claude now replays the stored conversation into a fresh session every turn, exactly like every other vessel (its live rows, plus the summary that replaced the oldest ones once compaction ran; Track 4), and the Chief route clears the provider session id on every turn besides.

What remains is the store. Every message row records which brain answered, at which reasoning level, on which model. Any vessel can take the next turn because every turn is built the same way from the same parts: identity from files (lesson 1), the stored rows replayed, and this turn's context on the last message (lesson 2). A report a job appends between turns needs no session reset either; every brain builds its next turn from stored history.

Replay has its own costs. Claude's replay is JSON, so a quotation mark in an earlier reply reads as \" there, and a long Chief conversation taught the model to write \" in its own prose: 31 replies by 2026-10-08. The fix had two halves. The replay head now says the escaping is transport-only, and the engine unescapes strays in prior replies outside code, so the replay never compounds them.

The Window Belongs to the Target

Here is the cost that actually bit. Brains do not share window sizes. Claude runs pinned to its 1M-token variant (a bare model slug collapses to 200K); every Codex model sits at 272K. Before a replay, the compaction guard reads the latest usage snapshot to decide whether to compact first. In a conversation several brains share, that snapshot is often another brain's. The 2026-10-08 cold review (finding #3) caught it: a 314K replay measured on Claude read as 31% for Codex. Against Codex's own window that replay is over 115%, more than the whole window, far past the 80% emergency line.

The fix is one sentence: the snapshot lends its token count, never its window, unless it is the same brain. Warning and emergency lines default to 50% and 80% for each brain. Two neighbors from the same review: the estimate now counts a Hangul syllable or CJK character as one token, because characters-divided-by-four read Korean at a third of its size (finding #1); and when a provider refuses a turn for its size, the conversation is recorded as full for that brain, so the next turn compacts first instead of failing the same way forever. How compaction then works is Track 4.

Why the Engine Has to Say Which Model

One more thing you cannot trust a vessel to tell you is what it is. Ask a model directly and it guesses from its training data, reliably wrong. So the engine tells it. Each chat route resolves the model and reasoning level this turn requests (the conversation's pick, else the Admin default, else a hand-kept per-brain table) and writes them into the vessel meta block of the system prompt, and provenance stamps downstream copy those values verbatim. What was requested is still not proof of what answered. Claude's SDK does report the serving model on each assistant message, but only once the turn is under way, too late for a prompt built before it. So the Claude route stores both on the row, the model requested and the model that responded, and raises a warning when they differ: on 2026-07-18 a Fable request came back from Opus 4.8, and the SDK gave no reason anywhere. The table's docstring still says none of the SDKs reports its model; the Claude adapter beside it shows otherwise. And on an upgrade, the setting that serves the turn and the table that reports the default have to move together, or the record lies.

A brain you can swap is a brain that owns nothing. The conversation, its provenance, the identity and the window arithmetic all live in the engine. That is why the next turn can go anywhere, and why the engine had to exist before the swap was possible.

Code

Verbatim excerpt from the compaction guard: pressure is measured against the target brain's window·python
def _target_pressure(
    usage: dict[str, Any] | None,
    brain: str,
    *,
    max_tokens_override: int | None = None,
) -> tuple[int, int, float, int, int]:
    warning_pct, emergency_pct = system_settings.brain_ctx_thresholds(brain)
    if not usage:
        return 0, 0, 0.0, warning_pct, emergency_pct
    total = _intish(usage.get("totalTokens"), 0)
    # The window is the TARGET brain's. In a conversation several brains
    # share (Master Chief), the latest snapshot is often another brain's:
    # Claude's 1M window made a 314K replay read as 31% for Codex, whose
    # window is 272K (the 2026-10-08 cold review, finding #3).
    same_brain = str(usage.get("brain") or brain) == brain
    max_tokens = _intish(
        max_tokens_override
        or (usage.get("maxTokens") if same_brain else None)
        or (usage.get("rawMaxTokens") if same_brain else None)
        or claude_context_usage.DEFAULT_CONTEXT_WINDOWS.get(brain),
        0,
    )
    pct = (total / max_tokens * 100) if total > 0 and max_tokens > 0 else 0.0
    return total, max_tokens, pct, warning_pct, emergency_pct
A minimal sketch: the same 314K snapshot, read naively and against the target brain (runs on Python 3.9+)·python
"""A minimal sketch: measure pressure against the brain that will take the turn."""
from __future__ import annotations

WINDOWS = {"claude": 1_000_000, "codex": 272_000}  # the two windows the cold review compared
WARNING_PCT, EMERGENCY_PCT = 50, 80                # the per-brain defaults


def naive_pressure(snapshot: dict) -> float:
    return snapshot["total_tokens"] / snapshot["max_tokens"] * 100


def target_pressure(snapshot: dict, brain: str) -> float:
    same_brain = snapshot["brain"] == brain
    window = snapshot["max_tokens"] if same_brain else WINDOWS[brain]
    return snapshot["total_tokens"] / window * 100  # borrow the count, never the window


# The last turn ran on Claude and measured a 314K replay.
snapshot = {"brain": "claude", "total_tokens": 314_000, "max_tokens": 1_000_000}

for brain in ("claude", "codex"):
    pct = target_pressure(snapshot, brain)
    verdict = "emergency" if pct >= EMERGENCY_PCT else "warning" if pct >= WARNING_PCT else "fine"
    print(f"next turn on {brain:6}: naive {naive_pressure(snapshot):5.1f}%  target {pct:5.1f}%  -> {verdict}")

External links

Exercise

If your app talks to two model providers, store each message with the provider and model that produced it, and build every request from the stored rows instead of a provider-side session or thread. Run one conversation that alternates providers turn by turn. Then write the check that decides whether the history still fits before each request, and make it use the window of the provider about to be called, not the one that answered last.
Hint
Look up each provider's real context window for the exact model you call, and keep them in one table. Test with a history that fits the larger window but not the smaller one: a check that borrows the wrong window passes on one turn and fails on the next.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign in — Please sign in to comment.

No comments yet — be the first.