Microsoft hat Project Zenith am 4. September 2026 vorgestellt. Auf den ersten Blick klingt das nach einem weiteren Windows-Branding. Tatsächlich ist Zenith keine neue allgemeine Windows-Edition, sondern eine vorkonfigurierte „ready-to-code“-Erfahrung für leistungsstarke Entwicklergeräte.
Die spannendere Seite daran ist nicht, dass Visual Studio Code und Windows Terminal schon griffbereit sind. Interessanter ist, worauf Microsoft mit der Hardwareklasse und der lokalen KI hinauswill.
Was Project Zenith überhaupt ist
Microsoft beschreibt Project Zenith als Windows-Erfahrung für Geräte mit mindestens 64 GB Unified Memory und 250 GB/s Speicherbandbreite. Die ersten Systeme sollen mit AMD Ryzen AI Halo kommen, weitere Geräte von OEM- und Silicon-Partnern sollen folgen.
Auf diesen Rechnern ist Windows direkt für Entwicklung vorkonfiguriert. Dateiendungen und versteckte Dateien sind sichtbar, Long Paths sind aktiviert, der vollständige Pfad kann im Explorer angezeigt werden und einige der typischen Hinweise und Empfehlungen sind abgeschaltet.
Das ist sinnvoll, aber kein Grund, allein deshalb einen neuen Rechner zu kaufen. Vieles davon stellen Entwickler auf einem frischen Windows-System ohnehin selbst ein.
Der interessantere Teil: 30B+-Modelle lokal
Microsoft sagt, dass Project-Zenith-Geräte Modelle mit mehr als 30 Milliarden Parametern lokal und ohne laufende Token-Abrechnung ausführen können.
Noch interessanter finde ich einen Satz aus der Ankündigung: Frontier-Modelle sollen die schwierigen Probleme übernehmen, während der Rest lokal laufen kann.
Das ist ziemlich nah an dem, was wir bei Quavon ohnehin zunehmend sinnvoll finden. Nicht jede Aufgabe braucht dasselbe Modell.
Für eine komplizierte Änderung über mehrere Services hinweg kann ein starkes Cloud-Modell sinnvoll sein. Für kleinere Arbeiten wie Code erklären, Tests zusammenfassen, Diffs prüfen oder einfache Refactors vorbereiten ist ein lokales Modell möglicherweise völlig ausreichend.
Dann wird nicht mehr jeder kleine Schritt zu einem weiteren API-Aufruf.
Lokal heißt aber nicht automatisch besser
„30B+ lokal“ klingt auf dem Papier gut. Für die tägliche Entwicklung sagt diese Zahl allein aber wenig aus.
Entscheidend wäre, wie schnell ein solches Modell tatsächlich arbeitet und wie oft ich anschließend korrigieren muss. Ein Modell, das lokal läuft, aber für einen brauchbaren Patch dreimal so lange braucht oder regelmäßig unnötige Änderungen macht, spart am Ende nicht unbedingt etwas.
Ich würde Zenith deshalb nicht anhand einer Demo beurteilen, sondern an einem echten Repository.
Ein paar Wochen normale Arbeit wären wesentlich aussagekräftiger: Bugs untersuchen, kleinere Features umsetzen, Tests reparieren, Dokumentation ergänzen und zwischendurch Aufgaben lösen, für die man normalerweise ein Cloud-Modell aufrufen würde.
Danach lässt sich messen, wie viele dieser Aufgaben tatsächlich lokal geblieben sind.
Das erinnert an HydraFusion – nur auf Hardware-Ebene
GitHub verfolgt mit Project HydraFusion gerade einen ähnlichen Gedanken auf Modell-Ebene. Nicht jede Aufgabe geht an dasselbe Modell. Ein Router kann entscheiden, ob ein günstigeres Modell reicht, ob ein Review nötig ist oder ob auf ein stärkeres Modell eskaliert werden soll.
Project Zenith ergänzt diese Idee um eine weitere Ebene: lokal oder Cloud.
Eine kleine Aufgabe könnte lokal laufen. Wenn sie zu kompliziert wird, übernimmt ein stärkeres Cloud-Modell. Für einen Entwickler wäre dann idealerweise gar nicht mehr wichtig, welches Modell gerade arbeitet, solange Qualität, Kosten und Kontrolle stimmen.
Genau diese Orchestrierung finde ich spannender als die Frage, welches Modell diese Woche auf Platz eins in irgendeinem Benchmark steht.
Microsoft baut Zenith auch für Agenten
Project Zenith wird nicht nur als AI-PC vermarktet. Microsoft ordnet die Geräte ausdrücklich in seine Arbeit an agentischen Systemen unter Windows ein.
Das Unternehmen nennt dabei unter anderem OS-enforced identity, Microsoft Execution Containers und zentrale Verwaltungsmöglichkeiten für Agenten.
Das passt zu einem Problem, das mit Coding-Agenten schnell praktisch wird. Ein Agent mit Zugriff auf lokale Dateien, Repositories, Terminal, Container und interne Tools ist etwas anderes als Autocomplete.
Wenn so ein System einen falschen Weg nimmt, ist nicht nur die Antwort falsch. Es kann Dateien verändern oder Befehle ausführen.
Für uns wäre bei so einer Plattform deshalb mindestens genauso interessant, wie Rechte begrenzt und Aktionen nachvollziehbar gemacht werden, wie schnell das lokale Modell ist.
Was mir an Zenith gefällt
Die Hardware-Anforderung wirkt im ersten Moment hoch, ergibt aber Sinn, wenn Microsoft ernsthaft größere Modelle lokal betreiben will. 64 GB Unified Memory und 250 GB/s Speicherbandbreite sind keine typische Office-Laptop-Konfiguration.
Damit wird auch klar, dass Microsoft hier nicht einfach einen Copilot-Button auf einen normalen Rechner klebt. Zenith zielt auf Entwickler, die lokale Modelle tatsächlich als Teil ihres Workflows einsetzen sollen.
Auch der Fokus auf gute Defaults ist nicht verkehrt. Ein neuer Entwicklerrechner besteht heute immer noch aus erstaunlich viel Setup, obwohl viele Einstellungen und Tools bei fast jedem gleich aussehen.
Wo ich noch skeptisch bin
Project Zenith klingt im Moment stärker als Strategie als als fertige neue Gerätekategorie.
Die ersten Geräte sind noch nicht breit im Markt. Preise und konkrete Modelle werden darüber entscheiden, wie relevant das Ganze außerhalb größerer Entwicklerteams überhaupt wird.
Und ein Teil des Konzepts lässt sich heute schon selbst nachbauen: leistungsstarke Hardware, WSL, VS Code, lokale Modelle und ein eigener Router zwischen lokaler und Cloud-Inferenz.
Der eigentliche Mehrwert müsste deshalb darin liegen, dass Microsoft diese Teile sauber miteinander verbindet und die lokale Agenten-Ausführung unter Windows besser absichert als ein selbst zusammengestellter Stack.
Was ich damit bei Quavon testen würde
Mich würde zuerst interessieren, wie viel tägliche Arbeit wirklich lokal bleiben kann.
Nicht mit synthetischen Aufgaben, sondern mit echten Issues aus unseren Projekten. Kleine Backend-Änderungen, Frontend-Fixes, Testfehler, Refactors und Aufgaben, bei denen ein Modell mehrere Dateien verstehen muss.
Dann würde ich vergleichen: Wie oft mussten wir doch auf ein Cloud-Modell wechseln? Wie lange hat die lokale Lösung gedauert? Wie oft musste ein Mensch nacharbeiten? Und was kostet der Workflow am Ende wirklich – inklusive der teureren Hardware?
Wenn ein lokales Modell einen großen Teil der normalen Entwicklungsarbeit zuverlässig abfängt, wird Project Zenith interessant.
Nicht weil Microsoft damit den nächsten „AI-PC“ erfunden hätte, sondern weil sich die Kosten- und Architekturfrage von Entwickler-KI verändert.
Dann wäre die Entscheidung nicht mehr nur: Welches Cloud-Modell benutzen wir?
Sondern: Welche Arbeit muss überhaupt noch in die Cloud?
Quellen
Microsoft Windows Developer Blog, 4. September 2026: „Announcing Project Zenith: The ready-to-code Windows experience on developer-class devices“ https://blogs.windows.com/windowsdeveloper/2026/09/04/announcing-project-zenith-the-ready-to-code-windows-experience/
The Verge, 4. September 2026: „Microsoft's Project Zenith is a 'distraction-free Windows experience' for developers“ https://www.theverge.com/news/990051/microsoft-project-zenith-windows-developers