A documentação indica que response.steer.accepted significa que o input foi enfileirado (“Acceptance means the input is queued, not that the model has acted on it”) e que, antes de criar a continuação automática, o servidor finaliza o item de saída atual e qualquer tool hospedada já em execução (“Before creating this automatic continuation, the server finishes the current output item…”).
O que ainda fica pouco claro é se esse “queued” implica apenas uma fila interna do servidor/stream ou se, na prática, o steering volta para uma nova fila de inferência (na infraestrutura) como uma requisição separada. Como o mid-turn steering é, conceitualmente, uma continuação inserida durante um turno em andamento, é razoável esperar (ou, no mínimo, querer uma confirmação explícita) se ele pode aproveitar estado/processamento já ativo para reduzir latência em cenários de dados em tempo real — isso seria um benefício central do recurso, não só uma simplificação de orquestração.
Pedido: acrescentar uma nota objetiva (sem promessas de performance) respondendo “sim/não” para: (1) reutilização de inferência/processamento em andamento; (2) necessidade de entrar novamente em fila de inferência; e (3) quais expectativas de latência são apropriadas ao usar steering.
/api/docs/guides/steering