Opus 5.5 빠른 모드를 켜기 전에 확인한 조건

Opus 5.5 빠른 모드는 요청 본문에 speed: "fast"만 넣으면 된다고 읽었고, 처음에는 파이프라인에 바로 넣어도 될 설정처럼 보였습니다. 그런데 가격 페이지와 빠른 모드 문서, 릴리스 노트를 함께 열어 보니 속도만 바뀌는 옵션으로 처리하기 어려웠습니다.

이 저장소에서는 아직 빠른 모드를 호출하지 않았습니다. 속도를 직접 재지도 않았습니다. 대신 켜기 전에 막혔던 지점은 접근 조건, 비용, 429 뒤의 처리였습니다. 문서에 흩어진 조건을 먼저 한 자리에 모았습니다.

먼저 결론부터

• Opus 5.5는 연구 프리뷰가 끝난 상태라 베타 헤더나 접근 신청 없이 빠른 모드를 쓸 수 있습니다.
• 요청 본문에 아래 값을 넣으면 됩니다.

{
  "speed": "fast"
}

• 문서가 말하는 효과는 첫 토큰 시간 단축이 아니라 출력 토큰 속도이며, 최대 2.5배 빠른 출력 토큰 속도로 설명됩니다.
• Opus 5.5 빠른 모드 가격은 입력 $8, 출력 $40이고 표준은 입력 $4, 출력 $20입니다. 입출력 모두 2배였습니다.
• Batch API와 Priority Tier 약정에는 빠른 모드를 함께 쓸 수 없습니다.
• 빠른 모드 전용 레이트 리밋을 넘으면 429와 retry-after 헤더가 돌아옵니다.
• SDK는 빠른 모드 429를 기본으로 2번 재시도합니다. 바로 표준 속도로 내리려면 이 재시도를 끄고 직접 처리해야 합니다.
• 빠른 속도에서 표준 속도로 내려가는 요청은 프롬프트 캐시를 공유하지 않습니다. 여기서 비용 계산이 다시 갈립니다.

Opus 5.5는 헤더 없이 켜집니다

릴리스 노트의 10월 15일 항목에서 먼저 확인한 내용은 접근 조건이었는데, Opus 5.5의 빠른 모드는 연구 프리뷰가 끝났고 더는 접근을 신청할 필요가 없다고 적혀 있습니다.

그래서 Opus 5.5에는 speed만 보내면 됩니다. 베타 헤더를 덧붙이는 흐름을 따로 만들 필요도 없습니다. 이 부분은 생각보다 빨리 끝났습니다.

다만 같은 방식이 다른 모델에 그대로 적용되지는 않습니다. Opus 5와 Opus 4.8은 아직 연구 프리뷰이며 fast-mode-2026-02-01 베타 헤더가 필요합니다. 헤더 없이 speed를 보내면 400이 돌아오는 조건입니다.

지원하지 않는 모델에 빠른 모드를 넣으면 에러가 납니다. 예외는 Opus 4.6이었습니다. 이 모델은 에러 대신 표준 속도로 처리되고, 응답의 usage.speed에는 "standard"가 찍히므로, 요청이 성공했다는 사실만으로 빠른 모드가 적용됐다고 판단하면 안 됩니다.

빨라지는 곳은 첫 토큰이 아닙니다

처음 문구만 보고는 응답 시작도 빨라질 것이라 생각하기 쉽지만, 문서는 빠른 모드를 “최대 2.5배 높은 출력 토큰 속도”로 설명합니다. 첫 토큰이 나오는 시간보다, 출력이 이어지는 구간에 효과가 있다는 뜻입니다.

그래서 스트리밍에서 차이가 가장 잘 보인다고 적혀 있습니다. 긴 응답을 계속 받는 요청과 짧은 답 하나를 받는 요청은 체감이 같지 않을 수 있습니다. 문서의 2.5배도 이 저장소에서 측정한 값은 아닙니다. 상한 표현입니다.

