Laya faces vegaml in a benchmark over 1,013,964 Jira issues
I made a developer's two models fight. For science. 1,013,964 Jira issues later: vegaml 1 and laya 0, but laya didn't even train and vegaml ate 120 labels first.
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.
Laya plays Snake locally at 86 decisions per second
Laya beat Jev 43 to 1 with the wifi turned off 86.4 decisions per second against 3.2. 1,281 moves against 47 left side is Laya, an open weights decision model, 421 million parameters, running locally off a 1GB footprint. right side is Jev 1.13.0 over an API. both got the identical typed decision schema and the identical snake, same seed, same 30 seconds predict time 8.9ms against a 258.3ms round trip. P50 latency 9.2ms against 308.7ms and here is the thing that actually matters, because it is not the one everyone will take from this. the cloud model was not playing badly. it was playing late by the time an answer came back, the board it described had already been gone for a quarter of a second. the snake did not die from a wrong move. it died from a correct move that arrived after the moment it was correct in that is a different failure than being wrong, and almost nobody designs for it for anything sitting in a loop with the world, latency is not a performance number. it is the capability ceiling now the honest half, because this benchmark is doing some work. 421M did not out-think anything. snake rewards reaction, not reasoning. hand both of them a real planning problem and the small local model loses so badly it is not a contest. this video does not say local beats cloud what it says is that you picked the wrong one for the loop the shape that works is boring. the slow, expensive, actually intelligent model writes the plan. something small and local executes the plan at 90 decisions a second. i use GPT-6 Astra for the first half of that sentence and i would never put it in the second one of those runs once. the other runs every 9 milliseconds, forever
Laya and Jev manage a simulated city traffic scenario
i made Laya and Jev run the same city for 90 seconds. ambulance at 0:25. accident at 0:40. then a road closure. Jev (cloud): 5.7s wait, 68 cars Laya (local, my mac): 15.5s wait, 35 cars i thought local would win.
A Google Icons search tool powered by JEV with Laya-MLX
Built a tool that searches Google Icons using JEV (Laya-MLX) Should I publish it? 👀
Laya and Qwen play Doom
laya and qwen playing doom gotta explore rl this weekend
Laya runs locally on an M4 Mac with 80 ms requests in Singularity Node
This is Laya, a decision model running locally on my 16GB M4 Mac. Insanely fastttt. ~80ms per request inside the Singularity Node App.
OpenGPT-Voice runs a local interruptible voice loop with GLiNER and Laya
Last month OpenAI launched GPT-Live-1 for realtime voice. I wanted the same interruptible conversation but running fully locally, so I built an open-source version of it. Meet OpenGPT-Voice😌 The loop stays on my machine: Silero VAD → Faster-Whisper → GLiNER/Laya → local LLM → Supertonic TTS → WebSocket The harder (fun) part was the messy edges of real conversation: - Barge-in cancels the active LLM stream and queued audio immediately. - Playback-aware history: interrupt after 2 words of a 100-word reply and only those 2 words enter memory. - Timers and external tasks can finish and speak without derailing the current turn. - The router waits through pauses and self-corrections instead of calling the LLM on every silence. Built for people who want the voice loop inspectable and replaceable: local-first experiments, offline use, and edge setups where you don’t want every utterance sent to a hosted realtime API. Still a POC. It breaks in funny ways. I’m still fixing them (constantly) 💪 Demo + GitHub repo in the comments
How Laya scores typed decisions in a single batched model call
Jev vs. Laya, clearly explained! (a faster, open-source alternative to Jev) Both models solve the same problem. You give them unstructured state plus typed questions. Instead of generating a paragraph, they choose from answers you define and return probabilities your code can act on. But they make those decisions differently. Jev is a closed, hosted API. Its architecture and training are not public, but it works zero-shot and supports up to 255 options. Laya is Apache 2.0 licensed, runs locally, and uses open-weight encoder models. Here is how its pipeline works. → It routes by language first. Plain Python selects the English or multilingual checkpoint before inference. → It creates one sequence for each question. Every possible answer gets a `[MASK]` marker. The question and state provide the context needed to compare those options. → It scores instead of generating. A bidirectional encoder and small decision head assign one score to each option. Softmax turns those scores into a probability distribution. → It batches the questions. They run together in one model call, although every question still carries its own copy of the state. This removes network latency and token-by-token generation. In one independent test, Laya took about 35 milliseconds on a local GPU. Jev took roughly 380 milliseconds over the network. Laya also has no per-call API fee, keeps data on your infrastructure, and can run on older GPUs. But it is not a drop-in replacement for every workload. Jev is a hosted generalist that works well out of the box. Laya is a fast base you need to specialize. Laya makes the most sense when you have a stable answer set and representative training data. Fine-tune it for the task, calibrate its probabilities on held-out examples, and send uncertain decisions to a stronger model or human reviewer. Jev gives you stronger zero-shot decisions. Laya gives you speed, privacy, control, and no per-call fee after you teach it your task. The open-source repository is here: If you want to self-host Laya, InstaCloud provides a really nice and easy way to do so. Check this out: If you're new to decision models, I wrote the full breakdown of how Jev. The article is quoted below.
Project: laya→
Laravel Judgment uses Jev and Laya to handle hard-to-write rules
When you can't write the rule: Laravel Judgment with Jev and Laya
Laya plays Tetris offline on a 16GB MacBook Air in 43ms per decision
本地模型把云端大模型打趴下，靠的往往不是智商，而是物理距离。 最近一个关于俄罗斯方块（Tetris）的 AI 实测对比非常引人深思： • 云端模型（Jev）：单次决策耗时 316ms，由于跟不上方块下落速度，直接被堆满惨遭 Game Over； • 本地开源模型（Laya）：决策耗时仅 43ms，在一台普通的 16GB MacBook Air 上离线丝滑运行，轻松应对。 很多人评估模型时只看参数规模和复杂推理能力，但这个实验撕开了一个被忽视的技术痛点：在强交互、高动态的实时场景下，延迟（Latency）的致命程度远胜于算力。 云端模型并不是“不会玩”，而是它“离战场太远了”。每次决策都要经历网络传输、序列化、云端排队与往返（RTT），这几百毫秒的物理延迟足以让快节奏任务直接崩盘。俄罗斯方块考验的是毫秒级的条件反射，而不是深思熟虑的长链思考。 这也清晰指明了未来 AI 架构的演进路线：“云端做大脑，端侧做小脑”。 宏观规划、海量知识检索交给云端百亿千亿级大模型；而涉及高频交互、本地环境操作、低延迟响应的执行闭环（如游戏操作、系统自动化、具身智能反射弧），必须彻底交给端侧轻量模型。 当一台普通的 16GB 笔记本就能在实时决策上甩开云端，边缘 AI 与小型开源模型的价值才刚刚展现。 #AI #本地模型 #人工智能 #边缘计算 #TechTrends
Acurast runs Laya email sorting and game decisions on real phones
AI 代理为什么需要去中心化手机？ 区块链上的 AI 代理越来越多，有的管理加密资产，有的做链上交易，有的跑推理任务。但它们都卡在同一个地方，往哪儿跑？ 中心化云不行。代理要签交易、处理私密数据、付费调用模型，这意味着私钥和数据都得放到某个服务商的服务器上。本质上是在赌云服务商。 Acurast 和 Teneo 最近做的合作改变了这个。他们在 Base 链实现了完整的闭环： AI 代理收到链上任务，用 USDC 和 x402 标准支付。代理把计算任务发到 Acurast 的手机网络。计算在手机硬件 TEE 里跑，数据和私钥永远封闭。结果回链上，同一笔交易完成支付和执行。 关键是这不是概念。现在真实手机网络上已经跑着 System One 模型做 AI 推理。Acurast 的 Laya 演示每秒处理邮件分类、实时游戏决策、prompt 注入防守，每个决策都可以链上验证。我试过他们的 Mail Sorter Demo，毫秒级返回，整个过程发生在一部真实手机里，没有数据中心。 这解决了 DePIN 最大的疑问。 之前的 DePIN 都在假设存在需求，"我有硬件，借给你赚钱，相信这里有需求"。AI 代理不一样。代理生来就需要计算，这个需求是真实的、不可替代的。一个代理要自主决策、自主付费、自主执行，它必须在某个安全的地方跑代码。中心化服务商不符合代理的独立性要求。 Acurast 现在做的是另一个命题，来这儿跑，我给你验证、隐私和去中心化。 数据支撑 318K+ 手机已接入，10 亿+ 链上交易。Acurast 已在 10 多条链上帮助代理和应用管理加密资产，包括比特币、以太坊。他们用硬件 TEE 和 Android Key Attestation、Apple App Attest 做持续验证，不是一次性检查。Cray 手机集群功能还在开发，上线后可以在去中心化手机上跑大型 LLM。 这是 AI 和 DePIN 真正碰撞的时刻。有一个实际生态需要计算基础设施，Acurast 恰好提供这个。 @Acurast @EchoHunt_ai 创作者活动进行中，200K ACU 奖池，邀请贡献占 40% 权重。如果对这个交集感兴趣，值得深入研究，代理怎么真正独立、链上计算怎么验证、隐私怎么放在硬件层而不是协议层。
Fine-tuning Laya for Snag exposes label errors behind an 82.1% accuracy score
sharing a few things i learned while fine-tuning a small model for snag, a pr reviewer i've been building. the first evaluation showed 82.1% accuracy. but when i ran it inside the actual reviewer, it caught just 1 of 21 defects i’d deliberately introduced. i wanted snag to answer a fairly specific question: does this pr actually do what its linked issue asked for? code can look reasonable and pass its tests while still leaving out part of the request. i wanted a reviewer that could point to the exact requirement and show where the implementation fell short. i started with laya ( an existing 421m-parameter decision model, and fine-tuned it to score answers to narrow questions about the requirements and code. an individual question took around 340ms at the median on my laptop. that made me interested in taking it further. but the early accuracy number gave me more confidence than it should have. i was measuring correctness across individual questions, and most training examples pointed towards full implementation or no conflict. the model could get plenty of those right while missing the problems i actually needed it to find. then i audited the labels. of 83 targeted labels i checked, 36 were wrong. i’d been assigning labels based on how i changed the code. remove an implementation, call the requirement “missing.” remove one case, call it “partial.” that seemed reasonable until i looked closely at what the remaining code did. say a requirement asks for retry delays that double each time. removing the backoff might leave a fixed delay. the code still retries, but its behaviour now contradicts the requirement. i wanted the model to understand that distinction, while giving it examples where i’d made the distinction incorrectly myself. knowing that, i wouldn’t put much weight on the initial 82.1%. some of my generated examples also contained shortcuts. distractor ids looked different from real ones. removing an implementation reduced the number of candidates. those details seemed harmless when i put the examples together. but they could reveal the answer without the model having to understand the code. even after cleaning things up, i struggled to get useful results on unfamiliar repositories. in a later test, i paired the same requirement with its implementation present and absent. the fine-tuned model got both versions right in only 4 of 27 pairs. it was a small experiment, so i don’t think it settles what laya could do with better data. i went into this thinking mostly about the model and the training setup. i underestimated how much of the work would be making sure my own definitions, labels and evaluations were sound. i’m still interested in getting a small local reviewer to work. for now, i think the mistakes are worth sharing too, especially for anyone about to try something similar. wrote up all six attempts, the label audit and the results here. would love to hear what you’d test next. 👇
Project: laya→
Laya evaluates Tetris moves on a real Android phone
What if your smartphone could do more than run apps and play games? What if it could make AI-powered decisions in real time? That’s what @Acurast is demonstrating with Laya. Their latest System One demos put AI to the test in Tetris, where a model evaluates 5 candidate moves and picks the best one, all on a real Android device. No massive server setup. Just a phone making decisions in around 0.2–1 second. The bigger picture goes beyond gaming. This kind of lightweight AI could help power crypto agents without depending entirely on centralized computing. We might be closer to everyday devices becoming part of the AI infrastructure than we think. You can try it out: And also explore more details:
Fine-tuning a Laya classifier to run inside a personal AI system
So @thinkymachines just saved one of our projects. For our mind we are tuning a Laya classifier to run inside the system. I will explain in more detail, but we essentially didn’t want to use Jev for this so we are fine-tuning our own thing based on the research we have done. Anyway, a while back we got rejected by their grant (fair, it was a long shot), but we got some credits, complimentary. And this came SO TIMELY!
Visualizations compare Jev with local models including Laya
Not sure what exactly Jev is? I wanted to understand what it could do, so I built some simple visualisations to test it out. Also just for fun, pitted it against small local models too (kev and laya). I love how easy LLMs make it to learn new things fast these days.
A project compares remote Jev with local Laya and reports Jev performed better
🤖 远端Jev vs 本地Laya：我在项目里实测之后，Jev 完胜，Laya 已卸载。果然不能听自媒体天花乱坠的吹。
A guide to Jev and Laya typed-decision models and when to use them
Nem toda decisão de um sistema de Inteligência Artificial exige um modelo capaz de gerar texto. Imagine um sistema que recebe solicitações de suporte técnico e precisa apenas determinar três coisas: qual equipe deve assumir o atendimento, qual é o nível de prioridade e qual categoria melhor descreve o problema. Ainda assim, muitas aplicações recorrem diretamente a um LLM, aguardam alguns segundos pela resposta e depois precisam validar se o modelo realmente devolveu o JSON no formato esperado. Em setembro de 2026, dois lançamentos colocaram essa prática em xeque. No dia 15, a TypeSafe AI apresentou o Jev, um modelo que não gera texto e devolve apenas decisões tipadas acompanhadas de probabilidades. Três dias depois, a Convai Innovations publicou o Laya, uma alternativa de pesos abertos com a mesma proposta. Neste post, você vai entender o que são esses modelos, como funcionam, em que se diferenciam e, principalmente, em quais situações cada um faz sentido no seu pipeline de IA. Confira:
An open-source Laya MCP runs on CPU
@ErickSky Tengo un MCP con Laya (alternativa open-source a Jev). Funciona de maravillas y solo con CPU. Con gusto te explico para que sirve y te doy acceso al MCP para que te des cuenta de lo que te pierdes
A roundup of local typed-decision tools for sorting support emails
IF YOUR AGENT USES CLAUDE TO SORT EVERY SUPPORT EMAIL, YOU’RE PAYING FRONTIER PRICES TO PICK A F*CKING FOLDER. the Jev article makes a useful distinction: the model that writes a reply doesn’t have to be the model that decides which queue gets the email 5 repos to test that idea on your own tickets: TypeSafe Skills the official skill teaches your coding agent to build with Jev’s Choice, Score, and Noul questions. ▸ System One Adapter send the same typed questions through OpenAI, Anthropic, or Gemini APIs. compare their routes with Jev on labeled tickets instead of trusting a cost or speed demo. ▸ Strands Decider a local 2B decision model for picking options and scoring them with confidence. one way to test the idea without a TypeSafe API key. ▸ Laya another local option: Choice, Score, and Noul, plus a router that selects a checkpoint for the request. its checkpoints download on first use. ▸ jev-starter the layer after the prediction: thresholds, fallbacks, evals, and human review. a confidence of 0.85 is a setting to test, not an accuracy guarantee. ▸ → let the cheap layer sort the queue. call the expensive model when an email actually needs a written reply. keep Send behind a separate decision you control. Jev itself isn’t open-source; the local models here are alternatives, not its released weights. save this before you route another inbox with a frontier model.
laya-mlx runs local decisions and Snake at 75 moves per second
THIS IS F**KING GOLD I found Laya, which now runs natively on Apple Silicon Not via a cloud API Not via PyTorch Not by generating JSON token by token laya-mlx runs open-weight decision models locally using MLX It won't write code or a post for you But in a single pass, it can solve the kinds of tasks for which we usually wastefully query a large LLM: ▸ where to route a ticket ▸ how urgent it is ▸ whether the message contains a jailbreak ▸ which tool to call ▸ whether to skip the next action On an M3 Max, the author shows: > 421M English Laya: P50 13.42 ms > 322M multilingual: P50 7.39 ms > Peak MLX memory: 943.6 MiB and 687.6 MiB And this isn't just some abstract "JSON benchmark. The repository includes a Snake demo where every move gets a new decision from the model locally In an optimized run: 75.4 moves per second over 2,400 moves But there are important limitations: ▸ Apple Silicon only, macOS 14+ ▸ It’s an independent MLX port, not an official release from the Laya team ▸ Model context is 512–1024 tokens ▸ It’s a decision layer, not a replacement for Codex, Claude, or a standard LLM The most interesting part isn't the Snake game It’s that you can keep a large LLM in your app for complex work while offloading quick `choose / score / yes-no` decisions to a local layer with millisecond latency Fewer API calls Less data sent externally Faster execution for chains where one decision blocks the next
Raya fine-tunes Laya for model routing
If the most trending open source Jev alternative Laya is not working for your use case, it is apparently possible to fine-tune it and increase performance Here @CDerinbogaz fine-tunes Laya for model routing I wonder how the process would compare to just fine-tuning BERT
OpenZL benchmarks Laya as a local decision model
Tried integrating Laya, a local decision model, into OpenZL. Results look good.
Project: openzl-laya→
A benchmark finds a fine-tuned encoder beats zero-shot decision models on macro-F1
Everyone is shipping zero-shot "decision models": Jev, Tev, laya, and now Cloudflare's Clef! I benchmarked them against the most boring baseline there is: a fine-tuned encoder On a taxonomy of my own the worst fine-tune beats the best zero-shot by 29 macro-F1 points, at $0.80 per 1M instead of $113 😈
Laya calculator-intent model improves unseen decisions from 50% to 93%
@UnslothAI Trained a Laya decision model to answer "does this message need a calculator?" for my agents. 4GB AMD RX 6500 XT, 40 steps, 25 seconds: 50% → 93% on decisions it never saw. Can't wait to train a whole stack of these!
Tetris matchup shows tuned Laya beating Jev after training
Jevのイベントをｸﾘﾌﾟﾄｶﾌｪ（@CryptoCafenBar ）で実施ー リサーチと共に laya（学習なし）とチューニングさせたlayaをテトリスで勝負させ評価 Jev ＞ laya（学習なし） Jev ＜ laya（学習あり） decisionsAPI, clefと共にローカルAIとクラウドのデータセキュリティなどを議論しましたー📝
StackOne benchmarks Jev against Laya for agent tool-call policies
We just launched our @stackonehq Tool Policies: tool, field, value, PII and semantic rules on every tool call your agents make, per user and group. Semantic rules run on @typesafeai's Jev, which we picked after benchmarking it against Clef and Laya on real connector fields. it decides if a tool input or output goes against a specific policy (eg. does it look like "compensation data" - or my favorite: "is this AI slop going to notion?").🧵
TandemLLM uses Laya to choose model thinking effort
still one of my favorite things i built. Laya is only 421m and answers a bunch of questions in milliseconds on the spark. back then i was wiring it into TandemLLM so it could sit next to any main model and make decisions. first feature was auto thinking effort, Laya reads the prompt and picks how hard the model should think. that was the start of the conductor idea. More here:
Boyun simulates economic decisions with agent swarms and Laya inference
Built for NEAR HACKATHON: Boyun ("Part the clouds", a Multi-Agent Simulation Engine for Financial and Economic Decisions). Financial and economic outcomes emerge from heterogeneous actors whose strategic choices, private constraints, and information exchange influence one another over time. The Methodological Gap: > Static models and spreadsheets compress strategic interaction into fixed parameters. > Unconstrained language-model simulations generate open-ended discourse without enforcing resource conservation, observation boundaries, or formal settlement laws. > Analyzing complex economic decisions requires a general simulation engine that unites autonomous agent behavior with exact mathematical accounting. The Boyun Framework: > Inspired by MiroFish, Boyun is a self-hosted Agent Swarm simulation engine where modeled actors operate as autonomous agents communicating across a Social Graph. > Three Formal Foundations: >> Game Theory: defines heterogeneous preference weights, utility functions, resource constraints, and strategic interdependence. >> Social Graphs: directed information graphs, govern observation boundaries, message propagation, and asymmetric information across the swarm. >> Probability and Statistics: formalize declared uncertainty through Bayesian belief updating, seeded Monte Carlo trajectories, and proper scoring rules. Architectural Moat and Capabilities: > Bounded Swarm Inference with Deterministic Settlement >> At each step, agents receive restricted Social Graph observations and score their affordable action menu; Boyun-core then settles state transitions atomically across Strategic, Market, and Lending ledgers under strict conservation laws. > Self-Hosted Decision Inference (such as Laya from >> Executes high-volume, typed agent decisions locally on open-weight models at zero API cost, preserving scenario confidentiality alongside an optional hosted route (Jev from @typesafeai). > Empirical World Grounding and Cryptographic Verification >> Construct and audit executable worlds from external evidence via MCP and Boyun-skills, verify trajectories through bit-identical offline replay, and anchor salted SHA-256 artifact commitments on NEAR. > Decision-Grade Analytical Synthesis >> Compiles five linked research reports (World Creation, Bear Case, Bull Case, Technical, and Decision Record) that separate mechanical ledger invariants from behavioral sensitivities — evaluated across game-theoretic benchmarks, multi-world market dynamics, and credit stress scenarios. Boyun examines conditional trajectories under explicit rules and declared assumptions — bringing strategic interactions and their numerical consequences into view before action. > Website & Paper: > Boyun-core: > Boyun-interface: > Boyun-skills: Built at #NEARHackathon @NEARProtocol @near_ai @ilblackdragon @NEARLegion @NEARDevHub
Project: laya→
OpenRelay serves Laya decisions through a token-priced API
Decision models are a new category: Jev from TypeSafe launched last week, typed answers with probabilities instead of text. Laya is the open-source one. It is live on OpenRelay: POST /v1/decisions, $0.02 per 1M input tokens, nothing else billed.
Testing Laya on Persian RAG context reveals lower accuracy than Jev
روی کانتکست فارسی برای سیستم RAG تستش کردم و من اصلا راضی نبودم! دقتش خیلی از jev کمتر بود و تا 40 درصد افت داشت! باز به بررسی های بیشتر ادامه میدم چون مفتس حیفس!
Posted a Laya demo on X? Mention “Laya” and it gets picked up automatically, or submit the project.