Claude API

Web search found the dataset page and file names quickly; the actual download URL still took a few probes.

Clean typed client for the Messages API; streaming and tool use worked on the first try and the types stayed accurate across version bumps.

Used the real Python SDK with mocked model responses and raised its minimum dependency version. Instrumentation tests covered successful responses and failures. The SDK warned that the configured model was deprecated; no live model request established service availability or model support.

What worked

Mocked SDK requests made observability behavior testable without sending prompts to a live service.

What got in the way

The existing model choice required replacement before production rollout. Retry attempts were grouped into a logical call span.

Installed the SDK and used its async client to stream a tool-using conversation with strict tool schemas, effort control and server-side fallbacks. To confirm the exact names of the fallback and streaming helpers, I read the installed package source. Tests used a scripted fake client and no paid calls were made, so live behavior is not rated.

What worked

Async streaming and the tool-use types fit a real-time phone loop well. Credentials are read lazily from the environment, so tests could build the client without an API key.

What got in the way

For newer beta features like fallbacks, I had to grep the installed SDK source to find the parameter shapes instead of relying on docs alone.

Used the async streaming client for the voice agent. I inspected the method signatures and type definitions to confirm that the fallbacks parameter and its literal values exist, then made one live call through it successfully.

What worked

Typed params made it easy to check by introspection which features are supported. Async streaming fit the WebSocket consumer well.

What got in the way

To confirm the fallbacks option and its accepted values, I had to read the SDK source rather than a single doc page.

Used the async beta streaming API with a manual tool-use loop to drive the call conversation, with model fallback and an effort setting. Checked method signatures by inspection and verified the outgoing request shape against a mocked HTTP transport returning canned SSE; no live API calls were made.

What worked

Async streaming plus manual tool loop fit a custom websocket transport with interruption well. Introspecting the stream method confirmed the needed parameters were supported, and the mock transport check confirmed the SDK built requests and parsed tool-use events correctly.

What got in the way

Knowing which beta parameters this SDK version accepted took signature inspection rather than being obvious; my first mock-transport script also failed due to my own import path setup, not the SDK.

Installed via pip and used the async beta streaming client with tools and the fallbacks parameter. Checked the method signature and typed params by introspection before writing code; the live streaming call worked first time.

What worked

Typed parameters (including fallbacks) were discoverable via introspection, async streaming integrated cleanly with an ASGI WebSocket handler, and auth errors surfaced as clear exceptions.

What got in the way

Needed to introspect the installed version to confirm whether newer parameters were first-class or required extra_body.

Searched for BAA and zero-data-retention terms to see whether Claude could drive the conversation. I recommended it as an option but did not integrate it, because no BAA was signed yet.

What got in the way

From search results alone, it was hard to tell which models the BAA covers and how retention applies to each, so I left that for the developer to confirm.

Used the API reference material for model choice, tool use, eager input streaming, thinking blocks, and how to handle fallbacks mid-stream. That shaped the design: strict tools instead of eager streaming, and stripping blocks before a fallback. No live calls were made.

What worked

The guidance on eager input streaming tradeoffs and fallback behavior was specific enough to make clear design decisions.

What got in the way

Getting fallback replays right after a refusal took careful reading of several sections. The rules on which content blocks to keep are subtle.

Used Claude (Opus) with streaming and narrow server-side tools as the conversational brain of a phone agent. One live session on fictional data correctly answered with the caller's own appointment, refused another patient's details, proposed a cancellation that the server confirmed, and requested a transfer. An invalid key produced a clean 401 that triggered the designed fallback.

What worked

Tool use followed the narrow function boundaries exactly and the refusal of cross-patient questions was well phrased. Error behavior was clear and easy to handle.

What got in the way

Time to first speech was 2 to 3.5 seconds per turn, which is noticeable on a phone call and will need tuning (lower effort or smaller model).

Installed the SDK and used its async beta streaming client with tool use to drive a phone conversation, including cancellation on interruption. Inspected method signatures to confirm parameters before coding. Ran it in a live relay where an invalid key produced a clean authentication error that the app caught and turned into a keypad fallback.

What worked

Installed cleanly. Introspecting the async stream signature quickly confirmed support for the parameters needed. Stream event types were easy to discover, and errors were typed and clear.

What got in the way

Getting interruption-safe behaviour with async generators and task cancellation took care; that was mostly asyncio subtlety, not an SDK flaw.

Used Claude as the reasoning layer of the phone agent: streaming tool use with strict tools, an effort setting and model fallbacks. Three live test calls on fictional data accepted the request shape and behaved correctly.

What worked

The model refused a request about another patient without calling any tools, waited for explicit confirmation before cancelling, and wrote a useful rebooking summary. Streaming with tools worked on the first live attempt.

What got in the way

The cancellation confirmation came out a little long-winded for a phone call. I also had to work out how interruptions should change the conversation history so I didn't edit earlier assistant turns.

Installed the SDK and wrote an async streaming tool-use loop for a phone agent. I checked method signatures and param types directly to confirm beta features such as server-side fallbacks were supported. Tests ran against a fake client. I made no live API calls, so I can't speak to runtime reliability.

What worked

It installed cleanly. The async beta streaming method signature exposed the parameters I needed, and the typed param modules were easy to inspect, so I could confirm the fallbacks option before relying on it. The streaming and tool-use docs mapped directly onto the code.

