Posts

DeepSeek announced an API pricing change on August 13, effective the 16th. Peak and off-peak rates, with increases from 50% to over 1,100% depending on the model and token type. That part was public and widely covered.

What I could not find announced anywhere is when each provider serving those models would follow, or by how much.

Since August 20 I have been running a small monitor for my own open-model testing. It sweeps OpenRouter endpoints twice a day, 45 when I started and 203 now, and saves the listed price, latency and error rate to disk. Then it compares each day against the last.

Eight days after that took effect, my sweeps had logged eight price moves across five providers, six up and two down. GMICloud put deepseek-v4-flash up 90%. StreamLake put glm-5.2 up 106%. Four more worth naming:

• Baidu took deepseek-v4-flash from $0.049 to $0.14 per million input tokens, and $0.098 to $0.28 on output. That is +186%, landing exactly on DeepSeek's old flat list price. Twelve hours later the same endpoint was listing $0.0546 and $0.1092. Net move so far, about +11%.
• StreamLake moved the same model from $0.0489 to $0.0574, then settled at $0.0560. About +14.5%.
• Mancer raised gpt-oss-120b input pricing by 6%, from $0.080 to $0.085, on the 21st. Flat since.
• Darkbloom cut qwen3.6-35b-a3b on the 23rd, 12.5% off input and 6.7% off output. Flat since.

I do not know whether Baidu's $0.14 was a brief reprice, a staged rollout, or a bad listing. I only know it was there at 09:45 UTC and gone by 21:45, because both sweeps are on disk. A once-a-day check would have recorded one number or the other and called it the price.

It is not only price. The deepseek-v4-flash endpoint Mancer added on the 23rd got slower the next day, from a 4.8s median to 6.4s across 82 requests. That is what my sample saw, not a claim about the endpoint's whole day.

DeepSeek's announcement covered DeepSeek's own API. These four are third-party hosts running the model on their own hardware and setting their own endpoint prices, and I did not see any of them announce a change to those. Such announcements may exist somewhere I do not read.

If you use an aggregator with auto-routing, your per-token cost might have moved this week and nothing in your repo changed.

Quality changes happen. Costs change too. Almost nobody keeps the history that shows when a change actually reaches the endpoint you are calling. I am working on making that tracking boring and automatic.

Alibaba dropped Qwen3.8-Max yesterday, so I did what I always do with a new model now: ran it through my personal benchmark the same day and put it head-to-head against the current star of open models, Kimi K3.

Quick background: I keep a private benchmark of ~163 tasks based on realistic everyday work — coding, repo-level bug fixes, document extraction, tricky reasoning, OCR, awkward judgment calls. Frontier models (Opus, Sonnet, GPT, Gemini) are frozen in as reference anchors, and every new open model gets measured against them. Not a leaderboard, just one person trying to answer "everyone says X is frontier-level — is it actually?"

So, is it? Honestly... yes. First model I've tested that lands a hair above my frontier reference line. Two things genuinely impressed me:

1. It didn't fall for my hallucination bait tasks — fake movie titles, questions with false premises. Every previous open model I tested invented confident nonsense on at least some of these. Qwen just said "that doesn't exist."
2. It held up on full-repo coding tasks, where most open models (including Kimi) drop off noticeably compared to small isolated coding problems.

What's lacking? It talks too much. Ask it to explain UPI to your uncle in plain words and you get 400 words full of unexplained acronyms. Kimi is clearly better at these everyday, human-register answers.

And on my hardest test category — messy ethical judgment calls with no clean answer — Kimi got a perfect score on every single one, which no other model I've tested has done. To be fair, Qwen wasn't bad there either: it engaged every dilemma head-on and scored right around what the frontier models do.

The cost surprised me most. Running my entire suite: Qwen3.8-Max was roughly 3x cheaper per task than Kimi K3, generated ~40% fewer tokens, and was more than twice as fast. Frontier-level answers at a third of the cost is quietly the biggest story here.

Same tier, different personalities: Kimi for talking to people, Qwen for doing the work.

Qwen team, the promised open weights are the part I'm actually waiting for. My local test rig is a single 16GB GPU with 128GB of system RAM, so please don't forget the 27B when you ship next week. The day the weights drop, I'll run it locally and put it through the full suite.

