# SDK and CLI compatibility

Canonical: https://savrn.com/cloud/docs/developers-sdk-cli

SAVRN Cloud · Coming soon. Public documentation and a browser simulation are available; connected services are not yet available.

The SAVRN Cloud preview provides browser workflows and labeled exports, but it does not release an SDK, CLI or live inference endpoint. This guide explains how to distinguish a useful review artifact from a supported client contract and what future compatibility documentation must establish.

**SAVRN Cloud · Coming soon · Public preview · Browser-local simulation · No live compute or payments**

## What the public preview supports

The public SAVRN Cloud preview runs its simulated workflows in your browser. Use screens such as [Playground](https://savrn.com/cloud/console/#/playground), [Projects](https://savrn.com/cloud/console/#/projects) and [Usage](https://savrn.com/cloud/console/#/usage). Workspace changes remain in browser localStorage; publishing the interface does not create a hosted account or connect an execution service.

There is no released SAVRN Cloud CLI, downloadable SDK or live inference endpoint established by this application. **Create demo key** in [Keys](https://savrn.com/cloud/console/#/keys) produces a simulated value; **Revoke** changes local key state. Neither grants or removes access to an external service.

## Use exports for review

Where an export action is provided, download the labeled JSON and inspect its record identifiers and simulation metadata. This is an artifact for understanding the proposed workflow, not a stable integration contract. Do not build a production client against undocumented localStorage structure.

The [API publication page](https://savrn.com/cloud/docs/reference-api) explains how a real client contract should be released.

## Before connected services launch

Begin with one maintained, tested client path and publish exact versions. If using an existing compatible client, document the supported operations and parameter subset. Provide real authentication, timeouts, streaming, retries, errors and usage examples. Test examples against the release they describe. Introduce a dedicated CLI only when it has an implemented lifecycle, distribution method, maintenance owner and compatibility policy. Documentation must not invent installation commands to make an unfinished service appear available.

## A client contract has several independent parts

A familiar request format is only one part of compatibility. A supported client also needs a verified service address, authentication method, accepted operation and parameter set, response contract and error behavior. The model or offer identifier must refer to the service being called; a catalog name or a demonstration identifier does not establish that relationship.

For streaming, compatibility includes the final event, interruption handling and whether usage arrives before the connection closes. For retries, it includes which failures may be repeated and how an idempotency key relates to the original request. These details determine whether a client can recover without submitting duplicate work or misreporting a partial result.

## What to look for when a supported client is announced

A SAVRN Cloud client guide should identify the tested package and version, the connected service release and a small example with an expected result. It should state unsupported features explicitly, including any differences between a base model's advertised capabilities and the offer available to the project. Examples should cover a successful request, a rejected request and a visible usage record.

Today, use the preview's exports to review relationships between sample records. A JSON download is neither a package distribution nor a commitment to maintain the browser's storage format. Installation commands, executable credentials and production integration instructions will belong to a separately released client path; none is supplied by this preview.