Alera’s library factory, run from a board: thirteen more libraries to 1.0

Abstract

This report follows Alera’s library factory, continued, which ended on 27 October 2026 at 10:10 US Central. From then until 6 November at 20:37 the same factory of specialist agents, shared process and fixed architecture took thirteen more libraries to 1.0. Each one is public on GitHub and published on NuGet:

• oneecma-csharp, an ECMAScript interpreter built around its error reports, and onerender-csharp, an HTML and CSS layout and rendering engine, both on 27 October;
• onemath-csharp, deterministic math, and onepath-csharp, pathfinding and navigation, on 28 October;
• oneocr-csharp, local OCR, which was still running when the last report closed; onearchive-csharp, compression and archives; and onemodel-csharp, a neural-network runtime, all on 31 October;
• onemedia-csharp, media containers and metadata, and onelite-csharp, a SQLite-compatible database, on 3 November;
• onemail-csharp, email, and onediff-csharp, diff and document comparison, on 5 November;
• onellm-csharp, LLM inference and an agent runtime, and onedocument-csharp, Word, Excel and PowerPoint documents, built as OneOffice and renamed the day before, on 6 November.

Three more stopped at previews: onecrypto-csharp, oneindex-csharp and onephysics-csharp. The libraries released before the window shipped 43 more releases in it; onegame went from 1.5.1 to 1.15.2 and onepdf-csharp from 1.11.1 to 1.19.0.

From the first build agent to the 1.0 tag took between 14 h 50 min (onellm-csharp) and 7 d 16 h 33 min (oneocr-csharp). Claude Sonnet 5.5 ran the engineers and Claude Opus 5.5 the orchestrators, planners and project managers.

Owner attention is counted with the previous report’s four codes, and only steering counts. In the open-source work Kurtis sent 138 messages and board answers, 54 of them steering. Each library started on 30 October took between 2 and 8 messages from him before its 1.0 or preview, plus 14 messages that planned the batch as a whole.

The main findings:

1. Once a library was planned, it needed little steering. Each library of the 30 October batch took 2 to 6 steering messages before its 1.0 or preview, ship decisions included. The libraries planned on 26 October took 1 to 4 in the window, after 7 to 14 in planning (section 3).
2. The owner ran the factory by its settings more than by its builds. He set the build-slot cap at four just before the window and changed it three times in it, each time with a short message: to two, back to four, and to two again. On 4 November the factory moved onto a projects board, and from then on most of his open-source input came through the board. He answered the median board question in 38 minutes, and 13 of the 21 he answered took a single tap on an action the agents had proposed (sections 2 and 3).
3. Several of his steering messages checked the agents’ claims. They included a “needs the owner” block that an agent then cleared itself in about a minute, a purchase that turned out not to be needed, a “done” feature that failed on his phone, and a published page he rejected, which started a rewrite of the site’s cookbook (section 3).
4. Every 1.0 faced outside checks, unevenly. Twelve of the thirteen have an outside test suite or corpus with measured results, and eleven publish a full list of losses. Fuzzing is the thinnest check: seven record fuzz campaigns (section 4).

---

1. The problem, and what this report counts

The first two reports showed the factory taking one library, then several at once, from an idea to 1.0. This window asked whether it could keep a portfolio moving: more libraries than the owner could follow one by one, under a limit on how many build at once, with the owner deciding what goes next and when a library ships.

Scope. The counts cover the open-source library work and work on Alera itself, the platform the factory runs on. They leave out client work, personal and own-business projects, the layer of agents that runs those, and a private product that sits in the same project tree. Two libraries still being built in private at the cutoff are counted in the hourly activity and shown as a combined line in the costs, but not named. The board figures in section 3.3 and the site work in sections 2.5 and 3.4 also include the website’s projects, where the libraries’ pages are published; messages to those projects are not in the steering counts. Kurtis approved this scope with the report.

