InspireSkill turns a Chinese research compute platform into one CLI for agents

The problem: a web console between the agent and the GPU

The project describes the origin of its problem in terms of the students it was built for. The Inspire platform, hosted at qz.sii.edu.cn, was the slowest link in a research workflow: every request for resources, every new notebook, every new training job and every code sync meant repeated clicking through a graphical interface, and features further along such as SSH were out of reach. InspireSkill was created to flatten that interface into a command line and to package the result as a CLI plus a skill, so that an agent can drive the platform directly. The stated ambition is that the system should become the single entry point for agents doing research work, replacing the browser workflow with a local one that lives in the same repository and the same conversation as the rest of the developer's tools. The project is careful to say that this was not a simple re-expression of the platform's web APIs as commands, and that the hard part was designing higher level features that sit above the platform's semantics, finding the platform's less obvious API endpoints, and maintaining a documentation system that an agent can read and that covers the whole platform.

Three parts: the CLI, the skill and the SDK

The architecture is three components that share one distribution. The first is the inspire CLI, which turns resource queries, notebook connections, GPU job, HPC and Ray submissions, serving deployments, TensorBoard curve reading, asset management and cleanup into chainable commands, with resources addressed by readable name and account alias and with JSON output for scripts that need to consume the result. The second is SKILL.md and the references/ directory, which tell the agent when to pick a class of workload, how to choose scheduling conditions from the live catalogue, and how to observe a job and verify its artefacts. The installer places these into the directories of the supported harnesses, so the user does not have to re-explain platform semantics in every conversation. The third is a Python SDK that ships in the same package as the CLI and offers both synchronous and asynchronous clients, so research scripts, services and agent runtimes can call the platform's capabilities directly. The intended loop is that you give the agent a goal and it queries available workspaces, quotas and images, prepares code and data on shared storage, submits the right kind of job, follows it through events, logs, metrics and instances, and then cleans up what is no longer needed.

Installing on macOS and Linux

Installation supports macOS, Linux and Windows, and the CI covers all three. On macOS and Linux you need bash, curl and tar, Python 3.10 or later, and uv, which is recommended, or pipx. The documented sequence starts with the uv installer.

curl -LsSf https://astral.sh/uv/install.sh | sh
curl -fsSL https://raw.githubusercontent.com/realZillionX/InspireSkill/main/scripts/install.sh | bash

The installer pulls the CLI from PyPI and places the skill into whichever harnesses it detects. You can name the targets explicitly with bash -s -- --harness codex,claude, and there are two switches worth knowing. The --no-cli option installs only the skill, and the --no-schedule option skips the daily version check on macOS. The last line of the documentation for this step is the check that matters, and it is to run inspire --version and inspire --help after installation to confirm the entry point works. The supported harness list is long, covering Codex, Claude Code, Cursor, OpenCode, ZCode, Kimi Code, Kimi Work, Qoder, Qoder Work, Antigravity and OpenClaw, and the licence is MIT.

Accounts, aliases and the init step

Account configuration is independent of any repository, and the name you use is a local alias. The account add command asks for the platform login name, password, address and proxy, and the login name is whatever the platform accepts, a phone number, a student number or an email. The configuration is kept at ~/.inspire/accounts/<name>/config.toml, and if you would rather not store the password there you can supply it through the INSPIRE_PASSWORD environment variable instead.

inspire account add <name>
inspire account check
inspire init

The init command validates and normalises the account configuration without binding it to a repository, project or resource, and the resource availability query above is the first thing to run after it, because it tells you what you can actually schedule. When you create a workload you choose the workspace, project, compute group, quota, image and remote path explicitly. Multiple accounts are supported, with account use to set the default, account current to show it and account rename to change the local alias. Every command also takes an --account option for a one-off selection, and that does not change the default or clear the per-account session, SSH connections and resource cache.

Notebook lifecycle, from the command list

The notebook command group is the widest part of the tool, and the documentation lists the subcommands explicitly: create, batch, list, status, start, stop, delete, ssh, ssh-config, ssh-proxy, connection, exec, shell, scp, install-deps, proxy-url, path, quota, profile, metrics, events, lifecycle, save-image and cancel-save-image. Two of these carry real weight. The proxy-url command with a port gives you the external address of a service deployed inside the container, so you can request it directly, and ssh-proxy is the raw stream forwarding used for an OpenSSH ProxyCommand, which the generated ssh-config points at. The image lifecycle is handled by save-image, which turns a working environment into a reusable image, and the documentation is careful about how it behaves. It reports the platform's estimated snapshot size first, with a --dry-run flag that only estimates, the notebook cannot be operated while the save is running, and cancel-save-image takes the notebook back even after it has entered the waiting state. The default is an incremental layer on top of the starting image, so repeated iteration accumulates layers, while --flatten merges the result into a single layer, which is what you want when freezing a base image.

Restricted notebooks, SSH and the Windows specifics

Not all notebooks are equal, and the documentation splits them. A notebook on a standard GPU such as an H100 or an H200 can use OpenSSH, SCP and SSH config, while a restricted notebook uses a JupyterTerminal execution path instead, with file transfer bounded by shared paths under /inspire/... and, where a notebook supports SSH, the same commands available through it. The Windows notes are unusually concrete and are worth reading before you set anything up. Get-Command ssh -All tells you which ssh.exe is actually in use, and the system OpenSSH and the one shipped with Git for Windows handle ProxyCommand differently. PowerShell 5.1 writes files with >> in UTF-16LE, which OpenSSH cannot read, so appending SSH config has to go through Out-File with an explicit utf8 encoding, while PowerShell 7 and later can use >> directly. Windows OpenSSH also refuses a private key with permissions that are too open, which shows up as an UNPROTECTED PRIVATE KEY FILE error and is fixed by tightening the ACLs on the .ssh directory. rsync is not required, since file transfer can go through the notebook scp command.

Updates, uninstall and what is left behind

The maintenance commands are grouped so you can do a partial operation.

The commands are `inspire update`, `inspire update --check`, `inspire update --cli-only`, `inspire update --skill-only` and `inspire uninstall`.

The update command recognises whether uv tool or pipx installed the CLI, and when it meets leftover local state from an older version it lists what it would remove and asks before removing it. The uninstall command behaves the same way, listing the targets and confirming first. Two things are deliberately kept by default: the account configuration and the shared Playwright browser cache, which are removed instead by the --purge and --purge-runtime variants, and a user maintained INSPIRE.md is left alone. If the CLI cannot run at all, the install script has an --uninstall fallback. That last detail matters for a project whose whole purpose is to be a stable entry point, because a CLI that cannot start is the one situation where you most need a way out.

Why not just use the platform's own harness

The documentation argues against QWorks, the platform's own downloadable harness, on the grounds that it locks the user into a single agent entry point. The comparison table makes the argument in four dimensions. On the agent entry point, QWorks ships its own harness while InspireSkill installs into Codex, Claude Code, Cursor, OpenCode and the other supported harnesses and can also be used as a plain CLI. On models and plans, the other client's subscription cannot be carried across directly and external models are connected by API, whereas with InspireSkill you keep the model configuration and plan you already have and InspireSkill does not take over model billing. On platform operations, QWorks does its work inside the QWorks session and interface, while InspireSkill covers resource discovery, notebooks, GPU jobs, HPC, Ray, serving, TensorBoard and asset management from the local command line. On workflow, QWorks centres on the QWorks session while the local repository, Git, other tools and the platform commands sit in one workflow with scriptable commands and JSON output for automation. The release history shows steady work, with v7.1.11, v7.1.12 and v7.1.13 published in October 2026, and the last push to the repository on 2026-10-16.

Editorial conclusion

Adopt InspireSkill if you do research on the Inspire platform and already work inside an agent harness, because the whole point of the project is that you do not have to switch tools to reach the compute. Do not adopt it if your compute is on another platform, since every command and every reference is written against Inspire's own semantics, and do not adopt it expecting a general pattern for agent tooling, since the hard part is the platform mapping rather than the CLI. Verify two things before you commit: that the harness you use is one of the supported ones the installer detects, and that your account configuration is complete, since the commands need a platform login stored locally before anything else works. The practical first step is to install the CLI and the skill on macOS or Linux, add an account, and run inspire init to validate the configuration before you try to submit any workload.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. realZillionX/InspireSkill on GitHub
5. Releases