
Connects Claude directly to Thunder Compute's GPU cloud platform through their API. You get programmatic control over the full instance lifecycle: spin up GPU instances with specific specs, manage snapshots, configure SSH keys, check billing, and monitor status. Basically lets Claude handle infrastructure operations you'd normally do through their tnr CLI or web dashboard. Reach for this when you're prototyping ML workloads and want Claude to provision compute resources, manage running instances, or automate deployment workflows without context switching. Uses streamable HTTP transport and hits their production API at api.thundercompute.com.
tnr is the official command-line interface for Thunder Compute, a high-performance cloud GPU platform built for AI/ML prototyping and experimentation.
Using a proprietary orchestration engine, Thunder Compute delivers fast provisioning, low-latency execution, and low-cost GPU compute designed for developer workflows.
The tnr CLI supports:
Install tnr using one of the supported methods below. You may also download installers and binaries directly from the Latest Release page.
Download the .pkg installer for your platform from the Latest Release page (tnr_*_darwin_arm64.pkg for Apple Silicon, tnr_*_darwin_amd64.pkg for Intel).
Homebrew:
brew tap Thunder-Compute/tnr
brew install tnr
Download .tar.gz, .deb, .rpm, or .apk packages from the Latest Release page.
Install script (recommended):
curl -fsSL https://raw.githubusercontent.com/Thunder-Compute/thunder-cli/main/scripts/install.sh | bash
Download the .msi installer for your platform from the Latest Release page.
Scoop:
scoop bucket add tnr https://github.com/Thunder-Compute/scoop-bucket
scoop install tnr
Winget:
winget install Thunder.tnr
git clone https://github.com/Thunder-Compute/thunder-cli.git
cd thunder-cli
go build -o tnr
./tnr
tnr login # Authenticate with Thunder Compute
tnr create # Create a GPU instance
tnr status # View instance status
tnr connect 0 # Connect to your instance
# File transfers
tnr scp myfile.py 0:/home/ubuntu/
tnr scp 0:/home/ubuntu/results.txt ./
tnr delete 0 # Delete instance
tnr login opens a browser and returns to a loopback callback on
127.0.0.1. On a headless or remote machine where that callback cannot be
reached, create a named API token in Console Settings and run
tnr login --token <named_api_token> instead.
For a local API, run make cli-local ARGS="login", make cli-local ARGS="status", or make cli-local ARGS="logout --revoke" from the Thundernetes repository root. This builds cli/dist/tnr-local and targets http://localhost:8443, storing credentials in cli/dist/local-home separately from staging and production. Start your local API first; the runner does not start it. Browser login also needs the API's OAuth configuration and a running authorization page, normally the local Console at http://localhost:3000. For arguments requiring shell quoting, use bash cli/scripts/tnr-local.sh <arguments>.
From the Thundernetes repository root, run make cli-staging ARGS="login", make cli-staging ARGS="status", or make cli-staging ARGS="logout --revoke". Each invocation builds the current branch through Bazel and runs cli/dist/tnr-staging against the URL supplied through TNR_STAGING_API_URL. The monorepo Makefile supplies the default; the CLI scripts contain no staging endpoint. Credentials are saved separately in cli/dist/staging-home, an inherited TNR_API_TOKEN is ignored, and self-updates are disabled. These generated files are gitignored. For arguments requiring shell quoting, export TNR_STAGING_API_URL and run bash cli/scripts/tnr-staging.sh <arguments> directly.
Browser login requires the staging API's /v1/auth/cli/oauth-config endpoint and staging Connected App configuration. A 404 indicates the route is unavailable; a 503 can indicate missing OAuth configuration. Local builds do not deploy or configure the API.
This project is licensed under the MIT License. See LICENSE for details.