feat(thinking): support Claude output_config.effort parameter (Opus 4.6)

[kaitranntt]

Summary

Anthropic's Messages API now includes output_config.effort as a top-level parameter for controlling overall token spend. This is separate from thinking.type: "adaptive" (which was added in 938a799) and is currently silently dropped by all translators.

Context

With Opus 4.6, Anthropic recommends combining output_config.effort with thinking.type: "adaptive" for optimal behavior:

{
  "model": "claude-opus-4-6",
  "messages": [...],
  "thinking": {"type": "adaptive"},
  "output_config": {"effort": "medium"}
}

• thinking.type: "adaptive" → Controls when Claude thinks (already handled by 938a799)
• output_config.effort → Controls overall token spend including text, tool calls, AND thinking depth

Claude Code sends output_config.effort when users adjust the effort slider (/model UI or CLAUDE_CODE_EFFORT_LEVEL env var).

Reference: https://platform.claude.com/docs/en/build-with-claude/effort

Current Behavior

1. Claude Code sends output_config: {effort: "low"} + thinking: {type: "adaptive"}
2. extractClaudeConfig() in internal/thinking/apply.go only checks thinking.type and thinking.budget_tokens
3. output_config.effort is silently dropped
4. All requests resolve to thinkingLevel: "high" regardless of user's effort setting

Expected Behavior

output_config.effort should be extracted and mapped through the existing centralized thinking pipeline:

output_config.effort	Expected mapping
low	Low thinking level / small budget
medium	Medium thinking level / moderate budget
high	High thinking level (current default)
max	XHigh / max budget (Opus 4.6 only)

The existing reasoning_effort → level/budget conversion pipeline already handles this mapping — it just needs a new extraction point in extractClaudeConfig().

Affected Users

All users routing Claude Code through CLIProxy with Opus 4.6 — effort slider has no effect.

Effort Levels (from Anthropic docs)

Level	Description
max	Maximum capability, no constraints. Opus 4.6 only — errors on other models
high	Default. Complex reasoning, agentic tasks
medium	Balanced token savings
low	Most efficient. Speed/cost optimized

"For Claude Opus 4.6, effort replaces budget_tokens as the recommended way to control thinking depth. While budget_tokens is still accepted on Opus 4.6, it is deprecated and will be removed in a future model release."

Suggested Implementation

In extractClaudeConfig() (internal/thinking/apply.go:351), check output_config.effort before falling through to thinking.budget_tokens:

// Check output_config.effort (Opus 4.6+ recommended format)
if effort := gjson.GetBytes(body, "output_config.effort"); effort.Exists() {
    value := effort.String()
    if value == "none" {
        return ThinkingConfig{Mode: ModeNone, Budget: 0}
    }
    return ThinkingConfig{Mode: ModeLevel, Level: ThinkingLevel(value)}
}

This feeds into the existing ValidateConfig → provider Apply pipeline, which already converts levels to budgets for budget-based providers (Gemini, Antigravity).

[pidgeon777]

Great suggestion, this is why I got many errors (thinking budget was missing for Opus 4.6).

[edxeth]

Additional Context & Reproduction (v6.8.35)

Hey @luispater — adding some findings that expand on this issue. Beyond output_config.effort being silently dropped, there are two additional gaps in the adaptive thinking pipeline:

1. extractClaudeConfig() doesn't recognize "adaptive" at all

In internal/thinking/apply.go (lines 351-376), the core parser only handles "disabled" and "enabled". When thinking.type: "adaptive" is sent, it falls through to an empty ThinkingConfig{}:

func extractClaudeConfig(body []byte) ThinkingConfig {
    thinkingType := gjson.GetBytes(body, "thinking.type").String()
    if thinkingType == "disabled" { ... }
    if budget := gjson.GetBytes(body, "thinking.budget_tokens"); budget.Exists() { ... }
    if thinkingType == "enabled" { ... }
    return ThinkingConfig{} // ← "adaptive" falls through here
}

This means the centralized thinking pipeline has no awareness of "adaptive" — any handling is entirely in individual translators.

2. All 5 translators hardcode "adaptive" to a fixed level

Every translator maps "adaptive" to a single hardcoded value, ignoring output_config.effort entirely:

Translator	File	Hardcoded Value
Antigravity	antigravity_claude_request.go:449-453	thinkingLevel: "high"
Gemini	gemini_claude_request.go:164-168	thinkingLevel: "high"
Gemini-CLI	gemini-cli_claude_request.go:183-187	thinkingLevel: "high"
OpenAI	openai_claude_request.go:78-81	reasoning_effort: "xhigh"
Codex	codex_claude_request.go:233-236	reasoning_effort: "xhigh"

Reproduction (v6.8.35, localhost:8317)

Both of these requests produce identical behavior — output_config.effort has zero effect:

# Without effort
curl -s http://localhost:8317/v1/messages \
  -H "x-api-key: <key>" -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model":"claude-opus-4-6-thinking","max_tokens":100,"thinking":{"type":"adaptive"},"messages":[{"role":"user","content":"Say hello"}]}'

# With effort=medium (silently ignored)
curl -s http://localhost:8317/v1/messages \
  -H "x-api-key: <key>" -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model":"claude-opus-4-6-thinking","max_tokens":100,"thinking":{"type":"adaptive"},"output_config":{"effort":"medium"},"messages":[{"role":"user","content":"Say hello"}]}'

Both resolve to thinkingLevel: "high" internally. The adaptive thinking benefit of skipping thinking at lower effort levels is lost.

Suggested fix scope

As your issue describes, the fix in extractClaudeConfig() should work. Specifically:

1. Check output_config.effort before thinking.budget_tokens
2. Handle "adaptive" as a recognized thinkingType
3. Remove the hardcoded mappings from all 5 translators — let the centralized pipeline handle it

This aligns with Anthropic deprecating budget_tokens on Opus 4.6 / Sonnet 4.6 in favor of adaptive + effort.

Environment: CLIProxyAPI v6.8.35, OpenCode 1.2.15, Linux (WSL2)

[luispater]

Thanks for the report — output_config.effort is already supported in the current codebase.

• Extraction: internal/thinking/apply.go extractClaudeConfig() reads output_config.effort when thinking.type is adaptive/auto.
• Application: internal/thinking/provider/claude/apply.go applies ModeLevel by setting thinking.type=adaptive and output_config.effort=<level>.
• Coverage: test/thinking_conversion_test.go includes Claude 4.6 effort handling (e.g. C22/C23) and unsupported-level validation.

If you are still seeing the effort slider ignored, please share the CLIProxyAPI version/commit you are running and a minimal repro request JSON. Note: effort=max is only valid on Opus 4.6; Sonnet 4.6 supports low/medium/high.