There is a particular kind of frustration that comes from building on top of a platform, shipping something useful, and then finding out the platform’s legal team has changed the rules underneath you. Developers who built CLI coding assistants on top of Anthropic’s API experienced exactly that when OpenClaw and similar tools found themselves in a policy gray zone. Now Anthropic has clarified its position, and the short version is: third-party Claude CLI usage in the style of OpenClaw is allowed again.
The longer version is worth understanding, because it says something about how Anthropic thinks about its API ecosystem and where it draws the line.
What OpenClaw Is and Why It Got Complicated
OpenClaw is a multi-provider CLI tool for AI-assisted development. Like aider or Open Interpreter, it lets developers work with large language models from the terminal, supporting multiple backends through a provider abstraction layer. The architecture is common enough: you configure a provider (Anthropic, OpenAI, Google, etc.), point it at a model, and the tool handles context management, file diffing, and conversation formatting on top.
The pattern looks roughly like this in practice:
# Configure Anthropic as your provider
openclaw config set provider anthropic
openclaw config set model claude-sonnet-4-6
# Start a coding session
openclaw chat --files src/Under the hood, OpenClaw is making standard API calls to api.anthropic.com/v1/messages, passing the contents of your files as context and streaming back responses. Nothing unusual from a technical standpoint.
The problem was never the API calls themselves. It was how Anthropic’s usage policy was worded around competitive products. Clauses that restricted building “products or services that compete with Anthropic” are standard boilerplate across AI API providers, but their scope is genuinely ambiguous when applied to developer tooling. Is a CLI coding assistant that supports multiple providers a competing product? What about one that only supports Claude but wraps the API in a terminal interface that resembles Claude Code?
Anthropics own Claude Code is a first-party CLI tool, which made the situation murkier. A third-party CLI that does roughly the same thing from a user’s perspective occupies an uncomfortable position.
The Previous Restriction
At some point in early 2026, Anthropic’s interpretation of its own usage policies shifted in a way that cast doubt on whether tools like OpenClaw could continue operating. The OpenClaw Anthropic provider documentation became a reference point for this ambiguity, with the project noting that Anthropic had flagged concerns about this usage pattern.
The HN thread that surfaced this reversal drew significant discussion, which is unsurprising. Developers building on any AI API have a strong interest in knowing whether the platform will stay stable under their tooling choices. A policy that could retroactively invalidate your infrastructure investment is a serious risk factor.
For context, this is not a new problem in the AI space. OpenAI went through similar periods of policy ambiguity around GPT-based coding tools before settling into a clearer stance. The issue tends to arise whenever a foundation model provider also ships first-party developer products: the incentive to protect those products through usage policies creates pressure that ends up restricting the ecosystem.
What Changed
Anthropics updated position, as documented on the OpenClaw provider page, is that this style of CLI usage is permissible. The key distinction appears to be around the nature of the tool: a CLI that uses the Anthropic API to provide coding assistance to individual developers, even one that offers similar functionality to Claude Code, is not the kind of competitive threat the policy was designed to prevent.
This makes sense when you think about what Anthropic is actually trying to protect. The concern behind competitive use restrictions is typically about someone using your API to build a cheaper wrapper they sell as a substitute for your own product, undercutting your pricing while free-riding on your infrastructure costs. A developer tool that happens to also work with OpenAI and Google models, used by individual engineers in their terminals, is not that.
The practical test that seems to have emerged is something like: are you building a product that replaces a direct Anthropic offering for paying customers at scale, or are you building developer tooling that happens to use Claude as a backend? The latter is fine.
Technical Implications for CLI Tool Builders
If you are building something in this space, the OpenClaw documentation is now a useful reference for how to structure Anthropic integration in a way that is explicitly sanctioned. A few technical considerations worth keeping in mind:
Context window management. Claude Sonnet 4.6 supports a 200k token context window, which means you can pass significantly more file context than older models allowed. OpenClaw and similar tools typically implement sliding window or summarization strategies anyway, but with Anthropic’s current models you have more headroom before those strategies kick in.
Prompt caching. Anthropic supports prompt caching for inputs above a certain token threshold, which matters a lot for CLI tools that repeatedly send large file contexts. The API pricing for cached tokens is significantly lower. A well-implemented CLI tool should be using the cache_control parameter on stable context blocks:
messages = [
{
"role": "user",
"content": [
{
"type": "text",
"text": file_contents,
"cache_control": {"type": "ephemeral"}
},
{
"type": "text",
"text": user_query
}
]
}
]This can cut costs substantially on longer sessions where the file context stays stable and only the conversation changes.
Extended thinking. Claude’s extended thinking mode is worth considering for complex refactoring tasks. It trades latency for reasoning quality, which is a reasonable tradeoff for the kind of multi-step code transformations that CLI tools often handle.
Rate limits. Anthropic’s API rate limits vary by tier and model. For a CLI tool doing interactive coding sessions, the limits are generous enough that most individual developers will not hit them. For a hosted version of a CLI tool serving many users concurrently, the limits matter more, and this is also where the competitive product distinction becomes relevant again.
The Broader Ecosystem Question
This situation highlights a structural tension that is going to keep recurring as AI providers mature. The most capable models are controlled by companies that also build their own developer tooling. That creates an inherent conflict of interest when those companies write usage policies.
Anthropics current resolution, permitting third-party CLI tools, is the right call for the ecosystem. The alternative, where only first-party tooling is allowed, would be both technically and commercially destructive. Aider, for instance, has a large and active user base that prefers its workflow to Claude Code. Forcing those users off the platform does not help Anthropic; it just sends them to OpenAI or Mistral.
There is also a quality argument. Third-party tools push Anthropic’s first-party products to be better. Claude Code has improved considerably, and some of that pressure comes from the existence of capable alternatives that users will switch to if the official tool falls short.
The OpenClaw situation is a small data point, but it suggests Anthropic understands this dynamic. Locking down the ecosystem might protect short-term revenue from Claude Code subscriptions, but it would cost far more in API usage from the developer community that builds and uses these tools.
For now, if you are building a CLI coding assistant on top of Claude, the path is clear. Use the official API, follow the rate limits, do not build something designed to wholesale replace Anthropic’s own subscription products, and you are on solid ground.