Go ahead, open it. It’s a lot of red.

What you're looking at is the open-source AI stack — every layer of it, from hardware and chips up through model weights, datasets, developer tools, documentation, licensing, and safeguards, scored against its closed-source equivalent. The breakdown comes from Unpacking Open Source Artificial Intelligence: Towards a Framework for Openness in Foundation Models. I pointed agents at each one, had them read real repos, compare them to closed-source equivalents, and score across 10 criteria. (If you're curious, hit me up, and maybe I'll package up the code.) If you're actually trying to piece together an open-source AI deployment — stitching inference servers to tooling to compliance — you're running into two problems at once: what's blocking you today, and what nobody's building for tomorrow. This is a map of both.

The headline: Average maturity is 3.2 out of 5. Enterprise readiness averages 2.3.

Works in demos. Dies in procurement. Maybe that’s why every engineering team that would prefer to own their inference is defaulting to closed APIs: Not because the models are worse, but because nobody’s staking a production SLA on a GitHub repo with no support contract. The preference exists. The plumbing doesn’t.

Only one subcategory hits a 4 on enterprise readiness: ML frameworks — PyTorch, TensorFlow, JAX — the things that have had a decade of production hardening. Everything else? No uptime guarantees. No VPC isolation. No AD integration. Closed platforms don’t win on the model. They win on the contract.

The developer experience is the other gap. Integrating the OpenAI API involves five-ish lines of code. Deploying the open-source equivalent? Docker, reverse proxies, manual model management. Teams with a six-week ship date, of course, are going to pick the thing that works today. And every team that makes that call — reasonably, defensibly — translates to another year of lock-in that gets harder to unwind later. (And more expensive when the pricing changes, as 135,000 OpenClaw users just learned.)

Licensing scored the lowest in the entire spreadsheet. There are no templates that address model output ownership, training data rights, or prompt injection liability. Every AI startup either adopts a closed platform’s terms wholesale or pays $50K+ for custom legal drafting. That’s not a technical gap. It’s an institutional vacuum.

Of course, this spreadsheet is almost certainly wrong in places. If you’re deep in any of these layers and you see something I missed, tell me: @raffihack on X, or comment below.

Leave a comment

The Bright Spots Are Real

Deployment, inference code, base weights, and training code all scored 4 on overall maturity. vLLM, llama.cpp, HuggingFace TGI are production-grade today. Strong tools, no wrapper.

The models aren’t the problem.

Open-weight models now trail the closed frontier by roughly three months. That’s Epoch AI’s Capabilities Index talking — a composite score across 37 benchmarks, updated continuously, built in collaboration with Google DeepMind. On MMLU specifically, the gap collapsed from 17.5 percentage points to under 1 in about a year. DeepSeek-R1 matched o1-class reasoning at a reported training cost of $6M. Qwen3.5 scores 88.4 on GPQA Diamond, ahead of everything except the most expensive closed options. On a single gaming GPU, you can run open-weight models matching frontier performance from nine months ago.

Three months behind on capabilities. And closing.

Even Mythos — the model Anthropic said was too dangerous to ship — isn’t an argument against open-source models being smart enough. AISLE researchers replicated several of its headline vulnerability findings with openly available models. Alex Stamos — Stanford’s former internet security chief, ex-CISO at Facebook and Yahoo — estimates six months before open-weight models close the rest of that gap.

But three months isn’t a law of physics. It’s a snapshot. makes a fair counterpoint: as frontier labs push into domains that aren’t on the public web — proprietary environments, long-horizon agentic work, specialized RL pipelines — the gap could widen again.

Which means two things need to be true at once. We need people working on models — the work DeepSeek, Qwen, and Meta are doing matters in a world where every month of lag is a month where someone signs a closed contract instead. But we also need people investing in the rest of the stack, because even when the models are competitive, teams are still defaulting to closed platforms. Not because the model is worse. Because the model is the only part that’s ready.

