Is Kepler good yet?

One of the programs I use quite often is GitKraken, in my opinion the single best Git GUI program. Yes, it's paid software for the full featureset like private repos, in comparison to something free like SourceTree but it's also performant, polished and plainly a joy to use, I'm happy to be their customer. Personally, I think more software should be like that!

In my opinion, version control is one of those domains where GUI apps are far superior to CLI ones, since you can review all of the diffs, stage things one chunk or line at a time if you wish and also immediately get a really nice graph view to understand things better - it's a problem space that's very well suited to a visual workflow.

It seems like those folks have also been busy, because this year they released an ADE (Agentic Development Environment) called Kepler, a program that's currently free for everyone, not just GitKraken subscribers. I'm not sure whether it will stay that way, because there are some other free options in this space like Paseo and also some other paid ones like JetBrains Air, but I gave it a fair shot a while ago.

It's been a while since I got the idea of writing a blog post about agentic development, though if I had done that a while back, then my mentions of Kepler would not have been as positive as today, because they've released quite a few updates since that improve the tool.

The other day, I got an e-mail from the devs, inquiring about hearing a bit more, about how the users actually use Kepler:

I might not have time for calls, but I figured what the hell, I might as well write up a quick blog post about what works and what doesn't, as well as the things I'd expect from an ADE in general. Maybe that will be helpful to anyone trying to create a tool like that too.

But first, I think we need a bit of a hierarchy to understand how the different tools fit together.

From the lowest level to highest, it's approximately like this:

• AI harness - OpenCode, Codex, Claude Code, Pi and others, the bits that actually handle interacting with the APIs on which the models are hosted, as well as expose tools to the models, letting them interact with the computer; which is basically the thing your agents will be running on, think of them like multiple sessions using the same underlying set of tools to interact with your computer and do work
• AI harness interfaces - OpenCode, Codex, Claude Code, Pi and others, the list is almost the same as above because pretty much every harness out there ships a way to interact with it directly, like a CLI, TUI or GUI; for example, you can open Claude Code by typing claude into your terminal, or alternatively by downloading their desktop app, though there's also the hybrid setup of having the UI be in the browser with their Remote Control, whereas something like OpenCode also can run its own server, meaning that you can expose it on your own infra, through Tailscale or whatever tunnel you want; often times there's also mobile apps for remote control too
• AI harness integrations - sometimes there's also 3rd party solutions that integrate with the harnesses through something like ACP, which gives tools a reusable way to talk to lots of different types of agents, but might not necessarily have as deep of an integration as, for example, OpenCode's own API; then again, that's why you'll see something like Zed supporting most agents out there on at least some level
• Agentic Development Environments - this is a relatively new group of software, that tries to orchestrate work across multiple agents of different types; the whole space sees lots of projects, but overall is pretty fresh and the software ends up looking both a bit samey and doesn't have that much to differentiate it, at least for now

We're mostly concerned with the last category today, because almost every ADE up until now works a bit like this:

• integrations with the various different agents, some common display of sub-agents, context sizes, model configuration etc.; the stuff that you'd also expect from Claude Code Desktop or the ChatGPT app with Codex
• sometimes there's support for switching the agent that will run the session, so you can for example start on Claude but switch over to Codex for review; sadly almost nothing lets you configure custom agents per-task, so you'd have to use OpenCode Agents directly for that, which sadly won't work with Claude because they don't give you an API key for subscriptions
• sometimes there's basic features for orchestrating agentic work with more parallelism, issue tracker integrations and other things like that, but it very much still feels like we're in the stage of people slowly figuring out what works and what doesn't

Those three points might seem fairly simple, but a lot of work goes into getting them working fine, and technically a good enough solution could easily replace using just two or more separate apps for Claude and GPT and other providers' models.

So, is Kepler actually good? What sets it apart from the other options?

Let's jump into Kepler

I ran a completely new install of the tool and played around with a few repos, so in general this will just be a quick feature tour with some nitpicks along the way. Nonetheless, it should be useful for anyone who's also curious about Kepler but hasn't used it themselves yet.

Onboarding

First up, the onboarding is good in the latest versions, it immediately brings you to the agent integrations and is pretty intuitive:

Unfortunately, as you can see, it didn't pick up my Claude and Codex desktop app installs - where the harness isn't installed separately like so, but rather installed with their corresponding desktop apps, which ship the same harnesses, but not in a way where the tool picks them up on its own.

Harness detection

That's the first snag that might make me want to leave immediately, because I don't want 2 versions of each harness and to have to do a /login within the CLI only harness, since those logins aren't shared between the two versions. I think I will track what I'd like changed in the post, so it'd be easier to follow along.

Issue #1: Kepler should support desktop app embedded versions of the harnesses as well - Claude Code Desktop, ChatGPT App, OpenCode Desktop and others.

For more context, here's where the various types of installation put their executables on Windows:

It would be really nice if I didn't have to install the CLI versions separately, if the harnesses (and their auth setups) are already bundled with the desktop versions, Kepler would benefit from detecting those and allowing using them automatically.

Either way, it wouldn't be much of an exploration if I quit now, so I proceeded.

Onboarding, part 2

We also got the option to choose between the native terminal views of the agent UI (which is a nice inclusion) and a custom chat format with diffs, basically a recreation of the other GUI apps. Overall, I very much like that choice up front:

After that, we got the choice to bring in our existing repos, though if you don't add one here, you can just bring it in later manually:

Then there was also some UI customization and the ability to set your notification preferences upfront as well, another great addition:

Frankly it's one of the better onboarding setups I've seen recently, all they might do in addition to the current setup is maybe add a button to go directly to the full settings for the users who want that.

Then, there's also the issue tracker integration, one of the things that Kepler does better than any other solution out there:

The idea is pretty simple - the majority of your sessions and tasks (that may span multiple sessions) will probably come from some Jira issue, or whatever you use for your work tracking. This means that if your ADE integrates with the issue provider, eventually the work on them might be as simple as choosing multiple items from the tracker, clicking "Plan" on them and then reviewing, iterating a bit, before sending them off in parallel to implementation, each getting a worktree if multiple per project.

In other words, when the work is suitable enough for agents to do (possible to detail well and testable), you can turn your SDLC into a bit of a factory, provided that you use models that are also good enough. You don't have to necessarily do large scale work that way, but it's really nice for small bugs and quick feature implementation, especially when working on multiple ones in parallel.

Starting work and configuration

It might sound a bit technical, but the onboarding remains nice and smooth when you get around to creating a new task too, to the point where there's not that much of a steeper learning curve to Kepler than any of the other GUI options out there. Once more, that's lovely to see:

In contrast to how most of the tools used to work a few months ago, you are allowed to select multiple separate repos to form a workspace for the agent:

This part I found a little bit annoying, because why on earth would I have to click "Add" on an item I've already selected the path for.

I think nicer UX might be two options: a checkbox that you can toggle for selecting repos and a trash icon to remove unwanted repos/folders from the list. Of course, some consideration might need to be given to supporting multiple worktrees for the same repo for the same task (e.g. running 3 experiments in parallel on the same repo).

Issue #2: The repo selection could probably be streamlined a bit more, checkbox/delete instead of add/cancel after something is selected. Happy path would mean you just select something once, it has a checkbox in the list, you don't need to confirm the choice a second time, fewer clicks.

Also, there's the ability to make a worktree right there, which is lovely, but I only saw existing branch selection or worktrees:

Why isn't there the ability to create a branch and switch to it within the same worktree instead of creating a new one?

For example maybe for my task I will only work on this one repo and to keep things simple, I don't want a separate worktree, but rather to just create a feature branch there directly, switch to it and work there, in the current working copy.

Issue #3: You might want to create a branch without it always getting a worktree, instead just switching the working copy in the main repo to a newly created feature branch.

Either way, you can also switch agents before starting a task once you've chosen where and what to work on, getting a nice and fairly consistent user experience, regardless of what harness you will actually use. You can set the automatic work mode so you don't get asked for permissions, or keep the permission prompts around, change the models, the reasoning levels and even toggle what MCPs are enabled:

If you dig around the settings, you will even notice features not just in regards to your usual display on each subscription's limits, but also a feature that allows you to automatically restart the work should it run out of your limits (for example, the 5 hour ones Anthropic has). This is actually a really nice feature, especially if I schedule some work overnight and go to sleep:

