[AINews] Here are 6 Clones of Jev in 2 days

來源原標題

[AINews] Here are 6 Clones of Jev in 2 days

作者

Latent Space

原始標籤

blog

原始連結

https://www.latent.space/p/ainews-here-are-6-clones-of-jev-in

摘要原文

We covered Jev’s launch on Wednesday , and they have completely taken over the timeline, with 36M views of their launch video (by comparison, OpenAI’s Navier Stokes result got 74M views, and Anthropic’s Fable 5 got 57M views) in just two days. It wasn’t open source 1 , so it invited tons of speculation and great demos and examples and salty schmidhubers and bad takes , which of course only fed the hype. Here’s a list. The best guesses are ModernBert and Diffusion: Laya : 421M params, ModernBERT -large encoder with two added transformer layers that score user-supplied options, PPO over sequence embeddings to output turn-by-turn conversion trajectories (probabilities from 0.0 to 1.0). salty that he did not get recognition; claims RLCD without justification confidence is entropy-based, not calibrated DiffusionGemmaJev: tackling this from a Diffusion model basis. Pretty close on benchmarks Bespoke Nimble : LoRA finetune of Qwen3.5-9B, using contrastive data curation. ( close but sllightly lower on benchmarks ) SemIf (fka OpenJev) ( HF ): 4B and 35B causal Qwen3.5 backbone with a tiny three-class NLI classifier on the last token. comparison vs Laya Jevlike : 40K byte embedding lightweight option-attention model. Each candidate becomes a query that reads from a shared context representation, then receives a score. Kev-0.5B : LoRA adapter + a small readout head on top of Qwen2.5-0.5B. Of course, not enough people are talking about the data side, which is acknowledged to be 100% synthetic . AI News for 9/17/2026-9/18/2026. We checked 12 subreddits, 544 Twitters and no further Discords. AINews’ website lets you search all past issues. As a reminder, AINews is now a section of Latent Space . You can opt in/out of email frequencies! Decision Models, Routing, and the “Jev” Wave Discriminative models broke out as a new systems primitive : The biggest technical conversation was around Jev , a non-generative decision model being positioned as a fast “ System 1 ” complement to LLMs. @ankrgyl said it is now available as an eval model in Braintrust with ~400x lower scoring cost versus prior setups, while @gabepereyra highlighted calibrated-probability use cases like routing, citation selection, escalation, and legal ops decisions. The more architectural take came from @hxiao , who argued Jev could pull tool calling, routing, and MCP-style decisions back from small generative LMs toward discriminative models; @signulll pushed the same idea further, framing this class as a near-zero-marginal-cost, on-device judgment layer for notifications, UI adaptation, and sensor-driven decisions. Open reproductions and ecosystem clones appeared immediately : @madiator released Bespoke Nimble , an “open Jev” recipe built from a LoRA fine-tune of Qwen3.5-9B using synthetic contrastive data curation and constrained decoding. On its curated eval, the base Qwen improved from 66% to 90% , versus 93% for Jev , with a reported 100ms on H100 and local usability. At the smaller end, @jaredpalmer released Kev-0.5B , a tiny Jev-like model based on Qwen2.5-0.5B that can run on a MacBook Pro. The reaction split roughly along prior experience: @MParakhin noted post-ChatGPT users treated it like a revelation, while pre-GPT ML people were more puzzled by the hype. The substantive question raised by @abacaj is the right one: a lot of demos emphasized speed more than quality , and there is still no standard benchmark for this category. The first compelling integrations were in browser/computer-use workflows : @levie demoed Jev classifying Box incident reports into escalation paths; @ndrezn showed browser use with LangChain + Jev and found it strong on tasks like the Wikipedia game and structured “folding laundry” workflows; @cline shipped a plugin giving Jev a browser in Cline. @hwchase17 explicitly called browser use the best Jev application he had seen so far. Net: this looks less like a chatbot story than a workflow control-plane story. Agent Tooling, Coding Harnesses, and Claude Code Standards AGENTS.md gained real momentum as a cross-tool convention : The highest-signal product update here was @trq212 announcing that Claude Code v2.1.277 now checks for AGENTS.md when no CLAUDE.md is present, with config-level toggle support. That effectively acknowledges AGENTS.md as an emerging standard rather than a one-tool convention, and @simonw immediately noted the practical payoff: fewer shim files that just point one format to the other. Harness design is becoming a first-class variable in coding-agent performance and cost : @pidotdev highlighted the Harness Tax analysis showing that a simple tool set— read, write, edit, bash —can reach the Pareto frontier on benchmark performance while reducing unnecessary spending. Relatedly, @_akhaliq pointed to the paper An Empirical Study of Harness Design for Coding Agents , underscoring that benchmark outcomes are increasingly shaped by harness structure , context setup, turn budgets, and tool affordances rather than just the base model. This is consistent with @dexhorthy ’s “software factory” argument that teams still need to read the code and deliberately design the human/agent interface. Model choice in software systems is bifurcating : Several practitioners described a split between “frontier for planning, cheap for execution.” @TheAhmadOsman summarized one stack as GPT 5.6 Sol XHigh for planning, GLM 5.3 Flash for implementation, and DeepSeek V4.1 Flash for other tasks. @kylebrussell reported an internal knowledge-base pipeline moving from Opus → Sonnet → GLM 5.2 → GLM 5.3 Flash , cutting spend by roughly two orders of magnitude since spring. Meanwhile @theo argued that in real-world coding the payoff from stronger models like Fable and Astra is not just code quality, but a subtler productivity gain in execution and iteration. Benchmarks, Recursive Self-Improvement, and Math Capability RSI discussion got more precise about what is actually “recursive” : @TheTuringPost offered a useful taxonomy: AI improving code or training methods is not, by itself, fully recursive if the surrounding improvement loop remains fixed. The key threshold is when AI can modify not just model internals, but search strategy, experience generation, research tooling, and the improvement process itself . That framing links well with @HuaxiuYaoML ’s RSI-Exam update, where GPT-6-astra remains #1 at 0.5126 , with Fable 5.1 entering at #2 with 0.4813 , and no model yet reaching the frontier-calibrated reference. Math benchmarks continued to fall to frontier models, but interpretation remains nuanced : @EpochAIResearch reported that another FrontierMath open problem was solved in an interactive session with GPT-6 Astra . Separately, @SAIRfoundation launched Open Math Model , pitching open models and tools for mathematics shaped by the research community. Against the “verifiability explains math strength” narrative, @steve47285 shared an argument that pretraining data , not merely verifiable reward structure, is the main reason LLMs are so good at math and coding. The meta-point from @sarahcat21 is worth keeping: we need not just better benchmarks, but better benchmark maintenance and audit tooling . Computer-use benchmarks are still far from saturation : @ValsAI launched CUA-Bench , testing real-time keyboard/mouse use across 6 games (with 3 kept private ) as a proxy for difficult human-easy tasks. Follow-up numbers from @ValsAI suggest this remains genuinely hard: all frontier models score below 20% . In parallel, @trycua open-sourced CUA-S1-FORMS , the first in a family of small “System One” computer-use models. The direction is notable: real-time action loops, video-grounded adaptation, and continuous learning, not just text-only planning. Infra, Training Systems, and Model Architecture Long-context and large-scale training infrastructure remain active optimization fronts : @Azaliamirh released Turbo-dLLM , an open-source library for training diffusion LLMs at scale, reporting 2.