Model Taxonomy

A taxonomy is a systematic classification using stated characteristics. In model selection, those characteristics include the training objective, input/output contract, architecture, available weights, license and deployment. There is no single universally standardized tier system for AI models.

Example: a downloadable 27B vision-language checkpoint can be instruction-tuned, dense in its feed-forward layers, hybrid in its attention layers, and served privately with a particular quantization. These describe different properties of the same model. None establishes its accuracy on your workload.

Current examples checked September 24, 2026. Definitions are stable; provider IDs, model availability and API limits change. The snapshot below includes GPT-6 Sol/Luna, Claude Opus 5.5 and Grok 4.7. Record the exact deployment and recheck its linked contract before changing a production dependency.

In an interview, use classification to narrow a decision. Explain the mechanism, state a requirement, and identify the measurement that would justify the choice.

Table of Contents

• The Taxonomy in One Table
• Foundation, Base, Instruction, and Reasoning Models
• Generalists and Specialists
• Modalities Are Directional
• Reasoning and Inference-Time Compute
• Tools, Agents, and Model Boundaries
• Open Weight Is Not Automatically Open Source
• Architecture and Size
• Lifecycle, IDs, and Versioning
• Context, Output, and Knowledge
• Deployment and Data Control
• Current Model-Family Snapshot
• The Model Passport
• Common Taxonomy Mistakes
• Interview case
• Final summary and notes
• Interview Questions
• Official Sources

The Taxonomy in One Table

No model belongs to only one box. Classify it independently on each axis:

This prevents category errors such as comparing “open source” with “reasoning,” or treating “long context” as a capability tier. A model can be an open-weight, multimodal, MoE, instruction-tuned generalist with tunable reasoning and a 256K context window—all at once.

flowchart TB
    M["One candidate checkpoint + serving endpoint"]
    M --> A["Task: generation, embedding, ranking or classification"]
    M --> B["Contract: inputs, outputs, limits and tools"]
    M --> C["Mechanism: objective, architecture, adaptation"]
    M --> D["Access: weights, license and deployment"]
    M --> E["Operations: lifecycle, region, measured performance"]
    A --> F["Requirements filter, then workload evaluation"]
    B --> F
    C --> F
    D --> F
    E --> F

This is a classification map: its branches are independent questions, not stages executed by the model.

Terms that are useful but informal

Use these labels to form a shortlist, then verify exact model specifications and evaluate the complete application.

Foundation, Base, Instruction, and Reasoning Models

Foundation model

A foundation model is trained on broad data at scale and can be adapted to a wide range of downstream tasks. This is the definition introduced by the Stanford foundation-model report, expressed in practical terms. It covers language, vision and other modalities. An LLM is a language-oriented model; a multimodal foundation model extends the input/output or representation scope. These categories can overlap.

Base or pretrained model

A base checkpoint primarily learns to predict or reconstruct training data. It is useful for research and further training, but it may not reliably follow instructions, refuse unsafe requests, call tools, or maintain a chat contract.

Instruction or chat model

An instruction-tuned model has additional training to respond to instructions and conversational roles. API generalists such as GPT-6 Astra/Sol/Luna, current Claude, Gemini 3.8 Flash, Grok 4.7, and DeepSeek V4.1 Flash expose instruction-following rather than raw next-token-completion behavior.

Reasoning-tuned model

A reasoning-tuned model is optimized to spend additional inference compute on multi-step tasks. In 2026, “reasoning model” is often a mode or configurable capability inside a general model family, not a separate species:

• GPT-6 Astra supports low, medium, high, xhigh, and max; it does not support none or minimal. GPT-6 Sol and Luna also support none; their documented efforts are none, low, medium, high, xhigh, max.
• Gemini 3.8 Flash supports low, medium, and high; minimal returns an error.
• Claude Fable 5.1 and Opus 5.5 use always-on adaptive thinking; Sonnet 5 supports adaptive thinking; Haiku 4.5 supports manual extended thinking.
• Grok 4.7 supports low, medium, high, and xhigh; reasoning cannot be disabled.
• DeepSeek V4.1 Flash and the still-served V4 Pro support thinking and non-thinking modes.

Therefore “standard model versus reasoning model” is no longer a reliable top-level split. Record the model and its reasoning configuration.

Fine-tuned, distilled, and quantized variants

These labels describe how a model was adapted or served:

• Fine-tuned: additional training changes weights for a domain, task, style, or policy.
• Distilled: a student learns from a teacher’s outputs or internal representations. The student is often smaller, but smaller size is not required by the definition. See distillation.
• Quantized: weights, activations or caches use reduced-precision representations. This can reduce storage and memory traffic; compute speedups depend on kernels and hardware. See quantization.
• Adapter-tuned: a small trainable component modifies behavior while the base weights remain frozen in the usual setup. A LoRA adapter is one example; it is a form of parameter-efficient fine-tuning, not a separate alternative to all fine-tuning.

These are not guarantees of quality. Keep the base checkpoint, adaptation method, quantization, tokenizer, and serving engine in the model identity.

Do not assume every hosted model allows fine-tuning. OpenAI's self-serve fine-tuning is being wound down: access is restricted for new/inactive customers, and new jobs end for active existing customers on January 6, 2027. Existing fine-tuned inference has a separate base-model lifecycle. Check the official transition notice.

Generalists and Specialists

General-purpose generative models

Generalists handle a wide task distribution: writing, analysis, coding, structured extraction, vision understanding, and tool selection. Current examples include GPT-6 Astra/Sol/Luna, the current Claude lineup, Gemini 3.8 Flash, Grok 4.7, Mistral Large 3, Mistral Medium 3.5, Mistral Small 4, and DeepSeek V4.1 Flash.

Use a generalist when the workflow requires flexible instruction following or cross-domain reasoning. Do not use one by default for every ML operation.

Specialist model classes

See embeddings, reranking, voice and document parsing for the corresponding pipeline and evaluation methods.

An embedding model does not generate prose. A vision-capable generalist is not automatically an OCR system. A text model discussing audio is not a speech model. Choose the class before choosing the brand.

Modalities Are Directional

Write modality support as a mapping:

$$\{\text{accepted inputs}\} \rightarrow \{\text{native outputs}\}$$

Examples as of this snapshot:

• GPT-6 general models: text and image input → text output. Calling an image-generation tool does not make image output native to the general model. Audio uses separate models; Sora's Videos API has a September 24, 2026 shutdown date.
• Current Claude models: text and image input → text output.
• Gemini 3.8 Flash: text, image, video, audio, and PDF input → text output.
• DeepSeek V4.1 Flash: text and image input → text output; V4 Pro is text-only.
• GPT-Image-2.5 Sunburst and Flare: text/image conditioning → generated or edited image.
• Realtime voice models: streaming audio/text → streaming audio/text, according to the endpoint contract.

Three distinctions matter:

1. Understanding is not generation. Image input support does not imply image output.
2. A platform is not one model. A provider may expose text, image, speech, and video through separate model families.
3. Native is not preprocessed. A pipeline that transcribes audio and sends text to an LLM is multimodal at the system level, not at the language-model level.

PDF support also varies: one API may extract text, another may preserve page images, and another may use a separate file service. Evaluate the actual upload and tokenization path.

Reasoning and Inference-Time Compute

Reasoning behavior should be described with a configuration, not a binary badge.

Reasoning tokens may be billed or included in an output category even when the full internal chain of thought is not returned. Do not design observability or trust around access to private reasoning. Record model/configuration IDs, usage, tool outcomes and externally checkable evidence. Retain or redact prompt/output content according to the application’s data policy; ordinary logs must not automatically collect every private input.

A fair evaluation holds the reasoning setting constant—or explicitly compares the cost-quality frontier across settings.

Identically named effort levels are not equal compute budgets across models. Compare measured quality, billed tokens, and latency; do not copy none or minimal into a model that rejects it.

Tools, Agents, and Model Boundaries

Function calling

