A Agents API da OpenAI já pode rever as ações do seu agente. Por omissão está desligada, e o orçamento é ilimitado
By Surya Pratap
1 de novembro de 2026
7 min read
AI & Technology
1 de novembro de 2026
7 min read
Ver os quatro valores por omissãoHover to exploreDois dias depois de a OpenAI publicar um Model Spec que pede aos agentes que se mantenham dentro de um âmbito acordado, o seu SDK de Python trouxe uma definição que passa parte desse trabalho para a plataforma. A versão 3.42.0, lançada a 31 de outubro de 2026, permite ligar a revisão automática das ações de um agente na Agents API. Permite também escolher como é compactado o contexto do agente e dá-lhe uma noção experimental do tempo. Nada disto chegou às manchetes. Para os fundadores que correm agentes nessa API, o mais útil não são as novidades, mas o facto de a referência dizer claramente o que faz cada definição quando a omite.
Este artigo baseia-se na versão 3.42.0 do openai-python e na referência da API que a acompanha, lida na íntegra no que diz respeito às definições de sessão e de agente da Agents API; as citações vêm dessa referência. A Agents API está em beta. A interpretação a partir da secção 3 é minha.
A versão enumera dez novidades. Três delas mudam o comportamento de uma sessão de agente:
review com dois valores, none e auto_review.compaction que escolhe entre compactação em segundo plano e bloqueante.experimental.time_awareness que dá ao modelo «lembretes periódicos da hora atual».A mesma versão acrescenta ainda a gestão de chaves externas ao nível da organização e o isolamento das chaves de API por pedido, o que interessa às equipas de segurança mas não muda o comportamento do agente. Uma quarta definição relevante já existia: spend_control, um limite de gastos por sessão em cêntimos de dólar.
A referência descreve cada modo de revisão numa linha. none mantém «o comportamento de execução existente, sem revisão automática de ações». auto_review serve para «rever automaticamente as ações elegíveis» e «recusar o recurso à aprovação manual».
Há três pormenores que importam. Primeiro, se omitir o campo, obtém none. Segundo, pode mudar mais tarde o modo de revisão da sessão, mas a alteração passa a ser a revisão por omissão «para novos turnos raiz»: os turnos existentes e os seus subagentes mantêm o seu modo. Um turno já em curso, e cada subagente que tenha lançado, continuam como estavam. Terceiro, o objeto de sessão devolve o modo, e omite-o quando o modo é none.
A referência não diz que ações são «elegíveis», contra o que o revisor as verifica, que modelo faz a revisão nem se rever tem custo. Hoje, o único pedido de aprovação que uma sessão pode devolver à sua aplicação é um pedido de utilização do computador, como permitir que um navegador abra uma nova origem ou inicie sessão. Tal como leio «recusar o recurso à aprovação manual», ligar auto_review significa que uma ação que teria esperado pela aprovação da sua aplicação é recusada. É uma escolha sensata para um agente que trabalha sem supervisão. É também uma mudança de comportamento que os seus utilizadores vão notar, por isso teste-a antes de depender dela.
A nova definição decide quem revê as ações do seu agente. Omiti-la também decide: ninguém, a não ser o seu próprio código.
Qualquer execução longa de um agente acaba por ultrapassar a sua janela de contexto, e o harness resume o contexto mais antigo para continuar. Em setembro escrevemos sobre modelos que escreviam instruções nesses resumos. Agora pode escolher quando é feito o resumo.
A compactação em segundo plano é o valor por omissão, e a referência junta-lhe um aviso: a compactação em segundo plano «pode aumentar o consumo de tokens». Ponha async a false e a compactação passa a ser bloqueante. A referência não quantifica os tokens extra. Se cobra aos seus clientes por tarefa ou trabalha com margens apertadas, meça-o nas suas próprias cargas antes de aceitar o valor por omissão.
A noção do tempo vem desligada e está marcada como experimental: estas funcionalidades «podem mudar». Resolve um problema real. Um agente que trabalha há horas, ou que é retomado no dia seguinte, não sabe quanto tempo passou se nada lho disser. Se o seu agente trabalha com prazos, horário de expediente ou qualquer latest_time no seu âmbito, vale a pena testar este indicador. Enquanto continuar experimental, continue também a verificar os prazos no seu próprio código.
O padrão é o mesmo para as quatro: fixe cada valor explicitamente ao criar a sessão, depois leia os valores efetivos no objeto de sessão e registe-os com a execução. Todos os nomes de campo abaixo vêm da referência da 3.42.0; o nome do modelo e as instruções são exemplos.
from openai import OpenAI
client = OpenAI()
session = client.beta.agents.sessions.create(
environment={"type": "none"},
agent={
"model": "YOUR_MODEL",
"instructions": "Chase overdue invoices. Never change payment details.",
"compaction": {"async_": False},
"experimental": {"time_awareness": True},
},
review="auto_review",
spend_control={"limit": 500}, # USD cents
metadata={"workflow": "invoice-chasing"},
input="Chase this week's overdue invoices.",
)
effective = {
"review": session.review or "none",
"spend_limit_cents": session.spend_control.limit if session.spend_control else None,
"compaction_async": session.agent.compaction.async_ if session.agent.compaction else None,
"time_awareness": session.agent.experimental.time_awareness if session.agent.experimental else None,
}
assert effective["review"] == "auto_review"
assert effective["spend_limit_cents"] == 500
Nunca confie num campo omitido. A referência é explícita: se omitir review obtém none, e se omitir spend_control a sessão fica sem limite. Escreva ambos no código, mesmo quando o valor que quer é o de omissão.
Registe o que a sessão devolve. Os valores que contam são os que a API diz estarem em vigor, não os que pensava estar a enviar. Guarde-os com a execução, para que a análise de um incidente comece pelos factos.
Decida quem trata de uma recusa. Com auto_review, algumas ações serão recusadas em vez de lhe chegarem. O seu produto precisa de uma mensagem clara para o utilizador e de uma forma de repetir o passo com a aprovação de uma pessoa.
Mude as definições entre turnos. Um novo modo de revisão só se aplica a novos turnos raiz. Para apertar um agente em execução, pare o turno, atualize a sessão e recomece.
O limite de gastos é o primeiro que eu fixaria. O exemplo de orçamento do Model Spec mostra que a OpenAI trata um orçamento como um teto. A Agents API dá-lhe um campo para o impor, e uma sessão ilimitada se o omitir.
Artigos anteriores relacionados
Na sexta-feira analisámos o âmbito de autonomia do Model Spec: ferramentas permitidas, um prazo e um orçamento, impostos pelo seu harness. Em setembro explicámos o que a Agents API executa por si e o que não executa, incluindo onde está disponível. As definições desta versão são os primeiros controlos de plataforma que correspondem a esse âmbito.
Que auto_review torne um agente seguro. A referência não diz o que o revisor verifica. Trate-o como mais uma camada, não como substituto dos seus próprios limites sobre ferramentas, destinatários e dinheiro.
Que a compactação bloqueante seja sempre a melhor escolha. A única contrapartida declarada é que a compactação em segundo plano «pode aumentar o consumo de tokens». Meça-o antes de mudar um valor por omissão.
Que a noção do tempo esteja pronta para produção. Está marcada como experimental, e a referência diz que estas funcionalidades podem mudar.
Que estas definições existam fora da Agents API. Pertencem às sessões de agente geridas pela OpenAI, que continuam em beta. Se corre o seu próprio harness sobre outra API ou outro modelo, tem de construir estes mesmos controlos.
A versão 3.42.0 do SDK de Python da OpenAI acrescentou três definições à Agents API: um modo de revisão automática de ações que recusa o recurso à aprovação manual, a escolha entre compactação do contexto em segundo plano ou bloqueante, e um indicador experimental de noção do tempo. Omitidas, dão-lhe nenhuma revisão automática, compactação em segundo plano que pode gastar mais tokens, e nenhum lembrete da hora. Ao lado delas, um campo mais antigo dá-lhe um orçamento ilimitado se não fixar um.
Nada disto está escondido; a referência di-lo claramente. O risco não é a OpenAI ter escolhido maus valores por omissão. É uma equipa que nunca fixou estes campos não conseguir dizer o que os seus agentes podem fazer.
Esta semana, abra o código que cria as suas sessões de agente e escreva explicitamente as quatro definições. Depois registe os valores que a sessão devolve e compare-os com o que julgava estar a executar.
Fontes: OpenAI, notas da versão 3.42.0 do openai-python (31 de outubro de 2026) — a lista de novidades, incluindo as definições de compactação do contexto do agente, a revisão de sessões e as definições de ferramentas, a noção experimental do tempo, a gestão de chaves externas da organização e o isolamento das chaves de API por pedido; e a referência da API publicada com essa versão — os modos de review e as suas descrições, a regra de que um novo modo de revisão se aplica a novos turnos raiz, a definição compaction e o seu aviso sobre o consumo de tokens, o indicador experimental.time_awareness e o seu valor por omissão, o valor por omissão de spend_control (uma sessão ilimitada) e os pedidos de aprovação de utilização do computador. O código da secção 4 é uma ilustração minha com nomes de campo dessa referência, e a interpretação das secções 3 a 5 é minha.
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.
