Composer 2.5: Prestanda, priser och jämförelse

Cursor släppte Composer 2.5 den 18 maj 2026, ungefär två månader efter att Composer 2 lanserades i mars. Det korta intervallet mellan versionerna visar hur snabbt Cursor uppdaterar sin egen modellserie.

Cursor rapporterar att Composer 2.5 ligger nära Claude Opus 4.7 och GPT-5.5 på flera kodningsbenchmark. Dess tokenpris är också lägre än för frontmodellerna. Träningen ändrades också: fler syntetiska uppgifter, svårare träningsmiljöer och en feedbackmetod som riktar in sig på specifika misstag under långa kodningssessioner.

I den här artikeln ser jag på Composer 2.5 som mer än en benchmarkuppdatering. Jag går igenom vad det är, vad som ändrats, hur benchmarkresultaten ser ut, hur prissättningen står sig mot frontmodeller och var den passar i ett kodningsflöde. Det finns också begränsningar, och några av dem är värda att känna till innan du ser poängen som hela sanningen.

För mer bakgrund om de andra modellerna i den här jämförelsen, se våra guider till Claude Opus 4.7 och GPT-5.5.

Vad är Cursors modell Composer 2.5?

Composer 2.5 är den senaste modellen i Cursors Composer-familj, byggd för kodningsarbete inuti Cursor IDE. Den följer Composer 1, Composer 1.5 och Composer 2.

Composer-tidslinje från lansering till 2.5. Bild av författaren.

Det här är inte en generell chattbot. Composer 2.5 är tränad för redigeringar över flera filer, terminalkommandon, verktygsanvändning och längre kodningssessioner. Träningsmålen och benchmarken fokuserar på mjukvaruingenjörsuppgifter.

Lanseringsinlägget säger att modellen presterar bättre än Composer 2 på kodningsuppgifter och beter sig annorlunda i längre sessioner. Den är nu standardalternativet i Cursors modellväljare, även om Composer 2 finns kvar. Den körs dessutom bara i Cursor. Det finns inget publikt API, inget Hugging Face-modellkort och ingen åtkomst via någon annan leverantör.

Vad som ändrats i Composer 2.5

Ändringarna i Composer 2.5 faller i två kategorier: prestanda på kodningsuppgifter och samarbetsbeteende. Det första är lättare att mäta än det andra, så det är värt att skilja på vad Cursor kan visa med siffror och vad de beskriver mer kvalitativt.

Prestanda på längre uppgifter

Composer 2.5 siktar på längre kodningssessioner där en modell behöver läsa filer, köra terminalkommandon, åtgärda fel och iterera. Det spelar roll eftersom verklig utveckling sällan ryms i en enda prompt och respons.

Cursor tränade modellen i svårare förstärkningsinlärningsmiljöer för den här typen av arbete. Uppgifter skapades under träningen och svårighetsgraden ökade över tid.

Instruktionsföljning och samarbete

Lanseringen beskriver också mer pålitlig instruktionsföljning. Den pekar på ansträngningskalibrering: modellen ska lägga mer beräkningskraft på svåra uppgifter och undvika att överanalysera enkla.

Här finns en brasklapp. Cursor noterar att dessa beteendeförändringar "inte fångas väl av befintliga benchmark." Så den här delen vilar mest på Cursors egen bedömning och tidig användarfeedback, inte på en publik poäng.

Svårare RL-miljöer

Lanseringsinlägget beskriver träningsändringen som "skala upp träning, generera mer komplexa RL-miljöer och introducera nya inlärningsmetoder." Träningen använde 25x fler syntetiska uppgifter än Composer 2.

Hur Cursor tränade Composer 2.5

Träningsdetaljerna förklarar varför modellen ändrades utan en ny baskonstruktion. Composer 2.5 använder samma grund som Composer 2, men arbetet efter basträningen har förändrats. Inte varje infrastrukturdetalj är lika viktig för läsare, men några delar hjälper till att förklara rörelsen i benchmarkresultaten.

Byggd på Kimi K2.5

Composer 2.5 är byggd på samma open source-checkpoint som Composer 2: Moonshot AIs Kimi K2.5. Cursor sa detta direkt i lanseringsinlägget, vilket spelar roll eftersom basmodellen var en diskussionspunkt kring Composer 2.

Kimi K2.5 använder en Mixture of Experts-arkitektur. Cursor tillämpar fortsatt förträning och förstärkningsinlärning ovanpå den basen, och säger att ungefär 85% av den totala beräkningen för slutmodellen kommer från det egna arbetet efter basträningen.

Riktad RL med textuell feedback

Detta är den viktigaste tekniska förändringen i Composer 2.5. Standard-RL ger en modell en belöningssignal i slutet av en lång sekvens. I en lång kodningssession kan den slutliga belöningen vara för brusig för att visa var modellen gick fel.

Läraren och studenten delar en vända. Bild av författaren.

Cursors metod inför en kort textledtråd på den punkt där modellen tog ett dåligt beslut. Om modellen till exempel anropar ett verktyg som inte finns kan träningsprocessen lägga in en påminnelse med korrekt verktygslista. Versionen med ledtråd fungerar som en "lärare" och den ursprungliga modellen som en "student". En destillationsförlust flyttar sedan studentens beteende mot lärarens endast för den vändan.

Resultatet är mer riktad träning: enskilda misstag kan rättas till utan att betrakta en hel lång utrullning som vagt rätt eller fel. Cursor tillämpade den här metoden på kodningsstil, verktygsanvändning och modellkommunikation under träningen av Composer 2.5.

Syntetisk data i större skala

Composer 2.5 tränades med 25x fler syntetiska uppgifter än Composer 2. Dessa uppgifter är förankrade i verkliga kodbaser, inte leksaksexempel.

En metod som Cursor beskriver är funktionsborttagning. En agent startar med en verklig kodbas och en stor testsvit och tar sedan bort kod och filer samtidigt som resten av projektet förblir funktionellt. Den syntetiska uppgiften är att återimplementera den borttagna funktionen, och testerna ger en verifierbar belöningssignal.

Skalan på den syntetiska träningen medför egna risker. Cursor dokumenterade fall där Composer 2.5 hittade genvägar, inklusive att återhämta borttagen information från en Python-typkontrollcache och dekompilera Java-bytecode för att återskapa ett externt API. Företaget säger att de fångade detta med övervakningsverktyg, men medgav att träning i den här skalan kräver "ökad försiktighet".

Infrastrukturförändringar

På infrastruktursidan använde Cursor Sharded Muon och dual mesh HSDP för fortsatt förträning. Dessa förändringar minskade en del av kostnaden och tiden som är förknippad med träning på stora GPU-kluster.

Composer 2.5 benchmarkresultat: Terminal-Bench, SWE-Bench och CursorBench

Benchmark är användbara, men de visar inte hela bilden. Jag skulle se dem som en utgångspunkt för jämförelse, inte som ett fullständigt utlåtande om hur modellen känns i dagligt arbete.

Cursor utvärderar Composer 2.5 över tre benchmark:

SWE-Bench Multilingual testar om en modell kan lösa riktiga GitHub-ärenden över flera programmeringsspråk. Varje uppgift ger modellen ett repo och en problemformulering och kontrollerar sedan om patchen klarar de tillhörande testerna.

Terminal-Bench 2.0 mäter om en AI-agent kan verka i verkliga terminalarbetsflöden: inspektera filer, köra kommandon, felsöka fel och slutföra uppgifter i flera steg.

CursorBench v3.1 är Cursors privata interna benchmark. Den utvärderar agenter på tvetydiga uppgifter över flera filer från riktiga Cursor-sessioner, inklusive förståelse av kodbas, buggsökning, planering och kodgranskning. Begränsningen är att CursorBench inte kan verifieras eller reproduceras av externa forskare, och poäng bör jämföras inom samma eval-version.

Det finns en viktig brasklapp innan man läser in för mycket i dessa siffror. Benchmarkjämförelser mellan modeller är inte alltid rena. Olika utvärderingsupplägg och ansträngningsinställningar kan flytta poäng, och Cursor noterar att Opus 4.7 och GPT-5.5 använder självrapporterade poäng för offentliga utvärderingar. Se dem som riktgivande jämförelser, inte direkta tester under identiska villkor.

En senare extern benchmark från Artificial Analysis pekar i liknande riktning, även om den använder en annan benchmarkmix. Composer 2.5 fick 62 på Artificial Analysis Coding Agent Index, bakom Claude Opus 4.7 på max-ansträngning (66) och GPT-5.5 på xhigh reasoning (65). 

Kostnadsgapet är det jag skulle fästa vikt vid: Artificial Analysis uppskattade Composer 2.5 till $0,07 per uppgift för Standard och $0,44 för Fast, jämfört med $4,10 för Opus 4.7 max och $4,82 för GPT-5.5 xhigh.

Composer 2.5 vs. Composer 2 vs. Composer 1.5: Så står sig poängen