The model emits a structured request to a tool supplied by the application. The application validates arguments, authorizes the call, executes it, and returns the result. The model has proposed an action; it has not executed one by itself.

Provider-hosted tools

The provider may execute search, retrieval, code, computer use, or media tools inside its platform. This changes billing, data flow, latency, and auditability. Record the exact tool version and service contract separately from the model.

Agent

An AI agent is a system that selects actions toward a goal using observations of its environment. For this guide, an LLM agent uses a model to guide some of those actions in a control loop. State, tools, budgets, permissions, recovery and stopping conditions are implementation responsibilities. No equation adding software components defines agency or guarantees reliability. See agent fundamentals.

sequenceDiagram
    participant App as Application
    participant Model as Model endpoint
    participant Gate as Authorization and validation
    participant Tool as External tool
    App->>Model: Instructions + authorized context
    Model-->>App: Proposed tool name and arguments
    App->>Gate: Identity + exact proposed action
    alt Authorized and valid
      Gate-->>App: Permit
      App->>Tool: Execute with scoped credentials
      Tool-->>App: Actual result or explicit uncertainty
      App->>Model: Result, request state and remaining budget
      Model-->>App: Answer or next proposal
    else Rejected
      Gate-->>App: Deny without executing
    end

Calling a model “agentic” normally means it is effective at planning and tool use. It does not supply least privilege, idempotency, sandboxing, approvals, memory integrity, or reliable termination. Those are system responsibilities.

GPT-6 supports asynchronous tool calling and mid-turn steering: the model can continue while an application-run tool is pending, and the user can redirect an ongoing turn. Those are interface capabilities, not permission to run unchecked actions. The application still owns authorization, cancellation, and duplicate-action prevention. See the Astra guide.

Structured output

Structured output and function calling are related but different:

• Structured output constrains a response to a schema.
• Function calling represents a request to invoke an operation.

A model may support one, both, or neither on a particular endpoint. Test schema validity and tool semantics instead of inferring support from a family name.

Open Weight Is Not Automatically Open Source

Use precise terms:

The Open Source Initiative’s Open Source AI Definition 1.0 distinguishes an open-source AI system from weights alone. In architecture discussions, say open-weight unless the full release and licenses justify the stronger term.

For every downloadable model, audit:

• weight, code, tokenizer, and dataset-information licenses;
• commercial, geographic, user-count, and field-of-use restrictions;
• redistribution and derivative-model obligations;
• acceptable-use policy and downstream notice requirements;
• whether base and instruction checkpoints are both available;
• availability of training code, data provenance, optimizer state, and evals.

Current Mistral examples show why the license must be attached to the exact model: Mistral Large 3 and Small 4 are listed under Apache 2.0, while Mistral Medium 3.5 uses a Modified MIT license. “Mistral model” is not a license.

A permissive license still has conditions. For example, Apache 2.0 section 4 requires specified notices and a license copy when distributing covered work. Downloadable weights, approved data handling and permission to redistribute are separate checks.

Open-weight deployment trade-offs

Open weights can provide placement control, custom serving, quantization, adapter training, and deeper inspection. They also transfer responsibility for capacity, patching, abuse prevention, safety layers, monitoring, upgrades, and incident response to the operator.

Closed APIs can provide faster access to current capability, elasticity, managed safety features, and reduced serving work. They add provider dependency and may limit weight-level customization and deployment placement.

Neither is inherently cheaper, safer, or more private. Compare the exact license, data policy, deployment, workload, and total cost.

Architecture and Size

Information flow and generation objective

These categories can overlap: a causal decoder may contain both recurrent and full-attention layers. Read Transformer architecture and diffusion LLMs for calculations. A robotics policy or vision-language-action model also needs an explicit action representation, control frequency and safety boundary; fluent text alone does not establish a physical control contract.

Dense versus mixture of experts

