Skip to content

laya-serve

Archived Jev-compatible HTTP server for Laya, superseded by upstream laya[serve]; includes a migration table.

Service

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

TypeQuestionAnswers
ChoiceWhich team should handle this?billing · technical · sales
Yes / noAny yes/no question via a Jev client—

How it works

  1. Install the package with inference extras
  2. Start laya-serve with the Laya backend
  3. Send Jev-format requests to /v1/systemone
  4. 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

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 serverbetaPython
  • Converts open Jev reproductions (Laya, Kev, NanoJev, PlayJev) to INT8 ONNX for offline CPU decisions at about 15.6 ms per question.

    ServicebetaPython
  • Native Go runtime serving Gemma 4 12B as a Jev-like decision model with hand-tuned PTX kernels and no CGo or CUDA toolkit.

    ProjectbetaGo
  • Go harness for System One models: hosted Jev, open Kev in-process via llama.cpp, and Cloudflare Clef, with typed helpers and a CLI.

    ServicebetaGo
  • Go gateway exposing the Jev /v1/systemone contract over ordinary LLM backends by reading single-token label logprobs.

    ServicebetaGo
  • Runs Intern-Decision-0.8B on Apple Silicon behind a local /v1/systemone endpoint that accepts screenshots for agent decisions.

    ServicebetaPython