lmjtfy: a guide in fifteen chapters

Let Me Jev That For You. You know the joke: someone asks a question they could have searched for, so you send them a link that slowly types it into a search box for them. This is that joke, aimed at Jev, and then it gets carried away and actually answers.

Jev is TypeSafe AI's "System One" model. It does not write. You cannot ask it to explain anything. You hand it a question whose answers are already written down (yes or no; one of these five; somewhere on this scale), and it tells you how likely each one is, with numbers you can trust. That is the whole trick, and this site is built around the one thing Jev cannot do, which is write the question.

It is live at https://lmjtfy.fun. Jev's own documentation is at https://docs.typesafe.ai.

Try it. Open https://lmjtfy.fun/?q=Is+a+slot+machine+a+good+retirement+plan%3F and watch. The question types itself, Jev answers, and under the answer is every call that was made to get it, with the bytes that crossed the wire. (That question has been asked before, so nothing is spent: you get the kept answer. Chapter 9 explains why that matters so much.)

How to read this

Every folder in this repository is a chapter, and each one ends with a link to the next. Read them in order and you will know how all of it works; jump in anywhere and the chapter tells you what it is and what is beside it. Each chapter starts with the idea, in plain words, and ends with the parts a maintainer needs (files, invariants, commands). The CLAUDE.md tab on each folder is what an AI agent working here is told on top of the chapter.

If you know Nuxt

It is a website, and its parts have counterparts in any JavaScript framework. Here they are next to Nuxt's.

The whole story in one picture

Here is what happens between Enter and the answer. Every arrow is a chapter somewhere in this guide.

sequenceDiagram
  participant B as Browser
  participant W as Worker (axum)
  participant A as Archive (Durable Object)
  participant J as Jev
  participant L as LLM (Workers AI)
  B->>W: POST /ask {q}
  W->>A: facts about q?
  A->>J: one request, eight questions
  J-->>A: probabilities
  A-->>W: kept, and shared with anyone else asking
  W-->>B: SSE: the transcript so far
  alt the rules need options or a scale written
    W->>A: the LLM's tool call
    A->>L: the request
    L-->>A: tool calls
    W->>A: Jev, judge them
    A->>J: one request
    J-->>A: answers
  end
  W-->>B: SSE: the answer, and every call that made it
  A-->>B: every open page: a toast, and the feeds

In words:

1. Jev is asked about the question first: eight typed questions in one request. Can it be judged at all? What kind of question is it? Is it several? And what is Jev's own answer, read each way? (Chapter 7.)
2. Rules decide what that means (chapter 6). Most questions end right here, with a refusal or with Jev's own answer, and no LLM is involved.
3. Only when something has to be written, the options of a pick, the levels of a scale, the parts of several questions, does the LLM write it, as tool calls (chapter 8).
4. Jev judges what the LLM wrote, in one more request.

Aside. Why go to Jev first, before the clever model that can write? Price. A Jev request costs about a hundredth of an LLM call, so every question Jev can settle by itself is a call the LLM never gets. The whole design leans that way: ask the cheap honest thing first, and only call in the expensive eloquent thing when someone has to write.

Running it yourself

Anyone who clones it can build and test it. No GitHub account needed:

git clone --recurse-submodules https://lmjtfy.fun/lmjtfy.git
cd lmjtfy
nix develop                   # or direnv; the toolchain, from public inputs
cargo test --workspace        # everything but the Worker's I/O, natively
cd apps/lmjtfy && worker-build --release

The other projects, and the client they share

Three more of the owner's projects ask Jev, and all four share one client, jevcrates. Each is served here the same way, with its own pages:

To run the Worker itself you need your own Cloudflare account (Workers AI has no local emulation) and a TypeSafe API key: wrangler login, put LMJTFY_TYPESAFE_API_KEY=... in apps/lmjtfy/.dev.vars, and run wrangler dev in apps/lmjtfy. The budgets and the clone proxy run without their secrets, counting only themselves and answering clones with 503.

For the owner

The owner's shell, nix develop .#owner, adds the tools that read this deployment's credentials from 1Password through the private nix-facts and nix-pkgs inputs:

nix develop .#owner
pitchfork start --local       # the dev server, on http://localhost:8787/
pitchfork logs worker         # what it is doing
pitchfork stop --local

pitchfork supervises the dev server from pitchfork.toml, as it does ~/aifleet's. Its one long-running daemon, worker, is the Worker under wrangler dev, inside op-env-run for the Jev key and through lmjtfy-wrangler for the Cloudflare token. wrangler rebuilds the Worker when a source changes. If it dies, pitchfork starts it again (tools/wrangler-dev).

To deploy:

nix develop .#owner
pitchfork stop --local                      # the deploy builds into the dev server's build/
lmjtfy-wrangler apps/lmjtfy deploy
op-env-run -- lmjtfy-secret jev             # only when the Jev key changes
pitchfork start --local

Both read the Cloudflare token from 1Password, which asks for approval on the Windows side: an "authorization timeout" means its prompt was not answered. The site is public and every visitor spends from the shared budgets. The secrets are listed in chapter 2, apps/lmjtfy/.

Files at the top

Next: Chapter 1, apps/ →