Billing & Usage

Airlock has two layers of control over usage: your seats, which cap how many people can be in the organization; and per-integration token budgets, which cap how much tool-call content each integration may move. The number of integrations you can deploy is not capped.

Plans

Airlock has no self-service billing portal. Whether your organization has an active subscription is a flag that airlock sets for you — paid plans are arranged directly with airlock (for example, by invoice or contract) rather than through an in-app checkout.

Integrations are unlimited on every plan, including the free tier. There is no cap on how many you can deploy and no upgrade prompt when you add another one.

Seats

Your organization has a seat limit that caps how many user accounts it can hold — invited and pending users count against it. You can see it on Settings → Organization as N / M seats used, and Settings → Users & Groups blocks the Add User button once the limit is reached ("Seat limit reached (N/M)").

Invited and pending members count against the limit, not just active ones. Like the plan flag, seats are set by airlock rather than bought in-app — contact us to raise the number. See Users, Roles & Groups for the full member lifecycle.

Per-Integration Token Budgets

Every integration can have an independent token budget that caps how much tool-call content it may move.

Airlock estimates tokens from the size of each call's arguments and its response (roughly 4 bytes per token). This approximates the context your agent's model has to process — it is not a reading of your model provider's bill, and the cost figure on the Usage tab is an estimate derived from it.

Budgets are configured on the integration's detail page, on the Usage tab, in the Budget Configuration card at the bottom. Only organization admins see this card; members see the usage figures without the controls.

Available controls:

• Hard limit — when crossed, further tool calls on that integration return an error until the budget resets or is raised. Use this to prevent runaway spend.
• Soft limit — a lower bound that does not block calls. On its own it sends nothing: when a hard limit is also set, the soft limit is purely informational; when no hard limit is set, the soft limit becomes the 100% mark that alert thresholds are measured against.
• Alert thresholds — the only thing that sends email. Percentages of the hard limit if one is set, otherwise of the soft limit. Budgets are evaluated hourly, and each run sends at most one email — for the highest threshold crossed since the last alert — so a sudden jump past several bands produces a single message, not one per band.
• Notify emails — the addresses alerted when a threshold is crossed. Leave this empty and no budget alerts are sent at all; there is no fallback to organization admins.

Budgets are measured per calendar month (UTC). Usage counts from 00:00 UTC on the 1st and resets automatically at the start of the next month — a hard-limited integration starts working again then, with no action needed. Alert thresholds re-arm each month too.

Hard-limit enforcement is real-time on each tool call; alerts are evaluated by an hourly background job.

Typical setup:

Soft limit:        2,000,000 tokens   (warning)
Hard limit:        3,000,000 tokens   (block)
Alert thresholds:  [50, 75, 90]       (% of hard limit; at most one email per hour)
Notify emails:     ops@example.com

Request Counting

Airlock counts MCP requests per period across all your integrations, but this is for usage visibility only — there is no request cap, and tool calls are never rejected for hitting a request count. The running totals feed the Usage and Analytics pages; spend is controlled by the per-integration token budgets above.

Usage Visibility

All MCP tool calls are also written to the audit log, accessible from the History page in the main navigation.