Skip to content

Commit b0ec6fe

Browse files
authored
Merge pull request #176 from quangdang46/fix/minimax-china-endpoint
docs(provider): MiniMax dual-endpoint auto-switch + regression (#141)
2 parents c43d4ba + 507b89e commit b0ec6fe

2 files changed

Lines changed: 37 additions & 2 deletions

File tree

OAUTH.md

Lines changed: 12 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -266,9 +266,19 @@ Two notable presets are:
266266
- Login: `jcode login --provider minimax`
267267
- Stored env file: `~/.config/jcode/minimax.env`
268268
- API key env var: `OPENAI_API_KEY`
269-
- Base URL: `https://api.minimax.io/v1`
269+
- Endpoint auto-selection by API key:
270+
- **International** (default): `https://api.minimax.io/v1`
271+
- Docs: <https://platform.minimax.io/docs/guides/text-generation>
272+
- **China Token Plan** (auto-selected when the key starts with `sk-cp-`):
273+
`https://api.minimaxi.com/v1`
274+
- Docs: <https://platform.minimaxi.com/docs/llms.txt>
270275
- Default model hint: `MiniMax-M2.7`
271-
- Docs: <https://platform.minimax.io/docs/guides/text-generation>
276+
277+
> jcode resolves the MiniMax base URL from the API key prefix. China
278+
> Token Plan keys (`sk-cp-...`) automatically route to
279+
> `api.minimaxi.com`, so users on the China platform should not see
280+
> the upstream `401 / authorized_error` reported when the international
281+
> endpoint is hit with a Token Plan key.
272282
273283
These are first-class jcode provider presets, not just manual custom endpoint examples.
274284
You can still use `openai-compatible` for arbitrary custom providers when there is not a built-in preset.

src/provider_catalog_tests.rs

Lines changed: 25 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -155,6 +155,31 @@ fn minimax_token_plan_keys_resolve_to_china_endpoint_without_changing_internatio
155155
assert_eq!(china.setup_url, MINIMAX_CHINA_SETUP_URL);
156156
}
157157

158+
#[test]
159+
fn minimax_token_plan_keys_route_to_china_even_when_openai_api_key_env_is_international() {
160+
// Regression for issue #141 (upstream PR #188): users on the MiniMax
161+
// China Token Plan reported a `401 authorized_error` because their
162+
// `sk-cp-...` keys were being sent to `api.minimax.io`. Our fork
163+
// resolves the base URL from the *hint* (the actual key being used to
164+
// call the API), not from a stale `OPENAI_API_KEY` env value, so the
165+
// auto-switch must still kick in even when an unrelated international
166+
// OpenAI key is exported in the shell.
167+
let _lock = crate::storage::lock_test_env();
168+
let _guard = EnvGuard::save(&["OPENAI_API_KEY"]);
169+
crate::env::set_var("OPENAI_API_KEY", "sk-international-not-china");
170+
171+
let resolved = resolve_openai_compatible_profile_with_api_key_hint(
172+
MINIMAX_PROFILE,
173+
Some("sk-cp-real-china-token"),
174+
);
175+
assert_eq!(
176+
resolved.api_base, MINIMAX_CHINA_API_BASE,
177+
"sk-cp-* keys must route to api.minimaxi.com regardless of an \
178+
unrelated international OPENAI_API_KEY in env"
179+
);
180+
assert_eq!(resolved.setup_url, MINIMAX_CHINA_SETUP_URL);
181+
}
182+
158183
#[test]
159184
fn auth_issue_lan_openai_compatible_bases_are_valid_for_local_model_servers() {
160185
assert_eq!(

0 commit comments

Comments
 (0)