Importing configuration
Since 1.3.0, ccode can import a profile from a local YAML file or an HTTPS URL. This is in addition to the regular Configuration mechanism. The imported file can also declare which fields ccode should ask the user for at import time, like to fill out their own API key.
The idea here is that your team can have files that you distribute as presets for your projects, or host them on your LAN somewhere.
How this works
The three commands that came in with 1.3.0:
ccode add-profile # interactive
ccode add-profile --from-file <path> # import from local YAML
ccode add-profile --from-url <url> # import from https URL
ccode remove-profile <name> # remove a profile from a config
ccode set-default-profile <name> # change default_profile in a config
Each one accepts an optional [target] (a directory, ., or an explicit file path) so you can edit project-level configs as well as the user config.
For example, you could execute the following in your project directory to have a config there:
ccode add-profile --from-url https://ccode.kronis.dev/configuration-examples/deepseek.yaml ccode.yaml
Or if you execute the following, then it just gets added to your own global config:
ccode add-profile --from-url https://ccode.kronis.dev/configuration-examples/deepseek.yaml
add-profile imports one profile per file/URL.
The single top-level key in your file is the profile name, and its value is the profile body.
If you’re hosting profile YAMLs for your team or org, here’s how you’d create your own:
- Put the profile body under a single top-level key (the profile name).
- Fill in everything except secrets (unless you want to share those and nobody else can see the files).
- Add a
prompt:list with the field names users should fill in interactively (see below).
Field names are validated strictly against the Config Reference, so typos should get caught.
Prompting for values to fill out
Those profile files can include data like API keys for internal files, but sometimes you can instead give the user an example file without those, and prompt them to enter whatever needs to be filled out on a case-by-case basis.
This can be achieved with a prompt: field listing names of fields the user should be asked about at import time. ccode reads this list, prompts for each one, fills the answers into the profile body, and doesn’t include the actual prompt field in the saved profile.
Here’s the hosted DeepSeek (Pro) example:
# Example profile: DeepSeek (Pro tier)
# Sign up: https://platform.deepseek.com/
#
# Add to your config with:
# ccode add-profile --from-url https://ccode.kronis.dev/configuration-examples/deepseek.yaml
#
# ccode will prompt you for the auth token during import.
deepseek:
anthropic_base_url: "https://api.deepseek.com/anthropic"
# the API key is part of the prompt field below, user will fill this out when pulling
# anthropic_auth_token: "YOUR_DEEPSEEK_API_KEY_HERE"
models:
model:
model: "deepseek-v4-pro[1m]"
opus:
model: "deepseek-v4-pro[1m]"
sonnet:
model: "deepseek-v4-pro[1m]"
haiku:
model: "deepseek-v4-flash"
subagent:
model: "deepseek-v4-flash"
claude_code_effort_level: "max"
env:
CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS: "1"
prompt:
- anthropic_auth_token
Importing this file would show:
This profile asks for the following values - press ENTER to skip any:
anthropic_auth_token: sk-...
A few rules:
- Each name must be a valid profile YAML field (see the Config Reference).
- ENTER skips a prompt; the field stays unset.
- The
prompt:field can target any single-string profile field. It cannot target the profile’senv:block, since that’s a map of arbitrary env vars rather than one fillable value.
If you want users to set their own env vars, ship the YAML with placeholder values and have them run ccode edit-config afterwards. You can also use --value to set fields without prompting, or --no-prompts to skip all prompts. See the ccode add-profile reference on the Usage page for examples.
Hosted example profiles
The example files below live on this site and you can use them directly. This would work nicely together with a minimal profile:
ccode init-config --minimal
ccode add-profile --from-url https://ccode.kronis.dev/configuration-examples/deepseek.yaml --set-default
Most use a prompt: list for any field ccode can’t fill in for you (auth tokens, project IDs, gateway URLs); a couple of providers don’t need any prompts at all and the file is a one-shot starter.
| Provider | URL | Prompts for | Open |
|---|---|---|---|
| Anthropic API | https://ccode.kronis.dev/configuration-examples/anthropic.yaml | API key | view |
| Amazon Bedrock | https://ccode.kronis.dev/configuration-examples/bedrock.yaml | (none - uses AWS creds) | view |
| Claude Platform on AWS | https://ccode.kronis.dev/configuration-examples/anthropic-aws.yaml | workspace ID + API key (ENTER on key for SigV4) | view |
| Amazon Bedrock Mantle | https://ccode.kronis.dev/configuration-examples/mantle.yaml | (none - uses AWS creds) | view |
| Google Vertex AI | https://ccode.kronis.dev/configuration-examples/vertex.yaml | GCP project ID | view |
| Microsoft Foundry (Azure) | https://ccode.kronis.dev/configuration-examples/foundry.yaml | resource URL + API key | view |
| DeepSeek (Pro) | https://ccode.kronis.dev/configuration-examples/deepseek.yaml | auth token | view |
| DeepSeek (Flash) | https://ccode.kronis.dev/configuration-examples/deepseek-flash.yaml | auth token | view |
| OpenRouter | https://ccode.kronis.dev/configuration-examples/openrouter.yaml | auth token | view |
| OpenRouter (custom model) | https://ccode.kronis.dev/configuration-examples/openrouter-model.yaml | auth token + every model slug | view |
| OpenRouter (custom preset) | https://ccode.kronis.dev/configuration-examples/openrouter-preset.yaml | auth token (preset slug edited after import) | view |
| Z.AI (Zhipu GLM) | https://ccode.kronis.dev/configuration-examples/zai.yaml | auth token | view |
| Moonshot Kimi | https://ccode.kronis.dev/configuration-examples/kimi.yaml | auth token | view |
| Alibaba Qwen | https://ccode.kronis.dev/configuration-examples/qwen.yaml | auth token | view |
| MiniMax | https://ccode.kronis.dev/configuration-examples/minimax.yaml | auth token | view |
| Local / self-hosted | https://ccode.kronis.dev/configuration-examples/local.yaml | local server URL (model name edited after import) | view |
| Organization gateway | https://ccode.kronis.dev/configuration-examples/gateway.yaml | gateway URL + auth token | view |
Handling of secrets during import
If you import a profile into a project file that needs a secret, ccode will ask where the secret should go:
Where should the API key go?
If you intend to commit project files, the separate user config is safer.
1) Your user config: <user-config-path>
2) This project file: <project-config-path>
Option 1 (default) puts the secret fields in your user config and the rest in the project file; option 2 keeps everything in the project file. Importing into your user config skips the prompt entirely.
The fields treated as secrets:
anthropic_api_keyanthropic_auth_tokenclaude_code_oauth_tokenclaude_code_oauth_refresh_tokenanthropic_foundry_api_keyaws_bearer_token_bedrockanthropic_aws_api_key
See also
For the day-to-day usage of:
ccode add-profile- adding a profileccode remove-profile- removing a profileccode set-default-profile- setting the default profile
you can also see the Commands section on the Usage page.