What OneAI is

Most AI tools are engines or plumbing. They send your request to a model and hand back an answer, and whatever accumulated around that exchange — the context you assembled, the history you built, the record of what was actually sent — belongs to the provider you used. Change providers and you start over.

OneAI treats that accumulation as the product. The workspace, the context and the history are the permanent layer; models are interchangeable engines underneath.

Own, run, connect

Own. A conversation is a OneAI object, not a provider’s. Every message records which model and provider produced it, from which context, at which version. Context items are versioned, and interaction records are append-only, so history does not silently rewrite when you change something today. Export is always available.

Run. The same conversation can continue on a different model without restarting: the history stays, and OneAI derives the context the new model needs. If it does not fit, OneAI asks you what to do rather than quietly truncating — that is a setting (ask, truncate, or summarize), not a hidden strategy.

Connect. Models run connected to your context and history, and to other people: shared team context, a shared prompt library, team projects. Longer term, agent flows on your own machines write into the same record.

The part worth looking at first

OneAI’s signature surface is the inspector: for any turn, it shows what you typed next to what was actually sent to the model, and why — which instructions were prepended, which context items were included, and which version of each.

It reads the stored record rather than recomputing anything. That distinction matters: a view that re-derived the payload would show you what today’s code would send, not what actually went out. The record exists precisely to answer the second question.

Two kinds of control, and the difference between them

What may be sent to a model is enforceable. You can mark context and conversations sensitive and restrict which models they may reach; a team can define a model allowlist. These are deterministic.

What a model answers is filterable only best-effort — pattern matching and policy, not a guarantee. OneAI keeps that line visible rather than marketing both as the same thing. Optional request anonymization (redacting personal data before anything leaves) is in the same category: real, useful, and best-effort by nature.

What ships today

• Provider-independent conversations, mid-conversation model switching, and projects
• Personal and project context, standing instructions, saved prompts with titles, tags and folders
• The inspector, over versioned records
• Search across your history
• Attachments
• Import from ChatGPT and Claude exports, plus a documented generic import format
• Teams: four roles, shared context and prompts, model allowlist, sensitivity rules, activity log
• Your own provider keys (BYOK), web, mobile and a CLI
• Personal data export, and account deletion

What is deliberately not here yet

• Billing. v1.0 is a testing phase. Checkout, organization-level keys and pooled budgets are the next release — see pricing.
• Provider account sign-in. Connecting an OpenAI or Anthropic subscription instead of an API key comes later; today it is your own keys.
• Nodes. Running OneAI on your own machine — serving local models into your catalog and executing agent tasks there — is the next major phase, not a shipped feature. Today you can register an OpenAI-compatible endpoint (Ollama, vLLM, LM Studio and similar) through the API or CLI; the in-app screen for it comes with that work.
• The model marketplace. Third-party and specialized models published into the catalog is a later phase.

What OneAI is not

It is not multi-model chat with a dropdown; that part is a commodity and not the point. It is not a request gateway or a model router. It is not a coding agent or an IDE. And it is not a device or policy control plane — governance exists to serve the record, not as the product’s identity.