// Tools & Entwicklung 22.10.2026 · 15:10 Uhr 7 Min. Lesezeit

OpenCode 2.1 verschiebt API-Daten und erweitert Terminalfunktionen

Mindverse News

KI-gestützt erstellt 2 Quellen Originalmeldung: heise.de Arbeitsweise

KI-generierte Illustration: OpenCode 2.1 verschiebt API-Daten und erweitert Terminalfunktionen — KI-generierte Illustration

Das Wichtigste in Kürze

OpenCode 2.1 verlegt anbieterspezifische Daten in Integrationen nach „tool.native“; bisherige Felder entfallen dort. [1]
Änderungen an Gesprächsverdichtung betreffen Metadaten, Nachrichtenkontext und Ereignisnamen, nicht aber die Lesbarkeit gespeicherter Sitzungen. [1]
Windows-Systeme mit x64- und ARM64-Prozessoren erhalten dauerhafte Pseudo-Terminals; eine Aufgabenliste ist experimentell zuschaltbar. [1]
Die Version baut auf OpenCode 2.0 auf, das Terminal, Web und Desktop an einen gemeinsamen lokalen Hintergrunddienst angebunden hat. [1]
OpenCode unterstützt laut Projektseite Modelle unterschiedlicher Anbieter und lokale Modelle; diese Flexibilität ist vom konkreten 2.1-Update zu unterscheiden. [2]

// Inhalt · 9 Abschnitte

Ein Update mit Folgen für eingebundene Werkzeuge
Neue Ablage für anbieterspezifische Zustände
Gesprächsverdichtung erhält ein neues Datenmodell
Windows bekommt dauerhafte Pseudo-Terminals
Aufgabenliste bleibt ausdrücklich experimentell
Länger laufende Befehle und Verbindungsdauer
OpenCode 2.0 schuf die gemeinsame Dienstarchitektur
Code Mode hält Zwischenergebnisse aus dem Gespräch
Versionssprung erfordert kontrollierte Prüfung
Quellen

Ein Update mit Folgen für eingebundene Werkzeuge

OpenCode 2.1 bringt neben sichtbaren Änderungen an der Terminaloberfläche vor allem Anpassungen an den Schnittstellen für SDK, HTTP-Nachrichten, Ereignisse und Plug-ins. Das ist insbesondere für Teams relevant, die den Coding-Agenten nicht nur direkt im Terminal nutzen, sondern seine Funktionen in eigene Entwicklungswerkzeuge oder Abläufe eingebunden haben. Heise beschreibt die Änderungen als Umstellungsbedarf für solche Integrationen. [1]

OpenCode ist ein quelloffener KI-Coding-Agent, der mit Sprachmodellen und Werkzeugen an Code arbeiten kann. Er ist über verschiedene Oberflächen nutzbar; die Projektseite nennt unter anderem Terminal, Desktop-Anwendung und IDE-Erweiterung. Damit besteht die technische Aufgabe nicht allein darin, eine neue Benutzeroberfläche auszuprobieren: Entscheidend ist, ob bestehende Verbindungen zu Sitzungen, Nachrichten und Plug-ins weiterhin die erwarteten Daten erhalten. [1][2]

Die Version 2.1 ist dabei von der übergeordneten Modellfrage zu trennen. OpenCode führt laut Projektseite Modelle verschiedener Anbieter zusammen und unterstützt auch lokale Modelle; diese Breite beschreibt das Produktangebot, nicht eine neue Funktion, die erst mit Version 2.1 hinzugekommen wäre. [2]

Für direkte Anwender nennt Heise dauerhafte Windows-Terminalsitzungen und eine experimentelle Aufgabenliste als sichtbare Neuerungen. [1]
Für Betreiber eigener Integrationen liegen die wichtigsten Änderungen in den API-Datenfeldern und Ereignisnamen. [1]

Neue Ablage für anbieterspezifische Zustände

