약간 회의적임
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에서는 반대임
믿을 수 있는 유일한 벤치마크는 실제 자신의 작업부하임

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

그 사이트는 별로 쓸모없음. 사고 토큰과 캐싱, 그리고 그 효율이 반영되지 않기 때문임
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배이지만 대부분에서 다른 모델들을 압도함. 다만 어떤 때는 싼 것과 비싼 것의 선택이 아니라, 비싸지만 가능한 것과 아예 불가능한 것의 선택이 됨. 다른 모델들과 마찬가지로 그 경계가 어디인지 배워야 함