Cloud Model Reference¶
Anthropic Claude Models¶
Source: docs.anthropic.com (2026-09-03), Claude 5 rows verified against platform.claude.com/docs
(2026-09-25). All models take max_tokens. temperature / top_p (0.0–1.0) are accepted by
Sonnet 4.6, Opus 4.6 and older; Opus 4.7, Opus 4.8, Opus 5, Sonnet 5 and Fable 5 reject them with a
400, and the app omits them for those models. See
Model Parameter Capabilities.
| Model | Context Window | Max Output Tokens | Notes |
|---|---|---|---|
| claude-fable-5-1 | 1,000,000 | 128,000 | 1M default |
| claude-opus-5 | 1,000,000 | 128,000 | 1M default |
| claude-sonnet-5 | 1,000,000 | 128,000 | 1M default |
| claude-fable-5 | 1,000,000 | 128,000 | 1M default |
| claude-opus-4-8 | 1,000,000 | 128,000 | 1M default, no beta header required |
| claude-opus-4-7 | 1,000,000 | 64,000 | 1M default |
| claude-opus-4-6 | 1,000,000 | 64,000 | 1M default |
| claude-opus-4-5-20251101 | 200,000 | 64,000 | Dated snapshot |
| claude-opus-4-1-20250805 | 200,000 | 32,000 | Dated snapshot |
| claude-opus-4-20250514 | 200,000 | 32,000 | Dated snapshot |
| claude-sonnet-4-6 | 1,000,000 | 64,000 | 1M default |
| claude-sonnet-4-5-20250929 | 200,000 | 64,000 | Dated snapshot |
| claude-sonnet-4-20250514 | 200,000 | 64,000 | Dated snapshot |
| claude-haiku-4-5-20251001 | 200,000 | 64,000 | Dated snapshot |
Older Claude 3.x / 4.0-4.5 models cap at 200K by default; they can be extended to 1M via the context-1m-2025-08-07 beta header. Opus 4.6+ and Sonnet 4.6+ no longer require it.
OpenAI Chat Models¶
Source: platform.openai.com/docs/models (2026-09-03).
Chat Completions Models (text-in, text-out)¶
| Model | Context Window | Max Output Tokens | API Params |
|---|---|---|---|
| GPT-5 series | |||
| gpt-5.6-luna | 1,050,000 | 128,000 | max_completion_tokens, no temperature |
| gpt-5.6-sol | 1,050,000 | 128,000 | max_completion_tokens, no temperature |
| gpt-5.6-terra | 1,050,000 | 128,000 | max_completion_tokens, no temperature |
| gpt-5.5 | 1,050,000 | 128,000 | max_completion_tokens, no temperature |
| gpt-5.5-pro | 1,050,000 | 128,000 | max_completion_tokens, no temperature |
| gpt-5.4 | 1,050,000 | 128,000 | max_completion_tokens, no temperature |
| gpt-5.4-mini | 400,000 | 128,000 | max_completion_tokens, no temperature |
| gpt-5.4-nano | 400,000 | 128,000 | max_completion_tokens, no temperature |
| gpt-5.4-pro | 1,050,000 | 128,000 | max_completion_tokens, no temperature |
| gpt-5.3-chat-latest | 128,000 | 16,384 | max_completion_tokens, no temperature |
| gpt-5.2 | 400,000 | 128,000 | max_completion_tokens, no temperature |
| gpt-5.2-pro | 400,000 | 128,000 | max_completion_tokens, no temperature |
| gpt-5.2-chat-latest | 128,000 | 16,384 | max_completion_tokens, no temperature |
| gpt-5.1 | 400,000 | 128,000 | max_completion_tokens, no temperature |
| gpt-5.1-chat-latest | 128,000 | 16,384 | max_completion_tokens, no temperature |
| gpt-5 | 400,000 | 128,000 | max_completion_tokens, no temperature |
| gpt-5-mini | 400,000 | 128,000 | max_completion_tokens, no temperature |
| gpt-5-nano | 400,000 | 128,000 | max_completion_tokens, no temperature |
| gpt-5-pro | 400,000 | 128,000 | max_completion_tokens, no temperature |
| gpt-5-chat-latest | 128,000 | 16,384 | max_completion_tokens, no temperature |
| GPT-4.1 series | |||
| gpt-4.1 | 1,047,576 | 32,768 | max_tokens, temperature |
| gpt-4.1-mini | 1,047,576 | 32,768 | max_tokens, temperature |
| gpt-4.1-nano | 1,047,576 | 32,768 | max_tokens, temperature |
| Reasoning (o-series) | |||
| o3 | 200,000 | 100,000 | max_completion_tokens, no temperature |
| o3-pro | 200,000 | 100,000 | max_completion_tokens, no temperature |
| o3-mini | 200,000 | 100,000 | max_completion_tokens, no temperature |
| o4-mini | 200,000 | 100,000 | max_completion_tokens, no temperature |
| o1 | 200,000 | 100,000 | max_completion_tokens, no temperature |
| o1-pro | 200,000 | 100,000 | max_completion_tokens, no temperature |
| GPT-4o series | |||
| gpt-4o | 128,000 | 16,384 | max_tokens, temperature |
| gpt-4o-mini | 128,000 | 16,384 | max_tokens, temperature |
| Legacy | |||
| gpt-4-turbo | 128,000 | 4,096 | max_tokens, temperature |
| gpt-4 | 8,192 | 4,096 | max_tokens, temperature |
| gpt-3.5-turbo | 16,385 | 4,096 | max_tokens, temperature |
The o3-pro and o1-pro rows are catalog-sourced at 200,000 context tokens and now appear in
the Agents config dropdown alongside the other supported reasoning models.
API Parameter Rules¶
| Model Family | Token Param | Temperature | reasoning_effort |
|---|---|---|---|
| gpt-5.x, o1, o3, o4 | max_completion_tokens |
Not supported | Model-dependent tiers (see below) |
| gpt-4.x, gpt-4o, gpt-3.5 | max_tokens |
Supported | Not supported |
The per-model tier list is the source of truth in config/model_capabilities.json, not this table.
Specialized (not Chat Completions)¶
- Deep research: o3-deep-research, o4-mini-deep-research
- Codex: gpt-5.1-codex, gpt-5-codex
- Realtime/Audio: gpt-realtime, gpt-audio, gpt-4o-audio-preview
- Image: gpt-image-1.5, gpt-image-1
- TTS/Transcribe: gpt-4o-mini-tts, gpt-4o-transcribe
Model Parameter Capabilities and Reasoning Effort¶
Which request parameters a model accepts is catalog knowledge, not something the
provider APIs report. config/model_capabilities.json is that catalog, keyed by model
id (version, verified_at, sources, then models):
"gpt-5.6-luna": {
"supports_temperature": false,
"supports_top_p": false,
"effort_levels": ["none", "low", "medium", "high", "xhigh", "max"],
"default_effort": "medium"
}
get_model_capabilities(provider, model) in src/services/provider_model_catalog.py
resolves it, and everything downstream consumes that one answer:
| Consumer | Behaviour |
|---|---|
llm_client.py (OpenAI) |
Sends temperature only when supports_temperature; sends reasoning_effort only when the configured tier is in effort_levels. |
llm_client.py (Anthropic) |
Sends temperature only when supports_temperature (Opus 4.7+/4.8/5, Sonnet 5, Fable 5 reject it); sends output_config.effort only for a listed tier. |
codex_app_server_client.py |
Never sends sampling parameters. Tiers are discovered live from model/list (supportedReasoningEfforts, defaultReasoningEffort); the configured tier is passed as the turn/start.effort override. |
model_supports_variable_temperature() (src/utils/model_validation.py) |
Thin wrapper over the resolver; openai_chat_client.py and the RAG / enrichment paths keep calling it unchanged. |
GET /api/workflow/provider-options |
Returns model_capabilities per provider so the Agents page can gate the Temperature / Top_P sliders (disabled with a "Not supported by this model" note, never hidden) and populate the Effort select. |
PUT /api/workflow/config |
Rejects an {Agent}_effort the resolved model does not list (Codex tiers are live, so only the token shape is checked there). |
Fallback rule. A model id with no entry does not raise. The resolver falls back to
the legacy name-prefix heuristics (o1/o3/o4/gpt-5* reject sampling; everything
else accepts it) with no effort tiers, so an unclassified model runs with provider
default effort and no Effort control in the UI until someone adds its entry.
Per-agent effort. Effort is an optional per-agent field in the v2 config contract
(src/config/workflow_config_schema.py), flat key {Agent}_effort, None = provider
default. Extractors inherit ExtractAgent_effort when they have no value of their own.
The default is always "Provider default": the shipped presets and existing DB configs
carry no effort and need no edit. Higher tiers spend more tokens per call.
Provider defaults (verified 2026-09-04). OpenAI: gpt-5.1 / 5.2 / 5.4 default none,
gpt-5 and o-series medium, gpt-5.5 / 5.6 medium; *-pro models are Responses-API only
and are not callable through the app's /v1/chat/completions path. Anthropic: default
high everywhere; xhigh exists on Opus 4.7+, Opus 5, Sonnet 5 and Fable 5 but not on
Opus/Sonnet 4.6; Opus 4.5 takes low|medium|high; Haiku 4.5 and Sonnet 4.5 have no
effort control.
Keeping the file current. Two mechanisms split the work:
- Gaps (a new id with no entry) are detected in-app. The daily
update_provider_model_catalogsjob (scripts/maintenance/update_provider_model_catalogs.py, cron0 4 * * *) already fetches the provider model lists; after writing the catalog it diffs them againstconfig/model_capabilities.json, prints a⚠️line per gap, and the Celery task logs a WARNING and returnsunclassified_models: ["openai:<id>", ...]in its result payload, visible in the Scheduled Jobs UI. - Values (tier lists, sampling support) have no API source. The
refresh-model-context-windowsskill (.claude/skills/refresh-model-context-windows/) verifies each existing entry against the current OpenAI and Anthropic docs alongside its context-window check. - Runtime drift alarm. When the file marks a model
supports_temperature: trueand OpenAI rejects the value anyway, the existing 400 retry logsCAPABILITY DRIFT: ... <model>and continues without temperature. That WARNING is the production signal that a value is stale.
Codex Subscription Provider (Workflow Only)¶
Huntable also supports an optional, deployment-managed Codex subscription for workflow inference. This is distinct from the OpenAI API and from the API-oriented Codex model identifiers above: it uses Codex-managed ChatGPT authentication, not an API key.
Set WORKFLOW_CODEX_ENABLED=true, authenticate the shared workflow-worker
state with docker compose exec workflow_worker codex login --device-auth, and
select one of the models the managed Codex login reports in the workflow
configuration UI. The device-code flow is what works from inside a container;
plain codex login waits on a container-local browser callback the host cannot
reach.
WORKFLOW_CODEX_MODEL supplies the fallback when that model list is
unavailable. Use POST /api/settings/codex/test to test the subscription
without running a workflow. See Configuration
for setup and API Reference for
provider discovery.
Cloud Model Versioning: Bare Names vs. Dated Snapshots¶
Both OpenAI and Anthropic publish two kinds of model identifiers for the same generation.
Bare names (no date suffix)¶
Examples: claude-sonnet-4-6, gpt-4o
These are floating aliases. The provider updates what they point to on their end without
any change on your side. When Anthropic ships an improvement to the Sonnet 4.6 family, calls
to claude-sonnet-4-6 automatically pick it up.
Use these for normal production workflows. You get provider improvements for free.
Dated snapshots¶
Examples: claude-sonnet-4-5-20250929, gpt-4o-2024-05-13
These are frozen. That exact model version is preserved indefinitely. The date is part of the identifier, not metadata.
Use these when reproducibility matters: eval baselines, regression comparisons, or any case where a silent model update could change your output in a way you would not immediately notice.
How this project handles them¶
The dropdown in the Agents config panel shows the result of filter_anthropic_models_latest_only
(in src/utils/model_validation.py). That filter keeps only one representative per family,
preferring: bare name > -latest suffix > most-recent dated snapshot. So if both
claude-sonnet-4-5 and claude-sonnet-4-5-20250929 are in the catalog, only the bare name
reaches the UI.
If you need a frozen snapshot for eval work, add the dated identifier directly to
config/provider_model_catalog.json. It will survive until the next catalog refresh
overwrites it, so note it externally if you need it long-term.
Quick reference¶
| Identifier type | Updates automatically | Use when |
|---|---|---|
Bare (claude-sonnet-4-6) |
Yes, provider-controlled | Normal workflows |
Dated (claude-sonnet-4-5-20250929) |
No, frozen forever | Evals, baselines, audits |
See Model Selection Guide for choosing between cloud and local models, and Context Window Rationale for why cloud defaults differ from the 16K local default.
GPT-4o and GPT-4o-mini for Strict Literal Extraction¶
When using cloud models for extraction tasks, the GPT-4o family is among the strongest available options for strict literal extraction. Both gpt-4o and gpt-4o-mini follow explicit "extract only what is stated" instructions with high fidelity, and gpt-4o in particular handles ambiguous phrasing without over-reaching into inference.
gpt-4o is the preferred choice for precision-critical extraction at scale. It handles edge cases, partial patterns, and ambiguous attribution language more consistently than any other cloud model tested, and it adheres to fail-closed instructions (return empty rather than infer) without needing heavy scaffolding.
gpt-4o-mini is a viable alternative when cost is a constraint. It requires more explicit prompting: additional guardrails, redundant "do not infer" instructions, and worked examples for edge cases, to match the behavior that gpt-4o produces from leaner prompts.
Eval Signal Transfer Between gpt-4o-mini and gpt-4o¶
Improvements measured on gpt-4o-mini do not reliably predict the same improvements on gpt-4o. Directional improvement may carry over, but magnitude and even sign can change. See Extract Agent Evaluation for the eval methodology and metrics referenced throughout this section.
Capability ceiling vs. constraint sensitivity¶
gpt-4o-mini is more instruction-fragile. Tightening prompts, adding explicit gates, or strengthening schema constraints often produces large score gains. gpt-4o already handles ambiguity better; the same constraints can yield smaller gains or occasionally regress by over-constraining a model that did not need the guardrails.
Error profile shifts¶
The two models fail in different directions. gpt-4o-mini tends to under-extract or miss edge cases; improvements typically come from clarity and redundancy. gpt-4o tends to over-generalize or fill gaps creatively; improvements typically come from stricter fail-closed rules and negative examples. A change that fixes under-extraction in mini may not address, and could worsen, over-extraction in the full model.
Prompt compression tolerance¶
gpt-4o is more robust to shorter prompts; removing redundancy can help. gpt-4o-mini benefits from explicit repetition and checklists. A prompt that was cleaned up to help gpt-4o can hurt mini, and vice versa.
Schema adherence¶
gpt-4o-mini improves markedly with rigid JSON examples and strong validation cues. gpt-4o usually adheres to schema without extra scaffolding; additional structure can be neutral or mildly negative.
Practical transfer expectation¶
Treat improvements on mini as hypothesis-generating, not predictive. Expect roughly 60-80% directional transfer on well-scoped, mechanical changes such as clearer field names or explicit "EXCLUDE if..." rules. Expect low transfer on changes that add verbosity, redundancy, or heavy guardrails; those changes are compensating for mini's specific weaknesses, not improving the prompt in a model-agnostic way.
Recommended workflow¶
- Use gpt-4o-mini for rapid iteration: cheaper signal, faster turnaround.
- Re-run the top candidate prompt variants on gpt-4o before treating any change as a regression or improvement.
- Track delta by failure mode (misses vs. false positives), not just aggregate score. A change that shifts the failure mode without improving aggregate score may still be worthwhile.
- Maintain model-specific prompt variants in presets if the optimal prompts for the two tiers diverge significantly.
Last updated: 2026-07-03 Last reviewed: 2026-09-01