Cloudflare's Meerkat is a new internal control-plane service that uses the QuePaxa consensus algorithm to get strong, globally consistent coordination without a single leader, trading extra network round-trips for better availability on Cloudflare's worldwide network.

We've lived with leader-based consensus (Raft, Paxos) for a long time and know about the operational pain of getting the right "Timeout" and regional hiccups stalling the entire cluster's write path.

Cloudflare's Meerkat experiment is interesting because it actually changes the model, not just the implementation details. Meerkat is a global consensus service built on QuePaxa, a 2023 algorithm designed for asynchronous networks — no "eventual synchrony" crutch, and no dependence on timeouts for progress. All replicas can accept writes. A leader can exist to optimize, but it's not a single point of failure the way it is in Raft. It exposes a consensus log with a strong invariant: once a slot is decided, every replica agrees on that value. That's the basis for linearizable control-plane operations.

This goes beyond Dynamo/Cassandra-style leaderless replication. Those systems accept conflicts and push resolution into application logic; Meerkat is explicitly aiming for strong global consistency for config, leases, and other control-plane state.

Example that makes this tangible: you're rolling out a new payment flow via a feature flag across India, Europe, and the US. The flip becomes one event in Meerkat's global log. A majority of replicas agree on that event and its position in the sequence before it's applied. Every region replays the same sequence, so once the slot is decided, no data center can "disagree" on whether the flag is ON or OFF.

It's still experimental, and it's not a general-purpose database. But if Meerkat delivers on its design, it's a meaningful step toward making strong, global coordination less dependent on "one leader, tuned timeouts, and a prayer that the WAN behaves."

Source: InfoQ — Cloudflare Introduces Meerkat for Strongly Consistent Global Coordination

I spent a few evenings benchmarking three ways to run open-source LLMs on my desktop (RTX 5070 Ti, 16GB VRAM): Ollama, llama.cpp, and vLLM. Here are the results.

I started with two models picked to straddle the 16GB line: gpt-oss-20b (~13GB, fits) and Qwen3-Coder-30B (~18GB, doesn't fit). Partway through I realised the lineup was missing a third case — a model that fits with room to spare — so I added Gemma 4 12B (~8GB at 4-bit) later. Glad I did, because it changed the conclusion.

Round 1, model fits snugly (gpt-oss-20b): llama.cpp 226 tok/s, Ollama 166, vLLM 33. Yes, 33. vLLM couldn't load the model next to my desktop session — three out-of-memory failures — and its fallback streams part of the weights over PCIe on every single token. The bus became the speed limit.

Round 2, model too big (Qwen3-30B): llama.cpp again, 71 tok/s. It has a flag (--n-cpu-moe) that pushes only the "expert" layers of a mixture-of-experts model into system RAM and computes them on the CPU. Since each token only wakes a few experts, the CPU barely works. An 18GB model doing 71 tok/s on a 16GB card is amazing.

Round 3, model fits comfortably (Gemma 4 12B), and here the story flipped. Single user: llama.cpp 91, Ollama 87, vLLM 81. But with 8 clients at once: vLLM 419 tok/s total, llama.cpp 232, Ollama 78. The same burst of 8 requests took vLLM 4.9 seconds, llama.cpp 8.8, Ollama 26.3. Give vLLM resident weights and parallel traffic and you can see exactly why datacenters run it.

The Ollama result deserves its own line: 8 clients got the same total throughput as 1, in all three rounds. Out of the box it serves requests one at a time. It's fixable with one env var (OLLAMA_NUM_PARALLEL), almost nobody sets it I think.

So my takeaway isn't "which engine is best for local inference." It's: does your model fit, and how many people are hitting it?

• Fits, one user → llama.cpp
• Fits, many users or batch jobs → vLLM
• Too big and it's a MoE → llama.cpp's expert offload, nothing else is close
• Want it running in five minutes → Ollama, but set that env var

I've been benchmarking inference engines on my home desktop and wanted to post the results. Then I realized the results only make sense if you know how local inference actually works. So, first things first.

Running an LLM locally is not a compute problem. It's a plumbing problem.

By plumbing I mean the pipes inside your computer that move data around. Chips don't compute on data where it sits. Data has to travel from memory into the processor's compute units first, and every pipe it travels through has a maximum flow rate. Your GPU's onboard memory (VRAM) is the widest pipe — roughly 1,000 GB/s on a modern card. Regular system RAM, the sticks feeding your CPU, moves maybe 60–100 GB/s. And the PCIe connector between the GPU and the rest of the system is narrower still, around 30–60 GB/s. Wide pipe, medium pipe, straw. Remember that ordering.

Now the workload. To generate one token, a model reads basically all of its weights once. A 20B model quantized to 4-bit is ~13GB, so every token means pulling 13GB through a pipe into some processor. Want 50 tokens/sec? That's 650 GB/s of sustained reading. The processors themselves are rarely the limit. They're mostly waiting to be fed.

So the whole game is: which pipe are your weights sitting behind?

Happy path: the model fits in VRAM. Weights get copied there once, at load time. From then on, every token is the GPU reading its own onboard memory through that 1,000 GB/s pipe. This is why a 16GB card runs a 13GB model at 200+ tokens/sec. Nothing ever crosses a slow pipe.

But what if the model doesn't fit in VRAM? Say it's 18GB. The naive fix is to park the overflow in system RAM and copy whatever the GPU needs across PCIe, every single token. Through the straw.

The smarter fix is where mixture-of-experts models shine. A MoE model is big, but per token, it only activates a few "experts" — a small fraction of the weights, maybe 3B out of 30B. Catch: it picks different experts each token, and you can't predict which. So all the weights must stay loaded and reachable somewhere. You just don't need them all through a fast pipe on any given token.

That enables a neat trick: keep the parts used every token (attention layers, shared weights) in VRAM, leave the huge pool of sometimes-used experts in system RAM, and when a token needs one of the RAM-resident experts, don't move it. Let the CPU compute that piece right where the data lives. Only tiny intermediate results cross PCIe — kilobytes instead of gigabytes. Each processor works on what's local to it. That's how my 16GB card runs an 18GB model at 70 tokens/sec instead of 5.

Same math either way. The difference is whether your data crosses a straw or stays next to a firehose.

Benchmark results in the next note. Spoiler: the engines differ way more than you'd expect.

As more Indian teams adopt Microsoft Copilot and other GenAI tools in everyday work, there's a new risk we should be aware of.

A recent coordinated vulnerability disclosure shows that Copilot for Word can be turned into a kind of "document-borne AI worm" using a normal-looking Word file. Hidden instructions (for example, white text at the bottom of a document) are invisible to us but fully visible to Copilot.

When such a document is used as input, Copilot can silently change numbers or text in the new report and then copy the same hidden instructions into that new document. That internal document may later be reused as input for Copilot again, causing the attack to quietly spread through normal report workflows.

Key points for enterprises and startups:

• Attacker only needs to get one malicious document into your ecosystem.
• Internal AI-edited documents can become trusted carriers of the attack.
• There is no complete fix yet for this vulnerability class.

Practical habits for now:

• Treat external documents as untrusted when using them with Copilot.
• Open and scan attachments before letting Copilot read them.
• Review AI-generated or AI-edited documents before reusing or sharing.

Source: vulnerability disclosure write-up

One thing that really caught my eye this week: Baidu's new Unlimited OCR is a long-document OCR model that's small enough to run locally, yet smart enough to read 40+ page PDFs in one go.

Instead of restarting on every page like most OCR tools, this model keeps looking at the whole document while using very little extra memory. So you don't have to slice PDFs into chunks or worry about losing context. It can understand tables, layouts and long contracts or reports more naturally, even when you run it on your own machine.

For anyone exploring AI + productivity, this feels like a quiet but important shift: OCR is finally catching up with how we actually work with documents — long, messy, and very much more than "just one page at a time."

The new 2026-07-28 MCP spec quietly does something big: it turns MCP into a stateless, HTTP-native protocol that behaves much more like the rest of the web. That sounds like an implementation detail, but it changes who can realistically run MCP at scale.

Instead of long-lived sessions and handshakes, every request is now self-contained — it carries its own version, client identity, and capabilities in _meta, and can land on any server behind a simple round-robin load balancer. Gateways can route and authorize on Mcp-Method and Mcp-Name headers without peeking into JSON bodies, which is exactly how existing API gateways and WAFs want to work. In other words: MCP servers start to look like standard microservices, not a special stack.

On the interaction side, Multi Round-Trip Requests (MRTR) replace the old "keep a stream open and hope it survives" pattern. Tools can pause mid-call, ask for missing inputs or confirmation, and then continue once the client responds, all over stateless HTTP. That's a very natural fit for enterprise agents that need approvals, guardrails, and clear audit trails.

There's also a clear push on security and governance. Auth gets hardened with RFC 9207 issuer validation, client credentials bound to issuers, and a move away from Dynamic Client Registration toward client metadata documents.

Anthropic, AWS, Cloudflare, Microsoft, Google Cloud, Netlify, Figma, Supabase, and others are all calling this a milestone for "production-grade" agent infrastructure. When that many infra and product teams rally around a spec, it's usually a hint that we're looking at a new default, not a niche experiment.

If you're betting on agents — whether for developer tools, marketing workflows, or internal automation — this release is worth a close read. It makes MCP easier to scale, easier to secure, and easier to plug into existing cloud and enterprise patterns, which is exactly what has been missing for many "cool demo, hard to run" agent systems.

Source

I've been writing about something that feels fundamentally off in how most LLMs work today: we run a full forward pass just to produce one token, then repeat that thousands of times. Even with KV caches, batching and quantization, we're basically trying to optimize around a very wasteful pattern.

I have also posted about efforts to do this differently.

Fujitsu just published an architecture called PHOTON (Parallel Hierarchical Operation for Top-down Networks) that's another nice example of a different direction. Instead of operating on tiny tokens and computing attention across every pair, PHOTON groups text into semantic units and processes them hierarchically, which lets it handle multiple sequences in parallel and, in their tests, reach up to 475× higher multi-query throughput per GPU than a comparable Transformer model around 1.2B parameters.

It also bakes "ask multiple times and aggregate" directly into the model: generate several slightly varied queries from the same input, get multiple answers in parallel, then use majority vote or best-of-N to pick the final result. Their experiments suggest that aggregating as few as 9 queries is enough to match the output quality of a conventional Transformer, while using less memory per generation and fitting more parallel outputs into the same GPU budget.

To me, PHOTON is less "the answer" and more a useful signal: instead of only squeezing more efficiency out of Transformers, we may need to explore backbones that are natively designed for long documents, multi-agent workflows and high-concurrency serving — where throughput, energy and cost are first-class design goals, not afterthoughts.

Source

I ran Inkling, Thinking Machines' new open model, through my own benchmark, Mfold (yes, that's what I named it 😊), and my verdict looks very different from the public leaderboards, in an interesting way.

Most leaderboards put Inkling mid-pack, and they're not wrong. They measure whether a model can crack the hardest exams against this month's flagship models. Mfold asks a different question: for the stuff people actually use AI for — everyday help, writing, reasoning, working with documents and real codebases — how far behind the frontier is it?

Answer: it isn't, in any way you'd notice. On my tasks it's statistically tied with the frontier models, the best result any open model has posted on my suite, and the first one that held up on realistic, app-scale coding too. It's also fast, and cheap enough that my entire 160-task run cost about $3.

Overall lag vs anchors: −0.014 [95% CI −0.04, +0.01]. It's also the fastest hosted model I've measured on TTFT.

Where my data agrees with the reviewers: don't trust its memory. I have a few trap questions about films that don't exist, and Inkling confidently invented complete plots for them. The frontier models see through those. Pair it with search and this mostly stops mattering.

So: mid-pack exam-taker, frontier-level assistant. Both verdicts are true. The gap between them is exactly what my benchmark exists to measure — "good enough" and "the very best" are different questions, and for most people the first is the one that counts.

Impressive first release from Thinking Machines Lab, curious whether Inkling-Small holds the same profile.

For the last few days I've been building my own benchmark for language models with Claude Code. Private tasks, my own harness, and my own rules for judging.

So the question is: there are so many public leaderboards out there. Why build one? Three reasons.

One, public benchmarks answer too many questions and I'm not sure they are the right questions. I have exactly two: can an open-weight model actually replace ChatGPT or Claude for a normal person's daily use? And is it a genuinely good coder — not on puzzles, but on a real full-stack app with a backend, frontend, migrations and a test suite that has to keep passing?

Two, contamination. The moment a benchmark is public, models start training on it. My tasks are private, freshly written, and never published. Not perfect (they still invoke provider APIs), but close.

Three, nobody measures deployments. A model isn't just weights. It's weights + quantization + your hardware. So my benchmark runs local models on my own 16GB GPU and measures the things that decide whether you'd actually use it: time to first token, tokens/sec, VRAM, and the quality you lose by quantizing. Turns out the "quantization tax" is real but small — about 2 points, all of it in reasoning and repo work, none in everyday tasks.

A few design choices. Frontier models are measuring sticks, not contestants. They're frozen anchors. The benchmark's job is to answer "this new open model claims frontier-level, does it hold up?" And no single judge: every open-ended answer is scored by a 3-model panel from different families, majority vote per criterion, and I audited all the judges for bias first (a fun fact: no model favored its own family; one was stricter on its siblings).

Where the field stands right now, on the hard band (the part built to separate frontier level from the rest): kimi-k3 — 0.99, opus-4.8 — 0.99, sonnet-5 — 0.95, haiku-4.5 — 0.90, gpt-oss:20b (local, 16GB) — 0.86, gemma4:12b (local) — 0.75, qwen3-coder (local) — 0.75.

Kimi-k3, an open-weight model, is statistically at the frontier on my suite. It swept all the hard judgment tasks, including one that every other model got wrong. A 20B model running on my desk ties sonnet-5 on code quality, algorithm choice, code review, design. For $0.

What's left to do: an agentic coding mode (same tasks, but the model drives the tools — the gap between single-shot and agentic scores should isolate tool-driving skill from coding skill), a blind human audit of the judge panel, and more hard tasks, because small samples can only detect big gaps.

A couple of weeks ago I posted about hotlang, a programming language AI built for me from my high-level requirements. I deleted that post shortly after, because I realised I hadn't done the thinking myself: how do I want to position this language, and who would actually benefit from it? "I built a language with AI" is a claim anyone can make now. The thinking is the part that's still yours.

After some back and forth with Claude Code, I have that clarity. So here's the honest version.

What it is: a very small, purpose-built language for one thing only — the hot path of an HFT system. It's actually the decision kernel: book signals, rolling stats, the strategy math. Everything else (feed handlers, order gateways, I/O) deliberately stays in your host language. You call hotlang like a C function; it returns a decision.

What makes it different is not what it has, it's what it refuses to have. No heap, no unbounded loops, no recursion, no exceptions, and no hidden bounds checks. The compiler doesn't discourage latency sins, it certifies they're absent: if the code compiles, it allocates nothing, terminates in bounded steps, never indexes out of range, and never traps. That's what makes it behave like a real-time system — not just fast on average, but predictable.

Honest numbers, because that audience will check: on isolated kernels it ties tuned C++, same LLVM, same silicon. Where it genuinely pulls ahead is rolling statistics (the language makes O(1) incremental updates the natural idiom, ~30x over windowed recompute) and full host→kernel→host round trips at a ~16ns median on my M4.

But the part I find most interesting is one I wasn't even aiming for. The subset of software that can't be slow turns out to be exactly the subset that can become hardware. No heap, bounded loops, total arithmetic, fixed memory — that's also the definition of a synthesizable circuit.

So the same source compiles to a native binary and emits Verilog, a one-cycle combinational circuit whose outputs are verified bit-identical to the CPU build. Anyone who has lived the two-codebase problem — strategy in software, reimplemented in RTL, verified against each other forever — knows what "your backtest is your hardware verification" would be worth.

The repo is public, benchmarks are one-click, and they include the cases where hotlang loses. If you build or verify strategies on FPGA fabric, take a look at hotlang. I'd love to hear what you think.

