GitHub Copilot, plany, kredyty i tryb agenta

GitHub Copilot, co się zmieniło i ile to kosztuje

Copilot zaczynał jako uzupełnianie kodu w edytorze i przez lata to była cała jego funkcja. Dziś obejmuje rozmowę o kodzie, tryb agenta wykonujący zadania wielokrokowe, przegląd zmian i osobnego agenta pracującego na zgłoszeniach w repozytorium.

Wraz z tym zmieniło się rozliczenie i to najważniejsza rzecz przy planowaniu wydatków. Od czerwca 2026 roku miejsce jednostek żądań zajęły kredyty naliczane według liczby przetworzonych tokenów, więc koszt zależy od tego, jak duże zadania zlecasz, a nie od tego, ile razy kliknąłeś.

Co jest bez limitu, a co kosztuje

To rozróżnienie decyduje o rachunku i warto je zapamiętać, zanim przejdziesz do wyboru planu.

Uzupełnianie kodu w edytorze jest bez limitu na każdym planie płatnym. Podpowiedzi w trakcie pisania nie zużywają kredytów, niezależnie od tego, ile ich przyjmiesz.

Kredyty zużywają natomiast rozmowy z wyborem mocniejszego modelu, tryb agenta i agent pracujący na zgłoszeniach. Tam liczy się objętość: zadanie obejmujące dziesięć plików przetwarza wielokrotnie więcej tokenów niż pytanie o jedną funkcję.

Praktyczny wniosek jest odwrotny do intuicji. Intensywne używanie uzupełniania kodu przez cały dzień nie zbliża Cię do limitu, a trzy duże zadania agentowe potrafią zjeść znaczną część miesięcznej puli. Planowanie kosztu polega więc na liczeniu zadań agentowych, nie godzin pracy.

Plany

Wybór między planami indywidualnymi zależy wyłącznie od tego, ile pracy agentowej wykonujesz.

Warto przy tym zauważyć, że pula kredytów na planach indywidualnych przewyższa cenę abonamentu: przy dziesięciu dolarach dostajesz piętnaście dolarów kredytów, przy trzydziestu dziewięciu siedemdziesiąt, przy stu dwieście. Na planach zespołowych proporcja jest inna, bo pula równa się cenie miejsca co do dolara. Do końca sierpnia 2026 roku dotychczasowi klienci zespołowi mają promocyjnie podniesioną pulę, trzydzieści dolarów na Business i siedemdziesiąt na Enterprise, więc rachunek policzony w te wakacje nie będzie odzwierciedlał kolejnych miesięcy. Jeśli używasz głównie uzupełniania i sporadycznie rozmowy, plan podstawowy wystarcza z zapasem. Jeśli codziennie zlecasz zadania obejmujące wiele plików, wyższy plan wychodzi taniej niż dokupywanie kredytów.

Warto od razu ustawić limit wydatków. Bez niego przekroczenie puli przechodzi w rozliczenie za zużycie, a rachunek widać dopiero na koniec miesiąca. Przy planach zespołowych limit ustawia się na poziomie organizacji, więc jedna osoba zlecająca duże zadania nie wyczerpie budżetu wszystkim.

Tryb agenta

To największa zmiana wobec pierwotnej wersji narzędzia. Zamiast podpowiadać kolejne linie, agent planuje zadanie, zmienia pliki, uruchamia polecenia, czyta ich wynik i poprawia się, dopóki nie skończy.

Trzy nawyki oddzielają użyteczną pracę od sprzątania po niej. Pierwszy to czysty stan repozytorium przed uruchomieniem, żeby zmiany agenta dało się odróżnić od własnych. Drugi to zadania wielkości jednego zatwierdzenia, bo diff obejmujący czterdzieści plików nie zostanie przejrzany. Trzeci to przegląd zmian przed przyjęciem, dokładnie tak samo jak przy cudzym kodzie.

Osobną odmianą jest agent pracujący po stronie repozytorium. Przypisujesz mu zgłoszenie, a on pracuje w tle i otwiera propozycję zmian. Ten układ ma sens przy zadaniach powtarzalnych i dobrze opisanych: aktualizacja zależności, dopisanie testów do istniejącej funkcji, poprawienie literówek w dokumentacji.

Przy zadaniach wymagających decyzji projektowej ten sam układ zawodzi, bo agent podejmie decyzję za Ciebie i dowiesz się o tym z gotowej propozycji zmian. Dlatego opis zgłoszenia decyduje o wyniku bardziej niż wybór modelu.

Instrukcje projektu

Najtańsza rzecz, jaką można zrobić dla jakości podpowiedzi, i jednocześnie najczęściej pomijana. Plik z instrukcjami w repozytorium trafia do kontekstu każdego zapytania.

# Konwencje projektu

- TypeScript w trybie ścisłym, bez typu any
- Komponenty funkcyjne z typowanymi propsami
- Zapytania do API wyłącznie przez `src/api/client.ts`
- Testy obok pliku źródłowego, nazwa `*.test.ts`
- Nie dodajemy komentarzy do generowanego kodu

Dobra instrukcja mówi, czego nie robić, a nie tylko co robić. Model domyślnie sięga po rozwiązania najpopularniejsze, a nie po przyjęte u Ciebie, więc różnica między dwoma zapisami tej samej zasady bywa spora.

Slabo:
- Piszemy testy

Lepiej:
- Testy piszemy do zachowania, nie do implementacji
- Nie mockujemy warstwy bazy, uzywamy testcontainers
- Kazda poprawka bledu zaczyna sie od testu, ktory ten blad odtwarza

Pierwszy zapis nie zmienia niczego, bo model i tak uważa, że pisze testy. Drugi odcina konkretne wybory, których sam by dokonał.

Można też opisać instrukcje osobno dla różnych obszarów repozytorium, żeby reguły frontendu nie trafiały do kontekstu przy pracy nad zapleczem.

.github/copilot-instructions.md          reguly dla calego repozytorium
.github/instructions/frontend.instructions.md
.github/instructions/api.instructions.md

Plik obszarowy zaczyna się od nagłówka wskazującego, których ścieżek dotyczy, i tylko przy nich trafia do kontekstu.

---
applyTo: "src/api/**/*.ts"
---

- Kazdy endpoint zwraca typ Result, nigdy nie rzuca wyjatkiem do warstwy HTTP
- Walidacja wejscia przez zod w pliku schema.ts obok trasy
- Bledy logujemy z requestId, nigdy nie logujemy tresci zadania

Przy dużym repozytorium ten podział zauważalnie poprawia trafność, bo kontekst nie puchnie od zasad, które akurat nie obowiązują.

Wybór modelu

Na planach płatnych możesz wskazać model do rozmowy i do trybu agenta, wybierając między rodzinami różnych dostawców. Dostępność zależy od poziomu planu.

Reguła doboru jest prosta i wynika z kosztu. Model tańszy albo dobierany automatycznie obsłuży pytania o kod, wyjaśnienia i drobne zmiany. Model mocniejszy bierz do zadań obejmujących wiele plików albo wymagających rozumowania o architekturze.

Stałe ustawienie najmocniejszego modelu do wszystkiego jest najczęstszą przyczyną szybkiego wyczerpania puli. Różnica jakości przy prostym pytaniu jest niewielka, a różnica w zużyciu kredytów kilkukrotna.

Warto przetestować kilka modeli na własnym repozytorium, bo różnice zależą od języka programowania i stylu projektu bardziej niż od ogólnych zestawień.

Żeby to porównanie coś znaczyło, warto zapisać wynik w liczbach, a nie we wrażeniach.

zadanie,model,minuty,rundy_poprawek,czy_przeszlo_verify
dodanie pola do zamowienia,tanszy,18,2,tak
dodanie pola do zamowienia,mocniejszy,12,0,tak
migracja endpointow,tanszy,55,6,nie
migracja endpointow,mocniejszy,31,1,tak

Kolumna z liczbą rund poprawek mówi więcej niż czas. Model wymagający sześciu rund zjada uwagę programisty przy każdej z nich, a to jest koszt, którego żadne zestawienie nie pokazuje. Godzina spędzona na takim porównaniu daje odpowiedź, której publiczne wyniki nie zastąpią.

Przegląd zmian i praca zespołowa

