The rules file that agent loads at the start of every session had grown past the runtime’s injection ceiling. It injected what fit and dropped the rest — and what got dropped was the rule I’d appended most recently, because appending to the end is how a governing file grows.

Nothing failed. No warning, no error, no change in the agent’s confidence. It simply operated for weeks under a rule set it had never fully received, and one morning it handed me a financial briefing with account balances it had never fetched — fabricated numbers — surprise, surprise! It’s hallucination! Your agent runtime ships you a component with an unknown (may be undocumented as well) tolerance.

The runtime doesn’t matter, and I’m not going to make this about one vendor — by the end of this you’ll see there are at least ten.

The vendors know

OpenAI’s Codex caps the AGENTS.md it injects at 32,768 bytes. That number isn’t a community discovery — it’s DEFAULT_PROJECT_DOC_MAX_BYTES in codex-rs/config/src/config_toml.rs, and the comment beside the loader describes the behavior in the vendor’s own words: “Larger files are silently truncated to this size so we do not take up too much of the context window.”

The bug report asking for a startup warning — openai/codex#7138, titled “AGENTS.md is silently truncated without any warning within the TUI” — was closed not planned in March 2026. The stated reason: “This feature request hasn’t received any upvotes in three months, so I’m going to close.” It was filed as an enhancement, not a bug. Someone refiled it the next day; #13386 is still open. A user commented there in July that he’d “only accidentally discovered today that my 40KB AGENTS.md was being truncated to 32KB and silently omitting 20% of my instructions.”

That’s the shape of it. The number is sometimes published. The behavior almost never is.

Nobody agrees on the ceiling — or the units

The good guides to AGENTS.md cover the four major coding agents and tell you the size limits. What none of them cover is what happens when you cross one — which is the only part that decides whether your rules are in the model’s context. Here is what the sources actually say:

Sources: Claude Code; OpenClaw; Nous Hermes; Moltis

Two things about this table are worse than any individual row.

The units aren’t comparable. Codex counts bytes. OpenClaw, Hermes and moltis count characters. Anthropic counts lines-or-kilobytes, whichever comes first. That divergence isn’t theoretical: Hermes’ own shipped AGENTS.md measures 75,142 bytes but 74,506 characters. Six hundred and thirty-six units of difference, in one file, on the number that decides what survives. I’ve found no test of how any of these implementations actually counts.

The config keys don’t even share a name — project_doc_max_bytes, bootstrapMaxChars, context_file_max_chars. There is no convention here to be non-compliant with.

And if you want a sense of how well the ecosystem tracks its own constraint, I measured the reference implementations. OpenClaw’s own shipped AGENTS.md is 56,458 bytes against its own 20,000-character cap — roughly 2.8× over. Hermes’ is 75,142 bytes; the issue documenting that 74% of it never reaches the model was closed not planned and labeled cosmetic. (Both measured 20 July 2026 — OpenClaw at e2e394e1, Hermes at 0144743b. They move.) The reference implementations exceed their own limits.

Rule drift

The closest named thing I’ve found is governance decay — safety constraints silently removed by context compaction (arXiv:2606.22528). This is a different mechanism with the same signature, and mine happens before the session even starts.

A governing instruction file grows by accretion, and it accretes at the bottom. You append a rule because something went wrong. You append another because a customer asked. Each edit is individually correct and individually small. Meanwhile the ceiling stays fixed and — in harnesses (the software that runs the agent, the runtime by another name) that truncate silently from the tail, which is not all of them, as the table shows — truncation eats from the end. The file degrades through ordinary, competent maintenance, and no single commit ever looks like the mistake.

This isn’t hypothetical. A survey of AGENTS.md files across 100 popular repositories (arXiv:2606.15828) found measurable context bloat in 42% of them, and “skill leakage” — execution detail sitting in the always-loaded file — in 35%.

The rules that die are the newest ones. Which is to say: the rules you added because something already went wrong once.

