Messages and delivery
Steering कतार
जब कोई सामान्य प्रॉम्प्ट तब आता है जब कोई सेशन रन पहले से स्ट्रीम हो रहा हो, तो OpenClaw
डिफ़ॉल्ट रूप से उस प्रॉम्प्ट को सक्रिय रनटाइम में भेजने की कोशिश करता है जब queue mode
steer हो। इस डिफ़ॉल्ट व्यवहार के लिए किसी config entry और किसी queue directive की
ज़रूरत नहीं होती। OpenClaw और native Codex app-server harness डिलीवरी
विवरण अलग-अलग तरीके से लागू करते हैं।
रनटाइम सीमा
Steering पहले से चल रही tool call को बाधित नहीं करता। OpenClaw model boundaries पर queued steering messages की जांच करता है:
- assistant tool calls मांगता है।
- OpenClaw मौजूदा assistant message के tool-call batch को निष्पादित करता है।
- OpenClaw turn end event emit करता है।
- OpenClaw queued steering messages को drain करता है।
- OpenClaw अगले LLM call से पहले उन messages को user messages के रूप में append करता है।
यह tool results को उस assistant message के साथ जोड़े रखता है जिसने उन्हें अनुरोध किया था, फिर अगली model call को नवीनतम user input देखने देता है।
native Codex app-server harness, OpenClaw runtime की internal steering queue के बजाय
turn/steer expose करता है। OpenClaw configured quiet window के लिए queued prompts को
batch करता है, फिर arrival order में collected सभी user input के साथ एक single
turn/steer request भेजता है।
Codex review और manual compaction turns same-turn steering को reject करते हैं। जब कोई
runtime steer mode में steering accept नहीं कर सकता, तो OpenClaw prompt शुरू करने से पहले
active run के finish होने का इंतज़ार करता है।
यह पेज normal inbound messages के लिए queue-mode steering समझाता है जब mode
steer हो। अगर mode followup या collect है, तो normal messages इस steering path में enter
नहीं करते; वे active run finish होने तक इंतज़ार करते हैं। explicit
/steer <message> command के लिए, Steer देखें।
मोड
| मोड | Active-run behavior | बाद का behavior |
|---|---|---|
steer |
संभव होने पर prompt को active runtime में steer करता है। | steering unavailable होने पर active run finish होने का इंतज़ार करता है। |
followup |
steer नहीं करता। | active run ends होने के बाद queued messages को बाद में run करता है। |
collect |
steer नहीं करता। | debounce window के बाद compatible queued messages को one later turn में coalesce करता है। |
interrupt |
active run को steer करने के बजाय abort करता है। | abort करने के बाद newest message शुरू करता है। |
बर्स्ट उदाहरण
अगर agent के tool call execute करते समय चार users messages भेजते हैं:
- default behavior के साथ, active runtime को उसके अगले model decision से पहले
arrival order में सभी चार messages मिलते हैं। OpenClaw उन्हें next model
boundary पर drain करता है; Codex उन्हें one batched
turn/steerके रूप में receive करता है। /queue collectके साथ, OpenClaw steer नहीं करता। यह active run ends होने तक इंतज़ार करता है, फिर debounce window के बाद compatible queued messages के साथ followup turn बनाता है।/queue interruptके साथ, OpenClaw active run को abort करता है और steering के बजाय newest message शुरू करता है।
दायरा
Steering हमेशा current active session run को target करता है। यह कोई नया session नहीं बनाता, active run की tool policy नहीं बदलता, और messages को sender के आधार पर split नहीं करता। multi-user channels में, inbound prompts में पहले से sender और route context शामिल होता है, इसलिए अगली model call देख सकती है कि हर message किसने भेजा।
जब आप चाहते हैं कि messages डिफ़ॉल्ट रूप से active run को steer करने के बजाय queue हों,
तो followup या collect use करें। जब newest prompt को active run
replace करना चाहिए, तो interrupt use करें।
Debounce
messages.queue.debounceMs queued followup और collect delivery पर लागू होता है।
native Codex harness के साथ steer mode में, यह batched turn/steer भेजने से पहले quiet window भी set करता है।
OpenClaw के लिए, active steering खुद debounce timer use नहीं करता क्योंकि OpenClaw messages को naturally
next model boundary तक batch करता है।
