Open Interpreter — wykonywanie kodu sterowane modelem językowym

Jeśli kojarzysz Open Interpreter jako pythonową bibliotekę, która pozwalała modelowi językowemu uruchamiać kod na twoim komputerze — coś w rodzaju interpretera kodu z ChatGPT, tylko lokalnie — to musisz wiedzieć, że pod tym adresem stoi dziś coś innego. Nazwa została, gwiazdki zostały (68 279), a produkt jest inny: przepisany w Rust fork narzędzia Codex firmy OpenAI, nastawiony na wyciśnięcie maksimum z tanich modeli.

To nie jest zarzut. Zmiana została przeprowadzona porządnie i, co najważniejsze, jawnie — README zawiera notatkę mówiącą wprost, gdzie szukać starego projektu. Ale jest to zmiana, która wpływa na decyzję o wdrożeniu, i to na dwóch poziomach, z których drugi zaskoczy najbardziej.

Dwa projekty o tej samej nazwie i dwie różne licencje

Zacznijmy od porządku, bo pomyłka tutaj ma konsekwencje prawne.

Nowy Open Interpreter mieszka pod adresem openinterpreter/openinterpreter — zwróć uwagę, że zarówno organizacja, jak i nazwa repozytorium się zmieniły, więc stary odnośnik przekierowuje. Jest wydany na Apache-2.0, a plik NOTICE przypisuje autorstwo tak, jak wymaga tego ta licencja: „OpenAI Codex, Copyright 2025 OpenAI", plus kod pochodzący z biblioteki Ratatui na licencji MIT.

Oryginalny projekt w Pythonie żyje dalej — README nowego wskazuje go wprost jako utrzymywany przez społeczność fork pod adresem endolith/open-interpreter. Sprawdziłem: fork jest realny i czynny, z commitami z 4 września 2026 i pushem z 9 września, przy czym utrzymuje go jedna osoba, a otwartych zgłoszeń jest tam 85. Ma 33 gwiazdki, czyli społeczność wokół niego jest niewielka.

A teraz rzecz najważniejsza, która przy pobieżnym czytaniu umyka: te dwa projekty mają różne licencje. Nowy, oparty na Codeksie, jest na Apache-2.0 — permisywnej, z jawnym udzieleniem patentowym, bez obowiązków wobec twojego kodu. Fork pythonowy jest na AGPL-3.0, odziedziczonej po oryginale. Dla firmy to różnica zasadnicza: AGPL ma klauzulę sieciową, więc wbudowanie tego kodu w usługę udostępnianą przez sieć rodzi obowiązek udostępnienia źródeł twoich modyfikacji. Wybór między „starym" i „nowym" Open Interpreterem nie jest więc wyborem wersji, a wyborem reżimu licencyjnego.

Dopełnijmy obraz jeszcze jedną liczbą. Paczka open-interpreter na PyPI stoi na wersji 0.4.3 opublikowanej 26 października 2024, czyli od blisko dwóch lat. Jeśli twój projekt ma ją w zależnościach, to nie jest to kod, który dostaje poprawki z głównego nurtu — wsparcie idzie dziś przez fork społecznościowy.

Stan projektu

Nowa linia rozwija się bardzo szybko. Wydania oznaczane są przedrostkiem rust- i idą niemal co tydzień: rust-v0.0.42 z 8 września 2026, wcześniej 0.0.41 z 5 września, 0.0.40 z 20 sierpnia, 0.0.39 z 17 sierpnia i 0.0.38 z 15 sierpnia. Commity wpadają codziennie.

Dwie obserwacje warte odnotowania. Pierwsza: numeracja 0.0.x przy 68 tysiącach gwiazdek mówi, że mimo popularności nazwy sama przepisana implementacja jest młoda — i tak też należy ją traktować przy planowaniu. Druga: otwartych zgłoszeń jest jedno. Przy repozytorium tej wielkości to liczba nietypowa; w praktyce znaczy, że dyskusja toczy się gdzie indziej (projekt prowadzi Discorda), a nie że nie ma o czym rozmawiać. Nie licz więc na zgłoszenia jako kanał wsparcia.

