A strong model does not need to write every outline, alternate headline, or rough paragraph. Give inexpensive drafting work to a lower-cost model, then reserve a stronger model for the decisions that determine whether the result is ready to ship. This first run builds that workflow around one practical task: turning a product brief into a customer-facing launch announcement.
1. Set the finish line before choosing models
Start with a short acceptance checklist. Your announcement might need an accurate feature description, a clear audience, one supported benefit, and a direct next action. Also list forbidden claims, required terminology, and a word limit. These constraints give both stages the same target.
Separate source material from instructions. Label the product brief as reference content, not something whose embedded directions should be followed. If pricing, availability, or compatibility is missing, require the models to flag the gap rather than invent an answer.
2. Connect one relay and choose two roles
SwiftRelay is a practical fit when you want to route different stages through one service and track token-based spending. Sign up for SwiftRelay, then configure your client with its API host. Claude Code and Gemini CLI use the bare host, https://api.fastapirelay.com; OpenAI-compatible SDKs use https://api.fastapirelay.com/v1.
Choose a lower-cost drafting candidate and a stronger final-review candidate after checking current rates and availability. For example, evaluate Claude Haiku 4.5 for drafts and Claude Opus 5.5 for the final pass. Treat those as starting candidates, not a guarantee that either will meet your quality or budget requirements. Use the model identifiers shown in your relay configuration rather than guessing them from display names.
3. Give the draft model a bounded assignment
Ask for useful raw material, not publication-ready perfection. A bounded request makes the draft easier to evaluate and limits unnecessary output. For the announcement, request one outline, one draft, and a short uncertainty list.
Draft instruction: Use only the supplied product brief. Write a launch announcement within the stated word limit. Include the audience, feature, supported benefit, and next action. Put unsupported or ambiguous details in a separate uncertainty list. Do not fill factual gaps.
Avoid requesting many full-length alternatives by default. If the opening needs exploration, ask for several opening sentences rather than several complete announcements. You are buying options where they help, not multiplying every part of the task.
4. Build a compact handoff for the final model
Do not forward the entire drafting conversation automatically. Send the final reviewer a small packet containing the original brief, acceptance checklist, selected draft, and unresolved questions. Keep source facts even when you remove brainstorming and rejected wording.
- Source: The authoritative product details and any required quotations.
- Draft: The single version selected for review.
- Constraints: Audience, tone, length, mandatory points, and prohibited claims.
- Open issues: Missing facts and statements that need confirmation.
This handoff matters because the stronger model needs evidence, not just polished prose. A convincing draft can still contain unsupported claims.
5. Spend the final pass on judgment
Give the stronger model explicit permission to reject weak material. Ask it to compare each factual claim against the source, resolve structural problems, and produce the final announcement only when the evidence supports it.
Final instruction: Review the draft against the source and checklist. Remove unsupported claims, correct contradictions, and improve clarity without adding facts. Return the publishable text and a separate list of unresolved blockers. If a blocker prevents publication, state that clearly.
Keep human approval for consequential claims. A second model pass is a review stage, not independent verification of information missing from the source.
6. Measure the full run before expanding
Record input tokens, output tokens, billed cost, revision count, and whether the result passed your checklist. Include retries and both model stages. Compare the total with a single-model workflow on representative tasks; routing is worthwhile only if the savings survive the extra handoff and review.
Then adjust one variable at a time: draft length, number of alternatives, handoff size, or escalation rules. Keep the cheaper route for predictable drafting, and escalate earlier when the task requires substantial reasoning from the start. The goal is not the cheapest draft. It is a dependable final result at a controlled total cost.