A software factory powered by the Pi coding agent
Tehas is a Pi software factory. It takes a GitHub issue, runs the Pi coding agent on it inside a sandbox, and hands back a reviewed pull request. Nobody sits in the agent session. A person writes the issue, applies one label, and later reviews and merges.
The factory floor on this host is one such factory at work. This page explains what it is made of.
Tehas is its own project. It is built on Pi and is not part of Pi or endorsed by its maintainers.
What a Pi software factory is
Pi is a minimal agent harness. You can use it in a terminal, run it in print or JSON mode, control it over RPC or build on its SDK. It does the work of one session: it reads code, runs commands, edits files and talks to a model.
A software factory is what stands around that session so that work can pass through without someone driving it: a queue, a rule for who may start work, a closed place for the agent to run, checks the result must pass, a review, and a record of what happened. A Pi software factory is one where the agent doing the work is Pi.
Who does what
| Part | What it does in tehas |
|---|---|
| Pi | The coding agent. Tehas starts it as pi --mode rpc in a container, so it needs no terminal, and sends it one command: /work <issue>. |
| pi-rukas | A Pi extension that provides /work. It runs the cycle, starts child Pi processes by role (explore, developer, adversarial developer, code review) and keeps them in git worktrees. |
| Tehas | The factory: the dispatcher that reads the queue, the check of who applied the label, the sandbox with its limits, the settings, the factory floor and the live console. |
| GitHub | The queue, the state and the results. Issues are the work orders, labels are the state machine, and the outcome is a pull request with comments. |
| Model endpoint | All inference. A self-hosted, OpenAI-compatible endpoint the operator names. The factory host needs no GPU. |
| A person | Writes the issue, authorizes it with a label, reviews the pull request and merges. |
pi-rukas and Pi are separate projects with their own repositories.
How an issue becomes a pull request
- Someone writes an issue with one outcome and a list of acceptance criteria.
- An allowed account applies the label
tehas:ready. That label is the authorization to spend compute. Applied by anyone else, it is ignored and logged. - The dispatcher polls the queue every two minutes, picks the issue and labels
it
tehas:running. - Pi starts in the sandbox and pi-rukas runs the cycle: explore, plan, a worktree for each workstream, develop.
- The project's own gates run: the commands in
.pi/verify-cmd,.pi/verify-cmd-fulland.pi/smoke-cmd. - A second agent attacks the patch before anything is committed.
- The cycle commits, opens a pull request and reviews it in six passes: security, error handling, type safety, performance, architecture and simplicity.
- The dispatcher labels the issue
tehas:awaiting-merge, comments the link and posts token usage for each agent role on the pull request. - A person reviews and merges. Tehas never merges, deploys or touches production.
A cycle that cannot finish leaves the label needs-human-attention and a
comment saying where it stopped. Overview has the same flow in
short, and Operating covers the day-to-day.
What tehas adds to running Pi by hand
| Running Pi yourself | With tehas |
|---|---|
| You start a session and stay with it | Issues wait in GitHub and are picked up one at a time, urgent ones first |
| Whoever has the terminal decides what runs | Only a label from an account on the allow list starts work |
| The agent runs with your files and your keys | It runs in a container with CPU and memory limits and one bot token: no Docker socket, no SSH keys |
| You decide when it is done | The repository's own gates decide, and the cycle halts if its patch touches .pi/, .github/ or AGENTS.md |
| Output scrolls past in your terminal | The console streams to the factory floor with tokens and passwords masked, and usage is posted on the pull request |
| A stalled session waits for you to notice | A stopped cycle labels the issue and says why; a pause label on the control issue holds the queue |
See it run
The factory floor shows the stages as stations: in line, building, review and shipped. Beside them are the selected work order with its tokens, time and estimated energy, the issue board and the console of the running cycle. When the live queue cannot be read the page loads sample tickets and says so.
The plain dashboard has the same queue as lists.
Questions
Is this an official Pi project?
No. Tehas uses Pi and pi-rukas as they are published, with Pi pinned by version and pi-rukas by commit.
Does tehas write code without anyone checking it?
It writes and reviews without anyone watching. It does not merge. Every pull request waits for a person.
Which models does it use?
Self-hosted ones, through an OpenAI-compatible endpoint named in the instance settings. One model serves every agent role today. A cycle needs a model that can hold at least two conversations at once and a context of around 80,000 tokens; Features explains what happens without that.
How much of it is proven?
Features lists every part with how far it has been checked, down to what has only been tested with fake files. Read it before relying on anything here.
Can one factory serve several repositories?
Not yet. An instance is one host, one product repository and one cycle at a time.
Where does the name come from?
"Tehas" is Estonian for factory. "Pirukas", behind pi-rukas, is Estonian for pie.
Set one up
- A new project: installing tehas for another repository.
- Bootstrap a host: preparing a fresh machine.
- For agents: handing the setup to a coding agent, starting from
/llms.txt. - Source: github.com/janit/tehas.