Performance Characteristics

How to interpret voice latency, scaling, emotion-analysis windows, API rate limits, and post-call processing behavior.

Operational characteristics for major platform subsystems. Unless a customer agreement says otherwise, the values on this page describe runtime controls or API limits rather than a service-level agreement.

Voice Pipeline Latency

The voice pipeline prepares first audio before or during conference setup where the call flow allows it, then records latency at multiple boundaries. It does not publish one universal first-message or speech-recognition latency guarantee.

End-to-end turn latency varies with the selected models, speech providers, tool dispatch mode, external integrations, audio quality, and network path. Per-call summaries expose observed engine and audio time-to-first-byte measurements rather than relying on one platform-wide average. Filler speech can acknowledge some processing gaps, and prompt caching can reduce repeated prompt processing where the selected model path supports it.

Per-Turn Processing Layers

Each conversational turn passes through five layers:

Layer	What Happens
STT processing	Audio converted to transcript text
Engine	Context graph navigation, state guidance, tool selection, and selected memory context
Render	LLM generates response text with emotional context
TTS generation	Text converted to speech audio with emotion parameters
Transport delivery	Audio delivered to the telephony layer

Scaling and Recovery

The voice runtime scales horizontally, but this documentation does not publish a universal workspace concurrency ceiling or throughput commitment. Capacity depends on the deployed region, voice path, provider quotas, and customer configuration.

On the data side, connector ingestion resumes from committed source checkpoints, allowing later polls to recover missed inbound changes. Automated outbound writes report failures and do not receive automatic reconciliation; approved idempotent proposals may retry under their separate delivery policy.

Emotion Detection

Parameter	Value
Acoustic outputs	Nine categorical scores plus dimensional valence and arousal
Audio segment size	2 seconds of voiced audio; sub-threshold silence is skipped
Rolling state	4 recent segments, approximately 8 seconds, with linear recency weighting
Rolling dimensions	Valence and arousal; dominance is not retained as an agent decision signal
Transcript analysis	Sentiment and toxicity, processed asynchronously
Speaker profile warmup	5 analyzed segments, approximately 10 seconds of voiced audio; observer data only
Compound window	5 caller turns
Empathy tier classification	Rule-based with no additional model call
Failure behavior	Analysis is best-effort and optional to the live reasoning path; repeated stream failures can disable it for the session

API Rate Limits

Platform API routes attach rate-limit policies individually. The following are current common policies, not a substitute for the contract and response headers on a specific endpoint:

Operation	Limit	Scope
Outbound call creation	1,000/min	Per credential and route
Conversation creation	60/min	Per credential and route
Common write policy	10/min	Per credential and route
Common read policy	60/min	Per credential and route
Default authenticated policy	100/min	Per credential and route

Outbound call creation has a higher route-specific limit for campaign and outreach fan-out. Rate-limit responses include Retry-After, X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset; clients should use those values rather than infer remaining capacity from a local counter.

Separately from rate limits, each workspace can register up to 100 test caller numbers.

End-of-Turn Detection

End-of-turn controls can be set at the service level and, on compatible recognition paths, overridden by a context graph state's turn policy. The thresholds balance responsiveness against the risk of cutting off a caller. Provider support and the speaking patterns of the target population determine useful settings.

Post-Call Processing

When transcript verification is enabled and a recording exists, an asynchronous job can create a second caller transcript with word timing and compare it with the live transcript. The result and comparison evidence are stored when processing succeeds. This optional artifact is not guaranteed for every call, is not guaranteed ground truth, and does not automatically replace transcription configuration or update keyterms.