System prompt assembly needs holistic refactor

[shanevcantwell]

Problem

The system prompt is the primary interface between Continue and every model it communicates with. It is currently assembled ad-hoc from hardcoded string literals spread across multiple files, accumulated through incremental changes by 400+ contributors over two years of growth. There is no template system, no per-model awareness, and no separation between base instructions, tool syntax, mode-specific behavior, and rules.

Current state

The system prompt is constructed by concatenating pieces from:

• core/llm/defaultSystemMessages.ts — mode-specific base messages (agent/chat/plan), hardcoded string literals
• gui/src/redux/util/getBaseSystemMessage.ts — mode selection and a hardcoded all-caps NO_TOOL_WARNING appended when no tools are active
• core/tools/systemMessageTools/toolCodeblocks/index.ts — tool syntax framework with hardcoded prefix, suffix, and example templates
• core/tools/systemMessageTools/buildToolsSystemMessage.ts — concatenates tool definitions (two incompatible formats: example-based for built-ins, schema-based for MCP)
• core/llm/rules/getSystemMessageWithRules.ts — appends workspace rules without budget awareness

There is no central template. No model-size or capability awareness. The only override is model.baseAgentSystemMessage, which replaces the entire base message or nothing.

What the model receives

With tools enabled (agent mode): A brief mode declaration ("You are in agent mode"), codeblock formatting instructions, then tool-use syntax rules and per-tool examples. The actual behavioral guidance is approximately 50 tokens. Everything else is tool syntax documentation.

With no tools enabled (agent mode): The same tool-use rules for tools that don't exist, followed by an all-caps message: "THE USER HAS NOT PROVIDED ANY TOOLS, DO NOT ATTEMPT TO USE ANY TOOLS." The model receives contradictory instructions in a single system message.

For local models with small context windows: No adaptation. The same prompt is sent to a 4-bit quantized 9B model as to GPT-4 or Claude. No output format guidance, no structural constraints, no awareness of context budget.

Documented downstream effects

The following open issues trace back to or are compounded by the system prompt:

• System message tool prompts teach models to echo TOOL_NAME keyword #11072 — TOOL_NAME keyword repeated in every built-in tool example; smaller models echo it as conversational text
• System message tools parser intercepts quoted tool syntax as real tool calls #11070 — Parser intercepts quoted tool syntax as real tool calls
• System message tools parser assumes tool calls are positionally terminal #11074 — Parser assumes tool calls are positionally terminal in model output
• Apply/edit writes raw model reasoning into files instead of filtering #10783 — Reasoning content leaks into applied edits (no output structure guidance in prompt)
• Model reasoning leaks into run_terminal_command output display #10785 — Reasoning content leaks into terminal output display
• Vercel stream converter maps reasoning-delta to content instead of reasoning_content #11069 — Vercel stream converter misroutes reasoning-delta to content
• System prompt not sent to local LM Studio models #10781 — System prompt not sent to local LM Studio models in some configurations

