CCARF Practice Question

Paper 5 · Question 14

D4 Prompt Engineering & Structured Output · Paper 5

[Scenario: Claude Code for Continuous Integration] Your code review component is iterative: Claude analyzes the changed file, then may request related files (imports, base classes, tests) via tool calls to understand context before providing final feedback. Your application defines a tool that lets Claude request file contents; Claude calls the tool, gets results, and continues analysis. You’re evaluating batch processing to reduce API cost. What is the primary technical limitation when considering batch processing for this workflow? What is the primary technical limitation?

• A.Batch processing does not include correlation IDs to map outputs back to input requests.
• B.The asynchronous model cannot execute tools mid-request and return results for Claude to continue analysis.
• C.The Batch API does not support tool definitions in request parameters.
• D.The batch processing latency of up to 24 hours is too slow for pull request feedback, although the workflow would otherwise function.

Show answer & explanations

Correct answer: B

A: The Batches API correlates results with custom_id. Missing IDs are not what breaks this loop.

B: A “fire-and-forget” asynchronous Batch API model has no mechanism to intercept a tool call during a request, execute the tool, and return results for Claude to continue analysis. This is fundamentally incompatible with iterative tool-calling workflows that require multiple tool request/response rounds within a single logical interaction.

C: A batch request can include tool definitions. Nothing in the batch can run the tool and return the result so Claude can continue.

D: A 24-hour wait is a reason to keep PR review synchronous, but the limitation asked for here is the missing tool round trip, which a slower batch still cannot do.

Related Prompt Engineering & Structured Output questions

More: Paper 5 · All practice questions