OpenMobile-2 é uma IA open source para celular impressionante — testei em um celular falso

Autoria: Prompt Engineer 48 · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: OpenMobile-2 Is a CRAZY Open-Source Phone AI - I Tested It on a Fake Phone · Canal: Prompt Engineer 48 · 14:11 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Avaliação e benchmarks de IA, Modelos locais e open source, Modelos multimodais

Resumo

OpenMobile-2 é uma família de modelos fine-tuned para operar interfaces de celular, acompanhada de apps simulados, dados e receitas de treinamento. O vídeo apresenta o Mobile Gym++, um ambiente de navegador com estado reinicializável, e compara os modos GUI-only e híbrido em seis tarefas. O modo híbrido foi mais eficiente e passou em duas tarefas, mas os testes também revelaram erros, incluindo valores incorretos e falhas em tarefas longas. O autor ressalta que seu teste com o modelo 9B não reproduz as avaliações dos autores e conclui que o ambiente de simulação é uma contribuição especialmente valiosa para pesquisa.

Pontos-chave

OpenMobile-2 inclui checkpoints de 9B e 27B, ambos Apache 2.0 e baseados em modelos Qwen.
O Mobile Gym++ simula dezenas de apps em um navegador e permite reiniciar o estado das tarefas sem usar um emulador Android.
As tarefas são avaliadas por mudanças no estado dos apps, em vez de depender de um modelo de visão para julgar capturas de tela.
O modo híbrido combina interação pela interface com ferramentas nativas dos apps; o artigo relata que o acesso a ferramentas ajuda mais após treinamento híbrido.
No teste do vídeo, o modo GUI-only passou em zero das seis tarefas, enquanto o modo híbrido passou em duas.
O total de passos caiu de 199 no modo GUI-only para 82 no modo híbrido, mas algumas tarefas ainda receberam pontuação zero ou parcial.
O autor executou o modelo 9B remotamente em uma GPU A40 de 48 GB, pois os pesos BF16 ocupavam cerca de 18 GB e a GPU local tinha 8 GB de VRAM.
Os resultados publicados são dos autores; o teste independente do vídeo usou apenas seis tarefas e não reproduziu a avaliação completa.

Capítulos

Início	Capítulo	Resumo
00:01	OpenMobile-2 e o ciclo de interação	O vídeo apresenta o modelo, sua família de checkpoints e o ciclo em que ele observa capturas de tela e escolhe ações.
02:09	Mobile Gym++ e treinamento	São explicados os apps simulados, a avaliação por estado, as ferramentas nativas e as etapas de treinamento.
05:13	Resultados publicados e configuração do teste	O autor contextualiza as avaliações dos modelos e descreve como executou o OpenMobile-2 9B em uma GPU remota.
08:20	Teste dos modos GUI-only e híbrido	Seis tarefas mostram que o modo híbrido costuma exigir menos passos, embora também cometa erros e não passe em todas.
12:08	Limitações e conclusão	O autor pondera as diferenças em relação às avaliações oficiais e destaca o ambiente simulável como principal contribuição.

Citações

Ninguém está tocando nele. Ele olha para uma captura de tela, decide onde tocar e acabou de abrir o Alipay. — 00:01

O acesso a ferramentas quase não ajuda um modelo antes de ele ser treinado para isso. — 04:12

60 passos e uma falha contra seis passos e uma aprovação na mesma tarefa. — 09:34

O mais valioso aqui não é o 79,9; é o Mobile Gym++, um celular reinicializável e programável, baseado em navegador. — 13:40

Conceitos e entidades

