Taming Token Explosion in OpenClaw Agents via Harness‑Based Observability, Memory & Skills

OpenClaw Popularity and Token Explosion

Since its November 2025 release, OpenClaw has attracted over 350 k stars and 70 k forks on GitHub (April 2026), becoming a leading AI‑Agent framework. Its ability to perform real‑world actions (file handling, email, code execution) lowers the usage barrier, but massive adoption has surfaced a severe Token explosion problem. OpenRouter data shows Chinese‑model usage grew from 4.68 trillion to 7.36 trillion tokens in one week (a 56.9% increase), indicating uncontrolled token consumption.

Root Causes of Token Explosion

The article identifies three categories of token waste:

Injection‑type explosion : loading all skills, long‑term memory, or intermediate states without prior filtering.

Repetition‑type explosion : re‑searching already‑found knowledge, re‑selecting stable skill paths, or re‑inferring known user preferences each turn.

Black‑box‑type explosion : lacking visibility into which skill, memory segment, or prompt component consumed tokens, making optimization guesswork.

These waste patterns stem from the way OpenClaw assembles the model’s context, which includes persisted session history, dynamically built system prompts, and semantic memory retrieval.

Harness Perspective on the Problem

Quoting Vivek Trivedy from The Anatomy of an Agent Harness , an agent consists of Model + Harness . All token‑related issues belong to the Harness layer (configuration, context building, skill injection, observability). The article frames the solution as managing three dimensions: inference budget (tokens), information inflow (memory), and capability exposure (skills).

Observability Solutions

When OpenClaw runs on Amazon Bedrock, native CloudWatch metrics such as InputTokenCount, OutputTokenCount, and TimeToFirstToken can be collected. Writing these metrics to CloudWatch Logs or Timestream enables time‑series analysis and hotspot detection. Bedrock’s AgentCore Observability further breaks down a task into steps, reporting per‑step model calls, latency, and token usage, moving visibility from a single call to the full execution chain.

However, even with AgentCore, the system cannot directly report how many tokens each prompt component (skill description, memory snippet, system prompt) consumes. Therefore, additional instrumentation inside the Agent Runtime is required for fine‑grained tracing.

Memory Management Strategies

OpenClaw stores session history as Markdown files indexed in SQLite, augmented with vector embeddings and full‑text search (FTS5 with BM25). The MemoryIndexManager handles indexing, embedding, and retrieval, supporting providers such as local Llama or Amazon Bedrock.

Hybrid search combines vector similarity (semantic recall) with keyword matching (FTS5) using a weighted score:

Score = (VectorWeight × VectorScore) + (FtsWeight × FtsScore)

. Time‑decay weighting prefers recent memories.

The framework also implements a “Dreaming” subsystem that promotes frequently accessed short‑term memories to long‑term storage (MEMORY.md) via Light‑Sleep and REM‑Sleep phases, applying a weighted formula over retrieval frequency, semantic relevance, and diversity.

To prevent unbounded context growth, a layered memory architecture is proposed:

Short‑term layer : retains the current session and recent rounds.

Long‑term layer : a global knowledge base of verified facts and user preferences.

Dynamic loading policies decide how many memory items to inject based on task complexity and remaining prompt window, aiming to reduce token consumption by 40‑60%.

Skill Management and Progressive Disclosure

Skills are defined declaratively via SKILL.md (YAML metadata + Markdown instructions). OpenClaw loads skills from four sources in priority order: Workspace skills, Managed (global) skills, Bundled (built‑in) skills, and Extra directories.

To avoid context bloat, a three‑level progressive disclosure is used:

Level 1 – Metadata (~100 tokens): names and short descriptions loaded at startup.

Level 2 – Instructions (<5 k tokens): full SKILL.md content loaded when a skill is activated.

Level 3 – Resources (on‑demand): auxiliary files, scripts, or assets loaded only during execution.

During runtime, skill information is injected into the prompt as description, usage guide, and required environment details. A snapshot of the active skill set is taken at session start to guarantee consistency across turns.

Skill selection can be optimized by semantic retrieval (vectorizing skill descriptions) or task‑driven classification, reducing unnecessary skill injection. Amazon Agent Registry is cited as an external service that provides hybrid search and MCP‑native access for on‑demand skill discovery.

Comprehensive Optimization Recommendations

Summarising the analysis, the article proposes a three‑tier observability stack:

Model‑call layer (LLM usage metrics).

Agent‑execution layer (task/step tracing via Bedrock AgentCore).

Prompt‑construction layer (context composition analysis, currently missing in OpenClaw).

Key actions include:

Enable CloudWatch metrics and AgentCore tracing for end‑to‑end token accounting.

Adopt layered memory with semantic de‑duplication, summarisation, and time‑decay to cut token waste.

Implement progressive skill disclosure and on‑demand loading to keep prompt size minimal.

Introduce token‑budget checks per task and abort or downgrade models when limits are exceeded.

By treating Memory and Skill as primary token consumers and closing the monitoring loop, developers can substantially lower operational costs while preserving the expressive power of AI agents.

Future Work

The series will continue with deep‑dives into observability best practices on AWS, alternative vector‑store options, and advanced harness functions beyond memory and skill management.