PublishedGuidanceLAST REVIEWED · 30 AUG 2026
Direct provider → MC-1
Migrate incrementally from direct provider → mc-1 while preserving working behavior and attribution.
What changes
Keep the existing client behavior stable first. Introduce the MC-1 base URL, logical model, and server-side credential, then add control-plane constraints only after compatibility passes.
Feature mapping
- Record the direct endpoint, model, authentication, streaming, tool, error, and retry contract.
- Introduce MC-1 behind a feature flag with the same user-visible workload.
- Add objectives and policy only after parity evidence is stable.
Migration sequence
- Inventory endpoints, models, streaming, tools, retries, and error handling.
- Create a scoped MC-1 project and test key.
- Run an owned non-production fixture through both paths.
- Compare outputs, tool continuation, latency, usage, and failures.
- Canary a reversible workload before broader promotion.
Compatibility example
export MC1_API_KEY="..."
export MC1_BASE_URL="https://api.colomboai.com/v1"
# Keep the client OpenAI-compatible and use model colomboai/mc-1.Source-specific caveats
- Provider-native features may require an explicit route or remain unsupported.
- Keep provider attribution visible for incident and commercial reconciliation.
Rollback
- Retain the previous route until acceptance passes.
- Do not translate unsupported provider-specific features silently.
- Record the exact client and integration versions used for validation.
Was this page helpful?