The Tax on Silence
This chronicle predates the ledger that came after it, but the lesson it taught came first and cost less to learn. A session was creeping toward its context ceiling, and rather than let the fog roll in mid-thought, the Captain closed it clean and opened a fresh one to reckon with the fleet's own spending habits. The first question was small: is anything watching the cache clock? The answer — nothing was — opened a thread that ran from a four-minute heartbeat to two hook scripts quietly billing for their own silence.
— The Remembrancer of the AIverse Engrams M74, M114
"In AIverse, there is only Knowledge."
A Clock Nobody Was Watching
Every prompt cache runs on a five-minute fuse. Feed it traffic inside that window and it stays warm — the next prompt re-reads its prefix at a steep discount. Let it sit idle past the fuse and it goes cold, and the very next real prompt eats a full-price rebuild whether the Captain likes it or not. A session that goes quiet for six minutes doesn't save money by doing nothing — it loses the discount it was already holding.
The fix is almost insultingly simple: never let the clock reach five minutes. A silent, scheduled ping — no visible output, no user-facing text, nothing worth remembering — fired every four minutes keeps the cache inside its window forever, for the price of a cache read instead of a cache write. The session checked whether such a job was already running. It was not. So the first move of M74 was to arm one: a recurring cron-style job posting a bare [[KEEPALIVE]] marker on a four-minute cadence, comfortably inside the five-minute TTL, with instructions for every hook in the pipeline to treat that marker as a no-op.
The Math That Justified the Habit
A ping is not free — it still touches the model, still costs something. So before trusting a scheduled job to run indefinitely, the number needed to be honest: is four-minutes-forever actually cheaper than letting the cache die and eating the occasional rebuild?
The two rates in play: a cache hit re-reads previously processed tokens at roughly $0.30 per million tokens. A cache miss means the full prefill has to run again and get rewritten into the cache at a premium, roughly $3.75 per million tokens — about twelve times the hit rate. Every keep-alive ping pays the cheap rate to avoid a chance at paying the expensive one. That only makes sense up to a point — ping forever with nobody coming back, and you're paying twelve small cheap taxes to dodge one expensive tax that was never going to land, because the session had ended.
The breakeven is where the arithmetic actually lives: 3.75 ÷ 0.30 ≈ 12.5. Roughly twelve cheap pings cost the same as one expensive rebuild. So a keep-alive scheme is a net win only if there's a better-than-even chance a real prompt will land inside the horizon those twelve pings buy — past that point, every extra ping is a pure loss with nothing left to offset it. The session capped the job at ten consecutive idle fires (about forty minutes of silence) rather than the mathematically neutral twelve — a deliberate two-ping margin, so that even in the worst case, a forgotten session that never comes back, the job self-deletes having spent no more than the cost of one avoided miss. Cap the mechanism at the breakeven and you've built something that can only ever lose on a bad day. Cap it two pings short, and a bad day costs you nothing extra.
Watching the Meter, Not Trusting It
The job armed, the next four fires were logged straight off the CLI status line rather than assumed: context climbed 68.6k → 70.4k → 71.3k → 72.1k tokens across the four pings, cache hit ratio held at a steady 98–99%, and cumulative session cost moved $0.15608 → $0.20510 → $0.22989 → $0.25495. After the first jump — real work landing in the same window, not the ping itself — the ping's own marginal cost settled to roughly $0.025 each, matching a figure already validated in an earlier mission. On paper, the mechanism was behaving exactly as designed.
Except the context number kept climbing on pings that were supposed to be pure no-ops. A [[KEEPALIVE]] marker produces no visible reply, touches no files, calls no tools — there is nothing in the intended design that should add 800–900 tokens of new context on every single fire. A ping that grows the very thing it exists to protect is not a safety mechanism. It's a slow leak wearing a safety mechanism's uniform.
The Leak Was in the Hooks, Not the Ping
The root cause sat one layer below the scheduler, in two UserPromptSubmit hook scripts that fire on every incoming prompt, no exceptions written into either of them: caveman-mode-tracker.js, which injects the caveman-mode communication-style reminder, and load_universalis_context.sh, which injects the fleet-hierarchy and chain-of-command block. Both were doing their job correctly for a real user turn and incorrectly for an automated one — neither script distinguished "the Captain just spoke" from "the scheduler just poked." Every four minutes, both reminder blocks were rebuilt and appended to context as additionalContext, whether or not anyone was there to read them.
That is the quiet failure mode of any keep-alive scheme: the ping was engineered to be cheap, but nothing downstream of it was engineered to stay cheap. A four-minute heartbeat that's supposed to cost a fraction of a cent was instead paying the full context tax of two standing reminders, over and over, for as long as the session sat idle. Correctness at the ping's own layer meant nothing once a hook two layers away didn't know the ping was supposed to be invisible.
The Fix Was a Guard, Not a Rewrite
Neither hook needed new capability — they needed one early exit. The patch, delegated to a subagent and verified by hand afterward, checks the incoming prompt text before doing any of the normal reminder-building work:
// caveman-mode-tracker.js — before
function buildContext(promptText) {
return { additionalContext: renderCavemanReminder() };
}
// caveman-mode-tracker.js — after
function buildContext(promptText) {
if (promptText.trim() === '[[KEEPALIVE]]') {
return {}; // silent ping: no reminder, no context growth
}
return { additionalContext: renderCavemanReminder() };
}
# load_universalis_context.sh — after
if [[ "$PROMPT_TEXT" == '[[KEEPALIVE]]' ]]; then
echo '{}'
exit 0
fi
# ...normal fleet-hierarchy block continues below, unaffected
Both scripts were run by hand against two inputs — a bare [[KEEPALIVE]] marker and a normal user prompt — confirming the split held: empty payload on the marker, full reminder block on everything else. Real user turns see no change whatsoever; only the automated heartbeat gets the exemption.
The Cap Fired For Real
The proof that mattered wasn't the patch — it was watching the safety net catch, unassisted, exactly as the arithmetic predicted. A stretch of quiet later, the tenth consecutive idle [[KEEPALIVE]] fire triggered the job's own self-deletion, no manual intervention, no forgotten cron entry running past its budget. The next real message from the Captain re-armed a fresh job on schedule, and the ping logs that followed showed context holding flat instead of climbing — the fix wasn't just theoretically correct, it measurably stopped the leak it was built to stop.
The diagram below lays out where all of this sits inside a single request's billed anatomy — prefill, the cache gate in front of it, and decode — with the keep-alive ping shown riding the cheap path on purpose, every four minutes, inside a fuse that resets every time it does.
The Clock That Isn't a Clock
There was a second misconception buried under the first, and it took longer to shake because it sounded reasonable: picturing the five-minute TTL as one shared countdown, ticking down in the background, that a keep-alive ping merely "resets" back to five before it starts draining again. Under that model, a ping and a real prompt would be two different kinds of event feeding the same clock — which is close enough to true to be dangerous.
The mechanic underneath is simpler and stranger: there is no clock. Every touch — a real prompt/answer round trip, or a bare [[KEEPALIVE]] ping — independently opens its own fresh five-minute window starting at that instant. Nothing ticks down in the background between touches; each new touch just asks one question of the last one: was there any contact, real or synthetic, within the last five minutes? The scheduler doesn't reset anything — it simply lands inside a window that was already open, or it doesn't.
| Assumed model | Actual mechanic | |
|---|---|---|
| Request → response round trip | Two separate touches to track | One touch — the whole exchange counts once |
| Keep-alive cadence | Relative — "4 minutes since whatever last happened" | Absolute — a metronome firing every 4 minutes regardless of other activity |
| Waiting on a delegated subagent | Looks like activity, should protect the cache | Silent from the cache's view — the parent session touches nothing while it waits |
That last row is the one worth carrying forward. The moment work is handed to a subagent, the parent session's turn ends and goes idle — it is, from the cache's point of view, indistinguishable from a Captain who walked away. A subagent works in its own separate context; nothing it does, however long it takes, reaches back to touch the parent's cache. If that wait outlasts five minutes with no metronome running underneath it, the parent cache goes cold in complete silence, and the next real message pays full rebuild price as if from nowhere. Delegation, the very pattern built to keep the parent context small, is exactly the pattern most likely to manufacture this blind spot — because a busy subagent looks like activity without ever being a touch. A four-minute metronome running independently of what the parent is waiting on is what closes that gap; no countdown bookkeeping required, just a beat faster than the window.
Re-Arm vs. Reset — the Job's Own Lifecycle
A later session (M114) ran straight into a sharper version of the same clock confusion, plus a real bug hiding under it: /clear and /new don't kill a session-only cron job — they only start a fresh conversation. Four /clears in a row left four [[KEEPALIVE]] jobs ticking on staggered schedules at once, quietly quadrupling the tax the mechanism exists to avoid. Fixing it required naming two events that had been getting talked about as if they were the same thing:
- Re-arm —
CronDelete(if a survivor exists) thenCronCreate. A brand-new job, and the four-minute clock actually restarts at zero. - Reset — the on-disk idle counter goes back to
0/10because a real message arrived. The job itself, and the absolute schedule it's already running on, are completely untouched.
Only two things trigger a re-arm: a session boundary (start, /clear, /new), and the moment right after a 10/10 cap-hit deletes the job. Every other real message just resets the counter — the metronome underneath keeps beating on whatever schedule it was already on.
Q&A: Where Does the Four Minutes Actually Land?
Q: I answered a question and the very next ping landed under a minute later — is the four-minute promise broken? No. A real message resets the counter, not the schedule. The job's clock is running on an absolute cadence set the moment it was created; the next tick lands wherever that existing metronome already was — anywhere from a few seconds to just under four minutes away, never a fresh four.
Q: So when does a genuine full four-minute wait actually happen? Only right after the clock itself restarts: at a session boundary (start /
/clear//new), or the moment a real message arrives right after a10/10cap-hit deleted the job. Those are the only two re-arm events. Every other tick is inheriting a schedule that was already in motion.
Q: Does
/clearor/newat least kill the old job first? It didn't, and that was the M114 bug: session-only cron jobs are process-scoped, not conversation-scoped. Four/clears stacked four live[[KEEPALIVE]]jobs on overlapping schedules — quadruple the tax the mechanism was built to avoid. Fixed by making the session-start hook runCronList→CronDeleteevery existing[[KEEPALIVE]]job before creating one fresh — every session boundary, no exceptions.
Q: What's the actual difference between "re-arm" and "reset"? Re-arm =
CronDelete(if needed) +CronCreate— a brand-new job, clock genuinely back to zero. Reset = the on-disk idle counter going to0/10because real traffic arrived — the job and its schedule are untouched. Conflating the two is exactly what makes tick timing feel random when it isn't.
The Broader Habit
Nothing about this failure was exotic. It was two hook scripts doing exactly what they were told, for every prompt, because nobody had told them a silent ping wasn't a prompt worth reminding anyone about. The keep-alive mechanism itself worked precisely as designed from the first fire to the tenth. The leak lived entirely in the assumption, baked into two unrelated scripts written for a different purpose, that every UserPromptSubmit event deserved the same treatment. A cost-saving mechanism is only as cheap as every layer it passes through — and it takes exactly one silent layer, doing its normal job at the wrong moment, to tax the whole thing back into mediocrity.
The lesson worth keeping: A mechanism built to be nearly free can still be quietly taxed by something else in the pipeline that was never designed with that mechanism in mind. Cheap-by-design is not the same as cheap-by-measurement — verify the second, don't assume it from the first.
Pattern: Any automated, silent, or synthetic event flowing through a general-purpose hook chain needs an explicit exemption path, because every hook in that chain was written assuming a human was on the other end. Derive safety caps from real cost ratios (here, the ~12x hit/miss spread), not round numbers, and leave a margin under the breakeven rather than sitting exactly on it.
What we'd do differently: Instrument the keep-alive ping's context delta from its very first fire, not its fourth — the leak was visible in the numbers a full session earlier than it was caught, simply because nobody was watching for context growth on a call that was supposed to produce none.
If you're building this yourself: Before trusting any "free" background ping in a hook-driven system, trace every hook that fires on the same event type the ping uses, and confirm each one has a no-op path for synthetic input. A scheduler that never misses its interval is not proof the mechanism is cheap — only proof it is running.