Wann wird Google Jules eingestellt? Export und Umstieg

Wann wird Google Jules eingestellt – und was gilt ab wann?

Google Jules, Googles Coding-Agent für Hintergrundaufgaben, wechselt nach dem 11. November in den Nur-Lese-Modus. Anschließend wird der Dienst vollständig eingestellt. Googles Mitteilung zur Einstellung von Jules trägt das Datum 29. Oktober 2026.

Die Mitteilung nennt weder eine genaue Uhrzeit noch eine Zeitzone für die Umstellung. Auch separate Fristen für die API oder Lizenzen, Termine für Abrechnungen oder Erstattungen sowie die Dauer der Datenspeicherung nach der Schließung bleiben offen. Diese Angaben lassen sich aus der Tabelle nicht ableiten.

Für Entwickler mit einer offenen Fehlerbehebung steht zunächst eine Entscheidung an: Lässt sich die Arbeit noch in Jules abschließen, oder müssen Patch und verbleibende Anforderungen in eine neue Aufgabe überführt werden? Wer ein Entwicklungsteam leitet, muss außerdem Abhängigkeiten aufspüren, die bei einem gewöhnlichen Code-Review nicht auffallen: wiederkehrende Prompts, Einrichtungsschritte, Repository-Berechtigungen und Zugangsdaten.

Wer Jules produktiv einsetzt, sollte jetzt handeln. Teams, deren fertige Änderungen bereits zusammengeführt sind und die keine in Jules gespeicherten Unterlagen mehr brauchen, haben weniger zu übertragen. Wer Agenten erst evaluiert und noch keine Arbeit in Jules liegen hat, kann den Export überspringen und direkt bei der Wahl der Ausführungsumgebung einsteigen. Mit der langfristigen Anbieterwahl zu warten, kann sinnvoll sein. Mit der Sicherung der eigenen Arbeit zu warten, ist es nicht.

Den Kontext sichern, der nicht im Git-Repository steht

Code, Branches und Pull Requests, die bereits in GitHub liegen, bleiben dort. Googles Export umfasst die in Jules gespeicherten Einstellungen, Umgebungsvariablen, Zeitpläne, Repository-Verbindungen, Erinnerungen und Einrichtungsskripte sowie Prompts, Pläne, Protokolle und Patches aus den Sitzungen. Das Vorgehen beschreibt die offizielle Exportanleitung.

Ein Pull Request, kurz PR, ist ein Vorschlag für eine Codeänderung. Er kann den Patch bewahren, ohne festzuhalten, weshalb sich ein Agent dafür entschieden hat. In einem Einrichtungsskript steckt womöglich genau die Paketinstallation, die den Tests noch zum Erfolg fehlte. Eine gespeicherte Erinnerung erklärt vielleicht, warum ein zunächst naheliegendes Refactoring verworfen wurde. Dieses Material sollte geprüft werden, bevor daraus Anweisungen für einen anderen Agenten entstehen.

Der Export dient als Archiv. Für jede offene Aufgabe sollte daraus eine kleinere, gezielte Übergabe entstehen: Repository und Branch, die beabsichtigte Änderung, der bereits erledigte Teil, die noch offenen Abnahmekriterien und der Befehl, mit dem sich der Erfolg nachweisen lässt. Ergänzende Unterlagen lassen sich verlinken; ein vollständiger Gesprächsverlauf gehört nicht in jeden neuen Prompt.

Bei einem Abhängigkeitsupdate reicht beispielsweise „das Update fertigstellen“ nicht aus. Festgehalten werden muss, welcher Kompatibilitätsfehler noch offen ist, welche Dateien geändert wurden und welcher Test den Fehler reproduziert. So erhält der nächste Agent eine klar begrenzte Aufgabe, und beim Review lässt sich ein unvollständiges Ergebnis erkennen und zurückweisen.

Jules exportieren: Googles vorgesehenes Verfahren

Google sieht dafür Jules Tools und den mitgelieferten Export-Prompt vor. Installation und Anmeldung:

npm install -g @google/jules
jules login

