Jak zmniejszyć koszty Claude Code o 3x dzięki inżynierii kontekstu backendu

Kontrprzykladowy wynik, który zmienił moje podejście

Benchmarki MCPMark V2 ujawniły coś, czego się nie spodziewałem.

Gdy Claude przeszedł z Sonnet 4.5 na Sonnet 4.6, zużycie tokenów backendu przez serwer MCP Supabase wzrosło - z 11.6 miliona do 17.9 miliona tokenów przy 21 zadaniach bazodanowych. Nowy model jest mądrzejszy. Powinien być bardziej efektywny. A jednak rachunek był wyższy.

Na pierwszy rzut oka to nie ma sensu. Bardziej inteligentny model powinien rozwiązywać problemy szybciej, używać mniej iteracji, popełniać mniej błędów. Większa zdolność rozumowania powinna przekładać się na mniejsze zużycie tokenów.

Ale tak się nie dzieje - i rozumienie dlaczego jest kluczem do tego, żeby przestać przepalać pieniądze na sesjach z Claude Code.

Prawdziwy powód: model nie jest problemem

Przyczyna jest subtelna i nie ma nic wspólnego z samym modelem.

Ma wszystko wspólnego z tym, jak backend udostępnia informacje agentowi.

Gdy kontekst jest niekompletny, bardziej zdolny model nie po prostu pomija lukę. On ją eksploruje. Spędza więcej tokenów na rozumowaniu o tej luce, uruchamia więcej zapytań odkrywczych, częściej ponawia próby. Brakujący kontekst nie znika wraz z lepszym modelem. Staje się droższy.

To fundamentalna zmiana w tym, jak należy myśleć o optymalizacji kosztów AI. Nie chodzi o wybór tańszego modelu ani o skracanie promptów. Chodzi o to, co dostajesz w odpowiedzi ze swoich narzędzi.

Karpathy ujął to precyzyjnie: "context engineering to delikatna sztuka i nauka wypełniania okna kontekstowego właśnie tymi informacjami, które są potrzebne w następnym kroku." Zauważcie, że mówi o narzędziach i stanie jako części tego kontekstu - nie tylko o promptach.

Większość ludzi aplikuje inżynierię kontekstu do promptów i RAG. Backend jest częścią okna kontekstowego, i właśnie ta część prawie nikt nie optymalizuje.

Dlaczego serwer MCP Supabase marnuje tokeny

Supabase to świetny backend. Ale nie był projektowany po to, żeby był operowany przez agenty AI - i serwer MCP, który dodano później, dziedziczy to ograniczenie.

Trzy konkretne mechanizmy powodują bloat tokenowy.

Problem 1: Pobieranie dokumentacji zwraca wszystko

Gdy Claude Code musi skonfigurować Google OAuth przez Supabase, wywołuje narzędzie MCP search_docs.

Implementacja Supabase zwraca pełne metadane schematu GraphQL przy każdym wywołaniu - zawierające 5-10x więcej tokenów niż agent faktycznie potrzebuje.

Jeśli agent zapytał o instrukcje konfiguracji OAuth, dostał całą dokumentację uwierzytelniania - włącznie z sekcjami o email/password, magic links, uwierzytelnianiu przez telefon, SAML i SSO.

To samo dzieje się przy każdym wywołaniu search_docs - przy zapytaniach o bazy danych, konfigurację storage, wdrażanie edge functions. Każde wywołanie zrzuca pełne metadane dla całej tej domeny.

W trakcie sesji, gdzie agent konfiguruje auth, bazę danych, storage i functions, sam narzut z dokumentacji może odpowiadać za tysiące zmarnowanych tokenów.

Problem 2: Brak widoczności stanu backendu

Gdy używasz Supabase jako ludzki developer, otwierasz dashboard i widzisz wszystko naraz - aktywnych dostawców auth, tabele, polityki RLS, skonfigurowane buckety storage, wdrożone edge functions.

Agent nie może zobaczyć dashboardu.

