Start here

One honest gate before we start. If you have already called the Claude API — even once, even from a toy script — everything below is revision for you, not news. Skip to Domain 01; your time is better spent where the marks are.

This page is for the reader who has met AI as a chat window, or not at all, and now wants the certification. Maybe your job suddenly expects it. Maybe you are weighing whether this career turn is for you. Either way: the eight guides that follow are written for a developer who builds with the API, and they stop explaining the basics on page one. This is the basics, once, so they never have to.

01What is Claude?

Claude is a family of AI models built by Anthropic, a company whose whole business is building them. That sentence carries more than it lets on, so take it in three parts.

A model, not an app. When people say Claude they can mean three doors into the same thing. Door one: the Claude app and website — the chat window where you type and it answers. Door two: Claude Code, a tool that lives in your terminal and edits real codebases — itself, underneath, a customer of door three. Door three: the API — the raw model, rented by the request, that you build your own products on top of. The same engine sits behind all three doors. This certification is about the third door, and so is everything an AI engineer does.

A family, not one model. The family comes in three tiers you choose between on every build: Opus — the strongest, slowest and most expensive; Sonnet — the balanced middle, where most production work lives; and Haiku — small and fast, built for volume. Each tier carries a version number (Opus 5.5, Sonnet 5, Haiku 4.5), and the numbers move constantly — those were last checked against Anthropic’s documentation in September 2026. Re-check anything numeric against the official documentation before you memorise it; that rule applies double on this page.

A text engine, not a mind. Underneath every door, Claude is a program trained on enormous amounts of text to do one thing extraordinarily well: predict the next word given everything before it. (That is a deliberate simplification — the honest version is a career of mathematics — but it is the load-bearing one.) Grown large enough, that one trick produces reading, writing, code and what looks like reasoning. But on its own the model has no tools, no memory from one call to the next, and no way to act. It only responds. Everything else — the tools, the memory, the loop that keeps it working — is what you build around it. That is not a limitation to apologise for; it is the job description.

02What an AI engineer does all day

The title is younger than the job. An AI engineer builds products and systems on top of ready-made models — models like Claude, trained by someone else, rented by the request. The engineer who trains those models is a different profession, an ML engineer or researcher, and the two get blurred constantly. This certification is firmly about the first one.

The work, stripped to its skeleton, is one loop you will run a thousand times:

• —Assemble the context. Decide what the model sees this request: the instructions, the data, the documents, the tools it may call. This — not clever wording — is most of the craft.
• —Call the model. Send that context over the API and get a response back, usually in under a second.
• —Inspect what came back. Read it, or better, have a check read it. Models fail confidently; the loop only works if failures surface.
• —Measure and adjust. Change the context, the model or the tools — and run it again.

Notice what shifts, though. A backend engineer encodes the rules that do the work; in model-driven features you more often specify the conditions under which a model applies judgement — the context it sees, the tools it may call, the checks its output must pass. Deterministic code does not disappear (orchestration, validation and infrastructure are still yours to write), but its centre of gravity moves from “here are the rules” to “here are the conditions”. That is also why prompt engineering is one slice of this job, not the job — a prompt is a lever, and the rest of the machine decides whether the lever is attached to anything. Choosing models, designing tools, structuring context, measuring whether any of it worked: that is the whole surface, and — conveniently — the map of this certification.

03Your first API call, on paper

You do not need to run anything to understand this. Every Claude API call is the same short conversation with a very fast stranger — one who forgets you the moment the reply is sent.

Your code sends a request: here is my API key proving I may ask; use this model; and here are my messages — a system prompt (the standing instructions that tell the model its job) plus the conversation so far. The response comes back as structured data: the text Claude produced, which model produced it, why it stopped, and — important — what it cost.

Cost is counted in tokens, and it is worth slowing down here because the whole guide talks in them. The model does not read words; it reads tokens — chunks of text roughly a word or a fragment of one. You pay for the tokens you send and the tokens you get back, at per-million rates that differ by direction and by model.

A worked example, with invented round numbers so it can never go stale. Say a model bills $3 per million input tokens and $15 per million output tokens. A request sends 2,000 tokens and gets 500 back: that is 0.6¢ of input plus 0.75¢ of output — about 1.4 cents for the whole call. Run that arithmetic over a million customers and you can see why “how much context does this feature really need?” is a business question, not just a technical one. For a feel of scale: an ordinary paragraph runs roughly 100–200 tokens, so a full page of text is a few thousand.

Every request, the model can see only so many tokens at once. That limit is the context window — think of it as desk space. Everything Claude can possibly use this request must fit on the desk at the same time: instructions, documents, conversation history, tool definitions, the works. Fit is not free either: more context costs more tokens and, past a point, degrades quality. Managing that desk is a certification domain of its own — you will meet it as Domain 06.

One last property quietly shapes everything in this guide: the API is stateless. The model remembers nothing between calls. If you want a conversation, you maintain it — your code resends the whole history every request, and the memory is just your transcript growing. Every clever thing you will read about later — sessions, prompt caching, agents that remember — is a strategy for coping with that one fact. (And no, the Claude chat app does not defy this: it keeps the transcript for you and quietly resends it each turn. Same stateless engine; someone else doing the resending.)

04The map from here

Everything on this page was the floor. Here is where each piece gets its proper room, and the order to read them in — heaviest marks first. One warning before you scan: the table below will name things — subagents, rules files, evals, MCP — that this page has not explained. That is deliberate. This is a map, not a syllabus: you are not expected to recognise the terrain yet, only to see that every mystery has an address where it gets solved.

The certification, at its core, asks one thing of you: that you understand what happens when a request leaves your code, everything Anthropic’s side does with it, and everything that can go wrong in between. You now know enough for that sentence to be a plan instead of a slogan. Domain 01 is where the marks start.