Configuration Commands

Manage CCO configuration profiles, endpoints, and tier settings.

cco config init

Initialize a new configuration profile. Creates ~/.codified-orchestrator/config.yaml with profile settings.

cco config init --profile direct-minimax

Parameters

Parameter	Type	Default	Description
`--profile`	string	direct-minimax	Profile name to create
`--force`	flag	false	Overwrite existing profile
`--print`	flag	false	Print config to stdout instead of saving

ℹ️

Available profiles include direct-minimax, ollama-local, and gemma-edge. Run cco config list to see all available profiles.

cco config show

Display the current CCO configuration. Shows active profile, endpoints, and tier information.

cco config show

cco config show --json

Parameters

Parameter	Type	Default	Description
`--json`	flag	false	Output configuration as JSON

cco config list

List all available configuration profiles. Shows profile names and their endpoints.

cco config list

This command has no parameters.

cco config switch

Switch the active configuration profile. The profile must already exist.

cco config switch my-profile

Parameters

Parameter	Type	Required	Description
`profile`	string	required	Name of the profile to switch to

cco config delete

Delete a configuration profile. Cannot delete the currently active profile.

cco config delete my-profile

Parameters

Parameter	Type	Required	Description
`profile`	string	required	Name of the profile to delete

⚠️

Deleting a profile is permanent. Make sure you have a backup or can recreate the profile if needed.

cco config tier

Show or upgrade the current tier. CCO offers two tiers: Starter (free) and Pro (paid).

cco config tier

cco config tier pro

Parameters

Parameter	Type	Default	Description
`tier`	string	omitted	Tier to upgrade to: `starter` or `pro`. Omit to show current tier.

Tier Comparison

Feature	Starter	Pro
Basic configuration	✓	✓
Core commands	✓	✓
Task management	✓	✓
AOMA memory	✓	✓
Advanced agents	—	✓
Priority support	—	✓

Configuration File Format

CCO stores configuration in ~/.codified-orchestrator/config.yaml. The file uses YAML structure with the following key fields:

active_profile: direct-minimax

profiles:
  direct-minimax:
    primary_endpoint: https://api.minimax.chat/v1
    primary_model: MiniMaxText-01
    fallback_endpoint: https://openrouter.ai/api/v1
    fallback_model: google/gemma-3-27b
    escalation: https://api.openai.com/v1
    escalation_model: gpt-4o
    timeout: 120
    max_retries: 3
    autopick_loopback: false

  ollama-local:
    primary_endpoint: http://localhost:11434/v1
    primary_model: qwen2.5-coder-14b
    fallback_endpoint: http://localhost:11435/v1
    fallback_model: llama3.2
    timeout: 300
    max_retries: 2
    autopick_loopback: true

tier: starter

Configuration Fields

Field	Description
`active_profile`	Name of the currently active configuration profile
`profiles.*.primary_endpoint`	Primary API endpoint URL
`profiles.*.primary_model`	Primary model identifier
`profiles.*.fallback_endpoint`	Fallback API endpoint (used when primary fails)
`profiles.*.fallback_model`	Fallback model identifier
`profiles.*.escalation`	Escalation endpoint (human review or premium model)
`profiles.*.timeout`	Request timeout in seconds
`profiles.*.max_retries`	Maximum retry attempts on failure
`profiles.*.autopick_loopback`	Whether to auto-detect local Ollama instances
`tier`	Current tier: `starter` or `pro`

ℹ️

The architecture is model-agnostic. The stable config concepts are primary_endpoint, fallback_endpoint, and escalation. Treat concrete backends as deployment profiles, not repo doctrine.