You keep the human work. We build the rest.
Every number below was read on 27 August 2026, Denver time, from files our own systems wrote for themselves. Nothing was started, stopped, or changed to produce it.
The short version
We run a memory system for our AI fleet. It reads our working notes and session transcripts and turns them into a searchable map of facts and the connections between them. The reading is done by a large open-weight model on one machine in our Mac Studio fleet: 27.3 billion parameters, 17.74 GB on disk, 20.32 GB of graphics memory while it is loaded.
In the last 24 hours, three of our always-on loops kept that model busy for 47.02 hours.
A day has 24 hours. The three loops call the same model at the same time, so their busy time adds up past a calendar day. The model is oversubscribed about two to one. It got through 2,921 items in that window, averaging 58.0 seconds each.
The traffic jam has a price. Of the 84 attempts to save facts from a finished work session, 71 hit a two-minute ceiling and came back with nothing. Twelve succeeded. We spent 2.41 hours of model time in one day producing nothing, because the model was already busy with the other two loops.
When one expensive worker repeats the same narrow task thousands of times a day, you train a cheap worker to do it and keep the expensive one on the bench. That is what we are doing.
What we measured
The 24-hour window is 26 August 18:43 to 27 August 18:43, Denver time.
| Loop | Items done | Model time | Share of the day | Seconds per item |
|---|---|---|---|---|
| Knowledge extraction, one at a time | 1,410 | 22.18 h | 92.4% | 55.7 mean, 24.0 median |
| Knowledge extraction, batches of ten | 1,427 | 22.12 h | 92.1% | 54.4 mean, 48.1 median |
| Session fact capture | 12 kept of 84 tried | 2.73 h | 11.4% | 91.6 mean on the 12 that worked |
| Total | 2,921 | 47.02 h | 195.9% | 58.0 |
Three caveats. "Model time" comes from each loop's own timer around its own request, so it includes waiting inside the request: it measures exactly how long the loop was blocked and is an upper bound on pure computation. The batch figure is a floor, because recovery passes record how many items they saved but never how long they took. And a second capture loop on our other agent setup records no timing at all, so its share is unknown and we left it unknown.
The method
The big model has been doing this job for weeks, and it wrote down its work. Every extraction is a question and an answer: raw text in, structured result out. That log is a training set that already exists.
Two large models produced pairs for us, 25,270 between them. After removing malformed entries, over-length entries, and duplicates, 14,457 unique pairs remain. Most of the removal was overlap: 10,554 of the second model's pairs described work the first had already done. We split the rest into 13,657 for training, 400 for validation, and 400 held back as an exam the student never sees.
The student is Qwen3-1.7B, 4-bit, fine-tuned with LoRA. LoRA means we do not retrain the model. We train a small set of extra weights that sit alongside it and steer it: in this run 0.289% of the parameters, 4.98 million out of 1.72 billion. That is why this fits on a desk instead of a data centre.
The run is in progress. Validation loss started at 1.605 and reached 0.491 by iteration 300 of a planned 6,900. That means the model is learning the shape of the answer. Whether the answers are good enough to keep is a separate question, and the exam settles it.
The bet is that a small model is enough when the task is narrow and the output format is fixed. A 2026 study that LoRA-fine-tuned models from 270M to 8B parameters on merchant-information extraction found quality scales log-linearly with diminishing returns above roughly a billion parameters, with a 4B model landing within 0.35 F1 points of the 8B at half the size. We have not verified that on our own data. The exam will say if it is wrong for us.
Qwen3.5-4B is the next candidate. Both take the same 400-pair exam. The winner ships behind a canary gate, and the 27-billion-parameter model stays loaded as the fallback.
What that would save, and what has to be true first
This is a projection. Here is the formula.
projected_seconds_per_day = items_per_day x student_seconds_per_item
saved_seconds_per_day = measured_seconds_per_day - projected_seconds_per_day
ratio = measured / projected
projected_seconds_per_day = items_per_day x student_seconds_per_item
saved_seconds_per_day = measured_seconds_per_day - projected_seconds_per_day
ratio = measured / projected
Both inputs are measured: items_per_day = 2,921 and measured_seconds_per_day = 169,289.
| Measured today | Student at 5 s/item | Student at 10 s/item | |
|---|---|---|---|
| Model time per day | 47.02 h | 4.06 h | 8.11 h |
| Share of a 24-hour day | 195.9% | 16.9% | 33.8% |
| Freed per day | — | 42.97 h | 38.91 h |
| Times less model time | — | 11.59x | 5.80x |
Four things have to be true for that table to hold. None is settled.
The student has to be fast enough, and we do not know whether it is. A typical answer here is 2,538 characters, roughly 634 to 846 tokens. Five seconds per item needs 127 to 169 tokens per second. Ten seconds needs 63 to 85. The only serving speed we have observed is about 20 tokens per second, measured while the big model held the graphics card at around 92% of wall clock. Uncontended speed is unmeasured. At 20 tokens per second neither target is reachable, so the projection rests on a number that does not exist yet. Measuring it is the first step of the exam.
The student is graded against the teacher, not against perfection. In a bake-off between candidate teachers on the same episodes, the two we chose for the bulk corpus agreed with each other on only 0.53 of the entities they pulled out, across 361 shared episodes. Other pairings ran from 0.35 to 0.55. Failure rates were 0% for one and 6% for the other. Two competent large models reading the same paragraph do not produce the same answer. The bar is matching the teacher, and we grade against 0.53 rather than a correct answer nobody can produce.
Student answer quality is unproven. Training is unfinished and no held-out comparison has been scored. Nothing here says the small model is good enough to replace the big one, only that it would be cheaper.
We do not know whether the freed capacity stays freed. If the loops stop holding the big model, it might be unloadable, or the space might fill with other queued work. Process listings cannot answer that.
What we will report back
Post two is the actuals against the numbers above: uncontended serving speed on a free card, the 400-pair exam scored for both candidates, agreement with the teacher, and the measured model time per day after the switch, set beside the 4.06 and 8.11 hours projected here. If the student misses, we will publish the miss with the same numbers attached.
After that the method has two more places to go: the capture extraction that times out 71 times a day, and drift adjudication. It fits any loop where a large model repeats one narrow job thousands of times and writes down what it did.
The open-source part
We will release the pipeline: the harvest pattern that turns a running loop's logs into training pairs, the dataset builder that deduplicates and splits them, the training recipe, and the exam harness that scores a candidate against held-out teacher answers. You can run it on your own data.
The 14,457 pairs stay private. They are distilled from our internal operations and they encode how we work. Keeping them back costs you nothing, because the pairs were never the transferable part. Your teacher writes your pairs from your loops, on your machine, and the small model you get is shaped by your job rather than ours. The machinery is what travels, and we will link it from post two.