Tag: Agenci AI

  • Google Antigravity 2.3.1 naprawia krytyczny błąd startowy. Drobna łatka, duże znaczenie

    Google Antigravity 2.3.1 naprawia krytyczny błąd startowy. Drobna łatka, duże znaczenie

    Google wypuściło 16 lipca 2026 roku wersję 2.3.1 swojej platformy Google Antigravity. Ta aktualizacja koncentruje się na jednym problemie – aplikacja mogła nie uruchomić się z powodu błędu w pliku konfiguracyjnym. Choć może to wydawać się technicznym szczegółem, dla deweloperów korzystających z agentów AI, to różnica między efektywną pracą a frustracją.

    Kluczowe fakty

    • Data wydania: 16 lipca 2026 roku, wersja 2.3.1
    • Główna poprawka: aplikacja nie ładuje się, gdy plik konfiguracyjny jest pusty lub zawiera niepoprawny JSON
    • Zalecane działanie: aktualizacja do wersji 2.3.1 lub nowszej (nowe wersje są wdrażane stopniowo i mogą docierać do użytkowników przez kilka dni)

    Skąd ten problem i dlaczego boli

    Parsowanie konfiguracji to jedna z pierwszych czynności, które aplikacja wykonuje po uruchomieniu. Jeśli plik JSON jest pusty, uszkodzony lub zawiera błąd składniowy, kod inicjalizacyjny może zakończyć działanie, zanim interfejs użytkownika zdąży się załadować. Użytkownik może zobaczyć jedynie komunikaty w logach, jeśli w ogóle.

    W przypadku platformy takiej jak Google Antigravity, która jest określana jako "agentic development platform", stawka jest wyższa niż w przypadku zwykłego edytora. Deweloperzy korzystają z sesji agentów, przestrzeni roboczych, kontroli przeglądarki i zautomatyzowanych przepływów kodowania. Gdy aplikacja nie uruchamia się, tracą dostęp do całego środowiska pracy. Problem z konfiguracją staje się poważną przeszkodą.

    Kogo to dotyczy najbardziej

    Poprawka jest szczególnie istotna dla kilku grup użytkowników. Deweloperzy używający skryptów do automatyzacji konfiguracji środowiska, gdzie pliki konfiguracyjne są generowane programowo, mogą nieświadomie tworzyć puste lub niekompletne JSON-y. Podobnie ci, którzy synchronizują pliki konfiguracyjne między maszynami za pomocą dotfiles lub narzędzi takich jak rsync. Przerwana synchronizacja może pozostawić plik w stanie pośrednim.

    Trzecia grupa to osoby pracujące w środowiskach kontenerowych, gdzie obrazy są budowane warstwowo, a plik konfiguracyjny może zostać nadpisany przez nieprzemyślany COPY w Dockerfile. W każdym z tych scenariuszy wersja 2.3.1 ma na celu zapobieżenie awariom startowym. Warto jednak pamiętać, że naprawa dotyczy konkretnego błędu i nie eliminuje wszystkich możliwych przyczyn, dla których aplikacja mogłaby się nie uruchomić.

    Co dokładnie zmieniono

    Co dokładnie zmieniono

    Changelog Google Antigravity dla wersji 2.3.1 jest krótki. Główny wpis dotyczy poprawki stabilności startowej związanej z pustym lub źle sformatowanym plikiem konfiguracyjnym. Choć zakres zmiany jest niewielki, to jest to łatka dotycząca niezawodności, a nie nowa funkcjonalność. Tego typu poprawki rzadko są na czołowych stronach, ale w codziennej praktyce mogą zaoszczędzić godziny debugowania.

    Co robić, gdy problem nie znika

    Co robić, gdy problem nie znika

    Po aktualizacji do 2.3.1 większość problemów powinna zostać rozwiązana. Jeśli jednak aplikacja nadal nie działa, warto sprawdzić kilka rzeczy. Plik konfiguracyjny musi być poprawnym JSON-em i nie może być pusty. Przed edycją warto zrobić jego kopię zapasową.

    Należy również unikać sytuacji, w których wiele procesów lub narzędzi synchronizacyjnych próbuje jednocześnie zapisywać do tego samego pliku. Równoległy zapis może prowadzić do uszkodzenia danych. W kwestii aktualizacji, zgodnie z informacjami producenta, nowe wersje trafiają do użytkowników stopniowo.

    Szersza lekcja dla narzędzi AI

    Przypadek Google Antigravity 2.3.1 ilustruje uniwersalne ryzyko. W narzędziach opartych na sztucznej inteligencji, gdzie użytkownicy często edytują konfigurację ręcznie, uszkodzony plik może zablokować cały produkt. To ryzyko jest znane z wielu systemów – od serwerów po aplikacje desktopowe – ale w kontekście platform agentowych nabiera nowego znaczenia. Deweloper traci nie tylko edytor, ale także cały zestaw agentów i zautomatyzowanych przepływów pracy.

    Dlatego ta drobna zmiana zasługuje na uwagę. Nie chodzi o nowe funkcje czy modele AI. Chodzi o to, aby narzędzie po prostu działało, co ma kluczowe znaczenie w codziennej pracy.

    Źródła

  • OpenCode ogranicza zagnieżdżanie subagentów i usprawnia pracę na pulpicie

    OpenCode ogranicza zagnieżdżanie subagentów i usprawnia pracę na pulpicie

    Najnowsza aktualizacja narzędzia OpenCode wprowadza domyślne ograniczenie głębokości delegowania zadań dla subagentów oraz szereg poprawek stabilności w wersji desktopowej. Zmiany, wprowadzone w wydaniach 1.18.2 i 1.18.3, mają na celu zapobieganie niekontrolowanemu mnożeniu się sesji agentów i ułatwienie nawigacji po projektach.

    Co nowego w skrócie

    • Limit zagnieżdżania – domyślnie subagent nie może tworzyć kolejnych subagentów; wartość subagent_depth wynosi teraz 1
    • Skrót do zamykania pickera – strzałka w górę pozwala szybko zamknąć okno wyboru subagenta, gdy zaznaczona jest pierwsza pozycja
    • Poprawione przewijanie – strona główna w aplikacji desktopowej działa teraz płynniej
    • Lepszy start WSL – desktop czeka teraz na gotowość serwera WSL, zanim zgłosi aplikację jako dostępną
    • Wyszukiwanie sesji w palecie poleceń obejmuje teraz również istniejące sesje, co przyspiesza przełączanie między konwersacjami

    Dlaczego limit zagnieżdżania ma znaczenie

    Praca z agentami AI przy złożonych projektach programistycznych często wymaga delegowania zadań pobocznych, takich jak przeszukiwanie repozytoriów, testowanie, generowanie dokumentacji czy przegląd kodu. Problem pojawia się, gdy subagent zaczyna tworzyć własne subagenty. Rekurencyjna delegacja może prowadzić do nadmiernej aktywności, obciążenia zasobów i trudności w śledzeniu postępów w drzewie zadań.

    OpenCode wprowadza konfigurowalne ograniczenie głębokości. Przy domyślnej wartości subagent_depth: 1, agent główny może delegować zadanie do subagenta, ale ten nie może tworzyć kolejnych poziomów. Ustawienie wartości na 2 pozwala na jeszcze jeden poziom zagnieżdżenia. Aby całkowicie zablokować możliwość tworzenia subagentów, wystarczy wpisać 0.

    To zabezpieczenie wpisuje się w szerszy trend, w którym narzędzia do kodowania wspomaganego AI stają się środowiskami do zarządzania wieloetapowymi procesami. Jasne granice delegowania ułatwiają odróżnienie głównych zadań od prac pomocniczych.

    Drobne zmiany, które robią różnicę

    Wersja 1.18.3 wprowadza także kilka usprawnień interfejsu. Skrót ze strzałką w górę do zamykania pickera subagentów, choć wydaje się drobnym szczegółem, oszczędza czas i frustrację podczas intensywnej pracy z agentami. Poprawione przewijanie strony głównej również znacząco poprawia komfort użytkowania.

    Rozszerzone wyszukiwanie sesji w palecie poleceń umożliwia użytkownikom zarządzającym wieloma równoległymi konwersacjami agentów szybsze odnalezienie właściwego wątku projektu. Dodatkowo wprowadzono poprawki związane z przyklejonymi nagłówkami sesji oraz widocznością selektora niestandardowych agentów.

    Stabilność WSL doceniona przez deweloperów

    Dla osób pracujących na Windowsie z Linuksem w tle zmiana w obsłudze WSL jest szczególnie istotna. Wcześniej interfejs desktopowy OpenCode mógł zgłaszać gotowość, zanim serwer WSL zakończył inicjalizację, co prowadziło do błędów podczas prób połączenia. To mogło zakłócać pracę nad projektami opartymi na kontenerach czy menedżerach pakietów linuksowych.

    Aktualizacja sprawia, że desktop czeka na pełną gotowość serwera WSL, zanim poinformuje użytkownika o dostępności narzędzia. W połączeniu z wymogiem uwierzytelniania przez OPENCODE_SERVER_PASSWORD, co jest wymagane przy nasłuchiwaniu na zewnętrznym adresie, zapewnia to solidniejsze podstawy do codziennej pracy.

    Mniej rewolucji, więcej kontroli

    Ta aktualizacja OpenCode nie wprowadza nowego modelu językowego ani przełomowych funkcji. Twórcy skupili się na przewidywalności zachowania agentów, szybszej nawigacji i mniejszej liczbie awarii. Domyślny limit zagnieżdżenia to najważniejsza zmiana dla każdego, kto deleguje złożone zadania. Użytkownicy spędzający długie godziny w narzędziu docenią poprawki pulpitu i WSL. To solidny zestaw usprawnień operacyjnych, które poprawiają codzienną pracę.

    Źródła

  • Factory App zyskuje precyzyjne sterowanie umiejętnościami i większą stabilność agentów

    Factory App zyskuje precyzyjne sterowanie umiejętnościami i większą stabilność agentów

    Wydana 15 lipca 2026 roku wersja v0.173.0 aplikacji Factory App wprowadza szczegółową kontrolę nad umiejętnościami agentów AI oraz kilka istotnych poprawek niezawodności. To pierwsza aktualizacja, która pozwala programistom wyłączać pojedyncze umiejętności zamiast traktować je jako całościowy zestaw.

    Co nowego w skrócie

    • Indywidualne wyłączanie skilli — użytkownicy mogą dezaktywować konkretne umiejętności bez utraty dostępu do pozostałych
    • Zapobieganie pętlom narzędziowym — agent przerywa działanie, gdy wykryje powtarzające się identyczne wywołanie narzędzia
    • Hooki wykonywane dokładnie raz — eliminacja ryzyka zdublowanych efektów ubocznych w zautomatyzowanych przepływach pracy
    • Poprawki interfejsu Mission Control — odświeżanie czatu po zamknięciu panelu działa teraz poprawnie

    Precyzyjna kontrola zamiast wszystko-albo-nic

    Dotychczasowe podejście do skilli w Factory App przypominało włącznik główny — albo agent miał dostęp do wszystkich umiejętności, albo do żadnej. Aktualizacja v0.173.0 zmienia tę logikę na znacznie bardziej szczegółową. Deweloper może teraz wyłączyć jeden konkretny skill, pozostawiając pozostałe aktywne. To przydatne, gdy agent ma tendencję do nadużywania jakiejś funkcji, ale wciąż potrzebuje innych narzędzi do wykonania zadania.

    Dodatkowo, aktualizacja pokazuje, jak ustawienia rozwiązują się w różnych zakresach konfiguracyjnych. Jeśli skill jest zdefiniowany jednocześnie na poziomie globalnym, projektowym i instalacyjnym, interfejs wizualizuje, która konfiguracja ma pierwszeństwo. Użytkownicy nie muszą już ręcznie przeszukiwać plików konfiguracyjnych w poszukiwaniu źródła problemu.

    Agent bez pętli, hooki bez niespodzianek

    Jednym z kosztownych problemów w narzędziach AI są pętle narzędziowe. Agent wywołuje to samo narzędzie z tymi samymi argumentami, nie robiąc postępu, co prowadzi do marnowania czasu i zasobów. Wersja v0.173.0 wprowadza mechanizm, który wykrywa takie powtarzające się wywołania i zatrzymuje agenta. Release notes nie podają konkretnych liczb — nie wiemy, o ile spadła częstotliwość pętli ani ile tokenów oszczędza to użytkownikom. Niemniej jednak, wprowadzenie tego zabezpieczenia to krok w stronę bardziej przewidywalnych sesji deweloperskich.

    Hooki również zostały poprawione — wykonują się teraz dokładnie raz na zdarzenie. W kontekście DevOps i hostingu ma to znaczenie, ponieważ hook może uruchamiać komendy, wysyłać powiadomienia czy wyzwalać deploymenty. Przypadkowe zdublowanie takiej akcji oznacza zbędny build albo podwójną notyfikację. Dokładne wykonanie eliminuje ten problem.

    Drobne, ale dokuczliwe usterki

    Aktualizacja rozwiązuje także kilka drobnych problemów. Mission Control po zamknięciu nie zostawia już czatu w niespójnym stanie wizualnym — interfejs odświeża się poprawnie, więc użytkownicy nie muszą restartować aplikacji. Przycisk aktualizacji na pasku bocznym ma teraz poprawione wyrównanie. To mała zmiana, ale istotna.

    Pluginy ładują się teraz poprawnie niezależnie od zakresu instalacji — globalnego, projektowego czy innego. To rozwiązuje sytuację, w której wtyczka zainstalowana w jednym miejscu była widoczna, a identyczna w innym — już nie.

    Równoległe zapisy ustawień również przestały się gryźć. Gdy kilka aktualizacji konfiguracji następuje jednocześnie, nowsze zmiany nie są już nadpisywane przez stare, buforowane dane. Dla zespołów pracujących równolegle nad konfiguracją to oszczędność frustracji.

    Co dalej z Factory App

    Wydanie v0.173.0 dotyczy zarówno CLI, jak i aplikacji desktopowej. Kontrola skilli i mechanizm zatrzymywania pętli to zmiany w CLI, podczas gdy poprawki Mission Control i paska bocznego dotyczą aplikacji. Release notes nie podają danych o adopcji ani metrykach wydajności, więc trudno oszacować konkretny wpływ na produktywność programistów. Jednak kierunek jest jasny — Factory App zmierza w stronę narzędzia, które daje więcej kontroli przy mniejszej liczbie niespodzianek.

    Dla zespołów budujących zautomatyzowane przepływy kodowania czy deploymentu oznacza to mniej ręcznego nadzoru nad agentem i bardziej przewidywalne zachowanie hooków. Takie zmiany są oczekiwane od narzędzi deweloperskich w 2026 roku.

    Źródła

  • Factory wzmacnia kontrolę nad umiejętnościami agentów w wersji v0.173.0

    Factory wzmacnia kontrolę nad umiejętnościami agentów w wersji v0.173.0

    Nowa aktualizacja platformy Factory wprowadza szczegółowe sterowanie umiejętnościami oraz poprawia niezawodność agentów. Wersja v0.173.0, opublikowana 15 lipca 2026 roku, koncentruje się na problemach, które często irytują programistów, takich jak zapętlone wywołania narzędzi i zdublowane efekty uboczne.

    Co nowego w skrócie

    • Szczegółowe sterowanie umiejętnościami – użytkownicy mogą wyłączać pojedyncze skille zamiast zarządzać nimi zbiorczo
    • Widoczność zakresów konfiguracji – aplikacja pokazuje, z którego poziomu pochodzi aktywne ustawienie (projekt, użytkownik, organizacja)
    • Zatrzymywanie zapętlonych wywołań – agent przerywa działanie, gdy powtarza identyczne żądanie narzędzia
    • Pojedyncze wykonanie hooków – każdy hook uruchamia się dokładnie raz na zdarzenie, eliminując duplikację walidacji czy formatowania
    • Poprawki interfejsu – naprawiono odświeżanie czatu po zamknięciu Mission Control i wyrównanie przycisku w pasku bocznym

    Koniec z grupowym sterowaniem umiejętnościami

    Zarządzanie umiejętnościami do tej pory przypominało jazdę bez sprzęgła – wszystko albo nic. Teraz Factory pozwala selektywnie dezaktywować konkretne umiejętności. Jeśli projekt nie potrzebuje określonego frameworka czy workflow testowego, można go po prostu wyłączyć. Bez obejść i kompromisów.

    Wprowadzono również wizualizację rozstrzygania konfliktów między zakresami. Ustawienia mogą nachodzić na siebie z poziomu projektu, użytkownika i organizacji. Użytkownicy teraz widzą dokładnie, która wartość wygrywa i dlaczego, co oszczędza czas zespołom dzielącym wspólne umiejętności między repozytoriami.

    Agent, który wie, kiedy przestać

    Osoby, które spędziły wieczór na debugowaniu sesji vibe codingu, znają ten scenariusz: agent w kółko wysyła to samo żądanie, zamiast posunąć się naprzód lub poprosić o pomoc. W tej aktualizacji wprowadzono mechanizm, który kończy turę, gdy agent powtarza identyczne wywołanie narzędzia.

    Nie ma spektakularnych statystyk poprawy – release notes nie podają częstotliwości występowania pętli przed i po. Jednak fakt, że agent przestaje kręcić się w miejscu, ma znaczenie w długich, autonomicznych sesjach programistycznych.

    Hooki bez ech

    Duplikacja efektów ubocznych to problem w automatyzacji. Hook uruchomiony dwukrotnie może sformatować kod dwa razy, zapisać zdublowany wpis w logach lub uruchomić skanowanie sekretów w nieskończoność. Teraz każdy hook wykonuje się dokładnie raz.

    Dla DevOps to szczególnie istotne – formatowanie przed commitem, sprawdzanie polityk bezpieczeństwa czy przygotowanie wdrożenia powinny działać na zasadzie „jeden strzał, jeden efekt”.

    Drobiazgi, które drażnią

    Aktualizacja rozwiązuje także kilka irytujących defektów interfejsu. Czat poprawnie odświeża się po zamknięciu Mission Control, a przycisk aktualizacji w pasku bocznym wreszcie znajduje się tam, gdzie powinien. Drobne poprawki mają znaczenie, szczególnie przy ośmiu godzinach dziennie przed monitorem.

    Dodatkowo poprawiono ładowanie wtyczek – działają teraz we wszystkich zakresach instalacji, a równoległe zapisy ustawień przestały się wzajemnie nadpisywać nieaktualnymi danymi z cache.

    Czego nie wiemy

    Release notes nie ujawniają wszystkich szczegółów. Nie dowiemy się, ilu użytkowników dotknęły poprawione błędy ani o ile wzrosła skuteczność agentów. Brakuje również informacji o zmianach wydajnościowych, liczbie testowanych pluginów czy potencjalnych incydentach bezpieczeństwa.

    Można traktować tę aktualizację jako solidną paczkę poprawek i funkcji – nie jako raport z laboratorium. To konkretne i użyteczne zmiany, które nie są obciążone marketingowym szumem.

    Źródła

  • Qwen-Code v0.19.11 z przebudowaną powłoką webową i pętlą walidacji recenzji kodu

    Qwen-Code v0.19.11 z przebudowaną powłoką webową i pętlą walidacji recenzji kodu

    Zespół Qwen-Code wypuścił wersję v0.19.11, kończąc intensywny tydzień rozwojowy, w którym zrealizowano ponad 160 scalonych pull requestów. Aktualizacja koncentruje się na trzech głównych obszarach: nowej powłoce webowej, ulepszonym interfejsie CLI oraz bardziej rygorystycznym, wieloetapowym procesie automatycznej recenzji kodu.

    Kluczowe zmiany w skrócie

    • Powłoka webowa zyskała blokadę ścieżki workspace, panel przeglądu artefaktów oraz interaktywne sterowanie diagramami Mermaid.
    • Polecenie /learn umożliwia zapisanie wiedzy z katalogu, URL-a lub rozmowy jako plik SKILL.md do późniejszego wykorzystania.
    • System recenzji rozszerza weryfikację zgłoszeń przed publikacją oraz wprowadza audyt wsteczny, który identyfikuje pominięte problemy.
    • Wydajność recenzji poprawiono przez ograniczenie buildów i testów tylko do zmienionych workspace’ów oraz skompresowane prompty.
    • Wielo-workspace’owe sesje z kolorowymi wskaźnikami i heartbeatami shellowymi zwiększają bezpieczeństwo długotrwałej pracy.

    Powłoka webowa jako centrum zarządzania pracą

    Przebudowa Web Shella to nie tylko kosmetyka. Interfejs zyskał nową bibliotekę komponentów (shadcn) i został wzbogacony o funkcje, które wcześniej wymagały przełączania się między terminalem a konfiguracją. Kluczową nowością jest blokada ścieżki workspace, co eliminuje ryzyko przypadkowej zmiany kontekstu katalogu roboczego podczas sesji. Dla zespołów pracujących nad wieloma projektami jednocześnie oznacza to koniec zgadywania, w którym repozytorium aktualnie wykonywane są polecenia.

    Wprowadzono również dedykowany panel zarządzania rozszerzeniami, który wcześniej kontrolowano głównie przez pliki konfiguracyjne lub CLI – teraz wystarczy kilka kliknięć w interfejsie. Pojawił się także panel przeglądu artefaktów, który organizuje wygenerowane pliki i wyniki pracy agenta.

    Dla wizualizacji architektury i przepływów pracy Qwen-Code dodał możliwość interaktywnego sterowania diagramami Mermaid: można je teraz przybliżać, przesuwać i przeciągać. Wsparcie dla wielu workspace’ów z podziałem ekranu i kolorowymi wskaźnikami kontekstu sprawia, że powłoka przestaje być jedynie terminalem w przeglądarce – staje się centrum zarządzania całym środowiskiem deweloperskim. Dodatkowo, przebudowa objęła maksymalizowanie paneli split-pane oraz wyświetlanie sesji oczekujących na działanie użytkownika.

    CLI, które pamięta i uczy się projektu

    Nowe polecenie /learn to jeden z ciekawszych dodatków tej wersji. Użytkownik wskazuje katalog, URL, treść rozmowy lub własny tekst, a Qwen-Code przetwarza ten materiał w plik SKILL.md. To więcej niż notatka – zapisana wiedza staje się częścią kontekstu i może być przywoływana w kolejnych sesjach.

    CLI zyskało także polecenie /update, które umożliwia aktualizację jednym kliknięciem, poprawione tryby zatwierdzania oraz lepsze zarządzanie sesjami, aby nie mieszać kontekstu między projektami. W tle działa Voice Bridge – mechanizm, który integruje audio z workflow Agent Communication Protocol: modele tekstowe otrzymują transkrypcję, a natywnie obsługujące dźwięk – oryginalne wejście audio.

    Recenzja kodu z pętlą weryfikacji

    To najważniejsza zmiana procesowa w tym wydaniu. Automatyczna recenzja kodu w Qwen-Code przestała być prostym „znajdź i zgłoś”. Teraz działa w pięciu krokach, z czego dwa zostały dodane lub rozszerzone.

    Po wykryciu problemów system uruchamia krok czwarty – weryfikator, który sprawdza każde zgłoszenie pod kątem faktycznej poprawności. Dopiero zwalidowane uwagi trafiają dalej. Krok piąty to audyt wsteczny, który szuka problemów pominiętych w pierwszym przeglądzie. To pełny, otwarty ponowny przegląd diffu, który może przebiegać w wielu rundach – od 2 do 10, w zależności od topologii i ustawień.

    Recenzje z kategorii „sugestie” trafiają teraz bezpośrednio jako komentarze inline w pull requeście – nie trzeba ręcznie kopiować rekomendacji z outputu. System zyskał także konfigurowalny poziom wysiłku recenzji, testy poprawności proceduralnej oraz mapowanie linii diffa do konkretnych recenzentów. Timeout recenzji podniesiono do 180 minut z możliwością przedłużenia do 240, co ma zapobiec przerywaniu analizy dużych pull requestów.

    Co istotne, Agent 7, odpowiedzialny za build i testy, ogranicza teraz swoje działanie wyłącznie do workspace’ów dotkniętych zmianą. Dla monorepozytoriów to znacząca różnica – zamiast przebudowywać całe repozytorium, Qwen-Code sprawdza tylko to, co faktycznie się zmieniło. Warto również wspomnieć o automatycznym fallbacku PDF-to-image, który rozszerza możliwości przetwarzania dokumentów.

    Dlaczego to ma znaczenie

    Wersja v0.19.11 scala wcześniej rozproszone elementy workflow: Web Shell zarządza środowiskiem, CLI tworzy reusable wiedzę projektową, a system recenzji weryfikuje przed publikacją i audytuje po fakcie. Dla zespołów web developerskich i devopsowych oznacza to mniej niespodzianek – agent nie wykona polecenia w złym katalogu, recenzja nie opublikuje fałszywego alertu, a build nie przeliczy połowy repo bez potrzeby.

    To wydanie koncentruje się na tym, aby Qwen-Code stał się bezpieczniejszym i bardziej praktycznym narzędziem do długotrwałej, wieloprojektowej pracy z AI.

    Źródła

  • Kimi Code CLI 1.49.0 wprowadza inteligentne zarządzanie oknem kontekstowym

    Kimi Code CLI 1.49.0 wprowadza inteligentne zarządzanie oknem kontekstowym

    16 lipca 2026 roku wydano wersję 1.49.0 terminalowego agenta Kimi Code CLI, która zmienia sposób, w jaki narzędzie zarządza tokenami dla odpowiedzi modelu i obsługuje zapytania thinkujące. Ta aktualizacja jest istotna dla zespołów, które często borykają się z błędami przepełnienia kontekstu podczas długich sesji programistycznych.

    Co nowego w pigułce

    • Dynamiczne budżetowanie tokenów – CLI szacuje dostępne miejsce w oknie kontekstowym zamiast stosować sztywny limit 32 000 tokenów.
    • Nowa zmienna środowiskowa KIMI_MODEL_MAX_COMPLETION_TOKENS pozwala na ręczne ograniczenie długości generowanych odpowiedzi.
    • Ujednolicona obsługa modeli thinkujących przez parametr thinking.type, eliminując potrzebę automatycznego dodawania starszego reasoning_effort.
    • Poprawka historii konwersacji zapobiega gubieniu pustych wpisów rozumowania z historii sesji.

    Dlaczego stały limit tokenów był problemem

    W poprzednich wersjach Kimi Code CLI każde zapytanie do API miało ustawiony limit max_tokens=32000. To mogło wydawać się rozsądne, ale podczas długich sesji agent gromadził wiele plików źródłowych, logów testów, wyników narzędzi i historii poprawek. W rezultacie okno kontekstowe stawało się zbyt małe, a stały limit odpowiedzi nie mógł się zmieścić w dostępnej przestrzeni, co prowadziło do błędów invalid-request i przerywania pracy.

    Wersja 1.49.0 rozwiązuje ten problem poprzez dynamiczne szacowanie pozostałego miejsca w oknie kontekstowym przed każdym zapytaniem. max_completion_tokens jest automatycznie dostosowywane, aby zmieścić się w dostępnej przestrzeni. Dla zespołów DevOps i web-developerów oznacza to mniej awarii w pipeline'ach CI, na hostingu i w środowiskach kontenerowych.

    Kontrola nad limitem – zmienna środowiskowa w akcji

    Nowa wersja wprowadza również KIMI_MODEL_MAX_COMPLETION_TOKENS jako maksymalny limit dla generowanych tokenów. Jest to szczególnie przydatne w konfiguracjach współdzielonych, takich jak kontenery Dockera, zadania CI i środowiska deweloperskie. Stara zmienna KIMI_MODEL_MAX_TOKENS nadal działa jako alias kompatybilności, więc istniejące konfiguracje nie wymagają natychmiastowych poprawek.

    Ustawienie którejkolwiek z tych zmiennych na 0 lub wartość ujemną całkowicie wyłącza mechanizm przycinania, a CLI działa wtedy zgodnie ze standardowym zachowaniem API.

    Thinking models: porządek zamiast chaosu

    Obsługa modeli thinkujących również została zaktualizowana. Wersja 1.49.0 standaryzuje konfigurację wokół parametru thinking.type i przestaje automatycznie dodawać starszy reasoning_effort przy korzystaniu z natywnej konfiguracji Kimi.

    To jest istotne, ponieważ integracje korzystające z dostawcy Kosong i starszych endpointów kompatybilnych z Kimi mogą wymagać aktualizacji. Jeśli backend wciąż oczekuje reasoning_effort, należy go jawnie przekazać przez opcje generowania. Standaryzacja jednego parametru zmniejsza niejasności w kontrakcie między CLI, adapterem dostawcy a endpointem modelu, ale starsze serwery proxy i backendy API mogą wymagać ręcznej migracji.

    Dodatkowo poprawiono błąd, przez który puste wpisy rozumowania były usuwane z historii konwersacji. Zachowanie struktury wiadomości z polem reasoningowym, nawet jeśli jest ono puste, utrzymuje spójną historię tur dla modeli thinkujących. To jest zgodne z szerszym zachowaniem Kimi: rozumowanie z poprzednich tur jest domyślnie zachowywane, chyba że użytkownik jawnie je wyłączy przez [thinking] keep = "off".

    Co to znaczy dla codziennej pracy

    Praktyczne konsekwencje dla programistów są znaczące. Dłuższe sesje autonomicznego kodowania, takie jak vibe coding, refaktoryzacja czy debugowanie, przestaną kończyć się błędami po kilkudziesięciu minutach. Agent może pracować z dużym kontekstem repozytorium, wynikami testów i historią zmian bez potrzeby ręcznego czyszczenia sesji.

    Wersja 1.49.0 to wydanie maintenance'owe w ramach linii CLI, która, jak wskazuje dokumentacja projektu, przechodzi na nowszy produkt Kimi Code. Starsze repozytorium Python CLI zostało już zarchiwizowane, a to wydanie należy traktować jako ważną łatkę stabilizacyjną przed szerszą migracją.

    Podsumowanie

    Kimi Code CLI 1.49.0 to przede wszystkim wydanie poprawiające niezawodność: dynamiczne budżetowanie tokenów rozwiązuje problem przepełnienia kontekstu, zmienna środowiskowa daje zespołom kontrolę nad limitami, a standaryzacja parametrów thinkujących porządkuje kontrakt API. Przy aktualizacji warto sprawdzić kompatybilność endpointów – jeśli integracja opiera się na reasoning_effort, należy to jawnie skonfigurować. Pozostałe funkcje działają od razu i są bardziej stabilne.

    Źródła

  • Kimi Code CLI 1.49.0 wprowadza dynamiczne zarządzanie tokenami i ujednolica obsługę modeli myślących

    Kimi Code CLI 1.49.0 wprowadza dynamiczne zarządzanie tokenami i ujednolica obsługę modeli myślących

    Narzędzie Kimi Code CLI otrzymało aktualizację 1.49.0, która została udostępniona użytkownikom 16 lipca 2026 roku. W tej wersji skupiono się na rozwiązaniu problemu przepełniania okna kontekstowego podczas długich sesji programistycznych. CLI wprowadza mechanizm dynamicznego budżetowania tokenów, który dostosowuje limity do dostępnego miejsca w kontekście modelu. Dodatkowo, zaktualizowano sposób komunikacji z modelami myślącymi oraz wprowadzono nową zmienną środowiskową, dając zespołom większą kontrolę nad limitami wyjściowymi.

    Kluczowe zmiany w skrócie

    • Dynamiczny budżet tokenów – CLI oblicza dostępny limit wyjściowy na podstawie pozostałego okna kontekstowego, zamiast wysyłać stałą wartość, która może przekroczyć pojemność modelu.
    • Nowa zmienna KIMI_MODEL_MAX_COMPLETION_TOKENS – pozwala ustalić twardy limit generowanych tokenów, który jest dynamicznie przycinany do bezpiecznego poziomu.
    • Ujednolicenie parametrów modeli myślących – zmiana z przestarzałego reasoning_effort na thinking.type, bez automatycznego dodawania starego parametru.
    • Zachowanie pustej treści rozumowania – puste reasoning_content jest teraz przechowywane w historii wiadomości, co ma znaczenie dla wieloetapowych konwersacji.

    Dlaczego przepełnienie kontekstu to realny problem

    Podczas pracy z Kimi Code CLI nad większym projektem, kontekst rozmowy szybko się powiększa. Pliki źródłowe, wyniki testów, komunikaty z shella i wcześniejsze odpowiedzi modelu zajmują miejsce w oknie kontekstowym. Modele Kimi mają swoje limity: K3 obsługuje do 1 048 576 tokenów, natomiast K2.7 Code i K2.6 zatrzymują się na 262 144 tokenach.

    Stały limit wyjściowy, który działał na początku sesji, po kilkudziesięciu interakcjach może stać się nierealny. CLI wysyłało go w żądaniu, API odrzucało, a sesja się kończyła błędem. Dynamiczny budżet rozwiązuje ten problem – przed każdym zapytaniem narzędzie sprawdza, ile miejsca zostało i odpowiednio przycina maksymalną liczbę tokenów do wygenerowania.

    Jak skonfigurować nową zmienną środowiskową

    Jak skonfigurować nową zmienną środowiskową

    Zmienna KIMI_MODEL_MAX_COMPLETION_TOKENS pozwala na ograniczenie długości odpowiedzi. Wartość taka jak 4096 sprawdza się w przypadku krótkich edycji kodu, diagnostyki czy wyjaśniania poleceń.

    Nawet gdy ustawisz tę zmienną, CLI nie wyśle wartości wyższej niż różnica między maksymalnym rozmiarem okna a tokenami już zajętymi przez wejście. To zabezpieczenie przed przypadkowym przekroczeniem limitu.

    Dotychczasowa zmienna KIMI_MODEL_MAX_TOKENS nadal działa, ale nowa ma pierwszeństwo, gdy obie są zdefiniowane. Jeśli chcesz całkowicie wyłączyć przycinanie, ustaw którąkolwiek z nich na 0 lub na wartość ujemną.

    Modele myślące bez starego balastu

    Modele myślące bez starego balastu

    Kolejna istotna zmiana dotyczy modeli myślących. Wcześniej Kimi Code CLI automatycznie dodawał do żądań parametr reasoning_effort, gdy tryb myślenia był aktywny. Teraz używa thinking.type, zgodnie z aktualnym standardem API Kimi.

    To oznacza, że starsze endpointy kompatybilne z Kimi mogą wymagać jawnego przekazania reasoning_effort przez opcje generowania. Jeśli integrujesz CLI z proxy lub własnym endpointem, warto to sprawdzić przed aktualizacją.

    Zmienił się również sposób przechowywania konfiguracji myślenia – stan domyślny trafia teraz do ~/.kimi/config.toml jako default_thinking, a wcześniejszy plik ~/.kimi/kimi.json nie jest już automatycznie odczytywany.

    Operacyjny charakter wydania

    Wersja 1.49.0 nie wprowadza nowego modelu ani spektakularnych funkcji. To aktualizacja, która poprawia niezawodność narzędzia, co sprawia, że mniej przeszkadza podczas pracy. Długie sesje DevOps, debugowanie rozległych baz kodu czy wieloetapowe refaktoryzacje rzadziej kończą się błędem przepełnienia kontekstu.

    Deweloperzy mogą teraz decydować o maksymalnej długości odpowiedzi, co pozwala na lepsze zarządzanie kosztami, opóźnieniami i bezpieczeństwem kontekstu. Zespoły korzystające z modeli myślących zyskują czystszy interfejs konfiguracji, bez problemów związanych z przestarzałymi parametrami.

    Źródła

  • Factory v0.172.0: nowy Mission Control i szybsze uruchamianie lokalnych projektów

    Factory v0.172.0: nowy Mission Control i szybsze uruchamianie lokalnych projektów

    Factory wypuściło wersję v0.172.0, która wprowadza zaktualizowany panel Mission Control oraz uproszczoną konfigurację folderów lokalnych. Aktualizacja poprawia także działanie pól tekstowych i eliminuje kilka błędów, takich jak problemy z uwierzytelnianiem MCP oraz błędne renderowanie Markdown.

    Co nowego w Factory v0.172.0

    • Ujednolicony panel Mission Control – wszystkie zadania i przepływy pracy agentów AI zebrane w jednym miejscu
    • Przycisk szybkiego podłączania projektu lokalnego – mniej kliknięć przy starcie pracy z istniejącym kodem
    • Spójna edycja tekstu w całej aplikacji – przewidywalne skróty, zaznaczanie i nawigacja kursorem
    • Poprawki uwierzytelniania MCP – ciche odświeżanie tokenów, koniec z duplikującymi się monitami o logowanie
    • Lepsza obsługa PDF-ów z hasłem i poprawione renderowanie Markdown

    Mission Control w jednym panelu – mniej przełączania kontekstu

    Główną nowością jest połączenie wszystkich elementów związanych z misjami agentów w jeden panel Mission Control. Zarządzanie zadaniami AI wcześniej wymagało przełączania się między różnymi widokami, co mogło być męczące przy większej liczbie równoległych sesji.

    Teraz można znaleźć wszystko – podgląd postępów, statusy zadań, listę aktywnych agentów – w jednym miejscu. To zwiększa wygodę i pozwala na szybszą orientację w działaniach agenta, bez potrzeby ciągłego przełączania kart i okien.

    Mission Control rozwija się jako centralny punkt operacyjny, a nie tylko lista zadań. W przyszłych aktualizacjach dodane zostanie raportowanie tokenów sub-agentów do panelu Mission Control, co wskazuje na dalszy rozwój tej funkcji.

    Lokalny projekt w kilka sekund

    Drugą istotną zmianą jest nowy przycisk do szybkiego podpinania lokalnego folderu projektu. Zamiast przechodzić przez kilka ekranów konfiguracyjnych, wystarczy jedno kliknięcie, aby wskazać katalog z istniejącym kodem.

    Dla programisty, który chce szybko otworzyć repozytorium i rozpocząć pracę, to znacząca różnica. Factory stawia na zmniejszenie tarcia przy wchodzeniu w projekt – im szybciej agent zacznie działać na realnym kodzie, tym lepiej.

    Drobiazgi, które robią różnicę

    Ujednolicenie zachowania pól tekstowych może wydawać się kosmetyką, ale w środowisku AI-driven development ma duże znaczenie. Często wklejasz prompty, edytujesz wygenerowane plany, poprawiasz konfiguracje – i oczekujesz, że skróty klawiszowe będą działać w ten sam sposób. Teraz tak jest.

    Poprawki MCP są również istotne. Model Context Protocol łączy agentów z zewnętrznymi narzędziami i serwisami. Factory przechowuje tokeny MCP w systemowym keychain, co oznacza, że jedno uwierzytelnienie działa na wiele projektów. Gdy autoryzacja nie działała, wpływało to na wszystkie integracje. Po aktualizacji tokeny odświeżają się automatycznie, a duplikujące się monity o logowanie zniknęły.

    Obsługa zaszyfrowanych PDF-ów została poprawiona. Jeśli agent napotyka dokumentację, specyfikację lub manual w formacie PDF zabezpieczonym hasłem, nie powinien już generować błędów ani nieczytelnych wyników.

    Ostatnią poprawką jest renderowanie Markdown – odpowiedzi agentów, podsumowania zadań oraz dokumentacja techniczna generowana przez Droidy będą wyświetlane poprawnie. To istotny detal, ponieważ różnica między czytelnym formatowaniem a zbitką tekstu jest odczuwalna podczas długiego czytania.

    Co to oznacza dla zespołów dev

    Każda z tych zmian osobno nie jest rewolucyjna, ale razem tworzą aktualizację, która realnie skraca czas od pomysłu do działania. Mniej kliknięć przy konfiguracji, lepsza widoczność pracy agentów, stabilniejsze integracje i czytelniejszy output – to rzeczy, które docenisz po kilku godzinach pracy.

    Factory konsekwentnie rozwija Mission Control jako centrum dowodzenia. W połączeniu z modelami MCP na poziomie projektu, folderu i użytkownika, powstaje środowisko, w którym agent AI jest integralną częścią workflow, bez potrzeby ciągłego edytowania plików YAML.

    Źródła

  • OpenCode ogranicza agentów AI – nowe limity głębokości i porządki w interfejsie

    OpenCode ogranicza agentów AI – nowe limity głębokości i porządki w interfejsie

    OpenCode wprowadza nowe ograniczenia dla agentów AI, w tym domyślne zablokowanie rekurencyjnego uruchamiania subagentów. Dodatkowo modele Meta otrzymały lepsze ustawienia wnioskowania, a aplikacja Desktop przeszła szereg poprawek użyteczności. Te zmiany kończą wielomiesięczny proces migracji do nowego interfejsu Desktop.

    Co nowego w OpenCode – fakty w pigułce

    • Subagenty domyślnie nie tworzą kolejnych subagentów – mechanizm ten ogranicza niekontrolowane rozgałęzanie zadań oraz ryzyko nadmiernego zużycia tokenów.
    • Ustawienie subagent_depth steruje poziomem delegacji – domyślnie wynosi 1, co pozwala głównemu agentowi na uruchamianie podwładnych, ale nie im na tworzenie własnych.
    • Poprawiono domyślne wnioskowanie modeli Meta – zmiana ma przynieść lepsze rezultaty bez konieczności ręcznego dostrajania parametrów.
    • Desktop zyskał skróty i przywróconą pomoc – Mod+N tworzy nową kartę, przywrócono przycisk Help, poprawiono widoczność sesji.

    Głębokość pod kontrolą – jak działa subagent_depth

    Deweloperzy, którzy przyzwyczaili się do swobodnego delegowania zadań między agentami, mogą być zaskoczeni nowymi ograniczeniami. Wcześniej subagent mógł uruchomić kolejnego subagenta, co w przypadku bardziej złożonych zadań prowadziło do niekontrolowanego rozrostu. OpenCode wprowadza konfigurowalny limit głębokości.

    Parametr subagent_depth określa maksymalny poziom zagnieżdżenia. Wartość domyślna to 1, co pozwala głównemu agentowi na tworzenie subagentów, ale ci nie mogą uruchamiać kolejnych. W przypadku potrzeby głębszej hierarchii, wartość 2 umożliwia jeden dodatkowy poziom. Ustawienie 0 całkowicie wyłącza możliwość delegowania.

    Przykład konfiguracji dla jednego poziomu zagnieżdżenia:

    {
  "subagent_depth": 1
}

    Dla bardziej rozbudowanego workflow:

    {
  "subagent_depth": 2
}

    Narzędzie task egzekwuje ten limit – gdy sesja osiągnie dozwoloną głębokość, próba stworzenia kolejnego potomka kończy się błędem z informacją o kluczu konfiguracyjnym. To mechanizm zapobiegający problemom z rekurencją, które mogą prowadzić do nieprzewidywalnego wzrostu zużycia tokenów.

    Modele Meta z lepszymi ustawieniami domyślnymi

    Wraz z ograniczeniami dla subagentów, OpenCode poprawił domyślne parametry wnioskowania dla modeli Meta. Celem jest, aby modele lepiej radziły sobie z typowymi zadaniami programistycznymi od razu po instalacji, bez potrzeby ręcznego dostrajania przez użytkownika.

    Nie podano konkretnych liczb dotyczących wcześniejszego i obecnego poziomu głębokości, wpływu na opóźnienia czy zużycie tokenów. Wiadomo jednak, że zmiana ma przynieść lepsze wnioskowanie w standardowych scenariuszach kodowania i zadań agentowych.

    Desktop – szybciej, wygodniej, bez bałaganu

    Równocześnie z pracami nad silnikiem agentów, zespół uporządkował aplikację Desktop. Migracja do nowego layoutu, rozwijanego od poprzednich wersji, została zakończona. Dla zainteresowanych dostępny jest również boczny panel eksperymentalny pod zmienną OPENCODE_SIDECAR_V2.

    Co konkretnie się zmieniło? Mod+N otwiera nową kartę bez potrzeby przeszukiwania menu. Przywrócono przycisk Help, który wcześniej zniknął w wersjach release. Sesje z czasem archiwizacji ustawionym na null pozostają widoczne na liście głównej, co wcześniej nie miało miejsca. Na Windowsie schowano przycisk zamykania panelu bocznego, ponieważ kolidował z natywnymi kontrolkami okna. Subagent picker zyskał skrót ze strzałką w górę do szybkiego zamykania.

    Poprawiono również przewijanie na stronie głównej, przyklejone nagłówki sesji, gotowość WSL i widoczność selektora niestandardowych agentów. Choć detale mogą wydawać się drobne, dla osób przeskakujących między kilkoma równoległymi sesjami subagentów, to realna oszczędność czasu.

    Co to znaczy dla zespołów developerskich

    Zmiana domyślnego zachowania subagentów ma znaczenie dla każdego, kto używa agentów do równoległej analizy repozytoriów, testowania czy zadań infrastrukturalnych. Zespoły wciąż mogą tworzyć wielopoziomowe workflow, ale teraz wymaga to świadomej decyzji konfiguracyjnej.

    Dla środowisk CI/CD i hostowanych platform deweloperskich domyślna wartość 1 pomaga utrzymać przewidywalność, zmniejszając ryzyko niekontrolowanego rozrostu zadań i związanych z tym kosztów. Nie podano jednak konkretnych metryk dotyczących oszczędności tokenów czy czasu wykonania.

    Źródła

  • OpenCode kończy migrację Desktop v2 i radykalnie skraca czas ładowania

    OpenCode kończy migrację Desktop v2 i radykalnie skraca czas ładowania

    Nowa wersja OpenCode v2 kończy migrację interfejsu Desktop v2, wprowadzając szereg poprawek, które znacząco wpłyną na pracę programistów korzystających z asystentów AI. Najbardziej zauważalną zmianą jest optymalizacja czasu uruchamiania – ekran główny, który wcześniej mógł zamrażać aplikację na kilkadziesiąt sekund, teraz ładuje się błyskawicznie.

    Najważniejsze zmiany w OpenCode v2

    • Desktop v2 jest teraz domyślnym interfejsem, z możliwością powrotu do starego układu
    • Czas ładowania Home spadł z ponad minuty do około sekundy w niezależnych pomiarach
    • Historia timeline ładuje więcej wpisów na raz, eliminując irytujące doczytywanie podczas przewijania
    • Naprawiono błędy terminala, pickera projektów i obsługi uprawnień sesji zdalnych
    • Wdrożono onboarding dla nowych użytkowników Desktop v2

    Koniec przejściówki – Desktop v2 na dobre

    Zespół OpenCode zakończył migrację nowego interfejsu, która trwała przez różne wersje v2. Sam układ nie jest nowością – użytkownicy testowali go od jakiegoś czasu – ale dopiero teraz stał się częścią głównego wydania desktopowego. Twórcy podeszli do zmiany ostrożnie: każdy może wrócić do poprzedniego układu jednym kliknięciem w ustawieniach, jeśli nowy interfejs nie przypadnie mu do gustu.

    Pierwsze uruchomienie po aktualizacji uruchamia krótki onboarding. To miły dodatek – zamiast wrzucać użytkownika w nieznany układ, aplikacja prowadzi go przez najważniejsze elementy. Deweloperzy, którzy spędzają w OpenCode długie godziny, docenią także odświeżony wygląd widoków plików – w wersji v2 mogły one wyświetlać się na złym tle, co teraz zostało naprawione.

    Wydajność, która robi różnicę

    Oficjalne notatki wskazują na „znaczne skrócenie” czasu zimnego startu Home. Nieoficjalne pomiary pokazują, że czas ten spadł z około 78 sekund do około jednej sekundy. Choć ta konkretna liczba nie jest uniwersalnym benchmarkiem, różnica jest odczuwalna od pierwszego kliknięcia.

    Kolejna istotna poprawka dotyczy timeline’u. Dotychczas przewijanie dłuższej historii przypominało walkę z buforem – aplikacja ciągle doczytywała kolejne fragmenty. Teraz ładuje więcej na raz, a po chwilowej utracie połączenia automatycznie synchronizuje stan. Dla osób prowadzących wielogodzinne sesje kodowania z agentem AI brak przerw w kontekście jest kluczowy.

    Terminal przestał kraść fokus

    Każdy, kto pracował z OpenCode, zna irytujący moment, gdy terminal nagle przejmuje fokus przy montowaniu, przerywając pisanie gdzie indziej. Aktualizacja eliminuje ten problem i dodatkowo zapewnia, że zmiana nazwy zakładki terminala nie resetuje kursora.

    Picker projektów również został poprawiony – nie zawiesza się już, gdy jego kotwica wciąż się ładuje. Dla zespołów pracujących zdalnie istotna jest naprawa automatycznej akceptacji uprawnień: każdy serwer teraz trzyma własny stan, więc zgoda udzielona na jednej maszynie nie przenosi się przypadkowo na inną.

    Szerszy kontekst

    Wydanie v2 jest częścią większej przebudowy OpenCode, której finał nastąpił miesiąc później wraz z premierą wersji 2.0. W tym czasie zespół przeszedł z Buna na Node.js, wymienił Tauri na Electron i wprowadził równoległe sesje AI w osobnych zakładkach. Jednak to drobne, punktowe poprawki z lipcowego wydania – szybszy start, płynniejsza historia, terminal bez irytujących przeskoków – wpływają na komfort, który decyduje o codziennej użyteczności narzędzia.

    Źródła