Khi chúng tôi thấy một lộ trình bất ngờ, tên mô hình không phải là manh mối hữu ích; cấp độ phân phối mới là manh mối. Lộ trình phục vụ một yêu cầu có thể thay đổi tính đủ điều kiện về giá ngay cả khi mô hình logic vẫn giữ nguyên. Sự không khớp đó là lý do tại sao chúng tôi coi cấp độ phân phối là một quyết định định tuyến, không phải là một huy hiệu chất lượng. Điều này quan trọng khi tính đủ điều kiện về giá và việc định tuyến cần phải rõ ràng. Nó ít quan trọng hơn khi chính sách mặc định của bạn đã phù hợp với các mục tiêu về rủi ro và chi phí của bạn.
Những điểm chính cần lưu ý
- Một yêu cầu có thể được phục vụ thông qua lộ trình
official(chính thức) hoặc lộ trìnhverified(đã xác minh). Lựa chọn này được ghi lại cho mỗi yêu cầu dưới dạngresolvedDeliveryTier(verifiedhoặcofficial, giá trị null nếu bản ghi có trước tính năng này). autolà chính sách mặc định, không phải là loại lộ trình thứ ba. Nó giữ lại các đường dẫn có thể truy cập và ước tính số tiền tối đa mà yêu cầu có thể tốn trước khi gửi đi.- Việc kế thừa chính sách của Workspace và API-key là thiết lập thông thường. Tại thời điểm đọc dữ liệu sản xuất ngày 11/09/2026, 5.536 workspace có chính sách Auto rõ ràng, 217 workspace kế thừa mặc định hệ thống và tất cả 4.134 API key kế thừa từ workspace của chúng. Một lần đọc dữ liệu sau đó trong tuần cho thấy 219 workspace kế thừa. Số lượng chính sách rõ ràng vẫn giữ nguyên vì các workspace kế thừa đó là các tài khoản mới tạo chưa thiết lập chính sách. Những số liệu này đến từ dữ liệu ra mắt TokenLab 2.0 được ghi lại trong các ghi chú diễn tập phát hành nội bộ, quan sát ngày 11/09/2026; hãy coi đây là dữ liệu sản xuất nội bộ, không phải là điểm chuẩn công khai.
- Tính đủ điều kiện về giá Official yêu cầu khớp chính xác với lộ trình Official. Phân phối Verified vẫn khả dụng khi không có lộ trình Official nào khớp.
- Bạn có thể ghi đè lựa chọn phân phối cho mỗi yêu cầu bằng header
X-TokenLab-Delivery-Policy. Mặc định của workspace sẽ bao quát các trường hợp phổ biến.
Ba tùy chọn cấp độ phân phối thực sự là gì
Các kênh khai báo cấp độ phân phối là VERIFIED và OFFICIAL. Chỉ những kênh có cấp độ phân phối công khai đang hoạt động mới có thể được liên kết với một ràng buộc mô hình tổ chức. Một workspace có thể liên kết một mô hình logic với một kênh cụ thể. Ràng buộc đó sẽ bị từ chối trừ khi kênh đang hoạt động, không bị xóa và khai báo một cấp độ phân phối công khai đang hoạt động. Một lộ trình cho mô hình trên kênh đó cũng phải được kích hoạt.
Official nghĩa là lộ trình được phục vụ bởi đường dẫn nhà cung cấp chính thức, trong khi Verified nghĩa là đường dẫn đã được TokenLab xác minh. Auto là chính sách cho phép bộ định tuyến chọn giữa các lộ trình có thể truy cập; khi chúng tôi kiểm tra một yêu cầu sau khi gửi, resolvedDeliveryTier cho chúng tôi biết liệu verified hay official đã phục vụ yêu cầu đó. Trường đó là null khi bản ghi có trước tính năng này.
Điều gì thay đổi khi bạn chọn cấp độ phân phối
Việc chọn một cấp độ sẽ thay đổi tính đủ điều kiện về giá, các bản ghi theo yêu cầu và ước tính bạn thấy trước khi gửi. Giá có thể được điều chỉnh theo từng cấp độ phân phối thông qua các quy tắc điều chỉnh giá phân phối ở cấp tổ chức, và sự điều chỉnh đó được chuẩn hóa và xác thực trước khi áp dụng. Sau khi ra mắt, các lựa chọn Verified hoặc Official rõ ràng vẫn tiếp tục được áp dụng, trong khi các yêu cầu có trước chính sách sẽ mặc định là Auto.
Auto ước tính số tiền tối đa cho yêu cầu thay vì một mức giá duy nhất. Có thể có nhiều hơn một lộ trình khả dụng, nhưng Auto giữ lại mọi lộ trình khả dụng và không loại bỏ lộ trình đắt tiền hơn để làm cho ước tính trông thấp hơn. Trong quy trình của chúng tôi, chúng tôi kiểm tra ước tính trước khi gửi và resolvedDeliveryTier sau khi hoàn tất.
| Tùy chọn | Điều được tối ưu hóa | Khi nào nên chọn | Những gì bạn có thể xác minh sau đó |
|---|---|---|---|
| Auto | Các lộ trình khả dụng và ước tính chi phí tối đa | Bạn muốn chính sách mặc định chọn giữa các lộ trình khả dụng | resolvedDeliveryTier hiển thị lộ trình đã phục vụ yêu cầu |
| TokenLab Verified | Quyền truy cập vào các đường dẫn đã được TokenLab xác minh khi Official không khả dụng hoặc không bắt buộc | Bạn cần một lộ trình đã xác minh, hoặc không có lộ trình Official nào khớp | resolvedDeliveryTier hiển thị verified |
| Official | Khớp chính xác lộ trình Official để đủ điều kiện về giá Official | Bạn cần tính đủ điều kiện về giá Official | resolvedDeliveryTier hiển thị official |
Cách các nhóm thường cấu hình chính sách cấp độ phân phối
Các số liệu trong phần này đến từ dữ liệu ra mắt TokenLab 2.0 được ghi lại trong các ghi chú diễn tập phát hành nội bộ, quan sát ngày 11/09/2026; hãy coi đây là dữ liệu sản xuất nội bộ, không phải là điểm chuẩn công khai.
Thiết lập mặc định là kế thừa, không phải là thao tác cho từng yêu cầu. Tại thời điểm đọc dữ liệu sản xuất ngày 11/09/2026, chúng tôi thấy 5.536 workspace có chính sách Auto rõ ràng, trong khi 217 workspace khác kế thừa mặc định hệ thống. Tất cả 4.134 API key kế thừa từ workspace của chúng, vì vậy các client cũ không cần header mới. Mô hình đó hợp lý vì chính sách workspace bao quát các trường hợp phổ biến, và việc ghi đè cho từng yêu cầu vẫn là ngoại lệ.
Một lần đọc dữ liệu sau đó trong cùng tuần cho thấy 5.536 chính sách rõ ràng và 219 kế thừa, trong khi số lượng chính sách rõ ràng giữ nguyên và số lượng kế thừa tăng từ 217 lên 219. Các workspace kế thừa đó là các tài khoản mới tạo chưa thiết lập chính sách, vì vậy các con số này thay đổi khi tài khoản được tạo. Việc thiết lập chính sách chưa bao giờ là một quá trình di chuyển, không có việc cập nhật hàng loạt chính sách workspace hoặc key nào được thực hiện khi ra mắt, và các key kế thừa không cần thay đổi client.
Các quy tắc ràng buộc vẫn áp dụng khi một workspace liên kết một mô hình logic với một kênh cụ thể. Ràng buộc bị từ chối trừ khi kênh đang hoạt động, không bị xóa và khai báo một cấp độ phân phối công khai đang hoạt động. Một lộ trình đã kích hoạt cho mô hình trên kênh đó cũng phải tồn tại. Một kênh chỉ có thể được liên kết với một ràng buộc mô hình tổ chức khi khai báo Registry của nó là ACTIVE và bản ghi riêng của nó là ACTIVE mà không có dấu thời gian xóa, vì vậy một kênh đã tạm dừng hoặc đã nghỉ hưu không thể được ghim.
Ghim một mô hình logic vào một kênh cụ thể là cách một workspace thể hiện "luôn luôn Official" cho mô hình này mà không cần chạm vào từng yêu cầu riêng lẻ. Các yêu cầu có trước chính sách phân phối sẽ mặc định là Auto. Không cần thay đổi client và không có việc cập nhật hàng loạt chính sách workspace hoặc key nào được thực hiện khi ra mắt. Để có ngữ cảnh ở cấp độ mô hình, hãy kết hợp điều này với hướng dẫn trung tâm dữ liệu mô hình.
Cách kiểm tra cấp độ phân phối nào đã phục vụ một yêu cầu
Khi một yêu cầu kết thúc, hãy đọc resolvedDeliveryTier trong bản ghi yêu cầu; giá trị là verified hoặc official, và giá trị null nghĩa là bản ghi có trước trường này. Yêu cầu cũng mang theo requestedDeliveryPolicy, ghi lại những gì người gọi đã yêu cầu và có thể là null khi áp dụng mặc định của workspace.
Để ghi đè cấp độ cho một yêu cầu, hãy thêm header X-TokenLab-Delivery-Policy; các giá trị được chấp nhận là auto, verified và official. Đây là header đó:
# Thêm header này vào yêu cầu Claude Sonnet 5
X-TokenLab-Delivery-Policy: verified
Ví dụ, lệnh cURL này nhắm mục tiêu vào Claude Sonnet 5 và yêu cầu official:
curl https://api.tokenlab.sh/v1/chat/completions -H "Authorization: Bearer $TOKENLAB_API_KEY" -H "Content-Type: application/json" -H "X-TokenLab-Delivery-Policy: official" -d '{"model":"Claude Sonnet 5","messages":[{"role":"user","content":"Hello"}]}'
Sau khi gọi, bản ghi yêu cầu cho cuộc gọi đó mang theo:
{
"requestedDeliveryPolicy": "official",
"resolvedDeliveryTier": "official"
}
Bản ghi yêu cầu cũng bao gồm các trường sử dụng, và hướng dẫn Request Console cho biết nơi lưu trữ bản ghi đó và tên trường hiện tại cho việc sử dụng.
Nếu cấp độ được yêu cầu không có lộ trình nào được kích hoạt, gateway sẽ trả lời với delivery_tier_unavailable và không tự động chuyển sang cấp độ khác. Request console cho biết nơi lưu trữ bản ghi đó, và hướng dẫn Request Console giải thích cách tìm nó. Chúng tôi bắt đầu từ đó khi giá hoặc lộ trình có vẻ bất ngờ, vì console và bằng chứng yêu cầu có thể cho thấy cấp độ nào đã phục vụ lưu lượng truy cập.
Khi Auto chọn một cấp độ phân phối bạn không mong đợi
Khi Auto chọn một cấp độ bạn không mong đợi, hãy đọc resolvedDeliveryTier trên yêu cầu và so sánh nó với các kênh mà tổ chức của bạn đã liên kết. Sau đó, hãy liên kết mô hình với kênh bạn muốn hoặc ghi đè cấp độ cho yêu cầu đó. Điều này giữ cho chính sách mặc định đơn giản trong khi vẫn cung cấp cho bạn cách cụ thể để sửa một lộ trình gây ngạc nhiên.
Hạn chế
Các con số ở đây là dữ liệu tại một thời điểm từ ngày 11/09/2026, và chúng sẽ thay đổi. Tính khả dụng của cấp độ phân phối phụ thuộc vào lộ trình nào đang hoạt động cho mô hình và tổ chức của bạn. Một ràng buộc workspace có thể bị từ chối nếu kênh không hoạt động, bị xóa, thiếu cấp độ phân phối công khai đang hoạt động hoặc không có lộ trình được kích hoạt cho mô hình. Việc điều chỉnh giá theo từng cấp độ phân phối phụ thuộc vào các quy tắc của tổ chức bạn. Chúng tôi không thể đưa ra so sánh phổ quát vì dữ liệu nguồn không cung cấp. Quyết định phân phối được giải quyết sau khi chọn lộ trình, vì vậy cấp độ bạn nhận được phụ thuộc vào lộ trình nào được kích hoạt cho tổ chức của bạn tại thời điểm đó.
Câu hỏi thường gặp
Auto thực sự chọn gì?
Auto là chính sách mặc định, không phải là loại lộ trình thứ ba. Nó giữ lại các đường dẫn có thể truy cập và ước tính số tiền tối đa mà yêu cầu có thể tốn trước khi gửi đi. Các yêu cầu có trước chính sách sẽ mặc định là Auto. Sau khi gửi, resolvedDeliveryTier ghi lại liệu yêu cầu được phục vụ thông qua lộ trình verified hay official.
Tại sao lộ trình Verified lại có thể tốn kém hơn lộ trình Official?
Giá có thể được điều chỉnh theo từng cấp độ phân phối thông qua các quy tắc điều chỉnh giá phân phối ở cấp tổ chức. Sự điều chỉnh được chuẩn hóa và xác thực trước khi áp dụng. Vì vậy, sự khác biệt phụ thuộc vào cấu hình của bạn, và bạn nên kiểm tra giá hiển thị trước khi gửi đi.
Tôi có phải đặt cấp độ phân phối cho mọi yêu cầu không?
Không. Việc kế thừa chính sách của Workspace và API-key là thiết lập thông thường. Tại thời điểm đọc dữ liệu sản xuất ngày 11/09/2026, 5.536 workspace có chính sách Auto rõ ràng, 217 workspace kế thừa mặc định hệ thống và tất cả 4.134 API key kế thừa từ workspace của chúng. Số lượng kế thừa tăng lên 219 vào cuối tuần đó khi các tài khoản mới được tạo. Những số liệu này đến từ dữ liệu ra mắt TokenLab 2.0 được ghi lại trong các ghi chú diễn tập phát hành nội bộ, quan sát ngày 11/09/2026; hãy coi đây là dữ liệu sản xuất nội bộ, không phải là điểm chuẩn công khai. Bạn có thể ghi đè lựa chọn phân phối cho mỗi yêu cầu, nhưng mặc định của workspace sẽ bao quát các trường hợp phổ biến.
Làm thế nào để biết cấp độ nào đã phục vụ một yêu cầu đã hoàn thành?
Đọc resolvedDeliveryTier trong bản ghi yêu cầu. Giá trị là verified hoặc official, và nó là null khi bản ghi có trước trường này. requestedDeliveryPolicy hiển thị những gì người gọi đã yêu cầu, và nó có thể là null khi áp dụng mặc định của workspace. Request console và hướng dẫn Request Console cho biết nơi lưu trữ bản ghi đó.
Điều gì xảy ra nếu tôi yêu cầu một cấp độ không có lộ trình được kích hoạt?
Gateway trả lời với delivery_tier_unavailable. Nó không tự động chuyển sang cấp độ khác. Hãy đọc bản ghi yêu cầu, sau đó kích hoạt lộ trình khớp hoặc thay đổi chính sách đã yêu cầu.
Tạo một API key và so sánh cấp độ bạn nhận được với cấp độ bạn mong đợi; hướng dẫn Request Console cho biết nơi lưu trữ bản ghi đó.
Nguồn
- TokenLab changelog: delivery tiersQuan sát ngày 2026-09-19
- TokenLab API documentationQuan sát ngày 2026-09-19
