- In short
- Error type identification is classifying a failure in a Claude application into one of four classes - transport and API errors, rate-limit errors, tool-execution errors, or model-output errors - so the right recovery can be chosen. Correct classification is the first step before any retry, backoff, or reprompt, because each class maps to a different recovery path.
Why classification comes first
When a Claude application fails in production, the instinct is to reach straight for a fix, wrap the call in a retry, raise a timeout, tweak the prompt. Error type identification is the discipline that says stop and name the failure first. The Claude Certified Developer - Foundations (CCDV-F) exam treats this as the foundation of Task 4.1 because every downstream decision depends on it: you cannot choose a recovery strategy until you know which kind of error you are recovering from. Classification is not busywork; it is the branch point that determines whether the right move is a retry, a backoff, a reprompt, or an escalation.
The reason this knowledge point sits at the understand level rather than being trivial is that the four error classes look similar at the call site. They can all surface as an exception or a non-success response in your code. The skill is reading past the surface to the underlying cause, because two failures that raise the same exception type can demand opposite responses. Get the class right and the recovery almost picks itself; get it wrong and you can retry forever against an error that will never succeed.
- Error type identification
- The act of classifying a failure in a Claude application into one of four classes - transport and API errors, rate-limit errors, tool-execution errors, or model-output errors - so that the correct recovery path can be selected. It is the first step in the debugging workflow, performed before any retry or reprompt.
The four error classes
The exam groups Claude application failures into four buckets, and knowing the boundaries between them is the core teaching point.
Transport and API errors are failures in the call itself. The request never completed as intended: a network drop, a timeout, a connection reset, or an HTTP error returned by the API such as a 500-class server error. The model never produced a usable response because the round trip broke. Many of these are transient, the same request a moment later may succeed, but not all of them are: a 400-class error caused by a malformed request body is an API error that will fail identically every time until you fix the request.
Rate-limit errors are their own class because they carry a specific meaning and a specific remedy. The call was well formed and reached the API, but you exceeded a request or token quota, so the API refused it (typically an HTTP 429). Nothing is wrong with your payload or the model; you are simply asking too fast. The failure is transient in the sense that waiting resolves it, which is exactly why it is separated from generic transport errors: the correct pace of recovery is dictated by the limit, not by a fixed timeout.
Tool-execution errors occur when the model asks to call a tool and the tool itself fails. The Claude API request succeeded, the model reasoned correctly and emitted a valid tool_use request, but the code or service behind that tool threw an error, timed out, or returned an unusable result. This is a fault in your integration surface, not in the model. The four error categories that tool interfaces surface, and the patterns for reporting them back to the model, live one layer down from this classification but feed directly into it.
Model-output errors are the subtle class. Here every call succeeded, no exception was raised, and the model returned a well-formed response, but the content is wrong. The JSON does not match your schema, a required field is missing, the answer is factually incorrect, or the model refused. Nothing in your transport or status codes flags this failure; only validating the content reveals it. This is why model-output errors are easy to misfile as something else, and why the exam probes the distinction so hard.
Each class maps to a different recovery
The whole point of naming the class is that the class dictates the response. A transient transport error or a rate-limit error is a candidate for retry, though with different timing. A tool-execution error may need the failure reported back to the model so it can adapt, or it may need a code fix. A model-output error is never fixed by retrying the identical call, it is recovered by reprompting with the validation error as feedback, or escalated when it cannot be resolved.
That mapping is the reason this knowledge point unlocks recovery strategy selection: classification is the input, strategy is the output. If you skip the classification step and apply a single blanket recovery to everything, you will inevitably apply the wrong one to some class. The exam rewards candidates who treat the two steps as a pipeline, identify the class, then select the matching recovery, rather than jumping straight to a reflex.
The exam traps
Misconception
Every API error is transient, so wrapping every call in a retry is a safe universal recovery.
What's actually true
The first trap the CCDV-F exam plants is the assumption that all errors are retryable. It is seductive because retries genuinely fix the two transient classes, so a blanket retry appears to work in testing. But a deterministic error, wrong input, a schema violation, an invalid argument, is deterministic precisely because nothing about the environment will change on the next attempt. The same input produces the same failure. Retrying it is not a recovery at all; it is a loop that always loses. The exam wants you to spot the deterministic error inside a set of failures and recognise that it needs a code or input fix, not another attempt.
Misconception
If the model gave me a wrong answer, my API integration must be broken.
What's actually true
The second trap is confusing a model-output error with an integration error. Because both can end with "the application did the wrong thing," candidates conflate them. The tell is whether the call succeeded. If the request completed and returned a structurally valid response, your transport, auth, and parsing all worked, the integration is healthy, and the fault lives in the content the model produced. Filing that as an integration bug wastes hours in the wrong layer. Recognising it as a model-output error points you at the right remedies: schema validation, a reprompt with the error, or escalation. Separating "the call failed" from "the content is wrong" is the single most important instinct this knowledge point teaches, and it is the same instinct that trace analysis and problem origin isolation formalises for multi-step agents.
Worked example: four failures, four classes
Worked example
A document-extraction service calls Claude to return structured JSON. Over one morning it logs four distinct failures, and the on-call developer must classify each before touching any recovery code.
The first failure is a Connection reset by peer raised mid-request. The call never completed, so this is a transport error, and because it is the kind of transient network blip that often clears on its own, it is a retry candidate.
The second failure is an HTTP 429 with a retry-after header. The request was fine and reached the API, but the account exceeded its per-minute token quota. This is a rate-limit error, a class of its own, and the remedy is dictated by the limit: wait and retry at a slower pace rather than hammering immediately.
The third failure comes from a lookup_customer tool the model invoked; the downstream database was unreachable and the tool threw. The Claude call itself succeeded and the model reasoned correctly, so this is a tool-execution error. It is an integration-surface fault, and the fix path is either repairing the tool or reporting the failure back to the model.
The fourth failure raised no exception at all. The response came back cleanly, but the JSON was missing the required invoice_total field, so schema validation failed. This is a model-output error: the call succeeded, the content is wrong. Retrying the identical request would just reproduce the same malformed output; the recovery is to reprompt with the validation error as feedback.
The instructive part is that all four surfaced in the same service and three of them could have been caught by a naive try/except that treats them identically. Only by naming each class does the developer see that one needs a plain retry, one needs a paced retry, one needs a tool fix, and one needs a reprompt. That is why classification is step one: the four failures share almost nothing except the moment they were logged.
How this is tested on the CCDV-F exam
Domain 4 carries 2.6% of the exam, and error type identification is where the debugging thread begins. A Task 4.1 item typically describes one or more failures, an exception message, a status code, a validation result, and asks you to classify them or to pick the correct first response. The credited answer names the class accurately; the common distractors apply a blanket retry to a deterministic error, or misattribute a wrong answer to the integration layer.
Read every failure scenario through two questions. First, did the API call actually complete? If not, you are in transport or rate-limit territory, and a 429 pins it to rate-limit. If the call succeeded, ask the second question: did a tool the model called fail, or is the returned content simply wrong? A failed tool is a tool-execution error; wrong-but-well-formed content is a model-output error. Getting to the right class quickly is what lets you then reach for the right recovery in recovery strategy selection, and it is why the exam sequences classification before remediation. When an option offers to retry a schema violation unchanged, treat it as a trap on sight; nothing about the next attempt will differ.
A Claude call returns HTTP 200 with a complete response, but the JSON is missing a required field and fails schema validation. No exception was raised. How should this failure be classified?
People also ask
What are the main error types in a Claude application?
Is every Claude API error safe to retry?
How do I tell a model-output error from an integration error?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.