O czym jest ten film
- Typowy problem osób budujących własne narzędzia wewnętrzne: aplikacja działa, ale każde kliknięcie kosztuje, bo pod spodem siedzi klucz API z osobną kartą i osobnym licznikiem.
- Propozycja autora: zamienić warstwę klucza API na SDK, które korzysta z już opłaconej subskrypcji (Codex/ChatGPT albo Claude).
- SDK jest tu opisane jako „most” między aplikacją a subskrypcją — autor celowo nie wchodzi w szczegóły techniczne.
- Mechanizm działania: żądanie z aplikacji trafia przez most do bezgłowej (headless) sesji subskrypcji, która wykonuje zadanie i zwraca wynik.
- Przez SDK dostępne jest to samo, co przez subskrypcję — także wybór modelu i poziomu wysiłku (effort), a nawet generowanie obrazów.
- Demonstracja na dwóch aplikacjach autora: analizatorze spotkań („Brief Room”) oraz wewnętrznym narzędziu do analityki social mediów z zakładką do miniatur.
- Ważne zastrzeżenie prawne: warunki korzystania z Codex SDK i Claude SDK dopuszczają wyłącznie użytek wewnętrzny i osobisty — nie wolno na tym budować komercyjnego SaaS-u.
- Autor pokazuje fragment „mega promptu”, którym jednym strzałem wygenerował aplikację, z kluczowym warunkiem: „żadnego klucza API, nie pytaj o klucz API”.
- Do udostępniania lokalnej aplikacji zespołowi autor używa prywatnej sieci mesh (Tailscale) — element całkowicie opcjonalny.
- Metodę można przenieść na dowolne narzędzia wewnętrzne: generatory briefów, narzędzia researchowe, sortowanie plików, triage skrzynki mailowej.
Redakcyjne tłumaczenie
Problem: zbudowałeś narzędzie, żeby przestać płacić — i płacisz dalej
Jeśli kiedykolwiek budowałeś własne narzędzie wewnętrzne — czy to na Claude, na Codeksie, czy nawet na Lovable — znasz ten scenariusz. Masz pomysł, budujesz aplikację, w końcu zaczyna działać. Ale żeby naprawdę działała, musisz dodać klucz API. I od tej chwili za każdym razem, gdy korzystasz z narzędzia, które miało zastąpić ci jakąś subskrypcję, ponosisz kolejny koszt — tylko po to, żeby to coś myślało.
A gdyby ta sama subskrypcja AI, która pomogła ci zbudować to narzędzie, mogła je też napędzać? Dokładnie to pokażę w tym materiale. Ta prosta zamiana pozwala oszczędzić setki, jeśli nie tysiące dolarów na narzędziach, które budujesz.
Demonstracja: analizator spotkań
To, co widzicie, to bardzo podstawowa aplikacja do analizy spotkań. Nie chodzi o to, jak wspaniale została „zvibecodowana”, tylko o to, co dzieje się pod spodem. Bierzemy hipotetyczne spotkanie, które przygotowałem, wybieram model — w tym wypadku korzystam z modeli Codeksa — ustawiam poziom wysiłku na średni i klikam przycisk „run brief”.
Normalnie ten request poleciałby dalej, a za kulisami czekałby klucz API z własną kartą kredytową i własnym zużyciem środków. Tutaj cały ten łańcuch wykonuje się bez obciążania mnie choćby o dolara. W dziesięć sekund mamy całe spotkanie przeanalizowane, skategoryzowane i podsumowane.
Powtórzę: sednem nie jest sama aplikacja, tylko fakt, że napędza ją istniejąca subskrypcja Codeksa.
To samo można zastosować do dowolnej aplikacji, jaką sobie wyobrazicie. To jest moje wewnętrzne narzędzie do analityki — właściwie do inwigilacji — social mediów. Wszystko: od trendów, przez tablicę pomysłów, po zakładkę z miniaturami, a nawet generowanie obrazów, obsługuje w całości subskrypcja, za którą i tak płacę już sto dolarów.
Jak to działa: podmiana jednego elementu
To było „co”, przejdźmy do „jak”. Teoretycznie masz swoją aplikację AI i w momencie, gdy klikasz, żeby coś zrobiła, kliknięcie równa się pieniądze. Pewnego dnia patrzysz na swoje subskrypcje i mówisz: „nie chcę już płacić za Lineara ani za Jirę, wezmę to do siebie”. Pojawia się problem, pojawia się aplikacja, a potem — klucz API i licznik.
W całym tym procesie zmieniamy tylko jeden element. Nadal musisz ustalić, jaki problem rozwiązujesz, jak to zbudujesz, zaplanować i zaspecyfikować. Podmieniamy wyłącznie tę jedną warstwę. Zamiast klucza wstawiamy Codex SDK — czyli software development kit.
Jeśli jesteś osobą nietechniczną i właśnie masz odruch, żeby zamknąć film: nie będę wchodził w szczegóły. To jest po prostu most. Zbudujesz aplikację, a potem masz ten most — most, o którego wstawienie możesz poprosić Codeksa albo Claude’a. Jedyne, co musi wiedzieć, to słowo „SDK”. Kiedy je zna, może korzystać z twojej istniejącej subskrypcji.
I tak, to działa również z Claude’em. Przypomnę: w kwietniu tego roku zrobiłem coś, co nazwałem Claude Claw (Informacja dodatkowa: w automatycznym transkrypcie nazwa jest zniekształcona; chodzi o rozwiązanie oparte na Claude Code i Claude SDK) — użyłem subskrypcji Claude’a razem z Claude SDK jako mostu, żeby nie musieć dopłacać za koszty API przy korzystaniu z agentów takich jak Hermes.
Jeśli poprosisz AI o poprawne skonfigurowanie tego mostu, to za każdym razem, gdy wysyłasz request do swojej aplikacji, zamiast trafiać do klucza API i na inny serwer, request skorzysta z bezgłowej wersji twojej subskrypcji. Jeśli nie wiesz, co znaczy „headless”: wyobraź sobie, że masz uruchomioną sesję Codeksa, tylko nie używasz jej przez interfejs — działa w tle, za kulisami. Kiedy odbierze request i dostanie zgodę na dostęp, wykonuje zadanie. Możesz używać istniejących modeli i różnych poziomów wysiłku dla danego modelu.
Najlepsze jest to, że cokolwiek dana usługa potrafi w ramach subskrypcji, potrafisz przez SDK. Jeśli Codex umie nie tylko generować tekst, ale i obrazy, to obrazy też tworzysz bez dodatkowych kosztów.
Przykład drugi: laboratorium miniatur
Dobrym przykładem jest moje thumbnail lab. Wpisuję: stwórz miniaturę o tym, jak wykorzystuję subskrypcję Codeksa zamiast płacenia za koszty API — i dorzucam prośbę o ciekawy efekt kontrastowy. Klikam „create thumbnail project” i narzędzie zaczyna składać pakiet pomysłów, a zaraz potem uruchamia pipeline graficzny. Ten korzysta z modelu obrazowego na średnim poziomie mocy, który mogę podmienić na dowolny inny. W przyszłości będziesz mógł tak samo podmieniać każdy kolejny model, który automatycznie wejdzie do twojej subskrypcji.
Po pięciu minutach powstały nie tylko trzy osobne koncepty miniatur — kiedy klikam „generuj kolejną”, request idzie do subskrypcji i wraca gotowa, ładna miniatura.
Żeby domknąć obraz tego, co się wydarzyło po kliknięciu: aplikacja wysłała request, request przeszedł przez most, most postawił w tle bezgłowego workera Codeksa, ten zabrał kontekst briefu miniatury i przyniósł nam wynik.
Największa wartość znajomości tej metody polega na tym, że kiedy raz ją opanujesz, zaczynasz podmieniać backendy we wszystkich narzędziach wewnętrznych: generatorach briefów, narzędziach researchowych, sortownikach plików, systemach triage’u poczty.
Zastrzeżenie: tylko użytek wewnętrzny
Zanim pokażę przykładowy mega prompt, którym jednym strzałem powstała ta aplikacja, chcę coś doprecyzować. Jeśli zajrzysz w warunki korzystania z Codex SDK — bardzo podobnie jest z Claude SDK — możesz go używać wyłącznie do celów wewnętrznych lub osobistych. To nie służy do tego, żeby postawić SaaS, sprzedawać go publicznie i przy okazji na zasadzie MacGyvera żonglować kilkoma kontami subskrypcyjnymi, oszczędzając na kosztach i zgarniając całą marżę. Są firmy — nie będę wymieniał — które najwyraźniej tak robią, ale to jest niezgodne z regulaminem i może ściągnąć na ciebie kłopoty.
Więc jeszcze raz: to jest zoptymalizowane pod narzędzia wewnętrzne, workflow i integracje.
Prompt, którym powstała aplikacja
Pokażę fragment promptu, którego użyłem do zbudowania tego analizatora spotkań. Nie przeczytam całości, bo to bestia, ale udostępnię go w drugim linku w opisie.
Zaczyna się tak: „Zbuduj mi kompletne, uruchamialne, lokalne narzędzie wewnętrzne o nazwie Brief Room. Zamienia dowolny wklejony tekst w ustrukturyzowany brief. Ograniczenie definiujące: wszystkie wywołania AI idą przez OpenAI SDK, korzystając z mojego zapisanego loginu ChatGPT — nigdzie nie ma żadnego klucza API. Nie proś o klucz API. Codex SDK sam znajduje odpowiedni kod autoryzacyjny, gdy zostanie utworzony bez argumentów”.
Dalej idzie specyfikacja budowy: zbuduj każdy z poniższych plików. Oczywiście sam prompt pomógł mi ułożyć Codex, kiedy już nauczyłem go dokładnie, co i jak chcę osiągnąć. Przechodzimy przez architekturę, przez to, jak postawić serwer na localhoście, potem mamy szkielet projektu. Następnie plik pierwszy — jeden z najważniejszych. To w istocie zestaw instrukcji, jak zbudować wrapper na SDK, żeby móc korzystać z subskrypcji. Jest tu sporo niuansów.
Idea jest taka: bierzesz ten prompt, wrzucasz go do swojego AI i każesz mu przerobić wymagania, strukturę i architekturę pod aplikację, którą już masz albo którą chcesz stworzyć.
Element opcjonalny: udostępnianie zespołowi
Ten jeden plik jest całkowicie opcjonalny — służy tylko temu, żebym mógł udostępnić aplikację reszcie zespołu mojej agencji przez prywatny serwer mesh. Korzystam z Tailscale, bez żadnej afiliacji. To aplikacja praktycznie darmowa dla mniejszych firm: kiedy postawisz lokalne narzędzie wewnętrzne i chcesz, żeby korzystało z niego kilka innych osób — przy założeniu, że to nie jest użytek komercyjny — możesz po prostu udostępnić im link. Albo wdrożyć aplikację i podzielić się nią z konkretnymi osobami.
(Informacja dodatkowa: Tailscale tworzy prywatną sieć VPN typu mesh między twoimi urządzeniami — usługa działająca lokalnie staje się dostępna dla wskazanych osób bez wystawiania jej do publicznego internetu).
Koszt i efekt
Korzystając z całkiem podstawowego modelu na wysokim poziomie wysiłku — a jest to dosłownie grosze, około 80% taniej niż porównywalna alternatywa w normalnym użyciu (Informacja dodatkowa: nazwy modeli są w automatycznym transkrypcie zniekształcone, więc porównanie warto potraktować jako orientacyjne) — dostałem cały pakiet. Wystarczyło uruchomić npm run dev. Jako że jestem leniwy, kazałem to zrobić modelowi za mnie, i dostałem localhost z gotową aplikacją. Wprowadziłem kilka kosmetycznych poprawek i od tego momentu wszystko śmiga.
Żeby jeszcze ułatwić wam sprawę, przygotuję pełny przewodnik, który dołączę do obiecanego promptu — będzie można podać go swojemu AI i zwiększyć szanse na zbudowanie czegoś takiego w możliwie najmniejszej liczbie kroków.
A jeśli chcecie wejść głębiej i dowiedzieć się dokładnie, jak buduję te bardziej złożone aplikacje, które wam pokazałem, z użyciem Codex SDK — zajrzyjcie do pierwszego linku pod filmem, do mojej społeczności, gdzie poprowadzę masterclass od A do Z.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Klucz API to nie jedyny sposób zasilenia własnej aplikacji
Na czym polega: W typowej aplikacji zbudowanej „na własne potrzeby” każde kliknięcie generuje wywołanie płatnego API. SDK dostawcy potrafi natomiast uwierzytelnić się przez zapisany login twojej subskrypcji i wykonać to samo zadanie w ramach opłaconego już abonamentu.
Jak stosować: Zanim wpiszesz klucz API do kolejnego prywatnego narzędzia, sprawdź, czy dostawca twojej subskrypcji udostępnia SDK działające na sesji logowania. Jeśli tak — to jest miejsce, w którym warto zacząć.
Na co uważać: To działa dla narzędzi uruchamianych lokalnie lub w twoim środowisku, gdzie ta sesja logowania w ogóle istnieje. W klasycznym hostingu w chmurze, bez twojego zalogowanego konta, ten mechanizm nie zadziała.
2.Zmieniasz jedną warstwę, nie cały projekt
Na czym polega: Autor podkreśla, że reszta procesu zostaje bez zmian — definicja problemu, planowanie, specyfikacja, budowa. Podmieniana jest wyłącznie warstwa dostępu do modelu.
Jak stosować: Trzymaj wywołania modelu w jednym module (wrapperze). Wtedy zamiana klucza API na SDK to podmiana jednego pliku, a nie przepisywanie aplikacji.
Na co uważać: Jeśli wywołania modelu masz rozsiane po całym kodzie, migracja przestaje być trywialna. Warto zacząć od refaktoru do jednego punktu wejścia.
3.Nietechniczni też mogą to zrobić — przez prompt
Na czym polega: Cały trik sprowadza się do tego, żeby asystent kodujący wiedział, że ma użyć SDK zamiast klucza. Autor twierdzi, że wystarczy, by model „znał słowo SDK”.
Jak stosować: W prompcie budującym aplikację wpisz twarde ograniczenie: wszystkie wywołania AI mają iść przez SDK korzystające z zapisanego loginu, nigdzie nie ma klucza API, nie pytaj o klucz API.
Na co uważać: Modele mają silny odruch wstawiania process.env.OPENAI_API_KEY. Ograniczenie trzeba powtórzyć i po wygenerowaniu kodu zweryfikować, czy klucz gdzieś się nie przemycił.
4.Ograniczenie licencyjne jest realne, nie formalnością
Na czym polega: Warunki korzystania z Codex SDK i Claude SDK dopuszczają — według autora — wyłącznie użytek wewnętrzny i osobisty. Budowanie na tym komercyjnego SaaS-u łamie regulamin.
Jak stosować: Traktuj tę metodę jako sposób na narzędzia dla siebie i swojego zespołu: briefy, research, porządkowanie plików, triage maili.
Na co uważać: Konsekwencją naruszenia może być utrata konta. Autor sam mówi, że zna firmy, które to robią, i że „może to ściągnąć kłopoty” — warto samodzielnie sprawdzić aktualne warunki u dostawcy przed wdrożeniem czegokolwiek dla klienta.
5.SDK daje ci wszystko, co daje subskrypcja — łącznie z obrazami
Na czym polega: Zakres możliwości przez SDK odpowiada zakresowi subskrypcji. Jeśli w abonamencie masz generowanie obrazów, dostajesz je również w swojej aplikacji.
Jak stosować: Planuj narzędzia multimodalne — jak pokazane w filmie laboratorium miniatur, gdzie z jednego briefu powstają koncepty i gotowe grafiki.
Na co uważać: Generowanie obrazów jest wolniejsze — u autora pełny pakiet trzech konceptów zajął około pięciu minut. Interfejs musi to znieść (kolejkowanie, stan „w toku”), bo inaczej użytkownik uzna, że aplikacja zawiesiła się.
6.Wybór modelu i poziomu wysiłku zostaje po twojej stronie
Na czym polega: Przez SDK możesz wskazać konkretny model i poziom wysiłku (effort) — dokładnie tak, jak w interfejsie subskrypcji.
Jak stosować: Wystaw wybór modelu i poziomu wysiłku jako parametr w UI swojej aplikacji, tak jak autor w analizatorze spotkań. Do rutynowych zadań ustawiaj niższy poziom, do trudnych — wyższy.
Na co uważać: Nie zaszywaj nazwy modelu na sztywno w kodzie. Modele w subskrypcjach zmieniają się co kilka miesięcy; parametr w konfiguracji oszczędzi ci późniejszej przeróbki.
7.„Headless” znaczy: ta sama sesja, tylko bez interfejsu
Na czym polega: Request z aplikacji uruchamia w tle bezgłowego workera twojej subskrypcji, który wykonuje zadanie z podanym kontekstem i zwraca wynik.
Jak stosować: Myśl o tym jak o zdalnym pracowniku, któremu przekazujesz brief. Im lepiej zapakujesz kontekst przekazywany do workera, tym lepszy wynik.
Na co uważać: Bezgłowa sesja wymaga aktywnego, zalogowanego konta na maszynie, na której działa. Wygaśnięcie sesji logowania po prostu zatrzyma aplikację — warto zawczasu przewidzieć czytelny komunikat o błędzie.
8.Zacznij od jednego, konkretnego narzędzia zastępującego subskrypcję
Na czym polega: Punktem wyjścia u autora jest pytanie „za co nie chcę już płacić?” — Linear, Jira — i wzięcie tego do siebie.
Jak stosować: Wybierz jedną subskrypcję o niskiej złożoności i wysokiej powtarzalności, przelicz jej roczny koszt i dopiero wtedy budów jej wewnętrzny odpowiednik.
Na co uważać: Nie każda subskrypcja da się sensownie zastąpić. Narzędzia, których wartość leży we współpracy zespołowej, integracjach z zewnętrznymi systemami czy w zgodności z regulacjami, odtworzysz drożej, niż kosztuje abonament.
9.Jeden „mega prompt” może wygenerować aplikację od zera
Na czym polega: Autor zbudował Brief Room jednym rozbudowanym promptem zawierającym architekturę, sposób uruchomienia serwera lokalnego, szkielet projektu i szczegółowe instrukcje do wrappera na SDK.
Jak stosować: Nie pisz promptu ręcznie od zera — najpierw wyjaśnij modelowi, co i jak chcesz osiągnąć, i poproś go o napisanie specyfikacji. Potem tę specyfikację przerabiaj pod kolejne aplikacje.
Na co uważać: Autor sam nazywa plik z wrapperem najważniejszym i pełnym niuansów. To tam najczęściej wychodzą błędy — i to ten fragment warto sprawdzić najuważniej, zamiast ufać, że „skoro się uruchomiło, to jest dobrze”.
10.Udostępnianie zespołowi bez wystawiania aplikacji do internetu
Na czym polega: Lokalne narzędzie autor udostępnia współpracownikom przez prywatną sieć mesh (Tailscale), zamiast publikować je publicznie.
Jak stosować: Postaw aplikację lokalnie, dołóż prywatną sieć i udostępnij link wybranym osobom. Dla małych zespołów to rozwiązanie w praktyce bezkosztowe.
Na co uważać: To wciąż musi pozostać użyciem niekomercyjnym — sam autor to zaznacza. Poza tym każda osoba korzystająca z takiego linku generuje ruch na twojej subskrypcji, więc kilku aktywnych użytkowników może szybko wyczerpać limity konta.