Model Recommendations

SideCar works with local Ollama models, Kickstand, Anthropic, OpenAI, OpenRouter, Groq, and Fireworks. This page helps you pick the right model for your hardware and use case. Numbers come from the Model Eval Results page, which documents scores from the deterministic eval harness (92 cases: 57 agent + 35 prompt).

Quick Picks

Local Models

SideCar’s local context cap is 32,768 tokens (LOCAL_CONTEXT_CAP). Very large prompts cause extreme first-token latency on consumer hardware regardless of a model’s native context window, so this cap applies to all Ollama and Kickstand requests.

RAM ceiling on 36 GB hardware: models larger than ~12 GB risk OOM when another model is already loaded. Always unload the active model before pulling a large one. qwen3.6 (23 GB) caused a kernel panic in testing — it is excluded from this list.

Cloud Models

Cloud models are accessed via their respective APIs. SideCar stores API keys in VS Code’s SecretStorage per-provider — switching backends doesn’t overwrite keys. Use SideCar: Switch Backend or the gear button in the chat header to change providers.

Anthropic prompt caching: SideCar automatically enables prompt caching for the Anthropic backend. Cache hits reduce input token costs by ~90%. On a typical agent session the system prompt and tool schemas are cached after the first turn, so most of the per-turn cost is output tokens only.

OpenAI rate limits: SideCar’s system prompt + tool schemas total ~23K tokens per request. The free OpenAI tier (30K TPM) is exhausted after 1–2 requests. The gpt-4o-mini / gpt-4.1-mini 200K TPM org ceiling can also cause failures during heavy usage. A paid tier with higher TPM limits is required for reliable operation.

Tool Use Compatibility

SideCar’s full agentic capabilities — file editing, shell commands, git operations, web search, and all 86 built-in tools — require function calling (tool use). Models without it fall back to chat-only mode automatically.

Reliable tool use (native function calling)

These models pass tool-use cases consistently in the eval harness:

• All current Claude models (claude-haiku-4-5, claude-sonnet-4-6, claude-opus-4-7)
• gemma4:e4b, gemma4:2b
• qwen3-coder:30b, qwen3-coder:8b, qwen2.5-coder:7b
• llama3.1:8b, llama3.3:70b
• deepseek-coder-v2:16b
• phi-4:14b
• codestral:22b
• deepseek-v4-pro (Fireworks)
• gpt-4o, gpt-4o-mini (OpenAI, paid tier)

Text-based tool call fallback (qwen3 / Hermes style)

Some models emit tool calls as structured text inside the model’s response rather than via the API’s native function-calling mechanism. SideCar’s textParsing.ts module parses these automatically, so models like qwen3.5 and Hermes-format models work with the full tool suite. Performance is slightly less reliable than native function calling — expect occasional parse failures on complex multi-tool turns.

Models in this category: qwen3.5:latest and any Hermes-format model. Check the eval results page for per-case failure rates before relying on these for production agent workflows.

No tool use / incompatible

Hardware Requirements

These estimates apply to Q4_K_M quantization (the default Ollama pull format). Actual VRAM usage varies by quant level, batch size, and context in use. The figures below assume a 32K context window (SideCar’s LOCAL_CONTEXT_CAP).

Unified memory (Apple Silicon): VRAM and system RAM share the same pool. A 36 GB M3 Max or M4 Pro can comfortably run models up to 14B. For 30B models, close other GPU-heavy applications first. 70B models require at least a 64 GB configuration.

Multi-GPU: Ollama and Kickstand both support splitting large models across multiple GPUs. Set OLLAMA_NUM_GPU_LAYERS or use Kickstand’s layer-assignment config if you need to run a 30B+ model on a multi-GPU workstation.

The Architect / Editor Split

SideCar supports a two-model workflow where a larger, slower model does planning and a smaller, faster model executes edits. Configure this with sidecar.editorModel in your workspace or user settings.

{
  "sidecar.model": "claude-sonnet-4-6",
  "sidecar.editorModel": "claude-haiku-4-5-20251001"
}

In this setup, sidecar.model handles intent classification, plan generation, and reasoning-heavy turns. sidecar.editorModel handles edit_file, write_file, and other execution turns where speed matters more than reasoning depth. The agent loop routes tool-execution turns to the editor model automatically.

Example configs

Local: quality planning + fast execution

{
  "sidecar.model": "qwen3-coder:30b",
  "sidecar.editorModel": "qwen3-coder:8b"
}

Hybrid: cloud planning + local execution (minimize API spend)

{
  "sidecar.model": "claude-haiku-4-5-20251001",
  "sidecar.editorModel": "qwen2.5-coder:7b"
}

Cloud: premium planning + budget execution

{
  "sidecar.model": "claude-sonnet-4-6",
  "sidecar.editorModel": "claude-haiku-4-5-20251001"
}

When sidecar.editorModel is not set, the main model handles all turns. The split is optional — most users run a single model.

What to Avoid

Common failure patterns across all models

Even well-performing models have consistent weak spots. Be aware of these when reviewing agent output:

• Verbosity on simple questions (rule3-concise-prose): all tested models occasionally write paragraphs for one-sentence questions. If this is a recurring issue, add a conciseness reminder to your SIDECAR.md.
• Error-recovery hesitation: models sometimes find the right file but ask “would you like me to read it?” instead of reading it directly. SideCar’s Rule 5 was strengthened in v0.87 to reduce this.
• Ambiguous rename targets: when two functions have similar names, models tend to guess and then hedge. If a rename goes to the wrong target, undo and re-state the target function name explicitly.
• Regex search avoidance: some models read files one by one instead of using grep with a pattern. The agent loop’s cycle detection catches runaway file-reading loops, but you may need to steer the model toward search_files on large codebases.