services

Generate real content — 3D meshes, textures, audio — from a prompt, by spending credits. This is the whole surface for it: discover what you can make, start a generation, track it, and find what you've made. You never touch the underlying asset type or task plumbing.

When a build needs a recognizable thing — a treasure chest, a snowboard, a character, a sound — you generate it. You don't assemble it from boxes and spheres.

The loop

Discover what you can make: each service lists its operations, and each operation is self-describing: its inputs, the kind of asset it produces, and its credit cost. Check your credit balance if you want. Start a generation with a service and a prompt; this returns immediately with a handle and runs in the background, because a generation takes minutes and blocking would trip the execute time limit. When the run ends it posts a notice, generation finished naming its id and the job's asset (the spawnable asset path, which you can drop straight into a blocked-out slot) or generation failed naming its id and the error, and the notice reaches you on your next tool call; services.status reads a run's progress by its id meanwhile. A run files its output where your writes landed when you started it: one started in edit keeps its asset on source even when it finishes after you entered play, and one started inside your play session leaves it on the play shadow, where a play-exit discard takes it back; durable in the input states it outright. The notice and services.status both say where the output stands (durable, and the shadowed paths when the play shadow holds any of it). Alongside the live per-session job view, a durable outputs record survives restarts by reading the provenance stamped on each generated asset.

Refusals and caps

A generation the provider refuses ends failed, and the failure states why as data beside its error: reason (the platform's reading, such as quota_exhausted, throttled, content_policy or out_of_range), field (the input the refusal concerns, when it names one) and retryAfterSecs (how long the provider asked to be left). A refusal that waiting clears (throttled, overloaded, provider_fault, timed_out) is sent again after the wait it names, and ends the run when that wait is longer than a minute; one it does not clear (quota_exhausted, credential, and the reasons about the request itself) ends the run on the first answer. A refusal for a cap (the provider account out of quota, a throttle, the credits or your allocation spent) holds for the next generation of that service too: services.caps lists the caps in force with when each began and when it resets, so read it before starting generations, and while a cap that waiting does not clear holds, start no generation of that service and tell the person what it cannot make.

Describing your assets

describe is the one tool here that makes text, not content. It finds the assets in your world that lack the description their type asks for (for the built-in types that ask, a README, or the about.yaml texts of a type) and fills them in: { mode = "find" } lists what is missing and what filling it costs, { mode = "all" } fills it, and { assets = { ... } } fills the assets you name. A call costs 1 credit and covers many assets, and find reports the number of calls before anything is spent. What it writes is an ordinary file in the asset, there for you to edit.