ngLover

OpenCode , the terminal coding agent from the SST team, just shipped v1.17.8 and has 176,000 GitHub stars as of June 2026. Claude Code sits at 132K. OpenCode also topped LogRocket's AI dev tool power rankings this month, displacing Cursor. That's a real market signal, not just GitHub vanity metrics. The core pitch: OpenCode is free, MIT-licensed, and works with 75+ AI providers. You pick the model. The agent is the constant; the intelligence behind it is a config option. What OpenCode Actually Is It's a Go-based CLI with a terminal UI, built by the SST team (the people behind SST and terminal.shop), and it runs on a client/server architecture. The TUI is just one client. The agent process runs on your machine and can be driven remotely from another client, including a desktop app for macOS and Windows. It ships with two built-in agents: a build agent with full filesystem and shell access, and a plan agent that's read-only for code exploration and analysis. An addit...

OpenAI published a paper on June 16 describing something I've been wanting to see for a while: a way to test how a new model actually behaves at scale, using real user conversations rather than synthetic benchmarks. They call it Deployment Simulation . The short version is they replay 1.3 million de-identified production conversations with a candidate model before releasing it, catch behavioral drift early, and find that models have almost no idea they're being tested. That last part is the most interesting finding. The Problem It's Solving Anyone who has shipped AI features has hit this pattern. A benchmark says your new model is better. You do some manual evals. You run your regression suite. You deploy. Then something shifts in a way none of that testing caught, and you find out from user complaints. The International AI Safety Report 2026 has a name for this: the "evaluation gap." It's the systematic disconnect between how models perform on pre-deploym...

I've been defaulting to Opus-tier or GPT-5.5 for anything agent-related because that felt like the safe call. Better reasoning, better tool use, better outcomes. Flash-tier models were for batch jobs, summaries, things where you didn't care that much about output quality. That calculus broke for me after spending time with the Gemini 3.5 Flash benchmarks . The model went GA on May 19 at Google I/O. The number that got my attention: 83.6% on MCP Atlas, a benchmark specifically for multi-step tool orchestration using Model Context Protocol servers. That puts it 8.3 points ahead of GPT-5.5 (75.3%) and 4.5 points ahead of Claude Opus 4.7 on the same eval. "Flash" doesn't mean what it used to. What MCP Atlas Is Actually Measuring MCP Atlas tests whether a model can chain together multiple tool calls across MCP servers, recover from partial failures, and complete multi-step tasks without going off-script. It's not a writing or reasoning benchmark. If you're ...

Claude Fable 5 went live on June 9, 2026. By June 12, the US Department of Commerce had issued an export control directive ordering Anthropic to suspend access to it and Claude Mythos 5 for all foreign nationals. Three days. Anthropic couldn't cleanly separate domestic from foreign users in real time, so they pulled both models for everyone worldwide. As of today, both are still offline with no resolution timeline announced. This is the first time the US government has applied export controls directly to an AI model rather than the chips or hardware underneath it. If you had shipped anything on claude-fable-5 last week, you got a few hours of warning. I want to talk about what this means architecturally, because Anthropic actually shipped a useful resilience mechanism in Fable 5's API design. Most teams hadn't configured it. What Fable 5 Actually Shipped The capabilities are real. Fable 5 shares its weights with Mythos 5 (available only through Project Glasswing to ap...

Multi-armed bandits are an adaptive testing method that shifts traffic toward your best-performing variant as the test runs, rather than holding a fixed 50/50 split throughout. The idea is to minimize the cost of running a losing variant. The problem is that teams adopt them as an upgrade to A/B testing, and they're not: they're a different tool that trades statistical validity for short-term efficiency. If you're using MABs for product features, checkout flows, or anything you'll iterate on, you're probably getting cleaner-looking results that tell you less than you think. The Core Tradeoff You're Actually Making A/B tests assign traffic randomly. That randomness is the whole point. It's what lets you make causal claims. When you can say "I randomly assigned users to this variant, and they converted at a higher rate," you're not just observing a correlation. You've approximated a controlled experiment. MABs discard that guarantee. By ...

I've audited a lot of experimentation programs. The most common red flag isn't a low win rate. It's a suspiciously high one. If your team is consistently reporting 40%, 50%, or 60%+ win rates with lifts above 20% on your primary metric, something is probably wrong. Not "wrong" in the sense of fraud, but wrong in the statistical sense: you're almost certainly looking at the winner's curse. What the Winner's Curse Actually Is The winner's curse is not about bad luck. It's a mathematical outcome of running underpowered tests. Here's the mechanism: when a test is underpowered (say, 30% or 40% statistical power instead of the standard 80%), the test usually fails to detect a real effect. Most runs come back null. But occasionally, by chance, the noise in your data pushes the result over the significance threshold. When that happens, the observed lift is almost always an exaggeration of the true effect. The only way a small, underpowered tes...