System prompt assembly needs holistic refactor

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:

• #11072 — TOOL_NAME keyword repeated in every built-in tool example; smaller models echo it as conversational text
• #11070 — Parser intercepts quoted tool syntax as real tool calls
• #11074 — Parser assumes tool calls are positionally terminal in model output
• #10783 — Reasoning content leaks into applied edits (no output structure guidance in prompt)
• #10785 — Reasoning content leaks into terminal output display
• #11069 — Vercel stream converter misroutes reasoning-delta to content
• #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

Start by tracing final prompt assembly in gui/src/redux/util/constructMessages.ts, then read the base messages, tool-message builder, codeblock framework, and rules injection files listed in the issue. Map how agent, chat, plan, tools, and rules are combined before defining the refactor boundaries. Done means prompt assembly has a central, model-aware structure without the documented contradictory or duplicated behavior.