2026-07-28T08:38:14.591Z

Optimize OpenClaw Token Usage Without Weakening Outcomes

Measure OpenClaw token savings in fresh sessions, trim repeated context, and promote a change only when the same verified outcome survives.

The safest way to optimize OpenClaw token usage is to change one source of context at a time, measure two fresh runs, and require the same outcome receipt from both. A lower token count is not a win if the agent forgets a decision, repeats an external action, or returns a plausible answer instead of the requested artifact. In a controlled run on July 28, 2026, I replaced 4,102 bytes of repeated retry history with a 924 byte evidence summary. Both fresh OpenClaw sessions used the same model, system prompt hash, task, expected SHA 256, and output predicate. Input usage fell from 24,605 to 23,614 tokens: 991 fewer tokens, or 4.0%. The returned JSON, 72 output tokens, artifact digest, and pass verdict were identical. That is evidence for a narrow decision—trim repetition while retaining terminal errors and outcome receipts—not a forecast that every workload will save 4%. The system prompt was much larger than the changed record, and each variant ran only once. Sidewisp is currently in private preview. Measure the prompt you can actually change OpenClaw context is more than the latest user message. Its official context guide lists the system prompt, conversation history, tool calls and results, and attachments as contributors. Tool schemas count even though they are not displayed as ordinary text. Skills add a compact metadata list; their full instructions load on demand. Start with evidence, not a cleanup spree: /context detail locates large bootstrap files, tool schemas, skill entries, and compactable transcript messages. /usage tokens exposes per response token and cache fields. /status shows the latest context snapshot and last response usage. These surfaces answer different questions. The distinction matters because OpenClaw keeps provider usage accounting separate from the current context snapshot. As the token use reference explains, provider totals may include cached input, output, and multiple tool loop calls, while the context display uses the latest prompt snapshot. Do not subtract one from the other and call the remainder “waste.” Record at least this before a change: Keep quota windows, billed account totals, and per run tokens in separate columns. A subscription usage page can answer “how much capacity remains?” without proving which local run consumed it. A transcript entry can attribute a model call without proving that the intended deliverable exists. Run a controlled before and after test The experiment used a synthetic invoice export incident so the input could be published without exposing private prompts or logs. The baseline contained two timeout attempts, repeated progress lines, and one successful attempt. The optimized variant retained the attempt count, both terminal timeout facts, final exit status, artifact path, exact SHA 256, test result, and final state; it removed repeated lines that did not change the decision. Each variant ran in a new session with thinking disabled. The verifier required one exact JSON shape and refused to pass unless the artifact existed, its digest matched, and tests passed. A reusable command looks like this: Run the optimized file under a different fresh session key. Keep the agent, model, thinking level, task, output contract, and system configuration fixed. If the system prompt hashes differ, the comparison is contaminated and should be rerun. The observed result was: Measure Baseline Optimized Change : : : Input file 4,102 bytes 924 bytes −77.5% Input tokens 24,605 23,614 −991 (−4.0%) Output tokens 72 72 no change Exact outcome JSON pass pass preserved Artifact SHA 256 match match preserved Tests pass pass preserved The large difference between file reduction and total input reduction is the useful finding. In both runs OpenClaw reported the same 33,883 character system prompt. Removing 3,178 bytes from one record therefore could not remove 77.5% of the whole prompt. This is why a dramatic screenshot of a smaller log does not establish a dramatic bill reduction. Wall time fell from 28.7 to 21.8 seconds, but one sample per variant is not enough to attribute latency to the context change. Model service variance, queueing, and network conditions are uncontrolled. Treat latency as unproven until several interleaved repetitions show a stable distribution. Remove repetition without deleting the decision Use the smallest lever that targets the largest measured contributor. For old tool output, OpenClaw’s session pruning documentation describes in memory pruning that trims eligible tool results while leaving the on disk transcript intact. It preserves recent turns and can soft trim large results before hard clearing older ones. That is a better fit for bulky command output than rewriting normal conversation text. For long conversation history, /compact creates a summary and keeps recent messages. The compaction guide says the summary is persisted in the transcript while the full history remains on disk. Guide the summary toward the task: Compaction has a boundary. A smaller prompt that loses an idempotency key, approval state, or expected digest can cause expensive and unsafe rework. After compaction, ask the agent to restate the outcome contract and compare it with the stored receipt before continuing. Retries need their own control. OpenClaw’s retry policy explicitly aims to retry the current request, preserve ordering, and avoid duplicating non idempotent operations. Do not solve a timeout by replaying an entire multi step flow. First check whether the external effect already happened. Then retry only the unresolved idempotent step, with a hard attempt limit. A compact retry record should still answer: Which step failed, and with what terminal error? Was an external effect observed before the timeout? Is the next action idempotent? How many attempts remain? What evidence will prove recovery? Anything that cannot change those answers is a candidate for trimming. Anything needed to answer them stays. Gate savings on the verified outcome Token reduction and outcome quality belong in the same test report. Use a deterministic receipt when the task permits it: file existence plus digest, test results, database row plus idempotency key, HTTP status plus response hash, or a destination specific message ID. Use an LLM judge only for properties that cannot be checked directly. Apply this decision rule: Test one lever at a time: large tool result trimming, guided compaction, shorter bootstrap files, smaller image dimensions, shorter skill descriptions, or a different model. Changing all of them together may reduce a bill, but it prevents you from learning which change helped and which one damaged reliability. Also separate cache economics from raw token reduction. A stable repeated prefix may be cheaper as a cache read than a constantly rewritten “short” prompt. Conversely, a large prompt recached after its time to live expires can be costly. Report input, output, cache read, cache write, and local price assumptions separately; never invent a cost when model pricing is missing. The controlled result here supports a practical default: retain terminal errors and receipts, collapse repetition, and judge the change against the same deliverable. It does not support aggressive deletion, a universal savings percentage, or declaring success from token counts alone. Sidewisp’s product direction includes planned token usage and estimated cost intelligence for OpenClaw and other agent runtimes, but that capability is not shipped today. The live experience is an early access site and product demonstration. If a health view that connects usage to verified outcomes would help your operations, you can join the private preview without changing your runtime or routing model calls through Sidewisp.