CursorBench 3.1 모델 평가 결과

 (cursor.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Cursor의 코딩 모델 평가표에서 Fable 5 Max가 72.9%로 1위를 기록해, 상위권 경쟁의 기준점이 됨
  • Fable 5 계열은 Max, Extra High, High, Medium이 1~4위를 모두 차지하며 다른 모델군과 뚜렷한 격차를 보임
  • 5위권 이후에는 Opus 4.7 Max 64.8%, GPT-5.5 Extra High 64.3%, Fable 5 Low 64.2%, Opus 4.8 Max 63.8%, Composer 2.5 63.2%가 이어짐
  • CursorBench 3.1은 코드베이스 이해, 버그 찾기, 계획, 코드 리뷰 중심 작업을 추가하고 일부 편집 작업의 채점 기준을 개선함
  • 평균 작업당 비용은 공개 토큰 가격과 작업별 사용 토큰으로 계산되며, 작은 점수 차이는 통계적으로 의미 없을 수 있음

상위권은 Fable 5가 독식

  • CursorBench 3.1 표는 모델별 순위, 점수, 평균 작업당 비용, 사용량 관련 수치를 함께 비교함
  • 1위부터 4위까지는 모두 Fable 5 계열임
    • Fable 5 Max: 72.9%, $18.02, 63,842, 76
    • Fable 5 Extra High: 72.0%, $13.74, 48,754, 63
    • Fable 5 High: 70.6%, $10.81, 37,173, 54
    • Fable 5 Medium: 69.8%, $8.27, 28,507, 47
  • 5~10위 구간에서는 Opus, GPT-5.5, Fable, Composer 모델이 섞여 있음
    • Opus 4.7 Max: 64.8%, $11.02, 62,989, 96
    • GPT-5.5 Extra High: 64.3%, $4.37, 17,905, 46
    • Fable 5 Low: 64.2%, $5.70, 18,882, 36
    • Opus 4.8 Max: 63.8%, $7.59, 77,370, 60
    • Composer 2.5: 63.2%, $0.55, 15,152, 37
    • GPT-5.5 High: 62.6%, $3.59, 13,329, 40

중하위권 모델별 점수

  • 11~20위는 Opus, Sonnet, GPT-5.5 모델이 주로 차지함
    • Opus 4.8 Extra High: 62.1%, $6.14, 55,622, 54
    • Opus 4.7 Extra High: 61.6%, $7.11, 43,942, 72
    • Sonnet 5 Max: 61.2%, $6.87, 93,485, 93
    • Opus 4.7 High: 59.4%, $5.01, 32,227, 59
    • GPT-5.5 Medium: 59.2%, $2.22, 9,065, 35
    • Opus 4.8 High: 58.4%, $4.41, 36,788, 45
    • Sonnet 5 Extra High: 58.4%, $5.23, 58,228, 86
    • Sonnet 5 High: 57.0%, $3.74, 41,735, 66
    • Opus 4.8 Medium: 56.6%, $3.83, 31,684, 41
    • Sonnet 5 Medium: 54.9%, $2.57, 27,469, 53
  • 21~36위에는 GLM, Kimi, Gemini, Sonnet, Composer 등이 포함됨
    • GLM 5.2 Max: 54.6%, $3.11, 51,312, 83
    • Opus 4.8 Low: 54.3%, $2.93, 22,726, 36
    • Opus 4.7 Medium: 52.7%, $2.93, 19,193, 41
    • Kimi K2.7 Code: 52.7%, $1.92, 32,902, 70
    • Composer 2: 52.2%, $0.56, 14,163, 40
    • GLM 5.2 High: 50.7%, $2.46, 30,621, 76
    • Gemini 3.5 Flash: 49.8%, $1.94, 35,105, 79
    • Sonnet 4.6 Max: 49.0%, $3.09, 40,280, 55
    • GPT-5.5 Low: 48.8%, $1.19, 4,923, 24
    • Sonnet 4.6 High: 48.8%, $3.06, 37,352, 57
    • Opus 4.7 Low: 48.3%, $1.87, 13,164, 29
    • Sonnet 5 Low: 47.7%, $1.46, 17,028, 37
    • Kimi 2.6: 47.6%, $1.27, 24,783, 56
    • Sonnet 4.6 Medium: 46.0%, $2.64, 31,360, 50
    • Sonnet 4.6 Low: 41.5%, $1.89, 21,211, 50
    • Kimi 2.5: 31.9%, $0.87, 9,446, 30

CursorBench 3.1의 평가 범위

  • CursorBench 3.1은 코드베이스 이해, 버그 찾기, 계획, 코드 리뷰에 초점을 둔 문제를 도입함
  • 일부 편집 작업의 채점 기준도 개선됨
  • CursorBench 3.0은 편집, 리팩터링, 버그 수정 문제에 초점을 둔 초기 작업 세트였음

비용 계산과 해석 제약

  • 평균 작업당 비용은 각 모델의 공개 per-million-token pricing을 사용해 계산됨
  • 입력, 캐시 읽기, 캐시 쓰기, 출력 가격을 모두 포함함
  • 각 모델이 CursorBench 3.1 작업에서 사용한 토큰에 가격을 적용한 뒤, 작업 전체 평균을 냄
  • 결과에는 변동성이 남아 있으며, 작은 점수 차이는 통계적으로 의미 없을 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 약간 회의적임
    Cursor의 벤치마크에서는 Cursor 모델인 Composer 2.5가 Opus 4.8 max와 GPT-5.5 xhigh만큼 좋으면서 가격은 훨씬 낮다고 나옴
    하지만 Artificial Analysis 테스트에서는 Composer 2.5가 꽤 뒤처짐: https://artificialanalysis.ai/agents/coding-agents
    DeepSWE 벤치마크를 보면 GPT-5.5 xhigh는 64, Opus 4.8 max는 56, Cursor 2.5는 16임
    Cursor가 누군가에게는 잘 맞을 수 있다는 건 의심하지 않지만, Opus 4.8이나 GPT-5.5의 경쟁자라는 주장은 미심쩍음. 자기 벤치마크에서는 잘 나오고 제3자 벤치마크에서는 크게 뒤처진다는 게 너무 편리해 보임

    • Cursor에서 일하고 있음. Composer 2.5 출시 당시에는 AA의 종합 벤치마크에서 꽤 경쟁력 있게 나왔고, 전체 3위였던 걸로 기억함
      최근 AA가 DeepSWE를 사용하도록 바꿨는데, 이 벤치마크는 매우 긴 범위의 작업에 더 초점을 둠. Composer는 아직 그런 작업에 강하지 않아서 다음 모델에서 개선하려고 작업 중임
      전반적으로 어떤 벤치마크에서는 Composer가 잘 나오고, 어떤 곳에서는 그렇지 않음. 그래도 현재 가격대에서는 매우 유능한 모델이라고 봄. 특정 동작이나 약한 지점을 보면 여기 알려주거나 lrobinson at cursor.com으로 메일해주면 됨
    • 무슨 일이 벌어지는지 이해하기 어렵지 않음. 자기 데이터의 패턴과 특정 능력에 맞춰 강화학습을 했으니, 당연히 학습 세트와 맞물리는 벤치마크를 만들게 됨
      아이러니하게도 Cursor의 “고유 고객”이 진짜 관심 있어 하는 좁은 범위에서는 그 벤치마크가 Artificial Analysis보다 더 정확할 수도 있음. 그 외에는 그냥 또 하나의 데이터 포인트로 보면 됨
    • DeepSWE는 자체 실행 하네스만 사용한다는 점에서 약간 결함이 있고, 그 하네스가 제대로 지원하지 않는 모델에서는 문제가 생김
      이런 모델들이 어떻게 동작하는지에 하네스가 큰 영향을 준다는 증거가 많은데, DeepSWE는 그 요소를 완전히 제거함. 아마 자기들이 선호하는 몇몇 모델에서만 잘 동작하는지 확인했을 가능성이 큼
      GitHub 이슈에도 보고됐듯 캐시를 쓰지 않는 하네스라 비용 계산에도 문제가 있음. 완벽한 벤치마크는 없지만, 벤치마크 간 편차를 꽤 설명해줌
    • Cursor 세션은 Composer 모델이 강화학습되는 대상과 거의 같음. 이 벤치와 학습 데이터는 사실상 같은 분포여야 함
    • 벤치마크는 잘 모르겠지만, Composer 2.5를 많이 써봤고 실제 작업에서는 꽤 잘 동작했음

  • 축을 이렇게 잡은 선택이 꽤 당황스러움. 왼쪽이 가장 싼 쪽이라고 생각했는데, 오히려 가장 비싼 쪽임
    오른쪽 위가 최고가 되게 하려는 배치는 이해하지만, 비용 축이 거꾸로인 건 여전히 직관적이지 않음
    그건 제쳐두고, 매일 하루 종일 에이전트가 간신히 할 수 있는 수준의 매우 어려운 구현을 하고 있는데, “진짜 검증”이 필요한 작업에는 한동안 Opus를 max로 유지해야 했음. Opus가 GPT-5.5 xhigh에 가깝게라도 동작하게 하려면 사실상 그게 유일한 방법처럼 느껴졌음
    GPT-5.5를 구독으로 쓰면 문맥 창이 작아서, 400k지만 실효는 258k 정도라 Opus를 쓰는 중임
    차이는 GPT-5.5 xhigh가 대부분의 실제 사례에서 매우 빠르다는 점임. 전체 구현도 효율적이고, 깊게 생각할 필요 없는 질문에는 적응적으로 빠르게 답함
    반면 Opus 4.8 Max는 모든 걸 불필요하게 오래 씹고, 단순한 구현도 몇 시간이 걸릴 수 있어서 주로 계획과 리뷰에만 쓰게 됨
    Fable은 적응적 사고와 빠른 응답에서는 훨씬 낫지만, 아마 GPT-5.5 xhigh보다는 여전히 못할 것임. 다들 장단점은 충분히 말한 것 같고, 안타깝게도 내 어려운 작업에서는 아직 신뢰할 만한 구현자는 아님. 여전히 GPT 영역이고, Fable은 세심하게 돌보지 않으면 구현 안쪽에 크고 위험한 구멍을 남기는 경향이 있음

    • “매일 하루 종일 에이전트가 간신히 할 수 있는 수준의 매우 어려운 구현을 한다”는 내용 중에 입증 가능한 게 하나라도 있음? 아니면 그냥 믿어야 하는 건가? 전부 웃길 만큼 주관적으로 들림
    • Fable이 구현 안에 위험한 구멍을 남긴다면, GLM이나 DeepSeek을 섞어서 코드 레드팀 용도로 통합할 수도 있겠다는 생각이 듦
      Fable은 설계상 보안에 눈이 멀어 있고[0], 오픈 모델들은 그쪽을 꽤 잘함
      [0] GPT-5.6이 어떻게 될지는 불분명하지만, 블로그를 보면 비슷하게 과도하게 조심스러운 안전 필터가 들어갈 듯함
      재미있는 건 최근 Opus 릴리스 글들이 보안 능력을 일부러 낮췄다고 자랑한다는 점임. “during its [Opus 4.7] training we experimented with efforts to differentially reduce these ["cyber"] capabilities”
    • Gartner식임. 오른쪽 위가 가고 싶은 자리임
    • x축을 왜 뒤집었는지 동의함. 이 그래프는 일반 관찰자가 이해하기 매우 어려워짐
    • “GPT-5.5를 구독으로 쓰면 문맥 창이 작다”는 게 실제 작업에서 차이를 만든다고 느끼는지 궁금함
      나는 5.5 high/xhigh로 C 코드베이스를 최적화하고 벤치마크하는 데 쓰고 있는데, 초기 코드를 읽는 것만으로도 첫 문맥 창이 거의 꽉 참
      세션은 자동 압축을 5~15번 정도 하지만, 작업이 매번 최신 창에 주로 집중돼 있어서 그런대로 괜찮게 해냄
      프로그래밍에서는 GPT의 강점이 Opus보다 커서, 문맥 창 차이를 이기는 것 같음

  • Composer 2.5가 그렇게 좋다는 건 믿기 어려움. GLM 5.2나 Opus 4.6과 비교해봤는데, 문제를 생각하는 깊이와 비판적 추론이 부족했음
    다른 모델이 만든 계획을 실행하는 데는 좋지만, 그때도 주변 파일들이 실제로 동작하는 방식과 한참 다른 이상한 코드 조작을 하곤 함

    • 지금은 Cursor를 쓰지 않지만, 얼마 전 썼을 때 경험이 비슷했음. Opus로 계획하고, Composer로 구현하고, Opus로 정리했음
      Composer는 좋은 계획이 있으면 유능하지만 놀라운 수준은 아니었음. 그래도 정말 마음에 들었던 건 속도였음
      Opus가 30분 걸릴 일을 Composer는 5~10분에 끝냈음. 물론 결과가 완벽하진 않아서 Opus나 Codex로 정리 단계를 거침
      결국 균형의 문제이고, 계속 변하며, 풀고 있는 문제에 완전히 의존함. 나는 유연하게 유지하면서 그 순간 가장 잘 먹히는 프로세스에 맞춤
    • 이런 걸 보면 그냥 들쭉날쭉한 경계라는 생각이 듦. 개인 경험을 의심하진 않음. 지난달에 Grok과 X 프리미엄 계정 크레딧으로 Composer 2.5를 써봤음
      로켓을 만드는 건 아니지만 꽤 인상적이었음. 모든 모델이 가끔 멍청한 짓을 하지만, 내가 요청한 작업은 꽤 잘 해냈고 인상적인 결과도 보여줌
      Grok에서는 빠르고, 내가 많이 써본 다른 모델들과 비교하면 gemini 3.1보다 낫다고 봄. 내 기준으로는 3.5와 antigravity가 이전 gemini cli보다 못했음. Opus 4.6과는 비슷함. Claude Code의 더 최신 모델은 아직 써보지 않았음

  • 그래프를 제대로 이해했다면, Fable은 sonet과 opus에 비해 같은 작업을 달성하는 데 더 적은 토큰을 쓰고 있음. 그렇다면 좋은 일임
    한동안 더 나은 결과를 얻으려고 토큰을 마구 뱉어내는 느낌이었는데, 모델 자체가 더 많은 토큰을 생성하지 않고 좋아지는 거라면 진짜 성과처럼 느껴짐
    질문 1: 이 그래프에서 단계 수가 왜 중요한가? 뭘 알려주는가?
    질문 2: 왜 가로축을 뒤집어서 0이 원점이 아니라 오른쪽에 있게 했는가? 새로운 똑똑한 방식인가? 전에는 본 적이 없는 것 같음

  • Opus 4.7이 4.8보다 더 잘 나온 게 흥미로움. 4.6도 테스트했으면 좋았을 텐데. 어제 여기서 후속 모델보다 4.6이 낫다고 고집하다가 조롱받은 사람을 봤음
    다만 벤치마크는 늘 교묘함. DeepSWE에서는 GPT-5.5가 Opus-4.8을 꽤 큰 차이로 이기지만, FrontierCode에서는 반대임
    믿을 수 있는 유일한 벤치마크는 실제 자신의 작업부하임

  • 새 벤치마크가 나올 때마다 중국 모델들은 기존 벤치마크 기준으로 기대되는 수준보다 훨씬 낮게 나오고, 시간이 지나면 다시 회복함

    • 증류의 마법임

  • 이런 사이트들이 모두 비용/성능 파레토 프런티어 그래프를 보여주면 좋겠음. 중요한 건 주로 그 두 가지임. 속도 매개변수를 넣어서 3차원으로 만들 수도 있겠지만
    https://paraplouis.github.io/llm-pareto-frontier/는 내가 본 것 중 가장 좋은 그래프지만, 원하는 만큼 자주 업데이트되지는 않음

    • 그 사이트는 별로 쓸모없음. 사고 토큰과 캐싱, 그리고 그 효율이 반영되지 않기 때문임
      GLM5.2는 인터넷에서 PLA가 동원할 수 있는 모든 우마오당이 홍보하지만, 사고 과정이 지나치게 장황해서 부족함이 드러남
      Anthropic 모델들도 같은 문제가 있지만, 훨씬 높은 실제 지능 기반에서 출발함
      바로 그래서 신뢰할 만한 비교는 이제 임의의 입력/출력 토큰 비용이 아니라, 작업을 완료하는 데 들어가는 총비용을 기준으로 보여줌

  • Composer 2.5와 GPT 5.5를 Cursor와 Codex 양쪽에서 많이 써봤는데, Composer 2.5 성능이 GPT 5.5에 가깝다는 주장은 완전히 터무니없음
    더 빠르긴 하지만 품질은 전혀 그 수준이 아님
    게다가 Composer는 Cursor 월 구독이 있어야만 쓸 수 있으니 비용 비교도 의미가 없음. 비슷한 가격의 OpenAI 구독이면 더 나은 모델을 그만큼 쓸 수 있음

  • 가장 흥미로운 부분은 비용임. GPT 5.5와 sonnet 5는 GLM 5.2와 같은 비용이지만 더 유능한 모델임

  • Cursor 모델이 Cursor 벤치마크에서 뛰어나다니, 11시 뉴스감임
    다만 다른 모델들은 모두 직접 써본 경험상 예상한 위치에 꽤 합리적으로 놓여 있음
    Fable은 비용이 10배이지만 대부분에서 다른 모델들을 압도함. 다만 어떤 때는 싼 것과 비싼 것의 선택이 아니라, 비싸지만 가능한 것과 아예 불가능한 것의 선택이 됨. 다른 모델들과 마찬가지로 그 경계가 어디인지 배워야 함

답변달기