• Dense feed-forward model: each token follows the shared feed-forward layers rather than a router selecting a subset of experts. Embedding lookups still select rows; “dense” does not literally mean every stored parameter is read for every token.
• Mixture of experts (MoE): a router activates a subset of expert parameters for a token or layer.
• Hybrid architecture: combines mechanisms, for example full-attention and recurrent/linear-attention layers. A provider may also use “hybrid” for switchable thinking behavior. Name the mechanism instead of treating those meanings as equivalent.

For an MoE, report both total and active parameters when disclosed. Mistral Small 4, for example, is documented as 119B total parameters with 6.5B active; Mistral Large 3 is documented as 675B total with 41B active.

Parameter count is useful for estimating self-hosted memory and compute, but it is not a cross-family quality score. Training data, architecture, tokenizer, post-training, inference compute, quantization, and serving stack all matter.

For API-only models, internal architecture and parameter count may be undisclosed or may change behind an alias. Do not invent them. Treat the API's documented behavior and version contract as the interface.

The Qwen3.8-27B configuration illustrates independent axes: dense feed-forward computation and a mix of linear/full attention. For memory, 27 billion BF16 parameters alone are approximately 27e9 × 2 = 54 GB, about 50.3 GiB. A theoretical 4-bit payload is 13.5 GB before scales, metadata, caches, runtime and media processing. Neither figure proves that a complete service fits a particular GPU. See Transformer architecture.

Small, edge, and on-device

“Small” can refer to parameter count, active parameters, memory footprint, latency tier, or price tier. These are not interchangeable. An inexpensive hosted model may still be large, while a small local model can be slow on unsupported hardware.

Record:

• checkpoint and quantization;
• memory required for weights and KV cache;
• prompt and decode throughput on target hardware;
• context and batch-size limits;
• power, cold-start, and thermal constraints;
• quality after quantization on the real task.

Lifecycle, IDs, and Versioning

Do not equate “newest” with “GA.” Google currently lists Gemini 3.8 Flash as stable while Gemini 3.1 Pro remains preview. Preview may be more capable on a particular task but carries a different lifecycle contract.

Alias, family ID, and snapshot

• A rolling alias can move to a newer backing model or configuration.
• A family/model ID identifies a named tier but may still follow provider version policy.
• A dated snapshot is intended to pin behavior more tightly.
• A cloud deployment ID may map to a provider model version through a marketplace-specific lifecycle.

Record the resolved model when the provider exposes it, requested ID, API version, reasoning setting, tools and prompt version in production telemetry. If no immutable model revision is exposed, record that limitation instead of inventing a stronger pin.

A live alias example: the current DeepSeek catalog maps deepseek-v4-flash and deepseek-v4-flash-vision-exp to V4.1 Flash, while deepseek-v4-pro is still listed as the distinct V4-Pro-0813 text model. Do not infer a completed Pro migration from an earlier announcement. A valid request name alone does not establish the backing model.

Shutdown example: OpenAI lists September 24, 2026 as the shutdown date for Sora 2 and the Videos API, with no replacement in that notice. A price appearing on a rate card does not override the lifecycle notice. OpenAI deprecations.

For each model dependency, maintain:

• an owner and deprecation feed;
• a replacement candidate and migration runbook;
• contract tests for tool calls, schemas, streaming, and usage fields;
• held-out evals rerun before changing aliases or snapshots;
• canary thresholds and rollback.

Context, Output, and Knowledge

Context window

The context window is the total token capacity available to the request under the provider's accounting rules. It may include instructions, conversation, images or other media converted to tokens, tool schemas, tool results, reasoning blocks, and generated output.

Always distinguish:

• maximum input tokens;
• total context window;
• maximum output tokens;
• thresholds that change price or availability;
• effective accuracy across position and length.

A 1M-token window means the request can fit under documented conditions. It does not guarantee reliable needle retrieval, global reasoning, citations, or acceptable latency at 1M tokens.

Knowledge cutoff

A knowledge cutoff describes training knowledge, not what the model knows at request time. Current information can come from search, retrieval, databases, or tools. Tool access does not silently update the model's weights.

Separate:

$$\text{parametric knowledge} \quad\text{from}\quad \text{retrieved or tool-provided evidence}$$

