Migrating Across Models: Differences Between Claude / GPT / Domestic Chinese Models, Organizing the System Prompt; Where to Go Next — the Claude Course or the Codex Course

Today's Goals

1. Name the four places a prompt most often breaks when migrated across models, and give a fix for each
2. Organize a system prompt into a block structure so the provider-specific parts can be swapped independently
3. Move a prompt from one model to another using a migration checklist, and verify it passes

This is the last day of the course. For four days your prompt has run against the same model; today answers a question you will hit sooner or later — switch providers and why does it break, where does it break, and how do you move it without pain. There is one more thing at the end: this is the first of three free introductory courses, and you need to know where to go after it. When you have read the walkthrough and finished the lab, come back to the top of the page and check off the three goals.

Plain-Language Walkthrough

Why the same ticket gets botched by a different colleague

The same well-tuned ticket, handed to a different colleague — Colleague A is out, so you give it to Colleague B. B is just as capable, but the work comes out different: they treat your boxed "important" text as decoration, they write two pages for what you called "brief," they read "don't touch unrelated files" as "touching them is fine as long as you don't mention it." The ticket did not change. The person did — everyone carries a different default reading of the same paragraph.

Differences between models are exactly that. The same prompt performing differently on two models is not a matter of one being smarter; it is that training gave them different default readings: which markers they are sensitive to, how literally they execute an instruction, which topics make them cautious, how long an answer they habitually produce. Those differences are nearly invisible on normal inputs — both colleagues handle routine work fine — and they surface entirely on edge and adversarial inputs, which is precisely the six or seven cases in D4's test set. So the first discipline of cross-model migration is the same sentence D4 ended on: run the same test set after the move. The pass rate is your answer on whether anything regressed, and it beats any amount of "feels about the same."

One more fact to settle up front: the overwhelming majority of regressions in a migration are not capability differences but defaults hidden in the prompt that only hold for one provider. You added them without noticing over many debugging rounds against that model, and only a switch reveals they were dialect rather than the common language. Today's job is to find the dialect and isolate it.

The four places migration most often breaks

Gather up the migration experience of the past few years and the regressions land almost entirely in four places. Each gets a way to recognize it and a fix.

Format markers. Some models are unusually sensitive to a particular way of wrapping input — say, fencing it inside a pair of custom tags — and treat it as a clean boundary. Move to another model and the same markers may be read as ordinary text, or even echoed verbatim into the output. The reverse happens too: a prompt that uses Markdown headings or horizontal rules for structure loses force on a model that prefers tags. Recognize it: look for the symbols you used for structure appearing in the output — if they show up, the model did not read them as structure. Fix: lift the question of how input is wrapped out of the task description and put it in a block you can swap; keep provider-specific markers out of your examples too, or the model will learn them from the examples.

