Say who may use which models, on what data, up to what spend. Every allowlist resolves against a verified rate card, so a rule that grants nobody anything shows up as a conflict here rather than as a support ticket later. Export the result as JSON and as a one-page Markdown policy.
| Role | Providers | Tiers | Data rules | Ceiling | Approve above | Models | Status |
|---|---|---|---|---|---|---|---|
| Engineering | all providers on the rate card | frontier, mid, small | no training on our data | $400 | $250 | 35 | clear |
| Data-restricted teams | Anthropic, OpenAI | frontier, mid, small | zero data retention required; no training on our data; US only | $250 | $150 | 16 | ZDR blocks Claude Fable 5US only, recorded not enforced |
| Contractors | Anthropic | mid, small | no training on our data | $100 | $75 | 3 | clear |
| CI service accounts | Anthropic, OpenAI, Google | small | no training on our data | $600 | $400 | 5 | clear |
Tier is derived from each model's published output rate: frontier at or above $20 per million, mid from $4 to under $20, small under $4. Nothing on this page maintains a second list of which model is which, so a repricing moves a model between tiers on its own.
{
"schema": "continuum.model-access-policy/v1",
"generated": "2026-08-20",
"rateCard": {
"source": "https://continuumcode.ai/tools/llm-pricing-calculator/",
"verified": "2026-08-19"
},
"tierBands": {
"frontier": "output at or above $20 per million",
"mid": "output from $4 to under $20 per million",
"small": "output under $4 per million"
},
"roles": [
{
"id": "data-restricted",
"name": "Data-restricted teams",
"providers": ["anthropic", "openai"],
"tiers": ["frontier", "mid", "small"],
"openWeightOnly": false,
"data": { "zdrRequired": true, "noTraining": true, "regionPin": "us" },
"spend": { "ceilingUsdPerSeatMonth": 250, "approvalAboveUsdPerSeatMonth": 150 },
"resolvedModelCount": 16,
"resolvedModelIds": ["claude-fable-5", "claude-opus-5", "..."],
"conflicts": [
{
"code": "zdr-unavailable-model",
"fix": "Fable 5 is not available under zero data retention. Drop the frontier tier for this role, drop the ZDR requirement, or accept that the model will not appear in the picker."
}
]
}
]
}
# Model access policy Owner: [Head of Engineering] · Last reviewed: 2026-08-20 · Next review: [+90 days] ## 1. Scope Applies to everyone using a model on behalf of [Company], on any device, including contractors and automated service accounts. It governs which models a role may reach, on what data, and up to what spend. It does not replace the wider AI usage policy; it is the model-access clause of it. ## 2. How a tier is defined Tier is derived from published output price per million tokens, not from a marketing name, so it cannot drift away from what a model actually costs: - Frontier: output at or above $20 per million - Mid: output from $4 to under $20 per million - Small: output under $4 per million Rates were read from each provider's own pricing page on 2026-08-19. ## 3. Roles ### 3.1 Engineering Approved providers: all providers on the rate card. Approved tiers: frontier, mid, small. This resolves to 35 models on today's rate card. Data rules: no training on our data. Spend: $400 per seat per month is the ceiling. Anything above $250 per seat per month needs approval from [Head of Engineering].
The export is meant to be committed next to your code and diffed on review, so nothing in it is decorative. resolvedModelCount, resolvedModelIds and conflicts are produced by resolving the allowlist against the rate card at generation time, which is what makes the file reviewable: a pull request that quietly widens a role shows up as a change in the model list, not just in a checkbox.
continuum.model-access-policy/v1.| Field | Type | What it holds |
|---|---|---|
schema | string | Always continuum.model-access-policy/v1. Version it if you extend the shape. |
generated | date | When the file was produced. Pair it with the review cadence in the Markdown doc. |
rateCard.verified | date | When the underlying rates were last read off the providers' own pages. If this is stale, the tier assignments are stale too. |
tierBands | object | The three price bands, written out so a reader of the file does not have to visit this page to know what frontier means. |
roles[].providers | string[] | Provider keys from the rate card: anthropic, openai, google, xai, deepseek, moonshot, zai, alibaba, together. |
roles[].tiers | string[] | Any of frontier, mid, small. |
roles[].openWeightOnly | boolean | Restricts the role to rows the rate card itself marks as open weights. It does not infer a licence the table does not state. |
roles[].data | object | zdrRequired, noTraining, and regionPin (none, us, eu, or no-cross-border). |
roles[].spend | object | ceilingUsdPerSeatMonth and approvalAboveUsdPerSeatMonth, both per seat per month. A ceiling of 0 means no ceiling. |
roles[].resolvedModelCount | number | Computed. How many rate-card models this role can reach right now. |
roles[].resolvedModelIds | string[] | Computed. The model ids themselves, so a diff shows exactly what a policy change granted or removed. |
roles[].conflicts | object[] | Computed. A code and a fix per unresolved contradiction. An empty array is the only publishable state. |
Four conflict codes exist today: no-providers, no-tiers, resolves-to-nothing, zdr-unavailable-model, and approval-never-fires. Each carries the fix rather than only the complaint.
A clause with no control behind it is advisory, and the useful thing a vendor can do is say so plainly. Three of the six controls in this builder are enforced by Continuum for organizations today. Three are not, and they are listed as manual in the exported policy rather than quietly implied.
| Policy control | What Continuum enforces | What stays manual |
|---|---|---|
| Allowed providers and models | Org model policy runs organization, then team, then member, with allowlists and deny patterns at each scope. A lower scope can narrow access but never re-open what a higher scope denied, and a newly released model stays blocked until an admin reviews it. | Only on Continuum-hosted inference. A member using their own provider key on their own machine is observed, not gated. |
| Spend ceiling per seat | A weekly allowance per tier, from $25 a week on Plus up to $1,000 a week on Ultra. With overage switched off a member simply stops at the cap. Hosted traffic passes through the gateway on purpose, because that is what makes a cap enforceable. | Direct and BYOK sessions run machine to provider and report usage only. A key nobody is in the path of can be measured, never hard-capped. |
| Approval above a threshold | Approvals ship on the Team plan alongside weekly caps. | The threshold in this file is not read automatically. Set the cap and the approval in org settings so the two agree. |
| Zero data retention | Nothing. This is a provider-side setting. | Set it with each provider, then remove the models it makes unavailable. Claude Fable 5 is the one this builder knows about. |
| No training on our data | Nothing. This is a provider-side setting or a contract term. | All of it. Record the term and the date you confirmed it. |
| Region pin | Nothing. It is recorded in the export and shown in the matrix, never validated. | All of it, at the provider or in a gateway that can route by region. |
| Offboarding | Removing someone in the identity provider blocks provider access, revokes devices and tokens, and destroys the content key. | There is no directory sync today. Sign-in and invitations run on WorkOS AuthKit with Google and Apple login, so federating your own provider is not available yet. |
The recurring gap is the same one every governance tool has: a developer with their own credential on their own machine. No wording fixes that. It is fixed by making the sanctioned path faster to obtain than the unsanctioned one, which mostly means provisioning generously and quickly.
This is the model-access clause of a wider AI usage policy. The full nine-clause template, covering scope, secrets, review of agent-written code, and execution boundaries, is in the AI usage policy guide.
The single most common failure in this document is the phrase "approved AI models" with no list attached. It is unenforceable, everybody reading it knows it is unenforceable, and it converts the policy into a liability statement rather than a control. Name the providers. Then, because a nine-provider list goes stale the moment a lab ships something, define which models within them by a rule instead of a roster. Price is the rule that ages best: it is published, it is checkable, and it correlates with the thing you actually care about, which is how much damage an unattended loop can do in an afternoon.
Two numbers per role, not one. The ceiling is where spend stops. The approval threshold is where a human is asked, and it only means anything if it sits below the ceiling: set them equal and the money runs out before anyone is consulted, which is a control that fires exactly never. This builder treats that as a conflict rather than a style preference, because it is the most common arithmetic mistake in a governance document and it is invisible in prose.
A blanket zero-data-retention requirement across an entire engineering organization is how a policy gets routed around within a quarter. The teams that genuinely handle regulated data need it; the team building the marketing site does not, and telling them they do costs you a model tier for no reduction in risk. Roles exist so the strict rule can be strict where it matters. The cost of that strictness should be visible when you set it, which is why the models column drops the moment you turn ZDR on for a role that wanted the frontier tier.
Region pins and no-training flags are real requirements and mostly unenforceable from inside your own tooling: they are provider-side settings, and the honest thing is to record them with the date you confirmed them rather than imply a control that does not exist. A policy that separates enforced clauses from advisory ones is more useful in an audit than one that presents everything with the same confidence, because the first tells a reader where to look and the second tells them nothing.
Model names, prices, and availability move on a scale of weeks. Because the tiers here are computed from price, a repricing can move a model from mid to frontier without anyone editing a word of your document, which is the good version of that problem: regenerate the file and the diff tells you what changed. Ninety days is the right cadence, and a review that changes nothing still gets recorded, because the date on the file is what tells the next reader whether the model list can be trusted at all.
The parts that decide whether the document survives its first quarter.
Six things per role: which providers are allowed, which model tiers are allowed, what data may reach them, a spend ceiling, an approval threshold below that ceiling, and the enforcement point that makes each one real. Name specific providers and tiers. The wider document this clause belongs to needs five more things, including secrets handling and agent execution boundaries, and the AI usage policy guide has the full template.
By published price, not by marketing name. This tool derives tier from output rate per million tokens: frontier at or above $20, mid from $4 to under $20, small under $4. A price-derived band cannot drift away from what a model actually costs, and a repricing moves a model between tiers on its own instead of quietly leaving your policy stale. It also means the bands are checkable by anyone with the rate card, which a hand-maintained roster never is.
Not on Anthropic's frontier tier. Claude Fable 5 is not available under zero data retention: the model picker either omits it or shows it disabled. So a role that requires ZDR and allows the frontier tier has written a contradiction, and the builder flags it with the fix attached. Drop the frontier tier for that role, drop the ZDR requirement, or accept that the model will not appear. The full model lineup and its plan rules are on the Claude models guide.
Provider and model allowlists on hosted inference, through org model policy that runs organization, then team, then member, where a lower scope can narrow access but never re-open what a higher scope denied. Spend ceilings as a weekly allowance per tier, enforceable because hosted traffic passes through the gateway; with overage off a member stops at the cap. Not enforced today: zero data retention, no-training flags, and region pins. Those are provider-side settings, and the exported policy lists them as manual rather than pretending otherwise.
Continuum for organizations puts model policy and weekly caps behind the clauses that can carry them: allowlists at organization, team and member scope, a weekly allowance per seat, and one view of usage and spend across every provider. The rest of this document stays advisory, and it says so. Before adding a model to the allowlist, compare its evidence with the model review scorecard.
model policy · weekly caps · approvals · one view of spend