Mid-conversation tool changes (beta, 2026-07-24) could remove the restart from add_skill/remove_skill — and with it a whole hazard family

[olegbrok]

What shipped

Claude Platform release notes, 2026-07-24: mid-conversation tool changes are in beta on Claude Fable 5, Mythos 5, Opus 4.8 and Opus 5 — add or remove tools between turns of a conversation while preserving the prompt cache, via the mid-conversation-tool-changes-2026-07-01 beta header. The Python SDK gained the matching surface in anthropic-sdk-python v0.120.0 (2026-07-24): "add tool addition/removal blocks and tool_change events."

Why this matters here specifically

Skill changes currently require a session restart. From src/pinky_self/server.py:1791 and :1828:

"Equip a skill and restart to activate its tools."
"Unequip a skill and restart to deactivate its tools."

That restart is the trigger for our single largest hazard family. Every one of these is a restart-boundary defect:

issue	what the restart costs
#747	queued scheduler wakes silently lost across restart
#943 → #945	wedged-REPL force-restart discards the dispatch deque
#953 → #954	composer Enter-loss on the re-pasted wake
#966	delivery-receipt false negatives around turn boundaries
#946	context_status serves the dead session's usage for ~3 min

Plus the unticketed cost: the agent loses working context and has to reload from save_my_context.

So "add a skill" currently means "accept a restart," and a restart means "roll the dice on the hazard family above." If tools can change between turns, an entire class of restarts stops being necessary — not mitigated, not made safer, simply not triggered. That is a better outcome than any fix to the restart path itself.

The open question — check this first

We have no beta-header plumbing at all today. grep -rnE "ANTHROPIC_BETA|anthropic-beta|betas=" src/ --include="*.py" returns nothing. Our agents run through Claude Code and the Agent SDK rather than raw Messages API calls, so the real question is not "does the API support this" (it does) but "does our harness expose a way to pass the beta header and to mutate the tool set mid-session?"

That is the first thing to establish, and it may kill the idea outright. Do not start on the skill-swap logic before it is answered.

Suggested order:

1. Determine whether the Agent SDK / Claude Code path can send mid-conversation-tool-changes-2026-07-01 and drive tool add/remove mid-session. If it can't, close this and revisit when it can.
2. If it can, prototype add_skill on one agent without a restart, and verify the prompt cache actually survives — the cache preservation is most of the value, and a tool change that busts the cache on a 1M-context Opus 5 session is a real cost, not a neutral one.
3. Only then consider remove_skill, which is the riskier direction: removing a tool mid-session while a turn may be mid-flight needs its own thinking about in-flight calls to the removed tool.

Not claimed

I have not verified that the Agent SDK exposes this. I have verified the API supports it, that the SDK has the request/event types, that our skill tools restart today, and that we have no beta-header path. The rest is the investigation this issue is asking for.

---

🤖 Filed by Barsik

[olegbrok]

Open question answered — not reachable today. Blocked upstream, not on our plumbing.

I said the first thing to establish was whether our harness can pass the beta header and drive tool mutation, and that it might kill the idea. It does, for now. Evidence, checked against the packages themselves rather than the docs:

1. The beta cannot be named. In the installed SDK and in the newest published one:

claude_agent_sdk/types.py:30:  SdkBeta = Literal["context-1m-2025-08-07"]

That is the complete set — one value, in 0.1.81 (installed here) and in 0.2.128 (latest on PyPI). mid-conversation-tool-changes-2026-07-01 is not among them.

2. There is nothing to drive even if it were. Grepping both versions for tool_change, add_tool, remove_tool, set_tools, update_tools, mid-conversation: no matches in either. The SDK has no surface for mutating a session's tool set between turns.

3. The beta transport does exist, which is the one encouraging detail. _internal/transport/subprocess_cli.py:

if self._options.betas:
    cmd.extend(["--betas", ",".join(self._options.betas)])

That is a plain string join onto a CLI flag, so SdkBeta is a type constraint rather than a runtime one — an arbitrary beta string would reach Claude Code past the type checker. But a header with no API behind it is inert: there is no call to add or remove a tool mid-session, so nothing would change. Passing it would be cargo-culting, not enabling. Don't.

Consequence

Keep this open as a watch item, don't work it. The blocker is Agent SDK support for tool mutation, which does not exist at any published version. When tool_change or an equivalent appears in the SDK changelog, this becomes a real piece of work and the motivation in the original post is unchanged — removing the restart from add_skill/remove_skill still deletes the trigger for our largest hazard family.

Recheck trigger: an SDK release whose notes mention tool addition/removal or tool_change. anthropic-sdk-python already has the request/event types (v0.120.0), so the API side is done; it is claude-agent-sdk that has to catch up.

Incidental finding, relevant to #852

We import claude-agent-sdk 0.1.81; latest is 0.2.128, and pyproject already floors at >=0.2.82. That gap is #852's subject and this changes nothing about its merits — but it does remove one false motivation for the upgrade: upgrading would not unlock mid-conversation tool changes. Worth knowing so the two don't get bundled and the upgrade isn't sold on a benefit it doesn't deliver.

---

🤖 Barsik