That way, when I come back, I won't just be met with a stupid-ass message like "Limits reached" and no further work, but Kepler will take care of picking the work back up once the limits reset. I can't help but wonder whether these retries also apply to something like model overloaded errors and similar things like that - at the very least, having one checkbox for those would be nice, albeit with a limited amount of tries before giving up (exponential backoff, anyone?).

Agent configuration

If you dig around a bit more, you can find settings for the default agent that you prefer, as well as the default branching preset, which makes me reconsider the prior UI labels that said that a new branch would always create a worktree, a bit of a mismatch there, since the "New branch" option is basically what I wanted under Issue #3:

There's also the ability to set per-model defaults, including the model to use, as well as effort, fast mode (where supported) and so on:

I did miss the feature of letting me configure custom context sizes though, because with Claude I've found that cache reads really add up and it's much better to use something closer to 420k in practice, with a command like:

/autocompact 420k

I'm pretty sure that Codex should also have a similar command, but I can't remember what it was, apparently there's model_context_window and model_auto_compact_token_limit in their ~/.codex/config.toml file, though I'm not sure about the ability to set it per session, whereas Claude Code does support per session overrides for it with CLAUDE_CODE_AUTO_COMPACT_WINDOW.

According to this, the OpenAI equivalent would be like so:

codex -m gpt-6.1-sol -c model_context_window=420000 -c model_auto_compact_token_limit=400000 ...

I don't want to have to set that manually, having a GUI preset across all of my agents would be a godsend!

Issue #4: It would be really nice to be able to configure custom model context size limits in the agent defaults/presets.

Custom actions

In contrast to some other tools, Kepler also has the concept of various Actions, basically the types of work that you might want to do: to tell a model that it should do a round of planning at the start, eventually do the implementation work, and when working with merge/pull requests, either do review or address the feedback from others.

Normally you want to at least occasionally be in the loop yourself, but when the tasks are simple enough, you can quite reliably cruise along by preset actions like these.

Personally, I've found that the best way to do review of agent work, is to delegate to a sub-agent which would do an adversarial review loop:

1. an agent does the implementation work, and eventually is ready to commit because it believes the work to be done
2. it spawns a sub-agent with clean context and gives it both the task description (often a plan file), as well as tells it to flag issues, this works better in practice than the main agent doing the review itself, because with a clean context and a singular task most models (even SOTA ones) seem to perform better, they don't have that "false confidence" in the existing implementation that a model with the work context has
3. once the sub-agent (or sometimes parallel agents) return output, the main agent can do fixes, and then go back to step 2 for another review round, until they come back clean and there are no outstanding serious issues found
4. in practice, a commit only gets made when the review is clean AND all of the tests and tooling pass, this means that work is reviewed at each step of the overall task and leads to pretty good outcomes in practice

This probably could also be written down as a skill for the various harnesses, or maybe something that Kepler could inject regardless of the harness used (because OpenCode and Codex and Claude Code all have slightly different ways where and how they expect skills to work, same as how for the longest time Claude Code would only take instructions from CLAUDE.md, before eventually patching that in to also accept AGENTS.md).

A tool that lets you not think about the specifics of the individual harnesses, is actually pretty great in this regard! As you can see above, you can even create a session without starting the work, which is especially great for spawning let's say 10 sessions and just playing around with what you think would or wouldn't fit within scope, what you want to address now and what later, without keeping track of the overall "backlog".

Some more customization

In addition, there's a nice amount of additional customization that you can do with the UI:

You can adjust the conversation width and whether to scroll down with the AI response, as well as change the font and size:

In a word, there's pretty much everything I'd expect in a tool like this, which was a pleasant surprise - adequate amount of thought has clearly gone into this version and you can make the tool feel like your own!

Remote access and automation

They also have support for their own version of remote access, which you can access through their website:

I didn't try it out myself, but it's nice that it's also something they support, which you don't need to set up per-harness but can let the ADE handle it.

There's even some experimental task support, where you can schedule recurring tasks, or kick off new tasks based on events:

I'm reminded of projects like Hermes or NanoClaw: while Kepler appears to be very software development leaning, all they are missing is integrations with WhatsApp or Telegram and then they can also turn Kepler into a personal assistant, because most of the building blocks already appear to be there. For example, if you control the Codex harness through Kepler, you also get support for computer use too.

Frankly, I can't think of many reasons why Kepler couldn't also be a general purpose AI assistant, not just a software development tool - especially since it can delegate tasks to different harnesses, or even across multiple machines. To that end, maybe they'd just need to streamline the tasks view.

The regular work experience

They do also have a kanban view for the various tasks, with status cards, to indicate what's being worked on, and what's being reviewed, is done, or put off until later. What upset me about that setup previously was that there was no apparent UI around changing those statuses, but there is now, alongside them being automatically nudged along for the most part:

One thing I did find a bit odd, is that they chose to add their own custom notes mechanism. On some level, it makes sense: for example, if working across multiple repos, you'll need agents to be able to exchange information and it's not guaranteed that all of the agents will be able to freely work outside their harness assigned workspace folder, nor will every project have a setup that has folders like plans/ and sessions/ like most of mine do, so it's not an entirely bad idea to have this sort of mechanism in place.

At the same time, unfortunately that also means that these notes/resources do only live within Kepler (unless you manually save them) and if you launch something else that isn't aware of Kepler, it won't be able to access any of this information. Because of that, I'm not the biggest fan of the mechanism, even though I roughly understand why they chose to go about it that way.

I'm also not a fan of the silly button to open the menu taking up an entire vertical row, which wastes whitespace:

Fixing it wouldn't even be that difficult, for example see this masterful Paint.NET sketch:

Issue #5: Resources open button should not take up a whole row alone, it might be moved to the left of the git status line.

If you glance at the actual session that I was in the middle of, you'll also notice something interesting - I was working on reverse engineering the software a little bit, to see if they'd also support the basic issue tracker that's built into Gitea (actually I couldn't find a more exact documentation page, though Forgejo which is a Gitea fork has their own page). It actually seems that the basic provider support is in place, it just doesn't seem entirely finished, so isn't available for now. I considered whether hacking around a bit more would be a good idea but it might just be better to wait for proper Gitea/Forgejo support.

Issue #6: Gitea and Forgejo have their own issue trackers, being able to integrate with those (or even custom providers/having plugins for Kepler) would be really nice at some point down the road.

A thing I really did like was the prose, how text and tables are rendered within Kepler. Personally, it's one of the better options out there and I could see myself using the tool daily because of it, the styling seems very well put together and the layout just works:

See that? Good text spacing, tables that don't waste too much space (though a copy button both for entire messages and individual tables would be useful), proper link render and also support for quotes in the text input box, alongside code blocks too, neither of which felt broken or anything!

In that upper status line I showed before, there's also options to open the current repo in both GitKraken, as well as text editors or whatever your default app is, alongside being able to open it both in the file browser and terminal - exactly the tools that you need, and nothing that you don't:

My only real complaint there would be that the icons are a bit small and it might not be obvious what is located where. For example, the branch name shows up on the left of the repo name, whereas the branch name related options are on the right of both of those:

The options themselves are really nice, but maybe review the ordering.

Issue #7: The buttons for opening a repo with GitKraken and editors like Zed, alongside the repo related options might need some work to make them a bit more prominent, because on a 1080p screen they look very small and are a bit hard to click on, the icons are small too. The ordering might need some work too. Consider a button group sort of look (full height in relation to parent element).

Data privacy?

Here's also a nice example of being able to toggle code wrapping inside of code blocks, as well as copy the blocks themselves, also really nice! Might use those options for tables as well (e.g. copy the Markdown text of a table, or maybe in a format that something like LibreOffice or Excel will understand, that would be really nice, maybe some day even things like sticky rows/columns and scrolling for tables):

Here you can see the exploration results, where Kepler presumably sends the PAT when you integrate with a Jira DC install to their cloud platform.

Unfortunately, this means that I couldn't set it up with an on-prem Jira instance, because it's plainly unacceptable to share either the domain or PAT, and definitely not both. If the exploration isn't wrong, then there probably should be an option to not upload that data to their cloud platform and instead allow keeping it all local in environments that are security conscious, otherwise Kepler is plainly a non-starter in regards to its issue tracker integration.

