Small decisions.
Everywhere.

01 / The opportunity

Useful software makes
decisions all day.

Which team should handle this request? Which result is relevant? What needs attention first?

Fixed rules work well for clear conditions. Other decisions need an assessment of a message, a document, or the current application state. That is where Jev fits.

The idea behind OpenJEV is simple: make these assessments accessible enough that more developers can try them. One useful decision can become a better feature. Repeated across applications, those small improvements add up.

Start with a decision.
Build something useful around it.

02 / How Jev decides

Context in.
Typed answers out.

TypeSafe built Jev to make structured decisions. You supply the state — the information to assess — and the questions your application needs answered.

Questions in one request share the same state and run independently in parallel. Your code combines the answers with rules you control.

03 / The OpenJEV layer

A shorter path
from idea to API.

OpenJEV is an independent project providing access to TypeSafe’s Jev through OpenRouter. The public API, key management, playground, documentation, and examples give developers a place to start.

1. 01

   Pick one decision

   Route a support request, select an agent tool, or assess a search result.

   Find a use case ↗
2. 02

   Test it with real context

   Try state and questions in the playground. Inspect the answers and the cases that fail.

   Open the playground ↗
3. 03

   Connect it to your application

   Create an account, get a key, and call the API. Keep the action rules in your code.

   Read the API docs ↗

Free access uses shared capacity. Rate limits help manage that capacity as more applications start making requests.

04 / Where $JEV fits

Community funding.
Public intelligence.

Free API access has a cost. OpenJEV’s funding plan uses creator fees from $JEV trading on Pons to help pay for inference — the model use behind each request.

The public treasury shows creator fees and an estimate of the calls those fees could fund. That estimate describes potential capacity. A complete funding record also needs actual model spending and the remaining balance.

Trading fees vary, and every request uses part of the budget. Dependable access will require careful capacity management as usage grows.

More API use alone does not guarantee token demand or returns for holders. The case depends on useful applications, dependable access, and clear funding records.

05 / What progress looks like

Built to be used.
Measured by what lasts.

A launch brings attention. Continued use is stronger evidence that something solves a problem. These are the signals we want progress to be measured by.

• 01

  Working integrations

  A real feature that uses the API to solve a problem for its users.

• 02

  Continued use

  Applications that keep making requests because the answers are useful.

• 03

  Reliable service

  Measured response times, failures, and available capacity as demand grows.

• 04

  Clear funding records

  Fees received, actual model spending, and the funds that remain.

• 05

  Useful contributions

  Examples, test results, and documentation that help the next developer start.