feat(plugin): add MiniMax Token Plan OAuth provider#27460
Conversation
Adds an internal plugin that registers OAuth + API key auth methods
on the existing minimax-coding-plan and minimax-cn-coding-plan
providers. Both regions get a "Sign in with MiniMax" entry that
runs OAuth 2.0 Device Code Flow (RFC 8628) with PKCE against
account.{minimax.io,minimaxi.com}, plus a "Paste Token Plan key"
fallback for manual API-key entry.
The plugin handles token refresh proactively (5-min buffer before
expiry) and persists the new refresh_token to disk before updating
in-memory state, so a crash mid-refresh can't lose a rotated
refresh_token. Refresh requests retry on transient 5xx/network
errors but bail immediately on 4xx (the refresh_token is genuinely
invalid).
Promotes the four MiniMax providers in the TUI provider picker so
they appear together as a contiguous block, instead of being
scattered among other "non-popular" providers in the catalog tail.
Companion catalog rename PR at sst/models.dev rebrands the two
Token Plan entries from "Coding Plan" to "Token Plan" in display
labels.
|
The following comment was made by an LLM, it may be inaccurate: Potential Duplicate FoundPR #27011: feat(opencode): add MiniMax OAuth device code flow plugin This appears to be a related or possibly duplicate PR that also adds MiniMax OAuth support with Device Code Flow. Since both PRs target the same provider (MiniMax) and implement OAuth authentication, they may be addressing the same feature or there may be overlapping work. Recommendation: Check PR #27011 to see if it's already implementing this functionality or if it covers the same scope. |
|
Automated PR Cleanup Thank you for contributing to opencode. Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions. This PR was closed because it matched the following cleanup criteria:
PRs created within the last month are not affected by this cleanup. If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate. Thanks again for taking the time to contribute. |
2 participants
Issue for this PR
N/A — new provider integration
Type of change
What does this PR do?
Adds an internal plugin that registers OAuth + API key auth methods on the existing
minimax-coding-planandminimax-cn-coding-planproviders (already inmodels.dev). Both regions get:account.{minimax.io,minimaxi.com}The plugin handles refresh proactively (5-min buffer before expiry) and persists the new refresh_token to disk before updating in-memory state — a crash mid-refresh can't lose a rotated refresh_token. Refresh requests retry on transient 5xx/network errors but bail immediately on 4xx (the refresh_token is genuinely invalid).
Also promotes the four MiniMax providers in the TUI provider picker (
PROVIDER_PRIORITY) so they appear together as a contiguous block, instead of being scattered among other "non-popular" providers in the catalog tail.How did you verify your code works?
bun typecheckcleantest/plugin/minimax.test.ts— 8 tests, all passing — covers refresh edge cases:expired_in: 0not treated as "infinite token, never refresh"refresh_tokenin OAuthsuccessresponse → fail loud (don't store empty string)bun dev: provider picker → "MiniMax Token Plan (minimax.io)" → "Sign in with MiniMax" → browser opens toaccount.minimax.iodevice-code page → returns to TUI → can chat withMiniMax-M2.7.Notes
client_idis from an official MiniMax-registered instance for this integration.Coding Plan→Token Planin the provider catalog: providers(minimax): rename Coding Plan → Token Plan in display labels models.dev#1776Checklist