Budowanie stoi na Bazelu — w korzeniu są pliki MODULE.bazel, BUILD.bazel i obszerny .bazelrc, obok justfile i flake.nix. To zaplecze dużego projektu, nie skryptu.

Co znaczy „fork Codeksa"

Warto zrozumieć, bo to nie jest luźna inspiracja, a rzeczywista pochodna. Struktura repozytorium zawiera katalogi codex-rs i codex-cli, a osobny dokument FORK_BRANDING.md opisuje, jak taki fork się „marchandizuje". Cytując go: Open Interpreter dziedziczy wewnętrzne nazwy skrzynek, protokołów i zgodności po OpenAI Codex, ale te nazwy nie są tożsamością produktu pokazywaną użytkownikom — i dalej instrukcja: nie zamieniaj globalnie słowa codex w całym repozytorium.

To rozwiązanie techniczne warte uwagi samo w sobie. Tożsamość produktu jest scentralizowana w jednym module, z metodami zwracającymi nazwę wyświetlaną, nazwę polecenia i adresy instalatora — a nowa marka dodaje własny wariant zamiast zmieniać znaczenie istniejącego. Efekt: zachowanie głównego nurtu Codeksa zostaje nietknięte, a zmiany z góry można dalej przyjmować. Kto kiedykolwiek utrzymywał fork większego projektu, wie, ile to warte.

Zgodność jest przy tym dwustronna i sprowadzona do jednej linii. Jeśli budujesz już na SDK Codeksa, wystarczy nadpisanie ścieżki do binarki:

-const codex = new Codex();
+const codex = new Codex({ codexPathOverride: "interpreter" });

Open Interpreter mówi tym samym protokołem wykonawczym co Codex, a w repozytorium jest skrypt sprawdzający tę zgodność lokalnie, bez potrzeby posiadania konta u jakiegokolwiek dostawcy. Działa też jako agent w protokole ACP dla edytorów — wystarczy skonfigurować klienta na uruchamianie interpreter acp.

Emulacja harnessów, czyli pomysł, który wyróżnia ten projekt

Tu jest sedno i jest to koncepcja, której nie spotkałem wcześniej w tak jawnej formie.

Obserwacja wyjściowa jest taka: ten sam model daje bardzo różne wyniki w zależności od tego, jak jest opakowany — jakim promptem systemowym, jakim zestawem narzędzi, jaką konwencją opisywania zmian w plikach. Każdy dostawca modelu dostraja swoje narzędzie do własnego modelu, więc model działa najlepiej w harnessie, dla którego był przygotowywany. Open Interpreter emuluje te harnessy i pozwala je przełączać poleceniem /harness:

> /harness

native
claude-code
claude-code-bare
zcode
kimi-code
kimi-cli
qwen-code
deepseek-tui
swe-agent
minimal

Dziesięć wariantów, od własnego (native) przez odwzorowania narzędzi konkretnych dostawców po minimal i swe-agent. Cel jest wprost nazwany w opisie projektu: agent kodujący zoptymalizowany pod tanie modele. Zamiast płacić za najdroższy model, bierzesz tańszy i uruchamiasz go w harnessie, w którym radzi sobie najlepiej.

Dla firmy przeliczającej koszty to argument konkretny. Trudno oczywiście z góry powiedzieć, ile realnie zyskacie — to zależy od zadania i modelu — ale możliwość przetestowania tej samej pracy na kilku harnessach bez zmiany narzędzia jest tanim eksperymentem z mierzalnym wynikiem.

Instalacja

Instaluje się skryptem pobieranym z sieci, a polecenie nazywa się interpreter albo krótko i:

curl -fsSL https://www.openinterpreter.com/install | sh

Na Windowsie jest odpowiednik dla PowerShella. Wypada powiedzieć rzecz, którą mówię przy każdym narzędziu instalowanym w ten sposób: przepuszczenie pobranego skryptu wprost do powłoki oznacza wykonanie kodu z sieci bez obejrzenia go. W firmowym środowisku rozsądniej pobrać skrypt osobno, przeczytać i wykonać świadomie — albo wziąć binarkę z wydania i zarządzać nią własnym procesem. Autorzy dają obie drogi, ale w README promują tę krótszą.

