How to Port a Prompt from One Model to Another

TL;DR: Porting a prompt between models rarely breaks on the wording. It breaks on the parameter surface around it: token-limit fields have four different names across three vendors, penalties only exist on some APIs, vendors give opposite advice on where long context goes, and reasoning models silently reject or ignore parameters that worked fine on a chat model. Here's what actually changes, sourced from each vendor's own docs.

You write a prompt against GPT-4.1, it works, and six months later you're running the same request against Claude or Gemini because a client asked for it, a rate limit hit, or a newer model looks better for the job. The prose survives the move almost every time. What quietly breaks is everything around it: the field names in your request body, where the vendor expects your long context to sit, and whether the parameters you tuned even mean anything once you're pointed at a reasoning model instead of a chat model.

Why does the same prompt behave differently on another vendor?

Because a prompt is never just the words. It travels inside a request shape, and that shape is where vendors actually disagree. Three surfaces cause almost all of the real breakage when you port a prompt: the token-cap field, the sampling and penalty parameters, and the placement convention for long context. A fourth, whether the target model reasons before answering, changes what all three of the others do.

None of this shows up as an error most of the time. A request with the wrong field name for your token cap doesn't fail to parse, it just gets ignored or silently rejected depending on the vendor, and you find out when the output truncates somewhere you didn't expect. If you've never laid the three vendors' request shapes side by side, our LLM parameter cheat sheet is the reference version of what this post walks through with the porting problem in mind.

What happens to your token limit when you port a prompt?

This is not a two-way split. It's four field names across three vendors, and every one of them caps generated output only, never your prompt.

The deprecation note on OpenAI's older field is explicit in its own OpenAPI spec: max_tokens "is now deprecated in favor of max_completion_tokens", the spec continues, and separately states the old field is not compatible with o-series models. If you're porting an old Chat Completions prompt built years ago, that field name alone is worth checking before anything else.

The reasoning-token point matters more than it looks. OpenAI's reasoning guide states plainly that you can "limit the total number of tokens the model generates, including reasoning tokens, visible output tokens, and non-visible formatting tokens, by using the max_output_tokens parameter" on its Responses API. Anthropic's docs describe the same mechanism for its own max_tokens: enabling extended output "counts towards your max_tokens limit." A budget that felt generous on a chat model can starve a reasoning model of room to answer at all, because the same ceiling now has to cover thinking it never had to do before. Google is the outlier worth flagging rather than guessing about: it tracks thinking tokens under a separate thoughtsTokenCount, and its docs don't state whether maxOutputTokens can be exhausted by thinking before any visible text appears.

Do frequency and presence penalties travel with your prompt?

Only if you're porting to or from OpenAI. frequency_penalty and presence_penalty are OpenAI-lineage parameters, ranging -2.0 to 2.0 with a default of 0 in its own OpenAPI spec. Search Anthropic's Messages API reference for either term and you get zero occurrences; they are not deprecated there, they simply don't exist as concepts in that API.

Google's API does define frequencyPenalty and presencePenalty fields, but its reference publishes no numeric range and no default for either. Porting a value like 0.4 across from an OpenAI prompt is porting a number Google's own docs never validate as sensible, high, or safe.

Where should long context go when you port a prompt?

Here vendors give opposite advice, and it's worth stating plainly as a real disagreement rather than resolving it in either direction.

Anthropic's prompting guide is explicit: "Place your long documents and inputs near the top of your prompt, above your query, instructions, and examples. This improves performance across all models." A note attached to that same guidance adds a number: "Queries at the end can improve response quality by up to 30 percent in tests, especially with complex, multidocument inputs." Google's Gemini prompting guide gives the same shape of advice for a different reason: for large input blocks like documents or code, "supply all the context first. Place your specific instructions or questions at the very end of the prompt."

OpenAI's own prompt-engineering guide says the reverse for its own models: added context "is usually best positioned near the end of your prompt, as you may include different context for different generation requests."

So a prompt with a 10,000-word document pasted at the top, question at the bottom, tuned and working well on Claude or Gemini, is structured backward by OpenAI's own stated preference if you port it to GPT without rearranging it. None of the three vendors reference the others' guidance; this is not a case where one is outdated and the rest agree.

Does the stop parameter port cleanly?

Mostly, with one sharp exception that's easy to miss because it isn't written where you'd look for it. OpenAI's Chat Completions API allows up to 4 stop sequences. Google's stopSequences field description reads in full: "The set of character sequences (up to 5) that will stop output generation." Anthropic's stop_sequences carries no documented count limit at all in its API reference.

The exception: OpenAI's own OpenAPI specification, under the StopConfiguration schema for stop, reads: "Not supported with latest reasoning models o3 and o4-mini." That sentence exists only in the machine-readable spec. It is not in the prose reasoning guide, not in the Chat Completions guide, nowhere a person reading the documentation top to bottom would naturally land on it. A prompt that relies on a stop sequence, ported onto o3 or o4-mini without checking the spec directly, will not behave the way it did on the model you built it against.

# Before porting a prompt that sets `stop`, check the target model class:

