Sam Witteveen explores Jev as a fast classification service rather than a conversational model. His demos cover the basic decision types, support routing, content checks, and tool selection; his closing analysis is careful about what Typesafe has—and has not—disclosed.

Why small software decisions need a different interface

  • Witteveen contrasts slow, deliberate System 2 reasoning with the fast System 1 decisions invoked by Jev’s branding.
  • Many software tasks are modest: classify a support ticket, detect urgency, or check whether an agent output breaks a rule. Generating a long answer before returning a label can add unnecessary latency.
  • He introduces Typesafe founder Diogo Almeida through his work on InstructGPT and presents the company’s motivating question: why has improvement in chat not translated into more automation?
  • The product premise is that software often needs a usable value, not a paragraph it must interpret.

State plus typed questions

  • The state is the material to judge, such as a ticket, log, or agent trace. Questions specify the decisions to make about it.
  • Choice: select from supplied options, returning the choice and probabilities for the alternatives.
  • Score: rate the state against an ordered scale defined by the caller.
  • Yes/no probability: estimate whether a statement or condition is true. The transcript and description spell the name of this third type inconsistently; its behavior is the important distinction here.
  • Rather than asking one broad question such as whether a startup pitch is good, Witteveen suggests smaller questions about feasibility and market type. Ordinary application code can then combine the results and adjust thresholds.
  • He contrasts these outputs with asking a language model to write a confidence number into JSON. A generated number alone does not demonstrate calibrated probability; the demos also do not independently establish Jev’s calibration.

Basic tests: language, sentiment, and question detection

  • Language classification: examples identify French and romanized Thai, the latter avoiding the easy clue of Thai script.
  • Sentiment scoring: a scale from zero to two separates negative, mixed, and positive examples. Repeated calls produce slightly different scores and confidence values.
  • Question detection: the demo includes questions without question marks and short, ambiguous inputs. Witteveen observes lower confidence on some underspecified phrases.
  • These are useful spot checks, not a representative evaluation set. The visible variation is also a reminder that structured decisions are not necessarily deterministic decisions.

Practical classification tasks

  • A duplicate-charge complaint routes to billing; a sales query routes to sales. A more ambiguous support message produces less confidence and an unclear classification.
  • The same support state can be assessed for refund requested and time sensitivity. Adding urgent wording changes the urgency result without requiring a different workflow.
  • Witteveen also tries injection-like text and sarcasm, and describes promising results on code-safety judgments, personally identifiable information, and spam detection.
  • Those examples do not establish adversarial robustness or certify code safety. They show candidate tasks for further testing.

Selecting a tool is not calling a tool

  • Jev can choose which tool should handle a request, but Witteveen emphasizes that this is not the same as extracting the arguments and issuing a complete function call.
  • The application still needs another component to construct the tool input and execute it.
  • He also runs a sequence of 20 tasks, reporting a total cost just over one-twentieth of a cent. Some could have run in parallel; the point is how inexpensive a chain of small classifications can be.
  • At recording time, he quotes OpenRouter pricing of 4.2 cents per million input tokens and no output-token charge. That is historical pricing reported in the video, not a current price check.

What is known about the model—and what is speculation

  • Witteveen says Typesafe advertises a new architecture, a parallel sampler, and reinforcement learning for calibrated decisions (RLCD).
  • He also says the launch material provides no paper or architecture diagram explaining those mechanisms in detail.
  • His idea that a transformer might use its input-processing stage to feed classification or regression heads is explicitly a hypothesis, not a disclosed implementation.
  • He quotes a roughly 70–500 millisecond decision range and links the speed argument to avoiding sequential text generation. Network round-trip time still affects application latency.

“Cannot hallucinate” needs a narrow reading

  • Witteveen interprets the claim as an output constraint: no malformed JSON, invented tool names, or answers outside the supplied schema.
  • That does not prevent the model from selecting the wrong allowed answer. Format validity and decision quality are different properties.
  • He cites Doom gameplay as an illustration of rapid repeated choices and reports an example cost of about $7 per hour at ten queries per second. This capture has not reproduced that workload or its billing.
  • His practical recommendation is to compare Jev with existing classification approaches, including task-specific BERT models, on the actual use case—not assume the demonstrations settle the question.

The open question

  • Witteveen wonders whether general-purpose decision models will reduce the need to fine-tune small classifiers and predicts interest in open-source alternatives. Both are forward-looking judgments.
  • He closes by asking for failure cases as well as successes: where does Jev not work, and which tasks expose its limitations?
  • This post is an outline of the full transcript, checked against the video’s title, channel, description, and original publication timestamp. It does not independently verify the vendor’s speed, calibration, or architecture claims.