Custom Model

In addition to the standard models built into Qoder CLI, you can also integrate your own third-party models via BYOK (Bring Your Own Key): use your own API key to call a provider's model and use it in Qoder CLI just like a standard model. This page covers standard models, how to configure BYOK custom models, how to select models per task, and the related model alias mechanism. For basic model switching, see Models.

Standard Models

Qoder CLI includes a set of standard models that can be selected via unified identifiers without configuring keys:

Identifier	Description
`auto`	Intelligently selects the optimal model, balancing performance and cost.
`ultimate`	Expert-level deep reasoning and thinking, delivering the highest output quality.
`performance`	Advanced reasoning with high output quality.
`efficient`	Standard reasoning at a lower cost.
`lite`	Basic reasoning, usable under free quota (may be slower during peak hours), does not support image input.

You can switch standard models by running /model in the interactive interface, or specify one at startup using -m/--model.

Configure Custom Models (BYOK)

BYOK allows you to integrate third-party models using your own keys. Custom models are declared in the modelConfigs.customModels array of the configuration file, with each entry describing a single model.

Configuration Example

Add the following to settings.json:

{
  "modelConfigs": {
    "customModels": [
      {
        "provider": "openai",
        "apiKey": "sk-...",
        "model": "gpt-4o",
        "baseURL": "https://api.openai.com/v1",
        "key": "my-gpt4o",
        "displayName": "My GPT-4o",
        "format": "openai",
        "isReasoning": false,
        "isVl": false,
        "maxInputTokens": 128000
      }
    ]
  }
}

You must restart Qoder CLI after modifying customModels for the changes to take effect.

Field Descriptions

Field	Required	Default	Description
`provider`	Yes	—	Provider Identifier, e.g., `openai`, `deepseek`.
`apiKey`	Yes	—	The API key for the provider.
`model`	Yes	—	The raw model ID on the provider's side, e.g., `gpt-4o`.
`type`	No	—	The provider's Model Type Key, matching the type in the provider configuration.
`baseURL`	No	—	The provider's Inference Request Base URL, e.g., `https://api.openai.com/v1`.
`key`	No	`<provider>/<model>`	The Identifier used by `-m` to select this model.
`displayName`	No	Same as `key`	A human-readable Display Name.
`format`	No	`openai`	API format/style. Allowed values: `openai` or `anthropic`.
`isReasoning`	No	`false`	Whether it is a Reasoning Model.
`isVl`	No	`false`	Whether it accepts image input (Vision-Language Model).
`maxInputTokens`	No	`128000`	Maximum input token count.

Selecting Custom Models

After configuration and restarting, custom models are merged into the Model Catalog and can be selected via key:

qodercli -m my-gpt4o

You can also select them in the interactive interface using /model.

Key Security

apiKey is stored in plain text within the configuration file. Please be mindful of where you store it:

Do not write configurations containing keys into the project-level settings.json (<project>/.qoder/settings.json), as it will be committed to the repository, leading to key leakage.
Prefer placing BYOK configurations in the user-level ~/.qoder/settings.json, or the local-level settings.local.json within the project that is not committed to the repository.
If you need to share the structure across teams without exposing keys, combine it with environment variable references and store the actual keys in environment variables.

Enabling Environment Variable Masking (security.environmentVariableRedaction.enabled) can further reduce the risk of keys being exposed during tool execution. See Configuration Files and Application Order.

Model Alias and Scope

Internally, Qoder CLI uses "model aliases" to map different tasks to different model tiers. An alias is a named set of Model Configuration Presets that can inherit from other aliases via extends, and can be extended or overridden in modelConfigs.aliases / modelConfigs.customAliases. This mechanism allows internal tasks for different purposes (such as Title Generation, context compression, Quick Completion, etc.) to use lighter or more appropriate model tiers, thereby controlling costs while ensuring quality. Most users do not need to modify aliases; for fine-grained control, refer to the following key points:

modelConfigs.aliases: Built-in named presets that can be used wherever a model name is required, supporting inheritance via extends.
modelConfigs.customAliases: Custom presets that merge with built-in aliases and override items with the same name.
modelConfigs.overrides / customOverrides: Apply configuration overrides based on matching conditions (with the model or alias as the primary key); the most specific match takes precedence.

Model Parameters

Generation parameters can be adjusted in the model configuration of an alias. Common ones include:

temperature, topP: Sampling-related parameters.
maxOutputTokens: Maximum token count for a single output.
thinkingConfig.thinkingBudget: thinking budget.

Next Steps

Basic model switching: Models.
Configuration files and application order: Configuration Files and Application Order.
Complete configuration items and environment variables: Configuration Item Reference.

​Standard Models

​Configure Custom Models (BYOK)

​Configuration Example

​Field Descriptions

​Selecting Custom Models

​Key Security

​Model Alias and Scope

​Model Parameters

​Next Steps