Your rules load every time. Not most of the time.
Every developer working with coding agents ends up with standing instructions: the conventions, the landmines, the “always run this first.” The common pattern is a markdown file the agent probably reads. Probably is the problem. Haybox assembles the model’s context itself, so rules injection is deterministic by construction — a guarantee, not a habit.
Plain files, two scopes
One global file for you; one file in the repository root for the project. Both are plain markdown you own and edit. The project file rides in git, so a rule change is reviewable in a pull request like any other change to the codebase. Where the two conflict, the project file wins; the more specific scope should.
haybox.md
# haybox.md (illustrative)
- Prefer plain Python over adding an abstraction.
- Run the regression suite before proposing any diff
to scanner.py or anything under patterns/.
- New endpoints require a test and a changelog line.
| Scope | File | Wins when they conflict |
|---|---|---|
| Organization | policy object | Always; cannot be overridden locally |
| Project | haybox.md in the repository root | Over the user file |
| User | your global haybox.md | Only where the project is silent |
Bring the files you already have
Haybox reads CLAUDE.md, AGENTS.md, and .cursorrules natively, with configurable precedence, from day one. It reads them and never writes them: your files stay yours, and nothing edits them behind your back.
Every rule that reaches a model is attributed to the file it came from, so when a rule produces a surprising result you know which file to open. Gateway users get this with zero migration: the rules you’ve already written start applying to routed work the moment traffic flows. We’d rather read the emerging conventions well than invent a competing one.
Budgeted, visibly
Rules cost context, and context costs money. On this product, that statement is measurable. Rules are loaded under a stated budget, and if a file outgrows it you get a visible notice saying so. Nothing is silently truncated, and the Ledger reports what your rules cost per task, so a bloated rules file shows up as a number instead of a mystery.
Kept apart, on purpose
Rules and everything else Haybox knows are per-project. Not per-project by default — per-project by construction: in v1 there is no cross-project path at all, so there is no setting to get wrong and nothing to leak through. If you work across clients, that sentence is the feature: client A’s code cannot inform suggestions in client B’s repo, because no mechanism exists that would let it.
Questions
Is this the same as my editor’s rules file?
Same idea, guaranteed delivery, plus one file that applies across every tool you route through Haybox.
Can rules force routing behavior?
Routing posture lives in the policy file; rules are instructions to the models. The two files sit side by side and the docs cover both.
What’s the file called?
haybox.md, and AGENTS.md is read natively; use either.
Agent & VS Code · Router · Works with Claude Code · Isolation, on the security page · All features
See what your own traffic says.
Shadow Mode reports on the traffic you already have. Before that exists for you, the calculator will estimate it from your GPU and your monthly spend, and show you every assumption it used to get there.