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

Every answer has an address

This is the mechanism the rest of magus stands on, and I do not want it to read as a detail. Every target run mints an output ref like out357f0f8559ae. It is not a counter or a random id. It is the head of the run's cache key, and the key is a hash of everything the run declared: its sources, its toolchain, its project and target, the key schema version. Nix does the same for a store path. Change one input and the address changes; keep them and the address is the same on a laptop, on a runner, and next month.

That one property buys a lot. A cache hit is a lookup by address, so replaying a run is as honest as its declarations. A ref in a pull request, a CI log or an agent's report points at exactly one run, and magus query output <ref> prints its full log wherever the run happened. magus x <ref> reproduces it. Two machines that disagree about a build can compare two short strings before they compare anything else. An agent can hand back a ref instead of pasting a thousand lines, and the person checks the evidence rather than the agent's prose about it.

The address is only as good as the declaration. A target that reads a file it did not declare gets a key that cannot see the file, and a stale hit follows. So under-declaring an input is the one way to make an address lie, and the sandbox, the drift gate and describe target --cache --inputs exist to catch it.

Enforced by

  • The cache key hashes the declared inputs in a fixed order, with keyVersion bumped whenever the hashed fields change.
  • The sandbox limits what a target may touch to what it declared.
  • magus job wait accepts a worker's result only with an output ref bound to a passing run of that job's own check.

Good

The ref is the key's head, and the key names its version (magus query output <ref> --identity):

ref:     out357f0f8559ae
key:     357f0f8559aece810f016bfa3ac3110b0ea9823e43976e6cca2b4796f3e2a863 (keyVersion 7)

Bad

Build #48213 passed. See the CI page for logs.

A build number says when something ran, not what ran. It cannot be recomputed from the source, it differs on every machine, and it points at a log that a retention policy will delete.

See also

PrinciplesPages in this section. SpellsA spell is a library of tool-native ops (go-build, cargo-clippy, eslint) plus cache metadata that your magusfile composes into runnable targets. magus documentationThe magus documentation hub covering install, targets, spells, charms, operations, engines, remote caching, MCP, telemetry, and the interactive playground. magus stdlibReference for every magus stdlib module - fs, os, http, json, yaml, crypto, and the rest of the magusfile API.
designprinciplecachedeterminism
Last updated (2df714e8)
Glossary

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.

Target

A named operation (build, test, ...) you invoke with magus run <target>; it may compose a spell's tool-native operations and depend on other targets. Target 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.

Cache

The content-addressed store magus consults before running a target, so unchanged work is skipped. Cache in full.

Sandbox

The restricted filesystem and environment a target runs in, so builds stay reproducible and side-effect-free. Sandbox in full.

CI

An ordinary target you compose yourself with ctx.needs; magus does not hardcode its stages. It is the anchor magus affected ci keys off, and ci strips the rw charm. CI 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.

Job

The unit of delegated work, and one row of the job store: what an orchestrating agent handed out, with its goal, the checkpoint it was cut against, the paths it may write or must not touch, and the one check it runs. A job's holder is either a session, for work an orchestrator handed out, or the daemon, for its own maintenance. The store records; the agent guard is what reads those facts back when grading a write. Job 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

Placeholders

Angle brackets mark a value you replace with your own; never type the brackets:

magus run <target>
magus completion <shell>    # e.g. bash, zsh, fish

<target>, <path>, <shell>, <name> and the like are stand-ins, not literal text.