Claude Code vs Codex CLI vs OpenCode - który wybrać w 2026

Trzy miesiące temu dorzuciłem Codex CLI obok Claude Code i przez tydzień próbowałem dawać mu zadania, które wcześniej dostawał Claude. Wyciągnąłem trzy wnioski, które kosztowały mnie 40$ na API i kilka godzin sprzątania po halucynacjach modelu. Potem doszedł OpenCode - open-source projekt, który w marcu 2026 wskoczył na #1 Hacker Newsa i ma już 147 tysięcy gwiazdek na GitHubie. Postanowiłem zrobić uczciwy benchmark: ten sam ticket Laravel, trzy agenty, jedno popołudnie.

Pod koniec kwietnia napisałem porównanie Claude Code z IDE-based agentami (Cursor, Windsurf, Copilot). Tamten wpis wybrał kierunek na CLI. Ten idzie głębiej - bo CLI to teraz najszybciej rosnąca kategoria w tooling dla developerów. I trzy nazwy się powtarzają: Claude Code, OpenAI Codex CLI, OpenCode.

Dlaczego CLI agenty wygrały z IDE w pewnych zadaniach

IDE-based agenty (Cursor, Windsurf) są świetne w jednym scenariuszu: edytujesz pojedynczy plik, widzisz kontekst, akceptujesz suggestion. Tab-tab-tab i jest. Ale jak tylko zadanie wychodzi poza pojedynczy plik - migracja, refactor cross-cutting, dodanie modułu z testami - kończy się magia, zaczyna walka z kontekstem.

CLI agenty działają inaczej. Mają plan/execute model: dostają zadanie, planują kroki, wykonują, raportują. Mogą długo trzymać kontekst całego repo, robić commity, odpalać testy, czytać logi. W moim workflow Laravel/Filament to game zmienił. Zamiast siedzieć i klikać po plikach, opisuję ticket w jednym promtcie i sprawdzam wynik. Pisałem o tym szerzej - Claude Code zmienił mi rytm pracy z "klikam i koryguję" na "deleguję i review".

Trzy CLI agenty, które warto rozważyć w 2026 roku, to dokładnie ta trójka. Każdy reprezentuje inną filozofię.

Setup eksperymentu - jeden Laravel, trzy agenty

Wybrałem realny ticket z projektu klienta (admin panel oparty o Filament). Zadanie: dodać resource Filament dla modelu Invoice, z relacjami do Customer i InvoiceItem, walidacją, polityką dostępu i testami feature. Klasyczny CRUD z paroma niuansami - to chleb powszedni, każdy z agentów powinien dać radę.

Mierzyłem cztery rzeczy:

• Czas wallclock - od pierwszego promtu do mergeable PR
• Liczba iteracji - ile razy musiałem korygować lub dopytywać
• Koszt API - ile kosztował przebieg w dolarach
• Jakość kodu - subiektywna ocena 1-10 (idiomatic Laravel, zgodność z konwencjami projektu, testy)

Setup był identyczny: świeży branch z mastera, ten sam prompt (3 paragrafy z kontekstem - model, relacje, wymagania UI, testy), MCP do bazy testowej dostępne w każdym agencie. Środowisko: PHP 8.4, Laravel 12, Filament 4, PostgreSQL 17.

# Claude Code (Anthropic)
brew install claude-code
claude --model claude-opus-4-7

# OpenAI Codex CLI
npm install -g @openai/codex-cli
codex --model gpt-5

# OpenCode (open-source)
brew install opencode
opencode --provider anthropic --model claude-sonnet-4-6

Każdemu dałem ten sam prompt:

Dodaj Filament resource dla modelu Invoice.
Pola: number, customer_id (relacja BelongsTo), issued_at, due_at,
total_net, total_gross, status (draft/sent/paid/overdue).
Relacja HasMany do InvoiceItem (name, qty, unit_price_net, vat_rate).
Walidacja: number unikalny per customer, total_gross >= total_net.
Policy: tylko admin może usuwać, manager może edytować swoje, viewer tylko podgląd.
Testy feature dla każdej akcji policy.
Trzymaj się konwencji z istniejących resource w app/Filament/Resources/.

Claude Code - kontekst i ekosystem