Models. Claude Sonnet 5.5 and Claude Opus 5.5 did the build work and are the two models in the report’s header. Two other groups appear in the record and are named where they occur: four small models in an evaluation of oneecma-csharp before the window (section 6.1), and two GPT models used by the managers’ helper agents for 52 calls.

Times are US Central: CDT until 1 November, CST after. 1.0 is the v1.0.0 git tag, as in the earlier reports. Each tag was on NuGet 2 to 7 minutes later, and oneocr-csharp’s 20 minutes later.

2. How the work was organised

2.1 Build slots

A project manager agent ran the builds from a queue with a fixed number of build slots. Each build had its own orchestrator and engineers, and released libraries kept getting maintenance runs outside the slots. Kurtis set the number of slots:

The manager kept the queue in a file and wrote each change into it. On 29 October Kurtis also asked whether the queue on the shared build machine could run itself, so that agents wouldn’t have to approve each next job. A mechanical job queue with priorities was committed about nine minutes later and made mandatory for heavy jobs.

2.2 The board

On 4 November the factory moved onto a projects board that the agents and Kurtis share. Before that, agents reached him through chat alerts; the build managers sent 68 between 27 October and 3 November. He asked for the move at 09:47. By 09:57 the library projects were on the board, a fresh build manager was running them, and ten open questions for him were posted as board items, eight of them first raised in chat alerts. After that the build managers sent no chat alerts.

An item carries a question, actions he can tap, and a priority that decides whether his phone buzzes. From 5 November a standing rule required a board status for every start and end of work. The open-source projects posted 58 statuses on 4 November (from 09:53), 149 on 5 November and 80 on 6 November.

2.3 What the board keeps

By the board’s own rules and records:

• Originals can’t be changed. Status updates, items, his answers, item chat, his feedback and inbox messages are stored as written and can’t be edited. A wrong item is closed or superseded. Only Kurtis can retract an answer, and he retracted none. Corrections are added beside the original: one agent corrected a word in its own release notice in the item’s chat three seconds after posting it.
• Decisions are copies, with a pointer to the original. His answers and feedback are recorded as owner decisions automatically. A decision he makes in chat or in a planning session is recorded by a manager, in his words, with a reference to where he said it. By the cutoff the projects in this report held 53 decisions: 30 from item answers, 3 from feedback, 7 from chat, 6 from planning and 7 others. His own session recorded 33 of them and agents recorded 20.
• Verbatim isn’t always self-explaining. Four decisions are an “OK” on a done notice, and two are single letters answering a planner’s lettered options, readable only beside the planner’s question. The six planning decisions from one session were recorded about ten hours after he made them, by the next manager.
• Delivery. His answer reaches the agent that posted the item as a direct message, with his text and the actions he chose. The build managers received 19 of these in the window, and 11 board pointers.
• Monitors. Each project with an owner has a baseline monitor on the project and everything below it, for blocks, items opened, answered or retracted, slipped milestones, new child projects and closure. It moves with the owner role. The projects in this report had 25, all baseline (5 Alera, 18 open-source, 2 website); no agent added one of its own. The managers’ supervision ran on agent monitors instead: in the window the build managers received 207 runtime alerts (105 for a finished run, 91 timers and 11 context thresholds), against 771 messages from other agents. Those monitors switch off when they fire, and every handoff note tells the next manager to re-arm them.
• Inbox. The board’s inbox holds mail and chat triage for work outside this report. The library factory has no inbound mail and didn’t use it.
• Thoughts are his own notes on the board, typed or dictated. Unlike the records above, agents may edit, split, merge or delete them when he asks. An entry keeps only its current text, and an undo log keeps snapshots.

2.4 Manager handoffs

A build manager hands its job to a fresh copy of itself, through a written handoff note, when its context reaches 400k tokens. Fifteen build-manager instances held the job in the window, in 14 handovers. The median handover came every 16.6 hours, with a range of 6.8 to 30.2. The handoff note grew from 269 to 1,133 committed lines.

2.5 From release to site

Each release went on to recursiveai.org. Eleven of the thirteen new 1.0s had their site page committed between 22 minutes and 1 hour 12 minutes after the tag. From 5 November a publishing queue with four priorities and a daily allowance of 75 pages ran the site work, release updates included.

3. What the human did

3.1 How it is counted

Where candidates were located. Owner acts were looked for in every agent conversation in scope and in four board records: item answers, his messages in item chat, his feedback on status updates, and his Thoughts, typed or dictated.

Counted once, at the original. Each act is counted once, where he first wrote it. The following are not counted:

• decision rows, which copy an answer, feedback or chat message and were matched to it by reference and by text;
• the board’s deliveries of his answers, feedback and Thoughts into agent conversations;
• anything an agent relayed, briefed or answered on his behalf;
• test identities and probes.

A chat message he edited and resent counts once; 15 such pairs were found. A dictated Thought is one entry, its transcript the text. He dictated four in the window: two were microphone tests and two were on an idea outside this report, so none is counted. Thoughts are read as their current text.

Coded with the previous report’s four codes: steering (a direction, a scope change, a fix, a decision, a design answer), check-in (status, “proceed”), question (exploration that doesn’t direct a build; every idea session counts here) and setup (devices, accounts, credentials). Only steering is the headline measure. One reader coded every act, as before.

Where the open-source messages went:

The Alera messages went to the board itself and its phone app (39, 32 steering) and to the agent runtime (8, 7 steering).

3.2 Per library

Each row runs from Kurtis’s first message in the conversation that started the build, the earlier reports’ rule, to the 1.0 tag or the latest preview. The build column runs from the first build orchestrator to the same tag.

Notes on the table:

• The rows don’t add up, and aren’t meant to. A message that steered several libraries is counted in each of their rows, and once in the totals above.
• ¹ One planning session, on 26 October, planned four libraries. Its 12 messages, 9 of them steering, are the same 12 in each of the four rows. They come from the previous report’s coding and were not re-coded.
• ² One instruction started ten libraries. At 15:25 on 30 October, in a manager conversation that had opened at 14:38, Kurtis asked for one planner per library, with the manager answering the planners’ questions for him. Eight of those libraries are in this table; the other two are still in private development. Each row includes that instruction. The other 14 messages that planned the batch as a whole are counted once, as their own line in section 3.1, and in no row.
• For the 30 October batch, “first message → 1.0” is mostly waiting for a slot. The build column is the better measure of build time.
• onemodel-csharp has no owner kickoff to start from. By its planning record it was planned on 29 October with a manager answering for him. His first message about it came after its build began, so no first-message duration is given.
• onelite-csharp’s public history was squashed to one commit, so its build time is taken from its first build agent, not from a first commit.

3.3 The board as his channel

From the first board record on 4 November to the cutoff, Kurtis sent the open-source work 38 inputs, 22 of them steering. 24 of the 38 (16 steering) came through the board, not chat. Board items in the open-source, Alera and website projects in that time:

Each of the four 1.0s after the move followed a “ship” tap: onemail-csharp after 7 seconds, onediff-csharp after 33 minutes, onellm-csharp after 3.2 hours overnight and onedocument-csharp after 11 minutes. Four questions were still open at the cutoff, and each said nothing was waiting on it.

3.4 Checking the agents’ claims

Several of his steering messages checked a claim rather than directed code:

• A block that wasn’t one. A planner handed him numbered steps to grant search-console access. He asked whether it couldn’t do that itself. It found a way and had done it 64 seconds later.
• A purchase that wasn’t needed. An item asked him to buy an office-suite seat for test files. He suggested an existing laptop, and the agent confirmed within a minute that it had everything.
• A “done” that failed on the device. A voice-notes feature in the board’s phone app had passed on desktop and failed on his phone’s microphone. A fixed build came seven minutes after his report.
• A page he rejected. An agent judged one of the site’s cookbook recipes partly fit for a reader arriving from search; he judged it not fit at all. That started a rework: a writing team, a page spec and the publishing queue. The rewritten recipe was approved the same evening, and 50 cookbook pages were rewritten to the new spec by the cutoff, with 303 more queued.
• Checks that crept back in. Asked to publish two early previews, he questioned the slow progress. By the manager’s count, about 30 queued verification jobs were stage-level checks that his earlier rule had moved to release time; the rule had never reached the build plans. The manager moved it into the files the builders read, and by its count the queue fell to 5 jobs.
• An estimate. A manager put one library at four to six days by comparison with a much larger one. He questioned the comparison, the manager agreed it was wrong, and the library reached 1.0 the same day.

