DEV Community

Cover image for LLMs Aren’t the Only Game in Town: A Beginner’s Guide to JEPA, Concept Models and Decision Models
amananandrai
amananandrai

Posted on

LLMs Aren’t the Only Game in Town: A Beginner’s Guide to JEPA, Concept Models and Decision Models

Last week I asked a teammate, "Is the build green?"

He replied with four paragraphs. There was context. There was a history of the CI pipeline. There was a philosophical aside about flaky tests. Somewhere in paragraph three was the word "yes".

That, in one office anecdote, is how we use large language models today. We have a machine that is wonderful at writing, and we keep asking it questions whose answer is one word.

This post is a tour of the models that do something other than write one token after another: concept models, JEPA, diffusion language models and decision models. No maths degree required. Bring chai.

Animated: an LLM types word by word, a concept model drops in whole sentences, and a decision model flips one switch and is finished

First, what is "next-token prediction"?

Your phone keyboard suggests the next word as you type. An LLM is that idea with a gym membership and a few billion parameters.

It reads everything so far, guesses the most likely next token (a word or a piece of one), adds it to the text, and then does the whole thing again. And again. A 500-word answer is roughly 700 tiny guesses in a row.

Animated: an LLM picks the next token from a list of candidates, appends it, and repeats
This works absurdly well. It gave us chatbots, coding assistants and an entire genre of LinkedIn posts. But it has three built-in quirks:

  1. It is slow by design. One token per trip through the network. A long answer is a long queue.
  2. It thinks at the smallest unit. Imagine planning a holiday letter by letter. "G... o... a..." You would never get to the beach.
  3. It always writes. Even when your code only wanted true or false, you get prose, and then you write a parser to dig the answer back out.

Each alternative below attacks one of these quirks.

1. Large Concept Models: think in sentences

The story. My grandmother does not cook letter by letter. Her recipe in her head is "make the tadka, add the dal, simmer". Each step is a whole idea. The exact words come later, and she can say them in three languages depending on who is in the kitchen.

The idea. In December 2024, Meta published Large Concept Models. Instead of predicting the next token, the model predicts the next concept, where a concept is roughly one sentence squeezed into a single vector.

It works in three steps:

  • An encoder called SONAR turns each sentence into a vector.
  • The concept model looks at the vectors so far and predicts the next vector.
  • A decoder turns that vector back into words.

Diagram: sentences go through a frozen SONAR encoder, the Large Concept Model predicts the next concept vector, and a frozen decoder turns it into English, Spanish or Japanese

The neat part is that the vector does not belong to any language. SONAR covers about 200 languages for text, so the same predicted idea can be decoded into English, Spanish or Japanese without running the model again.

Benefits

  • Plans at the level of ideas, which is closer to how people outline before they write.
  • Language-agnostic by construction. Low-resource languages get a ride for free.
  • Long documents become short sequences, since one sentence is one step.

The catch. This is research, not a product you can call from your app. The paper itself notes that sentence vectors can be fragile (a tiny nudge can decode into a different sentence), and for very short sentences an ordinary LLM is actually cheaper.

2. JEPA: predict the meaning, not the pixels

The story. You are crossing a busy road. An auto-rickshaw is approaching. Your brain predicts "that thing will be here in two seconds". It does not predict the exact pattern of dust on its windshield or which way each leaf on the roadside tree will flutter. If it tried, you would still be standing on the kerb next Tuesday.

The idea. JEPA stands for Joint-Embedding Predictive Architecture, a line of work Yann LeCun proposed in 2022. The pitch is simple: do not make a model reconstruct raw data. Make it predict the representation of the missing part.

Diagram: a generative model repaints every hidden pixel, while JEPA predicts an embedding of the hidden patch and compares it with the real embedding

Hide a patch of an image. A generative model is graded on repainting every pixel. A JEPA model is graded on whether its summary of the hidden patch matches the real summary. Unpredictable details simply stop mattering.

The family so far:

  • I-JEPA (2023): images.
  • V-JEPA (2024): video.
  • V-JEPA 2 (June 2025): a 1.2-billion-parameter model trained on more than a million hours of video. After just 62 hours of robot footage, it could plan pick-and-place moves for a robot arm on objects it had never seen.
  • LLM-JEPA (September 2025): brings the trick to language. It keeps normal next-token training and adds a JEPA term. For example, a bug description and the code that fixes it are two views of the same thing, so their representations should be predictable from each other. The extra work happens only during training; the finished model runs at the usual speed.

The "world model" argument. LeCun's long-running claim is that a system which only predicts the next word never has to learn how the world behaves. A toddler knows a dropped spoon falls long before she can say "gravity". A world model learns that kind of physics by watching, then uses it to imagine "if I do this, that happens" before acting. That is planning.

Benefits

  • Learns the gist and ignores noise, so it needs less hand-labelled data.
  • A natural fit for robots and anything that must predict consequences.
  • LLM-JEPA shows the idea can improve ordinary LLMs without slowing them down at run time.

The catch. You cannot chat with V-JEPA. It does not produce text. Today it is a research direction for long-horizon planning, not a drop-in API.

3. Diffusion language models: develop the whole photo

The story. Remember Polaroid photos? The picture does not print from left to right. The whole thing appears as a grey blur and sharpens everywhere at once.

The idea. A diffusion language model starts with a full-length answer made of noise and cleans up the entire sequence over a handful of passes. Many tokens are fixed in parallel rather than one after another.

Animated: the same sentence typed left to right by a classic LLM, and resolved all at once from noise by a diffusion model

This is the same family of technique behind image generators, pointed at text. Inception Labs shipped the first commercial one, Mercury, in early 2025, and Google showed an experimental Gemini Diffusion that May. In February 2026 Inception released Mercury 2, claiming about 1,000 tokens per second.

Benefits

  • Speed. Parallel refinement is the whole point.
  • It can revise the middle of a text, not only append to the end. Handy for editing and code infill.
  • Still a real language model: you get normal text out.

The catch. Speed numbers come from the vendors, and a "tokens per second" figure means little without the test conditions. One independent test measured Mercury 2 at a median of 324 tokens per second, well under the headline. Tooling around diffusion models is also younger.

4. Decision models: just give me the verdict

The story. In cricket, when a run-out goes upstairs, the third umpire watches the replay and the big screen shows two words: OUT or NOT OUT. Nobody in the stadium wants an essay. Forty thousand people want a decision, quickly, and ideally a correct one.

Psychologist Daniel Kahneman called this fast, intuitive mode of thought System 1, as opposed to slow, deliberate System 2. Catching a ball is System 1. Filing taxes is System 2.

The idea. On 15 September 2026, TypeSafe AI released Jev and described it as a "System One" model. It does not generate text at all. You send it:

  • a state (some text or JSON), and
  • one or more typed questions defined in code.

It returns typed answers with probabilities, in a single pass. All the questions are answered in parallel.

Diagram: a support ticket and three typed questions go into Jev, and typed answers with probabilities come out: team billing 0.93, urgency 4 of 5, angry 0.97
The docs list a few question types: Choice (pick one option from a set), Score (a number on a scale) and Noul (their name for a yes/no answer expressed as a probability between 0 and 1). In spirit, your code ends up looking like this:

# Sketch of the idea, not the real SDK. See TypeSafe's quick start for actual syntax.
answer = decide(
    state={"ticket": "I was charged twice and nobody is replying!!"},
    questions={
        "team": Choice(["billing", "bugs", "sales", "other"]),
        "urgency": Score(1, 5),
        "angry": Noul(),
    },
)

if answer.team.choice == "billing" and answer.angry > 0.9:
    page_a_human()
Enter fullscreen mode Exit fullscreen mode

No prompt engineering, no "respond ONLY in JSON, I am begging you", no regex.

Where people use it

  • Routing between LLMs. Is this request easy enough for the cheap model, or does it need the expensive one?
  • Checking an agent's next action. Before the agent runs DROP TABLE users, ask a fast model: is this safe?
  • Classification inside software. Spam or not, which queue, how severe.

A fun detail. The name comes from the economist William Stanley Jevons. His paradox: when steam engines got more efficient, Britain burned more coal, not less, because coal power became worth using everywhere. TypeSafe's bet is the same for decisions. Make one cheap enough and software will make a lot more of them.

Benefits

  • Fast: TypeSafe reports 70 to 500 milliseconds per call.
  • Output your code can branch on directly, with a probability attached so you can set thresholds.
  • Cheap at high volume.

The catch. It only works when you can list the possible answers in advance. It cannot explain itself, write, or reason through a brand-new problem. The headline comparisons are also TypeSafe's own, and the company itself flags limits in its benchmark, such as building the test workflows in-house. Treat it as early access, because it is.

The timeline: how we got here

Timeline from the 2017 Transformer through GPT-3, the JEPA proposal, ChatGPT, I-JEPA, V-JEPA, Large Concept Models, Mercury, V-JEPA 2, LLM-JEPA, Mercury 2 and Jev in September 2026

Read it as a story in three acts:

  1. 2017 to 2022: one unit to rule them all. The Transformer arrives, and predicting the next token turns out to scale further than anyone expected.
  2. 2022 to 2025: "should we predict something else?" LeCun argues for predicting representations. JEPA moves from images to video to robots. Meta tries sentences as the unit. Inception tries the whole sequence at once.
  3. 2025 to 2026: mix and match. LLM-JEPA blends two training goals in one model. Decision models drop text entirely for the jobs that never needed it.

Notice that nobody on this timeline killed the Transformer. Most of these models still use it inside. What changed is the question we ask it.

Cheat sheet: what each approach buys you

Approach Predicts Main benefit Main catch Status in 2026
Next-token LLM The next token Writes and reasons about almost anything Slow, wordy, costly for tiny jobs Everywhere
Large Concept Model The next sentence-sized idea Plans in ideas, works across languages Fragile vectors, research code Research
JEPA / world model The representation of what is missing or next Learns the gist, enables planning No text output Research, early robotics
LLM-JEPA Tokens, plus a representation term in training Better representations at no run-time cost Extra training cost Research
Diffusion LM The whole sequence, refined in passes Very fast generation, easy mid-text edits Younger tooling, vendor-reported speeds Commercial
Decision model A typed answer with probabilities Milliseconds, cheap, no parsing Only for answers you can enumerate Early access

Pick the right model for the job

Twelve everyday tasks. Before the animation sorts them, try guessing where each one goes.

Animated: twelve tasks are sorted one by one into four bins: LLM, decision model, diffusion LM, and concept or world model

Answer key (static version)

The twelve tasks sorted into their four bins

The rule of thumb that falls out of this:

  • Can you list every possible answer in advance? Use a decision model or a small classifier.
  • Do you need real text, right now? Look at a diffusion LM.
  • Is the answer open-ended or does it need actual thinking? That is still an LLM.
  • Does it need planning many steps ahead in the physical world? That is where concept and world models are heading, and it is still research.

Map with two axes, how open-ended the answer is and how fast it must be: decision models and small classifiers bottom left, diffusion LMs bottom right, LLMs upper right, concept and world models in the research corner

In practice these team up. A decision model at the front door routes each request, an LLM writes the hard answers, and another quick decision checks the result before it ships. System 1 and System 2, sharing a desk.

The numbers: latency and cost

Two charts, both built only from figures the vendors or their cited benchmarks have published. Dates are on the charts because these numbers age like milk.

Bar chart on a log scale: Jev 70 to 500 milliseconds, Mercury 2 at 1.7 seconds, Gemini 3 Flash at 14.4 seconds, Claude Haiku 4.5 with reasoning at 23.4 seconds, frontier LLMs on agent workflows 3 to 329 seconds

Bar chart of price per million tokens: Jev 0.042 dollars input with free output, Mercury 2 at 0.25 and 0.75, Gemini 3 Flash at 0.50 and 3.00, Claude Haiku 4.5 at 1.00 and 5.00

Please read these with one eyebrow raised:

  • They are not the same test. Jev's figure is for returning a decision. The LLM figures are for generating a full answer. Comparing them is like timing a nod against a speech, which is rather the point, but it is not a benchmark.
  • They are vendor-reported. Mercury 2's comparison numbers come from Inception. The 3-to-329-second range comes from a benchmark TypeSafe cites.
  • Prices change. Check the pricing pages before you put anything in a spreadsheet.

The honest takeaway is about orders of magnitude: a bounded decision can come back in a fraction of a second, fast generation in a second or two, and a reasoning answer in many seconds.

So, is the LLM dead?

No. Put the pitchfork down.

LLMs remain the best tool we have for open-ended writing and reasoning. What is ending is the habit of using them for everything. We do not hire a novelist to operate a light switch.

The mental model I would keep:

  • Words needed? LLM, or a diffusion LM if speed matters most.
  • A verdict needed? Decision model.
  • A plan needed? Watch the concept and world model research. It is not ready for your sprint, but it is where the interesting papers are.

And the next time someone asks whether the build is green, consider answering like a decision model: "Yes. 0.97."

Sources and further reading

Which of these would you actually put in production first? Tell me in the comments. One-word answers are welcome.

Top comments (0)