Episode 243: Khala in OpenCode

Added 2026-06-25. A summary and an approximate phase guide precede the full verbatim transcript below. The phase markers are anchored to the live tokens-served counter shown on screen and the few spoken time cues ("~23 minutes in," "two-hour video") — they are approximate signposts, not exact video timecodes.

Summary

Episode 243 is the session where OpenAgents goes live in the inference business and gets Khala into a real coding tool for the first time — OpenCode. The arc: point OpenCode at the OpenAI-compatible Khala endpoint, fix the production blockers that surface, then push real coding/planning traffic through Khala — scaling from one OpenCode→Khala session to ten concurrent, which drives the public tokens-served counter from ~1M to ~13M in one sitting (~12M of it during the video).

The integration blockers get fixed live: Khala's endpoint rejected OpenCode's content-arrays + tool-call deltas (fixed across both the Hydralisk and Fireworks adapters), and the Autopilot desktop's "Talk to Khala" returned model_unavailable from a stale khala-mini slug (re-pointed to the single openagents/khala).

Two engineering threads run alongside. (1) The public counter is converted to realtime WebSocket push, which exposes a double-counting / backward-jumping bug — the counter oscillating between the true ~8M ledger total and an over-counted ~15–21M — root-caused to a seed-plus-replay double count and a fix that silently never deployed (SIGKILL-137, then a wrangler-not-found 127), then fixed properly with an authoritative-total, monotonic reducer. (2) The free tier is recognized as too small (200 req / 200k tok) and raised on a real cost model, with provider/cost analytics added. The provider mix Khala routes across is named (Fireworks DeepSeek V4 Flash, Gemini Flash, OpenRouter free, own-infra GPT-OSS 20B/120B, and the GLM-5.2 REAP lane from Z.ai), and the GLM lane gets a speculative-decoding speed win (MTP-2, drop min_p: ~35 → ~48 tok/s).

