Configure

Streaming:Flux

Real conversations aren’t static. A call that starts with casual confirmation (“Can you verify your name?”) shifts to strict authentication (“Please say your 6-digit PIN”) and then to open-ended troubleshooting. Conversations evolve through discrete sections, intents, and steps—each with different demands on your speech recognition system.

The Configure control message enables you to adapt Flux’s behavior mid-stream as conversational context evolves, without disconnecting and reconnecting. This is essentially context injection for speech recognition: you inject the specific vocabulary, turn detection behavior, and timing parameters needed for each phase of the conversation.

The ASR behavior you want at minute one isn’t what you want at minute three. With dynamic configuration, you can:

Dynamically bias toward task-critical phrases. Collecting a customer’s name? Add it to keyterms right before you ask. Moving from appointment scheduling to pharmacy? Swap in medication names and medical terminology. Handling a product inquiry? Load the specific product names and feature terminology relevant to that conversation. You’re no longer stuck with a generic keyterm list that’s “good enough” for the whole call or loading hundreds of irrelevant terms upfront.

Adjust turn detection for critical flows. When you’re collecting a password, OTP, or account number, you don’t want Flux cutting off the user mid-utterance. Increase eot_timeout_ms and eot_threshold values for that segment to allow longer pauses and wait for higher confidence before detecting turn end, then decrease them when you’re back to natural conversation.

Switch number formatting per step. Turn on numerals right before you ask for a PIN, phone number, or order number so the transcript returns digits (“4 8 1 5”), then turn it off when the conversation returns to free-form speech.

Reduce engineering complexity. Without dynamic configuration, changing ASR behavior mid-call meant reconnecting (dropping audio, managing state transitions) or worse, managing multiple concurrent streams and swapping between them. That’s a state machine you never wanted to build and definitely don’t want to maintain. Configure gives you one connection with dynamic behavior.

Configuration updates are processed in order with your audio stream and take effect immediately when processed. The stream continues uninterrupted, and you receive confirmation of successful updates via ConfigureSuccess messages.

You can update the following parameters mid-stream:

All parameters are optional in a Configure message. Omitted parameters retain their current values.

Thresholds must be nested under a "thresholds" object. Individual threshold properties can be sent without including all three.

{
  "type": "Configure",
  "thresholds": {
    "eot_threshold": 0.8,
    "eot_timeout_ms": 5000
  }
}

Returned when configuration update is successfully applied. Returns the full active configuration, including fields you didn’t change.

{
  "type": "ConfigureSuccess",
  "thresholds": {
    "eager_eot_threshold": 0.4,
    "eot_threshold": 0.7,
    "eot_timeout_ms": 6000
  },
  "keyterms": ["apple", "banana", "orange"],
  "language_hints": ["en", "es"],
  "profanity_filter": false,
  "redact_usage": false,
  "numerals": true
}

Returned when configuration update fails validation. The stream continues with the previous configuration.

{
  "type": "ConfigureFailure",
  "request_id": "01a0e80f-3782-7413-afc3-091fabadf0a8",
  "sequence_id": 1,
  "code": "UNPARSABLE_CLIENT_MESSAGE",
  "description": "eager_eot_threshold cannot be greater than eot_threshold."
}

Key timing behaviors:

• Updates apply immediately when the Configure message is processed
• Updates persist until the stream ends or another Configure message is sent
• Turn boundaries do not affect when updates take effect
• Already-transcribed audio is NOT reprocessed with new configuration

Example:

Initial keyterms:    ["apple", "banana", "orange"]
Configure with:      {"keyterms": ["grape", "kiwi"]}
Result:              ["grape", "kiwi"]
                     // "apple", "banana", "orange" are REMOVED

To add terms while keeping existing ones, retrieve the current keyterms first (via application state tracking or the initial configuration), then send a Configure message with the combined list.

Different behaviors apply when you omit fields versus explicitly clearing them:

Configure messages are validated using the same rules as initial connection parameters:

• eager_eot_threshold must be ≤ eot_threshold (if both are specified in the message)
• Threshold values must be within valid ranges
• Keyterms array must contain ≤ 100 terms
• numerals must be a JSON boolean (true or false)

Important: A failed Configure message (returning ConfigureFailure) does NOT affect the stream. The connection continues with the previous configuration unchanged. Schema errors are the exception: a message that fails schema validation closes the connection (see the warning below).

Flux STT applies all fields in a Configure message together or not at all. If one field fails, such as an invalid keyterms list sent alongside numerals, none of the fields take effect.

• Configuration Parameters - Complete reference for all Flux configuration options
• Keyterm Boosting - Detailed guide to using keyterms for custom vocabulary
• State Messages - Understanding turn detection and state transitions
• Getting Started with Flux - Quickstart guide with basic configuration
• Close Stream - Close the WebSocket stream
• Force End Turn - End the current turn immediately from an external signal