Skip to content

[FEATURE]: Support multiple API keys per provider with fallback logic #16038

Closed as not planned
Closed as not planned
[FEATURE]: Support multiple API keys per provider with fallback logic#16038
Assignees
jlongster

Description

@yogeek
yogeek
opened on Mar 4, 2026

Describe the enhancement you want to request

as #1326 has been closed and it seems the feature has gained some interest, here is another issue as suggested

Problem

Under heavy usage, multiple Opencode instances hit rate limits, causing failures and interrupting sessions.

Proposed Solution

Allow users to configure multiple API keys for each LLM provider and automatically fallback to the next key when the current one returns a rate limit error (e.g. HTTP 429) or other failures.

On each request:

  • Try with the primary key.
  • If rate‑limited or failed, automatically retry with the next key.
  • Continue until a key succeeds or all fail.
  • Provide optional logs/metrics showing fallback usage (which key, error type).

Activity

  1. yogeek
    added
    discussionUsed for feature requests, proposals, ideas, etc. Open discussion
    on Mar 4, 2026
  2. github-actions
    assigned
    thdxr
    on Mar 4, 2026
  3. github-actions
    added
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on Mar 4, 2026

  4. github-actions commented on Mar 4, 2026

    @github-actions
    github-actionsBot
    on Mar 4, 2026 – with GitHub Actions
    Contributor

    This issue doesn't fully meet our contributing guidelines.

    What needs to be fixed:

    • The description field lacks meaningful content. A feature request should explain the problem being solved, the proposed solution, and relevant context — not just reference a closed issue. Please describe what "multiple API keys per provider with fallback logic" should look like, why it's needed, and how it should work.

    Please edit this issue to address the above within 2 hours, or it will be automatically closed.

    This issue might be a duplicate of existing issues. Please check:

    If you believe this was flagged incorrectly, please let a maintainer know.

  5. github-actions
    added
    needs:complianceThis means the issue will auto-close after 2 hours.
    and removed
    needs:complianceThis means the issue will auto-close after 2 hours.
    on Mar 4, 2026

  6. github-actions commented on Mar 4, 2026

    @github-actions
    github-actionsBot
    on Mar 4, 2026 – with GitHub Actions
    Contributor

    Thanks for updating the issue! It now meets our contributing guidelines. Your feature request is clear and well-described.

  7. thdxr
    assigned
    jlongster
    and unassigned
    thdxr
    on Apr 26, 2026
  8. thdxr
    removed
    discussionUsed for feature requests, proposals, ideas, etc. Open discussion
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on May 3, 2026

  9. LeoLP1 commented on May 18, 2026

    @LeoLP1
    LeoLP1
    on May 18, 2026

    Is there any news about this feature?

  10. github-actions commented on Jul 18, 2026

    @github-actions
    github-actionsBot
    on Jul 18, 2026 – with GitHub Actions
    Contributor

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

  11. github-actions
    closed this as not plannedon Jul 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions