Auto, TokenLab Verified 또는 Official: 딜리버리 티어 선택하기

예상치 못한 경로를 발견했을 때, 모델 이름은 유용한 단서가 되지 못했지만 전달 계층은 달랐습니다. 요청을 처리하는 경로는 논리적 모델이 동일하더라도 가격 적용 대상이 달라질 수 있습니다. 이러한 불일치 때문에 저희는 전달 계층을 품질 등급이 아닌 라우팅 결정으로 취급합니다. 이는 가격 적용 대상과 라우팅을 명시해야 할 때 중요합니다. 기본 정책이 이미 귀하의 위험 및 비용 목표와 일치한다면 그 중요성은 훨씬 낮아집니다.

핵심 요약

• 요청은 official 경로 또는 verified 경로를 통해 처리될 수 있습니다. 선택 사항은 요청별로 resolvedDeliveryTier(verified 또는 official, 해당 기록이 이전 것일 경우 null)로 기록됩니다.
• auto는 세 번째 경로 유형이 아닌 기본 정책입니다. 이는 도달 가능한 경로를 유지하고 발송 전 요청이 발생시킬 수 있는 최대 비용을 추정합니다.
• 워크스페이스 및 API 키 정책 상속이 일반적인 설정입니다. 2026년 9월 11일 프로덕션 리드백(readback) 기준, 5,536개의 워크스페이스가 명시적 Auto 정책을 가지고 있었고, 217개는 시스템 기본값을 상속받았으며, 4,134개의 모든 API 키는 워크스페이스로부터 상속받았습니다. 그 주 후반의 리드백에서는 219개가 상속받은 것으로 나타났습니다. 명시적 개수가 변동 없는 이유는 상속받은 워크스페이스들이 아직 정책을 설정하지 않은 신규 생성 계정이었기 때문입니다. 이 수치는 2026년 9월 11일에 관찰된 내부 릴리스 리허설 노트에 기록된 TokenLab 2.0 출시 리드백에서 가져온 것이며, 공개 벤치마크가 아닌 내부 프로덕션 리드백으로 간주하십시오.
• Official 가격 적용 대상이 되려면 정확한 Official 경로 일치가 필요합니다. Official 경로가 일치하지 않는 경우 Verified 전달을 계속 사용할 수 있습니다.
• 헤더 X-TokenLab-Delivery-Policy를 사용하여 요청별로 전달 선택을 재정의할 수 있습니다. 워크스페이스 기본값이 일반적인 사례를 커버합니다.

세 가지 전달 계층 옵션의 실제 의미

채널은 전달 계층을 VERIFIED 및 OFFICIAL로 선언합니다. 활성 공개 전달 계층이 있는 채널만 조직 모델 바인딩에 바인딩될 수 있습니다. 워크스페이스는 논리적 모델을 특정 채널에 바인딩할 수 있습니다. 해당 채널이 활성 상태이고 삭제되지 않았으며 활성 공개 전달 계층을 선언한 경우가 아니면 해당 바인딩은 거부됩니다. 해당 채널의 모델에 대한 경로도 활성화되어 있어야 합니다.

Official은 경로가 공식 제공자 경로를 통해 처리됨을 의미하며, Verified는 TokenLab이 검증한 경로를 의미합니다. Auto는 라우터가 도달 가능한 경로 중에서 선택할 수 있도록 하는 정책입니다. 발송 후 요청을 검사할 때 resolvedDeliveryTier는 verified 또는 official 중 무엇이 처리했는지 알려줍니다. 해당 필드는 기록이 이 기능 이전의 것일 경우 null입니다.

전달 계층을 선택할 때 변경되는 사항

계층을 선택하면 가격 적용 대상, 요청별 기록, 발송 전 확인하는 추정치가 변경됩니다. 가격은 조직 수준의 전달 가격 조정 규칙을 통해 전달 계층별로 조정될 수 있으며, 해당 조정은 적용되기 전에 정규화 및 검증됩니다. 출시 후, 명시적인 Verified 또는 Official 선택은 계속 적용되며, 정책 이전의 요청은 기본적으로 Auto가 적용됩니다.

Auto는 단일 가격이 아닌 요청에 대한 최대 금액을 추정합니다. 둘 이상의 경로가 도달 가능할 수 있지만, Auto는 도달 가능한 모든 경로를 유지하며 추정치를 낮게 보이게 하려고 더 비싼 경로를 삭제하지 않습니다. 파이프라인에서 발송 전 추정치를 확인하고 완료 후 resolvedDeliveryTier를 확인합니다.

