Little-Coder does not appear to support Zed editor ACP External Agent integration

[charly1r]

Version

little-coder 1.9.9
bundled pi 0.79.10
Zed 1.8.2

What I'm trying to do

I'm trying to use Little-Coder as a custom External Agent in Zed, he was asking for a new home.

Zed's documentation says custom agents must implement ACP (Agent Client Protocol).

I configured:

{
"agent_servers": {
"little-coder": {
"type": "custom",
"command": "C:\Users\charl\AppData\Roaming\npm\little-coder.cmd"
}
}
}

The thread appears in Zed, but stays on:

Loading...

and ACP logs show:

ACP: Disconnected
No active connection

Observations

Little-Coder launches successfully.

Running:

little-coder --mode rpc

produces structured JSON messages such as:

{"type":"extension_ui_request","method":"setTitle"}
{"type":"extension_ui_request","method":"notify"}
{"type":"extension_ui_request","method":"setWidget"}

Running the bundled Pi directly:

"C:\Users\charl\AppData\Roaming\npm\node_modules\little-coder\node_modules.bin\pi.cmd" --version

returns:

0.79.10

I searched the Little-Coder installation for ACP support and couldn't find anything that appears related to ACP integration.

Question

Does Little-Coder currently support ACP / Zed External Agent integration?

If not, is ACP support planned, or is there a recommended way to integrate Little-Coder with editors such as Zed while preserving the Little-Coder extensions and workflow?

[itayinbarr]

Short answer: no, little-coder doesn't support ACP today.

The structured JSON you saw from --mode rpc is pi's own internal extension-UI RPC (setTitle/notify/setWidget) — it's how the TUI talks to extensions, not the Agent Client Protocol — so Zed's ACP client never completes a handshake and you get "Disconnected". There's no ACP server in little-coder or in the bundled pi, which is why your search came up empty.

An ACP bridge is doable but non-trivial, and it really belongs in pi upstream rather than the little-coder wrapper — little-coder is a thin layer of extensions over pi, so an ACP transport added to pi would benefit both, whereas bolting it onto the wrapper would be fragile. I'll leave this open as a feature request to gauge interest; if a few people want it I'll raise it upstream.

In the meantime there's no clean way to drive little-coder's extensions/workflow from Zed's agent panel — running it in a Zed terminal is the only option. Thanks for the detailed write-up (the RPC trace was helpful).

[BMorgan1296]

I have it working using pi-acp as a bridge that instead calls little-coder by exporting PI_ACP_PI_COMMAND. A wrapper script also launches llama.cpp as well, that is killed upon Zed closure.

Not to be too cheeky, but I asked little-coder to do this for me a few days ago, then I saw this issue just now. Never say never!

Add this to your Zed settings.json (you may need to edit script paths/names)

  "agent_servers": {
    "codex-acp": {
      "type": "registry",
    },
    "little-coder": {
      "type": "custom",
      "command": "/usr/bin/little-coder-acp",
      "args": [],
      "env": {
        "LLAMACPP_BASE_URL": "http://127.0.0.1:8888/v1",
        "LLAMACPP_API_KEY": "noop",
        "PI_ACP_PI_COMMAND": "/usr/local/bin/little-coder",
        "PI_SKIP_VERSION_CHECK": "1",
      },
    },
  },

Here is the /usr/bin/little-coder-acp script which handles Zed calls, launches llama.cpp and starts pi-acp when you open up a little-coder agent session for the first time inside of Zed. Note that I have a higher context window (65K) enabled, and the LLAMA_SERVER and MODEL paths will need to be modified.

#!/usr/bin/env bash
set -euo pipefail

# ── Configuration ──────────────────────────────────────────────────────────
LLAMA_SERVER="$HOME/tools/llama.cpp/build/bin/llama-server"
MODEL="$HOME/models/Qwen3.6-35B-A3B-UD-Q4_K_M.gguf"

HOST="127.0.0.1"
PORT="8888"
BASE_URL="http://${HOST}:${PORT}/v1"

LOG_DIR="${XDG_STATE_HOME:-$HOME/.local/state}/lc-qwen"
LOG_FILE="${LOG_DIR}/llama-server.log"

SERVER_PID=""
ACP_PID=""

# Ensure Zed's environment can find npm/global binaries.
export PATH="${PATH:-/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin}"

log() {
  # Never write wrapper logs to stdout. ACP uses stdout for JSON-RPC.
  echo "$@" >&2
}

cleanup() {
  local code=$?
  trap - EXIT INT TERM HUP

  if [[ -n "${SERVER_PID}" ]] && kill -0 "${SERVER_PID}" 2>/dev/null; then
    log "Stopping llama-server..."
    kill "${SERVER_PID}" 2>/dev/null || true

    for _ in {1..30}; do
      if ! kill -0 "${SERVER_PID}" 2>/dev/null; then
        break
      fi
      sleep 0.2
    done

    if kill -0 "${SERVER_PID}" 2>/dev/null; then
      log "Force-stopping llama-server..."
      kill -9 "${SERVER_PID}" 2>/dev/null || true
    fi

    wait "${SERVER_PID}" 2>/dev/null || true
  fi

  exit "$code"
}

trap cleanup EXIT INT TERM HUP

# ── Sanity checks ──────────────────────────────────────────────────────────

if [[ ! -x "$LLAMA_SERVER" ]]; then
  log "llama-server not found or not executable: $LLAMA_SERVER"
  exit 1
fi

