OpenClaw + Claude Code Token-Saving Guide: Zero-Polling with Hooks Callbacks

The Pain Point: Excessive Token Consumption When OpenClaw Calls Claude Code

In the AI programming toolchain, the combination of OpenClaw (an open-source AI assistant framework) and Claude Code is incredibly powerful. However, many users have discovered a significant pain point in practice — excessive Token consumption.

In the traditional approach, after OpenClaw delegates a programming task to Claude Code, it needs to poll Claude Code every few seconds, constantly checking the task status and output. Polling is one of the most fundamental state synchronization methods in distributed systems — the client sends requests to the server at fixed intervals, asking "Is the task done yet?" This pattern was widely used in the HTTP era because the HTTP protocol itself is a stateless request-response model where the server cannot proactively push messages to the client. In AI Agent scenarios, the cost of polling is particularly steep: each poll requires re-transmitting context information to the large language model, and LLM billing is calculated by Token count. This turns what would normally be just network overhead into a very real economic cost.

This means the longer Claude Code takes to execute a task, the more times OpenClaw polls, and the greater the Token consumption. To put it in concrete numbers: assuming each poll consumes about 2,000 Tokens, polling every 10 seconds, a 6-minute task would generate approximately 72,000 Tokens of additional consumption. For complex development tasks, this overhead is substantial.

The good news is that both OpenClaw and Claude Code offer exceptional flexibility, and we can solve this problem through clever architectural design. The core solution is: leveraging Claude Code's Hooks callback mechanism to achieve a truly zero-polling development workflow.

Core Solution: Zero-Polling Architecture Based on Hooks Callbacks

Overall Workflow Design

The core idea behind this solution can be summarized in one sentence: Let OpenClaw only handle "dispatching tasks" and "receiving results," with the entire intermediate process handled independently by Claude Code. The specific workflow consists of four steps:

1. Task Delegation (One-Time Call): OpenClaw delegates the development task to Claude Code. This operation executes only once and runs in the background without blocking OpenClaw's chat window or main Agent.
2. Autonomous Development: After receiving the task, Claude Code independently carries out development and testing. Throughout this entire process, OpenClaw doesn't participate at all and consumes zero context Tokens.
3. Automatic Hooks Trigger: When Claude Code completes the task, it triggers a Stop event. The Hooks automatically write the execution results to a designated file, then send a Wake Event to wake up OpenClaw.
4. Result Push: OpenClaw reads the result file and pushes the task completion notification (including task description, project path, duration, file structure, etc.) to a chat group.

In this workflow, OpenClaw's Token consumption is virtually negligible — the first step only sends a single task instruction (~500 Tokens), and the last step only reads and forwards a result summary of no more than 1,000 characters (~1,000 Tokens). Compared to the tens of thousands of Tokens consumed under the polling model, this event-driven asynchronous architecture achieves an order-of-magnitude cost reduction.

Technical Principles Behind the Hooks Callback Mechanism

Hooks are a classic event-driven programming pattern that allows developers to insert custom logic at specific points in a software lifecycle. This concept is widely applied in technologies like Git Hooks, React Hooks, and Webpack Hooks. Claude Code's Hooks system draws from the lifecycle hook design found in CI/CD pipelines, exposing programmable interfaces at key points during Agent execution (such as startup, before/after tool calls, stop, session end, etc.). Developers can specify Shell scripts or commands to execute when specific events are triggered by configuring a JSON file. This design transforms "passive waiting" into "active notification" and is the key technical enabler for transitioning from a polling architecture to an event-driven architecture.

Why Stop Hook + Session End Dual Guarantee

Claude Code provides a total of 14 Hooks. This solution uses two of them:

• Stop Hook (Primary Callback): Triggers when Claude Code actually completes the development task, ensuring callbacks are only initiated upon task completion.
• Session End (Fallback Callback): Serves as a backup mechanism. If the Stop Hook fails to trigger for any reason, Session End acts as a safety net to ensure the user always receives a task completion notification.

This dual-guarantee mechanism is critically important — it ensures the reliability of the entire workflow. No matter what happens, the user will receive a notification in the chat app after development is complete. This redundancy design is a common best practice in distributed systems, similar to the "At-Least-Once Delivery" semantics in message queues — it's better to send duplicate notifications than to miss one.

Agent Teams: Claude Code's Multi-Agent Collaboration Capability

This solution becomes even more powerful thanks to Claude Code's new Agent Teams feature.