옵션	최적화 대상	선택 시점	사후 검증 가능 항목
Auto	도달 가능한 경로 및 최대 비용 추정치	기본 정책이 도달 가능한 경로 중에서 선택하게 하려는 경우	resolvedDeliveryTier가 요청을 처리한 경로를 표시
TokenLab Verified	Official을 사용할 수 없거나 필요하지 않을 때 TokenLab 검증 경로에 대한 액세스	검증된 경로가 필요하거나 일치하는 Official 경로가 없는 경우	resolvedDeliveryTier가 verified를 표시
Official	공식 가격 적용을 위한 정확한 Official 경로 일치	공식 가격 적용 대상이 필요한 경우	resolvedDeliveryTier가 official을 표시

팀의 일반적인 전달 계층 정책 구성 방법

이 섹션의 리드백 수치는 2026년 9월 11일에 관찰된 내부 릴리스 리허설 노트에 기록된 TokenLab 2.0 출시 리드백에서 가져온 것이며, 공개 벤치마크가 아닌 내부 프로덕션 리드백으로 간주하십시오.

기본 설정은 요청별 절차가 아닌 상속입니다. 2026년 9월 11일 프로덕션 리드백에서 5,536개의 워크스페이스가 명시적 Auto 정책을 가지고 있었고, 217개는 시스템 기본값을 상속받았습니다. 4,134개의 모든 API 키는 워크스페이스로부터 상속받았으므로 기존 클라이언트는 새로운 헤더가 필요하지 않았습니다. 워크스페이스 정책이 일반적인 사례를 커버하고 요청별 재정의는 예외로 남기 때문에 이러한 패턴은 합리적입니다.

같은 주 후반의 리드백에서는 5,536개의 명시적 설정과 219개의 상속이 나타났으며, 명시적 개수는 변동이 없었고 상속 개수는 217개에서 219개로 이동했습니다. 상속받은 워크스페이스들은 아직 정책을 설정하지 않은 신규 생성 계정이었으므로 계정이 생성됨에 따라 이 수치는 변동됩니다. 정책 설정은 마이그레이션이 아니었으며, 출시 시 워크스페이스나 키 정책에 대한 대량 백필(backfill)은 실행되지 않았고, 상속된 키는 클라이언트 변경이 필요 없었습니다.

워크스페이스가 논리적 모델을 특정 채널에 바인딩할 때 바인딩 규칙이 여전히 적용됩니다. 채널이 활성 상태이고 삭제되지 않았으며 활성 공개 전달 계층을 선언한 경우가 아니면 바인딩은 거부됩니다. 해당 채널의 모델에 대한 활성화된 경로도 존재해야 합니다. 채널은 Registry 선언이 ACTIVE이고 삭제 타임스탬프 없이 기록이 ACTIVE인 경우에만 조직 모델 바인딩에 바인딩될 수 있으므로, 일시 중지되거나 은퇴한 채널은 고정할 수 없습니다.

논리적 모델을 특정 채널에 고정하는 것은 워크스페이스가 개별 요청을 건드리지 않고 해당 모델에 대해 항상 Official을 사용하겠다고 표현하는 방식입니다. 전달 정책 이전의 요청은 기본적으로 Auto가 적용됩니다. 클라이언트 변경은 필요하지 않았으며, 출시 시 워크스페이스나 키 정책에 대한 대량 백필은 수행되지 않았습니다. 모델 수준의 컨텍스트는 모델 데이터 센터 가이드를 참조하십시오.

요청을 처리한 전달 계층 확인 방법

요청이 완료되면 요청 기록에서 resolvedDeliveryTier를 읽으십시오. 값은 verified 또는 official이며, null 값은 기록이 해당 필드 이전의 것임을 의미합니다. 요청은 또한 호출자가 요청한 내용을 기록하는 requestedDeliveryPolicy를 포함하며, 워크스페이스 기본값이 적용된 경우 null일 수 있습니다.

한 요청에 대해 계층을 재정의하려면 X-TokenLab-Delivery-Policy 헤더를 추가하십시오. 허용되는 값은 auto, verified, official입니다. 헤더 자체는 다음과 같습니다:

# Claude Sonnet 5 요청에 이 헤더를 추가하십시오
X-TokenLab-Delivery-Policy: verified

예를 들어, 다음 cURL 호출은 Claude Sonnet 5를 대상으로 하며 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"}]}'

호출 후 해당 호출에 대한 요청 기록은 다음을 포함합니다:

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

요청 기록에는 사용량 필드도 포함되어 있으며, Request Console 가이드에서 해당 기록의 위치와 현재 사용량 필드 이름을 확인할 수 있습니다.