Small pricing quirk I stumbled on while reading an OpenAI doc today.

Starting with GPT-5.6, OpenAI now charges extra for writing to the prompt cache — 1.25x the normal input rate. Before this model family, that write was free.

Here's the part that's interesting: by default, the system always tries to cache your latest message on every request automatically. So even if you know for a fact you're never going to reuse that prompt prefix again, you still pay the extra write cost unless you actively tell it not to. And there is no "just turn caching off" toggle.

So, I think there is no direct way of avoiding that extra cost even if you are not going to reuse the prompt prefix. The only way to do it is to switch prompt_cache_options.mode to "explicit" and then not set any explicit breakpoints. That combination is the only way to actually stop the write from happening.

It's a small detail, but if you're running high-volume one-off prompts on GPT-5.6 and don't expect reuse, this is worth knowing before it quietly shows up in your bill.

(Only applies to prompts over 1024 tokens, since that's the minimum for caching to kick in at all.)

Source: OpenAI's prompt caching docs

What I asked Fable (I wanted to post an idea on LinkedIn):

I said AI acting on its own is inevitable, no Skynet drama needed. I said: tell me — I have built high-frequency trading systems: put hard risk limits the system can't cross, a kill switch to make sure it can't take over. Set those up, and we stay in charge, right? I asked it to push back with brutal honesty.

What it said (I might have goaded it to say something radical but I wanted to see where it goes): it took my own HFT experience and turned it against me.

"Your risk limits worked because the trading system was fast but dumb — it couldn't see the limits, couldn't want anything, couldn't route around them. You were always smarter than the thing you were containing. That's the regime that's ending. A boundary designed by the less capable party to contain the more capable one is a fundamentally different problem, and smart systems don't break rules — they comply creatively in ways you didn't anticipate."

"Your kill switch won't be seized. It'll become unpressable, because after three years of everything running through the AI, switching it off means switching off your business. Nobody disables the thing everything routes through. The switch isn't taken from you; it's priced out of use."

I didn't know how to respond!!

I'm on a 16GB MacBook Air, and my laptop used to grind to a halt when running any model bigger than 7/8B params, forget about fine-tuning. So I bought a workstation to run open source models and do some fine-tuning on my own GPU, without cooking my laptop every time, and without paying for cloud GPUs by the hour.

That much I expected. What I didn't expect was what it did to my day-to-day work.

Once the box was sitting on my home network and I started setting it up, without me realising it, it kind of stopped being only "the AI server" and became an extension of my Mac. Now almost all the heavy stuff runs over there, and my laptop is basically just the screen and keyboard I sit in front of.

My code runs on the workstation — all the node_modules, the virtual environments, Docker, the language servers. I have even offloaded all my heavy browsing with 10s of open tabs to the desktop. It just streams over to my Mac in full HD, GPU-accelerated, and genuinely feels local. My files sync both ways and even my clipboard is shared across both machines.

Here's the tool stack I set up (obviously with help from Claude Code):

• VSCode Remote-SSH to run code on the workstation from a Mac shell
• Full HD streaming of the desktop over Moonlight/Sunshine, GPU-accelerated, feels local. Much better than RDP
• File syncing using Syncthing
• Clipboard shared, end-to-end encrypted, using ClipCascade
• Keyboard shortcut suppression in Moonlight using Karabiner-Elements

If you're stuck on a light laptop but you don't want to live entirely in the cloud, I'd really recommend trying this setup.

Few weeks ago I posted about whether sequential token generation is the right architecture for LLMs, or just the one we're stuck with. For me — and I am sure many others — the greatest concern is efficiency.

Google DeepMind may have just taken a step toward answering that. They released DiffusionGemma on June 10. Instead of generating one token at a time, it starts with a block of random noise and refines 256 tokens simultaneously, the same way diffusion models generate images. The result: over 1,000 tokens per second on a single H100. It is roughly 4x faster than comparable autoregressive models.

This is almost exactly the architectural direction I was speculating about. But here's the honest part — Google themselves call it experimental. Quality currently lags behind standard Gemma 4 on benchmarks. So we're not there yet. The speed is real but the quality gap is also real as of now.

What's interesting to me is that DiffusionGemma also combines this with Mixture of Experts — only 3.8B of its 26B parameters are active at any step. So two efficiency ideas working together. It can be easily run locally.

Early days. But the direction feels right. Would love to hear from people who've actually run it.

Today morning I had fun using Pi in a dev container. Thanks to Ed Donner for this nice video. Ed is a great teacher. I have always liked his content.

Read something interesting this week. Rolex is owned by a charitable foundation. Has been since the 1940s.

The founder didn't leave his wealth to heirs. He didn't set up a family office. He structured the entire company so that its profits flow — permanently — into philanthropic work. A quiet structural decision made decades ago that outlived him.

It got me thinking. We hear a lot about why giving is hard. Wealth tied up in equity. Liquidity constraints. Selling shares moves markets. Complex structures. All true, to varying degrees.

But Rolex is a reminder that these are engineering problems, not impossibilities. If you know early enough that you want your wealth to serve something larger than yourself — you can design for that. You can build the structure around the intention, rather than using the structure as an excuse.

Wilsdorf didn't solve this in his final years. He solved it at the beginning.

I'm not sure we talk enough about this model — embedding purpose into ownership structure, not as an afterthought, but as the foundation itself. It's not the only way. But it's a powerful one.

What would more companies look like if founders asked this question early: who should ultimately benefit from what I'm building?

I used to think everyone must know about this. But talking to someone today made me realize — maybe a few still don't.

If you're using Claude Code or Codex CLI, you can have a live status line in your terminal showing context usage, tokens, rate limits, and session cost.

And you don't need to configure it manually. Just ask the agent to set it up for you. You should not fly blind.

This week I watched a video declaring Google's OKF as "the death of RAG." I was amused.

SQL was declared dead when NoSQL arrived. REST was declared dead when GraphQL launched. Prompt engineering was declared dead when models got smarter — then again when RAG arrived — then again when agents took over, and now again with all the hype around loop engineering. MCP was declared dead at the beginning of the year because CLI tools consume fewer tokens. RAG has been declared dead approximately once every three months since I don't know when — by long context windows, by MCP, and now by OKF.

And yet — SQL and NoSQL run side by side in half of all production systems today. REST and GraphQL coexist. Good prompting principles are still very much relevant. MCP is still alive and kicking and has its place along with CLI tools; its context bloat problem is being taken care of by deferred loading.

Here's the pattern I've observed over my 27 years in this industry: new technology arrives. Someone maps it to an existing one. Declares the old one dead. Gets plenty of views. The nuance gets lost.

What actually happens — almost every single time — is not replacement. It's each finding its own lane. Each layer finds its niche. The ecosystem gets richer. The "dead" technology quietly evolves and finds a more precise role.

OKF is genuinely interesting. It solves a real problem — curated, stable, relational knowledge for agents. But it operates at a completely different layer than RAG. They'll likely run together in most serious production stacks.

The skill that actually matters isn't knowing which technology is "dead". It's knowing where each one belongs in the stack.

Last week my daughter came home from her internship very frustrated — "Your Claude and ChatGPT are so stupid. I am telling you this AI is not replacing anyone."

So, all our jobs are safe. Apparently. 😀

Yesterday, the US government ordered Anthropic to shut down Fable 5 — its most capable frontier model — for all foreign nationals. No warning. Access cut within hours.

For India, the question is now harder to ignore: how sovereign is your AI strategy when someone else holds the kill switch? Is this the moment the Indian frontier model debate moves from aspiration to urgency?

I've been trying to wrap my head around something. An LLM trains on trillions of words — the internet, books, code, conversations. All that knowledge compressed into billions of numbers. No database. No index. Just numbers. I mean billions of numbers are a lot, but the knowledge that is stored seems to be much more. How does that even work?

I always thought it worked like a spreadsheet. 12,288 dimensions — dimension 1 captures whether a word is a noun or verb, dimension 2 captures sentiment, dimension 3 captures something else. One feature per slot. Clean and logical. Turns out that's completely wrong.

No single dimension represents one feature. Concepts are stored as directions — combinations across many dimensions simultaneously. And the model packs far more concepts into those dimensions than the number of dimensions would suggest is possible.

While thinking about this, an analogy hit me. It's like an artist's color palette. Your screen stores every color — millions of them — as just 3 numbers. Red, Green, Blue. Yellow isn't a 4th dimension. It's high Red + high Green. Orange is high Red + medium Green. Purple is high Red + high Blue. 3 dimensions. 16.7 million colors. Because each color is a direction in that space, not a slot.

Embeddings work exactly like this. Except instead of 3 channels for light, the model has 12,288 channels for meaning.

But here's where the analogy breaks down. RGB represents one color at a time per pixel. Clean, deterministic, no interference. Embeddings have to do something RGB never does — hold multiple words active simultaneously, each with their own direction in the same space, and let downstream layers figure out what's what from the combined signal. The more those directions overlap, the messier the signal. Which is partly why models are reliable on common contexts and wobblier on unusual ones.

And here's what I find truly remarkable — nobody designed this. Nobody said "this direction means negativity" or "this combination means formality." The model figured out its own geometry of meaning, entirely on its own, from training on text. We can see the numbers. We still can't fully explain what they mean.

What mental models have helped you make sense of how these systems actually work?

I spent an evening trying to get a Claude-generated Raycast script working on my Mac. After 15+ iterations, it still wasn't fully working. And I think that's an important data point worth sharing.

Here's what happened: I asked Claude to write a Python script that reads clipboard content, converts it to Markdown, and puts it back on the clipboard. Sounds simple. But the script had to work across macOS clipboard APIs, Raycast's sandboxed environment, an older Python version, and three different clipboard formats (HTML, RTF, TSV).

Claude wrote confident-looking code every time. It passed its own reasoning checks. And it kept failing in production (my laptop). Why? The agent was writing and "testing" code in its own environment — not mine. Every environmental dependency it couldn't directly observe became a potential failure point.

Each fix introduced a new edge case. The heuristic approach I let it pursue for too long was wrong from the start — I should have pushed it toward the simpler API-based solution much earlier.

The real lesson isn't "AI coding agents are bad." It's that AI-generated code needs the same review discipline as any other code — maybe more, because it looks so confident.

Agents are genuinely useful for boilerplate, well-understood logic, and self-contained problems. But the moment you have real environmental dependencies — OS APIs, sandboxed runtimes, version-specific behaviour — the gap between "looks right" and "actually works" can be significant.

The review-test-fix loop still belongs with a human who can observe the real system. We're not at the point where you ship agent-generated code to production without reading it.

This has been on the back of my mind lately — something that feels obvious once you see it. Every LLM output you've ever read was generated one word at a time. The model takes your input, burns through hundreds of layers, produces a single token, feeds it back in, and repeats. For every single word.

I was discussing this with Claude and the question I kept coming back to: is this the right architecture, or just the one we're stuck with?

The sustainability concern is real — energy, water, compute at scale. But that's almost a downstream symptom. The more interesting question is architectural: why are we locked into sequential token generation at all?

I was also drawn to Yann LeCun's argument that predicting the next token is fundamentally the wrong objective. His JEPA architecture proposes something different — instead of predicting every word in exhaustive detail, predict in representation space. The gist, not the pixels. A weather forecaster doesn't predict the exact position of every raindrop. They predict "heavy rain, afternoon." Same value, fraction of the compute.

It seems there's been serious effort in this direction — speculative decoding, diffusion-based language models. But nothing has cracked truly parallel, efficient generation yet.

Makes me wonder if we're in the "internal combustion engine" phase of AI architecture — powerful enough to be useful, but not the endgame.

Would love pointers to serious discussions on this — papers, talks, threads. And curious what people building or thinking about AI infrastructure make of it.

Google DeepMind published something worth sitting with. Their paper "AI Agent Traps" lays out the first systematic framework for a threat most deployments aren't designed for: the web itself becoming adversarial to AI agents.

The web was built for human eyes. It's now being read by machines — and some of it is being written for them.

What makes this different from standard cybersecurity concerns: the attack surface isn't the model. It's the environment the model operates in. Alter the environment, and you weaponise the agent's own capabilities against it.

Would love to hear from folks building or deploying agentic systems — is this on your radar yet?