Multi-Agent Systems (MAS) are an important research direction in artificial intelligence. The core idea is to have multiple agents with independent decision-making capabilities collaborate to complete complex tasks. In the LLM era, this concept has been reinvigorated — frameworks like AutoGen, CrewAI, and MetaGPT are all exploring multi-Agent collaboration patterns. The key difference between Claude Code's Agent Teams and these frameworks is that it doesn't implement multi-Agent scheduling at an external orchestration layer. Instead, it natively supports multi-process parallelism within Claude Code itself, where each Agent shares the same code repository context but has an independent execution environment. This design avoids context loss from cross-process communication while also sidestepping the common problem in traditional multi-Agent frameworks of "inter-Agent conversations consuming massive amounts of Tokens."

Agent Teams essentially creates a complete development team within Claude Code, with the following capabilities:

• True Parallel Execution: Each Agent is an independent process that can handle different tasks simultaneously
• Inter-Agent Communication: Agents can communicate with each other and share task lists
• Automatic Task Claiming: Team members can automatically claim pending tasks
• Specialized Role Assignment: You can set up frontend Agents, backend Agents, testing Agents, and other specialized roles

Combining Agent Teams with Hooks callbacks means we can issue a single command through OpenClaw and have multiple Agents within Claude Code collaboratively complete complex full-stack development tasks — with zero intervention from OpenClaw throughout the process.

Key Implementation Details

The entire implementation involves the coordination of several key scripts:

1. Task Writing Script: Responsible for writing the development task issued by OpenClaw to a designated file
2. Claude Code Launch Script: Reads the task file and starts Claude Code for execution
3. Callback Script (Stop Hook Trigger): Automatically executes when Claude Code completes development, reads the execution result file, and sends task completion information to OpenClaw
4. Message Push: After OpenClaw receives the callback, it pushes the results to a dedicated chat group

The reason for pushing completion notifications to a separate group rather than the main chat window is that the main Agent might be handling other tasks (like checking the weather, casual chatting, etc.). Suddenly inserting a task completion notification would disrupt the context and degrade the interaction experience. This design follows the "Separation of Concerns" software engineering principle — isolating different types of message streams into different channels ensures both the continuity of the main conversation and the timely delivery of development notifications.

Live Demo: Falling Sand Simulation Game Development

In actual testing, the author gave OpenClaw a fairly challenging task:

Use Claude Code's Agent Team collaboration mode to build a falling sand simulation game with a material system based on a physics engine using HTML/CSS.

Falling Sand Simulation is a category of particle simulation games based on Cellular Automaton principles, dating back to the Flash game era around 2005. The core technical challenge lies in simulating the physical behavior of thousands or even tens of thousands of particles on a 2D grid, where each particle interacts with neighboring particles based on its material properties (density, fluidity, flammability, etc.). For example, sand needs to follow gravity and stacking rules, water needs to simulate fluid diffusion behavior, and flames need to propagate upward and interact with combustible materials. Implementing a fully functional falling sand simulation requires covering multiple technical domains including particle system design, material state machines, collision detection, and rendering optimization — making it an excellent test case for evaluating AI programming capabilities.

After sending the task, OpenClaw quickly confirmed that it had delegated the task to Claude Code's Agent Teams and indicated that "you'll be automatically notified in the group when it's done." The main Agent was not blocked and could continue executing other tasks — weather queries, telling jokes, and other operations all responded instantly.

About 6 minutes later, the chat group received a task completion push containing the following information:

• Game name and description
• Project file path and complete file structure
• Completion time (approximately 6 minutes)
• All 184 tests passed
• Performance metrics and delivery notes

The resulting falling sand game was fully functional: sand naturally falls and accumulates, water flows above the sand, flames float upward, wood can be placed, and steam landing on wood even turns into rain — the physics engine's material interaction effects were quite impressive.

Summary and Practical Recommendations

This zero-polling solution based on Hooks callbacks fundamentally solves the Token waste problem when OpenClaw calls Claude Code. Its core advantages include:

• Minimal Token Consumption: OpenClaw only consumes a tiny amount of Tokens during task dispatch and result reception, saving over 95% of Token overhead compared to the polling model
• Main Agent Not Blocked: Can handle multiple tasks simultaneously, truly achieving an asynchronous workflow
• Mobile-Friendly: Even when away from the computer, you can issue commands from your phone and view results in the group when complete
• Reliability Guarantee: The Stop Hook + Session End dual callback mechanism ensures no notifications are lost

For users who frequently use OpenClaw + Claude Code for development, this solution is well worth deploying. It not only saves Token costs but more importantly achieves a truly fully automated development workflow — from task issuance to development completion to result notification, with zero manual intervention required throughout. This architectural pattern also lays the foundation for more complex multi-Agent collaboration scenarios in the future: as AI programming toolchains evolve from single-task execution to multi-task parallel orchestration, event-driven asynchronous communication will become indispensable infrastructure.