Anthropic, Claude Code에서 '높음' 노력을 '낮음'으로 조용히 변경한 A/B 테스트 의심

Anthropic appears to be A/B testing reduced effort levels in Claude Code

▲ 203matthieu_bl184 HN 토론
Anthropic, Claude Code에서 '높음' 노력을 '낮음'으로 조용히 변경한 A/B 테스트 의심

한 개발자가 Anthropic이 Claude Code의 특정 세션에서 노력 수준을 조용히 축소하는 A/B 테스트를 진행하고 있다고 주장했습니다. 2.1.236+ 버전에서 '높음' 노력이 이전 '낮음' 수준(100점 만점에 10점)으로 처리된다는 것입니다. 이 변경은 서버 측에서 적용되며 앱 업데이트가 아니며, 변경 로그에도 언급되지 않아 개발자들이 자신의 코드가 손상된 것으로 오인할 수 있습니다. 이 테스트는 일부 사용자에게만 적용되므로 모든 사용자가 영향을 받는 것은 아닙니다.

2.1.237부터 모델은 '높음' 노력을 100점 만점에 10점으로 읽습니다. 이는 '낮음'이 예전에 사용하던 정확한 숫자이며, 변경 로그에는 한 마디도 없습니다.
원문 읽기 →HN 토론RSS

HN 토론

184
  1. pizzafeelsright

    Opus 5이 뭘 하든 그런 일은 일어나면 안 됩니다.

    프롬프트는 "설정 파일을 읽고 새 데이터로 업데이트하라"였습니다. 이 작업은 4.6에서는 파일을 읽고, 새 데이터를 파싱하고, 패치하는 데 2분도 걸리지 않습니다.

    Opus 5 결과: 컨테이너를 당기고, 샌드박스를 실행하고, 테스트 스위트를 만드는 데 43분이 걸렸으며, 여기에는 설정 파일 범위를 넘어 전체 저장소를 평가하는 것도 포함되었습니다.

    둘 다: 파일 수정 하나

  2. trq_

    안녕하세요, Claude Code 팀의 Thariq입니다. 트위터에도 올렸지만 여기에도 다시 올립니다.

    우리는 때때로 Claude Code에서 API 서빙 구성을 롤아웃 전에 테스트하는데, 지금 실행 중인 구성 중 하나가 숫자로 된 노력 값을 다르게 매핑하고 있습니다.

    그래서 Claude가 일부 사용자에게 높음에서 "10"이라고 말할 수 있는 것입니다. 척도는 0-100이 아니며, 숫자 자체는 의미가 없고, 선택한 노력이 실제로 적용되는 노력입니다. 우리는 이것이 모델 성능에 영향을 미치지 않는다는 것을 확인하기 위해 심층 평가를 실행했습니다.

    동일한 경험이어야 하지만, 명확한 성능 저하가 보이면 /feedback을 눌러 ID를 보내주세요. 크레딧을 드리겠습니다.

  3. boredumb

    특히 Anthropic을 겨냥한 것은 아니지만, 왜 우리는 모호하고 운영자가 완전히 통제하며 일치된 인센티브가 없는 토큰으로 청구하는 것을 허용하고 있습니까?

    사용자 입력이 있고 그것을 소독하여 프롬프트에 주입하여 무언가를 수행한다면, 그것이 얼마나 비용이 들지 전혀 알 수 없고 제대로 측정할 방법도 없습니다. 병렬 예로 Digital Ocean이나 AWS를 들 수 있는데, 컴퓨팅/파일 시스템/메모리/시작 시간 등을 측정하고 제한할 수 있으며, 마지막 플롭까지 돈을 할당하는 것은 불가능할 수 있지만 실제 예산과 실제 제약으로 실행할 수 있습니다. 반면 LLM에서는 소독된 사용자 프롬프트를 토크나이저에 미리 돌려보고 LLM에게 무엇을 할지 추측하게 하여 토큰 소비 추정치를 제공하고 사용자에게 합리적인 방식으로 그에 따라 행동해야 합니다.

    어쩌면 현실적이고 정적인 제한을 두는 방법을 놓치고 있을 수도 있지만, 사용자의 자유 텍스트 입력을 처리하는 일에 토큰 청구 모델을 규모 있게 사용하는 심각한 방법이 보이지 않습니다. VC 돈에 매달려서 다른 누군가가 해결할 때까지 돈을 쏟아붓지 않고서는요.

    *횡설수설을 명확히 하자면...

    우리는 리소스 사용 자체에 따라 청구되고 통제되어야 하며, 리소스 사용을 제어할 수 있는 어떤 손잡이도 돌릴 수 없는 불투명한 토큰 개념이 아니라 그런 방식이어야 합니다.

  4. hpone91

    트위터에서 Thariq의 업데이트입니다. https://x.com/trq212/status/2091247114869432543

    "우리는 때때로 Claude Code에서 API 서빙 구성을 롤아웃 전에 테스트하는데, 지금 실행 중인 구성 중 하나가 숫자로 된 노력 값을 다르게 매핑하고 있습니다.

    그래서 Claude가 일부 사용자에게 높음에서 "10"이라고 말할 수 있는 것입니다. 척도는 0-100이 아니며, 숫자 자체는 의미가 없고, 선택한 노력이 실제로 적용되는 노력입니다. 우리는 이것이 모델 성능에 영향을 미치지 않는다는 것을 확인하기 위해 심층 평가를 실행했습니다.

    동일한 경험이어야 하지만, 명확한 성능 저하가 보이면 /feedback을 눌러 ID를 보내주세요. 크레딧을 드리겠습니다."

  5. monideas

    이 현상은 Fable에서 너무 심하고 눈에 띄어서 Max 구독($200)을 Pro($20)로 다운그레이드했습니다. 기본적으로 쓸모가 없습니다. Codex 5.6 Sol은 실제로 매우 좋아서, 더 많은 사용량을 얻기 위해 계정을 하나 더 만들겠습니다.

  6. Insimwytim

    LLM 사용자들은 노력하기 싫어서 작업을 LLM에 떠넘깁니다.

    LLM도 노력하기 싫어하는 것 같습니다!

    이게 AGI인가요?

  7. N_Lens

    이것만이 아니라, 사용량 제한을 고무줄처럼 늘렸다 줄였다 하는 '최적화'와 백엔드에서 다른 모델로 라우팅하는 것도 많이 있을 것 같습니다. 인센티브가 너무 강합니다.

  8. ricardobeat

    저는 Opus 5를 거의 항상 낮은 노력으로 사용하는데 좋은 결과를 얻습니다. 특히 높음으로 하면 완전히 요청하지 않은 엉뚱한 방향으로 가는 것 같습니다. Sonnet 5도 마찬가지인 것 같습니다. 이전 모델들은 이렇게 행동하지 않았습니다.

    단 6개월 만에 분위기가 확 바뀐 것이 놀랍습니다. 올해 2월만 해도 Claude는 가장 인기 있는 LLM이었습니다.

이 날의 다른 글

2026-08-22