Scaling - Hexel Studio

Instances run always-on with CPU throttling, so they wake in milliseconds and cost little when idle. As traffic grows, you can scale capacity to handle more concurrent load.

Tiers

Two different problems call for two different solutions. If traffic is growing and requests are queuing up, you need more replicas — that’s horizontal scaling (covered below). If a single request is slow because the workload itself is heavy (large model inference, complex data transforms), you need a larger tier with more CPU or memory. The tier table below helps you pick the right baseline for each instance. Each instance runs on a tier that sets its baseline CPU and memory:

Tier	CPU	Memory	GPU	Best for
`micro`	0.25 vCPU	256 MiB	—	Lightweight agents, quick tasks
`standard`	0.5 vCPU	512 MiB	—	Most agents and sandboxes
`large`	1 vCPU	1 GiB	—	Heavier processing, RAG pipelines
`gpu`	2 vCPU	2 GiB	1	GPU-accelerated workloads

If the requested tier has no capacity, the deploy or scale operation returns HTTP 503. The platform does not fall back to a different tier.

Scaling via the API

Scale a running instance to adjust replicas. The permanent endpoint stays the same and load is distributed across replicas.

CLI
curl

hexel compute instance scale YOUR_INSTANCE_ID --replicas 3

curl -X POST https://api.hexelstudio.com/compute/v1/instances/YOUR_INSTANCE_ID/scale \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"replicas": 3}'

Parameters

integer

required

Number of replicas to run behind the permanent endpoint.

Response

string

The scaled instance.

integer

Current replica count after scaling.

string

Instance state (remains running).

Choosing a tier

Scenario	Recommended tier
Simple request routing, lightweight logic	`micro`
General-purpose agents, chat, tooling	`standard`
Retrieval-heavy or data-processing agents	`large`
Model inference, embeddings, image processing	`gpu`

If a single request is slow, a larger tier may help more than additional replicas. If throughput (concurrent requests) is the bottleneck, increase replicas.

Does scaling change the endpoint?

No. The permanent endpoint stays the same. Traffic is balanced across replicas.

Can I scale to zero?

Use stop to halt all traffic. Scaling to zero replicas is equivalent to stopping the instance.

What happens if I choose a tier that's unavailable?

The operation returns HTTP 503. Retry after a delay or choose a different tier.

Limits & quotas

Limit	Scope	Behavior
Replicas per instance	Per instance	Plan-enforced ceiling.
Total concurrent replicas	Per organization	Plan-enforced.

Numeric limits depend on your plan — see the Console.

Errors

`error_code`	HTTP	When
`invalid_request`	400	Invalid replica count.
`not_found`	404	The instance ID doesn’t exist.
`capacity_exhausted`	503	No capacity to add replicas right now. Retry shortly.

Common mistakes

Scaling instead of choosing the right tier. If a single request is slow, a larger tier helps more than more replicas.
Over-provisioning early. Scale to observed load, not anticipated peaks.

Best practices

Watch metrics before and after scaling.
Scale based on concurrency and latency, not raw request counts alone.
Keep production and development instances on separate environments.

Instances

Deploy and manage instances.

Runtime Lifecycle

How instances stay healthy and recover.

Metrics

Measure load and latency.

Tiers & Limits

Tier capacities and account limits.

Next steps

Continue to Sessions & Filesystems.

​Tiers

​Scaling via the API

​Parameters

​Response

​Choosing a tier

​Limits & quotas

​Errors

​Common mistakes

​Best practices

​Related pages

Instances

Runtime Lifecycle

Metrics

Tiers & Limits

​Next steps

Tiers

Scaling via the API

Parameters

Response

Choosing a tier

Limits & quotas

Errors

Common mistakes

Best practices

Related pages

Next steps