Compute services and limits

What works today

There are 50 native capabilities defined. None of them is open to customer traffic yet, and GET /v1/capabilities returns 503 UNAVAILABLE, so there is no live discovery endpoint to enumerate them from.

Why none of them routes yet

Three conditions must all hold before a capability accepts work. Today no capability satisfies all three, and they are independent — meeting one does not advance the others. We would rather set them out than let the catalogue's existence imply readiness:

1. Its definition must match the contract it declares. Each capability names the contract version it is written against, and must validate against exactly that. None currently does.
2. It must be admitted. All 50 declare an admission state of owner_gated. Compute routes a capability only when it is admitted, and opening one is a deliberate decision rather than a side effect of the service running.
3. Its signed release material must be published. A capability today has one signed artifact — its schema. The further release material a routable capability needs has not been published for any capability in the catalogue.

So the catalogue describes real, defined work, and none of it is reachable yet. This page describes how capabilities are shaped and what they declare, so you can read one when they open.

What a capability declares

A capability is not just a name. It carries the bounds your request must fit inside, and those bounds differ per capability. The ones that constrain a submission are:

• max_files — how many input files one job may reference.
• max_ciphertext_bytes — the largest encrypted input it accepts.
• max_input_tokens and max_output_tokens — the token bounds for the work.
• shared_data_profiles — which data profiles it will accept.
• engine_order — which execution engines it can run on.
• public_operations — which operations it exposes.

Your quote and your job must both sit inside these. Exceeding one is a CONTEXT_OVERFLOW or INVALID_REQUEST refusal at submission, not a truncation at execution.

The limits are not uniform

A common integration mistake is assuming one ceiling across the catalogue. Measured across all 50 definitions today:

So 16 MiB is the largest input any current capability accepts, not a universal allowance — and a third of the catalogue is below it. Read the specific capability rather than coding to the maximum.

If your input is larger than the capability accepts, that is a real constraint today and not something a retry or a different data profile will get around. See Input files for how this interacts with media.

How work is billed

Each capability declares its own billing unit, so cost is expressed in whatever that capability naturally counts. Across the 50 definitions the units in use are accepted_native_unit, accepted_output_token, accepted_page, accepted_test_unit, and accepted_build_unit.

You never have to infer the cost from the unit. A quote states the maximum charge explicitly before you commit, and a job cannot exceed the quote it references.

Operations

Every capability exposes a set of public_operations, and your quote names exactly one. Today all 50 declare a single operation, verify. The operation vocabulary is wider than what the catalogue currently uses, which means work that would need a different operation cannot be expressed yet — see Batches and chains for where that limit currently bites.

Related

• Submit work — the request contract
• Input files — how a file reaches a capability
• Errors — what a limit breach returns