Closed source AI is dead.
A claim about where the AI market is heading—and a question of whether the economics and technical lead of closed labs can hold.
Closed source AI is dead.
I would advise investors to look closely at the economics of closed AI labs. OpenAI and Anthropic are spending at extraordinary scale, while capable open models keep arriving. That raises a hard question: what durable product advantage can closed providers sustain, and where will their next breakthrough come from?
My view has been shaped by hands-on testing. I have been running Qwen3.8 Flash Next and Qwen 3.8 27B for local inference, and I have found them remarkable. In my use, their performance can match the previous generation of Claude Opus 4.5 and, on some tasks, even surpass it. The important qualifier is that this is my experience so far; the task, setup, and evaluation method matter, and I want to make those comparisons more concrete as I continue testing.
I have tested these models on two very different local setups. My main machine has two RTX 3090 Ti GPUs and 64 GB of RAM; there I can run the full 256k context. I can also run both models on a laptop with an RTX 3080 with 16 GB of VRAM and 64 GB of RAM. The trade-off is stark: Qwen3.8 Flash Next generates around five tokens per second on the laptop, and I have to use a much smaller context.
To get started quickly, I use Unsloth Studio to download models and apply its model profiles. Those profiles make it easier to get a model running, while the underlying inference engine still determines how well it performs on the hardware.
Running a model on a laptop does not mean every configuration is fast or supports the same context as a multi-GPU workstation. It does mean the model is available locally, and that people can experiment without sending every prompt to a hosted service. That distinction matters for privacy, access, and control.
A laptop. That changes who gets to experiment, build, and decide where their AI runs.
The next bottleneck is inference
I am now working on the Magnitude inference engine to improve both prefill speed and generation speed. Magnitude did not initially support my dual-GPU setup, so I have been adding the features I need. My branch now supports expert streaming and dual-GPU inference.
In a measured comparison with llama.cpp, I processed a prompt of 14,967 tokens and generated 256 tokens, running each configuration twice with MTP disabled. Magnitude default completed in 92.6 seconds at 10.4 tokens per second; llama.cpp completed in 109.9 seconds at 11.2 tokens per second.
| Configuration | Total model time | Generation speed |
|---|---|---|
| Magnitude default | 92.6 s | 10.4 tokens/s |
| llama.cpp | 109.9 s | 11.2 tokens/s |
Workload: 14,967 prompt tokens + 256 generated tokens. Two passes per configuration; MTP off. In this run, Magnitude took 15.7% less total time, while its generation rate was 6.7% lower. The earlier ~16% prefill improvement is a separate measurement. I will publish the full setup and timing method in a dedicated post.
A rough edge: thinking loops
Qwen 3.8 has also shown a failure mode in my testing: sometimes it gets stuck in a thinking loop and keeps reasoning without making useful progress. Some re-engineered releases appear to address this successfully. Using low reasoning effort also helps reduce the issue in my experience, though it can change how a model handles tasks that need deeper reasoning.
That is part of what makes local model work interesting: capability is only one part of the product. Reliability, latency, hardware requirements, and the quality of the inference stack all shape whether a model is useful day to day.
How the leaderboard compares
I have also been using Artificial Analysis to compare models on a common public benchmark. Its Intelligence Index currently places Qwen3.8 Flash Next at 40 and Qwen3.8 27B at 34 in the xhigh configuration. The leaderboard’s current flagship entries score higher:
| Model and setting | Intelligence Index | Cost per task |
|---|---|---|
| Claude Opus 5.5 · max + fallback | 58 | $5.98 |
| Claude Sonnet 5.5 · max + fallback | 56 | $5.46 |
| GPT-6 Astra · max | 53 | $3.26 |
| Gemini 4 Argon · high | 53 | $1.99 |
| Qwen3.8 Flash Next | 40 | $0.37 |
| Qwen3.8 27B · xhigh | 34 | $1.01 |
Artificial Analysis leaderboard snapshot checked 19 October 2026. The Intelligence Index is a benchmark score, not a percentage. “Cost per task” is its estimated weighted average for one Index task using hosted API pricing. These results compare the listed hosted model configurations; they do not measure local, quantized Qwen inference on my laptop. The leaderboard currently shows Opus 5.5, so it does not directly verify my hands-on comparison with the older Opus 4.5 generation.
This makes the distinction clearer: my experience says these local Qwen models can be surprisingly capable in the work I have tried, while the broad benchmark still gives today’s hosted flagships a substantial lead. The more interesting question is how much of that gap matters for everyday tasks, and what happens when local control, privacy, and running cost are part of the comparison.
The overall score also hides useful differences. Artificial Analysis builds its Index from four weighted groups: agent tasks (30%), coding (20%), scientific reasoning (20%), and general tasks (30%). For my work, the agent and coding sections matter most because they are closest to what I want Naori to do.
What I want to measure in Naori
Naori is my custom harness for software development. It takes a different approach to context compaction and agentic software development. The public leaderboard gives us a reference point, but the next step is to run comparable workloads through Naori and measure both the answer and the engine underneath it: did the model complete the task correctly, and how quickly and efficiently did the full system deliver the result?
| Task group | Public reference | Naori harness result | Runtime measures |
|---|---|---|---|
| Agent / tool use | AA-Briefcase, GDPval-AA, AutomationBench-AA | To measure | Task success, tool-call accuracy, end-to-end time |
| Coding | Terminal-Bench 4.0, SciCode | To measure | Tests passed, retries, prefill and decode speed |
| Scientific reasoning | Humanity’s Last Exam, CritPt | To measure | Answer accuracy, unsupported claims, time to answer |
| General / long-context | AA-Omniscience, GDP.pdf, AA-LCR | To measure | Retrieval accuracy, prompt prefill speed, peak memory |
The Artificial Analysis Index gives these groups weights of 30%, 20%, 20%, and 30% respectively for agents, coding, scientific reasoning, and general tasks. This table is a measurement plan for Naori; its “To measure” entries are not benchmark results. Artificial Analysis measures hosted inference endpoints, while my Naori runs will measure local hardware and the full harness path.
For throughput, I am focusing on prefill speed and generation speed as I explore the Magnitude inference engine. For the harness, I want to track whether the model chooses the right tool, completes the requested work, and avoids getting trapped in a thinking loop. Naori’s approach to compaction and agentic development deserves its own post, where I can explain the design and show how it affects longer software tasks.
The argument I want to test
This is the beginning of the case, not a final verdict. I want to compare specific tasks, hardware, quantization levels, runtimes, and reasoning settings. We should also distinguish open weights from fully open source, and weigh local control against the convenience, reliability, and continuing improvements of hosted services.
My thesis is that local models can already do most of the work I need. With a capable inference engine and a harness designed around how software development actually unfolds, they may be able to surpass today’s bleeding-edge hosted models on complete workflows. That is a claim to test, not assume. The next steps are to publish the Magnitude throughput results and the Naori harness approach, then compare task quality and end-to-end performance side by side.
BENCHMARK DATA · Artificial Analysis LLM leaderboard ↗ · General methodology ↗ · Intelligence Index and task weights ↗