Peter here from OpenClaw. For context, here’s why our post reads the way it does:
Boris from Claude Code said publicly on Twitter that CLI-style usage is allowed. We took that seriously and invested time building around that guidance. I even changed the defaults, so when using the cli we're automatially disabling features that use excessive tokens like the heartbeat feature. But in practice, Anthropic still blocks parts of our system prompt, so the actual behavior today does not match what was communicated publicly.
https://x.com/bcherny/status/2041035127430754686
They since seemed to changed their classifier as people hack around it, as it is trivial to do so with a few renames. I'm not playing that game so it's in a weird limbo where it should work in theory but doesn't in practice.
A lot of people have spent a considerable amount of time building out "claude -p" workflows trusting Anthropic because of those same Tweet assurances outside of OpenClaw.
It seems with the new "--bare" flag they are introducing, a huge rug pull is coming as they plan to deprecate -p for unlimited users.
The docs now read:
> "Bare mode skips OAuth and keychain reads. Anthropic authentication must come from ANTHROPIC_API_KEY or an apiKeyHelper in the JSON passed to --settings. Bedrock, Vertex, and Foundry use their usual provider credentials. --bare is the recommended mode for scripted and SDK calls, and will become the default for -p in a future release."
Hope I am reading this wrong or this is clarified.
https://code.claude.com/docs/en/headless
Peter, while we are on the subject of clarifying what is and isn't allowed I have a question: has OpenAI clearly communicated about precisely where one is supposed to be able to use their Codex quota? For instance, as far as I understand, it is allowed to use it with OpenClaw, but does it extend to any other coding harness? Say I have an app (potentially a paid one) and want my users to use their Codex quota in it, is it permitted to do? As you can probably imagine that would unlock a lot of uses cases given smaller actors can't subsidize as much token costs, but unfortunately, and maybe expectedly due to the nature of subscriptions, I have not been able to find any answer regarding this.
I'm not sure they have "officially" said anything but they do allow Codex OAuth login for 3rd party coding agents: pi, opencode, etc. Employees on twitter have explicitly approved this.
That matches what I have seen, but I think I remember reading a tweet that had mentioned those "developing in the open" (not an exact citation, just based on what I remember), which made me wonder if it meant they considered this allowed only for open source software, or if they were intending to be much more permissive, essentially considering users can use their quotas wherever they want, or maybe even completely different rules, again I feel there could be more transparency regarding all of that.
I've commented elsewhere about just having simple rate limits tied to oauth tokens. This should not be that hard.
There is one simple policy: Subscriptions are for use on human scale of comprehension. API Keys are for everything else.
Anthropic can have a machine/bot get rate limited and people can build workflows using `claude -p` or something even better (like an SDK) , all the while using their OAuth tokens for max/pro.
I mean surely you can understand the the difficulty of their position, right? It's as if Waymo offered a subsidized, subscription based plan that models a certain type of ridership as typical but then people start scheduling rides on a timer with no one in it, far outside the original use case of "Get me from point A to point B". And of course the line between what is acceptable is quite fuzzy. You could imagine it being seen as okay to send a rider-less Waymo to pick up groceries occasionally - but not to schedule one every single day at 4:30PM to pick up a single ice cream cone.
You can argue that this is unfair and they should provide clearer guidance. Well - as soon as they do people find ways to skirt the letter of the rules to once again take advantage of the economics of the subscription model. So should they just scrap the entire plan? Ruin it for people who are using it as it was intended (coding agent, light experimentation/headless use outside of that)? That doesn't seem right either.
I don't think anyone would want the type of user that OpenClaw users are as customers...
There will be a time for OpenClaw, but in the current world with limited compute, that time is not now.
I think HN needs a regular reminder that most things sold are commodities -without limits or re-use. Coal and wheat have no DRMs.
This kind of thing is the exception. Subsidized subscriptions work to distort the power of the market. The more successful they are (in destroying competition), the worse it leaves consumers.
While i get the individual steps that leads them to this "difficult position", I think i'll just keep telling everybody to cancel their sub and make sure to not get locked in.
> Most things are sold as commodities without limits or re-use.
This is somehow doubly wrong. Not only are most economic goods NOT commodities, there are plenty of economic analogs to AI subscriptions (streaming, telecom, gyms, buffets) and none of them operate as "unlimited with no restrictions on re-use". Really just terribly misinformed way of thinking here.
Looks like they are trying to correct course now, but they’ve already lost the trust, and with the new lower limits, it’s probably not worth using it in OpenClaw
Claude CLI has a server mode - am I missing something here, or could we all just claude --server and let openclaw use claude via a2a?