Transfers

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 to a device without it passing through your machine.

There are two subcommands.

transfers get

clika-rt 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-rt 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-rt transfers get 1f0a2b3c-4d5e-6f70-8192-a3b4c5d6e7f8 --wait=10m \
  && clika-rt jobs create --body '{"job_definition_id":"llm-latency","device_id":"jetson-01"}'

transfers delete

clika-rt 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-rt 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.

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 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-rt transfers

transfers has 2 subcommands.

clika-rt transfers delete

Cancel a transfer

clika-rt 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-rt transfers get

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

clika-rt transfers get <id> [flags]

Positional arguments: required <id>.

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

Related

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