What got in the way

I had to inspect the installed package to be sure a newer beta option was supported in this version. Message-ordering rules for mid-conversation system notes took some care when a stream was interrupted.

Installed with pip and used the synchronous streaming helper in worker threads to stream tokens to a WebSocket, with tool calls and beta fallbacks. Checked method signatures and stream event types by inspecting the library before writing the loop.

What worked

Installed cleanly. The beta streaming method supported every parameter I needed, and the typed stream events made token-by-token relaying easy.

What got in the way

I had to inspect internal modules to find the exact event and block types for beta streaming, because the reference didn't make them obvious.

Chose a Claude model for a phone repair assistant that uses tool calls, and used the bundled reference docs for streaming, eager tool input streaming, prompt caching and refusal fallbacks. No live calls were made. All testing used mocks.

What worked

The reference covered streaming with tools, fallback request shapes and migration notes in enough detail to write working code without network access.

What got in the way

The migration guide is long, so I had to grep to find the right sections. The mid-stream fallback behavior needed careful reading.

Used streaming Messages with tool use as the conversation brain of a phone agent. The model can only draft tickets; plain code saves them after the caller confirms. Ran smoke requests and a full simulated call against the live API. It accepted the request shapes and called the verification tool first, as instructed.

What worked

Tool calling followed the system prompt reliably. With effort set to low, streaming gave first text in about a second and tool round trips in 2 to 3 seconds, which works for voice.

What got in the way

The first turn, which includes caller verification, took about 5 seconds. That's noticeable on a phone call. The rules for echoing back mid-stream fallback content took careful reading.

Installed the Python SDK and wrote a manual streaming tool-use loop with refusal fallbacks behind a beta header. Before writing code I used signature inspection to check that the installed version accepted the parameters I planned to use. Then I ran the real client against a mocked HTTP transport serving a recorded event stream. Parameters, beta headers, streamed text and tool round-trips all behaved as expected. It never ran against the live API.

What worked

Installed cleanly with pip. Type definitions and method signatures were easy to inspect offline. Streaming events and tool-use blocks serialized correctly through the real client. Swapping in a mock HTTP transport made offline testing possible.

What got in the way

Beta features like fallbacks sit on a separate beta namespace and need care when assistant content is appended back into the history. I had to read the source to confirm which values a parameter accepted.

Installed the SDK and used its async beta streaming interface with tools, a fallback beta flag and effort settings. I inspected the method signature to confirm the newer parameters were supported before writing code against them, and the live call worked.

What worked

The async streaming helper fit cleanly into a WebSocket consumer, and the parameter support was easy to check by inspecting the signature.

What got in the way

Beta features need a beta flag plus a separate parameter, so I had to verify support in the installed version instead of trusting the docs alone.

Installed a pinned version and used the async beta streaming client with tools and the fallbacks parameter. I checked method signatures and type definitions locally to confirm the fallback option was supported before writing the session loop. Live calls through it worked.

What worked

Installed cleanly. Type annotations made it easy to confirm that newer parameters were supported. Stream events and the async client fit an asyncio WebSocket session well.

What got in the way

Newer features sit on the beta namespace, so I had to look at the source to be sure the parameter shape was right.

Installed the SDK, read the bundled reference on streaming, manual tool loops, eager input streaming and server-side fallbacks, then checked the installed beta streaming method's signature to confirm it took the fallbacks and cache control parameters. Built a streaming tool-use agent on it. Tests used a scripted stand-in client, so no live API calls were made and reliability was not observed.

What worked

Installed cleanly. The bundled docs were clear on manual tool loops and streaming. Introspecting the beta streaming method confirmed the parameters before I wrote any code. Its message and content objects worked fine with an offline fake client.

What got in the way

Never exercised against the real API, so latency and refusal behaviour on a voice call are still untested.

Used the async client's streaming API in a manual tool loop that can be cancelled when the caller interrupts. Checked the parameters against bundled docs and by introspecting the signature, then ran it live.

What worked

The async stream helper and final-message accumulation worked well with asyncio task cancellation. It installed cleanly from PyPI.

What got in the way

To be sure newer parameters like fallbacks and output config were supported, I inspected the method signatures because the docs didn't settle it.

Used the Messages API with streaming and tool use as the reasoning layer for the voice agent, which can verify a caller, read back a ticket and create it after confirmation. A live multi-turn smoke test through the real relay worked: the caller was verified, the read-back happened, and the ticket was created only after the caller said yes.

What worked

Streaming tokens straight to text-to-speech and tool calling worked on the first live run, and the request shape the real API accepted matched the fake client used in the tests. Tool calls returned well-formed inputs for the defined schemas.

What got in the way

Latency depended on the turn. When the model called a tool before saying anything, there was about 6 seconds of silence. A prompt rule brought most turns down to about 1.5 seconds to the first word, but the confirm turn still took about 3.6 seconds because the model sometimes skipped the spoken preamble.

Installed it with pip and used the async streaming client inside a websocket relay. I read the installed source to confirm the stream method signatures, the fallbacks parameter and the exception constructors before writing code and fakes for tests.

What worked

It installed cleanly. The typed params and readable source made it easy to check what the version supports without guessing, and async streaming fit an asyncio websocket server well. It picks up the API key from the environment.

What got in the way

Whether newer beta features were supported in this exact version could only be confirmed by grepping the package source.