The capability / cost / latency triangle

Every model choice trades off three things:

• Capability — how well it handles the task (reasoning depth, coding, instruction-following, long context, vision).
• Cost — price per input and output token (output is pricier; input can be prompt-cached).
• Latency — how fast it responds (bigger/"smarter" models are usually slower).

There's no universally "best" model — only the best fit for a task's requirements. A high-volume classification endpoint and an overnight autonomous coding agent want opposite ends of this triangle.

Tiers within a family

Providers ship a family of models at different capability/cost points. As a mental model (names vary by provider and change over time):

• Frontier / large tier — most capable, most expensive, slower. For the hardest reasoning, long-horizon agentic work, and correctness-critical tasks.
• Balanced / mid tier — near-frontier quality for most work at lower cost/latency. The default workhorse for production.
• Small / fast tier — cheapest and fastest, weaker on hard reasoning. For simple, high-volume, latency-sensitive tasks (classification, routing, short extractions).

For example, in the Claude family you'd pick from Opus (large), Sonnet (balanced), and Haiku (fast) tiers; OpenAI, Google, and Mistral offer analogous ladders. The names are placeholders — the capability ladder is the durable idea.

Route: don't use one model for everything

A key cost/latency win: route each task to the cheapest model that can do it well. A support assistant might use a fast/cheap model to classify the incoming message and a mid/large model only for the hard replies. This "model routing" (or a cascade: try cheap, escalate on low confidence) can cut cost by an order of magnitude with little quality loss.

from anthropic import Anthropic
client = Anthropic()

def classify(text: str) -> str:
    # Cheap, fast model for a simple, high-volume decision.
    r = client.messages.create(model="claude-haiku-4-5", max_tokens=10,
        messages=[{"role": "user", "content": f"Category (billing/technical/sales): {text}"}])
    return r.content[0].text.strip()

def answer_hard(text: str) -> str:
    # Larger model only when the task genuinely needs the capability.
    r = client.messages.create(model="claude-opus-4-8", max_tokens=1000,
        messages=[{"role": "user", "content": text}])
    return r.content[0].text

Closed vs open-weight models

• Closed / API models (Claude, GPT, Gemini): you call a hosted API. Top capability, no infra to run, but per-token cost, vendor dependency, and your data leaves your environment (subject to the provider's data terms).
• Open-weight models (Llama, Mistral, Qwen, etc.): you can download and run them yourself (on your own GPUs or a cloud GPU). Full control and data residency, no per-token API fee — but you own the infra, scaling, and (usually) a capability gap vs. the frontier closed models.

Choose open-weight when data must stay in-house, you need offline/edge deployment, you have very high volume where self-hosting is cheaper, or you want to fine-tune deeply. Choose closed API for top capability with zero ops — the common default.

Multimodal

Many models are multimodal — they accept images (and sometimes audio/PDF) alongside text, not just text. If your task involves screenshots, documents, charts, or photos (e.g. "extract data from this invoice image", computer-use agents), you need a vision-capable model. Check the specific model's supported input types; capability and cost differ from text-only use.

Provider & deployment (Azure-relevant)

Beyond which model, there's where you run it:

• Direct provider API (e.g. Anthropic's API) — simplest, latest features first.
• Cloud-hosted — the same models offered through Microsoft Azure (Azure OpenAI / Foundry), AWS Bedrock, or Google Vertex — with that cloud's auth, billing, data-residency, and compliance. For enterprise clients (and much of the FR/BE market, where Azure dominates), running models through Azure is often a hard requirement for procurement, data governance, and SSO. Feature availability can lag the direct API, so verify a needed feature is supported on your chosen platform.

For your consultancy and the job market you're targeting, "can you deploy this on the client's Azure tenant?" is frequently as important as raw model quality. You'll go deep on Azure specifics in the Deployment & Cloud track.

Recap

• Model choice trades capability / cost / latency — pick the best fit for the task, not a single "best" model.
• Providers offer a tier ladder (large / balanced / fast); route cheap tasks to cheap models and escalate only when needed.
• Closed API = top capability, zero ops, data leaves your env; open-weight = control, data residency, self-hosting effort. Choose by data/volume/capability needs.
• Use a multimodal model when inputs include images/documents.
• Deployment matters: enterprise/FR-BE work often mandates running models via Azure (or Bedrock/Vertex) — verify feature availability on the target platform.

from anthropic import Anthropic
client = Anthropic()

def route(text):
    triage = client.messages.create(model="claude-haiku-4-5", max_tokens=20,
        messages=[{"role":"user","content":f"Is this a simple FAQ or a hard case? Reply 'simple' or 'hard': {text}"}]
    ).content[0].text.strip().lower()
    model = "claude-opus-4-8" if "hard" in triage else "claude-haiku-4-5"   # escalate only hard cases
    return client.messages.create(model=model, max_tokens=800,
        messages=[{"role":"user","content":text}]).content[0].text