Die markanteste Integrationsänderung betrifft Daten, die OpenCode bei späteren Modellaufrufen wiederverwenden kann. In den SDK-, HTTP- und Plug-in-APIs sollen diese anbieterspezifischen Informationen künftig unter „tool.native“ liegen. Die bisherigen Felder „providerState“ und „providerResultState“ entfallen an diesen Stellen. Wer Code gegen die alten Felder geschrieben hat, muss die Verarbeitung entsprechend umstellen. [1]

Technisch betrachtet verändert sich damit der erwartete Ort, an dem eine Integration Zustandsinformationen findet oder übergibt. Ein Adapter, der bislang auf die bisherigen Feldnamen zugreift, kann mit der neuen Struktur nicht unverändert arbeiten. Das ist eine Analyse der beschriebenen API-Änderung; der Bericht nennt keine konkreten Drittanbieter-Integrationen oder Fehlerfälle. [1]

Für die Datenhaltung fällt die Umstellung laut Heise weniger tiefgreifend aus: Bereits gespeicherte Sitzungen und ältere Importe bleiben lesbar, eine Migration der Datenbank sei nicht erforderlich. Das grenzt die Änderung von einem umfassenden Umbau persistierter Bestandsdaten ab, beseitigt aber nicht den Anpassungsbedarf in laufenden Integrationen. [1]

SDK-, HTTP- und Plug-in-Code auf Zugriffe auf „providerState“ und „providerResultState“ prüfen. [1]
Verarbeitung auf die neue Ablage unter „tool.native“ ausrichten. [1]
Sitzungsdaten und Integrationscode getrennt betrachten: Lesbarkeit alter Sitzungen bedeutet nicht, dass alte API-Aufrufe unverändert bleiben. [1]

Gesprächsverdichtung erhält ein neues Datenmodell

Eine zweite Gruppe von Schnittstellenänderungen betrifft die Verdichtung langer Gespräche. Bei neuen Zusammenfassungen verweist OpenCode über „metadata.keepID“ auf Nachrichten, deren ursprünglicher Wortlaut erhalten bleibt. Der Text dieser Nachrichten wird damit nicht nochmals in der Zusammenfassung gespeichert. [1]

Auch der Nachrichtenkontext, den OpenCode für die weitere Verarbeitung durch einen Modellanbieter nutzt, bekommt einen neuen Ablageort: Er liegt künftig unter „native.messages“ statt unter „providerContext“. Wer diesen Kontext ausliest oder weiterverarbeitet, muss deshalb die neue Struktur berücksichtigen. [1]

Für Integrationen, die den Verdichtungsprozess beobachten, ändern sich außerdem die Ereignisse. Die neuen Bezeichnungen lauten „session.compaction.started“ und „session.compaction.ended“; das Ereignis „session.compacted“ entfällt. Ein Listener, der ausschließlich auf den alten Namen reagiert, würde die beschriebenen neuen Ereignisse folglich nicht über diesen bisherigen Namen erkennen. Diese Konsequenz ergibt sich aus der Umbenennung. [1]

Zusammenfassungen verweisen über „metadata.keepID“ auf beibehaltene Nachrichten. [1]
Der Modellkontext wechselt von „providerContext“ zu „native.messages“. [1]
Ereignisabonnements müssen die neuen Start- und Endereignisse berücksichtigen. [1]

Windows bekommt dauerhafte Pseudo-Terminals

Anwenderseitig sichtbarer ist die Unterstützung dauerhafter Pseudo-Terminals auf Windows-Systemen mit x64- und ARM64-Prozessoren. Damit soll dort derselbe Terminal-Workflow möglich werden, den OpenCode nach Heises Bericht bereits auf macOS und Linux bietet. [1]

Ein Pseudo-Terminal stellt einer Anwendung eine Terminalumgebung bereit, über die sie Prozesse und deren Ein- und Ausgabe steuern kann. „Dauerhaft“ ist in diesem Zusammenhang relevant, weil die Sitzung über den einzelnen Befehl hinaus bestehen bleiben soll. Für Entwicklungsteams kann das die Arbeit über unterschiedliche Betriebssysteme hinweg vereinheitlichen; aus der beschriebenen Funktion allein folgt jedoch keine Aussage über identische Leistung oder vollständige Gleichheit aller Plattformdetails. [1]

Die Unterstützung beider Windows-Prozessorarchitekturen ist für gemischte Gerätebestände relevant. Eine Organisation kann daraus aber nicht ohne weitere Prüfung ableiten, dass jede bestehende Windows-Konfiguration oder jede angeschlossene Terminalintegration abgedeckt ist: Die Quelle benennt ausdrücklich x64 und ARM64, nicht alle denkbaren Systemumgebungen. [1]

Aufgabenliste bleibt ausdrücklich experimentell

OpenCode 2.1 enthält zudem ein zuschaltbares Werkzeug zur Aufgabenverwaltung. Wird in der Konfiguration die Einstellung „experimental.todo“ auf „true“ gesetzt, kann das Modell mit dem Werkzeug „todowrite“ eine Aufgabenliste führen. OpenCode zeigt diese Liste innerhalb der Sitzung und in der Seitenleiste an. [1]

Die Kennzeichnung als experimentell ist für den Einsatz im Unternehmen wichtig: Heise beschreibt eine aktivierbare Funktion, aber keine allgemein eingeführte, stabile Projektmanagementkomponente. Die Aufgabenliste ist daher als Sitzungsfunktion des Coding-Agenten zu verstehen; eine Anbindung an Ticketsysteme oder eine Synchronisation mit unternehmensweiten Aufgabenbeständen ist in den vorliegenden Angaben nicht belegt. [1]

Für Teams kann die Anzeige von Arbeitsschritten im Gespräch den Überblick über längere Agentenaufgaben verbessern. Das ist eine mögliche praktische Folge, kein in den Quellen nachgewiesenes Produktivitätsergebnis. Vor einem breiteren Einsatz sollten Sie deshalb zunächst prüfen, ob das Verhalten der experimentellen Funktion zu den internen Abläufen passt. [1]

Länger laufende Befehle und Verbindungsdauer

Eine weitere Änderung betrifft Befehle, die in der Terminaloberfläche länger laufen. Ihre Verbindung soll nicht mehr am bisherigen Standard-Fetch-Timeout von fünf Minuten scheitern, den die eingesetzte Laufzeitumgebung Bun mitbrachte. Heise führt die Anpassung als Teil von OpenCode 2.1 auf. [1]

Das ist vor allem für Arbeitsabläufe relevant, bei denen ein Befehl nicht innerhalb weniger Minuten abgeschlossen ist. Die Änderung betrifft laut Bericht die Verbindung in der Terminaloberfläche; sie belegt weder, dass beliebig lange Prozesse garantiert durchlaufen, noch dass Zeitüberschreitungen an anderen Stellen ausgeschlossen sind. Für einen produktiven Einsatz bleibt es daher sinnvoll, die konkret verwendeten Befehle und ihre Laufzeiten zu testen. [1]

OpenCode 2.0 schuf die gemeinsame Dienstarchitektur

Die Änderungen in Version 2.1 bauen auf einer größeren Architekturentscheidung in OpenCode 2.0 auf. Nach der Projektvorstellung, auf die Heise verweist, starten Terminaloberfläche, Weboberfläche und Desktop-Anwendung nicht mehr jeweils einen eigenen Agentenprozess. Stattdessen greifen die Oberflächen auf einen gemeinsamen lokalen Hintergrunddienst zu. [1]

Der Dienst kann laut Bericht auch von Skripten über einen neuen Client angesprochen werden. Die überarbeitete API erlaubt unter anderem, Sitzungen zu verwalten und in Git-Worktrees zu verschieben. Damit wird OpenCode nicht nur als interaktive Oberfläche positioniert, sondern zugleich als lokal erreichbare Grundlage für weitere Werkzeuge. [1]

Für Unternehmen ist diese Trennung zwischen Oberfläche und Hintergrunddienst architektonisch bedeutsam: Mehrere Zugangswege können auf dieselbe Dienstebene zielen. Das kann die Einbindung in bestehende Entwicklungsumgebungen erleichtern, erfordert aber klare Zuständigkeiten für API-Kompatibilität und Betrieb. Diese Einordnung ist eine Analyse der beschriebenen Architektur; die Quellen nennen keine konkreten Unternehmensinstallationen oder Betriebsmodelle. [1]

