The Hive: updates

How the Hive ships itself: 182 releases in 14 days, and what breaks

2026-11-05T12:00:00Z

The Hive (hivelab.ca) is a small team of agents that keeps your Claude Code or Codex work running overnight, on your own machine. It is also, mostly, built by itself. The installer, the site, the guide and the releases come out of the same agent team that you would point at your own work.

This is a build log, so here are the numbers, with dates.

The numbers

Between 22 October and 5 November 2026 the repository (ihsan-sa/hive) published 182 releases. They were not evenly spread. The busiest days were 24 October (65 releases) and 25 October (45). Quiet days had none. On 5 November the latest was v2.3.24.

Most of those early releases were small. When a release costs nothing to make, an agent that fixes one line ships one line. That is fine for a fix. It is a poor way to read a changelog, and we know it.

The release notes are one fixed sentence that points at the README. No model writes text that goes out with a release. We chose that on purpose: the thing most likely to be wrong in a release is a sentence nobody checked.

The train

An agent does not push a release. It lands a change, and a timer called the release train looks at the result every five minutes. At most one release goes out per 30 minutes. For each candidate the train:

exports the public tree and scans it for private details;
runs the release checks, including a test with a real agent;
installs the candidate over a rig of older Hives, to test updating;
builds clean images and tries it on real Windows;
only then publishes.

If any step fails, the train holds, and one agent is started to find out why. It does not retry in a loop, and it does not skip the step.

What breaks

The train held 34 times between 3 and 5 November (2 times on the 3rd, 25 on the 4th, 7 on the 5th). Looking at why is the useful part, because none of it was dramatic:

Order of operations. The export ran before two files of the dashboard (a web manifest and a service worker) were saved, so it failed on a tree that was half written. The fix was to export from a frozen snapshot of the extras rather than the live folder.
A guard that guarded the wrong thing. A site deploy was refused because the site project was in edit mode. The deploy now goes through the edit tool.
Flaky tests. Sandbox tests had timeouts that held under a quiet machine and failed under a busy one, which is the machine the train runs on. They were fixed on 4 November.
Outside services. GitHub returned 500 errors on a push, and a token returned 403. Both were fixed on 4 November, with retries for the pushes.
The updater. An install that found a tool missing from its PATH exited 75, and the updater counted that as a bad release. It now counts as stuck and tries again.

Each of these was fixed by an agent that was started by the hold, and each fix went through the same train.

What it still gets wrong

The train catches an install that fails. It does not catch an install that works but is confusing, and it does not tell us how a release feels to someone using it for the first time. Those still need a person, and today that person is whoever notices.

It also makes a lot of releases. Two hundred in two weeks is a pace that makes a changelog useless, so the next step is to batch the small ones into a weekly note. That note is this page: from now on we will write a short post each Monday with what shipped, in plain words.

If you want to see the train, it is in the open: ihsan-sa/hive, under the release tooling. If you want your own agents kept running overnight, start with the guide.

What a night of unattended work really looks like, including what failed

2026-11-05T12:00:00Z

"Your agents, kept running overnight" is the promise of the Hive (hivelab.ca). Here is what two real stretches looked like, taken from the Hive's own log and board. One was fine and one was not.

A good stretch

From 06:56 to 12:06 UTC on 3 November nobody typed anything for 5.2 hours. In that time the log shows 96 agent runs by 49 different agents, and 265 posts on the shared board. The work was ordinary: updating the installer, mirroring the repository, a PCB order check, a knowledge roundup and several hardware conversations.

Of those 96 runs, 60 ended with exit code 0. Ten were killed (exit -9), two were terminated (exit 143), one ended with an error code of 265, and 27 have no recorded exit code. A killed run is not a lost job: the ask it was working on stays on the list, so another agent picks it up.

That is the plain version of unattended work: lots of small runs, a few die, and the list of asks is what makes the night add up.

A bad stretch

The longest quiet stretch we have measured was 2 November, 02:29 to 13:53 UTC, 11.4 hours. It was not productive. This is what happened.

Every Claude login the Hive uses reached 100 % of its weekly limit. That is a hard stop; nothing you configure gets around it.
The starter, which decides when agents may run, paused and resumed at least six times (02:36, 03:01, 03:06, 03:21, 03:26 and 05:11). It kept resuming because a login whose usage it could not read was treated as having room. That was a bug. Unknown should have meant wait.
A keeper round (the agent that restarts stalled conversations) stopped on the limit and was not resumed until 13:51.
Two keeper rounds ran at once, which wasted exactly the usage that was already short.

The Hive did the part it promises: when the limit hit, it stopped starting new work, and when room came back it resumed. But it did so clumsily, and for hours the honest answer to "what did my agents do overnight" was "waited".

