fabrig
Get started

hard questions

The objections, answered straight.

What a careful reader should ask before trusting any of this.

Can I run it today?

Yes. v0.1.0 is one binary for x86-64 Linux and Apple Silicon, and temper box runs a whole deployment on your machine with its own forge, or connects to GitHub. The playground needs no account. On Linux you need kernel 6.12 and glibc 2.39 or later, plus git and ripgrep.

It is a first release, and it should be treated as one.

Aren’t the numbers just fabrig building fabrig?

Yes. Every number on the home page comes from one project, built by fab, temper’s prototype. It’s a repository with deterministic simulation and strict gates, which is the best case for agents.

So the numbers show what’s possible under that discipline. They don’t forecast what you’ll get. A second, unrelated project is planned, and its numbers will sit next to these.

My repository is below the bar. Is this for me?

That’s your choice. Agents amplify what’s there: with flaky CI and loose design they drift, and slop accumulates faster than anyone can remove it. No harness fixes that, and fabrig doesn’t claim to.

You have two honest options. Raise the bar first, or run with autonomy turned down: low throughput, a person approving each landing, a chat instead of a fleet. Both are settings, and you can turn the dial as the repository earns it. The manifesto says where fabrig stands.

Does it need Rust, or your programming model?

No. fabrig’s strict Rust subset and deterministic simulation are fabrig’s choices for fabrig. temper adopts a repository as it is, runs your CI, and doesn’t mind what language it’s in. What should transfer is the practice, and those properties are achievable in many ways.

Nothing in another language has been published yet, so for now that’s a claim rather than a result.

Nobody can review this much agent-written code.

Correct, and nobody tries. fabrig passed 2.5 million lines of Rust and 21,000 commits in its first five weeks. No person has read that, and outsiders can’t either.

The bet is that reading doesn’t scale and proof does. People decide goals, designs and plans. The code gets about 30,000 tests, simulation where a seed replays a failure, gates, verification after landing, and a continuous tech-debt review by agents that files what it finds and squashes it.

In fabrig’s own way of working, individual changes into a goal’s branch get no CI or review of their own. Quality rests on the tier following that branch, the full gate when the goal lands, and the slow tiers after it. You can choose differently, and the stock path does.

Trust should come from published outcomes rather than this page. Escape rates, and what the debt review finds over time, are on the way. More automated review, such as security, is too.

What if the configuring agent gets it wrong?

You reject the proposal, and it revises. It can’t change anything itself: an owner accepts every change, the review shows every value before and after, what’s enforced is kept apart from what’s only followed, and any revision can be restored. More on that.

Why build your own runtime, store and HTTP?

Because the economics changed. When agents write the code, a dependency’s remaining costs are fit, control and churn. You build what you need, exactly how you need it, and you keep control of it.

There’s a limit. Cryptography stays on rustls and ring. Code whose value comes from adversarial testing carries real risk when it’s home-made, so the hand-written HTTP parser and the OAuth issuer are first in line for security review.

Isn’t this five products?

It’s five trees in one repository, with dependencies pointing one way, and it’s a lot. One thing ships now: temper. Prove and Run are labelled as direction. The other trees exist because temper needs them, and a small second application keeps jig from turning into temper in disguise.

What does it cost, and why does it follow my LLM quota?

fabrig is MIT. What you pay for is models. Hardware isn’t the constraint: machines can be provisioned to follow the work. Tokens are, so what matters is what each token buys.

The first move is offloading everything that doesn’t need judgement to code. A merge, an update or a rerun costs no tokens. The second is a model per role: your strongest where judgement is dense, a faster one for producing, a cheaper one for read-only foremen.

Budgets are carved from a project’s weekly spend down through every task. A task without enough is held rather than overdrawn, and spend is recorded per task, so you can see where it went. The number to watch is cost per landed change. fabrig’s own figure is still moving as its workflows are tuned, and it will be published next to time-to-land.

Is my plan allowed to run this?

Check your provider’s terms against your volume. temper uses your own account, signed in the way each provider documents, and when an account hits a limit the work waits. It never moves to another account to get around one.

Subscription limits generally assume ordinary, individual use, and providers change their terms. For sustained automated work, API keys are the safer footing, and temper takes those too.

Has it had a security review?

Not an independent audit. Parts of the design have been through security reviews run by agents, a box listens on loopback, and cryptography isn’t home-made.

Continuous security review is planned, in the way tech debt is reviewed today: deterministic tools first, such as dependency audits and secret scans, then a model reading a goal’s whole diff where it lands.

Who’s behind it?

Today, one person and a fleet of agents. That’s a fair concern if you’re choosing what to build on.

What limits the risk: it’s MIT, and the code, the design and the reasons behind each decision all live in the repository, written so that agents can carry the work forward. You’d keep a working binary, the source and a process that can maintain it. You wouldn’t keep a vendor.

Why are the design documents so hard to read?

They’re a contract written for agents, with citations checked by code, and they aren’t meant as a way in. Start with How it works, then ask temper itself: the configuring agent answers from your settings and the documentation in the binary.

Where does it stand?

In v0.1.0

Next

Direction

How does it compare?

By category, because this field moves monthly. In every row below the others have something fabrig doesn’t: years of use, and users. fabrig’s case is the design.

If you useIt’s good atfabrig adds
A coding agent at a terminalImmediate, flexible, one person at a timeWork that outlives processes and machines, many agents at once, rules no agent can loosen
Cloud agents that open pull requestsNo setup, and a person reviews at the endA path that doesn’t have to end in a person, with landing as procedure
Agent orchestratorsMany role-based agents, working todayExact-commit landing, enforced authority, effects made once
Merge queuesDeterministic, establishedRepair and conflict resolution inside the loop
Durable workflow enginesGeneral, proven at scaleRecovery classes for effects, instead of leaving idempotency to you

Almost nothing else configures its process from a description of how you work, and tells you what it can’t cover yet. That’s the place to start: tell temper how you work.