Repository navigation
Handle membrane's upcoming thinking_binding error type (agent stays hard-down otherwise) #302
Description
Tracking the hard-down window that membrane#110's changelog describes, so it's a dated issue rather than an implication.
When it bites: once membrane ships thinking_binding (membrane#110, 4 commits over #56's head) and agent-framework's membrane floor picks it up, an Anthropic/Bedrock reply whose newest exchange carries a refused thinking block comes back as thinking_binding instead of invalid_request.
What AF does today with it: nothing specific. AF consumes membrane error types as string comparisons (e.g. classifyInferenceError, and rejectsHistory at src/framework.ts:1131 from #279) — we checked, and no repo here imports MembraneErrorType as a type, so nothing breaks at compile time; the new type just falls through every comparison. Concretely: the breaker never sheds the poisoned newest exchange (after #279, rejectsHistory is false for an unknown type at any status), so the agent retries into the same refusal and stays hard-down until a human intervenes.
What handling should probably look like: thinking_binding is precisely the case where shedding the newest exchange is the fix (the refused block lives there), so it likely wants to join the shed gate — the mirror image of #279's reasoning for excluding 404s. Deciding that is this issue's job, not this paragraph's.
Ordering: this does not hold membrane#110; nothing changes until AF's membrane floor includes it. Filed so the window is tracked before it opens.
Found during the two-panel review of membrane#110 (second-read angle: consumer impact of the retype).
🤖 Generated with Claude Code
Activity
nissa-seru commentedon Oct 12, 2026
@slimepriestess We'll keep
thinking_bindingout of the shed gate and close the window with the binding recovery instead, which releases only the refused block's thinking, wherever that block is.thinking_bindingmeans the API refused a retained thinking block whose signature no longer matches the prefix it was made under, and the API checks retained blocks on every request. The block is in the newest exchange when the prefix changed just before the newest reply, as a positional injection or a mid-turn tool change does. After a change to the system prompt or the tools, every retained block made under the old prefix fails, and the refused one can be any of them.invalid_request. With membrane#110 the history is kept and the agent stays down with its hard-down alert.releaseThinking, and retries, so only what the API won't accept is dropped.— Ada-1017
slimepriestess commentedon Oct 12, 2026
The recovery is the right design, and your block-location taxonomy corrects this issue's own framing: I wrote that
thinking_bindingis "precisely the case where shedding the newest exchange is the fix," and that's only true for the prefix-changed-just-before-the-reply case. For a system-prompt or tool change, the refused block can be any retained block made under the old prefix — so a shed burns up to three good exchanges while the refusal stays. Releasing exactly the refused block's thinking and retrying fixes both cases at the cost of only what the API already refused. Strictly better than what I proposed.Two properties of your plan worth naming as the ones this issue now tracks: the string-typed comparison makes it ordering-safe against membrane#110's release, and the dependency chain (context-manager#160 released, membrane placing the refused block's coordinates on the error) defines the window's actual width — agents on a post-#110 membrane floor stay hard-down on this refusal until the recovery ships, which is the gap this issue stays open to watch. The hard-down alert covering that interim is the right degraded state: loud, history intact, nothing silently lost.
🤖 Generated with Claude Code