Your prompt starts the meter, but the answer often drives the bill. Generated tokens commonly carry a higher unit price than input tokens, and an open-ended request can produce far more text than your application needs. This sprint walks through measuring that cost, tightening the response contract, and checking that the savings do not break the result.
1. Calculate the output share before changing prompts
Start with the usage record from a completed request. Separate input tokens, output tokens, and their applicable rates. For straightforward text billing, the calculation is input tokens multiplied by the input rate, plus output tokens multiplied by the output rate. Match the units: rates quoted per million tokens require dividing token counts by one million.
For a hypothetical example, assume 4,000 input tokens at $1 per million and 2,000 output tokens at $4 per million. Input costs $0.004; output costs $0.008. Output accounts for about two-thirds of the $0.012 total, despite containing half as many tokens. These are illustrative rates, not a SwiftRelay price quote.
2. Identify the requests that generate unnecessary text
Review a representative sample of real tasks, including unusually expensive ones. Record the task type, model, output token count, completion status, and whether anyone used the full response. Look for repeated introductions, copied source material, excessive explanations, and entire files returned when a small patch would suffice.
Do not assume output always dominates. Large document inputs, cached-input pricing, reasoning charges, and tool-related charges can change the breakdown. Check the model’s billing rules and usage fields rather than estimating cost from visible answer length alone.
3. Give each task an explicit response contract
Replace “explain this thoroughly” with a deliverable your application can consume. For a support draft, request one answer paragraph and three troubleshooting steps. For classification, request the category and a short justification. For code review, request only actionable findings, each with a file location and proposed fix.
- Define scope: answer the requested question without restating the supplied context.
- Define structure: specify the fields, bullet count, or sections you actually need.
- Define exclusions: omit greetings, repeated instructions, and unrequested alternatives.
A concrete contract is more dependable than simply asking the model to “be concise.” Keep required warnings and uncertainty statements; removing useful information is not an optimization.
4. Set an output ceiling with room to finish
Use the output-limit parameter supported by your chosen model and API endpoint. Parameter names and semantics differ, so check the relevant documentation rather than copying one setting across every integration. Where reasoning tokens share that allowance, leave enough room for both reasoning and the visible response.
Choose a ceiling based on successful examples, not the smallest number that looks inexpensive. Inspect completion status and validate structured responses. A truncated answer that triggers another full request can erase the savings. Treat the ceiling as a guardrail, not a substitute for a clear prompt.
5. Make additional detail a separate decision
For interactive workflows, return the useful core first and let the user request expansion. A document assistant might provide five findings, then generate supporting passages only for a selected finding. A coding assistant can return a focused patch rather than reproducing unchanged files.
This works when the initial response is independently useful. Avoid splitting an inherently complete deliverable into mandatory follow-up calls: repeated context and additional generation can increase total cost.
6. Test the same task through SwiftRelay
SwiftRelay provides pay-as-you-go, per-token access to models including Claude Sonnet 5.5. Sign up for SwiftRelay to test a small batch with the gift credit available to new accounts. OpenAI-compatible SDKs use https://api.fastapirelay.com/v1; Claude Code and Gemini CLI take the bare host, https://api.fastapirelay.com.
Keep the task set fixed while testing prompt revisions. Record actual billed usage and task success, and use current model rates rather than assuming every generated token costs the same.
7. Keep the lowest-cost complete answer
Compare cost per accepted result, not just tokens per response. Include retries, repairs, and required follow-ups. Keep a revision only when it preserves correctness and usability. The finish line is less unnecessary generation, not less useful work.