Hacker News Reader

Comment by Wowfunhappy | Hacker News Reader

Given that Claude Code is a scriptable CLI tool with an SDK, why can't OpenCode just call Claude instead of reusing its auth tokens?

View on HN

You can't control it to the level of individual LLM requests and orchestration of those. And that is very valuable, practically required, to build a tool like this. Otherwise, you just have a wrapper over another big program and can barely do anything interesting/useful to make it actually work better.

What can't you do exactly? You can send Claude arbitrary user prompts—with arbitrary custom system prompts—and get text back. You can then put those text responses into whatever larger system you want.

May as well just use Claude Code then.

Well, I do use Claude Code myself, but I'd thought the point of OpenCode was that it could combine the responses of multiple LLMs.

You don't get a simple request/response paradigm with claude code: 1 message from the user results in a loop that usually invokes many inner LLM requests, among other business logic, resulting in some user-visible output and a bunch of less visible stuff (filesystem changes, etc). You control an input to the outer loop: you can only do some limited stuff with hooks to control what happens within the loop. But there's a lot happening inside that loop that you have no say over.

A simple example: can you arbitrarily manipulate the historical context of a given request to the LLM? It's useful to do that sometimes. Another one: can you create a programmatic flow that tries 3 different LLM requests, then uses an LLM judge to contrast and combine into a best final answer? Sure, you could write a prompt that says do that, but that won't yield equivalent results.

These are just examples, the point is you don't get fine control.

This is what ACP and https://github.com/zed-industries/claude-code-acp enables. ACP controls agents - there is native support in Copilot CLI and Gemini and adapters for claude code and codex.

wow. ACP is used within zed so I guess zed is safe with ACP using claude code

I wonder if Opencode could use ACP protocol as well. ACP seems to be a good abstraction, I should probably learn more about it. Any TLDR's on how it works?

According to Opus, ACP is designed specifically for IDE clients (with coding agent “servers”), and there’s some impedance mismatch here that would need to be resolved for one agent cli to operate as a client. I havent validated this though.

—-

1. ACP Servers Expect IDE-like Clients The ACP server interface in Claude Code is designed for: ∙ Receiving file context from an IDE ∙ Sending back edits, diagnostics, suggestions ∙ Managing a workspace-scoped session It’s not designed for another autonomous agent to connect and say “go solve this problem for me.”

2. No Delegation/Orchestration Semantics in ACP ACP (at least the current spec) handles: ∙ Code completions ∙ Chat interactions scoped to a workspace ∙ Tool invocations It doesn’t have primitives for: ∙ “Here’s a task, go figure it out autonomously” ∙ Spawning sub-agents ∙ Returning when a multi-step task completes

3. Session & Context Ownership Both tools assume they own the agentic loop. If OpenCode connects to Claude Code via ACP, who’s driving? You’d have two agents both trying to: ∙ Decide what tool to call next ∙ Maintain conversation state ∙ Handle user approval flows

opencode acp -- start ACP (Agent Client Protocol) server

https://platform.claude.com/docs/en/agent-sdk/overview#get-s... reads to me like you have to use the public API for the Claude Agent SDK, not a Claude Code plan:

> Unless previously approved, we do not allow third party developers to offer Claude.ai login or rate limits for their products, including agents built on the Claude Agent SDK. Please use the API key authentication methods described in this document instead.

Reply on news.ycombinator.com