Nowe zasady pracy zespołowej w Cursorze
Cursor zmienia sposób rozliczania planów Teams, ponieważ coraz większe znaczenie ma praca agentowa, a nie samo korzystanie z edytora kodu. Wcześniej Teams za 40 dolarów miesięcznie od użytkownika był często postrzegany głównie jako plan organizacyjny z administracją, billingiem i funkcjami firmowymi. Dla pojedynczego developera bardziej opłacalnie mogły wyglądać plany indywidualne, takie jak Pro, Pro+ albo Ultra. Od czerwca 2026 r. taka ocena wymaga korekty, ponieważ w Teams pojawia się większy usage, osobna pula dla Auto i Composer oraz nowy Premium seat. Zmiana nie sprowadza się więc do kosmetyki cennika, lecz do próby dopasowania oferty do realnych kosztów długich sesji agentowych.
Osobne pule dla Auto i modeli zewnętrznych
Najważniejszą zmianą jest rozdzielenie usage na dwie osobne kategorie: Composer and Auto oraz Third-Party API. Oznacza to, że praca na modelach first-party Cursora i w trybie Auto nie musi już bezpośrednio konkurować z użyciem modeli zewnętrznych, takich jak Claude, GPT czy Gemini wybierane ręcznie. Dla zespołów ma to duże znaczenie, ponieważ dotychczas intensywna praca agentowa mogła szybko wyczerpywać wspólną pulę. Teraz łatwiej będzie ustalić, czy limity zużywane są przez codzienne zadania w Auto i Composerze, czy przez kosztowniejsze modele third-party. Standard Teams nadal kosztuje 40 dolarów miesięcznie przy rozliczeniu miesięcznym, ale otrzymuje wyraźnie większy usage bez zmiany ceny.
Premium seat dla najbardziej aktywnych użytkowników
Nowy Premium seat nie jest planem dla każdego użytkownika zespołu, lecz dla osób, które przez dużą część dnia faktycznie pracują z agentami. Chodzi o developerów prowadzących długie sesje Composerem, refaktoryzujących większe fragmenty aplikacji, generujących testy, analizujących wiele plików i regularnie wykorzystujących duży kontekst. Premium ma dawać pięć razy większy included usage niż Standard przy trzykrotnie wyższej cenie. Taki model pozwala nie podnosić kosztów wszystkim, tylko przypisać droższe miejsca osobom, które realnie generują największe zużycie. W firmie bardziej sensowne staje się więc różnicowanie seatów według faktycznej intensywności pracy z AI.
Agentowe programowanie wymaga innego billingowania
Cursor coraz wyraźniej przesuwa się z roli edytora z czatem do środowiska pracy agentowej. W nowych funkcjach widać kierunek, w którym agent ma działać dłużej, analizować repozytorium, poprawiać kod, wykonywać testy i iterować nad rezultatem. Takie podejście zużywa więcej zasobów niż pojedyncze pytania do chatu, dlatego klasyczne limity requestów coraz gorzej opisują realny koszt pracy. Osobna pula dla Auto i Composer jest ważna właśnie dlatego, że odpowiada na zmianę sposobu korzystania z Cursora. W praktyce oznacza to, że codzienne zadania mogą być kierowane do warstwy agentowej bez natychmiastowego konkurowania z drogimi modelami zewnętrznymi.
Koniec prostego porównania z planem Pro
Argument, że Teams to jedynie droższy Pro z administracją, staje się znacznie słabszy. Wcześniej dopłata do Teams musiała być uzasadniona głównie funkcjami zespołowymi, takimi jak SSO, centralny billing, polityki prywatności, dashboard i kontrola organizacyjna. Po zmianach Teams Standard może bronić się również usage’owo, ponieważ otrzymuje dodatkową pulę dla Auto i Composer. Nie oznacza to jednak, że Standard Teams automatycznie zastępuje Pro+, Ultra albo inne najwyższe plany indywidualne. Bardziej trafne jest stwierdzenie, że Teams staje się planem zespołowym lepiej dopasowanym do pracy agentowej, a nie tylko administracyjną wersją konta indywidualnego.
Większa widoczność kosztów w zespole
Lepszy dashboard może mieć dla firm większe znaczenie niż sama zmiana limitów. Cursor zapowiada dokładniejsze raportowanie zużycia osobno dla Auto + Composer oraz modeli third-party, a także rekomendacje seatów i alerty kosztowe przez Slacka lub e-mail. Dzięki temu administrator nie musi opierać się wyłącznie na domysłach, kto faktycznie zużywa najwięcej zasobów. W pracy z AI jedna rozmowa może oznaczać prostą poprawkę albo wieloetapową analizę dużego repozytorium z testami i ponownymi przebiegami. Rozdzielenie widoczności kosztów pozwala ustalić reguły: kiedy używać Auto, kiedy sięgać po modele zewnętrzne i komu rzeczywiście przyznać Premium seat.
Rozsądna strategia używania modeli
Najbardziej praktyczne podejście zakłada traktowanie Auto i Composer jako domyślnej warstwy codziennej pracy, a modeli zewnętrznych jako narzędzi do zadań specjalnych. Composer 2.5 może pełnić rolę podstawowego modelu Cursorowego do pracy agentowej, ponieważ właśnie wokół Composer i Auto budowana jest osobna pula usage. Sonnet 4.6 może pozostać stabilnym wyborem do dokładnego rozumienia kodu i trudniejszych rozmów technicznych. Codex 5.3 sprawdza się przy zadaniach stricte programistycznych, a Gemini 3 Flash nadaje się do prostszych i szybszych operacji. Najcięższe modele, takie jak Opus albo największe warianty GPT, powinny być używane świadomie, ręcznie i tylko wtedy, gdy zadanie rzeczywiście wymaga bardzo mocnego reasoning.
Znaczenie zmian dla firmowego budżetu
Dla większości developerów Teams Standard powinien stać się wygodniejszą bazą pracy, zwłaszcza jeżeli główne zadania będą wykonywane przez Auto i Composer. Premium seat nabiera sensu dopiero wtedy, gdy dane z dashboardu pokażą regularne dochodzenie do limitów. Nie ma powodu kupować droższego miejsca każdemu użytkownikowi tylko dlatego, że pracuje w zespole programistycznym. Najlepszy model polega na zostawieniu większości osób w Standardzie i przydzielaniu Premium tylko tym, którzy realnie prowadzą długie, agentowe sesje. W takim układzie wzrost kosztów może być lepiej kontrolowany, a dodatkowy usage trafia tam, gdzie rzeczywiście tworzy wartość.
