Repository navigation
feat(providers): expose usage-supported in provider plugin manifest - #12214
Merged
diegosouzapw merged 5 commits intoSep 1, 2026
Merged
diegosouzapw merged 5 commits into
diegosouzapw merged 5 commits into
Conversation
maxmad64bis
marked this pull request as ready for review
August 31, 2026 18:16
Publish the second usage capability from cheaper-inference#11722. The manifest now advertises usage-supported alongside usage-fetch so integrators can tell whether the server usage routes accept a provider without reading TypeScript. USAGE_SUPPORTED_PROVIDERS moves to a zero-import leaf (src/shared/constants/providers/usageSupported.ts) and is re-exported from providers.ts, mirroring the fetcherProviders leaf from cheaper-inference#11903 and keeping the manifest a light module. usage-fetch resolves on id or alias (dispatcher accepts both); usage-supported resolves on id alone, matching the runtime guard (USAGE_SUPPORTED_PROVIDERS.includes with no alias resolution). 7 differences prove the two notions are distinct (42 shared, 4 fetcher-only, 3 supported-only).
maxmad64bis
force-pushed
the
feat/usage-supported-capability
branch
from
August 31, 2026 18:32
1d71175 to
60e977e
Compare
5 tasks done
…base Carry kilocode into the extracted USAGE_SUPPORTED_PROVIDERS leaf and keep the list as string[] so .includes(providerId) type-checks. Drop the unused UsageSupportedProvider type (knip dead-code).
Update the changelog count to 46 (kilocode) and drop stale usage-fetch vs usage-supported perimeter examples. Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
Collaborator
|
Babysit (/sweep-reds round 3, Fase B) — not merging. Reds before: Fast Quality Gates ( Action:
Local signal: CI running on |
Collaborator
|
Follow-up: original API Route Typecheck is green on this run. New reds after the merge-refresh are inherited from
Not fixing those inside this contributor branch (base-red belongs in a |
2 tasks done
6 tasks done
…-supported-capability
…kspace boundary) The manifest lives in open-sse and may not import from src/ (the open-sse typecheck gate). Same pure-data leaf pattern as fetcherProviders.ts (cheaper-inference#11903): open-sse/services/usage/supportedProviders.ts owns the list (typed readonly string[] so .includes(string) keeps compiling), and src/shared/constants/ providers.ts re-exports it so every existing import path is unchanged. The dead UsageSupportedProvider type is gone; the list matches the current base (kilocode included — openrouter/devin-cli arrive with cheaper-inference#12256, which needs a re-sync onto whichever of the pair lands first).
Collaborator
|
Holding this one rather than merging it, and I want to be explicit about why. I had prepared a reconciliation for the base drift here: the branch forked 46 commits before Checking what landed, the same gap was already handled here, and better — the leaf moved to Since another session is actively working this branch (commits from both @maxmad64bis and the maintainer account within the last hours), I'm leaving the merge to whoever owns that work rather than racing it. The PR is OPEN and MERGEABLE. For the record, the rest of your batch landed: #12321, #12319, #12314, #12316, #12318, #12215, #12151, #12218, #12320, and #12317 is in flight. |
diegosouzapw
merged commit Sep 1, 2026
c9f9b62
into
cheaper-inference:release/v3.8.51
11 of 16 checks passed
diegosouzapw
added a commit
to Neuron-Mr-White/OmniRoute
that referenced
this pull request
Sep 1, 2026
…base Re-home openrouter + devin-cli onto the USAGE_SUPPORTED_PROVIDERS leaf introduced by cheaper-inference#12214. Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
muhamadgalihsaputra
pushed a commit
to niyatna/NiyatnaRoute
that referenced
this pull request
Sep 27, 2026
…heaper-inference#12214) The provider plugin manifest already exposed usage-fetch (40 providers, cheaper-inference#11903); this publishes the second capability, usage-supported, so integrators can tell without reading TypeScript whether the server usage routes accept a provider. cheaper-inference#11903 closed cheaper-inference#11722 after shipping only half of it and said so at the time — this is the follow-up it promised. The two scopes genuinely differ and the docs now say how: usage-fetch resolves on id or alias (the dispatcher accepts both), usage-supported on id alone, because the runtime guard does a plain USAGE_SUPPORTED_PROVIDERS.includes(providerId) with no alias resolution. 42 providers carry both tags, 4 carry only usage-fetch (opencode, opencode-zen, openrouter, xai) and 3 only usage-supported (adobe-firefly, firefly, xiaomi-mimo-token-plan) — 7 measured differences, so neither tag implies the other. No list mutation, no new route, schemaVersion stays 1. USAGE_SUPPORTED_PROVIDERS moved out of src/shared/constants/providers.ts into an import-free leaf at open-sse/services/usage/supportedProviders.ts, keeping the manifest's import graph light — the same move fetcherProviders.ts got in cheaper-inference#11903, landed on the correct side of the workspace boundary. Base note: the branch forked 46 commits before kilocode joined the list, so a wholesale take of its providers.ts would have silently dropped that id. Verified against the current release tip before merging — both sides hold the same 46 ids, nothing lost. Verified on the current tip: typecheck:core clean, check:cycles OK across 417 files (the import-free-leaf claim holds), and 63/63 focused tests across provider-plugin-manifest, usage-fetcher-registration-coverage, adobe-firefly and agentrouter-quota-dashboard-rendering. Thanks @maxmad64bis — and for finishing the half of cheaper-inference#11722 that was left open rather than letting it sit.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Publish the second usage capability in the provider plugin manifest. The manifest already exposes
usage-fetch(40 providers, #11903); this PR addsusage-supportedso integrators can tell without reading TypeScript whether the server usage routes accept a provider.usage-supportedtag inProviderPluginCapabilityandcapabilitiesFor()(open-sse/config/providerPluginManifest.ts).USAGE_SUPPORTED_PROVIDERSextracted to a zero-import leafsrc/shared/constants/providers/usageSupported.ts, re-exported fromproviders.ts(same move asfetcherProviders.tsin feat(providers): expose a usage-fetch capability in the provider plugin manifest #11903; the manifest graph stays light).docs/reference/PROVIDER_PLUGIN_MANIFEST.md: 8 tags, distinction betweenusage-fetchandusage-supportedwith the 7 measured differences.schemaVersionstays1.usage-fetchresolves on id or alias (the dispatcher accepts both);usage-supportedresolves on id alone — the runtime guard doesUSAGE_SUPPORTED_PROVIDERS.includes(providerId)with no alias resolution (src/shared/utils/providerQuotaVisibility.ts,src/lib/usage/providerLimits.ts:isSupportedUsageConnection), so the manifest keeps the same rule.The two scopes differ: 42 providers carry both tags, 4 carry only
usage-fetch(opencode,opencode-zen,openrouter,xai) and 3 onlyusage-supported(adobe-firefly,firefly,xiaomi-mimo-token-plan) — 7 differences in total, so one tag does not imply the other.Related Issues
usage-fetch, so this PR ships just that. Happy to add the second tag in a follow-up if you want it." This PR is that follow-up.Validation
npm run lintupstream/release/v3.8.51(63e4afa32)check:cycles— pass (import-free leaf, no cycles)check:docs-sync/check:doc-links/check:changelog-integrity— pass (changelog.d/features/12214-usage-supported-capability.mdadded — reviewer-flagged gap, mirrors 11903)Tests Added Or Updated
tests/unit/provider-plugin-manifest.test.ts— 3 tests added (mirrors of feat(providers): expose a usage-fetch capability in the provider plugin manifest #11903, asserting against the real list):usage-supportedfor a listed providerusage-supportedfor a provider not in the listusage-supportedmatches on id only, not alias (and diverges fromusage-fetch, which does match on alias)USAGE_SUPPORTED_PROVIDERSviaproviders.tsstay untouched thanks to the re-export.Coverage Notes
Touches
src/andopen-sse/. Covered bytests/unit/provider-plugin-manifest.test.tsand the ~20 existing suites onUSAGE_SUPPORTED_PROVIDERS/isSupportedUsageConnection/supportsProviderQuota(e.g.provider-quota-visibility,adobe-firefly,command-code-usage,firecrawl-usage). No coverage drop expected on the touched files.Reviewer Notes