org.tech / Platform / Model access Generated, never typed. Catalogue · 5 Sep 2026

The interesting number is not how many models. It is where each one processes your request.

104 models behind one governed gateway.

One route to every model, and a content policy that route cannot travel without. The catalogue is produced from the provider's live list by a script, classified by where inference actually runs, and read by this website, the product and the agent index alike. Nobody retypes a model name into copy.

104 active models, 18 labs.

CATALOGUE · GENERATED 5 SEP 2026

A script reads the provider's live catalogue, resolves what a deployment can actually reach, and labels every model by where a request is processed when the deployment sits in Canada. The classification is the product of the exercise, not the count.

Generated on a date, so it moves. Per-account entitlement varies, and refreshing it is part of managed operations.

In-region, processed in country
Routed within the country only
Reachable, processed elsewhere
13
In-region · in Canada
1
Routed · within Canada only
18
Reachable · processed outside Canada
72
Served · US and global regions
Read the split before you read the total

The in-Canada generation set is previous-generation: Claude 3 Sonnet and Haiku, Llama 3 8B and 70B, Mistral Large 24.02, Mixtral 8x7B, Mistral 7B. Every current frontier model routes outside Canada. Data residency is configurable, pinned to your region when you need it, and it is a real choice with a real capability cost. The whole argument, with the arithmetic.

The gateway cannot run without it.

POLICY · NOT AN APP SETTING
Four denies, all tiers

Your content policy is not a toggle in an administration screen. It is attached to every inference call, and cloud identity policy denies the call without it. Four denies sit on the chat role and on every module inference role.

  • 01
    No policy, no call. A request that does not carry your content policy is refused before it reaches a model.
  • 02
    No route around the gateway. Inference that does not travel the governed route is denied.
  • 03
    No unconfigured region. Inference outside the configured endpoint regions is denied.
  • 04
    No widening of retention. The workload cannot loosen the account's data-retention election.
The policy objectPINNED
  • FormA numbered versionNever the mutable draft
  • ChangeForces a new versionLast quarter's policy stays identifiable
  • DigestCarried in the version description
  • AllowlistChecked at listing and at invoke
  • Changed byA release, not an administrator
  • TestThe build fails if a deny is weakened
Content policy·Pinned, numbered, versioned

We tell you, and we refuse.

RESIDENCY · REFUSED IN WORDS
Never a silent reroute

A pinned deployment would rather fail than travel.

Pin a deployment to a jurisdiction and the residency control becomes an allow scoped to in-country destinations plus a request-time refusal. If a model has no compliant route, the request is refused with a reason. It is never quietly sent somewhere else, and it is never downgraded to a lesser model on your behalf.

  • 01
    Exactly one. One cross-region route confined to Canada exists in the whole provider catalogue, covering one small model family.
  • 02
    The frontier vendor publishes none. So under the pin, every current frontier model is refused rather than served.
  • 03
    A second in-country region is a destination, not a door. It is admitted as a routed destination and never as an endpoint, because the content policy cannot be created there.
chat · deployment pinned to Canada
RUNNING
chat --model frontier-class --residency ca
[route] resolving a compliant path for the pin
Content policy attached✓ pinned version
In-country endpoint region✕ none published
Route confined to the country✕ no compliant path
Reroute outside the pin△ denied by policy
refused, with the reason, before the request was sent
Illustrative outputrefused
Residency refusal·Illustrative. The in-region set stays available

One upgrade we will not make quietly.

RETENTION · THE DEFAULT AND THE EXCEPTION
01 Default

Prompts are not used to train models.

Under the default posture, prompts are not used to train models and are not shared with model vendors, per the managed model service's terms. The election is made at account scope, and the workload is denied from widening it.

RetentionAccount scope
02 Your election

The newest tier costs you that posture.

One vendor offers its newest frontier tier only with provider-side data sharing and retention of up to 30 days. Those models render unavailable until you elect that explicitly. It never happens by upgrade.

ElectionIn writing, by you

Why a model is not on your list.

SERVE STATES · IN PLAIN WORDS
StateWhat it meansWhat happens
ServeableAllowlisted, entitled, with a compliant route from your deploymentAvailable in chat
Needs accessIn the catalogue, but your account has not been granted it by the providerWe request it; some vendors want a use-case form
Needs a retention electionOffered only with provider-side data sharingShown unavailable until you elect it
No route in your regionYour deployment is pinned and the model has no compliant pathRefused in words, with the reason
Ungoverned planeCannot carry the content policy as a denyListed and classified, never selectable

That last row is the discipline in one line. A second model plane exists and could be switched on tomorrow. It cannot carry your content policy as a deny in cloud identity policy, and it has no Canadian region at all, so on a governed deployment it is shown, classified and refused rather than quietly offered.

Counted where it actually happened.

METERING · AGAINST THE PROVIDER'S RECORD
What a question actually costs

For an order of magnitude: a knowledge question of roughly 10,000 tokens in and 1,000 out costs about 4 to 5 cents at a mid-tier frontier model's list price. That is an estimate, not a quote, and it lands on your cloud invoice rather than ours. Compute costs.

01Who decides which models we can use?

You do, and we apply it by release. The allowlist is a deploy-time parameter checked at listing and again at invoke, which means no administrator, including ours, can widen it from inside the running system. See administration.

02Do the model vendors see our prompts?

Under the default posture, prompts are not used to train models and are not shared with model vendors, per the managed model service's terms. The single exception is the newest frontier tier described above, which is unavailable unless you elect it.

03What happens when a provider changes its catalogue?

We re-run the generation script as part of managed operations. The site, the ticker and the product's own model library read the same generated file, so a change shows up in all three or in none. That is why the date is printed next to the number.

04Could we run open-weight models ourselves instead?

You could, and it is a genuine alternative with a different bill and a different operating burden. The catalogue already includes open-weight families from several labs through the managed service. We set the trade out on self-hosted models.

05Can we pin inference to Canada?

Yes, on the Strict tier. Read the numbers at the top of this page first, then posture tiers. Most organizations find that storage in their own region plus a governed route is the decision they actually wanted.

The discipline, in one line

Our model list is generated from the provider's live catalogue and labelled by where each model actually processes a request.

If we retyped it, the copy would be right on the day it was written and wrong every day afterwards.

  • 01
    Generated. The website, the product and the agent index read one file.
  • 02
    Classified. Every model labelled by where the request lands.
  • 03
    Refused in words. No silent reroute, ever.
⎯⎯ Book the strategic assessment ⎯⎯

Your private AI, inside your control ·

We will run the residency arithmetic against your actual obligations and tell you what it costs in capability before you decide.