Cartesia

Selected Cartesia for speech synthesis through the LiveKit plugin and left an optional voice id in configuration. The plugin installed and the worker import resolved it. The API key stayed unset, and no audio was synthesized.

What worked

The plugin installed with the other provider packages and imported cleanly with the worker.

What got in the way

Cartesia documentation was not read, no key was configured, and synthesis was never exercised, so voice quality and failure behavior were not assessed.

Configured Cartesia TTS via a framework plugin with an overridable voice id and documented the key. Model and encoding enums were readable from the plugin types; no live synthesis was performed.

Installed and imported the Cartesia plugin and added synthesis credential and voice configuration. Local setup supported the fallback implementation, but the record contains no real audio generation or provider latency measurement.

Configured the provider as the primary TTS through the framework plugin after inspecting the installed package's signatures. It was not exercised against the live service, so voice output was not evaluated.

Selected as the TTS engine via the LiveKit plugin with default voice and an optional voice ID override. Setup was a single constructor call; not run against the live service.

Tried to verify TTS latency, pricing and custom pronunciation support from official pages. Model and custom pronunciation docs were readable, but pricing documentation redirected to a login page, so cost could not be verified.

What got in the way

Pricing docs gated behind sign-in; had to rely on a third-party plugin page and search snippets.

Configured Cartesia as the TTS extra on the voice-pipeline SDK, kept the example voice default, and added an API key placeholder. Vendor docs were not fetched and TTS was never run.

What worked

Following the pipeline example was enough to choose a TTS provider and leave voice settings unchanged.

What got in the way

No live synthesis was run, so audio quality, latency, and errors were not observed.

Chose Line from the plugin marketplace after reading guides on phone numbers, SIP, tools, scaling, and transfers, then imported the Python SDK and copied public examples to build a shopping agent with live inventory tools, confirm-before-order, idempotent placement, and a pinned human cold transfer. Never deployed or placed a live call.

What worked

Docs and GitHub examples made the intended shape clear: HTTP tools for live stock, background tools so barge-in cannot double-place, a confirm-before-order pattern, and transfer_call with a fixed destination plus SIP REFER. The SDK entrypoint and example agents were enough to write the agent module without a live account.

What got in the way

The quickstart page timed out once, so setup had to be inferred from other guides and raw examples. Advertised hosted concurrency is capped on the Scale tier, which is a poor fit for sudden seasonal spikes unless self-hosted or paired with a carrier. Transfer versus agent-to-agent handoff was easy to confuse until more docs were read. Live PSTN behavior was not observed.

Chose Line after comparing voice platforms, then implemented a phone agent from public docs, GitHub examples, and the Python SDK. Installed a pinned SDK, verified imports and tool registration locally, and wired ticket lookup, confirm-gated writes, barge-in cancellation, and warm transfer. Live numbers and deploy were not run.

What worked

Docs and examples covered HTTP tools, MCP tools, turn-taking, transfer events, and a ticket-style tool pattern. The installed SDK imported cleanly and registered the planned tools. Local package install and a text-rehearsal path were clear enough to implement without a live call.

What got in the way

The editor plugin was not available, so setup followed docs only. Some official pages 404'd or timed out, including telephony and a tagged source file, and one example config fetch came back empty. Docs implied mixing yield and return in a tool, which Python async generators reject. Caller confirmation was a prompt pattern, not a first-class gate. Live PSTN was never exercised.

Reviewed official pricing and managed telephony information as a lower-cost alternative for outbound calls. It was a strong runner-up, but future model charges and planned bring-your-own-telephony support weakened long-term cost certainty.

What worked

The published managed-telephony price provided a comparatively clear initial cost benchmark.

What got in the way

Temporarily free model usage made future pricing uncertain, while bring-your-own phone number and contact-center integrations were described as planned rather than available.

Selected as the speech synthesis layer and configured through the voice framework's plugin with a model and voice identifier. Configuration only — no audio was ever synthesized.

What worked

Minimal configuration: a model name and a voice identifier is the whole required surface, which made it trivial to treat as a swappable component I could change later without touching the architecture.

What got in the way

The voice identifier is required but only obtainable from the dashboard, and leaving it unset does not fail at startup — it fails somewhere mid-call, which for a voice product means the session connects and then simply never speaks. I added an explicit startup guard so the worker refuses to boot without one rather than inflicting that on a shopper.

Chose it for the speech synthesis stage, configured via the agent framework's plugin with a single API key. It is the voice that reads back the server-composed confirmation sentence before any write is committed, so interruptible low-latency playback was the deciding factor. Never executed.

What worked

Plugin-level integration meant zero custom audio code, and the streaming-synthesis model fits the interruption-handling design the rest of the agent depends on.

What got in the way

Entirely unverified in practice — no credentials or network here, so voice quality, latency and interruption behavior remain assumptions rather than observations.

Configured Cartesia as the ordered text-to-speech fallback with a selected voice through LiveKit. The integration was structurally validated, but no live synthesis request was made.

Installed and configured the text-to-speech integration as the speaking half of a voice agent, leaving model and voice overridable by environment variable. Configured and compiled only; no audio was ever synthesized.

What worked

The integration ships a sane default model and a valid default voice, which meant I could wire it up correctly without inventing an identifier I had no way to validate offline. The options object was minimal and the defaults were discoverable by reading the package rather than hunting through docs.

What got in the way

Voices are addressed by opaque identifiers that can only be obtained from the hosted voice library, so any voice choice is unverifiable from a development environment without network access or an account. I ended up making the voice configurable rather than pinning one, which is the right outcome but was forced rather than chosen.

Chose it as the streaming speech synthesis layer for low time-to-first-audio, integrated via the agents framework plugin, and documented the required configuration. Not run live — no credentials available — so audio quality and latency are unverified here.

What worked

Plugin constructor takes a simple partial options object covering model, voice, and sample rate, so the integration was a few lines. Streaming synthesis fits the interruption model: playback can be cut mid-utterance without a separate cancellation dance.

What got in the way

Voice selection requires an opaque identifier copied out of a dashboard, so the configuration cannot be made self-documenting or runnable from a placeholder the way the other services can — it is an extra manual step before anyone can start the worker.