Technical Fundamentals

What this skill covers

Technical fundamentals are 6.1% of the exam, the largest slice of Domain 5. The skill is how a program reaches Claude: SDKs wrapping a REST API, and WebSockets as a transport you must not confuse with that API.

The model does not care which language built the JSON. It cares that the body is a Messages request. Your job is to know which process holds the connection, the history, and the retries.

REST, and nothing stored for you

A non-streaming Messages call is an HTTPS POST to the Messages endpoint. The body is JSON: model, max_tokens, messages, and the optional system, tools, thinking, and output_config fields. A success is a JSON message. An error is the error object from Domain 4.

The API does not keep your conversation. The next turn is a new HTTP request that includes every message so far, plus the new user content. That is why a long thread costs more input on every turn, and why two servers can continue the same task only if they share the history you stored.

Send the anthropic-version header and the API key. The official client libraries set those. A raw HTTP client has to set them itself. The request id comes back on the response for the failures you will file.

What an SDK wraps

The official Python, TypeScript, and other SDKs are clients for that REST API. A messages.create call becomes the same JSON a curl command would send. You gain typed parameters, typed errors, a default retry on connection failures, rate limits, and 5xx responses, and a place to read the request id.

The SDK does not add a session, a hidden memory, or a different model. Bedrock, Google Cloud, Foundry, and Claude Platform on AWS can be reached through the same style of client, with that platform's credentials and that platform's model id. The message shape stays a message. The id you pin is the one you evaluated on that platform.

Use the SDK in a supported language. Write raw HTTP when you are in a language without a maintained client, or when you are proving exactly which bytes left the process. A raw client that streams has to parse server-sent events itself. The SDK's stream helper accumulates those events into a final message.

const stream = anthropic.messages.stream({
  model: "claude-sonnet-5-5",
  max_tokens: 1024,
  messages: [{ role: "user", content: "Summarize the incident in five lines." }],
});
const message = await stream.finalMessage();

Streaming is server-sent events

Set stream to true and the success response is server-sent events, not one JSON blob at the end. Each event has a name and a JSON payload: the message starts, content blocks start, text arrives in deltas, blocks stop, and the message stops. An error can arrive after HTTP 200. The events before that error are a partial turn.

People turn streaming on to show tokens as they arrive, and to keep a long generation from looking like a dead HTTP connection. Idle proxies drop quiet sockets. A non-streaming call with a very large max_tokens is the call that times out. The TypeScript SDK refuses a non-streaming request it expects to run on the order of ten minutes. Streaming, or an explicit longer timeout, is how that call proceeds.

The client reads the stream. It does not send further tokens back on the same response. Tool results and the next user turn are a new HTTPS request.

WebSockets are a different socket

A WebSocket is a long-lived connection that both sides can write to, framed as messages, usually opened with an HTTP upgrade. Chat products use them so a browser can send and receive at any time without a new request per keystroke.

The Messages API does not deliver Claude's tokens on a WebSocket. It delivers them as JSON or as server-sent events. A browser that needs a live channel opens that channel to your server. Your server calls the Messages API over HTTPS, reads the SSE stream, and forwards the deltas across the socket you own.

Putting the Anthropic API key in the browser so the page can open either kind of connection publishes the key. The key stays on the server that is allowed to call the API. The socket, if you have one, carries your own session, your own auth, and the text you chose to forward.

Where the history lives

Because each REST call is independent, the store is yours: a database row, a cache, an agent transcript. The SDK object you constructed at process start does not remember previous messages.create calls. You pass the array.

An async SDK client lets your process wait on many HTTP calls at once. It does not merge those calls into one context. Each call has its own model, its own messages, and its own bill. A fan-out of Haiku classifications is many REST requests, not a WebSocket fan-out to the model.

The key in the browser

A prototype opens a socket from the page to a vendor endpoint and ships the Anthropic API key in the query string so tokens can stream to the user.

The key belongs on a server you control. The page can use a WebSocket to that server. The server calls the Messages API with the SDK, reads the SSE deltas, and writes them to the socket. The browser never sees the key.

The quiet POST

A batch of long summaries sets max_tokens to 32,000 and leaves stream false. Proxies close the connection before the JSON body arrives. The client reports a timeout and no message.

The generation was too quiet for the path. Stream the response, or set a timeout that matches the job. The final message is the same either way once the events are accumulated.