The harness, layer by layer
Comal ships as a stack you own end to end. Scroll it the way a company adopts it — fork first, then everything it powers.
What it is
Most portfolio companies shouldn't spend two quarters standing up AI infrastructure — a gateway, model routing, budgets, tracing, evals, agent tooling. Comal ships all of it as a fork you deploy in a day.
Point one config file at the models you want, plug in your own cloud and API keys, and go. From then on, upstream improvements arrive as release pull requests — each gated by your own evals before anything lands. Comedor ships software and playbooks only: it holds no provider contracts and sits in no request path. The result is a production AI platform that stays current on its own, without a platform team to build or babysit it.
Layer 01 — start here
Fork the template and it's yours from the first commit: config/portco.yaml, your budgets and teams, your golden sets, your data flywheel. This is the layer you own and configure — and the one upstream releases flow back into, as pull requests you merge on your own terms.
Layer 02
The gateway runs in your own cloud — not ours. Your apps call it with the standard OpenAI- and Anthropic-style APIs they already speak, so nothing gets rewritten and there's no Comal SDK to adopt. It issues virtual keys, enforces per-team budgets, routes to the right model, and traces every call. Comedor is never in the request path; the gateway's value is policy, not a schema you'd have to unwind at exit.
Upstream-maintained · runs in your cloudLayer 03
Name a tier, not a model. Chains fail over between providers when one degrades; caching, batching, and context management cut spend before a token is ever billed.
Upstream — maintained centrallyLayer 04
Every model and pairing arrives with eval-card evidence, list pricing, and data-term guidance. Comedor curates the fleet so no portfolio company re-runs that evaluation alone. A menu, not a mandate.
Upstream curatedLayer 05
Every provider contract, API key, and open-model deployment lives in your cloud from day one. Rent an endpoint from the menu, or run vLLM in your VPC for restricted data. At exit, there's nothing to unwind.
Yours — your accounts & cloudLayer 06
Every request is attributed and traced from the first token. No model change — a re-point, a release, a quant pin — ships until it passes your golden sets in CI. No evals, no swap.
Upstream stack · your golden setsLayer 07 — what it powers
Your product features, internal workflows, and the coding agents your engineers already use — all pointed at that one gateway, all metered, budgeted, traced, and model-swappable. The platform does the heavy lifting; your apps just make the call, without a line of vendor-specific code.
Yours — what it all powersAnd then it stays current
Setup isn't the end — it's the start of a loop. Every upstream release flows back into your fork as a pull request: a new model on the menu, a cheaper default, a security patch — gated by your own evals before it lands. The stack you own keeps getting better, and you never maintain it.
Why a fork, not a platform
A hosted platform would put Comedor in the request path and the exit path. A fork each company owns does the opposite — the leverage compounds upstream while control stays downstream.
Every gain to the shared core reaches every fork at the next release — a model vetted onto the menu, a cheaper routing default, a general-purpose agent skill, a security patch. One vetting, N companies, and none of them staffs the platform. Your own workflows, data, and golden sets stay yours; only the reusable, general-purpose pieces ever travel upstream.
Comedor curates the model fleet — capability benchmarks, price/performance, data-term guidance — so no company re-runs that evaluation alone. You pick from the menu; nothing is imposed.
The phases of a from-scratch build become properties of the template: a day of setup plus a quarter of adoption, not two quarters of infrastructure to staff and maintain.
Provider contracts, API accounts, keys, and traces live in your own accounts from day one. At exit, the fork simply stops taking upstream PRs — the buyer inherits a self-contained, documented stack.
Fork-to-first-token in a day
The registry, eval cards, field guide, and release notes are one click behind sign-in. No fork required to evaluate the program.