Cheap Drafts First, Expensive Polish Last

Not every stage of an AI task needs the same model. Outlining, exploring alternatives, and producing a rough draft often tolerate mistakes that would be unacceptable in the finished result. Spend less while the work is provisional, then reserve a more expensive model for a focused final pass. This walkthrough uses a technical article as the example, but the same pattern works for reports, documentation, and customer communications.

§ Step 1: Define what a finished result must satisfy

Before making a request, write a short acceptance checklist. Specify the audience, required facts, length, format, and conditions that would make the output unusable. This checklist becomes the shared contract for both drafting and review.

• Audience: developers integrating an API for the first time.
• Required content: authentication, one request example, and error handling.
• Constraints: no unsupported claims, no invented parameters, and a clear sequence of actions.

Keep authoritative source material separate from instructions. A final reviewer needs to distinguish verified facts from wording that an earlier model merely proposed.

§ Step 2: Choose two roles, not a complicated routing system

Start with one drafting model and one finishing model. Gemini 2.5 Flash and Claude Opus 5.5 are candidates to evaluate for those respective roles. Check the available rates and test representative tasks before deciding: a higher price does not automatically mean a better result for your workload.

Vana API provides one OpenAI-compatible endpoint, so an OpenAI SDK integration can keep the same connection setup while selecting different models for separate requests. Keep the model choice configurable rather than embedding it throughout your application. Create a Vana API account to try this workflow with a small, representative task.

§ Step 3: Explore cheaply before writing at length

Ask the drafting model for a compact outline and a list of unresolved questions. Do not request three complete articles when three short outlines would expose the same structural choices.

Example instruction: Produce two outlines that satisfy the checklist. Identify missing source information. Do not invent details or write the full article yet.

Select one direction yourself, or use explicit criteria to choose. Resolve factual gaps before drafting. Passing uncertainty downstream without labeling it gives the final model more material to misinterpret.

§ Step 4: Build one draft and repair obvious defects

Generate a single draft from the selected outline, the source material, and the acceptance checklist. Use the drafting stage to fix inexpensive problems: missing sections, repeated explanations, excessive length, or incorrect ordering.

Where possible, check mechanical requirements outside the model. Count words, validate required fields, and test code examples in an appropriate environment. These checks are more dependable than asking a model whether its own output looks correct.

Set a small revision limit. Two targeted repairs may be useful; an open-ended conversation can consume the savings this workflow was designed to create.

§ Step 5: Hand over a compact review packet

Send the finishing model only what it needs: the current draft, authoritative references, the checklist, and clearly labeled unresolved issues. Do not forward every discarded outline and intermediate conversation.

Example instruction: Review this draft against the checklist and supplied references. Correct reasoning gaps, remove unsupported claims, and improve clarity. Preserve verified facts. If a necessary fact is missing, flag it rather than guessing. Return only the revised article.

This makes the expensive pass a bounded editing task instead of a second attempt to discover the assignment.

§ Step 6: Validate before accepting the result

Run the same mechanical checks again. Review factual changes against the references, especially new examples, numerical claims, and API details. A polished sentence is not evidence that its contents are correct.

If the final output fails a check, request a narrow correction rather than restarting the whole process. For high-impact material, retain human approval as the final gate.

§ Step 7: Measure the complete workflow

Track input tokens, output tokens, retries, latency, and acceptance rate across all calls. Compare the total with a baseline that uses the finishing model alone. Cheap drafts are worthwhile only when they reduce total cost without creating unacceptable review work.

Vana API bills per real token with no monthly fee. Include every drafting and revision call in your comparison. The goal is not the cheapest individual request; it is the lowest practical cost for an accepted result.