GPT-6 Steering Is Not a Stop Button

OpenAI's new mid-turn steering lets you redirect a running agent. It does not let you stop one. Here is where the brake actually lives.

Every agent interface eventually grows a box where you type "wait, not that." OpenAI just made that box official for the GPT-6 family, and the documentation contains a sentence most people will skim past: steering does not "cancel tools that have already started."

Read that twice. The feature that looks like a steering wheel is closer to a note you slide under the driver's door.

On October 2, OpenAI published A practical guide to building with GPT-6, and one of its headline capabilities is mid-turn steering: "Mid-turn steering lets you send a correction through the Responses WebSocket API while the model works." The same guide adds the caveat in plain words. "Updates are queued; they don't cancel running tools or undo completed actions."

That is an honest design. It is also the kind of detail that turns into an incident report when a team wires steering into a product as if it were an abort button.

Why this matters more than it sounds

Long agent runs are the whole point of the GPT-6 pitch. The guide talks about compaction for longer conversations, asynchronous tool calling so "the model continue[s] independent work while your app runs a slower task, such as tests," and a beta multi-agent mode where GPT-6.1 Sol can "assign independent work to subagents" and merge the results.

Longer runs mean more moments where a human watching the trace sees something wrong. The agent is about to migrate the wrong table, email the wrong list, or delete the branch you still needed. The natural reaction is to type a correction. Steering is now the documented way to send it.

My position is simple: steering is a good feature with a dangerous name. "Steer" implies control over the vehicle. What OpenAI built is control over the next decision. Anything already in motion stays in motion, and your architecture has to account for that, because the API will not.

What steering actually does

The mechanics are in OpenAI's steering guide, and they are worth knowing exactly.

You send a response.steer event over the WebSocket connection with three fields: the event type, the previous_response_id of the run you want to redirect, and an input that can be a string or a nonempty array of user messages.

The server answers with response.steer.accepted. That event confirms your correction is queued. It does not confirm anything has changed.

Then the timing rule: "the server finishes the current output item and any hosted tool work already running" before it applies your update. A new response is created automatically, unless the run is waiting on tool results or approvals. If steering is waiting on required inputs, such as tool results your app owes, you get response.steer.pending, and the queued steer applies once you send those inputs back.

And the boundary, verbatim: "Steering does not rewrite output already sent to your application, undo earlier actions, or cancel tools that have already started."

Two more constraints matter in practice. Steering works only with the GPT-6 family over a WebSocket connection to the Responses API. And if corrections pile up faster than the run can absorb them, the API returns a too_many_pending_steers error.

Put those together and the picture is clear. Steering changes what the model decides next. It has no authority over what is already executing.

The two kinds of tool calls, and why the difference is everything

Here is the part that makes this manageable instead of scary.

Function tools, the ones you define, do not run on OpenAI's servers. OpenAI's function calling guide is explicit that your application executes the call and returns the result. The model emits a call, and your application decides whether to execute it. That means for every function tool, you already own a stop button. It is the code path between "the model asked for this" and "my executor ran it."

Hosted tool work is different. The steering docs say the server finishes hosted tool work already running before applying your correction. For anything OpenAI runs on your behalf, a mid-flight correction arrives after the fact.

So the real question for any GPT-6 agent is not "can I steer it?" It is "where is the last checkpoint before a side effect, and do I control it?"

I find it helps to sort every tool an agent can call into one of three buckets:

Read-only. Search, file reads, queries without writes. Steering lag costs you a few wasted tokens. Let these run.
Reversible writes. Draft emails, branch commits, staging deploys. A late correction is annoying but fixable.
Irreversible writes. Production migrations, payments, outbound messages, deletes. A late correction is an apology.

Bucket three is where steering cannot be your safety story. Those calls need a gate that runs before execution, every time.

What about cancel?

OpenAI does document a real cancel for background-mode responses: POST /v1/responses/{id}/cancel, with the background guide noting that cancelling twice is idempotent and simply returns the final response object.

