Lean AI
In a factory, Lean starts on the floor. You walk the line, name the waste you see, measure each kind from the record, then fix the cheapest big one and prove it moved. I do that for a living in medical-device quality. This is the same walk through my Hermes Agent setup's own records: 2,621 sessions since June 28, every one on a local model on two DGX Sparks.
Half of what it reads, it already read
An agent call doesn't send a question. It sends the whole session so far: the system prompt, every tool schema,
every earlier message, and every tool result. When the agent runs cat on a 6,000-token file at step 3,
those 6,000 tokens are read again at step 4, 5, 6 and every step after, until the session ends.
I rebuilt each session message by message and checked the rebuild against what Hermes itself recorded. It accounts
for 87–88% of the measured tokens; the rest is chat-template tokens, reasoning and context injected per turn, which
I report as "not rebuilt" rather than guess at. In that rebuild, old tool output is
half of everything read. On my main profile from Oct 20 to 28, terminal and
read_file results made up 73% of it, and each tool-output token was read 54 more times after it
first arrived.
The trend: what got better, and what didn't
Whole house, by month. The tool reads only Hermes' own records, so this is the same ruler each month.
| Jul | Aug | Sep | Oct | |
|---|---|---|---|---|
| Tool calls that failed | 3.3% | 4.8% | 3.1% | 1.4% |
| Repeat calls, same tool and arguments | 15.2% | 11.1% | 3.6% | 2.6% |
| System prompt share of reads | 19.9% | 16.3% | 16.9% | 10.9% |
| Old tool output share of reads | 39.6% | 46.6% | 54.3% | 52.3% |
| Times each tool-output token is re-read | 14× | 49× | 71× | 60× |
| Main-profile sessions ended by compaction | 71 | 21 | 2 | 0 |
Failures and repeated motion fell two to six times as the stack matured. Carried inventory went the other way. The context window grew to a million tokens, compaction stopped firing, and old tool output rode along for 60 more steps instead of 14.
The waste walk
Lean names eight wastes. Six have an honest, measurable twin in an agent loop. Main profile, Oct 20–28:
| Waste | In the agent | Size |
|---|---|---|
| Inventory (WIP) | Old tool output carried and re-read every call | 50.8% of reads |
| Overprocessing | System prompt (12.4K tokens) and 19 tool schemas (8.6K) re-sent every call | 15.4% |
| Waiting | Prompt the engine had to compute: a cache miss | 10.2% |
| Inspection | Scheduled checks that found nothing, after-session reviews | 3.6% |
| Defects | Tool calls the tool itself reported as failed | 1.0% of calls |
| Motion | The exact same call again in the same session | 1.0% of calls |
| Idle stock | Tool schemas sent every call: clarify never used, skill_manage 954 tokens per call for 3 uses in 10,369 calls | 2 never used |
The countermeasure was already in Hermes
Hermes ships compression.proactive_prune_tokens. Past a trigger size it replaces tool results over 8,000
characters, outside the last few messages, with a one-line summary. The default is 0, off, and the
comment beside it in Hermes' config says why it exists: the normal threshold "rarely fires on large windows, so old
tool output is re-sent every turn". That is exactly the curve in the table above.
Before switching it on, I replayed nine days of sessions under its rules. The replay used the summary size Hermes really produces (a median of 44 characters over 400 real outputs) and the prompt-cache break each prune causes.
| Trigger | Reads saved | Cache breaks | Extra recompute |
|---|---|---|---|
| 32,000 | −21.7% | 349 | 6.5 M |
| 48,000 | −20.3% | 272 | 6.5 M |
| 96,000 | −17.2% | 130 | 5.6 M |
The recompute is small next to the 139 M tokens of cache misses that already happened in those nine days. Since Oct 28 at 23:20 the main profile runs with a 48,000 trigger. A replay counts tokens; it can't know whether the agent needed the text it lost. The live trial watches for that through two guards that should not move: repeat calls and failed tool calls.
What this doesn't say
Re-reading isn't expensive to compute here. The engine's prefix cache serves most of a request from memory, as my earlier note says. But carried tokens still fill the window, still cost attention on every token generated, and on a paid API are billed at the cache-read rate. Lean calls inventory waste even when the warehouse is free.
The rebuild doesn't model reasoning text, tool schemas are measured as of today, and cache misses are only judged in sessions whose engine reports cache hits (September's mostly didn't, so it has no miss rate). Lead time is wall time between stored messages, so a model step includes queueing. All of it is in the method.
Tool: github.com/Coinupbtc/lean-ai (read-only, standard library,
11 tests on a hand-worked fixture) · reports: main profile, Oct 20–28 ·
Hermes: agent/context_compressor_prune.py, hermes_cli/config_defaults.py at
bf0203a794. I'm not affiliated with Nous Research.