Claude 5.5: 실패한 작업에 돈을 낭비하지 마세요

진짜 중요한 Sonnet 과 Opus 세팅: effort, cache, 검증, 그리고 완료된 작업 1 건당 비용

가장 저렴한 모델은 토큰 단가가 제일 낮은 모델이 아닙니다

제대로 작업을 끝내고, 검증을 통과하며, 같은 컨텍스트에 다섯 번씩 돈을 내게 만들지 않는 모델입니다

Sonnet 5.5 와 Opus 5.5 는 이 차이를 유난히 중요하게 만듭니다. 하나는 처리량에 맞춰 가격이 책정되었고, 다른 하나는 더 어려운 작업에 맞춰 책정되었습니다. 둘 다 새로운 effort 동작 방식을 가지며, 캐시가 잘 구성된 에이전트 루프 안에서는 놀라울 정도로 저렴해질 수 있습니다

기존 설정을 그대로 복사해서 두 모델 중 어느 쪽에 넣든 결과는 더 느려지거나, 비싸지거나, 400 오류를 뱉을 수 있습니다

대신 제가 이렇게 구성하겠습니다

1작업 → SONNET 5.5 → 검증 → 필요시 OPUS 5.5 → 검증된 결과
2             ↘ effort ↗         ↘ 캐시 + 사용량 원장 ↗

저는 Substack 에서 AI 에이전트, 워크플로우, 프로덕션 시스템에 대한 실용적인 분석을 발행합니다

여기서 뉴스레터를 구독하세요

스택을 결정해야 할 단 하나의 숫자

대부분의 모델 비교는 백만 토큰당 달러로 시작합니다

하지만 당신의 에이전트가 배포하는 건 토큰이 아닙니다. 완료된 작업입니다

https://x.com/claudeai/status/2102435511222890900

다시 말하지만, 이건 그들의 테스트입니다. 당신의 아키텍처에는 당신만의 숫자가 필요합니다

즉, 인상적인 답변 하나를 읽고 대충 "좋아요"를 누르는 식의 검증으로는 안 됩니다. 코딩이라면 머지를 막았을 테스트를 사용하세요. 추출이라면 필수 필드를 라벨링된 데이터셋과 비교하세요. 리서치라면 인용된 출처가 실제로 각 주장을 뒷받침하는지 기록하세요. 데모에 들어간 그럴듯한 예시뿐만 아니라 절대 통과하지 못하는 작업의 비용까지 포함해야 합니다

그리고 하드 테일(어려운 구간)은 따로 살펴보세요. 가장 저렴한 설정이 요청의 90% 를 처리하지만 나머지 10% 에서 예산의 절반을 태워버린다면, 평균값은 다른 모델이 필요한 워크플로우 영역을 가려버릴 수 있습니다

5.5 가격표가 실제로 말하는 것

2026 년 10 월 3 일 기준, 표준 Claude API 요금으로 백만 토큰당 가격은 다음과 같습니다.

1SONNET 5.5
2신규 입력  $2       출력  $10
3캐시 읽기   $0.20    캐시 쓰기  $2.50 / 5 분, $4 / 1 시간
4
5OPUS 5.5
6신규 입력  $4       출력  $20
7캐시 읽기   $0.20    캐시 쓰기  $5 / 5 분, $8 / 1 시간

두 모델 모두 1M 토큰 컨텍스트 창과 128K 토큰 최대 출력을 지원합니다. 이는 상한선이지, 억지로 채워야 하는 목표치가 아닙니다.

모델 사양 및 가격

눈여겨볼 부분은 캐시 읽기입니다

Opus 는 신규 입력과 출력에서 두 배 비싸지만, 캐시된 프리픽스는 두 모델 모두 백만 토큰당 동일한 $0.20 입니다. 그렇다고 Opus 실행이 똑같이 저렴해지는 건 아닙니다. 여전히 새 입력, 출력, 캐시 쓰기에는 더 많은 비용을 지불합니다. 다만 읽기가 많은 세션에서는 모델 간 가격 격차가 좁혀질 수 있다는 뜻입니다

사람들이 놓치는 두 번째 차이도 있습니다. Anthropic 의 "Opus 5 보다 40% 저렴"이라는 표현은 일반적인 \실행 비용\ 추정치입니다. Opus 5.5 의 신규 토큰 가격은 20% 하락했고, 캐시 읽기 가격은 60% 하락했습니다. 서로 관련은 있지만 바꿔 쓸 수 있는 숫자는 아닙니다

Effort 는 품질 슬라이더가 아니라 라우팅 결정이다

Sonnet 5.5 는 low, medium, high, xhigh, max 를 지원합니다. API 에서는 기본값이 high 이고, Claude 앱에서는 Anthropic 이 medium 을 기본값이라고 밝히고 있습니다. Opus 5.5 는 API 에서 medium 이 기본값입니다. 이 레벨들은 이전 모델에서 같은 단어가 의미했던 바와 정확히 일치하도록 조정되지 않았습니다.

제가 사용하는 초기 매핑은 다음과 같습니다.

• Sonnet low 범위가 좁고 지연 시간에 민감하며 검증 비용이 싼 요청용
• Sonnet medium 명확하게 정의된 코딩 및 일상적인 다단계 작업용
• Sonnet high medium 실행이 실제 검증을 통과하지 못하거나, 작업이 이미 복잡한 패턴을 보일 때
• Opus medium 모호하고, 여러 파일에 걸치며, 장기간의 맥락이 필요해 Sonnet 이 맴돌기만 할 때
• Xhigh/max 평가(evals) 결과 추가 시간과 토큰을 쓸 만한 이득이 확인된 경우에만

이는 출발점일 뿐, 만능 위계질서가 아닙니다. Anthropic 이 공개한 Sonnet 5.5 의 FrontierCode 결과에서 xhigh 가 max 보다 높은 점수를 받았습니다. effort 를 높인다고 결과가 무조건 좋아지는 건 아닙니다

Anthropic 의 각주는 이 직관에 반하는 결과를 설명합니다. max 에서 모델은 추가 코드 리뷰 작업을 더 자주 시작했습니다. 조사된 두 사례에서 이는 타임아웃이나 작업 범위를 벗어난 수정으로 이어졌습니다.

실패 원인은 "모델이 충분히 생각하지 않았다"가 아니었습니다. 엉뚱한 곳에 effort 를 쓴 것입니다. 에이전트가 이미 검증을 통과하고 있다면, 추가 리뷰 턴은 비용이자 새로운 실수의 원인이 될 수 있습니다

https://x.com/edwinarbus/status/2104675431853248816

또한 max_tokens 를 낮게 잡고 이를 최적화라고 부르지 마세요. 이 제한은 사고(thinking)와 보이는 출력을 모두 포함합니다. 작업 중간에 잘라버리면 돈을 아끼는 게 아니라, 잘린 답변과 두 번째 실행 비용을 사게 됩니다

https://x.com/claudeai/status/2104633115620823187

출시 시점의 주장으로는 매력적입니다. 하지만 프로덕션 설정은 여전히 당신만의 베이스라인을 이겨야 합니다

모델 라우터를 만들기 전에 소규모 스윕부터 돌려보세요

실제로 신경 쓰는 작업 10~30 개를 고르세요. 쉬운 작업, 모호한 작업, 로그에 남아있는 짜증 나는 실패 사례를 모두 포함합니다. 각 작업에 검증기를 붙이세요. 테스트, 구조화된 비교, 정답, 또는 실행 전에 기록해 둔 사람의 평가 기준이면 됩니다

다음은 가장 작지만 유용한 API 탐색 코드입니다. 필요한 usage 필드를 로깅합니다. 동일한 작업에 대해 각 모델과 effort 레벨로 실행한 뒤, 직접 합격/불합격 판정을 붙이세요. 완전한 에이전트 벤치마크는 아닙니다.

1import anthropic
2
3client = anthropic.Anthropic()
4response = client.messages.create(
5    model="claude-sonnet-5-5",  # claude-opus-5-5 로 반복 실행
6    max_tokens=8192,
7    output_config={"effort": "medium"},  # high 로 반복 실행
8    messages=[{"role": "user", "content": "Replace this with a real task."}],
9)
10
11answer = "".join(b.text for b in response.content if b.type == "text")
12usage = response.usage
13print(answer)
14print("fresh", usage.input_tokens, "output", usage.output_tokens)
15print("cache read", usage.cache_read_input_tokens)
16print("cache write", usage.cache_creation_input_tokens)

이 코드는 공식 Anthropic Python 패키지와 ANTHROPIC_API_KEY 환경 변수를 전제로 합니다. 캐싱을 켜지 않은 단일 호출이므로 캐시 읽기와 쓰기는 0 이 나와야 정상입니다. 다음 섹션에서 무엇이 이를 바꾸는지 설명합니다

실제 에이전트라면 재시도와 도구 호출을 포함해 하나의 작업 ID 아래 있는 모든 API 호출의 사용량을 합산하세요. 검증기가 작업이 끝났다고 판단할 때만 통과로 카운트하세요

기본값을 정하기 전에 통과 1 건당 총비용을 비교하세요

테스트는 정직하게 유지해야 합니다.

• 설정을 비교하기 전에 작업 세트와 검증기를 고정하세요
• 모든 후보에 동일한 도구, 권한, 컨텍스트, 출력 요구사항을 적용하세요
• 통과율, 총 지출, 통과당 비용, 지연 시간, 그리고 가장 오래 걸리거나 비쌌던 실패를 기록하세요
• stop_reason: "max_tokens" 는 저렴한 성공이 아니라 미완료 시도로 카운트하세요

위의 짧은 코드 샘플은 단일 턴 탐색용으로 8K 출력 상한을 사용합니다. 이 상한을 긴 코딩 에이전트에 그대로 복사하지 마세요.

Anthropic 은 에이전트 작업에 훨씬 더 큰 여유를 권장합니다. 숨겨진 사고(thinking)도 같은 제한에 포함되기 때문입니다.

작업에 맞는 상한을 먼저 설정하고, 답변을 중간에 강제 중단시키기보다는 effort, 캐싱, 작업 예산으로 지출을 통제하세요

작업의 안정적인 부분을 캐싱하세요

에이전트는 동일한 시스템 지침, 도구 정의, 저장소 맵, 이전 대화를 반복해서 보냅니다. 그 프리픽스가 안정적이라면, 프롬프트 캐싱은 프롬프트를 살짝 고치는 것보다 경제성을 훨씬 크게 바꿉니다

예를 들어 200K 캐시 토큰을 50 번 읽으면 10M 캐시 읽기 토큰이 됩니다. 백만 토큰당 $0.20 이면, 두 5.5 모델 모두 읽기 비용은 $2 입니다.

Opus 5.5 에서 같은 10M 토큰을 신규 입력으로 보내면 $40 가 듭니다. 200K 토큰에 대한 첫 5 분 캐시 쓰기는 추가로 $1 입니다.

이는 프리픽스 요금만을 보여주는 예시입니다. 새 입력, 출력, 기타 쓰기, TTL 만료, 실제 캐시 미스가 청구서에 더해집니다

실전 규칙:

• Claude API 에서는 최상위 cache_control={"type": "ephemeral"} 또는 명시적 캐시 중단점으로 프롬프트 캐싱을 활성화하세요. 위의 탐색 코드는 둘 다 사용하지 않으므로 캐시 카운터는 보통 0 으로 유지됩니다
• 변경되는 사용자 요청 앞에 안정적인 지침과 도구를 배치하세요
• 턴마다 공유 프리픽스를 동일하게 유지하고, 실제 cache_read_input_tokens 값을 확인하세요
• 모델 전환은 무료 연장이 아니라 새로운 대화 예산으로 취급하세요. 캐시는 모델별로 적용되므로, Opus 요청은 Sonnet 이 방금 캐싱한 프리픽스를 읽을 수 없습니다
• 턴마다 최상위 effort 를 바꾸지 마세요. 렌더링된 프롬프트가 바뀌어 캐시된 프리픽스가 무효화됩니다

지원되는 모델에서는 메시지별 effort 변경이 이전 캐시를 보존할 수 있지만, Anthropic 의 베타 헤더가 필요하며 최상위 output_config 를 변경하는 것과는 다릅니다.

Sonnet 5.5 에는 between_tools 주의사항도 있습니다. 이 모드에서는 대화 중간에 effort 를 변경할 수 없습니다.

프롬프트 캐싱 문서

응답이 빠르다고 캐시 히트를 짐작하지 마세요. usage 객체를 읽으세요. 신규 입력, 캐시 생성, 캐시 읽기를 분리해서 보여줍니다

두 5.5 모델 모두 캐시 가능한 프리픽스에 최소 512 토큰이 필요합니다. 아주 작은 시스템 프롬프트로는 위 예시 같은 절감 효과를 낼 수 없습니다. 기본 캐시 수명은 5 분이며, 빠른 도구 루프에 적합합니다.

1 시간 쓰기는 비용이 더 들고, 실제 세션이 5 분 윈도우를 놓칠 만큼 자주 길게 멈추는 경우에만 의미가 있습니다. 더 긴 TTL 에 돈을 쓰기 전에 그 간격을 먼저 측정하세요

불안이 아닌 증거를 보고 에스컬레이션하세요

대부분의 팀은 라우터를 거꾸로 만듭니다. 작업을 "어렵다"고 분류하고, 비싼 모델로 보내고, 더 저렴한 경로로도 통과했을지 결코 배우지 않습니다.

검증기를 라우팅 신호로 사용하세요

11  Sonnet 5.5 · 선택한 effort  → 작업 실행
22  검증기                    → 통과하면 수락
33  Opus 5.5 · medium           → 실패 증거가 있을 때만 재시도
44  검증기                    → 수락하거나 증거와 함께 넘김

검증은 테스트 스위트, 스키마 유효성 검사, 정답, 또는 리뷰어일 수 있습니다. 무엇이 실패했는지 설명해야 합니다.

"답변이 약한 느낌이야"는 형편없는 에스컬레이션 신호이고, "수정된 엔드포인트가 통합 테스트 2 개를 통과하지 못함"은 유용한 신호입니다

똑같은 프롬프트를 눈 감고 반복하지 마세요. 다음 시도에는 실패한 검증 내용, 관련 산출물, 그리고 부족한 부분을 수정하라는 구체적인 지시를 함께 주세요. 에이전트가 사람의 결정이 필요한 작업을 고치려다 예산을 다 태우지 않도록 에스컬레이션 단계에 상한을 두세요

오프라인 스윕에서 Sonnet high 재시도를 테스트해 볼 수 있습니다. 검증된 작업당 비용을 실제로 낮출 때만 라이브 경로에 유지하세요. 모든 실패가 Opus 로 가기 전에 Sonnet 실행 두 번 값을 치르게 할 이유는 없습니다

모델 전환 자체가 캐시된 프리픽스를 깰 수 있습니다. 구제 경로를 Opus 우선 경로와 비교할 때 이를 반드시 고려하세요

교차점은 쉽게 놓칩니다. Sonnet 시도가 $0.06 이 들고 작업의 80% 를 통과한다고 가정해 봅시다.

실패한 작업마다 Opus 에서 마무리하는 데 $0.20 이 든다면, 예시상 평균은 완료된 작업당 $0.10 입니다. $0.06 에 5 번 중 1 번 $0.20 구제를 더한 값이죠. 이는 모든 작업에 Opus 로 $0.20 을 쓰는 것보다 낫습니다. 하지만 Sonnet 이 $0.14 이고 절반만 통과한다면, 같은 단계 구조는 모델 전환 비용을 계산하기도 전에 $0.24 가 됩니다. 이런 워크로드에서는 Opus 우선이 더 저렴하고 빠릅니다

이 수치들은 예시일 뿐, 측정된 Claude 결과가 아닙니다. 목적은 라우팅 규칙을 반증 가능하게 만드는 것입니다. 절약된 Opus 호출이 실패한 Sonnet 시도, 캐시 미스, 추가 지연 시간을 상회할 때만 이 단계 구조가 제자리를 차지합니다

중간 경로도 있습니다. 바로 Anthropic 의 베타 advisor tool입니다. Sonnet 이 작업을 계속 수행하면서 어려운 결정만 Opus 에 물어볼 수 있습니다. 전체 작업을 Opus 에 넘기지 않고요.

이것이 자동으로 더 저렴한 건 아닙니다. Sonnet 이 실제로 advisor 에 얼마나 자주 문의하는지, 그 호출 비용은 얼마인지, 최종 통과율을 개선하는지 로깅하세요. 실행자가 거의 묻지 않는다면 advisor 는 그냥 안 쓰는 기능입니다.

이 5.5 모델들에서는 조언 자체가 암호화되어 클라이언트에 반환되므로, 비공개 조언 텍스트를 감사할 수 있다고 착각하지 말고 결과물을 평가하세요

모델 선택보다 먼저 청구서를 키우는 4 가지 누수

모든 비용 문제가 새 라우터를 필요로 하지는 않습니다

먼저 이것들을 확인하세요.

