cap_cost là cầu dao mạch cho việc đó: bạn soạn một
trần cents theo từng lần chạy một lần, và gateway deny cuộc gọi tool kế tiếp
ngay khi chi tiêu tích lũy của một lần chạy vượt nó — trước khi cuộc gọi đó
đến được mô hình hoặc tool.
Đây là kiểm soát chi phí AI agent được thực thi tại gateway, không phải gắn
vào vòng lặp agent của bạn. Như mọi
verdict firewall, một quy tắc cap_cost
sống trong một chính sách workspace, gắn vào một key, và có hiệu lực trên cuộc
gọi kế tiếp mà không cần redeploy.
1. Cầu dao mạch chi tiêu theo từng lần chạy
cap_cost là một verdict quy tắc bạn soạn với một trường thêm —
cap_cost_cents, trần chi tiêu của lần chạy tính bằng cents USD. Khi quy tắc
khớp một cuộc gọi tool, engine so sánh chi tiêu tích lũy của lần chạy agent
với cap đó:
- Dưới cap → cuộc gọi được phép; việc đánh giá tiếp tục.
- Trên cap → cuộc gọi bị deny, với một lý do nêu tổng của lần chạy so với cap. Đó là kết cục cuối cùng, cầu dao mạch — lần chạy không thể phát ra một cuộc gọi được quản trị nữa cho đến một lần chạy mới.
Phạm vi lần chạy, với một fallback theo từng request. Khi request mang một
agent-run id, trần áp dụng cho chi tiêu tích lũy của lần chạy. Một cuộc gọi
không có liên kết lần chạy (vd: một dispatch MCP trần không có session được
chuyển tiếp) rơi về một so sánh theo từng request thay vào. Dù cách nào, cầu
dao trip trước khi cuộc gọi vượt-ngân-sách được dispatch.
2. Một ví dụ cụ thể
Giới hạn bất kỳ lần chạy nào trên một key ở $5.00 chi tiêu tích lũy. Một quy tắc wildcard đơn làm việc đó —cap_cost_cents là 500 (cents):
firewall_policy_id, hoặc đặt làm mặc định của workspace, và mọi lần chạy
mà key đó điều khiển giờ đều bị giới hạn.
Bạn có thể thu hẹp cap chặt hơn “mọi tool”. Thu hẹp
glob tên-tool để chỉ một họ cuộc gọi đắt
tiền được tính vào cầu dao — vd: cap_cost trên *.search để giới hạn
fan-out web-search trong khi để các tool nội bộ rẻ không bị đo.
3. Nó kích hoạt ở đâu — và ở đâu nó không thể
cap_cost chỉ có nghĩa trước khi một cuộc gọi được dispatch — đó là điểm
duy nhất mà việc dừng cuộc gọi vẫn ngăn được chi tiêu. Nên nó live trên hai
bề mặt tiền-dispatch và bị từ chối trên các bề
mặt hậu-dispatch:
| Bề mặt | cap_cost? |
|---|---|
inbound (tool được quảng bá) | Thực thi. |
mcp (dispatch tools/call) | Thực thi. |
response (cuộc gọi do mô hình phát ra) | Từ chối khi lưu — chẳng còn gì để dừng. |
egress (đích đến đi ra ngoài) | Từ chối khi lưu — chẳng còn gì để dừng. |
cap_cost ghim vào response hoặc egress bị từ chối tại
thời-điểm-lưu, nên một quy tắc không bao giờ có thể hiển thị là live mà lại
không bao giờ deny được. Để stage trống để bao cả hai bề mặt tiền-dispatch,
hoặc ghim nó vào inbound / mcp.
4. Cầu dao trông như thế nào khi nó trip
Một cuộc gọi vượt-ngân-sách là một deny firewall bình thường:- Trên
inbound, relay trả về HTTP 400 với mã lỗifirewall_blocked. Block kích hoạt trước cuộc gọi mô hình thượng nguồn, nên nó tốn không token mô hình, và được đánh dấu skip-retry — chạy lại cùng cuộc gọi thì cũng chỉ trip cầu dao lại. - Trên
mcp, nó quay lại như một lỗi tool nên mô hình thấy sự từ chối và có thể dừng hoặc hỏi người dùng, thay vì crash.
cap_cost: estimated run cost $5.40 exceeds cap $5.00, nên một operator đọc events feed
thấy chính xác tại sao cầu dao trip.
Events không bao giờ mang một
cap_cost theo nghĩa đen. Bạn soạn verdict
là cap_cost, nhưng engine phân giải nó thành một allow hoặc deny cụ
thể trước khi event được ghi lại. Feed hiển thị allow/deny mà agent thực sự
thấy — trần chi-phí-lần-chạy là lý do, không phải nhãn verdict. Cái này phản
chiếu cách verdict phân giải.5. Triển khai nó an toàn
Vì một cầu dao trip dừng-cứng một lần chạy, hãy kiểm tra nó trước khi thực thi. Bật shadow mode trên chính sách: quy tắccap_cost vẫn đánh giá và một deny giả định bị hạ cấp thành audit, thêm tiền
tố [shadow] would …. Quan sát events feed để xác nhận cap trip ở nơi bạn mong
đợi — và chỉ nơi bạn mong đợi — rồi tắt shadow mode để bắt đầu thực thi.
Bạn cũng có thể chạy thử một chính sách trên một cuộc gọi mẫu trong
tab Test (một sandbox Developer+) để
thấy verdict đã phân giải và quy tắc đã khớp trước khi bất cứ thứ gì phụ thuộc
vào nó.
6. Nó khớp vào phần còn lại của firewall ra sao
cap_cost là một verdict trong sáu. Nó ghép tự nhiên với các kiểm soát khác
trên cùng chính sách:
Verdict
Toàn bộ tập — allow, audit, deny, sanitize, pending_approval, và cách
cap_cost phân giải.
Block tool nguy hiểm
Deny shell phá hủy, delete, và các cuộc gọi rủi ro cao khác dứt khoát.
Tham chiếu quy tắc
Toàn bộ ngôn ngữ so khớp — glob, mệnh đề argument, chuỗi.
Phát hiện bất thường
Đột biến chi phí được gắn cờ trên một baseline giờ-trong-tuần đã học.
cap_cost cho điểm dừng cứng, bất thường cho tín hiệu
sớm.
Giới hạn quota trên chính key (
credit_limit_usd) giới hạn chi tiêu tổng
trên mọi lần chạy; cap_cost giới hạn một lần chạy đơn. Chúng kết hợp — một
vòng lặp chạy hoang trip cầu dao theo-lần-chạy từ rất lâu trước khi nó có thể
cạn credit trọn đời của key. Xem
phạm vi: key, chính sách, workspace.Đi đâu tiếp theo
Tạo & gắn một chính sách
Tạo một chính sách, chọn một verdict mặc định, liên kết nó với một key.
Shadow mode
Đo một cap trước khi nó thay đổi traffic.
