feat(providers): centralize provider model capability config

[rdself]

Summary

This PR centralizes the provider model source of truth that was previously scattered across provider registries, routing helpers, translators, catalog endpoints, and UI-specific compatibility code. All provider models, model lists, and capability metadata are now consolidated into a single provider-first file: open-sse/config/providers/sharedModels.ts.

At a high level, the shared file is organized like this:

export const EXAMPLE_PROVIDER_MODELS = [
  {
    id: "provider-model-id",
    name: "Provider Model Name",
    capabilities: {
      contextWindow: 128000,
      maxOutputTokens: 8192,
      supportsVision: null,
      supportsTools: null,
      supportsReasoning: true,
      supportsXHighEffort: false,
      supportsMaxEffort: true,
    },
    compat: {
      targetFormat: "claude",
      unsupportedParams: ["temperature", "top_p"],
    },
  },
];

Providers import these shared model lists into their registry entries, while still preserving provider-specific capability differences when the same model ID is served by different upstreams.

The new provider-first model configuration structure groups models by provider and supports the full set of shared capability and limit fields used by OmniRoute, including context and output limits, vision, tool calling, reasoning/thinking support, xhigh/max effort support, default thinking budget metadata, target format metadata, and compatibility options. This makes model metadata maintenance consistent across all providers and significantly reduces the cost of adding or updating provider model catalogs.

It also adds user-overridable model capability configuration with matching dashboard UI, including explicit null / true / false states and reset-to-synced-baseline behavior. Custom/imported models can now carry the same capability metadata as built-in provider models without being overwritten by future syncs.

This has been reviewed with particular attention to preserving existing request behavior. The intended scope is to centralize model capability metadata and expose it for editing, with only the explicit behavior notes below treated as intentional semantic changes.

Because this touches a broad set of providers and model capability call sites, it would be best to merge it before additional provider/catalog PRs land and create another large conflict surface. @diegosouzapw

Main Changes

• Introduce a provider-first shared model metadata/configuration layer.
• Migrate provider model capability fields into the unified structure.
• Preserve provider-specific differences even for identical model IDs served by different providers.
• Add model capability override persistence, synced-baseline snapshots, and reset endpoints.
• Update model catalog, provider model sync, routing, translator, context, and compatibility consumers to resolve capabilities from the unified layer.
• Add dashboard UI for viewing/editing model capabilities and compatibility metadata.
• Add regression coverage for null/unknown overrides, CC-compatible fallbacks, OpenAI-compatible max effort behavior, model sync protection, catalog metadata, and custom model capability editing.

Behavior Note

Capability values intentionally remain tri-state where applicable: null means unknown, true means explicitly supported, and false means explicitly unsupported. Unknown values are not converted into unsupported defaults.

Intentional semantic changes documented for reviewers and future maintainers:

• max-effort: unknown (null) support now passes max through instead of normalizing max to xhigh, so upstream gateways can apply their own mapping.
• targetFormat: a saved DB override now wins over the static registry entry.
• Antigravity reasoning: the legacy REASONING_UNSUPPORTED_PATTERNS deny-list is replaced by registry-driven supportsReasoning, enabling reasoning for models it previously blocked.

Validation

• npm run typecheck:core
• npm run lint
• npm run check:file-size
• npm run check:docs-all
• npm run build
• Targeted provider/model sync and compatibility test suites, including null override, empty unsupported parameter, target format masking, CC-compatible fallback, and provider model route coverage.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[Copilot]

Copilot wasn't able to review this pull request because it exceeds the maximum number of files (300). Try reducing the number of changed files and requesting a review from Copilot again.

[diegosouzapw]

Really nice piece of work, @rdself — the centralization is clean and the test coverage is extensive. I want this in. A few asks before merge:

