Which intelligence does the work, and who decides.
The Models category answers a narrow question with wide consequences: what kinds of machine intelligence are available, and how is one selected for a given task? The answer is deliberately not “the best model, for everything.”
A model is a component, not the product.
Three separate decisions are in scope, and they are routinely confused for one. Capability level — frontier models handle difficult reasoning, synthesis and judgement, where superior capability materially changes the answer. Weight and licence access — open-weight models can be pinned, inspected and versioned rather than changing underneath the system, and open weights do not by themselves imply weaker capability. Deployment and data boundary — private and local execution runs inside controlled infrastructure, which is what makes high-volume interpretation economically and privately viable. These are independent axes, not three species of model: one model can be frontier-capability, open-weight and privately deployed at the same time.
A fourth worker sits outside this category entirely and usually wins: deterministic software. If a question is a calculation, a join, a reconciliation or an exact business rule, it should not be a model at all. Allowing the model to lose is a design position, not a limitation.
Selection, adaptation, and not being trapped.
- Selection. Matching a task to the cheapest worker that can do it correctly, on measured performance rather than reputation.
- Adaptation. Making a model better at a specific company’s work — through fine-tuning, parameter-efficient adapters, or narrower task specialization.
- Efficiency. Quantization and related techniques, which decide how much capability fits in the hardware actually available.
- Independence. Routing and fallback, so no single vendor, model family or API is load-bearing for the operating system as a whole.
The three axes above describe what can be used. Adaptation, fine-tuning, LoRA and task-specific specialization describe how one is made fit for a particular job. Quantization decides what will run on the hardware in front of it. Evaluation and benchmarking is the only honest way to choose between all of them, and multi-model fallback and model-agnostic routing turn those choices into something that survives a vendor changing its pricing, its API or its behaviour.
Model quality is measured on the actual workload, not on public leaderboards — see Evaluation & Reliability for how that measurement is done and how it keeps working after deployment.
Eleven capability pages sit in this category. Availability in the platform is not a claim that every one is used on every engagement.