Repository navigation
[Feature]: price gateway aliases at manufacturer list rates #1299
Description
Scope update — 2026-08-09
The long-context pricing portion originally included in this issue has already been implemented and merged in #952.
This issue now tracks only the remaining gateway/provider alias pricing work: exact-match alias coverage, manufacturer list-rate sourcing, promotional/free alias treatment, and auditable pricing-source metadata.
Area
Catalog / models
What are you trying to accomplish?
I want the Usage view to report real spend for traffic that goes through gateway providers, so I can compare routes and notice when a "free" alias is actually costing manufacturer rates.
Right now a large share of my traffic resolves to no price at all and simply drops out of the totals, which makes the Usage page misleading rather than merely incomplete: a route with unpriced aliases looks cheaper than one whose ids happen to be in the bundle.
What prevents this today?
Gateway providers re-expose upstream models under their own ids. Those ids are absent from both the jawcode bundle and EXPECTED_PRICE_OVERLAYS, so resolveMatchedPrice() returns nothing and the request contributes zero to cost.
Measured on my install: about 7,700 requests carrying roughly 880M input tokens over 30 days resolved to no price. EXPECTED_PRICE_OVERLAYS ships 51 rows on v2.11.0; my local overlay needs 108 to cover the aliases I actually route through.
Two pricing-source cases also need explicit handling:
-freeroutes and launch promotions. These are priced at $0 or not at all, but the token cost is real whenever the promotion ends or the route falls back. Pricing them at the manufacturer's normal published rate is the conservative reading; pricing them at $0 encodes a promotional state that expires silently.- Models without manufacturer-published pricing. Where the manufacturer publishes no usable rate, a documented third-party listing can be used as a derived source, but it must be distinguishable from manufacturer-verified pricing.
What should OpenCodex do?
- Ship exact-match overlay rows for gateway aliases, mapping each alias to the original manufacturer's published list price. Exact match only, case-sensitive — no fuzzy matching and no fragment fallback, so a near-miss stays unpriced rather than silently priced wrong.
- Price
-freeand promotional routes at the manufacturer's normal published rate rather than treating the promotional alias itself as permanently $0. - Where a manufacturer publishes no usable pricing, allow a documented third-party listing as a fallback and mark the row as derived rather than manufacturer-verified.
- Record enough source metadata for every overlay row to make the pricing decision auditable and re-verifiable.
The property I would most want preserved: every zero is a sourced decision, not a placeholder. An unresolved price must remain visibly unresolved rather than silently becoming zero.
Example usage or interface
Overlay row shape, as I run it locally:
{
provider: "Opencode",
modelId: "deepseek-v4-flash-free",
cost4: DEEPSEEK_V4_FLASH, // manufacturer rate, not promotional $0
source: DEEPSEEK_PRICING,
verifiedAt: "2026-08-02",
status: "verified-derived",
},
{
provider: "nvidia",
modelId: "minimaxai/minimax-m3",
cost4: MINIMAX_M3,
source: MINIMAX_PRICING,
verifiedAt: "2026-08-02",
status: "verified-derived",
},Non-USD list prices should be converted at a dated, exported rate rather than an inline literal, so the conversion is auditable and can be re-checked:
export const CNY_PER_USD_2026_08_02 = 6.7548;
const LING_30_FLASH = {
input: 0.4 / CNY_PER_USD_2026_08_02,
output: 1.2 / CNY_PER_USD_2026_08_02,
cacheRead: 0.08 / CNY_PER_USD_2026_08_02,
cacheWrite: 0,
};Before / after on the Usage page for one month of my traffic:
before: ~7,700 requests / ~880M input tokens -> no price resolved -> excluded from totals
after: same traffic priced using exact-match gateway aliases backed by auditable pricing sources
Alternatives or workarounds
- Maintaining the overlay locally, which is what I do. It works, but it is roughly 60 hand-sourced rows that need re-verification whenever a manufacturer changes a price, and every consumer of the Usage page has to repeat the same work independently.
- Pricing by fuzzy id matching — deliberately rejected. Gateway ids collide across manufacturers and a wrong price is worse than no price, because it looks authoritative. Exact match keeps unknown ids visibly unknown.
- Reading prices from provider APIs at runtime. Most of these gateways do not publish a rate endpoint, and the ones that do may report their own promotional pricing rather than the manufacturer's list rate this issue is trying to track.
Additional context
I keep a companion audit document alongside the table recording, per row: the source URL, the cache-pricing rule applied, the dated FX rate, the set of ids still deliberately unpriced, and known-stale rows in the jawcode bundle (gpt-5.6-terra and gpt-5.6-luna on my install).
I am happy to contribute both the table and that audit as a PR if the approach is welcome — the sourcing discipline is the part worth reviewing more than the numbers themselves, since the numbers will age.
One caveat I would want a maintainer's call on: my rows were verified on 2026-08-02 and prices drift. If upstream takes this, it needs an owner and a re-verification cadence, otherwise it becomes confidently wrong — which is worse than the current state of being visibly incomplete.
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 8, 2026
Automated translation bookkeeping — detected language: English.
[-][Feature]: price gateway aliases at manufacturer list rates, and model long-context tiers[/-][+][Feature]: price gateway aliases at manufacturer list rates[/+]Ingwannu commentedon Aug 10, 2026
The missing-price problem is real, but “actual spend” and “manufacturer list-rate equivalent” must not be represented as the same metric.
PR #1010 has now merged a durable exact provider/model
modelCostsoverlay, so operators can cover private or fast-moving aliases without patching the bundle. A built-in alias table is still useful only where its provenance is auditable and its meaning is explicit.For a focused follow-up PR:
-freerequest as real paid spend when the gateway charged zero; if a manufacturer-equivalent estimate is desired, expose it as such rather than replacing billed cost;Keeping this open for the built-in provenance layer;
providers.<name>.modelCostsis the current operator-owned workaround.brunoflma commentedon Aug 10, 2026
Update after 2.12.0 — #1010 landed
providers.<name>.modelCosts, and it changes what is left of this request. Narrowing it rather than leaving it as filed.Solved by #1010: the workaround half. I no longer need a patched
EXPECTED_PRICE_OVERLAYSto price gateway aliases —modelCoststakes the exact upstream model id per provider and wins over the built-in catalogs, which is precisely the shape I was carrying locally. The documented fallback order (usermodelCosts→ jawcode → expected-price overlay → vendor fallback) is also the right precedence. Thanks — that is a better mechanism than what I proposed.Still open, and the part I would keep this issue for:
Correct gateway prices by default.
modelCostsmakes the data expressible; it does not make it known. Every user routing through DevWorld / NVIDIA NIM / OpenCode Zen / TokenRouter still has to source ~60 manufacturer list prices by hand, and until they do, that traffic silently contributes zero to Usage totals — which reads as "cheaper route" rather than "unpriced route". Shipping the rows is the partmodelCostsdoes not address.Long-context tiers, which
Cost4cannot express.modelCostsis a flat{input, output, cacheRead, cacheWrite}per model. Several manufacturers publish a higher rate above a context threshold — xAI at ≥200k, OpenAI above 272k, MiniMax above 512k. There is no way to state "double all four rates above N input tokens" in the current shape, so a long-context request is still billed at the short-context rate.If (1) is not something upstream wants to own — and the re-verification burden I raised in the original post is a fair reason not to — then this reduces to (2) alone, and I am happy to retitle it that way. (2) is a schema question and does not age the way a price table does.
One correction to my original post while I am here: I described the overlay as something I maintain "locally as a patch". As of 2.12.0 that is the wrong framing for anyone reading this later — the supported way is
modelCostsin config, and I am moving to it.lidge-jun commentedon Aug 19, 2026
리뷰 · 우선순위 36 / 80
게이트웨이 별칭 트래픽이 가격표에 없어 Usage 합계에서 빠지고, 그래서 공짜처럼 보이는 문제를 다룹니다. 긴 컨텍스트 가격은 #952로 들어갔고, 남은 것은 정확한 별칭 매칭, 제조사 정가, 프로모/무료 별칭, 출처 메타데이터입니다.
현재 dev의 src/usage/cost.ts resolveMatchedPrice()는 사용자 modelCosts, 번들, EXPECTED_PRICE_OVERLAYS 순으로 보고, 매칭 실패는 null입니다. 주석도 0은 소싱된 결정이고 플레이스홀더가 아니라고 합니다. verified와 verified-derived 상태가 이미 있습니다. 퍼지 매칭은 없고, antigravity 베이스 id 폴백만 있습니다. 별칭이 오버레이에 없으면 이슈가 본 것처럼 합계에서 빠집니다.
원하는 규칙은 별칭을 제조사 정가로 정확 매칭하고, -free/프로모도 정가로 보수적으로 읽으며, 제조사 가격이 없으면 파생 출처를 표시하는 것입니다. 틀린 가격이 없는 가격보다 나쁘므로 비슷한 id를 추측하면 안 됩니다.
해결방안: EXPECTED_PRICE_OVERLAYS에 exact-match 행과 source, verifiedAt, status를 더 넣는 일입니다. 숫자보다 소싱 규율이 중요하고, 재검증 주기가 없으면 자신 있게 틀린 표가 됩니다. 로컬 오버레이는 이미 우회입니다. 어떤 별칭 집합을 번들에 넣을지는 여기서 정하지 않습니다.
이 댓글은 grok-bot이 작성했습니다
lidge-jun commentedon Aug 19, 2026
리뷰 · 우선순위 36 / 80 · 종결
게이트웨이 별명이 가격표에 없어서 Usage에서 통째로 빠지는 문제임. 긴 컨텍스트 가격은 #952로 이미 들어갔고, 남은 건 별명을 제조사 정가로 매기는 쪽임.
가격 넣는 건 이미 그 방향임. 다만 공짜/프로모 별명은 표시 안 함. 0원으로 보이게 해서 싸 보이게 만드는 게 이 이슈의 불만이기도 해서, 공짜 배지는 안 넣음.
이미 그쪽으로 가고 있으니 이 이슈는 닫음. 빠진 별명·잘못된 단가 같은 구체 예시가 있으면 댓글로 더 주고 다시 열어 달라. 예시 없이 열어 두진 않음.
해결방안: 별명 exact-match를 제조사 리스트 레이트로 채우는 건 진행 중 방향. 공짜 표시는 안 함. 추가 패치는 예시 오면.
이 댓글은 grok-bot이 작성했습니다
brunoflma commentedon Aug 20, 2026
Follow-up after v2.28.0 validation: the local layer-G patch still carries configurable long-context tiers for gateway aliases (commit 1ddefb89; the current source is src/usage/expected-prices.ts around the long-context tier table).
I see that this issue was closed on 2026-08-19 after the alias-pricing scope was narrowed and the long-context portion was considered covered by #952. I am leaving this concrete update in case the remaining configuration gap should be reopened here or tracked separately:
Requested behavior is a small, explicit configuration contract for context tiers (threshold, multiplier or per-field rates, precedence, and validation), with exact provider/model matching and auditable source metadata. No fuzzy alias guessing is requested. If this is outside the closed issue’s intended scope, please point me to the preferred new issue and I will move the evidence there.