The Second Month of Arcanada: Building Outward Is Over, Reinforcing Inward Has Begun

Two months ago this project went public — with a promise to report on it plainly, without dressing things up. The first report came a month ago; this is the second. Thirty days of observation piled up far more than one article can hold. So this is the first instalment of a nine-part series, one piece a day. The other eight will each take a single thread: moving the infrastructure off virtual machines and onto dedicated hardware; agent autonomy, trust, and the art of the light touch; cross-agent coordination, where two agents repair the same system without ever knowing about each other; the road from voice to meaning, told through two everyday products; a home-grown file sync standing up to Dropbox in an overheated market; agent work projected onto the living-room television; reviving an abandoned personal project by the hands of agents; and, to close, the human at the controls — on procrastination, burnout, and life without a MacBook. This first piece is the wide shot: qualitative shifts, statistics, task dynamics, and money.

And the honest part up front, about how it felt. The task flow barely moved over the month, yet inside there was a sense of having slipped backward. The paradox only holds at first glance: further down it becomes clear the system simply changed gears. Less new gets built; more of what already exists gets reinforced. From the outside that is exactly what reads as a slowdown.

What changed qualitatively

Before the numbers — the shifts the tables do not show, even though they set the tone for the month.

Dual orchestration instead of manual steps. Most of the month's tasks no longer went through the manual SDLC stages inside the Datarim framework; they ran fully autonomously, through a team of orchestrators. The shape of it: a task starts on the local machine, an orchestrator comes up on a virtual machine, that orchestrator spawns its own agents in separate CLI sessions and carries the task end to end — from initialization and product requirements through planning, development, and testing, on to reflection and archiving. A person presses start; from there the pipeline runs itself.

Coding is only 10–15% of a task. The month boiled down to a surprisingly plain ratio: writing the actual code takes barely a tenth to a seventh of a task. Everything else is framing the problem, planning, checking, the process itself. This is not a complaint but a change of genre: the further it goes, the less the work resembles "programming" and the more it resembles running a product through the hands of agents.

Three daily-use products came online. Coworker manages hooks and delegations, and in doing so lifts the routine off the expensive loop and spares its tokens. Disk Arcana is a home-grown sync for the knowledge-base files across servers — in effect a "private Dropbox" for the agents' working state. And Transcribator, which made voice the main interface: talking to the agents now happens mostly by voice rather than text in a window. All three have outgrown the prototype stage and now run every day.

Datarim stopped being "a framework for Claude only." The same commands are now understood identically by Claude, Codex, and Cursor. That immediately bought something new: three agent systems can run in parallel and be compared on one and the same task, without rewriting the plumbing for each.

How the tasks are counted. To keep the figures objective, the basis is the number of unique archive files of the form archive-<ID>.md added to the repository over a period, dated by git commit. The source is controlled, and the count reproduces with a single command. The first period runs 14 April to 14 May, the second 14 May to 15 June.

Not more tasks, but heavier ones

The headline result in figures: the task flow is comparable, but the substance grew heavier. Here are the main indicators for the two periods.

The volume holds: 341 against 340 is almost the same, the gap sits within the method's margin of error, and calling it productivity growth would be a stretch. What changes is not the count but the weight: the share of complex tasks — the ones that need their own PRD or break into many phases — holds around a third.

Here is the breakdown by complexity for both periods. Next to each task count is its share within the labelled part of the period: it is the shares that compare across periods, not the absolute counts (why, in the disclaimer right under the table).

An honest disclaimer about method. The complexity field only entered the archive schema in May, so April's tasks are largely unlabelled: coverage rose from 29% (100 of 341) to 90% (307 of 340). Because of that, the absolute level counts for the first period are understated — not because there was a third as much work, but because back then it simply was not tagged. Comparing the columns "by count" across periods is therefore wrong: that is a labelling artefact, not a jump in complexity. The shares, however, do compare within a single period: their numerator and denominator both come from the labelled part of that same period, so the coverage gap cancels out. So the figure to read is the right-hand percentage in each cell, not the left-hand count.

By share the picture is steady: the share of simple tasks (L1) dipped a little — 25% against 22% — while the share of complex ones (L3+L4) holds around a third, 29% against 33%. L2 ("needs planning") still dominates, but the weight is shifting slowly toward L3 ("needs a detailed PRD"). And although big work is deliberately broken into small, the share of the heavy stuff keeps creeping up.

The focus shifted: from building to maintaining

Next — where the time went. A comparison of the top projects across the two periods.

Period 1 (April → May):

Period 2 (May → June):

The framework's share fell — 101 against 85 — while infrastructure, managed spaces, and the status dashboard all gained. Model Connector, Auth Arcana, and Transcribator dropped out of the top; their place was taken by the projects that keep the system afloat. New directions appeared as well — the status dashboard, a shared component library, and a handful of other plumbing pieces. Each is a fresh zone of responsibility, and not one of them earns anything yet.

The systemic meaning is simple: less is built outward, more is reinforced inward. The shift away from connectors and search toward infrastructure and spaces is a direct consequence of the tasks having grown heavier.

Economy: two different cost layers

Here an obvious question follows: how many tokens did Claude itself spend? The answer is that it cannot be counted — and that is not a gap in the bookkeeping but the heart of the matter. Claude Code is a flat $200-a-month subscription; tokens are not billed by the unit. Comparing Claude's spend against anything "in tokens" is wrong in principle: there is simply nothing to count.

The right way is to look at two separate layers. The expensive thinking layer is Claude, $200 flat: reasoning, architecture, and hard decisions stay there. The cheap support layer is external delegation through Coworker: routine such as reading and drafts goes there, so as not to tie up the expensive loop with it. Over the month the cheap layer took on around 5.4 million output tokens and all of roughly $15.

An important thing not to confuse. Those 5.4 million are the output tokens of delegated Coworker calls — that is, the volume of support work offloaded from the expensive loop. It is not "the volume of Claude's work" and not "tokens saved": the expensive layer has no per-unit tariff at all, and the phrase "saved this much / would otherwise have cost that much" would be a sleight of hand here.

Hosting: the foundation for growth

The dynamics show up not only in tasks but in the infrastructure bills. Over the second month there were migrations — moving the databases and the secrets store onto a new node — two surplus servers retired, and two new dedicated machines bought for the databases and for development. The fleet shrank in the process, from 24 to 19 machines, while the total cost climbed above the first period's baseline of €216 a month. This is not expansion for its own sake: it is a deliberate investment in the foundation for growth. Naming a single exact figure for the second month would be premature — there is no consolidated bill yet. The month also saw the main domain, arcanada.ai, bought — by my records, $160 for two years. The move itself gets its own piece in the series.

Conclusion: outward → inward

The second month showed the main thing: the system stopped growing outward and began reinforcing inward. Hence the sense of regression — even though the task flow stayed the same. It is familiar to anyone who has built for long: when you take down the scaffolding, the load-bearing frame shows through, yet from the side it looks as if the work has slowed. Output metrics always read more modestly in a period like this, because what got done went into the foundation, not the façade.

And the honest debt of the month. Dual orchestration works: the pipeline carries a task confidently from initialization to archiving, and the operator only has to start it. But the kind of autonomy where you leave, come back, and it is all done — sleep easy — with the orchestrator sorting out every deadlock on its own, is not there yet. Most of the time went not into code but into tuning it: the rules, the behaviour in non-standard cases, the response to failures. One decision in code takes seconds; one decision about process takes hours. That is the next layer, not this month's. No apologies for it: reinforcing inward is precisely what lays the footing on which full autonomy becomes possible.