> ## Documentation Index > Fetch the complete documentation index at: https://docs.aireserve.com/llms.txt > Use this file to discover all available pages before exploring further. # Connect and manage > Inspect state, retrieve connection details, stream logs, and control the instance lifecycle. Instance mutations are asynchronous. Add `--wait` when you want the CLI to poll the returned operation until it succeeds, fails, or is cancelled. ## Inspect your instances ```bash theme={"dark"} aireserve gpu instances list aireserve gpu instances get ``` `get` shows normalized state, accelerator, region, price, storage, and lifecycle capabilities. It intentionally omits provider resource IDs and placement IDs. Use capability flags instead of assuming every future backend supports the same actions. ## Connect over SSH or HTTP ```bash theme={"dark"} aireserve gpu instances connections ``` Connections are available after the instance is running. The response contains a structured SSH command when SSH was configured and public HTTP URLs for any HTTP ports requested at launch. * AI Reserve stores public SSH keys, never private keys. * Public HTTP applications must implement their own authentication. * The normalized connection response does not expose raw provider connection objects. ## Stream workload logs The normalized REST API exposes a transient server-sent event stream: ```bash theme={"dark"} aireserve gpu instances logs --follow ``` or directly: ```bash theme={"dark"} curl -N "https://api.aireserve.com/v1/gpu/instances//logs?tail=200" \ -H "Authorization: Bearer $AIRESERVE_API_KEY" \ -H "Accept: text/event-stream" ``` Each event contains a timestamp, source, and line. AI Reserve relays active workload output and does not maintain a workload-log archive. A single stream response lasts at most 270 seconds. When that window ends the relay sends a standard SSE `retry:` hint and closes the connection cleanly; the pod and its logs are unaffected. Reconnect with the `Last-Event-ID` header set to the last `id:` you received and the stream resumes from that point. The `aireserve gpu instances logs --follow` CLI mode implements this reconnect contract for you, as does the Python SDK's `instances.logs(...)` iterator (aireserve-sdk 0.8.1 and later). The TypeScript SDK does not yet expose a GPU logs helper, so there use the REST stream and implement the reconnect loop in your client. An `event: error` frame is sent only when the provider stream itself fails. Any client must preserve `Last-Event-ID`; do not treat a normal 270-second close as workload failure. ## Stop and start ```bash theme={"dark"} aireserve gpu instances stop --wait aireserve gpu instances start --wait ``` Stopping an instance: * releases GPU compute; * stops compute accrual after the stop is confirmed; * destroys the ephemeral root disk on the current backend; * keeps an attached persistent volume and its storage billing; * does not reserve GPU capacity for the next start. A later start can fail when compatible capacity is unavailable. Check the instance's `capabilities.start`, `capabilities.stop`, and `capabilities.stopPreservesRootDisk` fields before automating lifecycle actions. ## Recover an instance that stopped on its own An instance that was running and then left `running` without a stop from you (the container exited, the provider reported an error) stays where the provider put it. By default AI Reserve leaves it for you: `status` reads `stopped` or `failed`, `desiredState` stays `running`, and nothing is billed for a released accelerator. Opt into automatic recovery per instance: ```bash theme={"dark"} aireserve gpu instances recovery --mode restart --max-attempts 3 --cooldown-minutes 5 ``` With `mode: restart`, the next health pass restarts the container in place when the machine is still allocated, or starts the instance again on the same hardware when it was released, up to `maxAttempts` times per unhealthy episode and no more often than every `cooldownMinutes`. Recovery never relaunches on different hardware, never re-quotes, and never changes the locked rate. The episode counter resets once the instance is observed running again. Read where it stands on the instance: ```json theme={"dark"} "recovery": { "policy": { "mode": "restart", "maxAttempts": 3, "cooldownMinutes": 5 }, "attempts": 1, "maxAttempts": 3, "lastAttemptAt": "2026-10-14T18:40:00.000Z", "lastOutcome": "recovering" } ``` | `lastOutcome` | Meaning | | - | - | | `recovering` | An attempt is in flight; the instance is starting | | `recovered` | The last attempt brought it back; the counter resets on the next healthy pass | | `failed` | The last attempt did not bring it back; another follows after the cooldown | | `exhausted` | Every attempt was spent; `lastError` reads `recovery_exhausted` and the instance waits | Make one attempt now, regardless of the cooldown and the cap: ```bash theme={"dark"} aireserve gpu instances recover --wait ``` It counts toward the episode and answers `409 operation_conflict` when the instance is running, was never admitted, or another operation is in flight. Turn automatic recovery off with `--mode none`. ## Terminate ```bash theme={"dark"} aireserve gpu instances terminate --yes --wait ``` Termination is irreversible. It releases the accelerator and destroys the root disk. An attached persistent volume survives, remains attached in the resource model until termination completes, and continues billing until you delete it. ```bash theme={"dark"} aireserve gpu volumes delete --yes --wait ``` ## Resume after a process restart Save the operation ID when your process may exit before a mutation completes. [Operations, pricing, and errors](/gpu-infrastructure/operations#wait-for-completion) shows how to retrieve and resume it. Resource and action labels currently retain some legacy `pod` terminology; treat the operation ID and status as the stable integration points. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.