Token usage always shows 0 when using @ai-sdk/openai with custom baseURL (Responses API)

[xialeistudio]

Description

When using @ai-sdk/openai with a custom baseURL pointing to an OpenAI-compatible proxy, the status bar always displays 0% used and $0.00 spent. Token usage is never tracked despite the upstream API returning valid usage data.

Configuration

{
  "provider": {
    "my-provider": {
      "npm": "@ai-sdk/openai",
      "options": {
        "baseURL": "https://my-proxy.example.com/v1"
      },
      "models": {
        "gpt-5.4": {
          "name": "gpt-5.4"
        }
      }
    }
  }
}

Steps to Reproduce

1. Configure @ai-sdk/openai with a custom baseURL
2. Start a conversation with any model
3. Observe the status bar — token usage and cost remain at 0

Verification

I verified the upstream API returns valid usage data in both non-streaming and streaming modes.

Non-streaming response (excerpt)

{
  "usage": {
    "input_tokens": 18,
    "input_tokens_details": { "cached_tokens": 0 },
    "output_tokens": 13,
    "output_tokens_details": { "reasoning_tokens": 0 },
    "total_tokens": 31
  }
}

Streaming — response.completed event (excerpt)

{
  "type": "response.completed",
  "response": {
    "status": "completed",
    "usage": {
      "input_tokens": 18,
      "input_tokens_details": { "cached_tokens": 0 },
      "output_tokens": 13,
      "output_tokens_details": { "reasoning_tokens": 0 },
      "total_tokens": 31
    }
  }
}

Both were tested via Postman against the same proxy endpoint. The usage field is present and correctly populated.

Expected Behavior

OpenCode should parse the usage field from the response.completed SSE event (streaming) or the response body (non-streaming) and reflect it in the status bar.

Actual Behavior

Status bar shows 0% used / $0.00 spent regardless of actual token consumption. Auto-compaction based on context usage may also be affected.

Notes

• This is specific to @ai-sdk/openai (Responses API, /v1/responses). The existing fix for @ai-sdk/openai-compatible (includeUsage: true, see Context usage count is always 0 for some local openai-compatible providers #423) does not apply here, as the Responses API uses a different streaming format (response.completed event vs stream_options).
• The proxy correctly follows the OpenAI Responses API spec.

Environment

• OS: macOS
• OpenCode: latest

[mengfanbo123]

Same issue with Zhipu (智谱) Coding Plan API

I'm experiencing the exact same issue with Zhipu's Coding Plan endpoint using @ai-sdk/openai-compatible.

Config

"zhipu-coding-plan": {
  "npm": "@ai-sdk/openai-compatible",
  "options": {
    "apiKey": "{env:ZHIPU_API_KEY}",
    "baseURL": "https://open.bigmodel.cn/api/coding/paas/v4"
  }
}

Key observations

1. API returns valid usage data — I verified with direct curl:

Non-streaming:

{
  "usage": {
    "completion_tokens": 15,
    "prompt_tokens": 6,
    "total_tokens": 21,
    "prompt_tokens_details": {"cached_tokens": 5},
    "completion_tokens_details": {"reasoning_tokens": 1}
  }
}

Streaming (last chunk before [DONE]):

{
  "usage": {
    "prompt_tokens": 6,
    "completion_tokens": 212,
    "total_tokens": 218,
    "prompt_tokens_details": {"cached_tokens": 5},
    "completion_tokens_details": {"reasoning_tokens": 167}
  }
}

2. Same SDK, different baseURL, different result — I have another provider using the same @ai-sdk/openai-compatible SDK pointing to Zhipu's international endpoint (https://open.bigmodel.cn/api/paas/v4), and context %used displays correctly there (~44-59%). The only difference is the baseURL path (/api/coding/paas/v4 vs /api/paas/v4).

3. Session I/O shows correctly — The right panel shows 44K in / 166 out correctly, but the top bar Context: 0% used stays at zero.

4. OpenCode version: v1.14.37 (latest as of 2026-05-05), issue persists after update.

Hypothesis

The Coding Plan endpoint (/api/coding/paas/v4) may return a slightly different response structure (e.g., missing or extra fields in the streaming SSE format) that causes the @ai-sdk/openai-compatible SDK to not extract the usage data correctly. The non-coding endpoint works fine with the same SDK.