Circuit breaker abre quando a chamada falha. Agente em loop não falha. Ele responde bem, chama a ferramenta certa, devolve JSON válido e cobra por cada volta. Por isso o kill switch de agente não pode herdar o gatilho do padrão clássico. Ele precisa disparar por comportamento e por custo, não por erro. A matriz de disparo abaixo tem cinco sinais, cada um com escopo, ação e regra de rearme.
O padrão clássico
Michael Nygard popularizou o circuit breaker no livro Release It!. A descrição de referência é a de Martin Fowler, de 2014. Uso essa fonte porque ela define o padrão, e a definição não mudou desde então.
Você embrulha a chamada remota num objeto que conta falhas. Quando as falhas passam de um limite, o breaker dispara. A partir daí, nas palavras de Fowler, “all further calls to the circuit breaker return with an error, without the protected call being made at all”.
São três estados.
Fechado: as chamadas passam.
Aberto: as chamadas morrem na porta.
Meio aberto: o breaker deixa passar uma chamada de teste. Fowler descreve esse terceiro estado como “ready to make a real call as trial to see if the problem is fixed”. Se o teste passa, o breaker fecha. Se falha, o relógio recomeça.
Dois parâmetros governam tudo: o limite de falhas e o tempo de espera antes do teste.
Onde a analogia segura
A parte que transfere sem ajuste é a falha de provedor. Timeout, 429 e 500 no endpoint do modelo são o mesmo problema que Nygard descreveu. E o gateway já resolve isso.
No LiteLLM, o parâmetro allowed_fails define quantas falhas por minuto um deployment aguenta. O cooldown_time define por quantos segundos ele sai do pool. Os padrões são 3 falhas e 5 segundos. A doc lista três condições de cooldown: resposta 429, taxa de falha acima de 50% no minuto corrente, e erros não repetíveis como 401, 404 e 408.
Isso é circuit breaker, com outro nome. Não reconstrua essa camada. O trabalho do kill switch de agente começa onde ela termina.
Quatro pontos de quebra
O gatilho não existe. Agente rodando em loop produz chamadas bem sucedidas. O contador de falhas fica em zero. O breaker clássico nunca dispara, porque não há nada que ele saiba contar.
O teste custa dinheiro. O estado meio aberto assume que uma chamada de teste é barata e sem consequência. Num agente com ferramenta de escrita, essa premissa cai. Uma chamada de teste que dispara um Pix move dinheiro de verdade.
O escopo é outro. O circuit breaker protege o chamador de um dependente doente. O kill switch de agente protege o dono da conta do próprio agente. A direção da ameaça inverte, e com ela o lugar onde o interruptor precisa morar.
O rearme automático rearma o problema. O breaker clássico volta sozinho depois do tempo de espera, porque a hipótese é que o dependente se recuperou. Agente em loop não se recupera com o tempo. Devolver a chamada depois de 30 segundos entrega o gatilho de volta para quem estava girando.
A matriz de disparo do kill switch de agente
A matriz abaixo é design meu. São cinco sinais. Cada um tem um lugar onde mora, uma ação e uma regra de rearme própria.
| Sinal | Onde mora | Ação ao estourar | Rearme | Obrigatório? |
|---|---|---|---|---|
| Gasto por janela | gateway | bloqueia a chave | automático, no fim da janela | sim |
| Passos por tarefa | runtime do agente | encerra a tarefa e escala | por tarefa | sim |
| Repetição de ferramenta | runtime do agente | encerra a tarefa e escala | por tarefa | sim |
| Falha de provedor | gateway | tira o deployment do pool | automático, por cooldown | sim |
| Ação fora do envelope | camada de ferramenta | recusa a ação e escala | humano | quando o agente escreve |
Cinco definições operacionais seguram a matriz.
Gasto por janela é o dólar acumulado por uma chave, num intervalo fixo.
Passos por tarefa é o número de voltas do loop numa única tarefa, contando cada ida ao modelo.
Repetição de ferramenta é a mesma ferramenta chamada com os mesmos argumentos, N vezes seguidas, dentro da mesma tarefa.
Falha de provedor é a taxa de erro do endpoint do modelo.
Ação fora do envelope é a chamada de ferramenta cujo valor, destino ou volume passa do teto declarado para aquela ferramenta.
Exemplo ilustrativo, com números fictícios. Um agente de cobrança roda com teto de US$ 10 por dia e 25 passos por tarefa. O limite de repetição é 3 chamadas iguais, e o envelope é de R$ 500 por Pix.
Duas regras de design sustentam a matriz.
O estado mora fora do processo. Kill switch guardado em memória do agente morre no restart e volta desarmado. Em orquestrador que reinicia processo sozinho, isso significa que o loop retoma de onde parou. O estado vai para o banco do gateway ou para um Redis, nunca para uma variável.
Rearme de sinal de comportamento é humano. Gasto e falha de provedor podem voltar sozinhos, porque são medidas de tempo e de terceiro. Passo, repetição e envelope não. Esses três dizem que o agente fez algo que ninguém previu, e nenhum relógio resolve isso. Essa é a minha posição, e é a parte da matriz mais fácil de discordar: rearme manual custa plantão.
Os três estados que sobram
O estado meio aberto não transfere. No lugar dele, uso uma escala de três degraus.
fechado -> agente opera com o conjunto completo de ferramentas
degradado -> modelo mais barato, ferramentas de escrita desligadas
aberto -> nenhuma chamada sai; a tarefa vai para a fila humanaO degrau do meio existe porque nem todo estouro merece parada total. Repetição de ferramenta pode virar leitura apenas, com escrita bloqueada, e o agente ainda entrega diagnóstico para o humano que vai assumir. Gasto estourado no teto diário pode virar rota para o modelo barato, se a qualidade aceitar. Esse degrau conversa direto com o roteamento de modelo, tema do próximo artigo da série.
O que o gateway cobre
Dois dos cinco sinais do kill switch de agente são configuração, não código. O gasto por janela vira teto na chave virtual. O LiteLLM aceita várias janelas na mesma chave. A doc é direta sobre o motivo: “A single budget_duration window can’t prevent a bad day from burning your entire month.”
curl 'http://0.0.0.0:4000/key/generate' \
--header 'Authorization: Bearer {master-key}' \
--header 'Content-Type: application/json' \
--data '{
"key_alias": "agente-cobranca-acme",
"budget_limits": [
{"budget_duration": "24h", "max_budget": 10},
{"budget_duration": "30d", "max_budget": 100}
]
}'Cada janela reseta no próprio calendário. A doc lista 1h de hora em hora, 24h diário à meia-noite UTC, 7d aos domingos e 30d no primeiro dia do mês. Quando o teto estoura, a resposta chega assim:
{
"error": {
"message": "LiteLLM Virtual Key: ..., exceeded budget for model=gpt-4o",
"type": "budget_exceeded",
"code": "400"
}
}O sinal de falha de provedor vem do bloco de roteamento, com os dois parâmetros da seção anterior:
router_settings:
allowed_fails: 3
cooldown_time: 30O LiteLLM tem, desde a versão v1.92.x, o recurso budget_fallbacks. Ele reroteia o request para outro modelo quando o model_max_budget estoura, no lugar de devolver budget_exceeded. A doc descreve o comportamento como reroteamento silencioso, com o gasto atribuído ao modelo de fallback. Isso é útil para produto que não pode parar. É o oposto de um kill switch de agente. Se o objetivo é frear, não configure fallback de budget na mesma chave.
O que o gateway não vê
Os outros três sinais não passam pelo gateway. Ele vê requests soltos, não a tarefa que os agrupa. Profundidade de loop, repetição de ferramenta e envelope de ação moram no runtime do agente e na camada de ferramentas.
O teto de passos costuma existir por padrão no framework. No Agents SDK da OpenAI, o loop roda até a saída final, e a doc descreve o corte assim: “If we exceed the max_turns passed, we raise a MaxTurnsExceeded exception. Pass max_turns=None to disable this turn limit.”
Essa frase esconde duas armadilhas. Existe um jeito documentado de desligar o limite, e ele nunca deve chegar em produção. E o limite conta voltas de uma execução, não da conversa. Sessão longa que chama o agente cinquenta vezes passa cinquenta vezes por um teto que nunca soma. O teto de gasto por janela é quem pega esse caso, e é por isso que os dois sinais precisam coexistir.
Repetição de ferramenta e envelope de ação não vêm prontos em lugar nenhum. São código seu, no wrapper da ferramenta. É pouco código: um contador de argumentos idênticos consecutivos e uma comparação de valor contra um teto.
Kill switch de agente e token budget resolvem coisas diferentes
A diferença entre os dois é o gatilho. O token budget controla o total gasto numa janela. O kill switch de agente para uma execução específica que está se comportando errado, mesmo dentro do orçamento. Os dois usam a mesma infraestrutura de chave e team, e nenhum substitui o outro.
A matriz cabe numa página e não precisa de ferramenta nova. Ela pede uma decisão por linha: qual sinal, qual teto, quem rearma. Circuit breaker resolvia um dependente doente. Aqui o dependente está saudável, confiante e cobrando por volta.
Deixe um comentário