01Live
Hub and registry
Accounts and organizations, model repositories under a stable namespace, versioned files, model cards, systemone.yaml validation, search with decision-native facets, and lineage.
ABOUT
Infrastructure for models that decide.
System One is a registry and developer platform for decision models — models that return a typed decision with calibrated confidence instead of generated text.
0public models
1namespaces
0architectures
How it started
System One Models began with Laya Studio , an open-source environment for fine-tuning Laya decision models, built by Biplov Gautam. It turned training one of these models on a laptop into an afternoon’s work.
Then came the obvious question: now what? A fine-tuned model sat in a folder, and there was nowhere built for it — no place to publish it with its evaluation numbers, to version it, to trace it back to the model it came from, or to hand it to the next developer. The people training decision models had a training loop and nothing after it.
So instead of stopping at training, we asked: why not give them the rest of what they need? The infrastructure to publish what they build, share it, and put it to work. That question became systemonemodels.tech.
Not a language model — so not a language-model hub
Psychologists describe two modes of thinking. System 2 is slow and deliberate: it reasons, weighs, explains. System 1 is fast and automatic: it sees the situation and acts. Large language models are the System 2 of AI, and the tools around them — chat playgrounds, token counts, prompt templates — were built for models whose output is prose.
System One models are the other half. A routing model picks a queue. A game agent picks its next move. A fraud model returns a score. The output is a typed decision with a probability attached, produced in milliseconds, often on a CPU or a phone. What matters about such a model is not how well it writes but how often it is right, whether its confidence can be trusted, and whether it is fast enough to sit in a request path.
You can store a decision model on a general model hub — it is a file. But you cannot filter a general hub by decision primitive, compare calibration across fine-tunes, or trace a policy back to its base model, because none of that is what a general hub records. Every step ends up adapted from a workflow designed for something else. This platform exists so the whole lifecycle — discover, pull, fine-tune, evaluate, publish, deploy — feels native to models that decide.
Who it is for
The developers who train and ship these models, and have been making do: people building game AI and reinforcement-learning agents, robotics controllers, ticket and request routers, risk and fraud scorers, rankers, and small classifiers that run on the device. If your model returns a choice, a score or an action rather than a paragraph, this is meant to feel like your own tooling — somewhere to publish your work under your name, find someone else’s, and build on it with the lineage intact.
It is early, and it is being shaped in the open. The manifest is a draft that changes with real architectures, and what gets built next is decided by what the people publishing here need.
What we store
Everything a model needs, versioned. A repository holds the manifest, the model card, the evaluation numbers, the lineage and the files themselves — each version a fixed set, with every file checksummed. Weights go straight from your machine to object storage and are stored once by content, so six exports of one model that share a tokenizer pay for it once, and downloads come from the edge rather than through our servers.
The metadata that decides whether a model fits your use case lives in a small, versioned manifest rather than a README: which decision primitive it implements, how well calibrated it is, how fast it responds, and what it was built from. That is what makes the registry an answer rather than a directory. Files can also stay where they already are — a version can point at Hugging Face, GitHub or any URL instead.
Where things stand
02Beta
SDK and CLI
Browser login, search, pull with a content-addressed cache, create and push, and manifest validation before publication.
What comes next is shaped by the people publishing here.
Related projects
Laya Studio is an open-source fine-tuning environment for Laya decision models, built by Biplov Gautam. It trains locally, evaluates calibration alongside accuracy, and emits a manifest you can publish straight to this registry.
systemonemodels.org is an independent hub and knowledge layer for the System One category. It is a different layer from this one: it explains and catalogues the ecosystem, while this site is where a developer publishes and operates a model. We are not affiliated with it.