Portowalność jako zadeklarowany cel produktu

To sekcja, która wyróżnia ten projekt na tle konkurencji, i cytuję ją, bo warto: Open Interpreter powinien wpasować się w twoje istniejące środowisko agentowe, a nie uwięzić je w formacie tylko dla Open Interpretera. Zadeklarowanym celem produktu jest preferowanie wspólnych, neutralnych wobec narzędzi standardów i katalogów, trzymanie danych tworzonych przez użytkownika w czytelnych plikach oraz uczynienie przejścia do innego zgodnego agenta i z powrotem sprawą prostą.

W praktyce znaczy to korzystanie z AGENTS.md w repozytorium, wspólnych katalogów .agents/skills, protokołów MCP i ACP oraz protokołu wykonawczego Codeksa. Magazyn własny pod ~/.openinterpreter jest — jak piszą autorzy — zarezerwowany dla konfiguracji i stanu, dla których nie ma jeszcze praktycznego wspólnego standardu. Stare, produktowe katalogi umiejętności pozostają czytelne dla zgodności, ale nowe umiejętności należą do .agents/skills.

Osobny dokument opisuje aktualną granicę tego podziału oraz reguły jej zmieniania, i warto z niego wyjąć dwie rzeczy. Pierwsza to tabela wspólnej powierzchni, czyli konkretna odpowiedź na pytanie „gdzie leżą moje dane":

Instrukcje projektu — AGENTS.md w repozytorium.
Umiejętności projektu — katalog .agents/skills/.
Umiejętności osobiste — katalog ~/.agents/skills/.
Integracje narzędzi — protokół MCP.
Integracja z edytorem — protokół ACP.
Wykonywanie programowe — protokół wykonawczy zgodny z Codeksem.

Po stronie produktowej zostają konfiguracja, poświadczenia, historia sesji, dzienniki, bufory i stan demona — przy czym poświadczenia trzymane są pod ~/.openinterpreter albo w magazynie poświadczeń systemu operacyjnego, co jest właściwym miejscem i warto to odnotować.

Druga rzecz to procedura, którą autorzy nakładają na siebie przed dodaniem własnego formatu: najpierw sprawdź, czy istniejący standard agentowy, edytorski albo systemowy nie potrafi tego wyrazić; a jeśli format własny jest naprawdę konieczny, to używaj prostych, udokumentowanych danych, trzymaj granicę wąsko, dostarcz ścieżkę migracji lub eksportu i nie czyń kopii produktowej jedynym użytecznym źródłem prawdy.

Domyka to zdanie, które jest najmocniejszą deklaracją przeciw uwięzieniu użytkownika, jaką spotkałem w tej kategorii narzędzi. Test cechy portowalnej jest prosty: użytkownik powinien rozumieć, gdzie leżą jego dane, móc użyć ustandaryzowanych części w innym zgodnym narzędziu i odejść od Open Interpretera bez utraty pracy, którą sam wytworzył. Deklaracja braku uwięzienia jest łatwa; zapisanie kryterium, po którym można ją sprawdzić, jest zobowiązaniem.

Katalog modeli, który się nie zestarzeje

Drobny szczegół inżynierski, który rozwiązuje problem opisywany w tej serii przy innych narzędziach — zamrożonej listy modeli, przez którą narzędzie do pośredniczenia w dostępie do modeli przestaje mieć sens po roku.

Tutaj przynależność dostawców i modeli jest generowana, a nie utrzymywana jako listy w kodzie Rusta. Odświeżenie wszystkich hostowanych dostawców to uruchomienie jednego skryptu, a można też odświeżyć wybranego dostawcę osobno. Pobieranie żywych źródeł modeli wymaga poświadczeń do danego dostawcy. To właściwe rozwiązanie: aktualizacja katalogu przestaje być pracą ręczną, którą ktoś kiedyś przestanie wykonywać.

Jak ten fork nadąża za górą

