It's like your actual asssitant. Now, most of this can be done inside ChatGPT/Claude/Codex now. Their only remaining problem for certain agentic things is being able to run those remotely. You can set up Telegram with Claude Code but it's somehow even more complicated than OpenClaw.
When people vibe-code, usually the goal is to do something.
When I hear people using OpenClaw, usually the goal seems to be… using OpenClaw. At a cost of a Mac Mini, safety (deleting emails or so), and security (litelmm attack).
Both OpenClaw and MSDOS gaining a lot a traction by taking short cuts, ignoring decades of lessons learned and delivering now what might have been ready next year. MSDOS (or the QDOS predecessor) was meant to run on "cheap" microcomputer hardware and appeal to tinkerers. OpenClaw is supposed to appeal to YOLO / FOMO sentiments.
And of course, neither will be able to evolve to their eventual real-world context. But for some time (much longer than intended), that's where it will be.
And if you remove either access to data or access to internet then you kill a good chunk of usefulness
Problem is, I was just learning and the mac was running System 7. Which, like MS-DOS, lacked memory protection.
So, one backwards test at the end of your loop and you could -- quite easily -- just overwrite system memory with whatever bytes you like.
I must have hard-locked that computer half a dozen times. Power cycle. Wait for it to slowly reboot off the external 20MB SCSI HDD.
Eventually I took to just printing out the code and tracing through it instead of bothering to run it. Once I could get through the code without any obvious mistakes I'd hazard a "real" execution.
To this day, automatic memory management still feels a little luxurious.
I too remember DOS. Data and code finely blended and perfectly mixed in the same universally accessible block of memory. Oh, wait… single context. nwm
So yeah, perhaps it isn't fooling the author, but it doesn't matter for the other billions of people.
Packages shipping as part of Linux distros are signed. Official Emacs packages (but not installed by the default Emacs install) are all signed too.
I thankfully see some projects released, outside of distros, that are signed by the author's private key. Some of these keys I have saved (and archived) since years.
I've got my own OCI containers automatically verifying signed hashes from known author's past public keys (i.e. I don't necessarily blindly trust a brand new signature key as I trust one I know the author has been using since 10 years).
Adding SHA hashes pinning to "curl into bash" is a first step but it's not sufficient.
Software shipped properly aren't just pinning hashes into shell scripts that are then served from pwned Vercel sites. Because the attacker can "pin" anything he wants on a pwned JavaScript site.
Proper software releases are signed. And they're not "signed" by the 'S' in HTTPS as in "That Vercel-compromised HTTPS site is safe because there's an 'S' in HTTPS".
Is it hard to understand that signing a hash (that you can then PIN) with a private key that's on an airgapped computer is harder to hack than an online server?
We see major hacks nearly daily know. The cluestick is hammering your head, constantly.
When shall the clue eventually hit the curl-basher?
Oh wait, I know, I know: "It's not convenient" and "Buuuuut HTTPS is just as safe as a 10 years old private key that has never left an airgapped computer".
Here, a fucking cluestick for the leftpad'ers:
https://wiki.debian.org/Keysigning
(btw Debian signs the hash of testing release with GPG keys that haven't changed in years and, yes, I do religiously verify them)
*Claw is more like windows 98. Everyone knows it is broken, nobody really cares. And you are almost certainly going to be cryptolocked (or worse) because of it. It isn't a matter of if, but when.
I am not interested in the "claw" workflow, but if I can use it for a safer "code" environment it is a win for me.
I remember Apple introducing sandboxing for Mac apps, extending deadlines because no one was implementing it. AFAIK, many apps still don’t release apps there simply because of how limiting it is.
Ironically, the author suggests to install his software by curl’ing it and piping it straight into sh.
Memory isolation is enforced by the MMU. This is not software.
Maybe you were confused with Linux, which came later, and landed in a soft x32 bed with CPU rings and Page Tables/VirtualMemory. ("Protected Mode", named for that reason...)
That being said, OpenClaw is criminally bad, but as such, fits well in our current AI/LLM ecosystem.
But my main takeaway is that from the security standpoint this is a ticking bomb. Even under Docker, for these things to be useful there is no going around giving it credentials and permissions that are stored in your computer where they can be accessed by the agent. So, for the time being, I see Telegram, my computer, the LLM router (OpenRouter) and the LLM server as potential attack/exfiltration surfaces. Add to that uncontrolled skills/agents from unknown origins. And to top it off, don't forget that the agent itself can malfunction and, say, remove all your email inboxes by mistake.
Fascinating technology but lacking maturity. One can clearly see why OpenAI hired Clawdbot's creator. The company that manages to build an enterprise-ready platform around this wins the game.
That’s why there isn’t a coherent use story because like glue the answer is whatever the user needs to glue/get done
It wasn’t (only) that, though; they also learned, so that, when people could afford to buy computers that were really useful, there were people who could write useful programs, administer them, etc.
Same thing with 3D printers a decade or so ago. What did people use them for? Mostly tinkering with hard- and software for days to finally get them to print some teapot or rabbit they didn’t need or another 3D printer.
This _may_ be similar, with OpenClaw-like setups eventually getting really useful and safe enough for mere mortals.
But yes, the risks are way larger than in those cases.
Also, I think there are safer ways to gain the necessary expertise.
From what I understand, the main appeal isn't the end result, but building that AI personal assistant as a hobby is the appeal.
Those arrived with the 386 (286? Don't remember but 386 for sure) and DOS was well alive late into the 386 and even late in the 486 days.
> For UNIX on the same machines, they also had no such protections.
I was already running Linux on my 486 before Windows 95 arrived. Linux and DOS. One had those protections, the other didn't.
"Interrupts", for example, are an old concept that is rarely talked about anymore until you get into low-level programming. At a high level, you don't even think about them, let alone talk about them.
Mostly (but of course, not exclusively), porn for the techies. Receiving a phone notification every time a PR is opened on a project of yours? Exciting or sad, depends on one's outlook on life.
Hype, mainly buying Hype before their IPO. The project is open source and the thinking behind it is not difficult, if they truly wanted they could have done it a long time ago or even without the guy. It was a pure hype 'acquisition' of a project that become popular for amateur programmers that got into it through vibe-coding and are unaware of the consequences and security exposure they subject themselves at.
It of course depends heavily on your work, but my work is 50% communication / overseeing, and I simply lose track of everything.
I don’t give it any credentials of any sort, but I run data pipelines on an hourly basis that ingest into the agent’s workspace.
If you look around in the business world, there is an absurdly large number of people still doing all sorts of things manually that they probably shouldn't. And its costing them money. Even before AI that was true. But now it's increasingly becoming obvious to these people that there are solutions out there that might work. There's a fair amount of FOMO on that front with more clued in people that have heard of other people allegedly being a bit smarter than them.
From a practical experience point of view, most people probably don't have the hands-on experience to make a good judgment just yet. "I tried Chat GPT once and it hallucinated" doesn't really count as valid experience at this point and many non-technical people are still at that level. There generally are a lot of headless chickens making absurd claims (either way) about what these systems can and cannot do making sweeping statements about how possible or impossible things are.
If you take the time and sit down to automate a few things you'll find that: 1) the tools aren't great right now 2) there are lots of basic plumbing issues that get in the way 3) fixing those plumbing issues is not rocket science and something anyone with basic CLI or scripting skills can solve easily 4) you can actually outsource most of that stuff to coding agents. 5) if you figure some of the basics out, you can actually make OpenClaw or similar systems do things that are valuable. 6) Most people that aren't programmers won't get very far given the current state of tools. 7) this might change rapidly as better tools become available. 8) people generally lack the imagination to see how even basic solutions could work for them with these systems.
I have an OpenClaw up and running for our company. It is doing some basic things that are useful for us. After solving some basic plumbing issues, it's now a lot easier to make it do new things. It's not quite doing everything just yet (lots more plumbing issues to solve) and we have our healthy hesitations about letting it loose on our inboxes. But it's not useless or without value. Every plumbing issue we solve unlocks a few more use cases. There's a bit of a gold rush right now of course. And "picks and shovels" people like myself are probably going to do a brisk business.
You can wait it out or tap into the action now. That's your choice. But try making it an informed choice. And no better experience than the first-hand type.
But the point is, OpenClaw is just the first that lucked and got viral. If not for it, something equivalent would. Much like LangChain in the early LLM days.
You can ask it questions like “what classes does my gym offer between 6-8pm today” and just get a good answer instead of wasting time finding their schedule. You can tell it to check your favorite band’s website everyday to see if they announce any shows in your city. You can tell it to read your emails and automatically add important information to your calendar.
This isn’t the space where I get the most value from AI, but it’s nice to have a hyper connected agent that can quickly take care of more smaller and more personal tasks.
If you ignore the risks I don't see why it's hard to see value.
The AI can read all your email, that's useful. It can delete them to free up space after deciding they are useless. It can push to GitHub. The more of your private info and passwords you give it the more useful it becomes.
That's all great, until it isn't.
Putting firewalls in place is probably possible and obviously desirable but is a bit of a hassle and will probably reduce the usefulness to some degree, so people won't. We'll all collectively touch the stove and find out that it is hot.
I have it hooked up to my smart home stuff, like my speaker and smart lights and TV, and I've given it various skills to talk to those things.
I can message it "Play my X playlist" or "Give me the gorillaz song I was listening to yesterday"
I can also message it "Download Titanic to my jellyfin server and queue it up", and it'll go straight to the pirate bay.
It having a browser and the ability to run cli tools, and also understand English well enough to know that "Give me some Beatles" means to use its audio skill, means it's a vastly better alexa
It only costs me like $180 a month in API credits (now that they banned using the max plan), so seems okay still.
Idk, it's strange for me to think of it that way. It's tech. If it does something useful, that's cool.
Data protection is always a consideration. I just don't consider a LLM to be a special case or a person, the same way that I don't have strong feelings about "AI" being applied in google search since forever. I don't have special feelings or get embarrassed by the thought of a LLM touching my mails.
Right now for me, agentic coding is great. I have a hard time seeing a future where the benefits that we experience there will not be more broadly shared. Explorations in that direction is how we get there.
This is cheap replacement for ordinary people.
It's going to be big. But probably it's best to wait for Google and Apple to step up their assistants.
The thread's linked article is about comparing MS-DOS' security, but the comparison works on another level as well: I remember MS-DOS. When the very idea of the home/office computer was new. When regular people learned how to use these computers.
All this pretension that computers are "hard to use", that LLMs are making the impossible possible, it's all ahistoric nonsense. "It would've taken me months!" no, you would've just had to spend a day or two learning the basics of python.
Similar YOLO attitude to OpenAI's launch of modern LLMs while Google was still worrying about all the legal and safety implications. The free market does not often reward conservative responsible thinking. That's where government regulation comes in.
I remember circa 2015 all my nerdy colleagues were going wild with home automation stuff, and I felt like I wanted to play with it too at first. But then I started to observe that these guys weren't spending less time than me turning on their lights. They were spending way more time than me, in fact, tinkering with their thermostats and curtains. I'm perfectly happy hitting a light switch when I walk in the door.
I can't envision one of these Telegram bots reliably completing tasks for me. Maybe the closest one would be what I've seen in this thread. Downloading torrents and putting them in Jellyfin for me, but really, I don't hate curating my own media collection.
This is so clearly the next step from Siri to Alexa to {Openclaw like technology}, that is an interface to technology that loads of people find value in everyday, and loads of people complain doesn’t have enough capabilities.
People do this? Or is it some sort of joke way above my head?
In what bizarre world is it easier to ask a massive LLM to play a playlist rather than ... literally hitting the play key on it?
I built a fastmail CLI tool for my *claw and it can only read mails, that's it. I might give it the ability to archive and label later on, with a separate log of actions so I can undo any operation it did easily.
It's pretty decent at going "hey, there's a sale on $thing at $store", for mails, but that's about it.
You could build up a legitimate collection for much less than $180/mo.
The tech has existed for a while but nobody sane wants to be the one who takes responsibility for shipping a version of this thing that's supposed to be actually solid.
Issues I saw with OpenClaw:
- reliability (mostly due to context mgmt), esp. memory, consistency. Probably solvable eventually
- costs, partly solvable with context mgmt, but the way people were using it was "run in the background and do work for me constantly" so it's basically maxing out your Claude sub (or paying hundreds a day), the economics don't work
- you basically had to use Claude to get decent results, hence the costs (this is better now and will improve with time)
- the "my AI agent runs in a sandboxed docker container but I gave it my Gmail password" situation... (The solution is don't do that, lol)
See also simonw's "lethal trifecta":
>private data, untrusted content, and external communication
https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
The trifecta (prompt injection) is sorta-kinda solved by the latest models from what I understood. (But maybe Pliny the liberator has a different opinion!)
So I guess that leaves the in-between people who don't care about spending $180 every month but don't have any personal staff yet or even access to concierge services.

OpenClaw isn’t fooling me. I remember MS-DOS.
The sad days of DOS. Any program could peek and poke the kernel, hook interrupts, write anywhere on disk. There was no safety.
The fix wasn’t a wrapper, or a different shell. It was a whole different approach to what was being done. The world already had rings, virtual memory, ACLs, separate address spaces. Thirty years of separations that Unix had from the start were ignored, and it finally caught up to the world of DOS.
I’m not saying DOS wasn’t wildly popular. Oh my god. I remember one dark night in a bar in Chicago, a drunk Swedish IT consultant jumped onto a table and said “listen up everyone!”. As he waved his beer mug around, sloshing carelessly, with wobbly legs, he said he was in town to work on Wal-Mart Point-of-sale (POS) devices running MS-DOS. Why was he acting like this? He was happy, very, very happy. He wanted us to know he loved his work, something like “CAN YOU BELIEVE WAL-MART HAS HUNDREDS OF THOUSANDS OF DOS MACHINES WITH ALL YOUR F$%#$%NG PAYMENT CARD DATA?! HAHAHA! AND IT ALL HAS ONE PASSWORD THAT EVERYONE SHARES! YOU WANT IT?! I GOT IT RIGHT HERE! FREEDOM, AMERICA, F$#%$K YEAH!”
True story. Both the guy and Wal-Mart put ALL customer information on MSDOS with exactly zero safety.
NCR had just announced a new MS-DOS-based PC…we decided to build a custom solution for Wal-Mart. I managed to connect a cash drawer and a POS printer to the new PC and wrote a dedicated Layaway application in compiled MS Basic. For the first time, Wal-Mart could store customer info on a disk. A clerk could search by name in seconds, and more importantly, the system tracked exactly where the merchandise was tucked away in the backroom. It was a massive efficiency win, and NCR ultimately rolled it out to all Wal-Mart stores.
Personal identity information was never breached faster! Massive efficiency win, indeed. When Wal-Mart was breached in 2006 they naturally had to wait three long years to notify anyone. So efficient.
Agent gateways feel like we are racing backwards into the MS-DOS era. At any minute in a bar I expect a drunk Swedish IT consultant to be standing on a table waving a lobster around, swearing about his single token for all agents. Because, let’s face it, when you look at gateways out there they can hand the model an exec tool and trust it. One process, one token, with the LLM holding the line.
NVIDIA clearly has seen the storm brewing and therefore published a thoughtful tutorial walking through a “NemoClaw” self-hosted agent setup on DGX Spark.
Use NVIDIA DGX Spark to deploy OpenClaw and NemoClaw end-to-end, from model serving to Telegram connectivity, with full control over your runtime environment.
I appreciate this effort. Real engineering, carefully done. I took the tutorial to learn and I followed it in Wirken, a gateway I’ve been building, to document what each step looked like.
The tutorial has you bind Ollama to 0.0.0.0 so the sandboxed agent can reach it across a network namespace. Then it pairs the Telegram bot by sending a code through the chat channel. It next approves blocked outbound connections in a separate host-side TUI. Each of those seem to be steps to address a real problem, which is how to put security around something that doesn’t work when it has security around it. It’s what an architecture requires when the sandbox sits around the whole agent.
Call me old-fashioned but I anticipated a lot of this in Wirken by giving the agent more safety by shrinking the boundaries. Each channel is a separate process with its own Ed25519 identity. The vault runs out of process. Inference stays on loopback because the agent is on the host. Shell exec runs in a hardened container configured at the tool layer, rather than trying to wrap around the whole agent. Sixteen high-risk command prefixes prompt on every call; others are first-use with a 30-day memory.
Here’s what I found, step by step
| Step | NemoClaw | Wirken.AI |
|---|---|---|
| 1. Runtime | Register the NVIDIA container runtime with Docker, set cgroup namespace mode to host. Foundational setup because the agent runs inside a container. | No equivalent step. The gateway runs as a host process. Docker appears only as a per-tool-call sandbox for shell exec, provisioned lazily. |
| 2. Ollama | Override OLLAMA_HOST to 0.0.0.0 so the sandboxed agent can reach inference across its own network namespace. | Ollama stays on 127.0.0.1. The agent is a host process, so loopback is enough. |
| 3. Install | curl-pipe-bash from an NVIDIA URL. | curl-pipe-sh as well. The installer verifies the release signature with ssh-keygen against an embedded key, fail-closed on every failure path. The installer’s own SHA is pinned in the README for readers who want to check the script before piping. |
| 4. Model | ollama pull the model, then ollama run to preload weights into GPU memory. | Same pattern. Both delegate inference to Ollama. |
| 5. Onboarding | Wizard produces a sandbox image with policy and inference baked in, as a named rebuildable unit. | Wizard writes provider config and channel registrations. The permission model lives in the binary; runtime state is which action keys have been approved. |
| 6. Telegram | Pairing code sent through the chat channel; user approves from inside the sandbox. Binds a platform user to the agent at first contact. | Bot token into an encrypted vault, fresh Ed25519 keypair for the adapter, no in-chat pairing. Approval granularity is per action and per agent rather than per channel user. |
| 7. Web UI | Localhost URL with a capability token in the fragment, not shown again. | Localhost URL, loopback-bound, no token required. |
| 8. Remote access | Host-side port forward started through OpenShell, then SSH tunnel. The extra hop is because the UI lives inside a netns. | SSH tunnel only. The WebChat listener is already on host loopback. |
| 9. Policy | Enforces at the netns boundary. Outbound connections are surfaced in a TUI with host, port, and initiating binary. Approve for the session or persist. | Enforces at the tool dispatch layer. Sixteen high-risk command prefixes always prompt; others are first-use, remembered 30 days. Approved commands run inside a hardened Docker container with cap_drop ALL, no-new-privileges, read-only rootfs, 64MB tmpfs at /tmp, and no network. |
Looking at my audit logs
The architectural claims above are recorded in the logs of the tutorial work. Wirken uses a hash-chained audit database of the webchat session, so here’s what that looked like in version 0.7.5.
First, the Tier 3 denial on curl:
[ 4] assistant_tool_calls call: exec({"command":"curl https://httpbin.org/get"}) [ 5] permission_denied action_key='shell:curl' tier=tier3 [ 6] tool_result tool=exec success=False output: Permission denied: 'exec' requires tier3 approval. [10] attestation chain_head_seq=9 chain_head_hash=ff57c574ab503a74fa942ddb164def0df5bfbff05e5d5d6ecadcf127bce7e021
The tool call never reached the sandbox. The denial is recorded as a typed event in the audit chain, covered by the per-turn attestation.
Second, the hardened sandbox on sh. With shell:sh pre-approved at Tier 2, the same agent runs a compound command that probes three locations:
[14] assistant_tool_calls call: exec({"command":"sh -c \"touch /cannot_write_here 2>&1; ...\""}) [15] tool_result tool=exec success=True output: touch: cannot touch '/cannot_write_here': Read-only file system ws_ok=1 tmp_ok=1 [19] attestation chain_head_seq=18 chain_head_hash=6bf35f22df02b496244091e54b4dbf9b3ffdcf6a03485413f0522b84e2eb08a8
Read-only file system is the kernel refusing to open a new file against a read-only mount. Not a DAC check, the rootfs itself. ws_ok=1 confirms the workspace bind-mount stayed writable. tmp_ok=1 confirms the tmpfs at /tmp did too.
Both receipts are consecutive rows from the same session, hash-chained through to the attestation signatures at seq 9 and seq 18. wirken sessions verify replays the chain and confirms every leaf hash matches its payload and every chain hash matches SHA-256(prev_hash || leaf_hash).
How big is your boundary?
The workarounds in the tutorial are trying to make the best of a foundation that doesn’t separate concerns the way engineers typically like. Bind to 0.0.0.0 because the sandbox can’t reach loopback. Pair through the chat channel because there’s no separate identity plane. Wrap the whole agent in a container because the agent itself isn’t yet trusted. Approve at the netns boundary because the tool layer has no concept of permission.
Each of those is a compromise; response to a constraint. The constraint is worth revisiting like it’s 1985 again and we can stop Bill Gates.

Abort, Retry, Fail today but tomorrow I promise there will be a better shell.
In 1973 Unix got process separation, user separation, file permissions, and pipes between small programs. By 1995 I was all-in on Linux, building kernels by hand and starting this blog named flyingpenguin, because it had inherited them and made them the default.
In 2020 Microsoft finally admitted Linux was their better future, which everyone knows today.
Back in 2001, former Microsoft CEO Steve Ballmer famously called Linux “a cancer” … During a [2020] MIT event, [Microsoft president Brad] Smith said: “Microsoft was on the wrong side of history”
The agent space is still early and some people never learn the past. Wirken is one take on what it looks like when you remember. Like, remember the sheer horror of trying to protect anything in DOS? Remember the Wal-Mart breach of 2006, reported in 2009?
It’s just a question of whether we apply what computer history already knows to how we make agents safe for daily use. There are dozens of others doing versions of their own Wirken, and I’d genuinely like to hear from people working on the same problem; the architectures can converge in more than one way.
Repo: wirken.ai
In The Netherlands you can get a live-in au-pair from the Philippines for less than that. She will happily play your Beatles song, download the Titanic movie for you, find your Gorillaz song and even cook and take care of your children.
It's horrible that we have such human exploitation in 2026, but it does put into perspective how much those credits are if you can get a real-life person doing those tasks for less.
Not to be a narc or anything, but is OpenClaw liable to just perform illegal acts on your behalf just because it seemed like that's what you meant for it to do?
I have a hard time imagining how much better Alexa would have to be for me to spend $180/month on it...
OTOH, this isn't an issue for "ordinary people". They go to work, school, children's sports events, etc. If they had an assistant for free, most of them would probably find it difficult to generate enough volume to establish the muscle memory of using them. In my own professional life, this occurred with junior lawyers and legal assistants--the juniors just never found them useful because they didn't need them even though they were available. Even the partners ended up consolidating around sharing a few of them for the same reason.
Down in this thread someone mentions it being an advanced Alexa, which seems apt. Yes, a party novelty but not useful enough to be top of mind in the every day work flow.
1. Something like OpenClaw will change the world.
2. OpenClaw is not yet ready.
The heart of OpenClaw (and the promise) is the autonomy. We can already do a lot with the paid harnesses offered by OpenAI and Anthropic, so the secret sauce here is agents doing stuff for us without us having to babysit them or even ask them.
The problem is that OpenClaw does this is an extreme rudimentary way: with "heartbeats." These are basically cron jobs which execute every five minutes. The cron job executes a list of tasks, which in turn execute other tasks. The architecture is extremely inefficient, heavy in LLM compute, and prone to failure. I could enumerate the thousand ways it can and will fail but it's not important. So the autonomy part of the autonomous assistant works very badly. Many people end up with a series of prescriptive cron jobs and mistakenly call that OpenClaw.
Compounding this is memory. It is extremely primitive. Unfortunately even the most advanced RAG solutions out there are poor. LLMs are powerful due to the calculated weights between parametric knowledge. Referring to non-parametric knowledge is incredibly inefficient. The difference between a wheelchair and a rocket ship. This compounds over time. Each time OpenClaw needs to "think" about anything, it preloads a huge amount of "memories" into the query. Everything from your personal details to architecture to the specific task. Something as simple as "what time is it" can chew through tens of thousands of tokens. Now consider what happens over time as the agent learns more and more about you. Does that all get included in every single query? It eventually fails under its own weight.
There is no elegant solution to this. You can "compress" previous knowledge but this is very lossy and the LLMs do a terrible job of intelligently retaining the right stuff. RAG solutions are testing intelligent routing. One method is an agentic memory feedback loop to seek out knowledge which might exist. The problem is this is circular and mathematically impossible. Does the LLM always attempt to search every memory file in the hope that one of the .md files contains something useful? This is hopelessly slow. Does it try to infer based on weekly/monthly summaries? This has proven extremely error-prone.
At this point I think this will be first solved by OpenAI and/or Anthropic. They'll create a clean vectorised memory solution (likely a light LLM which can train itself in the background on a schedule) and a sustainable heartbeat cadence packaged into their existing apps. Anthropic is clearly taking cues from OpenClaw right now. In a couple of years we might have a competent open source agent solution. By then we might also have decent local LLMs to give us some privacy, because sending all my most intimate info to OpenAI doesn't feel great.
OTOH a lower-middle-class Joe like me really does have a lot of mundane social/professional errands, which existing software has handled just fine for decades. I suppose on the margins AI might free up 5 minutes here or there around calendar invites / etc, but at the cost of rolling snake eyes and wasting 30 minutes cleaning up mistakes. Even if it never made mistakes, I just don't see the "personal assistant" use case really taking off. And it's not how people use LLMs recreationally.
Really not trying to say that LLM personal assistants are "useless" for most people. But I don't think they'll be "big," for the same reason that Siri and Alexa were overhyped. It's not from lack of capability; the vision is more ho-hum than tech folks seem to realize.
Edit: Yes it’s still there https://support.mozilla.org/en-US/kb/thunderbird-and-junk-sp...
I believe that the shift from "my one computer" to multiple clients (computer + phone + webmail) probably has something to do with it. Even with IMAP sharing state, you still don't have a great way to see and control the filtering, except by moving things in/out of spam folders.
I’m not generally interested in having it read my email or calendar. I have a digital calendar in the kitchen, and I rarely get important email. I do really enjoy being able to control my house by voice in natural language. I had it set all my lights to Easter colors a while back in a single instruction.
True, but it doesn't scale. No amount of YOLO will let anyone else repeat that feat.
Yep. The IoT home automation stuff is still less performant than much older, wired solutions where whole systems were designed at once in a set-and-forget mode and didn't have weird sync issues or delays. I remember seeing the 'home of the future' exhibit at Epcot like 20+ years ago and these IoT setups are often still a total joke in comparison because of all the protocol issues and fiddling with various interfaces needed.
Just like how the analog wired POTS phone systems were more performant in many ways than pretty much any IP based voice setup.
I simply got tired of messing with stuff that kept breaking in unexpected ways. It wasn't saving time, it was adding a lot of totally unnecessary stress and actually taking time away from me-- for little more than an occasional spark of novelty. Being able to use voice accurately & repeatably for simple task requests is probably the only standout advancement.
My 'nerdy colleagues' and myself can get a lot of enjoyment out of tinkering with this new agentic hotness. However, very few of us I think are really getting something that's actually saving us time in the long run (at least in our personal lives), and it's going to take a while to figure out what's actually realistically reproducible toward that end at a reasonable cost.
For comparison, a full time "virtual assistant" with fluent English from the Philippines costs upwards of $700/month nowadays.
And you see nothing wrong with that?
I think they do it mostly to feel young and edgy.
There's at least a couple of dozen instances right now, somewhere, getting very close to designing boutique chemical weapons.
A lot of people in the Silicon Valley area spend that much ($6/day) on coffee. What they don’t realize is how out of touch they are in thinking makes sense for the rest of the fucking world. $180/mo is about 5% of the median US per capita income. It’s not going to pick your kids up from school, do your taxes, fix your car, or do the dishes. It’s going to download movies and call restaurants and play music. It’s a hobby, high-touch leisure assistant that costs a lot of money.
The number one goal of AI should be to eliminate human exploitation. We want robots mining the minerals we use for our phones, not children. We should strive to free all of humanity from dangerous labour and the need for such jobs to exist.
If Elon Musk wants Optimus robots to help colonize Mars shouldn’t he be trying to create robots that can mine cobalt or similar minerals from dangerous mines and such?
OpenClaw is not a CC-only product. You can configure it to use any API endpoint.
Paying $180/month to Anthropic is a personal choice, not a requirement to use OpenClaw.
Like, no one bats an eye at all the people paying $100/mo for Hulu + Live TV, or paying $350/mo for virtual pixels in candy crush / pokemon go / whatever, and I'm having at least that much fun in playing with openclaw.
I have some bad news.
If any of my friends admitted to spending $350/mo on candy crush i'd think that they'd badly need help for a gambling problem.
In other words, assuming no price increase, 7 years of that pricing is $15k. Is there hardware I could buy for $7k or less that would be able to replace those API calls or alternativr subs entirely?
I've personally been trying to determine if I should buy a new GC on my aging desktop(s), since their graphic cards can't really handle LLMs)
Be judgemental all you want, but I feel like I'm paying for less friction, and also more security since my experiments also showed claude to be the least vulnerable to prompt injection attempts.
That means picking up and cleaning the house after 3 kids and a dog. Grocery shopping. Dishes. Laundry. Chores.
Tech crap? Nope.
Working abroad is a totally reasonable proposition compared to working in the Philippines.
But if you don't need frontier coding abilities, there are several nice models that you can run on a video card with 24GB to 32GB of VRAM. (So a 5090 or a used 3090.) Try Gemma4 and Qwen3.5 with 4-bit quantization from Unsloth, and look at models in the 20B to 35B range. You can try before you buy if you drop $20 on OpenRouter. I have a setup like this that I built for $2500 last year, before things got expensive, and it's a nice little "home lab."
If you want to go bigger than this, you're looking at an RTX 6000 card, or a Mac Studio with 128GB to 512GB of RAM. These are outside your budget. Or you could look at a Mac Minis, DGX Spark or Strix Halo. These let you bigger models much slower, mostly.
Over 5 years, that works out to ~$45k vs ~$10k, and during that duration, it's possible better open models will come available making the GPU better, but it's far more likely that the VC-fueled companies advance quicker (since that's been the trend so far).
In other words, the local economics do not work out well at a personal scale at all unless you're _really_ maxing out the GPU at close to 50% literally 24/7, and you're okay accepting worse results.
As long as proprietary models advance as quickly as they are, I think it makes no sense to try and run em locally. You could buy an H100, and suddenly a new model that's too large to run on it could be the state of the art, and suddenly the resale value plummets and it's useless compared to using this new model via APIs or via buying a new $90k GPU with twice the memory or whatever.
Hard to believe unless your are doing something much more complex than the things you listed
A normal full time employee costs at least 2000€ a month (salary, tax, pension plan, health insurance, etc). If you are paying less than that you are definietly exploiting them.
Given the trends of the capitalist US government, which constantly cedes more and more power to the private sector, especially google and apple, I assume we'll end up with a state-run model infrastructure as soon as we replace the government with Google, at which point Gemini simply becomes state infrastructure.
That's not correct. If USPS makes more revenue than their expenses for a year, they can't pay it out as profits to anyone.
It's true that USPS is intended to be self-funded, covering it's costs through postage and services sold, and not tax revunue. That doesn't mean there's profit anywhere.
That depends on the country in question :-)