Write a cost-aware system prompt

---name: cost-aware-system-promptsdescription: "Write or review a system prompt that does not quietly multiply the bill — bounded output, no re-sent bulk, tool schemas counted as the input tokens they are. Use when authoring or reviewing a system prompt, when cost per turn is climbing, or when adding tools to an agent."license: MITmetadata:  title: "Write a cost-aware system prompt"  version: 1.0.0  author: lobstack  category: cost  tags: [cost, prompting, agents, tokens]--- # Write a cost-aware system prompt A prompt is a recurring charge. Everything in it is re-sent on every turn of everyconversation, so a paragraph you added once is billed thousands of times, and theusual review — does it produce good output — never looks at that. Four facts about pricing decide most of this, and all four are checkable againstthe model catalogue rather than being rules of thumb. ## Fact 1: output costs several times input Across almost the whole registry, output tokens are priced four to five timesinput. claude-opus-5 is $5 in and $25 out per million; claude-sonnet-5 is$2 and $10; gemini-3.8-flash is $0.75 and $3.75. So the highest-leverage sentence in any prompt is the one that bounds the answer,and max_tokens is the highest-leverage parameter. ```Answer in at most three sentences. No preamble, no summary of the question,no offer of further help. If the answer is a single value, return the value.``` That is not a style preference. Removing "Great question! Let me help you withthat." from every response of a busy endpoint is a real line on an invoice. Be specific about the shape you want, because a model that does not know theshape hedges, and hedging is output tokens: "return JSON matching this schema,nothing else" costs a fraction of "explain your reasoning and then give theanswer". ## Fact 2: the system prompt is billed per turn, not per session There is no per-conversation discount. A 900-token system prompt on a 40-turnconversation is 36,000 input tokens spent restating instructions the model hasalready followed 39 times. Review a prompt by asking, of every paragraph: *does the model's behaviour changeif I delete this?* Delete anything where the answer is no. The usual finds: - Politeness instructions the model already follows.- Long "you are an expert…" preambles that change nothing measurable.- Repeated instructions, in different words, added by different people.- Examples that duplicate each other. Two well-chosen examples beat six.- Prohibitions on things the model was never going to do. Move anything long, conditional and rarely needed *out* of the system prompt: areference file the agent reads when it needs it costs nothing on the turns whereit does not. That is the whole argument for progressive disclosure, and it is acost argument as much as an attention one. ## Fact 3: tool schemas are input tokens Every tool definition — name, description, full JSON Schema — is serialised intoevery request that has tools enabled, whether or not any tool is called. Twentytools with verbose parameter descriptions is a fixed tax on every turn. - Enable the tools this agent actually needs, not the catalogue.- Keep parameter descriptions to one line each.- Prefer one tool with a mode parameter to five near-duplicates.- If a tool has never been called in production, delete it. ## Fact 4: "think step by step" is a purchase order Instructions that ask for visible reasoning buy output tokens at the output rate,and reasoning-heavy phrasing also pushes the router's complexity score up a tier.Sometimes that is exactly what you want on a hard task. It is rarely what you wanton the easy 80% of traffic. If you need reasoning but not the reader's copy of it, ask for the conclusion andkeep the working private to the model where the model supports that — do not askfor a written chain of thought you then discard, which is paying for tokens youthrow away. ## Cheap models want more explicit prompts Tier and prompt are one decision, not two. A nano or small model will follow anexplicit, structured instruction and will quietly ignore an implication. So whenyou move a call site down a tier: - Turn implications into imperatives. Not "keep it brief" but "at most 40 words".- Enumerate the allowed outputs. Not "categorise" but "return exactly one of:  billing, bug, feature".- Put the format last. It is the instruction most often lost.- State what to do when the input does not fit — otherwise it invents something. This is why the cheap tier so often "fails" on a first attempt: the prompt waswritten for a model that was covering for it. ## A review checklist Run this over any prompt before it ships: - [ ] Is the output bounded, in words and by max_tokens?- [ ] Would deleting each paragraph change behaviour? Delete the ones that would not.- [ ] Is anything long, conditional or rarely needed inline that could be a file read on demand?- [ ] Are only the needed tools enabled, with one-line parameter descriptions?- [ ] Is bulk context (whole files, full histories, entire tables) being re-sent every turn?- [ ] Is visible reasoning requested? Is it read by anyone?- [ ] Are the allowed outputs enumerated, so a cheaper tier can hold the call site? ## Measure it, do not argue about it Run the same twenty real inputs through the old and new prompt and comparex_lobstack.cost_usd per turn plus your own quality check. The Gateway pricesevery call, so this is a measurement rather than an opinion — and a prompt changethat saves 30% per turn with no quality change is the cheapest optimisationavailable to any LLM product. ## Do not - Do not put a rate card, a price table or a model list in a system prompt. It  goes stale and it is billed forever. Read it from the API.- Do not paste an entire file when a section answers the question.- Do not add a paragraph to fix one bad output. Fix it with an example or a  bounded instruction, then delete the paragraph.