메인 콘텐츠로 건너뛰기
재시도 루프에 갇히거나, 천 개의 하위 작업으로 팬아웃하거나, 단순히 계획 중간에 폭주하는 추론 에이전트는 누구도 알아채기 전에 실제 돈을 쓸 수 있습니다. cap_cost firewall 판정은 그것을 위한 회로 차단기입니다: 실행별 센트 상한을 한 번 작성하면, 게이트웨이는 실행의 누적 지출이 그것을 넘는 순간 — 그 호출이 모델이나 툴에 도달하기 전에 — 다음 툴 호출을 거부합니다. 이것은 에이전트 루프에 볼트로 조인 것이 아니라 게이트웨이에서 강제되는 AI 에이전트 비용 제어입니다. 모든 firewall 판정처럼, cap_cost 규칙은 워크스페이스 정책에 존재하고, 키에 연결되며, 재배포 없이 다음 호출에 효력을 발휘합니다.

​
1. 실행별 지출 회로 차단기

cap_cost는 추가 필드 하나 — cap_cost_cents, 실행의 지출 상한(USD 센트) — 로 작성하는 규칙 판정입니다. 규칙이 툴 호출에 매치하면, 엔진은 에이전트 실행의 누적 지출을 그 상한에 대해 비교합니다:
  • 상한 미만 → 호출이 허용됨; 평가가 계속됩니다.
  • 상한 초과 → 호출이 거부됨, 실행의 총합 대 상한을 명명하는 이유와 함께. 그것이 종착, 회로 차단기 결과입니다 — 실행은 새 실행이 있기 전까지 또 다른 통제된 호출을 발행할 수 없습니다.
상한은 단일 요청이 아니라 에이전트 실행에 키가 지정됩니다. 이미 예산의 대부분을 태운 긴 실행은 그 한 호출이 저렴할 때조차 다음 호출에서 거부됩니다 — 차단기는 한계 비용이 아니라 누적 총합에서 트립됩니다.
실행 범위, 요청별 폴백 포함. 요청이 에이전트 실행 id를 담으면, 상한은 실행의 누적 지출에 적용됩니다. 실행 연관이 없는 호출(예: 전달된 세션이 없는 맨 MCP 디스패치)은 대신 요청별 비교로 폴백합니다. 어느 쪽이든, 차단기는 예산 초과 호출이 디스패치되기 전에 트립됩니다.

​
2. 하나의 구체적인 예

