Skip to main content

​
Overview

Every Whim task runs on its own dedicated Git branch. This means you can launch dozens of tasks in parallel — each one writes to its own branch, so there are no merge conflicts or race conditions between tasks. When a task starts, Whim:
  1. Clones your repository into an isolated container
  2. Checks out the source branch you specified (or the repo’s default branch)
  3. Creates a new task branch and switches to it
  4. Hands control to the AI agent, which commits its work to the task branch

​
Branch naming

Task branches follow a deterministic naming pattern: 
whim-{display-id}
The display ID is derived from your workspace name. For example, if your workspace is named “whim”, tasks are numbered WW-1, WW-2, WW-3, and so on — producing branches like:
  • whim-ww-1
  • whim-ww-2
  • whim-ww-42
The prefix is generated from the workspace name:
Workspace namePrefixExample branch
whimWWwhim-ww-12
my-appMAwhim-ma-5
acme/billingBIwhim-bi-31
Each task gets a unique, atomically incremented counter, so even tasks created at the same instant receive distinct branch names.

​
Source branch selection

By default, tasks branch off your repository’s default branch (usually main). You can override this by setting a source branch when creating a task.
The source branch determines the starting point for the task’s work. The AI agent then commits its changes to the task’s own branch, not the source branch.
Common use cases for custom source branches:
  • Feature branches — base a task on an in-progress feature branch to continue work where someone left off
  • Release branches — target a specific release branch for hotfixes
  • Other task branches — chain tasks by using one task’s branch as the source for another
You can also set a default source branch in your workspace settings so all new tasks start from a branch other than main.

​
Parallel work without conflicts

Because each task operates on its own branch in its own container, parallel tasks are fully isolated:
  • No file locking — multiple tasks can modify the same files without blocking each other
  • No merge conflicts during execution — conflicts only surface when merging branches, not while tasks are running
  • Independent commit histories — each task builds its own linear commit history on its branch
This makes it safe to launch many tasks at once, even if they touch overlapping parts of the codebase.

​
What happens to branches after a task completes

When a task completes or is archived, its branch remains in your Git repository. Whim does not automatically delete task branches. This preserves the commit history and keeps any associated pull requests intact. To clean up old task branches, delete them in GitHub as you normally would — either through the GitHub UI, the CLI, or by configuring GitHub to auto-delete branches after PR merge.

​
Forking and branch inheritance

When you fork a task, the new task inherits the original task’s branch as its source. This lets you iterate on a task’s output — the forked task starts from where the original left off, then creates its own branch for new work.

Pull Requests

Create PRs from task branches and track their status.

Git Mirroring

How Whim mirrors repos for faster container startup.