How ClariSpace is built.
The machinery behind the promise on the homepage: what a question goes through, why nothing leaves without you, how DevMode works on your code, how the product watches itself, and what it costs to keep. Every sentence here is something the code does today.
The shape
One box. A Django API and a React app on a single small server, with SQLite as the database and a nightly snapshot of it. No queue, no second database, no vector store, no metrics stack: each of those is a second machine to run, back up and pay for, and none is needed for the work a person does in a day. The only thing that costs money as the product is used is the model, and every call to it is counted.
Everything a person connects - Gmail, Calendar, Docs, Sheets, Drive, Jira - is a bridge: one OAuth grant, read on demand, disconnected in one click. Tokens are encrypted at rest with a key the server holds, never the database.
What happens to a question
A question enters through a gateway that stamps it with a request id, checks its shape and size, and counts it. Then the product decides which of its sixty capabilities the question is - a reply, a brief, a spreadsheet read, a document edit, a plain answer - from the words alone, never from the material, so a mail cannot pick the tool.
For a plain answer, every connected source is asked at once, on a clock: the library by words and by meaning (every kept file is embedded and matched by cosine), mail by the people and topics in the question, the calendar by the day, the board by the issue. A small model reads the question in parallel and says whether it is about your work or about the world; a question about the world keeps your material out of the answer. A router reads the question's size and shape and picks the model tier - a short ask goes to the cheapest model, a comparison or a long write to the largest. Or a person picks the model themselves: ChatGPT's tiers, Anthropic's Claude Opus 5.5, xAI's Grok, or a local model. With Claude picked, the small reads still run on the cheapest model, and Claude writes the answer.
Before any model reads the material, three things happen to it: lines that address the assistant are taken out and declared; personal data can be covered; the whole is bounded. The answer comes back with every fact naming its source, and the line above it says what was read - three emails, an event, a file - in colour.
Nothing leaves without you
This is the rule the whole product is built around, and it is enforced in one place rather than promised in many. Every capability is classified: a read, a preparation, or an action that reaches outside. Actions wait in Sign-off with the exact payload that will go, editable, and are carried out only by the button. An agent's plan can contain "send the reply" so you see it coming; the executor cannot run it. A step an agent adds mid-run can never be a gated one, because it was decided from material - somebody else's mail.
Every action is on Trail with who, what and when. Every model call is on Spend with its tokens. Retention is yours to set, everything deletes in one click, and a bridge you disconnect takes its data with it.
DevMode: the hands are yours
DevMode works on code, and the code and the commands stay on the developer's own machine. It reaches them through a bridge: one Python file, standard library only, run inside the project. The bridge polls the server and takes the calls queued for it - list, read, search, write, run - so a laptop behind a home router works, and the server never reaches in. Pairing is a six-digit code, used once; the server keeps only a hash of the token the bridge earns. The brain - the model, the plan, the guardrails, Spend - stays on the server; the hands are local. Running a stranger's tests on our server would be a security hole and a bill.
What the bridge refuses, whatever the server asks: a path outside its folder, a symlink that leads out, the contents of a secrets file (.env, keys, credentials), a command past its time. Known key shapes, values whose names say secret, and credentials in URLs are masked in any command's output before the model or the page sees it.
The policy is code, not a prompt. Reads, searches and edits run, and every edit keeps the file as it was, so one click puts it back. Tests, linters, type checks, builds and git status run. Installs, deletes, commits, pushes and anything that reaches the network wait for Run it or Skip. sudo, rm -rf / and their kind never run at all.
Every ask is read first, in one light model call, for whether it is talk or work - so "hi" costs a sentence, not a mission. Work runs on GPT-5.6 Luna, or on GPT-6 Sol when it is hard, and moves to Sol mid-task when a plan reaches six steps or four files. A finish that claims more than the rows show is sent back: a change needs a passing run or, for a page, a look taken after it in a headless browser on the machine - and failing that, the report says plainly what was not proved. More than forty stress missions hold the engine to one number, a claim the rows do not bear out, and it is zero.
Seeing it work
Every request leaves a metric row; every turn leaves a trace, stage by stage, with the tool, the tier, the model and how long each part took - never the words. Settings → Health reads them back: latency at the median and the tail, error rate, where a turn spends its time, which models answered, the thumbs, the last eval. An eval suite pins the product's own behaviour as cases that run on every deploy; a live suite sends real prompts through the whole turn when asked. Two wordings of the writer run side by side, assigned per account, and the thumbs under every answer decide between them.
Signing in
Three doors, all free. A password, stored as a hash. A six-digit code from your mail - ten minutes, five guesses, once, never stored in clear - which is also how a new address proves it is real before an account exists for it. And a passkey: Face ID, Touch ID or a security key, bound to clarispace.in so a lookalike page gets nothing. The sign-in screen never says whether an address has an account. The first time a browser signs in, the account gets a short mail saying so, with what to do if it was not you.
Open at the edges
The API is versioned at /api/v1/. ClariSpace is also a Model Context Protocol server: mcp_serve lets Claude Desktop, Cursor or any MCP host ask an account's library, mail, calendar and Radar, read-only. And it is an MCP client: servers an operator attaches appear as capabilities an agent can plan with - reads run, writes wait at Sign-off like every other write, all under one switch in Permissions.
What it costs to run
A $7-a-month server, a domain, and the model tokens the people on it spend. Web search is on a free tier with a ceiling of its own. There is no bill that grows with a feature being used, only with a question being asked - and that one is on Spend, per person, per day, with a limit.
Where to read more
What is read and kept is in the privacy policy; what the product does, on the About page. For anything else, write to hello@clarispace.in.