Provider Query and Model Resolution

Relevant source files

• internal/cli/run.go
• internal/cli/run_test.go
• internal/credential/agent_init.go
• internal/credential/credential_test.go
• internal/credential/provider_query.go
• internal/credential/provider_query_test.go

The Provider Query and Model Resolution subsystem is responsible for disambiguating model identifiers and mapping them to specific credential namespaces. This logic ensures that skill-up can distinguish between a provider/model reference (where the prefix indicates which API key to use) and an opaque model identifier containing a slash (common in proxy gateways).

Model Disambiguation Pipeline

The core challenge in model resolution is determining if a slash in a model string (e.g., dashscope/claude-3-5-sonnet) represents a namespace or part of a literal ID. The ResolveModelRef function implements a "configured-provider-first" strategy to make this decision internal/credential/provider_query.go76-106

Resolution Logic

1. Split Check: The input string is split into exactly two parts at the first slash internal/credential/provider_query.go112-115
2. Provider Verification: The first part is checked against HasProvider internal/credential/provider_query.go116-118
3. Namespace Split: If the prefix is a known provider, the system returns (provider, model_name).
4. Opaque Collapse: If the prefix is unknown, the system treats the entire string as a bare model ID, returning ("", full_string) internal/credential/provider_query.go119-125

Data Flow: CLI to Agent

The following diagram illustrates how a user-provided model string flows through the resolution logic into the final agent parameters.

Model Resolution Flow

Sources: internal/credential/provider_query.go108-125 internal/credential/agent_init.go74-87 internal/cli/run.go1034-1065 internal/credential/provider_query.go24-26

Provider Configuration Discovery

The HasProvider function determines if a string qualifies as a credential namespace. A provider is considered "configured" if it meets any of the following criteria internal/credential/provider_query.go52-74:

Criteria	Description	Implementation
Framework Defaults	Hardcoded providers like anthropic and openai that carry persistent state in their respective CLIs.	internal/credential/provider_query.go22-26
Environment Variables	Presence of <PROVIDER>_API_KEY or <PROVIDER>_BASE_URL.	internal/credential/provider_query.go64-69
Credentials File	An explicit entry in the user's credentials.yaml.	internal/credential/provider_query.go59-63
Special Cases	Specific tokens like QODER_PERSONAL_ACCESS_TOKEN (via EnvQoderPersonalAccessToken).	internal/credential/provider_query.go70-73

Implementation Details

The frameworkDefaultProviders are kept as a private slice to ensure the "why this set is hardcoded" rationale remains centralized internal/credential/provider_query.go22-26 This allows skill-up to support bare model IDs for native engines while still allowing them to be used as namespaces for third-party providers (e.g., dashscope/claude-sonnet-4-6).

Sources: internal/credential/provider_query.go11-26 internal/credential/provider_query.go52-74

CLI Overrides and Environment Scoping

The CLI provides high-precedence overrides that bypass or influence the resolution pipeline.

Precedence Chain

When skill-up run is executed, the loadCredentialsAndAgent function constructs the final parameters:

1. CLI Flags: --api-key and --model take absolute precedence internal/cli/run.go1044-1049
2. Model Resolution: If --model contains a slash, ResolveModelRef is called to split it internal/cli/run.go1052-1053
3. Credential Retrieval: The resolveAgentInitParams function merges CLI values into the final AgentInitParams struct internal/credential/agent_init.go118-151

Scoped Environment Variables

The system supports a standard pattern for provider-specific environment variables via resolveValue internal/credential/agent_init.go220-225:

• <PROVIDER>_API_KEY: The primary secret for the namespace internal/credential/agent_init.go216
• <PROVIDER>_BASE_URL: Custom endpoint (useful for proxy gateways) internal/credential/agent_init.go217
• <PROVIDER>_MODEL: Default model name for that provider internal/credential/agent_init.go215

Entity Association: CLI to Credential Internal

Sources: internal/cli/run.go1034-1065 internal/credential/provider_query.go108-125 internal/credential/agent_init.go39-57 internal/credential/agent_init.go202-210

Proxy Gateway Handling (Opaque Collapse)

A critical feature of the resolution pipeline is the "Opaque Collapse." Many internal proxy gateways register models using strings like anthropic_modelscope/deepseek-v4-pro internal/credential/provider_query.go92-93

If anthropic_modelscope is not configured in the environment or credentials.yaml, ResolveModelRef will:

1. Detect that the prefix is not a known provider via HasProvider internal/credential/provider_query.go116
2. Emit a Debug Log explaining that the string is being treated as an opaque ID internal/credential/provider_query.go120-124
3. Return the string verbatim as the model name with an empty provider internal/credential/provider_query.go125

This prevents the system from accidentally stripping the prefix when the upstream API requires it for routing internal/credential/provider_query.go87-94

Sources: internal/credential/provider_query.go76-125 internal/credential/provider_query_test.go154-170