A future where compute costs approach zero
Writing software keeps getting cheaper. Running it does not.
An agent can write a service in minutes. Someone still has to decide how many CPUs it gets, where its data lives, how it reaches the network, and what happens when it crashes. These decisions became the blockers slowing down the process.
We talked about this gap with Reflex and Byteport at our Infra for Intelligence panel.
Starting a machine is the easy part
Keeping it useful is harder. A machine has to isolate its workload, grow and shrink with demand, keep the state that matters, and fail in a way someone can understand.
Each of these requirements gets harder as the number of machines scales, and everything built on top of the system inherits the result. When a resource manager misjudges capacity, or a recovery step cannot survive an interruption, someone’s product goes down.
Defaults were set before agents existed
Most workflows still start the same way. You pick a machine shape, guess how much CPU and memory it needs, and wire up the services around it.
Agents break those guesses, because they start work and hit failures far faster than a person watching a deploy. One task can fan out into many attempts, and each attempt needs different resources as it runs.
We don’t think running an application should mean stitching services together or fixing machine sizes up front. The machine should be able to make those decisions itself. Faster hardware and new workloads are a good reason to revisit the old model for improvements, and that is what we are building.
Most hardware sits idle
In systems our team worked on before smol machines, servers used only about 20% to 30% of the capacity provisioned for them.
Some headroom is necessary so a service can absorb a spike. But most of the unused capacity is locked up by fixed assignments, or it takes too much work to share safely.
Closing that gap is part of our mission. Faster processors, memory and storage keep making each machine cheaper, and getting more work out of the machines we already have is the next step.
One primitive for every workload
So we built smolvm as one machine primitive for CPU work, GPU work, storage and isolation, all managed the same way.
Today a single project might train a model in a GPU container, run its reinforcement learning evaluations in a local VM, and sandbox its agents on another cloud. Every move means rebuilding the environment, learning another interface and maintaining another set of deploy scripts.
With one primitive, the same machine carries the work from training to evaluation to running agents, with the resources each step needs. It runs on a laptop, on your own servers or in the cloud.
- in use
- 36%
- free for other work
- 5%
- in use
- 36%
- free for other work
- 64%
The same four workloads on both hosts. Black outline: one machine. Deep green: what it uses. Light green: reserved and idle. Illustrative numbers.
The .smolmachine file format packs a prepared Linux environment into one file, including its installed software and disk state. You can run that file locally, on your team’s servers, or through smol cloud without setting anything up again. The host only needs a matching CPU architecture and whatever GPU support the workload uses.
Cheaper compute, less work
We think useful compute will cost a trivial amount, and managing it will take far less work than it does today. This future comes from sharing hardware better, setting up an environment once and reusing it, and running everything on one consistent machine model.