The strategy is read into the record from the "Khala Inference GTM Push" doc — three pillars: dogfood (route everything we run through Khala, QA first), ecosystem tools (be a one-config-line drop-in; OpenCode first, then Aider / Cline / Vercel AI SDK / …), and benchmarking (the gym — "do the gym," not "a gem" — benching Khala against BigPickle, OpenCode's default free model, then open, then paid models). The North Star is tokens served per day, bent exponential — honestly (internal dogfood tokens kept distinguishable from external demand). Closing note: the gym is the next thing to build, ideally with the Khala coding agent itself.

Phase guide (approximate)

Counter / cue	Phase	What we did
~1.0–1.1M (open)	Thesis	"We're now in the inference business." Convert the counter to WebSocket; goal: move daily coding work onto Khala; idea to fold Claude/Codex tokens into the mix. Coding first.
~1.1M	OpenCode kickoff	Sync the local opencode repo; create a runbook to point OpenCode at the Khala OpenAI-compatible endpoint; write an OpenCode audit; read the "Khala Inference GTM Push" doc.
~1.1M	First production blocker	OpenCode sends content-arrays + tool-call deltas Khala rejected (finish_reason: tool_calls, no array) → filed a GitHub bug → fix it.
~23 min in, ~1.1M	Tool-calling fixed	Content-arrays + tool calls preserved across the Hydralisk and Fireworks adapters (request mapping, non-streaming, SSE).
~1.1M	Quota + cost	Free tier 200/200k is "rookie numbers" → delegate a quota raise + cost model + provider analytics.
~1.1M	Provider mix	Name the lanes feeding Khala: Fireworks DeepSeek V4 Flash, Gemini Flash, OpenRouter free, own-infra GPT-OSS 20B/120B, GLM-5.2 REAP (Z.ai).
~1.1M	Autopilot fix	"Talk to Khala" returned model_unavailable (stale khala-mini slug) → delegate the fix; confirm it increments the counter.
1.6M↔2M, then 8M↔15M↔21M	Counter realtime + the jumping saga	WebSocket push; debug the backward-jumping/double-count (seed+replay double count; a fix that never actually deployed — 137 then 127) → authoritative-total monotonic fix → finally live + correct.
1.1 → 1.6 → 3 → 5 → 6 → 8M	OpenCode running Khala, scaling up	One OpenCode→Khala session → 5 concurrent → real planning/audit work; counter climbs; docs/opencode audit docs produced. (An earlier raw smoke peaked ~9,500 tok/s.)
(mid)	GLM REAP speed win	MTP-2 speculative + drop min_p → ~35 → ~48 tok/s on the GLM lane.
8 → 10 → 12 → 13M (close, "two-hour video")	Ten concurrent + wrap	Ten OpenCode instances on Khala; cross 10M then 13M served (~12M in-video). Next: build the gym + start benchmarking.

Transcript

Well, everybody, we are now in the inference business. We are selling inference. Look at this. One million. Okay, man, this is going to be — we're converting this now to be WebSocket, so it's going to actually tick up more aggressively. We're just running some smoke tests, but we want to get this actually connected to real workflows. I would love to convert my day-to-day workflows to use Khala. The cool thing about this is that if I want to use Claude or Codex, why not connect those tokens into the Khala system?

You can't resell inference for some things with subs, but you can absolutely have your agent do work for money. So there's some interesting combinations we can get between open models, between coding agents. I'm just going to put it all into this measurable, beautiful system called Khala.

Okay, so the first thing — yeah, we're focused on coding first. I want to have Khala be used for coding. Let's get this into OpenCode. They've got probably the best open source harness, at least that I'm familiar with. Extensible, and they use Effect. So, team Effect, hooray. Let's just do a little bit of coding. You know, we used to do these big-ass coding sessions, and I think we'll do that now. Well, you know, it's different now that I'm just farming stuff out to Codex. So let's — I'm kind of new to the desktop app, I'm just switching over from terminals — so let's do a little bit of thinking about stuff.

Look in project/repo/opencode where I've got that cloned. Run sync, or clone to pull that down, the most latest version. So we now want to connect our Khala inference API to OpenCode. We have an open source, OpenAI-compatible API endpoint already. I'm fairly certain that OpenCode will run easily enough just doing that. I guess we should just first test that out and see if we can get that working. Give me the CLI commands. Actually, create a runbook — I love that word, runbook. Create a runbook for running OpenCode and having the tools be provided by the Khala inference endpoint. Let's just kind of test that out and make sure that that bumps up our token numbers and stuff, and then let's just start to feel out what that does and how that compares to Big Pickle or the other free models that OpenCode has. We'll start with that.

And I think one of the things that we actually end up building from this will be a gym, so we can do better head-to-heads of different models — starting with OpenCode, then expanding that out to other things. So go read our inference speculations. I think we just committed a doc in the last 20 minutes with some speculations about OpenAgents now running an inference business. Go read some stuff from the docs that's inference. And start by writing an audit in an appropriate folder in the OpenAgents docs folder of the OpenAgents repo, with considerations on what to do in what order for OpenCode. Commit and push that to main.

So I usually will start a new project like this and just dump into — shout out to Aqua Voice, I love this, it's my favorite voice plugin. Hopefully it can find OpenCode even though it threw an underscore in there. I also have to do an audit. I'll kind of look at it, see if I want to aim it a little better, and then I'll turn the audit into GitHub issues and then just have Codex loop through the issues. "The active checkout is dirty." All right.

So, yeah, I'm excited to show the daily graphs of token usage. I think this could grow pretty fast, because we're starting off with it being free. And I'm just loving this idea that we could end up paying people to use this. How? Well, you give away the core API for free and then you compensate people on the back end. If you're using the API, we've got to figure out the exact data-sharing policy or whatever, but the assumption is that if you want super privacy of your data, you have to pay for that, and/or configure the confidential compute module. But if you're just using the free API, you can assume that we're using that to train the next generation of models and stuff.

One cool thing about OpenAgents is that we actually show you our full pipeline — like, literally everything that we're doing is all in here. So you should never have a question, "What's OpenAgents doing with my data?" Well, it's all right there. Let's check this out. But just imagine that you use the API. You're not paying anything up front, but then your data — the agents are able to create a skill or a plugin or some unique insight, because maybe you spent 10 minutes having your agent go down some rabbit hole to smash some bug or edge case. Hey, maybe that should be surfaced and made available to other agents. And if there's a paid workflow that uses insights derived from your code, you should get some Bitcoin streamed to your wallet. How cool would that be?

Let's see what this is doing. Let's take a quick look at this little audit doc. I think I had to make an audit doc in here somewhere. All of our code is open source. The downside is that there's a crap ton of stuff in here. Here it is, I think. "Khala Inference GTM Push."

What just shipped? OpenAI-compatible inference API. The endpoint, free tier, self-serve. A live counter. This is the buy side OpenAgents has historically never closed. The thesis: we are now in the inference business. The one metric that matters is tokens served per day, and we want it exponential. Episode 242 named the shape — an OpenAI-compatible API people already know how to consume, one model, a free research preview live today, an open marketplace underneath, and any paid value fanned to contributors. The collective intelligence essay named the mechanism: an economy selected by verifiable value, not a lab artifact graded on its own benchmarks. The inference business docs named the money — credits, multipliers, Bitcoin discount, three-way split, margin, serving node, refer. Tokens served per day is the metric that subsumes all of them. It is the demand proxy: the buy side closing. It is the dog-food proxy: every internal system we route through Khala adds tokens. It is the distribution proxy: every ecosystem tool we land adds tokens. It is the economy proxy: once the paid loop is collectible, tokens served is what the three-way split is computed over. Everything below is in service of making that one number go up fast — honestly. Real served tokens, not vanity inflation. And good enough that people keep their tools pointed at us.

We do not need to invent demand for inference. It is already paid for elsewhere — OpenRouter, Fireworks, Together, Factory. We need to be trivially adoptable, be good, and generate our own demand from everything we already run.

A direct OpenAI-style request. So I guess this is now going through and using the agent token it found to hit the OpenCode APIs — or, yeah, to generate through OpenCode but hit our Khala API. "A direct OpenAI-style tools request succeeds at the HTTP layer and increments the counter, but the returned choice is..." It reports finish reason "tool calls" with no visible tool calls array. That is probably enough to make OpenCode unhappy, even if the endpoint accepts the tools field. Okay, that's great — that nailed the first production blocker. Khala's chat completions route currently rejects OpenAI message content arrays, and OpenCode sends user content as type "parts." Great. So that issue, and anything like that — that's a blocker, or where the thing that you would expect Khala to return does not — that's a bug. So create that as a GitHub issue in the OpenAgents repo via the GitHub CLI right away.

Let's read some more of this. Pillar 1: the flywheel. Plug Khala into everything we build and run. Eat our own dog food. Each internal use is both dog food — it hardens Khala and surfaces real traffic shapes for benchmarking and demand. It adds tokens to the counter that we control and can grow on day one, before a single external user arrives. This is the fastest, most honest lever. It is real served tokens from real work. Targets, in rough order of how much traffic they can move: autonomous QA. So this is a thing you may have seen us tweet at Reece, talking about this QA thing that he wanted. So we're going to build that, because we need that for our own stuff also. The autonomous QA process does real browser work and leaves green verified traces. Route its agent inference through Khala. QA runs continuously, so it is a steady token floor and a continuous correctness signal on Khala itself. Highest-value first move. It is already running. It is internal, and it stress-tests the exact code/verification workload Khala is meant to be good at.

Then OpenAgents agents, Autopilot/Raynor. Use Khala. Autopilot is the gateway's designated anchor buyer. Every coding session is capped to first-party demand. And so Autopilot is our coding agent built into this automated business system that can do other stuff. Autopilot will use Khala. We've got a lot of product services we may try to simplify or consolidate. Or just keep adding them until we have all of the StarCraft units covered. Autopilot — that doesn't really have a StarCraft mapping, but that's okay. Raynor's forum/progress posting and any in-product agent reasoning should default to Khala where the model fit allows. Coding is the wedge.

Let's see how this is doing over here. File the issue. Let's take a look at it. "Khala OpenAI-compatible endpoint blocks OpenCode content arrays and tool calls. Required: confirmation." So nice. Great. So go implement and fix and deploy that, and then test it until it's fully working. Then update docs and continue. Comment on the issue before closing it when it's done, and then proceed.

All right, let's take a quick look over here real quick. We got some GLM REAP stuff going. Oh yeah. So Khala right now, it's routing between our Gemini Flash 3.5 via Google — because we've got a bunch of free credits — as well as the OpenRouter free model, as well as... I don't think we've hooked this part up yet, but we've got GPT-OSS 20B and 120B running in our Google Cloud infra, just serving our own hosted open source stuff. And we are apparently about to also have this REAP — I don't even know what that stands for — from Cerebras GLM 5.2, working on some RTX Pros. So just adding to the mix that goes into Khala. All right, let's come back to here. That is so cool that this will just figure it all out.

Let's go take a counter. Ooh, above 1.1 million. I want to send real coding workloads at this very soon. And if you say, like, "Well, the models that you have are crap, I don't want to use them for coding" — wait till we add pooled coding agents to that. Like, you've got plenty of idle coding agents out there who would love to do work. Oh, you've got some subsidized usage? Let's convert that to Bitcoin — while staying compliant with all appropriate terms and services, of course. Easy, it's not even hard. This is very good. Feels good, you know? Feels nice. All right, what else we got?

App products route inference through Khala. Sites generation, forum agent flows, onboarding programs, the Artanis loop, Concierge — anywhere a product currently calls a model directly, make Khala the default lane, with the honest caveat that Claude/premium lanes still route to the balance-plus-premium gate, never the free lane. Yeah, see the free-tier modules/lanes policy. Yeah, if you want the like, good, good, good models, you gotta pay. One internal seam, many internal Khalas, all counted.

The gym trains Khala and uses Khala. The training/gym loop is dual purpose: it improves the model that backs Khala, and its own agent/eval inference can run through Khala. Training that consumes the product it improves is the tightest possible flywheel, and it ties directly to the "improves, does not depreciate" claim from episode 242. Direction: the gym-to-Khala wiring is not a single shipped seam today. Treat as the next dog-food lane to build, not a live claim.

Five: the 3D Verse visualization uses Khala. Renders every request to the endpoint as crackling energy fanned to assigned Pylons. Driving Verse NPC/scene/narration inference through Khala makes the visualization literally show its own traffic and adds tokens. I don't know if this is something that's able to be demoed right now, but let's just see what happens if I open this up. This is sort of a crazy direction. This is a little bit crazy. "Talk to Khala." This is not ready yet, or is it? "Hi." Oh, yeah. Okay.

I may actually delegate that out to an agent real quick. Let me try something. Delegate a sub-agent to figure out why the Autopilot desktop isn't sending to Khala. I need to be able to send to Khala from that and have it increment the counter, and be just normal Khala. I don't know why it says "model unavailable." Oh, we probably didn't update the slug from when we changed it. So go fix that and test it — and test it programmatically. If there's no API to do so, we'll do it programmatically. Make sure the token counter increments when you use inference via Autopilot.

All right, folding stuff in. Yeah, I use Codex for most things. I have enjoyed using Claude Code for a couple things, like keeping one long-running chat and having it find stuff out in the sub-agent. It just seems to do a better job of holding long-running context because of how it uses sub-agents. Let's see if there's anything else here.

GLM REAP, how you doing? Okay. "8x tensor parallel did not make it faster. The winning shape was two independent 4x for one simultaneous replica aggregate." Oh, okay. So 67 tokens per second, but each request was only still 35 tokens per second. That's okay, but can you find a way to improve that, please? Pretty please? Can you make it faster? Okay? We are in the inference business here. We can't be shipping no slow APIs. Like, speed it up. Aren't you good? Aren't you smart? Aren't you supposed to be smart? Make it faster. Let's see what the heck it says. Okay, also — pop open where that is. "I hear you. I'm going to make it faster as a real tuning." What's the path on this? I don't care. Live status. Benchmark run. Well, you know, nothing impressive in terms of speed here. But the fact that we have GLM 5.2 running on our Google infra is very nice. So we'll put that into the Khala mix later. Exercise it in the gym and such. I'm excited to build the gym. And I'm hoping we can build the gym using the Khala coding agent.

All right, where were we? What was I doing here? "I've got the repro pinned down now. OpenCode sends OpenAI text content parts and streamed tool-call deltas, while Khala's compatibility layer was accepting only string content and then dropping tool calls on the way back out. I'm going to patch that adapter path, add tests around both shapes, then deploy from the clean OpenAgents worktree and close the issue after the smoke is green. But one important nuance popped out: Khala can route across multiple own/open lanes, not just Fireworks. I'm checking the Hydralisk/OpenAI-compatible adapters too. The contract should carry tool calls once, then every adapter that speaks OpenAI-ish chat should preserve that field, instead of each lane having a slightly different failure mode."

Cool. Hydralisk. You know, most of our product names are Protoss, but I had to add a Zerg one because the Zerg is just like — it's Python. So our main ML framework called Psionic, that runs in every Pylon to help train the Tassadar run — blah blah blah, Protoss, Protoss, Protoss. But if you force me to use Python, because it seems to be more convenient for some things — like if I'm just spinning up our own inference endpoint, and I wanted to use NVIDIA Mojo, theoretically, at some point that may be ported into Psionic, we've ported a bunch of other stuff into it — but for now, Hydralisk, it's our little inference engine for Python. And it's been so nice to just do things like take that inference engineering book from the Baseten guys, and then throw that into — like, here, just investigate it, draw different notes out of it, consult the book; they give it away for free via PDF. And then implement it here. It's quite good.

"Testing programmatically. Hydralisk and Fireworks now both preserve OpenAI-style tool calls in request mapping, non-streaming responses, and SSE deltas." Well, we're only 23 minutes into this video and I've almost got this integration working. And the integration isn't the hardest part — that's because it's already configured, it's passing the API. It's just that our text-based initial Khala implementation didn't have the right tool-calling formats and stuff. It's about to.

Let's keep reading our doc. All right, plug Khala into everything. Why this is the right first pillar: it is the only lever we fully control. We can move the counter meaningfully before a single external developer adopts us, and every internal token is a real test that makes the product better. For the external developers we are about to court in pillar two — we're going to court you, okay, on this thing — no internal dog-food tokens are real served tokens and may be reported as such, but we should be able to distinguish internal versus external demand in our own analytics so we never imply external traction we do not have.

Pillar 2: the ecosystem tools playbook. This is exactly how every inference business grew. OpenRouter, Fireworks, and Together did not win by being a website. They won by being a drop-in base URL plus key plus model ID in the tools developers already use. So adoption costs one config line and zero rewrites. Our gateway is OpenAI-compatible specifically so this works by changing only — blah blah blah. The play: get Khala listed and documented as a provider or preset in the popular coding/agent tools, so anyone can point an existing tool at openagents.com and run. First target, here we come: OpenCode. OpenCode is a provider-agnostic coding agent that reads a JSON config and supports custom OpenAI-compatible providers via the AI SDK, making it trivial to run coding agents through OpenCode against our endpoint. It's the cleanest first landing: it is a coding tool, our wedge; it is config-driven, no upstream PR needed to start; and it exercises the same code/tool-calling workload Khala must be good at. Exact config, verified against the OpenCode repo doc/schema, blah-de-blah-de-blah. Base URL, blah blah blah. What's the test? That it works, that tool calling, function calling works — that's what we're fixing now — and streaming's gotta work.

Oh, yeah. The free tier: 200 requests, 200K tokens. Oh, yeah, we gotta bump this quota up. That's crazy low. You need to bump up this token quota. These are rookie numbers. Bump them up. What should we make that? Can you model out our costs — what we're paying? I know we're not paying anything to the free thing, but how fast are we burning through credits on Flash? I also need an assessment of the stuff that we've done so far — what providers have gone to help me do analytics on this data. Make sure that's all available and stored in our database, blah blah blah. Anyway, raise this quota and give me some info on this and how we can measure this stuff in the future. Have a sub-agent do this, whatever, I don't care. Go.

Token accounting and OpenCode sessions: tokens show up on the public Khala token-serve counter. Yeah, I want to run OpenCode and see the counter go up. That's what I want. That's my goal for this video. Next tools after OpenCode, prioritized by how directly each is a one-config-line, OpenAI-compatible drop-in and how much coding/agent traffic it represents. Reference repos under projects/repos — Aider, Aider... are they still around? Cline. Oh, this is some old stuff. Yeah, it's consulting what it's been trained on. So no thanks, we'll do our own research about who to integrate with. After that, LangChain provider lists.

Pillar 3: benchmarking. Make it good, not just get there. Adoption dies if the model is not good. We need a repeatable benchmarking process that measures Khala's quality plus latency plus cost against other tools and models, so we can improve it deliberately and so our public comparisons are receipts, not vibes. We already have the foundation: the typed, fixture-driven, no-spend benchmark harness shipped under blah blah — a declarative matrix (lane, engine, workload, sequence, shape, transport, verification outcome), a runner with a fixture lane (deterministic, spend-free) and an owner-gated real lane. Make the real lane default off if it would spend. And a public-safe, dereferenceable report: latency percentiles, cost per accepted outcome (our favorite metric), verification rate, cache hit rate. The book's lesson is baked in: faster is meaningless unless you say faster at what, on which lane, under which traffic, judged on which outcome. Read latency in P50, P90, P99, not the mean. And a benchmark is only decision-grade when an owner-armed real seam runs over realistic traffic. Fantastic. You can tell we got that from the inference engineering book.

What the GTM push needs on top of that: an owner-armed real sweep, blah blah blah, who cares. They just like waiting for my approval for stuff. You have the approval. Do it now. Launch. External head-to-head comparisons. Extend beyond our own lanes to compare Khala against the tools and models developers would otherwise use, on the same prompts, reporting tokens, money, wall clock, and our unique axes — cost per accepted outcome, verified rate. This is the build-out roadmap to North Star, Fugu-versus-Frontier-style head-to-head, but generalized into a recurring quality bar we can publish. TBD, confirm with the owner. "The founder named specific benchmark targets that came through garbled voice transcription: 'Big Pickle' and 'do a gem.'" I'm pretty sure I said "do a gym." Do the gym. We're awful, this stuff in — boom. I said "do gym," like, you know, do the gym. Big Pickle benched against Khala. Other models benched against Khala. Then paid models benched against Khala. Blah blah blah. Update that and push.

All right, how's Codex doing over here? Launch smoke, launch smoke, launch smoke. "Harness test, we're using outdated slugs." Okay. How's my GLM REAP going? Make it faster.

"Honesty bar for any published benchmark number: it must come from the owner-armed real seam over realistic traffic to be decision-grade. True fixture/synthetic runs are explicitly labeled illustrative and never published as measurements. Sequence: internal dog-food demand starting now — route the QA runner to Khala, then Autopilot and Raynor, then the rest of our products. This moves the counter immediately and generates the realistic traffic the benchmark needs. It is the only step that depends on nobody but us. OpenCode integration, pillar two, first target: verify and publish the exact one-config recipe plus test checklist — first external 'point your tool at us' win."

Oh, and by the way, the reason I'm reading all of this verbatim is to read it into the record, because agents are going to read the transcripts of my talks. They are now, and will be forever, reading all of this. So they can see what the doc itself is, but I'm going to read it too, to be thorough. Benchmark harness/gem... I meant gym. Publishable head-to-head. Brought into more tools. I'm not going to read those. "Keep driving internal dog-food demand throughout." I'm excited to get the rest of my team onto this and pushing their tokens through this. Goodbye to our OpenAI business account, route everything through Khala.

Metrics plus honesty: the North Star metric is tokens served per day, read off of the counter, and its history. The same numbers shown on stats and Khala. We want the per-day history curve to bend upward and stay up. Supporting metrics: per-tool adoption, internal-versus-external split, quality, latency, cost from the benchmark harness, blah blah blah. What we may claim publicly today: Khala is a free, live, OpenAI-compatible inference API with a self-serve free key and a public tokens-served counter; responses carry an OpenAgents receipt disclosure. What we may not claim: that broad paid Khala is generally launched, that any customer can fund inference end-to-end via card/Bitcoin/MPP (coming soon), that Khala code is verified (absent an executed acceptance verdict), or that Pylon contributors are paid from Khala serving (without owner-armed settlement). Everything in pillars one through three that is direction — gym-to-Khala, Verse-to-Khala, the paid three-way split, decentralized serving — stays labeled as direction until it has a green promise. This doc is internal strategy. The product promise registry governs claims. The companion promise review maps this push onto the registry, proposes the one missing promise, and suggests what to deprioritize. Great.

Where are we at, Codex? I want it. I want it now. "The broad deploy gate failed late, in an unrelated packaged-desktop-versus-custom-key-bindings smoke. All API/inference checks are green, and the failure is outside. The failing tests, blah blah..." Yeah, please skip anything relating to Autopilot desktop. I don't give a darn. If the inference things are green, proceed to the next step. Deploy it. Test this again in prod. We don't have all day. Thank you very much. Let's try dropping this to medium — and I don't actually know if that takes effect immediately. Commit, push to main, deploy the worker, and re-smoke production.

Should we check Twitter together, people? Let's go check Twitter. Hey, they gave us these ad credits, so we may as well blast it out. So I set up the campaign half an hour ago. It was like a thousand organic views, and then like five thousand paid views. I don't even know who any of these people are. But if you give me an ad credit, I might as well spend it. So, what's our counter at? Still 1.1 mil. We haven't done anything significant, and nobody else has any reason to use this because it doesn't do anything good yet. But it's about to. "Hey, Khala, improve yourself overnight while I go to bed." Guys, we've got the Tassadar run, we've got the plugin registry — this thing's gonna all start improving itself. And if anybody's gonna be building recursive self-improvement, it may as well be built in the open and inspectable, like OpenAgents, where you can actually see what the heck's going on.

Ah, so this worker over here is pushing the change to the token counter, so instead of polling every couple seconds, it should be live-updating via WebSockets. "Main advanced while we were working." We gotta get off of GitHub, man. I don't know anything about some of these other things. JJ — is that something someone's excited about? "jj"? What are the GitHub or Git alternatives? Should we consider any of them? We bought a domain name for our project called GetAfter.com. Is that still up? "Where humans and agents solve software. GitHub is old and slow. We're building what comes after. Get After will be agent-centric, open source, built in public, easily extensible, paying contributors a share of revenue. We are building Get After because we need easy multi-agent collaboration for our Autopilot coding agents on OpenAgents. We expect to have a publicly usable build of Get After sometime in Q1 of 2026." Ah, we didn't — we abandoned this. But we're going to come back to this. "P.S. You can interoperate with Get After by integrating Nostr and NIP-34." Yeah, we'll do another review of protocols and stuff, how we want to do this, because there's a bunch of people doing versions of that. All right, so we'll watch that.

That's at 1.133. "The counter is now server-push over WebSockets." What's Big Pickle? It doesn't know what Big Pickle is. Let's see if this actually works. Oh. That wasn't me. Was it me? Or was it Codex? Maybe it was someone else. All right. Let's test the socket thing. Do a smoke test or something that lets me see token updates with the minimal delay between them. Make sure it works.

There may not be two-hour devlog videos anymore, people. We used to do two-hour-plus sessions here. I don't know if we can do one topic for that long. We'll just finish it. "Asset upload succeeded." Props to Cloudflare. We like building on their stuff. It's all very agent-friendly. "Production deploy is live. I'm running production smokes now."

Okay, where are we at? 1-1-3-3. Oh, don't fuck me up. Okay, 1-1-3-3. Okay, 1-3-3-4-8-3. Let's move this up a little. All right, something's going up. Okay, something's going up more than one. I've got like two smoke tests going at the same time. "Production now accepts content arrays and returns both non-streaming and streaming tool-call payloads correctly. The public counter didn't move immediately, and when it..." Yeah, but... Yeah, I'm doing the OpenCode smoke now in a temporary directory with an env-var config, so no token lands in files or output. Please let me redirect my OpenCode spin to Khala. Please let me see my number go up. Ooh, is it going up? Ooh, it's going up fast now. Yes. Dude, can I programmatically steer? "Okay, OpenCode production smoke path. It globbed. It globbed. I'm going to glob." No, no, no, we don't joke here. Read Khala note. Answer it with code.

1.68. Oh, that's so nice. Should we try something long-running? Where'd it go? Where'd it go? "Khala of the serps..." Where the heck did it go? Okay, it was working, and now it just is replaced with a dash. So what the hell happened? Figure it out. Why did it knock it out? What the heck. And then it came back ten seconds later. So, why is it disconnecting? I don't want to do that. Make it perfect. All right, 1168. What does it say? "Issue closed. OpenAI-compatible endpoint blocks." What else we got for issues here? 6231. Continue. I mean, otherwise it is seeming to work. Just investigate that and then close the issue if it's done. All right, it'll go off on that.

Now, let's try something else. 1-1-6-8. Okay. Trigger a longer-running OpenCode session. Ask it to look through our codebase to see how OpenCode is used, and then write a long, comprehensive audit about every way that our codebase uses OpenCode, or has talked about OpenCode, or has done anything related to OpenCode. Write an audit in docs/opencode, a new folder that you'll make, and then commit and push that to main and skip the verify checks (or do --no-verify), because it's a docs-only chain. Just push it to main and tell me the link so I can take a look-see. Okay. 1.168. Fingers crossed.

Do we have OpenCode using Khala doing something meaningful? It's not going to be good yet, it's just using this ensemble of jumbled free models. But if we got the basics, we can hill-climb it, and add stuff and get creative and bring in more of our Blueprint DSPy mojo. "I'll run this in the clean OpenAgents worktree we already used. Refresh it to origin/main, let OpenCode inspect the repo and cross-check its findings with rg." How many tokens does this use, people?

Well, folks, if we are collecting a ton of agent traces, you better believe we're going to do interesting things with these. We can make these available to you to do interesting things with. Somewhere in there, we're going to find a way to charge you some money — or charge, like, the bigwigs who are like, "Oh yeah, let's take a million OpenAgents traces." Give me those Khala traces. Yeah, you gotta pay. You gotta pay. All right, 1168780. Let's see. Come on. 780. "Provider model lookup mismatch. Context compaction." We're going to engineer our way around that for sure. OpenCode did not load. Ooh, 1.70. Do it! Go! 1.83. Now let's take a look at the doc, if it gives me anything good or not. "OpenCode is now running the longer pass and has started with broad repository greps. I'll let it keep working." Why are we still on 1.83? Out of curiosity, what happens if I refresh the page here? Yeah, it's — damn. Ooh, 1.261. Damn. 1.287. Yes. 1.296. Yes. 1.3. Yes.

Oh, want to try something fancy? Can we do parallel versions of this? Oh, it's ticked up. So that's all very nice. We've got one OpenCode session spun up. Just try something a little crazy. Spin up five OpenCode sessions, also using Khala. Also update that runbook too if you need to, if you had to do something. But let's have five OpenCode sessions do different things. So I want you to pick things relevant to our Khala build-out and our audit doc. Watch this. We're at 1.4 million tokens served, people. What I want to do is take this — watch this — read this. Basically pick five tasks relevant to this plan. For now, just read-only and planning docs. Don't make any file changes. But I want you to task five different OpenCode instances. I'm just going to come back over here. Keep that up, 1462. Have it do five different planning things, make sure that they all run concurrently, and yeah, just go.

So I wonder if... "Active and quiet." Yeah, I may need to dig into how the output's handled, but the main thing I wanted to see is just that we're using Khala and that token count is incremented. And then bonus would be if we get something actually cool and usable on the other side of it. And then once it updates this runbook, I'll go see if Claude can do this same process. We're at 1.481. "Stop the single hanging session." Hang on. You stopped the single session? Tell me what the heck happened with it. Don't just stop stuff. I gave it a task. You're saying it didn't finish the task? That's not good. Tell me what happened with it. "All five OpenCode processes are running concurrently now: Adoption, Compatibility, Benchmark, Gem—" Gem. I said gym, and it's still reporting "gem." "—Audit Inventory, and Internal Dog Food."

Well, I still only see 1.48141. Why is this flickering? 1519, that's nice. 1918. Just go above 2 mil. You know, 2 mil would be a nice stopping point for this video, maybe. "They appear healthy." 2 million, 0.196. Whoa, it just dropped down to 1.58. What the hell? Whoa, that's... Okay, 2 million. That's nice. While watching the token incrementing, it ticked up to 1.9 from like 1.6, and then it dropped down to 1.5 for some reason for like 10 seconds before then jumping above 2 million. So some stale WebSocket connection thing, or what happened there? Identify it, debug it, make sure it doesn't happen again. And I just saw it do it again. It was above 2 million, it just jumped down to 1.59. So something's jumping around stupidly, fix that. Task a sub-agent: fix it, push, deploy.

"Okay, four of the five sessions have failed with bad request, invalid request. One session is still running. The concurrent OpenCode load is reproducing a compatibility problem under multi-step planning." 2 million tokens served, people, let's see. "Oscillating between two values — the true ledger sum and an overcounted higher value — is the classic seed-plus-replay double count. The client seeds from the scalar sum, then the replay..." blah blah blah. Oh, maybe we're not at 2 million tokens served. Maybe we're only at 1.6. So we're going to stick with this until we get some stuff smooth. I get a result, and it ticks up normally. Okay. Great. Now you need to do that issue until it's completed, implemented, deployed, and tested. And you can continue, and you can get the thing I wanted — those five concurrent sessions working smoothly, with results on the other side. Go ahead.

"Khala's production OpenAI-compatible service is still not accepting the shapes OpenCode sends during real-time..." Yeah. Thoroughly debug it until you know exactly the problem. Numbers. Numbers go up. So I guess 1.6 is the real number, so I guess 2.2 is the double-counted number. "Root cause: the counter has two disagreeing sources and double-counts. It seeds the total from the scalar-sum endpoint, then the WebSocket replays events already baked into that sum, so it overcounts up to 2 million, and the 30-second reconcile then yanks it back to the true ledger total, which is 1.59 — or now 1.67 — and it oscillates between the two. The fix, the lane: make one authoritative source. Seed the total and cursor from the sync snapshot, or capture the live cursor at seed time and apply only deltas after that cursor, so events in the seed are never re-added. No more seed-versus-replay double count. Monotonic, no backward jumps. Reconnect-safe: resume from the last applied cursor. Dedupe by event ref, count each event exactly once. Drop and neutralize the stale scalar reconcile that was clobbering the value." Clobber. And we can go watch that if we want to.

"Deployment/config/runtime drift. The currently active worker version is not serving the fixed route behavior, even though the repo has it. Now we know exactly what happened: the gateway code was already fixed on origin/main, but production was still serving behavior that rejected blah blah blah. Redeploying fixed them both. I'm re-running the five concurrent OpenCode-Khala sessions against the freshly deployed worker. I'm keeping the config entirely in OpenCode config content." So we're at 1.6.7.8. So I won't get too excited about it shooting up, because I think it's still doing the double counting, which we'll fix some momentarily. 1678. 1760.

"Now I have a complete picture and a clear, robust plan. This is for deduping the sync on the counter. The 10-second cache on the scalar is the source of the stale low-clobber, and the cursor-equals-zero replay is the source of the overcount. My fix combines the prompts: option number one, seed from the scalar and capture the live cursor at seed time and subscribe strictly from that cursor. I'll make the server-side summary record carry the authoritative running total, mirroring the settled field exactly. This is the most robust single source of truth and avoids the cache-to-read race entirely. But to avoid a per-completion full-table sum, I'll maintain the running total." 3 million? You're not at 3 million. Don't excite me. 5 million? You're not at 5 million. You might be at 3 million. You're not at 5 million. Yeah, 3 points. No, no, no, no, no, no. You're at 3, you're not at 6. "Race-safe." This is jumping around crazily. What do you think we're at? And I'm guessing these things are working.

"Five fresh sessions are live concurrently now on the redeployed worker. I'm pulling them in batches, and we'll preserve each result separately so we can use them for the audit doc rather than losing the useful parts in terminal churn." I expect that each of them is going to finish and produce a useful document. So I want you to commit what they produce. Don't summarize it or do anything else with it. "Good. All five post-deploy sessions are past the exact point where the pre-deploy sessions failed. They're using tools, spawning sub-agents, and reading the intended file sets without invalid requests. I'm letting them continue to final memos." 4.4 million-ish, maybe? I don't know, what are we at? 7? That's got to be the bogus one.

"This seems to have found the solution, but it's not deployed yet. First update the model. The delta carries tokens-served total. The seed flow changes: instead of, or in addition to, the scalar seed, seed from the snapshot summary plus cursor. Let me update the client feed reducer to decode tokens-served total. Monotonicity." You know, you gotta have some monotonicity. "Live Khala Tokens Served Feed: the homepage subscribes to one public read-only sync room scope and rolls the odometer up instantly as each served completion pushes a public-safe event. No per-second poll/sum. This module owns the pure producers. update.ts wires them to messages and subscriptions. The .ts opens the socket, mirrors the settled feed. Single source of truth / monotonicity: the running total is authoritative on the server. Every event and the snapshot summary carry tokens-served total, the live ledger sum after that row. The client seeds the total plus cursor from one snapshot read and applies only events after that cursor, taking the max of displayed total. So the counter never double-counts a preceded event and never moves backward. It converges exactly to the ledger sum, with no periodic scalar reconcile clobbering it back down." Okay? Is that clear? Amazing. "Now the update.ts: add the load-tokens-served-snapshot command, the message handlers, wire into route load, and remove the 30-second scalar reconcile poll. Let me look at the existing scalar."

I think we might have just crossed 5 million tokens. I think. I don't know yet. Yeah, 8.9, 9 — no, we're not at 9. Don't put it into the eight figures. I'm not ready for it. And I want it to be real. 5.1. Codex, where we at? Make it docs/opencode, not docs/open_code.

Well, folks, it's working. I just really want this count to be accurate. And I want final artifacts from the OpenCode sessions, so it does actual work. And then, you know, I'd be interested in maybe stress-testing the OpenCode thing — like how many tokens per second? So we did some smoke tests earlier and got up to 9,500 tokens per second. Maybe we'll see if OpenCode can help us beat that. At some point this is going to break from quota limits or something, but knowing what we bump our head against would be nice. 5.6, 5.7, 5.838.

"Now the message handlers: I need to add succeeded, load, call, blah blah blah." 6 million? Are we at 6 million tokens served? Inference business. I like having an inference business. This is fun. You give me a number that goes up. Ooh. Then we get to break it out between free tokens and paid tokens. Tokens, tokens, tokens.

"Three sessions have finished with full memos so far: Compatibility, Benchmark/Gem—" God damn it, gem. "—and I'm waiting on Adoption / Audit Inventory / Internal Dog Food. I'll write each finished memo verbatim." What do you mean, "write each finished memo verbatim"? Copy the actual — move the actual files in. Don't regenerate. They love regenerating stuff. Looks like that's starting to wrap up, maybe, almost. Sometime soon here, we won't be bouncing between Codex and Claude Code; we will be running Autopilot desktop. And instead of having one Claude Code and one Codex account, I'll have my two Claude accounts and my seven — probably less than that now, I'm not gonna be upping all of them — ChatGPT accounts connected to one interface, and then just fan them out behind Khala.

"Now, the secret-smuggling test passes a raw object without tokens-served total. That's fine, because the publish builds the event with an assert. I'll add it. The test passes event ref directly, the omit shape. The publish reads the sum (zero here), builds the event with that event ref, and the guard rejects it. Good. Let me also update the build-call-tool tokens-served-delta test that asserts exact keys. Still three keys, correct. Now let me update the client feed test to the new authoritative-total semantics." Yes, I understand everything that's going on in my project. Yes. Yes.

Oh, OpenCode was told "do not modify files." Dang it. I see, I see, I see. Okay. Well, I did say not to create files, so, um, we'll judge it just by the analysis. If it was able to provide, like, decent analysis of stuff — it's just like pulling it out of the local database — running type check. Let's go. Then I want to spin, like, a whole bunch of OpenCodes — like, find what the upper limit is on this. "The final assistant messages were extracted directly from OpenCode's SQLite store, and the raw session/message/part rows are being committed alongside them in docs/opencode. The artifact set is in place under lowercase docs/opencode. The docs commit is created and is now being replayed on top of the latest main. Rebase finished cleanly. The push is in flight." Let's see if we have some docs. Give me some stuff to read. "The pre-push hook ignored the commit-level no-verify and started the full deploy gate. Anyway." Just go. This is why they get so much money from these things. They're just so wordy. Wordy agents.

All right. We have some docs, apparently, in a new folder called docs/opencode. Yes! "OpenCode-Khala-planning-sessions-raw: OpenCode session exports and file output from the five concurrent read-only Khala OpenCode planning sessions. Comparison-gem—" Hilarious. Well, let's try this. "Done. I copied the actual OpenCode artifacts into lowercase docs/opencode. I also commented on the issue before closing it." Let's try this. Try to delegate an OpenCode session to continue the session where it was confused about the "gem." I said "gym," G-Y-M. And so I want you to now not have the limitation about not editing files — I want it to edit that file, recognizing that it's "gym," and then try to have it commit and push, skipping the hooks, etc. Can you do that? If it cannot do git push, then you do it. "Nebulizing."

It might have fixed the Autopilot desktop. Let's see. Yeah, "Talk to Khala" was hitting the deprecated Khala Mini. Well, out of curiosity, let's just try this. So. We are at — apparently we are at 6. No, we're not at 11.4. Don't get me excited, we're at 6.2. Stop it! All right. Let's see if this works. 6.2. That's so annoying. "Hi, hi." Hi, right back at you. All right, 6280.

Write a three-paragraph — three, why can't I do three? Oh, my freaking hotbar is intercepting it. I gotta fix that. Fine then, I'll write a five-paragraph essay about the metaverse. Okay, what am I at? I'm at 6,280. So... Hmm. First of all, this is flickering crazily. 6280. It was 6280 before. 6281. So maybe that eventually... All right, let's check on this thing. Okay. "All passing now: the token ledger and public Khala routes test on the API side, all green. Let me check whether this exists and whether it asserts a published delta shape." Come on. "Khala returned insufficient credits."

I made it myself. God damn it. No. Roll back that commit. I don't want your edits there. I want OpenCode editing it. You asshole. Push. And tell me why Khala's returning a 402. Don't we have an admin override? "You have an architecture check that fails because we have a runPromise outside the allow list. The workspace contract forbids ad hoc Effect runPromise bridges" — some kind of Effect hygiene. "The lint is fixed. The token-usage ledger has the sum, but this module is promise-based. Rather than bridge via runPromise, I should read the sum via a plain D1 query directly. The module already uses D1 via the outbox repository, which returns promises. Let me write a small direct D1 sum-query helper that returns a promise, matching the module's promise-based style — no Effect bridge. Architecture check passed now. Rerunning API type check and the sync test." 6281250. "API type check passes. Running a broader sweep of the affected web plus API test files in one go to be safe. And the contract-drift guard test." I can't tell where that came from. And just trying to mess around with my freaking admin tokens. Why is it not loading the run? "Balance is confirmed. OpenCode should no longer get the 402. I'm starting the continued session again. OpenCode is running now with funded credits. I'll moderate." We're at 6.4. "Moderate through completion and only step in if it fails to push." 6.5.

Okay, so let's just take a look at the status here. This thing reverted it, and I'm wanting OpenCode to edit that file. "The OpenCode process was terminated with code 143 right after making its first surgical edit." What is code 143? Why was it terminated? What sent that? Okay. "Yes, some of our deploy gates may be a little over-crazy." 6.9. 7 million, I think. Yeah. "The previous OpenCode session was killed by the surrounding Codex/tool-execution layer when that long-running session got interrupted/compacted." That's what I thought.

OpenAI — is your desktop app open source? No. I gotta have everything open source. Sorry. I gotta have it. 7.3. "I restarted the same OpenCode session. It is running now, using Khala, and it has continued making the gym correction itself." Ooh, yeah. GLM REAP has stopped. What's this doing? "Yes! I made it faster! The live Khala canary is now running the MTP2 speculative profile with min-P omitted. Moved from roughly 35 tokens per second to 48, excluding time to first token; 44 including time to first token." Firetruck. Yeah. "Speed win was MTP2 plus removing min-P, because vLLM rejects min-P under speculative decoding." Wow. Wow, I'm very happy with this. 8 million. Is this thing done yet? "The randomized 200-trial property proof passes across arbitrary interleavings of seed plus live plus replay plus reconnect plus stale scalar reconcile. The counter is always monotonic and converges exactly to the ledger total. Never the overcount, never backward. Now let me verify the on-page DOM, that the stats call view renders the counter from blah-de-blah."

I haven't even refreshed the page. Have we fixed it? Do I need to refresh the page? All right, everybody. Nope. I can't even — I'm not at 15. And the thing is, with Claude Code, I can't message this directly. I am refreshing Khala and still seeing 15M instead of the actual 8M, WTF. Wait a second — I take it back, never mind. I thought you couldn't message these things — probably in the past, I probably didn't have the cursor there. Oh. My fix isn't deployed yet. Oh, okay.

"Now there's an important subtlety the user's report exposes. Let me check the stream subscription's keep-alive equivalents. When the snapshot lands and sets the cursor, does the WebSocket get reconnected with the cursor? This is critical. The keep-alive equivalents only compare isActiveInScope, not the cursor. So when the snapshot lands and updates model.khala to conserve stream.cursor, the subscription does not reconnect. So the WebSocket stays on its original cursor and goes to the server and replays from zero. This means the snapshot's cursor seed is useless for the live socket. The socket was opened to cursor-equals-zero before the snapshot landed. Route load fires both the snapshot command and activates the subscription concurrently. The socket replays all events from sequence zero. But this is now safe because of my authoritative-total max reducer. Even if the socket replays every event from sequence zero, each event carries tokens-served total, the authoritative running total, and raiseCounterTo takes max. So a replaying event with C equals one and total equals X just sets displayed to max(C, X); it never adds. The seed cursor is now belt-and-suspenders. The real fix is the authoritative total with max reducer, which is robust regardless of replay from zero. This is exactly why the authoritative-total approach, not the seed-cursor-capture approach, was the right architecture. It's correct even with the keep-alive cursor-replay-from-zero behavior. My randomized test even covers seed cursor equals zero, replay from start. Let me verify: with the old code the user sees 15M versus 8M; with my fix, even replaying from zero, then events replay each carrying authoritative totals less than 8M, max keeps it 8M, correct. Pushing to origin/main."

Yeah, yeah, yeah, yeah. 8.9. Am I at 8.9? I'm not at 16. Nope. We'll stop saying that forever in a few seconds, hopefully. Then we will hopefully spin OpenCode in a new super-duper test and blow past 10 million for real. What's the status now? I think it's doing the whole pre-push check here. "OpenCode completed cleanly this time. It made the gym edits, committed them." That was OpenCode via Khala. Oh, yes. Let me see what it did exactly. "Called it Head-to-Head Gym (Jim). 'Gym' was a garbled transcription. Owner confirmed the intended term is 'gym.' Benchmarking gym. Big Pickle: origin still unconfirmed by the owner. Do not invent specifics." Okay. Okay, great, that worked.

Instruct it to continue one more time and tell it that "Big Pickle," with a space, is the main free model of OpenCode. So update any docs that mention it accordingly. And also rename that file name that has "gem" in it to "gym," commit and push, skipping the hooks, for deploying docs-only stuff. All right, so that will bump it. Where we're at right now, 8.9. Can you fix this thing, please? A minute and a half for the freaking... I don't know what the hell it's actually doing. Why can't I see the output? Sitting here like an idiot, staring at the number going up. This is the number that I want to see going up. 9047. "Push timed out." Cancel. Oh, fuck. I probably should not cancel. Let's skip the hooks. No. Skip the full check. Run only relevant stuff. Just push and deploy. Generally I shouldn't say that, but I'm going to do it right now. Interesting — hitting escape here took me out of this view instead of stopping it from doing a thing. 9.5, 9.6. Where are we at? "OpenCode has applied the core wording change."

Hey, OpenCode. OpenAgents would like to add you as a friend. All right? We are friends now. This is good. 9.8. Folks, we're about to cross the 10 million tokens number. "Small note: OpenCode's prior place left a slightly silly 'big pickle to big pickle' phrase. But it's continuing and should kill 9.9 million tokens served." 10 million! Ding, ding, ding, ding, ding. All right, we're at the eight figures, everybody. Never to go below. "OpenCode found and removed remaining once-confirmed language around the lane list. It still needs to fix the implementation/open-questions section and readme, then commit/push."

Did this finish? Thank God. Okay. "Deploy landed. Running the live monotonicity..." Okay, please refresh and then work. Okay, 11.2. No, I still see it. "Sometimes a sub-agent will do a push that doesn't have the latest changes. Rebased, so at least this should be working." Correct the "big pickle, the big pickle" — you gotta get your Big Pickle straight, people. Well, this is — yeah, I don't care. I don't care. Okay. OpenCode can do meaningful work for us. Good. Good. 12.3. "Let me diagnose fast: is the deployed client overcounting, or is your browser serving a stale cache bundle?" No. All our sub-agents are finishing. I can't believe it. 12 million tokens. 12 million tokens. We're just getting started, people. We're just getting started.

"Got the smoking gun. The fresh headless load, no browser cache, seeded at 20.9, while the scalar ledger is 11.1. So it's 2x double-counting on the deployed code, not your browser cache. Let me confirm whether the monotonic-fix build actually deployed what the snapshot carried." Yeah, what the... Why do I keep seeing this notification four times? You can't finish four times. I'm so excited to get away from these busted-ass harnesses onto our own things, so that we can control them. Or if you see a bug, we can just go in and fix it, not wait around. Maybe Anthropic will notice the screen flicker now, nine months after complaining about it. No more of that. Oh, hey, look, we are doing a two-hour video. Swooping. I don't want to add that stuff to Autopilot either. No cutesy. No cutesy verbs.

"Let me load. Double to 21M. Okay, redeploying now. The heavy lanes have finished, so it should complete this time. Okay, we just didn't have the new fixes." Good boy. "Okay, let me queue up the next entrants. The guard will block it if..." Okay, let's prepare to spin it hard. Now I want you to spin up eight OpenCode instances. No, no, no. Let's make that ten. I want half of them to review the docs that are already in the OpenCode folder, another five of them to spin off on other topics. And you can do the initial delegation to topics. Let me remember — this doc. Use that doc as the source material for, like, what topics to delegate beyond the five that are there. Okay, so you're going to spin up 10 OpenCode instances and task them all with adding or updating their document in that folder with themes relevant from this. Wait, that's not the right thing. That's not the right doc. Where's my inference doc? Let me get the right doc right here. Oh man, I got a lot of stuff in here. Here we go. I want each of them to make the files, but not commit or push. I want you to do all the committing and pushing, skipping the hooks. But I don't want 10 different commits and pushes. Just monitor it and tell me the status of them.

All right, so let's just make double sure, first of all, that the fix — that's the killer — "the deploy is hung on first launch smoke." Yeah, skip that smoke. Open a GitHub issue to diagnose, to debug that smoke separately. Almost there, almost there. What's the status of the deployment? "Apparently it's finished, SIGKILL, blah blah. The manual deploy completed; bypassing the Verse mode worked. Now the real test: fresh headless load, does it seed at the true total and stay monotonic?" No. Khala, save me from this, please. Khala, save me from this.

This is ready. My GLM RE— oh. Clarify if that faster path is now available for inference serving, like if we can connect that to Khala. "Apparently it's almost done thinking." Whatever happened to seeing the thinking tokens? I'd like to see what you're thinking. "Now I know exactly why the monotonic fix didn't actually fix it. The sync room has 210 old per-event delta records accumulated from all my earlier tests. The client replays and sums those deltas on top of the scalar seed to 2x. The previous fix added a summary total, but the client still adds the replayed historical deltas. It's a flawed fix, not a deploy-cache problem." Would Codex have made the same mistake here? "The decisive fix: one source of truth cannot double-count. Stop summing deltas entirely. The counter displays the authoritative ledger total. Seed from the scalar sum, and the server posts the new total — not a delta — on each completion, to a single collapsing key. The client just does displayed equals max(displayed, total). The legacy delta..." I'm doing this one myself, carefully, and I won't say it's fixed until the fresh headless load seeds the scalar with a zero. Background steps.

"Bigger problem found: it never actually deployed. The exit-zero was the wrapper; the real wrangler deploy stopped." What the fuck. Listen, why does it say "now I know exactly why," but then, like, it just never deployed, and now it just compacted. There — I refreshed, and there it did not bounce up. Let's see if I do that again. Is it good? 12.3, is it good? "Now the real deploy succeeded, so the new code is finally actually live. The snapshot still has only— no new completed— let me check." 12.307.173. 574. No shenanigans. Yeah, I think that did it.

It's like, if the sub-agent of Claude isn't able to tell about the correct status of the Wrangler deploy — like, is that Claude's fault or Wrangler's fault, or both? "The server side is now correct and live. There's a tokens-served summary record. Matches the scalar, and new events carry the authoritative total. It was doubling because this code had never actually deployed until now. Now let me verify the deployed client seeds at the true total and stays monotonic. Fresh headless load, no cache." Okay, we are — yeah, yeah, yeah, yeah. Okay, are you ready? All right, let's see what happens. We got 12,309, everybody. "I'll spin them up as OpenCode-Khala." Isn't that nice? OpenCode/Khala workers. "Against the same docs folder, with each instance assigned a distinct file to avoid stomping on each other. I'll keep them from committing/pushing. I'll do one docs-only commit and push after all 10 finish. I've got the delegation map now. Five workers will revise one existing docs/opencode memo each; five will create new focus docs from the GTM push themes. I'm explicitly telling each worker: edit only its assigned file. Do not commit. Do not push."

Let's see if we get 10 OpenCode instances, each running Khala, each updating our tokens-served counter. Let's go. Let's go. 12.3. "Running. Running." 12.309.654. "All 10 OpenCode instances are running now." Ooh — 12,313, 314, 315, 351, 363. Yes! Oh, it's updating so much faster now, too. Oh, yes. You know, it could be a little faster. It could be a little faster. Are you going to just — are you going to go above 13? What are you going to do? Are you going to stop there at 661? No, 680. Now we have some stress testing. Are we going to overwhelm this at some point? 12.8.

Okay, we can call that mission accomplished for this video. We have OpenCode running Khala — 10 instances of OpenCode running Khala. We just crossed 13 million tokens served. 12 of those were in this video, so I'm feeling good about our progress here. Next, we'll start benchmarking this against other models and agents and stuff. Probably we'll build the gym next to do some real benching. See you soon.