Claude Certified Developer - Foundations cheat sheet
Claude Certified Developer - Foundations ยท Keep the key ideas within reach.
Claude API Fundamentals: Models, Messages, Tokens, and Request/Response Structure
Required request fields are model, max_tokens, and messages; system, tools, tool_choice, temperature, top_p, top_k, stop_sequences, metadata, and stream are optional top-level parameters.
Each entry in messages is {role, content}, where role is only "user" or "assistant" and content is either a plain string or an array of typed content blocks.
The system prompt travels in the top-level system parameter, not as a message with role "system"; no system role exists in the messages array.
A successful response returns id, type "message", role, model, content[] (list of blocks), stop_reason, stop_sequence, and usage.
stop_reason values: end_turn (natural completion), max_tokens (output truncated at the cap), stop_sequence (a supplied sequence matched), tool_use (Claude is requesting a tool call).
Billing and budgeting read from usage.input_tokens and usage.output_tokens; cache activity appears separately as cache_creation_input_tokens and cache_read_input_tokens.
POST /v1/messages/count_tokens returns the token count a prospective request would consume without generating any output.
temperature ranges 0-1 with a default of 1.0; tune temperature or top_p, not both simultaneously.
Streaming (stream: true) emits server-sent events in order: message_start, content_block_start, content_block_delta(s), content_block_stop, message_delta (carrying stop_reason), message_stop.
Prompt Design and Prompt Engineering Techniques
Placement rule: persona, standing rules, and output contract go in the system parameter; the concrete task and its data go in the user turn.
XML-style tags (, , , ) with consistent, properly closed names let the model reliably separate prompt sections.
Few-shot prompting uses roughly 3-5 diverse examples that each show the exact target output format and collectively cover edge cases.
Prefilling the final assistant turn with an opening fragment (for example an opening brace) forces the continuation into the desired format and suppresses preamble.
For multi-step reasoning, instruct the model to reason inside a dedicated block (such as ) before emitting the answer, and parse out that block downstream.
Long-context ordering rule: large documents near the top of the prompt, the question and instructions at the end; this ordering yields up to about a 30% quality gain.
State the output schema explicitly and include one valid worked response; positive directives ("respond with JSON only") outperform prohibitions.
Use prompt chaining when a single prompt would carry several dependent transformations: split into sequential calls and pass the prior output forward.
Chain-of-thought instructions increase output tokens and latency, so apply them only to tasks that genuinely require intermediate reasoning.
Tool Use and Function Calling
A tool definition is {name, description, input_schema}, where input_schema is JSON Schema with type "object", a properties map, and a required list.
Tool names must be unique within a request, no longer than 64 characters, and match the pattern ^[a-zA-Z0-9_-]{1,64}$.
tool_choice modes: {"type":"auto"} lets Claude decide, {"type":"any"} forces at least one call, {"type":"tool","name":X} forces a specific tool, {"type":"none"} forbids all calls.
Setting disable_parallel_tool_use to true restricts the model to at most one tool call per assistant turn.
When stop_reason is "tool_use", the response contains one or more tool_use blocks, each with id, name, and input.
Results are returned in a user message of tool_result blocks whose tool_use_id matches the request; set is_error to true for failed executions.
Every tool_result for a turn must be delivered in the single user message immediately following the tool_use turn, before any other content.
Tool descriptions drive selection accuracy more than input_schema does: state when to use the tool and, explicitly, when not to.
Prefer several narrow, single-purpose tools over one generic tool that takes a mode parameter, because disambiguation improves selection reliability.
Agentic Workflows and Multi-Step Orchestration
Definition boundary: a workflow runs model calls along predefined code paths; an agent lets the model dynamically choose its own steps and tool calls.
Core agent loop: observe current results and context, decide the next action, execute a tool, observe the result, and repeat.
Every agent loop needs a hard cap on iterations plus a token or wall-clock budget; unbounded loops are the primary source of runaway cost.
Orchestrator-workers: a lead call decomposes the task, dispatches independent subtasks to worker calls, then synthesizes their outputs into one answer.
Routing: a cheap classification call labels the incoming request, and the label selects which specialized prompt, toolset, or model tier handles it.
Evaluator-optimizer: a generator call drafts, a separate critic call scores against explicit criteria, and the loop repeats until the critic passes or budget runs out.
Subagents isolate context: each child returns only a condensed summary to the parent, keeping the orchestrator's context window small.
Irreversible actions (writes, payments, deletions, outbound messages) require an explicit human confirmation gate before execution.
Terminate with a verification step in which the agent checks its output against the task specification before declaring completion.
Context Management, Retrieval, and Prompt Caching
Prompt caching is opt-in per content block via cache_control: {"type":"ephemeral"}, with a maximum of 4 cache breakpoints per request.
Cache prefix order is tools, then system, then messages; a change anywhere in the prefix invalidates every cached block after it.
Cost multipliers: writing a cached prefix costs about 1.25x base input tokens, reading it costs about 0.1x, so a prefix must be reused roughly twice to break even.
Minimum cacheable length is 1024 tokens for Opus and Sonnet class models and 2048 for Haiku class; shorter prompts are silently not cached.
Default cache lifetime is 5 minutes, refreshed at no extra charge on each hit; a 1-hour TTL option is available where supported.
Cache effectiveness is measured by comparing usage.cache_read_input_tokens against usage.cache_creation_input_tokens in the response.
Standard context window is 200K tokens; a long-context beta extends selected models to 1M tokens.
Retrieval pipeline: chunk to a few hundred tokens with overlap, embed, retrieve top-k, optionally rerank, then place passages before the question as quoted context.
Context management tactics: summarize older turns, drop stale tool results, and persist durable state in external storage rather than inside the context window.
Evaluation, Testing, and Observability of Claude Applications
Build eval sets from real production traffic; 20-50 curated cases catch most regressions and cost far less to maintain than hundreds of synthetic ones.
Grading ladder: deterministic code checks (exact match, regex, unit assertions) first, LLM-as-judge for open-ended output, human review for calibration.
LLM-as-judge: pairwise comparison is more reliable than absolute 1-10 scoring; randomize the A/B order to cancel position bias.
Validate the judge against a human-labeled subset and report agreement before using its scores as a release gate.
Log per request: model, prompt version, input and output tokens, stop_reason, latency, cache hit or miss, tool calls made, and error state.
Track cost and latency per successful task (p50 and p95), not per request, since retries and multi-step agents multiply request counts.
Temperature 0 reduces but does not eliminate output variance; run each case multiple times when scores sit near a pass threshold.
Version prompts and eval sets in source control so any quality shift is attributable to a specific diff and can be rolled back.
Production monitors: refusal rate, tool-error rate, max_tokens truncation rate, cache hit rate, and judge-scored sample audits.
Safety, Alignment, and Responsible Deployment Practices
Claude is trained with Constitutional AI (critique and revision against written principles, yielding preference data) plus reinforcement learning from human feedback toward helpful, honest, harmless behavior.
Anthropic's Responsible Scaling Policy defines AI Safety Levels (ASLs) that pair capability thresholds with required security and deployment safeguards.
Prompt injection rule: all retrieved text and tool-returned content is untrusted data and must never be allowed to override system instructions.
Least privilege applies to tools: minimum scope per tool, sandboxed execution for code, and confirmation gates in front of any write or external side effect.
Delimit untrusted content in dedicated tags and instruct the model explicitly that tagged content is data to be analyzed, not instructions to follow.
By default API inputs and outputs are not used to train models; retention length and zero-data-retention are contractual settings, not prompt features.
Over-refusal is a measured failure mode: track false-positive refusals on benign prompts alongside true harmful-output detection.
Pre-deployment safety evaluation uses red-team prompt sets, plus input and output filtering for prohibited categories.
High-stakes decisions retain a human decision-maker, and AI-generated content is disclosed where regulation or user expectation requires it.