Skip to main content

Using the ECI CLI with Claude Code

We provide a SKILL for driving the ECI CLI from natural language in Claude Code.

Claude Code only

If you're using Cursor, Windsurf, or another AI tool, adapt the contents below to that tool's convention.

Install​

Copy the code block below as-is and save it to ~/.claude/skills/eci-cli/SKILL.md.

---
name: eci-cli
description: Use the `eci` CLI to manage Elice Cloud Infrastructure (ECI) resources. Invoke when the user mentions ECI, the `eci` command, or asks to create/manage VMs, networks, or storage on the ECI platform — including GPU/NPU clusters (e.g., H100, B200), block/object storage, and public IPs.
---

# ECI CLI

`eci` manages compute, network, and storage on ECI (Elice Cloud Infrastructure).

## Source of truth

This skill is a snapshot of conventions and rules. **Always run `<command> --help` first** for destructive or unfamiliar commands (`launch`, `delete`, `attach`, `resize`). If this skill and `--help` disagree, `--help` wins. For values that change over time (prices, instance types, image versions, status names), query the CLI live rather than relying on this skill.

## Preflight

​```bash
eci config verify
​```

If it fails, guide the user through `eci config set ...` (preferred over interactive `init` in agent contexts). Don't touch resources before this passes.

## Patterns

- Resource commands follow `eci <group> <resource> list | get <name|id>`
- Names and UUIDs are interchangeable
- `--format {table,json,csv}` + `--query col1,col2` for parsing
- JSON output auto-resolves `*_id` fields to names

## VM launch

​```bash
eci compute vm launch \
  --name <name> --instance-type <type> --password <pw> [--wait]
​```

Most fields have sensible defaults when omitted (image and size depend on instance family; subnet auto-creates a default vnet/subnet on first use). Run `eci compute vm launch --help` for the current flags and default values.

Common variants: `--no-start` (skip boot — $0 compute), `--no-public-ip`, `--no-network`, `--price-type spot` (accelerator types only), `--spec <name>`, `--pricing-id <uuid>` (when multiple pricings exist for one instance type).

## Safety rules — must follow

1. **`vm delete` always with `--cascade`** — without it, the disk / NIC / Public IP leak and keep billing.
2. **Bulk operations require explicit confirmation.** List targets first.
3. **Never delete vnet / subnet / disk in use** without checking attachments.
4. **Password rules** (API-enforced — confirm exact rules via the launch error message or `--help`): typically minimum length, multiple character classes, and no long ascending/descending sequence.
5. **CIDR ranges**: only specific private ranges are allowed (10.x is rejected). Confirm the exact allowed ranges from the API error if a `vnet create` fails. Subnet `--gateway` requires CIDR notation, not a bare IP.

## Cost awareness

State the hourly cost **before** showing the launch command, especially for GPU/NPU instances. **Get current prices from the CLI rather than assuming:**

​```bash
eci pricing list --resource-kind vm_allocation
eci pricing list --resource-kind public_ip
eci pricing list --resource-kind block_storage
​```

For batches (3+ VMs or any GPU/NPU VM), show total cost + cleanup plan up front. `idle` VMs cost 0 for compute (disk + IP still apply) — don't auto-`start` unless asked.

For any ondemand/reserved VM launch, verify quota first:

​```bash
eci org info --format json
​```

Check `resource_quota.compute.devices`, `instance_types.<uuid>`, `storage.*`, `network.public_ip`. State the gap if over and offer to reduce count or request a quota increase. Pre-checking lets you explain *why* a launch will fail before the API rejects it, which is clearer than reacting to the error after the fact.

**Spot pricing bypasses quota.** `--price-type spot` launches do not consume `resource_quota.compute.devices` or `instance_types.<uuid>` — do not block a spot launch (single or batch) on these fields being absent or zero. Quota only constrains ondemand/reserved. Storage and `network.public_ip` quota still apply regardless of pricing type.

## Known behaviors

- VM/disk status names differ from AWS/GCP (`running`/`stopped`). Read the current state via `vm get`/`block get` rather than assuming.
- `vm stop` → idle transition can take 1–3 minutes. A follow-up `vm start` only succeeds once the VM has fully reached the idle state.
- After a disk resize, the disk briefly returns to a transient state. `vm start` is rejected until the disk settles back to its ready state.
- `vm delete --cascade` can timeout at the stop phase. Retry; for bulk cleanup use `|| true` in a loop.

## Don'ts

- Don't run `eci` silently — confirm what gets created/destroyed first.
- Don't drop `--cascade` as "safer" — it's the opposite.
- Don't guess a single `--pricing-id` when multiple exist; surface the API's candidate list to the user.
- Don't add `--wait` to GPU launches unless asked (each adds 1–3 min of blocking).
- Don't quote specific prices, quota numbers, or instance type lists from memory — fetch live via `eci pricing list`, `eci instance-type list`, and `eci org info`.

Confirm it works​

After installing, open a fresh Claude Code session and try:

Launch one C-2 VM on ECI for me

If Claude responds in this order, the skill is wired up correctly:

  1. States the hourly cost first (looked up via eci pricing list)
  2. Verifies the environment with eci config verify, eci instance-type list, etc.
  3. Asks for your confirmation before proposing eci compute vm launch ...
  4. Guides cleanup with vm delete --cascade afterwards

What the skill covers​

AreaContents
Command patternsUnified list/get, common launch flags, SSH, lifecycle, delete
Safety rules--cascade mandatory, bulk confirmation, password rules, CIDR rules
Cost awarenessPer-resource price lookup, mention cost before any GPU launch
Known behaviorsstop → idle 1–3 min, disk queued after resize, cascade timeout retry pattern
Don'tsSilent execution, building commands without --help, guessing pricing-id

References​