everyone is calling Jev a fast LLM. it doesn't…

haven't written in a while. jev broke the silence.

not because it's impressive. because it's a different category of thing and i keep seeing it described as a fast LLM and it's not that.

Jev doesn't generate text. let me say that more precisely: Jev is not a language model, it doesn't output tokens, and the output tokens are free -- $0 per billion -- not because TypeSafe is being generous but because the outputs are so small that metering them is noise. the model takes an unstructured state as input and returns typed values, probabilities, and confidence scores in a single parallel forward pass. no autoregression. no chain of thought. no next-token prediction. a decision, immediately, with calibrated uncertainty attached.

that's a different architecture, a different training objective, and -- the part i want to write about -- a different relationship with WebGPU than anything i've worked on before.

what jev actually is.

Kahneman's System 1 is fast, automatic, intuitive. System 2 is slow, deliberate, effortful. every LLM ever deployed -- even the ones with 30-second reasoning traces -- is System 2 dressed up as System 1. the model generates a token, then another, then another, each step slow enough that you can observe it thinking. the latency is baked into the architecture.

TypeSafe's argument: most software decisions don't need System 2. a game deciding whether an NPC should turn left or right doesn't need a reasoning chain. a real-time routing system deciding whether to flag a transaction doesn't need an explanation. a drone navigating around an obstacle needs a motor command in 50ms, not a chain of thought. these are System 1 decisions. they happen fast, they happen constantly, and the decision tree is constrained and knowable.

Jev was built for this. the input schema is: an unstructured state (current game frame, transaction record, sensor reading, whatever) plus a list of allowed actions. the output schema is: one of those actions, with a probability distribution over the full action space and a confidence score. the entire computation happens in a single forward pass through the model's parallel sampler. no sequential token generation. all outputs computed simultaneously.

the consequence: a decision in 70 to 500 milliseconds end to end, not the seconds an autoregressive model spends generating. 10 decisions per second in a real-time game loop at $7/hour total. that number was impossible with LLMs not because of engineering but because of architecture. $42 per billion input tokens, output tokens free. the pricing structure tells you how the model works: outputs are tiny typed values, not long text sequences. metering them doesn't make sense.

the rlcd training method and why it matters.

standard RLHF teaches a model to generate text that humans rate as good. the feedback signal is: human evaluator reads the output, assigns a score, that score propagates back through the model. for text generation this is correct. for decision making it's the wrong objective. you don't want a decision that a human evaluator finds plausible-sounding. you want a decision that's actually right, with a probability estimate that's actually calibrated.

RLCD (Reinforcement Learning for Calibrated Decisions) trains Jev on outcomes. the model makes a decision. the decision is executed. the outcome is observed. the training signal is: was the decision correct, and was the confidence score calibrated to the actual accuracy? a model that says "80% confidence" should be right 80% of the time, not 95% or 60%. calibration is the thing LLMs are famously bad at -- they express high confidence even when wrong, low confidence even when right. Jev was specifically trained to not do this.

the real-time game demos (Doom, Subway Surfers style, obstacle course drone) aren't just showing that the model is fast. they're showing that a model trained on decision outcomes can make good decisions without generating text. the Wikiracing benchmark -- choose the right Wikipedia link to reach a target article in minimum steps -- is specifically a decision problem without a natural language answer. Jev finishes in fewer steps than LLMs because it's selecting from the full action space in one pass rather than generating text about which link to choose.

the webgpu angle that i haven't seen anyone make.

i've been working on WebGPU kernels for the last few months, building Maple: ternary MoE inference in the browser. the hard parts are all in the kernels -- ternary weight decode, MoE dispatch without CUDA scatter/gather, 3:1 SWA/GA attention switching. all of that complexity exists because LLM inference in WebGPU inherits LLM inference's fundamental bottleneck: autoregressive decode, one token at a time, 33µs dispatch overhead per step × 200 steps = 6.6ms of pure overhead before any compute.

Jev's architecture removes this bottleneck entirely.

single-pass parallel inference on WebGPU: one forward pass, all outputs computed simultaneously, one kernel dispatch for the entire computation. the 33µs Chrome dispatch overhead fires once. not 200 times. the per-step sequential dependency that makes autoregressive LLM inference painful in WebGPU doesn't exist because Jev isn't autoregressive.

the compute pattern is also right. autoregressive decode is memory-bandwidth-bound at small batch sizes (matrix-vector products, waiting for weight bytes, GPU underutilized). Jev's parallel sampler computing all outputs simultaneously is a matrix-matrix operation -- the action space is the matrix dimension, the batch of decisions is the other. compute-bound. tensor cores utilized. the hardware does what it's designed to do.

the output is tiny. a decision plus a probability distribution over the action space. no long text sequences to write back to CPU memory. no token stream to stream to the client. the entire output fits in a few kilobytes. WebGPU's bandwidth from GPU buffer to JavaScript is not the bottleneck when the output is that small.

the 5GB mobile Safari memory limit that blocks Maple on mobile (5.31GB checkpoint barely doesn't fit)? Jev's model is smaller by design -- System 1 decisions don't require 20B parameters. the TypeSafe team hasn't published model size but the pricing and latency imply a much smaller model than any frontier LLM. a small enough checkpoint that mobile WebGPU is plausible without the memory pressure that blocks current browser-native LLMs.

i haven't tried porting Jev to WebGPU yet -- it's behind a waitlist and the architecture details aren't public enough to write the kernels without access to the model weights. but the mapping is clearer than anything i've worked on before. single-pass parallel sampler in WGSL: one compute shader over the full action space, parallel reduction to probabilities, output struct written to buffer. no autoregressive loop. no KV cache. no per-step dispatch. the complexity that made Maple's kernels interesting is mostly absent because the problem Jev solves doesn't require it.

the jevons naming is intentional and worth taking seriously.

Jevons paradox: when you make a resource more efficient to use, total consumption of that resource often increases because the lower cost enables new use cases. steam engines became more efficient; total coal consumption went up because cheap steam power enabled new industries that didn't exist before.

TypeSafe named the model after this explicitly. Diogo Almeida said the name reflects an expectation that cheaper machine intelligence will lead to far wider deployment. at $7/hour for a real-time game loop, you deploy AI decision-making in contexts where it wasn't economically viable before. not ten decisions a day. ten decisions a second. not one application. everywhere a branching decision currently requires hand-written rules.

the automation gap Almeida talks about -- the gap between "AI is capable of this task" and "AI is deployed doing this task" -- is partly a capability gap and partly a cost and latency gap. LLMs are too slow and too expensive for real-time loops. Jev is not too slow. at $7/hour for 10 QPS it's comparable to the compute cost of hand-written rule engines at equivalent scale. the deployment conversation changes when the cost is that low.

this is not a language model that got faster. it's a new category that starts where language models price out. the Jevons paradox naming is telling you: we expect total AI decision volume to go up dramatically when the per-decision cost reaches this level. that's the market they're building for, not the market of making existing LLM applications cheaper.

haven't written in a while.

jev broke the silence because it's genuinely a new category, not a faster version of an old one.

single-pass parallel decision, typed output, calibrated probability, output tokens free.

the webgpu mapping is cleaner than anything i've worked on because the autoregressive bottleneck that makes browser LLM inference painful doesn't exist in this architecture.

the 445x cost claim is self-tested and worth skepticism -- techstock² covered this honestly. wait for independent benchmarks on real-world decision distributions before committing production workloads. the architecture is sound. the specific speedup claims need third-party validation.

P.S. the doom bot demo running at 10 QPS for $7/hour is the best demo framing i've seen for a model launch this year. not because doom is a relevant enterprise application. because 10 decisions per second is the regime where LLMs are categorically excluded on cost and latency, and the demo shows the model working correctly in that regime without flinching. that's the right thing to demonstrate for a new category: not that you're better at what LLMs do, but that you work where LLMs don't. the wikiracing demo makes the same point from a different angle. every demo in the launch is chosen to show a decision problem where generating text first is the wrong approach. that's deliberate product framing and it's correct.