What that page does not say, at least in the version read for this piece, is what happens to a tool call that is already executing when you cancel. It also does not say whether cancel works the same way over WebSocket mode. I would not assume either. Treat cancel as "stop generating new work," and assume anything already dispatched may complete.

Put this into practice

The lowest-friction fix is an executor that checks a flag before it runs anything with side effects. If you already have a function-calling loop, this is an afternoon.

1. Add a run-level halt flag your executor reads before every side-effecting call. When a human hits "stop," set the flag first, then send the steer or cancel. The model may still emit the next call. Your executor refuses it.

SIDE_EFFECTS = {"run_migration", "send_email", "delete_branch", "charge_card"}

def execute(call, run_state):
    if call.name in SIDE_EFFECTS and run_state.halted:
        return {"error": "halted by operator", "executed": False}
    if call.name in SIDE_EFFECTS and not run_state.approved(call):
        return {"error": "awaiting approval", "executed": False}
    return TOOLS[call.name](**call.arguments)

Returning a structured refusal matters. The model sees that the call did not happen and can plan around it, instead of assuming success.

2. Put irreversible tools behind approval, not behind steering. The GPT-6 guide tells you to state "which actions can proceed independently and which require approval." Do that in code, not only in the prompt. A prompt rule is a request. An executor rule is a fact.

3. Keep slow, risky work out of asynchronous tool calls. Async calling is great for tests and builds. For a migration, you want the model waiting on the result, so nothing downstream starts before a human sees it. The guide itself says to wait for a result "before starting work that depends on it."

4. Log response.steer.accepted and the response that actually applies it as two separate events. When someone asks "I told it to stop at 14:02, why did it run at 14:03?", your trace should show the gap.

5. Handle response.steer.pending in your UI. If steering is waiting on inputs your app owes, your correction is waiting on you. A UI that shows "steer sent" while the steer is actually blocked on your own app will confuse every operator who uses it.

6. Throttle the steer box. Rapid-fire corrections hit too_many_pending_steers. One clear correction beats five panicked ones anyway.

The prompt side of the same lesson

The guide carries a second line that pairs well with this one: "overly specific guidance can now hinder results where it previously helped." Many teams respond to agent mistakes by piling rules into the system prompt. GPT-6 is the vendor telling you that habit now has a cost.

Read the two lines together and a cleaner split appears. Use the prompt for intent and judgment. Use the executor for hard limits. Steering lives in between, as a way to update intent mid-run. None of the three replaces the others.

Honest limitations

This piece rests on OpenAI's documentation as published on October 2, and several things it does not settle.

Which tools count as hosted. The steering page says hosted tool work already running finishes. It does not list which tools that covers in the passage read here. If you use remote MCP servers through the Responses API, verify how they behave under steering before trusting either answer.
Cancel semantics are unverified. The background guide documents a cancel endpoint but not what it does to in-flight tools or whether it applies to WebSocket runs. I did not test it.
Multi-agent is beta. Steering a parent run while GPT-6.1 Sol subagents work in parallel is the most interesting case and the least documented. Expect behavior to change.
Your executor is now load-bearing. The pattern above moves safety into your code, which means your bugs become safety bugs. Test the halt path the same way you test the happy path.
None of this is unique to OpenAI. Any agent framework where tools run asynchronously has the same gap. OpenAI just wrote it down clearly, which deserves credit.

Where this leaves you

Steering is worth adopting. Redirecting a long run without throwing away its context is a real improvement over killing it and starting over.

Just name it correctly in your own head and in your product. It is a way to change the plan. The brake is the line of code that runs before your agent touches anything it cannot take back, and you are the only one who can write it.

Go find that line in your current agent. If it does not exist, that is your next commit.

Sources: OpenAI, A practical guide to building with GPT-6; OpenAI steering guide; OpenAI background mode guide.

Medium metadata

Title: GPT-6 Steering Is Not a Stop Button
Subtitle: OpenAI's new mid-turn steering lets you redirect a running agent. It does not let you stop one. Here is where the brake actually lives.
Tags: OpenAI, AI Agents, GPT-6, Software Engineering, AI Safety
Canonical: import from the fervorai.dev URL