How to Use OpenClaw Tokenjuice

OpenClaw tokenjuice is an optional bundled plugin for reducing noisy tool output before it flows back into an active agent session. It does not make commands safer, faster, or different. It compacts the returned tool_result after the command has already run. That distinction is important: tokenjuice is a context-management tool, not an execution policy.

30-second answer

Enable tokenjuice with openclaw config set plugins.entries.tokenjuice.enabled true, or use openclaw plugins enable tokenjuice. Then start a session that can call exec and run a noisy command such as git status. If tokenjuice is active, the returned output should be shorter and more structured than the raw shell output.

What it changes

The docs say tokenjuice applies to PI embedded runs and OpenClaw dynamic tools in the Codex app-server harness. It hooks tool-result middleware and trims exec or bash output before the harness consumes it. It does not rewrite shell input, rerun commands, or change exit codes. A failed command is still failed. A dangerous command is still dangerous.

What it leaves alone

Tokenjuice preserves exact file-content reads and other commands that should remain raw. That is the right tradeoff. If an agent asks to inspect a file, compacting away meaningful lines would make the next edit less reliable. Use tokenjuice for noisy process output, not as a blanket summarizer for source files.

When to enable it

Enable tokenjuice when logs, builds, git output, or CLI status commands are bloating sessions. It is especially helpful for long-running coding loops where repeated command output can eat context. If you are doing a forensic debug session where every line matters, disable it temporarily and preserve raw logs separately.

How to disable

The docs show openclaw config set plugins.entries.tokenjuice.enabled false or openclaw plugins disable tokenjuice. Keep the toggle easy to reverse. A context compactor should help the agent think, not hide evidence during an incident.

Playbook angle

The Playbook view is pragmatic: compact the stuff that wastes context, preserve the stuff that is evidence. That one rule keeps tokenjuice helpful instead of mysterious.

Runbook checklist

Before you automate this, run one small acceptance test with harmless input. Confirm the tool is available to the right agent, the credential is loaded from config or environment, the output shape matches the workflow, and the failure message is understandable to a tired operator. If the feature touches money, public channels, logged-in browsers, host commands, or customer data, put a review step before the side effect. If it only reads data, still record the source and timestamp so future sessions do not treat stale context as fresh truth. Keep the first version narrow, then expand once the logs show the agent is choosing the right tool for the right reason. When the docs are incomplete, prefer a conservative sentence over a clever invented shortcut that future agents cannot reliably verify. Add one monitoring habit as well: after the first real run, check the transcript or logs for missing prerequisites, broad prompts, stale assumptions, and accidental side effects. Tighten the instruction while the failure is fresh. The best OpenClaw workflows improve in small, documented passes instead of one giant rewrite after something breaks in public. For SEO pages, that same discipline matters: do not promise hidden capabilities, paid-provider limits, or setup shortcuts unless the current docs say so. Trust compounds when the guide is accurate even in the boring operational edge cases that matter during real maintenance windows.

Operator note

How to Use OpenClaw Tokenjuice works best when it is written into a small runbook instead of treated as a magic switch. Record who owns the workflow, which config keys are allowed, which credentials are required, what the agent may do without approval, and what counts as a failure. OpenClaw gives agents broad tools, but the reliable version is boring: one source of truth, one verification step, and one rollback path when a provider or channel behaves differently than expected.