Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/onenot8/issueLoop/llms.txt

Use this file to discover all available pages before exploring further.

provider_config.yaml lets you configure the LLM backend used by IssueLoop without changing any Python code. This is useful for shared team setups, deployment environments, or any situation where you want the LLM settings to live outside the application — editable by ops or CI tooling without touching source files.

​
File structure

The file uses a single top-level reasoning key, which maps to the LLM used for ticket triage — the step where raw test failures are split into independent, prioritised tickets. 
reasoning:
  provider: ollama
  model: qwen2.5-coder:7b
  base_url: http://localhost:11434
The reasoning key is the only supported top-level key. The three nested fields map directly to fields on LLMConfig:
FieldDescription
providerThe LLM backend. Accepted values: ollama, anthropic, openai.
modelThe model identifier as the provider expects it (e.g. qwen2.5-coder:7b, claude-sonnet-4-6).
base_urlBase URL for the provider’s API. Defaults to http://localhost:11434 for a local Ollama server.

​
Supported providers

Three providers are supported:
  • ollama — local inference, no API key required. The default. Point base_url at your Ollama server (local or remote).
  • anthropic — Anthropic’s cloud API (e.g. Claude models). Requires an api_key.
  • openai — OpenAI’s API or any OpenAI-compatible endpoint. Requires an api_key.
For anthropic and openai, the api_key must be supplied via code or environment variable — it is intentionally not stored in provider_config.yaml to prevent secrets from landing in version control. Pass it through issueloop.use() or an environment variable your application reads at startup. 
import os
import issueloop

issueloop.use(llm={
    "provider": "anthropic",
    "model": "claude-sonnet-4-6",
    "api_key": os.environ["ANTHROPIC_API_KEY"],
})

​
Config file resolution order

IssueLoop resolves provider_config.yaml by searching the following locations in order, stopping at the first match:
  1. ISSUELOOP_PROVIDER_CONFIG_PATH environment variable — if set, the value is used as an absolute path to the config file, with no further searching.
  2. ./config/provider_config.yaml — relative to the current working directory when the process starts.
  3. config/provider_config.yaml in the IssueLoop checkout — the config/ directory at the root of the cloned repository (only relevant for development installs with -e .).
  4. Bundled package defaults — the _defaults/provider_config.yaml file shipped inside the issueloop package itself.
This means a standard pip install issueloop always has a valid fallback (Ollama on localhost) even when no project-local config directory exists.

​
When this file is used

provider_config.yaml is consulted only when IssueLoop is running with the built-in default single-provider Ollama configuration — specifically, when the active LLMConfig has provider="ollama", model="qwen2.5-coder:7b", and no api_key set. When that condition is met, the YAML file can override those values without any code change. If you call use(llm={...}) with any non-default values — a different provider, a different model, or an api_key — the condition is not met and the file is never read. The same is true if you configure multiple providers via llm={"providers": [...]}. In practice:
  • No use() call at all → the default LLMConfig is active (Ollama, qwen2.5-coder:7b, no key) → provider_config.yaml is read.
  • use() called without llm= → llm defaults to None, which resolves to the same default Ollama config → provider_config.yaml is read.
  • use(llm={}) called with an empty dict → _build_llm_config fills in the Ollama defaults → provider_config.yaml is read.
  • use(llm={"provider": "openai", ...}) or any non-default config → the condition is not met → the file is ignored entirely.
This means provider_config.yaml is a targeted override for the default Ollama path only. It is not a general-purpose config file that overrides arbitrary use() calls.

​
Relationship to use()

provider_config.yaml is a convenience default, not a hard override. Calling issueloop.use(llm={...}) with any non-default LLM settings always wins, regardless of what the file contains. Think of the file as the answer to “what should IssueLoop use when nothing else is configured?” — it fills the gap so you never need to touch Python code just to switch from the bundled Ollama default to a different model or server address. 
# This ignores provider_config.yaml completely — non-default provider
issueloop.use(llm={
    "provider": "openai",
    "model": "gpt-4o",
    "api_key": "sk-...",
})

# This reads provider_config.yaml — llm= is omitted, default Ollama config is active
issueloop.use(database="supabase", retention_days=7)
In CI/CD pipelines, set ISSUELOOP_PROVIDER_CONFIG_PATH to an absolute path outside the project directory — for example, a secrets-managed config file mounted at /etc/issueloop/provider_config.yaml. This lets you change the LLM backend across all pipeline runs without modifying the repository.

Build docs developers (and LLMs) love

Get started for freeTalk to us