April Build Log: 368 Commits, 37 Posts, and the Month I Was Not Measuring Yet

Every build log after this one leads with a metrics table. This one cannot, and that is the honest story of April.

April 2026 was the first full month I ran VNX Orchestration as a daily production system. It was also the month I built the part that records what the system does. So when I sat down to write the numbers, I found the uncomfortable truth: for most of April, nothing was watching. The receipt ledger only started capturing real data in the last week. I can tell you exactly how much I shipped. I cannot honestly tell you the dispatch-level metrics, because they were not being logged yet.

So this is the origin build log. What I can count, what I cannot, and why that gap is the whole point of everything that came after.

What I can actually count

These come from git log and the content folder, not from a dashboard I wish I had run.

• 368 commits in the VNX repo in April. The engine was being rebuilt almost daily.
• 37 published posts, a mix of Dutch (MKB) and English (technical). April was the first month I committed to publishing every day.
• Three providers in rotation from day one: Codex, Claude, and Gemini, each running as a plain CLI subprocess. No vendor SDK in the codebase, even this early.
• Public baseline since 19 February 2026. April was month two. This was a young system moving fast, not a mature one coasting.

That is the honest headline. Not "10,000 dispatches." A lot of building, a lot of publishing, and an instrumentation layer that was still mostly on my whiteboard.

The number I cannot give you

Here is what the retained audit trail holds for April: 147 receipts, and 141 of them landed on a single day near the end of the month. All marked success, because failure logging was not wired up yet either.

That is not a month of production telemetry. That is the moment the recorder switched on.

I could have filled a table with those 147 receipts and a lot of confident-looking percentages. First-pass yield, cost per dispatch, weekly quality trends. It would have looked like data. It would have been a number with no month behind it. Publishing that is exactly the failure I would spend the next two months building guards against, so I am not going to start the series by committing it.

April did not have metrics. April is where I built the thing that produces them. By May the receipt ledger was recording thousands of dispatches a month, and by June the numbers were dense enough to catch my own systems lying to me. None of that exists without the unglamorous April work of deciding what a receipt should even contain.

What worked

Two things delivered value out of proportion to their size this month.

Context rotation. The single highest-ROI mechanism in the system. Left alone, an agent's quality degrades as its context window fills with stale conversation history and it loses the thread of the actual task. Rotation resets the agent with a fresh context while preserving the intelligence layer: the learned patterns, the confidence scores, the prevention rules all carry over. The agent forgets the conversation and keeps the lessons. I wrote up how it scales in context rotation at scale.

Quality gates as hard stops. Gates are not suggestions in my system. If a deliverable does not pass, it does not proceed. It gets flagged, logged, and queued for rework. Rework costs tokens, which feels expensive, until you compare it to the cost of publishing something broken under your own name. April is where I decided that gate verdicts are binding, not advisory. That decision is the spine of every build log since.

What failed

The build log is worth more for the failures than the wins, so here is April's.

The idle worker in the tmux-spawn lane. When I first ran a real task through the new ephemeral tmux-spawn lane, the governance logic worked but the worker just sat there. The instruction was pasted into the interactive prompt and never submitted, and the readiness check was still looking for an old "Welcome to Claude" banner that the newer Claude Code build no longer printed. The worker did nothing.

The dangerous part was not the stall. It was that the system synthesised a fallback receipt that looked successful until I checked the filesystem and found no work behind it. One stuck dispatch, twelve minutes lost, and a green status with nothing under it. If that sounds familiar from later build logs, it should. This was the first time I met the failure mode that would define the rest of the series: a system reporting success it had not earned. I found it exactly one way, by dogfooding my own default lane instead of trusting its status.

The lane migration ahead

One structural change was already visible in April. The June Anthropic billing change would move headless claude -p to paid API credits while interactive Claude Code stayed on subscription. So I started shifting the default worker lane from claude-subprocess to the ephemeral tmux-spawn lane. The subprocess lane stayed as the proven reference. The tmux lane was younger but had already earned its keep by surfacing the idle-worker bug. Lane choice, it turned out, would matter as much as model choice for cost.

The meta observation

There is something uncomfortable about publishing your production numbers every month. Every figure is a surface someone can criticise, and every failure is documented proof the system is imperfect.

I do it anyway, because the alternative is worse. The AI industry runs on vibes. "Our agents are amazing." "AI is transforming everything." No numbers, no failure modes, no cost data, just promises wrapped in demo videos. I built VNX to be the opposite of that: open source, real data, failures documented next to the wins.

Which is why I will not fake April's. The honest version of this month is that I had not built the measurement yet. That admission is worth more than a polished table, because it is the reason the tables in May and June are real. You cannot publish honest numbers until you have built the thing that refuses to lie about them. That is what April was for. The receipts I now treat as the database started here, thin and late, but started.

What is next

For May, three concrete things:

• Get the receipt ledger recording every dispatch, so the next build log leads with real telemetry instead of an apology.
• Wire up failure logging, because a month where everything is marked success is a month you were not looking hard enough.
• Keep the daily publishing cadence, but measure whether quality holds across a full month instead of assuming it.

April was the origin. It shipped a lot and measured almost nothing, and being honest about that split is the only reason the rest of this series means anything. If you want the architecture underneath it, the VNX repo is open source, and my AI architecture work is where I build this kind of system for organisations that need the receipts, not the vibes.

Solo build, public feedback loop. See you in the May build log.

Sources

• VNX Orchestration, open source: github.com/Vinix24/vnx-orchestration. Commit counts are reproducible from the repo.
• April receipt count (147, concentrated in the final week) and post count (37 published) queried from my own audit-trail ledger and content folder.