키의 모든 실행을 누적 지출 $5.00로 상한 설정합니다. 단일 와일드카드 규칙이 그것을 합니다 — cap_cost_cents는 500(센트): 
{
  "label": "run cost ceiling $5",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
생성한 정책의 콘솔 규칙 편집기에서 작성하세요(정책 생성 & 연결 참조). 규칙을 쓰는 것은 Developer+ 액션입니다. firewall_policy_id를 통해 정책을 키에 연결하거나 워크스페이스 기본값으로 만들면, 그 키가 구동하는 모든 실행이 이제 제한됩니다. 상한을 “모든 툴”보다 좁게 범위 지정할 수 있습니다. 툴 이름 glob를 좁혀 비싼 호출 패밀리만 차단기로 계산되게 하세요 — 예: *.search에 cap_cost를 걸어 웹 검색 팬아웃을 제한하면서 저렴한 로컬 툴은 미계량으로 둡니다.
우선순위로 더 저렴한 경고 계층을 쌓으세요. 더 높은 우선순위(더 낮은 숫자)의 더 낮은 상한 audit 규칙은 강제 cap_cost 규칙이 트립되기 전에 실행이 예산에 접근하는 것을 이벤트 피드에서 지켜볼 수 있게 합니다. 첫 매치가 이기므로, 감시자를 먼저 정렬하세요.

​
3. 어디서 발동하는가 — 그리고 어디서 할 수 없는가

cap_cost는 호출이 디스패치되기 전에만 의미가 있습니다 — 호출을 멈추는 것이 여전히 지출을 막는 한 지점. 그래서 그것은 디스패치 전 두 표면에서 라이브이고 디스패치 후 표면에서는 거부됩니다:
표면cap_cost?
inbound(광고된 툴)강제됨.
mcp(tools/call 디스패치)강제됨.
response(모델이 발행한 호출)저장 시 거부 — 멈출 것이 남아 있지 않음.
egress(아웃바운드 목적지)저장 시 거부 — 멈출 것이 남아 있지 않음.
response나 egress에 고정된 cap_cost 규칙은 저장 시점에 거부되므로, 규칙이 결코 라이브로 표시되면서 결코 거부할 수 없는 일은 없습니다. 디스패치 전 두 표면을 모두 커버하려면 스테이지를 비워두거나, inbound / mcp에 고정하세요.
cap_cost_cents는 cap_cost 규칙에 필수이고 음수가 아니어야 합니다. 콘솔과 API는 상한이 없는 cap_cost 규칙을 거부하므로, 잘못 구성된 상한이 모든 호출을 조용히 통과시킬 수 없습니다.

​
4. 차단기가 트립될 때 어떻게 보이는가

예산 초과 호출은 평범한 firewall deny입니다:
  • inbound에서, 릴레이는 오류 코드 firewall_blocked와 함께 HTTP 400을 반환합니다. block은 업스트림 모델 호출 전에 발동하므로 모델 토큰을 들이지 않고, skip-retry로 표시됩니다 — 동일한 호출을 다시 실행하면 그저 차단기를 다시 트립할 뿐입니다.
  • mcp에서, 모델이 거부를 보고 크래시하기보다 멈추거나 사용자에게 질문할 수 있도록 툴 오류로 돌아옵니다.
deny 이유는 수치를 명명합니다, 예: cap_cost: estimated run cost $5.40 exceeds cap $5.00, 그래서 이벤트 피드를 읽는 운영자는 차단기가 왜 트립되었는지 정확히 봅니다.
이벤트는 결코 리터럴 cap_cost를 담지 않습니다. 판정을 cap_cost로 작성하지만, 엔진은 이벤트가 기록되기 전에 그것을 구체적인 allow 또는 deny로 해석합니다. 피드는 에이전트가 실제로 본 allow/deny를 보여줍니다 — 실행 비용 상한은 판정 레이블이 아니라 이유입니다. 이는 판정이 해석되는 방식을 반영합니다.

​
5. 안전하게 롤아웃하기

트립된 차단기가 실행을 하드 스톱하므로, 강제하기 전에 검증하세요. 정책에 shadow mode를 켜세요: cap_cost 규칙은 여전히 평가하고 거부였을 것은 [shadow] would …로 접두된 audit로 강등됩니다. 이벤트 피드를 보아 상한이 예상한 곳에서 — 그리고 오직 예상한 곳에서만 — 트립되는지 확인한 다음, shadow mode를 꺼서 강제를 시작하세요. Test 탭(Developer+ 샌드박스)에서 샘플 호출에 대해 정책을 dry-run하여 무언가가 그것에 의존하기 전에 해석된 판정과 매치된 규칙을 볼 수도 있습니다.

​
6. firewall 나머지에 어떻게 들어맞는가

cap_cost는 여섯 판정 중 하나입니다. 그것은 같은 정책의 다른 컨트롤과 자연스럽게 짝을 이룹니다:

Verdicts

전체 집합 — allow, audit, deny, sanitize, pending_approval, 그리고 cap_cost가 해석되는 방식.

위험한 툴 차단

파괴적 셸, 삭제, 그리고 다른 고위험 호출을 통째로 거부합니다.

규칙 레퍼런스

완전한 매칭 언어 — glob, 인자 절, 시퀀스.

이상 탐지

학습된 주중 시간대 베이스라인에 대해 플래그된 비용 급증.
실행 비용 상한은 정적이고 결정론적인 백스톱입니다; firewall은 또한 각 워크스페이스의 정상 비용 형태를 학습하고 Member 판독 가능한 이상 피드에서 14일 주중 시간대 베이스라인에 대해 급증을 플래그합니다. 하드 스톱에는 cap_cost를, 조기 신호에는 이상을 사용하세요.
키 자체의 쿼터 한도(credit_limit_usd)는 모든 실행에 걸친 전체 지출을 제한합니다; cap_cost는 단일 실행을 제한합니다. 그것들은 조합됩니다 — 폭주 루프는 키의 평생 크레딧을 소진할 수 있기 훨씬 전에 실행별 차단기를 트립합니다. 범위: 키, 정책, 워크스페이스 참조.

​
다음으로 갈 곳

정책 생성 & 연결

정책을 만들고, 기본 판정을 고르고, 키에 바인딩합니다.

Shadow mode

상한이 트래픽을 변경하기 전에 측정합니다.
지출 상한이 백스톱하는 폭주 에이전트 위협은 과도한 자율성과 위험한 툴 호출을 참조하세요.