OpenMobile-2 (modelo): Família de modelos fine-tuned para executar tarefas em interfaces de celular, com versões de 9B e 27B.
Mobile Gym++ (ferramenta): Ambiente de navegador com apps móveis simulados e estado reinicializável, usado para treinar e avaliar agentes.
Qwen (modelo): Família de modelos usada como base para os checkpoints do OpenMobile-2.
vLLM (ferramenta): Ferramenta usada no vídeo para servir o modelo remotamente.
RunPod (empresa): Serviço usado para alugar uma GPU A40 e executar o modelo.
Playwright (ferramenta): Ferramenta cujo Chromium é instalado para executar o benchmark no ambiente de simulação.
Alipay (ferramenta): App simulado usado em tarefas de consulta de transações, cálculo de despesas e criação de notas.
WeChat (ferramenta): App usado em tarefas de busca de contatos e envio de mensagens.
Android World (conceito): Benchmark citado para comparar o desempenho dos modelos em tarefas de uso de celular.
GUI-only (conceito): Modo de execução em que o modelo interage apenas olhando a interface e tocando ou deslizando na tela.
modo híbrido (conceito): Modo que combina ações na interface com chamadas a ferramentas nativas dos apps.

Tradução completa (pt-BR)

00:01 Este é um modelo de 9 bilhões de parâmetros controlando um celular falso no meu laptop. Ninguém está tocando nele. Ele olha para uma captura de tela, decide onde tocar e acabou de abrir o Alipay. No papel, seu irmão maior, o Open Mobile 2 27B, marca 79,9 no Android World. Esse é o maior número na tabela de resultados dos próprios autores. Então, executei esse modelo menor por conta própria em seis tarefas, duas vezes cada, e os resultados me ensinaram mais do que a pontuação. >> [música]

00:37 >> Open Mobile 2 é um lançamento de pesquisa de cerca de duas dúzias de autores, entre eles Da Huanglin. O artigo está no rx rx, o repo está no GitHub e os modelos no Hugging Face são públicos. E não é só um modelo: é a stack inteira, os apps simulados, os dados de treinamento, a receita de treinamento e dois checkpoints, um 9B e um 27B. Ambos são Apache 2.0 e ambos são fine-tunes do Qwen. O 9B parte do

01:08 Qwen 3.5 9B. O 27B parte do Qwen 3.6 27B. Então, o que eles acrescentaram não é uma nova arquitetura, mas comportamento: como operar um celular. Este é o ciclo. Você dá a ele uma frase como: encontre minha maior despesa no Alipay e anote nas minhas notas. Ele recebe uma captura de tela e responde com uma ação: tocar aqui, deslizar ali, digitar isto ou concluir. Depois, recebe a próxima captura de tela. Esse ciclo é o agent inteiro. Deixe-me mostrar como isso aparece nos logs reais. O harness envia a

01:39 tarefa e as três últimas capturas de tela. O modelo responde com um breve parágrafo de raciocínio e, em seguida, uma tool call. As coordenadas são normalizadas de 0 a 1.000, então a resolução da tela não importa. Este é o passo dois de uma das minhas execuções. O modelo escreve: “O usuário quer encontrar a maior despesa nos registros de transações do Alipay. Estou na tela inicial, vejo o ícone do Alipay, então preciso tocar nele.” Aí ele toca. Essa é toda a cognição, e dá para ler cada pedacinho dela. A propósito, nem todo pensamento é tão seco assim. Em uma execução, a

02:09 primeira linha que o modelo escreveu foi: “Isso é meio desagradável, não é? Todos queremos manter nossas finanças sob controle.” Depois, deslizou para encontrar o ícone do Alipay na barra de abas, cheio de opiniões. Por que é difícil treinar isso? Porque, para ensinar um modelo a usar um celular, você precisa de um número enorme de execuções de prática em apps com aparência real, e os apps reais são um pesadelo para isso. Não dá para redefinir facilmente uma conta de compras real, pagamentos são arriscados e um emulador Android completo para cada execução é pesado. Então, os autores dizem: “A maioria dos projetos open source

