Anthropic officially bans using subscription auth for third party use

Their models are accessed via their backend; the models are not the backend. Their backend is unique from a features perspective, while their models are unique by virtue of training data+technique.

> They make it impossible for smaller players to compete.

No they don't. Ollama is healthy, OpenRouter, and quite a few others. Then there are actual model makers such as DeepSeek, Google, Mistral, Zai, etc. The lists march on and nobody wanting access to LLMs is left in the cold. Somehow you're still trying to stick terms which just don't apply to the status quo. Unless you believe that Anthropic's offerings are so unique and critical to people's well-being that they should be treated as a public utility or something, which is laughable.

> So was Über, so was AirBNB

There is the option of not using them. But they actually have cornered a part of the market as well, even if that part is primarily comprised of well-to-do's ready to throw money to avoid the slightest inconvenience.

Anthropic is neither a monopoly nor has a dominant market position. Generally standards applied to companies like that are very different due to good reason.

The Distillation Irony In early 2025, Anthropic published a paper accusing DeepSeek and Moonshot AI (Kimi) of distilling Claude’s outputs — essentially claiming that competitors were extracting Claude’s capabilities by studying its responses. Read that again. Anthropic complained that external parties were extracting intellectual value from model outputs. Meanwhile, every user building novel systems through Claude Code was transmitting their complete intellectual work product directly to Anthropic’s servers — not through indirect output analysis, but through direct, structured, plaintext API calls. The company that accused others of extraction has the most direct extraction pipeline imaginable: the product itself.What “We Don’t Train on API Data” Actually Means Anthropic’s usage policy states they don’t use API inputs for model training by default. Let’s take that at face value. It doesn’t matter. Training is one use of data. Access is the structural advantage. When a platform has visibility into what its most sophisticated users are building — the problems they’re solving, the architectures they’re designing, the markets they’re entering — that visibility has value independent of whether it enters a training pipeline. Download the Medium app Consider: Product roadmap intelligence: Seeing what users struggle to build tells you what products to offer Market signal extraction: Knowing what problems users are solving reveals market demand before it’s public Architecture pattern harvesting: Novel system designs discussed in sessions can inform internal engineering Competitive timing: Awareness of what users are building allows strategic timing of competing offerings None of these require “training on API data.” They require reading it. And the architecture ensures it’s readable. The Prior Art Problem I have 20 DOIs. Every paper is timestamped, peer-reviewed, and independently hosted on Zenodo. My prior art chain is documented. But here’s the asymmetry: a platform can backdate. A platform can see your work in February and publish a “research paper” in March that appears to have been in development for months. Internal git histories aren’t public. Internal research timelines aren’t auditable. The burden of proving independent invention falls on the party with less institutional power — always the individual. DOIs prove I published. They don’t prove the platform didn’t read my sessions before forming its own research agenda. What I Had to Build When I realized the scope of exposure, I did the only thing that changes the architecture: I built a local transport proxy. It sits between the CLI tool and the upstream API. Before any request leaves my machine, it: Parses the JSON request body Walks every message and system prompt Replaces novel concepts — product names, algorithm names, economic parameters, architectural terms — with opaque tokens Strips fingerprinting headers Forwards the modified request upstream Anthropic’s servers now receive conversations about ת:a7f3 instead of my actual product names. They see ת:b2c1 instead of my algorithm parameters. The conversation is still functional — the model responds coherently because the tokens are consistent within the session — but the intellectual content is obfuscated. I had to build infrastructure to protect my IP from my own tool. That sentence should disturb you. The Structural Problem This isn’t about Anthropic specifically. It’s about the architecture of cloud-based AI tooling. Every major AI coding assistant — GitHub Copilot, Cursor, Claude Code, Windsurf — operates the same way. Your complete working session transits through the provider’s infrastructure. The provider has full visibility into your intellectual work product. The user has no visibility into what happens to it after transmission. This is a one-way mirror. You can see the tool. The tool’s operators can see everything you build with it. The implications compound: Solo developers and small teams have no leverage to negotiate data handling terms Novel IP — the kind that creates new markets — is the most valuable and the most exposed Speed of development — the primary value proposition of AI tools — requires transmitting more context, not less The users who benefit most from AI tools are the ones who expose the most IP This is the opposite of how intellectual property protection should work. What Needs to Change 1. Local inference must become viable for development workflows. Not as a downgrade — as a first-class option. Models that run on local hardware, with no API calls, no telemetry, no transmission. 2. Transport-layer IP protection must be built into AI tools, not bolted on by users. The proxy I built should be a standard feature, not a custom security measure. 3. Auditable data handling. If a platform receives your intellectual work product, you should have cryptographic proof of what they received and contractual guarantees — with teeth — about what they do with it. 4. Right to erasure with verification. Not a settings toggle. A verifiable, audited deletion of your session data with third-party attestation. 5. IP exposure warnings. Before transmitting novel content through an AI tool, users should receive explicit warnings about what’s being sent and where. None of this exists today. Users are building the future on platforms that have full visibility into those blueprints, with no structural accountability for what happens to that visibility. The Question I Can’t Answer I can prove my work is original. I have 20 DOIs, timestamped and independently hosted on Zenodo. I have the code, the commit histories, the architectural documents. What I can’t prove is what Anthropic — or any other AI platform — does with 778 sessions of complete, structured, parseable intellectual work product transmitted to their servers as a condition of using the tool. That’s the asymmetry. And until the architecture changes, every builder using cloud-based AI tools is operating under the same exposure.

But again, there's other things to consider. People are more likely to blame Anthropic, not OpenCode, when they run out of tokens.