The Laya project directory

Everything the world is building on Laya.

Laya turns any text into typed decisions in milliseconds, on your own machine. Here is what it does, and 2369 projects people built with it.

Input text

“Hi, we were billed twice for March. Please refund the duplicate today or we will cancel our plan.”

laya-mlx · 146 input tokens · 0 output tokens

Which team should handle this ticket?

choice
✓ billing98%
technical1%
sales1%

How urgent is this?

score
not urgent4%
soon15%
✓ blocking81%

Does the customer threaten to cancel or leave?

yes / no
✓ yes84%
no16%

Decided in 30.7 ms · 3 typed answers · one forward pass

Real outputs from Laya, not a mock-up. Run it yourself →

Projects
2369
New this week
67
Platforms
18

Seen on X this month

All demos →

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.

♥ 1.5k↻ 931.7M viewsView on X

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!!!

♥ 413↻ 3810.8k viewsView on X
Project: laya→
Image

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 落地以及隐私优先型工作流自动化的开发者,这个项目提供了一套极佳的工程实践范式。 项目链接:

♥ 313↻ 3321.7k viewsView on X
Project: FluidUse→
Image

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

♥ 300↻ 43.5k viewsView on X
Image

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.

♥ 297↻ 2510.2k viewsView on X
Image

colibri

JustVugg

Runs large open models locally in pure C, including Laya for typed decisions

40.1k·GitHub repo
Image

laya

NandhaKishorM

Runs multilingual typed-decision models and provides routing, serving, and integration options

23.9k·GitHub repo
Image

laya-mlx

mizorewww

Runs Laya typed-decision models locally on Apple Silicon using MLX

6.3k·GitHub repo
C

laya

convaiinnovations

A multilingual-ready System 1 model that returns calibrated typed decisions over text in one pass

28.5k·HF model
Image

laya-coreml

mizorewww

Runs Laya typed-decision models locally on Apple Silicon using Core ML and the Neural Engine

1.4k·GitHub repo
Image

laya

receptron

Runs Laya typed-decision models from Node.js and TypeScript through ONNX Runtime

450·GitHub repo
C

laya-multilingual

convaiinnovations

A multilingual System 1 model that returns calibrated typed decisions over text in one pass

16.7k·HF model
Image

typesafe-mcp

itsmostafa

Connects AI agents to typed-decision models through an MCP server

303·GitHub repo
C

laya-demo

convaiinnovations

A Gradio demo for Laya typed decisions, multilingual routing, moderation, and RAG filtering

288·HF Space
Image

openJev-verdict-2.0

Heman10x-NGU

Develops and benchmarks a non-autoregressive typed-decision model against Jev and Laya

286·GitHub repo
Image

quackd

rokbenko

A Python CLI coordinates robots using LLMs, vision-language-action models, and decision models

244·GitHub repo
Image

laya-ultrafast

ipenywis

Runs a browser automation agent using local Laya decisions through MLX

181·GitHub repo
Image

mu

qybaihe

Provides a coding agent with a judgment kernel that can use Laya as its local judge

179·GitHub repo
C

laya-typed-decisions

convaiinnovations

A Laya model fine-tuned for agent traces, customer service, invoices, and security incidents

4.4k·HF model
Image

FluidUse

FluidInference

Automates form filling on Apple devices with on-device models, including Laya through Core ML

160·GitHub repo
Image

jev-cookbook

datawhalechina

Teaches Jev and demonstrates fine-tuning and serving the open-source Laya model

158·GitHub repo
Image

laya-playground

wdobry

A local website combines Laya model demos, games, a benchmark, and an agent skill

157·GitHub repo
Image

keel

codejunkie99

A macOS coding workspace uses local Laya or hosted Jev to select task routes

122·GitHub repo
A

laya-mlx

aac6fef

An MLX FP16 conversion of Laya for native inference on Apple silicon

121·HF model
Image

laya-vs-jev

virajbhartiya

A side-by-side T-Rex game compares local Laya and hosted Jev decision models

100·GitHub repo
Image

laya.cpp

lkarlslund

A native C++ runtime runs Laya typed-decision models across GPU and Apple backends

89·GitHub repo
Image

jevals

openlayer-ai

Agent evaluation and guardrail tools run with local Laya, Kev, or hosted Jev

86·GitHub repo
Image

system-one-foundation-models

peterfriese

Bridges Laya and Jev System One decision models into Apple’s Foundation Models framework

72·GitHub repo
Image

chat-seek-vscode

fstandhartinger

A VS Code extension searches chat archives and uses Laya to rerank matches

66·GitHub repo