LibreChat for the enterprise: SSO, teams and per-token billing

The pilot happened without you. Somewhere in the company, LibreChat is already running: a developer set it up in an afternoon, two teams found it, and now it quietly carries real work. Then the request lands on IT's desk as one sentence, "can we make this official?" Official is where the hard part starts: single sign-on, access control, a budget somebody owns and an invoice procurement can actually file.

This article is the map for that step. What an enterprise rollout of LibreChat really requires, which parts LibreChat ships out of the box, and which parts someone has to build. Full disclosure up front: kral is a managed LibreChat built for exactly this gap, and we will be precise about where the open source project ends and our layer begins.

What "official" actually means

Every company means the same six things when it says official, whatever the tool:

• Identity. One login, managed joiners and leavers, no password lists in a spreadsheet.
• Access control. Who may use which models, decided by role, not by who found the URL first.
• Attribution. Usage that can be traced to a person, or finance will trace it to you.
• Budgets. A cap per person or team that stops overspending before it happens, not after.
• Procurement-grade billing. One invoice, correct VAT, a vendor that fits the purchasing process.
• A lifecycle. Updates on a schedule, a changelog someone reads, and a documented way out.

None of this is exotic. It is the same list your company demands from every other system of record. The difference is that AI arrived through the side door, and the list is now overdue.

What LibreChat ships out of the box

Credit first, because it has earned it. LibreChat gives an enterprise real substance to start from:

• OpenID Connect support. The app can authenticate against an identity provider instead of local passwords.
• The interface your users already picked. Agents, file chat, image generation, search; adoption is not your problem.
• An MIT license. No user-count clauses, no branding conditions, inspect and adapt the code freely.
• Token credits as a primitive. A basic mechanism to meter usage exists.

And the honest boundary, the same one we described in managed LibreChat hosting: LibreChat is a chat application, not a billing system and not a procurement counterpart. There are no plans, no invoices, no tax handling, no spending caps a finance team would recognize, and teams exist as rows of users, not as contracts with shared budgets. That is not criticism; it is scope.

The enterprise layer kral operates

kral keeps the LibreChat experience close to upstream and builds the official part around it as one suite: the chat your users see, the gateway your internal tools call, the admin console where IT governs, and the billing finance can file. Even LibreChat itself is configured from that console; switch a model on, toggle a feature, and the chat follows, no hand-edited YAML. In practice that means:

• One login. A single account carries chat, usage and billing. No API keys anywhere in the company.
• Teams as contracts. One agreement, one shared budget, members the owner invites and removes. Access ends the moment the seat does.
• Budgets that enforce themselves. Monthly caps per person; the platform measures every request against them and stops at the line you drew.
• Usage you can actually see. Every request is metered: model, tokens in, tokens out, cost. Token spend per user is a lookup you do in seconds, not a month-end reconstruction, and every unit of spend has a name attached.
• Model governance. Switch individual models on or off; every major provider is included and billed per token.
• Procurement-ready billing. Plans plus credits, EU VAT handled, one invoice instead of five provider statements.
• A lifecycle you do not run. When LibreChat ships a release, we merge, test and roll it out.

Hosted in a minute, or inside your walls

The fast path is hosted: sign in at app.kral.ai and the layer above is already live. The enterprise path goes further: the platform kral is built on can run inside your company, natively on your own Windows Server. There, sign-on plugs into the identity provider your IT already runs, the data stays on hardware you own, and your internal tools reach every model through one gateway endpoint with one key.

Both paths keep the same exit: the base is open source and your data is exportable. An official tool should never need a hostage clause to keep its users.

Raw LibreChat vs kral, through enterprise eyes

Questions IT actually asks

Is kral just LibreChat with extras?

Deliberately, yes. kral keeps the chat close to upstream; around it sit the gateway, billing, budgets, usage reporting and team management, driven from one console, which is precisely the part an enterprise rollout was missing.

Can we keep our identity provider?

On the self-hosted platform, yes: sign-on runs against the IdP your IT operates. The hosted service at app.kral.ai uses kral accounts with a single login across chat and billing.

What do we tell the data protection officer?

Ask where the prompts go. On your own server, they go to hardware you own before any model sees them. On the hosted service, they go through kral to the model providers you choose, and your data stays exportable at any time. That is not a lawyer's answer; it is the honest topology to build one on.

Do our people need API keys?

No. Every model on the platform is included and billed per token. Nobody opens provider accounts, and no key can leak, because there are none to hand out.

What does it cost?

Monthly plans with included usage, plus credits for the heavy weeks. Current numbers are on kral.ai; there is no per-seat markup hidden in a PDF, and the colleague who asks three questions a month costs you almost nothing.

LibreChat already won your users; that part is done. What remains is making it official without making it a six-month project. That is the part kral operates:

Book a demo

Try kral now