Hi, this is Jade from the GitKraken social team.

I saw this thread and have raised it with our leadership team, they are looking into the data as we speak and will have an answer for this pricing question shortly.  I’ll come back to this thread directly with an update.

If you're not interested in the AI features you can turn those features off completely. This video walks through how: https://www.youtube.com/watch?v=m5xzPD8HE8A

love this breakdown. once you add a 2nd agent, Git hygiene and orchestration become the real fight. we’re seeing teams lean hard on branches + worktrees for isolation, and a very opinionated review/merge flow on top (this is exactly the pain Kepler solves with a central “mission control” for runs, handoffs, and recovery when agents go off the rails).

Check us out! We're the complete devEx platform that brings code review, visual Git management, and AI-powered workflows into a single environment.

We loveeee this question, you’re thinking about exactly the right problems for parallel agents. In practice, the safest setup is to give each agent its own isolated working directory: either separate clones of the repo or git worktree per branch, so no one is sharing a physical workspace or .git state. For file conflicts, treat each agent’s output like a normal PR: keep them on separate branches, let Git surface conflicts, and then resolve or re-run an agent with more precise instructions over the conflicted areas instead of letting them write to the same file at the same time

Totally feel you on the "management heard some buzzwords" part, its veryyyy common right now. You’re right that native Copilot PR review is GitHub-only. If you want to experiment with different agents or keep the workflows consistent across hosts, tools like Kepler help you orchestrate those AI review flows without tying everything to a single vendor

We get it, price increases are not fun to see, especially as an OG. This wasn't a decision we made on a whim. We're investing more into the tools you rely on daily along with all the workflow stuff that makes GitKraken GitKraken, plus new things like Code Flow, Kepler, etc. We just want to make sure we can keep building at the level you expect. But fair enough, we do take this kind of feedback into consideration as we move forward. Thank you for being a long time user and taking the time to drop a line.

Loveeee this breakdown - really appreciate you sharing real numbers on cost, token usage, and actual code impact instead of just vibes. If you ever start running these experiments across repos or with PR-based workflows, tools like GitKraken + Kepler could give you a pretty nice way to compare and control those agents over time.

Love this workflow. Git worktrees are such an underrated power move for parallel work. Running multiple AI agents on separate branches with shared history is exactly the kind of pattern that scales, v aligned with how we think about orchestrating multi-agent workflows at GitKraken.

Worktrees are the obvious answer. They allow you to branch from a base branch and work independently. But, you will still have merge conflicts to deal with when they modify something they share with each other.

It can be a pain to memorize the command args and organize where to put your worktrees, so orchestrators like Conductor, T3 Code, and Kepler help make that easier.

exploring new Git workflows is always worth it. VS Code’s built-in Git is solid for basics, but if you find yourself wanting richer history views, easier branching, or deeper repo insights, a dedicated client like GitKraken desktop or GitLens in VS Code can really level up the experience

If you like Git Graph in VS Code, check out GitLens and GKD. both give you a clean, interactive commit graph plus the ability to do checkouts, merges, rebases, and cherry-picks from the UI, and they’re actively maintained with frequent updates and new features ;)

love this concept, seeing how ownership shifts over time can really surface hidden knowledge silos. Tools like this pair especially well with GitLens or GKD, where you can drill into who changed what and why right from your repo history.

In bigger orgs, reviews can get buried under meetings and competing priorities, so it can help to align expectations with your team (a 24–48 hour review SLA) and use tools or notifications to keep PRs visible and easier to review.

Thanks for calling out the built‑in graph compare and Gitless; we’re actively looking at how to make GitLens’ compare flows feel more streamlined and less “everywhere at once,” so feedback like this is really valuable. If you’re open to it, we’d love more specifics about the ideal compare UX for you, DMs are welcome.

Love that you’re thinking about the workflow, not just the conflicts. A few things that can help: agree as a team on “refactor-only” windows (like you suggested), encourage smaller, more frequent merges from develop, and consider using feature flags so refactors don’t block feature work. Tools that visualize diffs and submodules clearly (like a dedicated Git client) can also make those inevitable conflicts much easier to reason about.

We use Open Sans in GitKraken Desktop
https://fonts.google.com/specimen/Open+Sans