01 / Idle capacity
Sessions waiting
Agent sessions can remain available while waiting on models, tools, users, or external services. Memory held during that wait may constrain how many sessions fit on a host.
Infrastructure economics / workload-dependent
Pay for work.
Not waiting.
Agent infrastructure can spend more time holding execution environments ready than doing useful computation. A smaller runtime can improve density and reduce the capacity you need—when it replaces a meaningful part of your stack.
Where costs originate
Infrastructure has more
than one cost center.
A lower-footprint execution engine can reduce the resources attributable to compatible code execution. It does not automatically eliminate browser, application server, LLM, storage, or network costs.
02 / Active execution
CPU and startup overhead
Short-lived tasks can spend a meaningful fraction of their lifecycle starting a runtime or loading dependencies. A minimal execution path may reduce that overhead.
03 / The rest of the stack
Browsers and services
Chrome, Python/Node services, orchestration, and model inference can dominate overall spend. They remain separate cost centers unless a deployment explicitly changes them.
The economic question: How much billable or capacity-constraining infrastructure does Securely actually replace in your application—not how small a microbenchmark looks?
Interactive capacity model
Model the part
you can replace.
Change the assumptions to estimate the memory-constrained host capacity and associated infrastructure spend for a compatible execution tier. Defaults are illustrative inputs, not Securely benchmark measurements or customer results.
Workload inputs
Simultaneously held execution sessions.
Measured incremental, capacity-relevant footprint—not a container limit.
Your expected workload-specific footprint; validate in a PoC.
Unchanged browser/server memory attributable to each session.
After OS and reserved headroom.
Your effective price; no cloud-provider price is assumed.
Hours the capacity is provisioned.
Conservative packing factor for workload variance.
Minimum host count required for CPU, network, placement, or other bottlenecks. Enter 0 to model memory-only capacity.
Calculations update as you type. No data leaves this browser.
Illustrative model output
Current monthly capacity cost—
Modeled monthly capacity cost—
Potential monthly difference—
Modeled reduction—
Current hosts—
Modeled hosts—
What this estimates: a memory-constrained host count, subject to the non-memory host floor you enter. It is not a cloud bill, a measured customer saving, or a Securely price quote. Migration, licensing, observability, redundancy, and other costs are excluded.
A reduction in allocated memory is not necessarily a reduction in billed compute. If CPU, browser, or other requirements determine host count, savings may be zero even with much smaller execution memory.
Evidence versus extrapolation
Measured footprint.
Unmeasured customer savings.
Measured program example
5.1 MiB
Native Joulebox memory
Compared with 56.4 MiB for stock Go in one same-output internal experiment. That is a program-level measurement, not an end-to-end agent cost comparison.
Read the benchmark context →Measured scale experiment
1,000,000
Concurrent sessions
Created and held across a 1,024-vCPU fleet in 3.39 seconds. The fleet provisioned 2 TiB of RAM; this is not evidence of a universal 1 MiB billable reservation per session.
Read the scale methodology →Neither benchmark establishes a customer-wide cost-reduction percentage. Cost depends on actual workload compatibility, CPU time, idle footprint, shared infrastructure, utilization, and pricing.
How to prove savings
Benchmark the whole path.
A design-partner PoC should measure the same representative agent steps under equivalent functionality, security requirements, and load—not compare unrelated sandbox configurations.
01 / IDENTIFYSeparate workloads
Distinguish compatible code execution from Chrome, persistent servers, model inference, and external APIs.
02 / MEASUREBaseline the bill
Capture actual CPU time, RSS/PSS, idle memory, startup latency, success rates, and reserved capacity.
03 / REPLACERun equivalent work
Test only workloads supported by the restricted runtime, with the same functional output and security constraints.
04 / VALIDATECompute net savings
Include integration overhead, shared-service costs, operational staffing, and pricing—not just memory ratios.
Practical boundaries
Where the model helps.
Where it doesn't.
| Workload | Potential economic impact | Important limitation |
|---|---|---|
| Short-lived code tools | Lower startup and execution overhead may improve throughput and density. | Only supported Go and translated Python subsets. |
| Many idle sessions | Smaller session state may improve memory density. | Depends on actual retained state and host packing. |
| Browser-driven agents | Lightweight non-browser steps may still benefit. | Chrome and its per-context costs are outside the native runtime. |
| Persistent application servers | Possible savings in separately extracted short-lived tasks. | Not a drop-in replacement for arbitrary Python/Node services. |
Commercial model
Start with evidence.
Price for value.
Securely is currently exploring design-partner deployments. There is no published production rate card or independently verified customer-wide savings figure.
01 / Compatibility
Find the replaceable tier
Determine which existing tasks can run under Securely's restricted execution model.
02 / Economics
Agree on success metrics
Measure cost per successful task, host density, tail latency, and operational constraints.
03 / Deployment
Evaluate your environment
Discuss integration, security onboarding, and deployment within your infrastructure where appropriate.
Design partners / cost validation
Bring your actual infrastructure numbers.
We can scope a representative workload, compare equivalent execution paths, and establish whether the economics justify integration.
Contact email is a deployment placeholder until configured.