2026-07-27T20:29:59.670Z
OpenClaw Token Usage: Audit Four Counters Before Optimizing
Reconcile context, session tokens, local cost, provider scope, and verified outcomes before you call OpenClaw usage optimized.
OpenClaw token usage is not one number. A useful audit keeps four measurements separate: the current context snapshot, tokens reported for model calls, local estimated cost, and provider quota or billing. Then it joins those records to a verified outcome. If any join is missing, the honest result is incomplete , not “cheap,” “expensive,” or “optimized.” That distinction matters because the counters answer different questions. A context window can be 70% full without 70% of an account quota being consumed. A provider can report account level spend that includes traffic outside one agent. A session can have complete token metadata but no local price. And a completed run can still produce no durable deliverable. The practical default is a coverage audit before an optimization pass. Use OpenClaw’s built in surfaces to collect the available evidence, normalize it by run and time window, and refuse a final cost per outcome verdict until usage, pricing, and outcome coverage are explicit. Start with the four counters OpenClaw actually exposes OpenClaw’s current documentation separates context from usage. /status shows the active model, the current context snapshot, and last response token information. /context list or /context detail explains what occupies that window: system instructions, conversation history, tool schemas and results, attachments, and injected workspace files. This is an occupancy measurement for the prompt the model can see now. /usage tokens and /usage full expose per response usage. /usage cost aggregates local cost from session logs. The token use reference says assistant transcript entries persist a normalized usage shape and can include usage.cost when the provider supplies metadata and the active model has pricing. It also warns that provider usage can include cached input, output, and multiple tool loop calls, while context display uses the latest prompt snapshot. Those totals are not interchangeable. Provider usage is another scope. openclaw status usage reports provider quota windows or summaries. The usage tracking documentation distinguishes subscription quota, organization billing, and OpenClaw’s local session estimates. The Control UI can show both provider cards and transcript derived analysis, but it does not magically make their scopes identical. Use this map before collecting data: Evidence Question answered Common mistake Context snapshot What occupied the latest model prompt? Adding it to cumulative usage Turn or session usage What tokens did recorded model calls report? Treating a sparse transcript as complete Local estimated cost What did configured prices imply for recorded calls? Calling the estimate an invoice Provider quota or billing What did the provider report for its account or window? Assigning all of it to one agent Outcome receipt Did the intended work become true? Dividing by agent declared success Define scope before calculating cost Choose one UTC window, one agent or workflow, and one outcome predicate. Keep those identifiers in every row. “Last seven days” is not enough if the provider uses a rolling quota window while the local report uses calendar days. “OpenClaw spend” is not enough if the provider total also includes direct API clients, another gateway, or a second agent. A normalized run record can stay compact: The receipt should point to the strongest practical check: an object at the destination, a passing test run tied to the revision, a public API response, or an approval record followed by observed progress. Do not upload prompts, transcript content, secret values, or raw tool payloads just to calculate a ratio. Stable run IDs, timestamps, token fields, model identifiers, prices, and content minimized outcome references are enough for this audit. The same rule applies to retries. Aggregate every model call owned by the run, including nested tool loops, but keep the run’s final outcome independent. Three successful API responses followed by a missing artifact are cost with a false success receipt, not three outcomes. Run a coverage gate before interpreting the ratio The accompanying artifact, audit openclaw usage.mjs , replays six illustrative runs. It deliberately includes one run with a context snapshot but no usage metadata, one with token metadata but no configured price or outcome receipt, and one false success result. Run it with: The replay finds usage for five of six runs, pricing for four, and outcome receipts for five. It finds three verified outcomes and one false success. Known local estimated cost is $1.43 , so the arithmetic result is $0.4767 per verified outcome. The audit labels that value a lower bound , because two runs lack prices or usage and the provider’s $1.82 account total has a broader scope. This is the useful decision rule: Partial coverage still helps investigation. A missing usage run points toward adapter or transcript parsing. A pricing gap points toward model configuration. A missing receipt points toward outcome instrumentation. A provider/local difference with mismatched scope is not automatically leakage; it is an unattributed remainder that needs a compatible account, project, agent, and time boundary. Diagnose context growth and retries without confusing them Once coverage passes, split the total by mechanism. Context pressure and cumulative spend can move together, but they are not the same failure. Use /context detail to identify large injected files, tool schemas, retained tool output, attachments, or compactable conversation history. The context documentation explains that pruning can remove old tool results from the in memory prompt without rewriting the transcript, while compaction writes a summary and keeps recent messages. A smaller later context snapshot does not erase tokens already billed on earlier calls. For retries, retain an owner and reason for every repeated call: transport retry, provider rate limit, tool retry, validation retry, or human requested rerun. Then compare cost with useful progress: growing usage plus a changing artifact can be expensive but productive; repeated calls with no outcome delta are retry waste; a high cache read count may be cheaper than uncached input, but still needs the actual provider price; a long legitimate approval wait should not be counted as a stalled model loop; compaction that reduces context but drops a required decision is not an optimization. Only after those labels exist should you test a change such as trimming tool output, loading fewer skills, reducing image dimensions, changing cache policy, compacting earlier, or assigning a smaller model. Run the same outcome predicate before and after. A token decrease that weakens verified completion is a regression. Treat the result as an audit, not an invoice OpenClaw’s API usage and costs reference states that local Control UI totals describe available session history, not a provider invoice or lifetime ledger. Missing pricing is surfaced as missing; it should stay missing in your report. Subscription quota windows may not expose per message dollars at all. That creates three legitimate conclusions: 1. Reconciled: scopes match and every run has usage, pricing, and an outcome receipt. 2. Directional: coverage is complete enough to compare two controlled cohorts, but the cost remains an estimate. 3. Incomplete: gaps or scope mismatch make a final rate indefensible. The artifact returns INCOMPLETE on purpose. Its provider minus local difference is $0.39 , but it does not assign that remainder to the agent. It also keeps the $0.4767 ratio as a lower bound rather than dressing it up as a precise KPI. That is the behavior to preserve when the real data is inconvenient. Sidewisp is currently in private preview. Its production monitoring adapters and recovery systems are not generally shipped. The method here is a local operating practice for OpenClaw users today, not a claim that Sidewisp currently collects token evidence or reconciles provider billing. If you are evaluating the private preview, the useful question is whether a future health view can show coverage, freshness, scope, and verified outcomes beside cost—without turning a partial counter into a green verdict.