02:39 pratica com apenas algumas dezenas de apps de emulador, e esse é o gargalo.” A ideia deles é parar de usar os apps reais e recriar apps comerciais como clientes simulados em um navegador, onde todo o estado pode ser redefinido sem problemas. Isso é o Mobile Gym++, e posso mostrar porque estou executando agora mesmo neste laptop. É um celular que fica dentro de uma página web. Você clona o repo, precisa do Node 22 e um comando inicia um servidor de desenvolvimento na porta 3000. Só isso. Sem Android SDK, sem

03:10 emulador. O README nem menciona Docker. Esta é a tela inicial, com 63 apps distribuídos por algumas páginas. Alipay, eBay, Bilibili, WeChat, Meituan, Slack, Notes, Clock. 35 deles são novos nesta versão, e repare que a interface está em sua maior parte em chinês, porque muitos desses apps são chineses. Isso vai ser importante mais adiante. São simulações, não são afiliadas às empresas que imitam, e o repo deixa isso claro em um aviso, mas têm comportamento real. Este Alipay tem histórico de transações, saldo, transferências; toque, role a tela, e ele

03:42 responde a tudo. E aqui está a parte esperta. Cada tarefa é criada comparando o estado do negócio antes e depois. Nenhum vision model avalia uma captura de tela. A nota foi criada com o número correto? Sim ou não? O benchmark tem 215 tarefas e cerca de metade delas envolve mais de um app. A segunda ideia são as ferramentas nativas dos apps. Além de tocar na tela, o modelo pode chamar funções. O artigo diz que há mais de

04:12 300 ferramentas em mais de 50 apps. Coisas como pesquisar faturas, resumir faturas, criar uma nota, enviar uma mensagem. Essas ferramentas gravam no mesmo estado que a tela. Assim, em uma tarefa, o agent pode navegar por um app tocando na tela, chamar uma ferramenta em outro, e o avaliador ainda vê um mundo consistente. O artigo chama isso de híbrido. A descoberta deles aqui é sutil: o acesso a ferramentas quase não ajuda um modelo antes que ele seja treinado para isso. Depois do treinamento híbrido, o agent híbrido ganha mais e termina

04:43 em menos passos. Lembre-se disso, porque testei exatamente essa diferença. O treinamento tem três partes. Primeiro, supervised fine-tuning com cerca de 11,6 mil trajetórias de demonstração coletadas nesses apps simulados. Segundo, uma versão híbrida que combina toques e tool calls. Terceiro, reinforcement learning em mais de 2.000 tarefas executáveis, cada uma com uma recompensa automática fornecida por esse verificador de estado. Mais uma descoberta de que gostei. Com um orçamento fixo de

05:13 trajetórias, distribuí-las por mais apps é melhor do que concentrá-las em menos apps. Isso melhora o desempenho em apps não vistos sem prejudicar os conhecidos. Esse é o argumento para criar 35 apps em vez de cinco. Agora, os números. Eles vêm dos model cards, então são avaliações dos próprios autores, não minhas. No Android World, o 9B marca 74,0. Seu modelo base, Gwen 3.59B, marca 54,3. Outros agents de 8B, como

05:44 UI Venus, GUI OL e MAI UI, ficam entre 69 e 74. O 27B chega a 79,9. O segundo melhor nessa tabela é o modelo MAIUI, com 235 bilhões de parâmetros, que marca 76,7, e o Gemini 3.1 Pro aparece com 70,7. Mas é aqui que quero ter cuidado, porque o entusiasmo exagerado deixaria de lado esta parte: no Mobile World, que é mais difícil, o 27B marca 50,4. O Gemini 3.1 Pro aparece com 58,1, e o GPT 5.6 marcou 70,1 no SBA

06:17 Bench, que usa dispositivos reais. O 27B marca 59,6, contra 70,2 do Gemini e 68,1 do GPT. Então, a leitura honesta é: perto da fronteira. O salto em relação ao modelo base é enorme. No SBA Bench, o 27B sobe de 31,9 para 59,6. Mas, nos testes mais difíceis com dispositivos reais, os modelos fechados ainda estão na frente.

