Najnowszy "nightly build" Projekt Gemini CLI (wersja v0.53.0) wprowadza poprawkę w warstwie komunikacji z modelem, która dotyczy grupowania anulowanych odpowiedzi narzędzi oraz scalania sąsiadujących ról w konwersacji. Zmiana, wprowadzona przez kontrybutora @luisfelipe-alt w "pull requeście" #28407, eliminuje błędy 400 Bad Request, które mogły przerywać sesję w nieoczekiwanych momentach.
Każdy, kto spędził czas z agentem Projekt Gemini CLI w trybie vibe coding, zna ten problem. Uruchamiasz kilka narzędzi — edycja pliku, polecenie shella, szybki test. Część operacji wykonuje się, a inne anulujesz, ponieważ zmieniasz koncepcję. W efekcie klient dostaje błąd od API. Ta poprawka ma to zmienić.
Kluczowe informacje
- Poprawka grupuje anulowane odpowiedzi narzędzi i scala sąsiadujące wiadomości o tej samej roli przed wysłaniem zapytania do API.
- Pull request #28407 autorstwa
@luisfelipe-altjest oznaczony etykietącore,a2a, co wskazuje na zmiany w głównej logice przetwarzania i komunikacji agent-agent. - Wersja v0.53.0 (nie v0.52.0, jak początkowo sądzono) zawiera tę poprawkę w kanale "nightly".
- Praktyczny efekt: mniej błędów żądań po anulowaniu narzędzi i stabilniejsza kontynuacja rozmów z modelem.
Na czym polega problem techniczny
Rozmowy z użyciem narzędzi w Projekt Gemini CLI są reprezentowane jako uporządkowana sekwencja wiadomości z przypisanymi rolami — model, wywołanie narzędzia, odpowiedź narzędzia. Anulowanie operacji może pozostawić fragmenty odpowiedzi, które nie pasują do oczekiwanego przez API formatu. Czasami powstają dwie sąsiadujące wiadomości od użytkownika, a czasami odpowiedź narzędzia ląduje w niewłaściwym miejscu.
W efekcie API Projekt Gemini odrzuca zapytanie z kodem HTTP 400, co może przerwać całą sesję, szczególnie w złożonych, wieloetapowych "workflow".
Mechanizm naprawczy działa w warstwie normalizacji wiadomości. Po pierwsze, anulowane odpowiedzi narzędzi są grupowane — zamiast emitować je jako pofragmentowane wpisy, Projekt Gemini CLI łączy je w spójną całość. Po drugie, sąsiadujące wiadomości z tą samą rolą (np. dwie kolejne od modelu) są scalane. Dopiero tak przygotowana konwersacja trafia do API.
Dlaczego to ma znaczenie dla DevOps i vibe codingu
Wyobraź sobie typową sesję: agent Projekt Gemini CLI wykonuje serię operacji — klonuje repozytorium, modyfikuje konfigurację, uruchamia testy jednostkowe, sprawdza pokrycie kodu. W połowie orientujesz się, że obrałeś złą ścieżkę. Przerywasz. Agent anuluje pending tool calls, ale w tle pozostają fragmenty odpowiedzi.
Bez tej poprawki ryzykujesz, że następne zapytanie do modelu — nawet zupełnie niezwiązane z anulowaną operacją — zostanie odrzucone. Z poprawką warstwa komunikacji jest odporna na takie artefakty.
Co ciekawe, zmiana dotyczy nie tylko głównej ścieżki core, ale też komunikacji a2a (agent-to-agent). W środowiskach, gdzie wiele agentów wymienia się kontekstem, ryzyko zduplikowanych ról rośnie. Ta łatka zabezpiecza oba scenariusze.
Kontynuacja prac nad stabilnością
Linia rozwojowa v0.52.0 już wcześniej otrzymała poprawkę, która zapewnia, że anulowanie zadania przerywa pętlę wykonawczą agent-agent. Teraz v0.53.0 idzie krok dalej — nie tylko przerywa wykonanie, ale też sprząta po anulowaniu.
Warto pamiętać, że "nightly build" Projekt Gemini CLI jest publikowany codziennie z głównej gałęzi o 00:00 UTC. Nie jest przeznaczony do produkcji — może zawierać nieprzetestowane zmiany. Jeśli jednak testujesz najnowsze możliwości agentów Projekt Gemini CLI w "workflow" developerskich, ta wersja jest dla ciebie.
Czego nie ma w tej łatce
Nie ma nowych narzędzi, szybszego modelu ani zmian w interfejsie użytkownika. To czysto inżynieryjna poprawka, która realnie zmniejsza tarcie w codziennej pracy z Projekt Gemini CLI. Nie ma statystyk latency ani wykresów error rate przed/po. To solidna robota pod maską.
Następnym razem, gdy anulujesz agentowi część pracy i wszystko działa dalej bez restartu sesji, będziesz wiedział, komu za to podziękować.