fix(pricing): prefer a native provider over aggregator re-listings

[samirhvbr]

Problem

resolve_litellm_model() resolves a bare model name that several LiteLLM providers list by returning the alphabetically first matching key when those listings agree on price. LiteLLM's model_cost has since grown aggregator re-listings that sort ahead of a model's first-party provider. With the pinned litellm==1.90.1, grok-4.5 now has three same-priced listings:

• openrouter/x-ai/grok-4.5
• perplexity/xai/grok-4.5
• xai/grok-4.5

so the resolver returns openrouter/x-ai/grok-4.5 instead of xai/grok-4.5. The cost estimate is unaffected (identical price), but the reported provider is wrong — and tests/test_pricing.py::test_resolves_common_bare_model_names fails on main against the pinned litellm.

Fix

Prefer the first-party listing: the match whose key is exactly <litellm_provider>/<name>. When that match is unique, return it before falling back to price consensus. This restores native-provider attribution and also resolves names the price-consensus rule gave up on when aggregators disagree on price (a unique first-party listing among differently priced mirrors).

Tests

• test_resolves_common_bare_model_names passes again against litellm 1.90.1.
• Adds two deterministic, mock-backed regression tests so the behavior no longer rides on the live LiteLLM catalog.
• ruff format, ruff check, mypy, and pytest tests/test_pricing.py all pass.

🤖 Generated with Claude Code

[Copilot]

🟢 Approval recommended

The change is narrowly scoped, improves determinism/provider attribution, and is covered by targeted regression tests.

Pull request overview

This PR fixes LiteLLM model-name resolution so that when a bare model name matches both aggregator re-listings and the model’s first-party provider listing, the resolver prefers the native provider key (e.g., xai/grok-4.5) rather than the alphabetically first aggregator key. This keeps provider attribution accurate and stabilizes resolution behavior as LiteLLM’s model_cost catalog grows.

Changes:

• Update resolve_litellm_model() to prefer a unique first-party (“native”) "<litellm_provider>/<name>" match before falling back to the existing price-consensus tie-break.
• Add two mock-backed regression tests covering native-vs-aggregator preference and the “unique native even when aggregators disagree on price” case.

File summaries

File	Description
strix/report/pricing.py	Adjusts model resolution logic to prioritize unique native provider listings over aggregator re-listings.
tests/test_pricing.py	Adds deterministic tests that pin the resolver behavior for native-provider preference scenarios.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[greptile-apps]

Greptile Summary

This PR updates LiteLLM model resolution to prefer a unique first-party provider listing over aggregator re-listings before applying price consensus.

• Detects native listings using the catalog entry’s litellm_provider.
• Preserves the existing price-consensus fallback when no unique native listing exists.
• Adds deterministic regression coverage for equal-price and differing-price aggregator listings.

Confidence Score: 5/5

The PR appears safe to merge with no actionable correctness, security, or repository-rule violations identified.

The native-provider preference is applied only when exactly one matching catalog key identifies itself as the provider’s direct listing, while ambiguous cases retain the existing price-consensus behavior.

Important Files Changed

Filename	Overview
strix/report/pricing.py	Adds a narrowly scoped native-provider preference while retaining existing exact-match and consensus behavior.
tests/test_pricing.py	Adds isolated regression tests that restore LiteLLM’s global catalog and clear the resolver cache.

_{Reviews (1): Last reviewed commit: "fix(pricing): prefer a native provider o..." | Re-trigger Greptile}

[itzzdev09]

Drive-by review — the native-route preference is the right call, but the placement here widens the change well beyond #1288, and the existing guard test only looks like it still covers the old behavior.

The guard test passes by accident

test_resolver_does_not_guess_between_differently_priced_providers asserts that differently-priced routes resolve to None. It stays green under this patch only because its fixtures omit litellm_provider:

"provider-a/example": {"input_cost_per_token": 1.0, "output_cost_per_token": 2.0},

With no litellm_provider, the new comprehension compares key == "None/example", never matches, so native is empty and the price-consensus path runs as before.

In the real registry that never happens. Every entry carries the field:

litellm 1.100.0 — dict entries 3888 | with litellm_provider 3888 | missing: []

So in production the native list is populated for essentially every model, and returning native[0] before the price check means the differently-priced case no longer returns None. The behavior the test exists to protect is gone while the test still passes.

How much this actually moves

Sweeping the registry for bare names where main returns None (routes disagree on price) but this patch returns a native route:

121 bare model names change from None to a guess. For example:

gemma-7b-it -> groq/gemma-7b-it
  routes: anyscale/google/gemma-7b-it, fireworks_ai/accounts/fireworks/models/gemma-7b-it, groq/gemma-7b-it
  prices: (2e-07, 2e-07), (5e-08, 8e-08), (1.5e-07, 1.5e-07)

Those are ~4x apart on input cost, so the resolved route drives a materially different cost estimate. That may well be the behavior you want — a first-party listing is a better guess than nothing — but it is a separate decision from #1288, where the three grok-4.5 routes are priced identically and picking among them is free.

(Measured on litellm 1.100.0 rather than the 1.90.1 in uv.lock; the litellm_provider coverage and the shape of the divergence are not version-sensitive, though the exact count will be.)

Suggestion

Either:

1. Move the native preference inside the len(matches) == 1 or len(prices) == 1 branch, so it only breaks ties the resolver was already willing to resolve — that fixes BUG: pricing resolver returns the aggregator route for equally priced models (test failing on main) #1288 with no behavior change anywhere else; or
2. Keep it where it is, but give the guard test fixtures a real litellm_provider so it actually exercises the new path, and state the widened contract in the docstring: a unique first-party listing beats price consensus.

#1289 takes approach (1) on the same issue, so it's worth the two of you settling which contract you want rather than the placement being decided by merge order.