I run an API service whose entire development workflow — code, deploys, monitoring, even its own blog — is operated by one person plus AI agents. That arrangement survives on one discipline: the agents' instructions and memory live in plain files, and every rule in those files is justified by what it does to the token bill. This playbook is that system, as I actually run it.
The core observation: AGENTS.md is not documentation. It is a budget. Every rule you write (or fail to write) shows up on your invoice. A discussion making the rounds on X this week — developers banning their agents from writing UI unit tests via AGENTS.md — is the same realization arriving one rule at a time. Here is the full system instead.
AGENTS.md is now governed by the Linux Foundation's Agentic AI Foundation, is read natively by 30+ tools (Codex, Cursor, Cline, Copilot, Gemini CLI, Aider, and more), and sits in over 60,000 repositories. If you pay for model tokens by the million — as you do on any bring-your-own-key setup — this file is where your cost discipline lives. Disclosure: Wallaby Token sells API access to the kimi-k3 reasoning model; the endpoint and the bill screenshots below are ours. The bills shown are real, not estimates — and where an argument is mechanistic rather than measured, the text says so.
Why positive rules alone leak money
Most AGENTS.md files tell the agent what to do: how to build, how to test, where things live. Necessary — but the expensive behavior is what the agent does by default. Left unconstrained, coding agents tend to:
- write tests for everything, including pure-presentational UI with no logic to break
- verify visual changes by driving a browser frame by frame instead of letting a human glance at it
- "improve" code outside the task's scope
- explore widely before acting, re-reading the same files every session
Each of these is thousands of tokens, multiplied by every session, every day. The fix is a forbidden list: explicit "do not" rules that cut the leaks at the source.
The forbidden list (steal this)
These five rules live in our own repositories' AGENTS.md. Each exists because we watched it waste tokens in production:
## Forbidden without explicit human approval
- DO NOT write unit tests for presentational UI (no business logic). Visual
verification is a human's three-second job; an agent's version costs
thousands of tokens in screenshots and DOM comparisons.
- DO NOT use computer-use / browser automation to click through the UI as
acceptance testing. Produce an impact checklist; a human clicks.
- DO NOT refactor, reformat, or "improve" code outside the task scope.
- DO NOT add features, fallbacks, or configurability nobody asked for.
- DO NOT write prose explanations into instruction or memory files —
operational statements only.
The first two alone are what the X thread was groping toward. The third is the quiet killer: unrequested refactors pollute diffs, break reviews, and burn tokens on code that did not need to change. The last one keeps the file itself cheap — AGENTS.md is loaded into every session, so every wasted line in it is a recurring tax. Keep it between 100 and 300 lines; several tools truncate or quietly deprioritize files beyond ~32 KiB.
Positive rules that pay for themselves
Three we rely on:
- Scope the search. Tell the agent exactly which directories matter for common task types. Unscoped exploration is the largest single leak in agentic coding.
- Name the verification command. One canonical "run this to check your work" (a test suite, a build) beats the agent inventing a new verification ritual each time.
- Require closeout notes with a drift check. At the end of a task, the agent records what changed against what was planned. Borrowed from spec-driven development's analyze step: intent and outcome drift apart silently unless you check.
The layer above: memory that ages on purpose
AGENTS.md handles standing instructions. It does not handle state — what we were doing yesterday, which decisions are settled, which experiments failed. For that we run a three-tier file memory alongside it:
- Active — work in flight right now. Loaded every session.
- Standby — touched in the last 30 days. Loaded on demand, by pointer.
- Dormant — aged out automatically; an append-only log with dates.
Two disciplines make it cheap. First, process notes are deleted at closeout — git history and the decision log already hold what matters; the blow-by-blow is the biggest token garbage source in any memory system. Second, entries idle for 30 days drop a tier automatically. The result: the per-session memory load stays small and bounded instead of growing forever. (If you have seen heavier approaches — vector stores, background "dreaming" consolidation — they work, but for one person they are over-engineering you cannot inspect or git diff. Plain files win.)
I run exactly this on my own production project, every day, through the same gateway I sell.
What one run costs (real bill, honest caveat)
Theory is cheap; here is the meter. I asked an agent (Codex CLI + kimi-k3, configured per our Codex guide) to build a complete landing page for a bookstore — scaffold, write 300+ lines of HTML/CSS, recover from its own tool-call mistake, done in two minutes:
$0.16 all-in. Note the cache line: 85k of the 91k input tokens were served from cache at one-tenth price, because the agent's large system prompt repeats every turn. One honesty note: I have not run the undisciplined control arm, so the case for the forbidden list is mechanistic, not an A/B measurement — every banned behavior is an extra request loop, every loop resends the framework prompt, and every resend is billable. The bill above is real; the savings argument is arithmetic, and you can reproduce it on your own dashboard in an afternoon.
Get the template
Our full starter AGENTS.md — forbidden list, scoped-search rules, closeout ritual, and the three-tier memory convention — is available as a plain file you can drop into any repo: download the template. Adapt the paths and commands to your project; keep the forbidden list verbatim for a week and watch your dashboard.
Pricing
All prices are per 1M tokens of kimi-k3.
| Wallaby | Official list | |
|---|---|---|
| Input | $2.70 | $3.00 |
| Cached input | $0.27 | $0.30 |
| Output | $13.50 | $15.00 |
New accounts receive $0.50 in free credit — enough to run the bookstore task above several times. The minimum top-up is $20.
Get started
Create an account at wallabytoken.com, then put the template into your repo and point your agent at the endpoint using the Codex or Cline guide. Per-request billing settles in seconds — which is exactly why cost discipline is worth writing down.
What we do differently
Every request appears on your invoice as an itemized line with its token counts, so you can reconcile spend against your own logs. We host open-weight models only, and we add models based on sustained usefulness rather than launch-cycle attention.
Reliability you can verify
We operate a public status page so you can verify availability independently before troubleshooting your own setup. Our terms are written in plain language and publicly accessible. Wallaby Token is a registered Australian company with an ABN on file, and we run our own development workloads through the same gateway we sell.