How it fits together

Six words carry the whole product. Once these mean something, every other page reads easily.

Workspace

Your company. One workspace holds your people, your projects, your apps and one bill. Everything below lives inside it, and nothing is ever shared with another workspace.

You will also see it called your organisation in the console. Same thing.

People

Everyone you invite gets their own login — never a shared one, so spending and activity are always attributable to a person.

Role	Can do
Owner	Everything, including billing and payment.
Admin	Everything except billing — invite people, set budgets, deploy apps, see the whole workspace.
Member	Their own keys, their own usage, and the projects they've been added to.

Most people are members. The narrowed view is the point: a member opening the console sees their own work rather than the whole company's.

Projects

A project is how work is grouped and paid for — a team, a product, a client engagement, whichever matches how you actually think about spending.

Projects matter for exactly three reasons:

• Budgets attach to them, so "the support team may spend $200 a month" is one setting rather than a rule per person.
• Reporting rolls up by them, so the question "what did this cost us" has an answer.
• People are added to them, so a member sees the work they're part of and not the rest.

A workspace with one project is completely normal. Add more when you need to tell two lots of spending apart.

API keys

A key is how code proves it's yours. It looks like roar_live_…, it is shown once when created, and it is stored in a form nobody — including us — can read back.

Two things about keys are worth knowing before you make one:

• A key can do less than you can. Every key can call AI models. Anything beyond that — reading usage, deploying apps, creating other keys — is granted per key. A reporting script should get a key that can only read usage.
• Keys can expire. Give a contractor's key sixty days and it stops working on its own, which is one fewer thing to remember.

Full detail in Authentication & keys.

Models

The catalogue of what you can call. Each entry has a name you put in your code, a published price, and the kinds of request it handles — conversation, embeddings, images, speech, transcription.

Two properties are the reason people choose Roar over going direct:

• The price is published before you call and holds until we change it. It does not move with what a model costs us on a given day.
• The same name behaves the same way every time. We choose one way to serve each model and keep it there. A model that answered differently call to call would make everything built on it unpredictable, so we do not do that.

See Models & modalities.

Apps

An internal tool you deploy from a repository — a form, a dashboard, a small web app. Roar builds it, runs it and gives it a web address, and it can have a database and your own domain.

Every app gets its own AI key automatically, so anything it builds with AI is billed to your workspace and attributed to that app. See Hosting apps.

And the two things that watch everything

Budgets cap spending — per key, per project, or across the whole workspace. The tightest limit that applies is the one that counts. A budget either stops requests when it's reached or just emails a warning; you choose which.

Usage is the record: every request, what it cost, which model, which person, which app. It is how a budget stops being a guess.

Where things happen

I want to…	Go to
Invite someone, make a key, set a budget, deploy an app, see spending	The console — the website you log in to
Call a model from code you're writing	The API — see the Quickstart
Let an AI assistant do console work for you	The MCP server

Nothing needs code. If you never write any, the console is the entire product.