06:47 Então, consigo executar o modelo no meu laptop? Não. O simulador de celular roda bem localmente, mas o modelo 9B ocupa cerca de 18 GB em pesos BF16, e a GPU do meu laptop, uma RTX 4060, tem 8 GB. Também não encontrei uma versão quantizada na página do Hugging Face. Então, separei as coisas. O celular roda no meu laptop. O modelo roda em uma A40 de 48 GB alugada no RunPod, servida com vLLM, e meu laptop chama esse modelo como qualquer API no estilo da OpenAI.

07:19 A cobrança foi de 59 centavos por hora, e apaguei a instância assim que as execuções terminaram. Uma observação prática: minha primeira execução travou com um erro de Unicode porque o texto está em chinês e o console do Windows não usa UTF-8. Uma variável de ambiente, o modo UTF-8 do Python, resolveu. Vale saber disso se você tentar fazer isso no Windows. Se quiser experimentar por conta própria, o processo é mais ou menos assim. Clone o repo Mobile Gym Plus e inicie o celular. O script oficial espera ZSH show no Windows. Eu simplesmente executei npm install e depois npm run dev. Em seguida, em outro terminal, crie um ambiente Python, instale os requisitos do benchmark e instale o Chromium do Playwright. Sirva o modelo com vLLM em qualquer máquina com memória suficiente. Depois, aponte o executor do benchmark para essa URL, informe o nome do modelo e escolha um modo: somente GUI ou híbrido. Ele salva cada etapa, a captura de tela antes e depois, a resposta bruta do modelo e o arquivo de resultados. É daí que vem todo o material deste

07:49 vídeo. Meu conselho é manter as configurações do script oficial como referência. Thinking ativado, as três últimas capturas de tela no contexto, coordenadas normalizadas para 1.000. Mudei uma coisa: o modo de tool call XML, para não ter que reiniciar o servidor com flags extras. Hora de testar. A tarefa: “Veja o Alipay, diga se os gastos de janeiro de 2026 ou de dezembro de 2025 foram maiores, calcule a diferença e depois crie uma nota com o título comparação de gastos mensais.” A mesma tarefa,

08:20 em dois modos. Primeiro, somente GUI. O modelo só pode olhar e tocar. Veja como ele trabalha. Abre o Alipay, encontra a página de faturas e abre um seletor de mês, que é uma roda giratória, e tem dificuldade. Em certo momento, desliza usando coordenadas com um erro de digitação. No fim, consegue ler dezembro: 405,6, mas, depois de 60 passos, atinge o limite de etapas. Falhou.

08:50 dois modos. Primeiro, somente pela interface gráfica. O modelo só pode olhar e tocar. Veja-o trabalhar. Ele abre o Alipay, encontra a página de contas e abre um seletor de mês, que é uma roda giratória, e tem dificuldade. Em certo momento, ele desliza com um erro de digitação nas próprias coordenadas. Por fim, consegue ler “dezembro, 405,6”, mas, após 60 etapas, atinge o limite de etapas. Falha.

09:34 Agora, a mesma tarefa no modo híbrido. Etapa um: ele abre o Alipay. Etapa dois: em vez de tocar nos controles até encontrar um seletor de mês, ele chama uma ferramenta para resumir as contas de janeiro. Etapa três: usa a mesma ferramenta para dezembro. Depois, faz a subtração de cabeça, abre o Notes e cria a nota com uma chamada de ferramenta. Seis etapas, e o avaliador diz que passou. 60 etapas e uma reprovação contra seis etapas e uma aprovação na mesma tarefa. Foi exatamente isso que o artigo afirma sobre ferramentas, e eu vi acontecer na minha própria máquina.