For current or regulated facts, require authoritative retrieval and citations rather than relying on a family label or cutoff date.

Memory

Long context is not long-term memory. Cross-session memory is an application or platform feature that stores and retrieves state. It needs provenance, retention, deletion, access control, and poisoning defenses independent of the model.

Deployment and Data Control

The same or related model can be available through different serving paths:

“Sovereign,” “private,” “regional,” and “on-premises” describe deployment and governance, not model intelligence. Verify:

• where inference and storage occur;
• retention and training-use terms;
• whether routing can leave the chosen geography;
• encryption, keys, logs, and subprocessors;
• support for private networking and customer-managed controls;
• whether the regional endpoint changes price, capacity, or latency.

A model offered by the same vendor through two clouds can have different IDs, versions, features, prices, and retirement dates. Treat them as separate deployments in the model registry.

Current Model-Family Snapshot

This is a compact map of representative current first-party general models, not a leaderboard. Prices belong in Pricing and Costs, and production choice belongs in the Model Selection Guide.

Important boundaries:

• Google publishes an input-token limit, while OpenAI specifies separate input, output and combined limits. Check each endpoint’s accounting rules rather than adding or equating those caps.
• OpenAI's GPT-6 general models accept images but do not natively accept or generate audio/video; use specialist endpoints for those modalities.
• Gemini 3.8 Flash is natively multimodal on input but produces text, not native image or audio output.
• Grok does not gain live information merely from being a current model; xAI's documentation says search tools are required for realtime events.
• DeepSeek's old experimental vision ID is now a compatibility alias for V4.1 Flash, not a separate experimental model to shortlist.
• Model availability and feature parity can differ on Bedrock, Google Cloud, Microsoft Foundry, or other marketplace paths.

Capability lanes, not universal tiers

For shortlisting, use operational lanes:

These lanes are hypotheses for evaluation. They do not establish a cross-provider ordering.

The Model Passport

Store a structured record for every candidate and production deployment:

model:
  provider: openai
  requested_id: gpt-6-luna
  resolved_version: gpt-6-luna
  lifecycle: ga
  checked_at: 2026-09-24

contract:
  inputs: [text, image]
  outputs: [text]
  context_tokens: 1050000
  max_input_tokens: 922000
  max_output_tokens: 128000
  reasoning: [none, low, medium, high, xhigh, max]
  endpoint: responses
  reasoning_effort: medium
  features: [streaming, function_calling, structured_output]
  enabled_tools: []  # Application choice, not every supported tool

deployment:
  serving_path: first_party_api
  region: global  # Illustrative; not a residency commitment
  weights_available: false
  license: provider_api_terms
  data_policy_version: review-link-or-contract-id

operations:
  pricing_card_date: 2026-09-24
  rate_limit_tier: production-account-specific
  prompt_version: support-agent-v12
  eval_suite: support-agent-heldout-v7
  rollback_target: previous-pinned-deployment

Extend it with:

• tokenizer and media-token rules;
• cache, batch, flex, or fast-service support;
• exact regional deployment ID;
• safety and access restrictions;
• measured P50/P95 latency and throughput;
• quality, reliability, and safety results;
• cost per successful task;
• deprecation owner and migration deadline.

Do not fill unknown fields from inference or naming conventions. Write unknown, link to the provider contract, and test what can be tested.

Common Taxonomy Mistakes

1. Treating provider suffixes as universal sizes. Flash, Haiku, Luna, Small, Mini, and Pro are not standardized across vendors.
2. Calling all downloadable weights open source. Inspect code, data information, weights, and every applicable license.
3. Equating context capacity with long-context quality. Test recall, reasoning, citations, latency, and price at the real length distribution.
4. Equating image input with image generation. Record input and output modalities separately.
5. Calling a model an agent. The model proposes; the harness owns tools, state, permissions, budgets, recovery, and stopping.
6. Treating reasoning as a permanent model class. Many current models expose effort levels or adaptive thinking inside the same model ID.
7. Mixing model tier with service tier. Faster/priority serving can use the same model at a different latency and price.
8. Assuming a knowledge cutoff means current facts. Search and retrieval are separate evidence paths.
9. Assuming the same model name means cross-cloud parity. Check exact IDs, regions, features, versions, pricing, and retirement dates.
10. Publishing a giant current-model catalog without a date. Keep the taxonomy stable and the current snapshot small, dated, and sourced.

