Skip to content

@ai-sdk/openai-compatible provider fails to connect to LAN addresses — FailedToOpenSocket errno:0 #28418

Description

@desideratum

OpenCode 1.15.5 (Homebrew, macOS arm64) cannot connect to an @ai-sdk/openai-compatible provider on a LAN address. The embedded Bun runtime's fetch() fails with FailedToOpenSocket / errno: 0 for any non-localhost address. This affects HTTP and HTTPS equally.

Configuration:

"llama.cpp": {
  "npm": "@ai-sdk/openai-compatible",
  "name": "llama-server (remote)",
  "options": {
    "baseURL": "http://192.168.4.9:8080/v1",
    "apiKey": "no-key-needed"
  },
  "models": {
    "qwen3.6-27b:q8_0": {
      "name": "Qwen3.6-27B Q8_0 (local)",
      "limit": { "context": 262144, "output": 131072 }
    }
  }
}

Error (from log):

ERROR service=llm providerID=llama.cpp modelID=qwen3.6-27b:q8_0 error={"error":{"name":"AI_APICallError","cause":{"code":"FailedToOpenSocket","path":"http://192.168.4.9:8080/v1/chat/completions","errno":0}}}

Verified working from the same machine:

  • curl http://192.168.4.9:8080/v1/models — 200 OK
  • Node.js fetch() — 200 OK
  • System Bun 1.3.8 fetch() — 200 OK, including POST to /v1/chat/completions with streaming

The server responds correctly to every client except OpenCode's embedded runtime.

Also tested:

  • Hostname instead of IP — same failure
  • HTTPS via reverse proxy — same failure
  • NODE_TLS_REJECT_UNAUTHORIZED=0 — OpenCode logged the TLS warning (confirming it read the env var) but still failed with FailedToOpenSocket
  • apiKey in provider options vs. auth.json — no difference

Prior reports of the same bug:

The defect appears to be in how the Bun runtime is embedded in the OpenCode binary. Standalone Bun connects to LAN addresses without issue. Providers using their own HTTP stacks (e.g., @ai-sdk/amazon-bedrock via AWS SDK v3) are unaffected — only @ai-sdk/openai-compatible, which relies on the runtime's native fetch(), is broken.

This blocks use of OpenCode with any remote inference server on a LAN, which is a common deployment for GPU-equipped build machines separate from the development workstation.

Activity

alwold commented on May 22, 2026

@alwold

I'm seeing the same issue with a similar setup, remote llama.cpp on the same network, also on a macOS client. Random thought, but I'm wondering if this could be related to the macOS "Local Network" permission. It seems like it usually doesn't affect console apps, but maybe worth exploring?

github-actions commented on Jul 22, 2026

@github-actions
Contributor

To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions