Area
Catalog / models
What are you trying to accomplish?
I need user-configured price overlays (providers.<name>.modelCosts and expected-prices.ts overlays) to apply uniformly to every account under a base provider — including the dynamically generated account log labels that appear in usage.jsonl.
Today, an overlay keyed on openai does not resolve for requests whose provider field is openai-conta2, main, or conta2, even though those are just account-qualified log labels for the same underlying openai surface. The result is an em dash in the Logs ~$ column for those requests and no cost estimate at all.
What prevents this today?
baseProviderLabel() in src/providers/label.ts collapses a provider name to its base only when the suffix after the last - matches CODEX_ACCOUNT_LOG_LABEL_RE (/^p[a-f0-9]{6}$/) or is the literal main. Account labels like conta2 (a short alphanumeric handle, not a Codex-style p-prefix label) do not match, so resolveMatchedPrice never collapses openai-conta2 → openai and the overlay lookup misses.
resolveMatchedPriceExact is then called with provider="openai-conta2", finds no overlay row with that exact key, and returns null.
Relevant code:
src/providers/label.ts:8-20 — baseProviderLabel
src/codex/account-label.ts:6 — CODEX_ACCOUNT_LOG_LABEL_RE = /^p[a-f0-9]{6}$/
src/usage/cost.ts:176-212 — resolveMatchedPrice
The workaround today is to manually register a provider entry in config.json for every account suffix (e.g. openai-conta2, main, conta2), each carrying a full copy of every price overlay. That breaks on every proxy restart because those synthetic entries fail schema validation (baseUrl: Invalid input: expected string, received undefined), the proxy falls back to default config, and the whole catalog plus all overlays are lost.
What should OpenCodex do?
Cost resolution should apply a base provider's price overlays to every account-qualified log label derived from it, regardless of the suffix format.
Observable requirements:
resolveMatchedPrice("openai-conta2", "gpt-6-astra") resolves to the same cost4 as resolveMatchedPrice("openai", "gpt-6-astra").
- The collapse happens for any suffix that does not itself correspond to a configured provider.
- No operator action is required beyond the single base-provider overlay.
Example usage or interface
Expected behaviour in usage.jsonl:
| provider |
model |
resolved cost |
openai |
gpt-6-astra |
$10 / $50 |
openai-conta2 |
gpt-6-astra |
$10 / $50 |
main |
gpt-6-astra |
$10 / $50 |
conta2 |
gpt-6-astra |
$10 / $50 |
Alternatives or workarounds
- Register synthetic providers in
config.json: creates openai-conta2, main, etc. as full provider entries. Breaks on restart because they fail Zod schema validation without baseUrl, dropping all overlays. Fragile and unscalable.
- Duplicate every overlay for every account suffix: same validation problem, and the suffix set is dynamic — impossible to maintain.
- Current proposed fix: widen
baseProviderLabel so any unconfigured suffix collapses to the base, then resolve overlays on the collapsed name.
Additional context
- This matters because OAuth multi-account routing generates these labels automatically; operators cannot predict or enumerate them.
- A synthetic-provider workaround silently zeros cost estimates after every proxy restart, which is worse than no estimate at all because it looks intentional.
Checks
Area
Catalog / models
What are you trying to accomplish?
I need user-configured price overlays (
providers.<name>.modelCostsandexpected-prices.tsoverlays) to apply uniformly to every account under a base provider — including the dynamically generated account log labels that appear inusage.jsonl.Today, an overlay keyed on
openaidoes not resolve for requests whose provider field isopenai-conta2,main, orconta2, even though those are just account-qualified log labels for the same underlyingopenaisurface. The result is an em dash in the Logs~$column for those requests and no cost estimate at all.What prevents this today?
baseProviderLabel()insrc/providers/label.tscollapses a provider name to its base only when the suffix after the last-matchesCODEX_ACCOUNT_LOG_LABEL_RE(/^p[a-f0-9]{6}$/) or is the literalmain. Account labels likeconta2(a short alphanumeric handle, not a Codex-stylep-prefix label) do not match, soresolveMatchedPricenever collapsesopenai-conta2→openaiand the overlay lookup misses.resolveMatchedPriceExactis then called withprovider="openai-conta2", finds no overlay row with that exact key, and returnsnull.Relevant code:
src/providers/label.ts:8-20—baseProviderLabelsrc/codex/account-label.ts:6—CODEX_ACCOUNT_LOG_LABEL_RE = /^p[a-f0-9]{6}$/src/usage/cost.ts:176-212—resolveMatchedPriceThe workaround today is to manually register a provider entry in
config.jsonfor every account suffix (e.g.openai-conta2,main,conta2), each carrying a full copy of every price overlay. That breaks on every proxy restart because those synthetic entries fail schema validation (baseUrl: Invalid input: expected string, received undefined), the proxy falls back to default config, and the whole catalog plus all overlays are lost.What should OpenCodex do?
Cost resolution should apply a base provider's price overlays to every account-qualified log label derived from it, regardless of the suffix format.
Observable requirements:
resolveMatchedPrice("openai-conta2", "gpt-6-astra")resolves to the samecost4asresolveMatchedPrice("openai", "gpt-6-astra").Example usage or interface
Expected behaviour in
usage.jsonl:openaigpt-6-astraopenai-conta2gpt-6-astramaingpt-6-astraconta2gpt-6-astraAlternatives or workarounds
config.json: createsopenai-conta2,main, etc. as full provider entries. Breaks on restart because they fail Zod schema validation withoutbaseUrl, dropping all overlays. Fragile and unscalable.baseProviderLabelso any unconfigured suffix collapses to the base, then resolve overlays on the collapsed name.Additional context
Checks