Everything to plan, run, review, and ship

1. 01

   Write the ticket

   A ticket is one unit of work with a plan attached: a checklist the agent works through in order and ticks off as each item lands, so progress is a state you can read rather than a wall of output you have to parse.

2. 02

   Fredrin cuts the branch and the worktree

   Running it fetches your default branch from the remote first and cuts the ticket's branch from that, never from wherever your local clone happens to be sitting. The branch gets a real git worktree: its own directory, its own dev-server port, and its own copy of the project's context files.

3. 03

   The agent starts inside it

   A coding CLI launches in that directory and gets the ticket. It is the real tool, not a re-implementation of it: the same terminal UI you would have run yourself, which you can watch and type into while it works.

4. 04

   The board follows the session

   Columns move on lifecycle signals rather than on an agent remembering to report: the session starting moves the ticket to Running, the session ending moves it to Review, and a question the agent needs answered parks it in Blocked and rings for you.

5. 05

   Checks run, and their real exit codes ship with the PR

   The agent's last act is running the ticket's acceptance checks and reporting their real exit codes. A red check does not withhold the pull request: the failure is recorded against the ticket, stamped as a failing status on the PR, and written into its body, so you review a real diff with an honest signal instead of a ticket with nothing to open.

6. 06

   Conflicts are caught before the push

   Fredrin merges the branch against the latest base in memory before pushing. If it would conflict, the push is refused and the conflicting paths are named, so you are never handed a pull request with a red merge banner. One that appears later, because the base moved, is resolved when you click Merge and shown to you as a diff.

7. 07

   You merge

   Merging is the human gate. The pull request and its CI status ride back onto the card, and merging auto-completes the ticket. Auto-merge exists as a per-ticket opt-in and is off unless you turn it on.

Two of those steps are doing more work than they look. The worktree is what makes the board honest about parallelism: ten agents editing ten checkouts cannot overwrite each other, which is why isolation is a git worktree rather than a lock. And the copy of the context files each worktree inherits is the project's own memory (a concept wiki and a decision log, committed to your repo), so a ticket starts knowing what the last one settled, and any refinement it makes rides back in the same pull request. How project memory is stored and retrieved is its own page.

Claude Code

The default, with reasoning effort selectable from low to max.

Codex CLI

Reasoning effort set per model, because Codex scopes its levels that way.

Cursor Agent

Cursor's own agent CLI, on your Cursor plan.

GitHub Copilot CLI

On your Copilot subscription.

OpenCode

Provider-agnostic: models are named provider/model.

pi.dev

Provider-agnostic, same provider/model addressing.

Hermes

Provider-agnostic, OpenRouter-style model slugs.

The choice is per ticket, not per account: runtime, model, and (where the CLI has one) reasoning effort are set on the card, so a copy fix and a migration can run different models on the same board at the same time. For ticket work every runtime runs without approval prompts, which is what lets an unattended Worker finish; the thing that makes that safe is the branch and worktree it is confined to, and the fact that you still merge.

macOS, Windows or Linux

macOS 13 or later on Apple Silicon or Intel, Windows 10 or later on x64, or Linux on x64 — the Linux build is an AppImage, so there is no package manager and no root involved.

Git, and Git-Bash on Windows

Worktrees are git worktrees, so git is a hard requirement. On Windows the agent shell runs under Git for Windows rather than PowerShell; if it is missing, the session fails immediately with an install link instead of hanging.

The GitHub CLI, signed in

Fredrin drives branches, worktrees, and pull requests through gh. The app checks it up front and tells you which of install or sign-in is missing, and knows the difference between signed out and simply offline.

A GitHub repository

The board runs against your own repositories. Code and project context stay in them; nothing is copied into a Fredrin-owned store to be worked on.

An agent CLI you can already run

Whichever runtime you pick, installed and signed in on the machine. Bring-your-own-subscription means Fredrin launches the CLI as you, on the plan you already hold.

It does not replace your agent or your editor

Claude Code, Codex, and your shell run exactly as they are inside each ticket. Fredrin is the board, the worktrees, and the pull requests that tie them together.

It does not run in a browser

The board is a desktop app. These marketing pages and the HTTP API are on the web; the product surface is not, because it needs your filesystem, your git, and your local CLIs.

It does not move your agents off your machine by default

Sessions run locally, on the subscription you already pay for. Fredrin Cloud is there when you want it (every plan includes a monthly allowance of it), but running a ticket on our hardware is a per-ticket opt-in, not the standing arrangement.

It does not upload your agent conversations

Prompts, replies, and terminal output stay on your machine unless a project explicitly turns syncing on, which starts off. Status, exit codes, and token counts are metadata and always flow.

It does not merge behind your back

Nothing reaches your base branch until a human merges it. Auto-merge is a per-ticket setting that starts off, and a Worker never pushes to the base branch itself.

The vocabulary behind all of this (ticket, Worker, worktree, project memory) is defined on the docs page, and what each plan includes is on pricing.