[BUG] Claude Fable 5 / Mythos 5 fail with 400 on thinking.type.disabled (adaptive-thinking-only models)

[devinoldenburg]

Describe the bug

Claude Fable 5 (claude-fable-5, GA 2026‑06‑09) and Claude Mythos 5 (claude-mythos-5) are adaptive‑thinking‑only models: thinking is always on, and thinking: { type: "disabled" } is rejected by the Messages API.

Through this plugin's OAuth path, Fable 5 works fine for normal requests (thinking unset → adaptive). But the moment the outgoing body carries thinking: { type: "disabled" } — which OpenCode emits for a "no‑thinking" model variant / reasoning toggled off — every request to these models fails:

HTTP 400 invalid_request_error
"thinking.type.disabled" is not supported for this model. Thinking defaults
to adaptive mode when not specified; use "thinking.type.enabled" with
"budget_tokens" for extended thinking.

Opus/Sonnet/Haiku are unaffected (they support disabled thinking), so this is specific to the Fable/Mythos line.

To Reproduce

1. Authenticate with Claude Pro/Max (OAuth) via this plugin.
2. Select anthropic/claude-fable-5 (it's already in the models.dev catalog) using a "no‑thinking" variant, i.e. a request where the body sets thinking: { type: "disabled" }.
3. Send any message.
4. See the 400 invalid_request_error above. The request never reaches the model.

Verified directly against api.anthropic.com through the plugin's own request transform using a Pro/Max OAuth token:

• claude-fable-5 + thinking: { type: "disabled" } → 400
• claude-fable-5 + thinking unset → 200 (adaptive)
• claude-fable-5 + thinking: { type: "enabled", budget_tokens } → 200
• claude-opus-4-8 + thinking: { type: "disabled" } → 200 (control; non‑adaptive models are fine)

Expected behavior

Selecting Fable 5 / Mythos 5 should work in every OpenCode reasoning configuration, the same way Opus/Sonnet do. A thinking: { type: "disabled" } block (which the model cannot honor) should not hard‑fail the request — it should fall back to the model's default adaptive thinking.

Environment

• Plugin: @ex-machina/opencode-anthropic-auth@1.8.1
• OpenCode: 1.16.2
• Auth: Claude Pro/Max OAuth (subscription) path
• OS: Linux
• (CLI plugin — browser/smartphone fields N/A)

Additional context

Root cause: rewriteRequestBody passes the thinking block straight through, and the Fable/Mythos models reject type: "disabled".

Proposed fix: when the target model is adaptive‑thinking‑only (match claude-fable- / claude-mythos- ID prefixes), drop an unsupported thinking: { type: "disabled" } block so the request succeeds with the model's default adaptive thinking. Leave enabled thinking and unset thinking untouched; never touch non‑adaptive models.

I have a branch with the fix + unit tests + README + changeset (full suite green, live‑verified that the disabled‑thinking case returns 200 after the patch). PR incoming.

References:

• Introducing Claude Fable 5 and Claude Mythos 5 — https://docs.anthropic.com/en/docs/about-claude/models/introducing-claude-fable-5-and-claude-mythos-5
• Adaptive thinking — https://docs.anthropic.com/en/docs/build-with-claude/adaptive-thinking

---

_{I cleared ~/.cache/opencode and confirmed the behavior on the latest published version before filing.}

[eXamadeus]

I literally can't select a non-thinking variant. All of the below options worked when I tried it. Do you have a custom variant you are managing in your config?

[devinoldenburg]

I literally can't select a non-thinking variant. All of the below options worked when I tried it. Do you have a custom variant you are managing in your config?

I dug more into this and I think I mixed two things together.

The API-level behavior is real: Fable/Mythos reject thinking: { type: "disabled" } with a 400. But I tested the actual OpenCode path more carefully, including a custom off variant, and OpenCode 1.16.2 still sends thinking unset for Fable. So I don't currently have a stock OpenCode repro where the disabled block reaches the API.

So this PR is probably only defensive hardening, not a fix for the issue Hugo is seeing. Hugo's case sounds more like Fable returning a refusal / empty response or just getting very slow on longer context.

I'm fine closing this PR if you don't want defensive handling here. Sorry for the confusion, I should have separated the API behavior from the actual OpenCode behavior earlier.

[eXamadeus]

Let's keep it open for a bit and see how this rolls out. I would rather not put in defensive hardening, since this REALLY should be something that OpenCode should fix upstream, but I'm OK keeping it around in case we see this happening in mass (we can fix it temporarily until OpenCode solves it properly).

I still have no idea what's happening to poor Hugo. But it does seem like Fable itself is wonky.

Regardless I appreciate the PR and the effort. Let's keep an eye on it 😄

[eXamadeus]

Fable access has been suspended for the public: https://www.anthropic.com/news/fable-mythos-access

I'll close this out, since it's no longer relevant and the APIs will potentially change by the time it becomes commercially available again. Thanks for the input and effort @devinoldenburg!