Your House Agent Pays to Reread Its Rulebook Every Time It Wakes

Every agent in my house wakes up on a schedule, reads its rulebook, looks around, and goes back to sleep.

The rulebook is the same every time. Who lives here, which devices it can touch, what it must never do, the tool definitions, the house style. Thousands of tokens of instructions that change maybe once a week. The part that changes is the last few lines: the sensor readings, the time, what happened since last wake.

06:00 wake  hvac: 68F  doors: locked  queue: 0  barometer: steady
07:00 wake  hvac: 69F  doors: locked  queue: 1  barometer: steady
08:00 wake  hvac: 69F  doors: open    queue: 1  barometer: steady

If the cache has expired by the time the agent wakes up, it pays to read the whole rulebook again. Every wake. All day.

On a test station we called this setup time. You don’t reload the test program from scratch for every unit. You load it once and run units against it until the shift changes. The cache is the loaded program. The question is how long it stays loaded.

The rule

Match the cache lifetime to how often the agent wakes.

That’s it. It applies to any provider that lets you choose a cache lifetime. Short lifetime for agents that wake often, long lifetime for agents that wake rarely but on a steady rhythm. The rest of this post is the math, using one provider’s published numbers because they just shipped a longer option and the docs spell out the billing clearly.

The published numbers

From OpenAI’s prompt caching guide , for GPT-5.6 and later:

• The default cache lifetime is a 30-minute minimum, and writing to it costs 1.25x the normal input rate.
• In the Responses API you can set prompt_cache_options.ttl to "12h" for a 12-hour minimum, at a write rate of 2.5x.
• Reads cost 0.1x the input rate on most of these models, and 0.05x on GPT-6.1 Sol, whichever lifetime you chose.
• These are total rates, not surcharges. A token is billed once, as ordinary input, a cache read, or a cache write.
• A read refreshes coverage to at least 30 minutes after that read. On a 12-hour entry it does not restart the 12-hour clock.
• The prefix has to be at least 1,024 tokens to be cached on these models.

I’m keeping this in multiples of the normal input rate instead of dollars, because the multipliers are what the docs publish and they hold across models. Plug in your model’s actual price from the pricing page .

The math

Call the cost of reading the rulebook uncached once “1.” Here is one 12-hour stretch, using the 0.1x read rate.

Agent wakes every hour (12 wakes). Each gap is longer than 30 minutes, so the default cache is cold every time.

Read the middle row twice. If your agent wakes less often than every 30 minutes and you leave the default on, you pay a 25 percent premium to write a cache nobody will ever read. Worse than not caching at all.

Agent wakes every 20 minutes (36 wakes). Each read lands inside the 30-minute window and refreshes it, so the default cache stays warm.

Here the long lifetime is the waste. The short cache never goes cold, so the extra write premium buys nothing.

Where it flips. For wakes more than 30 minutes apart, the 12-hour option costs 2.5 + 0.1 x (N minus 1) for N wakes in the window, and the 30-minute option costs 1.25 x N. Those cross a little above two wakes. Two wakes is close to a tie. At three or more, the 12-hour cache wins and keeps winning.

So:

• Wakes more often than every 30 minutes: default 30-minute lifetime.
• Wakes on a slower rhythm, three or more times in 12 hours: 12-hour lifetime.
• Wakes once or twice a day: neither cache earns much. Look at not writing one at all.

Put the moving parts last

The cache only covers the unchanged prefix. If the timestamp or the sensor dump sits at the top of the prompt, nothing after it matches and you pay full price anyway. OpenAI’s guide says it directly: stable instructions and reference material first, dynamic content at the end.

The guide also shows mixing lifetimes in one request. Put the rulebook behind a breakpoint with a "12h" lifetime, put short-lived session context behind a "30m" breakpoint, and leave the current readings after the last breakpoint so they never get written to cache at all. That last part matters for a house agent. The sensor readings are never reused, so paying the write rate on them is pure waste.

The same applies when the agent pauses to wait on me. I wrote in human attention is the spec that the slowest part of any agent loop is the human. If I take 45 minutes to answer a question, the default cache is gone when I get back. An agent that routinely waits on people should keep its rulebook on the long lifetime for that reason alone.

Measure it

Don’t trust the table. Trust the usage fields. The guide lists cached_tokens and cache_write_tokens on every response, with writes broken out by 30-minute and 12-hour lifetime. Log them with every wake. If cache_write_tokens shows up on every single wake, your lifetime is shorter than your wake interval and you’re paying setup time on every unit.

This is the boring part of running a house full of agents . It’s also the part that shows up on the bill every month.

Load the program once. Run the shift.