Construído para Receber Direção do ChatGPT, Claude e Gemini
A era do "este produto roda apenas no modelo daquele fornecedor" é curta. A RakuAI é construída para que qualquer modelo - ChatGPT, Claude, Gemini, ou o seu - possa dirigir uma experiência de RA em tempo real. Traga o melhor modelo. O runtime está pronto.
A maioria dos motores de jogo que se integram com um LLM em nuvem hoje faz isso do jeito que você esperaria. Um modelo é pendurado no editor como um painel de chat. Você digita no painel de chat. O painel escreve algum conteúdo ou algum código. O runtime, que não faz ideia de que nada disso aconteceu, roda o artefato resultante depois.
Não é isso que a Raku está fazendo. A Raku está sendo construída para receber direção de um LLM em nuvem como uma preocupação de runtime, não uma conveniência de autoria. O trabalho deste fim de semana tornou isso explícito.
O que entrou
Cento e dezoito commits no runtime neste fim de semana. As peças-destaque:
- Um XRAssistantService que conecta respostas de LLM em nuvem ao pipeline de voz como uma funcionalidade de runtime de primeira classe
- Renderização foveada por rastreamento ocular com otimização de performance multi-perfil
- Um provedor OpenXR XR_EXT_eye_gaze_interaction
- Rastreamento de mãos e reconhecimento de gestos para o runtime XR
- Rastreamento de corpo inteiro com um esqueleto de 71 articulações
- Detecção de fixação e timers de permanência na infraestrutura de rastreamento ocular
- Passthrough de alta resolução, sensoriamento de profundidade, e estimativa de iluminação
- Um pipeline de renderização descarregada por Wi-Fi 7 com um servidor host e monitoramento de latência
- Um canal de delta de baixa latência para sincronização de pose e estado de RA multiplayer em tempo real
- Serviço de âncora sub-milimétrica para Android XR
- Ponte de sensor ARCore para dispositivos Android sem a stack Android XR
- Um Compositor de HUD Multi-Camada e API de overlay
- Exemplos de Demo de Superfície de RA e Visualizador de Cômodo para entendimento de cena
Algumas dessas são destaques que vale a pena discutir. O pipeline de renderização descarregada por Wi-Fi 7 é uma. O XRAssistantService é a outra. Ambas têm formato de parceria.
XRAssistantService e para que ele de fato serve
O XRAssistantService é a peça mais limpa de engenharia com isca de parceria que já lançamos até hoje. O formato dele:
O runtime tem um pipeline de voz. O usuário fala. Fala-para-texto roda localmente no dispositivo com baixa latência. O texto é transmitido para o serviço assistente. O serviço assistente entrega o texto a um LLM em nuvem. O LLM em nuvem transmite de volta tokens que representam intenção: o que a experiência de RA deveria fazer a seguir dado o que o usuário disse. O runtime analisa esse fluxo e o transforma em ações de runtime em voo. Texto-para-fala para a resposta também é transmitido.
A peça que eu quero que construtores e labs notem é que o LLM não é invocado uma vez por turno do usuário. O pipeline de voz pode continuar transmitindo tokens para o modelo durante um turno (com o suporte de backend certo), e o modelo pode continuar produzindo intenção sobre a qual o runtime age continuamente. É isso que “receber direção de um LLM em nuvem como uma preocupação de runtime” de fato significa. Não é um chatbot colado em uma experiência de RA. É o runtime tratando o fluxo de intenção do modelo como uma entrada de controle na mesma prioridade que o olhar do usuário.
A interface é agnóstica de modelo por design. O ChatGPT consegue dirigir isso. O Claude consegue dirigir isso. O Gemini consegue dirigir isso. Um modelo pequeno no dispositivo consegue dirigir isso. Qualquer coisa que produza um fluxo de tokens de intenção que esteja em conformidade com o protocolo do serviço assistente consegue dirigir isso. A peça que construímos neste fim de semana é a camada de integração entre qualquer modelo desses e o resto do runtime.
Se você está em um desses labs e está lendo isso: esta é a integração sobre a qual queremos conversar com você. Não queremos uma parceria especial em que o seu modelo seja o único modelo com que o motor consegue conversar. Queremos que o seu modelo seja o melhor modelo com que o motor consegue conversar, porque a integração é aberta e a experiência que o seu modelo produz vai ser melhor que a experiência que o modelo de qualquer outro produz.
O pipeline de renderização descarregada por Wi-Fi 7
Esta é a outra peça em formato de parceria. Óculos de RA têm um envelope térmico. O envelope térmico é pequeno. O envelope de computação dentro desse envelope térmico é menor do que o que algumas experiências querem renderizar. A resposta tradicional é fazer concessões na experiência. A resposta do Wi-Fi 7 é renderizar parte do frame em uma caixa de computação vinculada (tethered) (um celular, um beltpack, um desktop no mesmo cômodo) e transmitir o resultado.
Neste fim de semana o pipeline de renderização descarregada entrou de ponta a ponta. O servidor host roda em qualquer lugar. O runtime nos óculos conversa com o host via Wi-Fi 7. A latência de frame é monitorada e o runtime consegue degradar graciosamente para renderização local quando o link oscila, o que vai acontecer.
Por que isso importa para parceiros: significa que um parceiro de hardware não precisa colocar uma GPU de classe desktop nos óculos para lançar uma experiência de classe desktop. A computação pode estar onde a computação é mais barata. O link é a coisa que importa. Estamos construindo o runtime em torno do link.
O andaime OpenXR
Um monte dos commits deste fim de semana foi a serviço da conformidade OpenXR. XR_EXT_eye_gaze_interaction. Rastreamento de mãos. Padrões de provedor para ARKit e ARCore. A razão de OpenXR importar nesta base de código é que é a camada na qual queremos que este motor seja portável através de parceiros de hardware. Se um parceiro de hardware lança um runtime conformante com OpenXR, este motor pode ser lançado nele. As interfaces que estamos construindo este mês estão deliberadamente do lado dos padrões em vez do lado específico de fornecedor, porque é assim que o motor permanece neutro.
Honesto sobre o que não está pronto
Algumas coisas entraram neste fim de semana como WIP (trabalho em andamento). O PR de rastreamento de mãos especificamente ainda está conectado de forma incompleta. Há um erro de linkagem do PoseStabilizer que estamos corrigindo em um follow-up. O rastreamento ocular tem detecção de fixação mas a integração do timer de permanência com a camada de aplicação não está terminada. O rastreamento de corpo inteiro está dentro mas as peças de reconhecimento de gesto ainda precisam de mais amostras.
Quero ser claro sobre isso porque o padrão do trabalho de desenvolvimento conduzido por agentes é que muito WIP entra na mesma semana, e o WIP é nomeado explicitamente nos títulos de PR. Se você ler o log de commits deste fim de semana e ver “[WIP]” em alguns lugares, é de propósito. As entregas completas se juntam ao longo das próximas duas semanas.
O que eu quero que parceiros e construtores tirem disso
Se você é um lab de IA construindo o próximo grande modelo e se importa com um runtime de RA que trata a saída do seu modelo como uma entrada de controle na etapa de simulação, fale comigo. A camada de integração do XRAssistantService está sendo lançada neste motor em novembro de 2025 e vai ser uma interface estável para se conectar até o fim do ano.
Se você é um parceiro de hardware construindo óculos de RA com Wi-Fi 7 embarcado e uma proposta de computação externa, o pipeline de renderização descarregada é exatamente a carga de trabalho para a qual o seu hardware foi construído. O runtime está pronto para isso.
Se você é um desenvolvedor pensando em que tipos de experiências este motor vai te permitir construir, a resposta está começando a ficar visível no log de commits. Experiências de RA guiadas por voz que respondem ao usuário no meio da frase são viáveis. RA multiplayer em tempo real com ancoragem sub-milimétrica é viável. A computação de que você precisa para qualquer uma das duas vive nos óculos ou no tether, dependendo do que a sua experiência precisa.
Cento e dezoito commits, grande fim de semana. O motor parece diferente no domingo à noite do que parecia quando o laptop abriu no sábado.
Seu modelo pertence à etapa de simulação
O XRAssistantService da RakuAI é uma interface agnóstica de modelo para transmitir intenção para dentro de uma experiência de RA ao vivo. Se você constrói modelos de fronteira, esta é a integração sobre a qual queremos conversar com você.