Comparison
We run Claude too
Point it at the same Claude — we ship an Anthropic adapter and Claude is the default in several places in this product — and change the building it runs in: conversations under a key you hold, Anthropic never receiving the customer’s name, and an escape hatch to a model on your own network for the work that should not leave it. We think Claude is excellent and nothing here argues otherwise. The comparison is between a hosted team workspace and one you can hold: who keeps the conversations, whether personal data reaches the provider, and whether the chat is the whole product or one surface among several.
Open the app All comparisonsStated without hedging
The chat product itself. Anthropic ships model capabilities to their own surface first, the interface is unusually well judged, and features like Projects and Artifacts are polished in a way that takes years. If what your team needs is the best possible Claude experience and there is no constraint on where conversations are processed, buying it directly from the people who make the model is a sensible decision and we would say so to your face.
Three things a hosted workspace cannot give you, whoever runs it. The conversations sit in a database you control, encrypted under a key derived from the user’s own password. Personal data can be removed before the prompt ever reaches Anthropic, by a detector on your own hardware. And the model becomes a setting: Claude for most work, a local model for anything you have decided must never leave the building, chosen per assistant rather than per subscription.
What you gain
Bring your Anthropic API key and the models behave exactly as they do today. What you gain is the option to route differently: a local model for the assistant that handles HR cases, Claude for everything else, and the freedom to change either without rebuilding a single assistant. Provider independence is only valuable at the moment you need it, which is why it has to be there beforehand.
Install the detector and personal data is tokenised on your own CPU before the request leaves, then restored in the reply you read. The model does the work; the identifiers stay home. If the detector is installed and unreachable, the request fails closed rather than going out unchecked.
Chat and notebook conversations are encrypted with a key derived from the user’s password using Argon2id, and an OPAQUE path is available so a migrated account’s password never reaches the server. Knowledge documents and transcripts are server-readable, because search has to read them.
The same workspace runs workflows with approval gates and dry runs, internal apps over your own data model, meeting transcription with speaker identification, and cited answers over your own documents — sharing one permission model and one audit trail. A conversation can start a workflow, and the whole chain shows up in one place.
Evaluating
Start the stack, paste the key, pick a Claude model. Nothing about the model changes, which is the point — you are isolating the variable you actually care about.
Provider → Anthropic → your key
With the detector installed, read the guardrail event afterwards: which category was detected, which direction, what action was taken — and never the matched content itself, because an audit log that copies the sensitive text is a second leak.
detected: person, IBAN · action: tokenise · restored in reply
Connect Ollama or vLLM on your own network and move the assistant that handles your most sensitive category onto it. Nothing that assistant sees reaches any cloud provider. That configuration is the whole argument, and it takes about ten minutes.
Provider → OpenAI-compatible → http://your-model:8000/v1
Questions
Yes. The Anthropic SDK is a direct dependency and Claude is the default model in several parts of the product. That is exactly why this page compares workspaces rather than models: arguing that Claude is the weak point would contradict our own build, and you would notice.
The layer around the model. Your own database for the conversations, encryption under a key the server cannot derive on its own, a PII detector running on your hardware, an egress log resolved to a country, and a workspace where the chat sits next to automations, knowledge and meeting notes rather than being the whole thing.
No — not as a pure chat product. They build the model and the interface together and it shows. If chat quality is the only axis that matters to your team, buy it from them. The trade is everything in the previous answer.
The adapters that ship are Anthropic direct, Azure OpenAI, Google AI Studio, Google Vertex, OpenAI and Mistral, plus any OpenAI-compatible endpoint. Check the provider list against your exact routing requirement before committing — we would rather you verified that than took our word for it.
Those specific features, yes — they are Anthropic's product. The nearest equivalents here are notebooks with cited sources over your own documents, and assistants with memory scoped to a user or a project. Different shape, and worth trying before you assume it maps.
Source-available, and we would rather be precise than borrow the word. The server and frontend are published under the Sustainable Use License v1.0: read it, modify it, run it internally without paying — what you may not do is resell Bee Flow as your own hosted service. It is not an OSI-approved open-source licence. We are working toward AGPL-3.0-or-later; today the Nextcloud connector is the only part that carries it.
Bring your key, start the stack, and send the prompt you would never paste into a hosted chat window. That is the only comparison that settles it.
Run it yourself How sovereignty works