CCA-FChapters01

Chapter 01

Claude API

The request/response contract every agent is built on — and the four fields the exam actually tests.

D4D5guide part i

1.1

One request carries the whole world

Request–response. Nothing is remembered between calls, so every call ships everything the model needs.

modelopus-4-6 / sonnet-4-6 / haiku-4-5 — capability vs cost vs latency
max_tokensceiling on the reply, not the context window
systembehaviour, role, constraints, output format — separate field, not a message
messages[]the full conversation history, every single call
tools[]name + description + input_schema per tool
tool_choiceauto / any / a named tool
Six fields. Four of them are what the exam bends scenarios around.

1.1b

The API is stateless — the transcript is the memory

Nothing survives between calls except what you resend. That is why cost grows quadratically over a long turn.

call 1turn 1call 2turn 1turn 2call 3turn 1turn 2turn 3tokens paidgrow every turn
Call n pays for turns 1…n. Anything that must survive has to live in the transcript.

1.2

Three roles — and tool results are not one of them

A tool result rides inside a user turn as a tool_result block. There is no tool role.

system: "You are…"top-level fieldapplies from turn 1messages[ ]usertextassistanttexttool_usestop_reason: tool_useusertool_resultstill the user roleyour code wrote thisassistanttextstop_reason: end_turn
The tool_use_id is what pairs a result to its request — never the position in the array.

system can also appear inside messages[] to add instructions mid-conversation without invalidating the cached prefix from the top-level field. Later system messages win over earlier ones and over the top-level field, for turns after them.

1.3

stop_reason is the only completion signal

A structured field decides the control flow. Never the reply text.

end_turndone → show user
tool_useexecute → loop back
max_tokenstruncated → raise limit
stop_sequenceyour own marker hit
Two of the four values run the agentic loop; the other two are failure handling.

1.4

The system prompt shapes tool behaviour too

It is loaded once, outranks user messages, and quietly creates tool associations you did not ask for.

What it is for

Role, hard constraints, output format, escalation rules — the things that must hold across every turn.

The exam's favourite side effect

"Always verify the customer" makes the model call get_customer on turns where nobody needed verifying. Wording creates tool gravity.

1.5

The context window is a budget you spend four ways

System prompt + full history + tool definitions + tool results. Tool results are the ones that run away.

system
tool defs
history + tool results
free
Every tool call permanently enlarges the history segment for the rest of the turn.
highlowstartmiddle of inputendconstraints here…or heredetails go missing
Lost in the middle: reliable at the edges, lossy in the belly. Put constraints where retrieval is strong.
Accumulation

A tool returning 40 fields when 5 matter wastes the window on every later call. Trim at the boundary — a PostToolUse hook, or the tool itself.

Summarisation loss

Compaction eats exactly what you need: numbers, percentages, dates become "about", "roughly", "a few". Extract facts into a separate block before compacting.

Recall in 60 seconds

  1. Send the full history every call — the model persists nothing.
  2. Tool results are tool_result blocks in a user turn. No tool role exists.
  3. tool_use_id pairs a result to its request. Never rely on ordering.
  4. Completion = stop_reason === 'end_turn'. Not text, not an iteration count.
  5. max_tokens caps the reply. The context window caps everything.
  6. System-prompt wording creates tool gravity — "always verify" causes needless lookups.
  7. Lost in the middle → put constraints at the start or the end.
  8. Compaction destroys numbers and dates. Extract them out first.