Claude API Models: CCDV-F Domain 2 & 5 Study Guide

Choosing the right claude api models for a given integration task is not a matter of picking the most capable option and moving on. The Claude Certified Developer, Foundations exam (CCDV-F) tests whether you can reason about model selection, API mechanics, cost management, and configuration in real production scenarios. Domain 2 (Applications and Integration) carries 33.1% of the exam weight, and Domain 5 (Model Selection and Optimisation) carries 16.8%, making these two domains together nearly half the exam. Get them wrong and a passing score of 720 on the 100-to-1000 scale becomes very difficult to reach.

This guide works through the concepts those two domains test, with worked code examples, a comparison table of the four live tracks, and the decision logic the exam rewards.

What does the CCDV-F exam actually test about Claude API models?

The exam tests practical judgment, not recall. Every item is scenario-based: you are given a situation and asked what a competent developer would do. For model selection, that means understanding the trade-offs between latency, cost, capability, and context window rather than memorising a spec sheet.

Per Anthropic's exam guide, Domain 5 (Model Selection and Optimisation) covers:

• Selecting the appropriate model tier for a task's complexity and latency requirements.
• Applying prompt caching, batching, and streaming to reduce cost and improve throughput.
• Recognising when a cheaper model suffices and when a more capable one is necessary.

Domain 2 (Applications and Integration) covers the mechanics of wiring those models into real applications: API configuration, authentication, error handling, and the request-response cycle.

How does the Messages API request-response cycle work?

The Messages API request-response cycle is the foundation of every Claude integration. A request carries a model field, a max_tokens field, and a messages array. The response returns a content array, a stop_reason, and usage statistics.

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=1024,
    system="You are a helpful assistant.",
    messages=[
        {"role": "user", "content": "Summarise the key risks in this contract."}
    ]
)

print(response.content[0].text)
print(response.stop_reason)       # "end_turn", "max_tokens", "tool_use", etc.
print(response.usage)             # input_tokens, output_tokens

The stop_reason field matters for agentic loops. If it returns tool_use, the loop must append the tool result and continue. If it returns max_tokens, the response was truncated and the application must decide whether to extend or fail gracefully. Inspecting stop_reason field values before deciding next steps is a pattern the exam rewards consistently.

Which model should you choose for a given task?

The exam does not ask you to memorise pricing tiers. It asks you to apply a decision framework. The core question is: what is the minimum capability required to meet the task's quality bar, latency budget, and cost envelope?

A common exam trap is selecting the most capable model by default. The exam consistently rewards proportionate choices: use the lightest model that meets the quality bar, and reserve heavier models for tasks that genuinely require them.

How do you configure the API for production applications?

Production configuration goes beyond a single client.messages.create call. The exam tests three areas: authentication, retry logic, and streaming.

Authentication uses an API key passed either as an environment variable (ANTHROPIC_API_KEY) or explicitly in the client constructor. The exam expects you to know that hardcoding keys in source is a security anti-pattern.

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

Retry logic matters because the API can return transient errors (rate limits, network timeouts). The official Python SDK includes automatic retries with exponential backoff by default. You can configure the maximum number of retries:

client = anthropic.Anthropic(
    max_retries=3,
)

Streaming reduces time-to-first-token for user-facing applications. The exam distinguishes between use cases where streaming is appropriate (interactive chat, long-form generation) and where it is not (batch processing, downstream parsing of structured output).

with client.messages.stream(
    model="claude-haiku-4-5",
    max_tokens=512,
    messages=[{"role": "user", "content": "List five debugging strategies."}]
) as stream:
    for text in stream.text_stream:
        print(text, end="", flush=True)

What is prompt caching and when should you use it?

Prompt caching allows repeated prefixes (system prompts, large documents, tool definitions) to be cached server-side, reducing both latency and input token costs on subsequent requests. The exam tests when caching is worth the overhead and when it is not.

The decision rule is straightforward: if a prefix is long, expensive to process, and reused across many requests, cache it. If it changes on every request, caching adds overhead without benefit.

response = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "You are a legal document analyst. " + large_legal_corpus,
            "cache_control": {"type": "ephemeral"}
        }
    ],
    messages=[{"role": "user", "content": "What are the indemnification clauses?"}]
)

The exam also tests the interaction between caching and model selection. A cached prefix is model-specific: switching models invalidates the cache. If your architecture switches models mid-conversation (for example, routing simple follow-ups to a lighter model), you must account for cache misses.

How does batching work and when is it the right choice?

The Message Batches API allows you to submit up to 10,000 requests in a single batch, processed asynchronously. The exam tests the synchronous-versus-batch decision rule.

Use batching when:

• Requests are independent of each other (no sequential dependencies).
• Latency is not user-facing (the user is not waiting for a real-time response).
• Volume is high enough that the cost reduction justifies the operational complexity.

Do not use batching when:

• Requests form a chain where each depends on the previous result.
• The application requires a response within seconds.
• You need to stream partial results to the user.

