Skip to content
Pocket Grove
Developer blog

Jev, Open Source Experiments, and a Different Kind of AI Decision

Published 24 September 2026 · 7 min read

THE DECISION ARCADE · local model lab

Give a small model one useful job.

Load the open Laya model into this browser, pick an example, then watch its typed decisions update the scene. This is Laya running locally, not TypeSafe's Jev model.

01 / Load the model

Laya · English · compact int4 build

about 299 MB total · includes roughly 291 MB of model weights on first use. Older phones may not have enough memory to prepare it.

Model not downloaded

02 / Pick a scene

Runner: choose the next stretch

The model picks a bounded piece of terrain. The game still owns movement, collisions, and whether the route is valid.

03 / See the result

Waiting for a decision

NEXT SECTION UNKNOWN
Load the model, choose an example, then run it. You'll see the typed answer, its distribution and confidence here.

The runner scene uses the model's choice as a visual cue, not as a production game level. All examples are low stakes; do not use this model output to make consequential decisions.

Local by design: example text is processed in a browser worker on this device and is not sent to an inference API. The model files download from Hugging Face after you choose to load them, then cache in browser storage for reuse. Hugging Face receives the model-file request, not your example text. Your browser can clear the saved model; use “Remove saved files” to clear it now.

Laya is an independent open-source model, separate from TypeSafe's hosted Jev. The compact quantized build may differ from its original checkpoint. Laya model and license · Browser implementation and notices.

Quick answer: Jev is TypeSafe AI's hosted model for structured decisions. You send it context and typed questions, then handle its result in your software. Its weights are not an open-source local download. Around it, independent developers are publishing open-source clients, examples, and integrations. Frankly Decide explores a separate question: what does this decision-making experience look like when a model runs on your own phone?

I started paying attention to Jev because it focuses on a narrow but common problem in software: asking a model to make one bounded decision, then trying to turn a paragraph of generated text back into a reliable value.

That is also the gap behind Frankly Decide, an app we are building around comparing small language models on a phone. The connection is the product question—how to make a model's judgment useful—not shared code or a secret recipe. This article stays at that level.

What Jev does

TypeSafe's API reference describes a request to /v1/systemone: provide a model, some state, and named questions. Questions use typed forms such as Choice, Score, and Noul. The response is structured so an application can work with a decision directly instead of parsing prose.

For example, a support system might pass in a customer message and ask whether the person explicitly requested a refund, which team should handle it, and how urgently a human should reply. A game can do something more visual: snapshot the runner's position and speed, then ask for a legal width, height, surface and gap for the next slice of track. The game turns those bounded choices into tiles; its own physics still decides whether the jump is possible.

That runner example makes the boundary easier to picture. The model can choose among options the game already defined. It does not need to invent a whole level as prose, and the game keeps control of collisions, movement and what counts as a valid segment. A useful prototype can turn those decisions into a live scene, so you can see a choice change the world instead of only reading a JSON response.

In a product workflow, the same rule applies: the code that receives the answer still owns the real-world action. A model response should not silently issue a refund, ban an account, or send a message just because it returned a confident value.

Open the browser lab to try three editable examples: a runner choosing its next stretch, an inbox routing a support request, and a product team sorting a review. The lab loads an open Laya decision model into your browser only when you press the download button; then it runs the examples on your device and shows the typed answers and probability distributions.

Open experiments make the idea tangible

The early Jev use-case wave goes well beyond classification. People have been experimenting with game control, live level construction, inbox triage, browser agents and code review. The interesting pattern is not “put a chatbot in every app”; it is finding a small decision that can alter a real interface while the rest of the software stays in charge.

There is also an open-weight model called Laya that demonstrates a related typed-decision interface running locally in a browser. Our lab uses a pinned, compact quantized Laya build. Expect a first download of about 299 MB; completed model parts are cached in browser storage to make a later visit quicker. The demo checks available storage, reports download progress, verifies the model file's SHA-256 digest, and lets you pause, resume, unload the model from memory or remove saved files. If your browser clears site data, you may need to download it again.

That makes for a more hands-on experiment than a static API diagram, while also showing a real trade-off: local inference keeps example text in the browser, but model size, download time, memory use and device performance become part of the user experience. Laya is a separate model; it is not Jev and does not run Jev's weights. The compact quantized build can also differ from its original checkpoint, so the lab is a learning tool rather than evidence that a model is accurate enough for a production decision.

The ecosystem around the model

“Open source Jev” can mean two very different things. The hosted Jev service is accessed through an API; the model weights are not offered as a local download. But developers can—and do—publish open-source software around the API.

One approachable example is Jev by Example, an independent repository of small JavaScript examples for agent decisions. Community directories such as Awesome Jev collect further projects and resources. These projects can make integrations easier to inspect and adapt, but they do not turn the hosted model itself into open weights. Check each repository's license and current status before depending on it.

That distinction matters when choosing a design. With a hosted API, the request leaves the device and depends on network access, a provider account, and a service contract. With a local model, the application must ship or download model files and do inference on the device; performance and quality then depend on the phone and the particular model. Those are different trade-offs, not a contest with one universal winner.

Why Frankly Decide is looking at on-device models

Frankly Decide is a small, independent app project exploring local model decisions on iPhone. The public-facing idea is simple: choose a model, give it a concrete decision to make, and inspect the result on your own device. We want to make experimentation approachable without sending the decision text to a hosted inference service.

There is a lot of work behind a trustworthy experience—model compatibility, downloads, cancellation, storage, latency, and explaining what a score does and does not mean. I am keeping those implementation details private while the app is still taking shape. The useful public point is the direction: we are testing whether a phone can be a practical place to try small models for bounded, personal decisions.

That does not mean a local model is automatically private in every respect, accurate, or suitable for consequential choices. Privacy depends on the whole app and its network behaviour. A model can also be wrong. Our aim is to make the source of a result and its limits clear, and to leave the decision to act with the person using it.

When typed decisions are useful

Jev's API shape is a good fit when the next software step needs a small, well-defined value: choose the next platform segment in a runner, route a support request, tag a document, rank a short list, or flag an item for review. A general chat model is still useful when you need a flexible explanation, synthesis, or conversation. Many products may use both: one model to reason broadly and a narrower decision step where the application needs a typed answer.

The same product question applies on-device. Could a compact model help someone sort a pasted message, compare options, or label a note without turning the interaction into a long chat? Frankly Decide is exploring that territory. I can share the user problem and the broad experience while keeping the app's model-selection, evaluation, and implementation choices to myself.

A sensible way to try it

If you're exploring Jev, start with a decision that has a clear set of possible answers. Write down what each answer means, send only the context required, and check the returned result against examples you already know how to judge. Keep irreversible actions behind ordinary application rules or human confirmation.

If you are more interested in local models, start with a small, low-stakes task on the device you intend to use. Measure speed, battery, memory, and mistakes there; desktop performance will not tell you how a phone feels. Open-source clients and examples can help you learn the request patterns, while the model and application still need their own evaluation.

Jev and Frankly Decide are different approaches to the same practical question: how can software turn a model's judgment into something useful, understandable, and appropriately bounded? The answer depends on where the model runs, what the decision is for, and who remains responsible for acting on it.

Further reading

Apps from the studio

All apps

These practices come from shipping Pocket Grove's active apps. If you came here looking for something to install, start with one of these.

Related guides