MiniMax 429 rate limit pollutes all providers' request routing

[arvin68h-dot]

关键要点：

• MiniMax 429 不仅卡自己 provider，连切到别的 provider 都受影响——这是最核心的 bug。
• Issue #5744 和 #87608 被引用为相似案例，但这些 issue 在 openclaw/Tachikoma 仓库中未找到，因此未建立引用。

现象复述：

当 MiniMax 返回 HTTP 429（rate limit / cooldown）时，系统中其他 provider 的请求也会被阻塞或拒绝���表现为在切换 provider 后仍然遇到限流/错误，直到全局 cooldown 状态被清除。

可能的根因猜测：

• Provider 连接池或限流器的状态被全局共享，导致单个 provider 的 cooldown 污染其他 provider。

建议解决方向（优先级不分）：

1. Provider 连接池隔离：为每个 provider 保持独立的连接池和限流器/令牌桶，避免共享状态。
2. 模型级 cooldown：在 provider 内层实现针对具体模型或后端的 cooldown，而不是在更高的全局层面执行降级。
3. 用户选择也走 fallback：当用户切换 provider 时，确保新的 provider 请求路径不沿用上一 provider 的 cooldown状态；用户选择应强制触发一个新的、干净的调用上下文。

参考相关 issue（如果存在）：请维护者将任何相关的 provider cooldown issue 在本 issue 中标注，以便建立引用和历史线索。

重现与日志：

• 描述：在流量突增或 MiniMax 被限流时，尝试切换 provider（例如从 MiniMax 切到其他 provider）会发现请求仍被限流或失败；重启服务/清除全局状态后恢复正常。
• 日志示例：请维护者检查 provider 限流/连接池相关日志（没有附带日志，请告知需要我提供哪些具体日志）。

期望行为：

• 单个 provider 的 429 应只影响该 provider 或该具体模型实例，不应污染到其他 provider。

影响范围与紧急度：

• 由于会影响所有 provider 的可用性，建议设为高优先级/紧急处理。

请维护者评估并指定后续跟进计划。

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 22, 2026, 1:22 PM ET / 17:22 UTC.

Summary
Keep open: current main does not provide a confirmed fix or canonical replacement, but the report lacks logs or a concrete reproduction and source review did not find a global provider cooldown in Tachikoma itself.

Reproducibility: no. The issue describes a plausible MiniMax-to-other-provider failure, but it provides no logs or exact current-main reproduction, and source inspection did not reveal a global cooldown object to exercise.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Next step
The issue should not queue a new automated fix PR until a maintainer or reporter provides a concrete reproduction showing Tachikoma-owned cooldown contamination.

Review details

Best possible solution:

Capture a focused reproduction that forces MiniMax to return 429, switches to a different configured provider, and proves whether Tachikoma or the host app keeps stale cooldown state; then add a regression test and isolate cooldown state at the provider/model boundary if Tachikoma is responsible.

Do we have a high-confidence way to reproduce the issue?

No. The issue describes a plausible MiniMax-to-other-provider failure, but it provides no logs or exact current-main reproduction, and source inspection did not reveal a global cooldown object to exercise.

Is this the best way to solve the issue?

Unclear. Provider/model-scoped cooldown isolation would be the right fix if Tachikoma owns the state leak, but the current source first needs a proof that the contamination is inside this repository rather than in a caller, gateway, or host app.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The failure may live in a host app, external gateway, or caller-side fallback layer because Tachikoma source does not show a global provider cooldown or request router for this behavior.
• No logs, exact provider-switch sequence, or mocked 429 reproduction are available, so an autonomous fix would risk changing provider behavior without proving the reported bug.

Codex review notes: model internal, reasoning high; reviewed against a6c5cb90b182.

Label changes

Label justifications:

• P2: The reported provider-routing failure could affect provider availability, but it is not confirmed as a core crash, data loss, or urgent production regression.
• impact:auth-provider: The issue is about provider selection and whether one provider's rate-limit state contaminates requests routed to other providers.

