Part 2 : How I helped Abhimanyu to get inside chakravyuga using Laya
On 18th Sep 2026, I published Part 1 of this series, where I explained how I used Jev, a new system one model to predict next moves in a circular maze challenge task. Around the similar time, something else as getting viral in reddit.
Laya - another new kid, but on OSS block!
A r/LocalLLaMA post claimed the Jev architecture was built and open-sourced a year earlier. The author Nandakishor Mukkunnoth later wrote a detailed post on this topic explaining his past research, its similarites to TypeSafeAI’s Jev and his next move to package his research in to a consumable opensource project called Laya.
He said and I quote…
Instead of staying bitter, I decided to take everything I learned, fix every architectural limitation of the old approach, and build a completely open, horizontal System 1 decision model family: Laya.
The result is Laya — 421M parameters, Apache 2.0, open weights, claiming to beat Jev. 3 checkpoints have been released to hugging face along with a recipe for fine tuning as well. A laya py package was also released, which is comparable to TypeSafeAI’s node-js SDK to ease the model consumption.
Putting Laya to test in helping Abhimanyu!
I took the same chakravyuha-jev code which I introduced in Part 1, swapped only the AI call to a local Laya service, and published it as chakravyuha-oss. Same board, same questions, same confidence gate, just a different brain. Following are my observations on the Laya System One model and how it performed in the chakravyuha challenge.
The API contract is near-identical
These 2 projects converged on almost the same interface: POST JSON, { state, questions } in, { answers, usage } out, each answer carrying:
- a choice
- a probability per option
- a confidence.
Laya differs in having no auth (since it is local), no API cost, and the model id set server-side rather than in the body. The client code needed almost no change.
One thing broke: Laya’s head calls topk(2, -1), so a question with a single option raises a RuntimeError and takes the request down. So Sarathy had to tweak the harness not to send single-option questions.
TypeSafeAI’s TOS prevents anyone from comparing Jev with any other SystemOne models. Hence in this post, I’m going to talk about Laya’s numbers specifically. You can read the part 1 of this series to do a mental comparison if you’d like.
Few words on the test system
I ran Laya using the provided laya py package in a VM with 8GB memory and 4 vCPUs. I was not having GPU in that machine and hence all the numbers reported are for CPU only.
Lets see the numbers now!
I asked Sarathy (my AI assistant), to perform 25 runs in easy mode to assess:
- Latency (how fast it is to get a prediction)
- Accuracy (how much laya’s confidence scoring is proportional to the correctness of the step being predicted to solve the maze challenge)
- Batching (how much laya can predict in parallel while keeping an eye on its memory consumption and CPU utilization)
Based on the runs, here is what we (myself and my Sarathy) saw :
- On step mode (i.e predicting one move at a time, played in loop), Laya’s accuracy was only 34.7%. This very much aligns with the author’s claim on his blogpost about baseline checkpoint.
Out-of-the-box base models score ~0.35 on the typed-decisions benchmark (near random). The 0.766 score is achieved by fine-tuning on the benchmark’s train split. Treat Laya as a fast foundation model to specialize, not as an omniscient zero-shot oracle.
- On the batching claim, we found that
layawas able to answer 50 questions in one call, with 50 answers in one response. Speedup: not on CPU. Cost per question is flat at ~1.4 s whether you send 1 or 50, so batching saves HTTP round-trips and nothing more.
| Attribute | Value | Notes |
|---|---|---|
| Accuracy | 34.7% out of 25 runs in easy mode | Matches with author’s own accord. Near random numbers |
| Batching | 50 questions/answers per call | Near identical CPU |
| Latency | ~1.4s / call | Given my setup. mS numbers published in author’s report are for GPU setup |
My take on Laya
Many folks in the hacker news community are blaming the author for not popularizing / productizing his claimed earlier work, but IMO, the author is doing that right now by capitalizing on Jev’s popularity.
Classification models are way old. Generalized classification is also not that new. What the author has claimed is that, laya is more efficient than Jev on some selected trained domains and he goes by quoting the numbers published by some other independent sources as he was not having direct access to Jev’s API. But the out of box classification experience is near random as claimed by author himself and clearly showcased in my experiment. Near random is as good as coin flip and doesn’t really have any utility value.
The author further claims support for indic languages and the size of the model as the moat of laya and makes a case for fine tuned models as the way to apply in real world.
I respectfully disagree with that approach. In my view, the moat of Jev is both the latency and the generalization of the classification tasks with zero training overhead. I agree that the cost structure right now is little skewed as TypeSafeAI has not shared their internal economics of bringing this solution. They might be eating all the losses behind the scenes and still project their product as cost efficient. We never know and we can enjoy while it lasts.
So keeping the cost factor aside, focussing on just the latency, generalization of classification tasks with zero training overhead is a clear moat that TypeSafe’s Jev is still having over Laya. A non-usable project, even if it is open weights with Apache-2 license can only be a science project, not a production product.
I also publish a newsletter where I share my techo adventures in the intersection of Telecom, AI/ML, SW Engineering and Distributed systems. If you like getting my post delivered directly to your inbox whenever I publish, then consider subscribing to my substack.
I pinky promise 🤙🏻 . I won’t sell your emails!