fix(opencode): route SAP AI Core reasoning variants through modelParams

[jerome-benoit]

Issue for this PR

Closes #30481

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

The SAP provider's Zod schema strips unknown top-level keys, so opencode's reasoningEffort / thinking / thinkingConfig variants for SAP-hosted models never reached the wire. Only modelParams (Zod catchall) is forwarded verbatim by the SAP SDKs.

Routes reasoning variants through modelParams using upstream-native REST field names where SAP supports granular tiers, with a harmonized reasoning_effort fallback elsewhere:

• GPT (Azure OpenAI): reasoning_effort via openaiReasoningEfforts (inherits gpt-5.x sub-families and date-gated none / xhigh / minimal).
• Claude (AWS Bedrock): thinking + output_config.effort adaptive (Opus 4.6+ / Sonnet 4.6+, with display: "summarized" for Opus 4.7+); thinking: { type: "enabled", budget_tokens } non-adaptive. Adaptive shape per AWS Bedrock adaptive thinking docs.
• Gemini 2.5 (Vertex AI): thinkingConfig: { thinkingBudget, includeThoughts } via a new googleThinkingVariants helper shared with native @ai-sdk/google[/-vertex]. Pro 32k / Flash 24k via googleThinkingBudgetMax.
• Gemini 3+, Cohere reasoning, Sonar deep-research, future reasoning models: harmonized reasoning_effort: low|medium|high fallback. SAP orchestration translates server-side; FM proxies pass through. Required for Gemini 3+ because the SAP vertexai.py harmonizer reads only thinkingBudget and drops thinkingLevel.
• Drive-by: @ai-sdk/gateway Google 2.5 max budget unified with googleThinkingBudgetMax (was hardcoded 24576).

Behavioral change: variant overrides under providerOptions['sap-ai-core'] now reach the wire; SAP users previously got no reasoning at all.

How did you verify your code works?

bun test packages/opencode/test/provider/transform.test.ts
bun typecheck

241/241 tests pass (459 expects), typecheck clean. Tests use real SAP fixture IDs (gpt-5, gpt-5-mini, gpt-5-nano, gpt-5.4, gemini-2.5-pro, gemini-2.5-flash, gemini-3.1-flash-lite, anthropic--claude-4.5-opus, cohere--command-a-reasoning, sonar-deep-research) and assert the modelParams envelope on every effort variant. Wire passthrough across both orchestration and foundation-models API modes is validated by @jerome-benoit/sap-ai-provider-v2's parametrized test "should preserve unknown parameters" (sap-ai-language-model.test.ts:4912-4979).

Screenshots / recordings

N/A.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[rekram1-node]

can we follow style guide here prefer inlining things that arent used multiple times

[jerome-benoit]

Thanks — addressed in ab87638bd. Inlined the last SAP-specific single-use helper (sapAnthropicReasoningParams).

Recap of the multi-use helpers I kept:

• wrapInSapModelParams — 3 call sites in the SAP case (otherwise Object.fromEntries(Object.entries(...).map(...)) would repeat 3×)
• googleThinkingVariants — 2 call sites, shared between @ai-sdk/google[/-vertex] and SAP, so SAP automatically inherits future Gemini versions handled by googleThinkingLevelEfforts / googleThinkingBudgetMax.

Other single-use helpers from the original commit (sapGeminiReasoningParams, sapOpenaiReasoningParams) were removed in e97a3d2a4 (folded into the shared helper / inlined respectively).

[rekram1-node]

High: remove the max variant for SAP-routed Claude Sonnet 4.6  
File: packages/opencode/src/provider/transform.ts:981 (https://github.com/anomalyco/opencode/pull/30482/files#diff-59de659bca343c2cc4566be8d80288995f51430778081b42614f91e6707dc455R981)  
anthropicAdaptiveEfforts() includes max for Sonnet 4.6, and this branch now forwards it as modelParams.output_config.effort: "max". SAP routes these Claude models through AWS Bedrock. AWS documents max as Claude Opus 4.6-only and states that using it on other models returns an error. Selecting the new max variant for anthropic--claude-sonnet-4-6 will therefore produce a rejected request. Restrict Sonnet 4.6 to low, medium, and high, while retaining max for Opus 4.6.

Medium: do not expose low and medium for the Cohere fallback without verified SAP translation  
File: packages/opencode/src/provider/transform.ts:1005 (https://github.com/anomalyco/opencode/pull/30482/files#diff-59de659bca343c2cc4566be8d80288995f51430778081b42614f91e6707dc455R1005)  
The generic fallback adds reasoning_effort: low | medium | high to cohere--command-a-reasoning. SAP publicly describes this model as OpenAI-SDK-based, but Cohere’s official OpenAI compatibility API supports only none and high; it explicitly rejects low and medium. The PR description claims SAP translates these values server-side, but the tests only assert object construction and do not verify SAP service acceptance. Either restrict Cohere to documented tiers or add evidence from a real SAP orchestration request that SAP harmonizes all three values successfully.

review bot feedback, acccurate?

[jerome-benoit]

review bot feedback, acccurate?

SAP AI Core do the sanitization needed at routing the request to a given provider.
The same goes for the final fallback for harmonized thinking level: the payload is build given the targeted model/api provider

So I've chosen to expose the largest tunables surface that OpenCode offer for variants and SAP AI Core.