paperclipai/paperclip · info

[opencode-local] Remote model availability probe for "${mode

Error message

[opencode-local] Remote model availability probe for "${model}" timed out after ${probeTimeoutSec}s; proceeding with the configured model.

What it means

Before running opencode on a remote execution target, the adapter probes model availability by running `opencode models` there, bounded by probeTimeoutSec (20s default, 120s for sandbox transport, capped by input.timeoutSec). The probe is explicitly best-effort: on timeout it warns and proceeds with the configured model, because the real invocation is authoritative and a failed probe must never kill the run (that behavior previously lost agent work mid-flight).

Source

Thrown at packages/adapters/opencode-local/src/server/execute.ts:133

    input.executionTarget,
    input.command,
    ["models"],
    {
      cwd: input.cwd,
      env: input.env,
      timeoutSec: probeTimeoutSec,
      graceSec: input.graceSec,
      onLog: async () => {},
    },
  );

  // The remote availability probe is a best-effort pre-flight guard, not a gate.
  // If `opencode models` itself cannot run on the target — timeout, transient CLI
  // error, provider hiccup — do NOT abort the run. The real invocation is
  // authoritative, so a probe that can't execute must never be fatal. (Previously
  // these threw and crashed runs mid-flight, losing the agent's work + disposition.)
  if (probe.timedOut) {
    console.warn(
      `[opencode-local] Remote model availability probe for "${model}" timed out after ${probeTimeoutSec}s; proceeding with the configured model.`,
    );
    return;
  }

  if ((probe.exitCode ?? 1) !== 0) {
    const detail = firstNonEmptyLine(probe.stderr) || firstNonEmptyLine(probe.stdout);
    console.warn(
      `[opencode-local] Remote \`opencode models\` could not run for "${model}"${
        detail ? ` (${detail})` : ""
      }; proceeding with the configured model.`,
    );
    return;
  }

  const models = parseOpenCodeModelsOutput(probe.stdout);
  if (models.length === 0) {
    console.warn(

View on GitHub (pinned to 120ae5428f)

Solutions

  1. No action strictly required — the run proceeds with the configured model; check whether the run itself succeeds.
  2. If runs then fail on the model, debug the remote target directly: run `opencode models` there and time it.
  3. Raise the caller's timeoutSec (probe timeout is min(timeoutSec, preset cap)) for slow targets.
  4. Set OPENCODE_ALLOW_ALL_MODELS=1 (run env or process env) to skip the probe entirely — intended for gateway-routed models that never appear in `opencode models` output.

Example fix

# before
[opencode-local] Remote model availability probe for "anthropic/claude-sonnet-4-20250514" timed out after 20s; proceeding with the configured model.

# after — skip the probe for gateway-routed models
export OPENCODE_ALLOW_ALL_MODELS=1
# or give slow targets more headroom in the adapter call: ensureRemoteOpenCodeModelConfiguredAndAvailable({ ..., timeoutSec: 60 })
Defensive patterns

Strategy: fallback

Validate before calling

const t0 = Date.now();
const out = await runAdapterExecutionTargetProcess(runId, target, command, ["models"], { timeoutSec: 10, /* ... */ });
const probeHealthy = !out.timedOut && (out.exitCode ?? 1) === 0 && Date.now() - t0 < 15_000;
if (!probeHealthy) {
  // either skip the run gate or log-and-continue, mirroring the adapter's best-effort policy
}

Prevention

When it happens

Trigger: `opencode models` on the remote target exceeding the probe timeout: slow remote cold start, network latency to the target, provider auth hanging, overloaded sandbox; notably more likely at the 20s non-sandbox limit.

Common situations: Cold remote hosts where opencode first-run setup is slow; high-latency SSH/sandbox transports; provider outages that stall model listing; very large model catalogs.

Understand the failure class

Related errors


AI-assisted analysis of paperclipai/paperclip@120ae5428f (2026-08-18). Data as JSON: /api/errors/6a22a071071deccb. Report an issue: GitHub.