laya-serve
Archived Jev-compatible HTTP server for Laya, superseded by upstream laya[serve]; includes a migration table.
Overview
laya-serve was a Jev-compatible HTTP server for Laya System One decision models: point any Jev client at it and get typed choice, score and noul answers from local Laya weights instead of the TypeSafe API. It enforced Jev-style caps (up to 255 choices, 2 to 10 score levels, token budgets) and error shapes, had in-process rate limiting, a model list endpoint and a fake backend for CI.
The repository is now deprecated and archived because upstream Laya ships Jev-compatible serving natively via pip install "laya[serve]", with the same laya-serve binary and POST /v1/systemone. The README provides a migration table covering renamed environment variables, a renamed health endpoint, removed endpoints and backends, different handling of unknown model names (the upstream router auto-selects), and different caps and error formats. It remains useful as a record of differences between the two servers.
What the decision model decides
| Type | Question | Answers |
|---|---|---|
| Choice | Which team should handle this? | billing · technical · sales |
| Yes / no | Any yes/no question via a Jev client | — |
How it works
- Install the package with inference extras
- Start laya-serve with the Laya backend
- Send Jev-format requests to /v1/systemone
- Migrate to laya[serve] for ongoing use
Strengths
- Clear migration guide to upstream
- Documented Jev-compatible caps and errors
Caveats
- Deprecated and archived; no further releases
- Behaviour differs from upstream laya[serve]
Getting started
pip install "laya[serve]" then LAYA_PRELOAD=1 laya-serve (the upstream replacement).At a glance
- Type
- Service
- Language
- Python
- Runtime
- HTTP server
- Has code
- yes
- Has tests
- yes
Use cases and integrations
How curated lists describe it
Jev-compatible HTTP server for Laya System One decision models.
hellogumbo/awesome-jev
Frequently asked questions
Should I use this?
No, it is archived; use upstream laya[serve] instead.
What changed upstream?
Environment variables, health endpoint, error shapes and model handling, per the migration table.
Did it work with Jev clients?
Yes, it accepted Jev's /v1/systemone format.
Related projects
Docker service exposing local Laya, Von, a CLM head or hosted Jev through one TypeSafe-compatible HTTP and MCP endpoint.
MCP serverbetaPythonConverts open Jev reproductions (Laya, Kev, NanoJev, PlayJev) to INT8 ONNX for offline CPU decisions at about 15.6 ms per question.
ServicebetaPythonNative Go runtime serving Gemma 4 12B as a Jev-like decision model with hand-tuned PTX kernels and no CGo or CUDA toolkit.
ProjectbetaGoGo harness for System One models: hosted Jev, open Kev in-process via llama.cpp, and Cloudflare Clef, with typed helpers and a CLI.
ServicebetaGoGo gateway exposing the Jev /v1/systemone contract over ordinary LLM backends by reading single-token label logprobs.
ServicebetaGoRuns Intern-Decision-0.8B on Apple Silicon behind a local /v1/systemone endpoint that accepts screenshots for agent decisions.
ServicebetaPython