Know whether the next prompt will reuse a warm provider cache

[colonelpanic8]

What I am trying to do

Before sending another expensive prompt, I want to know whether the current agent's provider cache is likely still warm and how much of the previous request was served from cache.

This affects whether I continue now, wait, switch agents, or deliberately re-warm a session before a longer task.

How I do it today

Paseo shows context and cumulative usage, but it does not preserve or render a request-level cache sample. I infer cache behavior from provider billing, raw transcript fields, or elapsed time. By the time I learn a cache was cold, I have already paid the latency and token cost.

Where Paseo gets in the way

Cumulative cached-input totals do not answer whether the last request hit or when a documented cache lifetime will expire. Providers also report cache accounting differently, so comparing raw values is error-prone. For providers that do not publish a TTL, any countdown would be a guess.

What a better workflow looks like

The current agent's context/usage detail would show:

• the last request's cache hit ratio and cached/uncached token split;
• the session-wide ratio;
• the age of the last sample;
• a countdown only when that provider documents a lifetime; and
• an explicit “lifetime unknown” state otherwise.

A manual re-warm action could send a small visible message, but it should be optional and honest that no provider exposes a read-only cache probe. Paseo only learns cache state by making a request.

The same normalized figures would be useful from the CLI when inspecting an agent.

Scope, providers, and plugins

Claude and Codex are the initial useful TTL cases. OpenCode, Pi, OMP, and ACP providers may expose cache counts without a documented lifetime; they should show ratios/age without inventing expiry. Presentation should work on web, Electron, iOS, and Android.

Provider adapters need to emit normalized request or cumulative samples, so the base telemetry seam belongs in core. A plugin could provide an alternate visualization later, but it should not independently reinterpret every provider's accounting.

I found no matching Discussion. This is one user's optimization workflow, and shared demand is not demonstrated. PR #4305 is prior exploration only.

[stv1024]

Another concrete use case for preserving cache samples: I maintain TokenLedger, a community plugin that records per-turn tokens and estimates cost from a configurable price table. Cache creation can have a different rate from ordinary input, so losing that count prevents the plugin from explaining a reported total or estimating the missing component.

The plugin already provides the ledger and UI using public Paseo APIs. The missing extension point is the usage data. I would like to keep provider transcript parsing out of the plugin.

Current API boundary

Verified on Paseo 0.8.0 on Windows, with the source locations below rechecked on main at b2ce2bcb83dd40bd91c32098c59221f0b52d7ffd (source inspection, not a run of that checkout):

• AgentUsage and its wire schema expose input, cache reads, output, cost, and context counts, but no cache creation count.
• Claude's buildResultUsage copies input_tokens, cache_read_input_tokens, output_tokens, and total_cost_usd; it does not copy cache_creation_input_tokens.
• Codex's toAgentUsage similarly retains only the three token counters. Availability of a write count in Codex itself depends on the runtime/backend; missing data should stay unavailable.

For example, this synthetic Claude-shaped usage illustrates the loss:

{"input_tokens":10,"cache_read_input_tokens":60,"cache_creation_input_tokens":30,"output_tokens":5}

The current mapping preserves 10 input, 60 read, and 5 output tokens; the 30 creation tokens have no field in the public result. This is separate from the context-meter candidate selection and message_delta handling in #4295.

Smallest useful capability

An optional cache-creation count carried consistently through the provider adapter, wire schema, snapshots/terminal usage, and public SDK would let plugins handle the pricing and presentation. Please preserve missing versus zero and document whether input includes cache reads or writes. If a provider reports separately billed cache lifetimes, preserving their breakdown would avoid assuming one universal write multiplier.

A useful acceptance case is inclusive input=100, reads=60, writes=30: ordinary input is 10. For exclusive input=10 with the same cache counts, it remains 10. A reported total that already includes writes must not have estimated write charges added again.

This data extension could ship independently of cache warmth/TTL UI and of the child attribution discussed in #4660. Would preserving these optional counts in the existing usage contract be an acceptable first step?

[stv1024]

Follow-up to my September comment: OMP adds another concrete field-loss case, and the recent context-meter fixes do not close this accounting gap. Keeping this in the existing discussion rather than opening a duplicate feature request.

Version and evidence boundary

The installed-version investigation was on Paseo 0.11.2. I separately inspected public main at cafa04d3fbdbc7e4a3fe8f4d4bea80f15cd4a1d0 on October 14; I did not run the full upstream app. I exercised only its exported OMP usage poller in memory with synthetic stats and an injected scheduler, without a model request.

At that public revision:

• OMP's RPC schema accepts tokens.cacheWrite, but the usage mapper and change comparison omit it.
• Claude buildResultUsage still does not copy cache_creation_input_tokens. Codex toAgentUsage retains the last input/cached/output counts, without a creation field; this does not imply every Codex runtime supplies one.
• Neither AgentUsage nor its wire validator has a creation count.

Already fixed elsewhere: merged #6703 counts late Claude streaming input in the context meter; merged #6106 refreshes OMP context usage after manual compaction. Those are useful fixes on newer main, not public cache-write accounting fields, and I am not reporting their context-meter bugs again.

Additional acceptance evidence

Passing synthetic OMP stats {tokens:{input:10,cacheRead:60,cacheWrite:30,output:5}} to the current poller publishes input=10, read=60, output=5, with no write dimension. A context-only stats object also becomes input/read/output=0 (and cost=0) in this mapper, despite no token/cost measurement being supplied. Please keep unavailable, measured zero, and positive distinct across adapters, validation, snapshots and replay.

For the input convention, the installed OMP investigation found input already excludes cache reads/writes. It must remain 10 in that example, not have 60 and 30 subtracted again. An explicitly all-inclusive input=100 with read=60/write=30 instead normalizes to 10. This is a harness/statistics contract, not something a model name can establish. Please document inclusion of reads and writes independently, or provide normalized disjoint counts; retain separately reported creation-lifetime components with a declared total/subtotal relationship when available. A reported total cost must retain its scope and must not have these components added again.

The smallest extension still looks like optional creation counts plus explicit counting conventions, carried end to end. Request/branch/descendant ownership and late corrections remain in #4660; no pricing UI or cache-warmth probe is needed for this data-preservation step.