openclaw - 💡(How to fix) Fix [Feature]: session-level chat mode for lower-cost lightweight conversations [1 comments, 2 participants]

Summary

Add a session-level chat mode as a lighter alternative to full agent mode.

This would let users explicitly choose between:

• chat: lightweight conversation
• agent: full OpenClaw execution behavior

Problem to solve

For simple chat scenarios, the default full agent path can be heavier than needed.

Even when the user only wants a quick explanation or summary, the runtime may still carry:

• larger system prompt sections
• longer history
• tool-related behavior
• workspace-aware execution framing

That increases token usage and makes lightweight conversations more expensive than necessary.

Proposed solution

Introduce a session-level mode switch:

• /mode chat
• /mode agent
• /mode

Chat mode

Intended for:

• simple Q&A
• explanations
• summaries
• low-risk conversations

Behavior:

• lighter system prompt
• shorter history window
• reduced or disabled tool exposure
• less execution-oriented behavior

Agent mode

Keeps the current full behavior for:

• reading/writing files
• running commands
• browsing/searching
• multi-step task execution
• workspace-aware work

Introduce a session-level mode switch that lets users explicitly choose between a lightweight \chatmode and the existing fullagentmode. The minimal UX could be slash commands such as/mode chat, /mode agent, and /modefor status. Inchatmode, OpenClaw should assemble a lighter runtime context by using a shorter system prompt, a shorter history window, and reduced or disabled tool exposure, so the model behaves more like a lightweight conversational assistant. Inagentmode, OpenClaw should preserve the current full execution-oriented behavior, including workspace-aware context and full tool access. A good first version should be additive and opt-in, with session-persistent mode state so one session can stay lightweight while another stays fully agentic. As a follow-up,chat` mode could optionally support a small allowlist of lightweight read-only tools such as web search or web fetch without escalating to full agent mode.

Alternatives considered

No response

Impact

Affected users are people using OpenClaw for everyday chat-style conversations in TUI, WebChat, or messaging channels where they do not actually need full agent execution behavior on every turn. The severity is moderate: it does not usually block usage, but it can make simple conversations unnecessarily expensive and heavier than needed. This pain occurs frequently in normal use, because many interactions are lightweight Q&A, summaries, clarifications, and low-risk discussion rather than file mutation or multi-step task execution. The practical consequence is higher token usage, more context growth, and unnecessary escalation into tool- or workspace-aware behavior, which can increase cost, latency, and operational complexity for otherwise simple requests.

Evidence/examples

I built and tested a local prototype of this idea on OpenClaw v2026.3.13. In side-by-side testing with the same dev agent/model setup and similar prompts in separate clean sessions, \chatmode consistently behaved more directly and lightly, whileagentmode was more likely to expand into reads/search/execution behavior. For a token-optimization prompt, I observed roughly11k / 400kcontext usage inchatmode versus66k / 400kinagentmode, or about a 6x difference for that task shape. This suggests the savings come not only from shorter replies, but from a lighter overall runtime path with less context expansion and fewer tool-triggering behaviors. I also observed thatchatmode produced more bounded responses for prompts like “请用三句话总结 OpenClaw chat mode 的目的” and “请分析 chat mode 和 agent mode 的适用场景”, whileagent` mode more readily framed the task in terms of broader execution capabilities. If useful, I can provide implementation notes or a PR against current main.

Additional information

This proposal is intended as an additive feature, not a behavioral replacement for the current default agent path. The main goal is to provide an explicit low-cost session mode for lightweight conversations while preserving full agent behavior for execution-heavy tasks. I prototyped and validated the concept locally on v2026.3.13, but I understand any real upstream implementation should target current main. I also think session-level mode is the right granularity, because the same user may want one lightweight discussion session and another full execution-oriented session under the same agent. As a future extension, I think chat mode could support a configurable read-only lightweight tool allowlist, for example web search or web fetch, while still reserving heavy tools such as shell, browser control, file mutation, and multi-step execution for full agent mode.