Model Selection

Prospector Studio is not built around a single model. Every agent, workflow, and knowledge base picks the model that fits the job — and you can change that choice at any time, per agent, without redeploying anything.

That matters because the model is a business decision, not just a technical one. A model that reads ten thousand alerts an hour has different economics to one that writes the incident report your client's board will read. Pinning yourself to one model means overpaying for the first job or under-delivering on the second.

So we give you tiers. Pick the tier that matches the work, change it when the work changes.

The four tiers

Every model in the catalog sits in one of four tiers. The tier tells you what the model is good at and roughly what it will cost you against your contract.

Switching tiers

Tiers are a default, not a cage. If a tier is not right for you, change it:

• Per agent. Every agent has a model setting. Change it in the UI or through the GraphQL API and the next invocation uses the new model. No redeploy, no downtime.
• Per workflow step. A single workflow can triage on a Fast model and escalate the interesting five percent to Frontier. That is usually where the best economics live.
• Org-wide defaults. Set the default tier for your organisation so new agents inherit it, and let individual teams override where they have a reason to.
• Restrict the list. If there are tiers or providers you do not want your people using — for cost, for policy, or because your legal team has opinions about a particular vendor — we can hide them entirely. Your catalog shows only what you have approved.

Available models

This list is generated directly from the Amazon Bedrock catalog — it is what is actually callable, not a marketing list. Last refreshed from the live API on 2026-08-07.

How this stays private inside Bedrock

Every model in the list above is invoked through Amazon Bedrock, in the AWS account that hosts your deployment.

What that gives you:

• Your inputs and outputs are not used to train models. AWS states that Bedrock does not use customer prompts or completions to train the underlying foundation models, and does not share them with the model providers.
• Nothing crosses the public internet. Bedrock is reachable over an interface VPC endpoint (AWS PrivateLink), so traffic from your workloads to the model stays on the AWS network. An egress-free deployment is a supported configuration.

One thing to be aware of: we sometimes use global inference, where a request is served from whichever region has capacity rather than a fixed one. If you have a data-residency requirement, raise it early and we will scope your deployment around it.

Privately hosted, fine-tuned models

The catalog above is the shared foundation-model layer. Alongside it we host models we have fine-tuned for security work, and those never sit on shared infrastructure.

We can also self-host models on your own infrastructure, so inference does not go through Bedrock at all. If that is a requirement for you, talk to us about what it would take for your environment.

Consumption rates and your contract

Models do not consume your allowance at the same rate. A Frontier model does substantially more computation per request than a Fast one, and that difference is reflected in what it draws down.

The usage rate column tells you which band a model falls in:

What actually drives consumption, beyond the band:

• Tokens in and out. A long knowledge-base context costs more than a short prompt, on every model.
• Reasoning depth. Models that think before answering spend tokens doing it. That is the point of them, and it is also why they sit in the higher bands.
• Tool-calling loops. An agent that calls six connectors before answering ran six more inference passes than one that answered directly.
• Provisioned throughput. Reserved capacity is billed on time held rather than tokens used — better for steady, predictable load, worse for bursty work.

How the bands map to units, what is included, and where the ceiling sits are set by your contract — they differ between a shared deployment and a dedicated one, and between commercial and public-sector terms. Prospector Studio reports actual consumption per agent and per workflow, so you can see which parts of your automation are spending the allowance before the invoice tells you.

Next

• Configuring agents — where the model setting lives
• Workflows — routing between tiers inside one automation
• Knowledge bases — where the embedding models in the Specialized tier get used
• Deployment architecture — where Bedrock sits relative to your network

* Models and usage classifications are subject to change without notice.