Model Selection and Providers
CodingScaffold separates model recommendation from request routing. Routing is one optional backend capability, not the product thesis.
Bootstrap Boundary
Model recommendation is available before any LLM is configured. CodingScaffold reads local project metadata, hardware facts, credential presence, and the prompt text. It then recommends a route. It does not proxy the prompt or call a provider.
Actual request routing happens later in the coding tool or an optional backend such as RouteLLM.
Routing Levels
- Recommendation: human-readable model choice for all tools.
- Static profiles: different agents or commands use different models where the tool supports it.
- Runtime routing: one endpoint routes per prompt through RouteLLM or a compatible gateway.
Where runtime routing is not supported, CodingScaffold still provides model-selection guidance and tool-native profiles.
Recommendation
Use tools select-model when you want an explainable routing suggestion:
The command does not call a model. It classifies the task and reports:
- prompt profile
- route:
routineorheavy-lift - provider
- model family
- model or deployment
- confidence
- reasons
Auto Mode
Use auto mode when a developer does not want to choose each time:
Auto mode still prints the decision so the user can challenge it.
Provider Detection
Provider detection checks:
- local runtimes such as Ollama, LM Studio, and llama-server
- local credential files in
.coding-scaffold/.env.local - project-local JSON credentials
- common cloud provider environment variables
- optional GitHub Copilot CLI status during explicit
probeanddoctorcommands
Secrets are never printed.
Azure Guidance
For Azure OpenAI, use:
For Azure AI or Cognitive Services style endpoints, use:
If the endpoint serves Anthropic-family models, set: