SolutionsVibe coding
Every prompt, a running app
Your agent builds each app in a sandbox, with a link to preview it, then ships it as a Cube that sleeps until someone opens it.
from glac import Glac, AGENTS
glac = Glac()
sbx = glac.sandboxes.create(image=AGENTS, env=model_keys)
sbx.agent("claude").run("Make a todo app on port 3000")
print(sbx.url(3000)) # preview: a link to the port
image = "ghcr.io/you/todo:1" # what your build pushed
app = glac.cube.deploy(image, name="todo", port=3000)
print(app.url) # its own HTTPS address
app.rollback(1) # back a version in one callTwo machines for every app
Every app needs a machine to build in and one to run on, each paid for all month if kept running. Here both sleep: the sandbox when the agent stops, the Cube between requests.
Build in a sandbox, ship as a Cube
The agent works in a sandbox, with a link to its dev server and a fork for every attempt. What it ships is an image, deployed as a Cube at an address of its own, with instances that wake for requests.
What your product gets
Build in a sandbox: a terminal, a link to the dev server, a fork for every try.
A volume for the database, billed by the data it holds.
Ship as a Cube: every deploy a version, at its address or your customer’s domain.
Asleep until opened, 100 ms after its last request, and awake with its memory.
One instance per end user, picked by a key in the request.
Usage per customer, read by their label, with a monthly spend limit.
Illustrative previews
Measured, not promised
Medians on bare metal with nothing else running: a best case, and we say so. A Cube’s instance is the same kind as a sandbox. How we measure
- to wake a sleeping instance2
- 3.5 ms
- for the call that woke it, sent to answered2
- 6.7 ms
- to put it to sleep, with its memory and processes2
- 2.3 ms
See it for your own apps once the service opens: the log’s line for a request that woke an instance says how long the wake took.
glac cube logs todo -f
# one line a request; one that woke an instance says how long it tookThe products it uses
- SandboxA computer of its own for every agentWhere the agent builds and previews, a fork for every attempt.
- CubeAny container image as an app that sleeps between requestsWhere each app runs once it ships, at its own address, asleep between requests.
- VolumeCube’s disks, which outlive their instanceA disk for an app’s own database.
- Serverless PostgresSoonPostgres that sleeps when idle and wakes on a connectionManaged Postgres for the apps, asleep when idle, when it opens.
A month, worked out
A thousand apps made and run in a month, at the list prices. Estimate your own
The use
- 1,000 apps, each built by the agent in a sandbox of 2 vCPUs and 4 GiB for half an hour, its CPU busy a fifth of the time, 2 GiB in use; the sandbox deleted after.
- Each app then a Cube answering 30,000 requests in the month, 20 ms of CPU each, 256 MiB in use, 20 KB an answer.
- Requests arriving at random; an instance awake while it answers and for 100 ms after.
A month at the list prices
- CPU1.32 billion CPU-ms × $0.01 / M$13.20
- Memory1,250 GiB-h × $0.008$10.00
- Requests30 million × $0.30 / M$9.00
- Traffic out600 GB × $0.004$2.40
On Paid this month is $31.60: the $5 fee, and $26.60 past what its inclusions cover, from your balance at the same prices.
Ship the first app
A key, then an image deployed as a Cube with one command, or a sandbox for your agent to build in.