Skip to content

Bug: agent maxTokens forwarded raw (camelCase) instead of translated to max_tokens for custom @ai-sdk/openai-compatible providers #40151

Closed as not planned

Description

@mateuszhoffman

Summary

When an agent config sets maxTokens, OpenCode forwards it raw and untranslated (literal camelCase maxTokens) into the outbound JSON request body for a custom @ai-sdk/openai-compatible provider. The upstream endpoint (Azure AI Foundry / Fireworks-hosted models) rejects this with a strict-schema validation error, since it expects the OpenAI-standard snake_case max_tokens field instead.

This affects any custom npm: "@ai-sdk/openai-compatible" provider pointed at an endpoint with strict request validation (e.g. Azure AI Model Inference API routes).

Environment

  • OpenCode version: 1.18.11 (also reproduced conceptually against v2 beta docs/behavior, not yet independently verified there)
  • OS: macOS (darwin)
  • Provider: Custom @ai-sdk/openai-compatible provider pointed at Azure AI Foundry (Fireworks-hosted models: Kimi K3, DeepSeek V4, etc.)

Repro config (opencode.json, abbreviated)

{
  "agent": {
    "generalist": {
      "model": "azurefoundry/FW-Kimi-K3",
      "maxTokens": 12000
    }
  },
  "provider": {
    "azurefoundry": {
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "apiKey": "{env:AZURE_FOUNDRY_API_KEY}",
        "baseURL": "https://<resource>.services.ai.azure.com/models",
        "queryParams": { "api-version": "2024-05-01-preview" },
        "headers": { "api-key": "{env:AZURE_FOUNDRY_API_KEY}" }
      },
      "models": {
        "FW-Kimi-K3": {
          "modelID": "fw-kimi-k3",
          "name": "Kimi K3 (Microsoft Foundry)"
        }
      }
    }
  }
}

Steps to reproduce

opencode run --model azurefoundry/FW-Kimi-K3 "Say OK"

Actual result

Error: Extra inputs are not permitted, field: 'maxTokens', value: 12000

Expected result

The request should succeed, with maxTokens translated to the provider's expected field name (max_tokens) — or simply not being forwarded literally into the request body at all for providers/packages that don't recognize the raw config key.

Isolation / verification performed

I verified this is an OpenCode-side bug, not an endpoint/auth issue, by sending the raw HTTP requests directly with curl:

Works (no max_tokens field):

curl --url 'https://<resource>.services.ai.azure.com/models/chat/completions?api-version=2024-05-01-preview' \
  -H 'content-type: application/json' \
  -H "api-key: $AZURE_FOUNDRY_API_KEY" \
  --data-raw '{"model":"fw-kimi-k3","stream":false,"messages":[{"role":"user","content":"Say OK"}]}'
# -> 200 OK

Works (snake_case max_tokens):

curl ... --data-raw '{"model":"fw-kimi-k3","stream":false,"max_tokens":12000,"messages":[...]}'
# -> 200 OK

Fails (camelCase maxTokens — matches what OpenCode sends):

curl ... --data-raw '{"model":"fw-kimi-k3","stream":false,"maxTokens":12000,"messages":[...]}'
# -> 400 {"error":{"message":"Extra inputs are not permitted, field: 'maxTokens', value: 12000"}}

This confirms OpenCode is sending the literal maxTokens key (from the agent's config field name) directly in the request body, rather than mapping it to the AI-SDK/OpenAI-standard max_tokens parameter, for this provider package path.

Workaround

Removing the agent-level maxTokens field entirely allows the request to succeed. This is not scoped per-provider/per-model, so it removes the output-token cap globally for the agent across all models, which is not ideal.

Suggested fix

Translate agent/model maxTokens config into the standard max_tokens (or package-appropriate) field name before merging into the outbound request body for @ai-sdk/openai-compatible (and similar) provider packages, instead of forwarding the raw config key verbatim.

Related issues that may share root cause:

Activity

  1. github-actions commented on Aug 2, 2026

    @github-actions
    Contributor

    This issue might be a duplicate of or related to existing issues. Please check:

    (You've already linked #32776 and #2055, which are also relevant.)

  2. github-actions commented on Oct 2, 2026

    @github-actions
    Contributor

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions