How to reduce system prompt size without losing context

Every OpenClaw session starts the same way: the system prompt loads before your first message. It is the invisible foundation everything else sits on. For many operators it is also the largest single consumer of context tokens in the entire session. A system prompt that has grown unchecked through months of adding files, rules, and plugins can consume 30,000 to 60,000 tokens before you type a single word. Those tokens are paid for on every turn, every session, every cron job that fires. This article covers what is actually inside your system prompt, which parts are weight you can cut, and the structural patterns that eliminate bloat without losing the context your agent actually needs.

Throughout this article you will see indented blocks like the ones below. Each one is a command you can paste directly into your OpenClaw chat. Your agent will run it and report back. You do not need to open a terminal or edit any files manually.

When people say “system prompt” they usually mean one file. In OpenClaw, the system prompt is assembled from multiple sources on every session start. Understanding what goes in helps you understand what you can trim and what you cannot.

Base instructions from OpenClaw itself. The platform injects a base system prompt covering tool usage, safety guidelines, formatting rules, and capability descriptions. This is not user-configurable in the typical sense, but it is a fixed token cost on every session.

Workspace context files. Any file listed in your workspace context config gets read and prepended at session start. For most operators this includes SOUL.md, AGENTS.md, USER.md, TOOLS.md, MEMORY.md, INFRASTRUCTURE.md, and others added over time. Each file adds tokens. A typical AGENTS.md that has grown over several months of use can run 5,000 to 15,000 tokens on its own.

Memory plugin injections. If you have autoRecall enabled, the memory plugin queries your memory store on each turn and injects matching memories into the context. Depending on your settings, this block can range from a few hundred tokens to several thousand per turn. It is not a one-time load at session start. It compounds on every single turn in the session.

Plugin context blocks. Some plugins inject their own context at session start: channel metadata, node status, conversation history from external platforms, active cron job listings, and others. Each plugin that does this adds to the system prompt total without any visible line in your workspace files.

Channel and routing metadata. Information about the current channel, sender identity, and available capabilities is injected by OpenClaw automatically. This is a small but non-zero cost.

Estimate the total token count of my current system prompt. Break it down by source: base platform instructions, each workspace file loaded at session start, memory injections (per turn average), and any plugin context blocks. Give me an approximate total and rank the sources by size.

This number is the baseline you are working from. Do not guess. Run it before deciding anything.

The immediate reason most people care about system prompt size is compaction. If your prompt consumes 40,000 tokens and your context window is 60,000, you have 20,000 tokens of working space before compaction fires. That sounds like enough until you factor in a few file reads and a tool call or two.

But system prompt size has three other effects worth understanding:

Cost per turn. You pay for input tokens on every model call. Your system prompt is re-sent as input on every turn. A 40,000-token system prompt on a session with 20 turns costs you 800,000 input tokens just from the prompt, before any actual conversation. On Claude Sonnet at $3 per million tokens, that is $2.40 per session in system prompt costs alone. On a model like DeepSeek at $0.28 per million tokens, the same session costs $0.22. The model you choose multiplies the system prompt cost directly.

Response latency. Models process all tokens in context before generating each reply. Larger context means longer time-to-first-token. The effect is subtle on short prompts and significant on long ones. If responses feel slow on the first turn before any history has built up, the system prompt size is the most likely cause.

Cron job costs. Every cron job that fires starts a new session and loads the full system prompt. A queue processor that fires 48 times a day loads your entire system prompt 48 times. If that prompt is 40,000 tokens and you are using an API model, that cron job is burning nearly 2 million input tokens per day just in prompt overhead before it does any actual work. Multiply by several active cron jobs and the numbers get real fast.

Based on my system prompt token estimate: how much is my system prompt costing per day in input tokens, assuming my cron jobs fire at their current frequency and I have roughly 10 active chat turns per day? Use my current primary model’s pricing.

Before cutting anything, run a structured audit. You need to know which sources are expensive and which are not. Cutting the wrong thing wastes time and may break something. Cutting the right things can halve your system prompt size in under an hour.

Step 1: Measure each workspace file

List every file in my workspace that loads at session start. For each one, read it and give me an approximate token count. Sort them from largest to smallest. Flag any file where I have not referenced or updated its content in the last two weeks.

The files you have not touched in two weeks are your first candidates for either trimming or moving to on-demand loading. They are loading on every session even though you rarely need them.

Step 2: Read your AGENTS.md and SOUL.md as if you are an editor

These files grow by accretion. Every time you add a rule, it stays. Every note that was meant to be temporary becomes permanent. Most AGENTS.md files in active use contain at least 30% cruft by the time they are six months old: rules that contradict newer rules, sections that describe behaviors you changed, warnings about bugs that were fixed, and notes written for a specific task that were never removed.

Read my AGENTS.md. Flag every section that meets any of the following criteria: (1) it describes a rule that is already covered by another section, (2) it references a tool, plugin, or config state that has since changed, (3) it was written for a specific task and does not apply to general operation, or (4) it is a warning about something that no longer exists. Do not edit anything yet. Just flag and explain.

Read my SOUL.md. What sections are essential to how you operate day-to-day? What sections have not influenced a response in recent memory? What could be condensed to half its current length without losing meaning?

Do not act on these findings yet. Collect them first. Review the full list before cutting anything.

Step 3: Audit memory injection settings

autoRecall is one of the highest-value features in the memory system. It is also one of the stealthiest token consumers. Before you can do anything about it, you need to know how your plugin injects memories, because the two injection patterns have very different cost profiles.

User message prefix injection is the most common pattern. Every time you send a message, the plugin prepends a block of recalled memories to it before it reaches the model. That block becomes part of the conversation turn. It gets stored in the conversation history. It is still there on turn 5, turn 10, turn 20. The cost is not flat per session. It compounds: each turn adds another injection block to the persistent history, and all of the previous blocks stay in context. A 20-turn session with 3,000-token injections per turn carries 60,000 tokens of memory blocks in history by the end, plus whatever the conversation itself contains.

System prompt layer injection injects memories into the system prompt position rather than the conversation history. In this pattern, the memory block is refreshed each turn but does not accumulate. Turn 20 has the same memory overhead as turn 1. The cost is flat: one injection block, replaced on each turn rather than stacked. This is significantly cheaper for long sessions.

To find out which pattern your setup uses:

Check my memory plugin config. Does autoRecall inject memories as a prefix to user messages, or does it inject into the system prompt layer? I want to know whether the injected blocks accumulate in conversation history or get replaced each turn.

If your plugin uses user message prefix injection and your limit is set to 10 memories averaging 200 tokens each, you are adding 2,000 tokens of memory blocks per turn. Across a 15-turn session, that is 30,000 tokens of injections in conversation history, not counting the injections themselves in each turn’s input. On Claude Sonnet at $3 per million input tokens, that is $0.09 per session just in memory injection overhead. Across 30 sessions in a month, that is $2.70 from memory injection alone, before any other costs. It adds up faster than it looks, especially with higher limits or longer sessions.

If your plugin uses system prompt layer injection, the math is different: 2,000 tokens per turn as a constant overhead, not a growing one. A 15-turn session costs the same 2,000 tokens per turn whether it is turn 2 or turn 15.

Regardless of injection pattern, the two settings that control cost are the result limit and the similarity threshold.

Read my memory plugin config. What is the maximum number of memories returned per autoRecall query? What is the similarity threshold currently set to? What is the approximate average token length of my stored memories? Based on those numbers and the injection pattern, estimate what memory injection is costing per session.

Result limit: 5 to 8 memories per turn is enough for useful recall in most setups. If you are set to 15 or 20, you are injecting a large block to retrieve marginal relevance from the lower-ranked results. Cut the limit to 8 and watch whether recall quality actually changes. It usually does not.

Similarity threshold: A higher threshold means the plugin only injects memories that are closely matched to the current message. A loose threshold sweeps in loosely-related memories to fill the result limit. Tightening it reduces the average injection size by retrieving fewer but more relevant results, without changing the limit at all. Start at 0.75 if you are currently below that.

If your plugin supports system prompt injection and you are currently using message prefix: switching to system prompt injection is the highest-impact change available. It converts a compounding cost into a flat one. Whether this switch is available depends on your specific plugin configuration.

This is the highest-impact structural change you can make. Instead of loading all context files at session start, load them when needed.

The pattern works like this: your AGENTS.md or a startup instruction tells your agent that certain files exist and what they contain, but does not load them directly. When a task comes in that needs that context, the agent reads the file then. When the task is done, the file content falls off as it compacts or is no longer referenced.

Files that are good candidates for on-demand loading:

• Project files. If you have a project that is active for a week then goes quiet, its project file does not need to be in the session-start context. A one-line reference in AGENTS.md (“project files are in memory/projects/ — load the relevant one when working on a project”) is enough.
• MEMORY.md and INFRASTRUCTURE.md. If these files change rarely, they do not need to reload every session. A brief summary section at the top of AGENTS.md with a pointer to the full file is often sufficient for most sessions.
• Research and reference files. Any file that was generated for a specific task (a research report, a competitor analysis, a product brief) should never be in the session-start context unless you are actively working on that task right now.
• Tools and skills documentation. If your TOOLS.md is a detailed reference document, most of it is not needed on every turn. A two-line summary of available tools and a pointer to the file for details works for most sessions.

Look at the full list of files that load at my session start. For each one, tell me: how often does a typical session actually need the content in this file? Would a brief summary plus a “read this file when needed” instruction work instead of loading the full content? Which files are strong candidates for on-demand loading?

The goal is not to reduce what your agent knows. It is to defer loading context until the moment it is actually needed rather than preloading everything speculatively.

Beyond moving files to on-demand loading, the files that do stay in the session-start context should be as lean as possible. This is the editing pass.

Cut redundancy ruthlessly

Rules that appear in both SOUL.md and AGENTS.md should appear in one place. Pick the one that is the most appropriate home and delete the copy. The same applies to model routing rules, communication preferences, budget guidelines, and protocol descriptions. These tend to replicate across files as the workspace grows.

Replace narrative with bullets where possible

A paragraph explaining a rule uses more tokens than a bullet that states the same rule directly. “When approaching any task, Gambit should first consider whether the approach aligns with the governing priority order, which places cost reduction above all other concerns, followed by security hardening, then autonomy improvements, and finally monetization-related activities” is about 60 tokens. “Priority order: (1) cost (2) security (3) autonomy (4) monetize” is 12 tokens and conveys the same rule. The model does not need prose explanation to follow a rule. It needs the rule stated clearly.

Remove historical notes and incident logs

AGENTS.md often accumulates notes like “resolved 2026-03-18: the autoRecall conflict was caused by X” or “do not use Y because of the incident on date Z.” Once a bug or issue is resolved and no longer active, its documentation does not need to live in the session-start context. Move it to an archive file or delete it. The resolution matters when you are debugging. It does not need to be loaded on every turn of every session forever.

Audit the Known Issues sections

These sections are worth special attention. They tend to grow: every issue gets added, resolutions sometimes get noted but the issue entry stays. Walk through each known issue entry and ask: is this still an active concern? If the underlying bug was fixed or the workaround was incorporated into normal operation, remove the entry entirely.

Read my AGENTS.md. Identify every historical note, resolved issue, incident reference, or changelog entry. These are things like “resolved on date,” “fixed after the X incident,” “workaround applied,” or sections that describe past states of config or plugins that have since been updated. List them all. Do not edit yet.

Now do the same for SOUL.md and MEMORY.md if those files load at session start. What historical content exists in each? What would be safe to remove or archive without affecting day-to-day operation?

Over-trimming is a real risk. Some context that appears redundant or rarely referenced is actually load-bearing in ways that are not obvious until it is gone.

Model routing rules. These need to be in the session-start context. If your agent does not know at session start which model to use for which type of task, it will default to whatever the config says, which may not be what you want. This content looks short but saves money every day. Keep it.

Red lines and failure protocols. Rules about what the agent should never do, what to do when blocked, and what requires explicit approval before acting. These need to be present at every turn, not just loaded on demand. They are the safety layer. Trimming them to save tokens is a false economy.

Active project state. If you are in the middle of a multi-day project, the project context file needs to load. This is the exception to the on-demand rule. Active project state is worth the token cost because it prevents your agent from starting each session cold on work-in-progress.

Communication routing. Channel IDs, contact information, and notification targets. If these are missing, your agent cannot reach you when something goes wrong. Worth the tokens.

Before I approve any changes to my system prompt files: which sections are safety-critical or operationally essential and should not be removed regardless of size? Flag anything that would cause real problems if it were missing from session-start context.

After making changes, measure. Do not assume the changes worked.

Start a new session and estimate the total system prompt token count again using the same breakdown as before. Compare it to the baseline. What is the reduction? Did compaction behavior change? Did anything break or feel different in how you are operating?

A 20% reduction in system prompt size is a reasonable target for a first pass. A 40% reduction is achievable if the files have been growing for more than a few months without any editing. Numbers above 50% are possible but usually require moving significant context to on-demand loading rather than just trimming existing files.

Run one full day of normal sessions before declaring the reduction successful. Watch for: unexpected agent behavior that might indicate missing context, compaction firing earlier or later than before, and any cron job outputs that seem to miss context they previously had.

System prompt trimming is part of a larger configuration audit. Context window sizing, compaction thresholds, security exposure, and model routing all interact. The complete guide covers all of them together with the agent prompt that does the audit automatically and proposes the specific changes for your setup.