# The voice model refused the session The model refused to open or hold the session, so there was no voice to put on the call. Connect opens it once more on the same model and once on the fallback before giving the call up, and records that it restarted. Almost every case is a setting the chosen model does not accept — an option it refuses, an identifier in the wrong form, or a parameter that is invalid on an audio session. - **Status:** Available - **Audience:** both - **Channels:** phone - **In the app:** #/calls, #/phone-advanced - **Last verified:** 2026-09-10 - **Canonical:** https://connectbyjbrh.com/docs/troubleshooting/model-session-failed/ ## What it looks like Either the call rings and dies within a second or two, or the greeting is played and the conversation never starts. The record carries a session error rather than a conversation, and where a restart happened, the restart itself is on the record — which is the fastest way to tell a one-off from a configuration that cannot work. The clearest example in this system's history: a tuning call rang the line and then died immediately, every time, because of a single wrong character class in a model identifier. ## The three codes in plain language **1007** — The model rejected an option in the session. The known case is affective dialogue, which the default fast model refuses outright — it is only available on the older native-audio model. The Lab marks options of this kind by model rather than offering them everywhere. **1008** — The model identifier was not acceptable. In practice this is an identifier written in the path form used by the other hosting platform, or one that is simply malformed. Connect now refuses such an identifier as a bad model before the call, rather than ringing somebody and then failing. **1011** — The session failed internally, most often because a parameter that is legitimate on a text session is invalid on an audio one. A hard cap on output tokens, or thinking switched fully off, will do it on the native-audio model. Neither should be set on an audio session. > **Note** These are session close codes, not error messages about your account. None of them means the key is wrong; a rejected key produces a refusal at a different stage entirely, and is never retried because retrying cannot help. ## Causes, most likely first 1. **An option set for the wrong model.** The two models do not accept the same session options, and the fast default is the stricter of the two. 2. **A model identifier in the wrong form.** This is refused before the call now, which converts a dead call into a clear refusal. 3. **A parameter that is invalid on audio.** Output-token caps and disabled thinking belong to text sessions. 4. **A transient refusal from the service.** This is what the retry and the fallback exist for, and it usually leaves no trace beyond a restart on the record. 5. **A quota breaker already open.** On a rate limit or a revoked key the breaker opens, scheduled work is skipped, and a caller already on the line is still attempted — the breaker deliberately does not abandon a live conversation. ## What Connect completed - Attempted the session, then opened it once more on the same model, then once on the fallback model before giving up. - Recorded the restart explicitly, so a call that succeeded on the second attempt is not indistinguishable from one that never had trouble. - Ended the call rather than holding a caller on an open line with no voice behind it. - Attributed the ending to the engine, and booked the call's cost from its duration where the session reported nothing. ## What Connect did not complete - No conversation took place, so there is no transcript and no summary. - No lead and no follow-up were created from the call. - The setting that caused it was not changed. The retry and fallback rescue a call; they do not repair a configuration, and the next call will fail the same way. - No notification was sent per call. A repeated session failure shows up in line health, not as an alert on each one. ## What you can do 1. Read the call record for a session error and whether a restart was recorded. - Result: A restart followed by a normal conversation is a transient refusal and needs nothing. A failure with no successful restart is configuration. 2. Compare the line's settings with the model it is using. - Result: Options that exist for the older model and not the newer one are the single most common cause. 3. Place a test call from the Lab with the draft settings. - Result: The draft affects only that call, so you can prove a setting is the cause without changing the live line. 4. Revert the last setting change if the failures began with it. - Result: A line that worked yesterday and fails today rarely has a new fault; it has a new setting. ## What an administrator can do - Confirm the model identifier is in the plain form for the configured platform, not a path form for another. - Remove output-token caps and any fully disabled thinking budget from audio sessions. - Check whether the quota breaker is open — a rate limit produces a different pattern, where scheduled calls are skipped while live ones are still attempted. - Confirm the fallback model is available to the workspace, since it is the last thing tried before a call is given up. ## When to escalate Escalate when sessions fail on both the configured model and the fallback, or when failures persist after the settings have been matched to the model. Bring the close code, the model in use, and whether a restart was recorded. Do not paste raw provider responses containing session or project identifiers; the code and the model name are enough to act on. ## Questions ### Which model should we be on? The default is chosen for latency — roughly 0.6 s to first audio, against 1.2–2.2 s for the older native-audio model. It is also stricter, and its session is immutable, so mid-call notes and a supervisor's guidance cannot reach it. Move to the older model when steering a live call matters more than a second per reply. ### Does the fallback change how the call sounds? Yes — a different model has a different voice and a different pace. A call rescued by the fallback is a working call, not an identical one, which is why the restart is recorded rather than hidden. ### Is this the same as the model being out of quota? No. A rate limit or a revoked key opens a breaker: scheduled work is skipped and a caller already on the line is still attempted. A refused session is the model declining this particular session, usually over a setting. ## Related - [The call never rang](https://connectbyjbrh.com/docs/troubleshooting/call-never-rang/) - [Tuning the voice, end to end](https://connectbyjbrh.com/docs/workflows/voice-tuning-cycle/) - [Recovering a failed call](https://connectbyjbrh.com/docs/workflows/call-recovery/) - [The call ended early](https://connectbyjbrh.com/docs/troubleshooting/call-cut-short/) - [Phone and voice in Connect](https://connectbyjbrh.com/docs/phone/) ## What this page is based on - AGENTS.md §9a — model choice, session restarts and the fallback - PROJECT-STATE.md — realtime voice model behaviour, 2026-09 - Connect capability registry (docs-source/facts.py)