Reach
Connected Cluster
Cells can discover and reach the parts of the system they need. The cluster gives reach. It does not decide how every Cell executes.
Platform & Architecture · Scaling
Scaling to Millions of Cells
Celluster does not scale by building a bigger scheduler, a bigger controller, or a bigger coordination system. Each Cell carries the intent for how its own execution should behave, then adapts continuously through bounded Reflexes.
A million Cells do not create a million-way coordination problem.
They create a million independent execution boundaries, each acting on the conditions that matter to its own intent.
Celluster scaling architecture: connected reach, intent-scoped participation, and bounded host execution.
Start With the Simple Idea
A Cell can hold the infrastructure you already run.
One Cell can contain many workloads. Those workloads can be ordinary processes, containers, virtual machines, services, or even an entire Kubernetes cluster.
Celluster does not require you to turn everything into a new type of workload. The Cell sits around the execution and gives it authored intent: how it should behave, what it should preserve, what evidence matters, and which Reflexes it may use when conditions change.
A Kubernetes cluster can therefore become one workload inside a Cell. So can a group of VMs. So can dozens of containers. So can a process. The Cell is the execution boundary around them.
Processes
Containers
Virtual Machines
Services / Workload Sets
Entire Kubernetes Cluster
This is why “4,096 Cells on a host” is not the same statement as “4,096 Pods on a node.”
A Cell is bigger than any one workload object. It is the semantic execution boundary around whatever execution you place inside it.
How the Scale Model Works
Reach, purpose, and execution do not have to scale as one giant system.
Traditional systems tend to pull more state and more decisions into shared schedulers and controllers as they grow. Celluster separates the problem.
Shared Purpose
Intent Mesh
Cells with the same authored purpose participate together. Every Cell in a million-Cell system does not need to talk to every other Cell.
Where Action Happens
Host
Each host handles the Cells actually executing there. Evidence reaches the intended Cell locally, where that Cell can evaluate its own Reflexes.
Measured Cluster Scale
The logical population reached one million without turning every operation into a one-million-Cell operation.
1,000,000
retained Cell identities exercised
Authenticated readiness stayed essentially flat as retained population grew from 1,024 to one million.
31,250×
population growth
Distribution work grew only from 4 to 14 copies per update — 3.5× work while logical population grew 31,250×.
1,000,000 → 1
repeated-event collapse
Repeated million-event pressure can collapse into the one actionable retained state that matters.
The important point is simple: more Cells do not automatically create proportionally more coordination work.
Measured Host Scale
4,096 Cell contexts on one host, with Cell-local Reflex handoff staying around 89–112 µs.
This is the host-level proof that thousands of Cell execution boundaries can remain individually routable without turning the host into a shared scheduling bottleneck.
4,096
Cell contexts on one host
Distinct Cell contexts remained independently addressable while evidence reached the intended Cell and its membrane-local Provider.
89–112 µs
Cell-local Reflex handoff
The Cell-local Reflex handoff stayed in the same narrow range while logical Cell density increased.
64×
density increase exercised
Isolation and Cell-local Reflex behavior held as the tested Cell context population grew from 64 to 4,096.
Host-local figures shown here are from the shared benchmark material and portable host test path. Hardware-specific execution capacity still depends on what those Cells actually contain and the physical resources available.
Why the Usual Density Comparison Is Misleading
A Pod, task, VM, and Cell are not the same thing.
The familiar numbers are useful for orientation, but they count different units. A Cell can wrap many of those units and govern their execution as one authored semantic boundary.
| System | What is being counted | Reference figure | Plain-English meaning |
|---|---|---|---|
| Celluster | Cell execution boundaries | 4,096 validated on one host | A Cell may contain one process, many containers, VMs, services, or even an existing Kubernetes cluster. |
| Kubernetes | Pods | 110 per node | Counts Kubernetes workload objects managed through the Kubernetes control model. |
| Slurm | Tasks | 512 per node by default | Counts scheduled task execution units. |
| AWS T3 Dedicated Host | VM instances | Up to 192 T3 instances | Counts VM instances placed on one dedicated physical host. |
| Run:ai | Kubernetes workloads | Kubernetes-dependent | Runs on Kubernetes and therefore works within the Kubernetes node/workload model. |
Celluster is not trying to fit more Pods into the same node.
It changes the unit of infrastructure itself: from externally managed workload objects to intent-bound execution boundaries.
The Scaling Principle
Scale comes from execution acting on intent, not from coordinating more infrastructure.
Celluster does not decentralize a control plane into smaller control planes. It removes the control plane as the authority over execution. Each Cell preserves its own authored execution contract, and large-scale system behavior emerges from those bounded adaptations.