Claude Code uruchomiłem z modelem Claude Opus 4.7 (93.9% SWE-bench Verified - benchmark Anthropic). To mój daily driver, więc nie spodziewałem się niespodzianek - i ich nie było.

Wygenerował plan w 4 krokach: scan istniejących resource'ów, model Eloquent + migracja, Filament resource, policy + testy. Zaczął od czytania app/Filament/Resources/CustomerResource.php żeby trzymać konwencję - tego nie musiałem prosić. Potem zrobił migrację, model, resource z relation managerem dla items, policy i 8 testów feature.

Pierwsza iteracja - zauważyłem, że nie dodał ->required() w InvoiceItem dla name. Druga iteracja - poprawka kolejności kolumn w tabeli. Trzecia - dorzucenie testu na unique constraint number per customer.

Wynik: 14 minut, 3 iteracje, koszt $0.45 (Opus 4.7 jest droższy ale efektywny przez prompt caching), jakość kodu 9/10. Kod był idiomatic Laravel, testy zielone od razu po pierwszej iteracji, struktura zgodna z resztą projektu.

Co robi Claude Code dobrze, a co wykorzystałem w tym tickecie:

• Skills - mam zdefiniowany skill laravel-best-practices, który ładuje się automatycznie. Agent wie jakie konwencje stosujemy w projekcie.
• Hooks - po każdym Edit na pliku PHP odpalam php artisan test --filter. Agent widzi wynik i sam koryguje.
• Plan mode - przed touchingiem kodu agent pokazuje plan, który mogę zaakceptować lub poprawić.
• Agent SDK - mogę spawnować subagentów do równoległych zadań (ten test był single-threaded, ale w większych zadaniach to bardzo używam).
• MCP - mam podpięty serwer MCP do bazy testowej, agent może odpalać query żeby sprawdzić strukturę.

OpenAI Codex CLI - szybko, tanio, mniej dopracowane

Codex CLI Anthropic.. znaczy się OpenAI - otworzył kod w kwietniu 2026. Wcześniej był tylko closed beta, teraz każdy może go zainstalować. Pod spodem GPT-5, który w SWE-bench ma 89.2% (CodeAnt leaderboard) - więc niewiele mniej niż Opus 4.7.

Setup zajął 30 sekund. Login przez OpenAI account (mam Pro plan, więc API był pokryty kreditami). Ten sam prompt.

GPT-5 jest szybki. Naprawdę szybki. Plan wygenerował w 8 sekund, kod leciał po 50-80 tokenów na sekundę. Cały ticket zamknął w 8 minut. Ale pod tą szybkością ukrywa się problem - jakość spada.

Pierwsza iteracja - migracja miała źle nazwane kolumny (invoice_total_net zamiast total_net). Druga - policy używała $user->isAdmin() zamiast $user->hasRole('admin') jak w reszcie projektu. Trzecia - testy padały bo agent zmyślił seedery, których nie ma. Czwarta - factory dla Invoice generowała total_gross < total_net, łamiąc walidację. Piąta - Filament resource używał starej składni Filament 3 zamiast 4.

Po pięciu rundach kod zielony, ale pracy do dopieszczenia jeszcze sporo. Zauważ - Codex nie czytał istniejących resource'ów żeby trzymać konwencję, dopóki go o to nie poprosiłem explicit. Halucynacje były mniejsze niż w GPT-4, ale wciąż drogo kosztowały - znalezienie ich i poprawienie zjadło moje 8 minutowe oszczędzenie czasu.

Wynik: 8 minut wallclock, 5 iteracji, koszt $0.28 (GPT-5 jest mniej więcej 40% tańszy niż Opus), jakość 7/10. Kod działa, ale nie jest tak czysty jak z Claude Code. Konwencje musiałem przypilnować ręcznie.

Co Codex CLI robi dobrze:

• Speed - GPT-5 generuje kod naprawdę szybko, mniej kosztu opóźnienia w iteracjach
• Cena - jeśli masz OpenAI subscription i credity, koszt operacyjny jest niski
• OpenAI ekosystem - integracja z Whisper, DALL-E, Assistants API w jednym CLI
• MCP support - basic ale działa, można podpiąć customowe serwery

Co słabe:

