Skip to main content
Policies control which requests a workspace accepts, which models and credentials can serve them, and when a fallback can run. Each policy has a target and one or more rules. A rule combines a request match with an action.

​
How policies apply

  • Every matching restriction must pass
  • All matching policies compose
  • Policies are traversed by ID for deterministic evaluation

​
Create a workspace policy

This walkthrough creates a self-contained policy that caps every request in the active workspace at 1,024 output tokens, then verifies the behavior from the CLI.
1

Create the policy configuration

Save this as output-limit-policy.json:
2

Create and inspect the policy

The CLI uses your active organization and workspace context. Use --workspace to target a specific workspace:
The webapp can also create and edit policies with the same target, match, and action options.
3

Verify behavior

With the policy active, a Chat Completions request with max_completion_tokens greater than 1024 returns 403 policy_denied. A request that omits the field sends 1024 upstream and reports a defaulted adjustment with source: policy. If several matching policies set limits, the tightest ceiling applies.

​
Configure a policy

​
Choose a target

​
Workspace

Apply the policy to all current and future inference keys and playground sessions in the workspace:

​
User

Target a human user or service account to apply the policy to all inference keys associated with them, current and future:

​
Inference keys

Target specific keys. Keys created later are not included:
The webapp’s Applies to selector exposes the same three targets, including service accounts in the user picker.

​
Choose requests to match

Match all requests:
Or combine model, stream, and capability criteria. Every supplied criterion must match:

​
Choose actions

Add one action to each rule. A policy can contain multiple rules, and matching restrictions from all policies apply.

​
Allowed models

Limit matching requests and fallbacks to the listed catalog models:

​
Allowed providers

Limit primary and fallback routes to the listed providers:

​
Budget

Limit matching usage to a USD amount per UTC calendar day or month. Use shared to combine spend across the target or per_key to track each inference key separately:
See the budget tutorial to create a budget and inspect spend.

​
Credential access

Allow credentials from the listed scopes. Matching credential rules intersect. airmux chooses the most specific populated allowed scope in workspace, organization, instance order:

​
Strict parameter support

Reject a route if airmux would otherwise clamp an unsupported caller-supplied parameter:

​
Model price limit

Set maximum catalog prices in USD per million tokens. Both input and output prices must meet the limits:
This limits route prices, not the total request cost.

​
Request limits

Reject a request that explicitly asks for more output tokens than the limit. If it omits the limit, airmux does not invent one:

​
Deny requests

Reject matching requests with 403 policy_denied and the configured message:

​
Model fallbacks

Try backup models for rate limits, upstream errors, or timeouts:
Invalid requests, policy denials, and authentication failures do not trigger model fallback. An upstream authentication failure may try another credential in the selected scope.