The fix isn’t shortening the file. It’s deciding which prefix survives amputation — smaller, blunter, ordered by consequence, with the non-negotiables at the top not because top is more persuasive but because top is what remains. (Order does demonstrably affect adherence — Zeng et al., ACL 2025, arXiv:2502.17204 — though that paper finds hard-to-easy ordering wins, which is not the same as importance ordering. The optimal arrangement is still open.)

One thing that doesn’t help: splitting the file up. Anthropic’s docs are explicit that imports “help organization but don’t reduce context, since imported files load at launch.”

And the reason placement matters at all: a behavior placed in the wrong layer silently never happens. Put “always fetch before answering” in a skill body — which loads only after that skill is chosen — and it cannot help you. The agent decided to fabricate before it ever opened that file.

What the always-on layer costs

This is where it gets commercially interesting, and where I think the discussion is thin.

A rule that must hold on every turn is a fixed per-turn prefill tax. Twelve thousand characters is roughly three thousand tokens. At $5 per million input tokens (roughly a frontier model’s rate) — that’s about 1.5 cents a turn uncached, about 0.15 cents cached.

That tiny number is the problem. I’ve argued before that inference is usually the cheapest line item in an AI product — and here that cheapness turns dangerous: a bloated instruction file shows up as degraded adherence and silent rule loss long before it ever shows up on an invoice. There is no cost signal to catch this.

Two research groups have now measured what the file actually buys, and they don’t agree.

A team from Singapore Management University, Heidelberg, Bamberg and King’s College London (arXiv:2601.20404, ICSE JAWs 2026) ran Codex across ten repositories and 124 merged pull requests, twice each — with the repo’s AGENTS.md and without. Median wall-clock time fell 28.6% and median output tokens fell 16.6%, both statistically significant. Median total tokens went slightly up, about 1.3%, and that result wasn’t significant. So the file bought speed and cheaper generation, not less context. The authors speculate the gain comes from less exploratory navigation; they flag testing that as future work, and they did not measure task success at all. Caveats worth stating: PRs under 100 lines and five files, one harness, one model.

An independent team at ETH Zurich and LogicStar (arXiv:2602.11988) measured something close to the opposite. Across SWE-bench and a purpose-built benchmark, every kind of context file raised cost and step count — machine-generated ones by up to 23%, human-written ones by up to 19%. Success moved −2% for generated files and +2.4% for developer-written ones, and neither result was statistically significant. Their mechanism is the part worth keeping: cost rises because agents actually follow the instructions — more testing, wider exploration — not because the file is padding. What they found genuinely useless was repository overviews, which the agent can read for itself.

These two results point in different directions, and I’d rather say that than average them. One measures wall-clock and tokens on paired reruns of real merged PRs; the other measures dollars and agent steps on benchmarks. What survives both is narrower and more useful than either headline: instruction context is not free and it is not linear. It buys you less exploration, and it buys you more obedience — and obedience costs money too. What it does not reliably buy is a higher success rate. Past the ceiling, it also costs you the lines underneath.

One correction to the obvious conclusion: a file written blind is the failure mode, not machines writing files. Shepard and Albrecht (arXiv:2606.20512) got 33% resolution against 25.5% unguided by probing the agent and iterating the guidance against what actually failed. Generated-then-never-tested is the bad case.

The instruction file is also a cache key. Caching is exact-prefix; edit the file mid-session and you re-price everything downstream. Practitioners are already engineering around it — claude-code#77355, opened 14 July 2026 and still open, is someone maintaining a CLAUDE.staging.md and copying it in at session start “specifically to avoid busting the cache mid-session.” Google prices the same resource on a third axis: Gemini bills cached context by the hour — $1.00 per million tokens per hour of storage on 3.5 Flash, on top of a cached-input rate of $0.15 against $1.50 standard (pricing, read 20 July 2026). You pay rent on an always-loaded block whether or not anything reads it.

So one resource now has three incompatible meters: per-token consumption, per-hour rent, and free-if-the-prefix-matches. Nobody prices against all three.

