Skip to content

Routing: define hard cost-cap behavior when runtime cost evidence is unknown #1181

Description

@luvs01

Area

Proxy and routing

What are you trying to accomplish?

Make maxEstimatedCostUsd behave as an explicit policy when a live candidate has no finite cost estimate. Operators should be able to distinguish “known to be below the cap” from “cost is unknown” without silently weakening a hard ceiling or accidentally disabling every live route.

What prevents this today?

The current evaluator excludes only a finite estimate above the configured limit. The live routing path often has no request-usage evidence yet, so an unknown estimate passes the cap check.

A naive fail-closed patch is also unsafe: because usage is not currently wired into that path, it can reject every live candidate whenever a cap is configured. Existing documentation describes the cap in terms of known dry-run evidence, so changing this unconditionally would also change the contract.

What should OpenCodex do?

Define and expose one explicit unknown-cost policy. A minimal design could preserve the current known-only behavior but return an unknown_cost explanation, while an opt-in fail-closed mode excludes an unknown candidate. The chosen behavior should be consistent across dry-run, live routing, logs, and documentation.

Example usage or interface

With a route capped at USD 0.05:

estimate = 0.08  -> excluded: cost_cap_exceeded
estimate = 0.03  -> eligible
estimate = unknown
  known-only     -> eligible, explanation: unknown_cost
  fail-closed    -> excluded: cost_evidence_required

The exact configuration name is intentionally left to maintainer design review.

Alternatives or workarounds

A naive implementation that makes every unknown estimate fail closed would enforce the word “hard” but block normal live routing until reliable request-cost evidence exists. Keeping the current behavior without an explanation leaves operators unable to tell whether the cap was actually evaluated.

Additional context

The live route currently constructs cost evidence before request usage is available, while the dry-run path can have a finite estimate. No equivalent open issue or PR was found. This proposal asks for one contract that explicitly covers both evidence states before a code change.

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew 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