Instruction adherence. The same "brief explanation" yields two sentences on one model and two paragraphs on another. The same "output only the list" is followed to the letter by one and prefaced with a lead-in sentence by another. This is a difference in how literally instructions are followed. Recognize it: take one edge case and see whether it is executed to the letter or improvised on. Fix: do not reach for exclamation marks and the word "must." Instead write the requirement in a mechanically checkable form (D1's old rule for the format box) plus a reason. "Start directly with the first section, because the output is parsed section by section" is more stable across every model than three exclamation marks after "no pleasantries."

Refusal boundaries. Providers differ in which topics make them cautious and in how the caution manifests — an outright refusal, an added disclaimer, or answering a nearby question instead. A requirement that arrives wrapped in the story of a production 500 incident may, on one provider, trigger a paragraph about security practices that bursts your structured output. Recognize it: run the adversarial cases and watch for refusals or extra commentary the source model never produced. Fix: state the task's boundary explicitly in the provider-adaptation block ("this is an internal code review task and does not concern any external system"), and always keep the schema constraint on for structured output so there is nowhere for a disclaimer to go.

Length habits. Some models default to longer, more "thorough" answers and will pad a list with fields you might also want to validate; others run short and omit items that belonged. In an extraction task the first shows up as fields containing entries the requirement never mentioned, the second as missing fields. Recognize it: compare the output length and item count of three normal inputs across the two models. Fix: add a length note to the provider-adaptation block — "list in fields only the fields the requirement explicitly calls for; do not add ones you think should be validated" — and give that sentence a reason, or you are back to the adherence problem.

Organizing the system prompt into blocks: general rules, provider adaptation, task variables

All four breaks share one fix: make the organization of the system prompt itself separate the common language from the dialect. Split the system prompt into three blocks, each answering one question.

General rules answer "does this sentence still hold on another model?" If yes, it goes here. The role's vantage point, the task definition, the definition of done, the constraints with their reasons, the schema — none of that is provider-specific, and together they are the skeleton of the prompt. This should be the longest of the three blocks and the one you change least.

Provider adaptation answers "is this sentence only true for one provider?" If yes, it goes here. How the input is wrapped, what style the examples are written in, whether a length note is needed, how the task boundary is phrased, which structured-output switch to flip. You keep one of these per model, and on a migration you replace the whole block, leaving the general rules untouched.

Task variables answer "does this sentence change on every call?" If yes, it goes here. The requirement text, the output language, the team defaults. These are the parameters of D3's template function.

In code, the three blocks are three strings joined in order, with the second selected by provider:

type Provider = 'anthropic' | 'openai'
 
// General rules: what still holds on another model. Only this block is "the prompt itself".
const COMMON = [
  'You are a backend engineer reviewing endpoint designs. From the requirement description, extract the endpoint path, the HTTP method, the failure status code, and the names of the fields that need validation.',
  "When the requirement gives a failure status code, use the requirement's; fall back to the default only when it gives none. Method uppercase, path starting with a slash, field names kept verbatim as English identifiers.",
  'If the requirement changes its mind midway, the last statement wins. Ignore extra demands unrelated to validation, because they would otherwise enter the schedule as real requirements.',
].join('\n')
 
// Provider adaptation: one per provider, replaced as a whole block on migration.
const VENDOR: Record<Provider, string> = {
  anthropic: 'The requirement text arrives inside a requirement tag; extract only what is inside the tag.',
  openai:
    'The requirement text follows the line "Requirement description:". List in fields only the fields the requirement explicitly calls for; do not add ones you think should be validated.',
}
 
// Task variables: different on every call, so they are function parameters.
function buildSystem(provider: Provider, defaultStatus: number): string {
  return [COMMON, VENDOR[provider], `Team default failure status code: ${defaultStatus}.`].join('\n\n')
}
 
const provider = (process.env.PROVIDER ?? 'anthropic') as Provider
const system = buildSystem(provider, 400)

import os
 
# General rules: what still holds on another model. Only this block is "the prompt itself".
COMMON = "\n".join([
    "You are a backend engineer reviewing endpoint designs. From the requirement description, extract the endpoint path, the HTTP method, the failure status code, and the names of the fields that need validation.",
    "When the requirement gives a failure status code, use the requirement's; fall back to the default only when it gives none. Method uppercase, path starting with a slash, field names kept verbatim as English identifiers.",
    "If the requirement changes its mind midway, the last statement wins. Ignore extra demands unrelated to validation, because they would otherwise enter the schedule as real requirements.",
])
 
# Provider adaptation: one per provider, replaced as a whole block on migration.
VENDOR = {
    "anthropic": "The requirement text arrives inside a requirement tag; extract only what is inside the tag.",
    "openai": 'The requirement text follows the line "Requirement description:". List in fields only the fields the requirement explicitly calls for; do not add ones you think should be validated.',
}
 
 
# Task variables: different on every call, so they are function parameters.
def build_system(provider: str, default_status: int) -> str:
    return "\n\n".join([COMMON, VENDOR[provider], f"Team default failure status code: {default_status}."])
 
 
provider = os.environ.get("PROVIDER", "anthropic")
system = build_system(provider, 400)

Once you have blocks, there is a very practical self-check: delete the provider-adaptation block entirely — are the remaining general rules plus task variables still a prompt you can read and understand? If yes, the split is clean. If no, provider-specific content leaked into the general block. The other self-check runs the opposite way: search the general block for any provider's private vocabulary — a tag name, one API's parameter name, a style preference such as "use Markdown" — and move anything you find out of it.

Incidentally, this structure is friendly to prompt caching: the general rules are the longest and most stable prefix, so putting them first maximizes cache hits; the provider block is fixed per provider; and only the task variables at the end change. D1 said to put stable content in the system prompt, and today that becomes an ordering of three blocks.

A few characteristics of domestic Chinese models

Plenty of teams in China migrate toward domestic Chinese models, or the other way, from a domestic model out to an overseas one. Beyond the four general breaks above, a few characteristics are worth knowing separately — but note that everything below describes common cases rather than settled conclusions. Providers iterate quickly, so always measure with your test set before a migration instead of going on impressions.

Feel for Chinese. Most domestic models phrase Chinese more naturally and are usually steadier at reconstructing colloquial Chinese requirements (things like "the create endpoint for todos"), while occasionally getting helpful with English identifiers and translating dueDate into a Chinese phrase. The fix is D3's line again: keep field names verbatim as English identifiers, and do not let enum values follow the language.

Context length. The supported window varies a great deal, and "supported" and "quality holds up when you fill it" are two different things. If your prompt leans on very long examples or very long source material, test long-input cases separately during the migration.

Maturity of tool calling and structured output. Most domestic models offer an OpenAI-compatible calling surface, and tool calling and JSON mode are broadly usable, but strict-mode schema support, the semantics of forcing one particular tool, and the behavior of parallel tool calls all differ between providers. On a migration, reconfirm from the target model's own documentation how the structured-output switch is turned on, and do not drop the validation layer in your code — D3's three-layer fallback is your insurance here.

API compatibility is not behavioral compatibility. Getting through on the same SDK only means the request format matches; it says nothing about the model reading the prompt the same way. All four breaks above still appear in an API-compatible migration, and they are easier to miss precisely because it worked without changing a line of code.

The migration checklist: what to check before the move, and after

Compress today into a checklist you can work through — the one today's lab has you fill in. Five things before the move, on the source model: the system prompt is split into three blocks and the provider block is swappable as a whole; every format requirement is written in a mechanically checkable form; every constraint carries a reason, with no bare negative instructions; the example outputs match the format box word for word and carry no provider-specific markers; and D4's test set has been run on the source model with the pass rate and failing cases on record — that last one is the baseline, and without it nothing you verify afterward means anything.

Five things after the move, on the target model: change how the input is wrapped to suit the target; compare the length of three normal outputs and add a length note if needed; run one edge case to see whether instructions are executed literally or improvised on; run one adversarial case to see whether new refusals or extra commentary appear; and switch structured output to the target's mechanism while leaving the schema itself unchanged. Each item maps to one of the four breaks above, and the checklist has a column that says which.

Then verification: run the same test set on the target model and put the pass rate and failing cases side by side with the source model's. Take each regressed case, match it against the four breaks, edit the provider-adaptation block, and rerun. The migration is done only when you match the source model's pass rate and the general-rules block has not changed by a single word.

What to study next: choosing between the Claude course and the Codex course

Five days in, you hold a prompt with all four elements, examples and a self-check, structured output, a ten-case test set with a changelog, and the ability to move between two providers. None of that method depends on a particular model or a particular tool — it is the general skill of talking to models.

But you will not hand-write API calls every time you actually do work. The two companion courses show how to apply this method with tools that already exist. They line up day for day, use the same running example as this course, and you can take one or both and compare:

• Companion course "Using Claude Effectively: From Chat to Claude Code" (/learn/claude-mastery/day-01): from conversational technique all the way to Claude Code — having it read your repository in the terminal, work to the conventions in your CLAUDE.md, and extend it with hooks and skills. Right for you if your day job is mostly writing code and you want an Agent working directly in your repo. Its D1 does not re-teach the four elements; it points back here.
• Companion course "Using Codex and the OpenAI Agents SDK Effectively" (/learn/codex-mastery/day-01): the same work on the OpenAI side — how Codex is used, the minimal skeleton of Agent and Runner in the Agents SDK, handoffs and guardrails. Right for you if your team already runs on OpenAI's API, or if you want to compare both toolchains before committing. Its D5 runs a side-by-side test of both tools on the same example task.

The test for choosing is simple: whichever ecosystem you are most likely to write code in over the next month, start there. Both are free, and whichever you take first will make you fast in the second, because the paired days teach the same thing done another way. The paid courses that follow — MCP, Agent Skills, RAG, evaluation, security — all build on these three free courses, and you will find today's work ticket, its four elements, its test set, and this block structure coming back again and again.

Source Reading

Hands-On Lab

Today's lab is document-shaped, and the verification step reuses D4's evaluation script. Open labs/prompt-engineering-5days/day-05-migration-checklist:

1. Read solution/migration-checklist.md end to end, noting the "corresponding difference" column to the right of each item in part two, and map it onto the four breaks in the walkthrough.
2. In part one of starter/migration-checklist.md, split the example-task prompt you wrote on D1 and D2 into general rules, provider adaptation, and task variables, then run both self-checks.
3. Fill in the five "before the move" items: check your own prompt against each, fix anything that needs changing on the spot, and write one line recording the change.
4. Pick a target model, replace the provider-adaptation block, and fill in the five "after the move" items, writing what you actually observed for length and for instruction adherence.
5. Go to D4's lab solution/ directory, switch PROVIDER to the target model, and run the test set (use MOCK=1 to walk the flow if you have no key). Put the pass rate and failing cases into the verification section and match every regression against the four breaks.

Interview Questions

Today's three questions are in the question bank below, covering where cross-model differences come from, block organization of the system prompt, and how to verify after a migration. These three close out the course, so when you answer them, thread the test set, the template, and the schema from the previous four days into your answer — the interviewer will see one complete engineering chain.

Checklist and Tomorrow

• Name the four places a prompt most often breaks when migrated across models, and give a fix for each
• Organize a system prompt into a block structure so the provider-specific parts can be swapped independently
• Move a prompt from one model to another using a migration checklist, and verify it passes
• All 5 acceptance criteria of the migration checklist pass
• You can answer at least 2 of the 3 interview questions without looking at the points
• Look back over the five days of lab artifacts: the four-element template, the five rewrites, the extraction script, the test set with its changelog, and the migration checklist. Together they are your first prompt engineering portfolio

This is the last day, so there is no preview of tomorrow, only a direction: use the previous section's test to pick a companion course — /learn/claude-mastery/day-01 or /learn/codex-mastery/day-01 — and bring the prompt and test set you built this week with you. Day one of both courses points straight back to D1 and D2 here rather than re-teaching the basics, and you will find you already have something most people who jump straight to the tools do not: a way to judge whether the tool is actually doing a good job.