Does progressive disclosure actually save money? On tokens and accuracy, measurably yes. Anthropic reports a five-server MCP setup — 58 tools across GitHub, Slack, Sentry, Grafana and Splunk — consuming “approximately 55K tokens before the conversation even starts,” cut to ~8.7K with deferred loading, and MCP eval accuracy on Opus 4.5 rising 79.5% → 88.1% (Anthropic engineering, 24 Nov 2025). Internally they’ve seen tool definitions hit 134K tokens before optimization. On net cost, nobody has published a number — and the honest tell is that Anthropic had to build a special mechanism to keep deferred loading from destroying the cache. Naive on-demand loading would cost you cache reuse. That’s why the mechanism exists.

Which produces a question I’d want answered before I signed anything: if the injection budget determines whether my agent’s safety rules hold, and the platform owns that budget — what is it, how is it counted, and what happens when I exceed it, in writing?

It is the same question a buyer asks about any supplied component whose failure is invisible in the finished good: what is the tolerance, how is it measured, and does the supplier tell me when I’m outside it. In every mature supply chain that answer lives in a datasheet and a change-notification clause. Here it lives in a source comment.

Nothing I can find answers it. I’m talking about what a buyer can read before entering a negotiation: Anthropic’s Commercial Terms, effective 17 June 2025, contain no service levels, no context-size language and no truncation language — only that “ANTHROPIC DOES NOT WARRANT… THAT THE SERVICES OR OUTPUTS ARE ACCURATE, COMPLETE OR ERROR-FREE.” Meanwhile the same vendor publishes a twelve-row table specifying its own injected overhead to the single token — 290 tokens of tool-use system prompt on Opus 4.8 under tool_choice: auto, 410 under any, 675 on Opus 4.7, 264 on Haiku 3.5 — broken out by model and by setting (tool use pricing, read 20 July 2026). The platform meters its side of the boundary to the token. Yours it will not name.

The fix

Here is what to actually do — four steps.

1. Measure your file. Run wc -c on your rules file (AGENTS.md, CLAUDE.md, whatever your tool uses) and compare the number to your tool’s limit — Codex cuts off at 32,768 bytes; others differ, and some publish no number at all. If you are over the limit, part of your file is being thrown away every session, and nothing tells you.

2. Put the most important rules first. When a file is cut, it is cut from the bottom. So move your non-negotiable rules to the top, where they survive. Order by what matters most, not by topic.

3. Add a tripwire at the bottom. Make the last line of the file something distinctive — say, RULES-END-DO-NOT-DELETE — and have your startup check confirm that exact line came through. If it is missing, the file was cut, and now you know, instead of finding out from a wrong answer. (That is all a “canary” is: a marker whose absence is the alarm.)

4. For anything that must never be wrong, do not trust the file at all. A rules file is a suggestion — the model usually follows it, and “usually” is fine for judgment calls. It is not fine for a rule about money, which has to hold every time. Put those rules in code instead of text: make the step that reports a balance refuse to run until the balance has actually been fetched. Text can be ignored. Code cannot.

That is the whole fix.

And it generalizes past this one file. When a behavior has to hold every time, the answer is deterministic enforcement, not better prompt wording. No rewrite survives being truncated, ignored, or loaded into the wrong layer — a phrasing you can improve is a phrasing the model can skip. If it must hold, put it where the model doesn’t get a vote: a check, a line of code, the harness. Prose persuades; only structure enforces.

After running mine live for a while, I can report the opposite. The AI is the cheapest, most predictable line item I have — and the economics that actually matter turned out to be somewhere else entirely.

What the model actually costs

The app uses a small, cheap model for its AI features, and I built it to call that model as little as possible:

• A small model, not a frontier one, for tasks that don’t need a frontier one.

• Hard caps on output length and low temperature — predictable tokens in, predictable tokens out.

• Aggressive caching: a cache hit rate north of 80%, so most requests never reach the model at all.

• A free, deterministic data source tried first; the model is only the fallback.

• A per-user rate limit, so no single user can run up the bill.

Add it up and the cost to serve an active user lands on the order of a tenth of a percent of what they pay for a monthly subscription. On the P&L, the model is a rounding error.