Serwer MCP Supabase udostępnia pewien stan przez indywidualne narzędzia takie jak list_tables i execute_sql, ale nie ma możliwości zapytania "jak wygląda cały mój backend teraz?" i otrzymania jednej ustrukturyzowanej odpowiedzi.

Więc agent skleja obraz z wielu wywołań. Każde wywołanie zwraca częściowy widok. Niektórych informacji - jak którzy dostawcy auth są skonfigurowani - w ogóle nie można uzyskać przez MCP.

Ten pofragmentowany proces odkrywania kosztuje tokeny, a agent często potrzebuje kilku prób, bo informacje wracają niekompletne lub w formacie wymagającym dalszych zapytań do interpretacji.

Problem 3: Błędy bez ustrukturyzowanego kontekstu

Gdy coś idzie nie tak, Supabase zwraca surowe komunikaty błędów. Może to być 403 z odmowy RLS, 500 z źle skonfigurowanej edge function.

Ludzki developer spojrzałby na to, sprawdził dashboard Supabase, powiązał z logami i naprawił problem.

Agent nie ma tej ścieżki. Dostaje komunikat błędu, rozumuje o tym, co mogło spowodować błąd, i próbuje poprawkę. Jeśli poprawka jest zła, ponawia próbę. Każde ponowienie wysyła całą historię konwersacji od nowa i zwielokrotnia koszt tokenowy.

Te trzy mechanizmy - narzut dokumentacji, fragmentaryczne odkrywanie stanu i pętle ponownych prób z błędami - nakładają się szybko. Model, który rozumuje bardziej intensywnie, jak Sonnet 4.6, sprawia, że każdy krok eksploracji jest bardziej dokładny i droższy. Dlatego luka tokenowa zwiększyła się z Sonnet 4.5 do 4.6 - i prawdopodobnie będzie się nadal zwiększać z każdym kolejnym wydaniem modelu.

Jak powinna wyglądać inżynieria kontekstu backendu

Rozwiązanie nie polega na przełączeniu na inny model.

Polega na daniu agentowi ustrukturyzowanego kontekstu backendu, żeby nie musiał eksplorować i zgadywać.

Właśnie to ma na myśli Karpathy mówiąc o inżynierii kontekstu: wypełnianie okna kontekstowego odpowiednimi informacjami. On wprost włącza narzędzia i stan do tego kontekstu. Większość ludzi aplikuje ten pomysł do promptów i pobierania RAG.

Backend jest także częścią okna kontekstowego. I jest tą częścią, której prawie nikt nie optymalizuje.

Żeby zobaczyć, jak to wygląda w praktyce, projekt InsForge (open source z 8 tysiącami gwiazdek) implementuje to podejście. Dostarcza te same prymitywy co Supabase - Postgres z pgvector, auth, storage, edge functions, realtime - ale strukturyzuje warstwę informacyjną tak, aby agenty mogły ją konsumować efektywnie.

Kluczowa różnica architektoniczna polega na tym, jak dostarcza kontekst do Claude Code. Trzy warstwy współpracują ze sobą:

• Skills do wiedzy statycznej
• CLI do bezpośrednich operacji backendowych
• MCP do inspekcji żywego stanu

Każda warstwa rozwiązuje inny problem i zmniejsza tokeny z innego powodu.

Warstwa 1: Skills - statyczna wiedza bez round-tripów

Podstawowe podejście do wiedzy to Skills. Ładują bezpośrednio do kontekstu agenta na starcie sesji, więc wzorce SDK, przykłady kodu i przypadki brzegowe dla każdej operacji backendowej są dostępne bez żadnych wywołań narzędzi.

Skills używają też progressive disclosure - początkowo ładuje tylko metadane (nazwa, opis, ok. 70-150 tokenów na skill). Pełna treść skill ładuje się tylko wtedy, gdy agent stwierdzi, że pasuje do bieżącego zadania. Oznacza to, że możesz mieć zainstalowanych ponad 100 skills bez bloatu kontekstu - co nie jest możliwe przy ładowaniu schematu MCP w trybie wszystko albo nic.

Cztery skills pokrywają cały stack, każdy ograniczony do konkretnej domeny:

• insforge - dla kodu frontendowego komunikującego się z backendem
• insforge-cli - do zarządzania infrastrukturą backendową
• insforge-debug - do ustrukturyzowanej diagnostyki błędów przy typowych awariach, takich jak błędy auth, wolne zapytania, awarie edge functions, odmowy RLS, problemy z wdrażaniem i degradacja wydajności
• insforge-integrations - dla zewnętrznych dostawców auth (Clerk, Auth0, WorkOS, Kinde, Stytch)

Zainstaluj wszystkie cztery jednym poleceniem:

npx skills add insforge/insforge-skills

Kluczowa różnica w stosunku do Supabase: gdy piszesz kod frontendowy, aktywuje się tylko insforge. Gdy tworzysz tabele, aktywuje się tylko insforge-cli. Gdy coś się psuje, aktywuje się tylko insforge-debug. Pozostałe trzy pozostają na kosztach samych metadanych.

Supabase dostarcza jeden szeroki skill, który uruchamia się przy każdym zadaniu związanym z Supabase - pokrywając bazy danych, auth, edge functions, realtime, storage, wektory, cron, kolejki, biblioteki klientów, integracje SSR, CLI, MCP, zmiany schematu, migracje i rozszerzenia Postgres. Kiedy skill Supabase się aktywuje, cała jego treść się ładuje, bo warunki wyzwalania pokrywają prawie całą powierzchnię produktu.

Warstwa 2: CLI - bezpośrednie wykonanie ze strukturyzowanym feedbackiem

Do faktycznego wykonywania operacji backendowych - tworzenia tabel, uruchamiania SQL, wdrażania functions, zarządzania sekretami - CLI InsForge jest podstawowym interfejsem.

Każde polecenie wspiera --json dla strukturyzowanego wyjścia, -y do pomijania monitów potwierdzenia i zwraca semantyczne kody wyjścia, dzięki czemu agenty mogą programistycznie wykrywać błędy auth, brakujące projekty lub błędy uprawnień.

Jest to przydatne, bo Claude Code może przetwarzać wyjście CLI przez jq, grep i awk w sposób, który wymagałby wielu sekwencyjnych wywołań narzędzi MCP.

Benchmarki Scalekit pokazały, że CLI + Skills osiąga wskaźniki sukcesu bliskie 100% z 10-35x lepszą efektywnością tokenową niż równoważnie skonfigurowane środowiska MCP dla przepływów jednouzytkownikowych.

Oto przykładowe operacje, które agent faktycznie wykonuje:

# Inspekcja stanu backendu (uruchom jako pierwsze)
npx @insforge/cli metadata --json

# Operacje na bazie danych
npx @insforge/cli db query "CREATE TABLE posts (...)" --json
npx @insforge/cli db policies  # inspekcja istniejących polityk RLS

# Edge functions
npx @insforge/cli functions deploy my-handler
npx @insforge/cli functions invoke my-handler --data '{"action":"test"}' --json

# Storage
npx @insforge/cli storage create-bucket documents --json
npx @insforge/cli storage upload ./file.pdf --bucket documents

# Frontend deployment
npx @insforge/cli deployments env set VITE_INSFORGE_URL https://...
npx @insforge/cli deployments deploy ./dist --json

# Diagnostyka
npx @insforge/cli diagnose db --check connections,locks,slow-queries

Agent parsuje JSON i obsługuje błędy na podstawie kodów wyjścia. Brak zgadywania. Brak niejednoznacznych komunikatów błędów. Każda operacja zwraca strukturyzowane potwierdzenie tego, co się stało.

Warstwa 3: MCP - tylko do inspekcji żywego stanu

MCP jest nadal użyteczne, ale do węższego celu - inspekcji aktualnego stanu twojego backendu, gdy ten stan się zmienia.

Serwer MCP InsForge udostępnia lekkie narzędzie get_backend_metadata, które zwraca ustrukturyzowany JSON z pełną topologią backendu w jednym wywołaniu:

