agi.diy

Reference / How it works · look things up, do not read through

How it works.

What a policy is, what one call sends and returns, what a session costs, and what has to match on your robot. Each section opens with its one figure; the full text is one click further.

The model behind every agi.diy call, in the words the product uses. Each diagram is generated at build time from the deployment files, the Worker constants and one recorded session (web/scripts/concepts.mjs); the numbers are labelled with where they came from.

Three ways in, depending on why you are here:

The numbers, in one place#

Everything below is explained in its own section; this is the scan. Every row is generated from the same source its section quotes, so this table cannot disagree with the page.

one action$0.0001 — 1 tokenTokens and billing
one call100 actions ($0.01) on agi-act/so101 · 50 ($0.005) on agi-smolvla/so101 · 32 ($0.0032) on agi-wfm/so101Chunks, horizon and fps
new account200,000 tokens of creditTokens and billing
slots today2 agi-wfm/so101 · 3 agi-act/so101 · 4 agi-smolvla/so101 · 2 stock-act/so101 · 3 stock-smolvla/so101 · 2 custom, one client each — 4 runners, measured 2026-10-25More than one arm
a leaseconnect within 60 s · ttl 600 s by default, 60–3600 allowedSessions
time on the runner18.7–67.2 ms act · 366.6–416.6 ms smolvla (recorded probes)Latency
your own checkpointact, smolvla or diffusion · safetensors · ≤ 3 GB · 2 live, 10 cold starts an hourPolicies
browser wireone message ≤ 8 MB · no observation for 120 s closes itThe loop
a trace24 hours, then goneTraces
unitsarm -100…100, gripper 0…100 — never degreesNormalized units

Check this page yourself. Three public endpoints, no key, nothing billed:

a=https://api.agi.diy
curl -s $a/v1/models
curl -s $a/v1/stats
curl -s $a/reference/concepts/glossary.json

This table is also data: /concepts/numbers.json carries the same ten rows with the section that explains each, generated from the same sources.

/v1/models returns action_horizon, fps, cameras, slots_free, slots_total and units for everything served right now — except that the custom row carries no horizon (a custom checkpoint's comes from the checkpoint), and a model whose slots are all busy still reports its descriptor, because the catalog fills each field from the first runner that has one, newest generation first, instead of from whichever slot happened to be enumerated first; /v1/stats returns tokens, calls, models_online and last_call_at; the glossary returns this vocabulary as data, including semantics_label_by_surface — which surface reports which units label, and which one is right.

Policies#

A policy is a trained model that turns what a robot sees and feels into what it should do next. agi.diy serves policies over an API: you send an observation, it returns actions. Your robot, your control loop and your safety checks stay on your side.

The two default-tier policiesagi-act/so101: six joint values and top+wrist cameras in, 100 actions out, 207 MB checkpoint from scratch on real SO-101 teleoperation, no text input. agi-smolvla/so101: six joint values, front+wrist cameras and task text in, 50 actions out, 907 MB checkpoint trained in simulation. Both SO-101, 30 fps. agi-act/so101ACT · action chunking transformerin6 joint valuestop + wrist cameras, 640×480no text inputout100 actions × 6 joints3.33 s of motion at 30 fpscheckpoint207 MB · from scratch, real data18–20 ms policy time on the runneragi-smolvla/so101SmolVLA · vision-language-actionin6 joint valuesfront + wrist cameras, 640×480+ task textout50 actions × 6 joints1.67 s of motion at 30 fpscheckpoint907 MB · fine-tuned, real data365 ms policy time on the runner
The two default-tier policiesagi-act/so101: six joint values and top+wrist cameras in, 100 actions out, 207 MB checkpoint from scratch on real SO-101 teleoperation, no text input. agi-smolvla/so101: six joint values, front+wrist cameras and task text in, 50 actions out, 907 MB checkpoint trained in simulation. Both SO-101, 30 fps. agi-act/so101ACT · action chunking transformerin6 joint valuestop + wrist cameras, 640×480no text inputout100 actions × 6 joints3.33 s of motion at 30 fpscheckpoint207 MB · from scratch, real data18–20 ms policy time on the runneragi-smolvla/so101SmolVLA · vision-language-actionin6 joint valuesfront + wrist cameras, 640×480+ task textout50 actions × 6 joints1.67 s of motion at 30 fpscheckpoint907 MB · fine-tuned, real data365 ms policy time on the runner
The two default-tier policies. Drawn from runtime/deployments/*.yaml (cameras, fps, training note) · runtime/CAPACITY.md (horizon, checkpoint size, policy time)

Read the full section →

The loop#

The robot ↔ cloud loopYour robot sends an observation (six joint values, two top/wrist or front/wrist camera images, a task for SmolVLA). The runner returns a chunk of 100 (ACT) or 50 (SmolVLA) actions × 6 joints, played at 30 per second while the next observation is sent. Recorded ACT round trips from a Mac over the public relay: 59–157 ms. your robot · SO-1016 joint values2 cameras · 640×480plays actions at 30 fpsyou own this loopagi.diy runnerone warm slot per sessionact/so101 · smolvla/so101GPU, never touchesyour hardwareobservationstate[6] + 2 JPEG+ task text (SmolVLA)chunkn × 6 actions(100 ACT · 50 SmolVLA)round trip, act/so101 from a Mac over the public relay (recorded probe): 59–157 msa chunk plays 3.3 s (ACT) or 1.7 s (SmolVLA): ask for the next before it ends1 call = 1 observation in, 1 chunk out
The robot ↔ cloud loopYour robot sends an observation (six joint values, two top/wrist or front/wrist camera images, a task for SmolVLA). The runner returns a chunk of 100 (ACT) or 50 (SmolVLA) actions × 6 joints, played at 30 per second while the next observation is sent. Recorded ACT round trips from a Mac over the public relay: 59–157 ms. 1 call = 1 observation in, 1 chunk outyour robot · SO-1016 joint values2 cameras · 640×480plays actions at 30 fpsyou own this loopobservationstate[6]2 JPEG(+ task)chunk100 or 50actions× 6 jointsagi.diy runnerone warm slot per sessionact/so101 · smolvla/so101GPU, never touchesyour hardwareact round trip 59–157 ms (recorded)chunk = 3.3 s (ACT) · 1.7 s (SmolVLA)
The robot ↔ cloud loop. Drawn from runtime/deployments/*.yaml (cameras, horizon, fps) · act round trip: recorded probe ses_fxA3qHVEJekI5JH3TleZUf

One call is one observation in and one chunk out. The robot starts playing the chunk while it already sends the next observation, so the network round trip hides inside the motion the previous chunk bought. Two transports carry the same call:

Read the full section →

Sessions#

Session lifecyclePOST /v1/sessions creates a session in state leased. It becomes active when a client attaches (within about a second of connecting). It ends as client_done, expired (ttl 60–3600 s, default 600), credits, runner_lost, or never_connected if no client attaches within 60 s. POST /v1/sessionswarmingloadingleasedreservedactiveattachedendedback to poolloadedconnectsendsnever_connected — no client within 60 s of the leaseclient_done — you closed itexpired — ttl_s (default 600 s)credits — usage credit hit 0runner_lost — slot disappearedreplay_failed — a replay feed stoppedload_failed — checkpoint would not loadbilling: calls only, never lease time — tokens are charged per returned action
Session lifecyclePOST /v1/sessions creates a session in state leased. It becomes active when a client attaches (within about a second of connecting). It ends as client_done, expired (ttl 60–3600 s, default 600), credits, runner_lost, or never_connected if no client attaches within 60 s. POST /v1/sessionsleasedslot reservedclient connectsactiveclient attachedany end reasonendedslot back to poolnever_connected — no client in 60 sclient_done — you closed itexpired — ttl_s (default 600 s)credits — usage credit hit 0runner_lost — slot disappearedreplay_failed — a replay feed stoppedload_failed — checkpoint would not loadbilled per action, not lease time
Session lifecycle. Drawn from worker/src/runners.ts (states, end reasons) · worker/src/util.ts (ttl, connect_by)

POST /v1/sessions leases one warm slot — a policy process already loaded on the GPU — and returns a session: its id, the deployment name, the endpoint, the features the model expects, the horizon and the fps. Nobody else can use that slot until the session ends.

Read the full section →

Availability#

GET /v1/models (public, no key) reports each model's state and its free slots, summed across whichever runners serve it; GET /v1/health lists the runners and their roles. The fleet is four runners; one broker on the demo Jetson keeps 2 ACT slots and 3 SmolVLA slots warm, and the live totals come from the same payload.

Read the full section →

More than one arm#

A slot serves one client at a time, so two arms means two sessions and the pool is the ceiling. Measured on 2026-10-25: 2 agi-wfm/so101 slots, 3 agi-act/so101, 4 agi-smolvla/so101, 2 stock-act/so101, 3 stock-smolvla/so101 and 2 for custom checkpoints, across 4 runners (Availability) — a snapshot, since the fleet grows; curl -s https://api.agi.diy/v1/models is the live answer. …

Read the full section →

Observations and cameras#

An observation is one snapshot from the robot:

Where the two cameras sitSide view. The table camera is 0.5 m out along the arm's reach and 0.6 m up, tilted back toward the arm (vertical field of view 52.9°); ACT receives it as observation.images.top, SmolVLA as observation.images.front. The wrist slot (41.4°) rides on the gripper for the stock rows' checkpoints; on the default pool (our checkpoints, trained on svla_so101_pickplace) the same slot is a fixed side camera, not one on the gripper. Pose from the /play world manifest, matched to the stock SmolVLA's training camera. tableSO-101 basetable camera · 0.5 m out, 0.6 m upACT: top · SmolVLA: front52.9° vertical view, tilted to the armwrist slot · on the gripper (stock rows)41.4° · every row: wristdefault pool: FIXED side camera, not on the gripperpose from the /play world manifest, matched to the stock SmolVLA's training camera;our checkpoints' poses: in the dataset, not published · arm drawn schematically
Where the two cameras sitSide view. The table camera is 0.5 m out along the arm's reach and 0.6 m up, tilted back toward the arm (vertical field of view 52.9°); ACT receives it as observation.images.top, SmolVLA as observation.images.front. The wrist slot (41.4°) rides on the gripper for the stock rows' checkpoints; on the default pool (our checkpoints, trained on svla_so101_pickplace) the same slot is a fixed side camera, not one on the gripper. Pose from the /play world manifest, matched to the stock SmolVLA's training camera. tableSO-101 basetable camera · 0.5 m out, 0.6 m upACT: top · SmolVLA: frontwrist slot · on the gripper(stock-* rows, third-party checkpoints)41.4° · every row: wristdefault pool: FIXED side camera,not on the gripper52.9° vertical view, tilted to the armpose: /play world, stock SmolVLA rig
Where the two cameras sit. Drawn from runtime/worlds/worlds/desk/world.v1.json (camera pose, field of view, wire names) · arm drawn schematically

Read the full section →

Chunks, horizon and fps#

One returned chunk: 50 actions × 6 jointsFirst call of recorded session ses_6VvrpGKfCWlUDyAgNYgGfD (smolvla/so101, 2026-10-25T00:05:10Z): 50 rows of six joint targets in normalized units (−100…100, gripper 0…100), covering 1.67 s at 30 fps. Camera inputs were the browser simulation. call 1 of ses_6VvrpG… · smolvla/so101camera inputs: browser simulation · chunk: live policy output100500-50-10001020304049action row · each row is 1/30 s · the whole chunk is 1.67 s of motionwrist_flexelbow_flexgripperwrist_rollshoulder_panshoulder_lift
One returned chunk: 50 actions × 6 jointsFirst call of recorded session ses_6VvrpGKfCWlUDyAgNYgGfD (smolvla/so101, 2026-10-25T00:05:10Z): 50 rows of six joint targets in normalized units (−100…100, gripper 0…100), covering 1.67 s at 30 fps. Camera inputs were the browser simulation. call 1 of ses_6VvrpG… · smolvla/so101simulated cameras · live policy100500-50-10002449row (1/30 s each) → 1.67 swristelbowgripperrollsh_pansh_lift
One returned chunk. Drawn from call 1 of recorded session ses_6VvrpGKfCWlUDyAgNYgGfD (smolvla/so101, 2026-10-25T00:05:10Z) — simulated cameras, live policy output

A chunk is the sequence of actions one call returns: n rows × 6 joints, float32. Each row is one action — six target joint values for one tick of the control loop. The horizon is n: 100 for ACT, 50 for SmolVLA, fixed when the session is leased.

Read the full section →

Tokens and billing#

One returned action is one token, and one token costs $0.0001. A call is billed for every row in its chunk, whether or not your robot plays all of them:

Read the full section →

Normalized units#

Both live checkpoints were trained on LeRobot's normalized motor positions (use_degrees=false, the default when their datasets were recorded): the five arm joints run from −100 to 100 across each joint's calibrated range, the gripper from 0 to 100. The values are not degrees, and the semantics label is not the way to find that out — units is. …

Normalized unitsBoth checkpoints use LeRobot normalized positions: five arm joints from −100 to 100 over each joint's calibrated range, the gripper 0 to 100. The session label so101-degrees-gripper-percent-v1 says degrees; do not execute these values as degrees. Marks are the first recorded observation of ses_6VvrpGKfCWlUDyAgNYgGfD. what the six numbers meanlabel says "so101-degrees-gripper-percent-v1" — the data is normalizedarm joint (5)-1000100shoulder_lift -20gripper050100gripper 9.1±100 = the ends of YOUR arm's calibrated range,not a fixed angle — calibration decides the mapping
Normalized unitsBoth checkpoints use LeRobot normalized positions: five arm joints from −100 to 100 over each joint's calibrated range, the gripper 0 to 100. The session label so101-degrees-gripper-percent-v1 says degrees; do not execute these values as degrees. Marks are the first recorded observation of ses_6VvrpGKfCWlUDyAgNYgGfD. what the six numbers meanlabel says "degrees"; data is normalizedarm joint (5)-1000100shoulder_lift -20gripper050100gripper 9.1±100 = ends of your calibrated range,not a fixed angle: calibration maps it
Normalized units. Drawn from web/lib/sim/so101-units.ts · marks: first observation of ses_6VvrpGKfCWlUDyAgNYgGfD

Read the full section →

Latency#

Three numbers, never one:

Where the time goes in one act/so101 callThree recorded act/so101 calls from ses_fxA3qHVEJekI5JH3TleZUf (2026-10-25T05:36:27Z, synthetic inputs, the agi CLI on a Mac, Zenoh over the public relay (tcp/bore.pub)). Policy time 67.2, 18.7, 20.3 ms; time on the runner 98.4, 37.1, 35.3 ms; round trip at the client 157, 59, 95 ms. The rest is network. act/so101 · recorded probe ses_fxA3qHVEJekI5JH3TleZUf · 2026-10-25T05:36:27Zsynthetic inputs · the agi CLI on a Mac, Zenoh over the public relay050100150200call 167.2 · 98.4 · 157 mscall 218.7 · 37.1 · 59 mscall 320.3 · 35.3 · 95 mspolicyrest of the runnernetworkms
Where the time goes in one act/so101 callThree recorded act/so101 calls from ses_fxA3qHVEJekI5JH3TleZUf (2026-10-25T05:36:27Z, synthetic inputs, the agi CLI on a Mac, Zenoh over the public relay (tcp/bore.pub)). Policy time 67.2, 18.7, 20.3 ms; time on the runner 98.4, 37.1, 35.3 ms; round trip at the client 157, 59, 95 ms. The rest is network. act/so101 · recorded probeMac → public relay · synthetic inputs050100150200call 167.2 · 98.4 · 157 mscall 218.7 · 37.1 · 59 mscall 320.3 · 35.3 · 95 mspolicyrest of the runnernetworkms
Where the time goes in one call. Drawn from recorded probe ses_fxA3qHVEJekI5JH3TleZUf (2026-10-25T05:36:27Z) — trace server_ms.policy + rtt_ms, client ms from the agi CLI

Read the full section →

The robot plays chunks from a local queue, so a network drop does not stop the arm at once — and it does not let it run on forever either. The figure shows the worst case; the four steps under it are the same paragraph /docs carries, generated from one source (web/lib/linkdrop.mjs).

When the link drops mid-runWorst case, the link drops just after a chunk arrived: the arm plays what is queued without new observations (up to 3.3 s for ACT, 1.67 s for SmolVLA), then holds its last position target for the 3 s grace agi rollout sets, then the run stops with "action starvation grace expired". Chunks that arrive during the hold resume the run from a fresh camera frame. link dropsact/so101≤ 3.3 s3 s3 storque offsmolvla/so101≤ 1.67 s3 s3 storque off0 s1 s2 s3 s4 s5 s6 s7 s8 s9 s10 splays the queued chunk · no new imagesholds the last position target| run stopsmoves back to the pose it started in| torque off: the arm can fall under gravityworst case: the drop lands right after a chunk arrived. agi rollout asks for the nextchunk when 0.75 s of motion is left, so usually far less is queued. Chunks thatarrive during the hold resume the run from a fresh camera frame.
When the link drops mid-runWorst case, the link drops just after a chunk arrived: the arm plays what is queued without new observations (up to 3.3 s for ACT, 1.67 s for SmolVLA), then holds its last position target for the 3 s grace agi rollout sets, then the run stops with "action starvation grace expired". Chunks that arrive during the hold resume the run from a fresh camera frame. link dropsact/so1013.333smolvla/so1011.67330 s2 s4 s6 s8 s10 splays up to one chunk · no new imagesholds the last position target| run stops: starvation grace expiredmoves back to its start pose| torque off: the arm can fallworst case: the drop lands justafter a chunk arrived. agi rollout asksagain at 0.75 s left, so usuallyless is queued. Chunks during thehold resume from a fresh frame.
When the link drops mid-run. Drawn from sdk/python/agi/rollout.py (starvation grace, timeouts) · LeRobot @d3793b7e remote engine (refill at the SDK's REFILL_S left, hold, starvation fault) + rollout teardown (move to start pose, disconnect torque) · horizon / fps from the deployment files

Read the full section →

Traces, playback and running inference again#

Every session is recorded by default as a trace: each observation the policy saw (joint state, task, camera frames) and each chunk it returned, with timing.

What a trace holdsThe recording of ses_fxA3qHVEJekI5JH3TleZUf: each observation event (joint state, task, both camera frames) and each action event (the chunk, its time on the runner, policy time, tokens), at their real times — obs 0 ms → act 99 ms; obs 122 ms → act 159 ms; obs 221 ms → act 256 ms. trace of ses_fxA3qHVEJekI5JH3TleZUf · act/so101 · synthetic inputs○ observation event (what the policy saw) ● action event (what it returned)050100150200250300mscall 1○ obs · t 0 msstate[6] · top + wrist11.4 KB sent · frames kept● act · t 99 ms100 × 6 · 100 tokensrtt_ms 98.4 · policy 67.2call 2○ obs · t 122 msstate[6] · top + wrist11.4 KB sent · frames kept● act · t 159 ms100 × 6 · 100 tokensrtt_ms 37.1 · policy 18.7call 3○ obs · t 221 msstate[6] · top + wrist11.4 KB sent · frames kept● act · t 256 ms100 × 6 · 100 tokensrtt_ms 35.3 · policy 20.3readable 24 h · playback is free · run inference again = a new, billed session
What a trace holdsThe recording of ses_fxA3qHVEJekI5JH3TleZUf: each observation event (joint state, task, both camera frames) and each action event (the chunk, its time on the runner, policy time, tokens), at their real times — obs 0 ms → act 99 ms; obs 122 ms → act 159 ms; obs 221 ms → act 256 ms. trace of a recorded act probe○ observation in ● chunk out050100150200250300mscall 1○ obs · t 0 msstate[6] · top + wrist11.4 KB sent · frames kept● act · t 99 ms100 × 6 · 100 tokensrtt_ms 98.4 · policy 67.2call 2○ obs · t 122 msstate[6] · top + wrist11.4 KB sent · frames kept● act · t 159 ms100 × 6 · 100 tokensrtt_ms 37.1 · policy 18.7call 3○ obs · t 221 msstate[6] · top + wrist11.4 KB sent · frames kept● act · t 256 ms100 × 6 · 100 tokensrtt_ms 35.3 · policy 20.3playback free · run again is billed
What a trace holds. Drawn from recorded probe ses_fxA3qHVEJekI5JH3TleZUf — GET /v1/sessions/:id/trace event times, sizes and timings (docs/TRACE.md)

Read the full section →

Did it work?#

Nothing in the API answers that. A session tells you the policy answered — a chunk came back, in this many milliseconds, for this many tokens — and how the run ended (end_reason, see Sessions). There is no success, reward or score field in a session, a trace event or any other response: whether the orange ended up on the plate is your measurement, in your workspace, against your task.

What a run answers, and what you have to measureA recorded run (ses_fxA3qHVEJekI5JH3TleZUf, 3 calls of 100 actions, 300 tokens, ended client_done) answers with chunks and timings; its trace keeps the observations for 24 hours; POST /v1/sessions/:id/replay asks the same observations again in a new billed session, so two policies can be compared on identical inputs. Task success appears nowhere in the API: it is measured by watching the robot. recorded run ses_fxA3qHVEJekI5JH3TleZUf · act/so101 · synthetic probe inputsthe service answers3 chunks · 100 × 6 each35–98 ms on the runner300 tokens · $0.03ended client_donenever answereddid the task succeedhow close it camewas that action rightthe trace3 observationsstate[6] + 2 frames11.4 KB eachkept 24 hoursre-ask act/so101same inputs → $0.01 a callre-ask smolvla/so101409 — it wants front + wristrun inference again:a new, billed sessionno robot movesThe world does not replay: identical inputs compare judgement, not success.Counting completions is still yours — watch the run.
What a run answers, and what you have to measureA recorded run (ses_fxA3qHVEJekI5JH3TleZUf, 3 calls of 100 actions, 300 tokens, ended client_done) answers with chunks and timings; its trace keeps the observations for 24 hours; POST /v1/sessions/:id/replay asks the same observations again in a new billed session, so two policies can be compared on identical inputs. Task success appears nowhere in the API: it is measured by watching the robot. recorded run · act/so101the service answers3 chunks · 100 × 6 each35–98 ms on the runner300 tokens · $0.03ended client_donenever answereddid the task succeedhow close it camewas that action rightthe trace3 observations, 24 hstate[6] + 2 frames eachre-ask → new billed sessionidentical inputs comparejudgement, not success —watch the run yourself
What a run answers, and what you have to measure. Drawn from recorded probe ses_fxA3qHVEJekI5JH3TleZUf (2026-10-25T05:36:27Z) — calls, time on the runner, tokens and end reason from its trace · replay rules from docs/CONTRACT.md (409 incompatible_features) and the deployment cameras

Read the full section →

Simulation and real#

/play is an SO-101 simulated in your browser — MuJoCo physics and rendered cameras — driven by real calls to the live policies. Simulated inputs, live policy output. Two views exist there: the camera images sent to the policy are rendered from the simulation's geometry, and the photographic room behind the arm is a human view only — a policy never sees it. …

Simulated inputs, live policy outputIn /play the arm, its physics and the camera images the policy receives are simulated in the browser; the room backdrop is shown to people only and never sent to the policy. The policy, its chunks, the timing, the bill and the trace are the live service. simulated in your browserSO-101 arm + physics (MuJoCo)policy cameras: top · wrist · front(rendered from geometry)room backdrop: human view onlyactions as position targetskp 998.22 · ±2.94 N·m · 200 Hzlive on the servicethe policy and its weightsevery returned chunktiming on the runnerthe bill and the traceobschunkno physical robot moves; a call here is billed like any othernot modelled: your calibration and wear · the grip you really havecamera exposure, blur and lighting · the room your arm is in
Simulated inputs, live policy outputIn /play the arm, its physics and the camera images the policy receives are simulated in the browser; the room backdrop is shown to people only and never sent to the policy. The policy, its chunks, the timing, the bill and the trace are the live service. simulated in your browserSO-101 arm + physics (MuJoCo)cameras: top · wrist · front(rendered from geometry)backdrop: human view onlyactions as position targetskp 998.22 · 200 Hzobschunklive on the servicethe policy and its weightsevery returned chunktiming on the runnerthe bill and the traceno robot moves · calls are billednot modelled: calibration, grip, optics
Simulated inputs, live policy output. Drawn from web/lib/sim (MuJoCo, rendered policy cameras, splat backdrop) · the live service for everything else

Read the full section →

Compatibility#

Your setup matches a served model when all of these hold:

Read the full section →

Glossary#

The product's vocabulary, generated from web/lib/vocab.ts. The same list as data: /reference/concepts/glossary.json.

The product's 44 words — chunk, token, lease, slot, held-out error, artefact, spread and the rest — are defined once, together, on the glossary. Every link on this site that names a term points straight at its row there, and the same list is data at /reference/concepts/glossary.json.

Say this, not that#

The words to avoid, from the same avoid[] lists in web/lib/vocab.ts that the drift guard reads.

The words we deliberately do not use for these things — and what to say instead — are listed with the definitions on the glossary.

Where to go next#

  • /docs — the reference: every route, field, error code and limit, with runnable examples.
  • /play — a simulated SO-101 driven by the live policies; costs usage credit like any call.
  • /models — one page per model: inputs, price, measured times, licences, availability.
  • /dashboard — your keys, sessions, spend and traces.
  • /reference/concepts/glossary.json — this vocabulary as data, for agents and writers.