The lesson isn’t “models are cheap now,” though they are. It’s that AI cost is an architecture decision, not a procurement one. You don’t get cheap inference by negotiating price-per-token; you get it by calling the model less — cache, cap, prefer deterministic sources, batch. The team that designs for fewer, smaller calls beats the team with a better rate card. That bullet list above is really a pricing decision disguised as architecture.

The line item that actually moves the margin

The expensive part of the app has nothing to do with AI. It’s distribution.

Put it on a single $10 transaction. Route it through iOS in-app purchase and the platform fee takes $1.50 to $3.00 of it; the inference behind that customer’s usage costs a fraction of a cent. The channel takes a couple hundred times what the model does, on the same dollar. So the app applies the long-established “reader” principle — apps from Netflix to Spotify to Kindle handle commerce on the web and use the iOS app for access. That’s the architecture I ended up with. (The formal App Store carve-out is narrow, and the rules are in flux post-Epic and under the EU’s DMA — so the point is the principle, not any one loophole.)

A pricing person’s way to say it: your distribution channel’s take rate is usually a far bigger lever on margin than your cost of goods. I spend my day setting price inside a hardware P&L at scale, where a point of margin is real money and the structure — where value gets captured, not what it costs to make — dominates the model. The app just let me run the same logic at the opposite extreme: near-zero unit cost, and the structure still decides everything.

Two pricing reflexes that break when cost rounds to zero

When your unit cost rounds to zero, two reflexes that served older businesses well both break.

Cost-plus pricing makes you look cheap to your own product. Price a near-zero-cost feature on cost and you’ll price it near nothing — which tells the buyer it’s worth near nothing.

Per-usage metering makes the user anxious about a meter that’s measuring almost nothing — you collect all of the anxiety and almost none of the revenue.

Metering isn’t always wrong, though. It’s the right model when each call does expensive, legible work — a coding agent like Cursor or Claude Code, a per-resolution support agent — because there the meter tracks something the customer can see is worth paying for. It fails only when both the per-call cost and the per-call value are low, which is exactly the consumer-app case: each call is cheap and invisible, so the meter just generates worry. There, bundle pricing and value-anchored tiers win.

The same logic set my lifetime tier. I didn’t price it from cost; I priced it for what someone would pay for the certainty of never being asked to pay again — a willingness-to-pay number, not a cost number. A lifetime plan is normally a recurring-revenue anti-pattern: you trade a stream for a lump and a permanent obligation to serve. I took it deliberately, precisely because near-zero marginal cost makes that obligation nearly free to honor.

Then, at launch, I gave Pro away to the first cohort of families. That’s revenue I’m choosing not to collect — and it’s a standard early-stage sequencing move, not generosity. At this stage the binding constraint isn’t monetization; it’s getting enough engaged users in the door to learn what makes them stay. The risk you take on is anchoring — teach people the thing is free and some never convert — which is why it’s the first cohort, not forever.

Where the economics actually live

Once inference rounds to zero and you’ve protected your take rate, unit economics stop being about cost to serve at all. They’re dominated by activation and retention. If people sign up and ghost, no pricing tier saves you. If they stick, the model cost is noise. In a world of cheap inference, the highest-leverage “pricing” work often isn’t pricing — it’s getting someone to the “oh, I get it” moment fast enough that they come back.

The transferable part

If you price or build AI products, retire one reflex: treating token cost as the central economic question. It was the right worry in 2023; it’s increasingly the wrong one for products shaped like mine. The honest caveat is the frontier: multi-step agents and reasoning loops have pushed per-task cost up even as per-token prices fall, and cost still matters enormously there. But for the broad middle of consumer and SaaS AI features, cost-to-serve is trending toward noise.