{
  "auth": {
    "providers": ["google", "github"],
    "jwt_secret": "configured"
  },
  "tables": [
    {"name": "users", "columns": ["id", "email", "created_at"], "rls": "enabled"},
    {"name": "posts", "columns": ["id", "title", "body", "author_id"], "rls": "enabled"}
  ],
  "storage": { "buckets": ["avatars", "documents"] },
  "ai": { "models": [{"id": "gpt-4o", "capabilities": ["chat", "vision"]}] },
  "hints": ["Use RPC for batch operations", "Storage accepts files up to 50MB"]
}

W jednym wywołaniu i ok. 500 tokenach agent zna pełną topologię backendu. Pole hints dostarcza wskazówek specyficznych dla agentów, które zmniejszają nieprawidłowe użycie API.

Kluczowy wybór projektowy polega na tym, że MCP jest używane do inspekcji stanu (który zmienia się w trakcie pracy agenta), a nie do pobierania dokumentacji (która się nie zmienia). To odwraca typowy wzorzec użycia i jest głównym powodem, dla którego InsForge zużywa znacznie mniej tokenów niż Supabase przy równoważnie złożonych zadaniach.

Test w praktyce: budujemy DocuRAG na dwóch backendach

Żeby to ukonkretnić, Avi Chawla zbudował tę samą aplikację używając Claude Code na obu backendach i nagrał pełną sesję.

Aplikacja to DocuRAG. Użytkownicy logują się przez Google OAuth, uploadują pliki PDF, system chunkuje i embedduje tekst (text-embedding-3-small, 1536 wymiarów), przechowuje wektory w pgvector, a użytkownicy zadają pytania w języku naturalnym odpowiadane przez GPT-4o.

Dotyka to prawie każdego prymitywu backendowego naraz: auth użytkowników, przechowywanie plików, tabela dokumentów, embeddingi wektorowe, generowanie embeddingów, chat completion, edge function pobierająca dane i RLS izolujące dokumenty każdego użytkownika.

Konfiguracja dla Supabase

Krok 1: Załóż konto i nowy projekt. Krok 2: Podłącz serwer MCP do Claude Code:

claude mcp add --scope project --transport http supabase \
  "https://mcp.supabase.com/mcp?project_ref=<your-project-ref>"

claude /mcp

Krok 3: Zainstaluj Skills Supabase (oznaczone jako Opcjonalne w oficjalnej konfiguracji):

npx skills add supabase/agent-skills

Instaluje to dwa skills: supabase - szeroki, obejmujący wszystko: bazę danych, auth, edge functions, realtime, storage, wektory, cron, kolejki, biblioteki klientów i integracje SSR; oraz supabase-postgres-best-practices - optymalizacja wydajności Postgres w 8 kategoriach.

Konfiguracja dla InsForge

Krok 1: Załóż konto i nowy projekt (możesz też self-hostować lokalnie przez Docker Compose). Krok 2: Zainstaluj cztery Skills:

npx skills add insforge/insforge-skills

Instaluje to insforge (wzorce SDK), insforge-cli (polecenia infrastruktury), insforge-debug (diagnostyka awarii) i insforge-integrations (zewnętrzni dostawcy auth). Krok 3: Połącz CLI z projektem:

npx @insforge/cli link --project-id <project-id>

InsForge dostarcza cztery wąsko ukierunkowane skills, każdy pokrywający konkretną domenę. Gdy piszesz kod frontendowy, aktywuje się tylko insforge. Gdy tworzysz tabele, aktywuje się tylko insforge-cli. Gdy coś się psuje, aktywuje się tylko insforge-debug. Pełna treść ładuje się tylko dla tego jednego skilla, który pasuje do bieżącego zadania.

Co się stało w sesji Supabase: 10.4M tokenów, 9.21 USD

Początkowy build przebiegł gładko. Agent załadował skill supabase, odkrył stan backendu przez narzędzia MCP (list_tables, list_extensions, execute_sql), przygotował projekt Next.js, utworzył schemat bazy danych, napisał dwie edge functions i wdrożył wszystko. Build przeszedł.

Pierwszy problem: logowanie nie działało

