Problem
All 4 MiniMax providers (minimax, minimax-cn, minimax-coding-plan, minimax-cn-coding-plan) use npm = "@ai-sdk/anthropic" in their provider.toml. However, @ai-sdk/anthropic sends the API key via the x-api-key header, while MiniMax's Anthropic-compatible endpoints require Authorization: Bearer <key>.
This causes HTTP 401 errors:
login fail: Please carry the API secret key in the 'Authorization' field of the request header, using the 'Bearer' authentication scheme.
Affected providers
| Provider |
Endpoint |
minimax |
https://api.minimax.io/anthropic/v1 |
minimax-cn |
https://api.minimaxi.com/anthropic/v1 |
minimax-coding-plan |
https://api.minimax.io/anthropic/v1 |
minimax-cn-coding-plan |
https://api.minimaxi.com/anthropic/v1 |
Root cause
@ai-sdk/anthropic always sends authentication via x-api-key header (the Anthropic standard). MiniMax's Anthropic-compatible endpoint does not accept x-api-key — it requires the standard Authorization: Bearer <token> format instead.
Prior art
This is a well-known issue across the ecosystem:
- LiteLLM #24493 — fixed by adding Bearer auth
- OpenClaw #29095 — same fix
- Charmbracelet/Crush #2222 — same fix
Possible solutions
-
Client-side workaround (what we did in opencode): detect minimax in the provider ID and inject Authorization: Bearer header alongside the SDK's x-api-key.
-
Schema enhancement in models.dev: Add an optional auth or auth_type field to the Provider schema (e.g., auth_type = "bearer" vs auth_type = "api-key") so clients know which auth mechanism a provider expects. This would make the fix data-driven instead of requiring hardcoded provider checks in every client.
-
Static headers in provider.toml: The schema already supports provider.headers on models, but this can't be used for dynamic auth tokens (it's for static key-value pairs).
Option 2 would be the cleanest long-term solution, enabling any Anthropic-compatible provider that uses Bearer auth to declare it in their TOML config.
Problem
All 4 MiniMax providers (
minimax,minimax-cn,minimax-coding-plan,minimax-cn-coding-plan) usenpm = "@ai-sdk/anthropic"in theirprovider.toml. However,@ai-sdk/anthropicsends the API key via thex-api-keyheader, while MiniMax's Anthropic-compatible endpoints requireAuthorization: Bearer <key>.This causes HTTP 401 errors:
Affected providers
minimaxhttps://api.minimax.io/anthropic/v1minimax-cnhttps://api.minimaxi.com/anthropic/v1minimax-coding-planhttps://api.minimax.io/anthropic/v1minimax-cn-coding-planhttps://api.minimaxi.com/anthropic/v1Root cause
@ai-sdk/anthropicalways sends authentication viax-api-keyheader (the Anthropic standard). MiniMax's Anthropic-compatible endpoint does not acceptx-api-key— it requires the standardAuthorization: Bearer <token>format instead.Prior art
This is a well-known issue across the ecosystem:
Possible solutions
Client-side workaround (what we did in opencode): detect
minimaxin the provider ID and injectAuthorization: Bearerheader alongside the SDK'sx-api-key.Schema enhancement in models.dev: Add an optional
authorauth_typefield to theProviderschema (e.g.,auth_type = "bearer"vsauth_type = "api-key") so clients know which auth mechanism a provider expects. This would make the fix data-driven instead of requiring hardcoded provider checks in every client.Static headers in provider.toml: The schema already supports
provider.headerson models, but this can't be used for dynamic auth tokens (it's for static key-value pairs).Option 2 would be the cleanest long-term solution, enabling any Anthropic-compatible provider that uses Bearer auth to declare it in their TOML config.