It’s literally one deps line in your mix.exs and one line once only before starting Claude the next time. From that moment on, you just prompt Claude to use tidewave. that’s it.
this is the once only line:
claude mcp add --transport http tidewave http://localhost:4000/tidewave/mcp
max thinking effort – it does make a difference, it gets scary smart when it tries to scope out features and bug fixes because it considers much more of the codebase and the architecture but yes it burns more tokens.
All those add up.
One thing I am open to change is find a way to have Claude use high thinking effort for the less-clever tasks but I admit I am not at all interested in curating that. I throw it at all tasks on the max (heh) and yes, it’s not very economical but happily I don’t live to vibe-code two features a day. The work that I do is delicate and correctness still matters more.
This is a key point I didn’t mention: I’m using high, I actually didn’t realize there was max until just now, heh. I already find high crazy smart but I will try max.
Also re: single topic, I just started using /clear more heavily as I tend to bounce between topics (I’m kinda still prototyping as I think of stuff) and if it’s too much of a jump (which doesn’t need to be much) it starts conflating the previous feature with the new one and for whatever reason I found that incredibly annoying. Like the chirp of a low-battery smoke detector level annoying.
Yes, it always tries to connect a current discussion with a previous one and yes it’s definitely annoying. But I find ways to stop it and it does not happen super often. But yes, valid counter-point against having a single stream-of-consciousness session (like those that I do).
I do for sure also do it so I’m not sending tons of context back and forth so ya, I see… a lot of you are probably doing this and eating up tokens. I’m unemployed again so I don’t have the blank cheque to even really experiment with this kind of thing. The $100/month already isn’t great!
So, very short time using it, and I’m specifically reporting back with less for a reason:
So I’ve used this exclusively on styling tasks so this is all kinds of skewed, but I’d be interested to get others’ feedback.
The main difference I noticed using max effort was that it returned results much quicker, but consumed WAY more tokens, BUT with no discernible difference in output. Again, there are a metric 
ton of variables here, but the very first task I gave max effort was a CSS task that I believe “high effort” would have gotten wrong a few times before getting it right. Max effort got it in three tries but shot my freshly reset usage up to 11%! I feel like using high effort it may have taken five or six times but my usage would have been, like, 3%.
Does this track with anyone? It’s way too expensive for me to do some actual tests here.
For now I think I will stick to high effort and perhaps do the inverse of what is generally suggested: switch to higher effort when the thing can’t figure its out.
Otherwise, I don’t mind the extra waiting time to <insert things that I do while waiting for it to finish 
>
It is more expensive but for me the max effort helped with cross-app awareness (we have a monorepo) and paid closer and more persistent attention to the 50+ rules I gradually gave it. It was stopping and second-guessing its code edits and stopping dead in its tracks to then go back and fix a low-effort code that it “instinctively” output (its own words).
I’d say that probably up until a certain complexity level the high effort is the ideal tradeoff. But in my work max made an actual difference. Also, funny exercise: my colleagues still use high and when I give the max Claude their PRs to review, it finds 15+ defects, to the point that they gave up and told me “just take over the PR”. 
Which is the right call; 15+ defects and multiple messages of back-and-forth can easily consume the entire workday.
If this is Claude we are talking about I’d say styling is one it’s weaker spots, and I’m not sure adding more effort to bad work equals quality work or just more volume of bad work… The thing that I have found to work is showing some examples of how you want it or similar to what you want.
I usually use high effort, but might do higher in particular in the planning phase depending on the project. Skills help to some extent, and likely more with more effort than less. (I’ve tried with low effort and it was not too keen on using skills actively. I assume because that takes effort).
My experience is the opposite by the way - higher effort settings typically take longer. That might vary with the task.
They (LLMs) all suck at styling, not to mention shadow DOM styling. Like 0 knowledge on that matter.
I took time at some point, found various representative and well designed websites and industrial UIs, and made a few categories like landing page, information heavy website, industrial control dashboard, and so on. Then made a skill basically extracting and distilling the more general style features of each category into a design skill. That helped a lot, and combine with “make 4 options in this kind of style to choose from" there is usually something usable to choose and go on with.
I believe there are official frontend agents and skills too though, which should improve things and possibly considerably?