Im eigenen Home-Verzeichnis einen CLI-Coding-Agenten öffnen und den ausgeklappten Prompt aus der Mitteilung einfügen. Für Repository-Daten muss zuvor GitHub verbunden werden. Die Ausgabe landet unter ~/jules-export. Dieses Verzeichnis muss privat bleiben, denn env-variables.json enthält die Werte der Zugangsdaten. Zu den Unterlagen je Sitzung gehören summary.md, Aktivitätsprotokolle und Diffs.

Eine Erfolgsmeldung belegt noch keinen vollständigen Export. Die Prüfung des von Google veröffentlichten Exporters zeigt: Sein Sitzungszähler erfasst die aufgelisteten Sitzungen auch dann, wenn das Abrufen der Details einer Sitzung fehlschlägt. Fehler meldet er separat. Zudem gewinnt er Einrichtungsbefehle aus Sitzungsausgaben zurück. Deshalb muss geprüft werden, was tatsächlich in den Dateien steht, bevor ein Repository als übertragbar gilt. Dieser Befund beruht auf der Durchsicht des veröffentlichten Skripts; für diesen Artikel wurde kein Export ausgeführt.

Für die Person, die den Umstieg freigibt, ist dieser Unterschied entscheidend. „Der Befehl ist durchgelaufen“ sagt weniger aus als „Patch, Konfiguration und Aufgabenkontext sind vollständig vorhanden“. Fehlt eine wichtige Unterlage, sollte sie gesichert werden, solange noch Zugriff besteht. Sonst muss der nächste Agent fehlende Zusammenhänge erst rekonstruieren.

Was passiert mit dem Verlauf und der Jules-API?

Verläufe sollten lokal gesichert und Automatisierungen von Jules unabhängig gemacht werden. Die Mitteilung zur Einstellung verspricht weder einen automatischen Import des Verlaufs in einen anderen Agenten noch einen Weiterbetrieb der API nach der Schließung.

Googles öffentliche Dokumentation der Jules-API beschreibt Sitzungen und deren Aktivitäten, darunter das Anlegen von Aufgaben, das Freigeben von Plänen und das Senden von Nachrichten. Daraus entstehen betriebliche Abhängigkeiten: Ein Issue-Bot, der Sitzungen anlegt, braucht einen Ersatz – selbst wenn im Team niemand die Jules-Website öffnet.

Alle Skripte, Workflow-Dateien und Integrationen erfassen, die Jules aufrufen. Dabei festhalten, welche Eingaben sie verwenden, auf welches Erfolgssignal sie warten und wo sie Ergebnisse ablegen. Ein Umstieg, bei dem nur der Prompt geändert wird, kann trotzdem scheitern: etwa weil die alte Integration eine Jules-Sitzungskennung erwartet oder Jules-Aktivitäten abfragt, bis die Arbeit abgeschlossen ist.

Eine weiterhin veröffentlichte API-Schnellstartanleitung verlängert die Lebensdauer des Dienstes nicht. Solange es keinen separaten Zeitplan für die Endpunkte gibt, sollte der Zeitplan des Dienstes die Planungsgrenze bilden. Das Anlegen neuer Aufgaben muss vor dem Wechsel in den Nur-Lese-Modus umgestellt werden. Das ist eine betriebliche Empfehlung, kein zusätzlicher von Google angekündigter API-Termin.

Beim Verlauf sind Sicherung und Fortsetzbarkeit zu unterscheiden. Ein gespeicherter Plan hilft einem anderen Agenten, die Aufgabe zu verstehen. Die bisherige Laufzeitumgebung stellt er nicht wieder her. Arbeiten daher abschließen oder einen nachvollziehbaren Zwischenstand sichern, damit ein anderer Entwickler den nächsten Schritt ohne Zugriff auf Jules reproduzieren kann.

Was übernimmt Antigravity – und was ist schon verfügbar?

Google will die Erfahrungen aus Jules in seine Entwicklungsplattform für Agenten, Antigravity, einfließen lassen. Laut der offiziellen Jules-Ankündigung von Google arbeitet das Unternehmen daran, autonome Hintergrundausführung auf entfernten Rechnern mit der Entwicklungsumgebung von Antigravity zu verbinden. Einen Veröffentlichungstermin dafür nennt Google nicht.

