Get a pod's container log tail
Returns the tail of a pod's container output (startup, CUDA errors, a crash's last lines), capped to a bounded size, or found false while it starts.
Required permission
Requires the compute.read permission. See Permissions for the roles and API key permissions that include it.
Command line
The orl CLI wraps this endpoint:
orl pods log get <pod-id>apiKeyAuthorizationBearer <token>OpenRelay API key. Send it as Authorization: Bearer or_… (legacy vl_… keys still work).
podId*stringOK
application/json- response
A guest's console text, or a soft "not ready yet" status: a transient state (no allocation yet, logs temporarily unavailable) answers 200 with found false and a message, so a polling UI renders a state instead of an error toast; only ownership/existence failures are 404. Output is capped to a bounded tail (the same cap pods and VMs share), not the whole console.
found*booleancontent?stringThe console's tail, when found is true.
message?stringPresent when found is false (or on other soft states); human-readable.
curl -X GET 'https://api.openrelay.inc/api/nomad/pods/string/logs'{ "found": true, "content": "string", "message": "string"}Live pod GPU capacity and on-demand rates GET
Returns, per GPU model, the GPU units a pod create can claim right now, the largest single pod that fits, and the server-computed on-demand rate per GPU-hour. What a pod create can actually claim right now, per GPU model: free native (device-request) GPU units on online, non-delisted nodes a pod can be sized on (the exact filter admission uses), plus the SERVER-computed on-demand hourly rate. Only models with pod units and a price are returned; a create flow should offer exactly these and render these rates verbatim rather than re-deriving prices from the catalog.
Overview
Managed Kubernetes: clusters whose control plane we run, with whole GPU or CPU hosts as nodes. Create clusters, scale node pools, and get kubeconfigs. Managed Kubernetes is in limited availability and is enabled per organization; without it every operation answers 409 FEATURE_DISABLED. Every operation acts in the caller's own organization: the API key's, or the session's X-Org-Id. The server checks every request against the parameters and request bodies documented here and answers 400 BAD_REQUEST naming the violation, so each constraint is enforced as written. A 409 INVALID_CLUSTER_STATE names the cluster status that blocks the operation.