OpenAI Chat Completions, non-reasoning model  → up to 4 sequences, works
OpenAI o3 / o4-mini                          → unsupported per OpenAI's own OpenAPI spec
Google Gemini (stopSequences)                → up to 5 sequences, works
Anthropic (stop_sequences)                   → no documented count cap

What happens to temperature and top-p on a reasoning model?

This is where porting a prompt across to a reasoning model breaks the most silently, because each vendor handles it differently and none of them error the same way.

Anthropic is the strictest and the most explicit about it. Its docs state plainly that its newest models "do not accept top_k; any value will be rejected with a 400 error." A separate field description covers the other parameter: "do not support setting top_p. A value >= 0.99 will be accepted for backwards compatibility, all other values will be rejected with a 400 error." Temperature gets the same treatment: only 1.0 is accepted for backward compatibility on the newest models, anything else returns a 400.

Google takes the advisory route instead of a hard error. Its Gemini 3 docs state: "For all Gemini 3 models, we strongly recommend keeping the temperature parameter at its default value of 1.0". The same page goes on to warn: "Changing the temperature (setting it below 1.0) may lead to unexpected behavior, such as looping or degraded performance, particularly in complex mathematical or reasoning tasks." No error, just a warning that a value tuned for a chat model can quietly degrade a reasoning one.

OpenAI's current reasoning guide is the hardest case to reason about, because it's silent rather than either strict or advisory: the guide has zero occurrences of the words temperature, top_p or sampling. That is not the same thing as reasoning models rejecting temperature, a piece of folklore this guide does not support one way or the other. If a porting checklist tells you OpenAI reasoning models reject sampling parameters, that specific claim is not sourced from OpenAI's own current documentation.

Temperature and top-p tuned for one vendor's chat model, in short, is a parameter set you should re-verify rather than carry over, every time the destination is a reasoning model. Our temperature, top-p and top-k guide covers what each one actually does if you need the mechanics before deciding whether to port a value at all. For the fuller picture across all seven vendors we've checked this against, our reasoning-models guide goes deeper than this post's scope.

Can you control whether a model thinks, or how much?

Only one vendor documents this as something you can steer through the prompt itself. Anthropic states plainly: "The triggering behavior for adaptive thinking is promptable." It goes on to give guidance for cases where a model thinks more than you'd like, particularly with large or complex system prompts.

OpenAI's and Google's current guides offer nothing equivalent. If you've written a Claude prompt with specific wording that discourages unnecessary thinking on simple turns, that wording has nowhere to port to on the other two; there is no documented prompt-level thinking control to move it into. The parameter-level controls (reasoning.effort on OpenAI, thinking_level on Google) are the closest equivalents, but they're request fields, not prompt wording, and none of the three vendors expose the same lever in the same place. Why Claude and ChatGPT diverge on requests like this goes further into this specific asymmetry.

A worked example: porting one request across three vendors

Take a prompt that sets a 500-token output cap, a stop sequence, and a low temperature for consistency, built originally for OpenAI's Chat Completions API:

{
  "model": "gpt-4.1",
  "max_tokens": 500,
  "stop": ["\n\n"],
  "temperature": 0.2
}

Ported field-for-field to the other two vendors, without adjustment:

// Anthropic — max_tokens survives, temperature 0.2 is fine on Haiku 4.5
// but returns a 400 on newer models where only 1.0 is accepted.
{
  "model": "claude-sonnet-5",
  "max_tokens": 500,
  "stop_sequences": ["\n\n"]
}

// Google — the field is maxOutputTokens, not max_tokens; stop_sequences
// becomes stopSequences; temperature 0.2 works but Google's own guidance
// recommends leaving Gemini 3 at its default of 1.0.
{
  "model": "gemini-3.1-pro",
  "generationConfig": {
    "maxOutputTokens": 500,
    "stopSequences": ["\n\n"],
    "temperature": 0.2
  }
}

Nothing in that example is exotic. It's the ordinary shape of a prompt anyone would actually write, and every one of the three field-name changes, plus the temperature question, is exactly the kind of thing that fails silently rather than throwing an obvious error you'd notice on the first test call.

Where a prompt tool actually helps here

None of the parameter-surface differences above are things a prompt manager fixes for you; they're genuine, vendor-published differences in what each API accepts, and no tool changes what OpenAI, Anthropic or Google's servers will do with a request. What Prompt Architects is built for is the part underneath that: keeping one prompt's wording as a single reusable source, with variables for the parts that actually change per platform, instead of maintaining separate half-drifted copies per vendor by hand. The free plan includes 5 prompt enhancements per day, forever, per our FAQ page, enough to test whether a single saved prompt with per-platform notes beats the copy-paste-and-hope approach most people are running today.

The porting problem gets worse, not better, as more reasoning models ship, because reasoning is exactly the axis where vendors currently disagree most: whether it's promptable, whether sampling parameters still apply, whether your token cap has to cover thinking you never used to pay for. None of that is going to converge on its own; it's worth re-checking a prompt's parameter surface every time you move it, not just the first time.