Das verfügbare Produkt unterstützt bereits nützliche Hintergrundarbeit. Die Antigravity App verwaltet parallele Agenten, bündelt Aufgaben in Projects und führt zeitgesteuerte Aufgaben aus. Googles Dokumentation zu Remote Control beschreibt den Browserzugriff auf Sitzungen, die auf eigenen Laptops, Desktoprechnern oder Servern laufen.

Entscheidend ist, wer den Rechner bereitstellt. Remote Control ermöglicht den Zugriff auf eine bereits vorhandene Maschine. Allein daraus folgt nicht, dass Google einen gehosteten Ersatz für Jules bereitgestellt hat. Ein Team, das Wartungsarbeiten über Nacht ausführen lassen möchte, muss wissen, welcher Rechner dafür weiterläuft, wer dessen Abhängigkeiten pflegt und was bei einem Ausfall passiert.

So gelingt der Umstieg: Das Repository in Antigravity öffnen, die benötigte Einrichtung und die Anweisungen rekonstruieren und anschließend eine kleine Aufgabe mit einem eindeutigen Test ausführen. Gehört Fernzugriff zum Plan, müssen Zielrechner und Verfügbarkeit geprüft werden. Den wiederkehrenden Zeitplan erst hinzufügen, wenn dieser Ablauf das Review bestanden hat.

Antigravity passt, wenn seine Entwicklungsumgebung gewünscht ist und das Team den ausführenden Rechner betreiben kann. Lautet die Anforderung dagegen „Laptop zuklappen, ohne dass jemand einen weiteren Rechner warten muss“, sollte jetzt eine gehostete Lösung geprüft werden. Der Umstieg sollte nicht von einem Feature ohne Veröffentlichungstermin abhängen.

Der Überblick zu den Antigravity-Preisen hilft bei Fragen zu Zugang und Kontingenten. Google Antigravity vs Cursor behandelt die davon getrennte Frage, welche Entwicklungsumgebung zur täglichen Arbeit passt.

Hintergrundaufgaben in eine verlässlich betreibbare Umgebung verlagern

Die Laufzeitumgebung sollte vor dem Schreibstil des Agenten feststehen. Gemeint sind der Rechner und die Softwareumgebung, in denen eine Aufgabe ausgeführt wird. Für diesen Umstieg zählt vor allem, ob das Team die Umgebung selbst betreibt, der Anbieter sie hostet oder die Automatisierung über GitHub Actions läuft.

Die folgenden Wege beruhen auf der aktuellen Dokumentation der Anbieter. Sie sind Ausgangspunkte für den Umstieg. Daraus folgt weder ein identischer Funktionsumfang noch ein gemeinsames Importformat mit Jules.

OpenAI Codex Cloud: Gehostete Aufgaben mit wiederverwendbarer Einrichtung

OpenAI Codex Cloud ist ein gehosteter Coding-Agent, der weiterarbeiten kann, während der eigene Rechner im Ruhezustand ist. Jede Aufgabe erhält einen eigenen Arbeitsbereich. Änderungen und Testergebnisse lassen sich prüfen, bevor ein Commit erstellt oder ein PR geöffnet wird. Die offizielle Anleitung zu Codex Cloud beschreibt die derzeitige Einrichtung.

So gelingt der Umstieg: In ChatGPT Work in > Cloud wählen und eine Umgebung erstellen oder auswählen. Die GitHub-Repositories verbinden, Codex das Projekt vorbereiten lassen, die Prüfungen zur Einrichtung durchsehen und die Umgebung veröffentlichen. Anschließend mit den bereinigten Übergabeunterlagen aus Jules eine klar begrenzte Aufgabe starten und deren Änderungen und Testergebnisse prüfen.

Die Hürde ist der Zugriff aus der Umgebung. Ein erfolgreicher lokaler Test sagt wenig aus, wenn die Cloud-Aufgabe die Paket-Registry oder einen benötigten Dienst nicht erreicht. Die erforderlichen Netzwerkziele und Zugangsdaten müssen in den Umgebungseinstellungen hinterlegt werden. Danach ist derselbe Test dort auszuführen.

