Jev is a decision model: it does not write, it chooses. Most of my portfolio chat's answers already exist as built views, so Jev only has to pick the right one. In a head-to-head test, Jev picked the right view in about 0.3 seconds, three times faster than an LLM choosing the same one.
When someone asks my portfolio chat a question, they should not have to wait to see something happen. If they ask about my skills, the skills matrix should appear. If they ask about my education, the page should show my education. The written answer can arrive a moment later.
That is the reason I added Jev. It makes the chat feel faster, and it does it by doing less, not more.
What Jev is, and what its answers look like
Jev is a decision model. A language model gives you text: you ask, it writes. A decision model gives you a choice. You hand it a message and a list of questions, each with a fixed set of options, and it tells you which option fits. It does not write sentences, explanations or advice. Nothing it returns is free text.
Each question you ask comes back as one of two kinds of answer:
A choice. Jev names one option from your list, gives a confidence score between 0 and 1 that shows how far the top option stands above an even split, and gives a probability for every other option.
A probability. For a yes-or-no question, it returns a single number between 0 and 1.
For every visitor message I ask Jev five questions:
QuestionOptionsAnswerWhich view should the page show?15 views: skills matrix, resume, education, impact metrics, tools, projects grid, off-topic and othersA choice and a confidenceWhich area of work should the projects be filtered by?5 areas, or noneA choiceWhich single project does the visitor mean?5 case studies, or noneA choiceDid they clearly ask for a specific deliverable?8 deliverables, such as an ROI matrix or a KPI dashboard, or noneA choiceIs the message harmful or an attempt to manipulate the chat?Yes or noA probability
Take "What are Roy's main skills?". Jev's whole reply is five small decisions: show the skills matrix with high confidence, no area filter, no single project, no specific deliverable, and a harmful probability close to zero. It contains no sentence at all, and my server turns it directly into what the page shows.
That is why I trust it for routing:
It cannot invent anything. It can only return an option I wrote. It can't make up a view that doesn't exist or leave out a field.
Confidence is something I can act on. I set a threshold per question. Showing a view needs only 0.3, while opening a specific deliverable needs 0.7 and refusing a message as harmful needs 0.85. When Jev isn't sure enough, the page falls back to a plain keyword match.
It only knows what I tell it. Its whole picture of my site is the list of options, each with a short description and a few example questions. I wrote those from my own project list and knowledge base.
It reads little. It gets the visitor's message, the previous answer for follow-up questions and the interface language.
The language model still writes the answer. It just no longer decides where the page goes.
Two kinds of thinking, two speeds
I think of it as the split between fast and slow thinking. Jev is the fast layer: it recognizes the situation and picks. The language model is the slow layer: it reads, reasons and composes. You want the fast one in front, because it is the one that decides whether the visitor sees the right thing right away.
A decision is also cheap to trust. Because Jev returns a probability, I can set a threshold for each question. When it is not confident enough, the server returns nothing and the page falls back to a simple keyword match. Nothing breaks, and nothing gets shown with false confidence.
Why it is fast: nothing has to be created
The skills matrix, the experience matrix, my resume, my education and the impact metrics are not generated. They are built and waiting. When a visitor asks about one of them, the only open question is which one to show, and that is exactly the kind of question Jev answers. It picks, the page swaps in the finished view, and nothing is written along the way.
A language model has the opposite job. To say anything it has to read the question, reason about it and compose a reply, one word at a time. Even a fast model needs time before the first word appears.
Jev against an LLM choosing the same view
To see the difference, I gave the same six questions to two routers that choose from the same views. One was Jev. The other was the LLM router I used before Jev: a small, fast paid model at temperature zero, forced to answer with a strict JSON schema, which is about as quick and reliable as an LLM can be asked to behave. I ran each question five times from the same machine and timed only the decision.
QuestionPreloaded viewJevLLM routerWhat are Roy's main skills?Skills matrix0.31 s1.08 sDoes Roy have a degree?Education0.30 s0.95 sWhat impact has Roy's work had?Impact metrics0.33 s1.19 sMuéstrame el currículum de RoyResume0.32 s1.02 sShow experience matrixExperience matrix0.31 s0.70 sWhat design tools does Roy use?Tools0.31 s0.77 s
Median decision time over all 30 calls: 0.31 seconds for Jev, 0.95 seconds for the LLM. That is three times faster. Jev was also steadier: its slowest call took 0.39 seconds, while the LLM's slowest took 2.05.
Jev picked the expected view on 30 of 30 calls. The LLM picked it on 25 of 30. All five misses were the impact question, where the LLM sent the visitor to the generic projects grid. To be fair, that router's prompt had no impact-metrics view at all, so it could not have picked it. But that is part of the point: with Jev, adding a view means writing one more option with a description and a few example questions. There is no prompt to rebalance.
These timings are the model call alone. In production the visitor also pays for the network, my server and its safety checks, and I measured the right view appearing in the browser after about 0.74 seconds on average for the skills, education, impact and resume questions. The language model still writes its answer after that, and its first word takes about 2 seconds. The matrix is already on screen by then.
These are small tests on a handful of questions, not a statistical benchmark. The direction is what matters: choosing among finished answers is cheaper than asking a writer to choose.
What it feels like
With Jev in front, the visitor is looking at the right matrix in under a second, and the written answer follows while they read it. Without it, the page would wait for the language model to produce something, and routing would depend on text being generated correctly.
The deterministic part matters as much as the speed. On the first live run, a few questions were routed badly: a plural question about latest projects opened a single case study, and a general metrics question got one specific dashboard. Each fix was a change to a description, an example or a threshold. I did not retrain anything or rewrite code. Jev's answers are logged, so I can tune the routing from real questions instead of guessing.
What I would do next
If a decision is all it takes to show a finished view, some questions may not need the slow layer at all. When Jev is highly confident that the view itself answers the question, such as the resume, the skills matrix or the education section, the chat can add a short prewritten line and skip the language model. I am building that behind a switch. I expect those replies to take about as long as Jev's decision, but that is an expectation, not a result yet, so I will share the numbers once I measure them.
Open-ended questions will still go to the language model, because writing is what it is good at.
The takeaways
Build the answers once, choose them live. If the output is one option from a known list, use a model built to choose.
Put the fast layer in front. Let the page react first and the words follow.
Use confidence as a control. A probability per answer lets you be strict where a mistake is costly and relaxed where it is not.
Keep a deterministic fallback. When the decision layer is unsure, the experience degrades gracefully instead of breaking.
If you build chat experiences where the interface has to react to what people ask, I would try separating the decision from the answer. I'm curious how long your users wait before anything on the page moves.