Composer 2.5 w Cursorze
Composer 2.5 został udostępniony w Cursorze jako nowsza wersja modelu przeznaczonego do pracy z kodem i zadaniami agentowymi. Według opisu producenta model ma lepiej obsługiwać dłuższe procesy, dokładniej realizować złożone instrukcje oraz trafniej dobierać poziom wysiłku do konkretnego zadania. Nie oznacza to jednak, że powinien zostać automatycznie dodany do firmowego trybu Auto bez wcześniejszej weryfikacji. W środowisku z ograniczonym budżetem najważniejsze znaczenie ma nie sama deklarowana jakość modelu, ale relacja między skutecznością, szybkością i realnym kosztem użycia.
To samo źródło, mocniejszy trening
Nowy Composer bazuje na tym samym otwartym checkpoincie co poprzednia wersja, czyli Moonshot Kimi K2.5. Różnica ma wynikać przede wszystkim z dodatkowego treningu zastosowanego przez Cursor. Wskazywane są trudniejsze środowiska RL, nowe metody uczenia oraz znacznie większa liczba syntetycznych zadań treningowych. W praktyce może to oznaczać lepsze prowadzenie wieloetapowej pracy programistycznej, stabilniejsze wykonywanie poleceń i mniejszą liczbę przypadków, w których model gubi kontekst lub niepotrzebnie zmienia zakres zadania.
Koszt jako główne ograniczenie
Największym problemem nie jest sama dostępność Composer 2.5, lecz różnica między wariantem Standard i Fast. Composer 2.5 Standard kosztuje $0.50 za 1M tokenów wejściowych oraz $2.50 za 1M tokenów wyjściowych, dlatego wygląda rozsądnie przy firmowych limitach. Composer 2.5 Fast ma tę samą deklarowaną inteligencję, ale kosztuje $3 za 1M tokenów wejściowych oraz $15 za 1M tokenów wyjściowych. Oznacza to sześciokrotnie wyższy koszt względem wariantu standardowego, co przy codziennym użyciu może bardzo szybko przełożyć się na zużycie budżetu.
Ryzyko dla firmowego Auto
Włączenie Composer 2.5 do Auto ma sens tylko wtedy, gdy można kontrolować używany wariant modelu. Jeśli Cursor będzie domyślnie wybierał wersję Fast, firmowy limit $20 + Free Usage może zostać zużyty znacznie szybciej niż przy tańszych modelach. Promocyjne „double usage” w pierwszym tygodniu nie powinno być traktowane jako normalny model kosztowy, ponieważ jest to czasowa zachęta startowa. Z tego powodu najrozsądniejsze podejście zakłada testy na realnych zadaniach kodowych, porównanie zużycia oraz dopiero późniejsze podjęcie decyzji o stałym dodaniu modelu do domyślnego zestawu.
