How do their APIs compare?

These are two very different kinds of software, so "their APIs" really means two different things: opencode exposes an application/server SDK for controlling a coding agent, while sentry-javascript exposes a library API for instrumenting applications to capture errors/traces. Here's the comparison based on what's visible in the retrieved code.

opencode: a client/server SDK around a running agent process

opencode's API is built around createOpencodeClient from @opencode-ai/sdk/v2, which is an HTTP client for talking to a local or remote opencode server:

• The CLI itself is the primary consumer of its own SDK. In acp.ts, the CLI starts a Server, then immediately creates an SDK client pointed at that server's baseUrl [packages/opencode/src/cli/cmd/acp.ts:L1-L32]. This client/server split is core to the design — even "local" invocations spin up an in-process HTTP server and use the SDK to talk to it, rather than calling internal functions directly, e.g. the fetchFn wiring in run.ts that routes SDK requests through Server.Default().app.fetch(...) [packages/opencode/src/cli/cmd/run.ts:L948-L960].
• The SDK is method/resource-oriented: sdk.event.subscribe() returns an async-iterable .stream of typed events (message.updated, etc.) that callers consume in a loop [packages/opencode/src/cli/cmd/run.ts:L668-L707]. This is an event-streaming API, not a request/response-only API.
• There's a distinction between interactive/attach modes (runInteractiveMode for an existing SDK client vs. runInteractiveLocalMode for in-process, no external HTTP) documented directly in the module comment [packages/opencode/src/cli/cmd/run/runtime.ts:L1-L14], showing the API is designed to be transport-agnostic — the same SDK shape works whether the server is local or remote.
• Underneath the SDK, there are also internal Effect-based "Service" APIs (e.g. Auth.Service with get/set/remove/all [packages/opencode/src/auth/index.ts:L50-L98], Agent.Service with get/list/defaultInfo/defaultAgent [packages/opencode/src/agent/agent.ts:L324-L363]) which are composed via a Layer/Context.Service dependency-injection pattern rather than exported as a public surface — these back the SDK/server rather than being consumer-facing.

So opencode's API surface is fundamentally imperative/session-oriented: create a client, create/attach to a session, subscribe to a stream of events, send prompts, react to tool calls.

sentry-javascript: an SDK API for instrumenting apps

By contrast, sentry-javascript's API (as seen in the snippets) is organized around initialization + capture + context propagation, spread across many platform-specific packages:

• Each package (@sentry/astro, @sentry/aws-serverless, @sentry/browser, etc.) builds on a shared core (@sentry/core) and re-exports/wraps functions like captureException, continueTrace, startSpan, withIsolationScope, getCurrentScope — visible in the Astro middleware's import list [packages/astro/src/server/middleware.ts:L1-L35].
• The API is largely functional and scope-based rather than client-object-based from the consumer's perspective: functions like getActiveSpan, getClient, setHttpStatus, getTraceMetaTags operate against an ambient current scope/client rather than requiring you to hold and thread an object everywhere (contrast with opencode's explicit sdk client object passed through execute(sdk: OpencodeClient) [packages/opencode/src/cli/cmd/run.ts:L668]).
• Integration-specific glue code adapts framework primitives into this common capture API — e.g. buildSdkInitFileImportSnippet for Astro just emits an import statement to wire in an SDK init file [packages/astro/src/integration/snippets.ts:L7-L14], and the Vite integration wires up sourcemap upload via sentryVitePlugin [packages/astro/src/integration/index.ts:L81-L120].
• There are also narrower utility-style APIs, like extractType for normalizing error names including WebAssembly exceptions [packages