Chuyển đến nội dung chính
Một agent bị xâm phạm không tự dừng. Một prompt injection lừa nó vào một vòng lặp retry, hoặc một key bị rò rỉ trong một CI log, sẽ cứ tiếp tục gọi mô hình cho đến khi điều gì đó nói dừng. Trên OrcaRouter “điều gì đó” đó là hai trường trên chính key: một mức trần chi tiêu và một mốc hết hạn. Đặt chúng một lần trong trình chỉnh sửa key và gateway thực thi cả hai trên mọi request — không đổi code agent, không triển khai lại. Trang này là tham chiếu tập trung cho hai giới hạn đó. Để biết danh sách trường key đầy đủ, xem đối tượng token; để biết mô hình danh tính quanh chúng, xem tổng quan key có phạm vi.

​
1. Giới hạn chi tiêu api key: credit_limit_usd

credit_limit_usd là mức trần chi tiêu trọn đời cho một key, biểu thị bằng USD thuần. Bạn gõ một con số đô la trong trình chỉnh sửa key; OrcaRouter chuyển nó thành quota khởi đầu của key và đo lường mọi cuộc gọi đối với nó.

Bị giới hạn

credit_limit_usd: 25 đúc một key với $25 chi tiêu. Mỗi cuộc gọi trừ đi chi phí của nó; một khi số dư còn lại chạm zero, key ngừng ủy quyền và mọi request sau đó bị từ chối.

Không giới hạn

credit_limit_usd: 0 là giá trị sentinel cho không có mức trần — key rút từ số dư workspace của bạn không có mức trần theo từng key. Tiện lợi, nhưng bán kính ảnh hưởng tệ nhất nếu nó rò rỉ.
0 không nghĩa là “không đô la” — nó nghĩa là không giới hạn. Một key bạn định khóa vào một ngân sách nhỏ phải mang theo một số dương. Để biểu thị “key này không được tiêu gì,” hãy vô hiệu hóa hoặc xóa nó, đừng đặt mức trần là 0.

​
2. Cách mức trần được đo lường: remain_quota & used_quota

Mức trần đô la bạn nhập là bề mặt hướng tới con người. Bên dưới nó, gateway theo dõi hai bộ đếm đang chạy trên key:
TrườngÝ nghĩa
remain_quotaChi tiêu còn lại trước khi key ngừng ủy quyền.
used_quotaChi tiêu đã tiêu thụ cho đến nay trong vòng đời của key.
Đặt một credit_limit_usd dương gieo remain_quota từ con số đô la đó; mỗi cuộc gọi được tính phí dịch chuyển chi phí từ remain_quota vào used_quota. Một key với mức trần không giới hạn mang theo unlimited_quota thay vào đó, và việc kiểm tra số dư được bỏ qua hoàn toàn.
Một block guardrail hoặc firewall không tốn gì đối với mức trần khi nó kích hoạt trước khi mô hình chạy — một guardrail_blocked ở giai đoạn input và một firewall_blocked inbound đều xảy ra trước đo lường, nên remain_quota không bị động chạm. Một block guardrail ở giai đoạn output hoàn lại request. Xem guardrails và firewall.

​
3. Tự động hết hạn: expired_time

expired_time là một mốc cắt tuyệt đối — một Unix epoch timestamp (giây) sau đó key ngừng ủy quyền, bất kể còn bao nhiêu ngân sách.
  • Một timestamp tương lai cho key hết hạn vào thời khắc đó. Gateway so sánh nó với thời gian hiện tại trên mỗi request và từ chối cuộc gọi một khi nó đã qua.
  • -1 là giá trị sentinel cho không bao giờ hết hạn.
Hai giới hạn độc lập và cả hai đều phải qua. Một key còn ngân sách nhưng có expired_time đã qua là đã chết; một key trong cửa sổ hợp lệ của nó với remain_quota ở zero là đã chết. Bất kỳ ràng buộc nào kích hoạt trước sẽ thắng. Trình chỉnh sửa từ chối một mốc hết hạn đặt trong quá khứ, nên bạn không thể vô tình đúc một key sinh ra đã hết hạn.
Với các key ngắn hạn được đúc theo từng lần chạy CI hoặc theo từng agent tạm thời, xem key hết hạn.

​
4. Một key bị giới hạn, hết hạn cụ thể

Một job ban đêm đối chiếu hóa đơn bằng một mô hình rẻ, chạy cho một pilot hai tuần, và không bao giờ nên tốn hơn vài đô la mỗi đêm gần như không cần agency nào. Cấu hình key của nó trong trình chỉnh sửa key của console (/console/token — Developer+):
1

Đặt mức trần chi tiêu

credit_limit_usd: 40 — toàn bộ ngân sách của pilot. Một vòng lặp retry mất kiểm soát làm cạn key, không phải số dư workspace của bạn.
2

Đặt mốc hết hạn

expired_time: Unix timestamp cho kết thúc của cửa sổ pilot. Key tự động hết hạn và không thể tái sử dụng sau khi pilot ra mắt.
3

Ghép với các phạm vi khác

Thêm model_limits để nó không thể leo lên một mô hình frontier, và allow_ips để một key bị rò rỉ vô dụng ngoài host của scheduler.
Nếu agent này bị chiếm quyền vào ngày thứ ba, thiệt hại bị giới hạn ở bất kỳ phần nào còn lại của $40 của nó, và toàn bộ key biến mất trong mười một ngày bất kể. Phần còn lại của workspace không bị động chạm.
Cả hai trường đều là USD-và-thời-gian trên key, không phải chính sách toàn workspace. Để giới hạn chi tiêu của một lần chạy agent đơn lẻ (thay vì vòng đời của một key), verdict cap_cost của Firewall là cầu dao ngắt mạch theo từng lần chạy — xem quy tắc firewall. Hai cái kết hợp: mức trần key ràng buộc vòng đời, cap_cost ràng buộc một lần chạy đơn lẻ.

​
5. Ai có thể đặt những cái này

Đặt credit_limit_usd và expired_time là một phần của việc tạo hoặc chỉnh sửa một key, vốn yêu cầu vai trò Developer trở lên. Bất kỳ thành viên workspace nào cũng có thể đọc bản ghi đã che của một key; chỉ Developer+ có thể thay đổi giới hạn của nó. Key bị che khi hiển thị — plaintext chỉ hiện một lần lúc tạo (xem che key).

​
6. Bị giới hạn theo mặc định

Một key với credit_limit_usd: 0 và expired_time: -1 không có mức trần chi tiêu và không bao giờ hết hạn — agency tối đa, bán kính ảnh hưởng tệ nhất. Hãy biến đó thành ngoại lệ có chủ đích, không phải mặc định.

Không giới hạn vs bị giới hạn

Khi nào một key không mức trần, không hết hạn thực sự là lựa chọn đúng — và khi nào thì không.

Checklist least-agency

Cho mọi key production đi qua cùng một lượt làm cứng trước khi nó ra mắt.

​
7. Liên quan

Đối tượng token

Mọi trường trên một key, bao gồm các bộ đếm quota.

Gắn chính sách

Gắn một guardrail và một chính sách firewall vào cùng một key.

Quyền quá mức

Mối đe dọa mà mức trần chi tiêu và hết hạn được xây dựng để kiềm chế.
Một mức trần chi tiêu và một mốc hết hạn là bảo hiểm rẻ nhất trên một key: hai con số biến một credential vô thời hạn thành một cái fail safe — rỗng hoặc hết hạn — thay vì chạy cho đến khi hóa đơn của bạn nhận ra.