• Mniejsza dyscyplina kontekstu - rzadziej czyta istniejący kod żeby trzymać konwencje
• Mniej skilli/extensions - ekosystem młody, mało gotowych integracji
• Halucynacje - nazwy metod, klasy z innych frameworków, zmyślone seedery. GPT-5 jest lepszy niż 4, ale nie jak Opus 4.7.

OpenCode - free, customizable, multi-provider

OpenCode to projekt community-driven, który w marcu 2026 zdobył #1 na Hacker News i przekroczył 147k gwiazdek na GitHubie (dla porównania - cała organizacja Anthropic ma na public repos mniej). Filozofia: bring your own model. OpenCode jest tylko interfejsem - silnik wybierasz sam.

Można podpiąć: Claude przez API albo Bedrock, GPT-5 przez OpenAI, Gemini, Llama lokalnie przez Ollama, własny endpoint, dowolne. Ten sam interfejs, te same komendy, dowolny model pod spodem.

Do testu podpiąłem Claude Sonnet 4.6 przez AWS Bedrock (mam credity z innego projektu, więc Bedrock wychodzi taniej niż direct API).

opencode config set provider bedrock
opencode config set model claude-sonnet-4-6
opencode config set region eu-central-1
opencode

Plan podobny jak w Claude Code - skanowanie konwencji, migracja, model, resource, policy, testy. Ale bez polotu Opusa. Sonnet 4.6 to dobry model (~91% SWE-bench), ale Opus 4.7 jest lepszy w zadaniach wymagających długiego kontekstu i refleksji.

Pierwsza iteracja - relation manager dla items był OK, ale kolumna vat_rate miała typ integer zamiast decimal(5,2). Druga - test policy używał $this->actingAs() ze złym guard. Trzecia - dorzucenie soft deletes (które są w innych modelach projektu, agent ich nie zauważył). Czwarta - poprawka factory.

OpenCode nie ma niczego takiego jak Claude Code skills. Ma natomiast custom commands - skrypty bash, które można odpalić jako toole. Postawiłem dwa: php-test i php-stan, które agent odpalał po każdym Edit. To trochę jak hooks, tylko ręcznie skonfigurowane.

Wynik: 22 minuty wallclock, 4 iteracje, koszt $0.18 (Sonnet 4.6 przez Bedrock z prompt caching), jakość 8/10. Kod dobry, ale czas wallclock duży - bo Sonnet jest wolniejszy niż GPT-5 i interfejs OpenCode mniej dopracowany (więcej manual review między krokami).

Co OpenCode robi dobrze:

• Free - sam projekt jest darmowy, płacisz tylko za API którego używasz
• Multi-provider - jeden interfejs, dowolny model. Świetne dla teamów które chcą A/B testować modele.
• Open source - możesz zforkować, zmodyfikować, dostosować. Audytować bezpieczeństwo. Self-host bez vendor lock-in.
• Customizable - custom commands, prompty, system prompty - wszystko edytowalne
• Społeczność - 147k gwiazdek znaczy aktywne PR-y, pluginy, integracje

Co słabe:

• Mniej dopracowane - UX-owe drobiazgi w terminalu, nieintuicyjne defaults, breaking changes między wersjami
• Brak skill ekosystemu - jak Claude Code skills, brak. Wszystko trzeba ustawić ręcznie.
• Setup czasochłonny - konfiguracja providera, modelu, hooks, custom commands - to godzina pracy
• Brak managed - jeśli coś nie działa, debugujesz sam. Nie ma supportu Anthropic czy OpenAI.

Wyniki w jednej tabeli

Liczby pokazują tradeoff. Claude Code najdroższy, ale najmniej iteracji i najlepszy kod od razu. Codex najszybszy, ale jakość zmusza do dłuższego review. OpenCode najtańszy, ale wallclock długi i setup żre czas.

Northflank w swoim porównaniu z 2026 doszedł do podobnych wniosków - Claude Code jest "premium tier", Codex "fast and cheap", OpenCode "swiss army knife dla power userów".

Cena vs jakość - ile naprawdę płacisz

Koszt API to nie wszystko. Liczy się też koszt twojego czasu. Jeśli godzina developera kosztuje 200 PLN (~50 USD), to:

• Claude Code - 14 min czasu + $0.45 = ~$12.20 łączny koszt
• Codex CLI - 8 min czasu + 10 min cleanup + $0.28 = ~$15.30
• OpenCode - 22 min czasu + $0.18 = ~$18.50

Czyli najdroższy w API agent jest najtańszy w total cost. Bo czas review jest najkrótszy. To kluczowy insight - patrz na pełny pipeline, nie tylko na bill z API.

Ale to działa tylko dla solo developera. W zespole 5-10 osób wzór się zmienia. Codex może być lepszą opcją (bo szybszy onboarding na nowy framework, prostszy), OpenCode dla seniorów którzy chcą deep customization.

Customization - hooks, skills, commands

Claude Code ma najbogatszy ekosystem customizacji. Skills (markdown z instrukcjami + skrypty), hooks (event-driven scripts po każdej akcji), MCP (servers do integracji z czymkolwiek), Agent SDK (programatic spawning subagentów). Konfiguracja w .claude/ i ~/.claude/ - wszystko w plikach, version-controlowane.

Codex CLI ma minimalne MCP, brak skill systemu, brak event hooks. Customizacja głównie przez --system-prompt i custom toole. Jest młodszy, ekosystem dopiero rośnie.

OpenCode ma custom commands (bash scripts wystawione jako tools), własny config, plugin system. Wszystko bardziej DIY niż Claude Code, ale dla power userów bardziej elastyczne.

W moim workflow Claude Code skills są największą value-prop. Mam skill laravel-best-practices, który ładuje się przy pracy w Laravelu i wstrzykuje konwencje projektu. Mam skill filament-development, który wie o Filament 4. Mam skille per projekt - każdy klient ma swoje. To powtarzalność i niezawodność, których w Codex i OpenCode trzeba szukać przez ręczne prompt engineering.

Multi-provider w OpenCode - flexible setup

Najmocniejsza karta OpenCode to multi-provider. W zespole, gdzie różni developerzy mają różne preferencje (lub różne credity API), jeden interfejs i każdy używa swojego modelu - to ma sens.

# ~/.opencode/config.yaml
profiles:
  - name: cheap
    provider: openai
    model: gpt-5-mini
  - name: quality
    provider: anthropic
    model: claude-opus-4-7
  - name: bedrock
    provider: bedrock
    model: claude-sonnet-4-6
    region: eu-central-1
  - name: local
    provider: ollama
    model: llama-4-70b
    endpoint: http://localhost:11434
default: quality

Switch między profilami: opencode --profile cheap dla quick prototypów, --profile quality dla refactoringu, --profile local jak nie ma neta albo ticket jest poufny. Tego w Claude Code i Codex nie ma - są zamknięte na swojego providera.

Decyzja - co wybrać dla siebie

Po trzech miesiącach przeplatania CLI agentów w codziennej pracy mam jasne preferencje:

Solo developer, daily driver, projekt produkcyjny: Claude Code z Opus 4.7. Płacę więcej, ale dostaję najszybszy total time-to-merge, najmniej halucynacji, najlepszą integrację ze skillami. Mój benchmark to confirm.

OpenAI subscription, dużo szybkich zadań, prototypowanie: Codex CLI z GPT-5. Szybki, tani, dobry do MVP i prototypów. Ale dla produkcji - review-heavy.

Self-host, multi-provider, security-conscious zespół: OpenCode. Open-source dający kontrolę, audit, możliwość użycia lokalnego modelu (np. dla projektów rządowych albo healthcare). Tradeoff: setup time i ręczne customization.

Mieszany zespół 5+ developerów z różnymi preferencjami: OpenCode jako common interface, każdy z własnym providerem. Albo Claude Code dla wszystkich (jeśli budżet pozwala) - bo skills system daje team-wide consistency.

Dla kontekstu - o vibe codingu pisałem osobno. Wszystkie trzy agenty pozwalają popaść w pułapkę "kod działa, więc OK", bez zrozumienia. Niezależnie od narzędzia, review pozostaje twoja praca.

Personalnie - zostaję przy Claude Code. Codex używam jako secondary do quick prototypów (gdy chcę coś szybko sprawdzić bez palenia kreditów Opus). OpenCode trzymam zainstalowane na wypadek pracy z modelem lokalnym albo gdy klient chce self-hosted setup. Trzy agenty, trzy use case'y, brak silver bullet.

Wybierasz CLI coding agent dla zespołu i masz 5+ developerów? Napisz do mnie - przejdziemy razem przez decyzję dopasowaną do waszego stacka.