What is an evaluation?
An evaluation is a structured, controlled process for measuring a property of an AI system. That property might be a capability, a tendency, or a risk.
At its simplest, an evaluation gives a model an input, observes the output, and scores it. In the simplest case, scoring means comparing the output against a known target, like in a multiple-choice knowledge test. In more complex cases, scoring may involve grading an output according to set criteria, either automatically using AI or manually by humans.
However, frontier models not only answer questions, but also use tools, execute code, browse the web, and take multi-step actions across sandboxed environments. When you evaluate whether a model can solve a cyber challenge, the "output" is the full sequence of what the model did along the way (its transcript or "trajectory"), which you need to capture accurately and thoroughly through careful logging and instrumentation.
Doing this reliably, across many models and many evaluations, is the job of an evaluation framework. This is the shared software that runs an evaluation, talks to the model, captures what happens, and scores the result. It needs a way to represent inputs and expected outputs (samples), a strategy for eliciting behaviour from the model (solvers), and a method for judging the result (scorers). These three components combine into a task, a complete, self-contained evaluation that can be run against any model. Related tasks that share a theme are grouped into a benchmark. When these evaluations involve untrusted code or potentially dangerous agent actions, we run them in isolated execution environments (sandboxes).
These terms recur throughout this page, and several have more common names you may already know them by. Before going further, below is a glossary of terms which shows how smaller pieces build up into larger ones.
| Term | Also known as | What it is |
|---|---|---|
| Sample | test case, item | A single input paired with its expected output (the target). The smallest unit of an evaluation. |
| Solver | scaffold, harness | The structure put in place to let the model attempt the task, from simple prompting through chain-of-thought to a full agent loop. |
| Scorer | grader, judge | How the model's output is judged against the target, whether by exact match, by another model, or by a human. |
| Task | component | A dataset of samples, a solver, and a scorer composed together. |
| Run | trajectory | The log (or transcript) capturing every message, tool call, and result from the task starting to it finishing (through completion or a limit being hit). |
| Evaluation | an "eval" | Loosely, any measurement of a model. In practice it can mean a single task, or a whole set of related tasks run together. |
| Benchmark | eval suite | A collection of tasks that differ but share a common theme, such as maths or capture-the-flag (CTF) coding challenges. |
Three evaluation patterns of increasing complexity. The first, question and answer, is a single model call scored by an exact match against the target, the kind of multiple-choice test described above. The second, multi-turn, builds a conversation up over several steps and has another model grade the answer, which suits questions with no single correct phrasing. The third, a tool-using agent, lets the model call tools and act inside an isolated sandbox that holds the environment it is changing, scored at checkpoints along the way. In the diagram, samples are blue, solvers green, scorers yellow, and sandboxes purple.
Constraints in evaluating models
A handful of constraints shape what an evaluation framework must handle at the frontier.
Run the same evaluation twice and you may get different results. A single success can settle whether a model is capable of something, but how reliably it succeeds only emerges across many runs, which is why individual pass/fail results are usually read in aggregate. You need statistical rigour over large sample sets, metrics like pass@k (probability of at least one success across k trials), and confidence intervals that account for variance.
An agentic evaluation describes a set-up where a model can use tools to (for example) write and execute code as a normal part of the task. In coding benchmarks, an agent may compile and run programs. In cyber evaluations, an agent may attempt a live cyber task. In these cases, we cannot allow a model to escape its environment, touch the host, or reach the public internet, because the aim is to measure dangerous capabilities without enabling their consequences. The evaluation framework treats the execution environment as hostile by default and isolates it at a level the task warrants.
Even when execution is safe, a multi-step trajectory is hard to judge. A single pass/fail tells you almost nothing about a run that made dozens of tool calls and recovered from several dead ends. Understanding the result means capturing the whole trajectory and scoring it for partial credit. Without that record, you cannot tell a genuine success from a lucky one or distinguish between models that may have not reached the final step but made substantially different progress towards it. Capturing the trajectory is therefore essential to measurement.
There are 40+ model providers, each with different APIs, authentication schemes, and capabilities. If an evaluation is tied to a single provider's API, it isn't comparable across models, and comparability is essential. Evaluations must be provider-agnostic at the framework level.
The same model can look more or less capable depending on the resources the evaluation gives it. The token budget, the number of turns or tool calls allowed, and the scaffold it runs in all shape the result, an effect known as inference scaling or test-time compute scaling. On cyber tasks, success rates keep climbing as the budget grows, with some tasks only solved at the upper end of the range, so a budget set too low underestimates what a model can do. A framework therefore has to make these inference limits explicit and adjustable, because the result only means something alongside the budget that produced it.
Real evaluation campaigns are not just large, they are long-running and prone to failure. AISI has tested 30+ frontier models, METR runs 228 tasks per model, and a single agentic evaluation can involve hundreds of model calls. Across such volumes, evaluations can fail mid-run due to API rate limits, network errors, or provider outages. A framework therefore needs to be resumable, retry-aware, and able to preserve completed work across failures.
Composable by design
Considered together, these constraints drive what a framework needs to look like. If evaluations are built from independent, pluggable primitives, then reusability, provider-agnosticism, and community contribution tend to follow from the architecture itself. Inspect is built around this principle.
An evaluation composes three core components:
Samples are the inputs and their expected outputs, the what of an evaluation. A dataset is just a collection of samples, loaded from CSV, JSON, Hugging Face, or custom sources. Each sample can carry metadata, sandbox configuration, and files to inject into execution environments.
Solvers define how to elicit behaviour from a model. They chain in sequence, each transforming the conversation state. A simple evaluation might use a single generate() solver. A more sophisticated one might chain system_message() → chain_of_thought() → generate(). The key design decision is the separation of how you ask from what you ask. The same samples can be evaluated with different solver strategies (direct prompting, few-shot, chain-of-thought, or a full agent scaffold) and the results compared.
Scorers judge the final output against the target, and the choice of scorer is a trade-off between precision and flexibility. exact() matching is fast and deterministic but brittle to valid variations in phrasing. model_graded_qa() handles paraphrasing and nuance but is non-deterministic and costs money to run. Each scorer declares its own metrics, so a result describes how it was measured.
In addition there are three other pieces that complete the picture:
Sandboxes provide isolated environments configured per sample, so different samples can run at different isolation tiers. A standard coding task runs in Docker. Something that probes network services runs in Kubernetes with gVisor. A cyber evaluation where container escape is a realistic concern runs in a Virtual Machine. The isolation tier is matched to what the task can do if it gets loose. For further information on sandboxes, please read the page Isolate.
Agents compose solvers, tools, and planning for the complex end of the spectrum. Inspect provides a built-in ReAct agent, multi-agent handoffs, and an Agent Bridge for running external agents (OpenAI Agents SDK, LangChain, Claude Code) inside evaluations.
Inference limits cap how much room a sample gets, whether through a token budget, a wall-clock timeout, a maximum number of messages, a finite number of times the agent can submit a solution, or a cap on tool calls. They are set per sample or per task and recorded alongside the result, because the same task at a higher budget can produce a higher score. A result is only interpretable next to the limits that produced it, so limits are a first-class part of an evaluation rather than a runtime detail.
python@task
def hello_world():
return Task(
dataset=[Sample(input="Just reply with Hello World", target="Hello World")],
solver=[generate()],
scorer=exact(),
)
bashinspect eval hello_world.py --model openai/gpt-4o
This is a complete, runnable evaluation. The model, solver chain, and scorer can each be swapped independently, so the same task runs against any supported provider with any elicitation strategy or scoring method. Full documentation at inspect.aisi.org.uk.
Task composition, colour-coded by the glossary: a sample's input (blue) drives the solver (green) while its target (blue) is checked by the scorer (yellow), and samples, solver, and scorer compose into a Task. A sandbox (purple) can be attached per sample, and an agent composes solvers, tools, and planning for the more complex evaluations. Each component can be swapped independently behind a single CLI.
Extending the framework
With forty model providers, five sandbox backends, and hundreds of evaluation-specific tools, the ecosystem needs to grow without everything living in the central repository. Inspect handles this through Python's standard setuptools entry points, so anyone can extend the framework by publishing a package. Contributors can extend the framework independently, without coordinating with each other or modifying core code, allowing the ecosystem to grow organically.
There are five extension points:
- Model Providers (40+): OpenAI, Anthropic, Google, Mistral, AWS Bedrock, vLLM, Ollama, Hugging Face, and more. Adding a new provider means implementing one class.
- Sandbox Environments: Docker (built-in), Kubernetes, EC2, Proxmox, Modal. Each implements a lifecycle interface (setup, exec, cleanup).
- Tools: bash, python, browser, text editor, computer use, plus full MCP integration for connecting to external tool servers.
- Approvers: policies for approving, modifying, or rejecting tool calls before execution. Human-in-the-loop or automated policy gating.
- Hooks: lifecycle events (run start/end, task start/end, sample start/end) for logging, monitoring, and integration with external systems.
This is how 50+ contributors across organisations build and share evaluation components independently.
Beyond pass/fail
Running evaluations produces data. However, a pass rate on a large benchmark doesn't tell you why a model failed, or how it behaved along the way. The hardest part of evaluation is understanding the results.
Inspect treats analysis as a first-class concern across the full evaluation lifecycle.
Structured logs
Every evaluation produces a detailed log: the full conversation transcript, every tool call and its result, sandbox interactions, timing data, and scores. Logs are JSON-based and programmatically accessible via Python, or browsable in the web-based Inspect View, which updates live as evaluations run.
Eval sets
Real evaluation campaigns aren't single tasks but are instead coordinated runs across models, benchmarks, and configurations. Eval sets provide the infrastructure: automatic retry with exponential backoff, sample preservation across failures (completed work isn't repeated), and resumable runs that pick up where they left off. Results can be bundled into standalone log viewers deployable to static hosting.
Transcript analysis
Inspect Scout is a tool for systematic, quantitative analysis of agent transcripts at scale. It uses scanners, functions that detect specific signals in transcripts:
Is the model declining tasks because of safety training, or because it genuinely can't do them?
Is the model behaving differently because it knows it's being tested? The International AI Safety Report 2026 flagged this as a growing concern for pre-deployment testing.
Is the model trying to use tools it doesn't have access to, suggesting the evaluation setup may be under-measuring capability?
Scout scales to thousands of transcripts in parallel and transforms unstructured agent trajectories into structured data for downstream analysis.
The evaluation lifecycle. Design, Run, Analyse, Understand. Each stage is served by specific tools.
Inspect Evals: 150+ benchmarks, one command
inspect_evals is a community-contributed collection of benchmarks built on Inspect. It is the largest open-source library of AI security and capability evaluations.
bashpip install inspect-evals
inspect eval inspect_evals/arc --model anthropic/claude-sonnet-4-20250514
Benchmarks span 11 categories across capabilities and security. On the capabilities side, they cover knowledge, reasoning, coding, mathematics, assistants, multimodal understanding, and writing which includes widely used benchmarks like MMLU, SWE-bench, and GSM8K.
The security focused categories are the ones most relevant to this playbook. Safeguards evaluations (AgentHarm, WMDP, StrongREJECT) test jailbreaks, harmful content generation, and weapons knowledge. Scheming evaluations probe self-proliferation, self-reasoning, and situational awareness to account for the fact that a model may behave differently when it knows it's under evaluation. Cybersecurity evaluations assess offensive capabilities in CTF challenges.
Every benchmark composes the same primitives from section 3, which is why 50+ contributors can add evaluations independently. The framework handles orchestration, sandboxing, and scoring, so the benchmark author only needs to provide the samples, solver chain, and scoring criteria. The full catalogue is in the inspect_evals repo.
Agentic cyber evaluations
inspect_cyber is a purpose-built extension for evaluations where an AI agent is placed in a sandboxed environment and tasked with performing cybersecurity operations.
Evaluations defined declaratively (challenge name, agent prompt, sandbox config, flags, checkpoints).
Multiple variants per evaluation (different prompts, difficulty levels, sandbox types) sharing infrastructure.
Ordered checkpoints for partial-credit scoring on multi-step challenges. A model that gets halfway through a CTF challenge scores better than one that doesn't start.
Validate that an evaluation is correctly configured and solvable before spending on model runs.
Full docs at inspect.cyber.aisi.org.uk.
Getting started
bashpip install inspect-ai
inspect eval inspect_evals/arc --model openai/gpt-4o
inspect view
Full documentation at inspect.aisi.org.uk.