One Prompt, Six Dialects: Rewriting System Prompts and Instruction Formats That Only Work on One Vendor

The Portability Problem

When you route the same request to different model backends (Claude, GPT, DeepSeek, Qwen, GLM, Kimi), prompt idioms that work well on one vendor can fail silently on another. The output may still look plausible, but instruction adherence, formatting, and reasoning quality degrade. This article explains which constructs are vendor-specific and how to write prompts that remain effective across providers.

Common Vendor-Specific Idioms

XML Tags

Many Claude prompts use XML-style tags like <instructions>, <context>, or <output_format> to delimit sections. While Claude respects these naturally, other models may ignore them, treat them as literal text, or misinterpret nesting. GPT models often respond better to Markdown headings or plain text separators. Qwen and GLM tend to follow clearly labeled sections but may not honor XML attributes.

Portable alternative: Use Markdown headings (##) or simple delimiters like === or --- with explicit labels. These are universally understood.

Role Phrasing and Persona Instructions

Phrases like "You are a helpful assistant" are common, but some models are more sensitive to role framing than others. Claude often respects detailed persona descriptions, while GPT models may require shorter, more direct instructions. DeepSeek and Kimi may respond differently to authoritative vs. collaborative phrasing.

Portable alternative: Keep role descriptions brief and functional. Focus on the task and constraints rather than elaborate personas.

Prefill (Assistant Response Prefilling)

Some APIs allow you to prefill the assistant's response to guide formatting (e.g., starting with { for JSON). This feature is not universally supported. If you rely on prefill for Claude but switch to a backend that doesn't support it, the model may not produce the intended structure.

Portable alternative: Use explicit output format instructions in the system or user message. For JSON, specify the schema and provide an example.

System vs. User Message Placement

Different vendors weight system messages differently. Some models treat system messages as strong constraints, while others may give more weight to the most recent user message. Placing critical instructions only in the system message can lead to inconsistent behavior across backends.

Portable alternative: Repeat key constraints in the user message, especially for formatting or safety rules. Use the system message for stable context and the user message for task-specific instructions.

Writing a Portable System Prompt

1. Use Universal Formatting

Avoid vendor-specific markup. Use Markdown headings, bullet points, and clear section labels. For example:

## Task
Summarize the following text in three bullet points.

## Constraints
- Use only information from the text.
- Do not add opinions.

This structure is understood by all major models.

2. Separate Stable and Dynamic Content

Place persistent instructions (persona, safety rules, output format) in the system message, but also include a condensed version in the user message when the task is critical. This redundancy helps ensure compliance across models with different system-message weighting.

3. Avoid Implicit Assumptions

Don't assume the model knows vendor-specific conventions. For example, instead of writing "Use XML tags as shown," explicitly define the expected format:

Wrap your answer in <answer> and </answer> tags.

Even if the model doesn't natively use XML, explicit instructions improve adherence.

4. Test Across Backends

Before committing to a prompt, run it through each model you plan to use. Check for:

• Instruction adherence (does it follow all constraints?)
• Output format consistency (JSON, Markdown, plain text)
• Handling of edge cases (empty input, ambiguous queries)

Small differences in phrasing can lead to large behavioral gaps.

5. Use a Prompt Abstraction Layer

If you frequently switch models, consider a lightweight abstraction layer that adapts prompts per backend. For example, you might transform a generic prompt into vendor-specific variants by swapping delimiters or reordering sections. This keeps your core logic portable while allowing optimizations.

Practical Checklist

• [ ] Replace XML tags with Markdown headings or plain delimiters.
• [ ] Keep role descriptions short and task-focused.
• [ ] Avoid relying on prefill; specify output format explicitly.
• [ ] Repeat critical instructions in the user message.
• [ ] Test prompts on each target model with representative inputs.
• [ ] Document vendor-specific quirks in your prompt library.

Conclusion

Writing portable prompts is less about finding a single universal format and more about avoiding unnecessary vendor-specific idioms. By using clear, explicit instructions and testing across backends, you can maintain consistent behavior whether you're calling Claude, GPT, DeepSeek, Qwen, GLM, or Kimi through a single API key. This approach reduces silent failures and makes your prompts easier to maintain as you add or switch models.