M-Core Engine
Applications hardcode their capacity: worker counts, queue depths, cache sizes, concurrency constants. M-Core Engine inspects the hardware once at startup and derives all of it from what is actually there.
The core engine is written in Rust. It reads the machine at startup and derives every runtime budget from it, covering pools, caches, queue depth, connections, and sidecar policy, while verifying application integrity as it runs.
Core capabilities
- Detect host hardware once at startup and emit a single bootstrap plan
- Derive CPU pools, thread pools, queue depth, cache sizing, and connection budgets from that plan
- Classify runtime tier from low-end through server-grade and emit NUMA guidance
- Provide TTL and LRU caches with stampede protection
- Verify application integrity during execution, with protection reaching the hardware layer
- Supervise sidecars with health checks, restart backoff, port assignment, and graceful shutdown
- Return explainable balance decisions: stay local, rebalance to a warm node, or hand off
- Exhaust warm capacity before M-Core Autoscaler provisions anything new
Why it exists
Applications carry their capacity assumptions as constants: a thread pool sized to eight, a queue depth picked during development, an adapter pinned to sixteen concurrent requests, per-service caches with unrelated TTL rules. Each of those numbers is a guess about a machine, and each stops being right the moment the machine changes. M-Core Engine inspects the host once at startup and emits a single bootstrap plan that everything downstream derives from instead, covering pools, queue depth, cache sizing, connection budgets, NUMA guidance, and a runtime tier from low-end through server-grade.
Plan once, actuate per host
The core engine is written in Rust and is the only planner in the system. Python and TypeScript are SDKs over that engine rather than reimplementations of it. They consume the bootstrap contract and apply it in the terms their language can honour: Python building process pools, thread pools, asyncpg sizing, shared memory, and CPU affinity groups; TypeScript configuring caches, bounded concurrency, and a real worker-thread pool. Electron and Tauri are integrations, and they reach the engine differently: the Electron bridge is built on top of the TypeScript SDK and mirrors it over IPC, while the Tauri crate links directly to the engine and skips the SDK layer entirely. None of them re-derive the plan.
Sidecars it supervises
The engine owns sidecar lifecycle, covering environment injection, port assignment, health checks, restart backoff, and graceful shutdown, while leaving each sidecar's own protocol alone. A sidecar speaking HTTP, gRPC, or a model-serving protocol keeps that surface to itself; the engine governs only whether it is running, healthy, and correctly resourced. That boundary is how the SGLang model servers behind Senon AI are supervised.
Warm before scaled
For any request that could run elsewhere, the engine returns one of three decisions with its reasoning attached: keep it local, rebalance to an already-warm node, or hand off to the orchestrator. That ordering is the point. Warm capacity is exhausted before M-Core Autoscaler is asked to provision anything, so scale events happen because they are needed rather than because a threshold moved. The engine decides and explains; the gateway still performs the forwarding.
Integrity at the execution layer
The engine carries integrity responsibilities alongside the performance ones. Application integrity is verified during execution rather than only at load, and protection reaches down to the hardware layer. Those checks belong in the runtime that already inspects the machine and owns execution, not in a separate agent watching from above it. The same layer that decides how work runs is the layer positioned to confirm that what is running is what was meant to run.