Fix MiniMax CN Token Plan web fetch with token-plan endpoints (#254) - #262
Merged
Conversation
This was referenced Aug 6, 2026
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
A MiniMax China-mainland Token Plan user (TokenPlanPlus annual membership) has no coding-plan subscription, so the legacy endpoint
GET /v1/api/openplatform/coding_plan/remainsanswers HTTP 200 withbase_resp.status_code=2062/status_msg="no active token plan subscription". 0.47.0 surfaced that as a fatal fetch error.Upstream (steipete/CodexBar) has zero support for the token-plan endpoints — this is implemented from the reporter's live evidence.
Fix (rust/src/providers/minimax only)
coding_plan::is_token_plan_without_coding_plan— matchesProviderError::Othermessages containing "token plan" (case-insensitive), i.e. exactly the 2062 path through the existing remains parser.fetch_with_cookiewraps the coding-plan call: on that error it falls back to a new token-plan path; auth rejection staysAuthRequired; when all token-plan endpoints are empty the original coding-plan error propagates unchanged.fetch_token_plan_with_cookie), all on the www host with the fetch_remains_once request envelope:GET /v1/api/openplatform/charge/token_plan/usage— 401/403 → AuthRequired, other non-2xx/parse failures swallowed; body parsed with the sharedparse_coding_plan_value(charge-API family shares the model_remains/services schema).GET /backend/account/token_plan/usage_summary— lenient parse oftotal_days/active_days/total_token_consumed(numbers or numeric strings, root or "data") → informational "Token Plan" extra window (123,456 tokens · 5 / 30 days active) or summary-only snapshot.GET /backend/account/token_plan_credit— plan title (current_subscribe_title/…/current_combo_card.title/title) → login method.Fixes #254
Tests
cargo test --manifest-path rust/Cargo.toml minimax— 36 passed, 0 failed (8 new: predicate incl. the reporter's 2062 fixture, summary/title parsing, charge-usage fixture → 5h primary at 2% + unlimited weekly end-to-end, full/summary-only/row-less/all-absent assembly, original-error fallback).cargo test --manifest-path rust/Cargo.toml— 926 passed, 0 failed.cargo clippy --workspace --all-targets -- -D warnings— clean.cargo fmt --allapplied.Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is enabled.