Local & cloud

Tinspec is two products built from separate repositories, with a boundary that is enforced in the code rather than merely intended.

The free local app

• The desktop app — the whole workbench you have been reading about.
• The request engine — the Rust library that actually sends things. Headless by design, so the same engine can back a CLI runner later.
• The collection format — the shared schema for the YAML you commit.

All three are free, and none of them wants an account. Download and that is the whole transaction.

Source and licence

The source is not public. Those three 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.

Each of them declares AGPL-3.0-only and carries the full licence text, but whether the source is ever published has not been decided.

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 status of cloud, honestly

At v0.1.0-preview.9 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. Endpoint overlays are not a synced kind at this release.

Why the engine is its own repository

The engine is a separate library, not code inside the app, because it must stay headless. The same engine that sends a request when you press ⌘↵ is intended to back a CLI runner that executes saved chains in CI.

That is a core use case rather than an afterthought, and it 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, or a model.