---
title: Transfers
sidebar_label: transfers
description: "clika-cli transfers: follow a file transfer between the platform and a device to completion, and cancel one that is no longer wanted."
---

Moving a file to or from a device is not instant, and it does not happen inside the command that started it. When the platform pushes an artifact to a device, or pulls a file back, it creates a **transfer**: a record with a state, a byte count, a rate and, if it went wrong, an error. The `transfers` group is how you follow one.

You get a transfer id from whichever command started the move, for example `devices files-push-from-library`, which sends a stored [artifact](artifacts.md) to a device without it passing through your machine.

There are two subcommands.

## `transfers get`

```
clika-cli transfers get <id> [flags]
```

Reads a transfer's status: its state, how many bytes have moved, the current rate, and the error if it failed.

| Flag | Type | Default | Meaning |
| --- | --- | --- | --- |
| `--wait` | string | not set | Block until the transfer reaches a terminal state, printing each state change as it happens. A bare `--wait` waits indefinitely; a value bounds it, in seconds (`--wait=600`) or as a duration (`--wait=10m`). |

Three behaviours are worth knowing before you put this in a script:

- **It gates scripts.** With `--wait`, the command exits non-zero when the transfer ends `failed` or `canceled`, so `&&` does the right thing.
- **A bounded wait that expires still reports.** The latest status is printed and the exit code is non-zero, so a timeout is not silently indistinguishable from success.
- **An `unknown` state is waited on, not failed.** `unknown` means the platform temporarily lost track of the transfer, which is not the same as the transfer having gone wrong.

```
$ clika-cli transfers get 1f0a2b3c-4d5e-6f70-8192-a3b4c5d6e7f8
STATE       BYTES         RATE        UPDATED
running     318 MB/412 MB 22.4 MB/s   2s ago
```

Wait for it and only then start the run that needs the file:

```
clika-cli transfers get 1f0a2b3c-4d5e-6f70-8192-a3b4c5d6e7f8 --wait=10m \
  && clika-cli jobs create --body '{"job_definition_id":"llm-latency","device_id":"jetson-01"}'
```

## `transfers delete`

```
clika-cli transfers delete <id>
```

Cancels a transfer that is still in flight. The device stops receiving, and the transfer ends in the `canceled` state, which a concurrent `--wait` will see and exit non-zero on.

```
$ clika-cli transfers delete 1f0a2b3c-4d5e-6f70-8192-a3b4c5d6e7f8
canceled transfer 1f0a2b3c-4d5e-6f70-8192-a3b4c5d6e7f8
```

## Which command creates a transfer

| Command | What moves |
| --- | --- |
| `devices files-push-from-library <name-or-id> --body '<json>'` | A stored artifact goes from the platform to the device. |
| `devices services-update <name-or-id> <svc_id> --body '<json>'` | The artifacts a running service needs are refreshed on the device. |
| A job dispatch whose definition declares `artifacts` | Each declared artifact is pushed before the job starts. |

`devices push` and `devices files-fetch` are different. They stream through your own machine and finish inside the command, so they produce no transfer record to follow.

<!-- BEGIN GENERATED COMMAND REFERENCE (NOTES/gen-cli-reference.py) -->

## Full command reference

Every command below is generated from the deployment's own API description, so
one subcommand is exactly one platform operation. Each entry names the method,
the endpoint and the [MCP](mcp.md) tool name, so the same operation is
identifiable whichever surface you drive it from. Path parameters are positional
arguments, query parameters are flags, and a request body is `--body` or
`--body-file`. The hand-written commands, the ones that stream, propagate an
exit code, or hand your terminal to `ssh`, carry no operation line.

The prose above covers the commands most people reach for. This section is the
complete surface, for when you need the flag you have not used before.

### `clika-cli transfers`

`transfers` has 2 subcommands.

#### `clika-cli transfers delete`

Cancel a transfer

```
clika-cli transfers delete <id> [flags]
```

Positional arguments: required `<id>`.

| Flag | Type | Default | Meaning |
| --- | --- | --- | --- |
| `--raw` | bool | `false` | print raw response without pretty-printing |

Endpoint: `DELETE /api/transfers/{id}`. MCP tool name: `delete_transfers_id`.

#### `clika-cli transfers get`

Reads a device file transfer's status (state, bytes, rate, error).

```
clika-cli transfers get <id> [flags]
```

Positional arguments: required `<id>`.

Endpoint: `GET /api/transfers/{id}`. MCP tool name: `get_transfers_id`.

<!-- END GENERATED COMMAND REFERENCE -->

## Related

- [Artifacts and models](artifacts.md): what is being moved, and how it got into the library.
- [Devices](devices.md): the file commands on a device, including the ones that do not create a transfer.
- [job definitions](job-definitions.md): declaring the artifacts a run needs, which is what triggers most transfers.
