Account
Plans and usage credits
How account limits and metered ContextStream operations relate, without mixing them with an assistant's own model bill.
Two separate things affect access: your plan, which sets account features and limits, and usage credits, which cover operations the service meters.
What the plan controls
The effective plan can set limits for workspaces, projects, team members, and memory retention. It also controls the available depth of features such as dependency analysis and enhanced context.
The dashboard and pricing page are the authority for the current plan matrix. Those values can change independently of the MCP protocol, so this guide does not copy a tier-by-tier price table that will drift.
What credits cover
ContextStream meters eligible operations rather than charging one flat amount per MCP request. Search strategies, graph analysis, enhanced context, indexing, and model-backed work can have different configured costs. Many administrative and read-only lifecycle calls are not equivalent to those heavier operations.
Check the workspace billing view for the current balance and transaction history. It is more reliable than estimating from the number of messages because one natural-language request can involve several service operations.
Your assistant's own model bill
ContextStream usage and the model bill from Claude Code, Cursor, Codex, or another assistant are separate. Connecting an assistant through MCP does not move that assistant's subscription or API-key charges into ContextStream.
Some ContextStream capabilities perform their own model-backed processing and can draw ContextStream credits. The operation result and billing history are the authority for those charges.
Keeping usage predictable
- Use normal search before requesting deeper analysis.
- Check graph scan freshness before asking to recompute a large project.
- Index only the projects and media you actually need.
- Keep workspace ownership and billing responsibility explicit for team use.
- Review the billing history when usage changes instead of guessing which conversation caused it.
Compare the work, not the message count
These requests may all look like one sentence in an assistant, but they do different amounts of ContextStream work:
| Request | Typical shape |
|---|---|
| “Where is the expired-token branch?” | A normal indexed lookup with a small ranked result |
| “Find every use of the legacy refresh client” | A complete usage sweep that can return several pages |
| “What breaks if we change this auth function?” | Dependency and impact analysis over the code graph |
| “Refresh the full code-health baseline” | Project-wide analysis and a saved snapshot |
| “Index this two-hour architecture recording” | Upload plus asynchronous, model-backed media processing |
| “List my current reminders” | A lightweight scoped record read |
This table is not a price schedule. Current metering and plan rules live in the billing view. It explains why “six messages” is not a useful estimate: one may be a small lookup and another may request project-wide or model-backed work.
When usage jumps, inspect the transaction history, operation, project, and time. Do not assume the last visible chat message caused the whole change; one request can route through several supported capabilities.
Teams
Team requests resolve an effective billing owner from the account and workspace relationship. Owners and admins should keep membership and billing responsibility current; changing account mode does not bypass the resolved plan or balance.
If it doesn't work
A request used more credits than expected. Check the transaction history and the operation that ran. A deep or model-backed request is not equivalent to a lightweight lookup.
The assistant reports insufficient credits. Open the workspace billing view and confirm both the balance and which account owns billing for that workspace.
I'm on a plan that lacks something. The feature says which tier it needs when the service rejects the request. Compare that requirement with the effective plan shown in the dashboard.