Hi folks! Great to see our work on the front page, and I'm happy to answer questions.
Regarding next steps, we're currently working on React integration, with Python and JavaScript server-side web frameworks coming next. If you're interested, here's our survey/waiting list: https://forms.gle/8MeXwGjpBFDeGNQw9
ddon · 52m ago
Very cool, we use it as MCP server when we develop things using Claude Code... how would using Tidewave Web change our workflow?
josevalim · 42m ago
You can think of Tidewave MCP as integrating the agent with the language runtime, while Tidewave Web integrates the agent with your actual app and its interface. It knows your views and templates, it can correlate it with the rendered page, and then automate the browser to implement and validate features.
Our announcement post goes more into detail and explains why moving the agent to the browser means you (the developer) can spend more time out of the loop: https://tidewave.ai/blog/tidewave-web-phoenix-rails
kawsper · 1h ago
I spent a couple of hours last night testing it out.
The login process didn't work well, but it's due to my browser having a seperate container for Github.
I asked it to add a feature using Stimulus.js to my very simple gallery page written in Rails, when you hover over an image in the gallery, it should make an icon appear, and when clicking the icon, a modal should pop-up that allows the user to do cropping.
It picked up on my database models and it produced a very good result, however, it seemed to have issues verifying its solution, it particularly seemed to struggle with "on-hover".
The solution it produced was a lot better than what claude-code produced, and I liked the interface.
I also ended up hitting the limits on the Anthropic API, and it wasn't obvious to me what I should do in that case, but that's likely not the fault of Tidewave, and the Context Window Usage having a maximum of 200.0k also seemed very high, but that probably contributed to me hitting a limit.
josevalim · 1h ago
Thank you `kawsper` for the feedback!
We are going to introduce more visibility into the context limit and make it easier to summarize.
Regarding the on-hover, do you still have the snippets around that it tried? We instruct the model to dispatch events using the proper browser APIs and I wonder what it tried to do. I would love to hear more! You can ping me on Tidewave's Discord (https://discord.gg/5GhK7E54yA) or send me an email (see github.com/josevalim).
bluehatbrit · 24m ago
I've been using the tidewave plugin for a bit now, this browser addition seems pretty cool. I'm curious about the pricing though. It says we need to provide our own github copilot or anthropic keys, but there's then a limit on the number on usage before you need to pay.
Is this because data is going through a tidewave server or something, or is it just a way to create a bit of a free trial vs "now you need to pay us"?
josevalim · 20m ago
It is both. There is a Tidewave server (which will play a more meaningful role once we introduce agent coordination) but we also hope the limit will be enough for people to see value in the tool and convert into paying users (so we can continue improving it).
robertkoss · 30m ago
I would love to have a React Copilot that has access to the console, network logs, the actual html elements, computed styling etc. + my code.
This would be such a game-changer. I am also convinced that monorepos will become the de facto standard, since it is way easier for LLMs to navigate / implement features across the whole stack.
josevalim · 16m ago
We are working on React integration, first within Rails and Phoenix, but then also standalone. How are you serving/running your React apps in development?
awongh · 1h ago
The details on what the architecture of this aren't clear, but I can see that the big feature is deeper integration into the browser.
To me this is an obvious direction for all coding agents to go in. Right now the cursor chrome browser MCP server doesn't work very well, but it's very obvious to me that this is the direction things need to go in.
I'm not sure why focusing on a framework would fundamentally make this any better than the generic approach to getting good context directly from the browser.
josevalim · 1h ago
There are two main reasons why being framework specific can be a big boost:
1. We annotate and understand your template language. So when you select an element, we not only know its tag and attributes, but we also know which template file rendered it. The more structured the template language is (JSX, HEEx, etc), the better job we can do, which means LLMs don't have to guess.
2. We also run code within the web framework. This means database access, built-in documentation using the exact versions in your project, access to language and framework reflection/introspection APIs, etc. So the agents have more, err, agency.
I hope this clarifies it a bit!
towhans · 1h ago
When using browser-tools-mcp I can point to an element and ask Agent to "change color of this element to red". It would copy the part of the HTML and search the codebase for it.
I can imagine having an in browser, framework level tool would know exactly which controller and which template generated this element and could target it more precisely while using less tool calls and less tokens. I haven't tested it yet but that is my expectation.
cdiamand · 26m ago
Looks pretty neat, and certainly addresses a missing element in the current AI workflow.
Question: What happens to our data - i.e. the code and context sent to your service?
josevalim · 22m ago
We log basic request metadata (timestamps, model used, token counts). Prompts and messages are not logged unless you explicitly opt-in. We don't store tool results. Note the underlying model provider you use may store data separately depending on your user agreement with them.
pelagicAustral · 1h ago
This looks promising. I will definitely be giving it a shot. I have been getting pretty good results with Claude Code and Rails for a while now, I'm kind of excited to see how much things can improve with this.
thrown-0825 · 1h ago
I think opinionated frameworks like this are a good fit for ai.
Usually only one correct and idiomatic way to do things, and rails in particular really leans on convention over configuration.
yanis_t · 53m ago
Opinionated frameworks, strict types, and whatever non-ai tools for correctness validations (typescript, linters, compilers) are all helpful.
abrookewood · 31m ago
Hey Jose,
How does this differ from Phoenix.new?
josevalim · 25m ago
Phoenix.new is about remote agents, while Tidewave integrates with your app running on your machine!
abrookewood · 3m ago
Cool. That's actually interesting. I found with Phoenix.new that I would start there, but later ended up running everything locally - with the Tidewave MCP server of course!
kiru_io · 15m ago
Why does it forward to https://tidewave.ai/ when I type http://localhost:4000/tidewave ?
josevalim · 10m ago
You are first redirected for authentication purposes. Once authenticated, it redirects back to your app.
cpursley · 25m ago
It actually works (not to knock the fly folks, fly is great).
Regarding next steps, we're currently working on React integration, with Python and JavaScript server-side web frameworks coming next. If you're interested, here's our survey/waiting list: https://forms.gle/8MeXwGjpBFDeGNQw9
Our announcement post goes more into detail and explains why moving the agent to the browser means you (the developer) can spend more time out of the loop: https://tidewave.ai/blog/tidewave-web-phoenix-rails
The login process didn't work well, but it's due to my browser having a seperate container for Github.
I asked it to add a feature using Stimulus.js to my very simple gallery page written in Rails, when you hover over an image in the gallery, it should make an icon appear, and when clicking the icon, a modal should pop-up that allows the user to do cropping.
It picked up on my database models and it produced a very good result, however, it seemed to have issues verifying its solution, it particularly seemed to struggle with "on-hover".
The solution it produced was a lot better than what claude-code produced, and I liked the interface.
I also ended up hitting the limits on the Anthropic API, and it wasn't obvious to me what I should do in that case, but that's likely not the fault of Tidewave, and the Context Window Usage having a maximum of 200.0k also seemed very high, but that probably contributed to me hitting a limit.
We are going to introduce more visibility into the context limit and make it easier to summarize.
Regarding the on-hover, do you still have the snippets around that it tried? We instruct the model to dispatch events using the proper browser APIs and I wonder what it tried to do. I would love to hear more! You can ping me on Tidewave's Discord (https://discord.gg/5GhK7E54yA) or send me an email (see github.com/josevalim).
Is this because data is going through a tidewave server or something, or is it just a way to create a bit of a free trial vs "now you need to pay us"?
This would be such a game-changer. I am also convinced that monorepos will become the de facto standard, since it is way easier for LLMs to navigate / implement features across the whole stack.
To me this is an obvious direction for all coding agents to go in. Right now the cursor chrome browser MCP server doesn't work very well, but it's very obvious to me that this is the direction things need to go in.
I'm not sure why focusing on a framework would fundamentally make this any better than the generic approach to getting good context directly from the browser.
1. We annotate and understand your template language. So when you select an element, we not only know its tag and attributes, but we also know which template file rendered it. The more structured the template language is (JSX, HEEx, etc), the better job we can do, which means LLMs don't have to guess.
2. We also run code within the web framework. This means database access, built-in documentation using the exact versions in your project, access to language and framework reflection/introspection APIs, etc. So the agents have more, err, agency.
I hope this clarifies it a bit!
I can imagine having an in browser, framework level tool would know exactly which controller and which template generated this element and could target it more precisely while using less tool calls and less tokens. I haven't tested it yet but that is my expectation.
Question: What happens to our data - i.e. the code and context sent to your service?
Usually only one correct and idiomatic way to do things, and rails in particular really leans on convention over configuration.