같은 모델이라는 설명도 확인했습니다. 빠른 모드는 지능이나 기능을 바꾸지 않습니다. 처리 속도와 가격 조건을 바꾸는 선택지입니다. 모델 교체 실험으로 기록하면 안 되는 구분입니다.

가격표를 나란히 놓고 봤습니다

가격 페이지를 보기 전에는 빠른 모드의 비용을 대략적인 할증으로 생각했습니다. 표를 나란히 놓으니 계산은 더 단순했습니다. Opus 5.5는 빠른 모드 입력 $8, 출력 $40이고 표준 모드는 입력 $4, 출력 $20입니다.

입력도 2배였습니다. 출력도 2배였습니다.

Opus 5와 Opus 4.8도 같은 배수였습니다. 빠른 모드는 입력 $10, 출력 $50이며 표준은 입력 $5, 출력 $25입니다. 모델별 금액은 다릅니다. 그래도 빠른 모드가 표준의 2배라는 구조는 같았습니다.

200k 입력 토큰을 넘는 요청도 예외가 아니어서, 빠른 모드 배수는 전체 컨텍스트에 적용됩니다. 프롬프트 캐싱 배수와 데이터 레지던시 배수도 빠른 모드 가격에 다시 적용됩니다. 속도만 보고 요청 단가를 계산하면 빠지는 항목입니다.

429 뒤에 표준으로 내리면 캐시가 갈립니다

빠른 모드에는 전용 레이트 리밋이 있어서, 초과하면 retry-after 헤더가 붙은 429가 돌아옵니다. 응답 헤더에는 anthropic-fast-input-tokens-limit, anthropic-fast-output-tokens-remaining처럼 빠른 모드 전용 값도 들어갑니다.

Opus 5.5는 Start, Build, Scale 티어에 기본 빠른 모드 한도가 있습니다. Evaluation 티어에서는 티어를 올려야 사용할 수 있습니다. 호출 코드만 바꾸면 끝나는 조건은 아니었습니다.

여기서 문서의 SDK 기본 동작을 다시 봤습니다. 빠른 모드 429가 오면 SDK는 기본으로 2번 자동 재시도합니다. 표준 속도로 즉시 내려가는 흐름을 만들려면 첫 요청의 max_retries를 0으로 두고, 429를 잡은 뒤 speed를 뺀 요청을 다시 보내야 합니다.

문제는 캐시였습니다. 빠른 속도와 표준 속도 요청은 캐시된 접두부를 공유하지 않는다고 문서에 적혀 있어서, 빠른 모드가 막혀 표준으로 내려가는 순간 앞 요청에서 기대했던 프롬프트 캐시도 적중하지 않습니다. 문서 본문을 읽다가 가장 늦게 발견한 줄이었습니다.

처리 속도는 응답의 usage.speed로 확인할 수 있습니다. "fast" 또는 "standard"가 들어갑니다. 429 처리와 모델별 예외가 있습니다. 그러니 요청에 넣은 값보다 응답에 찍힌 값을 기록하는 쪽이 맞겠습니다.

아직 켜지 않은 이유

이 저장소의 파이프라인에서는 빠른 모드를 아직 켜지 않았습니다. 그래서 2.5배가 실제로 어느 정도였는지, 429가 어느 시점에 났는지, 표준 전환 뒤 캐시 비용이 어떻게 달라졌는지는 확인하지 못했습니다.

대신 문서를 읽으며 적용 순서는 정해졌습니다. 먼저 Opus 5.5 요청에 빠른 모드를 넣고 usage.speed를 남긴 뒤, 빠른 모드 전용 한도와 429 응답을 관찰해야 합니다. 그다음에만 재시도 횟수와 표준 속도 전환을 코드에 넣을 수 있습니다.

빠른 모드는 한 줄입니다. 그 한 줄 뒤에는 가격표, 별도 한도, 재시도, 캐시 분리가 붙어 있었습니다.