How afk.build works

From sign-in to a landed change: what you do, what the factory owns, the line every run follows, and every pause. The console and each project’s page show your real state; this page only explains.

What you do, once per project

The steps on the project page, one at a time. Signing in with GitHub is where the console starts; it is not a step.

  1. Connect a repository

    Give the afk.build GitHub App access to the repository (on github.com; the console links there and brings you back), then pick it here. It becomes a project in your workspace.

  2. Workstation

    Runs work on machines in your own Namespace or boat.dev account: afk.build starts one for a run and stops it when it is idle, and the bill is yours. Connect one once: every project of the workspace runs on it, and the next step signs in on it.

  3. Harness and account

    Claude Code or Codex, on the accounts of the workspace pool: you sign in once with your own Claude or ChatGPT plan (or add an API key), every project of the workspace runs on them, and a run moves to the next account when one is spent.

  4. Confirm the setup

    The factory reads the repository (lockfile, package.json scripts, test and lint tools, or Xcode, Gradle, Cargo, Go, Python…) and proposes install, build and gate commands. Accept them as they are or edit them; nothing is committed to the repository.

Then start the first conversation. Each conversation is one task: describe what should ship the way you would to a colleague, pick the harness's model and effort if you like, and the run starts at once. The harness works live in front of you and asks you here when it needs a decision.

What the factory owns, so you do not have to

Things the customer never sets up. They are state the factory manages; you only see their effect.

Configuration, detected
How to install, build and prove the project is read from the repository (lockfile, scripts, test and lint tools, or Xcode, Gradle, Cargo, Go, Python…) and kept with the project. You accept it once and edit it any time; the factory never writes a file into your repository.
Sessions, saved
After every turn the factory keeps its own copy of the harness’s session. A run resumes on the same workstation, on a new one, or, if the session is gone, in a fresh session that knows the brief and every answer you gave.
Credentials and access
Your Claude subscription token is sealed and delivered only to the project’s workstation for a run. GitHub is reached through the app’s one-hour tokens, so you never enter a GitHub secret.

The line every run follows

Six stages. The factory moves a run along; you are asked only where it pauses.

Queued

The factory · The task waits for a free slot.

You · Nothing.

Workstation

The factory · A workstation of the project is started in your own Namespace or boat.dev account, or made there when none is free. A one-hour GitHub token is minted and the runner starts.

You · Nothing.

Build

The factory · The harness (Claude Code or Codex) works in a checkout of your repository with its own instructions, skills and hooks. Every step it takes shows live in the conversation; the session is saved after every turn.

You · Answer when it asks. The run pauses as “waiting for you”, you get a push and an email, and your answer resumes it. Unanswered for 24 hours, the task is parked.

Prove

The factory · The gate from the project’s stored configuration runs on the workstation: lint, types, tests, build, Playwright with video and traces. Evidence is stored, the candidate branch is pushed, and the run enters the merge queue.

You · When a change you asked for touches T3 paths (schema, money, auth, policy, by the project's rules), the run waits for your “Ship it” before landing. A fix of an issue of the list lands without it. Otherwise nothing.

Land

The factory · The lander, a script with no model, rebases the candidate on your default branch, re-runs the fast gate if the branch moved, pushes, and writes a Check Run. A conflict or a red gate ejects the candidate with diagnostics.

You · Nothing.

Shipped

The factory · The change is on your default branch, and your own deploy runs.

You · Read the conversation’s proof of work: the screens and recordings of the change, what changed and why, the gate, the cost.

When the line pauses or stops

The other states a run can be in, and what they mean.

  • waiting for you

    The agent asked a question. Answer it and the build resumes.

  • waiting for quota

    The subscription hit its plan window. The run resumes by itself when the window resets.

  • awaiting approval

    A T3 candidate is proven and waits for your “Ship it”.

  • base moved

    Your default branch moved during landing. The candidate is re-derived on the new base, at most twice.

  • needs a human

    The factory stopped on purpose. The conversation says why.

  • parked

    24 hours without your answer. Answering resumes the run.

  • failed

    The run ended without a landed change; the conversation says why.

  • cancelled

    Stopped by you, for example by rejecting an approval.

Where to find things
  • Console

    Console: one row per repository with its setup state, what is running now, what waits for you, and what shipped.

  • Project

    Project page: the guide until the project is ready, then its conversations (one per task, with the harness's transcript live); Project settings holds the configuration (detected, editable), the repository's instructions and skills, and its credentials.

  • Account pool

    Account pool: every model account of the workspace in rotation order, and the fallback models.

  • General settings

    General settings: the workspace and its projects, instructions for every project, schedules, workstations, snapshots and GitHub.