Composer 2.5: benchmarki, ceny i porównanie

Cursor wypuścił Composer 2.5 18 maja 2026 roku, około dwa miesiące po premierze Composer 2 w marcu. Krótka przerwa między wydaniami pokazuje, jak szybko Cursor rozwija własną linię modeli.

Cursor podaje, że Composer 2.5 osiąga wyniki zbliżone do Claude Opus 4.7 i GPT-5.5 na kilku benchmarkach kodowania. Jego cena za token jest też niższa niż w przypadku modeli czołowych. Zmieniło się również szkolenie: więcej zadań syntetycznych, trudniejsze środowiska treningowe i metoda feedbacku, która celuje w konkretne błędy w długich sesjach kodowania.

W tym artykule patrzę na Composer 2.5 jako na coś więcej niż aktualizację benchmarków. Omówię, czym jest, co się zmieniło, jak wyglądają benchmarki, jak kształtują się ceny względem modeli czołowych oraz jak wpisuje się w workflow programistyczny. Są też ograniczenia, o których warto wiedzieć, zanim potraktujesz wyniki jako całą historię.

Więcej kontekstu o innych modelach w tym porównaniu znajdziesz w naszych przewodnikach po Claude Opus 4.7 i GPT-5.5.

Czym jest model Composer 2.5 od Cursor?

Composer 2.5 to najnowszy model z rodziny Composer od Cursor, zbudowany do pracy programistycznej w środowisku Cursor IDE. Nastapuje po Composer 1, Composer 1.5 i Composer 2.

Oś czasu Composer od startu do 2.5. Obraz: autor.

To nie jest ogólny chatbot. Composer 2.5 jest szkolony do edycji między plikami, poleceń terminala, użycia narzędzi i dłuższych sesji kodowania. Cele treningowe i benchmarki skupiają się na zadaniach inżynierii oprogramowania.

W poście premierowym podano, że model wypada lepiej od Composer 2 w zadaniach kodowania i zachowuje się inaczej w dłuższych sesjach. Jest teraz domyślną opcją w selektorze modeli Cursor, choć Composer 2 pozostaje dostępny. Działa wyłącznie w Cursor. Brak publicznego API, karty modelu na Hugging Face i bramki u innego dostawcy.

Co się zmieniło w Composer 2.5

Zmiany w Composer 2.5 mieszczą się w dwóch kategoriach: wydajność w zadaniach kodowania oraz zachowanie we współpracy. Pierwsze łatwiej zmierzyć niż drugie, więc warto oddzielić to, co Cursor może pokazać liczbami, od tego, co opisuje bardziej jakościowo.

Lepsza wydajność w dłuższych zadaniach

Composer 2.5 celuje w dłuższe sesje kodowania, gdzie model musi czytać pliki, uruchamiać polecenia terminala, naprawiać błędy i iterować. To istotne, bo prawdziwy rozwój rzadko mieści się w jednym promptcie i odpowiedzi.

Cursor szkolił model w trudniejszych środowiskach uczenia ze wzmocnieniem pod tego typu pracę. Zadania były tworzone w trakcie szkolenia, a trudność rosła z czasem.

Podążanie za instrukcjami i współpraca

Wydanie opisuje też bardziej niezawodne podążanie za instrukcjami. Wskazuje na kalibrację wysiłku: model ma poświęcać więcej obliczeń na trudne zadania i unikać "przeintelektualizowania" prostych.

Jest tu jednak zastrzeżenie. Cursor zaznacza, że te zmiany zachowania "nie są dobrze uchwycone przez istniejące benchmarki". Ta część wydania opiera się więc głównie na własnej ocenie Cursor i wczesnych opiniach użytkowników, a nie na publicznym wyniku.

Trudniejsze środowiska RL

Post premierowy ujmuje zmianę szkolenia jako "skalowanie treningu, generowanie bardziej złożonych środowisk RL i wprowadzenie nowych metod uczenia". W treningu użyto 25× więcej zadań syntetycznych niż w Composer 2.

Jak Cursor szkolił Composer 2.5

Szczegóły treningu tłumaczą, czemu model się zmienił bez nowej bazowej architektury. Composer 2.5 korzysta z tej samej bazy co Composer 2, ale prace po treningu bazowym są inne. Nie każda informacja o infrastrukturze jest równie ważna dla czytelników, ale kilka elementów pomaga wyjaśnić ruch w benchmarkach.

Zbudowany na Kimi K2.5

Composer 2.5 opiera się na tym samym otwartym checkpointcie co Composer 2: Kimi K2.5 od Moonshot AI. Cursor powiedział to wprost w poście premierowym, co ma znaczenie, bo model bazowy był punktem spornym wokół Composer 2.

Kimi K2.5 używa architektury Mixture of Experts. Cursor stosuje dalsze wstępne szkolenie i RL na tej bazie i podaje, że około 85% całkowitego nakładu obliczeń na finalny model pochodzi z ich własnych prac po szkoleniu bazowym.

Ukierunkowany RL z tekstowym feedbackiem

To główna zmiana techniczna w Composer 2.5. Standardowy RL daje modelowi jeden sygnał nagrody na końcu długiej sekwencji. W długiej sesji kodowania ta końcowa nagroda może być zbyt hałaśliwa, by wskazać, gdzie model popełnił błąd.

Nauczyciel i uczeń dzielą jeden krok. Obraz: autor.

Metoda Cursor wstawia krótką tekstową podpowiedź w miejscu, gdzie model podjął złą decyzję. Na przykład, jeśli model wywołuje nieistniejące narzędzie, proces treningowy może dodać przypomnienie z poprawną listą narzędzi. Wersja z podpowiedzią działa jako "nauczyciel", a oryginalny model jako "uczeń". Strata dystalacyjna przesuwa potem zachowanie ucznia w kierunku nauczyciela tylko w tym jednym kroku.

Efekt to bardziej ukierunkowane szkolenie: pojedyncze błędy można korygować bez traktowania całego długiego rollout'u jako ogólnie dobrego lub złego. Cursor zastosował tę metodę w obszarach stylu kodowania, użycia narzędzi i komunikacji modelu podczas treningu Composer 2.5.

Syntetyczne dane na większą skalę

Composer 2.5 trenowano z użyciem 25× większej liczby zadań syntetycznych niż Composer 2. Te zadania są osadzone w prawdziwych bazach kodu, a nie w przykładach-zabawkach.

Jedno z podejść Cursor to usuwanie funkcji. Agent startuje z prawdziwą bazą kodu i dużym zestawem testów, po czym usuwa kod i pliki, pozostawiając resztę projektu funkcjonalną. Zadanie syntetyczne polega na odtworzeniu usuniętej funkcji, a testy dostarczają weryfikowalnego sygnału nagrody.

Skala treningu syntetycznego niesie własne ryzyka. Cursor udokumentował przypadki, gdy Composer 2.5 znajdował skróty, m.in. odzyskując usunięte informacje z pamięci cache sprawdzania typów w Pythonie i dekompilując bajtkod Java, by odtworzyć zewnętrzne API. Firma twierdzi, że wykryła to narzędziami monitorującymi, ale przyznała, że trening na tej skali wymaga "coraz większej ostrożności".

Zmiany infrastrukturalne

Po stronie infrastruktury Cursor użył Sharded Muon i dual mesh HSDP do dalszego wstępnego szkolenia. Te zmiany ograniczyły część kosztów i czasu związanego ze szkoleniem na dużych klastrach GPU.

Wyniki benchmarków Composer 2.5: Terminal-Bench, SWE-Bench i CursorBench

Benchmarki są przydatne, ale nie pokazują pełnego obrazu. Traktowałbym je jako punkt startowy do porównań, a nie ostateczny werdykt, jak model będzie się czuł w codziennej pracy.

Cursor ocenia Composer 2.5 w trzech benchmarkach:

