Laya Pricing: What the Free Decision Model Costs to Run

Laya is an open-source decision-model family from Convai Innovations, published on Hugging Face on 18 September 2026, three days after TypeSafe launched Jev. Like Jev, it takes a state plus typed questions and returns typed answers with probabilities in a single forward pass. It does not generate text.

There is no per-token price, no seat and no rate card. The weights are Apache-2.0, so commercial use, modification and private deployment are allowed. What you buy instead is compute, storage, monitoring and the engineering time to make the model accurate on your own decisions.

The English laya checkpoint is a 421M-parameter decision head on ModernBERT-large with a 512-token default context. After the option budget, that leaves roughly 320 tokens for state. laya-multilingual uses mmBERT-base at 322M parameters with a 1,024-token default context, extendable to 8,192, and covers more than 100 languages. laya-typed-decisions is the 421M model fine-tuned on a typed-decisions benchmark's training split.

These windows are much smaller than Jev's 32,000 tokens. Laya suits short states such as a ticket subject, a single message or a pending tool call. It is a poor fit for whole email threads or documents, unless you summarise first and pay for that summarisation step.

Convai reports a median latency of about 32.8 milliseconds per decision on a Tesla T4, and the model runs in under 1 GB of memory. At that speed one T4 handles roughly 30 sequential decisions a second, about 79 million a month at full utilisation. Capacity is rarely the constraint; the always-on instance is.

At an indicative $0.35 an hour, one T4 running all month costs about $252. Add a second instance for availability and the floor is about $504 a month before monitoring, logging and on-call time. Teams that already run GPU inference can absorb this; teams that do not should price the operational work honestly.

Jev costs $0.042 per million input tokens on OpenRouter, or about $0.0000222 per 500-token decision after the 5.5% credit fee. Divide $252 of monthly hardware by that, and break-even is about 11.4 million decisions a month. With a 2,000-token state, Jev costs four times as much per decision and break-even falls to about 2.8 million a month.

Engineering time moves the line sharply. Forty hours of labelling, fine-tuning and evaluation at $100 an hour is $4,000. That would buy about 180 million Jev decisions at 500 tokens. Below tens of millions of decisions a month, the metered API is usually cheaper once people are counted.

On the typed-decisions benchmark of 2,000 decisions across four workflows, the base English checkpoint scored 0.362 and the multilingual one 0.352. Random choice scores 0.318, and always picking the most common label scores 0.461. So the base checkpoints sit below the majority-class baseline zero-shot. Only the fine-tuned laya-typed-decisions checkpoint, at 0.766, is clearly useful there.

Calibration needs work too. Convai reports an expected calibration error of 0.081 after refitting temperature on held-out domain data, against 0.466 out of the box. If your code branches on probability thresholds, budget for a held-out labelled set and a calibration step, or the thresholds will be wrong.

Laya is the better economic choice when decisions must stay inside your network, when the per-decision latency budget is tens of milliseconds, or when volume is high enough that metered tokens dominate. It also suits edge devices and Apple Silicon, where community ports report very low latency without a GPU.

It is the wrong choice for a small team that needs good zero-shot answers on many-option questions this week. In that case, start on Jev or Solar Decide through OpenRouter, collect labelled decisions, and revisit Laya once you have a dataset to fine-tune on and the volume to justify running it.

Self-hosting adds work that a metered API hides. You need a serving stack, health checks, autoscaling or a fixed capacity plan, model versioning, and a rollback path when a fine-tuned checkpoint misbehaves. Each new label set or question type means another round of labelling, training, calibration and evaluation before it reaches production.

Monitoring matters more for a decision model than for a chat model, because code acts on the answers without a person reading them. Track the distribution of answers and probabilities, compare samples against human labels each week, and alert when either drifts. Budget a few engineer-hours a month for this even when nothing breaks. That ongoing time, not the GPU, is often the line that decides whether Laya is cheaper than Jev for a small team.