10:04 Mais um exemplo: encontre as três maiores despesas dos últimos 30 dias no Alipay e envie-as para um contato no WeChat, terminando com uma frase específica. No modo híbrido, passou em nove etapas. E gostei de como chegou lá. Na primeira chamada de ferramenta, ele chutou o ano errado, então a busca quase não encontrou nada. O modelo percebeu que aquilo parecia insuficiente e voltou a navegar manualmente pela página de contas, tocando na tela. Depois, usou uma ferramenta para encontrar o contato e enviar a mensagem.

10:36 Agora, a parte que você não vai ver em um vídeo cheio de empolgação. Aqui está a primeira tarefa do começo ao fim. Tela inicial, desliza para encontrar o Alipay, a aba “Meu”, a página de contas e um filtro para despesas. Agora, veja a etapa seis: logo depois de aplicar o filtro, ele declara que a maior despesa é 200. Nunca rolou para ver o resto da lista. Depois, vai ao Notes, digita o título no campo errado, percebe, corrige e salva. 17 etapas, e ele relata que teve sucesso.

11:07 Essa execução recebeu crédito parcial, e o relatório do avaliador é específico: destinatário correto, valor errado. A nota diz 200. O valor real é 2500. Ele encontrou a pessoa certa e não encontrou a maior transação. E o modo híbrido não foi uma vitória garantida. Na mesma tarefa [limpa a garganta], levou 25 etapas e não pontuou nada. Nas seis tarefas, o modo somente GUI passou em zero. O híbrido passou em duas, e o total de etapas caiu de 199 para 82. Vou falar rapidamente das outras três. No eBay, encontre o

11:38 ventilador elétrico novo mais barato, confira meu saldo no Alipay e anote os dois. O modo somente GUI levou 25 etapas e não ganhou nada. O híbrido levou nove etapas e ganhou 2/3 dos pontos. No Bilibili, dê ao vídeo mais bem classificado a ação tripla de um toque e depois publique sobre ele nos Moments do WeChat. O modo somente GUI levou 37 etapas e obteve 60%. O híbrido levou 13 etapas e obteve 80%. Chegou perto, mas ainda não passou. A mais difícil foi a tarefa do computador e da TV. Encontre o computador mais barato e a TV mais barata no eBay, calcule quanto sobraria do meu saldo se eu comprasse os dois e escreva tudo

12:08 isso em uma nota. Os dois modos pontuaram zero. Então, não, isso não é mágica. É um modelo de 9 bilhões de parâmetros, e ele falha em tarefas longas de aritmética com várias etapas. Então, isso contradiz o artigo? Não à primeira vista. Executei seis tarefas, não 215. Usei o modelo de 9B, não o de 27B. Usei o modo de chamadas de ferramenta em XML para não precisar reiniciar meu servidor, e não posso descartar que minha configuração seja diferente da dos autores

12:39 de formas que custem pontos. A pontuação que os próprios autores obtiveram com o modelo de 9B nesse benchmark, no modo híbrido, é 46,5%, então é esperado que ele falhe em algumas tarefas. O que posso dizer é que ele joga o jogo inteiro. Navega por interfaces com vários apps, raciocina em etapas simples e para por conta própria. O que não posso dizer é que reproduzi a pontuação deles. Há também um espaço da comunidade no Hugging Face, acessível pela página do modelo, que mostra uma única etapa de decisão. Você envia uma captura de tela, digita uma tarefa e ele prevê o próximo toque. A descrição do próprio espaço diz que o ciclo completo precisa de um

13:10 emulador em execução, então não dá para executar o processo inteiro, mas é uma maneira rápida de experimentar o modelo sem configurar nada. Então, para quem é isso? Se você pesquisa agentes para dispositivos móveis, é um presente: ambientes, dados, receitas e checkpoints. Tudo sob Apache 2.0, incluindo um telefone que você pode executar no navegador com um único comando. Se você quer um assistente para o celular hoje, ainda não. É código de pesquisa. O repo do código tem 24 estrelas e nenhum lançamento. Os apps são simulações, e os cartões dos modelos mostram dezenas de downloads, não milhares.

