[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 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

Where the resolver already accepts a match (one route, or every route at one price), prefer the first-party listing: the key that is exactly <litellm_provider>/<name>. If that listing is unique it wins; otherwise the first key is returned as before.

The preference only breaks ties the resolver was already willing to resolve. Routes that disagree on price still return None, because the cost depends on the route. Measured over the 1,993 bare names in litellm 1.101: no name goes from None to a guess, and 40 names change route, all of them same-priced ties where the old pick was an aggregator (for example MiniMax-M2.5: baseten/MiniMaxAI/MiniMax-M2.5 → minimax/MiniMax-M2.5).

An earlier revision returned the native listing before the price check. That turned 91 of those names from None into a guess among differently priced routes, so it was narrowed after review.

Tests

• test_resolves_common_bare_model_names passes again.
• Mock-backed regression tests for the native preference at equal prices, and for the guard that differently priced routes still resolve to None even when one of them is the native listing. The guard's fixtures carry litellm_provider, as every real catalog entry does, so it exercises the new code.
• ruff format, ruff check, mypy and pytest tests/test_pricing.py tests/test_cost_tracking.py 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.

[samirhvbr]

Thanks for the careful review, and for measuring it. You were right on both points, and I have confirmed them:

• The guard test passed by accident: its fixtures had no litellm_provider, so the native route could never match. On litellm 1.101 the original placement moved 91 of 1,993 bare names from None to a guess among differently priced routes (DeepSeek-R1 → sambanova/DeepSeek-R1 and so on), which is a separate decision from BUG: pricing resolver returns the aggregator route for equally priced models (test failing on main) #1288.
• I took your option 1: the native preference now lives inside the branch that already accepts a match (one route, or every route at one price), so it only breaks ties the resolver was willing to resolve. Re-measured over the same catalog: 0 names go from None to a guess; 40 change route, all of them same-priced ties where the old pick was an aggregator.
• The guard test now uses fixtures with litellm_provider, and the test that asserted the wide behavior asserts None instead (it fails against the previous revision).

On #1289: I read it, and it makes the same change in the same place (it also prefers the native key only inside the len(matches) == 1 or len(prices) == 1 branch). The differences are small: this PR requires the native listing to be unique before preferring it, and carries the guard test above. I am happy to close this in favour of #1289 if that is easier for you to review.