Microsoft 7 października 2026 r. opisał plan, w którym GitHub Copilot będzie kierować zadania do modeli lokalnych lub chmurowych. Copilot Auto ma brać pod uwagę kontekst zadania i stan pamięci podręcznej w wieloetapowej sesji, a wskazanym celem jest koniec października 2026 r. To planowany routing; osobno GitHub dokumentuje ręczne konfigurowanie modeli w Copilot CLI.
Microsoft planuje routing lokalny i chmurowy
W Copilot Auto wybór trasy ma odbywać się automatycznie. Z kolei BYOK — „bring your own key”, czyli używanie własnego klucza i dostawcy modelu — pozwala użytkownikowi skonfigurować dostawcę albo wybrać konkretny model. Microsoft opisuje lokalne modele dla Copilot CLI, aplikacji Copilot i Visual Studio Code, ale szczegółowe ustawienia CLI nie oznaczają, że wszystkie trzy środowiska mają identyczne możliwości.
GitHub zapowiada, że planowany routing ma wykrywać zainstalowane modele lokalne, między innymi z Ollama i Foundry Local. Wśród zadań przeznaczonych do lokalnego przetwarzania wymienia proste prośby, wyjaśnianie kodu w repozytorium i automatyzacje działające w tle. Firma przedstawia te scenariusze jako wykorzystujące lokalne zasoby obliczeniowe bez zużywania kredytów AI. Model działający na urządzeniu nadal korzysta jednak z jego zasobów i energii elektrycznej.
BYOK i Copilot Auto inaczej rozdzielają wybór modelu
Ręczne BYOK daje użytkownikowi kontrolę nad skonfigurowanym dostawcą i modelem, ale wymaga ustawienia punktu końcowego. Copilot Auto ma samodzielnie kierować zadania między modelami lokalnymi i chmurowymi, biorąc pod uwagę kontekst oraz stan pamięci podręcznej sesji. W planie Auto wybór modelu nie jest równoznaczny z gwarancją, że dane pozostaną na urządzeniu: możliwa jest również inferencja w chmurze.
| Tryb | Kto wybiera model lub trasę | Znaczenie dla połączenia |
| Ręczne BYOK | Użytkownik konfiguruje dostawcę lub wybiera model. | Dostawca może działać lokalnie albo zdalnie; zależy to od skonfigurowanego punktu końcowego. |
| Copilot Auto | Planowana funkcja ma dobierać trasę na podstawie kontekstu zadania i stanu pamięci podręcznej sesji. | Routing może obejmować model chmurowy, więc sam Auto nie jest trybem offline. |
Co GitHub dokumentuje o lokalnych modelach w Copilot CLI
GitHub opisuje trzy typy dostawców: openai, azure i anthropic. Typ openai obsługuje zgodne z OpenAI Chat Completions punkty końcowe, w tym Ollama, vLLM i Foundry Local. Model skonfigurowany w Copilot CLI musi obsługiwać wywoływanie narzędzi oraz streaming. GitHub zaleca okno kontekstu o długości co najmniej 128 tys. tokenów, by uzyskać najlepsze rezultaty.
Przykładowa konfiguracja lokalnego Ollama używa COPILOT_PROVIDER_BASE_URL z adresem http://localhost:11434 oraz COPILOT_MODEL z identyfikatorem zainstalowanego modelu. Klucz API można pominąć, jeśli lokalna usługa nie wymaga uwierzytelnienia. Szczegóły konfiguracji opisuje dokumentacja GitHub dotycząca modeli BYOK w Copilot CLI.
Lokalna inferencja nie oznacza automatycznie pracy offline
W Copilot CLI ustawienie COPILOT_OFFLINE=true zapobiega łączeniu się programu z GitHubem. Nie blokuje jednak połączeń zdalnego dostawcy skonfigurowanego jako punkt końcowy modelu. Jeśli dostawca jest zdalny, nadal może otrzymywać prompty i kontekst kodu. Aby ruch modelu pozostawał lokalny, potrzebny jest lokalny dostawca albo taki, który działa w tym samym odizolowanym środowisku.
Copilot Auto ma kierować zadania także do modeli chmurowych, więc nie zastępuje ustawienia offline. Lokalizacja inferencji — miejsce, w którym model przetwarza dane — jest osobną kwestią od połączeń sieciowych i od tego, jakie działania może wykonywać agent.
Lokalizacja modelu i sandbox narzędzi to osobne mechanizmy
Microsoft rozróżnia izolację procesów od kontroli dostępu poszczególnych narzędzi. Gdy sandbox jest włączony, polecenia powłoki oraz domyślnie lokalne procesy MCP i serwery językowe działają w granicy procesu. Wbudowane narzędzia plikowe są sprawdzane przez polityki Copilota, a nie izolowane jako procesy potomne kontrolowane przez system operacyjny. Zdalne serwery MCP pozostają poza lokalnym sandboxem procesu.
Dlatego uruchomienie modelu lokalnie samo w sobie nie ogranicza dostępu agenta do powłoki, plików ani sieci. Microsoft wskazuje osobne zaplecza sandboxa dla Windows, macOS i Linux. Lokalne rozwiązania nie wymagają osobnej maszyny wirtualnej ani obrazu kontenera.
Backendy sandboxa wskazane przez Microsoft dla systemów operacyjnych
| System operacyjny | Backend wskazany przez Microsoft |
| Windows | BaseContainer w ramach ProcessContainer, przez Microsoft Execution Containers (MXC) |
| macOS | Seatbelt |
| Linux | bubblewrap |