Auto, TokenLab Verified veya Official: Bir Teslimat Katmanı Seçimi

Beklenmedik bir rota gördüğümüzde, model adı yararlı bir ipucu değildi; teslimat katmanı ise öyleydi. Bir isteğe hizmet eden rota, mantıksal model aynı kalsa bile fiyat uygunluğunu değiştirebilir. Bu uyumsuzluk, teslimat katmanını bir kalite rozeti olarak değil, bir yönlendirme kararı olarak ele almamızın nedenidir. Fiyat uygunluğunun ve yönlendirmenin açık olması gerektiğinde bu önemlidir. Varsayılan politikanız zaten risk ve maliyet hedeflerinizle eşleştiğinde ise çok daha az önemlidir.

Önemli Çıkarımlar

• Bir istek, bir official (resmi) rota veya bir verified (doğrulanmış) rota üzerinden sunulabilir. Seçim, her istek için resolvedDeliveryTier (verified veya official; kayıt bu özellikten önceyse null) olarak kaydedilir.
• auto, üçüncü bir rota türü değil, varsayılan politikadır. Erişilebilir yolları tutar ve gönderimden önce isteğin maliyetinin ulaşabileceği maksimum tutarı tahmin eder.
• Çalışma alanı (workspace) ve API anahtarı politikası devralma (inheritance) normal kurulumdur. 11.09.2026 tarihli üretim geri okumasında, 5.536 çalışma alanının açık bir Auto politikası vardı, 217'si sistem varsayılanını devralmıştı ve 4.134 API anahtarının tamamı kendi çalışma alanlarından devralmıştı. O haftanın ilerleyen günlerinde yapılan bir geri okuma 219'unun devraldığını gösterdi. Açık sayı sabit kaldı çünkü bu devralınan çalışma alanları henüz bir politika belirlememiş yeni oluşturulmuş hesaplardı. Bu rakamlar, 11.09.2026 tarihinde gözlemlenen ve dahili sürüm provası notlarına kaydedilen TokenLab 2.0 lansman geri okumasından gelmektedir; bunları halka açık bir benchmark olarak değil, dahili bir üretim geri okuması olarak değerlendirin.
• Official fiyatlandırma uygunluğu, tam bir Official rota eşleşmesi gerektirir. Hiçbir Official rota eşleşmediğinde Verified teslimat kullanılabilir durumda kalır.
• X-TokenLab-Delivery-Policy başlığı ile her istek için teslimat tercihini geçersiz kılabilirsiniz. Çalışma alanı varsayılanı genel durumları kapsar.

Üç teslimat katmanı seçeneği aslında nedir?

Kanallar, teslimat katmanlarını VERIFIED ve OFFICIAL olarak beyan eder. Yalnızca aktif bir genel teslimat katmanına sahip kanallar bir organizasyon model bağlamasına bağlanabilir. Bir çalışma alanı, mantıksal bir modeli belirli bir kanala bağlayabilir. Bu bağlama, kanal aktif değilse, silinmemişse ve aktif bir genel teslimat katmanı beyan etmiyorsa reddedilir. O kanaldaki model için bir rotanın da etkinleştirilmiş olması gerekir.

Official, rotanın resmi sağlayıcı yolu tarafından sunulduğu anlamına gelirken, Verified bir TokenLab-doğrulamalı yol anlamına gelir. Auto, yönlendiricinin erişilebilir rotalar arasından seçim yapmasını sağlayan politikadır; gönderimden sonra bir isteği incelediğimizde, resolvedDeliveryTier bize verified mi yoksa official mı hizmet verdiğini söyler. Kayıt bu özellikten önceyse bu alan null değerindedir.

Bir teslimat katmanı seçtiğinizde neler değişir?

Bir katman seçmek fiyat uygunluğunu, istek başına kayıtları ve gönderimden önce gördüğünüz tahmini değiştirir. Fiyatlandırma, organizasyon düzeyindeki teslimat fiyatı ayarlama kuralları aracılığıyla teslimat katmanı başına ayarlanabilir ve bu ayarlama uygulanmadan önce normalleştirilir ve doğrulanır. Lansman sonrasında, açık Verified veya Official seçimleri uygulanmaya devam ederken, politikadan önceki istekler varsayılan olarak Auto'ya döner.

Auto, tek bir fiyat yerine istek için maksimum tutarı tahmin eder. Birden fazla rota erişilebilir olabilir, ancak Auto tüm erişilebilir rotaları tutar ve tahmini daha düşük göstermek için daha pahalı rotayı elemez. İş hattımızda, gönderimden önce tahmini kontrol eder ve tamamlandıktan sonra resolvedDeliveryTier değerine bakarız.

