GitHub uruchamia setki agentycznych workflowów w swoich repozytoriach - automatyczny triage, sprawdzanie jakości kompilatora, audyty bezpieczeństwa. Każdy wywołuje LLM. Każde wywołanie LLM wysyła do API pełny schemat narzędzi MCP. Serwer MCP GitHuba z 40 narzędziami dodaje 10-15 KB JSON schematu per turę - niezależnie od tego, czy workflow używa 2 narzędzi, czy 40.

Nikt na to nie patrzył, dopóki GitHub nie zbudował AI-auditora.

Dane wyjściowe

W lutym 2026 infrastruktura agentycznych workflowów GitHuba skonsumowała 215 998 387 tokenów w 30 dniach w 333 uruchomieniach 49 unikalnych workflowów. Szacowany koszt po wewnętrznych cenach GitHuba: 21,60 USD. Po cenach detalicznych Sonneta byłoby znacznie więcej.

Wpis, przygotowany przez Microsoft Research i inżynierów GitHuba, wprowadza metrykę Effective Token (ET) do normalizacji między tierami modeli:

ET = m × (1,0 × I + 0,1 × C + 4,0 × O)

Gdzie I = tokeny wejściowe, C = tokeny odczytane z cache (tańsze), O = tokeny wyjściowe (najdroższe), a m = mnożnik kosztu modelu (Haiku = 0,25x, Sonnet = 1,0x, Opus = 5,0x). Bez tej normalizacji przejście z Sonneta na Haiku sprawia, że liczby tokenów wyglądają podobnie, a rzeczywisty koszt spada czterokrotnie.

Trzy techniki

1. Przytnij nieużywane narzędzia MCP. Najłatwiejsza ścieżka dla autorów workflowów to konfiguracja pełnego zestawu narzędzi i pozostawienie agentowi decyzji. Workflow, który wywoływał tylko get_pull_request i create_comment, wciąż nosił schematy 38 pozostałych narzędzi w każdym wywołaniu API. Po porównaniu manifestów narzędzi z logami rzeczywistych wywołań i usunięciu nieużywanych, workflow Auto-Triage Issues zmniejszył kontekst o 8-12 KB per wywołanie. Wynik: -62% ET w 109 uruchomieniach po poprawce.

Skrajny przypadek: workflow Glossary Maintainer wywołał search_repositories 342 razy w jednym uruchomieniu - 58% wszystkich wywołań narzędzi - mimo że nigdy tego narzędzia nie potrzebował. Było domyślnie w konfiguracji.

2. Zastąp wywołania MCP pobieraniem danych przed startem agenta. Wywołanie narzędzia MCP to krok rozumowania LLM plus pełne wywołanie API z narzutem schematu. Polecenie gh pr diff to deterministyczne żądanie HTTP. Tam, gdzie agent potrzebuje tylko danych - nie rozumowania - należy uruchomić polecenia gh przed startem agenta i zapisać wyniki do plików workspace. Agent czyta pliki zamiast wywoływać narzędzia.

Smoke Claude z samym przycinaniem narzędzi osiągnął -59% ET. Dodanie przełączenia modelu z Sonneta na Haiku (przy zachowaniu identycznego zachowania) dało -79% ET.

3. Wychwytuj anomalie za pomocą auditora. Daily Token Usage Auditor czyta artefakty z logami z ostatnich uruchomień, agreguje per workflow i oznacza anomalie - workflowy ze znacznie zwiększonym zużyciem lub liczbą tur poza normalnym zakresem. Workflow Daily Syntax Error Quality był rekordzistą ET przed optymalizacją. Powód: jednoliniowa błędna konfiguracja w allowliście bash wymusiła na agencie pętlę 64 tur - agent czytał ręcznie kod źródłowy zamiast wywołać kompilator. Jedna zmiana konfiguracji ją wyeliminowała.

Co można przenieść do własnych workflowów

Techniki są niezależne od frameworku. Wpis dokumentuje Claude CLI, Copilot CLI i Codex CLI uruchomione przez tę samą warstwę instrumentacji. Oba repozytoria - gh-aw i gh-aw-firewall - są publiczne, a audyt tokenów można dodać do dowolnego repozytorium:

gh extensions install github/gh-aw
gh aw add githubnext/agentic-ops/copilot-token-audit

Uczciwa uwaga autorów: sygnały jakości (liczba tur, wskaźnik ukończenia) pozostały stabilne. Ale nie można bezpośrednio zmierzyć, czy optymalizacja nie pogorszyła jakości wyników - nie ma wzorcowej "poprawności" dla "czy ten PR był dobrze obsłużony." Workflow Contribution Check pokazał nawet wzrost ET o 5% po optymalizacji - bo w tym okresie 65% PR było dużych, wobec 39% wcześniej. Zmienność obciążenia maskuje realne zmiany w obu kierunkach.