How to ask a model so it answers well, and does not bill you twice

The third stop on my AI roadmap is where you first talk to a model from your own code. The call itself is a few lines. What takes real learning is everything around it: phrasing the request so the answer is reliable, getting output your code can actually use, and not quietly paying several times over for the same tokens. This stop is those three things.

Briefing a fast assistant who only knows what you tell it

The frame that makes prompting click: a model is a very capable assistant with no memory of you, no context about your project, and a habit of taking instructions literally. Every call, you are handing them a fresh brief. A vague brief gets a vague answer. A brief that says who they are, what the task is, what a good answer looks like, and the shape you want it in gets a good one.

That brief is split into two parts in every API:

• The system prompt sets the role and the standing rules: “You are a support assistant for a bike shop. Answer only from the provided policy. If unsure, say so.”
• The user prompt is the actual request for this call.

const reply = await client.messages.create({
  model: "a-current-model",
  system: "You are a support assistant. Answer only from the policy below. If unsure, say so.",
  messages: [{ role: "user", content: `Policy: ${policy}\n\nQuestion: ${question}` }],
})

You call this through the provider’s SDK, a small library that wraps the raw web API so you are not hand-building requests. In TypeScript the common ones are the provider SDKs and the Vercel AI SDK, which works across providers.

The four prompt habits that fix most bad answers

Prompting has a lot of folklore. Four habits cover the bulk of it.

1. Give the role and the rules up front, in the system prompt, once.
2. Show examples, called few-shot: two or three input-and-ideal-output pairs teach the shape of a good answer far better than describing it.
3. Ask for a structured output. If your code needs to read the answer, do not ask for prose and parse it. Ask for JSON matching a schema, so the reply is data your program can trust.
4. Say what to do when unsure. “If the answer is not in the text, reply with NOT_FOUND” turns a hallucination into a handled case.

// ask for a fixed shape instead of free text
const schema = { name: "string", price: "number", inStock: "boolean" }
// the SDK validates the reply against the schema and hands you an object,
// not a paragraph you have to scrape

The three cost levers most people never touch

This is the part that separates a demo from something you can afford to run. Tokens cost money in both directions, and three levers change the bill a lot.

Prompt caching. If the start of your prompt is the same every call (a long system prompt, a policy document, a set of examples), the provider can cache it. Writing to the cache costs a little extra, but reading from it costs around a tenth of the normal price. For an app that re-sends the same ten thousand tokens of instructions on every request, that is most of the bill gone.

flowchart LR
  S[System prompt, policy, examples: identical every call] -->|cached after the first call, read at a tenth of the price| M[Model]
  U[The question: different every call] -->|sent in full| M
  M --> A[Answer]

Batch processing. Work that does not need an instant answer, like summarising a thousand documents overnight, can go through a batch API at roughly half price in exchange for waiting.

The right-sized model. From the last stop: route simple work to a small, cheap model and save the large one for what actually needs it.

The plumbing you cannot skip

Two last things belong at this stop because skipping them is how beginner apps break in public.

Rate limits, retries, and errors. Providers cap how many calls you can make per minute, and calls sometimes fail. Your code needs to catch that, wait, and retry with a growing delay, instead of crashing or hammering the API. Every SDK has this built in or a one-line option for it.

API key safety. Your API key is a password that spends your money. It lives in an environment variable on the server, never in front-end code, never in a repository. A key in the browser is a key anyone can copy and run up your bill with.

The tools you actually reach for

Good answers are mostly a good brief

The skill at this stop is not clever wording. It is treating each call as a complete, structured brief, asking for output your code can use, and knowing the three levers that decide whether the thing is affordable. Get those right and the model does most of the rest. Skip them and you get vague answers you cannot parse, at a price you did not expect.

Brief it properly, ask for structure, and cache what repeats.

Sources

• Maxim: a practitioner’s guide to prompt engineering in 2026 for system prompts, few-shot examples, and structured output
• Claude docs: prompt caching for how caching works and its pricing
• Claude docs: batch processing for the batch API and its discount
• DevToolLab: prompt caching in 2026, cut LLM API costs by up to 90% for the cost picture and stacking caching with batching