---
title: "wendy device info"
description: "Shows organization, agent version, OS, architecture, GPU, NPU, and hardware info for the target device."
---

# `wendy device info`

Shows organization, agent version, OS, architecture, GPU, NPU, and hardware info for the target device.

## Usage

```sh
wendy device info [flags]
```

## Description

`wendy device info` queries the connected device's agent and prints its version, operating system, CPU architecture, CPU core count, total RAM, GPU and NPU presence, and other hardware details. Use this command anywhere device metadata is needed — in scripts, CI pipelines, or interactively.

The output format follows the standard `--json` / human-readable convention shared across all device commands.

### Organization output

`Organization:` shows the device's enrolled organization name and ID, or just the ID when the name cannot be resolved. The name lookup uses credentials for the device's cloud and organization, with a cached name as an offline fallback. The ID comes from the device's enrollment, regardless of your default organization.

With `--json`, `organization` contains a string `id` and an optional `name`:

```json
{"organization": {"id": "42", "name": "Robotics"}}
```

The ID can be a tenant UUID or a legacy numeric ID encoded as a string. An unenrolled device shows `Organization: Not enrolled` and `"organization": null`. If enrollment information is unavailable, including on unsupported agents or Bluetooth connections, the field is omitted.

### CPU and memory output

Two headline hardware specs are included when the agent reports them. Both are omitted from the human-readable output and the JSON map when the agent cannot read them (older agents or non-Linux hosts), so treat them as optional.

| Field (JSON) | Human-readable label | Description |
|---|---|---|
| `cpuCount` | `CPU Cores:` | Number of online logical CPU cores. |
| `memTotalBytes` | `Memory:` | Total physical RAM in bytes; human-readable output shows a formatted size (e.g. `131.9 GB`). |

For **live** CPU and memory utilization, use [`wendy device top`](top.md).

### Power mode output

On NVIDIA Jetson devices the agent reports the current power mode (nvpmodel), shown as `Power Mode: MODE_30W (2)`. With `--json`, `powerMode` holds the numeric `id` and the `name`:

```json
{"powerMode": {"id": 2, "name": "MODE_30W"}}
```

The field is omitted on devices that are not a Jetson, when the mode cannot be read, and on agents that predate it. To see every available mode or switch, use [`wendy device power-mode`](power-mode.md).

### Storage output fields

When the agent can identify the filesystem that holds `/var/lib/containerd`, it is reported alongside the mounted partitions. The field is omitted from the JSON map when inspection fails or the agent predates it.

| Field (JSON) | Human-readable label | Description |
|---|---|---|
| `containerStorage` | `(container storage)` suffix on the matching partition row | The mounted filesystem backing `/var/lib/containerd`: `mountpoint`, `filesystem`, `device`, `usedBytes`, and `totalBytes`. Image pulls and container layers consume this filesystem, so its usage feeds the disk-usage warning. |

### GPU output fields

On GPU-capable devices, the following GPU fields are included. Each is omitted from both the human-readable output and the JSON map when the agent does not report it (e.g. non-GPU devices or older agents), so consumers should treat every field as optional.

| Field (JSON) | Human-readable label | Description |
|---|---|---|
| `gpuVendor` | `GPU:` | GPU vendor (e.g. `nvidia`, `qualcomm`); shown as `unknown` in human-readable output when a GPU is present but the vendor is unreported. |
| `jetpackVersion` | `JetPack:` | JetPack/L4T version string (Jetson only). |
| `cudaVersion` | `CUDA:` | CUDA toolkit version (e.g. `12.6`). |
| `gpuArch` | `GPU Arch:` | GPU architecture identifier. Format is vendor-specific (e.g. `sm_87` for NVIDIA, `a623` for a Qualcomm Adreno). On a Jetson, which ships no `nvidia-smi`, it comes from the SoC in the device tree: `sm_110` on Thor, `sm_87` on Orin, `sm_72` on Xavier. |
| `gpuCapabilities[]` | `GPU Compute:` | One entry per detected GPU: `vendor`, `path` (the device node that identified it, e.g. `/dev/dri/card0`), and `computeBackends` (`cuda`, `rocm`, or `metal`). A single GPU prints its backends; several print each one with its vendor and path. The line is omitted when no GPU reports a backend, and no entries at all means an older agent. An on-SoC neural accelerator is not a GPU backend — see `npuBackends`. |

### NPU output fields

On devices with an on-SoC neural accelerator the agent can reach, the following fields are included.

| Field (JSON) | Human-readable label | Description |
|---|---|---|
| `hasNpu` | — | Whether the device has a reachable NPU. Always present; `false` elsewhere. |
| `npuVendor` | `NPU:` | NPU vendor (e.g. `qualcomm`); shown as `unknown` in human-readable output when an NPU is present but the vendor is unreported. |
| `npuBackends[]` | `NPU:` | Runtimes an app can use on the NPU (e.g. `qnn` on a Qualcomm Hexagon). Rendered in parentheses after the vendor, as `qualcomm (qnn)`. Empty when the vendor's runtime is unrecognized, and on agents predating this field. |

Detection requires a non-secure FastRPC node: the signed-PD nodes are root-only, so a board exposing only those reports no NPU. The vendor comes from the DSP's device-tree `compatible`, the only vendor signal an on-SoC accelerator has.

FastRPC is the DSP's transport, so it is evidence for the NPU alone. A Dragonwing reports `NPU: qualcomm (qnn)` and no GPU compute backend for the Adreno beside it.

`wendy device info` reports static GPU *metadata* (vendor, architecture, toolkit versions). For **live** GPU utilization, memory, temperature, and power draw, use [`wendy device top`](top.md).

### Network output

The output includes the device's network interfaces and their routable IP addresses under a `Network:` block (human-readable) or a `networkInterfaces` array (JSON). This is the address to use to reach an app running on the device — the `.local` hostname does not always resolve on every network.

Loopback, down, and container/virtual bridge interfaces are omitted, as are link-local addresses. The section is absent entirely when the agent cannot enumerate interfaces (e.g. older agents).

| Field (JSON) | Human-readable label | Description |
|---|---|---|
| `networkInterfaces[].name` | (row label) | Interface name (e.g. `eth0`, `wlan0`). |
| `networkInterfaces[].ipAddresses` | (row value) | Routable IPv4/IPv6 addresses assigned to the interface. |

### OS Update output

When an update outcome has been recorded, `wendy device info` prints a compact `OS Update:` block:

```
OS Update:
  Last update: committed (0.16.0 → 0.17.0)
```

This reads the saved outcome. For live A/B slot state, pending updates, and engine diagnostics, run [`wendy os update-status`](../os/update.md).

The block is omitted when no update record exists, the agent does not support update status, or the optional status request fails or times out.

When the last update outcome is not `committed`, a hint is printed:

```
  Details: wendy os update-status
```

The outcome is colour-coded: `committed` is green, `rolled back` is amber, and failure outcomes are red.

### JSON: `osUpdate` field

When a recorded update outcome is available, `--json` includes an `osUpdate` object. It is omitted when no outcome is available.

```json
{
  "osUpdate": {
    "lastUpdate": {
      "outcome": "committed",
      "createdAtUnix": 1750000000,
      "oldOsVersion": "0.16.0",
      "newOsVersion": "0.17.0"
    }
  }
}
```

| Field | Description |
|---|---|
| `osUpdate.lastUpdate.outcome` | One of `committed`, `rolled back`, `rollback failed`, `commit failed`, `unknown`. |
| `osUpdate.lastUpdate.createdAtUnix` | Unix timestamp of the recorded update outcome. |
| `osUpdate.lastUpdate.oldOsVersion` / `newOsVersion` | OS versions before and after the update (omitted when not recorded). |
| `osUpdate.lastUpdate.note` | Failure reason from the updater, if any (omitted when empty). |

For the live engine snapshot, use `wendy os update-status --json` and read its `engineStatus` field. Basic device info does not request this snapshot.

## Flags

| Flag | Default | Description |
|------|---------|-------------|
| `--check-updates` | `false` | Check whether a newer agent release is available and include the result in the output. |
| `--prerelease` | `false` | Include pre-release (nightly) versions when checking for updates. |

## Examples

Print device info in human-readable form:

```sh
wendy device info --device my-device.local
```

Print device info as JSON (useful in scripts):

```sh
wendy device info --device my-device.local --json
```

Extract specific fields with `jq`:

```sh
wendy device info --device my-device.local --json | jq '{osVersion, agentVersion: .version, deviceType, cpuCount, memTotalBytes}'
```

## Deprecated alias

`wendy device version` is a deprecated alias for this command. It remains functional for backward compatibility but is hidden from help output. When invoked in non-JSON mode it prints a deprecation warning to stderr:

```
Warning: 'wendy device version' is deprecated; use 'wendy device info' instead.
```

No warning is emitted when `--json` is passed, so existing machine-readable scripts that use `wendy device version --json` continue to work without noise on stderr.

Migrate any usage of `wendy device version` to `wendy device info`.

## Related

- [`wendy os update-status`](../os/update.md) — full OS update record including service-level healthcheck details and the live engine snapshot
- [`wendy os update`](../os/update.md) — apply a WendyOS OTA update