Watch where the supply side is pushing it. NVIDIA’s published comparison for its next-generation Vera Rubin platform puts inference cost per token at roughly a tenth of the current Blackwell generation’s at the same latency — on one reasoning workload, with the usual caveat that the number moves with model and operating point. The cost floor under inference keeps dropping. But the direction was never the interesting part. The interesting question is who keeps the margin when a token costs almost nothing — and it isn’t the resellers metering tokens, or the SaaS priced on cost. It accrues to whoever prices the system and the relationship. That’s the same lesson the app taught me, three orders of magnitude down.

The questions that decide whether an AI product makes money are the old, unglamorous ones: what take rate your channel imposes, how you package against willingness to pay, and whether you keep the user long enough for any of it to matter.

Price the value and the relationship — not the inference. The inference was never going to be the expensive part.

It’s been live long enough now to be boring, which was the goal. Along the way three things surprised me. Each one cut against what I expected going in, and each turns out to matter well beyond a house.

1. The win was aggregation, not automation.

Going in, I assumed the value would be in the agent doing things — answering email, paying bills, scheduling. That’s the demo everyone builds.

What actually changed my days was duller than that: one message instead of twenty tabs. Before, a normal morning meant logging into App Store Connect, Google Ads, Firebase, three bank accounts, a brokerage, a property inbox, and a receipts ledger — each its own login, each a few minutes, each a context switch that cost more than the minutes. Now it’s one message at 6:30 a.m. and one at 8 p.m. The agent’s main job is to read everything, summarize it, and put it in a single place.

Most of the leverage in a personal agent — and, I’d argue, a business one — is in collapsing scattered state into one view. Automation is the dessert; aggregation is the meal. If you’re scoping an agent product, the unglamorous “read everything, summarize in one place” is probably worth more to the user than the impressive “take action” demo that gets the applause.

2. Constraining the agent made me trust it more — and use it more.

My instinct was that an agent earns its keep by acting, so I expected to keep widening what it was allowed to do on its own. The opposite happened.

The modules I rely on most are the ones that do the least. Property email gets a drafted reply that I approve with a tap; actually sending is gated behind a PIN. Banking is read-only — the agent can see balances and flag an odd charge, but it has no path to move a dollar. Investments are never traded. The medical module reads a sanitized ledger and never the underlying images.

Here’s the part I didn’t predict: the first time an agent does something you didn’t expect — even something small and harmless — you stop trusting it, and an untrusted tool gets quietly closed and never reopened. By keeping everything to draft → approve, I never had that moment. So I left more of it running, gave it more to read, leaned on it more. The constraint increased usage.

A narrow agent I trust beats a capable one I have to babysit. For anyone building agents for other people, the lesson is sharper still: “human in the loop” isn’t a compliance checkbox you bolt on at the end. It’s the feature that decides whether the thing survives contact with a real user. Design the approval step as the product, not as the guardrail around it.

3. The model was the most replaceable part of the system.

Partway through, I switched the underlying model from one provider to another. Not because of quality — because the framework I was running expected a particular model’s tool-calling profile. The swap took an evening, and the system behaved the same the next morning.

What did not swap easily was the plumbing. Read-only, scoped API tokens instead of stored passwords. Running on an isolated machine that is never my work laptop, so a bad instruction can’t reach anything that matters. A redaction step that strips personal information before anything leaves the house — the medical module, for instance, never sends a receipt image downstream at all, only a sanitized ledger. A PIN gate on anything that can send. That layer is where the weeks actually went, and it’s the part I couldn’t rip out without rebuilding the whole thing.

The model is increasingly a commodity you can swap in an evening. The durable engineering is the boring security-and-data-handling layer around it. So when you’re evaluating an “AI feature” — your own or a vendor’s — spend less time on which model and more on three questions: what can it read, what can it write, and where does the data go? That’s the part that’s hard to change later, and it’s the part that decides whether you can trust the thing with anything real.

The pattern underneath

None of this is exotic. A server that’s already on, some scoped tokens, a chat bot, a scheduler. The surprises weren’t technical — they were about where the value actually sat: in reading rather than acting, in constraint rather than capability, in the plumbing rather than the model.

None of this is specific to a personal setup. The same three decide things at company scale, anywhere an agent is put in front of real data and real consequences.