if [[ ! -f "$MODEL" ]]; then
  log "Model file not found: $MODEL"
  exit 1
fi

LC_BIN="$(command -v little-coder || true)"
if [[ -z "$LC_BIN" ]]; then
  log "little-coder not found on PATH."
  log "Set PATH correctly, or hard-code LC_BIN to the full little-coder path."
  exit 1
fi

PI_ACP_BIN="$(command -v pi-acp || true)"
if [[ -z "$PI_ACP_BIN" ]]; then
  log "pi-acp not found on PATH."
  exit 1
fi

# ── 1. Start llama-server ──────────────────────────────────────────────────

if curl -fsS "${BASE_URL}/models" >/dev/null 2>&1; then
  log "Something is already listening at ${BASE_URL}."
  log "Not starting a second llama-server, and not killing an existing one."
  log "Stop the existing server first, or change PORT in this script."
  exit 1
fi

mkdir -p "$LOG_DIR"
: >"$LOG_FILE"

log "Starting llama-server..."
log "llama-server log: $LOG_FILE"

(
  exec "$LLAMA_SERVER" \
    -m "$MODEL" \
    --host "$HOST" \
    --port "$PORT" \
    --jinja \
    --alias "qwen3.6-35b-a3b" \
    -c 65536 \
    -ngl 99 \
    --n-cpu-moe 999 \
    --flash-attn on \
    --no-mmap \
    -t 12
) >"$LOG_FILE" 2>&1 &

SERVER_PID=$!

log "Waiting for llama-server..."

for _ in {1..600}; do
  if curl -fsS "${BASE_URL}/models" >/dev/null 2>&1; then
    log "llama-server is ready."
    break
  fi

  if ! kill -0 "${SERVER_PID}" 2>/dev/null; then
    log "llama-server exited before becoming ready."
    log "Last 80 lines of llama-server log:"
    tail -n 80 "$LOG_FILE" >&2 || true
    exit 1
  fi

  sleep 1
done

if ! curl -fsS "${BASE_URL}/models" >/dev/null 2>&1; then
  log "Timed out waiting for llama-server."
  log "Last 80 lines of llama-server log:"
  tail -n 80 "$LOG_FILE" >&2 || true
  exit 1
fi

# ── 2. Launch pi-acp, but make it spawn little-coder ───────────────────────

export LLAMACPP_BASE_URL="$BASE_URL"
export LLAMACPP_API_KEY="${LLAMACPP_API_KEY:-noop}"

export PI_ACP_PI_COMMAND="$LC_BIN"
export PI_SKIP_VERSION_CHECK=1

log "Launching pi-acp with PI_ACP_PI_COMMAND=$PI_ACP_PI_COMMAND"

set +e
"$PI_ACP_BIN"
ACP_STATUS=$?
set -e

exit "$ACP_STATUS"

[charly1r]

@BMorgan1296 Wow, thank you, Morgan!

If it's not too much to ask, would you consider writing a guide on how to accomplish this?

A guide would be incredibly valuable for the community—not only for installing and configuring pi-acp, but also for demonstrating how PI extensions can be integrated with Little Coder. If pi-acp can be made to work, it opens the possibility of using many other PI extensions as well.

What makes this especially interesting is that PI isn't exposed like a standard installation. For example, I can't invoke it directly from the command line, so the integration process isn't immediately obvious.

Being able to extend Little Coder with the PI extension ecosystem would unlock access to a large and mature collection of tools and integrations, which could be a huge benefit for the community.

[BMorgan1296]

@BMorgan1296 Wow, thank you, Morgan!

If it's not too much to ask, would you consider writing a guide on how to accomplish this?

There was no configuration for pi-acp required, you only need to do npm install -g pi-acp.

As it spawns pi with pi --mode rpc, replacing that command using the PI_ACP_PI_COMMAND env variable to use the little-coder is all that is required, which is handled in Zed's settings.json.

Perhaps this could be added as a /bin/*.mjs target in this repo but I'll leave that decision up to @itayinbarr. I'm not sure what the cleanest way would be.

[itayinbarr]

@BMorgan1296 this is great — thank you (and it's very on-brand that you had little-coder set the whole thing up for you 😄, never say never indeed).

I've written your recipe up as a proper guide in v1.9.12: docs/zed-acp.md. Generalized the wrapper a little (start/stop llama-server, PATH-safe, stderr-only logging since ACP owns stdout), and documented the Zed agent_servers block plus the one lever that makes it click — pointing pi-acp's PI_ACP_PI_COMMAND at the little-coder binary. Credited you and @charly1r.

I'm keeping this issue open as the tracking item for native ACP. As I said above, I still think a first-class ACP transport belongs in pi upstream (so pi and little-coder both benefit), and the pi-acp bridge is the pragmatic path until then — but it's a bridge, not a built-in.

@charly1r — to your point about unlocking the wider pi extension ecosystem: you're right that this is what makes it interesting. Because pi-acp spawns via PI_ACP_PI_COMMAND, other pi extensions become reachable in principle too. One caveat worth flagging for anyone going down this path: little-coder launches pi with --no-extensions and wires in exactly its bundled set, so a globally pi install'd extension still won't load inside little-coder — the bridge exposes little-coder's own extension set to Zed, not pi's whole registry. Thanks both.

[charly1r]

@BMorgan1296 I found another interesting wrapper for little-coder, I can have side by side LC + ChatGPT + google chrome, that is nomally my holly trinity give it a shot.

https://github.com/lencx/noi

Qm-jmz give this project a test, you might like it.