Deloitte’s 2025 survey found that nearly 60% named legacy integration and risk/compliance — not model quality — as their top barriers to deploying agentic AI. The 2026 follow-up (3,235 leaders, 24 countries) put insufficient worker skills at the top of the list, with legacy data and infrastructure right behind. Nobody in procurement is blocking on benchmarks.

The capability gap is a “months” problem. The packaging gap is a “years” problem. And right now, almost all the energy is going to the part that’s already closest to parity.

Enterprises are signing multi-year contracts, building integrations, and training teams on specific APIs. Every quarter that open source doesn’t have a credible enterprise story, those defaults harden. Procurement doesn’t re-evaluate because a benchmark improved. It re-evaluates when something is obviously easier, obviously cheaper, and obviously supported.

We’ve seen this movie before. In 2002, Linux had the kernel but not the enterprise story: no certifications, no vendor support, no one willing to put it in the data center with a pager attached. Red Hat, SUSE, and Canonical didn’t build a better kernel. They built the wrapper. They made it adoptable. That’s what turned an ideology into an industry. Ask Sun how not shipping the wrapper in time worked out.

The open-source AI stack is at that same inflection point. What’s missing is the boring stuff: the SLAs, the compliance tooling, the five-line integration. That’s not a research problem. It’s an engineering and institutional problem. And those are the kinds of problems this community has solved before.

We’re not losing on the model. We’re losing on the paperwork.

Look at the gap map. Find a red zone you know how to fix. Maybe that’s compliance tooling. Maybe it’s a five-line SDK. Maybe it’s the ToS template that doesn’t exist yet. Maybe you’re training the next open-weight model that keeps the three-month number from slipping. All of it counts.

If you’re building in any part of this stack — models, infrastructure, tooling, licensing, documentation — I want to hear from you. Reply here, DM me, yell at @raffihack. I’ll feature what you’re working on.Let’s close this gap.

Share

What I’m Reading This Week

Anthropic built a model that found zero-days in every major OS and browser — a 27-year-old OpenBSD bug that survived five million automated scans — and then didn’t ship it. Instead: Project Glasswing. $100M in credits to a consortium (AWS, Apple, Microsoft, Cisco, Linux Foundation) to harden infrastructure before Mythos-class capabilities proliferate. The technical writeup is worth your time. Notable absence from the consortium: the US government, which banned Claude from federal agencies. I've been thinking a lot about what this means for the people who weren't on the partner list.

Full disclosure: Nous Research is a Mozilla VC company, but I would highlight them anyway. Hermes Agent is their answer to the question nobody at the closed platforms wants you to ask: What if the agent itself were open? Think OpenClaw, but with autonomous skill creation, cross-session memory, six terminal backends (including serverless that hibernates when idle), and an RL pipeline for fine-tuning tool-calling models on your own trajectories. It swaps providers with zero code changes. MIT licensed, runs on a $5 VPS. The agent-as-a-service pricing model looks a lot less inevitable when the alternative is curl | bash

Chardet, the Python character-encoding library with hundreds of millions of annual downloads, got a Claude Code-powered ground-up rewrite and a license change from LGPL to MIT. Mark Pilgrim, the original author who deleted his entire online presence in 2011, came back specifically to file the issue: exposure to the original codebase means no clean-room defense, and an AI rewrite doesn’t change that. The implications go way past one library: if a court ever rules that AI output is a derivative work of its training corpus, a lot of commercial codebases are carrying copyleft obligations nobody’s accounted for.

Alibaba AI is truly unhinged. (Via Ben Dickson at TechTalks.)

Andrej Karpathy’s — former Tesla AI lead, OpenAI founding team — latest obsession: using LLMs to compile personal knowledge bases. Dump source documents into a raw/ directory, have a model incrementally build a wiki of interlinked markdown files with summaries, backlinks, and concept articles. No database, no custom tooling — just .md and .png files with an AGENTS.md schema. I’m going to bumble my way through building one and write up what actually works.

Carnegie Mellon is releasing a paper on the problem everyone building with coding agents is about to hit: What happens when you need multiple agents working on the same codebase simultaneously? Their system (CAID) uses git worktrees for isolation, git merge for integration, and dependency graphs for task ordering — the same primitives human dev teams already rely on. Key finding: giving a single agent more iterations doesn’t help, but splitting work across coordinated agents does (+14% on library-from-scratch tasks, +27% on paper reproduction). I want to try implementing this.

My good friend Ryan Sarver wrote this — over a million views and counting. He built an AI chief of staff on OpenClaw out of markdown files, Python scripts, and a $20/month subscription. No SaaS, no vendor, no contract. Flat files he owns, backed up to git. It tracks his fundraise pipeline, preps him before every meeting, extracts action items after, and improves itself every week. The title says “better than any human I’ve hired.” Ryan hired me. I’m choosing not to take that personally. But this is the quote that matters: “Open source is an unmatched engine for turning community ideas and energy into progress. A week from idea to full native integration. Closed source is fast, but open source is something else entirely.” I’m building my own version and will write it up for you soon.

Button is a $180 AI pin from ex-Apple Vision Pro engineers that BLE-tethers to your iPhone and proxies every utterance to an unspecified cloud LLM. It might run something on-device. Nobody knows, including, apparently, the press. Eight bucks a month for unspecified Pro features. No Android. I keep waiting for AI hardware to be more than Siri in a lanyard, and it keeps shipping as a $180 curl to someone else’s API. My friend Ayah Bdeir nailed the structural reason in MIT Tech Review: when the hardware layer is closed, every device converges on the same interaction model — press, talk, wait for cloud. You can’t iterate on form factor if you can’t touch the board. She’s now CEO of Current AI, which just demoed an open-source handheld at the India AI Summit — local inference, no cloud round-trip, 22 languages via Bhashini, full schematics going to GitHub. We talk about open source like it’s a software problem. The hardware layer is just as locked, and it’s why every AI device on the market feels exactly the same.

Anthropic told every tool built on top of Claude: Use our API and pay per token or lose access. Starting April 4, subscribers can no longer route their subscription through third-party agent harnesses like OpenClaw. The stated reason is capacity: A single OpenClaw user consumes 6-8x the resources of a human subscriber, and subscriptions weren’t built for agentic workloads. The unstated context? OpenClaw’s creator had just joined OpenAI, and Anthropic had just shipped competing features into Claude Code. If you needed a concrete example of what platform dependency risk looks like in the AI stack, this is it. 135,000 active instances woke up one Saturday to find their cost structure had changed overnight. Some users are reporting 50x increases. Others are switching to local models.

Google Research open-sourced TimesFM, a foundation model for time-series forecasting — not “what word comes next?” but “what number comes next?,” applied to server load, revenue, error rates, stock prices, energy consumption. 200M parameters, 16k context length, PyTorch or JAX, Apache 2.0. Most teams doing this work are still hand-rolling statistical models or paying for a proprietary API.

Finally, file under DO NOT GET ME STARTED…: The White House proposed slashing NSF’s budget by 55% to $4 billion while claiming it will “maintain funding” for AI and quantum research. Read the fine print: basic AI research at NSF would be cut 32%, basic quantum 37%. The “maintained” funding goes to applied research at Defense and Energy. So the plan is to defund the pipeline that produces the science and then act surprised when there’s nothing left to apply. If you’re wondering why ownership of the AI stack matters, this is the policy environment you’re building in: The public funding for foundational research is being gutted while the administration tells you everything is fine because DARPA got a raise.

Subscribe now

You know that moment on a plane where you open your laptop, pull up your coding agent, and remember that it lives on someone else’s server? United’s wifi is doing its thing — which is to say, nothing — and you’re sitting there with an M4 Max that could run a 35-billion-parameter model but can’t complete a function call. This note is about fixing that, and a few hundred other decisions like it.

There are guides for running open-weight models locally. What’s missing is which model, which agent, and why. So, that’s what this is. By the end of this, you’ll have a working Claude Code equivalent running (kinda) entirely on your own hardware.

What You're Building

Three pieces: a local inference server (llama.cpp) that speaks OpenAI-compatible HTTP, a model you’ve chosen consciously with a license you’ve actually read, and an agent that routes tasks to it.

The agent I’m replacing Claude Code with is OpenCode — same terminal TUI feel, same agentic loop, reads your repo, proposes changes, executes tools, commits. If you’d rather stay in your editor, VS Code + Continue gets you something close to Cursor pointed at your local server. This guide focuses on OpenCode. The rest of the setup is identical either way.

Cursor bills me every time I look at it. This runs on hardware already sitting on my lap, and the marginal cost of the next token is zero.

Step 1: Install the Runtime

brew install llama.cpp fzf hf

llama.cpp is the inference server. Metal GPU support is on by default for Apple Silicon. fzf is needed by OpenCode for fuzzy search. hf is the official Hugging Face CLI — the right way to download models.

Confirm it worked:

llama-server --version

Step 2: Pick and Download Your Model

The benchmark tables are mostly useless for this decision. Three questions matter: Does it fit in your RAM, does it call tools reliably, and can you actually build on the license?

Start with how much RAM you have:

system_profiler SPHardwareDataType | grep -E “Chip|Memory”

16GB
→ Model: Qwen2.5-Coder-7B-Instruct
→ License: Apache 2.0
→ Size: ~5GB
→ Fast, reliable, great starting point

32–48GB
→ Model: gpt-oss-20b
→ License: MIT
→ Size: ~12GB
→ Best for tool use + agent workflows

64GB+
→ Model: Qwen3.5-35B-A3B
→ License: Apache 2.0
→ Size: ~22GB
→ More powerful, MoE architecture

Download commands:

# 16GB
hf download Qwen/Qwen2.5-Coder-7B-Instruct-GGUF \
  qwen2.5-coder-7b-instruct-q4_k_m.gguf \
  --local-dir ~/models

# 32-48GB
hf download ggml-org/gpt-oss-20b-GGUF \
  gpt-oss-20b-mxfp4.gguf \
  --local-dir ~/models

# 64GB+
hf download unsloth/Qwen3.5-35B-A3B-GGUF \
  Qwen3.5-35B-A3B-Q4_K_M.gguf \
  --local-dir ~/models

These downloads are large (5–22GB). Start one; go get coffee.

The 16GB and 64GB+ models are Q4_K_M - 4-bit quantization, the standard quality/size tradeoff. You lose a small amount of quality, gain a large reduction in size and memory. For most coding tasks, you won’t notice. The 32-48GB model is different: mxfp4 is how gpt-oss was actually trained, so there’s nothing to lose.

All three models in this issue are Apache 2.0 or MIT — you can build on them commercially without restrictions. (That’s not true of every popular model.) Before you add anything else to your stack, read the license file in the repo, not the marketing copy on the model card.

Case in point: yesterday, Alibaba released Qwen3.5-Omni — their new multimodal model — as API-only. No weights, no license file, no download link. The previous version was fully open. The researcher most associated with Alibaba’s open-source work left the company earlier this month. None of this changes what’s in your ~/models directory right now — those weights aren’t going anywhere. But it’s the kind of signal that makes me want to be better at evaluating alternatives, not worse. Next issue: how to actually do that with Kimi and DeepSeek.

Step 3: Start the Server

llama-server \
  -m ~/models/Qwen3.5-35B-A3B-Q4_K_M.gguf \
  --jinja \
  --host 127.0.0.1 \
  --port 8080 \
  --ctx-size 32768 \
  -ngl 99

Two flags worth explaining:

• --jinja enables tool-calling. Skip it and your agent will appear to work but silently refuse to call tools. This flag is responsible for most of the “it won’t use tools” failures I’ve seen.

• -ngl 99 offloads all model layers to Metal GPU. Skip it on Apple Silicon and you’re running on CPU — ten times slower than it should be.

Wait for this line before doing anything else:

main: server is listening on http://127.0.0.1:8080

Sanity check:

curl http://127.0.0.1:8080/v1/chat/completions \
  -H “Content-Type: application/json” \
  -d ‘{
    “model”: “local”,
    “messages”: [{”role”: “user”, “content”: “say hi in 5 words”}],
    “max_tokens”: 20
  }’

If you get a response, your stack is working. The first time I ran this I immediately opened Activity Monitor to watch the GPU. Everything after this is just routing clients at it.

Step 4: The Agent - OpenCode

My friends at anoma.ly built OpenCode as the open-source Claude Code equivalent. Same terminal TUI feel, same agentic loop. The difference: You’re not locked to Anthropic’s models, pricing, or terms.

(Timing note: As I was literally about to hit send, Anthropic accidentally shipped Claude Code’s entire source — 512,000 lines of TypeScript — in a .map file on npm. Nobody hacked anything. The front door was open. Within hours, a developer named Sigrid Jin used a different coding agent — OpenAI’s Codex — to rewrite the whole harness in Python before sunrise. The repo hit 48,000 stars in a day. A coding agent cloned a coding agent in one session. It’s days old, legally radioactive, and the author ships a parity_audit.py that’s refreshingly honest about what’s missing. I am not recommending you use it. I am noting that the universe has a sense of humor about the rent-vs.-own conversation.)

I did brew install opencode first. It installed, but it didn’t work. Thirty minutes later, I found the tap.

brew install anomalyco/tap/opencode

Pre-install the provider package. OpenCode downloads this at startup, but it hangs silently if npm is slow. Do it manually once and you’ll never hit this:

mkdir -p ~/.cache/opencode
cd ~/.cache/opencode
npm install @ai-sdk/openai-compatible

Now, create two config files, nothing else. In ~/.config/opencode/opencode.json

{
  "$schema": "https://opencode.ai/config.json",
  "model": "llamacpp/qwen3.5-35b",
  "provider": {
    "llamacpp": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "llama.cpp (local)",
      "options": {
        "baseURL": "http://127.0.0.1:8080/v1"
      },
      "models": {
        "qwen3.5-35b": {
          "name": "Qwen3.5-35B-A3B",
          "tools": true,
          "limit": {
            "context": 32768,
            "output": 8192
          }
        }
      }
    }
  }
}

and in ~/.local/share/opencode/auth.json

{
  "llamacpp": {
    "apiKey": "sk-local"
  }
}

Launch (server must be running first in a separate terminal):

mkdir ~/test-project && cd ~/test-project
opencode

OpenCode will ask if you want to configure providers. Anthropic, OpenAI, a dozen others. You can skip every single one. You don’t have a remote platform. You don’t need a key. That moment — closing out of a credentials prompt with nothing in it — is the whole point of this newsletter in one keystroke.

Want proof that it works? Type this in the input box:`

write a python script that prints ‘hello world’

It does. Obviously. That’s not proof of anything except that your wiring is correct. Let’s make it actually work for its dinner.

create a tetris clone in typescript that can be served statically out of a dist/ directory

OpenCode maps out a plan, scaffolds the project, writes the code. I open the browser and…

Uncaught SyntaxError: unexpected token: ‘as’ app.js:2:20

One error. I pulled it from the browser console, pasted it back into OpenCode, and it fixed it. Served it again. Played Tetris — on a model running on my laptop, with no API call, no subscription, no telemetry.

I should be honest about what that means. If I’d done this in Claude Code with Opus 4.6, it probably gets it right on the first try. I know it would in Cursor — I’ve run this exact test enough times to be bored by it. A local 35B model making one fixable mistake on a from-scratch Tetris clone is genuinely good. It is not frontier-model good. That’s the tradeoff you’re signing up for, and you should know it going in.

That’s the whole stack: local model, Metal GPU inference, OpenAI-compatible API, open-source agent, tool-calling. Nothing left my machine.

What You’re Actually Getting Into

The tooling is fast-moving and occasionally broken. OpenCode ships near-daily updates. The standard Homebrew formula lags. The startup hang — silently trying to download a provider package with no progress indicator — is a known issue with a simple manual workaround, which is why the setup above pre-installs it. This will improve. Worth knowing what you’re getting into.

Tool calling is fragile. The model has to be trained for it and templated correctly. --jinja is the most common fix. Second most common: The model you chose wasn’t trained for tool use. Qwen3.5 and gpt-oss-20b are; not all models are.

Context size costs RAM. The KV cache is the model’s working memory for a conversation — it stores computed state for every token in context, across every layer of the model. It grows linearly with context length, and at long contexts can rival the model weights themselves in memory. Start at 32k. Increase only if you need it and have confirmed headroom.

It’s faster than you might expect. Running Qwen3.5-35B on an M4 Max: it’s semi speedy! Comfortable reading speed is around 15-20. You are not waiting on this model. Where you will feel it is autocomplete — round-trip latency for inline suggestions is longer than a hosted API, and for that use case it’s a real regression. For agent tasks where you kick something off and come back, it’s a non-issue.

It works on a plane. No wifi, no API, no problem. I’ve done more useful work in airplane mode with a local model than I ever did frantically tethering before descent. Slower latency is a real tradeoff. Offline is a real feature. Decide which one you’re optimizing for on any given day.

The Decision Framework: What Stays Local, What Goes Cloud

Local wins on:

• Proprietary code you shouldn’t be sending to an external API

• Repetitive, high-volume tasks where cost is the actual constraint

• Anything where predictable latency matters more than raw speed

• Anywhere without reliable internet: planes, trains, a cabin, an SCIF

Cloud still wins on:

• Tasks that genuinely require frontier capability: complex, multi-step reasoning, novel architecture work

• Very long context where you don’t have the RAM to compete locally

• One-off tasks where setup time exceeds cost savings

The useful test: could a competent senior engineer do this task well? If yes, a good local model probably can, too. If the task requires something closer to “principal engineer with five years of context on your entire codebase,” you might still want the cloud.

The goal isn’t running everything locally. The goal is making the decision on purpose.

Now tell me about yours. What model are you running? What’s your setup? I’m particularly curious about the Kimi and DeepSeek models — next issue, let’s talk about how to actually evaluate and choose between them.

Leave a comment

What I’m Reading This Week

The new SVG engine Heerich isn’t open source AI, but it is open source. And gorgeous.

Everyone’s arguing about which LLM to run locally. Meanwhile, LeCun’s lab shipped a world model — a system that doesn’t predict the next token, it predicts what happens next in a latent representation of the physical world. That distinction matters: token prediction gives you autocomplete; state prediction gives you planning, reasoning, and systems that can actually act on things. LeWorldModel does it in 15M params, one GPU, two loss terms, no pretrained encoder, 48x faster planning than foundation-model approaches. The JEPA bet is that you don’t need to reconstruct every pixel to understand cause and effect — just the compressed state that matters. Code’s on GitHub.

I think the surveillance world we’re creating is generally creepy. (Part of the wonder of human memory is the ability to forget, to get fuzzy.) But I love this trend of people vibe-coding tools they want for themselves, like this app that makes your intent and decisions searchable by your AI. Of course, this is also the end of every SaaS company on the planet…

After virtual-world interaction, the next thing we all have to think about is robots and physical-world interaction. Maybe I should give these plans to my son to print for his robot hand…

I haven’t had a chance to play with this yet, but I’m definitely intrigued. The bare-metal inference engine runs a ~400B parameter MoE model on a laptop (10x larger than the ones I’m talking about above.) If it works, frontier models don’t have to live in the cloud, trading latency for independence.

Digging into this paper on optimizing the harness w.r.t. end performance.

Here’s the scientifically backed version of a piece I wrote about sycophancy. Stanford researchers found that AI reinforces users’ harmful prompts 47% more than humans. Turns out humans are more than okay with that.

Subscribe now

The Owners Not Renters Blueprint

Closed AI is winning because it’s easier to use, not because it’s better. That’s not a permanent condition. It’s a design problem. And design problems can be solved.

Most AI coverage doesn’t treat it as a problem at all. It’s more focused on benchmarks and funding rounds and whatever shipped this week. This newsletter is for the people downstream of those announcements: the engineers and engineering leaders who have to decide, in a sprint, whether to build on something they don’t control.

I believe that you’re not choosing between open and closed AI. You’re choosing between owning and renting. Think about it: The landlord sets the price, the context window, the terms of service, and the deprecation schedule. Most of the time you learn about changes in a routine email…until the one that isn’t routine — the one where the model you built on will be gone in 90 days, or the price just doubled. The people sending that email aren’t malicious. They’re optimizing for their business. Which is exactly why you need to be building differently.

We’ve been here before. By 2003, Internet Explorer had 95% of the browser market. Firefox launched in 2004. IE never recovered, fading slowly at first, then completely. Open standards and open source decentralized control over the core technologies of the web.

Once again, the ground is shifting. Small models run on hardware that organizations already own. Enterprises are migrating off closed platforms in numbers that don’t make press releases. Governments are building sovereign AI supply chains. The question isn’t whether this transition will happen. The question is whether we build the developer experience to make open easier than closed before someone else locks the next layer down — before the defaults harden and a new landlord inherits the keys.

That’s the north star: that openness wins on ease, not principle. Before the window closes.

Open isn’t always the right call. In this newsletter, I’ll tell you when it isn’t. What I won’t do is pretend the default is neutral. Every team that ships on a closed platform without examining the decision is making a choice…by not making it.

My job at Mozilla puts me close to where that’s actually being built: developer tools, data infrastructure, investments across the ecosystem. I’ve spent a career inside platforms. I know what it looks like when a technology transition is inevitable and the only question is who shapes it.

This newsletter is for the people shaping — and shipping — it. Twice a month, I’ll explore orchestration, inference, cost, security, governance — the real stuff, from original analysis to deployment patterns. I’ll evaluate model releases based on what matters in production, not what looks good in a press release. I’ll share migration stories from builders doing the work (and making real tradeoffs). And I’ll report with transparency from the seminars, symposiums, and events that I attend.

That’s the “Think” part of the newsletter. In the “Do” section, I’ll share an open source project that I’ve been playing with.

So, ready to run Claude Code equivalent on your own hardware? Catch the next issue. And in the meantime, let me know what you’ve been working on!

Subscribe now

Before you go… here’s what I’m reading this week

A compromised litellm release hit PyPI this week - credential theft, Kubernetes lateral movement, persistent backdoors. Your LLM proxy library just turned hostile. Time to route through Any-LLM instead of installing your attack surface.

Finally, skill-based adaptation converges: Working independently, three papers (MetaClaw, Memento-Skills, OpenSeeker) show that externalized skill/knowledge structures do better than static fine-tuning.

Which Chinese lab’s open-source drop panicked the market this week? As this reaction says: “The AI race isn’t US vs China anymore... It’s closed vs open. And closed is losing.”

Meanwhile, Nvidia is stepping into the open-source game, putting $26b behind its effort to make OpenAI and the gang very nervous. This week, it introduced NemoClaw and OpenShell runtime, with (much) more to come.

Ready for a personal AI agent that runs on your personal device? Meet Stanford’s OpenJarvis.

Leave a comment