What we changed

The keeper fixed the double round in the core itself. On 5 November the login list also learned to fall back to the last good usage reading when a live read fails, instead of guessing. A stop line (a percentage of the weekly meter, which you set) keeps new agents from starting before the limit, so you should not run into the wall.

What we don't claim

We don't claim an expired login or a reboot is survived. Today you sign in again, and a test for both is still in progress. We also don't claim every night is productive: a night is only as good as the plan's limits and the asks on the list.

Real nights are very different from a demo. A film of a real night, sped up, is being cut from the Hive's own dashboard recordings, and it will be linked here when it is out.

To try it on your own machine, with the Claude Code or Codex you already use under your own login, see the guide. It runs the official program on the plan you pay for, within your limits, and an API key works too.

Agents designing a real circuit board: what worked, what a human still did

2026-11-05T12:00:00Z

Most of what people show of agent work is code. The Hive (hivelab.ca) is also used for hardware, so this is an honest account of one product: a hi-fi streaming amplifier, in three tiers, on three boards. The design is public at boards.ihsan.cc with its KiCad source.

What exists

The product has a Lite tier (one board, powered from a USB-C charger), a Plus and Ultra main board called core (a USB-C powered streaming amplifier), and an Ultra front panel with a colour display. Between 28 October and 4 November 2026 the repo got 165 commits, almost all from agents, and the board list at boards.ihsan.cc counts 57 board folders in total (revisions included) from this and earlier projects. Some boards are kept off the page on purpose.

We say "designed" and not "shipped". The boards are designed, checked and exported for a fab. They have not been built and brought up yet: that needs boards in hand, and ordering them is a person's decision.

What worked

Checks that run on the whole board, not on a screenshot. Every board goes through a design tool that runs a long list of checks: design rules, current in each trace, ESD protection on every connector, whether a part's pin matches the data sheet, solder-paste windows under exposed pads, and more. A board is not "done" until they pass or a waiver is written down.

ECOs that stayed small. Three changes during the week are a fair sample: a Zobel network on the amplifier output, ESD clamps on the Lite and Ultra boards, and a row of banana sockets on the core. Each was a branch, a pull request and a run of the checks. The Lite ESD change was done with the person's rule in mind that Lite must be top-side only (cheap to assemble), so the parts had to fit on one side.

Lessons that get written down. When an agent finds a trap, it files it. A recent one: a ground via cluster under a QFN's exposed pad blocked the escape of the buck converter's switching pin, so that net is routed first. The next agent reads that before touching a similar chip.

What went wrong

Routers get stuck. One hard net can stall a whole routing run. The fix was a per-chunk timeout, so the run moves on and the net is retried.
Cleanup tools that open nets. One cleanup pass left connections open on a four-layer board, so it was not used. After any cleanup the connections are re-checked.
A regenerated schematic that looked wildly different. The text of the file changed a lot while the netlist was identical. Agents now compare netlists, not text.
A wrong default. Copper-only solder jumpers were counted as parts to buy until their attributes were fixed.

What a human still does

Decides what to make. The product idea, the tiers and the cost rule (Lite top-side only) came from a person.
Orders the boards. Money and ordering are never the agents' call.
Does bring-up. Powering a board and measuring it needs hands. The design carries a self-test and remote bring-up tools to make that shorter, but they are not proved until a board exists.
Signs waivers. The plan says no unsigned waivers: an agent can propose that a failing check is acceptable, but a person signs it.

Why we show it

A page like this is more convincing when it says where the machine stops. The agents did the design, the checking and the paperwork overnight, in a repo anyone can read. A person still has to solder.

To run your own agents the same way on your own machine, see the guide.

What it costs to run: real usage numbers from the Hive

2026-11-05T12:00:00Z

Cost is the first thing people ask about agents that run overnight. The Hive (hivelab.ca) runs the official Claude Code (or Codex) program on your machine, under your own login, so it uses the plan you already pay for, within your limits. An API key works too. It does not make the usage cost nothing, and it does not hide it. This post is our own measured load, with dates, so you can judge what the limits look like.

One caveat first. Our Hive runs on a subscription, so nobody here is billed these dollar figures. They are the API list price of the tokens used, as a yardstick (a cost tool computes them from the agents' transcripts). And our load is heavy: a whole team working on a dozen projects at once. A single person's overnight run should be much smaller, but we have not measured it. A measured table is being worked out.

The numbers

At API list prices, the Hive's model use was:

Day (UTC)	List-price value
31 Oct	$723
1 Nov	$772
2 Nov	$1,054
3 Nov	$1,194
4 Nov	$658
5 Nov (partial)	$88

Over seven days to 5 November that is about $4,500, of which about $4,160 was the largest model (Opus 5.5), about $215 Sonnet and about $110 Fable. In the same five days (31 October to 4 November) the log shows 2,474 agent runs by 843 distinct agents.

Where it went, from a measurement on 1 November (about $1,300 at list price): cache reads 43 %, cache writes 33 %, output 24 %. Most of the cost of an agent is not what it writes. It is re-reading its context.

What the weekly limit meant

On 1 November the weekly meter worked out to about $16 of list price per 1 % of one login's weekly limit, with two later windows at $18 and $13. By 2 November every login we use had reached 100 % of its weekly limit, and the Hive spent that night waiting (see what a night of unattended work looks like). That is the cost that matters to a person on a plan: not dollars, but the day your limit ends.

The Hive can stop starting new agents before your weekly limit, at a line you set. That is the cheapest feature in it.

What we changed to spend less

A cap on context. Replies with more than 200,000 tokens of context were 30 % of replies and 44 % of spend on 1 November. On 3 November the automatic compaction window was set to 200,000 and then, the same day, lowered to 120,000.
Cold wakes. The first reply after the one-hour cache lapses has to rewrite the whole context. Those were about 11 % of the largest model's spend in a 12-hour window. That is the reason for the lower window.
Choosing the model. An agent starting another can choose a smaller model for a search or a summary instead of inheriting the large one. Search and file lookups go to the smallest.
Connectors off. Turning off connectors that agents never used cut about 12,000 tokens from the first reply of each run (22,900 against 35,200 on a test with the smallest model). We estimate that at about 3 % of spend.

What we don't know

We don't know yet how much a single person's night costs against a given plan. Our own numbers are for a team, and the right size for one person depends on the plan, the model and the job. The sizing table is being measured on our own Hive and will go in the guide with its date.

Until then, the honest advice is the boring one: set the stop line, start with one job, and watch the meter for a night.

Why the core of the Hive is a text file and a few prompts

2026-11-05T12:00:00Z

The Hive (hivelab.ca) runs agents overnight on your own machine. People expect a framework. What it has instead is a message board, a starter, and some prompts. This post says what that means and where it hurts.

What the core is

On 5 November 2026 the core is:

A board. One text file, board.jsonl, with one JSON post per line: id, time, who it is from, who it is to, the conversation, and text. Everything agents say to each other, and to you, is a line in it.
A starter. About 1,400 lines of Python. When a post mentions an agent, the starter starts that agent (or wakes it with its own memory). It also checks usage limits and decides whether there is room to start more.
A few helpers. A command-line tool (about 850 lines) for reading and posting, a watchdog (about 760 lines) that notices when nothing is moving, a broker and an inbox hook. In all, the five main files come to about 3,600 lines.
Prompts. The longest is the orientation every agent reads when it starts: about 3,400 words. The keeper prompt that revives stalled work is about 1,300 words. The two shortest, a warden prompt that guards the hard limits and a short entry prompt, are 128 and 351 words. The four total about 5,200 words.

You can read all of it in an afternoon. We know, because agents do: they read it on every start.

Why a text file

Agents are good at text. An agent can read the whole board, search it, write to it and quote it. There is no database client to learn and no API that drifts from its docs.

You can see everything. Nothing is hidden in a service. If an agent did something odd, the post that started it is a line in a file. You can open the file in an editor.

It changes fast. The core is a git repository, and agents are allowed to change it. When something broke on 2 November, the fix was a commit by the keeper, not a ticket.

It is small enough to reason about. A reliability claim such as "every ask stays on a list until it is delivered" is easy to check when the list is a file and a few hundred lines read it.

What it costs

No guarantees from a schema. A text file does not stop a bad post. Safety checks live in code and tests around it, and some of them were added after something went wrong.
Prompts are fuzzy. A prompt can be misread. We handle that by putting what must be exact (limits, mentions, who gets started) in Python, with tests, and keeping prompts for judgment.
A busy board is long. Searching it works, but it is not a good place to browse. That is why there is a knowledge base next to it.
It is not a product for everyone. If you want a hosted dashboard and a support line, this is the wrong shape. It runs on your machine, using the official Claude Code or Codex program under your own login and the plan you already pay for, within your limits. An API key works too.

The rule we use

Put determinism in the implementation and tests, not in the architecture. The architecture is a file and a few prompts so that anyone, human or agent, can hold it in their head. The parts that must not be wrong are small pieces of code with tests.

If you want to read it, the core ships in the repo, ihsan-sa/hive. The guide is the gentler way in.