Skip to main content

Treq as a Graphite Alternative

Compare stack-oriented development philosophies, not feature checklists.

Introduction​

Graphite made stacked pull requests a daily habit for many teams. You open small dependent PRs. You restack them quickly. Reviewers see one layer at a time. Teams looking for a Graphite alternative often want that review model, plus better support for local agents.

Treq starts in a different place. Graphite organises remotes and pull requests. Treq organises local workspaces where coding agents run. It keeps those workspaces stacked and rebased while you review. Both care about incremental review. They fix different parts of the loop.

This page compares the two workflow philosophies so you can choose based on where your pain is.

Understanding the Concept​

A stack-oriented workflow splits large changes into ordered increments. Reviewers see one contract at a time. Later work waits on a stable base.

Definition

Stack-Oriented Workflow

A development process that splits dependent work into ordered branches or workspaces and reviews each layer against its direct base.

Graphite treats the pull request as the unit of collaboration. You create a stack of branches, open PRs with the right bases, restack after feedback, and merge upward. The main surface is remote review.

Treq treats the local workspace as the unit of agent work. You create isolated working copies, run agents inside them, review diffs locally, and merge when ready. Stacks are links between workspace bookmarks. Auto-rebase keeps dependents current when a lower workspace moves.

Graphite-style PR stacksTreq stacked workspaces
Primary unitPull request / remote branchLocal workspace / working copy
Best atShared review on GitHubParallel local agents and review handoff
IsolationBranch isolationWorking-copy isolation plus branch isolation
RestackStack tooling around git rebaseAutomatic rebase of dependent workspaces
Agent fitAgents submit PRs into the stackAgents run inside the workspace under review
Open sourceCommercial productOpen source desktop app

Neither model removes human review. Stacking only makes the review surface smaller.

Applying It in Practice​

Choose Graphite-style PR stacking when remote collaboration is the bottleneck. That often means many GitHub reviewers, long-lived stacks across teammates, and merge queues that already assume stacked PRs.

Choose Treq when local agent throughput is the bottleneck. That often means several Claude Code or Codex sessions, colliding checkouts, stale agent branches, and review comments you want to send back to an agent in place.

A common split:

  1. Develop and revise with stacked local workspaces while agents are active.
  2. Open pull requests for team review when a layer is ready.
  3. Keep restacking discipline on both sides after feedback.

If you already run Graphite, use Treq locally for agent isolation. Bring finished layers into your remote stack. If you start with Treq, open ordinary stacked PRs from workspace bookmarks. You do not need another stack client for that.

For stack mechanics, read Stacked PRs in AI-Assisted Development. For Treq workspace behavior, read Workspaces.

Engineering Considerations​

Feature checkboxes hide the real tradeoff. Decide which state you need to manage: the remote PR graph, or the local agent working copy.

Remote-first stacking is weak when agents need separate filesystems and long-running terminals. Local-first workspaces are weak when your team already depends on a hosted stack product and its merge automation.

Also compare rewrite policy. Any stack tool that rebases will force-push. Branch protection, review rules, and CI must allow leased force pushes on stack branches. Both models share that requirement.

Scaling and Operational Considerations​

As agent volume grows, local isolation comes first. Conflicts and stale bases show up in the working copy. Tools that only organise PRs leave that pain in your terminal tabs.

As team review volume grows, remote stack visibility and merge ordering matter more. Local workspaces alone do not replace shared PR discussion.

Use stacks only where dependencies are real. Independent agent tasks should stay on parallel branches and merge in any order. Fake dependencies create restack work with no review benefit.

Next Steps​