there are usage limits preventing you from running it 24/7 on all subscriptions tiers

This bolster's OP's point, to an extent

I understand you mean for free in the sense that you don't pay a third party to use it, however let's no forget that you still use the power grid and that's not free. Also worth to note that energy prices have increased worldwide.

Depending on utilisation and good use of low-power or sleep (or full off) states when things aren't actively processing, it can still be a _lot_ cheaper to run things at home than on a rented service. Power costs have increased a lot in recent years, but so have compute-per-watt ratios and you are not paying the that indirect compute price when the processors are asleep or off whereas with subscription access to LLMs you are paying at least the base subscription each month even if you don't use it at all in that period. Much the same as the choice between self-hosting an open-source project or paying for a hosted instance - and in both cases people don't tend to consider the admin cost (for some of us the admin is “play time”!) so the self-hosted option it does practically feel free.

Maintaining hardware also isn't free. Time is money.

Time is money if you have another good use of that time. If you like spending that time doing something, then it's literally free.

Coder doing the coding should use subscription, and now they ban the choice of your preferred ide for agentc coding. API is for automation not coding. I'm going to cancel their subscription today, I already use codex with opencode.

Sure it's $24/hour, but it'll crank through tens of thousands of tokens per second --- those beefy GPUs are meant for large amounts of parallel workflow. You'll never _get_ that many tokens for a single request. That's why the mathematics work when you get dozens or hundreds of people using it.

No. The sauce is in KV caching: when to evict, when to keep, how to pre-empt an active agent loop vs someone who are showing signs of inactivity at their pc, etc.

This is honestly the key difference here. I’m morally okay with using Claude Max Whatever with something like OpenCode because it’s literally the same thing from the usage pattern perspective. Plugging Nanoclaw into it is a whole another thing.

It probably doesn't help that the creator of OpenClaw just got hired by Anthropic's competitor.

This sounds like engineering, finance, and legal got together and decided they were in an untenable position if OpenAI started nudging OpenClaw to burn even more tokens on Anthropic (or just never optimize) + continually updated workarounds to using subscription auth. But I'm sure OpenAI would never do something like that...

At the end of the day, it's the same 'fixed price plan for variable use on a constrained resource' cellular problem: profitability becomes directly linked to actual average usage.

> OpenAI started nudging OpenClaw to burn even more tokens on Anthropic

Not possible: OpenClaw is run by a foundation, and is open source, which means OpenAI has no leverage to do such a thing.

Because open source has always been completely independent of unrelated corporate entities who employ people to work on it?

Because anyone can actually check the code, which means if there's any funny business, someone will come across it eventually and blow it open.

There probably wouldn’t be anything funny-looking – it might look like a genuine mistake in implementation that burns 2× or 3× tokens somehow (which, considering OpenClaw is vibe coded in the purest sense of this term, would blend right in).

Regardless, such things would eventually be found. Just as OpenClaw was tasked with finding and improving science repos (though unwelcome), it could - and very likely will - be tasked with improving its own codebase.

The bug that was causing the crazy token burn was added on Feb 15. It was claimed to have been fixed on Feb 19 (see https://github.com/openclaw/openclaw/pull/20597 ) but it's unclear to me whether that fix has been rolled out yet or if it completely solved the problem. (see https://github.com/openclaw/openclaw/issues/21785 )

TLDR: the commit broke caching so the entire conversation history was being treated as new input on each call instead of most of the conversation being cached.