Models & Prerequisites

Every cloud serves a different set of models, and each has setup a customer must do before some of them answer. getAvailableModels() reports what a deployment can invoke right now — use it at runtime rather than hardcoding an id, since the list narrows to what that account has enabled.

Which endpoint each model uses is decided by its protocol; see Behavior.

AWS — Amazon Bedrock

The widest selection of the three clouds: 50 models.

Prerequisites

Since October 2025, Bedrock enables serverless foundation models automatically in commercial regions, and every non-Claude model in Alien's catalog is invocable with no setup at all. Claude is the exception, and it takes two steps rather than one: a model agreement per Claude model, and a use-case form submitted once for the account. Submitting the form from an AWS Organizations management account covers every member account at once.

Neither step needs the console:

# once per account
aws bedrock put-use-case-for-model-access --form-data "$(base64 < form.json)"

# once per Claude model
OFFER=$(aws bedrock list-foundation-model-agreement-offers --model-id "$MODEL" \
  --query 'offers[0].offerToken' --output text)
aws bedrock create-foundation-model-agreement --offer-token "$OFFER" --model-id "$MODEL"

aws bedrock get-foundation-model-availability --model-id "$MODEL"

Agreements are usage-priced with no fixed fee, so accepting them costs nothing until a call is made. get-foundation-model-availability reports agreement, authorization, entitlement, and region status separately, so it tells you which of the four is missing.

The GPT-5 family runs on a different Bedrock endpoint with its own quotas, which count input and output tokens separately rather than together. Raising your Claude quota does nothing for GPT-5, and vice versa.

Check quota on a new AWS account. Quotas are per model and per region, and AWS states that "new AWS accounts might receive reduced quotas." A fresh account can therefore be far below the published defaults, and inference fails in a way that looks like a broken integration rather than a quota. Check Service Quotas for Amazon Bedrock before assuming the deployment is at fault.

Models

claude-opus-5, claude-mythos-5, claude-opus-4.1, claude-sonnet-4 and claude-3-haiku are AWS-only. The GPT-5 family answers on the Responses endpoint and nowhere else — a chat-completions call returns a 400 naming the right endpoint. gpt-oss-20b and gpt-oss-120b answer on both.

Model availability also varies by region. A model enabled in us-east-1 may not exist in another region, so check Bedrock's regional availability table for the customer's region rather than assuming parity.

GCP — Vertex AI

14 models: Gemini and Claude.

Prerequisites

Claude is enabled from Vertex AI Model Garden: find the model, click Enable, and accept Anthropic's terms. It is a per-project step, so a customer who has done it for one project still has to do it for another.

Quota is per region, and the global endpoint has its own pool. A project with room in us-central1 can still be at zero on a global or multi-region endpoint, because those draw from separate allocations. Check the quota page for the region the deployment actually runs in.

Models

Gemini is GCP-only, though Google's Gemma models are on AWS. Calls go to whatever location the deployment runs in — Alien does not reroute per model — and Google serves the 2.5 family in-region but the 3.x models only on its global location. So on a region-pinned deployment the 3.x models will not appear in the model list.

Azure — Azure AI Foundry

12 models: three OpenAI models Alien deploys, and Claude.

Prerequisites

Alien creates the account and deploys gpt-4.1, gpt-4o-mini, and model-router. Claude cannot be automated: the first deployment requires accepting Marketplace terms, which is a portal action no API performs. Once the customer creates the deployment there, Claude appears in getAvailableModels() after the workload next restarts, since the model list is checked once per process.

Quota moved to the subscription in May 2026. It is now tracked per model per subscription rather than per resource, and Global Standard deployments of the same model share one pool across regions. A new subscription can show 0 TPM in every region, which blocks deployment rather than just throttling it. Viewing quota needs the Cognitive Services Usages Reader role; raising it needs Owner or Contributor.

Models

model-router is a single deployment that picks an underlying model per request, defaulting to the cheapest model within a narrow quality band of the best one. Its context window is that of the smallest model it can route to.

Check the region offers all three models before deploying. Alien creates the three deployments together at the GlobalStandard tier and treats any one failing as a failed resource, so a region missing any of them fails the whole thing — mid-provision, after the account already exists, because nothing checks up front.

Most Azure regions are fine. North Europe is a live counter-example: it offers gpt-4.1 and gpt-4o-mini only as provisioned SKUs, not GlobalStandard, and does not offer model-router at all. To check a region before you commit to it:

az rest --method get \
  --url "https://management.azure.com/subscriptions/<sub>/providers/Microsoft.CognitiveServices/locations/<region>/models?api-version=2024-10-01" \
  --query "value[?model.name=='model-router'] | [0].model.skus[?name=='GlobalStandard']"

An empty result means that region will fail.

Local and Kubernetes

Neither uses a cloud catalog. Both take a bring-your-own-key binding, so you can call whatever your key can reach, but getAvailableModels() returns a short built-in list per provider rather than querying it. The only prerequisite is the key: OPENAI_API_KEY for alien dev, or the key inside the external binding on Kubernetes.

When a Model Is Missing

A model absent from getAvailableModels() is almost always one of these, in order of likelihood:

1. A one-time step is outstanding — the agreement and use-case form on AWS, Model Garden terms on GCP, Marketplace terms on Azure. This is the usual answer for Claude, and only for Claude.
2. Quota is zero — common on new accounts and subscriptions, on all three clouds. On AWS a model with no access reads 0 applied quota, so a quota increase does nothing until the access exists.
3. The model isn't offered in that region — availability differs per region on every cloud.

On AWS and GCP none of these fail the deploy: the model list narrows, every other model keeps working, and the model reappears once the customer completes the step. Azure is the exception — a model it cannot deploy, whether from zero quota or from the region not offering it, fails the resource rather than just narrowing the list.

Sources

Cloud requirements change; these are the pages to re-check.

• Bedrock model access · automatic enablement
• Bedrock runtime quotas · regional availability by model
• Claude on Vertex AI
• Foundry quotas and limits · model router