Yes, open-source / open-weight models are important for a healthy AI ecosystem. That's how we can verify things, check claims, and keep up outside the closed labs. Plus, it gives us the freedom to run AI on our own hardware if we are not ready to share personal data and IPs with closed labs through using their models. (Not that proprietary models are bad, actually I use them a lot as well, but it wouldn't healthy not to have any alternatives.)
Anyway, while pretty much everyone is waiting for the Kimi K3 and Ling 3.0 weights to land on the model hub any day now, there were quite a few other interesting new open-weight model releases the past week. Yes, one of those weeks!
So, here are the architecture pics along with some notes on what I found most interesting:
1) Nanbeige 4.2 3B uses looped depth sharing. This basically means it runs the same 22-layer (=transformer block) stack twice. So, it extends the 22-layer architecture to 44-layers, but without duplicating the weights. (2x the transformer block compute but same memory footprint.)
Why? The info is a bit sparse, but section 2.1 of the Nanbeige 4.2 technical report says two passes gave the best trade-off and retained about 75% of the token efficiency of a standard architecture. More passes gave barely any gains but made the training much slower and much more expensive.
2) Laguna S 2.1 is poolside's Laguna model in a really nice size: 118B sparse MoE with 8B active parameters and a 1M-token context window. Otherwise, the architecture is pretty standard. It uses 36 sliding-window and 12 global (gated-)GQA layers. However, given this size, and the fact that it (just barely) runs on my DGX Spark (uses about <80 GB of RAM), this is right now the most interesting model for me personally. It's 3x bigger and thus a tad slower but maybe a good candidate as daily-driver-Qwen3.6-35B-replacement. (Still waiting on some more independent performance benchmarks though.)
3) Motif-3-Beta is a new 314B-A13B sparse MoE that is somewhat based on DeepSeek V4 in terms of mHC and latent attention. But it uses a new component, Grouped Differential Latent Attention, which is inspired by Multi-head Latent Attention. I probably should write an article about this some time, but for now, the tl;dr is as follows. Regular MLA compresses the keys and values into a smaller latent representation to mainly reduce the KV cache size. GDLA does a similar low-rank compression but puts the attention heads into groups and also learns a noise head for each group where the noise gets subtracted for filtering purposes... Anyway, a topic for another day!
4) Solar Open 2 is a new 250B-A15B hybrid MoE by Upstage that interleaves three Kimi Delta Attention layers with one GQA layer.
5) Antares 1B is a small model (and there is also an even smaller 0.3B variant) from Cisco starts that with the IBM Granite 4.0 1B backbone and uses SFT plus GRPO for terminal-based cybersecurity stuff. It is a nice example of task-specific post-training on a genuinely small model.
6) BTL-3 is a rank-32 LoRA adapter for Qwen3.6-27B aimed at coding agents and structured tool use. The really strong benchmark performance suggests that LoRA adapters are still a useful tool/technique in 2026.
I added all six to the LLM Architecture Gallery for some additional details:
https://t.co/JDtfup3ncn
from prompt → context → harness → loop → graph engineering.
the list keeps growing, and every new term gets treated as a replacement for the last one. each layer wraps the one before it, and the cleanest way to tell them apart is to ask what a single unit of work looks like.
𝗽𝗿𝗼𝗺𝗽𝘁 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 𝗶𝘀 𝘁𝗵𝗲 𝗺𝗲𝘀𝘀𝗮𝗴𝗲.
the model remembers nothing before this call, so the prompt has to carry the full universe of what it needs. a role, the background, the instructions, a few examples, a format.
when the output falls short, the skill is working out which ingredient let you down, not rewriting the instructions every time.
the unit of work is one input.
𝗰𝗼𝗻𝘁𝗲𝘅𝘁 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 𝗶𝘀 𝘁𝗵𝗲 𝗺𝗲𝗺𝗼𝗿𝘆.
across many steps the window is finite and the available information is not, which forces a curation step. a curator keeps what matters, compresses what is useful but bulky, and drops the rest.
good curation is mostly about knowing what to throw away, not packing more in.
the unit of work is what stays in the window.
𝗵𝗮𝗿𝗻𝗲𝘀𝘀 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 𝗶𝘀 𝘁𝗵𝗲 𝗺𝗮𝗰𝗵𝗶𝗻𝗲.
on its own a model just generates text. the harness gathers what it needs, runs it, calls tools or sub-agents, and verifies the result with tests or a judge.
that verify step is the entire difference between calling an api and running an agent.
the unit of work is one pass through the machine.
𝗹𝗼𝗼𝗽 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 𝗶𝘀 𝘁𝗵𝗲 𝗿𝘂𝗻.
one pass rarely finishes the job, so something has to decide whether to run the machine again. that decision needs a goal defined upfront, brakes like max iterations and budget caps, and a completion check that is automated rather than felt.
an agent that stops asking for tools has ended its turn, which is not the same as finishing the task.
the unit of work is the whole run.
the diagram covers those four. here is the fifth.
𝗴𝗿𝗮𝗽𝗵 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 𝗶𝘀 𝘁𝗵𝗲 𝗰𝗼𝗼𝗿𝗱𝗶𝗻𝗮𝘁𝗶𝗼𝗻.
once several loops have to work together, you need to say what runs when, what runs in parallel, and who checks whom. nodes do the work, edges decide what runs next, and shared state flows between them.
a single loop is just a one-node graph with an edge pointing back at itself, which is why graphs govern loops instead of replacing them.
the unit of work is the whole job.
here is the part that ties it together.
prompt and context both live inside the harness gather step. the harness is one pass, the loop decides whether to run that pass again, and the graph decides which loops run at all.
zoom out and the unit of work gets bigger. zoom in and you are back at the prompt.
that also tells you where to debug. find the layer whose unit of work broke, then fix that layer.
the prompt is the easiest layer to edit, which is why it keeps taking the blame for failures that live three layers up.
i also published this deep dive on graph engineering, covering the core idea, how to get started, shared state, routing you can trust, and when a graph is genuinely overkill.
the article is quoted below.
This is f*cking gold.
I've just made the clearest explanation of graph engineering you'll find anywhere.
No jargon, no code, no 2-hour lecture, just the four shapes every agent graph is built from.
Read on, and you'll never build with AI the way you did before.
-------
Shape 0 - Basics
A graph is just a plan for your AI work, drawn out so you can see it - which jobs run and which one waits for which.
Graph engineering is the skill of drawing that plan well, so the work that doesn't depend on anything runs all at once, instead of one slow step at a time.
Get it right and one person can direct a whole fleet of agents. That is why the best engineers jumped on it the moment loops got old.
-------
Shape 1 - The Chain
This is the one everyone builds by default.
Do A, then B, then C, each step waiting politely for the last to finish. It works, and it is the slowest shape there is.
If one step stalls, everything behind it stops. Use it only when the steps genuinely need each other's output.
-------
Shape 2 - The Diamond
This is the workhorse of every serious graph.
You split the job, fan the workers out in parallel, verify what they found, then merge it all into one answer.
Use it the moment the work breaks into pieces that don't read each other. Same shape behind a research report, a market scan, or a code review.
-------
Shape 3 - The Router
Sometimes the next step depends on what you just found.
One node checks a result and picks the path. a small job gets a quick pass, a big one triggers a full audit.
Use it when the work needs to branch. The decision runs the same way every time, because it lives in the structure, not in a guess.
-------
Shape 4 - The Cycle
Some jobs you can't size up front.
A bug sweep where finding one problem reveals three more. So you add a controlled edge back: keep finding, checking, looping until two rounds turn up nothing new, then stop.
Use it for discovery of unknown size. The one rule is a hard limit, or it runs until your budget is gone.
-------
That's the base, now you know the four shapes and when each one fits.
If you want to go deeper, I wrote a full article just for that, it explains everything step by step and breaks down where graph engineering wins and where it breaks.
It also walks you through building your own graph from scratch, read it below.
So many brilliant people miss out simply from lacking access to key trends or hidden know-how.
AI acts as the ultimate equalizer. When you combine your talent + curiosity with it, new horizons open instantly.
The gatekeepers are gone. I’ve never felt more unchained.
How to graph-max with Codex and 5.6 Sol:
1. Draw a graph (literally in any tool, even on paper)
2. Send it to Codex and say "write a code mode script that implements this workflow, run it with <your inputs>"
There's no step 3, it just works.
Seriously it's that simple.
The knowledge that makes AI useful is diffused. It lives with scientists, engineers, clinicians, firms. For AI to benefit from distributed knowledge, it must itself be distributed. Agree with Jensen that this is a future worth building.
We removed ~80% of the Claude Code system prompt for our newest models, this is what we've learned about writing system prompts, skills and Claude.MDs for them. https://t.co/6DZwSrZjE9
Anthropic engineers on building evaluation harnesses, testing agentic loops, and verifying system end-states:
• 02:18 - Moving from text output to agent outcome evaluation
• 05:43 - Architecture and mechanics of an Eval Harness
• 10:48 - Converting production failures into test tasks
• 14:52 - Code-based checks vs LLM-as-a-judge calibration
• 17:09 - Structuring Regression & Capability test suites
• 24:32 - Q&A with Anthropic Applied AI engineers
in this 45-minute deep dive, Anthropic Applied AI engineers alongside Notion's PM break down how to systematically test autonomous systems from scratch.
Agent Harness + Regression Suites + End State Verification = Reliable Agents
Watch the full session today, then build your own evaluation suite.
The story of AI in the next few years is going to be compute: an essay on the future of AI.
K3 in 2 days is already #10 on OpenRouter with ~140B tok/day, and it’s infra is crumbling. Throughput is down from 30tok/s to 13tok/s, E2E latency is up to 72s and time to first token is >20s! It would cost a minimum of $500k to buy the 8 B300s it would take to serve even quantized Kimi K3 and ~$4M for the more recommended GB300 NVL72 rack.
I don’t think Moonshot has the compute available to scale to their demand! In fact, even the US based inference providers will likely not be able to scale capacity as much as they’d like even if they were to host it: a 2.8T model is no joke. GPU providers (neoclouds etc) are doing 3yr and I recently hear 5yr commits with an ungodly 30% down, and customers are chomping it up. Prices continue to go to the moon. The two big labs, hyperscaler clouds, Grok and Meta have compute deals locked in prior, and the rest are fighting for scraps. Tier 1 neoclouds (coreweave/nebius etc) are rumored to not even small “smaller” customers. Meta is the biggest wildcard here. With ~7GW of compute by eoy 2026 and no clear big model ties, they either get to frontier on their own or can host the most Kimi K3 capacity (unless they sell it to the labs).
Even though the price of models has fallen over time, it’s worth noting that the price of frontier has not. 3yrs ago, GPT-4 released at $60/M, o1 at $60/M, Opus 4 at $75/M, GPT5 at $10/M, Fable at $50/M and now Sol at $30/M and K3 at $15/M. Even if you consider K3 frontier, that’s only a 4-5x flux in 3yrs. In that time, frontier demand has increased at least 3+ ooms and frontier intelligence performance has gone 32x at least by task time by METR.
Essentially, so long as a) the demand for frontier intelligence continues to grow to near infinity, b) the frontier continues to grow in performance, even as c) if the price of frontier declines a little, the value accrued to frontier grows significantly! And there’s a tremendous bull case for those who have locked up compute if you’re bitter lesson pilled and believe larger models will always be smarter models.
Open Source AI updates :
> GLM-5.2 ✅ Almost Opus-level
> Kimi-K3 ✅ Almost Fable-level
> Qwen-3.8 🔜 2.4T, Expected to beat Opus
> Deepseek V4 GA 🔜 $0.0028/M Expected to beat Opus
> Minimax-M3-Pro 🔜 3T, Expected to be Fable-level
> GLM-5.5 🔜 Expected to beat Opus
Holy
https://t.co/6ay3t9fLhu
Our Kimi K3 blog is finally out. Enjoy!—and rest assured, the K3 model weights will be open in the coming day. We’re just taking a little extra time to ensure a smooth rollout with our inference partners.
Frontier intelligence belongs to everyone, without fallbacks of course. 😎
el fundador de una empresa china de IA valorada en más de $20,000,000,000 acaba de dar una clase de 40 minutos sobre enjambres de agentes
la explicación más clara que he visto sobre sistemas de IA a gran escala
cámbiala por tus 2 horas de Netflix de esta noche
My bet: @thinkymachines will soon make more money than @AnthropicAI. Not by winning the race to build one standardized frontier model. By becoming the Palantir FDE for enterprise custom models.
The playbook:
1. Release the best American open-weight model.
2. Drive widespread enterprise adoption.
3. Charge the largest companies 7–9 figures to post-train and run custom models behind their own firewall.
The model rests on three bets:
1. Large enterprises will increasingly demand their own models with their own data, and this is how they differentiate and win.
2. Enterprises won’t need just one model. They’ll continuously need new models for different workflows, departments, and proprietary datasets. That creates extremely sticky, recurring revenue.
3. Autoresearch will make custom model development increasingly scalable. Tinker can become the interface enterprises use to post-train their own models—with @thinkymachines providing the expertise and infrastructure behind it. FDE, infra, everything, huge contracts.
4. Eventually, maybe everyone wants their OWN model, and autoresearch and training inside tinker on top of @thinkymachines's base model will make it happen.
Meanwhile, Henry-ford-styled, standardized models will makes no margins. OpenAI and Anthropic will have their API margins squeezed by Deepseek/GLM/Grok/Meta etc, and their consumer subscriptions are loss centers.
The fat margin will move to customization: proprietary data, post-training, evals, deployment, and infrastructure.
If this thesis is right, @thinkymachines isn’t building just another frontier lab. It’s building the highest-value layer between frontier research and enterprise model ownership.
Turns out, the best business model for enterprise is NOT to sell commodity API access. Sell them their own models.
I’m extremely bullish on this approach.
@miramurati may be the most commercially savvy frontier-lab leader. I have to admit it.
Google engineer explained how to fine-tune a tiny LLM from 46% to 90% accuracy on your phone in 21 minutes - better than $1500 on-device AI bootcamps.
pick Gemma 270M -> generate synthetic task data -> fine-tune with LoRA -> quantize to int4 -> deploy to Pixel and hit 2000 tokens per second.
That loop is how a 270M model beats a 70B one on your task, running fully offline in your pocket.
Gemma 270M + synthetic data + LoRA + int4 quantization + on-device runtime - that's the stack.
Watch and save it, then fine-tune your own tiny agent tonight.
Today, we are introducing Inkling.
Inkling reasons efficiently across text, image, and audio modalities. We are making the full weights available.
https://t.co/Ghebq5mG30
Available today for fine-tuning on Tinker. Play with it in the Inkling Playground. 🧵
🧵 Researchers ran the same 22 enterprise tasks on six different foundation models—
Claude Sonnet 4.6,
Gemini 3.1,
Flash 3.5,
Qwen 3.6,
GLM 5.1, P
almyra X6.
Same prompts. Same judges. Same price table.
Only one thing changed: the orchestration layer around them.
What happened?
1/
The bill for every single model dropped 33% to 61%.
Median latency fell 44%. Tokens per task dropped 38%.
And headline quality? Held at parity.
On this workload, the orchestration layer moved cost more than switching between the cheapest and most expensive model did.
2/
The dominant pattern in agentic AI today is what we call token maxing:
Buying capability by throwing more tokens at it—longer reasoning traces, wider tool catalogs, full history replays every turn.
Falling per-token prices mask the pattern. But total spend rises anyway.
3/
The decisive lever isn't the model. It's the harness—the orchestration layer that:
• Assembles context
• Exposes tools
• Sequences turns
• Delegates work
• Governs failures
The harness controls every input token except the model's own verbosity. Which means it controls the bill.
4/
Here's the cost formula for one agentic task (Eq. 1):
C = Σ (p_in × T_in + p_out × T_out)
The input side breaks down into terms the harness builds:
T_in = System + History + Tool schemas + Retrieval + User turn
Four of five terms? Pure code decisions.
5/
A naive loop replays the full transcript every turn.
Total input tokens grow quadratically: O(k²) in turn count.
A harness that caches the stable prefix, compacts history, and offloads bulky tool outputs converts that to O(k).
Same model. Radically different bill.
6/
Two further facts sharpen this.
Agent workloads are input-dominated.
Measured ratios are ~100:1.
So the p_in term is nearly the whole bill.
Prompt caching prices cache reads at ~0.1× list.
If you can hold 99.9% of your prompt stable, you pay a tenth of list for the dominant cost term.
7/
The researcher's harness does exactly that with cache-shape discipline:
A byte-stable prefix (tool schemas + stable system prompt + append-only transcript) + a volatile tail rebuilt each turn (clock, plan, reminders).
Measured: 99.9% of tokens served as cache reads.
The same mechanism that cuts the bill also cleans the model's working set.
8/
Six mechanism families implement the harness:
1. Cache-shape discipline (two-zone prompt)
2. Structured, incremental, cache-aware compaction
3. Context offload (sub-agent firewalls, filesystem pointers)
4. Zero-token waiting (durable suspends, not polling)
5. Failure-spend governance (typed failures, circuit breakers)
6. Model-agnostic floor (normalized streams, native tool calling)
9/
Quality moved with capability.
Researchers measured quality gain vs. baseline strength across six models.
Correlation: r = 0.99
Stronger models extract more quality from the same harness. Weaker models can be overwhelmed by it.
We call this harness leverage.
10/
The harness also added one net-new capability: sub-agent delegation (spawn a scoped child, cap its summary at 8 KB, merge results).
But it only crossed a usable reliability threshold on the two strongest models (0.85–0.86).
Orchestration features carry capability floors.
11/
Per-model cost reductions:
• Sonnet 4.6: −39%
• Gemini 3.1: −33%
• Flash 3.5: −61%
• Qwen 3.6: −44%
• GLM 5.1: −47%
• Palmyra X6: −52%
Every. Single. One.
That's the signature of a layer-level effect, not a model-specific trick.
12/
Now, fleet economics.
At one million agent tasks per month:
Baseline: $210k/month
Harness: $120k/month
Savings: $90k/month. $1.08M/year.
From orchestration alone. And it stacks across every model, every vendor migration, every unit of volume.
13/
Three properties make harness savings compound:
• Model-portable: implemented above the API, applies to models that don't exist yet.
• Volume-linear: grows with exactly the quantity (agentic task volume) growing fastest.
• Stackable: multiplies with routing, per-token price declines, and prompt-level compression.
14/
The managerial fix is a measurement fix.
Teams that report quality alone will token-max, because tokens are someone else's line item.
The escape: CPM (task-completions per million tokens) and η$ (quality per dollar).
We moved CPM from 54.9 to 92.0—opposite to the industry trajectory—while quality held.
15/
One caveat: the harness regressed quality on one task (multi-step research synthesis, 0.80 → 0.60).
The regression was driven by the smaller models.
The honest reading of n=22: lead with efficiency (uniform, decisive), not quality (directional).
16/
The broader claim: token maxing is a choice made at the orchestration layer, and it can be unmade there.
Mechanism by mechanism:
• Cache the stable
• Compact the old
• Offload the bulky
• Suspend the waiting
• Bound the failing
17/
The contrarian takeaway:
"Model choice is now a rounding error compared with orchestration hygiene."
"The fastest way to raise quality per dollar is to stop showing the model 60% of the tokens it currently sees."
"Sub-agent delegation is not a feature—it is a capability tax that only frontier models can afford to pay."
19/
The strategic conclusion:
An organization that rents its orchestration layer has outsourced the variable it controls most.
The harness is not plumbing. On the evidence here, it's the P&L.
Paper: https://t.co/FZE7Uga7gh
Anthropic just dropped 5 workshops on building self-improving agentic systems from scratch:
00:00 - Ship your first Claude agent
36:44 - Build memory for Claude agents
1:05:06 - Make your agent autonomous
1:26:46 - Set up a proactive agent
2:03:35 - self-improving agents (tools,skills)
These 3-hours of free Claude workshops will replace 10 paid agentic courses.
Watch today, then read article below on how to build a self-improving agentic system with Fable 5.