I strongly resonate with the problem statement, but this implementation was very far off the mark for me. Every interaction feels bad.
I fired it up, and the first thing I notice is that the arrow keys don't work. I can't select Claude Code. Oh, apparently it's in a different control, so I have to press Tab, and then the arrow keys work. Wow, this list of buttons has a slow scrolling animation when navigating it. Can I turn that off? Press enter on Claude, now I'm in a tiny modal window. Press enter, because I want to do the obvious thing, but apparently the obvious thing is "show in launcher", so the background of the modal is weirdly changing while a tiny single character inside the button is indicating that this is the part I'm supposed to be focusing on. No, I want to do the obvious thing of running Claude code. You could easily fit the 4 actions of this form on my screen, but by choosing to use a tiny modal window you're now forcing yourself to use another modal drop-down control to choose the action and a separate "yes actually do it" button, so the OBVIOUS ACTION of RUN THIS AGENT requires pressing tab, enter, down, down, down, enter, tab, enter. Great. Now I'm at a chat interface with an error screen, because it isn't installed. Quit the program, restart, enter, tab, enter, down, down, enter, tab, enter to install. It shows a successful run of the "ACP adapter" for claude. Shift-tab, enter, down, enter, tab, enter. Now I'm back at exactly the same error screen because apparently the install didn't work. Now, I know that you need to be running "npx @zed-industries/claude-code-acp", so I check the docs and apparently I can "toad run COMMAND". But it doesn't work for multi-word commands. And my trial with toad comes to an end.
So I can't test it for anything actually useful right now, but I'll add this to my list of projects to watch. Hopefully, being a UX-focused project, the creator actually focuses on the UX and fixes some of these silly decisions.
This has been my experience also, so far. I like a lot about this and want to start using it, but beyond the initial awkwardness of key bindings feeling wrong, it just seems a bit too early for me. For example, most of the agents I tried to get working on my Arch system failed to connect, only Claude Code and Vibe worked. Most worked on MacOS (except Codex, even though it's installed on my system). But I need to be able to set the agent into Bypass Permissions mode, and when I do, I'm still constantly prompted with permissions checks. There also seem to be weird errors caused by fish shell. I'd also really like to be able to define my own custom agents (eg one use case I'd like is to be able to launch Claude Code but swapping out the Anthropic endpoint for OpenRouter's so I can try new models using CC's agent harness).
It's possible this is just part of the learning curve, but it is making me think I'll have to come back to this project in a month or two to see if there are fewer pain points. Great work so far though.
> Pretty sure you are a troll < OK, I'll come clean: I knew what Textualize is before I even evaluated toad, and have never to date found a Textualize app that "sparked joy" as it were. But I figured I should try Toad anyways since A) I strongly resonate with the problem statement of Toad and B) surely the creator of the library would create a best-in-class implementation using that library. Also, https://news.ycombinator.com/item?id=45912796
> If you don't like the keyboard control, you could always just use your mouse to click stuff. < You're reading me backwards. I like keyboard control, but feel like Textualize is a mouse-first UI library. Pressing arrow keys when launching Toad does nothing because I'm not in a "control". As a user, I am supposed to intuitively know that "Recommended" and "Coding agents" are "different controls" and so it should be obvious to me that the arrow keys would not navigate between them?
> 100x20 characters IIRC < You have 20 lines to work with and you decided to shove 4 of the 5 actions for the form into a modal control within the modal dialog. That's my point.
> Which is displayed prominently in the footer. < That's rich. You dedicate 3 lines to the "show in launcher" button and a "Go" button and say the one line at the bottom of the screen is "prominently". Also, that message isn't even on the opening screen of the app, presumably because I have a flawed understanding of what a "control" is.
> I don't think you were interested in fixing it, as you would have mentioned an error message.
No, the error message was perfectly clear! That's how I knew the solution. "Agent returned a failure code: 127 - /bin/sh: claude-code-acp: command not found" The solution is to run via npx.
> It does work for multi-word commands. But if your command contains a space you will need to wrap it in quotes. < You are wrong.
$ toad run "npx @zed-industries/claude-code-acp"
Not a directory: npx @zed-industries/claude-code-acp
> I imagine you don't work in the terminal much? < Please don't blame your users for uncovering bugs that your coding agent put in that you didn't catch in review.
Anyways, go take your sabbatical, relax, you need it. I do genuinely want a better CLI interface for my coding agents and what you said elsewhere that the landscape is "like building a browser for a single website" is very true. Hopefully you come back with fresh eyes and can make a compelling offering in this space.
Not saying there isn't room for improvement. This is the first release, and work is ongoing. But I can't predict everyone's assumptions. Everyone brings their own experiences to the table, and in 6 months of testing nobody has made assumptions you just did.
For instance, "toad run" takes a path to a directory and not a command (check the usage). You've made an incorrect assumption about how that works, based on previous assumptions on how the UI works.
I would be like to understand why you made the assumptions you did, and make changes based on your feedback. But you've chosen to be combative, for reasons known only to yourself.
For the record, I apologize for the "Mr cranky pants" quip. If you do want to improve this software, join the Discord. Let's keep it civil. Merry Xmas.
From someone who has not tried the software but might be interested if it gains traction:
You should decide whether you are building this for yourself or as a product to others. Each stance is perfectly valid but are somewhat not compatible, the software can be very opinionated or intuitive but attempts to be both seem to often fail.
If you are building opinionated software for yourself and are ok with alienating a part of the userbase: great, some great software are built this way! (Alacritty, Kakoune come to mind).
This should be clearly communicated to prospecting users though, it may need to convey "this software has strong opinions you may not agree with, that's fine but it may not suit you" somehow.
If you aim for maximum reach: expect your sense of what is "intuitive" to constantly be challenged, and to have to make many difficult compromises. You also need to take feedback from a more forgiving angle, and above all, assume good faith from your users. In this instance, GP stated their enthusiasm for your shared vision of the problem space, and your knee-jerk reaction was calling them a troll.
Builders of opinionated software should pay trolls no heed and refrain from engaging, and builders for maximum reach should think trolls don't exist.
footnote: `toad run` expecting a folder and not a command seems to fall in the "opinionated" ballpark
> Everyone brings their own experiences to the table, and in 6 months of testing nobody has made assumptions you just did. < As an experiment, try disabling the app's mouse support and testing it.
> For instance, "toad run" takes a path to a directory and not a command (check the usage). < I stand corrected. I think I was confused because I read this comment <https://news.ycombinator.com/item?id=46370722> ("toad acp COMMAND") and substituted "toad run COMMAND". I saw in the usage that it mentions "PATH" without specifying what it is the path to, and does include a "--agent" flag but with no explanation about what it does. This level of documentation is far from what I would call good, but I'll give it to you that I could have figured that one out. ([append] `toad run` isn't even the right command and as near as I can tell --agent does nothing. But `toad acp` is what I actually wanted and finally I can actually test the app)
> But you've chosen to be combative < My post was snarky but my experience was honest. I don't think I'm being combative. I certainly don't intend to offend you as the creator of the tool, regardless of whether or not I think the tool is high-quality in its current state.
Merry Christmas, I will continue to watch this project. Maybe I will open a discussion in the Github if I end up successfully able to use it with my newfound understanding of the "acp" subcommand.
Very much still around... and one of those "this (the terminal tool the HN post is about) might have some trademark challenges" given that every license of TOAD (Tool for Oracle Development) is bundled with some AI and the likelihood of confusion and overlap is quite real. ... and Quest really likes putting that ® after every mention of it.
Very excited to see this come out - though coding agents are impressive their UIs are a bit of a mixed bag.
Textual offers incredibly impressive terminal experiences so I'm very much looking forward to this.
I wonder how much agentic magic it'll be able to include though - Claude Code often seems like a lot of its intelligence comes from the scaffolding, not just the LLM. I'm excited to see!
Hope you like it. It is still Claude Code doing the work. Toad talks to the agent, and is the agent that works with the LLM. So the results should be identical to the native CLI.
I have written a coding agent which I plan to open up soon. By far the biggest time sink has been in the TUI - I've just implemented ACP and I really hope that I can use toad as a front end.
Toad looks really nice, I will definitely try it out. I have some ACP questions if you don't mind.
First, from my reading of the ACP doc, one thing that seems pretty janky is if the ACP client wants to expose a tool to the agent, e.g. if Toad wanted to add the ability for the agent to display pretty diffs. In the doc they recommend stdio to the ACP server, then stdio to an MCP server, and then some out of band network request back to the ACP client. Have you thought about this, or found a better solution working on Toad?
Similarly, it would be useful to be able to expose a tool which runs a subagent using ACP using a different agent, e.g. if I'm using Claude for coding but I'd like to invoke codex for code review. Have you thought about doing anything like this? Is it feasible over the protocol?
I don’t follow your first question. Toad already displays pretty diffs. MCP works in the same way as the native CLI.
One of the advantages of Toad is that it is vendor agnostic. In the future Toad will be able to run sub agents, and allocate any agent to any job. Still to figure out the UX for that.
In my first question, I'm referring to exposing functionality from the ACP client to the agent. Imagine an IDE ACP client which wants to expose language refactoring to the agent, for example - I can't think of a better example for something more like Toad. As far as I know the protocol doesn't expose a way to inject tools into the agent from the ACP client.
The ACP protocol supports MCP. That would be how the client provides additional functionality for the agent. There's no UI in Toad for that yet, but there will be in a future update.
1. How has it been working with ACP? Is it anywhere near feature parity with Claude code’s native interface?
2. I see your repo is written in Python which is interesting to me for a responsive TUI. Is it snappy and performant and if so what gave you done to make it feel native? And why did you choose Python?
ACP is will designed. It will always be a few features behind the native CLIs as the protocol catches up. But there is very little that you can't do with ACP. A lot can be done with slash commands that are passed through to the agent verbatim.
Python is more than capable of running a TUI. It is just text manipulation after all. Toad uses Textual, which is currently the best TUI library around. I may be biased saying that as I built it...
I was about to try opencode after using claude code for quite a while.
I think understand the fundamental difference in how they work (acp against existing agentic loops with toad vs a single agentic loop for all models with opencode) but I’m curious why we might want toad over something like opencode, which lets me use any model under the sun.
I suppose toad gets to use the highly specialized agentic loops for each cli. And has a nicer (? opencode is pretty slick from my brief usage…).
Curious to hear about why you chose to built this way and what advantages you see.
It’s stored statically in the Codebase. In the future, I suspect there will be enough compatible agents that there might be a web service to search them.
I think they are working in the Copilot ACP layer. Doubt it will take long.
Sorry, not a question, just wanted to say congrats on putting this together. I am so the target market for a nice terminal interface. I can’t wait to try this out!
The author is also the creator of the textual Python library for creating TUIs. The performance benefits of Rust don't seem very useful in a tool where you spend a few seconds typing in a prompt and then 90% of your time is spent waiting. As long as the UI is responsive when typing there wouldn't be much of a difference.
Didn’t know that. Good reason then of course. But I do notice these sort of differences. Codex feels way better than Claude code to me for example.
I tried Toad and to me it feels ridiculously slow and laggy. Switching between input and output (ALT+up/down) for example just lags, I can notice the transition. The whole UI lags. It's no wonder, it's python. Simply the wrong language for this, sorry.
Yeah it feels slow and laggy to me too and I'm not on an old laptop. Running on a M3 Macbook Pro here. I definitely notice the difference between using something like Ghostty (Rust based - super fast) and Toad (Python).
It's obviously way slower though. Also the point stands, it's written in a low-level, performance-oriented language. The author of Toad could have written it in Rust, Zig, C++, etc, but chose Python instead. He valued ease of development versus performance and the result is we get a laggy terminal.
I know for a fact that Textual can generate an entire frame in less than a 60th of a second. Any lag you see has nothing to do with the choice of language. A TUI just doesn’t require that much number crunching to use a low level language.
I’d be interesting in knowing what platform and terminal you observed the lag, when testing Toad.
Maybe it's something on my setup then. I notice some delay even though it's by no means huge but noticable. For me these things add up, another example is pane resizing in tmux. I like things snappy, but it's kind of an OCD thing I guess.
The creator of Toad, made a TUI framework in Python (Textual). What is so special about Rust, aside from it being blazingly fast and compiled, that you want from it?
I tried Toad and to me it feels ridiculously slow and laggy. Switching between input and output (ALT+up/down) for example just lags, I can notice the transition. The whole UI lags. It's no wonder, it's python. Simply the wrong language for this, sorry.
Check out vibecommander - it’s a young tool in this space with a different take that wraps around CLI coding assistants with IDE-style file and git panels that compliment the experience by letting the human do the code review part of the task seamlessly.
Will add Toad support ASAP, I’m sure they’ll be great together.
You could also consider checking out vim, which solved this 50yrs ago ;) in all seriousness, you have terminals, splits, lazygit… so to me, it seems like this is a case of “not invented here”
Vim has a terrible user experience though. There's a reason everyone stopped using it as soon as they possibly could and moved to other text editors. Now the only vim users are the 60 year old+ greybeards who try to convince everyone they're such morons for not using it.
Stop trying to convince people to use vim, it sucks, it's got a terrible ux, it's not intuitive, it's overly complicated, hard to learn, arcane, and looks like ass.
I disagree, but I'm a 60 year old+ greybeard who has managed to get a bunch of other devs addicted to vim. My real goal is to keep the key bindings popular enough that I won't have to reprogram my muscle memory before I shuffle off.
This is absolutely awesome but the little jokey captions that Claude did (Discombobulating... Laminating...) all that stuff, they were a little annoying but cute enough, but whatever is running this one (I did not murder him... I thought I was special....) they are genuinely offputtingly bad. This great app doesn't need clunky humour front and centre, I'm not sure if it's Claude or toad but it seems markedly worse than Claude used to be.
Ah right so they are your quotes. No not enough that it wasn't quite a shock to spin up a cli tool and the first thing it says is "I didn't murder him" lol
I’m not a big fan of the name Toad, but the Textual framework is fantastic. I’ve been using it for years in a small project and it’s just a wonderful tool - it makes it really easy to get a super fast little UI for scripts.
I strongly resonate with the problem statement, but this implementation was very far off the mark for me. Every interaction feels bad.
I fired it up, and the first thing I notice is that the arrow keys don't work. I can't select Claude Code. Oh, apparently it's in a different control, so I have to press Tab, and then the arrow keys work. Wow, this list of buttons has a slow scrolling animation when navigating it. Can I turn that off? Press enter on Claude, now I'm in a tiny modal window. Press enter, because I want to do the obvious thing, but apparently the obvious thing is "show in launcher", so the background of the modal is weirdly changing while a tiny single character inside the button is indicating that this is the part I'm supposed to be focusing on. No, I want to do the obvious thing of running Claude code. You could easily fit the 4 actions of this form on my screen, but by choosing to use a tiny modal window you're now forcing yourself to use another modal drop-down control to choose the action and a separate "yes actually do it" button, so the OBVIOUS ACTION of RUN THIS AGENT requires pressing tab, enter, down, down, down, enter, tab, enter. Great. Now I'm at a chat interface with an error screen, because it isn't installed. Quit the program, restart, enter, tab, enter, down, down, enter, tab, enter to install. It shows a successful run of the "ACP adapter" for claude. Shift-tab, enter, down, enter, tab, enter. Now I'm back at exactly the same error screen because apparently the install didn't work. Now, I know that you need to be running "npx @zed-industries/claude-code-acp", so I check the docs and apparently I can "toad run COMMAND". But it doesn't work for multi-word commands. And my trial with toad comes to an end.
So I can't test it for anything actually useful right now, but I'll add this to my list of projects to watch. Hopefully, being a UX-focused project, the creator actually focuses on the UX and fixes some of these silly decisions.
This has been my experience also, so far. I like a lot about this and want to start using it, but beyond the initial awkwardness of key bindings feeling wrong, it just seems a bit too early for me. For example, most of the agents I tried to get working on my Arch system failed to connect, only Claude Code and Vibe worked. Most worked on MacOS (except Codex, even though it's installed on my system). But I need to be able to set the agent into Bypass Permissions mode, and when I do, I'm still constantly prompted with permissions checks. There also seem to be weird errors caused by fish shell. I'd also really like to be able to define my own custom agents (eg one use case I'd like is to be able to launch Claude Code but swapping out the Anthropic endpoint for OpenRouter's so I can try new models using CC's agent harness).
It's possible this is just part of the learning curve, but it is making me think I'll have to come back to this project in a month or two to see if there are fewer pain points. Great work so far though.
[flagged]
> Pretty sure you are a troll < OK, I'll come clean: I knew what Textualize is before I even evaluated toad, and have never to date found a Textualize app that "sparked joy" as it were. But I figured I should try Toad anyways since A) I strongly resonate with the problem statement of Toad and B) surely the creator of the library would create a best-in-class implementation using that library. Also, https://news.ycombinator.com/item?id=45912796
> If you don't like the keyboard control, you could always just use your mouse to click stuff. < You're reading me backwards. I like keyboard control, but feel like Textualize is a mouse-first UI library. Pressing arrow keys when launching Toad does nothing because I'm not in a "control". As a user, I am supposed to intuitively know that "Recommended" and "Coding agents" are "different controls" and so it should be obvious to me that the arrow keys would not navigate between them?
> 100x20 characters IIRC < You have 20 lines to work with and you decided to shove 4 of the 5 actions for the form into a modal control within the modal dialog. That's my point.
> Which is displayed prominently in the footer. < That's rich. You dedicate 3 lines to the "show in launcher" button and a "Go" button and say the one line at the bottom of the screen is "prominently". Also, that message isn't even on the opening screen of the app, presumably because I have a flawed understanding of what a "control" is.
> I don't think you were interested in fixing it, as you would have mentioned an error message.
No, the error message was perfectly clear! That's how I knew the solution. "Agent returned a failure code: 127 - /bin/sh: claude-code-acp: command not found" The solution is to run via npx.
> It does work for multi-word commands. But if your command contains a space you will need to wrap it in quotes. < You are wrong.
> I imagine you don't work in the terminal much? < Please don't blame your users for uncovering bugs that your coding agent put in that you didn't catch in review.Anyways, go take your sabbatical, relax, you need it. I do genuinely want a better CLI interface for my coding agents and what you said elsewhere that the landscape is "like building a browser for a single website" is very true. Hopefully you come back with fresh eyes and can make a compelling offering in this space.
Not saying there isn't room for improvement. This is the first release, and work is ongoing. But I can't predict everyone's assumptions. Everyone brings their own experiences to the table, and in 6 months of testing nobody has made assumptions you just did.
For instance, "toad run" takes a path to a directory and not a command (check the usage). You've made an incorrect assumption about how that works, based on previous assumptions on how the UI works.
I would be like to understand why you made the assumptions you did, and make changes based on your feedback. But you've chosen to be combative, for reasons known only to yourself.
For the record, I apologize for the "Mr cranky pants" quip. If you do want to improve this software, join the Discord. Let's keep it civil. Merry Xmas.
From someone who has not tried the software but might be interested if it gains traction:
You should decide whether you are building this for yourself or as a product to others. Each stance is perfectly valid but are somewhat not compatible, the software can be very opinionated or intuitive but attempts to be both seem to often fail.
If you are building opinionated software for yourself and are ok with alienating a part of the userbase: great, some great software are built this way! (Alacritty, Kakoune come to mind). This should be clearly communicated to prospecting users though, it may need to convey "this software has strong opinions you may not agree with, that's fine but it may not suit you" somehow.
If you aim for maximum reach: expect your sense of what is "intuitive" to constantly be challenged, and to have to make many difficult compromises. You also need to take feedback from a more forgiving angle, and above all, assume good faith from your users. In this instance, GP stated their enthusiasm for your shared vision of the problem space, and your knee-jerk reaction was calling them a troll.
Builders of opinionated software should pay trolls no heed and refrain from engaging, and builders for maximum reach should think trolls don't exist.
footnote: `toad run` expecting a folder and not a command seems to fall in the "opinionated" ballpark
> Everyone brings their own experiences to the table, and in 6 months of testing nobody has made assumptions you just did. < As an experiment, try disabling the app's mouse support and testing it.
> For instance, "toad run" takes a path to a directory and not a command (check the usage). < I stand corrected. I think I was confused because I read this comment <https://news.ycombinator.com/item?id=46370722> ("toad acp COMMAND") and substituted "toad run COMMAND". I saw in the usage that it mentions "PATH" without specifying what it is the path to, and does include a "--agent" flag but with no explanation about what it does. This level of documentation is far from what I would call good, but I'll give it to you that I could have figured that one out. ([append] `toad run` isn't even the right command and as near as I can tell --agent does nothing. But `toad acp` is what I actually wanted and finally I can actually test the app)
> But you've chosen to be combative < My post was snarky but my experience was honest. I don't think I'm being combative. I certainly don't intend to offend you as the creator of the tool, regardless of whether or not I think the tool is high-quality in its current state.
Merry Christmas, I will continue to watch this project. Maybe I will open a discussion in the Github if I end up successfully able to use it with my newfound understanding of the "acp" subcommand.
The name Toad gave me a flashback to Tool for Oracle Application Development, an IDE and debugger for SQL and pl/sql back in the 1990s.
90s? I used that solidly into the mid-2000s! Worked across more than Oracle, if I remember correctly, was the DataGrip of it's time.
I use Navicat in the early 2010s for the "cheaper Quest Toad" (a regular developer could afford a few of their tools) and before DataGrip.
2000s? Our EBS consultants still use it
Still going strong, https://www.quest.com/toad/
It's still around!
Very much still around... and one of those "this (the terminal tool the HN post is about) might have some trademark challenges" given that every license of TOAD (Tool for Oracle Development) is bundled with some AI and the likelihood of confusion and overlap is quite real. ... and Quest really likes putting that ® after every mention of it.
Very excited to see this come out - though coding agents are impressive their UIs are a bit of a mixed bag.
Textual offers incredibly impressive terminal experiences so I'm very much looking forward to this.
I wonder how much agentic magic it'll be able to include though - Claude Code often seems like a lot of its intelligence comes from the scaffolding, not just the LLM. I'm excited to see!
Hope you like it. It is still Claude Code doing the work. Toad talks to the agent, and is the agent that works with the LLM. So the results should be identical to the native CLI.
I have written a coding agent which I plan to open up soon. By far the biggest time sink has been in the TUI - I've just implemented ACP and I really hope that I can use toad as a front end.
It should be as easy as running: toad acp “command”
Does it work with local models? ollama? LM Studio?
you still need an agent, but yes.
I'm really looking forward to trying this out over Christmas break. Textualize is awesome for building Python console apps.
Me too. I am on a mobile device but I put the article link on my TODO list.
It would be a matrushka to run Toad in a Zed terminal.
Pretty sure I could run Toad in Toad, but I’m scared to try.
Hi. Will McGugan here. I built Toad. Ask me anything.
Toad looks really nice, I will definitely try it out. I have some ACP questions if you don't mind.
First, from my reading of the ACP doc, one thing that seems pretty janky is if the ACP client wants to expose a tool to the agent, e.g. if Toad wanted to add the ability for the agent to display pretty diffs. In the doc they recommend stdio to the ACP server, then stdio to an MCP server, and then some out of band network request back to the ACP client. Have you thought about this, or found a better solution working on Toad?
Similarly, it would be useful to be able to expose a tool which runs a subagent using ACP using a different agent, e.g. if I'm using Claude for coding but I'd like to invoke codex for code review. Have you thought about doing anything like this? Is it feasible over the protocol?
I don’t follow your first question. Toad already displays pretty diffs. MCP works in the same way as the native CLI.
One of the advantages of Toad is that it is vendor agnostic. In the future Toad will be able to run sub agents, and allocate any agent to any job. Still to figure out the UX for that.
In my first question, I'm referring to exposing functionality from the ACP client to the agent. Imagine an IDE ACP client which wants to expose language refactoring to the agent, for example - I can't think of a better example for something more like Toad. As far as I know the protocol doesn't expose a way to inject tools into the agent from the ACP client.
The ACP protocol supports MCP. That would be how the client provides additional functionality for the agent. There's no UI in Toad for that yet, but there will be in a future update.
Very interesting project! I have 2 questions:
1. How has it been working with ACP? Is it anywhere near feature parity with Claude code’s native interface?
2. I see your repo is written in Python which is interesting to me for a responsive TUI. Is it snappy and performant and if so what gave you done to make it feel native? And why did you choose Python?
ACP is will designed. It will always be a few features behind the native CLIs as the protocol catches up. But there is very little that you can't do with ACP. A lot can be done with slash commands that are passed through to the agent verbatim.
Python is more than capable of running a TUI. It is just text manipulation after all. Toad uses Textual, which is currently the best TUI library around. I may be biased saying that as I built it...
Hi Will,
I was about to try opencode after using claude code for quite a while.
I think understand the fundamental difference in how they work (acp against existing agentic loops with toad vs a single agentic loop for all models with opencode) but I’m curious why we might want toad over something like opencode, which lets me use any model under the sun.
I suppose toad gets to use the highly specialized agentic loops for each cli. And has a nicer (? opencode is pretty slick from my brief usage…).
Curious to hear about why you chose to built this way and what advantages you see.
That’s pretty much it. You can bring your own agent. Including OpenCode by the way. I doubt they will mind as they still get paid for the tokens.
You get a nice UI that is only going to get better as time goes on.
It’s far better model to separate the agent from the UI. The current situation is like building a browser for a single website.
Just installed it...
How are new agents added? Do you have to write a dedicated plugin for each one? Or there's some kind of discovery mechanism?
(I was looking for Copilot, but I guess that will depend on https://github.com/github/copilot-cli/issues/222 ?)
It’s stored statically in the Codebase. In the future, I suspect there will be enough compatible agents that there might be a web service to search them.
I think they are working in the Copilot ACP layer. Doubt it will take long.
It's more like just a simple toml file. https://github.com/batrachianai/toad/tree/main/src%2Ftoad%2F... gets you the currently supported ACP clients
And Copilot isn't supported for now because, well, there is no ACP support
I'm using ollama with local LLM for completion (tabby-ml) and Open WebUI for chat. What will be the goto local ACP server working with ollama ?
Ideally working with toad to experiment with it.
You may be confusing Agent Communication Protocol with Agent Client Protocol. Yeah, 2 ACP protocols. I had no hand in the naming.
If an agent can be configured to use Ollama, then you could use it from a Toad. It might be possible right now.
fast-agent has ACP support and works well with ollama. Once installed you can just use `toad acp "fast-agent-acp --model generic.<ollama-model>"`.
Sorry, not a question, just wanted to say congrats on putting this together. I am so the target market for a nice terminal interface. I can’t wait to try this out!
Thanks. Hope you like it.
Hey Will, just wanted to say this looks pretty damn spectacular. No notes. :)
Thanks!
Cool idea but why python?! Rust please and I’m all ears.
The author is also the creator of the textual Python library for creating TUIs. The performance benefits of Rust don't seem very useful in a tool where you spend a few seconds typing in a prompt and then 90% of your time is spent waiting. As long as the UI is responsive when typing there wouldn't be much of a difference.
Didn’t know that. Good reason then of course. But I do notice these sort of differences. Codex feels way better than Claude code to me for example.
I tried Toad and to me it feels ridiculously slow and laggy. Switching between input and output (ALT+up/down) for example just lags, I can notice the transition. The whole UI lags. It's no wonder, it's python. Simply the wrong language for this, sorry.
Yeah it feels slow and laggy to me too and I'm not on an old laptop. Running on a M3 Macbook Pro here. I definitely notice the difference between using something like Ghostty (Rust based - super fast) and Toad (Python).
It doesn't really make sense to compare the performance of Ghostty, a terminal emulator, with Toad, a TUI. Also Ghostty is written in Zig, not Rust.
It's obviously way slower though. Also the point stands, it's written in a low-level, performance-oriented language. The author of Toad could have written it in Rust, Zig, C++, etc, but chose Python instead. He valued ease of development versus performance and the result is we get a laggy terminal.
I know for a fact that Textual can generate an entire frame in less than a 60th of a second. Any lag you see has nothing to do with the choice of language. A TUI just doesn’t require that much number crunching to use a low level language.
I’d be interesting in knowing what platform and terminal you observed the lag, when testing Toad.
It is quite literally instantaneous on my 5 year old laptop. Whatever you are seeing isn't due to the choice of Python.
Maybe it's something on my setup then. I notice some delay even though it's by no means huge but noticable. For me these things add up, another example is pane resizing in tmux. I like things snappy, but it's kind of an OCD thing I guess.
The creator of Toad, made a TUI framework in Python (Textual). What is so special about Rust, aside from it being blazingly fast and compiled, that you want from it?
Safety, performance, avoiding python dependency hell.
I tried Toad and to me it feels ridiculously slow and laggy. Switching between input and output (ALT+up/down) for example just lags, I can notice the transition. The whole UI lags. It's no wonder, it's python. Simply the wrong language for this, sorry.
This looks fantastic!
Check out vibecommander - it’s a young tool in this space with a different take that wraps around CLI coding assistants with IDE-style file and git panels that compliment the experience by letting the human do the code review part of the task seamlessly.
Will add Toad support ASAP, I’m sure they’ll be great together.
https://github.com/AvitalTamir/vibecommander
You could also consider checking out vim, which solved this 50yrs ago ;) in all seriousness, you have terminals, splits, lazygit… so to me, it seems like this is a case of “not invented here”
Vim has a terrible user experience though. There's a reason everyone stopped using it as soon as they possibly could and moved to other text editors. Now the only vim users are the 60 year old+ greybeards who try to convince everyone they're such morons for not using it.
Stop trying to convince people to use vim, it sucks, it's got a terrible ux, it's not intuitive, it's overly complicated, hard to learn, arcane, and looks like ass.
I disagree, but I'm a 60 year old+ greybeard who has managed to get a bunch of other devs addicted to vim. My real goal is to keep the key bindings popular enough that I won't have to reprogram my muscle memory before I shuffle off.
This is absolutely awesome but the little jokey captions that Claude did (Discombobulating... Laminating...) all that stuff, they were a little annoying but cute enough, but whatever is running this one (I did not murder him... I thought I was special....) they are genuinely offputtingly bad. This great app doesn't need clunky humour front and centre, I'm not sure if it's Claude or toad but it seems markedly worse than Claude used to be.
Guess you don’t like sci-fi movie quotes. You can change that to a simple pulse animation in the settings.
It literally is using Claude under the hood. Should be no different than Claude’s own CLI.
I guess I have never heard them! Thanks for the tip
I'm sure you recognise some of these? https://github.com/batrachianai/toad/blob/main/src/toad/app....
Ah right so they are your quotes. No not enough that it wasn't quite a shock to spin up a cli tool and the first thing it says is "I didn't murder him" lol
This looks really cool. I wonder if they support vi keybinds
First thing I thought of, too. If not, I hope it’s planned. I’m all in on TUI tools, and vi keybinds are a necessary part of that for me.
Not planned for now I believe, you could try making a new Discussion for it.
I’m not a big fan of the name Toad, but the Textual framework is fantastic. I’ve been using it for years in a small project and it’s just a wonderful tool - it makes it really easy to get a super fast little UI for scripts.
Long time `rich` and `textual` user here, just wanted to say thanks :-)
This was fun: https://willmcgugan.github.io/facts-about-toads/
I've long been integrating terminals with GUIs and wanting more of this sort of stuff.
Reading the article I felt like the "sickos: yes!" meme.
This looks great! Looking forward to trying it out. I recently tried moving to OpenCode but it didn’t quite scratch the itch UX wise.
I already used Toad to run a conversion task I've been procastinating on.
It worked perfectly and looked splendid doing so.
Excited to dig in further.
Congrats and thank you for making Rich and Textual
De nada.
I see what you did what that intro and I approve :)
I'm very taken by your response!
toad is next level in many ways
[flagged]
Get outta my terminal!