Someone on V2EX asked a deceptively simple question: how long does Claude Desktop's input cache stay valid? Is it an hour?
Is it configurable? Is that a precise number or a rough one?
The only reply was a guess — "probably 1 hour, I saw it show up in the Claude Code plugin for VS Code." That was it. No docs, no confirmation, just one person's screen reading.
That thread is not an isolated case. It's the whole pattern right now. On the same board, people are trying to reverse-engineer why a usage limit is 5 hours and not 6 or 4, spinning theories about why the number doesn't divide evenly into a day. A team building a desktop GUI for a coding agent listed "token and cost is a black box — how much context each step ate, what the cache-hit situation actually was, there's no hard evidence" as one of the main reasons they built their tool at all. The signal underneath all of this is the same: vendors ship operational behavior they don't document, and builders are left squinting at logs to figure out how the thing they depend on actually works.
The real problem isn't the cache, it's the guessing
Prompt caching matters because it's where your money goes. If a same-prefix call lands inside the cache window, you pay a fraction of the cost. If it lands just outside, you pay full freight and never know why the bill crept up. When the TTL is undocumented, you can't plan around it. You can't decide whether to fire a keep-alive call at minute 4 or minute 9, because you don't know if the window is 5 minutes or an hour. Every batching decision, every retry policy, every "should I re-warm the cache" choice becomes a coin flip dressed up as engineering.
The honest move is to stop treating TTL as a fact you look up and start treating it as a value you measure. Caches leave fingerprints. A cache hit is cheaper and usually faster than a miss, and many model responses carry usage metadata that distinguishes cached input from fresh input. If you fire the same prefix at rising delays and watch where the hit turns into a miss, the expiry boundary shows up on its own.
What you can actually build on VicroCode
Here's the shape of the probe I'd write. It's small, and the point is that it's reproducible rather than clever.
The core is a Python script that sends the same long prefix to a model repeatedly, spacing the calls at increasing intervals — say 30 seconds, then 2 minutes, then 5, 10, 20, 40. VicroCode lets you run Python online against a model that's actually available in Model Center, so you're not standing up infrastructure just to send a few dozen calls on a timer. For each call, the probe records the timestamp, the delay bucket, and whatever the response tells you about caching — reported cached-token counts if the model exposes them, and round-trip latency as a secondary signal. Whether any specific model returns cache usage fields is model-dependent, so the probe should log the raw usage payload and let you decide what counts as a hit rather than hard-coding an assumption.
Every observation goes into a SQLite ledger — one row per call, with the prefix hash, the delay, the timestamp, the hit/miss verdict, and the raw usage blob. This is the part I care most about, because the ledger is the evidence. When you later want to sanity-check a result or reprocess with a stricter hit definition, you open the SQLite editor and read the actual rows instead of trusting a summary you generated three weeks ago. Inspectable beats aggregated every time you're arguing with a vendor's silence.
Then you publish the picture. A single HTML page that reads the ledger and plots delay against hit rate makes the expiry cliff obvious: hits stay flat, then drop off at some interval, and that interval is your observed TTL. VicroCode's web app hosting means you can share that chart as a live page instead of pasting a screenshot into a thread and hoping people believe you. If a teammate doubts the number, they open the page and see the shape of the data.
Draw the boundary honestly
Two limits are worth stating plainly, because pretending otherwise is how you end up with a confident wrong answer.
First, you can only probe models that are available on the platform. This probe measures whatever model you can reach through Model Center — it does not and cannot tell you the TTL of Claude Desktop specifically, or any client you can't call from here. The original V2EX question was about a desktop app, and a probe on a different surface won't answer it directly. What it will do is give you a measured number for the models you actually run against, which is the number that affects your bill.
Second, any single measurement is a snapshot, not a contract. The TTL you observe today is what the vendor's cache did today. There's no documented guarantee, which means they can change it silently, and your chart can go stale without warning (that a specific vendor will change it is unverified — the point is that nothing stops them). That's exactly why the ledger matters: re-run the probe on a schedule, keep the history, and you'll notice a shift as a change in the data rather than as a mysterious cost spike a month later.
Why this is worth an afternoon
The broader mood in these threads is people paying real money for capacity they don't fully understand — renewal prices jumping week to week, accounts getting resold, limits that seem designed to be hard to plan around. You can't fix vendor opacity. But you can refuse to operate blind inside it. A cache-TTL probe is the cheapest possible instance of a good habit: when the docs won't tell you how the system behaves, measure it, write the measurements down somewhere you can inspect, and publish the result so the next person doesn't have to guess either.
That's the whole trade. A short Python loop, a SQLite table you can actually read, and a hosted chart — in exchange for a number you trust because you watched it happen.