Skip to content

[feature] explicit last-resort cooldown policy for failover combos #5691

Closed

Description

@RHODIZSECURITY

Area

Proxy and routing

What are you trying to accomplish?

Allow a failover combo to treat a designated last-resort target differently from ordinary targets so a brief cooldown on a preferred target does not immediately route traffic to a target intended only for emergency fallback.

What prevents this today?

The ordinary cooldown/failover selector has no explicit policy that says a target is a last resort. Without that distinction, transient cooldown state can cause routing to a target the operator intended to use only after all normal targets are unavailable.

What should OpenCodex do?

Support an explicit last-resort cooldown policy for combo targets. A last-resort target should remain eligible when normal targets are genuinely unavailable, but the router should be able to wait for a short recoverable cooldown on a preferred normal target instead of prematurely dispatching the last-resort target. Existing default behavior should remain unchanged unless the policy is configured.

Example usage or interface

{
  "strategy": "failover",
  "cooldownWaitPolicy": "before-last-resort",
  "targets": [
    {"provider":"provider-a","model":"model-a"},
    {"provider":"provider-b","model":"model-b"},
    {"provider":"provider-c","model":"model-c","lastResort":true}
  ]
}

Alternatives or workarounds

Operators can manually reorder targets or tune global cooldowns, but those approaches conflate priority with temporary health and can add unnecessary latency or cost. A local policy implementation has been validated without changing default behavior.

Additional context

This is intentionally a routing-policy feature rather than a claim that existing failover ordering is incorrect. It is useful for local/offline or high-latency emergency targets that should remain absolute fallback only.

Checks

  • I searched existing issues and documentation.
  • This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
  • I removed secrets and personal data.

Activity

  1. github-actions commented on Sep 23, 2026

    @github-actions
    Contributor

    Issue reopened

    The report now contains the information required by the automated check. Thanks for updating it.

  2. added
    enhancementNew feature or request
    proxyHTTP proxy, routing, reverse-proxy / management auth
    on Sep 23, 2026
  3. added a commit that references this issue on Sep 24, 2026
    893c81c
  4. lidge-jun commented on Sep 24, 2026

    @lidge-jun
    Owner

    Fixed on dev by bundle #5741 (squash-merged as 893c81c); it will ship in the next release. Closing manually because dev is not the default branch, so GitHub does not auto-close. If you still see this on a build that includes 893c81c, please reopen with the version and a redacted reproduction.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    account-poolOAuth, credentials, Codex pool, quota, failover, plansenhancementNew feature or requestproxyHTTP proxy, routing, reverse-proxy / management auth

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions