Repository navigation
Routing: define hard cost-cap behavior when runtime cost evidence is unknown #1181
Description
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.
Activity
github-actions commentedon Aug 7, 2026
Automated translation bookkeeping — detected language: unknown.
fix(routing): define hard cost-cap behavior when cost evidence is unk…
fix(routing): define hard cost-cap behavior when cost evidence is unk…
Merge pull request #1404 from lidge-jun/fix/1345-cost-cap-contract
Wibias commentedon Aug 10, 2026
Thanks @luvs01 — fixed by PR #1404 (
01db57cc): hard cost-cap behavior is now defined when runtime cost evidence is unknown — default allow stampscost.capOutcome: "unknown-allowed", opt-in exclude emitscost-limit-unknown/unknown-excluded, with docs, editor, and dry-run/live coverage.fix(routing): define hard cost-cap behavior when cost evidence is unk…
fix(routing): define hard cost-cap behavior when cost evidence is unk…
Merge pull request lidge-jun#1404 from lidge-jun/fix/1345-cost-cap-co…