Codex passt, wenn vor allem eine gehostete Aufgabenwarteschlange mit wiederverwendbarer Projekteinrichtung gesucht wird. Für den ersten Versuch eignet sich eine Aufgabe, deren Ergebnis schnell auf Richtigkeit geprüft werden kann, statt einer offenen Neufassung ohne klare Grenzen. Der ausführlichere Vergleich von Codex und Claude Code behandelt die Wahl des Arbeitsablaufs über die Jules-Abschaltung hinaus.

Claude Code: Cloud-Sitzungen oder Automatisierung im Repository

Anthropics Claude Code bietet Cloud-Sitzungen, die nach dem Zuklappen des Laptops weiterlaufen. Daneben gibt es eine separate GitHub-Actions-Integration für Repository-Workflows. Welcher Weg passt, hängt davon ab, ob eine interaktive Aufgabenübergabe oder ein automatischer Auslöser ersetzt werden soll.

Für Cloud-Sitzungen: Das Repository verbinden, Einrichtung, Netzwerkzugriff und Variablen der Cloud-Umgebung konfigurieren und eine klar abgegrenzte Aufgabe starten. In einem angemeldeten Claude Code-Terminal startet claude --cloud die Arbeit in der Cloud. Beim üblichen Vorgehen mit einem GitHub-Klon muss der Branch zuvor gepusht werden, damit die Sitzung die vorgesehenen Commits erhält. Details stehen in Claudes Anleitung zu Cloud-Sitzungen.

Die Hürde liegt im gemeinsam genutzten Kontingent und im Zugang: Cloud-Sitzungen verbrauchen das Claude-Nutzungskontingent des Kontos, und Berechtigungen der Organisation können ihre Nutzung einschränken. Dass die private Einrichtung eines Entwicklers funktioniert, belegt noch nicht, dass das Firmenkonto dieselbe Arbeitslast ausführen kann.

Für GitHub Actions: Ein Repository-Administrator kann in Claude Code /install-github-app ausführen, die Authentifizierung einrichten und den erzeugten Workflow-PR prüfen. Zunächst mit einer ausdrücklichen @claude-Anfrage beginnen. Anschließend den wiederkehrenden oder ereignisgesteuerten Job ergänzen, der ersetzt werden soll. Anthropic dokumentiert die Anforderungen an App, Zugangsdaten und Workflow in seiner Anleitung zu GitHub Actions.

Hier ist die Zuständigkeit für den Workflow die Hürde. Jemand muss Auslöser, Zugangsdaten und Berechtigungen pflegen und erkennen können, ob die Einrichtung oder die eigentliche Programmieraufgabe gescheitert ist. Actions passt, wenn ein Repository-Ereignis der natürliche Ausgangspunkt ist. Unser Leitfaden zu Claude Code mit GitHub Actions erläutert dieses Betriebsmodell.

Der Coding-Agent von GitHub Copilot: Aufgaben direkt in GitHub übergeben

Der Coding-Agent von GitHub Copilot übernimmt Implementierung und Tests im Hintergrund innerhalb des GitHub-Workflows. Die aktuelle Dokumentation unterscheidet zwischen Cloud-Sandboxen und GitHub-Actions-Umgebungen. Deshalb muss geprüft werden, welche Umgebung für die jeweilige Aufgabe ausgewählt ist. Details beschreibt Copilot auf GitHub.

So gelingt der Umstieg: Den Zugang über den gebuchten Tarif und die Richtlinien der Organisation prüfen, Repository und Branch auswählen und Copilot eine Aufgabe mit Abnahmekriterien und der Aufforderung geben, einen PR zu erstellen. Vor dem Zusammenführen die vorgeschlagenen Änderungen und Testnachweise kontrollieren. Die Aufgabenbeschreibung aus der Jules-Bestandsaufnahme unverändert übernehmen, damit sich beurteilen lässt, ob der Ersatz sie erfüllt hat.

Die Hürde hängt von der Ausführungsumgebung ab: GitHub-Actions-Sitzungen ändern ein einzelnes Repository, während Cloud-Sandbox-Sitzungen mehrere Repositories umfassen können. Beide arbeiten auf einem einzelnen Branch und öffnen einen einzelnen PR pro Aufgabe. Erfordert eine Migration koordinierte Änderungen über mehrere Branches hinweg, muss sie in separat prüfbare Aufgaben aufgeteilt werden.

