Supported models
Every model you can call through HASP — across Assistant, Studio, the Public API, and the Agent SDK — covered by the same BAA, the same audit chain, and the same PHI handling.
Last updated
One catalog, every surface. HASP routes through direct integrations with each AI provider under HASP-held BAAs. The models below are available identically from Assistant chat, AI Studio, the Public API, and the Agent SDK. Choosing a model is configuration, not a separate product.
BAA coverage applies to every model on this page. Each inference provider is a sub-processor under a HASP-direct BAA — see the sub-processor register for the contractual relationship and data scope. HASP's PHI handling pipeline runs before any prompt leaves our substrate, so the model never receives unredacted PHI unless the org's policy explicitly allows it.
What more than one provider buys you
A deployment built against a single AI provider inherits that provider's bad days and that provider's pricing. Calling every model through HASP removes both constraints — without you holding a separate agreement with each provider.
Redundancy through an outage
Frontier providers all post public status pages because they all have incidents. When your default model is unavailable, HASP routes the request to a healthy model on another provider — automatically, with no admin paged. The work doesn't stop.
No vendor lock-in
When a different provider ships a meaningfully better model, switching your org's default is a setting change — not a new contract, security review, or integration sprint. The BAA, audit chain, and billing relationship stay constant; the provider underneath is a routing detail.
Pricing leverage
If one provider's pricing moves the wrong way, you are not trapped. Inference is billed in a single normalized credit unit, so moving workloads to a better-priced model is a policy decision — not a re-architecture. Negotiated rate improvements reach you through the credit multiplier.
Right model for the task
Providers lead at different things, and within a provider the tiers trade cost for capability. Run a lightweight model for high-volume classification and extraction, a high-capability model for hard reasoning — your choice, per workload, on one bill.
Models supported today
| Model | Model ID | Context window |
Credit multiplier
What this number means HASP charges in AI Credits, not raw tokens. The multiplier shows how many credits each model costs relative to the baseline (Claude Sonnet = 1×). A 2× model uses twice the credits per request of a 1× model. Cheaper models like Haiku run below 1×. Your monthly credit balance is shared across all models — you can use any mix. | Default availability |
|---|---|---|---|---|
| Anthropic | 4 models | |||
| Claude Sonnet 4.6 Recommended default for most workloads — strong instruction-following, low cost. | claude-sonnet-4-6 | 1M tokens | 1× | On by default |
| Claude Haiku 4.5 Lightweight, low-latency. Good for high-volume classification, extraction, summarization. | claude-haiku-4-5 | 200K tokens | 0.3× | On by default |
| Claude Opus 4.6 Higher-capability tier. Opt-in per org due to cost. | claude-opus-4-6 | 1M tokens | 1.7× | Admin opt-in |
| Claude Opus 4.7 Latest Opus generation. Opt-in per org due to cost. | claude-opus-4-7 | 1M tokens | 1.7× | Admin opt-in |
| OpenAI | 5 models | |||
| GPT-5.5 High-capability flagship for coding and professional work. Opt-in per org due to cost. | gpt-5.5 | 1M tokens | 1.7× | Admin opt-in |
| GPT-5.5 Pro Highest-precision variant of GPT-5.5. Opt-in per org due to cost. | gpt-5.5-pro | 1M tokens | 10× | Admin opt-in |
| GPT-5.4 General-purpose model for complex professional work. | gpt-5.4 | 1M tokens | 0.8× | On by default |
| GPT-5.4 mini Faster, lower-cost model for high-volume workloads, coding, and computer use. | gpt-5.4-mini | 400K tokens | 0.25× | On by default |
| GPT-5.3 Codex Optimized for agentic coding tasks. | gpt-5.3-codex | 400K tokens | 0.6× | On by default |
All inference is billed in AI Credits using a model-relative multiplier. The multiplier is the only variable cost difference between models — every other HASP control (PHI handling, audit chain, BAA, retention) is identical.
How credits map to model usage
HASP prices inference in AI Credits, not provider-native tokens. One credit equals 1,000 Sonnet-equivalent tokens. Each model on the catalog above multiplies that base by its credit multiplier — Sonnet at 1.0× is the reference; Haiku at 0.3× costs less, the high-capability models cost more.
Why a normalized unit? You compare tiers against one number, not five provider price sheets. When HASP negotiates better rates with an upstream provider, the multiplier comes down without rewriting your invoicing logic. When a new generation lands, it slots into the same math.
Use the pricing calculator to model your mix and see the per-tier numbers in context.
Choosing which models your org uses
Model access is an org-admin setting, configurable from Settings → Workspace → AI controls. Three controls:
- Default model. The model picked when a caller doesn't specify one (single value per org).
- Allowed models. An allowlist of models permitted in your org. If the list is empty, every supported model is allowed; populate it to lock your team (and any agents) to a subset.
- Disallowed providers. A blocklist of upstream providers — useful when you've committed to a single-provider posture and want a hard rail against accidentally calling another.
Changes take effect immediately. Every change is logged to the audit chain — who made it, the prior value, and the new value.
Why higher-tier models are off by default
Higher-capability models carry higher credit multipliers. A team that reaches for a premium model when a lighter one would do the job will burn through their credit allotment faster than the workload requires. To prevent that surprise, models with a multiplier above 1.0× ship in the opt-in state for every new org. An admin enables them when the work calls for them — by name, with the audit entry to match.
Once enabled, the model behaves identically to any other model in the catalog — same BAA, same PHI handling, same audit chain. Only the credit multiplier and the org-policy approval differ.
How new models reach this page
New models land in three steps:
- Provider BAA coverage confirmed. The new model only appears on this page after the upstream provider has confirmed the model is covered by our existing BAA — no PHI flows to a model until that's written.
- Sub-processor notice (if the provider is new). Adding a new provider is a sub-processor change under DPA §5. Customers get 30 days' advance notice and an objection window. Adding a new model from an existing provider does not trigger this notice — the sub-processor relationship is unchanged.
- Catalog entry published. The model appears on this page with its credit multiplier, context window, and default-on / opt-in state. New higher-tier models always land as opt-in.
What happens when a model is retired
Providers retire models on their own schedules. HASP's policy:
- 90 days' notice. Once an upstream provider announces a retirement date, HASP posts the deprecation on this page and emails admins of any org that has called the model in the prior 30 days.
- Migration guidance. The notice names the recommended successor model (typically the same family, next generation) and links to any behavioral differences in the docs.
- Wire-level retirement. After the deprecation date, calls to the retired model
ID return
410 MODEL_RETIREDwith a pointer to the successor. The audit chain captures the retirement event and any post-deprecation call attempts.
No models are currently in a deprecation window. When one is, it appears here with the retirement date and recommended successor.