Context Windows and Token Limits
Every LLM can only "see" a fixed amount of text at once — its context window. For agents that run many steps, accumulating tool results and conversation history can exhaust the context quickly. Understanding and managing context is essential for reliable, cost-effective agents.
What Is a Token?
LLMs don't read characters — they read tokens. A token is typically 3–4 characters of common English text. As a rough rule:
- 1 token ≈ 4 characters of English
- 100 tokens ≈ 75 words
- 1,000 tokens ≈ 750 words ≈ 1.5 pages
Code, non-English text, and special characters often use more tokens per character.
Context Window Sizes by Model
| Model | Context Window | Cost per 1M input tokens |
|---|---|---|
| GPT-4o | 128,000 tokens | $5.00 |
| GPT-4o-mini | 128,000 tokens | $0.15 |
| Claude 3.5 Sonnet | 200,000 tokens | $3.00 |
| Gemini 1.5 Pro | 1,000,000 tokens | $1.25 |
| Llama 3.3 70B | 128,000 tokens | ~$0.10 (self-hosted) |
Why Context Limits Matter for Agents
Each agent step appends to the context: the Thought, the tool call, and the Observation all consume tokens. After many steps — or with large tool results (e.g., a 10,000-word web page) — the context fills up. This causes:
- API errors (context exceeded)
- Expensive retries with truncated content
- "Lost in the middle" — the model forgetting earlier context
- Increased latency and cost per step
Context Management Strategies
Truncation
The simplest strategy: drop the oldest messages when context fills. Fast but risks losing important earlier context.
Summarisation
When context reaches a threshold, summarise old steps with a quick LLM call. More expensive but preserves information density.
Sliding Window
Keep only the last N steps in context, plus a pinned system summary. Good balance for long-running agents.
# Context management in OpenClaw
context_management:
strategy: "sliding_window" # truncate | summarise | sliding_window
max_history_tokens: 32000
summary_model: "gpt-4o-mini" # cheaper model for summaries
pin_system_prompt: trueHow OpenClaw Manages Context Automatically
By default, OpenClaw uses a smart truncation strategy: it always keeps the system prompt and the last 4 steps, and trims middle history to fit within 80% of the model's context limit. This prevents context overflow without requiring manual configuration.
Token Counting with the SDK
from openclaw import count_tokens, Agent
# Count tokens before running
prompt = "Summarise the Python 3.13 changelog in 200 words."
token_count = count_tokens(prompt, model="gpt-4o")
print(f"Prompt uses {token_count} tokens")
# Get token usage after a run
agent = Agent(model="gpt-4o", tools=["web_search"])
result = agent.run(prompt)
print(f"Total tokens used: {result.usage.total_tokens}")
print(f"Estimated cost: ${result.usage.estimated_cost_usd:.4f}")- Context windows limit how much text an LLM can process in one call.
- Agent steps accumulate in context — long runs can easily exhaust limits.
- Use
sliding_windoworsummarisestrategy for agents with many steps. - OpenClaw manages context automatically but you can configure the strategy explicitly.
- Larger context windows cost more — choose the smallest model that fits your use case.
Context Management Strategies
When agent conversations or workflows exceed the model’s context window, OpenClaw applies one of several strategies depending on your configuration:
| Strategy | Behaviour | Best for | Trade-off |
|---|---|---|---|
truncate | Drops oldest messages first | Simple chatbots | May lose critical context |
summarise | Compresses history to a summary | Long conversations | Adds one extra LLM call |
sliding_window | Keeps the N most recent turns | Stateless task loops | Context continuity limited to window |
memory_offload | Stores old turns in vector DB, retrieves on demand | Long-running sessions | Requires vector memory setup |
from openclaw import Agent
agent = Agent(
model="gpt-4o",
context_strategy="summarise",
context_strategy_config={
"summarise_after_tokens": 80_000,
"summary_model": "gpt-4o-mini", # cheaper model for summaries
"preserve_last_n_turns": 4,
},
)The summarise strategy adds one additional LLM call per summarisation event. Use a fast, cheap model (GPT-4o-mini, Claude Haiku) for the summary call to minimise latency and cost overhead. The summary is injected as a system-level message at the start of the context, so the agent retains awareness of earlier goals and constraints even after extensive truncation.