Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Anthropic Explicitly Blocking OpenCode

gist.github.com

Post reply on HN
Print view View original

161–164 of 164 posts

Re: Anthropic Explicitly Blocking OpenCode

#161

Post by BSchoolland »

Neither OpenCode nor Anthropic is in the wrong IMO. Opencode is trying to do a good thing by letting people choose which CLI to use with their subscription, and Anthropic is perfectly within their rights to enforce their own TOS. I don't have a problem with OpenCode breaking TOS but then it's up to them to deal with the problems that stem from that. I use OpenCode with my Claude Code subscription, and it's really good, so personally I hope OpenCode continues to find ways around it.

Re: Anthropic Explicitly Blocking OpenCode

#162

Post by BellCube »

chatmasta wrote: post #14

It’ll be interesting to see how far they take this cat and mouse game. Will “model attestation” become a new mechanism for enforcing tight coupling between client and inference endpoint? It could get weird, with secret shibboleths inserted into model weights…

Cat and mouse indeed... such is the way of the internet nomad

There ain't no client validation mechanism you can't fake with enough time, patience, reverse-engineering, and good-old-fashioned stubborn hacker ethos.

Re: Anthropic Explicitly Blocking OpenCode

#163

Post by uhuhuhuhuhuh »

Aurornis wrote: post #93

The title is misleading if you don’t read the whole text: Anthropic is not blocking OpenCode from the API that they sell. They’ve blocked OpenCode from accessing the private Claude Code endpoints. These were not advertised or sold as usable with anything else. OpenCode reverse engineered the API and was trying to use it. The private API isn’t intended for use with other tools. Any tool that used it would get blocked.

This is incorrect. There are no separate "private Claude Code endpoints."

I reverse engineered this over the past week. Both Claude Code and regular API users hit the same endpoint: https://api.anthropic.com/v1/messages

The only difference is the auth method - OAuth bearer token (sk-ant-oat01-...) vs API key (sk-ant-api03-...). The "blocking" is request body fingerprinting on the server side.

Here's what a working Claude Code request looks like:

  {
    "model": "claude-sonnet-4-20250514",
    "max_tokens": 32000,
    "stream": true,
    "metadata": {
      "user_id": "user__account__session_"
    },
    "system": [
      {"type": "text", "text": "You are a Claude agent, built on Anthropic's Claude Agent SDK."},
      {"type": "text", "text": ""}
    ],
    "tools": [
      {"name": "Task", ...},
      {"name": "Bash", ...},
      // 17 tools total, PascalCase names
    ],
    "messages": [...]
  }
And here's what OpenCode sends (blocked):

  {
    "model": "claude-sonnet-4-20250514",
    "max_tokens": 16000,
    "temperature": 0,           // Claude Code doesn't send this
    "stream": true,
                                // no metadata.user_id - required
    "system": [
      {"type": "text", "text": "You are OpenCode, an interactive CLI..."}
    ],
    "tools": [
      {"name": "bash", ...},    // lowercase, wrong schema
      {"name": "edit", ...},
      // 11 tools total
    ],
    "messages": [...]
  }
The API validates at least 5 things:

(1) system prompt must start with "You are a Claude agent, built on Anthropic's Claude Agent SDK."

(2) tools must match Claude Code's exact 17 tool definitions with PascalCase names

(3) headers must include anthropic-beta, x-app: cli, and claude-cli user-agent

(4) metadata.user_id must be present in a specific format

(5) temperature field must be absent.

Fail any of these:

  400 | This credential is only authorized for use with Claude Code
        and cannot be used for other API requests.
It's bypassable though. I wrote a local proxy that lets OpenCode (and other third-party clients) work with a Max subscription. The approach: run legit Claude Code through the proxy once to capture its exact request format - the full system prompt, all 17 tool schemas, headers. Cache that. Then when OpenCode sends a request, the proxy swaps its templates with Claude Code's cached ones, adds the required headers/metadata, and strips temperature. The OAuth token is already on disk at ~/.claude/.credentials.json (written by "claude login") - the proxy just reads it for each request.

Same endpoint, same request size, just different templates. Returns 200. OpenCode works with Max subscription again.

It's not endpoint separation, it's request body validation. The OAuth token is tied to an expected request format, but the format can be mimicked.

Re: Anthropic Explicitly Blocking OpenCode

#164

Post by kapelan »

This is the second time this month I've been frustrated with Anthropic's decisions. First, Claude Code after the 2.1.9 update completely broke - it lost context between messages and ignored previous prompts. The quality degraded overnight with no warning. So I migrated to Open Code while still using Claude as the underlying model since I was comfortable with it. Now they're blocking authorization for third-party clients? Last I checked, my subscription is for Claude, not exclusively for Claude Code. I really dislike these kinds of moves. Anthropic seems aware they have goodwill in the developer community largely due to good PR and a solid model - though Opus 4.1 was bad enough that I cancelled my subscription for the first time. If they want to play the corporate lock-in game, that's their choice. But I'm not interested. I just want a stable solution that's properly tested before release - not beta-tested on paying customers. Open Code works fine as a CLI. Claude Code is heading in the wrong direction with these restrictions. And honestly, Claude doesn't differentiate itself enough from competitors anymore to justify not switching to Codex or Gemini. For now, I'm done with Claude.
Post reply on HN