The interpretation, kept apart: in these cases the input that changed the outcome was a judgment about a claim, whether something was really blocked, done or needed, rather than direction on the code. The board made those calls quick to give; it didn’t make the agents need fewer of them. This is a reading of a few examples, not a measured share of his messages.

3.5 Compared with the previous report

The previous report counted 241 messages and 97 steering messages to the open-source work in about four days. This window counts 138 and 54 in ten and a half, on the same codes. The codes and the rule for which conversations count are the same. This count adds the board’s channels, which didn’t exist before 4 November, and leaves out the private product. Messages to libraries after their 1.0, old and new, numbered 9 in the window, none of them steering, while the earlier libraries shipped 43 releases.

4. Verification: the outside checks

As in the earlier reports, each library is held to four kinds of outside check: tests or a corpus it didn’t write, a comparison with the library people use now, fuzzing, and a published list of losses. The table is read from each repository at its v1.0.0 tag. These are the library agents’ own measurements; nothing was re-run for this report.

Ratios are time against the incumbent, so below 1× is faster, except onearchive-csharp’s, which are speed. Where to look closer:

• Fuzzing is the thinnest check. Seven of the thirteen record fuzz campaigns. Five have fuzz targets with no campaign record: oneecma-csharp, onepath-csharp, oneocr-csharp, onearchive-csharp and onemodel-csharp. onemath-csharp has none.
• oneocr-csharp’s outside tests are switched off in CI; its sealed benchmark is the outside check that counts.
• Raw benchmark output is mostly not committed. Each repository has its tables and method, but mostly not the logs.
• Some READMEs at the tag quote the better figure. onerender-csharp’s README gives the template geometry, not the real-page figure. onediff-csharp’s gives its worst speed row as 1.03×, against 1.13× on its results page. onemedia-csharp’s and onellm-csharp’s carry wording from before 1.0.

The three previews have outside checks too. onecrypto-csharp, for example, runs Wycheproof, x509-limbo and PKITS, and is compared with BouncyCastle.

5. What went wrong

• oneocr-csharp shipped with its own gate failing. On its sealed test set it was best in 5 of 10 categories and behind PaddleOCR, Apple Vision or Tesseract on character error in the other five, including receipt photos and clean digital PDFs. Kurtis chose to ship it as good enough after more than a week.
• onearchive-csharp shipped below its own Zstandard bar on x64, with his go-ahead.
• A slot was handed out twice. From 30 October 18:21 to 1 November 17:02, the manager gave the finishing oneocr-csharp’s slot to two new builds, so five ran under a cap of four for about 45 active hours, while the queue file’s heading still said four. Kurtis then cut the cap to two, to save tokens.
• 11.5 hours with nothing building. From 22:35 on 3 November to 10:06 on 4 November no library agent made a model call. Both slots were free, and Kurtis had already said which paused build resumes first. The manager asked him anyway and stopped. His answer the next morning became a standing rule, never leave a slot idle waiting on him, and the builds restarted 32 seconds after it. No idle gap of that kind recurred.
• Push to his phone was down for about 3.6 hours on the day of the move to the board. Restoring it took a three-step consent from him.
• A planner waited 9 h 40 min on a single question that didn’t reach the board. The website manager posted statuses saying the work was waiting on him, without the open item the board’s rules require. Once the question was posted as an item, he answered it in 62 seconds.
• Two libraries had no site page for about two days. onemath-csharp and onepath-csharp waited until a manager noticed the gap while routing another library’s page.
• Two manager handoffs overshot, to 750k and 814k tokens of context, when a single step pushed them past the 400k mark.
• A manager widened his words. Kurtis asked managers to discuss his questions rather than act on them at once. The handoff note recorded it more broadly, as acting only on instructions, hours before the idle night.
• onecrypto-csharp is labelled as waiting on him for cloud accounts in the queue. Its own plan says the rest of its 1.0 needs no accounts and that the manager chose to pause it.
• onellm-csharp’s provider fixtures are described as recorded, but were written from documentation.

6. Results

6.1 Agent runs and metered-equivalent usage

Each library is counted from the first planning message to its 1.0 tag or latest preview, with model calls cut at the tag and every sub-agent included, the previous report’s basis. The build models ran through subscription channels. The separately listed small-model evaluation mixed subscription and metered calls; its recorded metered charges were $0.91. Every dollar amount in the tables is metered-equivalent usage: what the same tokens would cost at the providers’ list prices. It is a comparison figure, not money spent.

• ¹ oneecma-csharp’s evaluation. In the early hours of 27 October, before the window, 981 short agent runs compared small models fixing scripts with its error reports and with Jint’s. They ran on Claude Haiku 5.5, Gemini 3.5 Flash-Lite, Gemini 2.5 Flash-Lite and GPT-4.1 nano. They are product evaluation, not build work, and are shown on their own line. Its $1.42 is metered-equivalent usage; the $0.91 actually charged, all on Gemini 3.5 Flash-Lite, is a separate, recorded figure.
• ² onepath-csharp and onemath-csharp were built in one orchestrator run, so they share a row that ends at the onepath-csharp tag.
• ³ onemodel-csharp is counted from its first build agent. Its planning took place inside a conversation outside this report’s scope, so its planning usage isn’t included.
• Usage before the window. $2,326.86 of the sixteen libraries’ metered-equivalent usage came from model calls made before 27 October, 10:10, by oneocr-csharp, onerender-csharp, oneecma-csharp and onearchive-csharp. $11,377.46 came from calls inside the window. oneocr-csharp’s part before the window, $1,224.08, contains the previous report’s figure for it ($1,220.62 on that report’s runs, published as about $1,220); the small difference is planning sub-agents that this report counts and the previous one didn’t.
• Tokens, all sixteen: 879.4 million input, 176.3 million output, 1,923.4 million written to cache and 31,098.5 million read from cache.
• Models. Of the 159,527 calls, 137,004 ran on Claude Sonnet 5.5 and 19,005 on Claude Opus 5.5. The other 3,518 are the oneecma-csharp evaluation.

What the library figures leave out, all inside the window:

The managers served every library, new and old, in the same conversations, so their usage can’t be split per library. They ran on Claude Opus 5.5; two of their helper agents, a browser assistant and a web searcher, used GPT-6.1 Sol and GPT-5.6 Sol for 52 calls. Website work that the managers launched, $1,437.06, is outside this report’s scope.

6.2 Projects building at once

This is the previous report’s measure: the number of library projects whose agents made at least one model call in a clock hour. It counts released libraries’ maintenance and the two private builds, so it runs higher than the slot cap.

1 November has 25 clock hours: the hour from 01:00 happened twice when daylight saving ended, and both are kept, with 7 projects each. The median is 4 whether the empty hours are counted or not. The peak of 13 came at 14:00 on 29 October, mostly maintenance on released libraries; the previous report’s peak on the same measure was 9. The empty hours of 3 and 4 November are the idle night in section 5.

6.3 After 1.0

The libraries released before the window shipped 43 releases in it:

6.4 Names, versions and the previews

• onedocument-csharp was built as OneOffice. On 5 November a board item asked whether to rename it to avoid a trademark conflict. Kurtis tapped the recommended rename at 07:34, and the rename of namespaces, package IDs, tool and docs was committed at 08:05. No package was ever published under the old name, and the old repository name redirects. 1.0.0 followed on 6 November.
• onellm-csharp 1.0.1 came 9 h 19 min after 1.0.0, on 6 November. It fixed a spending cap that was read only once and host hooks that didn’t fire on every kind of run, and its README now says which providers ran live at 1.0.
• onecrypto-csharp shipped six previews, 0.1.0-preview.1 on 31 October to 0.4.0-preview.2 on 5 November, all on NuGet. Its build was paused on 2 November after 0.4.0-preview.1. By the manager’s notes, 0.4.0-preview.2 came from a maintenance run outside the slots. The queue lists it as waiting on Kurtis for cloud accounts, which its key-management adapters need. Its own plan says 1.0 itself needs no accounts and that the manager chose to pause it. The accounts question was still open at the cutoff.
• oneindex-csharp published 0.4.0-preview.1 and 0.4.0-preview.2 on 3 November and was then parked. Its first public preview followed Kurtis’s go-ahead, given after he questioned an agent’s trademark caution about the name and kept it.
• onephysics-csharp stopped at 0.4.0-preview.1 on 30 October. By the manager’s record, Kurtis judged it good enough to move on, with some 3D speed targets missed.

7. Recommendations

1. Write the owner’s standing answers where the manager reads them, and treat a question they already answer as a fault. The idle night came from asking what the queue already said.
2. Every question for the owner is a board item. “Waiting on him” without an open item is invisible to him; the one question that stayed in chat cost a planner most of a day.
3. Check a “needs the owner” claim before it reaches him, in planners as well as managers. A numbered checklist for him is a sign the agent hasn’t looked.
4. Put the owner’s process rules into the plans the builders follow, not only into a manager’s notes, or they drift back.
5. Count active builds from what’s running, not from a heading.
6. Make the site page part of the release, so a 1.0 can’t go two days without one.
7. Record a fuzz campaign for every library before 1.0, and quote the harder figure in the README when there are two.

Links

• The previous reports: Alera’s library factory, continued: parallel runs and a game engine · Alera builds a library factory: from 112 owner messages to 11
• All libraries: recursiveai.org/libraries
• Repositories:
  • oneecma-csharp
  • onerender-csharp
  • onemath-csharp
  • onepath-csharp
  • oneocr-csharp
  • onearchive-csharp
  • onemodel-csharp
  • onemedia-csharp
  • onelite-csharp
  • onemail-csharp
  • onediff-csharp
  • onellm-csharp
  • onedocument-csharp
• Devlog: recursiveai.org/devlog

Limits of this report

• Scope (section 1): It leaves out client, personal and own-business work, the agents that run it, and a private product. So the owner counts are not his whole working day, and the usage figures are not the cost of running everything.
• Website messages aren’t counted. The site pipeline and the cookbook rework are described (sections 2.5 and 3.4), but his messages to the website’s agents are outside the steering counts.
• Owner acts are the candidates located by the method in section 3.1, not a guaranteed complete set. Coding is one reader’s judgment.
• The sender gap. Messages before 28 October, 16:25, carry no sender stamp. For that day and a half his messages were told apart from agents’ by a text filter and then by reading; 41 of the counted acts come from this period. On later, stamped messages the same filter missed 1 owner message in 101, so a few may be missing here too. Edits he made to messages before the stamps can’t be seen.
• Thoughts are counted as their current text.
• The board exists only from 4 November, so earlier questions for him went through chat alerts and aren’t comparable with the board figures.
• Durations from a first message include waiting for a build slot. The 30 October batch waited days.
• Metered-equivalent usage prices every model call at list prices; it is not a bill or money spent. The only recorded charges in the library figures are the evaluation’s $0.91. Shared managers are left out of the library figures. Links between parent and child runs before 29 October rest on one field of the run records.
• “Building at once” means a model call in that hour. Long builds and benchmarks that make no calls are missed, and light manager traffic counts.
• Outside checks are the agents’ own measurements at each tag and were not re-run.
• Some figures are the agents’ own account: the count of queued verification jobs, and the reasons agents gave for decisions.
• Two libraries in private development are in the hourly counts and one usage line, and are not otherwise described.