Poza edytorem narzędzie działa też w przeglądarce, przy propozycjach zmian. Może wygenerować opis zmiany, zasugerować uwagi i wskazać miejsca warte uwagi recenzenta.

Wartość leży tu w innym miejscu, niż się wydaje. Wygenerowany przegląd nie zastąpi człowieka, bo nie zna kontekstu biznesowego i nie wie, czego zespół się obawia w tym module. Przydaje się natomiast jako pierwsze przejście wyłapujące rzeczy oczywiste: brakującą obsługę błędu, niespójne nazewnictwo, pominięty przypadek brzegowy.

Praktyczny układ wygląda tak: automatyczny przegląd jako sito wstępne, człowiek jako decyzja. Odwrotna kolejność, czyli przyjmowanie zmian na podstawie samego przeglądu automatycznego, przenosi odpowiedzialność na narzędzie, które jej nie udźwignie.

W planach zespołowych dochodzi zarządzanie dostępem i ustawienia obowiązujące całą organizację, w tym wykluczenie wybranych repozytoriów i katalogów z kontekstu. To pierwsza rzecz do skonfigurowania przy wdrożeniu w firmie.

Praca z kontekstem w rozmowie

Jakość odpowiedzi zależy przede wszystkim od tego, co model widzi. W rozmowie kontekst dołączasz wprost, wskazując pliki, zaznaczenie albo wynik polecenia.

Odwołanie do zaznaczonego fragmentu jest najprostsze i wystarcza przy pytaniach o konkretną funkcję. Wskazanie pliku albo katalogu ma sens, gdy sprawa dotyczy struktury. Dołączenie treści błędu z terminala zamienia pytanie ogólne w pytanie o konkretną sytuację.

Warto też wiedzieć, czego model nie widzi domyślnie. Pliki niezapisane, pliki spoza otwartego katalogu i zawartość zależności zwykle nie trafiają do kontekstu, więc pytanie o zachowanie biblioteki zewnętrznej opiera się na wiedzy modelu, a nie na kodzie w Twoim projekcie.

Praktyczna zasada brzmi: im bardziej konkretne pytanie i im węższy kontekst, tym lepsza odpowiedź. Prośba „popraw ten kod" bez wskazania, co jest nie tak, daje przypadkową zmianę. Prośba „ta funkcja gubi przypadek pustej listy, dopisz obsługę i test" daje dokładnie to, o co chodzi.

Wdrożenie w zespole

Narzędzie kupione dla dziesięciu osób bez ustaleń daje dziesięć różnych sposobów pracy. Kilka decyzji podjętych na starcie oszczędza późniejsze porządkowanie.

Pierwsza dotyczy pliku z instrukcjami. Powinien powstać raz, leżeć w repozytorium i podlegać przeglądowi jak każdy inny kod. Instrukcje trzymane w ustawieniach osobistych działają tylko dla jednej osoby i rozjeżdżają się między członkami zespołu.

Druga to wykluczenia. Katalogi z sekretami, konfiguracją produkcyjną i danymi testowymi warto wyłączyć z kontekstu na poziomie organizacji, zanim ktoś zapyta o coś, co ich dotyczy.

Trzecia to zasady przyjmowania zmian od agenta. Propozycja otwarta przez agenta przechodzi przez ten sam przegląd co propozycja od człowieka, a osoba, która ją zleciła, odpowiada za jej treść.

Czwarta to przegląd zużycia po pierwszym miesiącu. Zwykle okazuje się, że dwie osoby zużywają większość puli, a reszta prawie nic, co jest sygnałem do zmiany planów, a nie do podnoszenia limitu wszystkim.

Copilot kontra alternatywy

Największą przewagą tego narzędzia jest miejsce, w którym siedzi. Działa w edytorze, którego już używasz, w przeglądarce przy przeglądzie zmian i w samym repozytorium przy zgłoszeniach. Dla zespołu pracującego na tej platformie to znaczy jeden rachunek i jeden zestaw uprawnień zamiast osobnego narzędzia obok.

