Kurzfassung: Mit GitHubs Veröffentlichung vom 28. Oktober können Nutzer kostenpflichtiger Copilot-Pläne dieselbe Cloud-Sitzung über Web, Mobilgerät, CLI, Copilot-App und VS Code fortsetzen. Slack und Teams können bei entsprechender Einrichtung in der Organisation Arbeit anstoßen.[1] Ab November 2026 werden laufende Rechenzeit und zugewiesener Arbeitsspeicher einer Cloud-Sandbox mit demselben monatlichen, in US-Dollar bezifferten Guthaben verrechnet wie berechtigte Actions-Jobs. GitHub nennt dafür 12 US-Dollar bei Free, 18 US-Dollar bei Pro oder Team und 300 US-Dollar bei Enterprise Cloud. Copilot Free schaltet das neue Cloud-Erlebnis jedoch nicht frei.[1][5]
GitHub kündigte die verbundene Copilot-Cloud-Erfahrung am 28. Oktober 2026 auf der Universe an.[2] Das Versprechen ist Kontinuität: Eine Aufgabe aus einem Issue auf dem Telefon beginnen, im Web prüfen und dieselbe Sitzung in einem Entwicklungsclient steuern. Nach GitHubs Angaben sind Cloud-Sandboxes und die geräteübergreifende Erfahrung für kostenpflichtige Copilot-Pläne allgemein verfügbar; die Einführung begann am 28. Oktober.[1]
Die eigentliche Geschichte ist nicht nur ein weiterer Ort zum Chatten. GitHub macht die Agentensitzung zu einer transportablen Arbeitseinheit und ihren Ausführungsort zu einer bewussten Betriebs- und Kostenentscheidung. Ein in der Cloud gesendeter Auftrag kann das absendende Gerät überdauern; die Rechenleistung erscheint trotzdem auf einer Rechnung. Dieser Artikel beschreibt einen anhand von GitHubs Dokumentation zu prüfenden Arbeitsablauf. LLM Rumors behauptet nicht, eine produktive Sitzung ausgeführt oder ihre Leistung gemessen zu haben.
Warum das jetzt wichtig ist
Titelbild: generierte redaktionelle Metapher einer Arbeitsmappe auf einem karmesinroten Faden zwischen Geräten, Rechenwerkstatt und Sanduhr. Es zeigt weder die GitHub-Oberfläche noch gemessene Nutzung.
Sitzungskontinuität: Die Aufgabe mitnehmen, nicht den Laptop
GitHubs Modell besteht aus drei Teilen: dem Client, in dem ein Mensch mit Copilot spricht, der Sitzung mit Gespräch und Aktivitäten sowie der Umgebung, in der Befehle laufen. Eine Cloud-Sandbox ist eine von GitHub betriebene Linux-Umgebung, getrennt vom Rechner des Nutzers. Laut GitHub klont sie die betreffenden Repositories, führt dort Befehle und Tests aus und speichert angehaltene Arbeit als Snapshot, damit sie in einem anderen Client fortgesetzt werden kann.[3][8]
Eine sinnvolle Übergabe beginnt beim Repository, Issue oder Pull Request. Fügen Sie den nötigen Kontext hinzu, beauftragen Sie eine begrenzte Änderung und prüfen Sie das Sitzungsprotokoll, bevor Sie einen Pull Request anfordern. Laut GitHub fügt eine Web-Sitzung über einem Pull Request, einer Datei oder einem Repository diese Seite als Kontext hinzu. Auf dem Mobilgerät lassen sich Sprache, Bilder und Dateien verwenden. Die unterstützten Clients zeigen dieselbe Liste der Cloud-Sitzungen, sodass das nächste Gerät die Aufgabe fortsetzt, statt den Prompt neu aufzubauen.[1][8]
Slack und Teams bieten einen weiteren Einstieg: Sind die Organisationsrichtlinien aktiviert und die GitHub-App verbunden, kann @GitHub eine Codeänderung anfordern oder einen Fehler untersuchen. Das ist ein Eingangskanal, keine automatische Freigabe zum Zusammenführen. In Organisationen regelt Single Sign-on den Zugriff auf Sitzungsdaten; ohne Schreibrecht für das Repository arbeitet Copilot nur lesend.[1]
Oft übersehen wird die lokale Ausnahme. Copilot-CLI-Sitzungen laufen standardmäßig auf dem Rechner des Nutzers. copilot --cloud startet eine interaktive Sitzung in einer Cloud-Sandbox; laut GitHub lässt sich die Option nicht mit den CLI-Modi -p oder -i verbinden. Wer eine bestehende lokale CLI-Sitzung vom Telefon aus fernsteuert, muss den ursprünglichen Rechner weiterlaufen und online lassen. Das ist ein anderer Ablauf als die Verlagerung der Ausführung in eine Cloud-Sandbox.[3][9]
Umgebungswahl: Cloud, Actions oder eigener Rechner
GitHub dokumentiert die Optionen Cloud, Actions und Remote. Wo ein Client Cloud und Actions anbietet, ist Cloud die Voreinstellung. Die Umgebung wird beim Sitzungsstart gewählt und lässt sich danach für diese Sitzung nicht wechseln. Benötigt die Aufgabe eine andere Umgebung, muss eine neue Sitzung beginnen.[3][8]
Zum Lesen aller Spalten seitlich scrollen.
| Wahl | Wofür die Dokumentation sie vorsieht | Zu prüfende Grenze |
|---|---|---|
| Cloud-Sandbox | Fortsetzbare Sitzungen, Arbeit über Repositories eines Eigentümers hinweg, keine lokale Rechenleistung nötig | Von GitHub betriebenes Linux; Firewall-Freigaben gelten; keine reinen Actions-Einrichtungsschritte und keine eigenen Runner |
| Actions-Umgebung | copilot-setup-steps.yml, OIDC-Einrichtung, Windows, größere oder selbst betriebene Runner | Actions-spezifische Umgebung; andere Sitzungskontinuität als in der Cloud-Sandbox |
| Lokale CLI oder Copilot-App | Arbeit mit lokalen Dateien oder Werkzeugen | Ausführung auf dem eigenen Rechner; Fernsteuerung erfordert einen eingeschalteten, verbundenen Rechner |
Diese Unterschiede stammen aus GitHubs Umgebungsdokumentation und sind keine Rangliste der Geschwindigkeit.[3][8][9] Eine Cloud-Sandbox beachtet die Firewall-Regeln des Repositorys und der Organisation. Ein neu freigegebener Host erfordert eine neue Sitzung, damit die Änderung greift. Braucht die Aufgabe Actions-Einrichtungsschritte, einen selbst betriebenen Runner oder Windows, wählen Sie Actions vor dem Start.[3]
Hier liegt die Stärke der Übergabe und zugleich ihre Grenze: Eine gespeicherte Cloud-Sitzung erspart den Wiederaufbau des Prompts auf einem anderen Gerät. Lokale Dateien werden dadurch nicht von selbst verfügbar. Laut GitHub können Befehle in der Cloud-Sandbox Dateien auf dem Rechner des Nutzers weder lesen noch verändern. Hängt die Arbeit von nicht eingechecktem lokalem Zustand ab, bringen Sie ihn über einen zulässigen Repository-Ablauf ein oder führen Sie die Aufgabe lokal aus.[3] Unsere frühere Analyse zur Ausführung von Cloud- und lokalen Aufgaben beleuchtet diese Grenze aus einem anderen Produktblickwinkel.
Getrennte Abrechnung: Actions-Dollar sind keine KI-Guthaben
GitHub hat das enthaltene Actions-Rechenguthaben von einer festen Zahl an Minuten auf Standard-Runnern in einen gemeinsamen Dollarwert umgestellt. Berechtigte Jobs privater oder interner Repositories auf GitHub-gehosteten Standard-Runnern sowie Rechenleistung und Arbeitsspeicher von Cloud-Sandboxes verbrauchen diesen Wert. Bei Team und Enterprise Cloud können auch größere gehostete Runner ihn nutzen. Jobs öffentlicher Repositories auf Standard-Runnern und selbst betriebene Runner bleiben nach GitHubs Regeln unabhängig davon kostenlos.[1][4]
Zum Lesen aller Spalten seitlich scrollen.
| GitHub-Accountplan | Enthaltenes Rechenguthaben pro Monat | Neue verbundene Copilot-Cloud-Erfahrung |
|---|---|---|
| Free oder Free für Organisationen | 12 US-Dollar | Erfordert einen kostenpflichtigen Copilot-Plan |
| Pro | 18 US-Dollar | Erfordert einen kostenpflichtigen Copilot-Plan |
| Team | 18 US-Dollar | Erfordert einen kostenpflichtigen Copilot-Plan |
| Enterprise Cloud | 300 US-Dollar | Erfordert einen kostenpflichtigen Copilot-Plan |
Diese Dollarbeträge sind GitHubs ausgewiesene Rechenguthaben für den GitHub-Account, weder enthaltene Copilot-KI-Guthaben noch ein Versprechen, dass jeder Account eine Cloud-Sitzung starten kann.[5] Für Sandboxes nennt GitHub drei Zähler: laufende Rechenzeit zu 0,000024 US-Dollar pro Rechensekunde, zugewiesenen Arbeitsspeicher zu 0,000003 US-Dollar pro GiB-Sekunde und Snapshots angehaltener Sitzungen zu 0,005 US-Dollar pro GiB-Monat. GitHubs Rechenbeispiel bewertet 600 Sekunden mit 4 GiB mit 0,0216 US-Dollar für Rechenleistung und Speicher, zuzüglich eines möglichen Snapshot-Betrags.[4]
Klar ist: Das monatliche Guthaben ist eine gemeinsame Kapazität, kein separater Agentengutschein. Keine berechtigte Nutzungsart hat Vorrang. Ein CI-Job in einem privaten Repository kann das Restguthaben für Sandboxes reduzieren und umgekehrt. Nach Verbrauch des enthaltenen Betrags gelten Zahlungsmethode und Budgets des Accounts. Ohne gültige Zahlungsmethode wird die Nutzung laut GitHub nach Ausschöpfung gesperrt. Ein Sandbox-Budget muss auf Produkt- oder SKU-Ebene angelegt werden. GitHub sagt ausdrücklich, dass das Budget für gebündelte KI-Guthaben die Sandbox-Kosten nicht steuert.[4]
Sicherer übergeben: Zuständigkeit, Budget und Prüfung
Die unbequeme Wahrheit: Reibungsloser Zugriff kann verdecken, wer die Kosten trägt. Eine Sitzung mit Repositories wird deren gemeinsamem Eigentümer berechnet. Ohne Repository wird der gewählte Eigentümer belastet, standardmäßig der persönliche Account. GitHub beschränkt die Arbeit über mehrere Repositories in einer Sandbox auf Repositories desselben Eigentümers.[4] Ein Team sollte diesen Eigentümer prüfen, bevor es eine Chat-Anfrage als kostenloses Experiment behandelt.
Für einen ersten Ablauf wählen Sie ein kleines Issue mit einem klaren Akzeptanzkriterium. Prüfen Sie den kostenpflichtigen Copilot-Zugang und die Organisationsrichtlinie „Copilot in the cloud“.[6] Wählen Sie Cloud, wenn die Aufgabe Gerätewechsel verlangt und die Sandbox die nötigen Abhängigkeiten und Netzwerkzugriffe bietet. Wählen Sie Actions bei den entsprechenden Einrichtungs- oder Runner-Anforderungen. Prüfen Sie den abrechenbaren Repository-Eigentümer und setzen Sie ein Produkt- oder SKU-Budget für Sandboxes. Wenn eine harte Grenze nötig ist, aktivieren Sie „Stop usage when budget limit is reached“. Prüfen Sie anschließend Sitzungsprotokoll, Diff und Testergebnis, bevor Sie einen Pull Request annehmen.[3][4][7]
Berechtigungen bleiben relevant. Laut GitHub steuert die Richtlinie „Copilot in the cloud“ den Cloud-Zugang; bestehende Repository-Ausschlüsse sowie unternehmensweit verwaltete Agentenberechtigungen und MCP-Freigabelisten gelten auch in der neuen Erfahrung. Für entsprechende Werkzeugaufrufe verlangt Copilot eine Freigabe. Das ist eine Verwaltungsgrenze, kein Beweis dafür, dass jede erzeugte Änderung sicher oder richtig ist.[1][7]
Die zentrale Erkenntnis
GitHub erleichtert das Fortsetzen von Agentenarbeit. Der nachhaltige Vorteil entsteht, wenn jede Aufgabe in der passenden Umgebung läuft, ihre tatsächlichen Kosten sichtbar sind und das Ergebnis geprüft wird.
Quellen
Zum Lesen aller Spalten seitlich scrollen.
| Nr. | Quelle | Beleg |
|---|---|---|
| 1 | Ortsunabhängig arbeiten mit einer neuen, verbundenen Copilot-Cloud-Erfahrung, GitHub Changelog, 28. Oktober 2026 | Einführungsstatus, unterstützte Oberflächen, Sandbox- und Actions-Änderungen. |
| 2 | GitHub Universe 2026: Die Weiterentwicklung aller Ebenen des Stacks, GitHub Blog, 28. Oktober 2026 | GitHubs Einordnung der Produkteinführung. |
| 3 | Cloud-Sandboxes für GitHub Copilot, GitHub Docs, geprüft am 30. Oktober 2026 | Ausführungsort, CLI-Option, Lebenszyklus, Firewall und Umgebungsgrenzen. |
| 4 | Abrechnung von Cloud- und lokalen Sandboxes, GitHub Docs, geprüft am 30. Oktober 2026 | Drei Zähler, Preise, gemeinsames Guthaben, Rechnungsempfänger und Budgets. |
| 5 | Enthaltene Produktnutzung je Plan, GitHub Docs, geprüft am 30. Oktober 2026 | Monatliche Dollarwerte der GitHub-Accountpläne. |
| 6 | Copilot-Sitzungen starten, GitHub Docs, geprüft am 30. Oktober 2026 | Berechtigung in zahlenden Plänen und dokumentierte Einstiegspunkte. |
| 7 | Copilot in der Cloud verwalten, GitHub Docs, geprüft am 30. Oktober 2026 | Organisationsrichtlinien und Verwaltung. |
| 8 | GitHub Copilot auf GitHub.com und GitHub Mobile, GitHub Docs, geprüft am 30. Oktober 2026 | Client-, Sitzungs- und Umgebungsmodell sowie Zugriff und Kontinuität. |
| 9 | Fernsteuerung von Copilot-CLI-Sitzungen, GitHub Docs, geprüft am 30. Oktober 2026 | Der ursprüngliche Rechner muss für lokale Fernsteuerung online bleiben. |
Zuletzt aktualisiert: 30. Oktober 2026