1. [Rule #16] PR description. Please remove the sentence crediting AI tools ("…cross-review with Claude Opus 4.8 and Codex 5.5…") — we don't advertise AI authorship in PR bodies / commits / CHANGELOG. Human reviewers and co-authors are of course welcome to be credited.
2. [CHANGELOG] This adds user-visible surface (the capability-editing UI, POST /api/provider-models/reset, capability-override persistence) and changes routing semantics, so it needs an entry under [3.8.43].
3. [title] It's a refactor + feature + intentional behavior changes, so please retitle refactor(providers): … → feat(providers): ….
4. [please note them in the description] I verified these are deliberate and I'm good with them — just document them so future readers/users know they're intentional rather than regressions:
   • max-effort: unknown (null) support now passes max through instead of normalizing max → xhigh (upstream gateways apply their own mapping);
   • targetFormat: a saved DB override now wins over the static registry entry;
   • Antigravity reasoning: the legacy REASONING_UNSUPPORTED_PATTERNS deny-list is replaced by registry-driven supportsReasoning, enabling reasoning for models it previously blocked.

Once the Rule #16 line is gone, the CHANGELOG entry is added, and the title is feat, I'll merge. Thanks for the careful work here.

[rdself]

@diegosouzapw I have addressed the requested changes: removed the Rule #16 line from the PR description, added the [3.8.43] CHANGELOG entry, retitled the PR to feat(providers): ..., and documented the intentional behavior notes for max-effort, targetFormat overrides, and Antigravity reasoning.

Could you please take another look and merge if everything looks good?

[rdself]

@diegosouzapw I resolved the latest conflicts by merging the current release/v3.8.43 into this branch and pushed the updated head. I also re-ran the relevant local checks around the resolved conflicts (check:file-size, check:test-discovery, check:deps, check:docs-sync, typecheck:core, and the OpenAI→Gemini translator coverage), and they are passing locally.

Could you please re-review and merge as soon as the new GitHub checks are green? This PR has a broad conflict surface, so getting it in soon would avoid another round of conflict resolution.

[rdself]

@diegosouzapw This branch has now been rebased onto release/v3.8.44 and the conflict resolution has been pushed. The PR is mergeable again from GitHub’s perspective; checks have been re-queued.

I also re-ran the relevant local validation after the rebase: check:docs-sync, check:file-size, typecheck:core, plus the provider model route/config sync test coverage affected by the conflict resolution.

[rdself]

Hi @diegosouzapw, I have rebased and resolved the latest conflicts again. Since this PR keeps picking up new conflicts as the release branch moves, could you let me know when it might be possible to merge, or if there is anything else blocking it? Thanks.

[diegosouzapw]

Thanks @rdself — this is a genuinely large and valuable refactor (centralizing provider model-capability config, ~281 files touched incl. hot-path chatCore.ts/combo.ts and the translators). Because it touches the routing/translation hot path across every provider, merging it mid-release into v3.8.44 is too high-risk for a quick review. I'd like to defer it to the next cycle where it can get a dedicated layer-by-layer review (registries → hot-path → routes) plus a full validate-release-green + per-provider smoke run. Please keep it open and rebased; it's on the list for the next release, not rejected. 🙏

[diegosouzapw]

@rdself — first, thank you for the persistence here, and for rebasing this again and again. That effort is exactly why I don't want to keep putting you through it.

You already put your finger on the real problem: "this PR keeps picking up new conflicts as the release branch moves." A ~280-file refactor across the routing/translation hot path can't realistically win a rebase race against a live release branch — every merge into v3.8.44 shifts the ground under you. And because it touches chatCore.ts / combo.ts / the translators for every provider, it genuinely needs a dedicated, layer-by-layer review (registries → hot-path → routes) plus a full validate-release-green + per-provider smoke run — not a mid-release squeeze.

So rather than leave you rebasing indefinitely, I'm closing this and opening #6117 to track the refactor for the 3.9.0 cycle. This is deferred, not rejected — the work is wanted. When the 3.9.0 release branch opens (a stable base that won't move under you), please re-open a focused PR against it and I'll give it the review window it deserves. If you're open to it, staging the diff (registries first, then hot-path adoption) would de-risk the merge a lot.

Really appreciate the contribution — see you in 3.9.0. 🙏