Local & cloud

Tinspec is a free local tier and a paid cloud tier, built from separate repositories, with a boundary that is enforced in the code rather than merely intended.

The free local tier

• The desktop app — the whole workbench you have been reading about.
• tinspec, the CLI runner — a second program that runs your saved chains headlessly, in a pipeline.
• The request engine — the Rust library that actually sends things. Headless by design, which is the reason the runner is a thin program rather than a second implementation.
• The collection format — the shared schema for the YAML you commit.

None of them wants an account. Download and that is the whole transaction.

The app and the runner ship on separate version lines — this release is app v0.1.0-preview.10 and CLI v0.1.1 — but the runner is built on the same engine release the app embeds, so a request behaves the same in a pipeline as it does in the window. See Run a suite in CI and the CLI reference.

The runner has no cloud half at all: there is no sign-in command, no device token, and nothing in it reads a Tinspec URL. It opens a project folder and sends.

Source and licence

The source is not public. Those repositories are private today, so there is nowhere to read the code, open an issue, or send a patch — and saying so plainly is cheaper than letting you find out by clicking.

The licence file shipped inside the app says the same thing in its own words: the software is not open source, no licence to the source is granted, and whether Tinspec is ever released as open source — and under which licence — has not been decided. The CLI is distributed in binary form under the same terms.

That is the entire claim. No intent, no date, no “yet”.

Paid cloud tier

• Workspace sync — share collections, chains, auth definitions, and providers across a team.
• A web console — request-history metrics and workspace administration.
• Dev tunnels — expose a local service under a public hostname.

The guarantee

The desktop app is fully usable offline with zero cloud account. Not “usable with limitations” — everything in the Start here, Concepts, Guides, and Reference sections of these docs works with no account, no network, and no sign-up.

Cloud features are strictly additive. There is no cloud assumption inside the local app; no feature is held back behind a login.

Concretely:

• The app has no Clerk dependency and no identity SDK. Sign-in, when you use it, mints a device token through a browser flow — no password ever lives in the app.
• There is exactly one backend URL and it is compiled in. There is no server field in the UI to point somewhere else.
• Secrets never sync. Auth definitions reference secrets by name; values stay on the machine that holds them, in the keychain or the encrypted store.
• The CLI has no login at all, so nothing in CI depends on the cloud tier existing. It reads secrets from a file or a command you name, and authenticates against your identity provider.

The status of cloud, honestly

At v0.1.0-preview.10 the desktop side of sync and tunnels is built and shipped in the binary — the views are there, the commands are there. The hosted service is not open for sign-up yet, so in practice you cannot use them today.

These docs therefore do not carry how-to guides for cloud sync or tunnels. Writing a walkthrough for something nobody can complete would be the exact failure mode this documentation is trying to avoid. When the service opens, those guides get written against a release that can actually reach it.

For where the cloud tier stands, see Pricing and the roadmap.

What sync will do when it opens

Recorded here because it shapes the file format you are already using.

Sync is server-as-source-of-truth with versioned whole-document push and pull. Each document carries a version; a push from a stale base returns a conflict instead of overwriting. A pull never silently overwrites or deletes a local file you edited since it last synced — that surfaces as a conflict too, resolved by taking remote, keeping local, or deleting.

Conflicts are never resolved automatically. Git-style three-way merge is deliberately not attempted.

The synced document kinds are collections, chains, auth providers, API providers, and route matchers. Three things in your project folder are not synced kinds at this release: endpoint overlays, and the .tinspec/lib and .tinspec/functions script files. A request’s own pre/post hooks are a different case — they are stored inline in the collection, so they travel with it.

Why the engine is its own repository

The engine is a separate library, not code inside the app, because it has to stay headless. The same engine that sends a request when you press ⌘↵ is the one that runs your chains in CI — that is no longer a plan. tinspec v0.1.1 links the engine release this app ships, which is why a pipeline and the window agree about what a request does.

That constraint is also why agent access works the way it does: the agent is a client of the engine’s interface, never a parallel request path. One auditable choke point for executing requests — whether the caller is you, a script, a pipeline, or a model.