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

spawn-above-parent-tier

A deny rule by default: it refuses a subagent spawned on a model whose tier ranks above its spawner's, and names what to run instead.

What it catches

A subagent spawned on a model whose tier ranks above its spawner's.

Why

A child never outranks the work that handed it out: the root session runs on the model the person picked, and every agent below it stays at that tier or lower. Both models resolve to tiers by an exact alias of the spawning host in the workspace's model-tier declaration, or by the exact id of a mgs_listModels row that names a tier, and compare by rank, never by name or price. A spawn naming no model is never judged. Any other model has an unknown tier: magus never infers one from a name, and advises once naming the model, the aliases the declaration maps and the mgs_listModels row to add. The spawner's model is proven when its host reported it: a main thread's from its transcript once the host has reported the thread, a subagent's from the model its spawn named. Proven, the spawn is refused; a subagent spawned on no model is taken to run on the session's, which is inferred and advised once. magus job fork holds a child row to its parent's tier the same way. The way up is a person's: they fork the higher-tier row and run it from a session at that tier. Set to advise, proof is advised too.

Default and override

By default this rule takes the decision deny. A workspace sets it by name, in its root magusfile, to deny, advise or off:

magus\guard.builtins({"spawn-above-parent-tier": "advise"})

A loosening takes effect once it is committed; a tightening applies at once.

Seeing it

A verdict names its rule in brackets, which is how you got here:

deny [spawn-above-parent-tier]: ...

A workspace that sets this rule to advise sees advise [spawn-above-parent-tier]: ... instead.

magus describe rule spawn-above-parent-tier prints the same entry at a terminal, and magus describe rules lists every rule this workspace enforces.

See also

ReferencePages in this section. background-left: an agent finishing while shell commands it ran in the background are still runningA deny rule by default: it refuses an agent finishing while shell commands it ran in the background are still running, and names what to run instead. check-timeout: a bound worker's magus run whose timeout is shorter than the target's last real run allows forA deny rule by default: it refuses a bound worker's magus run whose timeout is shorter than the target's last real run allows for, and names what to run instead. human-only: a magus run reaching a human_only target: the person is asked, a leased worker refusedA deny rule by default: it refuses a magus run reaching a human_only target: the person is asked, a leased worker refused, and names what to run instead.
guardrulesspawn-above-parent-tierdeny
Last updated (73992e6a)
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.

Magusfile

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

Buzz

The language magusfiles are written in (the .buzz engine). Buzz 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.

Session

An agent host's conversation, by the id the host delivers to its hooks. magus never mints one: a record with no session is unattributed, and the OS user it carries says whose account ran it. Session 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

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