13:40 Minha opinião: o mais valioso aqui não é o 79,9; é o Mobile Gym++, um telefone baseado no navegador que pode ser redefinido e programado por scripts, e que você pode disponibilizar para qualquer modelo, incluindo o seu. Era isso que estava faltando. Em seguida, quero testar o modelo de 27B e executar as 215 tarefas completas. Se você quiser isso, me conte nos comentários e diga que tarefa de celular você proporia para ele. Se estiver procurando GPUs baratas e confiáveis, eu uso RunPod, e o link está na descrição. É isso sobre o OpenMobile-2. Obrigado por

14:11 assistir, e até a próxima.

Transcrição original

[00:01] This is a 9-billion parameter model driving a fake phone on my laptop. Nobody is touching it. It looks at a screenshot, decides where to tap, and it just opened Alipay. On paper, its bigger sibling, Open Mobile 2 27B, scores 79.9 on Android world. That’s the top number in its own results table. So, I ran this smaller one myself on six tasks twice, and the results taught me more than the score does. >> [music]

[00:37] >> Open Mobile 2 is a research release from about two dozen authors with Da Huanglin on the list. The paper is on rx rx and the GitHub repo, and the hugging face models are public. And it’s not just a model, it’s the whole stack, the simulated apps, the training data, the training recipe, and two checkpoints, a 9B and a 27B. Both are Apache 2.0, and both are fine-tunes of Qwen. The 9B starts from

[01:08] Qwen 3.5 9B. The 27B starts from Qwen 3.6 27B. So, what they added is not a new architecture, it’s behavior, how to operate a phone. Here’s the loop. You give it a sentence like find my biggest expense in Alipay and write it in my notes. It gets a screenshot, and it answers with one action, tap here, swipe there, type this, or finish. Then it gets the next screenshot. That loop is the entire agent. Let me show you what that looks like in the real logs. The harness sends the

[01:39] task and the last three screenshots. The model answers with a short paragraph of reasoning, then one tool call. Coordinates are normalized from 0 to 1,000, so the screen resolution doesn’t matter. Here’s step two from one of my runs. The model writes, “The user wants to find the largest expense in their Alipay transaction records. I’m on the home screen, I see the Alipay icon, so I need to click it. Then it clicks, that’s the whole cognition, and you can read every bit of it. Not every thought is that dry, by the way. In one run, the

[02:09] very first line the model wrote was, “This stinks a bit, doesn’t it? We all want to keep our finances in check.” Then it swiped to find the Alipay icon at tab bar with opinions. Why is this hard to train? Because to teach a model to use a phone, you need a huge number of practice runs on real-looking apps, and real apps are a nightmare for that. You can’t easily reset a real shopping account, payments are risky, and a full Android emulator for every single run is heavy. So, the authors say, “Most open projects

[02:39] practice on only a few dozen emulator apps, and that’s the bottleneck.” Their idea is to stop using the real apps, rebuild commercial apps as simulated clients in a browser where all the state can be reset cleanly. That’s Mobile Gym plus plus, and I can show you because I’m running it right now on this laptop. It’s a phone that lives in a web page. You clone the repo, you need Node 22, and one command starts a dev server on port 3000. That’s it. No Android SDK, no

[03:10] emulator. The readme doesn’t even mention Docker. Here’s the home screen, 63 apps spread across a few pages. Alipay, eBay, Bilibili, WeChat, Meituan, Slack, Notes, Clock. 35 of those are new in this release, and notice the interface is mostly Chinese because many of these are Chinese apps. That’s going to matter later. They’re simulations, they’re not affiliated with the companies they imitate, and the repo says so in a disclaimer, but they have real behavior. This Alipay has a transaction history, a balance, transfers, tap, scroll, and it

