Saltar para o conteúdo principal
Um agente comprometido não para sozinho. Uma injeção de prompt que o engana para entrar em um loop de retry, ou uma chave vazada em um log de CI, continuará chamando modelos até que algo diga pare. No OrcaRouter esse “algo” são dois campos na própria chave: um limite de gasto e uma expiração. Defina-os uma vez no editor de chave e o gateway enforça ambos em cada requisição — sem mudança no código do agente, sem redeploy. Esta página é a referência focada nesses dois limites. Para a lista completa de campos da chave, veja o objeto token; para o modelo de identidade ao redor deles, veja visão geral das chaves com escopo.

​
1. O limite de gasto de chave de api: credit_limit_usd

credit_limit_usd é o teto de gasto vitalício de uma chave, expresso em USD simples. Você digita uma cifra em dólares no editor de chave; o OrcaRouter a converte na cota inicial da chave e mede cada chamada contra ela.

Delimitada

credit_limit_usd: 25 cunha uma chave com $25 de gasto. Cada chamada debita o seu custo; uma vez que o saldo restante chega a zero, a chave para de autorizar e cada requisição adicional é rejeitada.

Ilimitada

credit_limit_usd: 0 é o sentinela para sem limite — a chave saca do saldo do seu workspace sem teto por chave. Conveniente, mas o pior raio de explosão se vazar.
0 não significa “zero dólares” — significa ilimitado. Uma chave que você pretendia trancar em um orçamento minúsculo precisa carregar um número positivo. Para expressar “esta chave não pode gastar nada”, desabilite ou delete-a, não defina o limite como 0.

​
2. Como o limite é medido: remain_quota e used_quota

O limite em dólares que você insere é a superfície voltada ao humano. Sob ele, o gateway rastreia dois contadores em execução na chave:
CampoSignificado
remain_quotaGasto restante antes de a chave parar de autorizar.
used_quotaGasto consumido até agora ao longo da vida da chave.
Definir um credit_limit_usd positivo semeia remain_quota a partir dessa cifra em dólares; cada chamada faturada move o custo de remain_quota para used_quota. Uma chave com limite ilimitado carrega unlimited_quota em vez disso, e a verificação de saldo é totalmente pulada.
Um bloqueio de guardrail ou firewall não custa nada contra o limite quando dispara antes de o modelo rodar — um guardrail_blocked de estágio de input e um firewall_blocked inbound ambos acontecem pré-medição, então remain_quota fica intocado. Um bloqueio de guardrail de estágio de output reembolsa a requisição. Veja guardrails e firewall.

​
3. Auto-expiração: expired_time

expired_time é um corte absoluto — um timestamp Unix epoch (segundos) após o qual a chave para de autorizar, não importa quanto orçamento reste.
  • Um timestamp futuro expira a chave naquele instante. O gateway o compara com o tempo atual em cada requisição e rejeita a chamada uma vez que ele tenha passado.
  • -1 é o sentinela para nunca expira.
Os dois limites são independentes e ambos devem passar. Uma chave com orçamento restante mas com um expired_time passado está morta; uma chave dentro de sua janela de validade com remain_quota em zero está morta. O limite que disparar primeiro vence. O editor rejeita uma expiração definida no passado, então você não pode cunhar uma chave nascida-expirada por acidente.
Para chaves de vida curta cunhadas por run de CI ou por agente efêmero, veja chaves que expiram.

​
4. Uma chave concreta delimitada e que expira

Um job noturno que reconcilia faturas com um modelo barato, roda por um piloto de duas semanas e nunca deveria custar mais que alguns dólares por noite precisa de quase nenhuma agência. Configure a sua chave no editor de chave do console (/console/token — Developer+):
1

Defina o limite de gasto

credit_limit_usd: 40 — o orçamento inteiro do piloto. Um loop de retry descontrolado esgota a chave, não o saldo do seu workspace.
2

Defina a expiração

expired_time: o timestamp Unix para o fim da janela do piloto. A chave auto-expira e não pode ser reutilizada depois que o piloto encerrar.
3

Combine com os outros escopos

Adicione model_limits para que ela não possa escalar para um modelo de fronteira, e allow_ips para que uma chave vazada seja inútil fora do host do scheduler.
Se este agente for sequestrado no terceiro dia, o dano é delimitado ao que quer que reste dos seus $40, e a chave inteira desaparece em onze dias de qualquer forma. O resto do workspace fica intocado.
Ambos os campos são USD-e-tempo na chave, não política de todo o workspace. Para limitar o gasto de um único run de agente (em vez da vida de uma chave), o veredito cap_cost do Firewall é o disjuntor por run — veja regras de firewall. Os dois compõem: o limite da chave delimita a vida, cap_cost delimita um único run.

​
5. Quem pode definir estes

Definir credit_limit_usd e expired_time é parte de criar ou editar uma chave, o que exige o papel de Developer ou superior. Qualquer membro do workspace pode ler o registro mascarado de uma chave; só Developer+ pode mudar os seus limites. As chaves são mascaradas na exibição — o texto plano é mostrado uma vez na criação (veja mascaramento de chave).

​
6. Delimitada por padrão

Uma chave com credit_limit_usd: 0 e expired_time: -1 não tem limite de gasto e nunca expira — agência máxima, pior raio de explosão. Faça disso a exceção deliberada, não o padrão.

Ilimitada vs. delimitada

Quando uma chave sem limite e que não expira é realmente a escolha certa — e quando não é.

Checklist de menor agência

Passe cada chave de produção pela mesma passada de hardening antes de ela entrar em produção.

​
7. Relacionados

O objeto token

Cada campo em uma chave, incluindo os contadores de cota.

Vincular políticas

Anexe um guardrail e uma política de firewall à mesma chave.

Agência excessiva

A ameaça que os limites de gasto e a expiração são construídos para conter.
Um limite de gasto e uma expiração são o seguro mais barato em uma chave: dois números que transformam uma credencial sem fim em uma que falha de forma segura — vazia ou expirada — em vez de rodar até a sua conta perceber.