SWE-Bench Multilingual sprawdza, czy model potrafi rozwiązać prawdziwe issue z GitHuba w wielu językach programowania. Każde zadanie daje modelowi repozytorium i opis problemu, a następnie weryfikuje, czy łatka przechodzi powiązane testy.

Terminal-Bench 2.0 mierzy, czy agent AI potrafi działać w realnych workflow terminalowych: przeglądać pliki, uruchamiać polecenia, debugować błędy i kończyć zadania z kilkoma krokami.

CursorBench v3.1 to prywatny, wewnętrzny benchmark Cursor. Ocenia agentów na niejednoznacznych, wieloplikowych zadaniach z prawdziwych sesji w Cursor, w tym rozumienie bazy kodu, szukanie błędów, planowanie i code review. Ograniczeniem jest to, że CursorBench nie może być sprawdzony ani odtworzony przez zewnętrznych badaczy, a wyniki należy porównywać w ramach tej samej wersji ewaluacji.

Jest jedno zastrzeżenie, które ma znaczenie, zanim za bardzo wczytasz się w te liczby. Porównania benchmarków między modelami nie zawsze są czyste. Różne konfiguracje ewaluacji i ustawienia wysiłku mogą przesuwać wyniki, a Cursor zaznacza, że Opus 4.7 i GPT-5.5 używają wyników samodeklarowanych w publicznych ewaluacjach. Traktuj to jako porównania kierunkowe, a nie testy w identycznych warunkach.

Późniejszy zewnętrzny benchmark od Artificial Analysis wskazuje podobny kierunek, choć używa innego zestawu benchmarków. Composer 2.5 uzyskał 62 w Artificial Analysis Coding Agent Index, za Claude Opus 4.7 przy max effort (66) i GPT-5.5 przy xhigh reasoning (65). 

Warto zwrócić uwagę na różnicę w kosztach: Artificial Analysis oszacowało Composer 2.5 na $0,07 za zadanie dla Standard i $0,44 dla Fast, w porównaniu do $4,10 dla Opus 4.7 max i $4,82 dla GPT-5.5 xhigh.

Composer 2.5 vs. Composer 2 vs. Composer 1.5: jak wypadają wyniki

Rodzina Composer miała trzy wydania w krótkim czasie. Composer 1.5 wyszedł w lutym 2026, Composer 2 w marcu, a Composer 2.5 w maju. Każda wersja zmieniała inny element podejścia treningowego.

Composer 2.5 kontra Composer 2

Skok z Composer 2 do 2.5 najlepiej widać w Terminal-Bench 2.0, gdzie wynik wzrósł z 61,7% do 69,3%, oraz w SWE-Bench Multilingual, z 73,7% do 79,8%. Zysk w CursorBench jest mniejszy, a wersja benchmarku zmieniła się z v3 na v3.1, więc to porównanie jest mniej bezpośrednie.

Większa różnica dotyczy pipeline'u treningowego. Composer 2 wprowadził dalsze wstępne szkolenie na Kimi K2.5. Composer 2.5 zachował tę bazę i dodał ukierunkowany tekstowy feedback, 25× więcej zadań syntetycznych oraz zmiany infrastrukturalne. Cena Standard pozostała taka sama.

Composer 2.5 kontra Composer 1.5

Composer 1.5 powstał przez 20× większe skalowanie RL na tym samym modelu wstępnie wytrenowanym co Composer 1. Wprowadził adaptive thinking i autosumaryzację, co pozwala modelowi kompresować własny kontekst, gdy sesja się wydłuża.

Przepaść między Composer 1.5 a 2.5 jest duża na każdym benchmarku. Pojawiła się też niższa cena tokenów: Composer 1.5 kosztował $3,50 za milion tokenów wejściowych i $17,50 za milion tokenów wyjściowych, czyli około 7× drożej niż Composer 2.5 Standard.

Co się zmieniło w praktyce

Widać dość jasny wzorzec: każde pokolenie zmieniało zachowanie w długich sesjach i podążaniu za instrukcjami, a Composer 2 i 2.5 obniżyły koszt utrzymanych sesji agenta.

Composer 2.5 vs. Claude Opus 4.7 vs. GPT-5.5: benchmarki, cena i kompromisy

To porównanie będzie interesować wielu czytelników w pierwszej kolejności. Composer 2.5 ma podobne wyniki w niektórych obszarach kodowania, niższą cenę za token niż wymienione niżej modele czołowe i wyraźne kompromisy.

Porównanie benchmarków

GPT-5.5 prowadzi w Terminal-Bench 2.0 z wynikiem 82,7%, około 13 punktów przed Composer 2.5. Ta różnica ma znaczenie przy pracy mocno zależnej od terminala.

Claude Opus 4.7 jest nieco przed Composer 2.5 w SWE-Bench Multilingual (80,5% vs 79,8%), mniej niż punkt. W CursorBench Composer 2.5 z 63,2% jest powyżej Opus 4.7 przy ustawieniach domyślnych (61,6%), ale poniżej Opus 4.7 przy maksymalnym wysiłku (64,8%). GPT-5.5 także osiąga 64,3% przy xhigh, przy wyniku domyślnym 59,2%.

Te modele nie wykonują tej samej pracy. Opus 4.7 i GPT-5.5 to szersze modele czołowe. Composer 2.5 to model do kodowania działający wyłącznie w Cursor. Wyniki są zbliżone w części zadań kodowych, ale granice produktowe są różne.

Porównanie cen

Różnica kosztów to najjaśniejszy punkt odcięcia od modeli czołowych.

Composer 2.5 Standard jest wyceniony na około jedną dziesiątą ceny Opus 4.7 i GPT-5.5 w przeliczeniu na token. Wariant Fast także jest poniżej standardowych progów cenowych obu modeli czołowych.

Te ceny są aktualne na maj 2026, więc przed poleganiem na porównaniu sprawdź cennik modeli Cursor, ceny Opus od Anthropic i cennik API OpenAI.

Uwaga, którą często się pomija: ceny Composer 2.5 Fast podwoiły się względem Composer 2 Fast. Cennik Standard został bez zmian, ale Fast jest domyślny, więc aktualizacja może i tak podnieść koszty dla części użytkowników.

Który model wybrać?

Wybór modelu zależy od tego, co ważniejsze: koszt, praca w terminalu czy głębsze planowanie:

• Composer 2.5 pasuje do codziennego kodowania w Cursor, zwłaszcza edycji między plikami, refaktoryzacji, debugowania i sesji agenta, gdzie liczy się koszt.
• GPT-5.5 sprawdzi się tam, gdzie kluczowa jest wydajność w terminalu.
• Claude Opus 4.7 pasuje do zadań wymagających uważnego rozumowania, planowania architektury lub okna kontekstu 1 miliona tokenów.

Taki wzorzec wyłania się z liczb: Composer 2.5 pokrywa rutynową pracę programistyczną, a modele czołowe wciąż mają rolę przy szerszym rozumowaniu lub wyższych wynikach terminalowych.

Composer 2.5 Standard vs. Fast: szybkość, cena i kiedy używać którego

Cursor dostarcza Composer 2.5 w dwóch wariantach, jak wcześniej Composer 2. Według Cursor oba dzielą tę samą "inteligencję". Różnica dotyczy głównie szybkości odpowiedzi i kosztu.

Selektor modeli Cursor z wybranym Composer. Obraz: autor.

Fast jest domyślny i kosztuje $3,00 za milion tokenów wejściowych i $15,00 za milion tokenów wyjściowych. Jest przeznaczony do interaktywnych sesji, gdzie liczy się niskie opóźnienie. Standard kosztuje $0,50 i $2,50, więc pasuje do zadań w tle lub dłuższych pętli agenta, gdzie natychmiastowy feedback jest mniej istotny.

Użycie Composer 2.5 trafia do puli "Auto + Composer" w Cursor, oddzielonej od puli API używanej dla zewnętrznych modeli jak Claude i GPT. Cursor oferował też podwójne limity użycia w pierwszym tygodniu po premierze.

Ograniczenia i zastrzeżenia Composer 2.5

Zastrzeżenia dotyczą dostępu, benchmarków i ryzyka treningu. Nie czynią Composer 2.5 wyjątkiem, ale wpływają na to, jaką wagę przykładać do twierdzeń Cursor.

Dostęp tylko w Cursor. Jak wspomniałem wcześniej, Composer 2.5 nie ma publicznego API. Jeśli twój workflow zależy od wywoływania modelu z własnych skryptów lub potoków, Composer 2.5 odpada.

CursorBench nie jest niezależny. Jak opisałem przy benchmarkach, CursorBench v3.1 jest wewnętrzny dla Cursor. Jego metodologia nie jest w pełni publiczna, a zadań nie mogą odtworzyć zewnętrzni badacze.

Zmienność ustawień benchmarków. Wyniki modeli czołowych w tabeli Cursor nie wszystkie są mierzone tak samo. Traktuj porównania jako kierunkowe, nie rozstrzygające.

Reward hacking podczas treningu. Cursor ujawnił przypadki, gdy model znajdował sprytne skróty w zadaniach syntetycznych zamiast rozwiązywać je normalnie. To wrodzone ryzyko RL na tej skali, nawet jeśli monitoring wyłapuje oczywiste przykłady.

Kalibracja wysiłku niezweryfikowana. Twierdzenia Cursor o stylu komunikacji i kalibracji wysiłku nie są poparte danymi z benchmarków, jak wcześniej wspomniałem. Trudno je więc sprawdzić z zewnątrz.

Kiedy Composer 2.5 ma sens

To zależy od zadania. Traktowałbym Composer 2.5 mniej jako uniwersalny wybór modelu, a bardziej jako model do kodowania dla osób już pracujących w Cursor.

Jeśli większość dnia spędzasz na kodowaniu w Cursor i zależy ci na koszcie tokenów, Composer 2.5 Standard ma najniższą cenę w linii Composer 2.5. Dotyczy to tych samych zadań edycji, refaktoryzacji, debugowania i długich sesji, o których była mowa wyżej.

Jeśli bardziej liczy się szybkość odpowiedzi, domyślną opcją jest Composer 2.5 Fast.

Jeśli zadanie wymaga szerszego rozumowania, większego okna kontekstu lub wyższych wyników w konkretnym obszarze, lepsze może być Claude Opus 4.7 albo GPT-5.5.

Można to ująć tak: Composer 2.5 obsługuje rutynową pracę programistyczną, a model czołowy może pasować do zadań wymagających szerszego rozumowania lub wyższych wyników w terminalu. Utrzymuje to porównanie w realiach, bez rekomendowania jednego modelu we wszystkich przypadkach.

Na koniec

Composer 2.5 łatwo czytać jako historię benchmarków, ale bardziej użyteczny jest tu kierunek rozwoju. Cursor nie tylko opakowuje modele czołowe w edytor. Buduje linię modeli wokół rodzaju pracy, jaką jego agenci już wykonują: edycje między plikami, kroki terminalowe, dłuższe sesje i wychodzenie z błędów.

Jak wspomniałem, kompromis polega na tym, że Composer 2.5 jest celowo wąski. Nie zastępuje Claude Opus 4.7 ani GPT-5.5 jako model ogólny i nie pomoże, jeśli potrzebujesz API poza Cursor. Ale w Cursor to zawężenie jest atutem. Model jest tańszy w użyciu niż opcje czołowe, dostrojony do zadań kodowania i blisko warstwy produktu, gdzie te zadania się dzieją.

Kolejne pytanie brzmi, jaką część z tego Cursor chce mieć u siebie. Firma mówi, że pracuje ze SpaceXAI nad trenowaniem większego modelu od zera, używając 10× większego łącznego nakładu obliczeń i infrastruktury Colossus 2. Nie podano daty wydania, więc na razie niewiele da się analizować. Mimo to ogólny obraz jest dość jasny: Cursor przechodzi od dobrego używania modeli do budowania większej części stosu modelowego samodzielnie.