Opus 5.5가 너프된 게 아니라, 그냥 실험 중인 것 같음

dba랑 34e는 내가 로그인을 바꿔서 여기서 끝난 거지, 실제로는 더 오래 돌아갔을 수도 있음. dba는 나중에 나온 패턴의 초기 버전이었을 거라 추측함. 34e랑 763은 캐시된 설정이나 동작이 비슷해서 한 세트로 묶었고, 그럼 eab가 세 번째가 됨. 링크는 내 추론임. 34e만 활성화된 상태에서 헤더를 넣고 뺄 때 테스트해 봄.

34e 적용/미적용 상태로 20개 요청 재실행

내 설정은 커스텀된 상태라, 저장된 요청 20개를 34e가 있을 때랑 없을 때 각각 한 번씩 재실행해 봤음. 요청 본문은 똑같이 유지했고. 34e가 오기 전에 저장해 둔 요청 10개에 대해 미리 설정해 둔 주 지표인 '총 출력량'은 별다른 결론을 못 냈음. 다른 출력 및 도구 관련 지표들도 미리 정해뒀는데, 응답을 보고 나서 아래의 상세 수치들을 뽑아봤음.

쌍으로 비교해 보면, 헤더가 있을 때 기하평균 기준으로 사고 과정을 제외한 출력은 2.23배, 도구 입력 텍스트는 2.35배 더 많았음. 이건 생성된 호출 횟수지, 완료된 작업 횟수가 아님.

ID별 일상적인 사용 패턴

xhigh effort(높은 노력) 설정에서의 메인 스레드 요청들임. 마지막 열은 나중에 실험이 적용되지 않았을 때의 샘플인데, 격차가 좀 줄어듦.

각 사고 블록은 '사고(thinking)'나 '서술(narration)'로 분류되는데, 서술 블록은 짧은 진행 상황 보고임. 실험 기간에는 이 비중이 줄었음. 내장된 "지금 뭐 하는지 말하기" 알림도 더 자주 떴음. dba, 34e, 763 적용 시에는 응답 100개당 19~20회 정도였는데, 실험 전 샘플에서는 12.9회였음. 34e랑 763에서는 그 알림 뒤에 텍스트가 따라오는 경우가 43%, 44%였는데, 이전에는 54%였음. 알림 수치는 모든 노력 수준을 합친 거임.

ID가 없는데도 바뀐 부분들이 좀 있음. 나중 샘플이랑 비교했을 때 763의 출력량과 Bash 크기는 약 1.43배 더 컸고, 다중 호출 응답은 12%에서 26%로 유지됨. "확인 중입니다..." 같은 요약 스타일도 10월 30일부터는 실험 없이도 나타나기 시작했음.

도구 사용 전 텍스트가 줄어드는 건 그냥 평소에 쓸 때나 나타나는 현상임. 리플레이 때는 반대로 작동했으니까 헤더 때문에 그런 거라고 단정할 순 없음. 작업 내용이나 다른 설정들도 기간마다 달랐으니까.

노력 대비 사고 토큰(Thinking tokens)

일상적인 사용 기준, 메인 스레드 요청당 중앙값:

사고 토큰의 경우, 실험 없이 보면 34e나 763 미만은 높은 것처럼 보임(111 대비 122와 117). 그렇다고 추론 성능이 더 좋다는 뜻은 아님. 리플레이 때는 정반대였거든. 헤더가 있을 때 사고 토큰 중앙값이 떨어졌고, 미디엄 요청 3건의 사고 토큰 평균은 헤더 있을 때 456개, 없을 때 855개였음.

763이 끝난 뒤에 미디엄은 다시 72토큰으로 돌아왔지만, 그 시점에 전달되는 프롬프트도 바뀌었음.

일반 클로드(Claude)가 더 빠르게 느껴짐

사람들이 "너프 먹었다"고 하는 것들 상당수가 그냥 실험 대상이 아닌 일반 클로드에 걸려서 그런 거 아닐까 싶음. 일반 클로드는 모든 턴을 다 볼 수 있어서 훨씬 빠르게 느껴짐. 짧은 명령어 하나 끝나고, 답장 오고, 다음 단계로 넘어가는 게 다 보이니까. 반면에 실험 중인 버전은 보통 긴 도구 호출 하나로 퉁쳐버려서 볼 게 별로 없음. 난 단계를 직접 보는 게 더 좋음.

측정된 출력 속도는 그룹 전체에서 초당 104~112토큰 정도로 일정했음. 첫 토큰까지 걸리는 시간은 실험 중에 더 짧게 나온 것 같은데, 이건 확실하진 않음. 그러니까 이건 그냥 내 체감상 그렇다는 거고, 모든 불만을 설명해주진 않음. 11월 3일에 r/ClaudeCode에 올라온 글 보면, 계정 두 개 중 하나가 같은 작업인데도 출력 토큰을 두 배나 더 썼다더라. 그 계정이 바로 불만 제기한 계정이었고. 실험 패턴이랑 비슷하긴 한데, 그 계정이 실험군으로 배정됐는지는 확인 안 됨.

배칭 프롬프트를 쓰면 명령어가 길어지긴 하지만, 추가적인 다중 호출 응답이 재현되지는 않았음(부분적으로 노력이 일치하지 않는 작은 테스트였음). 763을 제거한 뒤에 다시 보내봐도 이전 패턴은 안 나왔음. 둘 다 실험을 강제로 켜는 확실한 방법은 아님.

5시간 미터 포인트당 달러 비용

이건 작업당 비용이 아니라, 5시간 미터의 1퍼센트 포인트당 정가 기준 예상 달러 비용임.

34e와 763을 합치면 포인트당 5.24달러로, 10월 13일~29일 중앙값보다 약 30% 낮음. 그 6일 중 5일은 신뢰도가 낮은 추정치고, 유일하게 믿을 만한 11월 4일은 6.52달러였음. dba에서는 이런 하락세가 안 보였고.

정가 기준 달러에는 캐시된 읽기 비용이 포함되는데, 내 계산상으로는 미터기에 거의 영향을 안 줌. 그러니까 달러 수치가 낮다고 해서 무조건 유용한 작업이 줄었다는 뜻은 아님. 작업당 달러 비용은 아직 계산 안 해봄.

계정 확인하기

jq가 설치되어 있다면 셸에서 이걸 실행해 봐. 현재 조직에서 각 모델의 가장 최신 캐시된 대화형 CLI ID의 앞 세 글자를 보여줌:

jq -r '.oauthAccount.organizationUuid as $o | [(.clientDataCacheSlots // {})[] | select(.entrypoint=="cli" and .org==$o)] | group_by(.model)[] | max_by(.at) | "\(.model): \(.data.atis[0:3] // "no experiment")"' ~/.claude.json

no experiment는 해당 캐시 슬롯에 ID가 없다는 뜻임. 아무것도 안 뜨면 결론을 내릴 수 없음. 일치하는 캐시된 CLI 슬롯이 없을 수도 있으니까. ID가 있다고 해서 무조건 뭐가 바뀐 것도 아님. 내가 로그 남긴 다른 ID들도 실험 안 한 것처럼 작동했거든. 위 표에서 "no experiment"는 모델 슬롯에 값이 없다는 뜻임.

캐시된 ID를 상태 표시줄에 넣으려면 /statusline을 실행하고 아래 내용을 붙여넣어:

실험 표시기를 상태 표시줄에 추가하고 기존에 있던 건 다 유지해. 상태 표시줄의 stdin JSON에서 .model.id를 읽고 [1m] 접미사는 버려. ~/.claude.json을 읽어. .clientDataCacheSlots에서 .model이 해당 id이고, .entrypoint가 "cli"이며, .org가 .oauthAccount.organizationUuid와 같은 항목을 유지하고, .at이 가장 높은 걸 가져와. .data.atis가 있으면 노란색으로 "exp:"와 앞 세 글자를 표시해. 없으면 흐릿하게 "exp:none"이라고 표시해. 파일이나 필드가 없으면 아무것도 표시하지 말고 그냥 0으로 종료해. statusLine 설정에서 refreshInterval은 60으로 맞춰. 마무리하기 전에 stdin에 샘플 JSON을 넣어서 스크립트를 테스트해 봐.

그건 1년 전 얘기고, 이제는 추론 규모가 커지면 수익성이 좋아서 계정이 '보조금'을 받는 게 아니라 API보다 원가에 가까운 수준이라는 걸 알게 됐잖아.