# Chat0 keeps AI chat history in your browser and your keys on your machine

> Chat0 is a free MIT-licensed TypeScript chat client built on Next.js, where conversations live in browser storage through Dexie, API keys are supplied by the user, and the deployment path targets Cloudflare Workers instead of a Node host.

**senbo1/chat0** — Blazingly-fast open source AI chat app.

- Repository: https://github.com/senbo1/chat0
- Website: https://chat0.app
- Stars: 738 · Forks: 87
- Language: TypeScript
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/senbo1-chat0

## Conversation state lives in Dexie, not on a server

The consequential choice in Chat0 is where a conversation actually lives. The project description says all data is stored locally in your browser, and the dependency list supports that claim rather than merely asserting it: `dexie` and `dexie-react-hooks` are both present, and Dexie is the IndexedDB layer that stores the records. No database client, ORM or server SDK appears anywhere in package.json, so history is written to the browser rather than to a hosted store.

That single decision reshapes everything else. A second device does not inherit your conversations, because there is no account for them to sync through. Clearing site data erases the transcript, and no backup or export path is described. What the trade-off buys is narrow but real: no server operator holding your conversation history, and no signup form in front of the app.

## Three provider routes and a bring-your-own-key flow

Credentials are handled the same way. The feature list describes bring your own API keys and states plainly that they are not stored, so requests are signed in the browser with a secret you control rather than one held on a platform's behalf.

The provider surface is narrower than the headline suggests. `@ai-sdk/google` and `@ai-sdk/openai` cover Gemini and OpenAI, and `@openrouter/ai-sdk-provider` adds a third route. The shared runtime is the `ai` package, pinned at `^4.3.16`, with `@ai-sdk/react` providing the React binding. The feature list also promises DeepSeek and further providers soon, but no DeepSeek dependency shows up in package.json, so treat that line as a roadmap item rather than a shipped capability. Because the caret range holds the `ai` package inside the 4.x line, updates to that dependency only arrive as a deliberate bump in package.json, and that bump is a breaking change rather than a routine pull.

## Clone, pnpm install, pnpm dev, then localhost:3000

Chat0 is a Next.js application, so the local setup is a clone, an install and a dev server. The setup notes name pnpm as the package manager, and `pnpm-lock.yaml` plus `pnpm-workspace.yaml` at the repository root confirm that choice.

Start by taking the source:

```bash
git clone https://github.com/senbo1/chat0.git
cd chat0
```

Then install the dependency graph as the lockfile defines it:

```bash
pnpm install
```

Finally start the development server:

```bash
pnpm dev
```

That script runs `next dev --turbopack`, so the app compiles on demand instead of through a separate bundler step. You then open http://localhost:3000 to see the application. No environment variable for the model key is documented, so the key is entered on the browser side, which is consistent with the claim that keys are never stored.

## OpenNext points the build at Cloudflare Workers

Deployment is the part that departs from the usual Next.js defaults, and the `wrangler.jsonc` and `open-next.config.ts` files at the repository root explain why. The `deploy` and `preview` scripts both begin with `opennextjs-cloudflare build`, and `@opennextjs/cloudflare` is a listed dependency, which places the target on Cloudflare Workers rather than on a long-running Node server or a managed Next.js host.

Two more scripts complete the arrangement. `preview` builds and then serves the bundle locally, which is the quick way to check a deployment without pushing it. `cf-typegen` invokes `wrangler types` to emit a `CloudflareEnv` interface, so application code can be typed against the Workers runtime instead of a generic Node one. The repository keeps `next.config.ts` next to the OpenNext config, which means the codebase is still an ordinary Next.js app with an adapter layer sitting on top rather than a project rewritten around a specific backend.

## No tagged releases behind a 0.1.0 version number

Two facts set the maintenance picture. The last push was on 2026-09-10, and the repository has no GitHub releases. There is no changelog to read, no versioned tarball to pin, and no migration note attached to an upgrade, so the commit history is the only meaningful signal a user has.

