Feature: Multi-account support with automatic failover

[cvrt-jh]

Feature Request

I've built a fork with multi-account support that I'd love to contribute back to this project.

Features Added

• Multiple accounts: Add multiple Claude Pro/Max accounts with custom labels
• Automatic failover: When one account hits rate limits (429), automatically switches to the next available account
• Rate limit tracking: Tracks which accounts are rate-limited with expiry times
• API key fallback: Falls back to ANTHROPIC_API_KEY env var when all OAuth accounts are exhausted
• CLI management tool: Standalone multi-auth CLI for account management outside of OpenCode
• Backwards compatible: Automatically migrates existing single-account auth to multi-account format

CLI Tool

Account management via multi-auth command (run before starting OpenCode):

multi-auth add [label]     # Add account (opens browser for OAuth)
multi-auth list            # List accounts with token status
multi-auth info            # Detailed info (expiry times, tokens)
multi-auth rename <n> <name>
multi-auth remove <n>
multi-auth status

Example output:

$ multi-auth list
📋 Connected Accounts

   1. "Personal" - 🟢 valid (7h 56m left)
   2. "Work" - 🟢 valid (7h 56m left)
   3. "Backup" - 🔴 expired (will auto-refresh)

Use Case

For users with multiple Claude subscriptions (personal + work, or team accounts), this allows seamless switching when hitting rate limits, maximizing productivity without manual intervention.

Implementation

The fork is available at: https://github.com/cvrt-gmbh/opencode-anthropic-multi-auth

Key changes:

• Storage format changed from type: "oauth" to type: "multi-oauth" with accounts array
• Config stored in ~/.config/opencode/multi-auth.json (shared between CLI and plugin)
• Added rate limit tracking with retry-after header parsing
• Automatic retry with next available account on 429
• Standalone CLI tool for account management

Collaboration

I'm happy to:

• Submit a PR with these changes
• Adapt the code to match your project's style/conventions
• Discuss alternative implementation approaches
• Help maintain the feature going forward

Let me know if you're interested in incorporating this functionality!

[cvrt-jh]

Update: In-Session Status Tool Added (v1.3.0)

Just pushed a new feature that addresses the "how do I know which account is active?" question:

New: multi_auth_status Tool

Users can now ask the agent "what's my auth status?" and it will call a new tool that displays:

• Account summary (total, available, rate-limited)
• Current active account with token validity
• All available accounts with token expiry times
• Rate-limited accounts with time remaining until available
• Configuration settings

Screenshot:

The agent formats it nicely:

Auth Status ✅

| Account | Status | Token Validity |
|---------|--------|----------------|
| info (current) | 🟢 Valid | 7h 35m remaining |
| jh | 🟢 Valid | 7h 36m remaining |
| dev | 🟢 Valid | 7h 36m remaining |

All 3 accounts are available with valid tokens. Failover is enabled...

Also Filed: Plugin Status Bar Feature Request

I've also filed a feature request for OpenCode itself to add a plugin status bar area:
anomalyco/opencode#10400

This would allow plugins to display real-time status in the TUI without requiring the user to ask the agent.

---

The fork is at: https://github.com/cvrt-gmbh/opencode-anthropic-multi-auth

Still happy to contribute this back as a PR if you're interested!

[lucafanselau]

Would also be interested. @cvrt-jh I would try the fork, but the repo you linked is not public.

[Shivprasadpravindongapure]

Hi 👋
I’m preparing for open-source contributions (GSoC focused) and this issue really caught my attention.

The idea of multi-account support with automatic failover is very practical and also beginner-friendly when broken down:

• maintaining multiple OAuth accounts as a list
• handling 429 rate-limit responses
• switching accounts automatically
• falling back to API keys when needed

I’d be interested in helping with:

• testing the multi-account flow once the fork is public
• reviewing and understanding the auth + failover logic
• improving documentation or edge-case handling
• helping adapt the fork into a clean PR if maintainers are open to it

This looks like a great improvement for reliability, and I’d love to learn and contribute step-by-step.
Looking forward to collaborating 🙂