AI providers

Bring-your-own model

Qoc is model-agnostic. The agent loop that runs research, writes proposals, and responds to inbox tasks can use any provider you configure. Your API key lives in your local desk.toml (or in an environment variable it references); it is never sent to Qoc servers.

Three provider families are supported out of the box: Claude (Anthropic), OpenAI-compatible endpoints (including OpenAI itself, Azure OpenAI, and any other service that speaks the OpenAI chat completions API), and local/self-hosted models via an OpenAI-compatible local server.

Supported provider families

Configuring Claude (Anthropic)

Set provider = "anthropic" and supply your Anthropic API key. The model field accepts any Anthropic model identifier — use the latest Claude model available in your tier for best results on complex research and multi-step reasoning tasks.

Anthropic API calls go directly from your machine to api.anthropic.com. Qoc does not intercept, log, or re-transmit the content of those calls.

Claude (Anthropic) configuration

[ai]
provider = "anthropic"
model = "claude-opus-4-5"

# Reference an environment variable to keep the key out of the file.
api_key = "{env:ANTHROPIC_API_KEY}"

# Optional: system prompt prefix appended before every agent task.
system_prefix = "You are a disciplined trading analyst. Be concise and cite data."

Configuring an OpenAI-compatible endpoint

Any service that implements the OpenAI chat completions API (POST /v1/chat/completions) works as an OpenAI-compatible provider. Set provider = "openai-compatible", provide the base_url, and supply the appropriate key.

This covers OpenAI's own API, Azure OpenAI Service (with an Azure-specific base_url and api_version), and third-party providers that publish an OpenAI-compatible interface.

OpenAI-compatible configuration

[ai]
provider = "openai-compatible"
base_url = "https://api.openai.com/v1"
model = "gpt-4o"
api_key = "{env:OPENAI_API_KEY}"

# For Azure OpenAI, use your deployment endpoint and add api_version:
# base_url = "https://your-resource.openai.azure.com/openai/deployments/your-deployment"
# api_version = "2024-02-01"

Configuring a local or self-hosted model

Local model servers that expose an OpenAI-compatible HTTP API (such as Ollama, llama.cpp server, or LM Studio) work with the same openai-compatible provider type. Point base_url at the local server address. Most local servers do not require a real API key; use a placeholder string like "local" if the field is required.

Local models keep all data on your machine. No content is sent to an external service. This is useful when your investment data is sensitive or you are operating in a network-restricted environment.

Local model configuration (Ollama example)

[ai]
provider = "openai-compatible"
base_url = "http://localhost:11434/v1"
model = "llama3.1:70b"
api_key = "local"

# Context window for large research tasks. Match your model's actual limit.
max_context_tokens = 32768

Data flow and privacy

When the agent runs a task, Qoc constructs a prompt from the task brief, relevant workspace files, and any tool results from the MCP server. This prompt is sent to the configured provider endpoint — and only that endpoint. Qoc has no telemetry pipeline that captures prompt content.

If you use a cloud provider (Anthropic, OpenAI, etc.), their data handling policies apply to the content you send. If data residency or confidentiality is a concern, use a local model or a provider whose terms satisfy your requirements.

Full [ai] block reference

Related pages