• 끝없이 늘어나는 출력 두 5.5 모델 모두 출력 토큰은 신규 입력 토큰보다 5 배 비쌉니다. 대화에서 긴 답변은 이후 턴의 컨텍스트로 다시 돌아옵니다. 모든 단계를 나열한 해설 대신 산출물과 짧은 완료 메모를 요청하세요. 숨겨진 사고(thinking)도 출력으로 청구되므로, 마지막 답변만 짧게 한다고 effort 문제가 해결되지는 않습니다. 결과 검증에 필요한 증거까지 없애지는 마세요
• 작업에 필요한 것보다 큰 이미지 Sonnet 5.5 는 이전 Sonnet 릴리스보다 고해상도 이미지를 처리할 수 있어 이미지 토큰 수가 늘어날 수 있습니다. 에이전트가 버튼 레이블이나 문단 하나만 필요하다면 먼저 자르거나 크기를 줄이세요. 빽빽한 차트나 미세한 UI 디테일이 필요하다면 해상도를 유지하고, 무작정 줄이지 말고 비용을 측정하세요
• 아무도 쓰지 않는 컨텍스트 도구 정의, 오래된 로그, 지난 검색 결과, 비대해진 CLAUDE.md 가 모든 요청을 따라다닐 수 있습니다. 영구적인 규칙은 짧고 안정적인 프리픽스에 넣고, 일시적인 증거는 해당 작업 근처에 두세요. 컨텍스트를 줄인다는 명목으로 모델이 올바르게 마무리하는 데 여전히 필요한 사실까지 지우면 안 됩니다
• 아무도 기다리지 않는 작업에 인터랙티브 요금 적용하기 Message Batches API 는 두 모델 모두 입력과 출력을 50% 할인해 줍니다. 오프라인 평가, 문서 백필, 기타 비동기 작업에 유용합니다. 하지만 사용자가 당장 다음 단계를 필요로 하는 실시간 도구 루프의 대체재는 아닙니다

네 가지 모두 패턴은 같습니다. 더 많은 지능을 사거나 품질이 깨질 때까지 effort 를 낮추기 전에, 작업이 필요로 하지 않는 일을 먼저 제거하세요

절약을 400 오류로 바꾸는 마이그레이션 함정

기존 요청 본문은 5.5 제품군의 출발점으로 부적합합니다.

특히 다음 사항에 주의하세요.

• Opus 5.5 thinking 은 항상 켜져 있습니다 thinking: {"type": "disabled"} 와 기존 고정 budget_tokens 설정을 제거하고, 깊이는 output_config.effort 로 제어하세요
• 강제 도구 선택은 두 5.5 모델 모두에서 실패합니다

tool_choice 값 any 와 tool 은 400 을 반환합니다. auto 를 사용하고, 도구를 언제 써야 하는지 명시한 뒤, 도구 결과는 자체 코드에서 검증하세요

• Thinking 블록은 텍스트 블록이 아닙니다 콘텐츠를 content[0] 이 아닌 type 으로 읽으세요. 도구 루프에서는 assistant 턴과 함께 thinking 블록을 변경 없이 반환해야 합니다
• UI 가 아무 반응 없는 것처럼 보일 수 있습니다 Opus 5.5 에서 도구 간 진행 상황은 기본 표시 설정에서 비어 있는 thinking 블록으로 도착할 수 있습니다. 이전에 해당 메모를 사용자에게 렌더링했다면, 지원되는 thinking 표시 모드를 요청하고 타입별로 블록을 렌더링하세요. 그렇지 않으면 인터페이스가 멈춘 것처럼 보여도 에이전트는 작동 중일 수 있습니다
• 오래된 computer-use 도구 버전은 실패할 수 있습니다 브라우저/컴퓨터 에이전트를 마이그레이션하기 전에 현재 도구 버전을 확인하세요
• 더 작은 max_tokens 상한은 작업을 중간에 잘라낼 수 있습니다

텍스트가 숨겨져 있어도 thinking 은 포함됩니다

이것들은 프롬프트 작성 요령이 아니라 API 동작 변경 사항입니다.

Opus 마이그레이션 가이드 및 Sonnet 마이그레이션 가이드

계약은 머릿속이 아니라 Claude Code 에 두세요

API 는 모든 usage 필드를 측정할 수 있는 곳입니다. Claude Code 는 많은 사람들이 모델 변화를 처음 체감하는 곳입니다. 원칙은 동일합니다. 에이전트에게 한정된 완료 정의를 주고, 증거를 보여주게 만드세요

