If we want to be pedantic, we could say that your automation is like a particularly aggressive DoorDash driver; runs into the store, grabs all items as fast as possible, and is perhaps rude to the checkout girl on the way out. And if you scale this to checking N vendors - and only buying from one - you fall right into the bad behavior.
I’m not sure if your bot is like this, but my understanding is that many of them are - and they interfere with the other shoppers and generally change the economics of it.
I think you are on the right side of this, but you are almost indistinguishable from the negative case.
That’s not all you need to do though; once you have bought all Cable Matters or Anker cables, you still need to remember which one charges your iPhone quickly, and which one is thunderbolt-capable but missing the lightning bolt, which one is charging-only, etc. I have a whole mess of cables - and several of these dongles (you need a usb-a capable one, and only that other one reads thunderbolt markers, etc). I spend the time to label any cable that I buy myself, and wish the vendors would do it instead.
From reading TT, it seems there’s just no easy solution to complexity if we want interoperability.
Moshi has an integration with Herdr; you can connect to your herdr sessions over mosh, your touches register as mouse clicks in the UI (which is minimally rendered above the shell), and there’s a shortcut bar which can issue herdr-keymapped commands.
It’s not open source, and costs a few bucks, but it works well and has live Claude/Codex/etc notifications if you are willing to install a hook daemon on your hosts with homebrew. I was looking for batteries-included “code from my iPhone” after trying a bunch of self-hosted stuff, now I connect to my Macs over Tailscale and get dropped right into multiplexer sessions with rich status notifications.
I tried Moshi. Some things I did not like
- Despite the name, using mosh is a paid feature
- It was not clear what is and isn't a paid feature when using the app for the first time (after selecting which server to connect to, when you select which terminal/chat to connect to there's initially a counter that says 20/20 which decreases every time you connect)
- If you pair your phone to the server for push notifications a bunch of info regarding the chat is sent to their servers to produce the push (naturally), this makes it unsuitable for me at my job at least. IMO it would be sufficient to just get a "Agent needs your attention" push.
All in all, I did not find it worth it compared to using mosh or SSH in Termux. I have a colleague who loves Moshi though, for him its perfect. Among other things he likes the dictation.
I’ve been adding a “terms” section to every AI-used project due to these hallucinations. We abbreviate our company name eeeeverywhere and even Opus gets this wrong constantly. Obv I’m not adding “YES==yes” but that’s hilarious!
v4 is in beta and the source has some skills files. And for me personally I'm slowly building my own rules, like not having dialogs live hidden in the main page; instead, every button that triggers a dialog should do so via an htmx call that returns a dialog and appends it to the body. And then setting rules for how Claude should write templates, leveraging Django's new partialdef feature.
Same. I’m starting to believe that consumers need to own the UI/experience, so we can install blast doors around context/memory for each “slice” of our lives - something only we can know how to divide (imo). If the provider tools’ memory implementations can’t provide this multi-tenancy - or won’t because they want to Know Us, then we need to treat them as token vendors at best and adversaries at worst.
This would actually work very well - until context goes into latent space, becomes a server-side resource, and we lose sovereignty over our data. Tools like Pi and Openclaw are showing that other options exist to decouple us from the LLM provider frontend experiences, not just for orchestration and use case diversity but for pluggable memory designs.
They are imo over-relying on Claude automemory here, which is terrible at contextualizing memory access and makes huge leaps that don’t make sense - except when it’s actually useful, which makes the problem even worse for an operator who can’t see the thinking process anymore.
Yes, I worked on a related project, no I don’t want you to use those memories to make assumptions which emerge as decisions that I didn’t want. With reasoning traces hidden, I am sometimes not even sure if it used those memories or just independently decided that PCI-DSS subsection-whatever is somehow relevant to this PR that has the word “credit”.
There is no way for me to fully configure memory preferences at a granularity which would be useful, and so I continue to use context files (and other tools, sometimes) to ensure the right memories are stored and surfaced at the right times.
There’s a lot of room for agent memory improvement across the ecosystem, and I don’t think the LLM providers should try to own this vertical slice. This will never happen though, because it makes us “sticky”.
A CLAUDE.md file has no moat, it can be read by other agents.
Automemory can be weaved into the product in ways that make it harder to switch.
This is a company that's looking to IPO soon at a trillion+ dollar valuation, and they need to pull every lever to keep the users they got during the past year's boom.
Those auto memories are also annoying because by default they are not version controlled and land in a secret location. I much prefer storing stuff in a version controlled `CLAUDE.md` file.
It's an insane way of managing what is essentially configuration in this day and age, literally throwing away all our hard-earned lessons of the last 3 decades.
Worse still, it'll just use it randomly, and you have to notice it's done it.
"The user never wants to use ORDER BY Timestamp, I'll add this as a memory"
"For this object, JUST FOR THIS OBJECT! NOOOOOOOOOOOO!!"
I’ve rolled a small program to enforce consistency, lint rules, and human-authored files for Claude Memory.
It’s insanely powerful when doing by a human 100%. It’s conversely harmful when an agent manages it. There’s several papers about how LLM-managed memory is unequivocally terrible.
Indeed. I find it quite bizarre that just about the only thing the LLM appears incapable of doing is writing appropriate instructions for an LLM - whether it be memories, sub agent prompts, planning documents.
I’m not sure if your bot is like this, but my understanding is that many of them are - and they interfere with the other shoppers and generally change the economics of it.
I think you are on the right side of this, but you are almost indistinguishable from the negative case.
reply