Why OpenAI is Perfectly Poised to Fast-Follow Jev

Originally analyzed by Arcturus Labs

The AI landscape has been recently disrupted by TypeSafe's Jev, a novel approach to large language models (LLMs) that has seen explosive growth. According to reports from Vercel, Jev's adoption rate has surpassed every other model in the history of their AI Gateway.

While I wish TypeSafe immense success, there is a looming concern: if Jev's promises are legitimate, OpenAI is in a prime position to ~~simply copy~~ "fast-follow" the product. OpenAI could not only replicate the core functionality but integrate it directly into their agents and future models, creating a synergy that Jev might struggle to match.

The Core Thesis

My argument is straightforward: OpenAI has been utilizing LLMs as implicit classifiers for years. They simply haven't marketed "general classification" as a standalone feature or trained their models specifically for that singular purpose.

If OpenAI replicates the specific training methodology, they can recreate Jev rapidly. Furthermore, integrating a general classifier into their existing ecosystem would enable:

$\text{Faster model selection}$
$\text{More efficient "reasoning" (thinking)}$
$\text{Robust security guardrails}$
$\text{Reduced latency and cost}$

The only remaining question is whether TypeSafe possesses a sustainable moat. Currently, the only significant barrier I see is TypeSafe's proprietary training data and refined training pipelines.

What's Old Is New Again

To support this claim, we must look at the underlying mechanics of how Jev likely operates.

How Jev Works (The Hypothesis)

I assume Jev utilizes a standard LLM architecture. This is supported by Latent Space, which noted that early clones of Jev are indeed LLM-based.

Essentially, given a specific state and a query, the model doesn't "write" a response; it generates a probability distribution for the next token. The logprobs (logarithmic probabilities) are then processed to provide a classification.

Question Type	Mechanism	Logic
Boolean	Token Filtering	Looks only at `true` and `false` tokens; normalizes them into a single probability: $P(\text{true}) / (P(\text{true}) + P(\text{false}))$
Choice	Relative Distribution	Prompted with options (e.g., `A=happy`, `B=sad`). It compares the probabilities of tokens `A`, `B`, `C`, and `D` to find the winner.
Score	Variant Pattern	Likely a variation of the above probability-massing technique.

I actually explored this "choice pattern" in a 2025 blog post titled Supercharging LLM Classifications with Logprobs, noting that even without fine-tuning, this approach was highly effective. As the saying goes, ideas are cheap; execution is everything.

OpenAI's Hidden Classifier

OpenAI has already been doing this—just in a specialized way. This became evident with the introduction of tool calling. In early 2024, I published Tool Invocation – Demonstrating the Marvel of GPT's Flexibility, where I analyzed how GPT decides to trigger a tool.

The ChatML Architecture

OpenAI uses an internal markup called ChatML to structure conversations. It uses reserved tokens like |im_start| and |im_end| to delineate speakers.

|im_start|user
What is the weather in NYC?|im_end|
|im_start|assistant
[The model now decides the next token...]

The very first token predicted after |im_start|assistant acts as a micro-classifier:

If the token is \n $\rightarrow$ The model proceeds with a standard text response.
If the token is to=function $\rightarrow$ The model has classified this request as requiring a tool.

The "Shut Up" Token: A Lesson from GitHub Copilot

While working on Copilot at GitHub, I encountered a raw version of the GPT-4 API. We noticed a bizarre bug: the model would provide a perfect answer but then refuse to stop talking, looping phrases like "Let me know if you have any other questions" until it hit the token limit.

The Discovery: We realized the API required specific headers to enable the |im_start| and |im_end| tokens. Because those headers were missing, the model literally could not predict the "end" token. It had lost its internal ability to classify the conversation as "finished."

Conclusion: The Moat Analysis

OpenAI has been using single tokens as micro-classifiers for years to determine:

Should a tool be used?
Which specific tool is appropriate?
Is the response complete?

The only difference is that OpenAI's classifiers are specialists, whereas Jev's are generalists. However, moving from specialized to general classification is a relatively small leap for a company with OpenAI's resources.

Final Assessment: Unless TypeSafe has a proprietary data advantage that is impossible to replicate, OpenAI is well-positioned to absorb this functionality into their broader agentic framework.