Phase 0 — The Engine: linkcpp, a Control Plane for inference engine
inference engine ships a capable RPC data plane but no control plane. linkcpp adds the missing half — discovery, planning, launch and gateways — around stock binaries.
Everything Kvasir runs on starts here. linkcpp is a source-available control plane (Business Source License) around inference engine's RPC data plane: it runs large AI models across multiple GPUs and machines using *stock* ggml-rpc-server / llama-server binaries. The data plane stays unforked — everything linkcpp adds is orchestration.
A data plane without a control plane
inference engine can already split a model across machines over RPC — but someone has to discover the GPUs, decide which layers go where, launch the right workers with the right budgets, check that every node speaks the same protocol, and expose an API developers can actually call. Doing that by hand for one cluster is a chore; doing it for an open network of strangers' devices is impossible. That coordination layer is linkcpp.
One hub, stock workers, standard gateways
Request flow — the hub orchestrates, stock binaries compute.
browser / SDK → hub :19000 # FastAPI control plane (single Docker image) → GPU-less llama-server master # per-controller, :8080+ → ggml-rpc-server workers # local slots, remote units, managed agents

- Three ways a machine joins: fixed local node slots with editable VRAM/RAM/CPU budgets; remote units — register another hub and import its nodes; and managed node agents — worker-only services that join over plain request/response HTTP, deliberately not a persistent stream, so they survive simple LAN/VPN routing.
- Compatibility gating is first-class: every unit, node and agent reports a protocol / runtime-pack identity plus backend details. Unit, runtime-pack, inference engine-revision and RPC-ABI mismatches are hard-blocked before bind, plan, load or infer — backend differences (CUDA/Metal/Vulkan/CPU) are tracked as capabilities, not rejections.
- The planner reads GGUF metadata and produces contiguous per-node layer placement,
--tensor-split, KV-cache/layer/expert VRAM estimates, and optional expert-FFN offload to RAM. - Gateways: every controller exposes OpenAI-compatible (
/v1/chat/completions,/v1/responses,/v1/models) and Anthropic-compatible (/anthropic/v1/messages|models) endpoints, backed by the same loaded model — existing clients work unchanged.
This deliberate split — an unmodified data plane under an open control plane — is what everything later builds on: the ring runtime, the layer market, and eventually the expert-sharded swarm are all control-plane evolutions over the same stock compute.