How SynapseX fits together

This page gives you the one mental model that prevents the two mistakes new users make most often: expecting a key from one SynapseX product to work in the other, and expecting your local files to be readable by a surface that never touches your machine. When you finish, you will be able to say — for any task — which surface to open, which credential it needs, and where the work runs.

What are the parts of SynapseX?

The SynapseX models sit behind two customer-facing hosts:

chat.synapsex.ai — the chat product, plus the account surfaces around it: your plan, your personal API keys, the browser page where you approve a device sign-in, and the download page for the apps.
platform.synapsex.ai — the developer API. It hosts the workspace console where you create API keys and buy credits, and the OpenAI-compatible HTTP endpoints under /api/v1.

And four surfaces you actually work in:

Surface	Where it lives	What it is
SynapseX Chat	Browser, `chat.synapsex.ai`	Chat with the SynapseX models, attach files, keep projects and memory
SynapseX Desktop	App on your machine	A coding agent that opens a local project folder
SynapseX CLI	`synapsex-code` in your terminal	The same coding agent, scriptable
Platform API	An HTTP call from your own code	OpenAI-compatible chat completions

That is the whole picture. Everything in this documentation belongs to one of those four boxes.

Where does the work actually run?

This is the part that drives real decisions, so it is worth being precise.

Surface	Runs where	Consequence for you
Chat	Entirely server-side	It cannot read your local files. To ask about a document, attach it in the composer
Desktop	The agent runs on your machine	Your files, terminal and git stay local; model traffic goes out
CLI	The agent runs on your machine	Same as Desktop, and scriptable in CI
Platform API	A server call from your application	You control the request; SynapseX only sees what you send

The Desktop app is not a web wrapper. On launch it starts its agent server on 127.0.0.1 behind HTTP Basic auth with a password generated fresh for that launch, and the interface talks to it over loopback. That is why the agent can edit your repository and run your commands: the part doing the editing never left your computer.

The CLI works the same way. Two of its capabilities need no account and no network at all — the local OpenQASM simulator and the local file runner. See Quantum simulator and Local runs.

What is shared between the surfaces, and what is not?

Shared:

The SynapseX model family. The chat catalog and the Platform API catalog are drawn from the same family of models.
The browser-approval sign-in. Both SynapseX Desktop and the CLI are signed in by approving a short code at chat.synapsex.ai/activate — see How browser-approval device login works.

Not shared — this is the trap:

Accounts. An account on chat.synapsex.ai is not an account on platform.synapsex.ai. You sign up for each separately.
API keys. Two formats exist and they are not interchangeable: sxc_ for Desktop and the CLI, sk-synapsex- for the Platform API. See Which SynapseX key do you need?.
Billing. A chat subscription grants nothing on the API platform, and Platform API credits grant nothing in chat. Even the credit units differ: in chat 1 credit is $0.01; on the API platform 1 credit is $1.00.

Which surface should I use?

One line each:

Chat — you want an answer, a document read, or a conversation you can come back to. Start here. See SynapseX Chat.
Desktop — you want an agent to work in a real project folder on your machine with a graphical file tree, terminal and diff review. See SynapseX Desktop.
CLI — you want the same agent in a terminal, or inside a script or CI step. See SynapseX CLI.
Platform API — you are writing an application that calls a model. See Platform API.

The longer comparison, with the trade-offs spelled out, is on Choose your surface.

Prove the shape in two commands

The two hosts are two different doors with two different credentials. You can see that directly.

The chat model catalog is public — no key at all:


curl -s https://chat.synapsex.ai/api/models

That returns the six models selectable in SynapseX Chat, each with its id, context window and per-million-token prices. The first entry looks like this (real response, abbreviated):


{
  "models": [
    {
      "id": "synapsex:synapsex-atlas-7b-v1",
      "name": "SynapseX Atlas",
      "provider": "SynapseX",
      "description": "Compact, fast model for general tasks and high volume.",
      "contextWindow": 128000,
      "inputCost": 0.1,
      "outputCost": 0.4,
      "priceUnit": "per 1M tokens"
    }
  ]
}

The Platform API catalog is the same family behind a different door, and that door is locked:


curl -s https://platform.synapsex.ai/api/v1/models \
  -H "Authorization: Bearer sk-synapsex-YOUR-API-KEY"

With no key — or the wrong kind of key — you get exactly this, HTTP 401:


{"error":{"message":"Missing or invalid API key","type":"authentication_error"}}

Same models, two hosts, two credentials. If you remember only one thing from this page, remember that.

How browser-approval device login works — what happens when Desktop or the CLI sends you to the browser.
Which SynapseX key do you need? — pick the right key the first time.
Getting started — pick a surface and get a working result.