The client-event vocabulary a full-duplex session accepts.
Seven of the seventeen are events OpenAI's Realtime API has no equivalent for, because they only make sense when the model and the user can talk at the same time: the user cuts in (barge_in), the client reports how much audio it played (playback.ack), a turn transition is signalled locally (turn.signal), input is abandoned without committing (input.cancel), text is pushed into a live turn (input.text.append), and the session is kept alive or closed explicitly (session.heartbeat / session.close). Two more are OpenAI commands carrying duplex-only fields (Tier 2).
The remaining eight are OpenAI's, unchanged, and re-exported from vllm_omni.protocol.realtime.commands rather than redeclared --- they are the same objects. They are re-exported so this module is the whole vocabulary and a duplex consumer never has to import the Tier 1 package directly; keeping them declared there means a GA-only consumer is still not handed events its clients never send.
None of these carries the engine's mailbox rendering: payload() and its channel live in vllm_omni.engine.duplex.commands, because for four of the seventeen the runner's channel is not the client event type at all.
dataclass ¶
Bases: RealtimeCommand
dataclass ¶
Bases: AppendAudio
Tier 2: OpenAI's input_audio_buffer.append plus the duplex hints.
OpenAI's append is just base64 audio. The duplex lane also lets a client declare this chunk's own format and rate, whether it believes the chunk is speech, camera frames captured alongside it, and its timing --- all additive, all ignored by a stock client. Empty audio with video_frames is legal when session capabilities allow video without required audio.
class-attribute instance-attribute ¶
dataclass ¶
Bases: RealtimeCommand
dataclass ¶
Bases: RealtimeCommand
dataclass ¶
Bases: RealtimeCommand
dataclass ¶
Bases: RealtimeCommand
dataclass ¶
Bases: RealtimeCommand
dataclass ¶
Bases: RealtimeCommand
dataclass ¶
Bases: RealtimeCommand
Graceful close requested through the command stream (session.close).
dataclass ¶
Bases: Commit
Tier 2: OpenAI's input_audio_buffer.commit plus duplex turn control.
OpenAI's commit carries nothing and always produces an item. Here a commit may be non-final, may decline to start a response, and may declare itself silence --- the semantic divergence documented in docs/serving/realtime_duplex_api.md ("Commit != response").
dataclass ¶
Bases: RealtimeCommand
conversation.item.create (history injection or function-call output).
dataclass ¶
dataclass ¶
Bases: RealtimeCommand
dataclass ¶
Bases: RealtimeCommand
dataclass ¶
One decoded OpenAI Realtime client event.
wire_type is the event type the client sent; the typed fields are what survived decoding, so a consumer reads them instead of re-parsing JSON.
There is deliberately no rendering method here. A server receives commands, it does not emit them, and how a runtime represents one internally is its own business --- the duplex engine renders its mailbox dictionary in vllm_omni.engine.duplex.commands.
dataclass ¶
Bases: RealtimeCommand
Generic turn.signal (local turn transitions such as user_started).