Skip to main content

Supported models

For the administrator choosing models in the New deployment wizard or a Fleet Configuration Template, and the engineer preparing the target AWS account: Studio runs on Amazon Bedrock in your own AWS account, with one model for each of three classes of work and a fixed model for embeddings. Before you start, know the deployment's region: it decides the inference zone, us or eu.

The three model classes​

Each class is named for the work it does, so its name stays the same when the model behind it changes. The three are deployment-wide settings: Studio users cannot pick a model per agent or per conversation.

ClassWhat it runs (the console's own words)Model in Studio 2.1.0Bedrock model id
Coordinator model (most capable)"Plans the board and coordinates the agents. Also runs the Governor that reviews every run, PII redaction, context summaries, workflow conditions and knowledge-graph updates."Claude Opus 5.5anthropic.claude-opus-5-5
Worker model"Runs each agent's own turns and workflow task steps. Also runs the coder, knowledge-graph builds and search, Optimise prompt, connector guides and schedule text."Claude Sonnet 5.5anthropic.claude-sonnet-5-5
Chat-title model (fastest, lowest cost)"Names each new chat."Claude Haiku 5.5anthropic.claude-haiku-5-5
Embeddings (not a class and not a choice)Every knowledge-graph write embeds its text with itCohere Embed v4cohere.embed-v4:0

Organisations 1.1.0 offers one model per class, and it is the default. Claude 4.x models (Sonnet 4.6, Opus 4.6, 4.7 and 4.8, Haiku 4.5) are no longer offered or accepted: the wizard, a template and an update refuse them, and Studio refuses a run that names one. Choosing the Coordinator model also chooses the model that redacts personal data (PII redaction).

Inference profiles: us. and eu. only​

Claude 5.5 runs on Amazon Bedrock only through cross-region inference profiles, and Studio uses the geography profiles: us. for a deployment in a US region, eu. for one in an EU region. The wizard's Bedrock inference zone is set from the account you pick and checked against the region at launch. Organisations stores the base ids in the table above and adds the zone to all three classes and the embeddings model together, so a deployment in eu-west-2 calls eu.anthropic.claude-opus-5-5, eu.anthropic.claude-sonnet-5-5, eu.anthropic.claude-haiku-5-5 and eu.cohere.embed-v4:0. No model is called outside the deployment's zone. The supported regions are listed in Before you start.

Studio never uses a global. profile, which can route a request to any commercial AWS region. The pickers offer base ids only; Organisations refuses an id that carries a us., eu. or global. prefix ("Enter the base model id anthropic.claude-opus-5-5 without a us., eu. or global. prefix. Organisations adds the geography prefix for the deployment's region."); the quota check reads only the geography profiles' quotas; and the Studio task role denies invoking any global. inference profile.

A geography profile serves a request in one of the regions AWS lists for it, which need not be the deployment's own region:

ProfileCalled fromServed in
us.a US regionus-east-1, us-east-2 or us-west-2
eu.eu-west-2 (London)eu-central-1, eu-north-1, eu-south-1, eu-south-2, eu-west-1, eu-west-2 or eu-west-3

So a request from a deployment in London can be processed in another EU country, inside AWS. The Amazon Bedrock console lists the destination regions for each source region on the inference profile itself. Residency of what Studio stores: Data at rest and in transit.

Model access and Bedrock quotas​

The deployment preflight checks the three models a job is about to write, through the account's registration role, before anything changes: in the wizard's Run preflight, and in the preflight step of every install, upgrade and configuration change.

CheckWhat it readsWhen it is not met
The selected models can be invoked in this account and region (bedrock-model-access)For each class, that the us. or eu. inference profile exists in the region, and Bedrock's model availability for the account: authorisation, availability in the region and the model agreementFailed when the profile does not exist, the account is not authorised for the model or the model is not available in the region. The remediation names the model and the account: "Enable access to Claude Sonnet 5.5 in Amazon Bedrock for account 123456789012." A job stops with bedrock_model_access_refused before its restore point; fix the access and resume. Warning when only the agreement is missing: "Claude Sonnet 5.5 has no model agreement in account 123456789012 yet. The Studio's first call to the model subscribes the account through AWS Marketplace where the model requires it; you can enable access in the Amazon Bedrock console first instead." The job goes ahead.
Bedrock quotas for the selected models meet the recommended floors (bedrock-model-quotas)For each class, the tokens-per-minute quota of its geography profile, in Service Quotas in the deployment's regionWarning, never Failed, when the quota is not set, is zero or is below the floor: "<quota name>: <value> (recommended at least <floor>). Request an increase: <link>". The deployment goes ahead without it; calls to a model whose quota is too low are throttled.

A warning is recorded on the job and, for an update started by a rule, in the rule's History. The quotas the check reads:

ClassQuota name (service Amazon Bedrock)Quota codeRecommended at least (tokens per minute)
Coordinator modelCross-region model inference tokens per minute for Anthropic Claude Opus 5.5L-A44306972,000,000
Worker modelCross-region model inference tokens per minute for Anthropic Claude Sonnet 5.5L-94A31E462,000,000
Chat-title modelCross-region model inference tokens per minute for Anthropic Claude Haiku 5.5L-47520EB7200,000

The same code covers the us. and eu. profiles. AWS publishes no requests-per-minute quota for these profiles, so none is read, and the global. quotas are never read.

Steps: prepare the account​

  1. Before you install or upgrade, enable access to the three Claude 5.5 models. Sign in to the target AWS account, switch to the deployment's region, open the Amazon Bedrock console and choose Model access. Request access to Claude Opus 5.5, Claude Sonnet 5.5 and Claude Haiku 5.5, and wait until each shows access granted. Also check that Cohere Embed v4 can be used there. The deployment preflight refuses a model the account cannot invoke.
  2. Keep aws-marketplace:ViewSubscriptions and aws-marketplace:Subscribe allowed in the Studio account; Bedrock checks them on that first call (SCPs and guardrails).
  3. Run the wizard's preflight. For each quota warning, open its link (https://<region>.console.aws.amazon.com/servicequotas/home/services/bedrock/quotas/<code>) signed in to the deployment's account and request an increase; AWS decides the request.

Choose the models​

In the New deployment wizard's Parameters step (Deploy your first Studio), the Models section has one picker per class, Coordinator model (most capable), Worker model and Chat-title model (fastest, lowest cost), each with what it runs beneath it. A picker lists only its own class's models, each as product name and id ("Claude Opus 5.5 · anthropic.claude-opus-5-5"), and starts on the default, "Default: Claude Opus 5.5 · anthropic.claude-opus-5-5". Review and launch repeats them as Coordinator model, Worker model and Chat-title model.

Change the models after install​

Models change through a Fleet Configuration Template and an Update Manager rule; the Overview shows them but does not edit them.

  1. Open Fleet Configurations and create or edit a template. Under Models ("The model each class of work runs on. A template names all three."), choose the model for each class.
  2. Open Update Manager and point a rule at the template and the deployment. The target preview names each class that differs, for example "Coordinator model: anthropic.claude-opus-4-6-v1 → anthropic.claude-opus-5-5".
  3. When the rule fires, the update job writes all three class ids with the deployment's zone, and every service's own copy of the Worker model id; the services restart on them. A job changes the three classes together, never one alone.

A deployment must run Studio 2.0.20 or later to change models; on an earlier release the change is refused (Upgrading from Claude 4.x). The mechanics are those of any update: Fleet configurations and Update Manager.

Upgrading from Claude 4.x​

Upgrade Organisations to 1.1.0 first: Studio 2.1.0 is offered only to an Organisation on 1.1.0 or later. Then upgrade each Studio deployment to 2.1.0. The upgrade checks model access in its preflight, then sets the three Claude 5.5 models for the deployment's zone, whatever the deployment ran before, and every service's copy of the Worker model id follows. Existing conversations carry on with the new models.

Organisations 1.1.0 launches Studio 2.0.20 or later only, and updates a deployment only to 2.0.20 or later, because every launch and update writes the Claude 5.5 models and an earlier release cannot call them. Launching an earlier release, updating a deployment to one (by a rule or through the API), or changing the models of a deployment that still runs one is refused with release_lacks_model_classes_support before anything is created or changed: "Organisations sets Claude 5.5 models, which need Studio 2.0.20 or later; <version> is older." A template can still name an earlier release; a rule that applies it records "Not updated, because Claude 5.5 models need Studio 2.0.20 or later: <names>." in its History. A deployment that still runs an earlier release keeps running it, and a configuration change that names no model still applies to it. The only way back to a release before 2.0.20 is Roll back… on the deployment's Overview, which returns the services to the restore point of the last completed update or configuration change (Deployment detail).

The restore point an upgrade captures includes the model ids, the effort settings and the streaming speed settings below. If the upgrade fails after that point, or you roll the deployment back, the rollback writes them back, so a Studio rolled back returns to its previous models, and the Overview shows them (Updates and rollback).

Effort settings​

Every call to a Claude 5.5 model carries an effort level, which sets how hard the model works on that call. Higher effort gives better results and takes longer and more output tokens. Studio sets the level by role, from four keys in the Studio account's alphaagent-common-config secret in AWS Secrets Manager, beside the three model ids:

KeyApplies toDefault
COORDINATOR_EFFORTThe Coordinator model's work: board turns, PII redaction, context summaries and knowledge-graph updatesxhigh
WORKER_EFFORTThe Worker model's work: agent turns, workflow task steps, knowledge-graph builds and search, Optimise prompt, connector guides and schedule text (the coder sets its own)xhigh
GOVERNOR_EFFORTThe Governor and workflow conditions, on the Coordinator modelhigh
CHAT_TITLE_EFFORTChat titles, on the Chat-title modellow

Each takes low, medium, high, xhigh or max. The coordinator and the worker default to xhigh: it answers hard prompts in full and starts answering far sooner than max, which can spend its whole output allowance reasoning. Set max only if you accept much longer waits.

  1. In the Studio account, open AWS Secrets Manager in the deployment's region and the secret alphaagent-common-config.
  2. Edit the key's value and save.
  3. The services read the secret when they start, so the value applies after the next update or configuration change from Organisations, which restarts every service.

No screen in Organisations or Studio shows or edits these keys. An install writes the defaults, and an update adds any missing key with its default; neither an update nor a configuration change overwrites a value you set. A restore point captures them, and a rollback restores them.

Streaming speed settings​

Five keys in the same alphaagent-common-config secret tune the speed check that raises the banner described in Banners you may see. Each takes a whole number, and an absent key uses its default:

KeyMeaningDefault
BEDROCK_THROTTLE_TPS_THRESHOLDThe banner shows when active streaming runs below this many tokens per second30
BEDROCK_THROTTLE_WINDOW_SECONDSThe length of the measuring window, in seconds15
BEDROCK_THROTTLE_CYCLE_SECONDSHow often the check runs, in seconds60
BEDROCK_THROTTLE_MIN_ACTIVE_SECONDSThe least streaming time in a window that counts, in seconds2
BEDROCK_THROTTLE_BANNER_TTL_SECONDSHow long the banner stays after the last throttled reading, in seconds60

Time the model spends reasoning, or running tools, does not count as slow streaming. Change a value in Secrets Manager as for the effort keys above; the services read it when they start. No screen edits these keys.

What you should see​

  • The deployment's Overview lists Coordinator model, Worker model and Chat-title model in Configuration, each as product name and id, beside Inference zone. A field that has not been recorded yet shows "—" with a hover explaining when it is recorded.
  • In Studio, the agent page's Model section names the ids each role runs on (Agents: configure and activate), and each workflow step reads Model with the id it runs on, "set by the step type".

Notes​

  • Each class accepts only its own model. Another class's model, a Claude 4.x id or an id outside the table is refused with wrong_class, naming the expected id: "The Coordinator model must be anthropic.claude-opus-5-5."; an id with a zone prefix with zone_prefixed_id_not_allowed. Nothing is queued when a request is refused.
  • The embeddings model is fixed. There is no field for it anywhere in the console.
  • An effort value outside the list, or a missing key, uses that role's default, and the service logs a warning once. Chat titles run with thinking off, which the Chat-title model accepts only up to high, so xhigh and max are treated as high for titles.
  • Agents or knowledge-graph builds fail after a fresh install. Read the job's bedrock-model-access row, then the Bedrock console in the deployment's region, and check that no service control policy denies the Marketplace actions above or any destination region of the profile (SCPs and guardrails).
  • Studio shows a throttling banner. Raise the quota the preflight warned about (Banners you may see).
  • The Overview shows a model you did not choose. A blank class in a draft or template takes the default; an upgrade to 2.1.0 sets the Claude 5.5 models.