Course Build · API API-01

Build · API · Module 01

First Call, the Loop

After this, you've sent a single API call to Claude, read the response, identified what it cost and have a clear answer to whether building on the API is the right move for the thing you're trying to do.

Entering the Build axis · API

From conversation to construction.

What this axis is

The Use axis taught you to talk to AI well. Beginner showed you the message, Enabled showed you the constraints, Advanced moved you into Claude Code where the AI starts acting on your files. The Build axis is the next room across. Same building, different work. Here you're the one writing the loop the AI sits inside. You decide which model. You decide when it stops. You pay for every byte.

This isn't a promotion. Practitioners on the Use axis don't need to be here. They might choose to be here for a specific job — automating a thing they used to do by hand, shipping a feature for someone else — but the axes are independent. Pick the right one for the thing in front of you.

The question before the call

Before you write any code, the honest question is whether this should be an API call at all. Most early "I should build this on the API" moments are reversible. A 20-line script that calls the API can usually be done with a Skill, a Claude Code session, or a chat with yourself once a week. The decision becomes real when the work has to run when you're not there — on a schedule, on a trigger, for someone else.

The decision tree is small. Use it first.

Decision · build vs use

Need Claude to do this thing?
├─ Will the trigger be me, when I sit down? ────────── Chat or Claude Code
├─ Does it run on a schedule, or for someone else? ── API
├─ Does it live inside another system I ship? ─────── API
└─ Am I reaching for code because it feels serious? ─ Probably Claude Code

If you land on Chat or Claude Code, stop. Open Claude.ai or run claude instead. You've saved yourself a build. If you land on API, keep reading.

The minimum viable call

You need three things. An Anthropic API key. The SDK installed. A folder to run code in.

Get a key from console.anthropic.com. Add a small amount of credit (five or ten dollars is plenty for this module and the next). Export the key as an environment variable so you don't paste it into code:

export ANTHROPIC_API_KEY="sk-ant-..."

Install the SDK. Python or TypeScript both work; the surface is identical in shape. Python:

pip install anthropic

Write the smallest call. Save it as hello.py:

from anthropic import Anthropic

client = Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=200,
    messages=[
        {"role": "user", "content": "Summarise the idea of an API in one sentence."}
    ],
)

print(response.content[0].text)
print("---")
print(f"Input: {response.usage.input_tokens} tokens")
print(f"Output: {response.usage.output_tokens} tokens")

Run it. python hello.py. You should see a one-sentence summary, then a line of dashes, then the token counts. That's your first API call.

What just happened

Five things are worth noticing in that nine-line script. They're the seeds of every API surprise you'll have later.

The model is stateless. You sent a single message in a list. The model has no memory of any previous run of hello.py. If you want a conversation, you maintain the full message list yourself and re-send it on every turn. The list is the conversation. The server doesn't store it.

You set a ceiling. max_tokens=200 says "stop generating after 200 output tokens, no matter what." The model can stop sooner. It cannot stop later. If you forget to set this, the SDK has a default but you should never depend on it. Always name the ceiling.

The response is a draft. Same lesson as B-07. The model produced something plausible. Your code printed it. Your code did not verify it. If the next line in your real system depends on this being right, you need to read it before acting on it — programmatically.

Tokens are not characters. A token is roughly four characters of English. The exact split depends on the tokeniser and the language. You paid for both directions, input and output, at different rates.

You can read the usage. response.usage tells you what you just paid for. Get in the habit of printing it during development. The number rarely matches your gut estimate the first few times.

What it cost

For the call above, your usage will look like roughly 25 input tokens and 50–100 output tokens. At claude-sonnet-4-6 rates (check the current numbers at anthropic.com/pricing), that's a fraction of a cent. Less than the electricity to run the laptop for the second it took to respond.

The number to keep in mind is the multiplier. The hello-world call was tiny. A real system with conversation history, system prompts, tool definitions and a longer output will be 100–10,000x the input tokens and 10–100x the output. The same code at production scale is the same code with a real bill. The first call is the unit. Multiply.

The loop, named

A single call is the simplest possible interaction. Most production work involves a loop: you send a message, the model responds with text or a tool call, your code does something with the response, you send another message, the model responds again. The loop runs until the model stops asking for tools and produces a final answer, or until your code decides to stop it.

You won't write the loop in this module. Module 02 covers the basic loop with tool_use. What matters now is that the loop is something you write, not something the API does for you. The model proposes. Your code executes. The model has no memory between turns; you reconstruct the conversation each time. Every turn is metered.

The thing to do before the next module

Send three more calls. Vary one thing at a time. Use a different model (try claude-haiku-4-5 and claude-opus-4-7). Use a longer prompt (paste in a 200-word paragraph and ask for a summary). Use a tighter max_tokens (set it to 30 and see what happens). Print the usage every time.

The goal isn't building anything. The goal is to feel the proportions. Which model costs how much for which length. Where the cost scales with input vs output. What happens when you cap output too tight (it cuts off mid-sentence; stop_reason will say "max_tokens" instead of "end_turn").

Five minutes of varying. The intuition you build here is the floor for every cost question in the rest of the axis.

Next

API-02 walks the auth flow properly (env vars vs config files vs platform secrets), the model selection question for real workloads and the first tool_use round-trip. You'll write a loop instead of a single call.