Claude route drops a Responses provider's native encrypted reasoning, so the model loses its chain of thought every turn (Muse Spark slow starts) #6736

Client or integration

Claude Code

Area

Proxy and routing

Summary

On the translated Claude Messages → Responses route, a Responses provider's native encrypted reasoning never makes it back to the model on the next request. The routed model keeps only whatever reasoning summary it happened to emit, and usually nothing. For meta-muse/muse-spark-1.3-contributor this shows up as very slow starts on coding tasks. Each request, the model re-derives where it is from the visible transcript and re-announces readiness ("I have the shape of the work. Now checking X before editing", written 7 times in one run), then reads more before its first edit.

Where it is lost (current dev, 1a8377d):

• Outbound, Responses → Claude. src/claude/outbound.ts decodes a reasoning item's encrypted_content only as an ocxr1: envelope (streaming around line 670, non-streaming around line 915). A provider's own blob decodes to null and is discarded. When the item has summary text, the thinking block is signed with encodeReasoningEnvelope({ txt }), summary only (lines 399 and 923). When it has no summary, no thinking block is emitted at all. In our capture that was 43 of 62 Muse reasoning items; all 62 carried a native blob.
• Inbound, Claude → Responses. The body is store: false with no previous_response_id and no include: ["reasoning.encrypted_content"] (around line 430). The replayed thinking block becomes a reasoning item carrying the ocxr1:{txt} envelope, which sanitizeReasoningInputContent then strips before the upstream call. The model gets summary text at most.

Codex-shaped requests to the same provider replay the blob, and ReasoningEnvelope already round-trips another provider's opaque continuity value the same way (krc, Kiro).

Suggested fix.

• Add a field for the provider's native encrypted_content to ReasoningEnvelope, together with the provider/model that produced it.
• In outbound.ts, put a native blob into the envelope and always emit a signed thinking block for it, with empty thinking text when there is no summary.
• In inbound.ts, unwrap it back to encrypted_content when the request targets the same provider/model, and drop it otherwise. The passthrough already strips blobs on threadServingIdentityChanged.
• Send include: ["reasoning.encrypted_content"] on the translated body.

Also relevant: Meta documents a native Anthropic-format endpoint (https://api.meta.ai/v1/messages). It returns Muse's reasoning as redacted_thinking blocks that Claude Code replays verbatim. On that endpoint the same recall test below passes.

Reproduction

Recall test: put a random 8-character code in the first user message, ask the model to keep it only in its private reasoning and reply OK. Replay turn 1 with the code replaced by [removed], then ask for the code in turn 2.

The code never appeared in any visible text or summary.

Field data from our worker transcripts (Claude Code subagents, same harness and prompts), minutes from the brief to the first file edit:

Muse also reports reasoning tokens on only about 10–18% of Claude-route requests in usage.jsonl, while every Codex-shaped request in our test reasoned. We haven't confirmed whether that is a consequence of the lost continuity or a separate cause.

Version

2.76.0 installed; the same code is on dev at 1a8377d (2026-10-08)

Operating system

macOS 26.6.2 (arm64)

Provider and model

meta-muse / muse-spark-1.3-contributor (Coding Plan OAuth). The loss happens in the Claude translation, so any Responses provider that returns native encrypted_content is affected.

Logs or error output

No response

Screenshots and supporting files

No response

Redacted configuration

claudeCode.stabilizePromptCache: true, desktopMode: "first-party". Muse was just as slow on 2026-09-27 and 09-28, before stabilizePromptCache was turned on.

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.