laya-mlx plays Snake at 60 decisions per second on an M3 Max
介绍比Jev快50倍，在你设备上跑的laya-mlx! 只在你的设备上占用最高1G内存 Laya是一个开源的类似于Jev的,基于文本输出概率的分类系统 我将其移植到MLX,并且做了一些性能优化! 视频中就是这个模型在我的本地M3Max上玩贪吃蛇 这个模型能够以每秒决策60次的速度玩贪吃蛇！
Project: laya-mlx→Seen on X
What people are building with Laya.
Demos, games, ports and benchmarks posted on X, picked by hand. Each one links back to the original post and, where there is one, to the project in the directory.
Local Laya beats Jev at Tetris on a MacBook Air
Local Laya moggs Jev at @grok 4.7-built Tetris 🧩 An open-weights System One model called Laya, beat cloud-based Jev at playing Tetris by making decisions 11 times faster, running locally on a 16GB MacBook Air! Run AI models locally ->
Jev decision layer routes tasks and recovers from tool failures
jev + opus 5.5... i simply can't comprehend why everyone isn't building this yet. in my workflow, this cut costs and time by ~80%. i think it's one of the best ways to use it. → pick relevant project notes before loading the context → route suitable tasks to a faster worker → choose a recovery path when a tool fails → run focused checks before the full test suite opus handles the hard reasoning. jev picks from options the harness prepares and validates. i explain how to build the decision layer in the article below:
Local Laya checks spider links 3× faster than cloud decision models
Local Laya beat @OpenAI's decision API 🕷 Four decision models raced down a web page ripping out links that name a spider and Laya running locally on an M5 Max took 34 ms a link so it checked 3x more than the cloud models Run decision models locally ->
Laya plays Tetris locally with decisions in about 27 milliseconds
This is NOT Jev. Open source. Runs on your laptop. Decides in ~27 ms, about 200× faster than waiting on a hosted LLM. Here it is playing Tetris by itself 👇
Unsloth Desktop serves Laya decision models locally on 4GB RAM
You can now run Laya Decision models locally on just 4GB RAM! 🔥 Works on CPU, Mac, Windows, Linux and GPU setups. Serve Laya through a Jev-compatible API via Unsloth Desktop. GitHub: Guide:
Self-hosted Laya sorts 600 files into categorized desktop folders
Jev cleaned my desktop! 600+ files sorted neatly into categorized folders. All for free. Because I self-hosted Laya (open-source Jev alternative, 29k GitHub stars) on InstaCloud ☁️
Ollaya runs Laya locally to cut decision-model API costs
최근 Jev와 Kev로 개발자 판이 발칵 뒤집히더니, 결국 '끝판왕'이 나와버렸음. LLM 호출 97% 삭감하고 속도를 10배 올리는 의사결정 모델을, 마치 'Ollama'처럼 내 맥북 로컬에서 명령어 한 줄로 돌리는 오픈소스 'Ollaya'. 클라우드 API 비용 0원, 몇 밀리초 만에 에이전트 판단 끝내는 치트키 👇 (타래)
QVAC SDK 0.22 adds Laya support for probabilistic decisions
QVAC SDK 0.22 is out, and it adds Laya, a model that makes decisions instead of writing text. We added: - Laya support: answers the questions you define, each with a probability - CUDA support: for LLM, embedding and VLA models. - MiniMax-H3 image to video: start a clip from your own picture - MOSS-SoundEffect v2: create sound effects on device - Model fit checks: broader model coverage, improved estimates for model combinations, and opt-in load refusal before model loading begins - Parallel tool calls: agents run several tools in one turn Learn more in the thread below. Complete release doc here: Star ⭐️ for updates.
laya-coreml runs 99.5% of operations on ANE at 3.7 ms per decision
Thanks for the model, we were able to port Laya to coreml with 99.5% of the ops on ANE + benchmarked too. it is now blazing fast with 3.7 ms per decision on an M5 Pro. Release: Models:
Project: FluidUse→
A profile tells the story of Laya creator Nandakishor M
He comes from a small village in Kasaragod, Kerala. In 2016, he was selected for IISER Mohali but couldn't afford to make the move. He eventually studied engineering at Government College of Engineering, Kannur. Last week he released Laya, an open-source AI model that challenged TypeSafe’s Jev on speed and on published decision-making scores. This is the story of Nandakishor M and how he built Laya.
A step-by-step Jev build guide with code and architecture
everything you need to start building with jev, in one article. code, architecture, diagrams... everything you need to follow the build and make it your own.
Laya uses all 20 moves without solving a Rubik’s Cube
Opus 5.5 is crazy, and this is yet another proof. 3 moves. That's all it needed to solve the Rubik's Cube and beat GPT-6 Sol, Jev and Laya, with the same limits for all four models: 20 moves or 5 minutes. Opus 5.5 solved it in 1m 12.87s with the perfect 3 moves. GPT-6 Sol made a wrong first move and ran out of time after 4. Jev and Laya both used all 20 moves without solving it.
Kaggle notebook fine-tunes Laya for typed decisions
Asking everyone to fine tune Just use any kinda agentic harness like claude code, codex etc. Change the code and use free kaggle GPUs to train your own use cases. Base model has limitations
Project: laya→
Laya runs Tetris locally at 43 ms per decision on a MacBook Air
Local vs cloud at Tetris. • Jev (cloud): 316ms per decision, buried alive, game over • Laya (local, open-weights): 43ms per decision, running clean on a 16GB MacBook Air 11x faster and it didn't even need the cloud to get there.
Self-hosted Laya sorts 13,000 emails into labels in three seconds
Jev cleaned up 13000+ emails in my mailbox in 3 SECONDS Sorted them neatly into categorized labels. All for free. Because I self-hosted Laya (open-source Jev alternative, 29k GitHub stars) on InstaCloud ☁️
Laya plays Snake at 60 decisions per second
So we already have an open source alternative similar to Jev... and 50x faster?! Laya is an open source classification system: - runs on less than 1GB memory - available on hugging face - can run on any laptop/phone Quick example where it plays Snake at 60 decisions/sec! BUT it has some limitations: 1. For now it only has a 1k context so some use cases won't fit 2. It's not as good as Jev when it comes to generalization (but very easy to fine tune it if needed)
Kaggle notebook guides fine-tuning multilingual Laya
If you are fine tuning laya. Use And use the multi lingual base model
Project: laya→
Laya-mlx processes 20 Chinese support tickets in 25 ms
Jev 发布才 8 天，开源替身已经一堆了，今天诺基亚也来蹭热闹了😅 我在 MacBook 上，让官方 Jev 和 3 个开源方案同跑 20 张中文工单🫱 Laya 25ms，比 Jev 快 50 倍 djev 509ms 官方 Jev 1.3 秒 AnyJev 将近 4 秒 仓库都在这： Laya（Mac 版） djev（Mac 版） AnyJev 但快的，不一定对 👇
Project: laya-mlx→Laya blocks agentic website attacks and checks tool calls on-device
Laya can help protect your website from agentic attack jailbreaking. Imagine a swarm of agents attacking your website, and in under 33 ms, it all gets blocked. Also, before the agent is allowed to call a tool (send email, query a database, execute code, etc.), Laya can answer: “Is this action consistent with the original user request and safe under the current policy?” Low confidence or a clear “no” triggers a human review or hard block. All on your browser with the 421 M model on edge!!!
Project: laya→
Eikos benchmark compares decision accuracy with Laya and Jev
Eikos, um modelo de decisão open source (MIT), alternativa ao Jev e ao Laya. Sai em dois tamanhos, 4B e 27B, com versões quantizadas (FP8, INT4 e MLX para Mac). O que muda: • lê até 64k tokens (Laya: 1k, Jev: 32k) • no JevBench, nível difícil: 82,9% (Jev: 73,0%, Laya: 35,1%) • quando tem ≥90% de certeza, erra só 2,4% das vezes (Jev: 5,9%) Eikos vem da filosofia de Aristóteles, "O provável". Logo mais vou liberar no Hugging Face/GitHub pesos, códigos e datasets que criei sinteticamente.
Laya plays live Tetris locally in 40–50 ms per decision
Locally Laya just beat cloud Jev at live Tetris. Laya System 1 model made Decision time: 40–50 ms. on a 16GB MacBook Air. Jev, running in the cloud, sat above 300 ms. That is enough for 60+ decisions per second.
laya-mlx brings Laya decision models to Apple silicon
this is f*cking gold 12 open-source repos that plug Jev into real AI work, 550.7k stars combined Jev decides, your LLM writes. these repos are where that split already runs: agents > browser-use/jev-ultrafast (~20.3k): Jev picks the next action + DOM element, a small LLM only types. Zürich to London flights in ~7s > awlevin/typesafe-computer-use (~978): macOS computer use, OCR reads the screen, Jev picks the next click local decision models > jaredpalmer/kev (~7.1k): Jev-like models on Qwen, same /v1/systemone wire format > mizorewww/laya-mlx (~6.4k): Laya, the main open Jev-style engine, running on Apple silicon > TheoLeeCJ/SemIf-OpenJev (~4.3k): local semantic ifs from frozen open models, not a TypeSafe project > contrastive-lm/clm (~1.3k): open System One model with a Choice / Noul / Score API > vinnylarouge/jevlike (~1.3k): community trainer and tooling for your own Jev-like model context + skills > tamaratran/fast-jev-compaction (~6.9k): Claude Code plugin, Jev keeps, drops or truncates tool results instead of summarizing context > typesafe-ai/skills (~2.2k): official TypeSafe skill for Claude Code and Codex trading > jarrodwatts/jev-trader (~2.4k): one Jev buy/sell decision per Monad block catalogs > yibie/awesome-jev (~1.7k): the biggest map of Jev projects and discussions > Anil-matcha/awesome-jev-by-typesafe (~851): use cases, patterns and starter code start with jev-ultrafast
Pi adds native Laya classifiers through llama.cpp
Pi v1.1.0 is out! Highlights: - Program status reporting via OSC 7501: terminals and agent dashboards see whether Pi is working, blocked on a dialog or login, done, or failed. PI_PROGRAM_STATUS=1|0 overrides detection. - Claude Haiku 5.5 (anthropic/claude-haiku-5-5) added, with adaptive thinking up to xhigh/max effort and prompt caching on Bedrock. - --tools now accepts +name/-name to adjust the default selection instead of replacing it, e.g. pi -t +codemode,-write. - GPT-6 Luna available as a Decisions API classifier; native llama.cpp models (Julia-1, Laya, Kev, lev, OpenJev) served by llama.cpp 0.6.0+ run as classifiers through /v1/systemone. Complete details in thread ↓
FluidUse runs private form automation with laya on Apple chips
苹果芯片本地自动化迎来新突破：开源项目 FluidUse 实现了完全基于端侧运行的“Computer Use”。 它摒弃了昂贵且高延迟的云端多模态大模型方案，通过 macOS 原生的 Accessibility API（辅助功能接口）直接抓取运行中 Mac 应用或浏览器页面的表单上下文，由 Apple 芯片的 Neural Engine（ANE）或 GPU 运行超轻量端侧模型判定填入内容，再直接驱动系统完成键入与交互。 核心特性与性能亮点： • 极致速度与能效：运行 706K 参数的表单模型 CUA-S1-FORMS 时，在 Neural Engine 上的单次决策延迟仅约 1 毫秒（0.9ms）；搭配 322M 的 laya 模型，单次前向传播直接输出选择与评分概率，无需逐字生成 token， short 决策耗时仅约 3.7ms。 • 全面的端侧模型矩阵：支持 GLiNER 2.5、Kev-0.8B、Clef-vision（端侧视觉决策）、Decision 2.0/3.0 以及用于意图分类与 PII 隐私脱敏的 Vela 2.0。除了自动填表，还适配了 Tetris、2048 等交互演示。 • 100% 数据隐私安全：计算完全在本地设备完成，零数据出机，非常适合财务报销、内部审批、客户凭证录入等敏感场景。 • 清晰的安全边界：专注把字段匹配到已有数据画像，不盲目生成长篇自由文本，且默认不自动触发最终 Submit 提交，兼顾自动化与人工复核。 对于探索端侧 AI Agent、Swift + Core ML 落地以及隐私优先型工作流自动化的开发者，这个项目提供了一套极佳的工程实践范式。 项目链接：
Project: FluidUse→
Laya plays Snake live on a single Acurast phone
Model One Systems, playing Snake on a single phone, live, right now on Acurast. No human player. No data center. 0.37 s per move. The future of AI doesn't need a server farm. It fits in your pocket. Try it out and explore the other demos 👉
Acurast runs Laya email, moderation, and injection-screening demos on Android
The most interesting thing about @Acurast is where it looks for compute: the phone sitting unused in your drawer. Much of the AI infrastructure conversation revolves around building bigger data centers. Acurast is exploring how much useful work we can get from hardware people already own. I think that deserves attention, with one distinction: different AI tasks need different hardware. Training a frontier model is a very different job from classifying an email, filtering a message, or running a small decision model. Smartphones have limits. But there is a market for smaller, repeated tasks that don’t need an entire GPU cluster. That’s where the AI × DePIN thesis becomes interesting to me. Acurast lets developers deploy workloads to a distributed network of smartphone Processors. It adds another source of compute capacity, with a lower barrier to contributing hardware. Whether that capacity is useful depends on the workload, uptime, latency, and cost of getting a correct result. There’s already something concrete to try. Acurast’s Laya demos run a decision model on an Android phone’s CPU. The examples include email sorting, chat moderation, and screening prompts for injection attempts. Acurast reports roughly 0.2–1 second per decision in those demos. You can try them at and inspect the device serving the request. The team also acknowledges the limitations: classifications can be wrong, and queues grow when requests exceed a phone’s capacity. That gives developers a useful starting point: test a task, measure the response, and decide whether the hardware fits. The harder question is trust. If someone else owns the phone, how do you verify the device running your workload? Acurast uses hardware-backed attestation through Google Key Attestation and Apple App Attest. It also checks for revoked attestations and removes affected devices from receiving deployments and rewards. That’s an important detail. Verification has to continue after a phone joins the network. It also means the security model retains dependencies on those hardware and platform providers. Where does $ACU fit? ACU has defined roles in network fees, compute provisioning incentives, staking, and governance. The documentation describes deployment compute costs as gas fees; developers also have a USDC access route. The mechanism I find most relevant is Staked Compute. Providers lock tokens against a compute commitment. ACU holders without hardware can delegate to providers. Benchmarks and heartbeats track capacity and availability, while rewards account for committed compute, stake, and time parameters. This gives providers an economic reason to maintain the capacity they promise. Developers need machines that stay available, not just devices that once registered. There’s an important distinction when assessing those rewards: Acurast’s tokenomics specifies 5% annual inflation, with 70% allocated to the Staked Compute Pool. Staking rewards therefore shouldn’t be confused with revenue from paying compute customers. My view is that incentives can help establish supply. Repeat customers will tell us how valuable that supply actually is. The numbers I’d watch: • Paid workloads and returning developers. • Cost per successfully completed task. • Reliability under sustained load. • How usage grows relative to token-funded incentives. Those measures would tell me more than an onboarded-phone count alone. Acurast’s opportunity is to make distributed smartphone compute useful enough that developers choose it for specific jobs. If it can do that consistently, the connection between network activity and ACU’s utility becomes much more tangible. For anyone curious, Cloud Rebellion offers a way to explore the ecosystem through quests, app deployments, and onboarding a supported phone. You earn MIST points through the program; MIST and ACU are different things. I’d start with a demo and a spare device before committing more resources. If you want to join, here’s my referral link: Referral code: emk6ts
Acurast demos Laya for email classification and chat moderation on mobile
Finding a spare phone is easy; finding a reliable source of computing power is far more difficult. This is the aspect of @Acurast that I find most compelling. Connecting smartphones into a network creates a supply of computing resources. However, for developers to entrust this network with real-world workloads, several additional requirements must be met: suitable hardware, verifiable execution, consistent availability, and a compelling incentive for device owners to remain part of the network. The intersection of AI and DePIN (Decentralized Physical Infrastructure Networks) must address all of these challenges. AI workloads are highly diverse. Training large-scale models requires different resources compared to tasks like classifying messages, running a small inference model, or handling the backend for AI agents. In my view, the computing power derived from smartphones is best suited for tasks that align with their specific hardware characteristics—tasks frequent enough to generate genuine, sustained demand. Acurast aggregates resources from smartphones into a decentralized computing network. Developers deploy workloads, which are then executed by the participating devices. This offers an alternative approach to accessing computing resources, distinct from traditional, centralized infrastructure. The real question is: will a developer continue to use this network after their initial experiment? I would start with a specific, narrow use case—measuring response times, error rates, and the cost per successful outcome. From there, gradually increase the workload. An initial implementation might appear inexpensive, but it can quickly become costly if the application is forced to repeatedly re-execute tasks due to errors. Acurast’s "Laya" demos serve as a solid starting point: a decision-making model running on a mobile device, handling tasks such as email classification or chat content moderation. The published examples are transparent about their shortcomings and processing limitations, which helps users better understand the appropriate use cases for this approach. The $ACU token is integrated into the operational framework through network fees, staking mechanisms, governance, and incentives for those providing computational power. Under the "Staked Compute" model, providers lock up tokens as a commitment to supply computing capacity. Token holders can delegate their stake without needing to operate hardware themselves. Benchmarks and "heartbeat" signals are used to monitor the capacity and availability underlying these commitments. To me, the crucial element lies in the value provided by such a commitment: developers need the assurance that resources will remain available to them tomorrow. Furthermore, it is important to make a clear economic distinction: staking rewards are derived from the protocol’s inflationary mechanism and are not inherently equivalent to revenue generated from customers. A sustainable computing marketplace requires both users willing to pay for services and participants willing to supply the necessary resources. That is how I gauge Acurast’s progress: the return of developers, the presence of meaningful workloads, reliable execution, and competitive costs. The potential is immense if off-the-shelf hardware can consistently meet these demands. Every successfully completed task serves as proof of this. If you’d like to explore it yourself, you can join the "Cloud Rebellion"—a program featuring tasks and opportunities to connect compatible devices to the network. Participants are rewarded with MIST points (distinct from ACU tokens). Try the demo to get a clear sense of how the network actually operates.
Benchmark compares Laya with other decision classifiers
Já expliquei o que é um classificador/modelo de decisão tipo Jev, mas desta vez resolvi criar e rodar meu próprio benchmark em todas as soluções mais populares como Jef, Clef, Laya, Jebediah, etc A idéia não é só quem performa melhor, mas também preços, em quais situações qual modelo é melhor, caso a caso. Vale a pena entender: English:
rapidmlx runs Laya locally to play Snake on a Mac
Blown away by how capable small decision models are getting. 🤯 I just had a local System One model (Laya) play Snake on my Mac via @rapidmlx. No cloud, no text gen—just pure real-time decision making. Avg latency: ~312ms. Zero errors. Local agent loops are insanely fast now. 🐍⚡️
Posted a Laya demo on X? Mention “Laya” and it gets picked up automatically, or submit the project.