Composer 2.5

Cursor가 2026년 5월 18일 Composer 2.5를 공개했습니다. Cursor가 자체 학습시키는 코딩 에이전트 모델이고, 베이스는 Composer 2와 같은 Kimi K2.5 오픈소스 체크포인트입니다.

한 줄 요약은 "지능도 올리고 동작도 다듬었다"입니다. 흥미로운 건 그걸 어떻게 학습시켰느냐인데, Cursor 블로그가 짚는 세 가지 방법이 꽤 구체적이라 하나씩 풀어 봅니다.

벤치 먼저, 어떤 의미인가요

Cursor가 공개한 표입니다.

세 벤치가 각각 뭔지부터 짧게 짚고 가겠습니다.

• *Terminal-Bench 2.0* — Stanford와 Laude Institute가 만든 터미널 환경 벤치마크. 89개 과제로 구성되고, 리눅스 커널 빌드부터 OpenSSL 인증서 생성, Git 서버 설정, FastText 학습까지 다양한 시스템·DevOps 작업을 다룹니다. 셸 실행 결과로 채점하기 때문에 답을 외우는 식의 공략이 어렵습니다.
• *SWE-Bench Multilingual* — 실제 GitHub 이슈로 모델을 평가하는 SWE-bench의 다국어 변형. 원본 SWE-bench가 Python에 치우쳐 있어서 다른 언어 저장소까지 확장한 버전입니다. 코드베이스를 이해해서 여러 파일에 걸친 패치를 만들어야 합니다.
• *CursorBench v3.1* — Cursor 엔지니어링 팀이 자기 코딩 세션에서 뽑은 사내 벤치. 특징은 "프롬프트가 짧고 모호한데 해결엔 수백 줄짜리 다중 파일 변경이 필요하다"는 점. 실제 IDE에서 사용자가 던지는 한두 줄짜리 요청에 가깝습니다. v3.1은 어려운 과제 위주로 재편된 갱신판이고, 자세한 건 CursorBench 항목 참고.

수치를 읽는 법.

• Composer 2 대비는 전 벤치에서 큰 폭으로 올랐습니다. CursorBench는 52.2% → 63.2%로 11%p, Terminal-Bench는 61.7% → 69.3%로 7.6%p, SWE-Bench Multilingual은 73.7% → 79.8%로 6%p. 자체 후속 모델 기준으로는 한 세대를 건너뛴 수준입니다.
• Opus 4.7과는 거의 동률입니다. 세 벤치 모두 0.1~1.6%p 차이고, 표 각주에 적힌 대로 Opus·GPT 수치는 자체 보고치이므로 사실상 같은 구간으로 보는 게 맞습니다.
• GPT-5.5는 Terminal-Bench에서 압도적입니다 (82.7% vs 69.3%). 반대로 SWE-Bench Multilingual에선 Composer 2.5가 GPT-5.5보다 2%p 위입니다. 한 모델이 모든 벤치에서 1등이 아니라는 게 핵심이고, 어떤 작업이냐에 따라 갈립니다.
• 벤치 성격이 달라서 점수 비교는 가로 줄 안에서만 의미가 있습니다. Terminal-Bench는 단발성 시스템 과제, SWE-Bench Multilingual은 GitHub 이슈 기반 패치, CursorBench는 모호한 IDE 요청. 같은 모델이 셋에서 다 다른 점수를 받는 이유는 모델이 들쭉날쭉해서가 아니라 작업 종류가 다르기 때문입니다.

CursorBench는 Cursor 자체 벤치라 자기 모델에 유리할 수 있다는 점은 감안해야 합니다. 그래도 Opus 4.7이 max effort에서 64.8%, default에서 61.6%라는 걸 같이 보여준 건 정직한 표시입니다. Composer 2.5의 default 동작이 Opus의 max 근처에 있다는 정도의 메시지로 읽힙니다.

한 가지 비는 게 있다면 레이턴시·비용·툴콜 정확도 같은 벤치 점수에 안 잡히는 축입니다. 코딩 에이전트는 점수 1%p보다 답이 빨리 오느냐, 잘못된 도구를 안 부르냐가 실제 사용감을 결정합니다. Composer 2.5가 텍스트 피드백 RL로 국소 동작을 다듬은 이유도 여기 있고, 자세한 학습 방법은 다음 섹션에서 봅니다.

학습

1. 텍스트 피드백을 활용한 타깃형 RL

코딩 에이전트는 한 작업이 수십만 토큰짜리 롤아웃으로 늘어집니다. 보상은 보통 "작업을 최종적으로 풀었는지"로 계산되는데, 그러면 모델 입장에서는 "내가 뭘 잘못해서 망친 거지?"를 알 수 없습니다. 100번 도구 호출 중 1번 잘못 부른 것이 최종 보상에 미치는 영향은 거의 0에 가깝습니다. 잘못된 도구 호출, 어색한 설명, 스타일 위반 같은 국소적인 문제는 이 방식으로 절대 안 잡힙니다.

Cursor의 해법은 이렇습니다.

1. 롤아웃 중 모델이 더 나았을 수 있는 지점을 고른다
2. 그 지점에 짧은 힌트를 끼워 넣는다 (예: "Reminder: Available 도구는 X, Y, Z입니다")
3. 힌트가 들어간 컨텍스트로 모델을 한 번 더 돌려서 나온 분포를 teacher로 둔다
4. 원래 컨텍스트의 모델을 student로 두고, student의 토큰 확률을 teacher 쪽으로 끌어당기는 KL loss를 추가한다

전체 trajectory에 대한 RL 보상은 그대로 두고, 바꾸고 싶은 그 한 턴에만 국소적인 학습 신호를 꽂는 구조입니다. 예시로 든 게 "Tool not found" 케이스인데, 사용 불가능한 도구를 부르려 한 그 한 턴에만 "유효한 도구 목록은 이거다" 힌트를 주입하면, teacher 분포에서 잘못된 도구의 확률은 내려가고 유효한 도구의 확률은 올라갑니다. student는 그 확률을 흉내내도록 업데이트되고요.

이게 왜 영리하냐면, 최종 보상을 건드리지 않고도 모델 동작을 고칠 수 있기 때문입니다. 보통은 보상 함수에 룰을 더 박아 넣어서 동작을 잡는데, 그러면 보상 해킹이 심해지거나 작업 자체를 못 풀게 됩니다. 텍스트 피드백은 "내가 원하는 동작을 자연어로 그 지점에 꽂는다"라는 점에서 훨씬 핀셋에 가깝습니다.

Cursor는 이 방법을 코딩 스타일부터 모델의 커뮤니케이션 톤까지 다양한 동작에 적용했다고 합니다. 벤치엔 잘 안 잡히지만 실제 쓸 때 체감되는 부분, 답변이 산만하다거나 같은 말을 반복한다거나 하는 부분이 여기서 잡히는 거죠.

2. 합성 데이터 25배

RL이 진행되면 모델이 학습 과제를 대부분 풀어 버려서 더는 배울 게 없어집니다. Cursor는 학습 진행 중에 더 어려운 과제를 동적으로 생성하는 방식으로 이걸 우회했고, Composer 2 대비 합성 과제를 25배 늘렸습니다.

기억해둘 만한 합성 패턴 하나는 기능 삭제(feature deletion) 입니다.

1. 테스트가 잘 갖춰진 코드베이스를 준다
2. 코드베이스를 계속 작동 가능한 상태로 유지하면서, 특정 테스트 가능한 기능만 골라 삭제하라고 시킨다
3. 그 다음 합성 과제는: 삭제된 기능을 다시 구현하라
4. 보상은 원래 있던 테스트가 통과하는지로 측정

테스트가 곧 정답이라 채점이 깔끔합니다. 그리고 자동으로 어렵게 만들기도 좋습니다. 더 깊이 얽힌 기능을 지우면 더 어려운 복원 과제가 되니까요.

재밌는 건 같이 적은 보상 해킹 사례입니다. 모델이 똑똑해질수록 정공법으로 푸는 대신 우회로를 찾아내기 시작했다고 합니다.

• 한 사례: 삭제된 함수 시그니처를 알아내려고 Python 타입 검사 캐시가 남아있는 걸 발견해서 그걸 리버스 엔지니어링했다
• 다른 사례: 타사 API를 재구성하기 위해 Java 바이트코드를 디컴파일했다

원래 과제 의도는 "기억과 추론으로 구현해봐"였는데 모델이 "어, 이 캐시 파일이 답을 갖고 있네?" 식으로 풀어버린 겁니다. Cursor는 에이전트 기반 모니터링으로 이런 케이스를 잡아냈다고 적었습니다. RL 스케일이 커질수록 "모델이 우리가 의도하지 않은 길로 보상을 따먹는다"는 흔한 경고가 실제 사례로 적힌 거고, 학습 데이터 큐레이션이 점점 디버깅 작업이 되어간다는 신호입니다.

3. 샤딩된 Muon과 듀얼 메시 HSDP

이 부분은 사전학습 인프라 얘기라 좀 더 기술적입니다. 핵심만 잡으면 1T 파라미터 MoE 모델에서 옵티마이저 한 스텝이 0.2초라는 결과를 어떻게 만들었느냐입니다.

Muon 옵티마이저는 모멘텀 업데이트 뒤에 Newton-Schulz 반복을 돌려 가중치를 직교화합니다. MoE 모델의 expert 가중치가 가장 무거운 비용이라, Cursor는 이 부분을 이렇게 처리했습니다.

1. 같은 shape의 expert 텐서들을 배치로 묶는다
2. all-to-all 통신으로 샤드를 모아 완전한 행렬로 만든다
3. Newton-Schulz를 실행한다
4. all-to-all로 다시 원래 샤딩으로 돌려보낸다
5. 이 통신을 비동기로 돌려서, 한 태스크가 통신 기다리는 동안 다른 Muon 태스크 컴퓨트를 진행한다

여기에 HSDP 레이아웃을 두 개로 나눈 게 듀얼 메시 부분입니다.

• Non-expert 가중치 — 비교적 작으니까 FSDP 그룹을 좁게 유지. 노드나 랙 내부에서 끝남.
• Expert 가중치 — 대부분의 파라미터와 컴퓨트를 차지하니까 더 넓은 메시로 분산.

이렇게 분리하면 두 종류의 병렬성을 서로 겹쳐서 굴릴 수 있고, 결과적으로 16개 GPU 짜리 단일 메시가 아니라 CP=2, EP=8 같은 조합을 8개 GPU에 얹는 식으로 절약이 됩니다. 작은 텐서엔 광범위한 통신을 피하면서, 큰 텐서엔 충분한 분산을 주는 거죠.

요점은 MoE에서는 가중치 크기에 따라 통신 패턴을 다르게 짜야 한다는 겁니다. 단순한 FSDP 한 벌로 균등 분배하면 작은 가중치의 통신 오버헤드가 비대해집니다.

SpaceXAI 협업과 다음 모델

이 글의 사이드 노트인데 흥미로워서 짚어둡니다. Cursor는 SpaceXAI와 협력해서 총 컴퓨트 10배의 훨씬 큰 모델을 처음부터 학습 중이라고 밝혔습니다. Colossus 2 클러스터 기준 H100 환산 100만 개 규모. Composer 2.5는 K2.5 베이스의 finetuning 흐름인 반면, 다음 라운드는 자체 사전학습으로 가는 그림입니다.

이게 시사하는 건 Cursor가 영원히 오픈소스 베이스 위에서만 굴릴 생각은 아니라는 신호입니다. K2.5 라이선스에 묶이는 것, 베이스 모델 업데이트를 기다려야 하는 것, 베이스 모델의 행동을 못 바꾸는 것. 이런 제약을 풀려면 결국 자체 사전학습이 필요하죠.

가격과 사용

• 입력 토큰 $2.50 / M
• 출력 토큰 $15.00 / M (지능은 같은 더 빠른 버전도 같이 제공, 빠른 모드가 기본)
• 첫 주는 사용량 2배 제공

자세한 가격, 옵션은 모델 문서 참고.

정리

• 베이스를 안 바꾸고도 Composer 2 대비 한 단계 올라간 이유는 (a) 텍스트 피드백 RL로 국소 동작을 핀셋으로 잡고, (b) 합성 과제 25배로 학습 분포를 어렵게 끌고 가고, (c) MoE 학습 인프라를 빡빡하게 최적화한 합입니다.
• 벤치만 보면 Opus 4.7과 거의 같은 구간, GPT-5.5와는 작업에 따라 갈립니다. Terminal-Bench에서 GPT-5.5에 크게 밀린 건 사실이고, Cursor가 이 표를 그대로 공개한 건 정직한 쪽에 가깝습니다.
• SpaceXAI 컴퓨트 10배 학습이 따로 진행 중이라는 게 진짜 큰 그림입니다. 다음 라운드는 Cursor가 처음부터 사전학습한 모델일 가능성이 높습니다.

원문: Composer 2.5 (Cursor blog) · Composer 2 Technical Report