Migrating Config to YAML
Continue’s YAML configuration format provides more readable, maintainable, consistent configuration files, as well as new configuration options and removal of some old configuration options. YAML is the preferred format and will be used to integrate with future Continue products. Below is a brief guide for migration from to .
See also
Create YAML file
Create a config.yaml
file in your Continue Global Directory (~/.continue
on Mac, %USERPROFILE%\.continue
) alongside your current config.json
file. If a config.yaml
file is present, it will be loaded instead of config.json
.
Give your configuration a name
and a version
:
config.yaml
Models
Add all model configurations in config.json
, including models in models
, tabAutocompleteModel
, embeddingsProvider
, and reranker
, to the models
section of your new YAML config file. A new roles
YAML field specifies which roles a model can be used for, with possible values chat
, autocomplete
, embed
, rerank
, edit
, apply
, summarize
.
-
models
in config should haveroles: [chat]
-
tabAutocompleteModel
(s) in config should haveroles: [autocomplete]
-
embeddingsProvider
in config should haveroles: [embed]
-
reranker
in config should haveroles: [rerank]
-
experimental.modelRoles
is replaced by simply adding roles to the modelinlineEdit
-> e.g.roles: [chat, edit]
applyCodeBlock
-> e.g.roles: [chat, apply]
Model-level requestOptions
remain, with minor changes. See YAML Continue Config Reference
Model-level completionOptions
are replaced by defaultCompletionOptions
, with minor changes. See YAML Continue Config Reference
Before
config.json
After
config.yaml
Note that the repoMapFileSelection
experimental model role has been deprecated and is only available in config.json
.
Context Providers
The JSON contextProviders
field is replaced by the YAML context
array.
- JSON
name
maps toprovider
- JSON
params
map toparams
Before
config.json
After
config.yaml
System Message
The systemMessage
property has been replaced with a rules
property that takes an array of strings.
Before
config.json
After
config.yaml
Prompts
Rather than with customCommands
, you can now use the prompts
field to define custom prompts.
Before
config.json
After
config.yaml
Documentation
Documentation is largely the same, but the title
property has been replaced with name
. The startUrl
, rootUrl
, and faviconUrl
properties remain.
Before
config.json
After
config.yaml
MCP Servers
Properties:
name
(required): The name of the MCP server.command
(required): The command used to start the server.args
: An optional array of arguments for the command.env
: An optional map of environment variables for the server process.cwd
: An optional working directory to run the command in. Can be absolute or relative path.
Before
config.json
After
config.yaml
Deprecated configuration options
Some deprecated config.json
settings are no longer stored in config and have been moved to be editable through the User Settings Page (Gear Icon). If found in config.json
, they will be auto-migrated to User Settings and removed from config.json
.
See the JSON Config Reference for more information on fully deprecated options.
The following top-level fields from config.json
still work when using config.json
but have been deprecated and don’t have a YAML equivalent:
-
Slash commands (JSON
slashCommands
) -
top-level
requestOptions
-
top-level
completionOptions
-
tabAutocompleteOptions
disable
maxPromptTokens
debounceDelay
maxSuffixPercentage
prefixPercentage
template
onlyMyCode
-
analytics
The following top-level fields from config.json
have been deprecated. Most UI-related and user-specific options will move into a settings page in the UI
customCommands
experimental
userToken
New Configuration options
The YAML configuration format offers new configuration options not available in the JSON format. See the YAML Config Reference for more information.