Skip to main content
Most Prism errors do not end the conversation. Prism sends each error as an error event on the open connection, and refuses or drops only what the error names. Only a closed connection ends the conversation. This page uses the event names of the WebSocket API. The Rime SDK reports the same codes as fault.code, on its error events and on RimeRealtimeError. The Prism SDK reference lists the SDK’s other error classes.

Read an error event

Prism sends this error when a session.update sets temperature, a field that Prism does not accept:
Branch on code and scope, never on message. Errors in the WebSocket reference describes every field.

Error codes

Each code below is an invalid_request_error, unless the table says server_error. A request that you send again on the same connection gets the same error, unless the table says to resend.

Setting up the session

Messages and audio

Requested replies

response.create asks for a reply without new speech: a typed turn, a tool continuation, or a nudge, which makes Prism speak first.

Tool calls

Tools explains the whole round, and Report a result later covers a late result.

History and playback reports

Caller speech

Reply failures

Each of these codes has scope response, so the conversation continues. All codes except context_length_exceeded are a server_error. Only capacity_exceeded, response_timeout, and unavailable can succeed when you send the same request again.

Ending the conversation

Connection refusals

Before the WebSocket opens, Prism can refuse the upgrade with an HTTP response, and no error event follows. The Rime SDK raises RimeAuthenticationError for a 401 and RimeUnavailableError for the other refusals.

Close codes

After a reconnect, send session.update again, and add the history that the agent needs with conversation.item.create messages, as Start from an earlier conversation shows.

Limits

Common problems

Every audio message gets session_not_initialized

Prism has not accepted a session.update yet. Send one before any audio. If an error refused it, fix what that error names.

Prism never answers the caller

Keep sending audio after the caller stops, because Prism finds the end of a turn from the silence. Also send 16 kHz audio, or let the Rime SDK convert it.

Replies keep stopping partway

The caller’s microphone can pick up Prism’s voice from a speaker, and Prism can take that audio as an interruption. Each false interruption starts with input_audio_buffer.speech_started while a reply plays. Use headphones when you test, and echo cancellation in production.

Replies sound too slow or too fast

Play Prism’s audio at 24 kHz. A player set to 16 kHz plays it slow and low, and one set to 48 kHz plays it fast and high.

Phone audio crackles

Send each reply to your telephony provider at a steady pace, as Phone audio shows. Uneven pacing makes the caller hear crackles.

A tool ran, but Prism said nothing

Prism does not continue after a tool result on its own. Ask for the continuation, as Tools shows.

The connection closes without an error

Check for messages larger than 1 MiB or a server message that Prism could not deliver within 10 seconds. See Close codes for these connection limits. A close after session.idle_timeout is the 5-minute idle close.

Report a problem

Email support@rime.ai these items from the failed conversation: Do not put your API key in the report.

Before production

  • Your API key is only on your backend.
  • Your backend runs in or near US East, close to Prism.
  • You pin your SDK version.
  • Your client reads events on their own task, so a slow tool cannot delay them. The SDK ends the session when 256 events wait unread.
  • Your application reports what the caller heard after each interruption.
  • Each tool is safe to run once. Your code never runs a call again when its outcome is unknown.
  • You log the request ID, the session ID, and the correlation_id of every error.
  • Each error code has a handler.
  • Your backend retries a 503 refusal after a backoff.