OpenAI zaprezentował Pando, nowy backend Git, który obsługuje teraz cały rozwój w ich monorepo, czyli pojedynczym repozytorium kodu. Klient Git i protokół pozostają niezmienione: inżynierowie i agenci Codex nadal wykonują polecenia git push i git fetch jak dotychczas, zmienił się tylko serwer. Według firmy mediana opóźnienia przy wysyłaniu kodu (push) spadła o blisko 80%.
- OpenAI wdrożył Pando, nowy backend Git dla swojego monorepo, bez zmian w kliencie i protokole.
- Mediana opóźnienia pushów spadła o blisko 80%, według firmy.
- Pando przetwarza każdą gałąź osobno i przechowuje pakiety jako niezmienne bloby.
- Liczby są samodzielnie zgłaszane, a backend pozostaje wewnętrzny i nie jest open source.
Dlaczego OpenAI zmienił backend
Agenci Codex znacząco zwiększyli liczbę równolegle prowadzonych prac. Zgodnie z opublikowanym przez OpenAI wykresem commitów, commity na gałęzi master wzrosły o 1378% w trzecim kwartale 2026 roku w porównaniu z pierwszym kwartałem 2024, a szacunki na czwarty kwartał 2026 sięgają +2442%. Każde wysłanie kodu uruchamia teraz wiele pobrań przez narzędzia ciągłej integracji. Pod koniec 2025 roku pobieranie i wysyłanie kodu zwalniało, niektóre merge’e kończyły się niepowodzeniem, a niezawodność czasami spadała poniżej 90%. Firma doszła do wniosku, że wąskim gardłem był sposób, w jaki obsługiwano Git, a nie sam Git.
Jak działa Pando
Według wpisu inżynieryjnego opublikowanego przez OpenAI, Pando odrzuca dwa założenia, które większość serwerów Git uważa za niepodważalne. Pierwsze dotyczy spójności w skali całego repozytorium: klasyczne serwery porządkują każdą aktualizację referencji dla całego repozytorium, przez co niezwiązane ze sobą pushy muszą czekać. Pando przyjmuje spójność przyczynową, gdzie każda gałąź jest przetwarzana osobno, a klienci wchodzą w konflikt tylko wtedy, gdy pushują tę samą referencję. Kompromisem jest to, że czytelnik przeglądający wiele gałęzi może widzieć je w różnych momentach.
Drugie założenie dotyczy generowania osobnego pakietu dla każdego klienta. Standardowe serwery tworzą nowy przy każdym pobraniu, podczas gdy Pando przechowuje każdy wysłany pakiet jako niezmienny blob i zapisuje „wersję referencji » w rozszerzalnym magazynie metadanych. Wysłanie kodu wymaga stałej liczby odczytów i zapisów metadanych, podczas gdy pobranie wymaga liczby proporcjonalnej do logarytmu różnicy wersji do uzupełnienia. Aby ograniczyć rozmiar pushów, tylko gałąź główna jest ogłaszana jako baza dla nowych gałęzi. W monorepo OpenAI mediana pakietu waży mniej niż 20 KiB.
Pakiety są następnie dystrybuowane za pomocą packfile-uri, istniejącej funkcji protokołu Git, a usługa dostarczania o nazwie Express buforuje je według regionów, ze wskaźnikiem sukcesu przekraczającym 99%. Każdy push tworzy pakiet „L0″, który procesy działające w tle łączą w coraz większe pakiety, aż do poziomu L4 dla obecnego monorepo. Ten mechanizm zastępuje tradycyjne odśmiecanie pamięci w Git.
Samodzielnie zgłaszane liczby
OpenAI wskazuje, że Pando przetwarza blisko petabajt danych Git dziennie, wykorzystując tylko kilka rdzeni procesora, oraz że obsłużył ponad 57 TB pakietów w ciągu jednej godziny, z czego ponad 99% z lokalnej pamięci podręcznej dyskowej. Na standardowych maszynach wirtualnych w chmurze klonowanie i pobieranie nasyca łącza 10 Gb/s. Firma przeprowadziła również testy z kilkoma tysiącami jednoczesnych nadawców, bez zauważalnej degradacji według jej oceny. Wszystkie te liczby są samodzielnie zgłaszane i nie opublikowano jeszcze niezależnych benchmarków.
Pando nie jest open source, a OpenAI wskazuje, że bada sposoby udostępnienia tej technologii. Odczyty obejmujące wiele gałęzi nie mają pojedynczego, spójnego migawkowego widoku repozytorium w danym momencie, a powtarzane pushy stosowanych gałęzi zwracają całą zawartość znajdującą się poza gałęzią główną. Poprawki wprowadzone do klienta Git zostały przekazane do projektu upstream, podczas gdy backend pozostaje na razie wewnętrzny.
