You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Managed coding-agent model lists currently replace live workspace discovery instead of constraining it.
At launch, managed_supplies_models(managed, tool) sets skip_model_discovery=True whenever the managed config names models. The per-agent writers then classify the admin's strings by model-name shape, without validating that those models are actually available on the target AI Gateway.
The provider capability matrix is also stale relative to the open provider PRs:
classify_model_family() classifies any id containing gpt- as Codex, so a managed system.ai.gpt-oss-120b can bypass the normal discovery exclusion and reach the Responses provider path.
The existing tests pin the old provider matrix with comments such as "Pi has no OSS provider" and "OpenCode has no OpenAI provider". Those premises become stale once #217/#239 merge.
Expected behavior
An admin model list should be an allowlist over what the target workspace actually serves:
models exposed to agent = managed allowlist ∩ live gateway discovery
The admin should win by narrowing the set, but naming an unavailable or incompatible model must not make ucode generate an unroutable provider entry.
Suggested acceptance criteria
Do not skip the discovery required to validate an admin model allowlist, or provide an equivalent launch-time availability check.
Intersect managed model IDs with the target workspace's live family lists.
Preserve admin ordering/default intent among surviving models.
Warn clearly about allowlisted models that are unavailable or unsupported.
Keep gpt-oss out of Codex/Responses routing for both discovered and managed inputs.
Replace the stale negative tests in tests/test_agent_pi.py and tests/test_managed_resolve.py with intersection/provider-routing coverage.
Context
Discovered while rebasing/reviewing #217, #223, and #239 over the managed-config work from #276. Kept out of those provider PRs deliberately so their scope remains focused.
Problem
Managed coding-agent model lists currently replace live workspace discovery instead of constraining it.
At launch,
managed_supplies_models(managed, tool)setsskip_model_discovery=Truewhenever the managed config names models. The per-agent writers then classify the admin's strings by model-name shape, without validating that those models are actually available on the target AI Gateway.The provider capability matrix is also stale relative to the open provider PRs:
_managed_model_families()andmanaged_unservable_models()still drop/report managed Pi Kimi/GLM models as unservable._bucket_by_provider()andmanaged_unservable_models()still drop/report managed OpenCode GPT models as unservable.classify_model_family()classifies any id containinggpt-as Codex, so a managedsystem.ai.gpt-oss-120bcan bypass the normal discovery exclusion and reach the Responses provider path.The existing tests pin the old provider matrix with comments such as "Pi has no OSS provider" and "OpenCode has no OpenAI provider". Those premises become stale once #217/#239 merge.
Expected behavior
An admin model list should be an allowlist over what the target workspace actually serves:
The admin should win by narrowing the set, but naming an unavailable or incompatible model must not make ucode generate an unroutable provider entry.
Suggested acceptance criteria
gpt-ossout of Codex/Responses routing for both discovered and managed inputs.tests/test_agent_pi.pyandtests/test_managed_resolve.pywith intersection/provider-routing coverage.Context
Discovered while rebasing/reviewing #217, #223, and #239 over the managed-config work from #276. Kept out of those provider PRs deliberately so their scope remains focused.