Abide checks every agent edit against your AGENTS.md rules

Rules that live in prose and cannot be scripted

Abide exists to enforce a category of rule that no linter can check. The README puts it plainly: your AGENTS.md, CLAUDE.md and the rest of your project instructions are full of rules no linter can check, with the examples being never let a raw error reach a user and don't create premature abstractions. Nothing can script those, so nothing enforces them. The measurement in the README is that in 93 real sessions the agent broke one of these rules on one turn in 13, from the first edit onwards, and that the 1,256 edits and 147 turns came from replaying 93 real Claude Code sessions in two repos against their own AGENTS.md, at a cost of 22 cents. Abide's design follows from that. It does not ship a rule catalogue, there are no built-in rules and no instruction files, so there is nothing to enforce until your own repository states the rules. That design decision is the main thing to understand about it, and it also means the tool is only as good as the specificity of the rule text you already have.

One question per rule, answered with a probability

The mechanism is a decision model rather than a language model, and the choice of model is the technical core of the project. On every edit or turn, Abide asks Jev, described as TypeSafe's decision model, one question per rule and gets a probability back. Jev sees the rule and the diff, never the conversation, which the README points at as the reason edit 200 is checked like edit 1. The decision model answers a typed question with a calibrated probability and nothing else, so there is no free text and therefore nothing to make up. The README quantifies the difference: an ordinary LLM check is about 2,500 tokens, which at typical model prices is a cent or more and a few seconds per edit, and the answer comes back as prose you have to parse and cannot fully trust. Jev is described as up to 100x cheaper than a typical LLM and answering in about 300 ms, at a few thousandths of a cent per call. Break a rule and the agent is told which one and fixes it in the same turn, with no human in the loop.

Setup is two commands and a key

The install path is short. A TypeSafe API key is needed, from typesafe.ai, or you can use a Vercel AI Gateway key you already have. Then the login and init commands.

npx @coldtea/abide login    # pick a key type, paste it once
npx @coldtea/abide init     # hooks into every agent on this machine

The login step asks which kind of key it is and where it lives, and it goes to `~/.abide/.env` for every repository on the machine, or to `.env.local` in the repository you are in, owner-only either way. A `.env` you already have at the repository root works too. The `init` command with no name installs into every agent it finds, and adding `--project` installs into the repository instead so that teammates get it with the checkout. The documentation is explicit that the key and the data are yours and that nothing talks to a server belonging to the project. After that you start `claude`, `codex`, `opencode` or `pi` as usual, and the agent's first turn compiles your rules into `.abide/rubric.json` and reports what it found.

Four agents, four different integration mechanisms

The integration is not uniform, and the differences are technical rather than cosmetic. Claude Code uses a hook installed into `~/.claude/settings.json`, Codex uses a hook installed into `~/.codex/hooks.json`, and both take the same `npx @coldtea/abide init` form with the agent name appended. For Codex there is an extra manual step, since you start codex, type `/hooks` and accept the four abide entries, and Codex asks this once for any new hook. Codex also edits through `apply_patch`, so abide reads the patch and judges every file in it. OpenCode has no hook processes at all, so it runs as a plugin at `~/.config/opencode/plugins/abide.js`, and the mechanism differs slightly: an edit that breaks a rule gets the repair request appended to its tool result, and a turn that ends with one gets a single follow-up message. Pi installs as an extension at `~/.pi/agent/extensions/abide.js` and must be restarted or reloaded with `/reload`, and Pi must trust the project before loading it. `CLAUDE_CONFIG_DIR`, when set, replaces `~/.claude` for Claude Code's settings file and global CLAUDE.md, as it does for Claude Code itself, and `PI_CODING_AGENT_DIR` selects a different user-level agent directory for Pi.

Auditing a codebase you did not write

The audit command is the part that helps before you have enabled anything, and it works on files rather than on a live session.

abide audit src/

Every file is judged as if it had just been written, and you get a table by rule and a list by file. The README gives one measured data point for it: on 33 API routes of a real Next.js app, 12 seconds and about a cent. That is a cheap way to find out whether your existing rules describe things your code already violates, which is the question to answer before wiring up a per-edit check. It also gives you a feel for how noisy your rules are. A rule that fires on existing code is a rule that will fire on every future edit, and the audit is the cheapest way to find out which ones. There is also a replay command for recorded sessions, mentioned for Claude Code and for Pi, which checks recorded edit and write tools on the active persisted branch.

What the published numbers actually measure

The evaluation claims are specific enough to be checked, and the README points at the method. The stated figure is that 1 in 13 turns breaks a rule no linter can catch, at 300 ms per check and a tenth of a cent per turn. The subtext gives the sample: 93 real Claude Code sessions, 1,256 edits and 147 turns, in two repositories, measured against their own AGENTS.md, for 22 cents in total. And the honest part is what came out of it. Jev flagged 39 edits and 15 turns, and an independent reviewer confirmed 10 and 11. The turn-level catches, which are the single-use abstractions, oversized files and duplicated logic, held up 11 times in 15. The method, the per-rule table and a description of what was wrong are in the benchmarks/replay directory. So the headline is a mix: only 10 of the 39 flagged edits were confirmed, while the turn-level category held up in most cases. Anyone evaluating this should read that directory rather than the summary.

A rule set the tool can act on, and the parts it will not judge

Two boundaries are stated in the README and both matter in practice. The first is that rules a linter could check are handed to your linter instead, which is the right division of labour and also means Abide is not a substitute for formatting, typing or lint enforcement. The second is that the model sees the rule and the diff and never the conversation. That is what makes the check cheap and consistent across a long session, and it is also a real limit: a rule whose meaning depends on context outside the diff, on why the edit was made, or on a decision made earlier in the session, cannot be judged from the diff alone. The example output shows the shape of a failure, with the rule name and its source location, the quoted rule text, the score, and the file it was scored in.

Abide: This edit appears to break a rule from this repository's instructions.
- Rule "api-validation-uses-yup" from ~/.codex/AGENTS.md line 65: "When writing API endpoints, do NOT write input validations manually. Use Yup (with clear validation messages) + early return in the API handler". Scored 0.86 in apps/web/src/pages/api/logout.ts.
Repair apps/web/src/pages/api/logout.ts now, then continue with the task.

The agent is then told to repair the file and continue with the task, and the README notes the agent repairs it before moving on.

Editorial conclusion

Adopt Abide if your project has written rules that no linter can enforce, you run one of the supported agents, and you are willing to add a per-edit check to the loop. Skip it if your rules are all mechanically checkable, since the documentation says those should go to your linter instead, and skip it if a per-edit network call is unacceptable in your environment. Before you commit, read the replay benchmark method in benchmarks/replay, since the published catch rate is measured by the project's own harness, and check that your rules are stated in a file the agent's first turn can compile into a rubric.

Frequently asked questions

Official sources

1. coldteadotai/abide on GitHub
2. Issues
3. License: MIT
4. README