A ranking by workload, not a universal leaderboard
A model that writes a persuasive proposal may still misclassify a short service request. A model that solves a difficult coding problem may add unnecessary waiting time to a simple tagging job. The useful question is which model meets the requirements of this task, inside this workflow.
The tiers below are Ghost AI Systems editorial recommendations, informed by the providers’ documented positioning. They are not results from a Ghost benchmark, and order within a row does not imply a winner. We have not measured comparative accuracy, latency, or return on investment for this guide. Treat the examples as a shortlist for your own evaluation.
The public catalogs reviewed on September 25, 2026 list GPT-6 Luna, Sol and Astra; Claude Haiku 4.5, Sonnet 5, Opus 5.5 and Fable 5.1; and Gemini 3.5 Flash-Lite and 3.8 Flash. Google labels those Gemini examples stable; Gemini 3.1 Pro is separately labeled preview. Availability still depends on provider, account, region and platform. A listing is not a promise that your account has access.
Primary sources: OpenAI: public model catalog · Anthropic: model overview and availability · Google: Gemini API models and release status
AI model comparison by task
Read each row as a starting point. These tiers describe how we would allocate work, not an intrinsic limit on what a model can do. Lightweight models can handle demanding work when the task is sufficiently constrained.
On smaller screens, scroll the table horizontally. Recommendations are editorial; examples are not ranked within tiers.
| Use case | Tier & public examples | Tradeoff | Escalation rule |
|---|---|---|---|
| Repetitive, bounded workClassify inbound requests, extract fields, normalize CRM notes. | LightweightGPT-6 Luna · Claude Haiku 4.5 · Gemini 3.5 Flash-Lite | Start here when the task is narrow and the answer is easy to check. Test ambiguous inputs before automating. | Missing required fields, conflicting evidence, or repeated validation failures → general model or human queue. |
| Everyday demanding workDraft sourced proposals, implement scoped code changes, synthesize documents. | Strong general modelsGPT-6 Sol · Claude Sonnet 5 / Opus 5.5 · Gemini 3.8 Flash | Our default shortlist for work with several constraints. Compare total review effort as well as response cost. | A reproducible failure remains after correcting context and instructions → deep reasoning. |
| Hard, unresolved problemsInvestigate a stubborn bug, compare system designs, reconcile competing hypotheses. | Deep reasoningGPT-6 Astra · Claude Fable 5.1 | Reserve more inference budget for a documented difficulty. A larger model can still be wrong. | No verifiable improvement → collect new evidence or involve a specialist. Do not retry indefinitely. |
Primary sources: OpenAI: public model catalog · Anthropic: model overview and availability · Google: Gemini API models and release status
ChatGPT is a product; a model is one part of it
Keep the interface, model and workflow separate. ChatGPT is an application that provides access to models and tools. A model name identifies the engine; search, file access, instructions and connected systems determine what that engine can actually use. A subscription experience and an API integration are not interchangeable test conditions.
Record the exact public model ID and available settings when evaluating. “Gemini 3.8” is not specific enough when the catalog includes Flash, Live and speech variants. Similarly, use the full public name GPT-6 Astra or Claude Fable 5.1 instead of an informal nickname. Do not turn an internal alias, rumor, or product label into a model recommendation.
Primary sources: OpenAI: public model catalog · Anthropic: model overview and availability · Google: Gemini API models and release status
Escalate the problem, with the evidence attached
Begin with a strong general model when you do not yet know how difficult a workflow is. Once you have examples of acceptable outputs, try a lighter model on the same cases. Promote a cheaper option only if it continues to meet the requirements. The goal is lower total operating effort, not the lowest price for one response.
When a model fails, inspect the failure before switching. Missing source material calls for better retrieval. An ambiguous request calls for clarification. A bad calculation calls for a calculator or tested function. Only a remaining reasoning failure is a reason to spend more on reasoning.
- Capture the original input, relevant sources, attempted output and failed acceptance check.
- Correct missing context and run one controlled retry under your workflow’s retry budget.
- Escalate unresolved reasoning with a concise failure summary and the same acceptance checks.
- Stop or route to a person if the result is still unsupported, permissions are missing, or the cost limit is reached.
Build a small evaluation before choosing a winner
For a service inbox, use representative past requests with private information removed. Include normal requests, incomplete addresses, contradictory dates, duplicate messages and requests outside your service area. Decide the expected route and required fields before running models. Keep a separate set of examples that you did not use while tuning prompts.
Track whether the answer is correct, whether the source supports it, whether the format is valid, and whether a person had to repair it. Record elapsed time, tool charges, retries and review minutes alongside model usage. A fast answer that needs extensive repair may be the expensive option.
OpenAI’s evaluation guidance recommends explicit objectives, representative datasets, defined metrics and continued evaluation. Our application of that guidance is to keep failed real-world examples in a regression set and rerun it when the model, prompt, source data or tools change. Set the acceptance threshold based on the consequence of a mistake; no generic pass rate fits every business.
Primary sources: OpenAI: evaluation best practices
Your first model-routing workflow
Imagine an HVAC company receiving a request for a maintenance visit. A lightweight model extracts the request type and contact details. Code validates the fields and checks service coverage. A general model drafts a reply using approved availability returned by the scheduling system. A person handles ambiguous or urgent requests. There is little reason to use the heaviest reasoning model on every message.
Save deep reasoning for a different problem: investigating why otherwise valid bookings repeatedly fail across several systems. Supply logs, constraints and a reproducible example. Even then, require tests and human approval before changing production behavior. Heavyweight reasoning is a tool for hard questions, not a guarantee of previously impossible answers.
Sources & review notes
Primary sources reviewed September 25, 2026. Provider documentation can change. Workflow recommendations and examples are our editorial judgment; no original comparative benchmark or client ROI measurement is claimed.