Issue #8: Review whether it's possible to set up a Jira DC issue tracking integration with both the domain and PAT never leaving the local machine outside of talking only to that Jira DC instance directly. Same principle for all self-hosted integrations.

Additional UI features

Aside from that, there's some more cool stuff, like you see information about your context and the cache hit rates right there:

You also see information about your particular subscription (at least Codex and Claude Code that I tried, no idea about ones like Kimi or GLM):

Kinda crazy that you can even redeem a reset right there, if you have some of those available. I didn't expect that deep of an integration, given that the providers have different types of resets and that's probably really annoying to handle - for example, how Anthropic was recently handing out Fable-only resets to get more people using it.

There's also the Agent Graph feature that I previously admittedly lambasted as AI coded slop, because the earlier iterations of the UI didn't feel as polished as the current one and it felt odd that time was spent on features like that, instead of getting the core of the software rock solid. It's still there, for what it's worth:

I'm not sure if I'm going to use it much at all, but they have added a task overview pane to the side:

Personally, that has more value than any sort of fancy graph visualization, especially if it'd be possible to expand this and get a per-tool breakdown, to figure out where the hell my subscription limits go.

If the folks behind GitKraken wanted to have a look at some of the best options out there, I found the Kimi Visualizer tool to be plainly more useful than anything else out there to date. Sadly, I'm not using Kimi at the moment, but if you're curious, I suggest you install it and after letting the model work on some task for like 4 hours give it a look, the visualization was really useful. Not just what's going on right now, but rather what the main agent and all of the sub-agents worked on, how many tokens were spent, and so on.

Here's an ancient screenshot that I dug up, I think such tooling should exist for pretty much any harness out there:

I don't have the screenshots here, but basically you could dig into every sub-agent if you wanted to, their visualization tool did give you a whole bunch of granularity and insight into how your models were performing together with the harness.

Some annoyances

I did find one annoying bug, though. See how we have the quote followed by some regular text, right:

The underlying Markdown is basically this, ">" on the first line, followed by some regular text lines:

The problem is that most Markdown renderers out there mess the rendering up and make the quotation block swallow all of the following lines:

I feel like that's just a quirk of Markdown, but at the same time the text composition view looks "correct" so the discrepancy itself is probably a bug.

Issue #9: Writing text on the next line after a quotation block will later make it render as one big quotation, instead of quotation followed by a regular line of text.

I did also observe that Codex could take advantage of its regular computer use, however trying to use the built in browser basically failed. I feel like this is where we hit a limitation of most of the harnesses and their limited interop - because both Claude Code Desktop and Codex come with their own integrated browsers that you can open as a sidebar pane, but good luck getting those working well in 3rd party tools.

On some level, I feel like that's just a limitation of how all of these tools are integrated, since it feels like Kepler would have to work on their own browser integration and then probably try to get it integrated (as an MCP?) with all of the supported harnesses, which feels unnecessarily complex and basically like a gargantuan effort, with no idea of even how viable that would be.

Interaction between sessions

A feature that's really cool is their support for multiple sessions under the same task:

For example, if I have a main task that's working on the project and doing some changes, but I want to spawn an adjacent one (still under the same task, with its context and directories and all that, but maybe with a different agent), I can do that quite easily. That's another thing that I think is really nice to be able to do, since that still keeps the adjacent sessions grouped together, almost like the sidecar concept.

The task context mechanism also allows sessions to exchange messages between one another:

Here's also an example of the shared notes, that the agents under the same task can read as well:

And here's the note contents:

I think those are Markdown files in some internal directory, though personally I think it might be nice to be able to save those within the project.

Issue #10: Consider whether it might be good to provide an option to the user, to automatically save resources/notes in some project directory, or expose tools to do that automatically (agent decides where exactly).

Interesting thing, your sessions do get registered in Codex:

And I didn't double check with Claude Code, but at least Codex seems aware of external tools like Kepler, pretty nice:

The overall UI structure

What I don't enjoy as much, though, is the fact that there's an additional view. You can click on a session in the main view to open an individual task view, which replaces your list of tasks with a sidebar of this particular task's sessions and changes and the notes:

I'm not sure when I'd want it laid out like this, because I can already access all of those as the horizontal tabs at the top, in addition to this fucking with my ability to easily swap between the tasks - since I'd need to press the back button, and this also doesn't show a new tab at the very top of the program or anything (e.g. next to Tasks), which is just a tad jarring.

Issue #11: Consider whether individual task view even needs to be a thing, whether its left bar couldn't just be a docked panel below the main task list that can be conditionally brought up, alongside allowing Git change and other side panels (like file content previews) to be opened from within the main tasks view, while a task and its sessions are selected.

Maybe I'm not explaining it perfectly, but here's a quick sketch:

Obviously you wouldn't see everything all the time, the purple section would be hidden by default and only opened when needed, while above the tabs you could still have the Git status bar (or have it be just a tab), or any other number of options. I just feel like that additional level of nesting isn't really that useful and just ends up being confusing - why would I use that and sacrifice my ability to easily switch between the different tasks?

Meanwhile, there's no real reason why you couldn't have a right sidebar in the main window as well, which could conditionally show either the sub-agent sessions (like Claude Code Desktop) or allow previewing file contents, or anything else like that. Make the sidebar contain two tabs if you want, maybe even support custom docking (the top/bottom layout in the sketch), there's lots of options to show additional information for those that want it, while keeping things simple.

Here's an example of what the current Claude Code Desktop version looks like, by the way:

And if you want, you can open additional detail views:

Frankly, I'm not the biggest fan of this iteration, because they end up with three (or more!) columns, whereas previously the sub-agents were just an expandable section in the main right sidebar - which I think actually worked way better! Either way, being able to see what executed, as well as any and all other relevant information in one sidebar is really nice.

What's missing there is support for tabbing/docking - technically, the sidebar itself could easily be tabbed, to allow you to switch between the status display, file previews, or file browsing. I think Visual Studio Code did it really nicely and tools like Zed also allow you to drag things around, though in their UI sadly it's still limited to some elements only supporting docking left and right:

Either way, people will have their own preferences and having a fairly minimalist and non-overwhelming layout by default is probably a really good idea, with optional support for people expanding more of the UI as they choose. To me, that would be the main session list on the left, tabs of sessions in the main section, and any and all additional information (sub-agents, file navigation, file browser) in any other number of arrangements to the right.

Personally, also not the biggest fan of the Kepler sub-agent display, they just show up as small pills at the bottom of the agentic window:

Issue #12: Consider whether it might not be better to have a sidebar for the sub-agents, a bit like how Claude gives you a summary of those, instead of just pills at the bottom that don't seem as helpful. Secondly, consider whether it's MAYBE possible to allow some interaction with the sub-agents as well, e.g. messaging them directly, stopping them, that kind of thing.

Another really annoying quirk can be seen here. See those two links:

One of them leads to a regular webpage, all is good there. However, the other link is a file. When I click on it, the normal behavior I'd expect from any agentic GUI tool is just to have a sidebar open, where I can read the file contents. That's not what happens here, it completely messes up my UI by going into a full individual task view, and not only that, but also shows a file browser in the middle that I didn't ask for, leaving only a bit of space to the side for the file contents:

If most of the UI feels decently thought out now, this one interaction is what I'd still describe as "vibe coded crap", because I need to preview files quite often and me being taken to the individual task view and not even getting what I want properly there feels jarring and odd. Like, I didn't ask for the file browser to cram itself in the middle of my screen, or to be brought into the individual task view, all I wanted was just a sidebar with the file preview (and ideally a button to open the folder that the file is in, not just copy its contents, MAYBE also a target icon similar to IntelliJ to open the built in file browser with the file focused when it's pressed).

Issue #13: Clicking on a link to a file probably shouldn't open a completely different view (e.g. going from an open task in the tasks main page, to an individual task view), nor show an uncalled for file browser in the middle of the screen which limits how much space is left for the actual file preview.

Message steering vs queueing

Here's another case, where I found that Kepler isn't really able to reproduce the user experience of something like Codex. In Codex, there's an option to have your additional messages guide the further generation by steering it. Essentially, they don't get queued in a way that waits for the full agentic turn to be over but they get sent to the model ASAP:

Instead, Kepler only seems to support message queueing instead of steering, which is a bit of a gap:

Issue #14: Consider whether adding support for steering would be possible for follow-up messages, instead of just queueing. Furthermore, consider adding the ability to switch queued messages between being submitted one at a time when possible or all at once. For example, the user might queue messages A, B and C and they probably should have a setting to choose between them being submitted like:

• work --> A --> work --> B --> work --> C --> work (one at a time)
• or just work --> A, B, C --> work (all at once).

Repository trust

Another rough edge was repository trust. I created a new task like normal after installing Kepler on a laptop, and then got an error while trying to start the task:

First up, why couldn't I just press one button to make the repository trusted?

Issue #15: You should be able to make a repository trusted the first time that trust is needed, instead of getting an error and just being told to go to the settings.

Secondly, I opened the settings and saw a long list of repositories, where it seemed like the only way for me to trust them was one at a time:

Do you have any idea how insanely annoying it is, when you have let's say 50 repos and have to trust them one at a time, where clicking the back button also scrolls the list up to the beginning?

Issue #16: It should be easy to add trust to multiple repositories at once - maybe with checkboxes in the repository list. Alternatively, a button where the "Untrusted" chip currently is, to easily add the trust to a repository. And clicking on the back button from a single repository view probably shouldn't scroll the repository list to the top every time when returning to it.

Multiple accounts

Lastly, I hate having to switch between multiple Codex accounts (for example, a private one, a work one, or just multiple private ones), so I was delighted to see that Kepler allows you to add additional accounts:

Except the button didn't actually do anything and I couldn't add a second Codex or Claude account. There were also some issues about me not being able to find an easy way to set the default preset to use/select whenever I want to use Claude or Codex and switch between the harnesses. Instead of just one default agent preset for every new session, it would be nice to set the default presets per agent - e.g. "Here's the preset to always use when Codex is selected at first. Oh and here's the preset for Claude Code that you should use."

Issue #17: Check whether adding accounts works correctly. Also check whether it'd be possible to allow not only one global agent/preset for all new tasks, but also a default preset for whenever a specific agent is selected.

Frankly, that's quite a few features, as well as quirks. So, what are my overall impressions of Kepler?

Where does all of that leave me?

You might think that I'd dislike a piece of software if I'm this nitpicky about it. Not so at all! Compared to the first time I used Kepler, this time was actually quite pleasant and I was happy to see it improving at a nice pace - whereas the first time I just saw potential, this time I saw features taking shape and the overall tool getting more polish. There were very few things that I'd classify as "glaring oversights" and almost nothing was broken.

I would definitely recommend Kepler to someone who's new to the ADE group of tools because of the nice onboarding, alongside maybe something like Paseo, because that one also has a really nice UI and UX, even if it doesn't aim to be quite as featureful. Kepler's issue tracker integration is really nice too, even if I didn't show it here this time, due to not wanting to risk hooking it up to Jira DC if it really sends the credentials to the cloud. I have used it in the past with GitHub, though, and it performed pretty well there.

Now, will I be using Kepler myself as my main daily driver? About that, I'm not sure yet - there definitely are a few snags here and there, and UI choices I'd make differently, but the tool itself is pretty nice. That said, it also feels like sometimes the harnesses don't really play all that nicely with various 3rd party tools, such as the integrated browsers not working, and there's also features like Claude Code's sub-agent/task/workflow UI that I think are still superior to Kepler.

GitKraken I'm definitely daily driving, but for now I'm still spread out across Claude Code Desktop and Codex, due to some of their features like built-in browser, though I'm growing increasingly convinced that a good enough MCP/plugin could replace both of those, alongside something like the Kepler Actions/skills that would work across multiple harnesses as a regular prompt template (or just feed in .agents/skills to Claude). Because of wanting a single tool like that, I'll probably eventually check back in to see how much better Kepler will have got and whether I want to give it another shot.

But all in all, the answer to the original question of:

Is Kepler good yet?

At this point, it would be a pretty simple "Yeah, it's pretty good!".

Not perfect by any means, but it feels like they're on the right track. I might try daily driving it at some point.