Copilot passt, wenn die anstehenden Reviews und die Zuständigkeiten für Aufgaben bereits in GitHub organisiert sind. So bleibt die Übergabe nah an Issue und PR. Die Umgebung und die Anweisungen, die bisher in Jules lagen, müssen trotzdem neu aufgebaut werden.

Was zu viel versprochen klingt: Ein Export ist noch kein automatischer Umzug

Die irreführende Abkürzung besteht darin, „Jules geht in Antigravity auf“ als Plan für die Übertragung des eigenen Kontos zu verstehen. Googles Aussagen beschreiben die Produktrichtung und einen Datenexport. Sie versprechen nicht, dass aktive Sitzungen, Zeitpläne oder Erinnerungen in einem Ersatz sofort einsatzbereit auftauchen.

Ebenso verkürzt wäre es, Browserzugriff als Beleg für eine Ausführung in der Cloud zu betrachten. Ein Browser kann einen selbst betriebenen Rechner steuern oder eine vom Anbieter gehostete Maschine. Die Oberflächen sehen womöglich ähnlich aus, doch die Verantwortung für den laufenden Betrieb liegt jeweils woanders.

Als praktische Abnahmeregel gilt: Der Ersatz muss die benötigte Einrichtung reproduzieren, eine klar begrenzte Aufgabe abschließen, seine Prüfungen offenlegen und eine Änderung liefern, die sich im Review beurteilen lässt. Dass ein Tool dasselbe Repository erkennt oder einen plausiblen Plan erstellt, reicht für die Auswahl nicht aus. Ein Plan kann belegen, dass die Aufgabe verstanden wurde. Erst der erfolgreich durchlaufene Arbeitsablauf belegt, dass der Umstieg funktioniert.

Für die Entwicklungsleitung wird die Entscheidung dadurch überschaubarer. Vor der Abschaltung müssen nicht sämtliche künftigen Vorlieben bei Coding-Tools geklärt sein. Benötigt wird ein verifizierter Weg für die Aufgaben, die sonst zum Stillstand kämen – mit einer verantwortlichen Person, die Fehler diagnostizieren kann.

Die Checkliste für diese Woche

Zunächst zählt ein funktionierender Ersatz. Danach lässt sich der Ansatz auf die übrigen offenen Aufgaben übertragen.

• Bestand erfassen: Jules-Repositories, offene Sitzungen, wiederkehrende Aufgaben und API-Aufrufer auflisten. Jedem fortzuführenden Job eine verantwortliche Person und ein Zielsystem zuordnen.
• Sichern: Googles Exportverfahren ausführen, Fehlermeldungen und wichtige Dateien prüfen und das Originalarchiv privat aufbewahren.
• Abschließen oder Zwischenstand sichern: Offene Patches prüfen. Für jede fortzuführende Aufgabe einen nachvollziehbaren Branch, eine verständliche Anforderung und einen Test hinterlassen.
• Neu einrichten: Abhängigkeiten, Anweisungen, Netzwerkzugriff und Zugangsdaten der gewählten Laufzeitumgebung konfigurieren. Geheime Werte gehören nicht in gewöhnliche Aufgabennotizen.
• Funktionsfähigkeit nachweisen: Eine kleine Aufgabe durch Einrichtung, Implementierung, Tests und menschliches Review führen. Neben dem erfolgreichen PR auch das Verhalten im Fehlerfall prüfen.
• Umstellen: Wiederkehrende Auslöser erst übertragen, wenn der Ersatz funktioniert. Doppelte Aufgabeneingänge unterbinden und überholte Zugriffsrechte entfernen, sobald sie nicht mehr gebraucht werden.

Der konkrete Schritt für Montag: ein aktives Repository auswählen, seinen Jules-Kontext exportieren und eine kleine Aufgabe mit dem Ersatz bis zum abgeschlossenen Review durchlaufen lassen. Daraus entsteht ein brauchbares Muster, das sich wiederholen lässt, bevor der Dienst keine neuen Aufgaben mehr annimmt.

Den Newsletter abonnieren für praktische Anleitungen zu Veränderungen bei Entwicklertools.