Problem:

OpenClaw injects the same workspace context (AGENTS.md, SOUL.md, USER.md, TOOLS.md, etc.) and exposes the same tool list to every model regardless of its capabilities or intended use. When users route between multiple models via /model or configure additional providers through OpenAI-compatible proxies, this creates several problems:

1. Wasted context on models without tool access. Models added via external proxies or providers that don't support OpenClaw's tool calling still receive the full tool list and skill descriptions in their system prompt. This consumes thousands of tokens with information the model can't act on, and often causes the model to hallucinate tool calls or emit malformed function-call syntax.

2. No way to customize workspace files per model. Different models serve different purposes in a multi-model workflow. An orchestrator model needs full workspace context. A model used purely for conversation or research might need a stripped-down profile — or entirely different instructions. Currently the only workaround is embedding model-specific conditional blocks inside AGENTS.md (e.g., "If you are Model X, ignore the tool list"), which is fragile and wastes tokens for every other model that has to read past it.

3. System prompt bloat degrades quality. The combined system prompt (tools + skills + workspace files + runtime instructions) can easily exceed 15-20K tokens. For models with smaller context windows, or tasks where most of that context is irrelevant, this bloat reduces effective working memory and increases latency and cost.

Use Cases:

• Multi-provider setups: Primary model runs as full orchestrator (tools + workspace), secondary model handles research/conversation (no tools, minimal workspace files).
• Specialized model roles: A coding model needs coding skills and workspace context; a research model needs web search only; a conversation model needs minimal injection.
• Proxy-integrated models: Models accessed through OpenAI-compatible proxies that don't support tool calling shouldn't receive tool descriptions at all.
• Context window management: Models with limited context windows need control over what's injected so working memory isn't consumed by irrelevant system prompt.

Proposed Solution:

An optional contextProfile per model alias or provider that controls what gets injected:

models:
  aliases:
    research:
      provider: custom-proxy
      model: research-model
      contextProfile:
        workspaceFiles: ["USER.md"]  # only inject these (default: all)
        tools: false                  # strip tool list from system prompt
        skills: false                 # strip skill descriptions

Design points:

• Opt-in, backward compatible. No contextProfile = current behavior (everything injected).
• Granular control. Independently toggle workspace files, tools, and skills.
• Per-alias scoping. The same underlying model might serve different roles — configuration should live at the alias level.

Benefits:

• Clean /model switching without behavioral contamination between roles
• Reduced token waste and faster responses for models that don't need full context
• Eliminates fragile conditional blocks in workspace files
• First-class support for multi-model workflows that power users are already building with workarounds