A small semantic router you can explain

Suppose incoming tasks are shipping FAQs, policy interpretation, and code analysis. Build a labeled sample containing the input, each candidate model's verified outcome, latency, and total cost. Embed the task input, inspect clusters to discover useful categories, and train or calibrate a router against those measured candidate outcomes. A nearest-centroid classifier is a baseline: compare the query vector to FAQ, policy, and code centroids, then choose a permitted model only when confidence and the quality gate allow it.

For example, “Where is order 482?” may route to an authenticated order lookup and response template, while “Do these two exceptions conflict?” routes to the policy model. An uncertain or out-of-distribution input takes an evaluated fallback. Clusters alone do not tell you which model is competent, and a model calling its own answer “easy” is not a calibrated routing label. Split by customer/source/time where needed to avoid near-duplicate leakage. Recheck routing after model or traffic changes.

Open-weight examples for interview breadth

These include current and historical examples whose model cards can be studied, not a ranking of the newest releases or a purchase recommendation. Pin the exact checkpoint and inspect its license, template, modality, and deployment requirements.

Recall the dimensions of the comparison: weights, license, modalities, architecture, adaptation, serving, evidence. A memorized vendor list is less useful than classifying a newly encountered checkpoint correctly.

Interview case: choose model classes for a support platform

Prompt: design model selection and routing for an account-support service. These are interview assumptions, not vendor benchmarks.

Functional requirements

1. Answer order-status requests using authenticated order data.
2. Answer policy questions with cited, authorized policy versions.
3. Extract fields from uploaded return-label images and request confirmation when uncertain.
4. Escalate unsupported requests without fabricating an answer or performing account writes.

Non-functional requirements

1. Meet a measured p95 end-to-end latency of two seconds for order lookup and eight seconds for generated policy answers at the proposed peak load.
2. Achieve at least 95% accepted outcomes on the held-out workload and investigate every critical authorization failure separately.
3. Keep restricted tenants on approved regional deployments, including fallbacks, OCR and telemetry.
4. Retain the exact routing, prompt, evidence and model versions needed to investigate an outcome, within the data-retention policy.
5. Bound retries, execution time and spending; define an explicit unavailable outcome when no eligible dependency remains.

Basic design: send all inputs to one general-purpose model. It simplifies the first prototype but does not supply current order state, document authorization, image parsing accuracy or predictable costs. A large context window does not fix these gaps.

Detailed design: filter deployments by hard requirements first. A calibrated task router then selects among eligible paths. It cannot grant a disallowed model access to sensitive data.

flowchart TB
    C["Authenticated request: tenant, task, attachments"] --> G["Policy gate: data class, region, modality, lifecycle"]
    V[("Versioned registry: approved model and tool deployments")] --> G
    G --> R{"Eligible task route"}
    R -->|Order status| D["Scoped order lookup + deterministic template"]
    R -->|Policy question| E["Authorized retrieval + evaluated text generator"]
    R -->|Return-label image| I["Evaluated OCR/vision extractor + field checks"]
    R -->|Unknown or unavailable| H["Explicit escalation"]
    E --> O["Evidence and output validation"]
    I --> O
    D --> O
    O --> A["Answer or request for confirmation"]
    O --> T["Versioned outcome, latency, usage and failure record"]
    T -.-> Review["Offline review and approval"]
    Review -.-> V

The dotted path represents an offline review that may approve a new registry version. Production telemetry must not silently change routing policy or deploy an unreviewed model. An image parser's output is evidence to validate, not an instruction to tools. See document processing and RAG.

