Gebaut, um Anweisungen von ChatGPT, Claude und Gemini entgegenzunehmen

Die Ära von „dieses Produkt läuft auf dem Modell dieses einen Anbieters" ist kurz. RakuAI ist so gebaut, dass jedes Modell — ChatGPT, Claude, Gemini oder Ihr eigenes — eine AR-Erfahrung in Echtzeit steuern kann. Bringen Sie das beste Modell mit. Die Runtime ist bereit.

Die meisten Game-Engines, die heute ein Cloud-LLM integrieren, tun das so, wie man es erwarten würde. Ein Modell wird als Chat-Panel in den Editor geschraubt. Man tippt in das Chat-Panel. Das Panel schreibt etwas Inhalt oder etwas Code. Die Runtime, die keine Ahnung hat, dass irgendetwas davon passiert ist, führt das entstandene Artefakt später aus.

Das ist nicht, was Raku tut. Raku wird so gebaut, dass es Anweisungen von einem Cloud-LLM als Runtime-Anliegen entgegennimmt, nicht als Autoren-Komfortfunktion. Die Arbeit dieses Wochenendes hat das explizit gemacht.

Was gelandet ist

Hundertachtzehn Commits über die Runtime dieses Wochenende. Die Schlagzeilen-Stücke:

• Ein XRAssistantService, der Cloud-LLM-Antworten als erstklassiges Runtime-Feature in die Voice-Pipeline einbindet
• Augenverfolgtes foveiertes Rendering mit Multi-Profil-Performance-Optimierung
• Ein OpenXR-XR_EXT_eye_gaze_interaction-Provider
• Hand-Tracking und Gestenerkennung für die XR-Runtime
• Ganzkörper-Tracking mit einem 71-Gelenke-Skelett
• Fixierungserkennung und Verweildauer-Timer in der Eye-Tracking-Infrastruktur
• Hochauflösender Passthrough, Tiefenerfassung und Beleuchtungsschätzung
• Eine ausgelagerte Wi-Fi-7-Rendering-Pipeline mit Host-Server und Latenzüberwachung
• Ein Low-Latency-Delta-Kanal für Echtzeit-Multiplayer-AR-Pose- und Zustandssynchronisation
• Submillimeter-Anchor-Service für Android XR
• ARCore-Sensorbrücke für Android-Geräte ohne den Android-XR-Stack
• Ein Multi-Layer-HUD-Compositor und Overlay-API
• AR-Surface-Demo und Room-Visualizer-Samples für Szenenverständnis

Ein paar davon sind Schlagzeilen wert. Die ausgelagerte Wi-Fi-7-Rendering-Pipeline ist eine davon. Der XRAssistantService ist die andere. Beide sind partnerschaftsförmig.

XRAssistantService und wofür er tatsächlich da ist

Der XRAssistantService ist das sauberste Stück partnerschafts-anlockendes Engineering, das wir bisher ausgeliefert haben. Die Form davon:

Die Runtime hat eine Voice-Pipeline. Der Nutzer spricht. Sprache-zu-Text läuft lokal auf dem Gerät mit niedriger Latenz. Der Text streamt in den Assistant-Service. Der Assistant-Service übergibt den Text an ein Cloud-LLM. Das Cloud-LLM streamt Tokens zurück, die Intent darstellen: was die AR-Erfahrung als Nächstes tun soll, gegeben das, was der Nutzer gesagt hat. Die Runtime parst diesen Strom und macht daraus laufende Runtime-Aktionen im Flug. Text-zu-Sprache für die Antwort streamt ebenfalls.

Der Punkt, den ich Buildern und Laboren nahelegen möchte: Das LLM wird nicht einmal pro Nutzer-Turn aufgerufen. Die Voice-Pipeline kann während eines Turns weiter Tokens an das Modell streamen (mit dem richtigen Backend-Support), und das Modell kann weiterhin Intent produzieren, auf den die Runtime laufend reagiert. Das ist es, was „Anweisungen von einem Cloud-LLM als Runtime-Anliegen entgegennehmen” tatsächlich bedeutet. Es ist kein Chatbot, der in eine AR-Erfahrung eingeklebt wurde. Es ist die Runtime, die den Intent-Strom des Modells als Steuerungseingabe mit derselben Priorität wie den Blick des Nutzers behandelt.

Die Schnittstelle ist von Grund auf modellagnostisch. ChatGPT kann das steuern. Claude kann das steuern. Gemini kann das steuern. Ein kleines On-Device-Modell kann das steuern. Alles, was einen Strom von Intent-Tokens produziert, der dem Assistant-Service-Protokoll entspricht, kann das steuern. Das Stück, das wir dieses Wochenende gebaut haben, ist die Integrationsschicht zwischen einem solchen Modell und dem Rest der Runtime.