Evidence reviewed

Acceptance criteria:

• Add a mocked provider test where a MiniMax request returns HTTP 429 and a subsequent non-MiniMax provider request succeeds without inherited cooldown state.
• If reproduced in a host app, capture the exact Tachikoma model selection, configuration, and provider-switch sequence before changing core provider code.

What I checked:

• Repository policy read: AGENTS.md was read fully; its provider-adapter guidance made the provider factory and provider implementation paths the relevant review surface. (AGENTS.md:1, a6c5cb90b182)
• Issue discussion lacks reproduction artifacts: The issue describes MiniMax 429 behavior and asks maintainers what logs are needed, but no concrete logs, versions, failing transcript, or exact provider-switch call sequence are attached; the only comment is the prior failed ClawSweeper review.
• MiniMax routing is provider-specific in current source: Current main selects MiniMax and MiniMax China through provider-specific enum cases and constructs an Anthropic-compatible provider with that provider's API key and base URL; there is no cooldown state in this factory path. (Sources/Tachikoma/Providers/ProviderFactory.swift:61, a6c5cb90b182)
• MiniMax provider creation carries per-provider endpoint identity: makeMiniMaxProvider resolves the base URL for the selected MiniMax provider and passes MiniMax-specific auth, capabilities, reasoning provider, and reasoning base URL into the Anthropic-compatible provider. (Sources/Tachikoma/Providers/ProviderFactory.swift:138, 63601973c6d0)
• Compatible provider does not store cross-provider cooldown: AnthropicCompatibleProvider creates an AnthropicProvider for each generate or stream call using a local configuration seeded with that compatible provider's API key and base URL; source inspection found no shared cooldown or token bucket there. (Sources/Tachikoma/Providers/Compatible/AnthropicCompatibleProvider.swift:85, 82c7aa095ff9)
• HTTP 429 is not handled as a persistent provider cooldown: AnthropicProvider turns non-200 responses into immediate API errors; the reviewed code does not persist a 429 cooldown that could intentionally block later calls to other providers. (Sources/Tachikoma/Core/BaseProviders.swift:354, 82c7aa095ff9)

Likely related people:

• steipete: Git history and blame show this handle authored the MiniMax provider, MiniMax China provider, recent Anthropic-compatible reasoning changes, and most touched provider/config files in this area. (role: introduced behavior and recent area contributor; confidence: high; commits: 7704018a475d, 63601973c6d0, 4669fe58f4b3; files: Sources/Tachikoma/Providers/ProviderFactory.swift, Sources/Tachikoma/Providers/Compatible/AnthropicCompatibleProvider.swift, Sources/Tachikoma/Core/BaseProviders.swift)
• shraderdm: The closed Anthropic base URL routing issue and merged configuration workaround are adjacent to provider routing and environment/base URL isolation, though not the same MiniMax 429 behavior. (role: adjacent provider configuration contributor; confidence: medium; commits: 8b808f24c869; files: Sources/Tachikoma/Core/Configuration.swift, Tests/TachikomaTests/Core/ConfigurationEnvironmentTests.swift)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[steipete]

Maintainer update: #27 now includes a regression test that forces a MiniMax HTTP 429 and then verifies a Kimi request succeeds on its independent route. The full exact-head suite passes (770 tests/103 suites), and authenticated text calls through both provider implementations also pass.

This establishes that Tachikoma does not carry a shared provider cooldown across the two routes. I am keeping this issue open until the provider PRs clear their remaining authenticated vision gate and the regression is on main.

[steipete]

Fixed on main by PR #27, merged as eb921cf05083.

The landed regression forces a MiniMax HTTP 429, then performs a Kimi request and verifies that it succeeds on its independent endpoint. This confirms Tachikoma has no shared global provider cooldown contaminating that route. The exact merged candidate passed 773 tests across 103 suites, clean autoreview, and all exact-head CI workflows.

Thanks for reporting this, @arvin68h-dot.