State and request contract: a request carries an immutable request ID, authenticated tenant, task input, attachment references and deadline. Persist the selected deployment and policy revision, then record running, completed, escalated or failed. A retry checks existing state and approved routes. Fallback is another explicitly allowed deployment; it cannot silently send data to a different region. Tool writes are outside this exercise, so retrying lookup is read-only, while billed model executions still need separate accounting.

Cost/benefit calculation: suppose 100,000 monthly requests comprise 50% order lookups, 30% policy answers and 20% images. Assume a one-model baseline costs USD 0.020 per request, including model attempts, and achieves 96% accepted outcomes. A proposed router costs USD 0.001 per request; its paths cost USD 0.001, 0.012 and 0.008 per request respectively, including their measured retries. The routed variable cost is:

100000 × (0.001 + 0.50×0.001 + 0.30×0.012 + 0.20×0.008) = USD 670/month.

The baseline costs USD 2,000/month. If routing needs USD 500/month in additional operations and amortized implementation, its full incremental comparison is USD 1,170 versus USD 2,000, saving USD 830. At 95.5% accepted outcomes, that is about USD 12.25 per 1,000 accepted results, compared with USD 20.83 for the baseline. Common infrastructure costs are excluded equally; a full budget must add them to both options. The routed quality is 0.5 percentage points lower, so confirm the required threshold and important slices before accepting the saving. Aggregate cost improvement cannot excuse unauthorized disclosure.

Failures and recovery: a router outage uses a preapproved fixed route or escalation; provider failure uses only an eligible fallback; a registry outage may retain the last approved version only within its explicit freshness/expiry policy; an expired or revoked policy means no inference. An alias change triggers contract/evaluation checks and canary review. A model's self-reported confidence is not the fallback threshold. Calibrate routing decisions on measured outcomes and reevaluate when traffic changes.

Closing remarks: “I would first identify the operation each request needs. Current account state comes from an authorized lookup; language synthesis and image extraction use independently evaluated models. I would choose the least costly eligible path that meets quality and latency requirements, record every version and keep fallback within the same privacy rules. The next evidence I need is peak-load performance, rare-case routing errors and complete cost per accepted outcome.”

Interview Questions

Q: How would you classify an unfamiliar model?

Q: What is the difference between a reasoning model and a normal LLM?

Q: What is the difference between open-weight and open-source AI?

Q: Is an agentic model an agent?

Q: Does a one-million-token context remove the need for RAG?

Q: How should lifecycle affect model selection?

Q: A model has 100B total and 5B active parameters. Can it fit wherever a 5B dense model fits?

Q: Can a model be both dense and hybrid?

Q: A vision model accepts invoices. Does that establish production OCR accuracy?

Q: An Apache-licensed checkpoint is downloadable. Can we omit notices when redistributing a modified version?

Q: The API accepts the same ID after an upgrade. What might have changed?

Q: Does disabling thinking always make a workflow cheaper?

Q: What belongs in a data-residency decision beyond the model name?

Q: Two embedding models return 1,024 numbers. Can we mix their vectors?

Q: Does a semantic cluster prove which model should receive the query?

Final summary and notes

60-second answer: “I start by identifying the operation: lookup, generation, ranking, extraction or action. I classify each candidate by its inputs and outputs, training/adaptation, architecture, available weights and deployment contract. I filter out candidates that fail privacy, modality or lifecycle requirements. Then I compare measured quality, latency and full cost on representative tasks. Model names form a shortlist; the evidence decides the deployment. I document the selected version, fallback rules and migration owner.”

Keep the capability-assessment, pricing and selection records together. A model catalog answers what exists; an assessment answers what works for this application.

Official Sources

Checked September 24, 2026:

• OpenAI model catalog, GPT-6 Astra, GPT-6 Sol, and GPT-6 Luna
• Anthropic Claude model overview and model-selection guidance
• Google Gemini model catalog, Gemini 3.8 Flash specifications, and Gemini deprecations
• xAI models and pricing
• Mistral model catalog, Mistral Large 3, Mistral Medium 3.5, and Mistral Small 4
• DeepSeek current API models
• Open Source AI Definition 1.0

Next: Capability Assessment