OpenAI Decisions API Voice: Fix Late Results in 2026
A corrected sentence can arrive before the answer to the sentence it replaced.
October 23, 2026
The voice integration in OpenAI's Decisions API lets apps respond to transcript updates while a person is speaking. The docs warn that results may arrive out of order. Apps need to match each result to its transcript and ignore results that no longer fit the conversation.[1][2]
That warning should be read alongside the launch's speed claims. OpenAI announced general availability on October 22. TechCrunch covered the growing decision-model market that day.[3][4] The story stayed on Techmeme's front page on October 23.[6] Anyone building voice input should ask: what happens when an answer arrives after the speaker has changed their mind?
I'm looking at this from DictaFlow, so my interest is practical. People pause, correct names, and revise sentences halfway through. A microphone interface needs to make room for that. This article looks at the published documentation, not results from hands-on testing of the new API.
The late answer can belong to an earlier sentence
Picture a task board you control by voice. This is a made-up example, not a reported failure. You say, "Move the launch task to Friday," then add, "Wait, keep it on Thursday. Friday is the review."
The app starts processing the first phrase, then sends another request after you correct yourself. The second answer arrives first, so the board shows Thursday. Then the older answer comes in and changes the task back to Friday. Both requests may have worked correctly, but the board still ends up showing the opposite of what you last said.
OpenAI's voice guide says Live can combine pending transcript deltas, and results can arrive out of order. It tells them to match each result to its source event and use the newest relevant result for each direction.[2] Test this during integration, even if the first demo looks smooth.
Using whichever answer arrives last would fail in our example. The app needs to know the order of the speech and whether each answer is still relevant. An answer may be out of date by the time it appears on the screen.
What the new integration changes
The Decisions API returns answers within set limits, such as a probability, a choice from given options, or a score. OpenAI describes it as a tool for classification and routing. Its documentation separates those tasks from writing an explanation or creating a custom object.[1]
Its built-in GPT-Live integration lets Live call Decisions directly, without sending the request back through the app. Developers can set up delegation or respond to changes in the input and output transcripts.[2] This keeps small decisions close to the conversation, but developers need to define what a partial utterance can change.
OpenAI's October 22 launch example shows transcript updates animating an avatar. I read the announcement as archived on October 23 at 13:04 UTC and checked the current developer guide.[4][2] A brief change in expression makes a useful demo. Moving a deadline can have different consequences.
The launch makes a strong case for cutting delays in conversational software. But developers still need to decide what the app does with speech before a person finishes. I would keep visible suggestions easy to replace and wait for a clear completion signal before saving a task change. That is a proposed design, not a guarantee from the API.
Keep the transcript version beside the proposed change
For the task-board example, label the speech being evaluated with a version and keep it next to the proposed date. When an answer comes back, compare it with the current turn before updating the task. If the user has corrected the request, discard the old proposal or evaluate the revised request.
Don't treat a model's confidence as a timestamp. A confident answer to the Friday phrase still reflects that phrase. It tells you nothing about the later correction unless the request included it.
A documented trigger event records the source event ID, trigger ID, and source event type.[2] These details link the result to the transcript update that caused it. The app still has to work out how that update fits into its task state.
In a prototype, I'd show the proposed date without saving it right away. The person could finish speaking and see which task it would change. If they select a second task during the pause, the proposal should stay with the first task or expire. Applying it to whichever card is open would cause another timing bug.
A release button, a clear confirmation, or an app-specific rule for ending a turn can show that someone is done. Pick a signal people can understand. Test silence with people who pause to think, especially if the app is meant to reduce the work of typing.
Test a correction while an older request is still pending
In a controlled test harness, hold back the answer to the first phrase until the correction has been processed. The final saved task should still be set for Thursday. Record each transcript version and returned answer so you can trace any failure.
Then test a cancellation: "Change the title to launch review. Cancel that, leave the title alone." The task should keep its original title. A canceled change should not come back after a delayed answer finishes.
Repeat the request with a long pause before saying "Wait" and correcting the date. This checks how the app decides a task is complete. If it has already saved Friday, it should make that clear and respond to the correction directly. A quiet save followed by a cheerful reply would leave the person unsure which date the task actually holds.
Also, test what happens if the connection drops after a proposal appears. After reconnecting, check whether the app says the change was saved, is still pending, or failed. A returned classification does not prove the change succeeded. Read the task record back to confirm.
Measure how long it takes for the correct state to appear after the speaker finishes correcting a mistake. Track request latency separately. This shows whether a faster classifier speeds up the whole interaction, including recovery from mistakes.
For writing, editable dictation is a simpler boundary
Someone dictating a project note may just want the words in an editor. Intent detection and task changes could make the software do things they never asked for. Let them finish their note.
DictaFlow lets you hold a hotkey, speak, and release to place text where your cursor is. Its current product docs describe native desktop and mobile apps, along with tools for adding recurring terms to its vocabulary.[5] That makes it useful for speaking a draft into an app you already have open. The recommendation here concerns editable text, not a claim of Decisions API integration or task-board automation.
For a daily work note, speak the explanation, check the dates in the text, and save it with the host app's controls. A team building a voice-controlled task board has more to check before shipping. They should intentionally delay the first answer to a Thursday-and-Friday request, then check the saved task after both answers arrive.
Sources
[1] OpenAI Decisions API guide
[2] OpenAI: Connect voice to Decisions
[3] TechCrunch: Decisions API general availability
[4] OpenAI announcement, archived October 23 2026 at 13:04:04 UTC