import anthropic

client = anthropic.Anthropic()

requests = [
    {
        "custom_id": f"doc-{i}",
        "params": {
            "model": "claude-haiku-4-5",
            "max_tokens": 256,
            "messages": [{"role": "user", "content": f"Classify: {doc}"}]
        }
    }
    for i, doc in enumerate(documents)
]

batch = client.beta.messages.batches.create(requests=requests)
print(batch.id)

The custom_id field is important: it lets you correlate batch results back to your input records when results arrive out of order. The exam tests this pattern directly.

How does model selection interact with tool use and MCP integration?

Tool use adds complexity to model selection because not all models handle tool calls with equal reliability. The exam tests whether you understand that tool-calling performance varies across model tiers, and that for agentic workflows with many tool calls, model reliability matters more than raw cost per token.

The tool_choice configuration options let you control whether the model must use a tool, may use a tool, or must not use tools. Setting tool_choice to {"type": "required"} forces a tool call, which is useful when you need structured output via a tool schema rather than free text.

response = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=1024,
    tools=[extract_entity_tool],
    tool_choice={"type": "required"},
    messages=[{"role": "user", "content": "Extract all named entities from this text."}]
)

For MCP-integrated applications, the exam also tests configuration scoping. The MCP scoping hierarchy determines which tools are available to which models in a multi-agent system. Getting scoping wrong leads to tool misrouting, which is a common exam scenario.

What does Domain 2 expect about configuration management?

Domain 2 (Applications and Integration, 33.1%) is the heaviest domain on the CCDV-F exam. Beyond API mechanics, it tests configuration management: how you manage API keys, model identifiers, and environment-specific settings across development, staging, and production.

The exam rewards:

• Externalising configuration (environment variables, secrets managers) rather than hardcoding.
• Using model identifiers as configuration values rather than string literals scattered through code.
• Validating configuration at startup rather than discovering missing values at runtime.

import os
from dataclasses import dataclass

@dataclass
class ClaudeConfig:
    api_key: str
    default_model: str
    max_retries: int
    timeout: float

def load_config() -> ClaudeConfig:
    api_key = os.environ.get("ANTHROPIC_API_KEY")
    if not api_key:
        raise EnvironmentError("ANTHROPIC_API_KEY is not set")
    return ClaudeConfig(
        api_key=api_key,
        default_model=os.environ.get("CLAUDE_MODEL", "claude-sonnet-4-5"),
        max_retries=int(os.environ.get("CLAUDE_MAX_RETRIES", "3")),
        timeout=float(os.environ.get("CLAUDE_TIMEOUT", "30.0")),
    )

This pattern validates at startup, centralises configuration, and makes environment-specific overrides straightforward. The exam consistently rewards this kind of deterministic, fail-fast design over probabilistic error discovery.

How do the CCDV-F domain weights affect your study priority?

With 53 items and a 120-minute time limit, the CCDV-F exam allocates roughly two minutes per item. Understanding domain weights helps you allocate study time proportionately.

Domains 3 and 4 together account for fewer than 3 items. Foundational awareness is sufficient; deep expertise in those areas will not move your score materially. Domains 2 and 5 together account for roughly 27 items, nearly half the exam. That is where preparation time pays off most.

How does the CCDV-F differ from the CCAR-F in how it tests model knowledge?

The two exams test overlapping concepts from different angles. The CCAR-F (Architect Foundations, $125) tests model selection as an architectural decision: which model tier belongs in which part of a multi-agent system, and how to design for reliability at scale. The CCDV-F (Developer Foundations, $125) tests model selection as an implementation decision: which API parameters to set, how to handle errors, and how to manage costs in code.

A key structural difference: CCDV-F has no scenario bank. Unlike CCAR-F, which draws 4 scenarios at random from a bank of 6 at each sitting, CCDV-F items are written directly against the skills in each domain. This means every sitting covers the full domain map, and there is no scenario-based variance to account for in your preparation.

For developers preparing for CCDV-F, the prompt engineering and structured output concepts and the context management and reliability concepts from the CCAR-F library provide useful background, even though the developer exam tests them at the implementation level rather than the architecture level.

Where should you focus your final preparation?

Given the domain weights, a rational final-week study plan concentrates on:

1. Domain 2 mechanics: Messages API parameters, authentication patterns, streaming vs. synchronous, error handling, and configuration management.
2. Domain 5 decision logic: The model selection framework, prompt caching trade-offs, batching decision rules, and cost optimisation patterns.
3. Domain 1 and 8 overlap: How model selection interacts with tool use and MCP integration in agentic workflows.

Our adaptive study platform tracks your mastery across all eight CCDV-F domains using Bayesian Knowledge Tracing with a 0.90 mastery threshold, so you spend time where your knowledge is weakest rather than reviewing what you already know. Practice exams mirror the real format: 53 questions, scored 100 to 1000, with 720 as the passing bar.

AI Skill Certs is an independent prep platform and is not affiliated with or endorsed by Anthropic.