Claude Code 에서 /model 은 모델을 선택하고 /effort 는 지원되는 effort 레벨을 선택합니다. 세션을 비교하기 전에 활성 설정을 확인하세요. Sonnet API 기본값은 현재 당신의 Claude 앱이나 Claude Code 세션이 무엇을 쓰고 있는지 신뢰할 수 있게 설명해주지 않습니다

다음은 바로 재사용할 수 있는 완전한 CLAUDE.md 시작 블록입니다. 프로젝트에 맞게 명령어를 수정하세요

1# 작업 계약
2
3요청된 변경만 수행하세요. 관련 없는 작업은 그대로 유지하세요.
4편집 후 관련 테스트를 실행하세요. 실행할 수 없는 검사가 있으면 보고하세요.
5요청된 작업이 통과되면 멈추세요. 추가 기능이나 리뷰 루프를 덧붙이지 마세요.
6다음 형식으로 끝내세요: 변경됨 / 검증됨 / 남은 위험.
7파괴적인 작업, 배포, 또는 이 저장소 밖의 변경 전에는 반드시 물어보세요.

이 블록이 모든 실행을 마법처럼 저렴하게 만들어주지는 않습니다. 대신 성공과 실패를 눈에 보이게 만듭니다. 거기서부터 같은 작업에 대해 Sonnet 우선 워크플로우와 Opus 우선 워크플로우를 비교할 수 있습니다

작업 메시지는 여전히 구체적이어야 합니다. "결제 코드 고쳐줘"와 에이전트가 실제로 끝낼 수 있는 작업의 차이는 다음과 같습니다

1변경: 결제 엔드포인트를 새 클라이언트로 마이그레이션
2완료: 기존 클라이언트 제거, 엔드포인트 테스트 통과, diff 는 이 경로로 한정
3중지: 데이터 삭제나 저장소 외부 변경 전에는 반드시 질문
4보고: 변경된 파일, 실행한 정확한 검사, 남은 위험

이 작은 계약은 검증기에 확인할 구체적인 대상을 제공합니다. 또한 모델에게 멈춰야 할 이유를 줍니다. "완벽해질 때까지 검토해" 같은 끝없는 지시는 통과될 변경을 또 다른 유료 루프로 바꿀 수 있습니다

긴 프로젝트의 경우 압축(compaction) 후에도 살아남는 파일에 체크리스트를 보관하세요. 서브에이전트를 쓸 때는 리드 에이전트에게 보고서를 수락하기 전 그들의 증거를 검사하라고 요청하세요. 그리고 아이디어만 요청했다면 Claude 에게 구축을 시작하지 말라고 지시하세요. 이는 "더 똑똑해져라"라는 프롬프트가 아니라 워크플로우 경계입니다

제가 가장 먼저 배포할 세팅

• 실제 작업 10~30 개를 고르고 각각에 대한 검증을 정의하세요
• Sonnet 5.5 를 medium 과 high 로, 그다음 Opus 5.5 를 medium 으로 스윕하세요
• 작업별로 신규 입력, 출력, 캐시 쓰기, 캐시 읽기, 지연 시간, 재시도, 합격/불합격을 로깅하세요
• 안정적인 프리픽스를 캐시 가능하게 유지하고 usage 에서 히트를 확인하세요
• 실패한 작업만 증거와 함께 상위 단계로 라우팅하세요
• 워크로드가 바뀌면 단계 구조를 다시 검토하세요. 저장된 벤치마크가 영원한 진리는 아닙니다

어려운 10% 가 반복적으로 Sonnet 실패에서 곧바로 Opus 성공으로 넘어간다면, 처음부터 그 recognizable 한 작업 클래스를 Opus 로 라우팅하는 것을 고려하세요. Sonnet high 가 더 적은 비용으로 같은 케이스를 통과시킨다면 거기에 두세요. 라우터는 측정된 정책이지, 어떤 모델이 더 똑똑한지에 대한 영구적인 의견이 아닙니다

5.5 업그레이드는 단순히 "싼 일은 Sonnet, 어려운 일은 Opus"를 쓰라는 말이 아닙니다

모델에 가격을 매기는 걸 멈추고 완료된 작업에 가격을 매기기 시작할 기회입니다

여기까지 읽으셨다면

-> 제 Substack을 구독하세요

-> 제 Telegram에 참여하세요

-> 이 글을 북마크하세요

-> @0xwhrrari를 팔로우하세요