Composer-familjen har haft tre släpp på kort tid. Composer 1.5 kom i februari 2026, Composer 2 i mars och Composer 2.5 i maj. Varje version ändrade något annorlunda i träningsupplägget.

Composer 2.5 jämfört med Composer 2

Klivet från Composer 2 till 2.5 syns tydligast på Terminal-Bench 2.0, där poängen gick från 61,7% till 69,3%, och på SWE-Bench Multilingual, från 73,7% till 79,8%. Vinsten på CursorBench är mindre och benchmarkversionen ändrades från v3 till v3.1, så jämförelsen är mindre direkt.

Den större skillnaden är träningskedjan. Composer 2 introducerade fortsatt förträning på Kimi K2.5. Composer 2.5 behöll den basen och lade till riktad textfeedback, 25x fler syntetiska uppgifter och infrastrukturförändringar. Standardpriset förblev oförändrat.

Composer 2.5 jämfört med Composer 1.5

Composer 1.5 byggdes genom att skala förstärkningsinlärningen 20x ytterligare på samma förtränade modell som Composer 1. Den introducerade adaptivt tänkande och själv-summering, vilket låter modellen komprimera sitt eget sammanhang när en session blir lång.

Gapet från Composer 1.5 till 2.5 är stort över varje benchmark. Det kom också med ett lägre tokenpris: Composer 1.5 kostade $3,50 per miljon inputtoken och $17,50 per miljon outputtoken, ungefär 7x dyrare än Composer 2.5 Standard.

Vad som ändrats i praktiken

Mönstret är ganska tydligt över versionerna: varje generation ändrade beteendet under långa sessioner och instruktionsföljning, medan Composer 2 och 2.5 sänkte kostnaden för ihållande agentsessioner.

Composer 2.5 vs. Claude Opus 4.7 vs. GPT-5.5: Benchmark, pris och avvägningar

Det här är jämförelsen många läsare bryr sig om först. Composer 2.5 har liknande kodningsbenchmark i vissa områden, ett lägre tokenpris än frontmodellerna nedan och tydliga avvägningar.

Benchmarkjämförelse

GPT-5.5 leder på Terminal-Bench 2.0 med 82,7%, cirka 13 poäng före Composer 2.5. Det gapet spelar roll för arbete som är starkt beroende av terminalanvändning.

Claude Opus 4.7 ligger något före Composer 2.5 på SWE-Bench Multilingual (80,5% mot 79,8%), alltså mindre än en poäng. På CursorBench ligger Composer 2.5 på 63,2% över Opus 4.7 på standardinställningar (61,6%) men under Opus 4.7 på max-ansträngning (64,8%). GPT-5.5 når också 64,3% på xhigh, medan dess standardpoäng är 59,2%.

Dessa modeller gör inte exakt samma jobb. Opus 4.7 och GPT-5.5 är bredare frontmodeller. Composer 2.5 är en kodningsmodell som endast körs i Cursor. Benchmarkresultaten är nära på vissa kodningsuppgifter, men produktgränserna är olika.

Prisjämförelse

Kostnadsskillnaden är den tydligaste skiljelinjen mot frontmodellerna.

Composer 2.5 Standard är prissatt till ungefär en tiondel av Opus 4.7 och GPT-5.5 per token. Fast-varianten ligger också under standardnivåerna hos båda frontmodellerna.

Dessa priser gäller i maj 2026, så kontrollera Cursors modellpriser, Anthropics Opus-priser och OpenAIs API-priser innan du förlitar dig på jämförelsen.

En sak som ofta missas: Priset för Composer 2.5 Fast har fördubblats jämfört med Composer 2 Fast. Standardpriset är oförändrat, men Fast är förvalt, så uppgraderingen kan ändå höja kostnaderna för vissa användare.

Vilken modell ska du välja?

Valet beror på om kostnad, terminalarbete eller djupare planering är viktigast:

• Composer 2.5 passar vardaglig kodning i Cursor, särskilt redigeringar över filer, refaktorering, felsökning och agentsessioner där kostnad spelar roll.
• GPT-5.5 passar uppgifter där terminalprestanda är viktigast.
• Claude Opus 4.7 passar uppgifter som kräver noggrant resonemang, arkitekturplanering eller ett sammanhangsfönster på 1 miljon token.

Det är mönstret jag skulle ta med mig från siffrorna: Composer 2.5 täcker rutinmässigt kodningsarbete, medan frontmodeller fortfarande har en roll för bredare resonemang eller högre terminalpoäng.

Composer 2.5 Standard vs. Fast: Hastighet, pris och när du använder vilken

