Set model enablement and monthly quotas

Model policies constrain Task-creation admission where the policy check is integrated. They are not a shared hard budget across all conversations, automations and collaboration entry points, or a real-time circuit breaker for running work.

Prerequisites and permissions

• Confirm that the deployment provides Team → Models & quota and that the workspace has an available model catalog. Gateways, published models and credentials belong to Platform configuration and personal access; a quota does not configure them.
• Current Team navigation is for platform administrators. Inline editing additionally requires the current user to have workspace_admin membership in the target workspace's member list. The server still checks workspace-management rights on save; seeing a page does not establish permission to save.
• Prepare the gateway, logical model name, enabled state, monthly Token limit and estimated USD cost limit. Read cost states and limitations first so missing prices or records are not mistaken for complete costs.
• Validation affects new Tasks. Obtain internal approval and use existing records or small, cost-controlled tests in a test workspace. Do not generate large Token volumes just to reach a quota.

Steps

1. Sign in, confirm the target workspace and open Team → Models & quota. Find the model in Workspace model catalog.
2. Check the gateway below the logical model name and the provider. Policies identify a model by “gateway identifier:logical model name”; a similar display name is not enough to identify the row.
3. Enter Monthly Token quota and Monthly cost quota. Use a non-negative integer for Tokens and a non-negative USD amount for cost. 0 means unlimited for either field, not prohibited usage.
4. Set the checkbox under Access policy. A checked box displays Allow; clearing it displays Disable. To deny new Task admission for that model, disable it rather than setting a zero quota.
5. Click that row's Save. If Revision changed. Refresh appears, reload, review the latest policy and then edit again. For other save failures, inspect the error and service state as well; do not assume success or blindly overwrite another administrator's change.
6. Reload and confirm the enabled state and both limits remain as intended. Unsaved inputs do not change policy.

The Console route pattern is /w/{workspaceId}/settings?section=team-models. Follow the existing Create a task guide for Task operations. Its form has no generic task-level model selector, so establish which model the execution configuration actually resolves before validating policy.

How admission works

• Enablement: Task creation checks the policy matching the resolved gateway and model. A matching disabled model is rejected. No matching policy does not itself mean usage is prohibited.
• Month: quotas accumulate recorded Runs by their start time in the UTC calendar month, not the local calendar month, last 30 days or Overview's last seven days.
• Tokens and cost: the check totals matching input plus output Tokens and estimated USD cost. If a non-zero limit has already been reached, a new Task using that model is rejected. Either limit can cause rejection.
• Model attribution: the policy key includes the gateway, but usage accumulation currently matches ModelID. Identical model identifiers across gateways are not guaranteed independently accounted gateway budgets.
• Dependency failures: unavailable policy or required usage queries deny admission instead of allowing it. Restore dependencies or authorization before retrying; repeated creation is not a workaround.

The page's “Usage this period” comes from its returned Run records and is not established as UTC-month-filtered. Do not use it as a remaining-quota balance. Costs are estimates; missing usage or pricing affects the completeness of quota decisions.

Verification

1. Persistence: reload and confirm workspace, row, state and limits. A successful save establishes that configuration was accepted, not that every execution entry point enforces it.
2. Disabled model: in an approved test workspace, disable a model that the Task configuration is known to resolve. Create a small test Task and confirm rejection due to model disablement. If creation succeeds, first inspect the actual resolved model and policy key rather than concluding that all policies fail.
3. Quota: use existing Runs with known models and months. Set a test limit at or below recorded UTC-month usage and confirm the corresponding Token- or cost-quota rejection for a new Task. Check pricing states for cost samples; incomplete prices cannot prove a hard budget. Do not “burn through” a quota with repeated real calls.
4. Restore: restore the original state and limits and reload to confirm. If positive-path creation needs verification, use a minimal authorized test Task. Record environment, role, policy, resolved model, month definition and rejection reason.

Limits and common mistakes

This is an admission-time check against recorded usage. It does not reserve quota for a new Task or terminate an already running Task in real time. Concurrent creation, a large execution and telemetry delay can cause final usage to exceed a limit. It cannot promise that the provider bill will never exceed a budget.

Do not extend this Task admission point to claim identical budget protection for every Chat, Automation Run, MCP or other entry point. Automatic role collaboration is currently assembled with BudgetNone; the existence of a lower-level BudgetHard type does not establish enabled hard-budget enforcement. Disabling a model does not revoke credentials, delete historical Runs or recover incurred costs.

There is insufficient evidence for unified budget alerts or real-time circuit-breaking controls, so this guide invents no alert switch. Record saved configuration, admission verification and business acceptance separately; see Verification boundaries.