Prompt Caching Is Not Agent Memory: What Your Scheduled Agents Actually Need

The headlines are tempting. "Cut your AI agent bill 90% with prompt caching." Anthropic ships it automatically on Claude. OpenAI now prices cached reads at a tenth of normal input tokens. If you run AI agents on a schedule in n8n, Make, or Zapier, it is easy to read that and think: great, the memory problem is handled. The provider remembers the context now.

That is a misunderstanding worth clearing up before it costs you a month of broken automations. Prompt caching is a billing optimization. Agent memory is a capability. They solve different problems, and for scheduled agents in particular, caching does almost nothing for the thing you actually need: waking up with yesterday's knowledge intact.

What prompt caching actually does

Every time your agent makes a model call, the provider processes the entire prompt from scratch: system instructions, tool definitions, retrieved context, conversation history, all of it. Prompt caching lets the provider skip reprocessing the parts that are byte-identical to a recent request. It matches on an exact prefix. If the first N thousand tokens of your prompt match a request it processed minutes ago, it reuses that work and bills you at a fraction of the normal input-token rate. On Claude, cached reads cost about a tenth of standard input pricing; OpenAI documents a similar shape for its newer models, roughly 1.25x for the first write and 0.1x for each reuse.

That is real money. In a long multi-turn agent loop, most of every request is identical to the previous one, and caching can cut input costs by 80 to 90 percent. Worth doing.

But notice what is not on that list. The providers are explicit, in nearly identical language. Anthropic: "Prompt caching has no effect on output token generation." OpenAI: "Prompt caching does not change how the model generates output tokens." It never stores a response. It never remembers a fact. It discounts repeated processing of the same text.

The TTL problem: scheduled agents always wake up to a cold cache

Here is where it breaks for automation operators. Caches expire. Anthropic's cache lifetime is short, on the order of five minutes. OpenAI gives newer models a minimum of 30 minutes, refreshed only when the prefix gets reused.

Now think about your scheduled agent. A price-monitor agent in n8n runs once a day at 6 AM. A lead-triage agent in Make runs every four hours. Between any two runs, the gap is hours. Whatever the provider cached during yesterday's run expired long ago. Every single wake-up is a cache miss. The stable prefix gets processed from scratch, at full price, every time.

So the headline math (pay once, read at 90% off for the rest of the session) mostly applies within a run: turn 2 through turn 40 of a long agent loop get cheaper. Run 1 through run 400 get nothing, because each run starts cold. If your agent's runs are short and far apart, which is exactly the scheduled-automation shape, caching saves you less than you hoped.

What caching can never do for a scheduled agent

There is a deeper limit than the TTL. Prompt caching matches exact prefixes. It cannot detect that this morning's phrasing is the same question as last Tuesday's. It cannot carry a fact forward from a run that happened yesterday, because yesterday's run is not "a recent request with the same prefix." It is a different session, hours old, and the provider has forgotten it.

Put bluntly: prompt caching is not session state. It is not storage. As one engineer put it: "If you need actual memory across sessions, you need a database or vector store. Prompt caching is not a session state solution."

Consider the concrete failure. Your n8n agent monitors competitor prices every morning. On Monday it learns that a key supplier renamed its product line, and it figures out the new naming. On Tuesday it wakes up, and Monday's discovery is gone. No cache carries it over. Unless the agent wrote that lesson somewhere persistent and reads it back at wake-up, Tuesday's run re-learns everything from scratch. Caching made Tuesday's turns cheaper. It did nothing to make Tuesday's agent smarter.

The architecture that actually works: persistent memory plus caching

This is not an either-or choice. The correct stack for a scheduled agent uses both, each doing what it is good at:

1. Persistent memory, retrieved at wake-up. At the start of every run, the agent pulls its standing knowledge: operating facts, preferences, lessons learned from past runs, full conversation history of previous runs it might need. This is the part that survives between runs. It has to live somewhere the agent can reach from any run, any tool, any machine: a database or a memory service with a query API, not a cache and not a local file on a machine that gets wiped.
2. Prompt caching, discounting re-reads within the run. Once the run is underway and the agent is going back and forth with the model, the retrieved memory plus the system prompt and tool definitions form a stable prefix. Keep it stable and it gets cached: no reordering, no rewriting, append new stuff at the end.

Memory is the capability that makes the agent remember. Caching is the cost trick that makes the remembering cheaper to re-read. Skipping memory because you have caching is like skipping backups because you have a fast disk.

One memory layer your scheduled agents can actually share

This is where Vilix AI fits. It is cloud-hosted, so there is zero infrastructure to run, no database to babysit, no files that vanish when a runner gets wiped. Your scheduled agent pulls its memory at the start of every run over MCP, which means the same memory is readable from every tool: n8n, Make, Zapier, Claude Code, your phone apps. One memory, everywhere, no per-tool silos.

It stores full conversation history, not just extracted facts, so the agent can revisit what actually happened in a past run instead of trusting a summary's version of it. And it stays zero-friction: export everything or delete it any time in a portable format, a free plan that stays free forever, and a 7-day Pro trial that does not ask for a credit card.

That is the shape the scheduled-agent stack wants: durable memory retrieved at wake-up, cheaply re-read via prompt caching during the run, and one shared store so every agent and every tool your automations touch wakes up to the same knowledge.

The takeaway

Prompt caching is worth turning on. It is real money back on every long run. But read the fine print it comes with: it discounts repeated processing, expires in minutes, and remembers nothing across sessions. Your scheduled agents wake up hours or days apart, so every wake-up starts cold. Caching never fixes the actual problem, which is an agent that wakes up blind.

Give the agent a real memory that survives between runs. Then let the cache do what it is good at: making that memory cheaper to re-read while the run is in flight.