Najbardziej użyteczna dyskusja tygodnia o AI coding agents nie dotyczyła tego, który agent wydaje się mądrzejszy. Dotyczyła tego, co agent wysyła do modelu, zanim w ogóle przeczyta zadanie.

Abstrakcyjny panel agenta kodującego z licznikiem tokenów i wskaźnikiem budżetu

12 lipca Systima opublikowała pomiar Claude Code i OpenCode na granicy API. Liczba, która się rozeszła, była prosta: w trywialnym zadaniu z odpowiedzią dokładnie "OK" Systima zmierzyła około 32,800 first-turn tokens dla Claude Code i około 6,900 dla OpenCode. Do 14 lipca wątek na Hacker News miał około 687 points i 378 comments.

To nie była tylko wojna fanów narzędzi. Post trafił w realny problem. AI coding agents są już dość użyteczne, by wejść do codziennej pracy, ale ich koszt i zachowanie nadal trudno zobaczyć. Prompt developera to tylko część rachunku. Harness dodaje system instructions, tool schemas, repository instructions, opisy MCP servers, reminders, subagent plans, cache writes i historię rozmowy.

Praktyczne pytanie nie brzmi "Claude Code zły, OpenCode dobry". Wyniki Systimy są bardziej zniuansowane. Pytanie brzmi, czy zespół widzi, co jego agent stack wysyła, po co to wysyła i czy jakość uzasadnia token load.

Co zmierzyła Systima

Systima twierdzi, że wstawiła logging proxy między coding harness i model endpoint, a następnie porównała Claude Code 2.1.207 oraz OpenCode 1.17.18 na tej samej maszynie, zadaniach i rodzinie modeli. Badanie obejmowało floor task, one-tool task i multi-step write-run-test-fix task.

Najgłośniejszy był floor task. Prosił agenta o odpowiedź dokładnie "OK". W tej konfiguracji Systima zmierzyła około 33k tokens u Claude Code przed sensowną pracą i około 7k u OpenCode.

Według payloads przyczyną nie był user prompt. Był nią wrapper. Systima mówi, że baseline napędzały głównie tool schemas: Claude Code wystawiał 27 tools i około 99,778 characters of tool schemas, a OpenCode 10 tools i około 20,856 characters. Nawet bez tools system prompt Claude Code miał około 26,891 characters, czyli 6.5k tokens, wobec 8,811 characters i około 2k tokens w OpenCode.

To ukryty podatek agent interfaces. W terminalu wygląda jak jedna komenda. Pod spodem agent może wysyłać do modelu mały podręcznik w każdym turn.

Mniejsze nie zawsze znaczy lepsze

Lekki baseline jest atrakcyjny. Kosztuje mniej, zajmuje mniej context window i zwykle zmniejsza latency. Ale Systima znalazła też przypadek, w którym cięższy harness Claude Code nie przegrał wyraźnie.

W multi-step task Claude Code zbatchował kilka tool calls w mniejszą liczbę model requests. OpenCode robił więcej one-tool-per-turn calls. Ponieważ baseline płaci się ponownie przy requests, mniej requests może częściowo zrekompensować większy baseline. W tym konkretnym Sonnet run Systima zmierzyła około 121k cumulative metered input tokens dla Claude Code i około 132k dla OpenCode.

Ta uwaga jest ważna. Narzędzie z ciężkim startem może być efektywne, jeśli rozwiązuje zadanie w mniejszej liczbie turns. Lekkie narzędzie może być drogie, jeśli za bardzo serializuje. Token cost trzeba mierzyć per useful task, nie tylko per first request.

Komentarze na Hacker News pytały też o metodologię: Meridian gateway, pinned model version, wpływ gateway envelope i to, czy toggles jak extended thinking przeszły przez cały path. Systima przyznała część caveats, a Fable reruns zmieniły część obrazu.

Uczciwy wniosek jest węższy niż viral headline: harness overhead może być ogromny i zależny od narzędzia. Nie dowodzi to, że jeden agent zawsze jest tańszy od drugiego.

Dlaczego zespoły nagle liczą token overhead

Dla developera overhead objawia się szybkim zużyciem subskrypcji, wolniejszą sesją albo context, który kończy się szybciej niż oczekiwano. Dla firmy to budżet.

Dokumentacja kosztów Claude Code mówi wprost: Claude Code charges by API token consumption, a per-developer costs vary widely by model selection, codebase size and usage patterns such as multiple instances or automation. Docs zalecają pilot groups, usage tracking, spend limits, org analytics, OpenTelemetry and gateway-based metrics.

Anthropic podaje orientacyjne wartości enterprise: average cost around $13 per developer per active day and $150-250 per developer per month, with 90 percent of users below $30 per active day. To może być rozsądne. Ale średnie ukrywają outliers.

Forbes opisał niedawno token spend jako nową metrykę zarządczą po fazie "tokenmaxxing". Cykl znamy z infrastruktury cloud: entuzjazm adopcji, potem faktura, potem governance.

AI coding agents są właśnie w tej drugiej fazie.

Skąd bierze się ukryty koszt

Widoczny user prompt zwykle nie jest najdroższy. Kosztowne są elementy strukturalne.

Najpierw tool schemas. Każde exposed tool ma name, description i parameter schema. Jeśli harness pokazuje file operations, search, shell, browser, planning, task management and MCP tools, model dostaje duże menu przed właściwym zadaniem. To może poprawiać autonomy. Zjada też context i pieniądze.

Potem project instructions. Duży AGENTS.md lub CLAUDE.md jest wartościowy, jeśli zawiera realne repo rules. Może też stać się śmietnikiem starych preferences, powtarzanych warnings i vague style advice. Systima zmierzyła, że realny 72KB instruction file dodawał trochę ponad 20k tokens per request.

MCP servers dodają własny tax. Każdy server wnosi tool descriptions and schemas. Systima mierzyła około 1,000-1,400 tokens per small public MCP server, per request. Production servers z bogatymi APIs mogą być znacznie większe.

Subagents mnożą problem. Jeśli orchestrator uruchamia kilka agents, a każdy dostaje ten sam ciężki zestaw repository instructions, tools and conversation setup, zespół może płacić baseline wiele razy przed pierwszą poprawą kodu.

Rośnie też conversation history. Długa sesja zużywa coraz więcej context na scaffolding i old state. Cache discounts pomagają billingowi, ale nie usuwają context window consumption.

Co mierzyć przed sporem o narzędzia

Praktyczny rollout zaczyna się od pomiaru na boundary. Jeśli nie widzisz payload size, cache writes, cache reads, output tokens and request count, spierasz się głównie o wrażenia.

Oddziel model cost od harness cost. Premium model to jedna decyzja. Heavy wrapper to druga. Zespół powinien wiedzieć, czy rachunek pochodzi z reasoning, tool schemas, repeated instruction files, MCP metadata, subagent fan-out czy po prostu too many model turns.

Mierz per task, nie tylko per session. Refactor za 300k tokens może być opłacalny, jeśli zastąpi dwie godziny senior engineer work. Tiny rename za 80k tokens, bo agent załadował wszystkie tools and instructions, raczej nie.

Mierz by project and repository. Niektóre repos naprawdę potrzebują heavy context. Inne mają bloated instructions, bo nikt ich nie sprzątał. Różnica powinna być widoczna.

Mierz by agent mode. Planning, implementation, test repair, code review, dependency updates and documentation work mają różne token profiles. Wysyłanie każdej pracy do tego samego drogiego setupu to jak uruchamianie każdego cron job na największej instancji cloud.

Prompt rules nie zastąpią procesu

Jeden z wątków HN trafił w praktyczny punkt: jeśli napiszesz agentowi w prompt, by zawsze uruchamiał testy, może wielokrotnie wydawać tokens na rozumowanie o test policy i szerokie checks. Czasem to działa. Często powinno być w hooks, CI albo task-specific scripts.

To samo dotyczy style rules, security checks and release steps. Jeśli reguła jest deterministyczna, włóż ją tam, gdzie software wymusi ją tanio. Pre-commit hooks, pre-push hooks, CI jobs and repository scripts są nudne, ale zmniejszają potrzebę, by model pamiętał i reinterpretował tę samą politykę w każdym turn.

Instructions są do judgment. Automation jest do repetition.

Wtedy agent skupia się na tym, gdzie language and reasoning są potrzebne: zrozumieć change, wybrać approach, przejść przez codebase, wyjaśnić trade-offs i naprawić failures, które nie wynikają ze statycznej reguły.

Jak kontrolować koszt bez zabijania adopcji

Zła reakcja to zakazać mocnych agents, bo jeden benchmark wygląda drogo. Druga zła reakcja to dać wszystkim unlimited access i liczyć, że invoice będzie jak demo.

Zdrowszy rollout wygląda jak FinOps for AI development.

Zacznij od pilot group. Mierz prawdziwą pracę, nie toy prompts. Włącz small fixes, code review, test repair, migrations and multi-file changes. Porównuj token spend z outcomes: time saved, bugs caught, PR cycle time and developer satisfaction.

Ustaw budgets and alerts. Developer powinien wiedzieć, gdy session pali context or subscription limits. Managers powinni widzieć per-project and per-team trends bez zmiany token tracking w surveillance theater.

Route tasks. Używaj najlepszego modelu tam, gdzie trzeba. Tańsze modele lub mniejsze harnesses pasują do routine edits, explanation, formatting and search-heavy chores. Jeśli agent ma subagents, powinny umieć step down to cheaper models przy wąskich zadaniach.

Audit instruction files. Usuń stale rules. Podziel giant instructions into smaller skills or task-specific guidance, jeśli harness to wspiera. Repository instructions powinny być concise and testable.

Audit MCP servers. Nie podłączaj every server to every session by default. Database schema tool, browser tool, ticket tracker i cloud admin tool są wartościowe, ale nie każde musi być w każdym coding prompt.

Watch cache behavior. Cache writes, cache reads and context window use to różne rzeczy. Discounted cache read nadal może zapełnić context.

To wykracza poza coding

Coding agents po prostu najwcześniej pokazują problem. Ten sam wzorzec pojawi się w sales agents, legal research agents, support automation, data analysis agents and internal operations bots.

Każdy agent framework ma overhead: role instructions, tool schemas, memory, policies, examples, retrieved context and conversation history. Część poprawia reliability. Część to cargo cult. Bez observability zespół nie odróżni jednego od drugiego.

Rynek przechodzi od "give the model more context" do "prove the context is worth sending". To dobry ruch. Nie czyni agents mniej użytecznymi. Czyni je bardziej infrastrukturą.

Praktyczna lekcja

Post Systimy stał się viral, bo nazwał koszt, który wiele osób czuło, ale którego nie widziało. 33k tokens before prompt to dramatyczny przykład. Lekcja jest szersza: AI agents mają bill of materials.

Wchodzą w niego model, harness, tools, instruction files, servers, subagents and organizational habits. Jeśli drogi agent daje lepszy outcome, używaj go. Jeśli pali tokens na scaffolding, którego nikt nie rozumie, napraw scaffolding.

Następna dojrzała faza AI Practice to nie mniej AI. To measurable AI. Zespoły powinny umieć odpowiedzieć: co agent wysłał, ile to kosztowało, co zrobił i która część stack naprawdę dała efekt?