Open-source vs hosted Currai: choosing what fits your team
Compare operating responsibility, customization, costs, and retention to decide whether to run Currai yourself or use its hosted service.
Your team wants to learn from agent conversations: what users need, where the agent fails, and which changes deserve attention. Currai offers an open-source edition you can operate yourself and a hosted service you can use without deploying your own Currai application.
The useful starting question is who will run the analytics system. That decision affects how quickly you can start, which parts you can customize, and what your team needs to maintain.
Compare the responsibilities
| Decision | Open-source, self-hosted Currai | Hosted Currai |
|---|---|---|
| Application operation | Your team deploys and maintains the instance | Currai operates the hosted application |
| Initial setup | Configure the application, Convex, Clerk, and required service credentials | Create an account and workspace, then connect your agent |
| Implementation changes | Inspect the source and maintain your own changes | Use the features and configuration available in the service |
| Application billing | No Currai subscriptions, credits, or event quotas in the self-hosted edition | Access and usage follow the hosted offering |
| Running costs | Your infrastructure, service, and model-provider bills, plus maintenance time | Evaluate the hosted plan and your agent's separate operating costs |
| Retention | Your operators establish retention and deletion procedures | Review the retention provided by the selected hosted plan |
| Updates | Your team chooses when to upgrade and verifies the result | Currai manages hosted application updates |
For current hosted terms, limits, and pricing, use the pricing page. For self-hosted requirements, use the repository documentation. Neither option removes the work of instrumenting your agent and checking that its evidence is useful.
Choose self-hosting when you have a concrete reason to operate it
Self-hosting can fit a team that needs to inspect the implementation, maintain a custom integration, or choose how its analytics instance is operated.
For example, your team might want to adapt a connector to an internal event format. Access to the source lets a developer follow that event through ingestion and make a change. The team also becomes responsible for checking that change when upgrading Currai.
Another reason is control over retention. The self-hosted edition does not automatically expire data through hosted plan rules. Operators must decide what to retain, implement deletion procedures, and monitor storage growth.
That flexibility is useful when someone owns it. Before choosing self-hosting, identify who will handle deployments, failed ingestion, credentials, backups, and updates. Include their time in the decision.
Choose hosted when getting started quickly matters more
Hosted Currai can fit a team that wants to spend its effort connecting the agent and reviewing findings instead of operating another application.
You still need to provide meaningful evidence. A model event with no readable conversation context may explain latency without explaining why the user left. You also need to define relevant intents and violation rules, review findings, and decide which issues to fix.
Evaluate the hosted offering against your expected event volume and the amount of history your team needs. A multi-turn session can generate several agent, model, and tool events, so conversation count alone is not enough to estimate usage. Review the current plan details before making a purchasing decision.
Look at the complete data path
Self-hosting lets you operate your Currai instance, but the application uses Convex and Clerk, and classification uses TypeSafe / Jev. Optional integrations can involve other providers.
Map the services involved in your intended deployment. Decide which conversation content you send, which credentials each service requires, and who can access the resulting evidence. Running Next.js yourself does not automatically make every processing step local.
For hosted Currai, review the service's published terms and discuss any specific requirements before adoption. Choose based on the deployment you can verify, rather than assumptions attached to the words "open source" or "hosted."
Compare total cost with a small trial
The self-hosted edition has no Currai application subscription or event quota. Your infrastructure and model-provider costs remain, along with the time needed to maintain it. Hosted Currai has its own offering and limits, which should be compared against that full operating cost.
Use a small set of representative conversations to evaluate either option. Include a successful task, an incomplete task, and a user correction. Check that the evidence is readable and the findings help your team make a decision.
Then estimate your workload from what the trial actually produces: events per conversation, classification activity, retained data, and integration maintenance. This gives you a more useful comparison than assuming every conversation costs the same amount to process.
Make the choice your team can sustain
If you have an owner for the instance and a specific need for implementation or operating control, start with Self-hosting Currai: your first agent conversation.
If your priority is connecting an agent without deploying Currai, create a hosted workspace and use the integration documentation.
In either case, start with evidence you understand. The value comes from turning that evidence into better agent behavior, then checking whether the next version actually helps users complete their tasks.