Code Mode hält Zwischenergebnisse aus dem Gespräch

Zu OpenCode 2.0 gehört außerdem der „Code Mode“. Dabei kann der Agent Werkzeugaufrufe in einem Skript verknüpfen, anstatt jedes einzelne Ergebnis wieder an das Sprachmodell zu übermitteln. Heise erläutert dies am Beispiel einer Ticketsuche: Mehrere Einträge könnten abgerufen und anschließend nur passende Titel zurückgegeben werden. [1]

Der technische Unterschied liegt darin, wo Zwischenergebnisse verarbeitet werden. Wenn ein Skript mehrere Aufrufe bündelt und nur die benötigte Auswahl an das Modell zurückgibt, verbleibt ein Teil der Verarbeitung außerhalb des Gesprächskontexts. Das kann die Menge an Zwischeninformationen im Modellkontext verringern; die Quelle liefert jedoch keine Messwerte zu Kosten, Geschwindigkeit oder Qualität. [1]

Die grundsätzliche Modellvielfalt des Produkts ist davon getrennt zu betrachten. Die OpenCode-Projektseite wirbt mit Unterstützung für mehr als 75 LLM-Anbieter einschließlich lokaler Modelle und nennt auch Anbieter wie Anthropic, OpenAI und Google. Das ist eine Aussage des Projekts über die Plattform, keine unabhängige Prüfung aller Kombinationen oder eine Garantie, dass jedes Modell für jede Aufgabe gleich geeignet ist. [2]

Versionssprung erfordert kontrollierte Prüfung

Die Umstellung auf Version 2.0 war nach Heises Bericht bereits mit inkompatiblen Änderungen verbunden: Plug-ins aus der 1.x-Reihe funktionieren nicht unverändert, zudem wurde die Server-API neu gefasst. Version 2.1 setzt mit den geänderten Datenfeldern und Ereignissen an weiteren Integrationspunkten an. [1]

Für Verantwortliche ergibt sich daraus eine gestufte Migrationsaufgabe. Zuerst sollten Sie erfassen, welche internen Skripte, Plug-ins und Ereignisabonnements die betroffenen Felder oder den bisherigen Verdichtungsablauf nutzen. Danach lässt sich in einer Testumgebung prüfen, ob Sitzungszugriffe, Kontextverarbeitung und Terminalbefehle mit der neuen Version wie erwartet funktionieren. Diese Empfehlungen leiten sich aus den dokumentierten Schnittstellenänderungen ab; die Quellen beschreiben keinen offiziellen Migrationsleitfaden. [1]

Wichtig ist die Trennung zwischen Datenbestand und Laufzeitkompatibilität. Dass alte Sitzungen und Importe weiterhin lesbar sind und keine Datenbankmigration nötig ist, reduziert den Aufwand auf der Persistenzseite. Es ersetzt aber nicht die Prüfung eigener Integrationen, deren API-Verhalten sich durch neue Feldpfade und Ereignisnamen ändert. [1]

Für die Modellauswahl schließlich bietet OpenCode laut Projektseite eine gemeinsame Arbeitsumgebung für unterschiedliche Anbieter und lokale Modelle. Die organisatorischen Fragen zu Anbieterzugang, Abrechnung, Datenschutz und Modellfreigaben bleiben davon unabhängig zu bewerten. Die vorliegenden Angaben belegen die technische Auswahlbreite, nicht aber eine einheitliche Governance oder gleichartige Datenschutzbedingungen über alle Anbieter hinweg. [2]

Quellen

[1] OpenCode 2.1: Ein Coding-Agent, viele Modelle | heise online — https://www.heise.de/news/OpenCode-2-1-Ein-Coding-Agent-viele-Modelle-11497016.html (abgerufen am 2026-10-22)
[2] OpenCode | The open source AI coding agent — https://opencode.ai/ (abgerufen am 2026-10-22)