Przewagą dedykowanego edytora jest głębsze zrozumienie projektu, bo indeksuje repozytorium i pracuje na większym kontekście. Różnica jest odczuwalna przy pytaniach o architekturę, a niewielka przy uzupełnianiu kodu. Z tego zestawienia wypadł natomiast asystent od AWS. Amazon Q Developer nie przyjmuje już nowych subskrypcji, a wtyczki do IDE razem z płatnymi planami kończą wsparcie 30 kwietnia 2027, więc zespoły, które trzymały się go dla modernizacji Javy i .NET z poziomu edytora, muszą domknąć te transformacje wcześniej albo przejść na Kiro. Wersja w konsoli AWS zostaje bez zmian, więc migracja dotyczy wyłącznie pracy w edytorze.

Te narzędzia nie wykluczają się i część zespołów używa dwóch naraz: tego przy przeglądzie zmian i zgłoszeniach, drugiego przy pracy na kodzie. Koszt takiego układu bywa niższy niż jednego planu na najwyższym poziomie, bo każde narzędzie obsługuje to, w czym jest tańsze.

Warto natomiast pamiętać, że różnice między narzędziami są mniejsze niż różnica między używaniem ich z opisanymi konwencjami projektu a bez. Zanim zmienisz narzędzie, bo podpowiedzi są słabe, sprawdź, czy w repozytorium leży cokolwiek, co je opisuje.

Typowe błędy

Pierwszy to praca bez pliku z instrukcjami. Model podpowiada wtedy rozwiązania popularne zamiast przyjętych w Twoim kodzie i każda podpowiedź wymaga poprawki.

Drugi to stałe używanie najmocniejszego modelu. Pula kredytów kończy się w połowie miesiąca, a różnica jakości przy prostych pytaniach jest niewielka.

Trzeci to brak limitu wydatków. Po przekroczeniu puli rozliczenie przechodzi na zużycie, więc rachunek rośnie po cichu do końca miesiąca.

Czwarty to zbyt duże zadania dla agenta. Propozycja zmian obejmująca czterdzieści plików trafia do repozytorium bez przeglądu, bo nikt jej nie przeczyta w całości.

Piąty to przyjmowanie wygenerowanych testów jako dowodu poprawności. Test napisany przez model do kodu napisanego przez model potwierdza, co kod robi, a nie co powinien robić.

Szósty to zlecanie agentowi zgłoszeń opisanych jednym zdaniem. Wynik odpowiada opisowi, więc zgłoszenie w rodzaju „popraw wydajność" kończy się propozycją zmian, której nie da się przyjąć ani sensownie odrzucić.

FAQ

Ile kosztuje GitHub Copilot?

Plan darmowy daje dwa tysiące uzupełnień miesięcznie i ograniczoną liczbę rozmów. Plan podstawowy kosztuje dziesięć dolarów i zawiera piętnaście dolarów kredytów, wyższe poziomy trzydzieści dziewięć i sto dolarów, z pulą odpowiednio siedemdziesięciu i dwustu dolarów. Plany zespołowe to dziewiętnaście i trzydzieści dziewięć dolarów za osobę.

Czy uzupełnianie kodu zużywa kredyty?

Nie, na planach płatnych jest bez limitu. Kredyty zużywają rozmowy z wyborem mocniejszego modelu, tryb agenta i agent pracujący na zgłoszeniach, a naliczane są według liczby przetworzonych tokenów.

Copilot czy Cursor?

Copilot wybierzesz, gdy chcesz zostać w swoim edytorze i pracujesz w zespole na tej platformie, bo integracja obejmuje też przegląd zmian i zgłoszenia. Cursor wybierzesz, gdy zależy Ci na głębszym kontekście całego repozytorium przy pracy na wielu plikach naraz.

Czy mój kod trafia do trenowania modeli?

Na planach zespołowych i firmowych kod nie jest używany do trenowania. Na planach indywidualnych warto sprawdzić ustawienia, bo część opcji jest domyślnie włączona i można je wyłączyć w konfiguracji konta.

Jak poprawić jakość podpowiedzi?

Dodaj plik z instrukcjami do repozytorium i opisz w nim konwencje projektu, zwłaszcza to, czego nie robicie. To najtańsza możliwa poprawa, działająca przy każdym zapytaniu, i zauważalnie skuteczniejsza niż zmiana modelu na mocniejszy.

Dokumentację znajdziesz na stronie GitHuba, a aktualne progi cenowe na stronie planów.