Copilot CLI with a local Ollama model: do Sume MCP tools still work?

A local model in GitHub Copilot CLI can drive Sume's hosted MCP tools, provided the model supports tool calling and streaming, and the tools still run on Sume's servers, not on your machine. GitHub's changelog entry for Copilot CLI 1.0.94 and later says local models are discovered through the /model command, and that selecting one does not turn on an offline-only mode.

The GitHub facts come from the changelog post Discover local models in GitHub Copilot CLI, read on 2026-10-11. Sume's facts come from the MCP overview, tools and gates and OAuth and API keys pages. The post says nothing about MCP servers, so the combination below is my reading, and the steps that depend on it are marked as things to test.

What does the GitHub post actually say?

The changelog says the /model command can now list models from running Ollama instances alongside configured and cloud models. Discovery does not add anything automatically: you review the provider details and endpoint, then choose "Add and use for this session" or "Add without switching". The models must already be installed, since the CLI does not install runtimes or download models. Ollama is the only local runtime the post names.

Two sentences matter for Sume. First, "Models must support tool calling and streaming." Second, GitHub says choosing a local model does not mean offline: GitHub telemetry continues, remote providers can still receive prompts over the network, and offline mode needs COPILOT_OFFLINE=true.

Where does each part of the call run?

Sume's tools are server-side. A tool call leaves your session as an HTTPS request to https://mcp.sume.com/mcp, and generation, job state and the wallet all live on Sume. The local model only decides which tool to call and with what arguments. Swapping a cloud model for a local one therefore changes the quality of those decisions, not what the tools do or what they cost.

What happens with COPILOT_OFFLINE=true?

The GitHub post names the variable but does not say what it does to remote MCP servers. Do not assume either way. A remote streamable HTTP server cannot work without a network, so if the setting blocks outbound calls, Sume's tools will fail with a connection error, and if it does not, they will run. Test with mcp_health, which Sume lists as a read-only readiness check, and take the answer from what you see.

Either result is safe for your wallet. A tool call that never reaches Sume cannot create a job, and a repeated call uses the same idempotency_key so it cannot create two.

How do I keep a small local model from overspending?

Smaller models make more argument mistakes, so use Sume's own gates rather than the model's judgement. Connect with OAuth mcp:read and the model sees only read-only tools; a write or paid call returns insufficient_scope. When you need generation, add mcp:write and require dry_run=true first, then submit with max_spend_usd. Sume enforces that cap only when you send it, so put it in your prompt or wrapper, not in the hope the model remembers.

Sume's docs also recommend generation_admission_preview before expensive bursts. A local model that loops on jobs_wait is harmless because the call is read-only and holds at most 55 seconds, but the same loop on generate_video is not, which is why the idempotency key is required on every paid call.