Tag: API

  • Claude z nowymi narzędziami bezpieczeństwa: wygasanie kluczy API i pełniejszy wgląd w wydarzenia administracyjne

    Claude z nowymi narzędziami bezpieczeństwa: wygasanie kluczy API i pełniejszy wgląd w wydarzenia administracyjne

    Anthropic rozszerzyło dokumentację Access Transparency dla zdarzeń cmek_preserve oraz wprowadziło możliwość ustawiania daty wygaśnięcia kluczy API bezpośrednio w konsoli Claude. Te zmiany, choć mogą wydawać się drobne, przynoszą znaczące korzyści dla zespołów DevOps i platform engineeringu w zakresie zarządzania bezpieczeństwem.

    Co konkretnie się zmieniło?

    • Access Transparency zawiera teraz przykładowy payload zdarzeń cmek_preserve oraz dwa nowe kody przyczyny: policy_violation_investigation i csae_report.
    • Dokumentacja wyjaśnia, że zdarzenie zachowania treści jest rejestrowane niezależnie od tego, czy proces został zainicjowany przez człowieka, czy przez zautomatyzowany pipeline bezpieczeństwa.
    • Klucze API można teraz tworzyć z określoną datą wygaśnięcia – predefiniowaną, niestandardową lub bezterminową.
    • Dla kluczy z okresem życia minimum 7 dni Anthropic wysyła do twórcy powiadomienie e-mail przed wygaśnięciem.
    • Pole expires_at w Admin API oraz tabela kluczy w konsoli pokazują status wygaśnięcia, co ułatwia audyt i rotację.

    Więcej przejrzystości wokół CMEK

    Access Transparency to mechanizm, który umożliwia organizacjom wgląd w to, kiedy i dlaczego Anthropic uzyskuje dostęp do ich treści. Rozszerzenie dokumentacji o filtry i konkretne przykłady payloadów dla zdarzeń cmek_preserve będzie szczególnie przydatne dla zespołów pracujących w regulowanych środowiskach.

    Ważnym uzupełnieniem jest wyjaśnienie dotyczące mechanizmu przechowywania treści. Kiedy organizacja korzysta z kluczy szyfrowania zarządzanych przez klienta (CMEK), zachowana treść jest ponownie szyfrowana poza tym kluczem. Dzięki temu dochodzenie może być kontynuowane niezależnie od tego, czy klient nadal udostępnia swój klucz, co jest istotne w przypadku incydentów bezpieczeństwa.

    W dokumentacji pojawiły się także kody przyczyn zachowania treści: safety_review, incident_response, policy_violation_investigation oraz csae_report. Dla audytorów to konkretna informacja – wiadomo nie tylko, że coś zostało zachowane, ale także dlaczego i czy stało za tym narzędzie automatyczne, czy decyzja człowieka.

    Koniec z wiecznymi kluczami

    Druga zmiana, choć bardziej praktyczna, jest równie istotna. W konsoli Claude można teraz ustawić datę wygaśnięcia klucza API już na etapie jego tworzenia. Użytkownicy mogą wybierać spośród okresów predefiniowanych, niestandardowych lub opcji "Nigdy". Istniejące klucze pozostają bez zmian, co zapobiega problemom z działaniem pipeline'ów.

    Długowieczne klucze API to klasyczny problem bezpieczeństwa – im dłużej klucz istnieje, tym większe ryzyko jego wycieku. Automatyczne przypomnienia e-mail dla kluczy z minimum tygodniowym okresem życia stanowią dodatkową warstwę zabezpieczeń. Jeśli ktoś zapomni o rotacji, system przypomni.

    Dla zespołów zarządzających sekretami i rotacją poświadczeń nowe pole expires_at w Admin API umożliwia budowanie własnych workflow opartych na tych danych. Ręczne śledzenie, który klucz kiedy wygasa, staje się zbędne.

    Co to oznacza w praktyce

    Te zmiany nie są rewolucyjne, ale wskazują na wyraźny trend: Claude z nowymi narzędziami bezpieczeństwa staje się coraz bardziej audytowalny i łatwiejszy do wdrożenia w środowiskach wymagających ścisłej kontroli. Więcej zdarzeń administracyjnych trafia do logów, a operatorzy zyskują narzędzia do zarządzania cyklem życia poświadczeń bez konieczności tworzenia własnych obejść.

    Dla osób wdrażających Claude'a w organizacjach z wymogami compliance, to dwie mniej rzeczy do zmartwień.

    Źródła

  • Anthropic wprowadza kontrolę daty ważności kluczy API — koniec z zapomnianymi tokenami

    Anthropic wprowadza kontrolę daty ważności kluczy API — koniec z zapomnianymi tokenami

    Anthropic wprowadziło nowe mechanizmy kontroli cyklu życia kluczy API w konsoli Claude Platform. Deweloperzy mają teraz możliwość ustawienia czasu wygaśnięcia klucza już w momencie jego tworzenia, wybierając spośród kilku predefiniowanych okresów lub decydując się na dostęp bezterminowy. Zmiana dotyczy zarówno kluczy osobistych, jak i administracyjnych (Admin API), a użytkownicy otrzymają powiadomienia e-mailowe ostrzegające przed zbliżającą się dezaktywacją.

    Kluczowe informacje o aktualizacji

    • Predefiniowane okresy ważności obejmują 3 godziny, 1 dzień, 7 dni oraz 30 dni — dostępna jest także opcja niestandardowego czasu oraz ustawienie „Nigdy”.
    • Powiadomienia e-mail są wysyłane do twórców kluczy z co najmniej 7-dniowym okresem życia — szczegółowe zasady różnią się w zależności od długości ważności.
    • Pole expires_at w Admin API umożliwia zespołom programistyczne śledzenie i audytowanie dat wygaśnięcia wszystkich kluczy.
    • Istniejące klucze pozostają bez zmian — nowe reguły dotyczą wyłącznie tokenów tworzonych po wdrożeniu funkcji.

    Jak działają nowe mechanizmy wygasania

    Podczas tworzenia klucza w konsoli Claude Platform użytkownik ma teraz wyraźny wybór okresu ważności. Opcje są jasne: od krótkich (3 godziny — idealne do testów czy sesji debugowania), przez dłuższe okna produkcyjne (7 lub 30 dni), aż po pełną elastyczność w postaci własnego zakresu czasowego.

    Klucze tworzone z flagą „Nigdy” nie mają daty wygaśnięcia — to rozwiązanie jest przeznaczone głównie dla organizacji korzystających z zewnętrznych systemów zarządzania sekretami, gdzie rotacją zarządza oddzielna warstwa narzędziowa.

    Po przekroczeniu daty ważności klucz przestaje działać. Żądania wysłane z wygasłym tokenem zwracają błąd 401 authentication_error, a jego reaktywacja nie jest możliwa — konieczne jest wygenerowanie nowego klucza.

    Powiadomienia, które ratują przed awarią

    Anthropic dodało do aktualizacji system ostrzeżeń e-mailowych. Zasady są dwustopniowe: dla kluczy utworzonych z okresem co najmniej 14 dni powiadomienie przychodzi na 7 dni przed wygaśnięciem. Jeśli klucz ma żywotność między 7 a 13 dni — ostrzeżenie pojawia się na dobę przed dezaktywacją.

    Tokeny krótsze niż 7 dni nie generują powiadomień, co jest uzasadnione — przy trzygodzinnym oknie czasowym mail dotarłby prawdopodobnie już po fakcie.

    Dla zespołów devopsowych to praktyczne zabezpieczenie. W mniejszych środowiskach, gdzie rotacja kluczy bywa odkładana, e-mail może uchronić przed nagłym przestojem integracji czy pipeline'u CI/CD.

    Admin API i pole expires_at

    Nowe pole expires_at w Admin API zwraca datę wygaśnięcia w formacie RFC 3339 lub wartość null dla kluczy bezterminowych.

    Dzięki temu zespoły mogą budować własne dashboardy monitorujące stan autoryzacji, pisać skrypty audytowe lub integrować sprawdzanie dat z istniejącymi systemami alertowymi. Data wygaśnięcia jest jawnie dostępna w odpowiedzi API, co eliminuje potrzebę zgadywania lub przeszukiwania logów.

    To także dobra wiadomość dla tych, którzy automatyzują zarządzanie dostępem. Pole expires_at ułatwia wykrywanie kluczy zbliżających się do końca cyklu życia i planowanie rotacji bez konieczności zewnętrznego bookkeepingu.

    Co to oznacza dla bezpieczeństwa

    Co to oznacza dla bezpieczeństwa

    Anthropic zaleca regularną rotację poświadczeń i trzymanie kluczy z dala od kodu źródłowego czy promptów. Nowe mechanizmy wspierają te zalecenia, ułatwiając ich stosowanie — deweloper nie musi już pamiętać o ręcznej wymianie tokena, ponieważ platforma automatycznie wymusi odświeżenie po zadanym czasie.

    Dla zespołów pracujących z agentami, serwisami produkcyjnymi czy współdzielonymi workloadami istotna jest możliwość odróżnienia typów kluczy. Platforma rozróżnia klucze osobiste, kont serwisowych i przestrzeni roboczych — dwa pierwsze typy automatycznie tracą ważność, gdy powiązane konto znika z organizacji.

    Nowa funkcjonalność nie zastąpi pełnoprawnego systemu zarządzania sekretami, ale dla wielu średnich i mniejszych wdrożeń może okazać się wystarczającym zabezpieczeniem. Szczególnie tam, gdzie zespół nie ma jeszcze wdrożonej federacji tożsamości czy zautomatyzowanej rotacji przez vault.

    Podsumowanie

    Aktualizacja Anthropic to krok, który realnie zmniejsza ryzyko w codziennej pracy. Wbudowana rotacja kluczy, czytelne ostrzeżenia i programistyczny dostęp do dat wygaśnięcia to zestaw, który powinien być standardem — cieszy, że w końcu trafił do Claude Platform.

    Źródła

  • Anthropic ujednolica limity API i upraszcza strukturę tierów w platformie Claude

    Anthropic ujednolica limity API i upraszcza strukturę tierów w platformie Claude

    Firma Anthropic ogłosiła zmiany w zasadach korzystania z API Claude. Modele Sonnet i Haiku otrzymały teraz takie same limity szybkości jak Claude Opus na wszystkich poziomach użytkowania. Platforma została zreorganizowana, konsolidując dotychczasową strukturę w trzy czytelne tiery: Start, Build i Scale. Dla większości zespołów oznacza to automatyczne przeniesienie do wyższego poziomu bez konieczności podejmowania jakichkolwiek działań.

    Kluczowe informacje o aktualizacji

    • Limity API dla Claude Sonnet i Haiku są teraz równe limitom Claude Opus na każdym tierze
    • Trzy tiery – Start, Build i Scale – zastępują wcześniejszy, bardziej rozdrobniony system
    • Automatyczna migracja – większość organizacji zostanie przeniesiona do wyższego tieru bez dodatkowych formalności
    • Limity organizacyjne – ustalane są na poziomie całej organizacji, a nie pojedynczych użytkowników
    • Maksymalny miesięczny wydatek dla tieru Scale wynosi 200 000 dolarów

    Co konkretnie zmieniło się w limitach?

    Dotychczas korzystanie z różnych modeli Claude oznaczało różne limity – Opus miał własne pułapy, Sonnet inne, a Haiku jeszcze inne. Teraz to się zmienia. Anthropic postawiło na spójność: niezależnie od tego, czy aplikacja wywołuje Claude Sonnet do generowania kodu, czy Haiku do lżejszych zadań, limit żądań na minutę (RPM) oraz tokenów wejściowych i wyjściowych jest identyczny.

    W tierze Start limit wynosi około 1000 RPM, 2 miliony tokenów wejściowych na minutę i 400 tysięcy tokenów wyjściowych. Build podnosi te wartości do 5000 RPM, 5 milionów tokenów wejściowych i miliona wyjściowych. Scale, przeznaczony dla największych wdrożeń produkcyjnych, oferuje 10 000 RPM, 10 milionów tokenów wejściowych i 2 miliony wyjściowych przy wspomnianym limicie wydatków 200 000 dolarów miesięcznie. Warto jednak sprawdzać aktualne liczby bezpośrednio w dokumentacji – Anthropic zastrzega, że wartości mogą być aktualizowane.

    Dlaczego to ma znaczenie dla zespołów deweloperskich?

    Ujednolicenie limitów upraszcza planowanie wydajnościowe. Zespoły budujące aplikacje oparte na wielu modelach Claude – na przykład systemy agentowe, gdzie jeden model planuje zadania, a drugi wykonuje generowanie kodu – nie muszą już osobno kalkulować przepustowości dla każdego endpointu. Jedna polityka limitów obejmuje teraz całą organizację.

    Szczególnie odczują to środowiska o wysokiej przepustowości: potoki DevOps, backendowa automatyzacja czy narzędzia do generowania kodu w czasie rzeczywistym. Wcześniej różnice między modelami mogły wymuszać ograniczenia w architekturze – teraz można skalować równomiernie. Automatyczne przeniesienie większości organizacji do wyższego tieru dodatkowo zmniejsza tarcia przy rozwoju produktu.

    Trzy tiery – przejrzystość zamiast złożoności

    Konsolidacja do trzech poziomów to krok w stronę prostoty. Zamiast rozbudowanej struktury, którą trudno było wytłumaczyć nowym członkom zespołu, mamy logiczną ścieżkę: Start dla projektów na wczesnym etapie i małych integracji, Build dla rozwijających się aplikacji, oraz Scale dla dużych wdrożeń korporacyjnych.

    Limity działają teraz na poziomie organizacji. To rozwiązanie eliminuje sytuacje, w których jeden intensywnie korzystający z API deweloper blokuje dostęp pozostałym. Administratorzy zyskują lepszą kontrolę nad budżetem – miesięczny pułap wydatków w tierze Scale jest jasno określony i wynosi 200 000 dolarów, co pozwala precyzyjnie planować koszty przy dużych wdrożeniach.

    Praktyczne następstwa w świecie web devu i AI

    Dla branży web developmentu i systemów AI zmiany te wpisują się w szerszy trend upraszczania infrastruktury modeli językowych. Twórcy narzędzi takich jak Cursor, Windsurf czy Claude Code, które intensywnie wykorzystują API Claude do generowania i analizy kodu, zyskują bardziej przewidywalne środowisko. Mniej czasu spędzonego na zarządzaniu limitami to więcej czasu na rozwój funkcjonalności. Automatyczna migracja oznacza też, że zespoły nie muszą przerywać pracy, aby dostosować się do nowych zasad – wszystko dzieje się po stronie platformy.

    Źródła

  • Claude Code 2.1.185: cichsza komunikacja z API i mniej fałszywych alarmów

    Claude Code 2.1.185: cichsza komunikacja z API i mniej fałszywych alarmów

    Anthropic wprowadziło 20 czerwca 2026 roku wersję 2.1.185 Claude Code, która wprowadza dwie istotne zmiany w systemie powiadomień dotyczących oczekiwania na odpowiedź API. Aktualizacja koncentruje się na komunikacie wyświetlanym podczas stream-stall, czyli sytuacji, gdy strumień danych z API na dłużej przestaje działać.

    • Claude Code 2.1.185 zmienia treść komunikatu o przeciągnięciu strumienia z „No response from API · Retrying in …” na „Waiting for API response · will retry in …”
    • Próg czasowy wyświetlenia ostrzeżenia zwiększono z 10 do 20 sekund ciszy ze strony API
    • Krótkie opóźnienia sieciowe lub po stronie dostawcy rzadziej będą teraz wywoływać komunikat, co ogranicza szum w terminalu
    • Zmiana dotyczy wyłącznie warstwy UX i obserwowalności — nie wpływa na działanie modelu ani mechanizm ponawiania zapytań

    Komunikat, który nie straszy

    Poprzednia wersja komunikatu — „No response from API · Retrying in …” — sugerowała, że wystąpił problem. Dla dewelopera w trakcie sesji kodowania taki tekst mógł wyglądać jak zapowiedź błędu, podczas gdy klient po prostu czekał na odpowiedź. Nowa treść lepiej oddaje rzeczywistość: klient oczekuje na dane, a ponowienie próby nastąpi, jeśli cisza się przedłuży. Choć to drobna zmiana, w narzędziu używanym przez wiele godzin dziennie takie szczegóły mają znaczenie.

    Zespół Anthropic nie zmienił mechanizmu retry — chodzi wyłącznie o to, co widzi użytkownik. Dla osób pracujących w web devie, przy automatyzacji DevOps czy w sesjach vibe codingowych oznacza to mniej fałszywych sygnałów, że sesja „wisi”.

    Dlaczego 20 sekund ma znaczenie

    Podniesienie progu z 10 do 20 sekund to odpowiedź na realia infrastruktury API. Krótkie przestoje — spowodowane chwilowym obciążeniem providera, routingiem sieciowym czy restartem usługi — zdarzają się regularnie i zwykle trwają kilka sekund. Przy 10 sekundach próg był na tyle niski, że wiele takich incydentów wywoływało ostrzeżenie. Teraz większość z nich przejdzie niezauważona.

    W praktyce oznacza to, że terminal nie będzie już co chwilę wyświetlał komunikatu o braku odpowiedzi podczas normalnych, krótkotrwałych fluktuacji latency. Deweloperzy korzystający z Claude Code w złożonych pipeline’ach — gdzie odpowiedzi API przychodzą przez kilka warstw pośrednich — powinni odczuć różnicę niemal natychmiast.

    Kontekst i wcześniejsze problemy ze stream-stall

    Problemy z przeciągającymi się odpowiedziami nie są nowe. W raportach z początku 2026 roku użytkownicy opisywali przypadki zamrożenia strumienia — długie przerwy między kolejnymi zdarzeniami, które potrafiły zakłócić rytm pracy. Wprowadzenie czytelniejszego wskaźnika było odpowiedzią na konkretne sygnały ze społeczności. Wersja 2.1.185 nie rozwiązuje samych przyczyn stallowania (to leży po stronie infrastruktury API), ale sprawia, że informowanie o tym stanie jest precyzyjniejsze i mniej inwazyjne.

    Co ciekawe, w changelogu Claude Code zmiana figuruje jako zwykła pozycja „Update”, bez osobnej sekcji czy rozbudowanego opisu. To podkreśla jej charakter — nie jest to przełom funkcjonalny, a przemyślane szlifowanie detalu.

    Znaczenie dla różnych grup użytkowników

    Dla frontendowców i full-stack deweloperów, którzy często pracują z Claude Code w trybie interaktywnym, kluczowa jest przewidywalność interfejsu. Każdy niepotrzebny alert w terminalu rozprasza. Nowy próg czasowy i poprawiony komunikat sprawiają, że narzędzie zachowuje się bardziej „dorośle” — sygnalizuje problem dopiero wtedy, gdy faktycznie może on wymagać uwagi.

    W kontekście DevOps i zautomatyzowanych workflow, gdzie Claude Code działa jako element większego łańcucha (np. w połączeniu z Cursor, Windsurf czy narzędziami CLI), rzadsze ostrzeżenia zmniejszają ryzyko, że skrypt nadrzędny błędnie zinterpretuje komunikat jako twardy błąd i przerwie przetwarzanie.

    Co dalej

    Anthropic nie zapowiedziało kolejnych zmian w tym obszarze, ale kierunek jest jasny: narzędzie ma być coraz lepiej dostosowane do rzeczywistych warunków sieciowych, w jakich pracują deweloperzy. Wersja 2.1.185 wpisuje się w szerszy trend — kolejne buildy Claude Code z czerwca i lipca 2026 roku przynoszą dziesiątki poprawek związanych z niezawodnością, proxy, timeoutami i obsługą błędów. Stream-stall to tylko jeden z wielu elementów tej układanki, ale jego poprawa pokazuje, że Anthropic reaguje na feedback z terminali.

    Źródła

  • Claude Sonnet 4 i Opus 4 przeszły na emeryturę. Czas na aktualizację API

    Claude Sonnet 4 i Opus 4 przeszły na emeryturę. Czas na aktualizację API

    Anthropic oficjalnie wycofał modele Claude Sonnet 4 i Claude Opus 4 z API. Od 15 czerwca 2026 każde zapytanie do claude-sonnet-4-20250514 i claude-opus-4-20250514 zakończy się błędem. Dla zespołów zajmujących się web developmentem, sztuczną inteligencją i DevOps to sygnał do natychmiastowego sprawdzenia konfiguracji produkcyjnych. Jeśli wasza aplikacja wciąż korzysta z tych identyfikatorów, integracja przestała działać.

    Co dokładnie się zmieniło

    • Data wycofania: 15 czerwca 2026 — od tego dnia API zwraca błędy dla starych identyfikatorów modeli.
    • Dotknięte modele: claude-sonnet-4-20250514 oraz claude-opus-4-20250514 (oryginalne wydania 4.0 z maja 2025).
    • Zalecane zamienniki: claude-sonnet-4-6 i claude-opus-4-8 — nowsze i bardziej wydajne.
    • Zasięg problemu: dotyczy bezpośrednich wywołań API — klientów SDK, funkcji serverless, pipeline'ów CI/CD i narzędzi automatyzacji.
    • Kolejne wycofanie: Opus 4.1 (claude-opus-4-1-20250805) — datę utraty wsparcia należy zweryfikować na oficjalnej stronie deprecjacji Anthropic.

    Nie chodzi o etykiety, tylko o konkretne identyfikatory

    Warto zaznaczyć, że Anthropic nie wycofuje całej rodziny Claude Sonnet 4 czy Claude Opus 4. Emerytura dotyczy wyłącznie pierwszych wersji z maja 2025. Modele oznaczone jako claude-sonnet-4-5-20250929, claude-opus-4-5-20251101 czy nowsze wciąż działają normalnie. Problem występuje tam, gdzie ktoś na sztywno wpisał identyfikator z datą 20250514 — a takich przypadków w produkcyjnych backendach jest wiele.

    Po 15 czerwca API zwraca błąd. Jeśli wasz system obsługi klienta, agent AI albo pipeline do generowania kodu polegał na tych modelach, przestał działać z dnia na dzień. Anthropic powiadomił deweloperów 14 kwietnia 2026, a data wycofania to 15 czerwca 2026, co daje około 62 dni na dostosowanie — czasu było sporo, ale jak to zwykle bywa, nie każdy zdążył.

    Jak migrować i nie stracić pół dnia na szukanie

    Migracja jest prosta. W kodzie wystarczy zamienić stary identyfikator na nowy — format zapytań, nagłówki autoryzacji i struktura odpowiedzi nie zmieniły się. W Pythonie z SDK Anthropica wygląda to tak:

    # przed zmianą
model="claude-opus-4-20250514"

# po zmianie
model="claude-opus-4-8"

    Podobnie działa to w JavaScript, curl i innych SDK. Problem nie leży w skomplikowanej zmianie, lecz w liczbie miejsc, gdzie stary identyfikator mógł zostać użyty. Sprawdźcie zmienne środowiskowe, pliki konfiguracyjne CI/CD, zadania cron i zewnętrzne integracje — scenario buildery, platformy do vibe codingu, narzędzia automatyzujące workflow. Każde z nich mogło mieć zaszyty claude-sonnet-4-20250514 w ustawieniach.

    Przy przechodzeniu na Opus 4.7 lub 4.8: zachowanie parametrów temperature, top_p i top_k przy wartościach innych niż domyślne nie zostało potwierdzone w oficjalnych źródłach — przed migracją należy sprawdzić aktualną dokumentację Anthropic.

    Dlaczego to ma znaczenie dla szerszego ekosystemu

    Wycofanie modeli 4.0 wpisuje się w szerszy trend. Anthropic, podobnie jak OpenAI czy Google, przyspiesza cykl życia modeli — nowe wersje pojawiają się co kilka miesięcy, a stare tracą wsparcie po około roku. Dla zespołów pracujących w trybie ciągłego dostarczania to norma. Gorzej, jeśli prowadzicie projekt, który działa stabilnie od miesięcy i nikt nie zaglądał do konfiguracji API.

    Deweloperzy korzystający z Claude przez interfejs claude.ai nie muszą podejmować żadnych działań — tam wybór modelu jest automatyczny. Problem dotyczy wyłącznie dostępu programistycznego. Jeśli korzystacie z Claude przez Amazon Bedrock albo Vertex AI, sprawdźcie osobno ich tabele wsparcia — partnerzy mają własne kalendarze wycofywania.

    Na froncie DevOps warto także pamiętać, że za Opus 4.1 podąży Opus 4.5 i Sonnet 4.5 — ich daty emerytury są już zapowiedziane na trzeci kwartał 2026. Kto migruje teraz z 4.0 na 4.6 lub 4.8, ten za kilka miesięcy i tak będzie musiał powtórzyć tę operację. Dlatego część zespołów rozważa abstrahowanie identyfikatorów modeli przez warstwę zarządzaną — aby nie gonić za każdym ogłoszeniem deprecjacji osobno.

    Podsumowanie

    Wycofanie Claude Sonnet 4 i Claude Opus 4 to nie katastrofa, ale test na dojrzałość procesów w zespole. Jeśli wasze pipeline'y wytrzymały 15 czerwca bez awarii — dobrze. Jeśli nie — macie okazję zautomatyzować monitoring wersji API, zanim kolejne deprecjacje was zaskoczą. W ekosystemie AI modele starzeją się szybko, a umiejętność sprawnej podmiany jednego identyfikatora na inny staje się równie ważna jak sam kod.

    Źródła

  • OpenCode z lepszą integracją MCP i nowymi endpointami API

    OpenCode z lepszą integracją MCP i nowymi endpointami API

    OpenCode wprowadził aktualizację, która poprawia integrację z protokołem MCP oraz dodaje nowe endpointy API. Użytkownicy zyskają stabilniejsze połączenia, lepszą widoczność logów oraz nowe endpointy API v2 do zarządzania sesjami. Zmiany te są istotne, ponieważ dotyczą kluczowych elementów integracji, z których korzysta coraz więcej zespołów programistycznych.

    Co nowego w skrócie

    • MCP zyskuje obsługę ścieżek względem przestrzeni roboczej oraz lepszy podgląd logów serwera
    • Nowe endpointy API v2 umożliwiają zarządzanie sesjami bez zbędnych obejść
    • Naprawiono błędy w schematach narzędzi Gemini, filtrowaniu treści oraz obsłudze dużych repozytoriów Git
    • Ulepszono autoryzację — przepływy OAuth działają stabilniej, także przy równoległych żądaniach

    MCP: stabilność i wygoda na pierwszym planie

    Model Context Protocol stał się w OpenCode kluczowym narzędziem do integracji z zewnętrznymi systemami. Dzięki niemu asystent AI może korzystać z serwerów MCP — zarówno lokalnych, jak i zdalnych — bez modyfikacji kodu edytora. Wystarczy dodać wpis w konfiguracji pod kluczem mcp, aby narzędzia były dostępne dla modelu.

    Wcześniej występowały problemy z połączeniami podczas dłuższych sesji. Serwery SSE mogły wpadać w pętle reconnectów, a starsze wersje SDK nie działały poprawnie. Aktualizacja z 28 i 30 lipca rozwiązała te problemy, przywracając kompatybilność z legacy SDK oraz eliminując niepotrzebne zapętlenia połączeń.

    Dodatkowo, wprowadzono obsługę ścieżek względem przestrzeni roboczej. To zmiana, która ułatwia pracę, ponieważ konfiguracja MCP nie jest już sztywno związana z absolutnymi lokalizacjami, co jest szczególnie przydatne w projektach klonowanych na różne maszyny.

    API v2 i autoryzacja: koniec z ręcznym odświeżaniem

    API v2 i autoryzacja: koniec z ręcznym odświeżaniem

    Nowe endpointy do zarządzania sesjami to długo oczekiwana funkcjonalność dla osób tworzących własne integracje. API v2 umożliwia programowe zarządzanie sesjami — od ich tworzenia po zamykanie — bez potrzeby korzystania z dodatkowych skryptów.

    Autoryzacja również została ulepszona. OpenCode wspierał OAuth dla serwerów MCP, ale teraz przepływ działa bardziej płynnie. Sesje OAuth, które wygasły, są automatycznie odnawiane, nawet przy równoległych żądaniach. Dodatkowo, polecenie opencode mcp auth <nazwa-serwera> zyskało możliwość konfiguracji portów callback, co ułatwia pracę w środowiskach z restrykcyjnymi firewallami.

    Dla zespołów korzystających z organizacyjnych konfiguracji zdalnych to istotna zmiana — serwery można aktywować przez enabled: true bez konieczności edytowania plików lokalnie.

    Poprawki, które bolą mniej

    Poprawki, które bolą mniej

    W tej aktualizacji wprowadzono także kilka poprawek, które eliminują frustrujące problemy. Gemini przestało otrzymywać przestarzałe domyślne wartości samplingu, co rozwiązało problemy ze schematami narzędzi. Modele z filtrowaniem treści, które wcześniej mogły przerywać odpowiedzi, teraz działają przewidywalnie.

    Dodatkowo, zoptymalizowano obsługę dużych repozytoriów Git. Cache gałęzi nie psuje się już przy odświeżaniu pojedynczej referencji, co przyspiesza przełączanie kontekstu w monorepozytoriach.

    Co to znaczy dla codziennej pracy

    OpenCode wyraźnie stawia na ekosystem, a nie na monolit. MCP przestało być jedynie ciekawostką — staje się domyślnym kanałem do łączenia z zewnętrznymi narzędziami. Użytkownicy OpenCode powinni sprawdzić, czy ich serwery MCP wymagają aktualizacji konfiguracji, szczególnie jeśli korzystają z OAuth lub pracują z dużymi repozytoriami.

    Zmiany w API v2 sugerują, że w przyszłości pojawią się kolejne ułatwienia dla osób automatyzujących pracę z asystentem, co może wpłynąć na sposób, w jaki zespoły integrują AI w swoje procesy CI/CD.

    Źródła

  • OpenCode z lepszą integracją MCP – ścieżki względne i nowe API v2

    OpenCode z lepszą integracją MCP – ścieżki względne i nowe API v2

    Najnowsza aktualizacja OpenCode wprowadza istotne ulepszenia w integracji z serwerami MCP, rozszerza API v2 o nowe końcówki do zarządzania sesjami oraz optymalizuje obsługę obiektów Git w dużych repozytoriach. Choć na pierwszy rzut oka zmiany mogą wydawać się technicznymi porządkami, w praktyce znacząco wpływają na codzienną pracę z narzędziem.

    Kluczowe zmiany w skrócie

    • Wsparcie dla ścieżek względnych w konfiguracji MCP – katalog roboczy podąża za workspace, eliminując potrzebę stosowania sztywnych ścieżek bezwzględnych
    • Nowe końcówki API v2 do zarządzania sesjami, co ułatwia kontrolę nad aktywnymi połączeniami
    • Optymalizacja Git dla dużych repozytoriów – szybsze operacje na rozbudowanych historiach commitów
    • Poprawki błędów w schematach narzędzi Gemini, widoczności filtrowanych odpowiedzi oraz niezawodności uwierzytelniania
    • Lepsze logowanie MCP – błędy z połączeń SSE nie prowadzą już do pętli reconnectu, a logi serwerów są bardziej przejrzyste

    Ścieżki względne w MCP – koniec z absolutnymi zależnościami

    Dotychczas konfiguracja lokalnych serwerów MCP w OpenCode wymagała podawania bezwzględnych ścieżek do katalogu roboczego. Oznaczało to, że przeniesienie projektu między maszynami lub współpraca w zespole z różnymi strukturami folderów wiązała się z koniecznością ręcznego poprawiania konfiguracji.

    Teraz opcja cwd akceptuje ścieżki względne, które są rozwiązywane względem głównego katalogu workspace. Dla zespołów pracujących w monorepo to duża oszczędność czasu – serwer MCP skonfigurowany raz działa identycznie w każdym środowisku, niezależnie od lokalizacji projektu na dysku. Wystarczy umieścić konfigurację w repozytorium, a po klonowaniu wszystko działa od razu.

    Co ważne, zmiana dotyczy nie tylko nowych instalacji. OpenCode zachowuje również kompatybilność ze starszymi klientami SDK MCP, co umożliwia zespołom na różnych wersjach narzędzia współpracę bez konfliktów.

    API v2 i zarządzanie sesjami

    Rozszerzenie API v2 o końcówki sesji to odpowiedź na bardziej zaawansowane scenariusze, w których OpenCode działa jako usługa w tle, a nie tylko jako interaktywne narzędzie CLI. Nowe endpointy umożliwiają programowe tworzenie, odpytywanie i zamykanie sesji, co otwiera możliwości budowania własnych integracji oraz dashboardów monitorujących pracę agentów.

    Dla zespołów DevOps oznacza to możliwość tworzenia dedykowanych sesji na żądanie – na przykład w kontekście CI/CD, gdzie agent analizuje różnice przed scaleniem i raportuje potencjalne problemy. Sesje można teraz kontrolować przez API, co eliminuje potrzebę ingerencji w procesy systemowe.

    Jednocześnie poprawiono kilka uciążliwych błędów – uwierzytelnianie OAuth dla serwerów MCP przestało gubić stan przy odświeżaniu tokenów, a odpowiedzi filtrowane przez content safety Gemini nie znikają już bez śladu. Wcześniej użytkownik otrzymywał pusty ekran, teraz OpenCode informuje, że odpowiedź została zablokowana.

    Git i duże repozytoria

    Optymalizacja obsługi obiektów Git to zmiana, która z pewnością ucieszy osoby pracujące z rozbudowanymi historiami. OpenCode poprawił sposób cache'owania branchy, eliminując sytuacje, w których odświeżenie jednej referencji przypadkowo przesuwało checkout innego brancha. Choć może to brzmieć skomplikowanie, w repozytoriach z tysiącami commitów i wieloma równoległymi gałęziami przekłada się to na zauważalnie szybsze przełączanie kontekstu.

    Dodatkowo poprawiono indeksowanie wyników grep – ścieżki symlinków są teraz poprawnie zachowywane, co ma znaczenie w projektach korzystających z linków symbolicznych do współdzielonych bibliotek.

    Te zmiany pokazują, że narzędzie rozwija się z etapu "ciekawego eksperymentu" w kierunku dojrzałego środowiska pracy. Wsparcie dla ścieżek względnych w MCP oraz nowe API sesji to funkcje, które mogą zdecydować o długoterminowym przywiązaniu zespołu do tego narzędzia.

    Źródła

  • Anthropic wycofuje Claude Opus 4.1 i zmienia zasady rozliczania odmów w API

    Anthropic wycofuje Claude Opus 4.1 i zmienia zasady rozliczania odmów w API

    Anthropic ogłosiło 5 czerwca 2026 roku, że model Claude Opus 4.1 zostanie wycofany. Deweloperzy mają 60 dni na migrację, ponieważ po 5 sierpnia API przestanie przyjmować zapytania kierowane do claude-opus-4-1-20250805. W tym samym czasie wprowadzane są dwie zmiany techniczne: narzędzie doradcze zyskuje kontrolę nad tokenami, a puste odmowy nie będą generować kosztów.

    Kluczowe fakty o aktualizacji

    • Claude Opus 4.1 zostanie wycofany 5 sierpnia 2026 — oficjalnym następcą jest Claude Opus 4.8.
    • Parametr max_tokens w narzędziu doradczym umożliwia kontrolę opóźnień i kosztów.
    • Odmowy bez wygenerowanej treści nie będą już naliczane na fakturach.
    • 60 dni na migrację — po tym terminie zapytania do starego modelu zwrócą błędy.
    • Nowy tokenizer w Claude Sonnet 5 generuje około 30% więcej tokenów dla tych samych tekstów.

    Co dokładnie się zmienia z Claude Opus 4.1

    Model o identyfikatorze claude-opus-4-1-20250805 został wprowadzony do API jako ulepszenie względem podstawowego Opus 4. Anthropic kieruje wszystkich użytkowników do Claude Opus 4.8, który oferuje ten sam poziom wydajności przy niższych kosztach operacyjnych. Deweloperzy korzystający ze starszych wersji SDK lub zahardcodowanych konfiguracji powinni sprawdzić, czy ich aplikacje, agenci i zadania backendowe nie polegają na wycofywanym modelu.

    Termin migracji wynosi dwa miesiące, co może być niewystarczające, szczególnie gdy zmiana wymaga testowania promptów i potencjalnego dostosowania logiki aplikacji. 60 dni może wystarczyć na prostą podmianę identyfikatora, ale osoby z rozbudowanymi pipeline'ami ewaluacyjnymi powinny rozpocząć migrację jak najszybciej.

    Narzędzie doradcze z kontrolą tokenów

    Nowy parametr max_tokens w narzędziu doradczym to praktyczna zmiana. Deweloperzy mogą teraz ograniczyć maksymalną liczbę tokenów generowanych przez doradcę, co przekłada się na szybsze odpowiedzi i niższe rachunki.

    Na przykład, jeśli doradca analizuje długi dokument, ale potrzebujesz tylko krótkiej rekomendacji, możesz ustawić max_tokens na 500 i nie płacić za rozbudowaną analizę, której nie potrzebujesz. To proste, ale wcześniej brakowało tej opcji.

    Odmowy bez opłat — zmiana polityki rozliczeniowej

    To aktualizacja, która nie jest szeroko komentowana w release notes, ale ma realny wpływ na budżet. Dotychczas każde zapytanie kończące się statusem refusal, czyli sytuacja, gdy Claude odmawia odpowiedzi ze względów bezpieczeństwa, było normalnie naliczane, nawet jeśli model nie wygenerował żadnego tokena treści.

    Od teraz Anthropic nie pobiera opłat za zapytania, które kończą się odmową i nie produkują żadnego outputu. Dla aplikacji z dużą liczbą zapytań granicznych, takich jak systemy moderacji treści czy agenci działający na wrażliwych danych, może to oznaczać zauważalne oszczędności.

    Szerszy kontekst: Claude Sonnet 5 i zmiany w tokenizacji

    Warto również zauważyć, że Anthropic uruchomiło Claude Sonnet 5 z nowym tokenizerem, który produkuje około 30% więcej tokenów dla identycznych tekstów. To istotna informacja dla osób migrujących między modelami i porównujących koszty — ten sam prompt może nagle kosztować więcej z powodu zmiany w zliczaniu tokenów, a nie samej ceny za token.

    Claude Opus 5 zadebiutował w lipcu 2026, zastępując Opus 4.8 jako flagowy model. Wprowadził domyślnie włączone myślenie i kontekst miliona tokenów, ale to Opus 4.8 pozostaje zalecanym celem migracji dla użytkowników wycofywanego Claude Opus 4.1.

    Migracja od strony technicznej

    Jeśli korzystasz z oficjalnych SDK (Python, TypeScript, Go, Java), podmiana identyfikatora modelu na claude-opus-4-8 powinna wystarczyć. Jednak w przypadku aplikacji, które polegają na konkretnych zachowaniach modelu, warto przetestować prompty przed wdrożeniem.

    Należy również przejrzeć konfiguracje agentów Claude Managed Agents, jeśli któryś z nich wskazuje na claude-opus-4-1-20250805. To samo dotyczy skryptów automatyzacji i pipeline'ów CI/CD, gdzie identyfikatory modeli często lądują w zmiennych środowiskowych i łatwo o nich zapomnieć podczas rutynowej aktualizacji.

    Źródła

  • OpenCode zyskuje kontrolę nad dostawcami AI i odświeżony interfejs pulpitu

    OpenCode zyskuje kontrolę nad dostawcami AI i odświeżony interfejs pulpitu

    Zespół OpenCode wprowadził 27 maja 2026 roku aktualizację v1.15.11, która obejmuje Desktop v2 oraz zmiany w konfiguracji dostawców i stabilności systemu. Narzędzie to, które w czerwcu zdobyło ponad 160 tysięcy gwiazdek na GitHubie, obsługuje 2,5 miliona deweloperów miesięcznie.

    Co nowego w aktualizacji

    • headerTimeout umożliwia programistom kontrolowanie czasu oczekiwania na żądania do zewnętrznych dostawców, co zapobiega zawieszaniu się zapytań przy niestabilnych połączeniach API.
    • Desktop v2 wprowadza nowy ekran startowy, kontrolki sesji w pasku tytułowym oraz obsługę gestów pinch-zoom.
    • Agentowe push notifications eliminują potrzebę ciągłego sprawdzania statusu — agenci sami wysyłają aktualizacje podczas pracy.
    • Bezpośrednie tokeny OAuth dla DigitalOcean upraszczają proces uwierzytelniania, eliminując zbędne pośredniki.

    Więcej kontroli nad tym, jak agent działa

    Nowy parametr headerTimeout odpowiada na problem, gdy połączenie z API dostawcy jest niestabilne, co może prowadzić do zawieszania się zapytań. Teraz można to kontrolować na poziomie konfiguracji każdego dostawcy.

    Wprowadzono również elastyczne ustawienia modalności, które pozwalają na dostosowanie sposobu, w jaki agent obsługuje różne typy wejścia i wyjścia — tekst, komendy shella, bloki kodu. Umożliwia to dostosowanie poziomu dostępu do potrzeb konkretnego projektu.

    Nowością, która może znacząco wpłynąć na codzienną pracę, są agenci działający w trybie push. Dotychczas użytkownicy musieli stale sprawdzać, czy agent zakończył zadanie. Teraz to agent informuje o postępach, co oszczędza czas i zmniejsza potrzebę przełączania kontekstu dla zespołów korzystających z OpenCode.

    Interfejs, który nie przeszkadza

    Desktop v2 to nie tylko zmiany wizualne. Nowy ekran startowy ułatwia szybkie rozpoczęcie sesji, a kontrolki w pasku tytułowym pozwalają na łatwe przełączanie się między zadaniami. Funkcja pinch-zoom w aplikacji desktopowej, choć może wydawać się zbędna, znacząco poprawia przeglądanie większych diffów czy diagramów.

    Terminalowy interfejs również przeszedł poprawki, które zwiększają czytelność i szybkość reakcji. Dla użytkowników preferujących pracę z klawiaturą, te zmiany są istotne.

    Zespół zadbał również o poprawę obsługi serwerów MCP. Mniej awarii i czystsze zamykanie połączeń to detale, które mogą decydować o tym, czy narzędzie nadaje się do produkcyjnego użytku.

    Gdzie OpenCode pasuje w ekosystemie

    OpenCode pozostaje neutralne wobec modeli, obsługując ponad 75 dostawców — od Anthropic Claude i OpenAI, przez Google Gemini i DeepSeek, po lokalne modele przez Ollamę. Ta różnorodność stanowi istotną przewagę nad narzędziami takimi jak Claude Code czy Codex, co jest ważne dla zespołów, które nie chcą być uzależnione od jednego dostawcy.

    Jednak ta elastyczność ma swoją cenę. Benchmarki pokazują, że OpenCode działa około 78% wolniej niż Claude Code na tym samym modelu. Przyczyną jest użycie "uprzęży agenta", która dodaje warstwę abstrakcji między kodem a API. To rozwiązanie może nie być odpowiednie dla tych, którzy potrzebują maksymalnej wydajności.

    Mimo to, rosnąca liczba użytkowników jest wymowna. Część migracji jest efektem decyzji Anthropic o ograniczeniu zewnętrznego dostępu do swoich modeli. Gdy dostęp do Claude'a jest ograniczony, uniwersalny adapter, jak OpenCode, staje się niezbędny.

    Instalacja i konfiguracja

    OpenCode można zainstalować standardowo — przez npm lub homebrew:

    npm install -g opencode-ai

    lub:

    brew install opencode

    Konfiguracja opiera się na plikach JSON umieszczanych w różnych lokalizacjach: globalnie w ~/.config/opencode/, projektowo w katalogu repozytorium lub przez zmienne środowiskowe. System łączy warstwy konfiguracji zamiast je nadpisywać, co daje elastyczność, ale wymaga zrozumienia priorytetów.

    Poprawki i stabilność

    Aktualizacja rozwiązuje także kilka problemów. Naprawiono błędy związane z wywoływaniem narzędzi, synchronizacją sesji i raportowaniem błędów. Mniej irytujących przerwań oznacza więcej czasu na pracę z kodem. Choć szczegóły mogą nie być widoczne w changelogu, to właśnie one decydują o tym, czy narzędzie staje się częścią codziennego workflow, czy ląduje w folderze "do sprawdzenia".

    Źródła

  • OpenCode v1.14.46: wbudowana umiejętność zapobiega błędom startowym i zwiększa stabilność API

    OpenCode v1.14.46: wbudowana umiejętność zapobiega błędom startowym i zwiększa stabilność API

    Zespół OpenCode opublikował wersję v1.14.46, która jest stabilizacyjną aktualizacją. Wprowadza nową umiejętność customize-opencode oraz naprawia kilka krytycznych błędów w API i narzędziach MCP. Zmiany mają na celu poprawienie edytowania konfiguracji, eliminując problemy z awariami przy uruchamianiu, co zwiększa przewidywalność całego środowiska deweloperskiego.

    Kluczowe informacje

    • customize-opencode – nowa umiejętność, która zmniejsza ryzyko awarii startowych po edycji plików konfiguracyjnych.
    • Poprawki HTTP API – naprawiono obsługę numerycznych parametrów zapytań, co zwiększa niezawodność klientów wysyłających wystandaryzowane zapytania.
    • Wzmocnione bezpieczeństwo Plan Mode – podagenci działający w trybie planowania otrzymali dodatkowe zabezpieczenia izolacji.
    • Lepsza stabilność sesji i narzędzi – rozwiązano problemy z ładowaniem starszych danych sesji oraz z wykrywaniem narzędzi MCP.
    • Wyrównanie typów SDK – poprawiono zgodność typów między klientami a działaniem w czasie wykonania, co redukuje potencjalne błędy integracyjne.

    Więcej niż tylko kosmetyka – co dokładnie zmieniono

    OpenCode to otwartoźródłowy agent kodowania AI, który działa w terminalu, IDE i aplikacji desktopowej. Szybkie tempo rozwoju sprawia, że każda aktualizacja może wprowadzać drobne usterki. Wersja v1.14.46 koncentruje się na ich eliminacji.

    Najważniejszą nowością jest umiejętność customize-opencode. Dodano ją, aby edytowanie konfiguracji opencode rzadziej prowadziło do przerwania startu. Oznacza to, że agent będzie lepiej obsługiwał niepoprawne lub niepełne ustawienia, podejmując próbę naprawy kontekstu konfiguracyjnego zamiast odmawiać uruchomienia.

    Równolegle rozwiązano problem z numerycznymi parametrami w zapytaniach HTTP API. Gdy klient przesyłał parametr jako liczbę (np. limit=10), niektóre ścieżki API interpretowały go błędnie. Teraz to już nie powinno się zdarzać, co jest szczególnie ważne dla osób integrujących OpenCode z własnymi narzędziami lub zewnętrznymi platformami.

    Bezpieczeństwo podagentów i odtwarzanie sesji

    Tryb Plan Mode pozwala agentom rozkładać złożone zadania na mniejsze kroki wykonywane przez podagentów. W wersji v1.14.46 wzmocniono ich bezpieczeństwo, wprowadzając zmiany dotyczące granic wykonawczych i izolacji. Szczegóły techniczne nie zostały szerzej rozwinięte w notatkach, ale wiadomo, że poprawiono mechanizmy odpowiedzialne za odtwarzanie stanu po długich sesjach. Problemy z ładowaniem starszych danych sesji mogły zakłócać ciągłość pracy, szczególnie gdy projekt był otwierany po przerwie.

    Dodatkowo naprawiono wykrywanie narzędzi MCP (Model Context Protocol). Jeśli serwer MCP nie zgłaszał narzędzi poprawnie, agent mógł ich nie widzieć. Po aktualizacji skanowanie narzędzi działa stabilniej, a problemy z ich dostępnością powinny zniknąć.

    Dlaczego to istotne dla „vibe coding” i codziennej pracy

    OpenCode stał się poważnym konkurentem wśród terminalowych asystentów AI, szczególnie w środowiskach, gdzie liczy się szybkie prototypowanie i tzw. vibe coding, czyli tworzenie w luźnym, eksperymentalnym tempie. Każda awaria przy starcie może wybić z rytmu na dłużej. Dlatego poprawki konfiguracyjne i te związane z sesjami są niezwykle istotne.

    Wersja v1.14.46 wpisuje się w szerszy trend szybkich iteracji. W poprzednich wydaniach OpenCode wprowadzono m.in. wsparcie dla WebSocketów OpenAI, ograniczenia kroków agenta oraz ulepszone wyszukiwanie plików. Teraz przyszła kolej na solidność, co jest dobrą wiadomością dla każdego, kto nie chce martwić się o to, czy konfiguracyjny eksperyment wywoła awarię.

    Choć zmiany nie są spektakularne, ich suma zdecydowanie podnosi komfort codziennego użytkowania. Otwarte źródło i aktywna społeczność gwarantują, że kolejne wydania będą dalej wygładzać kanty – v1.14.46 jest tego dobrym przykładem.

    Źródła