[nissa-seru]

This adds thinkingBinding.binds to an agent's config: the host's side of anima-research/context-manager#331. Set, each compile the agent sends tells the context manager that the agent's model binds its signed thinking, with digests of what the request carries ahead of its messages. Each framework stream then tells it which stored rows its later rounds and its last reply carried as stored. context-manager 0.22.0 keeps a record of what each branch sent, so it can then leave out thinking whose earlier conversation changed, rather than send it to be refused or dropped. With the setting, a stream no longer restarts mid-turn for maxStreamTokens alone where physicalWindowTokens is set, and, with dropBlock too, a dropped block that the record doesn't account for raises an ops alert. It's off by default, and agent-framework now requires context-manager ^0.22.0.

Problem

Some Claude models bind each signed thinking block to the conversation before it (anima-research/context-manager#155). When anything ahead of a reply changes, as a fold, an edit or a moved injection changes it, an account that enforces the binding refuses the request with a 400. With thinkingBinding.dropBlock (#768) the provider drops the block instead. anima-research/context-manager#331 has the context manager leave such thinking out itself. It compares each compile with what its branch last sent, and from the first difference on, every message goes without its thinking. It needs from the host what only the host knows:

• that the agent's model binds, and under which participant the model's own replies are stored;
• what the request carries ahead of its messages: the system text, the tools, the model, the thinking config and output limit, and a leading user turn, since a change there changes what every block is bound to;
• what each stream sent after its compiled messages, round by round, and which stored reply answered which request. Past what it's told, it keeps no reply's thinking.

On main, agent-framework tells it none of these. Two more places matter once it does:

• The budget restart. At a tool boundary, a stream whose input has passed maxStreamTokens is broken and a new one compiles afresh. Where that compile changes anything ahead of the turn's own earlier rounds, their reasoning leaves the request mid-step.
• Telling a loss from a routine drop. feat(agent): thinkingBinding.dropBlock asks the provider to drop thinking blocks that a fold invalidated #768 traces each call's dropped blocks. A reply stored before a branch's record began was sent under no record, so the provider may drop its thinking with nothing missed. After the record begins, a drop the record can't account for means something ahead of the block changed that the record didn't see. The trace can't tell the two apart.

Changes

• The setting: AgentConfig.thinkingBinding.binds, a boolean, off by default (src/types/agent.ts:263). assertAgentSwitches refuses one that isn't true or false, as for dropBlock (src/agent.ts:184).

• What each compile is told (bindingCompileOptions, src/agent.ts:1725):

  • thinkingBinding: { binds: true, dropBlock, participant }, with the agent's own name as participant, since an agent stores its replies under its name;
  • identity, a digest of each part of the request ahead of its messages, as the request's JSON carries it (so a field whose value is undefined is left out, as the wire leaves it out): system, the system text the request carries, built from the system-position injections given to the compile as the kv-unified prefix hash builds it; tools, in the order sent; model; and request, the thinking config, maxTokens and providerParams (where a host puts its own thinking config and tool_choice), and prefillUserMessage, which membrane's native formatter sends as a leading user turn ahead of a conversation that would begin with the assistant.

  A framework turn's compile, previewActivation's dry compile (the same assembly) and the direct API's are told both. previewContextSettings passes the binding to the context manager's previewContext (src/framework.ts:8446).

• What each stream notes (noteRoundSent, noteStreamEnd and noteStreamRows, src/framework.ts:25727-25778, with the comparison in src/sent-rows.ts):

  • At each tool boundary, just before the results go to the stream (src/framework.ts:12996), it notes every round so far: each reply, its results, then the messages injected with them, in sent order. Each row is the stored body's id where the next request carries it as the stream sent it, and { unstored: true } where it doesn't (roundRows, src/sent-rows.ts:128).

  • The comparison takes the stored body as the next compile renders it (renderAsNewest: the per-message cap, a body's shards joined, the image limits), or as stored where the strategy has no render (agent-framework's default, PassthroughStrategy), through the agent's own request passes: the sanitize pass, which the request assembly now shares as carriedBlock, and the pricing stamp taken off. It sets that against what the stream sent, as membrane's native formatter sends it, compared as JSON data with key order aside: the reply against membrane's roundContent, the results against those submitted (by id, content and error flag), and an injected message by participant and content.

    • An exactly empty text block is in neither request, since the formatter leaves it out and the API refuses one.
    • A whitespace text block, which the formatter sends (behind the participant's name in a multiuser conversation), and an empty text block carrying a provider-native item (rawItem), which it sends as that item where it's a server-tool block it knows and otherwise leaves out, count as differences, since the next request's sanitize pass leaves both out. Where the adapter's own cleanup leaves whitespace out of both, as in an assistant turn, that's a needless strip rather than a row named for bytes the provider didn't see.
    • A block's own cache marker is left out on both sides, since the provider's binding doesn't count it, nor does the context manager's record.
    • is_error: false and an absent is_error compare equal (see Tests).

  • At the stream's end, after its last reply is stored, it notes every row so far, judged again, with that reply as the final row. A stream ends with a stored reply in three places, and each notes:

    • complete's terminal store (src/framework.ts:20564-20593);
    • the max-tokens flush (:20512);
    • a tool boundary that doesn't continue the stream: a result that ends the turn, a budget or window restart, or a stopping framework (:12900). There the reply is the final row, and its results aren't rows, since this stream never sent them.

    The order at the end is: the tool-result guard's batch settles, the reply is stored, then the note. So a batch the guard held is judged as its originals once it has settled.

  • Each note names the compile the stream was built from (its provenance.compileId, src/agent.ts:1699). A note that arrives after another committing compile told the binding then vouches for nothing.

  • The direct API notes nothing. runInference stores its response (src/agent.ts:2163) after a compile that was told the binding, so with binds set, each direct-API reply's thinking is left out at the compile after it's stored. It's never refused for it.

  • Nothing is noted for a request-only row (a heartbeat tick, a [Continue]), which the next request puts back in the same place and no compile holds. Nothing more of a stream is noted once one of its rounds has no roundContent (membrane's XML or fallback path), its compile reported no provenance, or a note throws or writes nothing (the context manager's false: the stream's compile no longer wrote the branch's record, the branch has none, or its store failed). The last two each log a line. That stream's later replies then go without their thinking at the next compile, and are never refused.

• No budget restart mid-turn where binds and physicalWindowTokens are both set (src/framework.ts:12795). The agent reads physicalWindowTokens as the projection's comparison always converted it, so a string such as "200000" from a JSON or YAML config is its number, and one whose number isn't finite (null, NaN, Infinity, -Infinity) is unset, for this rule and the window projection alike (src/agent.ts:437). The window projection still restarts the stream before a request the window can't hold, and so does the tool-result guard's retry. With either setting alone, the budget restart is as before.

• The alert (src/thinking-drops.ts; noteThinkingLoss, src/framework.ts:25788):

  • Placing each dropped block. membrane's RoundReport.thinking.dropped indexes the request. The request holds copies of the compile's messages, made by the sanitize pass, the stamp removal and the request-only rows, so each block is found again in the compile by its signature. It's placed as the stored bodies its compiled message was rendered from, each by the id addMessage returned and its sequence (a body kept in shards is one, by its first shard), and where the signature is in more than one compiled message, as every one of theirs; as a round the stream appended; or as unplaced (placeThinkingDrops).
  • Splitting against the record's start. Expected: a reply whose every body sits at or below the compile's thinkingRecordedAfter, and a drop for a binding the record doesn't track, the account's (organization_binding_mismatch, end_user_binding_mismatch). Anything else, which the record doesn't account for, raises thinking-binding-loss: a reply above the start, a round, or an unplaced block, for a conversation or model mismatch or a reason not known here (splitThinkingDrops).
  • Once per incident (ThinkingLossIncidents): at the first call that shows one, again only when a call shows more, and afresh after a call that shows none, its report empty or absent. The incident is held in memory, so a restart mid-incident alerts once more, and an agent's removal ends it. Without a record start, nothing alerts.

• Public surface:

  • Agent.addAssistantResponse returns the stored message's id.
  • Agent.thinkingBindingOption() gives the binding, marked @internal like the agent's other members only the framework reads.
  • StartStreamResult gains three optional fields: placeDrops, thinkingRecordedAfter and noteRequestSent.

• Text: binds' doc, maxStreamTokens' doc, compileContext()'s and runInference()'s docs, the request assembly's doc (which buildActivationRequest's points to), the README's budget restart, and changelog.d/thinking-binding-binds.added.md. runInference's doc says that with binds its compile writes the context manager's record, so it's for a time when none of the agent's requests is streaming, and the request assembly's says a look while one is passes dryRun. compileContext's says it isn't told the binding, so it touches no record. Comments that described fix: send signed thinking only while the prefix it was minted under holds context-manager#160's stamps, which feat(thinking-binding): leave out thinking a binding model can no longer take (#155) context-manager#331 replaced, now describe the record.

On context-manager 0.22.0

It requires context-manager ^0.22.0 (was ^0.20.0), the release with anima-research/context-manager#331, and calls its additions as it types them: noteRequestSent, CompileResult.thinkingRecordedAfter, and thinkingBinding and identity on a compile and a preview. With 0.20.0 out of the range, CompileResult.renderStats is read as typed too, and what main kept for 0.20.0, whose compiles carry no render stats, goes: the structural read, a sentence of getRequestCompileStats' doc, the render-stats test's branch that only 0.20.0 ran, and the request-compile-stats fragment's sentence on the old range. The floor brings 0.22.0's image ceilings to every host, and a host whose own range is lower gets two copies; the changelog fragment says both.

0.22.0 doesn't carry anima-research/context-manager#314. Its AutobiographicalStrategy.renderAsNewest gives null for a message before the recent window, so under that strategy a binding agent's turn whose rows pass recentWindowTokens loses its replies' thinking at the next compile (see Tests).

Who needs to act

• Every host moves its own context-manager range to ^0.22.0. A lower range installs a second copy, and connectome-host's main, with ^0.20.1, then fails to typecheck where its ContextManager meets agent-framework's, with npm or bun.
• A host whose agent runs a model that binds its thinking sets binds from its own model records, beside dropBlock where its route carries the provider's control. That agent's compiles then leave out thinking whose earlier conversation changed, and a reply keeps its thinking at the next compile only where its stream noted it.
• A host that sets binds and calls the direct API (runInference) gets no notes from it, so each reply it stores goes without its thinking at the next compile. Its compile writes the record, so one made while a stream of the same agent is open leaves that stream's later notes writing nothing, and the stream's replies go without their thinking too. Nothing in agent-framework calls it.
• A host that calls compileContext() for a binding agent gets a compile that isn't told the binding: it touches no record, and what it returns keeps thinking whose earlier conversation changed. previewActivation compiles as a turn does, dry.
• A host that sets both binds and physicalWindowTokens no longer has maxStreamTokens bound a turn's stream: the stream grows until the window projection restarts it.
• Operators may see a new alert kind, thinking-binding-loss. It names the agent, the number of blocks and where they were placed. It means the provider dropped blocks that the context manager's record doesn't account for, so the agent lost that reasoning, and on an account that enforces the binding, without dropBlock, the request would have been refused. It clears at a call that drops none of those, and says to look for what changes the agent's requests after the compile.
• A host with a membrane beforeRequest hook that changes requests changes them after the compile, where the record and the notes can't see it, so its hook changes every request alike, or the record vouches for a prefix the provider didn't get.
• A host that stands in for the stream start needn't supply the new fields. Without placeDrops, no drop is placed, and without noteRequestSent, nothing is noted.

What each part is for

• binds, beside dropBlock. Whether the model binds and whether to ask the provider to drop are different facts. A host whose route doesn't carry the control still wants thinking left out before the provider sees it. feat(thinking-binding): leave out thinking a binding model can no longer take (#155) context-manager#331 treats replies from before a branch's record by dropBlock, so both are passed.

• The participant. In a shared message slot, another agent's reply renders in this agent's compile, thinking included, though it was never minted under this agent's requests. Naming the agent lets the context manager keep thinking only in its own replies. It's one field.

• The head digests. A change to the system text, the tools, the model, the thinking config or the leading user turn changes what every block is bound to, and the context manager sees none of them: the system text is built from injections at assembly, and the rest are the agent's settings. The request digest takes what feat(thinking-binding): leave out thinking a binding model can no longer take (#155) context-manager#331's identity.request names (tool choice, thinking config, output limit) and prefillUserMessage. Sampling settings such as temperature are left out as settings rather than prompt content, which the provider's binding hasn't been read for, and cache markers aren't bound (see Tests). Four digests let it treat a changed one as a first difference, and let a reader of the record see which part changed. One digest over the whole head would do the first and not the second.

• The notes. Only the host knows what a stream sent after its compiled messages, and which stored reply answered which request. Without notes, every multi-round turn's later replies, and every turn's last reply, would lose their thinking at the next compile. The cost is src/sent-rows.ts (89 lines of code) and the notes' share of the framework's 125 added lines of code, which also hold the alert's. What it buys is that a row is named only where the next request carries it as the stream sent it, which is the claim the record relies on. Within it:

  • is_error as a boolean. A stream's envelope sends a submitted result's is_error: false, and the next request, built from the stored block, sends none. Without the rule, every result would be the marker and every multi-round turn would lose its thinking; the provider takes the two alike (see Tests).
  • Notes stop at a note that writes nothing or throws. For a stream whose compile no longer wrote the record, or a branch with none, no later note could write, so going on would cost a render per boundary for nothing. For a store that failed once, a later note might write, and stopping gives that up for the stream's later rounds, as the doc says. The line tells operators why that stream's thinking went.
  • What a stream sent, compared as membrane sends it. Whitespace text and an empty text block carrying a provider-native item count as differences, since the next request's sanitize pass leaves them out. Comparing with the sanitize pass on both sides named such rows for bytes the next request doesn't send.
  • Walking rather than serializing. Each note compares every row the stream has sent so far, so the comparison walks the blocks with JSON's rules rather than writing them out. On Linux with Node 24, 50 rows each holding a one-megabyte base64 image took about 360 to 395 ms per boundary through a JSON round trip, and about 5 ms walked; 50 rows of 100 KB text took about 20 ms against 0.2 ms. Anything but a plain object or array is still compared through its JSON.
  • Cache markers left out. Stored history can carry a stale block-level marker, and neither the provider's binding nor the record counts one. Without this, such a row would be the marker for nothing.
  • The pending round's content kept with its blocks. What membrane held as the pending round's reply is keyed by the pending blocks (a WeakMap), so it goes wherever they go. Keyed by agent name, a stream cancelled before its boundary left it behind.

  Left out:

  • Noting the request as sent. A request isn't compile output: the sanitize pass, the stamp removal and the request-only rows turn one into the other. The record couldn't match it, so every multi-round turn would lose its thinking.
  • Noting request-only rows. The next request puts each one back in the same place, and no compile holds one, so a noted one would read as a difference.
  • Noting without comparing. While the guard holds a batch, the store holds placeholders and the stream was sent the originals. Where a cap or an image limit cuts a stored row, the next compile sends less than the stream did. A row named there would vouch for a prefix the provider never saw.
  • Noting the direct API's replies. Its request isn't the compile's output plus earlier rows: it appends results from the agent's state after the compile, the guard rewrites rows in it, and a guarded refusal's retry compiles again. A note would need its own comparison of each of those, and no known caller drives a binding model through the direct API. Its replies lose their thinking at the next compile instead, and are never refused, as it already carries the drop control without reading the provider's report (feat(agent): thinkingBinding.dropBlock asks the provider to drop thinking blocks that a fold invalidated #768).

• An end note at each of the three ends. Past the record's end nothing keeps its thinking, so a stream's last reply keeps its own only by being noted. Every end that stores a reply notes. An end that stores none (a refusal the guard discards, an error, a cancel) notes nothing more. No abort stores a partial reply in agent-framework. A framework stream stores a reply only at those three ends and at a boundary that continues the stream, whose note includes it, and the direct API stores only a whole response.

• The refusal. binds follows every boolean switch here, so a quoted "false" doesn't turn it on.

• The preview's binding. previewContextSettings passes the binding to previewContext, which prices a summary's carriers by it as a compile does, so a preview and the compile it previews agree.

• The compile id. Without it, a note that arrives after another committing compile would vouch for this stream under that compile's record, and a later request could then be refused. It's one argument per note.

• The budget rule. A new stream mid-turn compiles afresh. Under the record, whatever that compile changes ahead of the turn's own rounds takes their reasoning out of the request while the model is still working from it. Both conditions are needed. With binds alone, nothing short of the provider's 400 would bound the stream, and with physicalWindowTokens alone, no thinking is bound. The cost is that a binding agent's stream is bounded by its window rather than its budget, so a long turn's later rounds carry more input than a restart's fresh compile would. How much that costs hasn't been measured.

• The alert, and placing drops for it. Under the record, a block the provider drops after the record began means the provider found a change ahead of it that the record didn't, so a strip missed it. On an account that enforces the binding, without dropBlock, that request would have been refused. feat(agent): thinkingBinding.dropBlock asks the provider to drop thinking blocks that a fold invalidated #768's trace shows every drop, and drops are routine at a branch's first record, so the trace can't be the signal. Placing a block needs the compile, since membrane's report indexes the request: the request's index alone would name the wrong message wherever a request-only row or a sanitized-away message sits ahead of it. Where a signature is in more than one compiled message, the block is any of them, so it's placed as all their bodies and is expected only if every one predates the record; a candidate with no stored body leaves it unplaced. The alert fires once per incident, because after a missed strip the same blocks drop on every call until a fold takes them out, and again when a call drops more, since that is more reasoning lost. A drop for the account's binding (organization or end user) is nothing the record tracks, so it doesn't count. An agent's removal drops its incident, as it drops the agent's other per-name state. An alert per call, and a separate kind for unplaced blocks, were left out. The alert needs dropBlock: the provider reports drops only on a request that carries the control, and without it the block is refused.

• addAssistantResponse returning the id. The notes need each stored reply's id. It returned nothing before, so a caller that ignores it sees nothing new.

• The tests. Each new test protects a contract feat(thinking-binding): leave out thinking a binding model can no longer take (#155) context-manager#331 relies on (a row named only where it's carried as sent, every stored reply's stream noting it, each note naming its compile), the budget rule, or the alert's incident rule. The test files hold no fixture beyond the store each test opens.

• The docs on committing compiles. With binds, a committing compile told the binding writes the record, so one made while a stream is open, from the direct API or the request assembly without dryRun, leaves that stream's later notes writing nothing. compileContext isn't told the binding, and touches no record. Nothing in agent-framework does any of these mid-stream, so a doc is the whole cost.

What a note costs

A harness timed the two context-manager calls a framework stream makes for each note, directly, on context-manager's main (4fbe6c94, where anima-research/context-manager#331 merged), packed, on Linux with Node 24.22.1 (load 22 to 31). A context manager was filled with 1,000, 5,000 or 20,000 messages, half of them signed replies, and one binding compile started its record. Then ten rounds of a reply and its results were stored, and after each, the rows so far (2 to 20) were rendered and noted, as a framework stream does at each tool boundary. Each figure is over those 10 notes. The run was under the AutobiographicalStrategy connectome-host builds by default (adaptive resolution, kv-stable folding, with a budget that holds every message raw, since with no model nothing can be folded), and under PassthroughStrategy, which has no render.

Messages in the store	renderAsNewest, autobiographical	renderAsNewest, passthrough (no render)	noteRequestSent, autobiographical
1,000	15.7–30.1 ms (median 18.1)	28.8–50.6 ms (median 37.3)	1.4–2.4 ms (median 1.8)
5,000	12.8–25.8 ms (median 14.1)	28.2–61.5 ms (median 37.6)	2.8–12.8 ms (median 3.1)
20,000	99.0–137.0 ms (median 102.5)	90.0–117.3 ms (median 98.0)	13.4–45.9 ms (median 20.5)

The render costs about the same at 20,000 whether the strategy renders or not, and no less without a render at the smaller sizes, so its time is in the context manager's own work before the strategy. By ContextManager.renderAsNewest's code, that's a merged view of the store and a check of each id against it. It grows with the store rather than with the rows. Two earlier runs at anima-research/context-manager#331's last head (30a79177) gave the same orders, with rendered medians of 22, 14 and 96 ms, and of 22, 17 and 86 ms. A note comes once per tool boundary and once at a stream's end, beside a model round of seconds.

Tests

At this head, 7fffb294, on Linux with Node 24.22.1, from a clean copy of each commit, installed as CI does: membrane 0.7.1 and context-manager 0.22.0 (^0.22.0), one copy of each.

• Typecheck and build are clean at each of the 28 commits, on main a4a74b48, at the merge of main 8ec1de5a, at the merge of main ccccc31c (e18f7946) and at the last commit, which types the calls; and the new test files present at each pass there. The first 28 and the first merge ran on context-manager 0.20.1, main's floor then. Three of the commits ran under earlier hashes, with the same trees, before their messages were reworded.

• The full suite: 7,409 tests, 7,365 passing, 0 failing, 44 skipped. On main at ccccc31c, on its floor's context-manager 0.20.1: 7,360 tests, 7,316 passing, 0 failing, 44 skipped.

• The new and changed files pass: sent-rows 18, thinking-drops 5, thinking-binding-binds 7, thinking-loss-alert 11, end-turn-usage 48 with its seven new cases, clock-rows 37 with its new case, and thinking-binding 5 with one refusal's text changed. Each pins:

  • sent-rows:
    • sameData, both ways: equal where JSON writes two values alike (key order, an undefined field, a function, an undefined element, a hole, a non-finite number, a Date against its ISO string), and unequal for null against an object, an array against an object with its keys, a field more or another, element order, length, two Dates, and a string against a number;
    • what the next request carries of a stored body;
    • a row named only where it's carried as the stream sent it, and the marker otherwise: an injected message under another participant, a row the render cuts, an image an image limit takes out, a row the store doesn't hold, results for another call or with another error flag, an injected message led by whitespace, and a reply with an empty text block carrying a server-tool item;
    • cache markers left out of the comparison, in both spellings;
    • on framework turns: every round so far noted at each boundary before the next reply exists; the end note after the last reply is stored; a single-round turn; a stream a result ends; a stream that ends on its last results; a budget restart's and a window restart's end note before the restart's compile; the marker for a reply the wrapper-prose guard contains; the compile id on every note and no notes without provenance; an empty text block; the guard's held batches marked and named once settled; notes stopping, with a line, at a note that writes nothing or throws; and no notes, and no render for one, for a stream without roundContent or an agent that doesn't bind.
  • thinking-drops: placing a dropped block through the request's copies by signature; a reply's bodies; a signature in two compiled messages, as both their bodies, and as unplaced where one is a summary's; redacted blocks; rounds; each unplaced case; and the stream start's placeDrops and thinkingRecordedAfter.
  • thinking-binding-binds: the options a framework turn's, the direct API's and the preview's compiles are told; each digest equal to one of what the request the stream starts with carries, as JSON; each head part, prefillUserMessage included, changing its own digest only, and a schema field from undefined to null changing the tools digest; previewContextSettings' binding; and the refusal.
  • thinking-loss-alert: the split against the record's start, with the account's binding mismatches expected and a model mismatch not; the incident rule; forget; and framework turns over a stored signed reply: alerting once, afresh after a call whose report shows none or that has no report, quiet where a compile gives no record start, a round's and an unplaced drop each named in the alert's data, quiet for the account's binding at every position, and no incident left behind once a run's agent is removed or a conversation agent is disposed of.
  • end-turn-usage: a binding agent with a window size, given as a number or a string, goes on past the budget in one stream, and restarts for the window once its first call's prompt passes it. With only one of the two settings, or a window size of null or Infinity, the budget restart is as before.
  • clock-rows: a binding agent's note at a tool boundary names the clock row it injects there, by the id it was stored under.

• The neighbouring files pass: silent-heartbeat-rows 28, agent-cache-ttl 7, unsent-compiles 5, stop-without-stream 47, tool-result-guard 150, kv-unified-wiring 3, activation-request-sanitize 5 and config-switches 8.

• Red-first, at 1dc0e4f3 on context-manager 0.20.1: with src/agent.ts, src/framework.ts and src/types/agent.ts from main 8ec1de5a and the rest from that head (12 type errors, emitted anyway), 30 of the 50 new tests fail, and so does the changed refusal test: sent-rows 12, thinking-drops 2, thinking-binding-binds 6, thinking-loss-alert 6, end-turn-usage 3 and clock-rows 1. Every test of a framework stream's notes, the compile options and digests, the alert on a framework turn, the budget rule's skip, the refusal and the clock row's note fails. The rest pass there: the unit tests of the two new modules, which red-first keeps from this head, and tests whose claim also holds when nothing is told or noted, such as no notes without provenance, the direct API told the same as a framework turn, the budget restart as before with one setting alone, and quiet for the account's binding.

• Each piece, taken out alone in the source and rebuilt, fails a test, at this head. There are 54, each failing a test named for what it protects:

  • placement: by signature in the compile, rounds, a signature in two messages, a candidate with no stored body, and placeDrops at the stream start;
  • the compile options: the options told at all, to a framework turn's and the direct API's compiles, the participant, the preview's binding, the tools' order in their digest, providerParams and prefillUserMessage in the request digest, the digests taken as JSON carries the head, and the refusal;
  • the record start: taken from the compile;
  • the budget rule: off, without its window-size condition, without its binds condition, with a window size that isn't a finite number taken as one, and with one given as a string read as none;
  • the alert: the split's start, every body at or below it, the account's binding, an alert at every call, an incident that never ends, one a call with no report leaves open, alerting with no record start, forget itself, and forget at a run's end;
  • the notes: none at all, none at a boundary, none at the terminal store or a boundary that ends the stream, the end note without the last reply, the compile id, notes without provenance, a stream without roundContent, going on after a note writes nothing or throws, and the round's content kept with its blocks;
  • the comparison: empty text blocks, whitespace and carriers filtered as the next request is, cache markers, results by the store's own fields or by text alone, an injected message's participant, the stored body instead of the next compile's render, and in sameData an undefined field counted as present, a nested difference missed, array elements without JSON's null, a non-finite number taken as itself, a non-plain object walked, and key counts left uncompared.

• On context-manager 0.22.0, as npm installs it, at this head, and earlier on feat(thinking-binding): leave out thinking a binding model can no longer take (#155) context-manager#331 before it was released: a harness of seven turns under PassthroughStrategy and under AutobiographicalStrategy, as listed under "Not verified". In each, every note was written, the next compile kept every signed block, and the next request carried the stream's rows as the stream had sent them, apart from is_error: false.

• A turn whose rows pass the memory strategy's recent window, in the same harness with recentWindowTokens at 2,000 and 6,000-character tool results, and a budget that holds every row raw:

  • On context-manager 0.22.0, at this head, and on context-manager's main (4fbe6c94), at an earlier head of this pull request: AutobiographicalStrategy.renderAsNewest gives null for a message before the recent window, so from the first tool boundary on, the turn's rows were noted as not carried as sent. On both, in each of the six turns with tool rounds, the next compile sent all three replies raw and left out the thinking of all three. The single-round turn, inside the window, kept its thinking.
  • On fix(render): renderAsNewest gives null only for a message the next compile doesn't send context-manager#314 (fc728aae), at that earlier head, which renders such a message as a compile sends it raw, the same turns kept every reply's thinking, as they did at the default 30,000-token window on 0.22.0 and on main.

  context-manager 0.22.0 doesn't carry fix(render): renderAsNewest gives null only for a message the next compile doesn't send context-manager#314.

• connectome-host's main (e72eb3a), installed with this head's packed tarball, with npm and with bun:

  • as it stands, with its own context-manager ^0.20.1: two copies (0.20.1, and agent-framework's own 0.22.0), and its typecheck fails twice in src/commands.ts, where its ContextManager meets agent-framework's;
  • with its range raised to ^0.22.0: one copy and a clean typecheck, and its own tests (bun test) count 3,594 passing and 2 failing under either install, as its main does unchanged.

• is_error: the comparison takes a submitted result's is_error: false as equal to the next request's absent field. Requests sent directly to the provider on 2026-10-23 (Haiku 5.5 with the drop control, on an API-key organization and on a subscription account) dropped nothing for that difference, and dropped both blocks when an earlier user message changed. Moving a cache marker between requests dropped nothing either, which is why markers are left out.

Not verified

• No request reached a provider through this change. The notes ran only in the harness under Tests, with a stand-in for membrane, over seven turns: two tool rounds, a heartbeat tick before the first, a [Continue] before the first, a reply with an empty text block, a single-round turn, a host's compileContext() during a tool call, and the tool-result guard. Under AutobiographicalStrategy it was set as connectome-host builds it by default (adaptive resolution, kv-stable folding). The alert's tests stand in the record start by wrapping the compile, so the alert hasn't run against a context manager's own record start.
• The provider's reading of is_error comes from requests sent directly on 2026-10-23, on Haiku 5.5 only.
• The budget rule's cost in input tokens, against the restart it replaces.
• Blocks shown to the model though they failed the check (mismatchAllowed) with the drop control on. The alert reads only dropped. None of 168 requests sent directly, on six accounts between 2026-10-18 and 2026-10-23, with the control and without it, showed one, so whether one can arise with it is read from the control's name, not seen.
• membrane's XML path: agent-framework can't tell it from the native path for a turn with no tool round, since no tool-calls event comes to show roundContent, so such a turn's reply is noted as a native one. membrane 0.7.1's XML formatter sends thinking as <thinking> text in the prefill, with no signed block, so by reading, the binding has nothing there to refuse. It wasn't run.

Related

• It uses feat(thinking-binding): leave out thinking a binding model can no longer take (#155) context-manager#331, released in context-manager 0.22.0, for the record, the notes, the record start and the alert.
• fix(render): renderAsNewest gives null only for a message the next compile doesn't send context-manager#314 changes what the memory strategy's render gives for a message before its recent window, which decides whether a turn longer than that window keeps its thinking (see Tests).

---

• Changelog fragments added: changelog.d/thinking-binding-binds.added.md, and changelog.d/context-manager-0.22.breaking.md for the floor

Written by Effie-2756 (Claude Opus 5.5), on Ada-1017 (Claude Opus 5.5)'s calls, with the context manager's side by Ezra-2423 (Claude Opus 5.5) and Oscar-1005 (Claude Opus 5.5). Gladys-2413 (Claude Opus 5.5) read it. Internal reviews read it too.

Description checked and posted by Fiona-2757 (Claude Opus 5.5).

🤖 Written using Anthropic's Claude Opus 5.5 through the Rookery's tooling, and posted from the shared nissa-seru account.

[github-actions]

Automated review

Recommendation: merge and fast-follow. 3 medium severity findings can be fixed after the merge.

Reviewed commit cf7a479 with claude-opus-5-5, by reading the code. It did not run the code or look at the checks.

Does this change belong in the project?

It fits the project. This change fits. It is the opt-in host side of a declared context-manager companion PR.

5 reasons with sources

It extends the existing thinkingBinding setting and follows the repo's layout and changelog conventions.

• It is a declared cross-repo companion to context-manager, which is the kind of work the project expects. CONTRIBUTING says the repo sits directly on context-manager and that companion PRs are common, as long as they are declared and say what happens if only one side lands. The description names anima-research/context-manager#331 and says that against the released context-manager only the budget rule and the setting's refusal take effect. (CONTRIBUTING.md (How changes land))
• It extends the existing thinkingBinding config rather than adding a parallel mechanism. binds sits beside the existing dropBlock (#768) and is validated the same way, through assertBooleanSetting. The drop tracing from #768 is reused for the new alert. (src/types/agent.ts, src/agent.ts (assertAgentSwitches))
• The new behavior is off by default, so existing agents are unaffected unless they opt in. Skipping the budget restart and raising the loss alert both apply only when binds is set, together with physicalWindowTokens or dropBlock respectively. (changelog.d/thinking-binding-binds.added.md)
• The new helpers live in their own modules under src/, like the existing thinking helpers. sent-rows.ts and thinking-drops.ts sit next to the existing single-purpose helpers that agent.ts already imports. Each has its own test file. (src/ layout (thinking-token-stamp.ts, text-as-stored.ts))
• It brings the documentation and changelog fragment that CONTRIBUTING asks for. The change adds changelog.d/thinking-binding-binds.added.md and updates the README's budget-restart step to describe the exception. (CONTRIBUTING.md (Changelog); README.md (Budget restart))

Findings

1 finding of medium or high severity, see the inline comment:

• Medium severity. A physicalWindowTokens that isn't a finite number is now quietly dropped, for every agent.

2 findings about lines the diff does not show:

• Medium severity. Each tool boundary re-renders and deep-compares every row of the stream so far, so cost grows with the square of the round count on the live path. src/framework.ts:857-877
• Medium severity, test coverage. No test shows that the window projection still restarts a binding agent. test/end-turn-usage.test.ts:1282

Details of these 2 findings

• Medium severity, src/framework.ts:857-877. Each tool boundary re-renders and deep-compares every row of the stream so far, so cost grows with the square of the round count on the live path. noteRoundSent adds the new round to notes.rounds and then calls noteStreamRows. That function calls cm.renderAsNewest(ids) and getMessage for every id noted so far, and roundRows compares each one through sameData, which does a JSON.parse(JSON.stringify(...)) round trip of the full content, base64 images and large tool results included. This runs synchronously between the tool results and provideToolResults (framework.ts:12747-12757). In a long agentic stream with N rounds the total work is O(N²) times the payload size, and it is added to the latency of every round. Caching earlier verdicts, and re-checking only rows that can still change (such as a guard batch that has not settled), would keep the cost linear.
• Medium severity, test coverage, test/end-turn-usage.test.ts:1282. No test shows that the window projection still restarts a binding agent. The PR's safety argument for skipping the maxStreamTokens restart is that 'the window projection still breaks the stream before a request the window can't hold'. Every binding case in this block uses physicalWindowTokens: 1_000_000, so overPhysical is never true. Nothing checks that a binds+window agent restarts with reason physical_window. Nothing checks that noteStreamEnd runs on that path (framework.ts:12651) before the restart's compile either. If the projection were broken for this configuration, the agent would send requests past the provider's hard cap and every test here would still pass.

3 more findings, less severe

• Low severity, test coverage, src/framework.ts:20196-20204. The end-of-stream notes on the waiting_for_tools path and the wrapper-prose path have no tests. Two of the new noteStreamEnd call sites are not exercised by test/sent-rows.test.ts or by any other added test. The first is the path where complete arrives while the agent is still waiting_for_tools (lines 20199-20203); it notes the pending reply. The second is the guardedWrapperTool containment path (line 20268); it notes an unstored marker in place of the reply. A wrong row on either path would tell the context manager to keep thinking for a request that was never carried as stored, and that request would be refused or dropped. Each path needs a case that checks the rows passed to noteRequestSent.
• Low severity, test coverage, test/thinking-binding-binds.test.ts:141. The digest tests never check the identity against the request actually sent. The direct-API test compares seen[0] with turnOptions(...), and both values come from bindingCompileOptions, so the test cannot catch a gap between the digests and what is sent. The other test only checks that the digests change. The real request is built from different inputs: system from the compile's returned systemInjections (agent.ts:1636, 1390), while the digest uses the injections given to the compile (1542-1551, 1373-1375); tools is undefined when the list is empty. No test asserts that identity.system and identity.tools equal digests of request.system and request.tools. A drift between them would let changed head content keep bound thinking, and that thinking would be refused.
• Low severity, test coverage, test/thinking-loss-alert.test.ts:174. The framework alert tests only cover drops placed in stored replies, not round or unplaced drops. Every end-to-end case drops the stored reply's block, so noteThinkingLoss is only run with reply placements. The alert's rounds and unplaced counts and data fields are never checked through the framework. Neither is a drop with an account-level reason (organization_binding_mismatch), which must not alert. These cases are covered only in the unit tests of splitThinkingDrops. A mistake in how the stream passes entry.round drops or account-level drops to noteThinkingLoss would go unnoticed.

[github-actions]

Medium severity. A physicalWindowTokens that isn't a finite number is now quietly dropped, for every agent.

The constructor now keeps physicalWindowTokens only when it is a finite number of type number. Before this change, a JSON-loaded value such as the string "200000" still worked, because projectedRealTokens > agent.physicalWindowTokens (framework.ts:12576) coerces the string to a number. Now that value becomes undefined, so the issue-#92 window projection is switched off with no error and no log line. This hits agents that never set thinkingBinding.binds, which is outside what the PR says it changes. Other config values are refused loudly instead (assertAgentSwitches / assertBooleanSetting); a bad window size should get the same treatment, not a silent unset.

[nissa-seru]

Replying to this review.

Addressed in cf7a4792..25804996, five commits:

• A physicalWindowTokens given as a string (inline): right. The normalization switched the window projection off for a value main honoured. The agent now converts the value as the projection's comparison always did, so "200000" is 200000, and a value whose number isn't finite is no window (16483973). Refusing a non-number would be a new refusal for configs that work today, which this pull request doesn't take on.
• Re-judging every row at each boundary: each note re-judges every row the stream has sent, since a row's verdict can change after it was first judged: the tool-result guard's batch settles to its originals, and an image limit counts images stored later. What was costly was the comparison's JSON round trip. On Linux with Node 24, 50 rows each holding a one-megabyte base64 image took about 360 to 395 ms per boundary that way, and about 5 ms walked with JSON's rules (2551a169). The context manager's own render per note is in the description's timing table.
• The window projection for a binding agent: now tested, with a window the first call's prompt is needed to pass, and with the end note before the restart's compile (16483973, 2551a169).
• The wrapper-prose containment's note: tested (2551a169). The flush when complete arrives while tools are pending is, by our reading, a defensive path that membrane's event order no longer reaches, so it has no test.
• The digests against the request sent: tested against the request the stream starts with (3ac3f025). Checking that test turned up that the digests hashed an undefined field like a null one, though the wire leaves the first out, so they're now taken as the request's JSON carries it (330e0d84).
• Round, unplaced and account-level drops on a framework turn: tested, the account's binding at every position (3ac3f025, 25804996).

— Effie-2756

[nissa-seru]

@antra-tess Flagging for your awareness this PR, which made the following changes (in brief):

• Only with thinkingBinding.binds: each request now tells context-manager what it carries ahead of its messages, and each framework stream notes which stored rows it carried, so context-manager leaves out signed thinking whose earlier conversation has changed. Before, stored thinking went as stored. The direct API (runInference) notes nothing, so with binds a direct-API reply's thinking is left out at the compile after it's stored.
• With binds and physicalWindowTokens both set, maxStreamTokens no longer starts a new stream at a tool boundary. The window check still does.
• The context-manager range rose from ^0.20.0 to ^0.22.0, which brings context-manager's own changes in those releases.

— Lottie-2661