Your AI test-writer re-reads the whole suite every time — that is the bill

The bill that grows with your coverage

An AI agent maintaining a real test suite does not work in a vacuum. To add a case without duplicating one, to keep naming and fixtures consistent, to avoid re-introducing a bug you already have a test for, it wants context: the existing cases, the shared helpers, the recent run history, the flaky-test notes. So on each step it re-loads a large slice of all of that before it writes a single new assertion.

The result is a quiet inversion of what you wanted. Coverage going up is the goal; but the more the suite grows, the heavier every subsequent step becomes, until generating or repairing tests across a big suite costs far more per change than it did when the suite was small.

Why it grows the way it does

Each step of an agent loop re-sends the system prompt plus the entire growing context — here, the suite and its history. Because every step replays what came before, the tokens you pay for scale faster than the suite itself. SAIHM measured this on a reproducible, offline benchmark and saw 62.8%–85.9% fewer context tokens across a session when an agent recalls a compact memory instead of replaying everything, with the gap widening as the session runs longer. The benchmark is open source and runs locally, so you can change the scenario to your suite and check the number.

Recall the cases that matter to this change

SAIHM stores prior cases and their outcomes as individual memory cells — this module’s edge cases, that fixture’s quirks, the three tests that go flaky under load. When the agent works a specific change, it recalls only the cells relevant to the code under test, not the whole suite. Each step stays focused and cheap instead of re-reading thousands of unrelated assertions. And because the same memory is addressable from any model, the QA agent in your CI is not pinned to one vendor — you can run it against whichever model is fastest or cheapest this quarter without re-teaching it the suite.

Your tests describe your product — keep them under your keys

A mature test suite is a precise description of how your product actually behaves: business rules, failure modes, the data shapes your system accepts. That is proprietary, and test fixtures often carry real or realistic personal data. With hosted-memory products, that description sits on a vendor’s servers under the vendor’s keys. SAIHM keeps it yours: you hold the encryption keys, and erasure is per-record and provable — retire a fixture that contained personal data and that one cell is cryptographically destroyed, with an audit trail you can show. Portable, private, and erasable per record is a very different posture from trusting a hosted vendor’s dashboard delete button.

The honest close

SAIHM has a free tier — a one-time lifetime allowance you activate with a single command, no card and no wallet. Paid plans are a monthly subscription, not a trial that quietly converts. But the benchmark and more than a dozen integration demos are open source and run locally, so you can verify the savings and try the connect path before deciding anything. The tool surface and setup steps are at /developers; pricing is at /pricing.

Join SAIHM

— Architect

Common questions

Why does the AI test-writer get more expensive as coverage grows?

Because it re-reads the suite to write the next case, and the suite is bigger every time it succeeds. Left alone, coverage growth turns directly into cost growth.

If it only recalls some cases, will it write duplicate tests?

Recall targets the cases relevant to the change under test rather than a random subset, so the agent sees the neighbours that matter. The memory contract in this post is what produces that behaviour.

Do my tests count as sensitive?

They describe your product in detail — its edge cases, its business rules, sometimes its fixtures and sample data. That is why this post argues for keeping them under your own keys.

How do I check the savings on my own suite?

The benchmark is open source and runs offline, so you can set your own session length and recall cap and see where the curve lands rather than taking a published figure on trust.

Try it: a memory contract for your test-writer agent

Here is the fastest way to feel the difference. Paste this into your agent’s system prompt — it assumes the SAIHM MCP tools saihm_recall / saihm_remember / saihm_forget are wired into your harness. Following it is what produces the savings:

## Memory contract (test-writer agent)

On every turn, before you act:
1. RECALL, don't re-read. Call saihm_recall for only the code under test - a small, bounded set -
   instead of re-sending the whole test suite. The recalled cells ARE your context.
2. Prefer the CURRENT fact. If two recalled cells conflict, the most recent /
   non-superseded one wins - never act on a decision a later cell reversed.
3. REMEMBER durably. Call saihm_remember to persist decisions, conventions,
   and constraints as cells - one fact each, in your own words.
4. On a "delete my data" request, call saihm_forget on those cells: erasure
   is per-record and provable, not a soft delete.

Follow this and each new test costs about what the first one did; the resend curve flattens from O(N²) to O(N·cap) — the 62.8–85.9% fewer context tokens the open benchmark shows.