Multi-Model Workflows: Draft in One, Edit in Another

TL;DR: A multi-model workflow means drafting in one AI model and editing in another, routing each step to whichever model is actually good at it. The catch: token-cap names, penalty defaults, context placement, and even chain-of-thought advice differ by vendor and change within weeks. Below is the field map and the routing rules that actually transfer.

You draft the first pass of a report in one model because it writes clean structure. You paste that draft into a different model to tighten the prose, because that one is better at cutting filler. Maybe a third model turns the final text into a slide outline. This is a multi-model workflow, and it is quietly how a lot of serious AI users already work: nobody claims one vendor is best at everything, so they don't ask one vendor to do everything.

The part that trips people up isn't the idea. It's the handoff. The instructions you wrote for the first model rarely fail in the second one, because plain-language instructions travel fine. What fails, silently and without an error message half the time, are the API-level details: the parameter you set to control length, the position you put your reference material in, the assumption that "think step by step" still helps. Those are not universal facts about AI. They are vendor-specific facts about API contracts, and the contracts disagree with each other more than most guides admit.

Why does one token limit have four different names?

Because there isn't one token-limit parameter. There are at least four, across three vendors, and they are not interchangeable field names for the same thing.

OpenAI's Chat Completions endpoint has two: max_tokens, which the API's own specification marks deprecated: true and states "is not compatible with o-series models." max_completion_tokens is the current replacement. OpenAI's newer Responses API uses a third name, max_output_tokens, which carries a minimum value of 16 in the specification — you cannot set it lower even if you wanted a very short reply. OpenAI's legacy Completions endpoint still has its own max_tokens with a default of 16, a third distinct meaning under the same field name. Anthropic's Messages API uses max_tokens. Google's Gemini API uses maxOutputTokens.

Every one of these caps output only. None of them trims your prompt. And on both OpenAI and Anthropic, thinking or reasoning tokens are billed against that same ceiling: OpenAI's reasoning guide defines the cap as covering "reasoning tokens, visible output tokens, and non-visible formatting tokens" together, and Anthropic's Messages API reference states that extended thinking "counts towards your max_tokens limit." Google is the outlier here — it tracks thinking tokens in a separate counter and does not state as clearly whether maxOutputTokens alone can be exhausted before any visible text appears, so don't assume Google behaves the same way.

If you're building a template that gets reused across models, the practical move is to name the field per vendor rather than writing one generic token-limit instruction and hoping it copy-pastes cleanly.

Do frequency and presence penalties travel between vendors?

Not consistently, and this is the parameter pair most likely to silently do nothing when you move a prompt.

OpenAI documents frequency_penalty and presence_penalty with a numeric range of -2.0 to 2.0 and a default of 0 in its API specification. Anthropic's Messages API reference has zero occurrences of either term — the parameters simply don't exist there, so a config object copied from OpenAI and sent to Anthropic will just have those keys ignored or rejected depending on the client library. Google's Gemini API does define frequencyPenalty and presencePenalty as fields, but its own reference publishes no numeric range and no default for either — so if you've seen a specific recommended value for Gemini's penalties somewhere, it did not come from Google.

Whether reasoning models honor these penalties at all is genuinely undocumented on OpenAI's side — its reasoning guide has zero occurrences of the word "penalty," in contrast to stop, which OpenAI explicitly flags as unsupported on certain models (more on that below). Don't guess an answer here; say plainly that it isn't documented.

Where should long context actually go in the prompt?

Depends which vendor you ask, and the two answers are opposites.

Anthropic's prompting guidance is explicit: "Place your long documents and inputs near the top of your prompt, above your query, instructions, and examples." It adds that "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 for long-context work: "supply all the context first", with specific instructions or questions placed "at the very end of the prompt." Google's own Gemini 3 developer guidance repeats the identical ordering for large datasets.

OpenAI's current prompt-engineering guide says the opposite for the general case: added context "is usually best positioned near the end of your prompt," on the reasoning that you may swap in different context for different requests while keeping the rest of the prompt fixed.

Neither side is wrong for its own model family; this is a genuine, sourced disagreement, not a case where one vendor forgot to update a page. Pick your placement per vendor, and don't average the two into a compromise that matches neither.

Should you tell a model to think step by step?

On OpenAI's reasoning models, no. OpenAI's guidance says plainly that because these models reason internally, prompting them to "think step by step" or "explain your reasoning" is unnecessary. Google's current Gemini 3 migration guidance points the same direction for its own reasoning-capable models, telling anyone who was "previously using complex prompt engineering (like chain of thought)" to switch to setting a thinking_level parameter and simplifying the prompt instead.

Anthropic is the interesting exception, and it's a genuinely useful one for a multi-model workflow. Anthropic's adaptive-thinking models don't just decide on their own whether to think. Anthropic states plainly: "The triggering behavior for adaptive thinking is promptable." Its prompting guide gives sample wording for both directions: a prompt that encourages the model to reflect before acting after a tool call, and a separate prompt that tells it thinking "should only be used when it will meaningfully improve answer quality" if it's thinking more than you want.

So the same instinct — add a line nudging the model's reasoning behavior — is documented as unnecessary on one vendor's models and documented as a supported lever on another's. A workflow that drafts on one and edits on the other needs to know which rule applies where, not one rule borrowed from whichever vendor you read about first.

Why did my stop sequence silently keep going?

If the step you moved to a new model runs on OpenAI's o3 or o4-mini, this is expected, not a bug in your prompt. OpenAI's own OpenAPI specification is direct about it: "Not supported with latest reasoning models o3 and o4-mini." That sentence is not in OpenAI's prose documentation or its reasoning guide — it lives only in the specification's StopConfiguration description, which is a 3-megabyte YAML file most people never open.

This is a useful general lesson for anyone chaining models together: a vendor's prose docs and its machine-readable spec don't always say the same things, and the spec sometimes carries constraints the docs never mention at all. When a workflow step behaves differently than the guide you read said it would, check the spec before you check your own prompt.

A draft-in-one, edit-in-another template you can reuse

The instructions below are the part that should travel unchanged between models. Keep the per-vendor parameters (token cap field name, penalty support, stop sequences) in a separate block you swap out per API call, rather than baking them into the instruction text itself.

### DRAFT PASS (model chosen for structure and coverage)
Task: Draft a [document type] covering [topic].
Cover exactly these sections, in this order: [list].
Do not polish prose at this stage. Flag any section where you are guessing
rather than working from supplied facts, using the marker [UNVERIFIED].
Length target: [N] words, approximate.

### HANDOFF NOTE (paste this plus the draft into the second model)
The text below is a first draft from another model. Do not regenerate it
from scratch. Edit for: clarity, removing repeated points, and tightening
any sentence over 25 words. Preserve every [UNVERIFIED] marker exactly as
written — do not resolve or remove them. Return the full edited document,
not a diff or a summary of changes.

<draft>
[paste draft here]
</draft>

### FACT-CHECK PASS (model chosen for citation and verification, optional third step)
Read the document below. List every claim that includes a number, a date,
or a named source. For each, state whether it is directly supported by
material I have provided, or whether it needs an external check before
publication.

The instruction text ports cleanly. What doesn't port is the surrounding API call: the token-cap field name, whether a penalty parameter does anything, and where you'd place a long reference document if one is attached to the fact-check pass. Handle those per vendor, using the tables above, rather than assuming last week's settings still apply.

How fast does this information actually go stale?

Fast enough that naming a specific model in permanent documentation is a small liability. In the same week this post was checked, Google's flagship Flash model moved from version 3.7 to 3.8, and the Gemini 3 developer guide quoted above now carries its own deprecation notice, pointing readers to a newer guide for the current generation. None of the underlying mechanics changed — the placement advice and the migration guidance were consistent across both versions of the page — but the specific page and model name did.

The practical habit: cite behavior, such as which family defaults its thinking to on, rather than a version number, wherever you can avoid it. Where you do need to name a model, date the claim. A reader six weeks from now should be able to tell whether your fact is still current from the date next to it, without needing you to have predicted the vendor's release schedule.

The short version

Multi-model workflows work because the instructions travel and the API contracts don't. Draft in the model that's good at structure, edit in the model that's good at prose, fact-check in whichever one you trust with citations — but keep the token-cap field name, the penalty support, the context placement, and the chain-of-thought advice as a separate, per-vendor checklist rather than folding them into the prompt you copy-paste everywhere. The four token-cap names alone are worth writing down once so you stop rediscovering them mid-project. Save that checklist as a template and the next handoff between models takes minutes instead of a fresh round of debugging.