Skip to content

Model providers

gdc doesn't ship a model. Instead it connects to a model provider — an endpoint that runs the LLM. gdc speaks the widely-used OpenAI-compatible API, so the same configuration works whether the model runs on your laptop or in the cloud.

Open, local models first

gdc is designed to work well with open-weight models you run yourself. Running the model locally means:

  • Your code stays on your machine. Nothing is sent to a third party.
  • No per-token bill. Experiment freely.
  • Reproducibility and autonomy. You choose and pin the exact model.

Hosted providers are fully supported too — pick whatever fits your needs.

Supported backends

Any OpenAI-compatible endpoint works. In practice that covers:

  • Local runners

    Run a model on your own hardware:

    • Ollama — http://localhost:11434/v1
    • llama.cpp server — http://localhost:8000/v1
    • vLLM — your server's address
    • LM Studio — http://localhost:1234/v1

  • Hosted providers

    Reach many models through one endpoint, or a specific vendor's OpenAI-compatible API. These require an API key.

Pointing gdc at a provider

Set the endpoint, model, and (if needed) API key. The easiest way is your config file:

~/.gdc/config.toml
[provider]
base_url = "http://localhost:11434/v1"
model    = "qwen2.5-coder:14b-instruct"
# api_key = "sk-..."   # only for hosted endpoints

You can also set them per run:

gdc --base-url http://localhost:8000/v1 --model my-model print "..."

or with environment variables (GDC_BASE_URL, GDC_MODEL, GDC_API_KEY). Command-line flags win over environment variables, which win over the config file.

Your API key is kept out of logs

gdc never prints your API key in help output or error messages, so it won't leak into logs or terminal scrollback.

Switching models on the fly

In the terminal app, switch the model for your next turn without editing config:

/model qwen2.5-coder:14b-instruct

You can also define named provider profiles in config and mark one active, so you can keep several endpoints ready and switch between them. See the Configuration reference.

Choosing a model

  • For tool use (reading and editing code, running commands), a coding-focused, instruction-tuned model generally behaves best.
  • Some "thinking" models need specific settings to work smoothly. If a local model occasionally returns an empty response after using a tool, see Troubleshooting.
  • Larger models are more capable but slower; smaller models are faster but need more guidance. Try a few and see what fits your machine and task.