I was using this religiously but there’s a bug currently that makes the initialization fail and/or throws an error on the phone client.
Absolutely great piece of software otherwise, free, anonymous, encrypted and so on. Really hope the team can fix this soon - I would hate to switch back to tmux tunneling.
Set it up and never managed to have it work. Only thing it did was renaming my sessions on my main cc instance. Mobile did nothing, not even an error message.
All of these agent wrappers/claws/whatever seem to encourage wildly irresponsible usage of AI. Sure it can get stuff done in what is effectively a simple loop but without review we’re just playing with fire.
I was experimenting with Claude code doing similar (don’t need wrappers really) and the result was a huge amount of mediocre code and my weekly limit burnt. The code “works” but oh my the duplication and potential bug surface is off the chart.
Stopped my experiment and back to human in the loop plan->execute cycle which is way more effective.
Thankfully I don’t think we’re at jarvis levels yet.
The whole point of Mato is to make human-in-the-loop supervision easier, not to encourage autonomous loops.
In my daily workflow I constantly run multiple coding agents at the same time. The annoying part isn’t the AI itself — it’s switching between tabs, terminals, and different tools just to check what each agent is doing.
I built Mato mainly because I wanted a faster way to jump between agents, review their outputs, and approve or intervene when needed. Think of it more like tmux for AI workers, where a human manager can oversee multiple agents at once.
Personally I’m also skeptical of fully self-driving loops. In practice the plan → execute → review cycle with a human in the loop is still the most reliable way to work with AI today.
As a primarily Go dev - 100% agree. The endless check and wrap error results in long chains of messages you have to grep for to understand the call stack. For what benefit? Might as well just panic and recover/log the stack in many cases.
The error handling is by far my least favorite aspect of Go. It's tedious and dangerous. It should either be like Rust or like JS, there isn't a good third option.
Isn't JS the same? But seems like people tend to make a lot of exception types in Java with inheritance, which I think is overkill.
Typically I'll only have a couple of exception types that my own code throws, like user error vs system error. If I want more detail than that, it goes into the exception payload rather than defining many different types of exceptions.
The key here is a singleton sequencer component that stamps the new versions. There was a great article shared here on similar techniques used in trading order books (https://hackertimes.com/item?id=46192181).
Agree this is the best solution, I’d rather have a tiny failover period than risk serialization issues. Working with FDB has been such a joy because it’s serializable it takes away an entire class of error to consider, leading to simpler implementation.
Eight, but half of them exist as long running test accounts for Kanmail (kanmail.io) so arguably do not count. I do use them for legit emails though, new services usually get one of four test emails.
I have Spotify premium but the constant shuffle of content availability has meant I’ve stared routinely archiving my liked songs to avoid any rug pull. Zspotify and co still work a charm.
