Make your first model call

In The model is a part, not a coder you wrote a component spec: the job, the input, the output your feature needs back. This chapter opens the pipe behind that spec by printing one call from our own product in full, so the variation in that demo becomes a property you plan around.

The whole call, printed

In our family nutrition app FuelTheFam, the fridge feature sends a photo of the user's fridge to a multimodal model, and a shopping list comes back while they wait. Nobody on our team reads a list before a user sees it, so everything the feature is rides in one request, which leaves our server like this:

POST https://api.provider.example/v1/generate
Authorization: Bearer (our key, attached on the server)

{
  "model": "(the model we chose)",
  "instructions": "This is a photo of the inside of a home
    refrigerator. List every grocery item visible in the
    photo, one item per line, with no other text. Include
    only items visible in the photo. If the photo is too
    dark or blurry to read reliably, reply with exactly:
    RETAKE",
  "input": [
    { "type": "image",
      "data": "(the fridge photo, encoded as text)" }
  ]
}

Two working parts sit inside the wrapper. The instructions state the job in exact, quotable text: ours fixes one item per line, limits the list to items visible in the photo, and orders a retake request instead of a guess when the photo is unreadable. The input is whatever the user supplied, here a photo traveling as a long block of encoded text. The Authorization header carries the API key that bills our account, which is why the call runs on our server and never in a browser, the rule the backend chapter settled.

Providers label these fields differently: OpenAI's current default primitive, the Responses API, calls them instructions and input; Anthropic takes the instructions as a top-level system parameter; Gemini uses a system instruction field. All of them describe this same authenticated POST.

A model call is your instructions and an input in one authenticated request, and most of what this part teaches is a change to one of those two fields.

What comes back

The reply is also JSON, and the generated text is one field among several:

{
  "id": "resp_8f42a91c",
  "model": "(the model that ran)",
  "output_text": "whole milk\nlarge eggs\nbaby spinach\n
    strawberries\ncheddar cheese\nbutter\norange juice",
  "stop_reason": "complete",
  "usage": { "input_tokens": 1641, "output_tokens": 24 }
}

The id ties the response to the user request that caused it, and the model field confirms which model ran. The output text is the product: the \n escapes are line breaks, and the string reaches the user's screen as it stands. The stop reason says why generation ended; complete is a natural finish, a length cap would read differently. The usage block counts tokens in and out, the raw material of the bill. Nothing in the body says whether the list matches the fridge, no confidence score, no correctness flag, so your feature still has to judge the output.

Same photo, different list

Now send the identical request twice and print both replies.

Run one:

whole milk
large eggs
baby spinach
strawberries
cheddar cheese
butter
orange juice

Run two:

milk
eggs
strawberries
spinach
cheddar
butter
orange juice

Both runs returned the same seven groceries. Run two dropped the adjectives, moved strawberries ahead of the spinach, and finished at 18 output tokens where run one took 24, so the runs did not even cost the same. Neither reply is the correct one; both satisfy the instructions, and for a shopping list the differences are harmless.

The mechanism is sampling. A database looks answers up, so the same query returns the same row forever. A model generates its reply one token at a time, producing at each step a ranked list of candidate next tokens, each with a probability. The API does not always take the top candidate; it picks among the strong ones with weighted randomness, a setting most providers call temperature. The first step where two runs pick differently puts the replies on different paths, and every later pick widens the split. Nothing malfunctioned in your rehearsal; the call behaved as designed, twice.

Send the same request twice and the replies can legitimately differ, because a reply is generated by sampling, not looked up. Design for the variation instead of filing it as a bug.

Tokens, the unit you are billed in

The usage block is where the money is counted. A model takes text in and puts text out in tokens, chunks a few characters long, and the boundaries fall where you would not guess:

You | have | straw | berries | and | a | dozen | eggs | .

That is nine tokens for a seven-word sentence: common short words cost one token each, strawberries splits in two, and the period is a token of its own. Images are billed as tokens too, and they dominate here: of run one's 1,641 input tokens, the instruction text accounts for roughly sixty and the photo for nearly all the rest. You pay for tokens in and out on every call, so instructions sent on every call are a recurring cost. One fridge list, photo included, costs a fraction of a cent at current mid-tier rates; live prices belong to provider pricing pages and the Playbook's cost section, not prose.

A token is a chunk of text a few characters long, and every call bills for tokens in plus tokens out, photos included.

Why read it when your tool will write it

The obvious objection is that you will never assemble this JSON by hand: your coding tool writes the route and a provider library builds the request. That is true, but reading the call is what lets you direct them. When our fridge feature misfired, the reply was "Sure! It looks like you have milk, a dozen eggs, and some spinach in there," friendly to a person and fatal to code expecting a bare list. Both the failure and the fix sat in fields you have now read: the instructions permitted prose, and tightening the reply is the subject of get output your code can build on. Every move left in this part edits one of these fields, and the request your tool assembles is what you will review.

Try it now

Budget twenty minutes. The drill picks up the component spec from The model is a part, not a coder and leaves your feature's first call, which every remaining drill in this part builds on.

No setup: Provider playgrounds want an account and paid credits, so this path stays on paper and spends nothing. Label the parts of our fridge request: endpoint, key, model, instructions, input, and in the response the reply, stop reason, and usage. Then write your feature's request the same way on one page: instructions in exact text you could paste, one real input written out in full, and the reply you expect, line by line. Mark which parts of that expected reply may vary between runs, order and phrasing, and which must never vary. The page is your feature's first call, written and ready to run the moment your tools are.

With your tools: Make the call for real. Ask Claude Code for a one-file script that sends your feature's instructions and one real input to a model and prints the entire raw response body, key read from an environment variable. Run it twice with the identical input and compare the replies, the stop reasons, and the output token counts; the pair of calls costs a fraction of a cent. Provider consoles run the same call behind a browser form (Anthropic's is branded the Claude Console) but need a funded account, which is why the paper path exists. Same move in Codex or Cursor: ask for a single script that makes one call and prints the raw response, then run it twice. If nothing is installed yet, the Setup Clinic gets you running in one sitting.

Either path leaves the same artifact, your feature's first call: made live if your tools are running, written and runnable for the day they are.

Chapter Summary

• A model call is one authenticated POST carrying your instructions and an input, plus the name of the model to run.
• Providers label the two fields differently (OpenAI's Responses API, Anthropic's top-level system parameter, Gemini's system instruction field), but the request is the same pattern everywhere.
• The API key rides in the request header, so the call runs on your server and never in the browser.
• The response body holds the generated text plus the metadata you will lean on later: an id, the model that ran, a stop reason, and the token counts behind the bill.
• The same request can return a different reply on every run, because replies are generated by sampling among probable next tokens, not looked up.
• Never judge a feature on a single run; rerun the input and judge the range, the habit that becomes the Proof Table.
• A token is a chunk of text a few characters long, and every call bills for tokens in plus tokens out, photos included.
• One fridge list costs a fraction of a cent at current mid-tier rates; live per-token prices belong to pricing pages and the Playbook, not prose.
• You leave this chapter holding your feature's first call, live or on paper.
• Next, Prompting is engineering, not wording takes the instructions field you just wrote and treats it as the first rung of the ladder this part climbs.

Sources

• OpenAI Responses API documentation (last verified July 2026).
• Anthropic Messages API documentation (last verified July 2026).
• Google Gemini API documentation on system instructions (last verified July 2026).
• OpenAI, Anthropic, and Google pricing pages for per-token rates (last verified July 2026).