GitHub Copilot startet in JetBrains Air: Der Agent läuft lokal oder in der Cloud – die Kostengrenze bleibt getrennt

Das Wichtigste: Mehr Agentenfreiheit, aber zwei Verwaltungsoberflächen

Am 3. November 2026 kündigen GitHub und Microsoft an, dass GitHub Copilot in JetBrains Air als Agent ausgewählt werden kann. Statt nur Vorschläge in einer klassischen IDE-Chatoberfläche zu lesen, können Entwickler Aufgaben delegieren, mehrere Sitzungen parallel verfolgen und Änderungen im Arbeitskontext prüfen. Die Integration nutzt das Agent Client Protocol (ACP).

Die wichtige Grenze: Für lokale Aufgaben genügt die passende Copilot-Anmeldung in Air. Cloud-Aufgaben setzen zusätzlich eine JetBrains-Air-Teams-fähige Organisation, eine freigegebene Copilot-Integration und den Copilot-Zugang voraus. Es ist kein universell kostenloser Dienst und kein Hinweis, dass alle bestehenden JetBrains-Plugins denselben Workflow bieten.

Was sich gegenüber dem bisherigen Copilot-Plugin ändert

Die Integration ist in Airs Agent-Picker integriert. Ein Anwender kann GitHub Copilot gezielt für eine Coding-Aufgabe auswählen, Ausführungsschritte verfolgen, Ergebnisse prüfen und parallel an mehreren Agentensitzungen arbeiten. Das frühere Copilot-Plugin bleibt als alternativer Workflow erhalten.

Technisch ist ACP hier die Schnittstelle zwischen Agent und Umgebung. Daraus folgt jedoch nicht, dass sämtliche IDE-Agenten dieselben Rechte, Werkzeuge oder Cloud-Bedingungen besitzen. ACP vereinheitlicht einen Teil der Kommunikation, nicht automatisch Abrechnung, Freigaben oder Schutzmaßnahmen.

Lokal und Cloud sind nicht dasselbe Produktversprechen

GitHub unterscheidet zwei Ausführungswege. Lokal wird Air in einer JetBrains IDE installiert, Copilot im Agent-Picker ausgewählt und das bestehende Copilot-Konto verbunden. Bei Air Teams Cloud werden Aufgaben entweder über den Air-Browser oder aus dem IDE-Plugin gestartet.

Für Cloud-Aufgaben beschreibt GitHub eine frische virtuelle Maschine mit Docker-Container, deren Netzwerkverkehr über einen Proxy läuft. Zwischen Aufgaben soll kein Zustand übernommen werden. Der Agent kann Pakete installieren, bauen und testen, ohne die lokale Entwicklungsumgebung zu verändern. Das reduziert einige Risiken eines direkten lokalen Schreibzugriffs, ist aber keine Behauptung vollständig isolierter oder ungefährlicher Agentenausführung in jeder Konfiguration.

Die übersehene Governance-Lücke

Die wichtigste Information für Unternehmen steht nicht in der Funktionsliste, sondern in den Randbedingungen: Airs Governance- und Analyseoberflächen zeigen den GitHub-Copilot-Verbrauch nicht. Außerdem können Air-Administratoren die Copilot-Integration zwar abschalten, aber keine Copilot-Ausgabenlimits innerhalb von Air festlegen. Die Cloud-Nutzung wird laut GitHub dem Copilot-Tarif zugeordnet, nicht JetBrains-AI-Credits.

Dazu kommt eine Plan-Zuordnungsgrenze: Laut GitHub lässt sich für eine einzelne Aufgabe nicht auswählen, ob der persönliche Copilot-Plan oder der Organisationsplan genutzt wird. Ein bloßer „AI-Credit-Limit“-Schalter in JetBrains Air ersetzt daher keine eigene Copilot-Kostenprüfung.

AgentenCode-Matrix: Diese fünf Grenzen muss ein Team kennen

Eigene redaktionelle Folgerung: Für Coding-Agenten gibt es hier mindestens zwei Kontrollsysteme – JetBrains Air für die Agentenauswahl und Cloudzugänge, GitHub Copilot für Lizenz und Verbrauch. Eine einheitliche Oberfläche ist noch keine einheitliche Governance.

Was Unternehmen vor der Freigabe prüfen sollten

Ein kleiner Pilot sollte drei Rollen abbilden: einen IDE-Nutzer mit lokalem Repository, einen Air-Teams-Nutzer für Cloud-Aufgaben und einen Administrator mit Einsicht in Copilot-Lizenzen. Zu testen sind vier Fragen: Kann der Agent ohne Freigabe sensible Dateien lesen? Welcher Plan trägt die tatsächlich entstandenen Kosten? Wo werden Aufgaben-/Auditereignisse sichtbar? Und wer kann die Integration kurzfristig stoppen?

GitHub nennt zudem einen speziellen Stolperstein: Das Verbinden des Copilot-Kontos prüft noch nicht zwingend, ob ein Cloud-Auftrag tatsächlich abrechenbar ist. Bei Start der Cloud-Umgebung kann die Aufgabe wegen fehlender Berechtigung oder Credits fehlschlagen. Deshalb braucht ein belastbarer Pilot den erfolgreichen Cloud-Start, nicht nur einen erfolgreichen Login.

Fazit: ACP ist Interoperabilität, keine gemeinsame Finanzkontrolle

Das Update ist interessant, weil Entwicklungsagenten von einzelnen Chat-Plugins zu austauschbaren Arbeitsakteuren in einer gemeinsamen Oberfläche werden. Gleichzeitig zeigt es, wie wichtig Plan-Transparenz, echte Rechte und prüfbare Kosten sind: Die UX verbindet zwei Systeme schneller als deren Governance.

Drei häufige Fragen

Muss ich mein Copilot-Abonnement wechseln? GitHub beschreibt die Nutzung mit einem bestehenden passenden Copilot-Abonnement. Konkrete Berechtigungen und Limits hängen vom Plan ab.

Ist der Air-Cloud-Agent derselbe wie lokal? Oberfläche und Agent können ähnlich sein, der Ausführungsort und die Berechtigungsvoraussetzungen unterscheiden sich.

Kann JetBrains Air den Copilot-Verbrauch begrenzen? Laut GitHubs Changelog nicht innerhalb der Air-Verwaltung. Die Kosten müssen auf Copilot-Seite geprüft werden.

Quellen, Redaktion und Prüfgrenzen

• GitHub Changelog, 3. November 2026 — ACP, Lokal/Cloud, Docker-/Proxy-Umgebung, Plan- und Governance-Limits.
• Microsoft Java DevBlog, 3. November 2026 — Integrationsumfang und Cloud-Start.
• JetBrains Air: Teams Setup und Governance — zusätzlicher Kontext zu Organisationsrichtlinien.

Methode: Primärquellenvergleich mit eigener Zugang-/Ausführungs-/Kostenmatrix. Keine selbst durchgeführten Air-/Copilot-Tasks, keine Lizenzabrechnung gemessen und keine unabhängige Sandbox-Sicherheitsprüfung. Cover ist eine symbolische KI-Illustration, kein Screenshot von JetBrains Air oder GitHub. Mehr: Agenten auswählen, GitHub-Copilot-Meldung vom Oktober, AgentenCheck.