MC-1 by ColomboAI
The Intelligence Control Plane for adaptive, governed, economically accountable AI.
One stable control layer across models, providers, agents, policy, evaluation, economics, adaptation, and enterprise outcomes.
Explore MC-1 · Open Console · Read the flagship paper · Request an enterprise briefing
Important
This is the public information and research repository for MC-1. It intentionally contains no MC-1 application source code, provider credentials, deployment configuration, routing weights, customer data, or production secrets.
| Surface | Official location | Purpose |
|---|---|---|
| MC-1 product | colomboai.com/MC-1 | Platform, enterprise, developer, pricing, and Forward product pages |
| MC-1 Console | console.colomboai.com/MC-1/console | Authenticated projects, Playground, routes, policies, usage, billing, adaptation, and operations |
| MC-1 API | https://api.colomboai.com/v1 |
OpenAI-compatible and MC-1 intelligence APIs |
| Admin Control Center | console.colomboai.com/admin | Restricted ColomboAI platform operations; a normal customer account does not grant access |
MC-1 account access is first-party ColomboAI authentication. The Console supports email verification and configured SSO, issues a secure MC-1/Cairo identity token, and resolves application users, organizations, projects, and memberships from MC-1's own authoritative data stores. OpenAI or ChatGPT identity is not the MC-1 account database.
MC-1 has grown from a model router into a connected intelligence-control product family:
The status column below is a compact orientation. Public capability status is the authoritative maturity vocabulary for this repository.
| Product or control layer | What it does | Current boundary |
|---|---|---|
| MC-1 Intelligence Control Plane | Understands a task, enforces identity and policy, budgets the execution, selects eligible model/provider routes, evaluates outcomes, and records evidence | Core inference production; advanced intelligence capabilities mature independently |
| Query, Execution, Model & Provider Intelligence | Classifies requests, plans bounded execution, separates model fit from provider fit, and ranks only executable, policy-compliant routes | OpenAI-compatible routing is production; Query and Execution Intelligence are beta |
| MC-1 Console | Provides Playground, projects, API keys, routing traces, models, providers, policies, billing, teams, support, Forward, and adaptation surfaces | Production, with capability-specific configuration gates |
| MC-1 Everywhere | Brings colomboai/mc-1 to OpenAI-compatible agents, coding tools, harnesses, SDKs, and orchestration frameworks through verified recipes and compatibility evidence |
Staged compatibility program; integration-specific production status is always stated |
| MC-1 Forward | Extends MC-1 from intelligence execution into governed enterprise discovery and transformation | Staged read-only discovery foundation; consequential write autonomy remains gated |
| Agent Identity & Agent Guard | Binds agent claims to a tenant and principal, checks exact permissions, and blocks unauthorized tool or advanced-runtime execution before provider spend | Beta and fail-closed |
| Adaptive Intelligence | Compares route-versus-train economics, governs authorized training, captures lineage, evaluates challengers, and supports canary-first specialization | Staged; live training and export remain provider/policy gated |
| Advanced Runtime | Governs replanning, multimodal pipelines, deliberation, Guard Edge, and Physical AI through authenticated customer-compute runtimes | Staged and external-runtime gated; never inferred from a model name |
| FinOps, Billing & Enterprise Control | Coordinates budgets, prepaid credits, provider cost evidence, BYOK separation, plans, audit, sovereignty, and organization policy | Production foundations; provider- and contract-specific features remain explicit |
| Admin Control Center | Gives authorized ColomboAI operators cross-tenant operational, security, finance, routing, CRM, Everywhere, and incident views with narrow RBAC | Production internal surface; sensitive or unverified mutations fail closed |
See the detailed MC-1 product map and public capability status for boundaries that do not fit in a headline.
- One ColomboAI identity boundary: customer Console and restricted Admin access now use the same first-party account flow and authoritative MC-1 data model.
- Intelligence Trace 3.0: route, execution-plan, model/provider, evaluation, Guard, usage, and policy evidence share coherent route and trace identifiers.
- Model and provider separation: MC-1 can keep a selected model while failing over across eligible providers before escalating to another model.
- Guarded agent execution: signed Agent Identity, tenant binding, exact tool permissions, schema validation, and policy checks happen before privileged execution.
- Adaptive route-versus-train decisions: routing, experiments, training, checkpoints, lineage, evaluation, canaries, production promotion, reconciliation, and retirement share one governed lifecycle.
- MC-1 Everywhere evidence: integrations are validated against released hosts and public configuration seams; synthetic compatibility is never mislabeled as authenticated production support.
- MC-1 Forward foundation: tenant-scoped workspaces, read-only discovery, connectors, transformation graphs, provenance, confidence, and opportunity models are separated from gated autonomy.
- Operational control: the Admin Control Center exposes source-backed executive, customer, provider, security, finance, Everywhere, partner, enterprise, and system-health projections without substituting demo data.
- Truthful rollout states: unavailable, configuration-required, configured, connected, beta, staged, and production are distinct states across the platform.
MC-1 is ColomboAI's Intelligence Control Plane: the adaptive operating layer that determines what intelligence should be used, where it may execute, what it may cost, whether an agent is authorized to act, whether the result satisfies the request, and what evidence should be retained for governance and improvement.
Mixture-of-Models is a foundational execution strategy inside MC-1, not the product's outer boundary. The platform now connects intelligence selection with provider execution, Agent Identity and Guard, evaluation, FinOps, tenant policy, adaptation, Everywhere compatibility, Forward transformation, customer operations, and restricted platform administration.
Applications can keep the OpenAI client pattern and submit a task to the stable colomboai/mc-1 profile, select a verified model while retaining provider intelligence, or explicitly constrain eligible providers. For each request, MC-1 can:
- understand the task, modality, risk, output contract, and requested objective;
- resolve the authenticated organization, project, account, and—when required—signed Agent Identity;
- apply capability, privacy, sovereignty, region, provider, budget, latency, tool, and egress policy before optimization;
- plan a bounded execution strategy and rank only eligible model-provider routes;
- execute across customer/BYOK compute, approved direct providers, or coverage networks;
- preserve same-model provider failover before model escalation when policy permits;
- evaluate completion, structured output, and tool-call contracts before accepting or recovering the result;
- attribute usage, customer price, provider cost evidence, credits, and Cost per Successful Outcome where authoritative evidence exists;
- record a tenant-scoped Intelligence Trace containing route, plan, policy, evaluation, Guard, usage, and audit evidence without claiming prompt/response persistence;
- convert sufficiently supported outcomes into tenant-scoped memory, adaptation, or governed transformation signals.
MC-1 ships each capability behind an explicit, documented maturity or availability boundary. See Public capability status for the dated authoritative product-state snapshot; use the authenticated Console for live tenant-specific availability.
MC-1 does not claim that one model is universally best—or that intelligence automatically has authority. Its core premise is that the right execution is contextual: a function of the task, identity, modality, policy, economics, risk, latency, privacy, sovereignty, evaluation needs, provider health, and intended outcome.
flowchart LR
A["Application or agent"] --> B["MC-1 stable intelligence endpoint"]
B --> C["Query Intelligence"]
C --> D["Agent Identity and Guard"]
D --> E["Policy, sovereignty, and budget"]
E --> F["Execution Intelligence"]
F --> G["Model Intelligence"]
G --> H["Provider Intelligence"]
H --> I{"Execution fabric"}
I --> J["Customer or BYOK compute"]
I --> K["Direct managed providers"]
I --> L["Coverage networks"]
J --> M["Evaluation and telemetry"]
K --> M
L --> M
M --> N["Response, trace, usage, and audit evidence"]
M --> O["Memory and adaptation signals"]
The architecture separates two questions that are often conflated:
- Which intelligence should answer? Model capability, task fit, context, modality, tools, quality, and risk.
- Where should it run? Provider health, price, latency, privacy, geography, capacity, contractual policy, and availability.
Mixture-of-Experts systems conditionally activate subnetworks inside one trained model. MC-1 moves conditional computation one level higher: its experts are complete, independently trained models that may use different architectures, tokenizers, providers, regions, hardware, licenses, and operating policies.
That creates three practical opportunities:
- Specialization: small, local, multimodal, reasoning, coding, and long-context models can each serve the workload regions where they are strongest.
- Economics: easy or latency-sensitive work need not consume the most expensive available model.
- Sovereignty: the logical intelligence endpoint can span local, private, customer-owned, and approved external compute without treating governance as an afterthought.
The research challenge is not merely whether a diverse pool contains complementary models. It is whether a realizable router can identify that complementarity before seeing the answer. The MC-1 paper therefore distinguishes the best fixed model, an outcome oracle, and the performance actually recovered by a deployable router.
MC-1 derives lightweight pre-answer signals such as domain, estimated difficulty, reasoning depth, context size, modality, tool use, language, structured-output requirements, privacy sensitivity, risk, and expected value.
Hard constraints are applied before optimization. A cheaper or nominally stronger route cannot compensate for violating a local-only rule, provider allowlist, regional restriction, maximum cost, required capability, or data-classification policy.
MC-1 represents models as multidimensional capability and operating profiles rather than one leaderboard number. A model profile can include:
- reasoning, math, coding, vision, multilingual, tool-use, and structured-output capability;
- context capacity and modality support;
- input, output, and fixed-request price information;
- latency, throughput, availability, and failure evidence;
- provider, region, hardware, quantization, and policy labels;
- provenance, uncertainty, recency, and sample counts.
After removing infeasible candidates, MC-1 ranks executable routes using the deployment objective. Objectives can prioritize balanced utility, quality, cost, latency, privacy, sovereignty, or local execution. Provider ordering and pinning remain available when an operator needs deterministic control.
MC-1 can attempt a cost-efficient route first, evaluate whether the result satisfies the request contract, and escalate when confidence is insufficient and policy allows. Fallbacks preserve hard constraints; a local-only request must not silently escape to external compute.
Each route can produce evidence about classification, eligibility, selection, provider attempts, latency, usage, price provenance, evaluation, fallback behavior, and policy decisions. That evidence is the basis for auditability and future capability updates.
| Mode | What the caller specifies | What MC-1 decides | Typical use |
|---|---|---|---|
| Smart | colomboai/mc-1 plus the task and constraints |
Model, provider, and bounded execution strategy | Default adaptive intelligence |
| Manual model | A verified canonical model | Eligible provider and failover path | Model-specific evaluation or compatibility |
| Manual model + provider | A verified model plus provider pin/order rules | Execution within the caller's allowed set | Regulated, contractual, or deterministic operations |
Manual control does not mean arbitrary execution. Model identifiers still require a verified mapping and routes remain subject to capability, price, policy, and availability checks.
MC-1 is a control plane; it does not present itself as the owner of every accelerator that executes a request.
| Execution class | Purpose | Billing and governance boundary |
|---|---|---|
| Customer / BYOK compute | Customer-supplied OpenAI-compatible endpoint or private deployment | Provider compute remains on the customer account; MC-1 does not create a ColomboAI provider payable |
| Direct managed provider | Direct adapters to approved inference providers | MC-1 requires normalized pricing and records provider attempts and payable evidence |
| Coverage network | Broad model/provider reach and resilience | Used only when price, policy, capability, and health requirements are satisfied |
The deployed adapter architecture includes OpenRouter, Together AI, Fireworks AI, Nebius Token Factory, NVIDIA NIM, vLLM/custom OpenAI-compatible endpoints, and request-scoped customer compute. Availability of a particular model or modality depends on current production configuration and verified mappings.
These products solve different layers of the inference stack. The table is intended to clarify category boundaries, not declare one universal winner.
| Product | Primary role | Cross-provider abstraction | Request-level model intelligence | Local / self-hosted path | Policy-aware route constraints | Financial control-plane scope |
|---|---|---|---|---|---|---|
| ColomboAI MC-1 | Provider-independent Mixture-of-Models intelligence control plane | Yes | Core product concept: task, capability, objective, confidence, identity, evaluation, and policy signals | Yes, through customer/private OpenAI-compatible compute | Core product concept | Credits, reservations, usage ledger, provider attempts/payables, and settlement evidence |
| OpenRouter | Hosted unified API and routing layer across many models/providers | Yes | Offers routers including automatic model selection; also provides strong provider-routing controls | Not a local model runtime; custom/provider routes depend on its supported network and integrations | Provider preferences, fallbacks, parameter requirements, and data-policy controls | Centralized usage/credit accounting for OpenRouter traffic |
| Ollama | Local model packaging and runtime | No hosted multi-provider network | Model choice is generally caller/operator driven | Core product concept | Primarily local runtime controls rather than a cross-provider enterprise policy plane | No managed provider-payable settlement plane |
| Nebius Token Factory | Managed AI inference platform/provider | Models are served within the Nebius platform | Caller selects among available endpoints/models; not positioned as a provider-neutral MOM control plane | Dedicated and managed deployment options; not a desktop local runtime | Provider/platform deployment controls | Provider-native consumption and billing |
| Together AI | Managed AI acceleration and inference provider | Broad model catalog within Together's platform | Supports serverless/dedicated model execution; caller typically selects the model | Dedicated endpoints, not a general local desktop runtime | Provider/platform controls | Provider-native usage and billing |
| Fireworks AI | Managed generative-AI inference platform/provider | Broad model catalog within Fireworks' platform | Supports serverless, on-demand, and dedicated deployments; caller typically selects the model | Dedicated deployments, not a general local desktop runtime | Provider/platform controls | Provider-native usage and billing |
| vLLM | Open-source high-throughput inference engine | No hosted provider marketplace in the engine itself | The engine serves selected models; the separate vLLM Semantic Router project adds signal-driven routing | Core product concept | Deployment-defined; semantic routing is a separate layer | No built-in commercial provider settlement network |
OpenRouter is a valuable coverage network and unified API. It can route among providers for a selected model and offers router models that choose among models. MC-1 is designed as an enterprise intelligence control plane above and across execution networks. Its architecture explicitly separates model intelligence from provider intelligence and treats customer compute, direct providers, coverage networks, hard policy constraints, route evaluation, credit reservation, and provider settlement evidence as parts of one control loop.
MC-1 can therefore use OpenRouter as one eligible execution network without reducing MC-1 itself to an OpenRouter wrapper.
Ollama and vLLM make models executable on operator-controlled infrastructure. MC-1 decides which eligible intelligence path should execute a request and can include an Ollama/vLLM-style OpenAI-compatible endpoint as customer or private compute. Runtime engines and the MC-1 control plane are complementary layers.
Nebius, Together, and Fireworks operate inference platforms. MC-1 is provider-independent: it can evaluate direct-provider routes alongside customer compute and coverage networks, while applying one caller-facing policy and evidence model.
MC-1 treats governance as an eligibility decision, not merely a score adjustment. Representative controls include:
- provider and model allowlists;
- explicit provider order or pinning;
- approved regions and sovereignty objectives;
- standard, zero-data-retention, private, or sovereign privacy requirements;
- public, internal, confidential, and restricted data classifications;
- maximum request cost and latency constraints;
- required tool, structured-output, streaming, vision, or modality support;
- fail-closed behavior when no route satisfies policy.
Sovereignty is a property of the entire route—not just the model name. The endpoint, provider, region, credentials, logging behavior, fallback chain, and data policy must all remain inside the approved boundary.
The MC-1 production architecture separates customer pricing, provider cost, and platform economics. Its control surfaces include:
- pre-inference credit reservation for managed routes;
- rejection before provider spend when prepaid credit is insufficient;
- authoritative per-model price configuration or provider price snapshots;
- route- and attempt-level usage evidence;
- separate customer price, provider payable, platform fee, and margin fields;
- append-oriented financial journal entries;
- provider settlement periods, variance review, and reconciliation evidence;
- BYOK isolation so customer-funded compute does not become a ColomboAI provider liability.
Financial controls reduce operational risk; they do not turn estimated or unreconciled values into audited financial statements. Provider reports and invoices remain authoritative inputs to settlement review.
MC-1 presents provider-independent interfaces modeled around common OpenAI-compatible surfaces:
- chat completions;
- responses;
- model and provider discovery;
- route, activity, usage, and billing views;
- image, audio, video, and embeddings routes when production adapters and prices are enabled.
The public repository documents the interface at a product level. It does not publish production credentials, private endpoint details, internal routing weights, or server implementation code.
Smart routing uses the stable intelligence profile:
{
"model": "colomboai/mc-1",
"messages": [
{"role": "user", "content": "Design a fault-tolerant payment service and explain the tradeoffs."}
],
"mc1": {
"objective": "balanced",
"max_cost_usd": 0.25,
"privacy": "standard"
}
}Advanced callers can request a verified model and constrain provider execution:
{
"model": "verified/model-id",
"provider": {
"order": ["customer-compute", "approved-direct-provider"],
"allow_fallbacks": true
},
"messages": [
{"role": "user", "content": "Analyze this workload under the approved provider policy."}
]
}These examples describe the contract; they are not production credentials or guarantees that every illustrative identifier is currently enabled.
MC-1 is intended for teams that need more than a static model alias:
- AI products that want one stable intelligence abstraction while the model pool evolves;
- enterprises balancing quality, cost, latency, privacy, region, and provider commitments;
- agent systems that need different models for planning, coding, vision, tools, and verification;
- sovereign or hybrid deployments spanning private and approved public compute;
- platform teams that need route evidence, bounded failover, and provider cost accountability;
- model providers that want their specialized models to compete on measurable task fit rather than global popularity alone.
The Intelligence Control Plane: The Missing Operating Layer for the AI Economy
Wilfried Kouadio and Andrew Li, ColomboAI / Cairo Lab. Flagship Category Paper / Preprint v2.0, August 2026.
Download the complete flagship paper
The paper presents:
- the shift from model endpoints to Intelligence Contracts and measurable Outcome Contracts;
- MC-1 v2.0's Intelligence, Economic, and Transformation control loops within one identity, policy, governance, and sovereignty trust envelope;
- Query Intelligence, Model Intelligence, Mixture-of-Models routing, elastic reasoning, evaluation, correction, and adaptive improvement;
- MC-1 Intelligence FinOps, token-maxing prevention, runtime budgets, provider economics, and Cost per Successful Outcome;
- MC-1 Forward, the Enterprise Intelligence Graph, opportunity discovery, governed transformation, bounded autonomy, and the Transformation Sandbox;
- Agent Identity and Agent Guard as the non-bypassable authority boundary for agents, tools, enterprise changes, and future physical AI;
- Outcome Contracts and the Enterprise AI Outcome Ledger for connecting intelligence consumption to measurable operational and business outcomes;
- the category's competitive surface, compounding Intelligence/Trust/Transformation graphs, evidence requirements, manifesto, and research agenda.
- MC-1 platform: colomboai.com/MC-1
- MC-1 Console: console.colomboai.com/MC-1/console
- Developers: colomboai.com/MC-1/developers
- Enterprise: colomboai.com/MC-1/enterprise
- ColomboAI: colomboai.com
- Enterprise and provider inquiries: sales@colomboai.com
The dated, authoritative public snapshot is maintained in Public capability status. The MC-1 control plane, customer Console, and restricted Admin Control Center are deployed on official ColomboAI domains, and production readiness currently reports the database, authentication, routing, inference, providers, billing, and pricing configured. That readiness confirms the current deployment configuration—not universal model availability, integration maturity, customer entitlement, or completion of every enterprise certification.
Model/profile values labeled as operator configuration are not represented as measured benchmark results. Providers, models, modalities, prices, regions, and rollout gates can change as mappings and operating conditions evolve; use the authenticated Console for live tenant-specific state.
MC-1 is an intelligence control plane and stable logical model profile, not one fixed set of model weights.
No. It can route to independently developed models running on customer, direct-provider, or coverage-network compute.
No. Cost is one objective among capability, quality, latency, privacy, policy, health, availability, confidence, and operator preferences.
No. Those engines can be execution substrates. MC-1 operates at the intelligence-selection and control-plane layer.
Not necessarily. OpenRouter can be an eligible coverage network inside MC-1. MC-1 additionally coordinates customer compute, direct providers, model intelligence, policy, evaluation, accounting, and settlement evidence.
The architecture supports customer-controlled OpenAI-compatible endpoints. BYOK compute remains financially separated from ColomboAI-managed provider payables.
Everywhere is MC-1's compatibility program for agents, coding tools, harnesses, frameworks, and SDKs that expose a supported OpenAI-compatible configuration seam. Every integration keeps its own evidence and maturity boundary; a synthetic released-host proof is not presented as authenticated production support.
Forward extends MC-1 into governed enterprise discovery and transformation. Its current public foundation is read-only and evidence oriented. Production-changing autonomy remains gated by identity, Guard, organization policy, approvals, evaluation, cost authorization, audit, and rollback.
No. MC-1 customer and platform-operator surfaces use the first-party ColomboAI account flow and MC-1's authoritative user and organization data. Admin access adds a separate server-side platform role; signing in as a normal MC-1 owner does not grant cross-tenant administration.
No. This repository intentionally publishes product information, research, diagrams, and access links only.
Product capabilities evolve. The comparison above was prepared from first-party material and should be revalidated for procurement or architecture decisions:
- OpenRouter documentation and provider routing
- Ollama documentation
- Nebius Token Factory documentation
- Together AI documentation
- Fireworks AI documentation
- vLLM documentation and vLLM Semantic Router
“Not documented” should not be read as proof that a private-preview, partner, or newly released capability does not exist. This repository makes no cross-product quality, latency, uptime, reliability, or price-superiority claim without a common reproducible benchmark.
This public repository accepts documentation and research corrections. It is not the MC-1 production source repository and should never receive:
- application or infrastructure source code;
- provider, Stripe, alerting, identity, or registry credentials;
- customer prompts, responses, traces, or account data;
- private pricing, routing weights, contracts, or incident material;
- deployment archives, environment files, or database exports.
For security-sensitive reports, do not open a public issue. Contact sales@colomboai.com and request the appropriate security channel.
Built by ColomboAI
Intelligence should be selected at runtime, governed by policy, and measured by outcomes.
© 2026 ColomboAI. All rights reserved. Product names and trademarks belong to their respective owners.