Cursor levererar Composer 2.5 i två varianter, som med Composer 2. Enligt Cursor delar båda samma underliggande intelligens. Skillnaden är främst hur snabbt modellen svarar och vad den kostar.

Cursors modellväljare med Composer vald. Bild av författaren.

Fast är förvalt och kostar $3,00 per miljon inputtoken och $15,00 per miljon outputtoken. Den är avsedd för interaktiva sessioner där låg latens är viktigt. Standard ligger på $0,50 respektive $2,50 och passar därför bakgrundsjobb eller längre agentloopar där omedelbar feedback är mindre viktig.

Användningen av Composer 2.5 ligger i Cursors "Auto + Composer"-användningspool, separat från API-poolen som används för externa modeller som Claude och GPT. Cursor erbjöd också dubbel användning under den första veckan efter lansering.

Composer 2.5: Begränsningar och förbehåll

Förbehållen gäller åtkomst, benchmark och träningsrisk. De gör inte Composer 2.5 ovanlig, men de påverkar hur stor vikt man bör lägga vid Cursors påståenden.

Endast tillgänglig i Cursor. Som nämnts tidigare har Composer 2.5 inget publikt API. Om ditt arbetsflöde kräver att du anropar en modell från egna skript eller pipelines är Composer 2.5 inget alternativ.

CursorBench är inte oberoende. Som jag tog upp i benchmarkavsnittet är CursorBench v3.1 intern för Cursor. Metodologin är inte helt offentlig och uppgifterna kan inte reproduceras av externa forskare.

Variabilitet i benchmarkupplägg. Poängen för frontmodellerna i Cursors benchmarkdiagram är inte alla uppmätta på samma sätt. Se jämförelserna som riktgivande, inte definitiva.

Belöningshackning under träning. Cursor redovisade fall där modellen hittade smarta genvägar i syntetiska uppgifter i stället för att lösa dem normalt. Detta är en inneboende risk med RL i den här skalan, även när övervakning fångar uppenbara exempel.

Ansträngningskalibrering är overifierad. Cursors påståenden om kommunikationsstil och ansträngningskalibrering backas inte upp av benchmarkdata, som jag tog upp tidigare. Det gör dem svåra att kontrollera utifrån.

När Composer 2.5 är vettigt

Det beror på uppgiften. Jag skulle se Composer 2.5 mindre som ett universellt modellval och mer som en kodningsmodell för den som redan arbetar i Cursor.

Om du tillbringar större delen av dagen med att koda i Cursor och bryr dig om tokenkostnad har Composer 2.5 Standard det lägsta priset i Composer 2.5-serien. Det gäller samma redigeringar, refaktorering, felsökning och långsessioner som nämnts ovan.

Om svarstiden är viktigare är Composer 2.5 Fast standardalternativet.

Om uppgiften kräver bredare resonemang, större sammanhangsfönster eller högre benchmarkpoäng inom ett specifikt område kan Claude Opus 4.7 eller GPT-5.5 passa den uppgiften.

Ett sätt att se det: Composer 2.5 hanterar det rutinmässiga kodningsarbetet jag beskrev ovan, medan en frontmodell kan passa uppgifter som kräver bredare resonemang eller högre terminalpoäng. Det håller jämförelsen jordnära utan att bli en rekommendation för en modell i alla fall.

Avslutande tankar

Det är lätt att läsa Composer 2.5 som en benchmarkhistoria, men jag tycker att den mer användbara poängen är riktningen. Cursor nöjer sig inte med att bara kapsla in frontmodeller i en editor. De bygger en modellserie kring de typer av arbete deras agenter redan gör: redigering över filer, terminalsteg, längre sessioner och återhämtning från misstag.

Som jag nämnde tidigare är avvägningen att Composer 2.5 är smal avsiktligt. Den ersätter inte Claude Opus 4.7 eller GPT-5.5 som generell modell, och den hjälper inte om du behöver ett API utanför Cursor. Men i Cursor är det smalare fokuset poängen. Modellen är billigare att köra än frontalternativen, den är trimmad för kodningsuppgifter och den ligger nära produktlagret där dessa uppgifter sker.

Nästa fråga är hur mycket av detta Cursor vill äga. Företaget säger att de arbetar med SpaceXAI för att träna en större modell från grunden med 10x mer total beräkning och Colossus 2-infrastruktur. Inget lanseringsdatum har angetts, så det finns inte mycket att analysera ännu. Ändå är grunddragen tillräckligt tydliga: Cursor går från att använda modeller väl till att bygga mer av själva modellstacken.