magus v0.4.3 is out. See what's new
¶ View markdown source · ✎ Suggest an edit
2 min read

Benchmarks

Two things are measured, and both results are committed with the environment that produced them, so a number on this site can be traced to a date, a version and a machine rather than remembered.

The agent harness benchmark

The question is narrow: given the same model and the same task, does the magus agent integration (skills, hooks, the routing index, the guard) make an agent cheaper, faster, or more often correct than the same agent with only a magusfile? Two arms run every task, rampant with the bare workspace and full with everything magus agent install ships. The agent is the same in both, and the only variable is what magus puts in the workspace.

Tasks come from two sources. SWE-bench Verified, the human-validated set of five hundred real GitHub issues, is run inside each instance's own container with a magusfile added, graded by the instance's own tests. A small set of tasks on an enriched monorepo fixture covers what single-package repositories cannot reach: cross-project affected sets and generated-output drift.

Every task is checked by an exit code, never by the agent's own claim, and two controls run before any number is trusted: the golden control applies the known solution and must pass, the null control changes nothing and must fail. A report's first table says whether both held. The statistics are the community's: paired differences with a seeded bootstrap interval and a Holm adjustment across tasks, Wilson intervals on pass rates, pass^k for reliability, and cost-of-pass, the expected dollars per correct solution.

Published runs:

Read a pilot for what it is. Three reps on one task cannot separate the arms on correctness, and the reports say so in their caveats; what they can show is the direction and size of the cost difference, and both models agree on it.

The runner, the task definitions, the grader and the analysis live under benchmarks/agent with a README that walks through running a grid yourself.

The build-tool comparison

Build-tool benchmarks times magus against make on one fixture with hyperfine, with turbo, nx, lage, moon and bazel pinned for the matrix to come. The results carry their date, hardware and exact tool versions. The scenarios are under benchmarks.

benchmarksagentsharnessperformancemeasurement
Last updated (ebec0d8b)
Earlier changes on this page (1)

Full history ↗ · Blame source ↗

Glossary

Workspace

The magus root directory that owns a set of projects and shared config; the unit magus operates over. Workspace in full.

Project

A directory magus recognizes as a unit of work (it has a magusfile); the unit of caching, scheduling, and dependency tracking. Project in full.

Magusfile

The magusfile.buzz that declares a project's targets (as export funs) and binds its spells. Magusfile in full.

Op

A single tool-native command a target composes (long form: operation); the middle of the work hierarchy (Spell to Op to Target). Op in full.

Affected

The set of projects touched by a change; magus affected <target> runs a target only over them. Affected in full.

Trace

OpenTelemetry's name for one whole magus invocation; every target it runs is a span beneath it. Trace in full.

Agent

A model working through an agent host such as Claude Code, Codex, Cursor or OpenCode. magus treats an agent as one more caller of its CLI, MCP tools and console, held to the same checks as a person. Agent in full.

Tool

An action a model can call through its host: a name, a description, a typed input and a result. magus serves its tools over MCP, each a read of the workspace model or a run of the CLI it already has. Tool in full.

Harness

The deterministic scaffolding around the work on a change, for a person or an agent: compiler errors, formatters, linters, checks, gates, leases and hooks, placed at points a person chose. Around an agent's loop, magus supplies one and keeps it outside. Harness in full.

Skill

A packaged set of instructions an agent host loads when a task matches its description: a directory holding a SKILL.md. magus ships its magus-* skills in the binary and writes them with magus agent install. Skill in full.

Run

One target executing under one magus invocation, such as magus run test web or magus affected ci. A run keeps its captured output behind an output reference. Every magus run is a run whether or not any job asked for it; see Job for how the two relate. Run in full.

Conventions

This page uses none of the site's convention markers. The full set is on the conventions page.