akt-cli

# Operate Akash with akt `akt` is the unified Akash user CLI. It manages contexts and keys, queries the chain, signs transactions, deploys workloads, accesses provider gateways, and integrates with Akash Console. Blockchain validators and provider infrastructure run through their own node software. This skill needs an installed `akt` binary and shell access. Install the skill from the same release as the binary; repository copies track their checkout. Use the installed version's help when examples differ from available commands. There is no need to read the akt source repository to operate the CLI. ## Discover the installed CLI ```bash akt version --long -o json akt --help ``` Inspect the relevant command's `--help` before choosing arguments. Workflow definitions can be overridden per context, so discover their help with the same `--context` you intend to use. Bare `akt` prints help; `akt monitor` is an interactive dashboard. Use one-shot queries for agent inspection. ## Establish identity and capabilities A context selects a network, keyring, default account, Console credentials, local deployment store, and action log. Context selection is `--context`, then `AKT_CONTEXT`, then the configured current context. Use per-invocation `--context` when working on a named environment. ```bash akt context list -o json akt context show --context example -o json ``` Replace `example` with the user's intended context. Check its network, `auth_method`, account, and `capabilities` before acting. A configured RPC enables chain commands but does not prove that a funded signing key exists. Unavailable commands explain which configuration is missing. Two execution paths can coexist in one context: - `keyring`: the user holds the key and akt signs chain transactions. - `console-api`: Console signs using its managed wallet and funds deployments from account credits. The context preference chooses the path for shared `deploy`, `update`, and `close` workflows. Explicit `akt tx` commands always use local signing. Explicit `akt console` commands use Console. Read [setup](references/setup.md) when configuration, credentials, installation, or MCP setup is needed. ## Choose the operation and identifiers Prefer `akt deploy`, `akt update`, and `akt close` for complete deployment lifecycle work. They select the configured execution path and coordinate the underlying steps. Use lower-level commands when the task calls for an individual operation or recovery step. SDL is the YAML description of services, resources, placement, and pricing. The deployment sequence number, `dseq`, identifies a deployment within its owner's account. Keep the context and owner with every captured dseq. Orders and leases add group/order sequence numbers and a provider address. Primary values are positional. Deployment queries accept identifiers such as `12345` or `<full-owner-address>/12345`, with an omitted owner resolved from the context. Query filters can take a positional state such as `active`. Use command help for the exact hierarchy; familiar `--owner`, `--dseq`, `--state`, and service flags are disabled on some commands. Other commands still expose those flags. Preserve complete addresses when reporting results. ## Run a bounded operation 1. Keep the user's chosen network, account, provider requirements, and budget. Inspect or preview freely within the requested task. A skill invocation or `--yes` does not grant permission to spend funds or close other workloads. 2. Generate or edit the SDL, then validate it locally. Read [deployment recipes](references/deployments.md) for the sequence and examples. 3. Preview a workflow with `--dry-run` when useful. A chain preview with the default `auto` deposit can query live network parameters; it is not an offline transaction simulation or proof that deployment will succeed. 4. For authorized unattended deployment, supply an explicit bid strategy and `--yes`. Use `cheapest` only if any qualifying provider is acceptable, or `provider=<full-provider-address>` when a provider was chosen. `--yes` does not select a bid, supply missing arguments, or unlock a keyring. 5. Capture results and inspect resulting deployment, lease, and service state. A transaction hash or `sync` broadcast response alone is not confirmation. ## Read machine output Request `-o json` for ordinary queries and `-o jsonl` for workflow execution or previews. Preserve stderr separately from stdout. Parse each JSONL record and retain the workflow/run ID, dseq, provider, transaction hashes, and errors. Check the exit status as well as the records. SDL source commands such as `sdl init` emit raw YAML; redirect that output to a file without `-o`. Human output scales amounts for readability. Machine amounts retain their denomination, so never interpret a micro-denominated integer as whole AKT or dollars without conversion. ## Recover from partial failure A failed or interrupted deployment may leave funded resources and active leases. Read the emitted recovery commands and inspect authoritative state before repeating a mutation. An ambiguous Console create or lease response may already have committed. Do not replay the whole deployment or invent a `--resume` flag. Use `akt context log` to inspect recorded mutations, and retain the original error and run ID. Closing leftover resources requires the user's existing authorization to cover those resources. Read [troubleshooting](references/troubleshooting.md) for state checks and remedies. MCP is optional. If the client already exposes akt tools, discover their current schemas and use this same operating guidance. Tool availability depends on configuration. `akt mcp` starts read-only; enabling writes is a separate choice.