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.