An InfoWorld article (https://www.infoworld.com/article/4144487/i-ran-qwen3-5-locally-instead-of-claude-code-heres-what-happened.html) documents end-user failures with local models through Continue that are consistent with these issues: crashes mid-apply, infinite loops, mangled indentation, and erasing entire files.

Files involved

• core/llm/defaultSystemMessages.ts — base system messages
• gui/src/redux/util/getBaseSystemMessage.ts — message selection and no-tools warning
• core/tools/systemMessageTools/toolCodeblocks/index.ts — tool syntax framework
• core/tools/systemMessageTools/buildToolsSystemMessage.ts — tool message generation
• core/llm/rules/getSystemMessageWithRules.ts — rules injection
• gui/src/redux/util/constructMessages.ts — final assembly

[shanevcantwell]

Community-reported issues tracing to the same root (since Oct 2025)

The following issues filed by other contributors describe failures consistent with the ad-hoc system prompt assembly:

Tool call parsing failures:

• Tool / Agent command parsing breaks due to streamed token fragmentation (Ollama + Qwen3-Coder) #9529 — Streamed token fragmentation breaks tool/agent parsing with Ollama + Qwen3-Coder. The parser built to intercept text-based tool calls can't handle chunked tokens across the TOOL_NAME/BEGIN_ARG boundaries.
• Agent tool calls fail when OpenAI-compatible models return XML-like function.arguments #11453 — OpenAI-compatible models return XML-like function.arguments; Continue assumes JSON-only. A different model's interpretation of underspecified tool calling format.
• Ollama models (Mistral, Gemma) fail during MCP tool calling due to message formatting incompatibilities #9249 — Ollama models (Mistral, Gemma) fail MCP tool calling due to message formatting incompatibilities.
• Bug: Tool ID pattern validation fails after switching models in agent mode #10416 — Tool ID pattern validation fails after switching models in agent mode.

Models misinterpreting the system prompt:
- #10495 — Local Ollama model self-identifies as "Claude". The system prompt provides no identity; the model defaults to training-time identity or inherits from prompt artifacts. Struck from this list because this is not at all uncommon behavior in any model frontier or open weights.

• File editing tool in agent mode overwrites the file with model thoughts not with actual changes #9379 — File editing tool in agent mode overwrites files with model thoughts instead of actual changes. The system prompt provides no instruction to separate reasoning from output. (Qwen2.5-coder:14b via Ollama)
• edit_existing_file may need an improved description to help GLM-4.6 use it correctly all the time #8189 — edit_existing_file description insufficient for GLM-4.6 to use correctly. The tool's system message description doesn't provide enough guidance for non-GPT/Claude models.

Local model tool use broken:

• continue tool calling with supported models not working #9157 — Tool calling with supported models not working.
• Agent/Plan mode does not execute tool calls with Ollama remote HTTPS endpoint (RunPod, VS Code Remote SSH) #10198 — Agent/Plan mode does not execute tool calls with Ollama over remote HTTPS.
• Responses from LLM's running from LocalAI are not detected #10113 — Responses from LocalAI models are not detected.
• Fail to call Qwen3-Coder model with tool calling enabled #8744 — Fail to call Qwen3-Coder model with tool calling enabled.

Reasoning/thinking content handling:

• File editing tool in agent mode overwrites the file with model thoughts not with actual changes #9379 — Model thoughts written into files (same as above, dual-category)
• Not able to disable thinking mode for the self hosted models which use OpenAI as a provider (please read quick description) #9102 — Cannot disable thinking mode for self-hosted OpenAI-compatible models.
• Error: Gemini 3 Flash - Invalid role: thinking #9944 — Gemini 3 Flash: "Invalid role: thinking"

These span 6 months, multiple model providers (Ollama, LM Studio, LocalAI, Bedrock, Vertex, OpenAI-compatible), and multiple model families (Qwen, Mistral, Gemma, DeepSeek, GLM). The common factor is the system prompt and tool definition path.

[shanevcantwell]

Static rules reference nonexistent tools

The base system message (defaultSystemMessages.ts) and the tool framework suffix (toolCodeblocks/index.ts) contain hardcoded rules that are included regardless of which tools are actually enabled. These rules reference specific tool capabilities that may not be present.

The 6 rules in the base message:

1. ALWAYS read a file before editing it.
2. Do NOT call edit tools in parallel with each other.
3. Do NOT use terminal commands (sed, awk) to edit files — use the edit tools.
4. For find-and-replace tools: old_string must match file contents EXACTLY, including whitespace.
5. ONE tool call at a time unless multiple read-only tools can run simultaneously.
6. When done, respond with plain text. Do not call tools when you have the answer.

Rules 1-4 reference edit tools, find-and-replace tools, and terminal commands. If those tools are not enabled, these rules describe capabilities that don't exist.

The 9 rules in systemMessageSuffix repeat and expand on this, again unconditionally.

Example: single tool enabled

When a user enables only read_file, the model receives this system prompt:

You are a coding assistant with access to tools. Tool definitions and calling syntax are provided below.

## Rules

1. ALWAYS read a file before editing it.
2. Do NOT call edit tools in parallel with each other.
3. Do NOT use terminal commands (sed, awk) to edit files — use the edit tools.
4. For find-and-replace tools: old_string must match file contents EXACTLY, including whitespace.
5. ONE tool call at a time unless multiple read-only tools can run simultaneously.
6. When done, respond with plain text. Do not call tools when you have the answer.

## Important
If a tool call fails or returns no useful results, respond with plain text explaining what you tried. Do NOT invent tools that are not listed or use other tool call syntax.


<tool_use_instructions>
You have access to tools. To call a tool, you MUST respond with EXACTLY this format — a tool code block (```tool) using the syntax shown below.

CRITICAL: Follow the exact syntax. Do not use XML tags, JSON objects, or any other format for tool calls.

The following tools are available to you:

To read a file with a known filepath, use the read_file tool. For example, to read a file located at 'path/to/file.txt', you would respond with this:
```tool
TOOL_NAME: read_file
BEGIN_ARG: filepath
path/to/the_file.txt
END_ARG

RULES FOR TOOL USE:

1. To call a tool, output a ```tool code block using EXACTLY the format shown above.
2. Always start the code block on a new line.
3. You can only call ONE tool at a time.
4. The tool code block MUST be the last thing in your response. Stop immediately after the closing .
5. Do NOT wrap tool calls in XML tags like <tool_call> or <function=...>.
6. Do NOT use JSON format for tool calls.
7. Do NOT invent tools that are not listed above.
8. If the user's request can be addressed with a listed tool, use it rather than guessing.
9. Do not perform actions with hypothetical files. Use tools to find relevant files.
   </tool_use_instructions>

15 rules. 1 tool. 12 of the rules reference capabilities the model does not have.

[shanevcantwell]

(Note: the github code block issue with the formatting in the previous comment is github itself demonstrating the problem inherent in #11674)

[chernistry]

We ran into exactly this problem when building our multi-agent orchestrator. One system prompt for everything sounds reasonable until you're debugging why a 7B local model echoes your tool syntax as conversational text while Claude handles it fine. The root cause is always the same: prompt assembly that doesn't know what it's talking to.

The approach that worked for us was a three-layer separation:

1. Role templates as standalone Markdown files. Each role (backend engineer, QA, security reviewer, etc.) gets its own system_prompt.md with a config.yaml for defaults like preferred model tier and effort level. We have 17 of these. The template uses {{PLACEHOLDER}} substitution and simple conditionals ({{#IF VAR}}...{{/IF}}), rendered by deterministic code — no LLM involved in prompt construction. The key insight is that role identity and behavioral guidance are static content that should be version-controlled and diffable, not buried in string concatenation across six files.

2. Conditional section assembly based on task metadata. Not every agent needs every section. A docs writer doesn't need team coordination instructions. A manager doesn't need file ownership warnings. We define SectionRule objects that gate sections on role, scope (small/medium/large), file patterns, and session state. The prompt assembler (spawn_prompt.py) builds a list of named (section_name, content) tuples, filters them through the rules, then concatenates only what's relevant. This keeps small-context prompts lean — a local model running a simple task gets maybe 40% of the sections a frontier model on a complex task would get.

3. Adapter-layer formatting per CLI agent. The prompt text is the same, but how it gets delivered differs per target. Our Claude adapter passes structured JSON schemas via --json-schema to enforce machine-parseable output. The Codex adapter uses --json with a file output path. The Ollama adapter routes through Aider with --model ollama_chat/ prefixing. The Gemini adapter uses --output-format json. Each adapter knows what flags and envelope its target expects — the prompt assembler doesn't care about delivery mechanics, and the adapters don't care about prompt content.

The specific problem you describe with TOOL_NAME being echoed by smaller models — we see the same class of issue. The fix isn't just making the prompt shorter; it's making the prompt aware of what the model can handle. Our config.yaml per role sets default_model: sonnet or default_model: haiku, and the section filtering respects scope thresholds (min_scope parameter) so that lower-capability models don't get prompt sections they'll choke on. A 7B model doesn't need a 2000-token team coordination protocol. It needs the task, the file list, and tight behavioral constraints.

One concrete gotcha: prompt caching. If you're composing prompts dynamically, you need to decide which prefix is stable (cache-friendly) and which suffix varies per task. We split prompt parameters into "cache-safe" (role, template hash, project context hash, git safety rules) and "variable" (task descriptions, specialist lists, fork messages). Changing the variable parts doesn't bust the cache on the stable prefix. If Continue ever wants to leverage prompt caching with providers that support it, this separation matters from day one — retrofitting it is painful.

The contradictory instructions problem (tool syntax rules sent alongside "DO NOT USE TOOLS") is a perfect example of why prompt assembly needs to be section-aware rather than string-concatenation-based. Each section should know its own activation conditions. Tool syntax sections activate when tools are available. The "no tools" warning activates when they aren't. They should never coexist. We enforce this structurally — section rules are evaluated before concatenation, so contradictions are impossible by construction.

For what it's worth, our implementation is at https://github.com/chernistry/bernstein — specifically src/bernstein/core/spawn_prompt.py for the assembly logic and templates/roles/ for the role templates. Not suggesting you adopt it wholesale, but the patterns might save some design iteration.