Project Cyborg

Motivation

A large block of compute, about to expire, pointed at my own record rather than at a product or a customer. Anything can burn compute. The design question is what has to be true for the burning to produce anything.

Design premise

The naive theory is that more calls make more value, and it holds for almost everything else you can buy. More servers serve more requests. More storage holds more files.

Model calls break it. Their output is text, and text is not automatically worth anything. Ask a model a vague question ten thousand times and you get ten thousand vague answers, which is a reading problem stacked on the original problem. The one thing you cannot buy more of is your own attention.

The constraint at the top of the repository: compute helps when it reduces ambiguity, not when it creates more text. Its value is that it scores a run:

• wasted if the run leaves more words and the same number of open questions, however good the words
• paid if the run leaves fewer open questions

The working method that follows is run hot first and select afterwards: explore in many directions, generate a great deal of material, then compress and promote whatever repeats. The generating half is cheap. The selecting half is the whole game.

The ledger

The ledger came before any of the research programs, because an experiment that cannot say what it spent is not an experiment.

Every model call goes through one wrapper, which appends one line per call to an append-only file. The whole record of a run, in the second engine:

interface LedgerEntry {
  ts: string;              // ISO timestamp at completion
  runId: string;
  program: string;
  model: string;
  inputTokens: number;
  cachedInputTokens: number;
  outputTokens: number;
  costUsd: number;
  ms: number;
  ok: boolean;
  error?: string;
}

Nothing else in the system is allowed to be the source of truth about what happened. A separate database exists for querying and is rebuilt from the file, so if the two ever disagree the file wins and the database is thrown away.

Where cost gets computed moved between engines, and it is a real tradeoff either way:

• Read time (first engine). Events carry no cost; it is computed from a pricing table. When prices change, one table edit corrects every historical number without touching a single recorded event. Facts about what happened stay separate from opinions about what they were worth.
• Write time (second engine). Each line carries its own cost, so the ledger is self-contained and the pricing table becomes historical rather than load-bearing. The price is exactly what read time was buying: a pricing correction can no longer reach back through the record.

The second engine's governing constraint decides it. Its README requires zero dependence on the old machinery, which had never been verified, and a ledger deriving cost from an external table depends on that table being right. Self-containment removes the dependency, which is also why the accounting was rebuilt rather than ported: an unverified accounting layer is worse than none, because it produces numbers you half-believe.

The research programs

The research runs as a set of programs, each one a prompt shape with a model assigned to it. Seven do the searching; three arrived later, two of them closing the loop and one that ran a single time.

• insight-miner on the cheapest model, looking for connections across documents that I never stated in one place
• product-forge on the strongest model, which must return a mechanism, the smallest real test, and a kill criterion
• tech-mechanisms in the middle, looking for primitives that dissolve frictions that keep recurring
• reality-contact on the strongest model, turning thinking loops into something that produces a signal from the world, with one design drafted all the way
• ensemble on the cheapest model, answering a fixed bank of questions many times independently
• wildcard in the middle, designing its own experiment on the corpus and reporting hypothesis and result
• synthesis on the strongest model, running every forty runs or so over everything produced since the last one

The corpus is a local snapshot of about nine thousand documents. The engine reads it and cannot write to it, and every write the system makes goes somewhere else.

The ensemble program is the philosophy in one program. It asks the same question many times, independently, then counts:

• an idea appearing in one run is a model producing plausible text
• an idea appearing in most of them is a property of the material

Repetition across independent samples is the cheapest signal detector available, and it costs nothing but calls, which was the resource I had.

The open loop

The synthesis program was already doing the right thing. Its prompt asks for exactly three new questions that the outputs raise and that the next wave should chase, and it maintains a short list of the sharpest currently open ones, dropping the answered and the stale.

Those questions went into a markdown file, and nothing read them.

The system did not look broken:

• the ledger recorded completed runs
• the programs wrote artifacts
• synthesis produced good questions about those artifacts, and maintained a list of the open ones

And every wave started where the last one did, at a random sample of the corpus, because the sampler had no memory of what the synthesizer had learned. Calls arranged that way are not an agent doing research, they are a very expensive random number generator with excellent prose.

The machine-readable channel

The fix is one harvester, scraping the FRONTIER questions out of the synthesis files into a line-delimited file. An entry is three fields:

{"ts":"2026-06-11T19:13:28.725Z",
 "q":"What is the minimal process primitive that unifies organs, documents, triggers, and agent runs?",
 "source":"2026-06-11181420-synthesis-00193.md"}

The source field is what makes it a loop rather than a queue, because every question can be walked back to the artifact that raised it. Two new programs consume it:

• frontier-chase takes one of those questions as its input and researches it directly, on the strongest model.
• deepen takes a prior artifact and second-passes it against a fresh slice of the corpus, auditing it, strengthening it, producing a revised version and then a verdict of promote, revise, or kill.

The loop that results is explore, synthesize, generate new questions, explore those. It seeded in one burst with 134 questions pulled out of 26 synthesis files. It currently holds 413.

The transferable mechanism: a feedback loop needs a machine-readable channel between its halves, and prose is not one. The synthesis output was always full of good questions embedded in paragraphs, a format only a human can act on. One harvester pulling them into a file with a stable shape converted a producer of essays into something that steers.

The harvesting is imperfect in the way this kind of thing always is. Five of the 413 entries are not questions, three of them visibly a bullet caught mid-line, because the extractor is reading structured meaning out of formatted text. A 1.2 percent error rate on a channel that costs almost nothing to run is a trade I would take every time.

What the engine produced

The engine recorded 6,211 completed runs, one ledger line each. By program:

The two programs added to close the loop account for 1,028 of those runs, so the loop did not just exist, it ran.

The stated result in the record is the title of the first field note written out of it, that extraction beats generation. That agrees with the constraint I started from rather than testing it, so the finding to take from the run is structural rather than substantive.

The shape is what I would defend. An experiment that spends a lot of compute needs, in order:

• an accounting layer you trust, before it needs any research programs
• independent repetition rather than single answers, if it wants signal
• a machine-readable path from what it learned back to what it does next

The first engine had two of those three, ran well, and could not accumulate. The gap between a system that produces and a system that improves is one file and a consumer for it.