The package.json version is `0.1.0` and the package is marked `private`, which fits a project still shaped like an early release rather than a published library. A `todos.md` file at the repository root points the same way. If you need a fixed, reviewable version of this code, you have to pin a commit yourself, because the project gives you no release boundary to pin against.

The licence is MIT, which is permissive. Redistribution and modification are allowed provided the copyright notice and licence text travel with the copies. If you fork Chat0 for internal use, keep the LICENSE file intact. This is a reading of the licence terms rather than legal advice.

## Chat Navigator is the one non-generic piece of interface work

Chat Navigator gets its own line in the feature list, and it is the one piece of interface work that is not table stakes. It lets you jump to any message in the thread rather than scrolling for it, which matters once a conversation with a long-answer model runs past a screenful.

The rest of the front-end stack is conventional for a Next.js app: React 19 with react-dom, Tailwind CSS 4 through the PostCSS plugin, Radix UI primitives for dialog, dropdown, separator, slot and tooltip, and lucide-react for icons. Class handling leans on clsx with tailwind-merge and class-variance-authority. Answer rendering runs through react-markdown with remark-gfm, remark-math and rehype-katex, plus react-shiki for syntax highlighting, so code blocks and formulas inside a reply are formatted rather than dumped as plain text. The feature list also claims an optimized React codebase with no unnecessary re-renders. That is a claim about render behaviour rather than a documented setting, and nothing in the dependency set can confirm it.

## Where browser-local storage is the wrong shape

Local-only storage is right for a private scratchpad and wrong for anything shared. Because conversations live in one browser profile, two people cannot review the same thread, and a second machine starts from an empty history. A team that wants a shared prompt library or a transcript it can audit will find no server to point at.

The key story has the same shape. Because keys are never stored, there is no team key vault, no rotation policy and no audit trail, and a user who forgets the key pastes it again. A centrally managed credential requirement is not something Chat0 attempts.

The documentation is also silent on the questions an adopter eventually asks. It does not describe authentication, deployment environment variables, backup of stored conversations, or a self-update path. Support is directed to the GitHub issues page on GitHub, which is where those gaps would have to be answered. The trade-off is deliberate rather than accidental, but it is a trade-off with a hard edge.

## Conclusion

Chat0 suits a single engineer who wants a fast scratchpad for Gemini, OpenAI or OpenRouter, values keeping keys and transcripts off a hosted service, and is comfortable running a pnpm and Next.js project without a release channel. It does not suit teams that need shared history, centrally managed credentials or a versioned upgrade path. Before adopting it, check that your provider account accepts the requests this client makes, that browser storage is adequate for the transcripts you intend to keep, and that you can live with a project whose last push was on 2026-09-10 and which has published no releases.

## FAQ

### Does Chat0 require an account or a server to chat?

No. The project description states that all data is stored locally in your browser, and package.json contains no database client or server SDK, so history stays in browser storage. Model API keys are supplied by you and are not stored by the project.

### Which AI model providers does Chat0 support?

The dependency list includes `@ai-sdk/google`, `@ai-sdk/openai` and `@openrouter/ai-sdk-provider`, all built on the `ai` package pinned at `^4.3.16`. The feature list mentions DeepSeek and further providers as coming soon, and no DeepSeek dependency appears in package.json.

### How do I run Chat0 on my own machine?

Clone the repository, run `pnpm install`, then `pnpm dev`, and open http://localhost:3000. The dev script uses `next dev --turbopack`, so there is no separate build step to run before the app appears.

### Can Chat0 be deployed to Cloudflare Workers?

Yes. The `deploy` script runs `opennextjs-cloudflare build` and then `opennextjs-cloudflare deploy`, and the repository carries `open-next.config.ts` and `wrangler.jsonc` for that path. The `cf-typegen` script generates CloudflareEnv types with wrangler types.

## Sources

- [Issues](https://github.com/senbo1/chat0/issues)
- [License: MIT](https://github.com/senbo1/chat0/blob/main/LICENSE)
- [Project website](https://chat0.app)
- [README](https://github.com/senbo1/chat0/blob/main/README.md)
- [senbo1/chat0 on GitHub](https://github.com/senbo1/chat0)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/senbo1-chat0