想要什么功能 / What feature?
Use each active account's GetCascadeModelConfigs response as an account-scoped model catalog.
For a multi-account pool:
- Synchronize the cloud catalog for every active account.
- Show the union of active account catalogs through
/v1/models and the Dashboard.
- Route a requested model only through accounts whose own catalog contains it.
- Remove stale catalog state when an account is disabled, removed, or receives a new API key.
The current static catalog can advertise models that are absent from an account's upstream response. A single process-wide snapshot is also insufficient for mixed pools because different accounts may expose different catalogs.
This feature should remain generic: it must not depend on deployment names, hardcoded private model lists, or account-specific metadata.
替代方案 / Alternatives considered
Manual model allowlist
An environment-configured allowlist could hide unavailable models, but it would drift from the upstream catalog and could not represent different account catalogs in the same pool.
Use only the first active account
This is simple, but it incorrectly applies one account's catalog to every other account in a mixed pool.
Use the intersection of all catalogs
An intersection would avoid advertising unsupported models, but it would also hide models that are callable through at least one active account. A union for discovery plus per-account checks for routing preserves all usable models.
最小验收标准 / Minimum acceptance criteria
GetCascadeModelConfigs is synchronized independently for every active account.
/v1/models, Dashboard /models, and Dashboard /tier-access expose the union of usable active-account catalogs.
- Account selection rejects candidates whose own catalog omits the requested model.
- Per-account entitlement data and manual tier overrides cannot bypass that account's catalog.
- Disabling, removing, or rotating the API key of an account invalidates its stale catalog.
- Missing, empty, or failed catalog responses remain fail-open for startup compatibility.
- Special-agent models remain governed by their separate backend catalog.
- An explicit compatibility switch can restore the complete static catalog.
- Automated tests cover mixed catalogs, per-account routing, incomplete synchronization, lifecycle invalidation, Dashboard listings, and dynamic models.
是否愿意提 PR / Willing to submit a PR?
想要什么功能 / What feature?
Use each active account's
GetCascadeModelConfigsresponse as an account-scoped model catalog.For a multi-account pool:
/v1/modelsand the Dashboard.The current static catalog can advertise models that are absent from an account's upstream response. A single process-wide snapshot is also insufficient for mixed pools because different accounts may expose different catalogs.
This feature should remain generic: it must not depend on deployment names, hardcoded private model lists, or account-specific metadata.
替代方案 / Alternatives considered
Manual model allowlist
An environment-configured allowlist could hide unavailable models, but it would drift from the upstream catalog and could not represent different account catalogs in the same pool.
Use only the first active account
This is simple, but it incorrectly applies one account's catalog to every other account in a mixed pool.
Use the intersection of all catalogs
An intersection would avoid advertising unsupported models, but it would also hide models that are callable through at least one active account. A union for discovery plus per-account checks for routing preserves all usable models.
最小验收标准 / Minimum acceptance criteria
GetCascadeModelConfigsis synchronized independently for every active account./v1/models, Dashboard/models, and Dashboard/tier-accessexpose the union of usable active-account catalogs.是否愿意提 PR / Willing to submit a PR?