SDKs
Generated CLI
Every generated SDK can ship a runnable command-line interface: one kebab-case subcommand per operation, sharing the client's auth, retries, and base URL.
It's opt-in. Turn cli on in SDK Studio and the generator emits it alongside the library.
This is a CLI generated for your API, shipped inside your SDK. It is unrelated to octri-monitoring, which uploads symbolication artifacts to Octri.
What it produces
Each included operation becomes a subcommand named from its method name, kebab-cased. users.list() becomes users list; createPaymentIntent() becomes create-payment-intent.
acme users list --limit 10
acme users create --name "Ada" --email ada@example.comExcluded endpoints don't get a subcommand, the same way they don't get a method. See Generating an SDK.
Why ship one
An evaluator can exercise a real endpoint in one line instead of scaffolding a project first.
Support and ops teams get a supported tool instead of hand-rolled curl with a copy-pasted token.
What it costs
Every included operation becomes a runnable command, destructive ones included. acme users delete --id ... is one typo away from a bad afternoon.
Before enabling it, check your endpoint inclusion. An endpoint that shouldn't be one keystroke from a shell should be excluded from the SDK, which excludes it from the CLI too.
It also adds surface to maintain: the CLI's argument parsing is generated, but its existence is a promise to your users.
Credentials
The generated CLI reads credentials the same way the library does, from flags or the environment, and never bakes them in.
acme users list --token sk_live_... lands in ~/.bash_history and in CI logs. Use the environment variable instead, and keep the token out of the command line.
Relationship to the library
The CLI is a thin shell over the generated client, so everything from reliability to idempotency applies identically. A retry policy set in Studio governs the CLI too.