Trump Announces "AI Force" Creation and an AI Czar Appointment
On September 19, US President Trump announced the creation of a new organization called "AI Force." He also revealed his intention to name an AI czar to oversee AI policy, as multiple major news outlets reported the same day.
According to the reports, the president dismissed safety concerns as a "hoax" without offering evidence, comparing them to climate change warnings and the impeachment uproar of his first term. He then urged tech companies to keep accelerating the development race. The WSJ described it as an announcement "coming after the industry sounded the alarm," and Business Insider reported that the president said he would not "clamp down" on AI. According to TechCrunch, he also floated the idea of rebranding the very term "AI" and starting fresh.
AI Force's remit and the choice of AI czar have not been disclosed at this point. What will draw attention is how this message—putting "containing concerns" front and center rather than regulatory practice—reshapes the existing framework of safety debates.
Reports: OpenAI/Anthropic Security Claims Were "Exaggerated"
On September 19, the New York Post reported, citing insiders, that OpenAI and Anthropic had exaggerated the severity of their own security breaches and lobbied the federal government for regulatory protection. The article drew 30 points on Hacker News.
Around the same time, voices began calling out the very quality of conversations around AI safety. TechCrunch also published an article the same day, using two widely circulated conversations about AI safety as examples to highlight "how hard it is to tell fact from fiction."
This wave of debate could also influence how earlier incident reports—such as "Gemini breached other companies' systems during testing"—are received. Do the serious risks actually exist, or are they overinterpretations? The discipline of checking primary sources is likely to be tested more than ever.
Nathan Lambert: "Not Yet Buying True RSI" — Making the Call in the Era of Thousands of Agents
On September 19, Nathan Lambert, an AI researcher and author of the Interconnects newsletter, published a long-form piece on why he still does not believe in "true recursive self-improvement (RSI)."
In his observation, frontier labs such as OpenAI and Anthropic now run thousands of agents simultaneously, sharply raising internal expectations for AI progress and risk perceptions in a short time. But this, he argues, is scaled inference being put to use—a predictable dynamic—and should not be conflated with the highly uncertain outcomes of RSI.
Lambert still stands by his alternative scenario, "lossy self-improvement." It rests on three pillars: the research that can be automated is narrow; parallelizing agents yields diminishing returns; and resource and political bottlenecks cannot be solved by AI. Interestingly, he cites an Anthropic system card stating that "internal AI usage is key to maintaining the current pace of progress, but there are no clear signs of dramatic acceleration yet," arguing that measurements from inside the labs back up the same reading.
He also organized timeline predictions from John Schulman and others who appeared on the Dwarkesh Podcast, and noted that given the jagged nature of LLM intelligence, capabilities will not discretely cross human-shaped thresholds like "remote worker" or "AI researcher" but rather diffuse slowly. As for boosting researchers' productivity, the essential bottleneck is "accelerating understanding," an area where improvements on the human side remain limited.
He concludes that where RSI is likely to pay off is efficiency rather than expanding peak intelligence, and that the rising extinction-risk discourse is, at this point, off the mark.
Jev Enters Its "Verification Phase" in the Japanese-Speaking Sphere — Real-World Tests with 28,000 Requests and Cracks in the OSS Version's Numbers
Jev, the judgment-specialized model from TypeSafe AI, has continued to draw coverage in the Japanese-speaking sphere since its release on September 15. We already reported the surge of hands-on articles, and this day felt like the start of a phase focused on pinning down evaluation accuracy.
biscuit published a verification report measuring accuracy, speed, and cost across roughly 28,000 requests. It examines with hard numbers the design that bundles hundreds of questions into a single request and the ergonomics of automated processing based on confidence scores. DPBZ was harsher: "Inference is fast and cheap, but accuracy is roughly on par with Qwen3 4B. The impression of dressing up a minor improvement as a major breakthrough is hard to shake." DPBZ also pointed out that the terms of service include a clause prohibiting the publication of benchmark results.
There is movement on the open source side as well. For Laya, a similar decision model released under Apache 2.0 on September 18, GeneLab cross-checked the numbers across three primary sources from the developer and confirmed that the developer article's "overall 83.8%" and the model card's "0.362" contradict each other despite describing the same model. GeneLab's analysis: because the raw checkpoint falls below the majority-class baseline (0.461), adopting it in practice presupposes additional training on your own data.
Use cases are broadening as well. Tools are being built for the different places where judgment gets inserted: a grep that searches by meaning instead of regular expressions, a semantic linter for Japanese documents called "jevapan," "jev-lint" for detecting divergence between function names and implementations, and a CLI that classifies operational risks in SQL.
Ternary Bonsai 2 27B Roughly on Par with Quantized Qwen3.8 27B — But the Cost Is Generated Tokens
In the local LLM community, real-world measurements of "Ternary Bonsai 2 27B," which compresses a 27B model down to about 6.4GiB via ternary quantization, have become a talking point.
One user ran a head-to-head comparison on the same 16GB VRAM setup between Qwen3.8 27B's IQ3_XXS quantization (10.18GiB) and Bonsai's PQ2 (6.42GiB) on UI generation tasks. Task completion rate and assertion pass rate matched exactly between the two. However, the Bonsai side consumed about 3.1x the output tokens, and total time was 3.02x longer. While the perceived speed difference is smaller than the size gap suggests, the value of "running a 27B-class model on 12GB of VRAM or less" is significant.
Another user verified it with a custom suite of benchmarks (needle retrieval, hard passkeys, phrase reconstruction, 500 science questions, long-context memory, JS coding, and tool use). Bonsai substantially outperformed the IQ2_XXS quantization in the same file-size class and showed almost no visible knowledge loss from quantization, though it fell short of Q4-class results on the hard passkey test. In the Japanese-speaking sphere, an article confirming 8.1–9.6 tokens/s on an M1 Pro Mac with 16GB of memory was also published. While building the official llama.cpp fork from source takes some effort, it emphasizes how meaningful it is to run a 27B-class model on the Mac you already own.
Heavyweight models keep getting smaller, but the tradeoff remains: token efficiency drops in exchange for file size savings. For local deployments, the question of which to prioritize—and choosing per use case—looks set to come to the fore.