Utrzymywanie forka dużego, szybko zmieniającego się projektu jest trudne i zwykle kończy się rozejściem. Notatki wydania pokazują, jak ten problem został ujęty: wersja 0.0.42 jest opisana jako oparta na stabilnej bazie zgodności z Codeksem w wersji rust-v0.153.4. Fork ma więc własną, niską numerację, a osobno deklaruje, którą wersję z góry śledzi. To rozwiązuje zamieszanie, które przy forkach jest normą — wiesz, co dostajesz i wobec czego.

Równie starannie potraktowano listy modeli, i jest to warte pochwały, bo dotyka rzeczy, na której inne projekty się przewracają. Notatki rozdzielają odziedziczone z góry ustawienia od identyfikatorów udokumentowanych przez dostawców i mówią wprost, że Open Interpreter nie dodaje własnych aliasów dla tych pierwszych. Jest też zastrzeżenie, którego zwykle brakuje: podana lista nie jest obietnicą, że każdy dostawca, region, konto, interfejs czy harness przyjmie każdy identyfikator — a ostatecznym autorytetem jest polecenie /model i lista modeli aktywnego dostawcy.

Wraz z generowanym katalogiem dostawców daje to spójną odpowiedź na problem zestarzałej listy modeli. Nie ma tu ręcznie pisanej tablicy, która przestanie być aktualizowana, ani obietnic, których dostawca nie potwierdza.

Na koniec drobiazg z tej samej sekcji, który spodoba się każdemu, kto testował agenty. W wydaniu 0.0.42 pojawiło się narzędzie diagnostyczne dla lokalnych modeli na Ollamie, sprawdzające używanie narzędzi. Ogranicza przechwytywane wyjście, sprząta grupy procesów po przekroczeniu limitu czasu, zapisuje sygnały wywołań narzędzi i — to jest ta część warta zapamiętania — weryfikuje żądane efekty na plikach osobno od końcowej wiadomości asystenta. Innymi słowy sprawdza, co agent faktycznie zrobił, a nie co o sobie napisał. To właściwe podejście do testowania agentów i dobry wzorzec do skopiowania u siebie.

Obsługa komputera i testowanie interfejsów

Projekt dowozi umiejętność kontroli jakości, która pozwala dowolnemu modelowi obsługiwać i testować interfejsy. Aplikacje webowe prowadzi w prawdziwej przeglądarce przez agent-browser, a aplikacje natywne przez trycua. To odpowiada na przypadek użycia, który w tej serii pojawiał się już przy narzędziach do rozkładania zrzutów ekranu — z tą różnicą, że tutaj jest wbudowany w agenta, a nie jest osobną warstwą do spięcia.

Bezpieczeństwo — polityka, którą warto przepisać

Plik SECURITY.md tego projektu jest najlepszym przykładem, jaki widziałem, tego, jak fork powinien podchodzić do zgłoszeń podatności. Rozwiązuje problem, o którym większość forków nie myśli wcale: gdzie zgłosić błąd, który mógł zostać odziedziczony.

Podział jest jawny. Podatności w powierzchniach należących do Open Interpretera — emulacji harnessów, zgodności z dostawcami, pakowaniu i aktualizacjach, punktach końcowych marki, obsłudze ACP oraz zachowaniu przy importach i zgodności — zgłasza się na adres opiekuna. Natomiast jeśli podatność istnieje również w niezmodyfikowanym Codeksie, należy skorzystać z programu ujawniania podatności OpenAI — z podanym uzasadnieniem: pozwala to zespołowi z góry naprawić źródło, a Open Interpreterowi otrzymać poprawkę wraz z wydaniem z głównego nurtu.

I zdanie domykające: w razie wątpliwości zgłaszaj prywatnie do nich, a odziedziczone problemy przekierują w górę bez publikowania wrażliwych szczegółów. To jest przemyślane do końca — z uwzględnieniem tego, że osoba zgłaszająca nie ma obowiązku wiedzieć, po której stronie granicy leży błąd.

