Skip to content

feat(rankings): order free providers by measured reliability - #12218

Merged
diegosouzapw merged 2 commits into
cheaper-inference:release/v3.8.51from
maxmad64bis:feat/rankings-reliability-sort
Sep 1, 2026
Merged

diegosouzapw merged 2 commits into
cheaper-inference:release/v3.8.51from
maxmad64bis:feat/rankings-reliability-sort

Conversation

@maxmad64bis

@maxmad64bis maxmad64bis commented Aug 31, 2026 •

Copy link
Copy Markdown
Contributor

Summary

Free Provider Rankings sorts by the top model's Arena score — a provider stays first even if it fails every call. The reliability column (#11546) already shows what each provider actually served, but ordering ignores it.

This PR adds an opt-in ?sortBy=reliability (API) and a "Most reliable first" toggle (page), sharing one comparator in freeProviderRankingsUsage.ts — measured providers first (by successRate desc, ELO on ties), then unmeasured in their incoming order. Default unchanged (locked by tests). successRate is null below MIN_USAGE_REQUESTS = 5 (existing, never zero), and ordering runs before slice(0, limit) so limit counts in the requested order.

The toggle is deliberately opt-in — the page is for discovery, including providers never called — and composes with the existing sortTypeFirst/groupByType type-grouping (stable sort keeps reliability order within each group).

Related Issues

Validation

  • Change type: routing (server ordering) + UI (toggle) + i18n
  • Focused tests and category gates from the golden path
  • npm run lint
  • Reconciled with the current active release base (upstream/release/v3.8.51)
  • Production-code changes include a new or updated automated test in this PR

Tests Added Or Updated

  • New tests/unit/freeProviderRankings-reliability-sort.test.ts — 6 tests for sortRankingsByReliability in isolation (measured first, rate desc, ELO fallback on ties, null counts as unmeasured, stable unmeasured, no mutation).
  • Updated tests/unit/freeProviderRankings-filters.test.ts — 3 tests: no sortBy preserves ELO order, sortBy=reliability pulls usage without withUsage, and limit + combined sortRankingsAuthTypeFirst stability.
  • Updated tests/unit/free-provider-rankings-usage-route.test.ts — 4 tests: unknown sortBy → 400, sortBy=elo/reliability accepted, sortBy=reliability hits call_logs without withUsage, default path stays off call_logs.

Hard Rule #18 red/green: stubbing the comparator to return [...rankings] → freeProviderRankings-reliability-sort 2/6, restore → all green (6/6, 29/29, 8/8).

Coverage Notes

Touches src/lib/, src/app/, src/i18n/. Covered by suites above plus existing free-provider integration tests. i18n gates: i18n:check-ui-coverage PASS, i18n:check-value-drift (BASE_REF=upstream/release/v3.8.51) PASS, i18n:check-glossary PASS, check:dashboard-typecheck within baseline.

Reviewer Notes

Diff is two halves — read behavior first, then catalogs:

  • Behavior (4 files): src/lib/freeProviderRankingsUsage.ts (comparator), src/lib/freeProviderRankings.ts (sortBy, needsConnectionSnapshot, ordering before slice, usage aggregate gated on sortBy), src/app/api/free-provider-rankings/route.ts (sortBy enum, 400 on typo), src/app/(dashboard)/dashboard/free-provider-rankings/page.tsx (toggle, useMemo composition).
  • Catalogs (43 files): en.json gains sortByReliability / sortByReliabilityHelp (2 keys). 42 locales via scripts/i18n/sync-ui-keys.mjs gain those 2 plus 23 prior en_only keys already in en.json at base but missing in those locales (40 × +25, vi/pt-BR +2) — all __MISSING__ sentinels, no hand editing. All i18n gates PASS.

No new threshold, no silent coercion, no extra network call (withUsage already fetched).

@maxmad64bis
maxmad64bis force-pushed the feat/rankings-reliability-sort branch 2 times, most recently from 6855361 to 5c67330 Compare August 31, 2026 18:55
@maxmad64bis
maxmad64bis force-pushed the feat/rankings-reliability-sort branch from 5c67330 to a566cf6 Compare August 31, 2026 19:21
…new sort keys

- freeProviderRankings.ts: extract needsUsageAggregate() and applyRankingOrder()
  so computeFreeProviderRankings stays within the cyclomatic ratchet (file back
  to the base's single pre-existing cognitive violation)
- vi.json / pt-BR.json: real translations for the two new keys
  (sortByReliability, sortByReliabilityHelp) — the strict Vietnamese
  completeness gate rejects __MISSING__ markers
@diegosouzapw
diegosouzapw merged commit 5253b93 into cheaper-inference:release/v3.8.51 Sep 1, 2026
15 of 16 checks passed
@maxmad64bis
maxmad64bis deleted the feat/rankings-reliability-sort branch September 24, 2026 21:11
muhamadgalihsaputra pushed a commit to niyatna/NiyatnaRoute that referenced this pull request Sep 27, 2026
…-inference#12218)

Free Provider Rankings sorted by the top model's Arena score, so a provider stayed first even if it failed every call — the reliability column from cheaper-inference#11546 already showed what each one actually served, but ordering ignored it.

Adds an opt-in ?sortBy=reliability (API) and a "Most reliable first" toggle (page) sharing one comparator in freeProviderRankingsUsage.ts: measured providers first by successRate desc with ELO on ties, then unmeasured in their incoming order. The default is unchanged and locked by tests. successRate is null below MIN_USAGE_REQUESTS = 5 (existing, never zero), and ordering runs before slice(0, limit) so limit counts in the requested order. The toggle composes with the existing sortTypeFirst/groupByType grouping — a stable sort keeps reliability order within each group.

Opt-in is the right default here: the page is for discovery, including providers never called.

13 tests across three files (6 new for the comparator in isolation, plus filter and route coverage including unknown sortBy → 400 and the default path staying off call_logs).

Verified in a combined batch worktree with all 11 PRs of this batch: 174/174 focused tests, typecheck:core clean, complexity 2706/3218, cognitive-complexity 1221/1437, check:cycles and check:docs-counts green. The 42-locale i18n pass was checked with the CI gates: check-ui-keys-coverage PASS (all 42 locales at or above 65%) and check-ui-value-drift PASS against the release tip.

Thanks @maxmad64bis.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants