What is Repo Fleet?

Repo Fleet is where you build AI agents for your GitHub repositories and watch them run. The agents run on your own GitHub Actions runners with a model key you hold, so Repo Fleet runs no model, meters nothing, and keeps no copy of your code.

An agent here is a GitHub Actions workflow file in your repository: it says what starts it, what it may do, and what it runs on what brief. Repo Fleet is the editor those files are built in and the page their runs show up on. This article draws that shape once, follows one agent from an issue to a pull request, says where a person stands in it, lists what has shipped, and ends where you would start.

Three layers, and where Repo Fleet sits

Three different things get called AI in a repository.

• A model turns a prompt into text. Claude is one. It holds no repository and opens no pull request on its own.
• An agent is a program built on a model. It gives the model tools, reads files, runs commands, edits code, and keeps going until the task is done or a cap stops it. Claude Code is one; run on a runner in your repository, it takes an issue and leaves a branch.
• Repo Fleet sits above both. It is where you decide which agents run in which repositories, on what trigger, with which permissions and caps, and where you watch what each run did.

Repo Fleet is not a coding agent and never edits your code. The one thing it writes into a repository is a workflow file, and only when you save one.

Your runners, your key

Every run happens in your own GitHub account, on GitHub's hosted runners or on runners you host. The model calls a run makes bill a key you create and hold, added to the repository as a secret; the templates read it as ANTHROPIC_API_KEY. Repo Fleet holds no model key, sees no model call, and meters nothing. What a run costs is what your GitHub plan and your model account say it cost, and both are yours to cap.

One agent, from an issue to a pull request

Take a repository called acme/shop with one agent in it: a workflow file at .github/workflows/implement.yml, built on the Agents page. It says three things.

• What starts it. A label landing on an issue, and the job runs only when that label is agent.
• What it may do. The token GitHub mints for the run may push a branch, open a pull request, and comment on the issue, nothing more, and the job stops at thirty minutes.
• What it runs. A checkout of the repository, then the Claude Code action with a brief: read the issue, do what it asks, run the tests, push a branch named after the issue, and open a pull request whose body closes it.

Then, on a Tuesday:

1. Someone opens issue #42, "Add a CSV export to the orders page". Nothing happens yet.
2. A maintainer reads it, decides it is ready, and adds the agent label. That label is the approval; nothing ran before it.
3. GitHub starts the run on a fresh runner. Runs in Repo Fleet shows it in progress, with what started it.
4. On the runner, Claude Code reads the issue and the code, writes the export, runs the tests, commits to agent/issue-42, pushes it, and opens pull request #43, ending in Closes #42. The tokens it spent are on acme's key; the minutes are on acme's GitHub plan.
5. The run ends. Runs shows it succeeded, how long it took, and links #43 and the log on GitHub. Nothing has merged.
6. A reviewer reads #43 like any other pull request, asks for a change or merges it, and the merge closes #42.

The next labelled issue is the agent's. The file itself, every line explained, is in Claude Code in GitHub Actions.

Where a person stands

Nothing above ran without a person saying so, and every point where one might want to say so is a place the file can hold. A step becomes a gate when it waits for someone.

• Before work starts. The trigger is the first gate. A label takes someone with write access to add, so an agent that runs on labelled issues runs on the ones a person chose, whether an event or a schedule starts it. A workflow that starts by hand, workflow_dispatch, waits for someone to press the button.
• Before a merge. The pull request is the second gate. An agent that opens one lands nothing; a protected branch with a required review means a person reads the diff before it merges. An agent told to push to the default branch skips this gate, which suits a repository where the label is review enough, and it is one line of the brief to change.
• On any step. A job that names a GitHub environment with required reviewers waits until one of them approves it, and the job card in the Visual editor has an Environment field for exactly that. A deploy, a release, or a step that spends money can wait for a person every time.

Add the gates a repository needs and leave out the ones it does not; the file is yours. The starter pipeline keeps the label as its gate and ships the oldest labelled issue to the default branch every fifteen minutes. A repository that wants a review first changes its brief to open a pull request instead.

What has shipped

Repo Fleet is early. What is live today:

• A visual editor for workflow files, on the Agents page. Triggers, permissions, jobs, steps, and an action's inputs are plain fields on a Visual tab, with the YAML on a Code tab one click away. Every edit is checked as you type: the syntax, the schema, whether every action and workflow it names exists, and the habits that go wrong, such as an unpinned action or a job with no timeout.
• Templates that start whole, a working workflow rather than a blank file. The starred one ships the oldest open issue labelled fleet every fifteen minutes; others answer a comment, build and test, test on a matrix, deploy by hand, run nightly, and label new issues.
• Saving as a commit to the branch you are on, or as a branch and a pull request for review.
• Repositories, where you connect the GitHub App, choose what it may see, and start a pipeline in a repository that has no workflow yet.
• Runs, each repository's runs newest first, with the outcome, the duration, the pull request a run opened, and its log on GitHub.

Claude is the model the templates run today, through the Claude Code action on your own Anthropic key. Other providers follow. Repo Fleet reads your repositories through a GitHub App you install, with the permissions you grant, and keeps no copy of your code; the privacy policy lists exactly what it stores.

Where to start

Install Repo Fleet on GitHub. It signs you up, sends you to GitHub to install the app on an account or organization, and asks which repositories it may see. Then:

1. On Repositories, pick a repository with no workflow yet and choose Start a pipeline. It writes the starter file to the default branch and touches nothing else.
2. On GitHub, add the secret ANTHROPIC_API_KEY under the repository's settings and create the label fleet.
3. Put the label on an issue. Within the quarter hour the run takes it, and Runs shows what it did.