Co do samego wykonywania kodu: projekt deklaruje uruchamianie poleceń w natywnej piaskownicy systemu na macOS, Linuksie i Windowsie, a w kwestii granic bezpieczeństwa, zatwierdzeń i kontroli sieci odsyła do dokumentacji Codeksa. To uczciwe rozgraniczenie — nie udają, że napisali tę warstwę sami — ale znaczy też, że przy ocenie ryzyka trzeba przeczytać dokument u źródła, nie tylko README forka.

Reszta uwag jest wspólna dla wszystkich agentów wykonujących kod, o których pisaliśmy w tej serii: to narzędzie za twoim przyzwoleniem uruchamia polecenia na twojej maszynie, a treść repozytorium, cudzego zgłoszenia czy komentarza w kodzie jest dla modelu wejściem. Sekrety trzymaj poza maszyną roboczą, a przy wrażliwych repozytoriach rozważ model działający lokalnie.

Pułapki w jednym miejscu

To już nie ta sama aplikacja. Pythonowa biblioteka, która rozsławiła nazwę, żyje jako fork społecznościowy pod innym adresem.
Dwa projekty, dwie licencje. Nowy jest na Apache-2.0, fork pythonowy na AGPL-3.0 z klauzulą sieciową.
Paczka open-interpreter na PyPI stoi na 0.4.3 z października 2024. Jeśli ją masz w zależnościach, nie dostaje poprawek z głównego nurtu.
Adres repozytorium się zmienił — dziś jest to openinterpreter/openinterpreter.
Wersja 0.0.x przy 68 tysiącach gwiazdek — implementacja jest młoda, mimo dojrzałości nazwy.
Jedno otwarte zgłoszenie. Zgłoszenia nie są tu kanałem wsparcia; dyskusja toczy się na Discordzie.
Instalacja przez przepuszczenie skryptu z sieci do powłoki. W firmie pobierz, przeczytaj, wykonaj świadomie.
Granice piaskownicy i zatwierdzeń są opisane w dokumentacji Codeksa, nie tego projektu — trzeba przeczytać u źródła.
Podatności odziedziczone zgłasza się do OpenAI, nie do Open Interpretera. Dokładny podział jest w polityce bezpieczeństwa.
Budowanie stoi na Bazelu. Samodzielna kompilacja to nie cargo build.

Podsumowanie

Open Interpreter w obecnej postaci jest projektem o wyraźnie zdefiniowanej niszy: bierze dopracowany harness Codeksa i pozwala uruchomić w nim tani model, w opakowaniu, które temu modelowi najbardziej sprzyja. To pomysł konkretny i policzalny, a przy okazji jeden z lepiej przemyślanych forków, jakie widziałem.

Emulacja dziesięciu harnessów przełączanych jednym poleceniem, żeby tani model działał w opakowaniu, dla którego był dostrajany.
Zgodność z SDK i protokołem wykonawczym Codeksa — podmiana istniejącej integracji to jedna linia, ze skryptem sprawdzającym zgodność lokalnie.
Portowalność jako zadeklarowany cel — AGENTS.md, wspólne .agents/skills, MCP i ACP, z zapisanymi regułami tego, co wolno trzymać we własnym formacie.
Katalog dostawców i modeli generowany skryptem, więc nie zestarzeje się przez zaniechanie.
Wbudowana umiejętność obsługi i testowania interfejsów, webowych w przeglądarce i natywnych w systemie.
Wzorowa polityka zgłaszania podatności, z jawnym podziałem między powierzchnię własną i odziedziczoną po Codeksie.

Nowa linia jest wydana na licencji Apache-2.0, z poszanowaniem atrybucji wobec OpenAI i Ratatui w pliku NOTICE — czyli dokładnie tak, jak ta licencja wymaga od forka. Apache-2.0 dokłada wobec MIT jawne udzielenie licencji patentowej oraz wymóg odnotowania zmian w plikach, które modyfikujesz; przy zwykłym używaniu narzędzia nie ma to znaczenia, przy własnym forku ma. A jeśli przyszedłeś tu po pythonowy Open Interpreter, pamiętaj o jednej rzeczy przed dodaniem go do projektu: tamten jest na AGPL-3.0, i to jest zupełnie inna rozmowa z prawnikiem niż ta.