Seçenek	Optimize ettiği şey	Ne zaman seçilmeli	Sonrasında neyi doğrulayabilirsiniz
Auto	Erişilebilir rotalar ve maksimum maliyet tahmini	Varsayılan politikanın erişilebilir rotalar arasından seçim yapmasını istediğinizde	resolvedDeliveryTier isteğe hizmet eden rotayı gösterir
TokenLab Verified	Official mevcut olmadığında veya gerekmediğinde TokenLab-doğrulamalı yollara erişim	Doğrulanmış bir rotaya ihtiyacınız olduğunda veya hiçbir Official rota eşleşmediğinde	resolvedDeliveryTier verified değerini gösterir
Official	Official fiyatlandırma uygunluğu için tam Official rota eşleşmesi	Official fiyatlandırma uygunluğuna ihtiyacınız olduğunda	resolvedDeliveryTier official değerini gösterir

Ekipler teslimat katmanı politikasını genellikle nasıl yapılandırır?

Bu bölümdeki geri okuma rakamları, 11.09.2026 tarihinde gözlemlenen ve dahili sürüm provası notlarına kaydedilen TokenLab 2.0 lansman geri okumasından gelmektedir; bunları halka açık bir benchmark olarak değil, dahili bir üretim geri okuması olarak değerlendirin.

Varsayılan kurulum, istek başına prosedür değil, devralmadır. 11.09.2026 tarihli üretim geri okumasında, 5.536 çalışma alanının açık bir Auto politikasına sahip olduğunu, diğer 217'sinin ise sistem varsayılanını devraldığını gördük. 4.134 API anahtarının tamamı kendi çalışma alanlarından devraldı, bu nedenle eski istemcilerin yeni bir başlığa ihtiyacı olmadı. Bu model mantıklıdır çünkü çalışma alanı politikası genel durumları kapsar ve istek başına geçersiz kılma istisna olarak kalır.

Aynı hafta yapılan daha sonraki bir geri okuma, 5.536 açık ve 219 devralınan gösterdi; açık sayı sabit kalırken devralınan sayı 217'den 219'a yükseldi. Bu devralınan çalışma alanları, henüz bir politika belirlememiş yeni oluşturulmuş hesaplardı, bu nedenle bu sayılar hesaplar oluşturuldukça değişir. Politika belirlemek hiçbir zaman bir geçiş süreci olmadı, lansmanda çalışma alanı veya anahtar politikası için toplu bir geri yükleme çalıştırılmadı ve devralınan anahtarlar istemci değişikliği gerektirmedi.

Bir çalışma alanı mantıksal bir modeli belirli bir kanala bağladığında bağlama kuralları hala geçerlidir. Bağlama, kanal aktif değilse, silinmemişse ve aktif bir genel teslimat katmanı beyan etmiyorsa reddedilir. O kanaldaki model için etkinleştirilmiş bir rota da mevcut olmalıdır. Bir kanal, yalnızca Registry beyanı ACTIVE olduğunda ve kendi kaydı silinme zaman damgası olmadan ACTIVE olduğunda bir organizasyon model bağlamasına bağlanabilir, bu nedenle duraklatılmış veya emekli edilmiş bir kanal sabitlenemez.

Mantıksal bir modeli belirli bir kanala sabitlemek, bir çalışma alanının bireysel isteklere dokunmadan bu model için her zaman Official ifadesini kullanma biçimidir. Teslimat politikasından önceki istekler varsayılan olarak Auto'ya döner. Hiçbir istemci değişikliği gerekmedi ve lansmanda çalışma alanı veya anahtar politikası için toplu bir geri yükleme yapılmadı. Model düzeyi bağlamı için bunu model veri merkezi kılavuzu ile eşleştirin.

Bir isteğe hangi teslimat katmanının hizmet ettiğini nasıl kontrol edersiniz?

Bir istek bittiğinde, istek kaydındaki resolvedDeliveryTier değerini okuyun; değer verified veya official'dır ve null değer, kaydın bu alandan önce olduğu anlamına gelir. İstek ayrıca, arayanın ne istediğini kaydeden ve çalışma alanı varsayılanı uygulandığında null olabilen requestedDeliveryPolicy değerini de taşır.

Bir istek için katmanı geçersiz kılmak isterseniz, X-TokenLab-Delivery-Policy başlığını ekleyin; kabul edilen değerler auto, verified ve official'dır. İşte başlığın kendisi:

# Claude Sonnet 5 isteğine bu başlığı ekleyin
X-TokenLab-Delivery-Policy: verified

Örneğin, bu cURL çağrısı Claude Sonnet 5'i hedefler ve official ister:

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"}]}'

Çağrıdan sonra, o çağrı için istek kaydı şunları taşır:

{
  "requestedDeliveryPolicy": "official",
  "resolvedDeliveryTier": "official"
}

İstek kaydı ayrıca kullanım alanlarını da içerir ve Request Console kılavuzu bu kaydın nerede yaşadığını ve kullanım için mevcut alan adlarını gösterir.

