Support for Ollama – looking for ideas / guidance

[suhasparuchuri]

I’m exploring adding Spec Kit support for Ollama and wanted to check if anyone here has looked into this before or has ideas on the best approach.

[mnriem]

Hey! Thanks for kicking off this thread — Ollama support is a really reasonable thing to want. 🙂

One thing worth clarifying up front, since it shapes the "best approach": Ollama is a local model runtime rather than a coding agent. Spec Kit integrations attach to an agent that has a command/skill surface — a place to install the speckit.* commands and a defined args/tool-calling contract (Claude Code, Copilot, Gemini CLI, Cursor, etc.). Ollama on its own doesn't have that surface; it serves models over an API, so there isn't an obvious spot for the commands to live.

The good news is that Ollama has been growing agentic building blocks lately — native tool/function calling, and ollama launch, which can start external coding tools (OpenCode, Claude Code, Codex, VS Code, Droid) pointed at a local model. So the most promising path is probably indirect: use an agent that already works with Spec Kit and can talk to Ollama as its backend — e.g. ollama launch vscode pointed at a local Ollama model — then drive Spec Kit through that agent's existing integration.

If that framing sounds right, the interesting open question becomes less "how do we add Ollama" and more "which local models reliably follow the multi-step Spec Kit prompts + tool-calling contract" — that's where testing and shared notes would help a lot.

---

Posted on behalf of @mnriem by GitHub Copilot (model: Claude Opus 4.8).

[ameerhamzaa47]

One possible approach would be to use Ollama as the local model backend while keeping the existing Spec Kit integration through a supported coding agent. This would avoid treating Ollama itself as an agent and could make the integration easier to test across different local models.

[Saqlaindigu]

Adding the missing concrete layer: whichever agent you keep in front of a local backend, the first wall you hit is model-id resolution, not the proxy itself. For Claude Code (the most common spec-kit agent), pointing it at any Anthropic-compatible server/router is:

export ANTHROPIC_BASE_URL="https://your-endpoint.example/v1"
export ANTHROPIC_AUTH_TOKEN="<token if your server requires one>"

Two gotchas that bite nearly everyone doing this:

1. Path doubling. The base URL must not include the messages path. Depending on client version, a stray /v1 can turn into /v1/v1/... requests — which return a 404 that looks exactly like "model not found" but is really a doubled path.

2. Client-side model validation. Claude Code checks model ids against its built-in Anthropic list before sending anything, so a local id like qwen3-coder-30b gets rejected with a 404 even though your server lists it. The working trick is to route the id through an alias slot and select the alias instead of the raw id:

export ANTHROPIC_DEFAULT_SONNET_MODEL="qwen3-coder-30b"
# then launch claude with "sonnet" selected — not the raw id

(ANTHROPIC_CUSTOM_MODEL_OPTION does not bypass this despite some tutorials — it only adds a picker entry.)

Before debugging anything else, confirm what the endpoint actually exposes:

curl -s "$ANTHROPIC_BASE_URL/v1/models"

Once the agent runs against your chosen backend, the speckit command set works unchanged on top of it — spec-kit attaches to the agent, not the model.

We maintain a step-by-step walkthrough of this exact class of setup (Claude Code / OpenCode / Cline against custom endpoints, with an error-to-cause table covering the two gotchas above): Fixing custom-endpoint setups