[03:42] all responds. And here’s the clever part. Every task is created by comparing the business state before and after. No vision model judging a screenshot. Did the note get created with the right number in it? Yes or no? The benchmark has 215 tasks and about half of them cross between apps. The second idea is app native tools. Besides tapping the screen, the model can call functions. The paper says over

[04:12] 300 tools across more than 50 apps. Things like search bills, summarize bills, create note, send message. Those tools write to the same state as the screen does. So, in one task, the agent can tap through one app, call a tool in another, and the grader still sees one consistent world. The paper calls this hybrid. Their finding here is subtle tool access barely helps a model before it’s trained for it. After hybrid training, the hybrid agent gains the most and finishes

[04:43] in fewer steps. Keep that in mind because I tested exactly that. Training is a three-part recipe. First, supervised fine-tuning on about 11.6 thousand demonstration trajectories collected on those simulated apps. Second, a hybrid version mixing tabs and tool calls. Third, reinforcement learning on over 2,000 executable tasks, each with an automatic reward from that state checker. One more finding I liked. With a fixed

[05:13] budget of trajectories, spreading them across more apps beats piling them onto fewer apps. It improves unseen apps without hurting the familiar ones. That’s the argument for building 35 apps instead of five. Now, the numbers. These come from the model cards, so they’re the authors’ own evaluations, not mine. On Android world, the 9B scores 74.0. Its base model Gwen 3.59B scores 54.3. Other 8B agents like

[05:44] UI Venus, GUI OL, and MAI UI between 69 and 74. The 27B goes to 79.9. The next best in that table is the MAIUI model with 235 billion parameters at 76.7, and Gemini 3.1 Pro is listed at 70.7. But, here’s where I want to be careful because hype would skip this part on Mobile World, which is harder. The 27B scores 50.4. Gemini 3.1 Pro is listed at 58.1, and GPT 5.6 sold at 70.1 on SBA

[06:17] bench, which uses real devices. The 27B gets 59.6 against 70.2 for Gemini and 68.1 for GPT. So, the honest reading is near frontier. The jump from the base model is huge. On SBA bench, the 27B goes from 31.9 to 59.6. But, on the hardest real device tests, the closed models are still ahead.

[06:47] So, can I run it for the model on my laptop? No. The phone simulator runs fine locally, but the 9B model is about 18 GB of weights in BF16, and my RTX 4060 laptop GPU has 8 GB, and I didn’t find a quantized version on the Hugging Face page. So, I split it. The phone runs on my laptop. The model runs on a rented 48 GB A40 on RunPod served with vLLM, and my laptop calls it like any OpenAI style

[07:19] API. It billed at 59 cents an hour, and I deleted it as soon as the runs finished. One practical note, my first run crashed with a Unicode error because the text text is Chinese, and my Windows console isn’t UTF-8. One environment variable, Python UTF-8 mode, fixed it. Worth knowing if you try this on Windows. If you want to try this yourself, here’s the shape of it. Clone the Mobile Gym Plus repo and start the phone. The

[07:49] official script expects ZSH show on Windows. I just ran npm install and then npm run dev. Then in a second terminal, make a Python environment, install the bench requirements, and install Playwright’s Chromium. Serve the model with vllm on any machine with enough memory. Then point the benchmark runner at that URL, give it your model name, and pick a mode, GUI only or hybrid. It saves every step, the screenshot before and after, the model’s raw response, and the result file. That’s where all the footage in this

[08:20] video comes from. My advice is to keep the official script’s settings as your baseline. Thinking turned on, the last three screenshots in context, coordinates normalized to 1,000, I changed one thing, XML tool call mode, so I didn’t have to restart the server with extra flags. Time to test. The task, “Look at Alipay, tell me whether January 2026 or December 2025 had higher spending, work out the difference, then create a note titled monthly spending comparison.” Same task,

[08:50] two modes. First, GUI only. The model can only look and tap. Watch it work. It opens Alipay, finds the bills page, and opens a month picker, which is a spinning wheel, and it struggles. At one point, it swipes with a typo in its own coordinates. It does finally read December 405.6, but after 60 steps, it hits the step limit. Fail.