요청된 계층에 활성화된 경로가 없는 경우, 게이트웨이는 delivery_tier_unavailable로 응답하며 다른 계층으로 자동으로 폴백(fallback)하지 않습니다. 요청 콘솔에서 해당 기록의 위치를 확인할 수 있으며, Request Console 가이드에서 찾는 방법을 설명합니다. 가격이나 경로가 예상과 다를 경우 콘솔과 요청 증거를 통해 어떤 계층이 트래픽을 처리했는지 확인할 수 있으므로 거기서부터 시작하십시오.

Auto가 예상치 못한 전달 계층을 선택할 때

Auto가 예상치 못한 계층을 선택하면 요청의 resolvedDeliveryTier를 읽고 귀하의 조직이 바인딩한 채널과 비교하십시오. 그런 다음 모델을 원하는 채널에 바인딩하거나 해당 요청에 대해 계층을 재정의하십시오. 이렇게 하면 기본 정책을 단순하게 유지하면서 놀라운 경로를 수정할 수 있는 구체적인 방법을 제공합니다.

제한 사항

여기에 있는 수치는 2026년 9월 11일 기준의 시점별 리드백이며, 시간이 지나면 변동될 수 있습니다. 전달 계층 가용성은 모델과 조직에 대해 어떤 경로가 활성화되어 있는지에 따라 달라집니다. 채널이 비활성 상태이거나, 삭제되었거나, 활성 공개 전달 계층이 없거나, 모델에 대한 활성화된 경로가 없는 경우 워크스페이스 바인딩이 거부될 수 있습니다. 전달 계층별 가격 조정은 귀하의 조직 규칙에 따라 달라집니다. 소스 데이터가 보편적인 비교를 제공하지 않으므로 보편적인 비교를 제공할 수 없습니다. 전달 결정은 경로 선택 후 해결되므로, 얻게 되는 계층은 해당 순간에 귀하의 조직에 대해 어떤 경로가 활성화되어 있는지에 따라 달라집니다.

FAQ

Auto는 실제로 무엇을 선택합니까?

Auto는 세 번째 경로 유형이 아닌 기본 정책입니다. 이는 도달 가능한 경로를 유지하고 발송 전 요청이 발생시킬 수 있는 최대 비용을 추정합니다. 정책 이전의 요청은 기본적으로 Auto가 적용됩니다. 발송 후 resolvedDeliveryTier는 요청이 verified 또는 official 경로를 통해 처리되었는지 기록합니다.

Verified 경로가 Official 경로보다 비용이 더 많이 드는 이유는 무엇입니까?

가격은 조직 수준의 전달 가격 조정 규칙을 통해 전달 계층별로 조정될 수 있습니다. 조정은 적용되기 전에 정규화 및 검증됩니다. 따라서 차이는 귀하의 구성에 따라 다르며, 발송 전 표시되는 가격을 확인해야 합니다.

모든 요청에 전달 계층을 설정해야 합니까?

아니요. 워크스페이스 및 API 키 정책 상속이 일반적인 설정입니다. 2026년 9월 11일 프로덕션 리드백 기준, 5,536개의 워크스페이스가 명시적 Auto 정책을 가지고 있었고, 217개는 시스템 기본값을 상속받았으며, 4,134개의 모든 API 키는 워크스페이스로부터 상속받았습니다. 상속 개수는 신규 계정이 생성됨에 따라 그 주 후반에 219개로 이동했습니다. 이 수치는 2026년 9월 11일에 관찰된 내부 릴리스 리허설 노트에 기록된 TokenLab 2.0 출시 리드백에서 가져온 것이며, 공개 벤치마크가 아닌 내부 프로덕션 리드백으로 간주하십시오. 요청별로 전달 선택을 재정의할 수 있지만, 워크스페이스 기본값이 일반적인 사례를 커버합니다.

완료된 요청을 어떤 계층이 처리했는지 어떻게 알 수 있습니까?

요청 기록에서 resolvedDeliveryTier를 읽으십시오. 값은 verified 또는 official이며, 기록이 해당 필드 이전의 것일 경우 null입니다. requestedDeliveryPolicy는 호출자가 요청한 내용을 보여주며, 워크스페이스 기본값이 적용된 경우 null일 수 있습니다. 요청 콘솔과 Request Console 가이드에서 해당 기록의 위치를 확인할 수 있습니다.

활성화된 경로가 없는 계층을 요청하면 어떻게 됩니까?

게이트웨이는 delivery_tier_unavailable로 응답합니다. 다른 계층으로 자동으로 폴백하지 않습니다. 요청 기록을 읽은 후 일치하는 경로를 활성화하거나 요청된 정책을 변경하십시오.

API 키를 생성하고 얻은 계층을 예상했던 계층과 비교하십시오. Request Console 가이드에서 해당 기록의 위치를 확인할 수 있습니다.