Model control
Model control lets admins curate the model catalog — which providers and models your members can use — and set defaults per surface (desktop, CLI, cloud, mobile). Policy resolves through organization → team → project → member layers; explicit denies and contract ceilings always win.
What you control
Members never see models your catalog disables, even if they type a model id manually in the CLI — the runtime returns a policy denial recorded on the Usage page.
Policy resolution order
Effective policy is computed server-side on every run:
contract entitlements (Console)
→ organization catalog (allows / denies / groups)
→ team override (optional)
→ project override (optional)
→ member exception (optional)
Hard contract ceilings and explicit denies win unless a platform operator applies an audited override in the Console.
Setting org-wide policy
Review contract entitlements
Open Organization or model control's entitlement panel. You can only enable providers and model groups your contract includes — unavailable entries appear disabled with an explanation.
Enable providers and models
Turn on the providers you use in production. Prefer model groups over long explicit lists so new models in a group roll out without weekly admin toil.
Set defaults per surface
Choose a sensible default for each surface:
Defaults improve onboarding — members get a good experience without configuring anything.
Preview effective policy
Use Policy preview (when available) to simulate effective models for a sample member, team, and project before publishing. Preview matches what
4rged policy modelsreturns locally.Publish and audit
Save changes. Model policy versions appear in the audit log with actor, diff summary, and timestamp.
Team and project overrides
Delegated managers with team.policy.manage or project agent manage capability can narrow
org policy — never widen beyond contract:
Restricting the catalog is a cost lever — fewer, well-chosen models keep spend predictable. Pair model control with budget policies and review policy denials weekly.
Admin procedure: respond to a policy denial
When a developer reports "model not allowed" in CLI or desktop:
Find the denial event
Open Usage → Denials (or Analytics → Policy denials). Note model id, surface, project, and member.
Trace effective policy
In model control preview, select the same member/team/project. Identify whether deny is org, team, or project scoped.
Fix intentionally
Either add the model (or group) to the catalog, add a scoped exception, or tell the developer to use an allowed default — avoid one-off member exceptions when a group change is cleaner.
Verify
Ask them to rerun
4rged policy models --surface clior start a short dry-run agent task.
Server-side resolution
Effective catalogs are computed in Postgres via get_effective_model_catalog_bundle, merging
policy rules in scope order: organization (1), team (2), project (3), then member
(4). Each layer merges into the previous snapshot; explicit denies and contract ceilings from the
Console win over org allows. Providers are filtered by surface — a model enabled for desktop
but not CLI will not appear in 4rged policy models --surface cli even if the member can see it
in the IDE picker.
Example: CLI check after policy change
4rged policy models --surface cli --output json
# allowed: ["claude-sonnet", "gpt-4o-mini"]
# default: "claude-sonnet"
# denied_reason: nullSurfaces and enforcement
Spend attribution and budget stops when models are allowed but caps are hit.
How CLI runs consume the CLI surface default.
Operator-set ceiling that bounds your catalog.
Before rollback, open model control Change history to restore a prior policy version instead of manually re-clicking dozens of models — faster and audited as a single revert action.