System Types

@app.job(system=...) requests a GPU tier for that job, from a fixed, published catalog of four: simulo.SystemType.TIER_1 through TIER_4. There is no free-text gpu= argument anymore, and there is no way to name hardware outside this list.

The four tiers

Tier	GPU model	VRAM	vCPU	Memory	Status
simulo.SystemType.TIER_1	T4	16 GB	4	16 GB	available
simulo.SystemType.TIER_2	A10G	24 GB	4	16 GB	available
simulo.SystemType.TIER_3	L4	24 GB	4	16 GB	not yet available
simulo.SystemType.TIER_4	L40S	48 GB	4	32 GB	not yet available

Tiers 3 and 4 are published so you can see what’s coming, but the deployable fleet can’t provision either one today. Requesting one is refused up front (see below), not accepted and then left waiting for hardware that never shows up.

@app.job(system=simulo.SystemType.TIER_1, timeout=8 * 60 * 60)
def train(num_envs: int = 4096, max_iterations: int = 200) -> dict:
    ...

num_envs here is this training job’s own parallel-simulation count. It is NOT the same number as simulo systems’ MAX PARALLEL ENVS column, and the two can disagree: that column is a measured ceiling (16, for Tier 1) for one specific default workload, where a 4096-environment run exhausted the GPU’s memory. This example’s own default of 4096 is the shipped code’s choice, not a value benchmarked against that ceiling. Nothing in this platform enforces the catalog’s number today, so scaling num_envs up on any tier is on you to benchmark; the number in the catalog is a warning from one measured failure, not a limit that stops you.

system= has to be a catalog member, not a string

system="tier1" is refused, even though it spells a real tier’s own value. @app.job validates system= in its own decorator body, so this fails the moment Python imports your module, before anything uploads or contacts the platform. It is a plain Python exception, not a message the CLI formats for you, so you see it as part of a traceback ending in the line below:

TypeError: @app.job(system=...) must be a simulo.SystemType member, e.g. system=simulo.SystemType.TIER_1;
got 'tier1'. Run `simulo systems` to list the tiers.

Only the enum member is accepted, never a raw string, so a typo or a guessed value fails immediately rather than quietly falling through to whatever **extra would have done with an unvalidated string.

Requesting a tier the fleet can’t provision yet

system=simulo.SystemType.TIER_3 and TIER_4 raise the same way, at the same point, when you decorate the job:

ValueError: @app.job(system=SystemType.TIER_3) (L4) is not available on the platform yet. Available
today: SystemType.TIER_1 (T4), SystemType.TIER_2 (A10G). Run `simulo systems` for the full
catalog.

That’s a refusal at decoration time, not a job that gets accepted and then never scheduled. The error names the GPU model you asked for and the tiers that are actually available today, so you can pick one without a second lookup.

The old gpu= parameter is gone

@app.job(gpu="L4"), the parameter system= replaced, is rejected outright rather than silently accepted and ignored:

TypeError: @app.job(gpu=...) is no longer supported. Request a GPU system tier instead:
@app.job(system=simulo.SystemType.TIER_1). Run `simulo systems` to list the
tiers and which are available today. Remove gpu=.

Note

There’s no compatibility window for gpu=: it was a free-text argument nothing validated, and every shipped example already uses system=. Every app that used to say gpu="L4" in this repository ran on Tier 1 (T4) hardware regardless of that string, since the fleet never read gpu= in the first place. If you have an existing app that still passes gpu=, replacing it with system=simulo.SystemType.TIER_1 matches what that app was already running on.

Discovering the catalog: simulo systems

simulo systems
simulo systems --json

Both forms list all four tiers, including the two not yet available, and read only the published catalog: no network call, no credential resolution. The table version ends with a footer stating plainly that your choice is recorded on the job and doesn’t select hardware today: no tier schedules faster or trains better than another, and neither does leaving system= out entirely. A numbered ladder invites the opposite assumption, that TIER_4 means “faster,” so the footer says so explicitly rather than leaving you to guess.

What system= does today

Selecting a tier is a declaration, not a scheduling request. It’s recorded on the job and validated against the catalog above; it does not yet choose which hardware your job actually runs on, because the fleet enforces nothing per tier yet. Picking TIER_1 over TIER_2 (or omitting system= entirely) has no effect on how fast your job starts or how it performs.