İstenen katmanın etkinleştirilmiş bir rotası yoksa, ağ geçidi delivery_tier_unavailable ile yanıt verir ve sessizce başka bir katmana geri dönmez. İstek konsolu bu kaydın nerede yaşadığını gösterir ve Request Console kılavuzu onu nasıl bulacağınızı açıklar. Bir fiyat veya rota beklenmedik göründüğünde oradan başlarız, çünkü konsol ve istek kanıtları trafiğe hangi katmanın hizmet ettiğini gösterebilir.

Auto beklemediğiniz bir teslimat katmanını seçtiğinde

Auto beklemediğiniz bir katman seçtiğinde, istek üzerindeki resolvedDeliveryTier değerini okuyun ve bunu organizasyonunuzun bağladığı kanallarla karşılaştırın. Ardından modeli istediğiniz kanala bağlayın veya o istek için katmanı geçersiz kılın. Bu, varsayılan politikayı basit tutarken şaşırtıcı bir rotayı düzeltmeniz için size somut bir yol sağlar.

Sınırlamalar

Buradaki rakamlar 11.09.2026 tarihinden itibaren bir anlık geri okumadır ve zamanla kayacaktır. Teslimat katmanı kullanılabilirliği, modeliniz ve organizasyonunuz için hangi rotaların aktif olduğuna bağlıdır. Kanal aktif değilse, silinmişse, aktif bir genel teslimat katmanından yoksunsa veya model için etkinleştirilmiş bir rotası yoksa bir çalışma alanı bağlaması reddedilebilir. Teslimat katmanı başına fiyat ayarlaması kendi organizasyon kurallarınıza bağlıdır. Kaynak veriler bir tane sağlamadığı için evrensel bir karşılaştırma yapamayız. Teslimat kararı rota seçiminden sonra çözümlenir, bu nedenle aldığınız katman, o anda organizasyonunuz için hangi rotaların etkinleştirildiğine bağlıdır.

SSS

Auto aslında neyi seçer?

Auto, üçüncü bir rota türü değil, varsayılan politikadır. Erişilebilir yolları tutar ve gönderimden önce isteğin maliyetinin ulaşabileceği maksimum tutarı tahmin eder. Politikadan önceki istekler varsayılan olarak Auto'ya döner. Gönderimden sonra resolvedDeliveryTier, isteğin verified veya official bir rota üzerinden sunulup sunulmadığını kaydeder.

Neden bir Verified rota, bir Official rotadan daha pahalı olsun?

Fiyatlandırma, organizasyon düzeyindeki teslimat fiyatı ayarlama kuralları aracılığıyla teslimat katmanı başına ayarlanabilir. Ayarlama, uygulanmadan önce normalleştirilir ve doğrulanır. Bu nedenle fark yapılandırmanıza bağlıdır ve gönderimden önce gösterilen fiyatı kontrol etmelisiniz.

Her istekte bir teslimat katmanı ayarlamak zorunda mıyım?

Hayır. Çalışma alanı ve API anahtarı politikası devralma normal kurulumdur. 11.09.2026 tarihli üretim geri okumasında, 5.536 çalışma alanının açık bir Auto politikası vardı, 217'si sistem varsayılanını devralmıştı ve 4.134 API anahtarının tamamı kendi çalışma alanlarından devralmıştı. Devralınan sayı, yeni hesaplar oluşturuldukça o haftanın ilerleyen günlerinde 219'a yükseldi. Bu rakamlar, 11.09.2026 tarihinde gözlemlenen ve dahili sürüm provası notlarına kaydedilen TokenLab 2.0 lansman geri okumasından gelmektedir; bunları halka açık bir benchmark olarak değil, dahili bir üretim geri okuması olarak değerlendirin. Teslimat tercihini istek başına geçersiz kılabilirsiniz, ancak çalışma alanı varsayılanı genel durumları kapsar.

Tamamlanmış bir isteğe hangi katmanın hizmet ettiğini nasıl anlarım?

İstek kaydındaki resolvedDeliveryTier değerini okuyun. Değer verified veya official'dır ve kayıt bu alandan önceyse null değerindedir. requestedDeliveryPolicy, arayanın ne istediğini gösterir ve çalışma alanı varsayılanı uygulandığında null olabilir. İstek konsolu ve Request Console kılavuzu bu kaydın nerede yaşadığını gösterir.

Etkin rotası olmayan bir katman istersem ne olur?

Ağ geçidi delivery_tier_unavailable ile yanıt verir. Sessizce başka bir katmana geri dönmez. İstek kaydını okuyun, ardından eşleşen bir rotayı etkinleştirin veya istenen politikayı değiştirin.

Bir API anahtarı oluşturun ve aldığınız katmanı beklediğiniz katmanla karşılaştırın; Request Console kılavuzu bu kaydın nerede yaşadığını gösterir.