Wenn Sie bei einem dieser Labore sind und das hier lesen: Das ist die Integration, über die wir mit Ihnen sprechen wollen. Wir wollen keine besondere Partnerschaft, bei der Ihr Modell das einzige Modell ist, mit dem die Engine sprechen kann. Wir wollen, dass Ihr Modell das beste Modell ist, mit dem die Engine sprechen kann, weil die Integration offen ist und die Erfahrung, die Ihr Modell produziert, besser sein wird als die Erfahrung, die das Modell von irgendjemand anderem produziert.

Die ausgelagerte Wi-Fi-7-Rendering-Pipeline

Das ist das andere partnerschaftsförmige Stück. AR-Brillen haben eine thermische Hülle. Diese thermische Hülle ist klein. Die Rechenkapazität innerhalb dieser thermischen Hülle ist kleiner, als manche Erfahrungen rendern wollen. Die traditionelle Antwort ist, bei der Erfahrung Kompromisse einzugehen. Die Wi-Fi-7-Antwort ist, einen Teil des Frames auf einer angebundenen Recheneinheit (ein Telefon, ein Beltpack, ein Desktop im selben Raum) zu rendern und das Ergebnis zu streamen.

Dieses Wochenende landete die ausgelagerte Rendering-Pipeline durchgängig. Der Host-Server läuft überall. Die Runtime auf der Brille spricht über Wi-Fi 7 mit dem Host. Die Frame-Latenz wird überwacht, und die Runtime kann elegant auf lokales Rendering degradieren, wenn die Verbindung ruckelt, was sie tun wird.

Warum das für Partner wichtig ist: Es bedeutet, dass ein Hardware-Partner keine Desktop-Klasse-GPU in die Brille packen muss, um eine Desktop-Klasse-Erfahrung auszuliefern. Die Rechenleistung kann dort sein, wo sie am günstigsten ist. Die Verbindung ist das, worauf es ankommt. Wir bauen die Runtime um die Verbindung herum.

Das OpenXR-Gerüst

Ein Haufen der Commits dieses Wochenendes diente der OpenXR-Konformität. XR_EXT_eye_gaze_interaction. Hand-Tracking. Provider-Muster für ARKit und ARCore. Der Grund, warum OpenXR in dieser Codebasis wichtig ist, ist, dass es die Schicht ist, auf der wir wollen, dass diese Engine über Hardware-Partner hinweg portabel ist. Wenn ein Hardware-Partner eine OpenXR-konforme Runtime ausliefert, kann diese Engine darauf ausliefern. Die Schnittstellen, die wir diesen Monat bauen, sind bewusst auf der Standard-Seite statt auf der anbieterspezifischen Seite, weil das die Engine neutral hält.

Ehrlich darüber, was nicht fertig ist

Ein paar Dinge landeten dieses Wochenende als WIP. Der Hand-Tracking-PR ist speziell noch unvollständig verdrahtet. Es gibt einen PoseStabilizer-Linking-Fehler, den wir in einem Follow-up beheben. Eye-Tracking hat Fixierungserkennung, aber die Verweildauer-Timer-Integration mit der Anwendungsschicht ist nicht fertig. Ganzkörper-Tracking ist drin, aber die Gestenerkennungs-Teile brauchen noch mehr Beispiele.

Ich will das deutlich sagen, weil das Muster agentengetriebener Entwicklungsarbeit ist, dass viel WIP in derselben Woche landet, und das WIP wird explizit in den PR-Titeln benannt. Wenn Sie das Commit-Log dieses Wochenendes lesen und an ein paar Stellen „[WIP]” sehen, ist das Absicht. Die vollständigen Liefergegenstände kommen in den nächsten zwei Wochen zusammen.

Was ich Partnern und Buildern mitgeben möchte

Wenn Sie ein KI-Labor sind, das das nächste große Modell baut, und Ihnen an einer AR-Runtime liegt, die die Ausgabe Ihres Modells als Steuerungseingabe auf dem Simulationsschritt behandelt, sprechen Sie mit mir. Die XRAssistantService-Integrationsschicht wird im November 2025 in dieser Engine ausgeliefert und wird bis Jahresende eine stabile Schnittstelle sein, an die man andocken kann.

Wenn Sie ein Hardware-Partner sind, der AR-Brillen mit Wi-Fi 7 an Bord und einer externen Recheneinheit baut, ist die ausgelagerte Rendering-Pipeline genau die Arbeitslast, für die Ihre Hardware gebaut wurde. Die Runtime ist dafür bereit.

Wenn Sie Entwickler sind und überlegen, welche Art von Erfahrungen diese Engine Sie bauen lässt, wird die Antwort im Commit-Log allmählich sichtbar. Sprachgesteuerte AR-Erfahrungen, die mitten im Satz auf den Nutzer reagieren, sind erreichbar. Echtzeit-Multiplayer-AR mit Submillimeter-Anchoring ist erreichbar. Die Rechenleistung, die Sie für beides brauchen, lebt auf der Brille oder auf der Anbindung, je nachdem, was Ihre Erfahrung braucht.

Hundertachtzehn Commits, großes Wochenende. Die Engine sieht Sonntagnacht anders aus, als sie es tat, als der Laptop am Samstag aufging.