Hacker News Reader

Comment by gck1 | Hacker News Reader

I don't understand how this can be enforced without ridiculous levels of false positives. I'm truly baffled. The same with Claude Code situation.

gemini-cli, claude-code, codex etc, they ALL have a -p flag or equivalent, which is non-interactive IO interface for their LLM inference.

If I wire my tooling (or openclaw) to use the -p flag (or equivalents), is that allowed?

Okay, maybe they get rid of the -p flag and I have to use an interactive session. I can then just use OS IO tooling to wire OpenClaw with their cli. Is that allowed?

How does sending requests directly to the endpoints that their CLI is communicating with suddenly make their subsidized plans expensive? Is it because now I can actually use my 100% quota? If that's so, does it mean their products are such that their profitability stands on people not using them?

What is even going on?

View on HN

The direct answer is their clients play extra nice with their backend.

Specifically all optimize caching.

The indirect answer is for everyone using third party tools to play about there are 10x using it to spam or malicious use cases hammering their backend far cheaper than if it was by API.

These people are the false positives in this situation, but whether Google or Claude care is unlikely. They're happy to ban you and expect you to sign up for the API.

This has always been a worry when you use a service like Google.

claude -p is allowed as far as I'm aware.

if i understand correctly, they even have a wrapper around it to make it easier to use: the Claude Agent SDK

the thing that's disallowed is pretending you're the claude binary, logging in through OAuth

in other words, if you use some product thats not Claude Code, and your browser opens asking you to "give Claude Code access to your account", you're in hot water

as for how they detect it: they say they use heuristics and usage patterns. if something falls wildly out of the distribution it's a ban.

my take is that the problem is not the means of detection. that's fine and seems to work well. the problem is that its an instant outright ban. they should give you a couple warning emails, then a timeout, etc.

The Claude Agent SDK is explicitly disallowed from subscription use, as of a few days ago.

No it's not. You can't offer OAuth + the Claude Agent SDK in your own product, but you can use Claude Agent SDK locally by signing in through Claude Code.

It's no different than using Claude Code directly.

I’m aware of the tweet that says otherwise, but until they update their legal documentation, it’s still not allowed.

> OAuth authentication (used with Free, Pro, and Max plans) is intended exclusively for Claude Code and Claude.ai. Using OAuth tokens obtained through Claude Free, Pro, or Max accounts in any other product, tool, or service — including the Agent SDK — is not permitted and constitutes a violation of the Consumer Terms of Service.

https://code.claude.com/docs/en/legal-and-compliance#authent...

It's not about a tweet, just read your own quote.

You cannot authenticate with anything but Claude Code and Claude.ai.

But you do not need to authenticate with Claude Agent SDK (even though you can using env variables).

When you authenticate with Claude Code (allowed), Claude Agent SDK works without any further authentication.

It's really annoying that people keep trying to make this complicated because the inevitable end result is that they remove authless usage of the Agent SDK and save themselves the headache.

I really hate Clawdb-Moltb-OpenC-NanoCode or whatever half-baked project the grifters are on this week for ruining a good thing for the rest of us.

Did you read the second part? The ToS explicitly says that using the Agent SDK with Pro/Max authentication is disallowed. There is no ambiguity or interpretation here.

You do not need to give Agent SDK any credentials (completely optional)

But honestly, this is the side of intentionally misunderstanding that's actually preferable so: "You're absolutely right! You can't use your subscription to build yet another vibeslop harness, please refrain from doing so."

Why a couple warnings and timeout? 1 warning that the next incident will lead to a ban should be enough. Treat people like adults, not kids.

adults make mistakes and the situation was murky without clear guidance.

this was the experience for some claude subscribers just a couple weeks ago:

1. download opencode

2. select claude as a model

3. browser window opens, asking you to sign in. typical oauth screen.

4. everything works, prompt away

5. some days/weeks pass

6. you get permanently banned

now if you add one warning email just before step (6.) then that doesn't really help. what if it bounces? what if people don't check their emails? put a big flashy red warning into claude code? sure, but what if users accidentally dismiss it or simply do not understand it (non tech folks, non native english speakers)

its just the friendly and correct thing to do, in my opinion

> they say they use heuristics and usage patterns.

cache hit rate alone would stand out

Why do you mean by this? What cache?

Generally speaking, there's prompt caching that can be enabled in the API with things like this: https://platform.claude.com/docs/en/build-with-claude/prompt...

For a specific harness, they've all found ways to optimize to get higher cache hit rates with their harness. Common system prompts and all, and more and more users hitting cache really makes the cost of inference go down dramatically.

What bothers me about a lot of the discussion about providers disallowing other harnesses with the subscription plans around here is the complete lack of awareness of how economies of scale from common caching practices across more users can enable the higher, cheaper quotas subscriptions give you.

I feel like a lot of this would go away if they made a different API for the “only for use with our client” subscriptions. A different API from the generic one, that moved some of their client behaviors up to the server seems like it would solve all this. People would still reverse engineer to use it in other tools but it would be less useful (due to the forced scaffolding instead of entirely generic completions API) and also ease the burden on their inference compute.

I’m sure they went with reusing the generic completions API to iterate faster and make it easier to support both subscription and pay-per-token users in the same client, but it feels like they’re burning trust/goodwill when a technical solution could at least be attempted.

> I feel like a lot of this would go away if they made a different API for the “only for use with our client” subscriptions.

They literally did exactly that. That's what being cut off (Antigravity access, i.e. private "only for use with our client" subscription - not the whole account, btw.) for people who do "reverse engineer to use it in other tools".

Nothing here is new or surprising, the problem has been the same since Anthropic released Claude Code and the Max subscriptions - first thing people did then was trying to auth regular use with Claude Code tokens, so they don't have to pay the API prices they were supposed to.

What I was getting at is that the current API is still a generic inference endpoint, but with OAuth instead of an API key. What I'm suggesting is that they move some of the client logic up to the OAuth endpoint so it's no longer a generic inference endpoint (e.g. system prompt is static, context management is done on the server, etc). I assume they can get it to a point that it's no longer useful for a general purpose client like OpenClaw

prompt caching - big part of the reason why they can economically offer claude code plans. one of the ant team explain it here:

https://x.com/trq212/status/2024574133011673516

The heuristic detection approach is fine. The penalty ladder is broken.

Reasonable progression: warning email → quota throttle → AI Pro subscription suspended → Google account suspended.

They skipped to step 4 on a first offense, paid account, no appeal. That's not a terms enforcement system, that's a hostage situation. "Comply or lose your digital life."

The real lesson isn't "don't use OpenClaw." It's: never let one company own your primary identity infrastructure.

Is OpenClaw a product though? It's more like a system/framework.

Haha, no. I can tell you that it is so obvious and there is basically no false positives. Can’t share more details though.

If it makes you feel any better, some google employees have their personal accounts banned too (only Gemini access, not the whole account) for running opeclaw, and also have a hard time getting their account reinstated.

Its obvious why this us getting blocked open claw will make multiple orders if magnitude more requests. For each open claw user you could support tens of thousands of regular users.

The financial costs would clearly be ruinous.

I'm sure google employees that were banned can talk to a HUMAN to solve it.

The -p flag should be fine, so long as you don't use their oauth in a third-party tool. Gemini also supports A2A for this sort of thing.

But the question is - why is the -p flag fine? It hits the same endpoints with the same OAuth token and same quotas.

Comments section here and on related news from Anthropic seems to be centered around the idea that the reason for these bans is that it burns tokens quickly, while their plans are subsidized. What changes with the -p flag? You're just using cli instead of HTTP.

Are the metrics from their cli more valuable than the treasure trove of prompt data that passes through to them either way that justifies this PR?

I assume that -p is the same that "codex exec".

The difference is that in this case the agent loop is executed, which has all the caching and behaviour guarantees. What I assume OpenClaw is doing is calling the endpoint directly while retaining its own "agent logic" so it doesn't follow whatever conventions is the backend expecting.

How important is that difference, I can't say, but aside the cost factor I assume Google doesn't want to subsidize agents that aren't theirs and in some way "the competition".

> Are the metrics from their cli more valuable than the treasure trove of prompt data that passes through to them either way that justifies this PR?

Yes. The only reason they subsidise all-you-can-prompt subscriptions is to collect additional data / signals. They can use those signals to further improve their models.

Because the ToS explicitly says the -p flag is fine, but the Agent SDK is not.

There are examples of labs banning these use cases for sure, as well as the presence of terms and conditions allowing them to ban you for merely “competing” with them. If you’re building, it could be worth locking in a contract first.

> I don't understand how this can be enforced without ridiculous levels of false positives.

It's embarrassingly trivial, IMO - compare what antigravity reports for token to what the backend reports for token usage for that user.

I feel like it's about data quality. They want humans using the tools because that data is valuable and helps them improve the product. AI's using their product like OpenClaw makes their training missions harder. And even if you opt-out of training, they are still using your data for non-training purposes (you can't open out of that) and that human data is valuable.

Every subscription's profitability stands on people forgetting to unsubscribe, how is this surprising?

They're in the wrong business then. They're selling peak automation software, with the sales pitch of 'have AI do your work while you sleep'.

Are they banning their core offering? Are Ralph' loops also banned for building software? Because I can drain my quota with a simple bash loop faster than any OpenClaw instance.

You most likely don’t pay per call for your cellphone.

You most likely don’t pay per machine to use the gym.

You don’t pay per cup if they allow unlimited refills.

You are not supposed to go into an all-you-can eat buffet and stuff steaks into your bag.

Sometimes not all of us want to do the math à la carte for every thing we use in life. Don’t ruin it for us.

The buffet analogy breaks down here. Using OpenClaw isn't stuffing steaks in your bag — you're eating the same food, in the same seat, consuming the same tokens your subscription allows. Google banned you because they didn't like the plate you brought. Then took your house key as punishment.

The steaks-in-bag analogy would apply if you were somehow extracting MORE than your quota. You're not. You're just routing the same tokens differently.

You must not work in the SaaS business if you think that

Not sure if this is sarcasm, but I'll respond as if it isn't. Having worked my entire career to date in the SaaS business, it is well known in some verticals that a large portion of revenue comes from companies that literally do not know they have purchased your product. And when you have a large customer like that, people are very careful to walk quietly and not do anything to notify them. I've seen it happen quite a few times.

Reply on news.ycombinator.com