fix(api): enumerate tiered auto combo endpoints in /api/combos/auto

[ekinnee]

Problem

The OmniRoute server's backend already supports auto/<category>[:<tier>] routing (e.g. auto/coding:free, auto/reasoning:pro, auto/vision) via suffixComposition.ts + virtualFactory.ts, and the chat handler routes them correctly. But GET /api/combos/auto only enumerates 6 flat variants (coding, fast, cheap, smart, offline, lkgp), so clients can't discover the tiered variants.

Root Cause

src/app/api/combos/auto/route.ts only iterates VALID_VARIANTS (the 6 flat variants). The 10 curated AUTO_SUFFIX_VARIANTS from builtinCatalog.ts were never exposed via this endpoint.

Solution

Added a second loop after the flat-variant loop that iterates AUTO_SUFFIX_VARIANTS, parses each via parseAutoSuffix, and materializes the combo via createVirtualAutoCombo(undefined, { category, tier }) — the same pattern used by createBuiltinAutoCombo in builtinCatalog.ts.

Changes

File	Change
src/app/api/combos/auto/route.ts	+43 lines — new loop enumerating 10 tiered auto combo variants

Newly exposed endpoints

• auto/coding:fast, auto/coding:cheap, auto/coding:free, auto/coding:pro, auto/coding:reliable
• auto/reasoning, auto/reasoning:pro
• auto/vision, auto/multimodal

Verification

• Syntax check: node --check passes
• Only 1 file changed
• Individual try/catch per variant; failures skip cleanly without breaking the list
• Existing flat variants unchanged

Related Issues

Fixes #7619

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[manchairwang]

When I retrived model list from omniroute 3.8.48 (with another omniroute 3.8.48 server), I got these endpoints but they didn't work. I found that they are not in this 10 name list. Is there anything possible missing?

auto/glm
auto/minimax
auto/mimo
auto/zai
auto/gemma
auto/llama
auto/gemini

[ekinnee]

Great catch, thanks for reporting this! You're right — those auto/glm, auto/llama, auto/gemini etc. endpoints are legitimate family variants from the #6453 feature. They were being advertised by /v1/models but GET /api/combos/auto was missing them entirely, along with the template variants (auto/best-coding, auto/pro-*, auto/claude-*, etc.).

I've pushed a fix that adds three additional enumeration phases to the combos endpoint:

1. Template variants (20) — auto/best-coding, auto/pro-reasoning, auto/claude-opus, auto/best-free, etc.
2. Family variants (7) — auto/glm, auto/minimax, auto/mimo, auto/zai, auto/gemma, auto/llama, auto/gemini
3. Suffix variants (9) — auto/coding:fast, auto/reasoning:pro, etc. (already in the original PR)

The endpoint now exposes all 36 auto variants that /v1/models advertises. A seenIds set prevents duplicates across the overlapping phases.

Thanks again for the thorough testing!

[diegosouzapw]

Thanks for wiring the template/suffix/family enumeration through — the logic itself (AUTO_TEMPLATE_VARIANTS/AUTO_SUFFIX_VARIANTS/AUTO_FAMILY_IDS + parseAutoSuffix + createVirtualAutoCombo(variant, spec)) is correct and matches builtinCatalog.ts's own resolution order.

However, running the existing suite against this branch turns up a real regression:

$ node --import tsx/esm --test tests/unit/auto-combo-context-advertising.test.ts
✖ GET /api/combos/auto includes positive context_length for combos with candidates
  AssertionError: combo auto/llama must advertise a positive max_output_tokens, got null

Root cause: computeAdvertisedLimits() in virtualFactory.ts has a guaranteed-positive fallback for contextLength (via getTokenLimit()) but not for maxOutputTokens (via getResolvedModelCapabilities()), which can legitimately return null for some family models. That gap was invisible while only 6 flat variants were exposed — your new family enumeration (Phase D, auto/llama etc.) is what surfaces it. Could you either give maxOutputTokens the same positive fallback as contextLength, or gate Phase D enumeration on every candidate having a resolved max_output_tokens? Also worth adding a direct test asserting the new ids show up in the response (right now the PR relies entirely on pre-existing, unrelated test coverage to catch regressions).

[diegosouzapw]

(internal) Still fix-in-place: same defect as before, target files untouched by tip drift since last analysis. Needs the null max_output_tokens guard before merge.

[ekinnee]

Added a direct test asserting the new tiered, family, and template auto combo IDs show up in GET /api/combos/auto — covers the specific gap Diego called out. 9/9 tests passing locally.

[diegosouzapw]

Validated in local merge-train on 192.168.0.113 @ 9d2b92a63acdf6915dbcb5d9ae7a4b18caf79d6d (FAST gates green: static + changed tests + vitest; today's full-suite parity ran in trains 4+5)