Gdy próbowałem zalogować się przez Google OAuth, aplikacja wyrzuciła błąd. Agent skonfigurował uwierzytelnianie używając złej biblioteki klienta Supabase dla Next.js.

W Next.js callback OAuth uruchamia się po stronie serwera, ale agent użył biblioteki po stronie klienta, która przechowuje stan logowania w przeglądarce. Stan przeglądarki nie jest dostępny po stronie serwera, więc flow logowania się zepsuło.

Agent naprawił to, przechodząc na inną bibliotekę (@supabase/ssr), przepisując jak aplikacja obsługuje sesje logowania i budując od nowa.

Drugi problem: upload dokumentów zajął 8 rund naprawiania

Po naprawieniu logowania próbowałem uploadować dokument. Edge function zwróciła błąd. Zgłosiłem to, próbowała naprawić, nie udało się, próbowałem ponownie - i zwróciła ten sam błąd. Ten cykl powtórzył się 8 razy:

• Agent próbował ręcznie dodać nagłówki auth - ten sam błąd
• Ponowne wdrożenie z dodatkowym logowaniem - ten sam błąd
• Próba pokazania prawdziwego komunikatu błędu zamiast ogólnego - inny błąd (teraz problem z siecią/CORS)
• Naprawiono CORS - powrót do oryginalnego błędu
• Wypróbowanie innego sposobu odczytywania tokenu logowania użytkownika - ten sam błąd
• Wypróbowanie jeszcze innego podejścia do uwierzytelniania - ten sam błąd

Po 8 nieudanych próbach agent w końcu zrozumiał, co się dzieje: błędy 401 pojawiają się na bramce verify_jwt platformy, zanim kod w ogóle zaczyna działać.

Mówiąc prosto: Supabase ma warstwę bezpieczeństwa, która sprawdza tokeny logowania zanim kod edge function w ogóle ruszy. Nowa biblioteka auth zainstalowana przez agenta - żeby naprawić pierwszy problem - wysyłała format tokenu, którego ta warstwa bezpieczeństwa nie rozpoznawała. Więc każde żądanie było odrzucane przy drzwiach, zanim kod functions miał szansę uruchomić się.

Agent spędził 8 rund naprawiając problemy na poziomie kodu, gdy problem był upstream od kodu w ogóle. Rozwiązanie było proste: wyłączyć automatyczne sprawdzanie tokenów przez platformę i zamiast tego obsługiwać uwierzytelnianie w kodzie funkcji.

Ale podczas tego procesu debugowania edge function była ponownie wdrażana 8 razy. Każde ponowne wdrożenie, sprawdzenie logów i ponowienie przesłało całą rosnącą historię konwersacji, zwielokratniając koszt tokenowy.

Końcowe statystyki sesji Supabase: 12 wiadomości od użytkownika (10 to raporty błędów), 135 wywołań narzędzi, 30+ wywołań MCP, 10.4 miliona tokenów, koszt 9.21 USD.

Co się stało w sesji InsForge: 3.7M tokenów, 2.81 USD

Sesja InsForge zakończyła się bez żadnych błędów wymagających mojej interwencji.

Agent zaczął od inspekcji stanu backendu. Jego pierwsza akcja to npx @insforge/cli metadata --json, które zwróciło ustrukturyzowany przegląd projektu - w tym skonfigurowanych dostawców auth, istniejących tabel, bucketów storage, dostępnych modeli AI i kanałów realtime.

To dało agentowi kompletny obraz tego, z czym pracuje, zanim napisał jakikolwiek kod. W sesji Supabase agent potrzebował wielu wywołań MCP, żeby skompletować podobne zrozumienie - i nawet wtedy przeoczył krytyczne szczegóły, takie jak zachowanie verify_jwt.

Konfiguracja schematu przeszła przez 6 poleceń CLI, wszystkie zakończone sukcesem. Agent włączył pgvector, utworzył tabele documents i chunks (z kolumną vector(1536)), włączył Row Level Security na obu, utworzył polityki dostępu i skonfigurował funkcję wyszukiwania podobieństwa match_chunks. Każde polecenie zwróciło strukturyzowane wyjście potwierdzające, co się stało, więc agent mógł zweryfikować każdy krok przed przejściem do następnego.

Problemy z auth i edge functions z sesji Supabase nie pojawiły się tutaj. Skill insforge zawierał prawidłowe wzorce biblioteki klienta dla Next.js, więc agent skonfigurował uwierzytelnianie prawidłowo przy pierwszej próbie.

Dwie edge functions - embed-chunks i query-rag - obie wdrożyły się i uruchomiły bez błędów, bo bramka modeli do embeddingów i chat completion była częścią tego samego backendu. Agent nie musiał osobno integrować OpenAI, zarządzać drugim kluczem API ani radzić sobie z uwierzytelnianiem cross-serwisowym.

Końcowe statystyki sesji InsForge: 1 wiadomość od użytkownika, 77 wywołań narzędzi, 0 wywołań MCP, 3.7 miliona tokenów, koszt 2.81 USD.

Analiza porównawcza

Koszt tokenowy sesji Supabase był napędzany przez pętlę ponownych prób przy błędach. Każde z 8 ponownych wdrożeń edge functions przesłało całą rosnącą historię konwersacji. Agent sprawdzał logi 6 razy, ponownie wdrażał functions 8 razy i wypróbował 6 różnych strategii uwierzytelniania przed znalezieniem głównej przyczyny.

Żadna z tych prób nie była winą agenta. Bramka verify_jwt platformy Supabase odrzucała token zanim kod function uruchomił się, a logi nie rozróżniały odrzuceń na poziomie platformy od odrzuceń na poziomie kodu. Bez tego sygnału agent kontynuował próby naprawy kodu.

Sesja InsForge uniknęła tych problemów, bo skills załadowały prawidłowe wzorce auth od początku, CLI dawało strukturyzowany feedback przy każdej operacji, a bramka modeli oznaczała brak drugiego serwisu do integracji. Agent nie trafił na żaden błąd wymagający debugowania.

Główna lekcja: twój backend jest problemem kontekstu

To porównanie uwidacznia problem wykraczający poza sam Supabase.

Większość backendów była projektowana dla ludzkich developerów, którzy mogą czytać dashboardy, interpretować niejednoznaczne błędy i mentalnie śledzić stan w wielu serwisach. Gdy agent przejmuje ten przepływ pracy, założenia się łamią.

Agent nie widzi dashboardu. Nie może stwierdzić, skąd pochodzi błąd, jeśli logi tego nie mówią. I za każdym razem, gdy zgaduje źle, koszt tokenowy się nakłada.

InsForge jest zbudowany wokół innych założeń: backend ujawnia swój stan przez ustrukturyzowane metadane, a CLI daje agentowi programistyczną kontrolę z jasnymi sygnałami sukcesu i porażki. Skills kodują prawidłowe wzorce, więc agent nie musi odkrywać ich metodą prób i błędów. Bramka modeli utrzymuje operacje LLM wewnątrz tego samego backendu, co usuwa problemy integracji cross-serwisowej.

Jeśli twój agent spędza tokeny na odkrywaniu, jak działa twój backend, zgadywaniu konfiguracji i ponawianej operacji, bo komunikaty błędów nie mówią co poszło nie tak - płacisz za brakujący kontekst.

Poprawka to nie lepszy model ani dłuższe okno kontekstowe. To danie agentowi ustrukturyzowanych informacji o twoim backendzie zanim zacznie pisać kod.

To jest inżynieria kontekstu stosowana do backendu. Karpathy miał rację mówiąc, że wypełnianie okna kontekstowego odpowiednimi informacjami to podstawowa umiejętność. Spostrzeżenie z tego eksperymentu jest takie, że twoja infrastruktura backendowa jest jednym z największych źródeł tego kontekstu - i większość z nas nie traktuje jej w ten sposób.

InsForge jest w pełni open source na licencji Apache 2.0 i możesz go self-hostować przez Docker. Kod, skills i CLI są dostępne na GitHub: github.com/InsForge/InsForge