Service capabilities and effective limits
GET /info
Reports the limits every task runs under, the sandbox profiles a
request may choose, whether the step cache is enabled, and the
language toolchains installed in this image (from FABER_TOOLCHAINS).
Authorizations
Section titled “Authorizations ”Responses
Section titled “ Responses ”Service capabilities
object
Kernel architecture, e.g. x86_64 or aarch64
object
Versioned seccomp policy. v2 profiles are allowlists (an unlisted
syscall fails with ENOSYS); v1 profiles are denylists. compile_*
tasks may create processes and namespace-scoped sockets (compilers,
interpreters, build tools); native_* tasks may do neither (running a
compiled submission). A denied syscall kills the task with SIGSYS
and outcome policy_violation.
Limits applied to every task; requests cannot raise them.
object
Cgroup cpu.max value, "<quota> <period>" in microseconds
object
object
Catalog id, e.g. python, node, rust
Missing or wrong API key (unauthorized)
object
Human-readable message
Stable machine-readable error code. Clients should treat unknown codes as internal_error.
Example
{ "error": "Missing or invalid API key", "code": "unauthorized"}Headers
Section titled “Headers ”The API key has used up its requests (rate_limited). Sent only when
the service enables per-key rate limiting (RATE_LIMIT_PER_MINUTE).
Retry after the Retry-After header.
object
Human-readable message
Stable machine-readable error code. Clients should treat unknown codes as internal_error.
Example
{ "error": "Rate limit exceeded for this API key", "code": "rate_limited"}Headers
Section titled “Headers ”Seconds until the key may make another request