mythos-router: Strict Write Discipline for AI File Edits

The claim-versus-filesystem problem mythos-router targets

An agent says it edited src/config.ts. The file may not exist, may not have changed, or may have changed in a way the agent did not describe. Most tooling trusts the model's summary. mythos-router takes the opposite position, stated plainly in the README: the trust boundary is the filesystem, not the model. It is aimed at engineers who run AI coding agents on real repositories and want the file operations checked rather than narrated. The README calls it a local CLI power tool for verifiable AI-assisted coding, built around Strict Write Discipline, abbreviated SWD. The project ships a built-in Claude Opus 5 agent through mythos chat and mythos run, but the verification layer is described as model-agnostic. That matters, because the interesting part is not the bundled agent. It is the checker that any agent can be routed through.

How SWD verifies a batch and rolls it back

The mechanism is snapshot comparison. Before a batch of file actions runs, mythos-router takes pre-state snapshots; after the batch, it takes post-state snapshots and compares hashes with what the agent claimed it did. The README states that file operations are checked against the actual filesystem using SHA-256 snapshots. If a claim does not match reality, the batch is rolled back so a bad write never half-lands. Agents can express actions in two ways. By default they emit text FILE_ACTION blocks; with --tools, Anthropic and OpenAI native tool-calling is used instead, and the README says verification is the same either way with automatic fallback to text. A run produces a receipt recording touched files, hashes, provider or external-agent id, budget, git state, and the verification result. Receipts are hash-chained and serialized under a repository lock. The README is careful here, and the caveat is worth repeating: atomic receipt and HEAD writes detect local gaps, reordering, forks, partial edits, and unsynchronized writers, but the local chain is tamper-evident, not an external authenticity proof. Read that as a design boundary, not a marketing line.

Installing mythos-router and verifying your first batch

The README gives a single command to try it, run through npx:

npx mythos-router chat

The package declares two binaries, mythos and mythos-router, both pointing at dist/cli.js, so the shorter name works once installed. For a repository you intend to use it on, the README documents a single-command onboarding step with environment validation, a read-only --check mode, and scaffolding:

mythos init

Before trusting anything to it, run the read-only health check. The README describes mythos doctor as read-only workspace checks covering policies, receipts, sessions, telemetry, filesystem safety, and interrupted SWD transactions. The --repair flag is documented as recovering inactive transaction journals only, so it does not silently rewrite your tree:

mythos doctor

If you want to route an external agent through SWD without the bundled model, the README documents stdin and JSON input with no Mythos model key required:

mythos swd apply --stdin --json

A runnable demonstration lives in examples/verified-writes, described in the README as a demo where the agent hallucinated a write and SWD caught it. That example is the fastest way to see the rollback path without risking a real repository.

The cost router and the escalation cap

The feature table describes a verified cost-router behind --escalate. A run starts at a cheap --effort level and climbs one model tier per Correction Turn, but only when SWD verification fails. The stated intent is to pay for the expensive model only when the cheap one is provably wrong, with --escalate-to capping how far it climbs. This is a genuine coupling of two normally separate concerns: verification failure becomes the trigger for spending more. The constraint is that escalation is bounded by Correction Turns, which the README describes as two retries for the model to match filesystem reality before it yields. So the worst case is not an unbounded spend loop, it is a run that exhausts its retries and stops. Whether that is the right trade-off depends on how often your agent's writes fail verification in the first place, and the README does not publish a rate.

Where mythos-router is the wrong tool

Two limits are stated in the README and deserve to be taken literally. First, the receipt chain is local and tamper-evident, not an external authenticity proof. It detects internal inconsistency, not a determined adversary. Second, verification covers file actions. It does not audit network calls, shell commands outside the checked batch, or anything the agent does that leaves no filesystem trace. If your threat model is a hostile process on the same machine, this is not the layer that stops it. There is also a practical cost: every verified run takes pre and post snapshots and writes a receipt under a repository lock. On a large tree that is real work per batch, and the README does not quantify the overhead. The project is TypeScript, Node 22 or later, and the deterministic reasoning cache and the FTS5 memory index are both marked as requiring Node 22+. Teams pinned to older runtimes lose those pieces. Finally, the bundled agent path assumes provider keys. The .env.example lists ANTHROPIC_API_KEY, OPENAI_API_KEY, DEEPSEEK_API_KEY, and SURPLUS_API_KEY, so the model side is bring-your-own-key rather than included.

How it differs from a git hook or a pre-commit check

The obvious alternative is a pre-commit hook plus git diff. That approach checks the tree after edits land and gives you a reviewable patch. mythos-router works earlier and differently: it compares the agent's stated actions against the filesystem before accepting the batch, and it can roll the batch back when the claim and the tree disagree. A pre-commit hook cannot tell you that the model claimed a write it never made, because the hook has no record of the claim. The receipt is the artifact that carries that record, with hashes, provider id, budget, and git state per run. The trade-off is scope. Git history is a format every tool already understands; SWD receipts are specific to this project, and reading them means using its own commands, such as the documented receipts undo <id|latest>, which previews by default, requires --yes to apply, is drift-gated so it never overwrites newer edits, and produces its own receipt. If your workflow already has strong review discipline and a human reads every diff, the added layer may be more machinery than you need.

Maintenance, licence and upgrade surface

The repository is not archived, and the last push was on 2026-09-10, days before this writing. Recent releases are v1.21.0 on 2026-06-21, v1.22.1 on 2026-07-03, and v1.23.0 on 2026-07-11, so the release cadence in the supplied history is roughly every two to three weeks, with no release after mid-July. The licence is MIT, which permits commercial use and modification; that is a statement about the licence text, not legal advice, and you should read LICENSE in the repository for the terms that bind you. Upgrade cost concentrates in two places. The Node 22+ floor gates the caching and memory features, so staying current with the project eventually means staying current with the runtime. And because receipts are hash-chained and serialized under a lock, any change to receipt format across versions is the thing to watch in CHANGELOG.md before upgrading a repository that already holds a chain. The package exposes schemas at ./schema, ./policy-schema, and their explicit paths, so a policy file and an external-agent action format both have published JSON schemas to validate against.

Editorial conclusion

Adopt mythos-router if you already run an agent that touches files and you want a filesystem-level check on what it reports, since the engine verifies external agents over stdin or MCP without a Mythos model key. Do not adopt it as a security boundary against a hostile process: the README states the receipt chain is tamper-evident locally, not an external authenticity proof, and it is written to catch drift and hallucinated state, not an attacker with disk access. Before wiring it into CI, run mythos doctor and mythos verify --ci against a copy of your repository and confirm that the policy file and receipt directory land where you expect.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. thewaltero/mythos-router on GitHub