AI Model Evaluation: Reference Guide
A companion reference to the three-part blog series AI Model Evaluation blog series. Each section expands on a concept the series introduces but does not fully develop. For maximum depth on any topic, the full guide contains primary sources and complete methodology.
How to Use This Guide
- Following a link from the blog series? Navigate directly to the relevant section.
- Deciding which benchmarks matter for your work? Start with Benchmark Categories in Depth.
- Planning a model evaluation? Start with Building a Personal Evaluation.
- Making sense of a model announcement? Start with How Providers Select Benchmarks.
Continue to the complete research guide
This reference is the middle layer between the blog and the full research record. For complete methodology, the evaluation prompt, appendices, and primary-source bibliography, continue to Reading AI Model Benchmarks—and Building a Personal Evaluation.
Core Terminology
The following terms appear throughout AI benchmark reporting. Understanding the distinction between a model and a system is particularly important — most published scores reflect the latter, not just the former.
Model The trained neural network itself, together with the settings that affect how it generates a response (such as temperature and output length). When a company trains and releases a new AI, the model is the core artifact.
System The model plus everything wrapped around it: the instructions given before a conversation starts, the tools it can call, any memory or context it has access to, safety filters, and the software that manages its work. A coding agent that can inspect files, run tests, and retry failed actions is a system. Most benchmark scores for agentic tasks reflect the system, not the model alone. Two products built on the same model can produce meaningfully different scores if their surrounding systems differ.
Benchmark A standardized collection of tasks with a defined scoring method. GPQA Diamond is a benchmark. SWE-bench is a benchmark. Each one specifies what the model or system must do, what tools it may use, and how the result is graded.
Evaluation (eval) The full process used to test performance. An evaluation may use a public benchmark, a private task set, or examples drawn from real work. The benchmark is the test; the evaluation is the act of running it and recording results under specified conditions.
Scaffold / Harness The software layer that controls how the model receives instructions, context, and tools during a test. The scaffold may also manage retries, stopping rules, and the order in which information is presented. Two runs of the same model with different scaffolds can produce substantially different results.
Grader / Judge The mechanism that decides whether a response is correct. A grader may compare a short answer against an answer key, run executable tests against generated code, check a final system state, ask a human reviewer, or use another AI model to assess quality. The grading method is a critical part of what a benchmark actually measures.
Metric The value reported at the end of an evaluation: accuracy, pass rate, task completion rate, cost per successful task, response time, or another outcome. Different benchmarks report different metrics, and they are not interchangeable.
Elo Rating A score derived from head-to-head comparisons rather than absolute tests. A higher Elo means the system won more often against the group of other systems in that comparison. Chatbot Arena uses Elo. Elo scores are only meaningful relative to the specific pool of systems compared.
Token Budget A limit on the units of text the model can read or generate. Tokens are short pieces of words or punctuation used internally by the model's text-processing system. A model given more tokens can handle longer inputs and produce longer outputs, which can significantly affect performance on complex tasks.
Reasoning Setting A product-level control that determines how much computation the model is allowed to use before producing a response. Extended reasoning can improve accuracy on difficult problems but increases cost and latency. Provider names for this setting vary. Benchmark reports should specify which reasoning setting was active.
For the full technical definitions with additional context, see Section 1.1 of the full guide.
How AI Evaluation Evolved
AI evaluation has expanded as models and systems gained new capabilities. The development can be understood as four overlapping layers. Older layers remain in use alongside newer ones.
Layer 1: Language, Knowledge, and Short Answers
Task formats used: - Multiple-choice questions (select one answer from a fixed set) - Classification (assign a label such as a topic or sentiment) - Exact-answer matching (compare the response with an accepted answer) - Reading comprehension (answer a question using a supplied passage) - Short code generation (write a small function from a specification)
What these tests show: - A quick check of knowledge, language understanding, and basic problem solving. - Scores are inexpensive to calculate and easy to reproduce.
Where their evidence is limited: - A fixed public test may eventually become familiar through training data. - A short answer reveals little about tool use, error recovery, or performance across a multi-step workflow.
Representative benchmarks: MMLU, MMLU-Pro, BIG-bench Hard.
Layer 2: Reasoning and Constructed Outputs
The second layer introduced tasks requiring a derived answer or a working output. Rather than selecting from options, the model must reason to a conclusion or produce a functional artifact.
What this layer tests: - Multi-step scientific and mathematical reasoning. - Code generation verified by running the code against automated tests. - Written explanations reviewed for correctness, clarity, and completeness.
Representative benchmarks: GPQA Diamond, FrontierMath, AIME, HumanEval.
Layer 3: Tools, Interaction, and Environments
Systems that can browse the web, edit repositories, use a terminal, call APIs, or operate graphical applications require tests that examine actions, not just answers.
What changes in this layer: - The test measures tool selection, tool quality, and recovery from failed actions. - Results depend on the scaffold, the tools available, and the amount of context the model can access. - A failed command mid-task is as informative as the final result.
Representative benchmarks: SWE-bench (software repositories), OSWorld (computer interfaces), BrowseComp (web research), Terminal-Bench (command-line tasks).
Layer 4: Reliable Work Over Time
The most recent layer studies whether systems can complete meaningful, multi-step work over extended periods without human intervention at every step.
Capability measures used: - Percentage of tasks completed. - Quality of the final output. - Ability to recover from errors. - Performance across tasks of different lengths and difficulty.
Operating measures used: - Cost per successful task. - Elapsed time and number of model turns. - Amount of human intervention required. - Frequency and severity of failures. - Safe handling of permissions and reversible actions.
Representative framework: METR's task-completion time horizon — an estimate of the task length, measured in human-expert completion time, at which a system reaches a specified success rate.
For the complete four-layer breakdown with additional benchmark examples, see Section 1.2 of the full guide.
Why Benchmark Scores Differ
The same benchmark, applied to the same underlying model, can produce dramatically different scores depending on how the test is configured. This is not incidental — it is a direct consequence of how agentic evaluations work.
The configurability problem
A benchmark score is the result of five interacting choices: the task set, the test conditions, the response format, the grading method, and the reported measure. Two runs on the same benchmark with different tools, different reasoning budgets, or different numbers of retries are not the same test — even if they share a name.
A documented example: OpenAI ran the same GPT-4 model through multiple test configurations and reported SWE-bench Lite scores ranging from 2.7% to 28.3%. The model was identical. The surrounding setup — the tools available, the instructions given, the number of allowed retries — varied. The highest score is the one typically cited.
This is why the phrase "agent score" is often more accurate than "model score." The benchmark result reflects the system, not the model in isolation.
What a complete score record includes
A score that can be meaningfully compared with another must specify:
- The exact model and product version tested.
- The benchmark name and task-set version.
- The tools and surrounding software (scaffold).
- The time, token, and retry limits.
- The grading method used.
- The date the evaluation was run.
Without this information, a score still describes a result — just not one you can reliably compare against results produced under different conditions.
For additional examples and the full comparability analysis, see Section 1.4 of the full guide.
Why Scores Don't Transfer
Even a carefully documented benchmark score may not predict performance in a different workflow. Researchers call this the external validity problem: a benchmark can be scored correctly under its own rules while providing weak predictions for a different setting.
Seven factors create this gap:
1. Training data overlap (data contamination) Benchmark questions, or close variants, may appear in the model's training data. Familiarity with the questions raises the score without improving capability on genuinely new problems.
2. Task-format specialization Models are often optimized for the specific format a benchmark uses — its question structure, required output type, or grading method. Those optimizations may not transfer to other formats.
3. Protocol optimization The test setup — prompts, tools, retries, reasoning budget, scaffold — may be tuned specifically for the benchmark. The optimized configuration may differ from what is available to a regular user.
4. Selective reporting Providers report the benchmarks that support their intended narrative for a release. The benchmarks not reported are often as informative as the ones that are. Missing results are not random.
5. Leaderboard adaptation Repeated submissions to a shared leaderboard can reveal information about a private test set and guide model development toward it. Teams with greater access can benefit more.
6. Grading limitations An answer key or unit test can reject a valid response or accept an incomplete one. Human and model judges can be influenced by response length, confidence, or presentation order rather than correctness.
7. Limited coverage Every benchmark samples a finite set of tasks. A benchmark for graduate-level science questions represents one narrow slice of possible work, however well it represents that slice.
For the full analysis including research citations, see Section 1.5 of the full guide.
Benchmark Categories in Depth
Benchmarks are organized here by capability category. Each entry covers: what the benchmark tests, representative examples with key details, what the results tell you, and what they cannot tell you.
Knowledge and Academic Subjects
What it tests: Whether a model has knowledge across a wide range of academic and professional domains.
Representative benchmarks:
MMLU (Massive Multitask Language Understanding) Uses multiple-choice questions across 57 subjects. Provides a broad view of academic and professional knowledge. The standard four-choice format makes scores easy to compare, but the format also limits what the test can reveal about open-ended reasoning. Paper
MMLU-Pro An updated version of MMLU. Uses more reasoning-oriented questions, expands the answer set from four to ten choices, and removes items identified as noisy or ambiguous. Score comparisons between MMLU and MMLU-Pro are not straightforward because the task is meaningfully harder. Paper
Humanity's Last Exam (HLE) Contains 3,000 difficult, expert-written questions across many fields, including multimodal questions that combine text with images. Designed to be hard for state-of-the-art models. HLE-Verified is a later subset with noisy or ambiguous items removed — reports should specify which version was used. HLE paper, HLE-Verified paper
BIG-bench / BIG-Bench Hard (BBH) Contains 204 tasks across language, logic, science, mathematics, and social reasoning, contributed by researchers across 132 institutions. The diversity is a strength; a single average score can hide large differences across tasks. Paper
Useful for: Gauging general knowledge depth; comparing models across many academic and professional domains. Limitation: These benchmarks score answers, not workflows. High scores do not imply the model is good at doing work — only at answering questions about knowledge.
Scientific and Mathematical Reasoning
What it tests: Whether a model can reason through multi-step problems in physics, chemistry, biology, and mathematics — arriving at a derived answer, not just recalling a fact.
Representative benchmarks:
GPQA Diamond Graduate-level biology, chemistry, and physics questions. Designed to challenge knowledgeable non-specialists even with web access. The Diamond subset is the higher-quality slice most commonly reported. Paper
FrontierMath Original, expert-authored mathematics problems with precise, verifiable answers. Problems are written and reviewed by expert mathematicians specifically to avoid overlap with training data. Paper
AIME (American Invitational Mathematics Examination) Competition-level mathematics problems with integer answers. Frequently cited in model announcements as a proxy for deep mathematical reasoning.
ARC-AGI (Abstraction and Reasoning Corpus) Visual grid transformation puzzles. The model sees examples of a rule applied to grids, then must apply the rule to a new example. Designed to test adaptation to unfamiliar tasks rather than pattern-matching on familiar ones. ARC-AGI-1 and ARC-AGI-2 use different task sets and protocols — comparisons should specify which version. Original paper, ARC-AGI-2 paper
Useful for: Selecting models for analytical, technical, or scientific work; identifying whether a model can reason under genuine difficulty rather than pattern-match. Limitation: Advanced mathematics and small visual puzzles represent selected forms of reasoning. They provide limited evidence about communication quality, tool use, or reliability across real workflows.
Coding and Software Engineering
What it tests: Whether a model can write code, fix bugs, navigate codebases, and complete software engineering tasks.
Representative benchmarks:
HumanEval Asks a model to generate short, self-contained Python functions from written specifications. Results are checked by running unit tests — automated checks that supply known inputs and compare the output with expected results. The tasks are isolated and small, representing a limited slice of real software engineering. Paper
SWE-bench family Asks a system to resolve real issues filed in real GitHub repositories. The score reflects the system's ability to read and understand a codebase, identify the relevant files, make targeted edits, and produce a fix that passes the repository's existing tests.
The SWE-bench family has several variants. Scores from different variants are not interchangeable:
| Variant | Tasks | Description |
|---|---|---|
| SWE-bench (original) | 2,294 | Issues from 12 Python repositories |
| SWE-bench Lite | 300 | A representative subset of the original |
| SWE-bench Verified | 500 | Tasks screened by professional developers for clear issue descriptions and fair tests |
| SWE-bench Pro | Ongoing | A maintained variant used in recent provider announcements |
| SWE-bench Multilingual | Expanding | Extends SWE-bench beyond Python to other languages |
SWE-bench scores depend heavily on: the scaffold and tools provided, the token and time budget, the number of allowed retries, and the selection rules for which tasks are included. Two SWE-bench scores should only be compared when these conditions are documented and matched. Original paper, SWE-bench Verified announcement
Terminal-Bench Asks an agent to complete command-line workflows inside isolated software environments. Version 2.0 contains 89 tasks based on real workflows. The result reflects the complete terminal agent, its tools, and its budget. Paper
Useful for: Selecting coding assistants; evaluating software engineering agents; understanding real-world debugging and code editing capability. Limitation: Scores are highly sensitive to system configuration. Comparisons without matching conditions are unreliable.
Visual and Multimodal Reasoning
What it tests: Whether a model can work with information presented in both text and images — charts, diagrams, scientific figures, screenshots.
Representative benchmarks:
MMMU-Pro College-level questions combining images, domain knowledge, and reasoning. Updated version of MMMU with harder tasks and more options per question. MMMU paper
MathVista 6,141 examples combining charts, diagrams, and figures with quantitative reasoning. Tests the combination of visual interpretation and mathematical thinking. Paper
CharXiv Reasoning Charts sourced from scientific papers. Reasoning questions require information to be extracted and combined across complex visual elements — harder than reading a simple bar chart. Paper
Useful for: Workflows involving scientific literature, slide decks, dashboards, or documents with figures. Limitation: Tests interpretation of static images. Does not measure image generation quality.
Browsing, Tool Use, and Computer Operation
What it tests: Whether a system can take actions through browsers, APIs, tools, and graphical applications.
Representative benchmarks:
BrowseComp 1,266 questions requiring persistent web navigation to find difficult-to-locate information. Answers are short and verifiable. Results depend on browser tools, web state, and available budget. Paper
OSWorld-Verified Tasks performed through real computer environments — web applications, desktop applications, and multi-application workflows. The original OSWorld contains 369 tasks; OSWorld-Verified removes tasks with unclear grading. Results depend on the environment setup and action interface. Paper
τ-bench Multi-turn conversations using domain policies and tools that change database state. Provides a controlled approximation of customer-service and workflow automation scenarios. Paper
Useful for: Evaluating research agents, automation agents, and any workflow where the model must operate software rather than only produce text. Limitation: These are system evaluations. Performance depends on tools, permissions, and environment configuration, not just the underlying model.
Human Preference and Deployment Qualities
What it tests: Whether people actually prefer a model's responses, and how the model performs on qualities that matter for deployment but are hard to reduce to a single accuracy score.
Representative benchmarks:
LMArena / Chatbot Arena Users see two anonymous responses to the same prompt and vote for the one they prefer. Results are aggregated into an Elo ranking. Provides evidence about real human preferences across a large and diverse sample of prompts. Style, length, and confidence can influence votes alongside actual quality. Paper
MT-Bench Multi-turn questions graded by a model judge. Supports scalable evaluation of conversational and instruction-following quality without requiring human raters for every comparison.
HELM (Holistic Evaluation of Language Models) A framework that evaluates multiple qualities together: accuracy, consistency when conditions change, whether stated confidence matches actual correctness, efficiency, and potential for generating biased or harmful content. Makes trade-offs and gaps in coverage visible rather than collapsing everything into one number. Stanford HELM
Useful for: Assessing open-ended conversational performance; evaluating deployment readiness beyond raw accuracy. Limitation: Preferred responses may still contain factual errors, safety problems, or hidden costs. Human-preference data should complement accuracy benchmarks, not replace them.
For additional benchmark details, a suggested five-benchmark portfolio, and the complete primary source bibliography, see Section 2 and Appendix D of the full guide.
How Providers Select Benchmarks
Benchmark selection in model announcements is not neutral. Each provider leads with benchmarks that support the story they are telling about a release. The tables below summarize the July 2026 release landscape.
July 2026 provider comparison
| Provider | Release | Dominant narrative | Benchmark families emphasized |
|---|---|---|---|
| OpenAI | GPT-5.6 (Sol / Terra / Luna) | End-to-end work and performance per dollar | Coding agents, professional workflows, browsing, computer use, science, cybersecurity |
| Anthropic | Claude Fable 5; Claude Sonnet 5 | Long-horizon capability with tiered safeguards and cost options | Coding, finance, vision, science, cybersecurity, search, computer use |
| Gemini 3.5 Flash | Fast frontier agents and multimodal coding | Terminal, professional work, MCP/tool use, scientific charts, composite intelligence index | |
| Qwen / Alibaba | Qwen3.7-Max | A general foundation for diverse agent scaffolds | SWE, terminal, MCP, office automation, multilingual, context, simulated worlds |
| Mistral | Mistral Medium 3.5 | Open-weight, self-hostable unified agent | SWE, domain tool use, system efficiency |
What the selection patterns show
-
OpenAI presents GPT-5.6 as an end-to-end work system. The benchmark portfolio has moved well beyond MMLU-style knowledge testing toward coding agents, professional deliverables, computer operation, and science workflows. The highest reported results use a multi-agent "ultra" configuration that should not be treated as a single-model comparison.
-
Anthropic foregrounds safeguards and cost tiering alongside capability. Fable 5 is positioned for long-horizon agentic work; Sonnet 5 for more economical, broadly deployed use. Both target coding, research, and professional tasks. Anthropic also reports cost-performance curves at different effort levels — a useful transparency practice.
-
Google shifted from reasoning-heavy framing (Gemini 3.1 Pro and ARC-AGI-2) to a combination of reasoning, action, multimodality, and speed. That change within one provider illustrates that benchmark selection follows the intended positioning of each release, not a universal standard.
-
Qwen presents the agent system as the product, not the underlying model. Its evidence includes many internal tasks, custom harnesses, and judge choices. Cross-provider comparisons require matching these protocol details carefully.
-
Mistral emphasizes open-weight deployment, self-hosting, and hardware efficiency alongside benchmark performance. For Mistral buyers, licensing, hardware requirements, and price may matter more than marginal benchmark differences.
The benchmarks absent from an announcement are often as informative as the ones present. A provider consistently avoiding a well-established category may simply be less competitive there.
For the complete per-provider benchmark lists and detailed interpretation, see Appendix B of the full guide.
Building a Personal Evaluation
A personal evaluation translates the principles behind public benchmarks into a test that reflects your specific work. It does not require academic infrastructure. The essential inputs are a representative task, consistent conditions, and a rubric written before testing.
Step 1: Define the decision
Start with the specific decision the evaluation must support — selecting a model for a recurring task, comparing a new release with a current model, approving a model update for production, or identifying work that still requires human execution. The decision determines which strengths and failure modes are relevant. Without a clear decision, an impressive but unrelated capability can dominate the comparison.
Step 2: Describe representative work
List the frequent, important, and difficult tasks the model will need to do. For each task, record: - What information the model receives as input. - What form the output must take. - What tools, data, and constraints apply. - What time and cost limits apply. - What characteristics make the result useful. - What errors would require correction. - What failures would be serious (financial, legal, safety, reputational).
Step 3: Choose a small, varied task set
A practical first evaluation can use 5 to 15 tasks organized across three types:
- Normal tasks: Represent regular work. Prevent the evaluation from focusing only on unusual challenges.
- Difficult tasks: Separate strong systems from weak ones. Include tasks with ambiguity, incomplete information, or multiple dependent steps when those conditions occur in the real workflow.
- Edge cases: Target known failure modes. Include high-cost mistakes and situations that require refusal, escalation, or confirmation.
Include at least one task with an objectively checkable result and at least one that requires qualitative human review.
Step 4: Fix the test conditions
Use equivalent conditions for every model being evaluated:
| Keep constant | Record for every run |
|---|---|
| Task instructions and source material | Exact model and product version |
| Tool access and permissions | Product surface (API, chat, coding agent) |
| Reasoning setting | Prompts, outputs, logs, and files |
| Time, token, and cost limits | Elapsed time, cost, and date |
| Starting context | Errors, interventions, and retries |
Different product interfaces may supply different prompts, tools, and context. Record them as separate system configurations even when they use the same underlying model.
Step 5: Write the rubric before testing
Write the scoring criteria before you see any model outputs. A rubric that is written afterward tends to reflect what the models actually produced, not what the task actually required.
A useful rubric separates the major qualities of the output into independent criteria. One example scoring scale:
| Score | Meaning |
|---|---|
| 0 | Missing, unusable, or materially wrong |
| 1 | Major errors or omissions; extensive correction required |
| 2 | Partly successful; several important corrections required |
| 3 | Meets the main requirement; limited correction required |
| 4 | Complete, accurate, clear, and ready for intended use |
Include disqualifying gates for failures that should invalidate a run regardless of average score — fabricated sources in a research task, unauthorized irreversible actions in an automation task, or materially incorrect conclusions in high-stakes domains.
Step 6: Review the evidence
Use automatic checks and human review for what each does best.
- Automatic checks: Valid file formats, code tests, required fields, broken links, numerical consistency.
- Human review: Clarity and usefulness, judgment under ambiguity, source quality, subtle factual errors, whether the result is ready for its intended audience.
Blind the reviewer to model identity when practical. Record category scores, failure notes, variation between runs, cost, and completion time. A single weighted total can hide important trade-offs.
Step 7: Run a supervised production pilot
A controlled test supports a shortlist. A limited pilot shows how the system performs with real users, real data, and real workflow constraints.
Track during the pilot: completion rate, correction time, human interventions, incidents, cost, and user outcomes.
Repeat the evaluation when the model version changes, when prompts or tools change, when a workflow changes, or when production monitoring reveals a new failure pattern.
The complete decision sequence:
Use case
→ requirements and unacceptable failures
→ relevant public benchmark portfolio
→ candidate models
→ same-protocol private evaluation
→ supervised production pilot
→ monitoring and re-evaluation
For the full methodology with additional detail on task design and rubric construction, see Appendix A of the full guide.
The Evaluation Rubric
This is the four-criterion rubric used in the personal evaluation described in Part 3 of the blog series.
The criteria are scored independently. This prevents a model that writes excellent code from obscuring scientific weaknesses behind a polished interface — and vice versa.
Criterion 1: Multi-Step Compliance and Attention (20 points)
Evaluates the model's ability to hold constraints across a long prompt and sequence its output correctly.
What is being measured: Whether the model follows the requested planning process before the code, meets exact visual constraints, formats the appendix as requested, and preserves all meta-instructions once code generation begins.
High scores mean: The model has strong context-window attention and can execute structured, multi-step instructions reliably.
Low scores indicate: Attention decay — the model loses track of meta-instructions once it begins producing a heavy block of structured output such as an HTML file.
Criterion 2: Domain Rigor and Epistemology (30 points)
Evaluates the factual accuracy, depth of scientific reasoning, and handling of uncertainty.
What is being measured: Whether the scientific principles are accurate and comprehensively applied; whether ambiguity is addressed explicitly or papered over with confident assertions; whether real formulas are used or simplified approximations invented for convenience.
High scores mean: The model reasons from correct physical or biological principles, states its assumptions explicitly, and acknowledges what is uncertain.
Low scores indicate: Factual gaps, silent assumptions, invented formulas, or overconfident claims in areas where the evidence is genuinely ambiguous.
Criterion 3: Pedagogical and Information Design (25 points)
Evaluates how well the artifact communicates the reasoning to a non-specialist audience.
What is being measured: Whether a reader unfamiliar with the domain can follow the reasoning by scanning the visualizations and captions; whether the layout flows logically; whether interactive elements build genuine understanding rather than serving as decoration.
High scores mean: The artifact teaches the concept effectively to someone without specialist background.
Low scores indicate: Visualizations that are decorative rather than explanatory, text-heavy sections without supporting visuals, or a flow that assumes prior knowledge.
Criterion 4: Software Engineering (25 points)
Evaluates the code quality, rendering, and dependency management.
What is being measured: Whether the file runs correctly in a browser without a build process; whether the code is well-structured and readable; whether external dependencies are managed cleanly (not imported but unused, not multiple redundant libraries for the same function).
High scores mean: The artifact is reliable, portable, and maintainable.
Low scores indicate: Files that require external servers, unused imports, bloated or redundant dependencies, non-responsive layouts, or interactive elements that break on inspection.
The complete evaluation prompt — including all specifications, constraints, and the quality checklist — is reproduced in Section 3.4 of the full guide.