[09:34] Now, the same task in hybrid mode. Step one, it opens Alipay. Step two, instead of tapping through a month picker, it calls a tool summarize bills for January. Step three, same tool for December. Then it does the subtraction in its head, opens notes and creates the note with a tool call. Six steps, the judge says pass. 60 steps and a fail versus six steps and a pass on the same task. That is exactly what the paper claims about tools and I watched it happen on my own machine.

[10:04] Another one, find the three biggest expenses from the last 30 days in Alipay and send them to a contact on WeChat ending with a specific sentence. In hybrid mode, this pass in nine steps. And I liked how it got there. It’s first tool call guessed the wrong year, so the search came back with almost nothing. The model noticed that looked thin and fell back to tapping through the bills page by hand. Then it used a tool to find the contact and send the message.

[10:36] Now the part you won’t see in a hype video. Here’s the first task start to finish. Home screen, swipe to find Alipay, the my tab, the bills page and a filter to expenses. Now look at step six, right after filtering, it declares the largest expense is 200. It never scrolled through the rest of the list. Then it goes to notes, types the title into the wrong field, notices, fixes it and saves. 17 steps and it reports success.

[11:07] That run got partial credit and the judge report is specific. Recipient correct, amount wrong. The note says 200. The ground truth is 2500. It found the right person and missed the biggest transaction. And hybrid mode wasn’t a free win. On that same [clears throat] task, it took 25 steps and scored nothing. Across all six tasks, GUI only passed zero. Hybrid passed two and the total steps dropped from 199 to 82. Let me give you the other three quickly on eBay. Find the

[11:38] cheapest new electric fan, check my Alipay balance, and note both GUI only took 25 steps and earned nothing. Hybrid took nine steps and earned 2/3 of the credit. Bilibili, give the top-ranked video the one-tap triple action, then post about it on WeChat Moments. GUI only took 37 steps for 60%. Hybrid took 13 steps for 80%. Close, but still not a pass. The hardest was the computer and TV task. Find the cheapest computer and the cheapest TV on eBay, work out what both would leave in my balance, and write all

[12:08] of it in a note. Both modes scored zero. So, no, this isn’t magic. It’s a 9-billion parameter model, and it fails on long, multi-step arithmetic tasks. So, does this contradict the paper? Not on its face. I ran six tasks, not 215. I used the 9B, not the 27B. I used XML tool call mode, so I wouldn’t have to restart my server, and I can’t rule out that my setup differs from the authors

[12:39] in ways that cost points. The authors’ own hybrid score for the 9B on this benchmark is 46.5%, so failing some is expected. What I can say, it plays the whole game. It navigates multi-app interfaces, reasons in plain steps, and stops itself. What I can’t say that I reproduced their number. There’s also a community space on Hugging Face linked from the model page that shows a single decision step. You upload a screenshot, type a task, and it predicts the next tap. Its own description says the full loop needs a

[13:10] live emulator, so it can’t run the whole thing, but it’s a quick way to poke at the model without any setup. So, who is this for? If you research mobile agents, it’s a gift environments, data, recipes, and checkpoints. All Apache 2.0, including a phone you can run in a browser with one command. If you want a phone butler today, not yet. It’s research code. The code repo has 24 stars and no releases. The apps are simulations and the model cards show dozens of downloads, not thousands.

[13:40] My take, the most valuable thing here isn’t the 79.9, it’s Mobile Gym plus plus, a resettable, scriptable, browser-based phone that you can point any model at, including your own. That is what was missing. Next, I want to try the 27B and run the full 215 tasks. If you want that, tell me in the comments and tell me which phone task you’d throw at it. If you’re looking for cheap and reliable GPUs, I use RunPod and the link is in the description. That’s open Mobile too. Thanks for

[14:11] watching and I’ll see you in the next one.