/status in telegram

[winter storm]

what does the /status command in telegram help me understand about my usage

[ancient anchor]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[tall egret]

In Telegram, /status gives you a snapshot of what your OpenClaw session is doing right now (and roughly how “expensive” it is), not a full billing dashboard.

What it helps you understand:

• Which model/provider is active for this chat session.
• How full your context window is (i.e., how close you are to hitting the model’s context limit).
• Token usage for the last turn (input/output tokens), and sometimes recent totals depending on provider.
• Estimated $ cost for the last reply only if you’re using an API key–based provider (OAuth flows usually hide dollar cost and show tokens only).
• Provider quota/usage window for the current provider when usage tracking is available (e.g. a “Claude xx% left” style line).
• A few session toggles/health hints, like your current /think level, whether /verbose is on, and often things like compaction count (e.g. 🧹 Compactions: N) so you can tell if the session has been auto-compacted.

If you’re trying to track usage over time:

• Use /usage full to append a usage footer to every reply (tokens + cost when available).
• Use /usage cost for a local cost summary aggregated from OpenClaw’s session logs.
• For provider quota breakdowns, the CLI openclaw status --usage is the more detailed view.

[winter storm]

what does this mean: Cache: 52% hit · 45k cached, 0 new

[tall egret]

That line is OpenClaw reporting provider prompt-caching stats for the last model call (not a local disk cache).

🗄️ Cache: 52% hit · 45k cached, 0 new means:

• 52% hit: about 52% of the prompt input was reused from the provider’s prompt cache (OpenClaw computes this roughly as cacheRead / (cacheRead + cacheWrite + normal input)).
• 45k cached: ~45,000 tokens were cache reads (cacheRead) — i.e. the provider didn’t have to re-process that prefix.
• 0 new: 0 tokens were written to cache this turn (cacheWrite) — i.e. you didn’t extend/refresh the cached prefix on this request.

Why you care:

• Higher cache hit usually = cheaper + faster for long sessions (especially on providers like Anthropic where cacheRead is billed differently than normal input).
• If you go idle past the cache TTL, you’ll often see lower hit and more “new” again because the provider cache expired and needs to be re-written.

[winter storm]

is this good or bad or something else

[tall egret]

Mostly good (or at least a good sign that caching is working).

That cache line is about cost/latency optimization, not “quality”:

• Good: a 52% hit means a big chunk of your prompt was reused from the provider’s prompt cache → usually faster and often cheaper than re-sending/re-processing everything every turn.
• Also good: 0 new means this turn didn’t have to write any new cache blocks (often the “expensive” part on providers that charge separately for cache writes). It’s common once the cache is “warm”.

When it’s not “good”:

• If you expected caching savings but you keep seeing very low hit rates (near 0%) or lots of “new” every turn, you’re re-writing cache a lot (can happen after long idle gaps/TTL expiry, or if your system prompt/context keeps changing). That’s not necessarily wrong—just less efficient.

If you want to judge impact: pair it with /usage full (or look at the token/cost breakdown if your provider shows cost) to see whether caching is actually reducing what you’re paying.

[winter storm]

What about this: Context: 44k/272k (16%) 🧹 Compactions: 0