STU, quotas and spending

Shara measures consumption in a single unit, the STU (Shara Token Units), independent of the model used underneath. On top of that come clear quotas by plan, predictable overage, rollover and automatic spending cuts: the idea is that you never get a surprise invoice at the end of the month.

The STU is the client’s single unit of consumption, independent of the model used underneath. Every time an agent reads or writes, Shara measures the real tokens (input plus output) and converts them to STU based on the model that handled the request. More capable models consume more STU per token, so the same sentence resolved by Symphony spends more STU than if resolved by Prelude.

The token-to-STU conversion is deterministic: for a given model and a given volume of tokens, the STU cost is always the same. There are no hidden rates or opaque rounding; the weight of each model is fixed by its tier.

Tier	Alias	STU / token ratio
Agile	Prelude	Low
Production	Sonata	Medium
High capacity	Symphony	High
Local	Concerto	No cloud STU cost

Since Amadeus delegates each task to the most suitable model, your consumption naturally goes down: routine tasks fall to Prelude or Sonata, and only complex reasoning reaches Symphony. You never pay for more capacity than a simple task needs.

Every exchange with an agent deducts STU from your monthly quota. An interaction’s consumption depends on three things:

• Input size: the message, plus the context the agent needs (its IDENTITY.md, the relevant memory, the email or document it’s reading).
• Output size: what the agent drafts or reasons through to respond.
• The model handling it: the higher the tier (Prelude, Sonata, Symphony), the more STU each token weighs.

A task can involve several chained calls. If Amadeus receives a request and delegates it to a departmental agent, and that agent in turn queries a tool and drafts a document, each step adds its part to the interaction’s total. The dashboard breaks that journey down so you can see exactly what was spent on what.

Quotas are sized for real business use, not to be burned through in an afternoon. As an indicative reference (the exact consumption depends on the model, the context and the length of each response):

• A short task (classifying an email, extracting data from a message, drafting a brief reply) is low consumption, especially when handled by Prelude or Sonata.
• A medium task (drafting a proposal, summarizing a long thread, preparing a report with data) consumes more, because the context and the output both grow.
• A complex task (analyzing a contract clause by clause, a strategic analysis, in-depth research) weighs the most, and is usually resolved by Symphony.

Translated into monthly capacity, each plan covers on the order of thousands of interactions. This is a sizing guide, not an exact promise: what’s reliable is looking at your real consumption on the dashboard during the first few weeks and adjusting the plan from there.

Plan	STU / month	Usage profile it covers
First	50M	An essential team automating its day-to-day
Pro	140M	Intensive daily use with more departments
Max	280M	Intensive multi-department operation
Max ×5	1,150M	Large teams with high concurrency
Max ×20	4,000M	High volume for a mid-sized company

Plan	Price	STU / month
First	€129/month	50M
Pro	€349/month	140M
Max	€690/month	280M
Max ×5	€2,900/month	1,150M
Max ×20	€9,900/month	4,000M
Concerto Local	€999/month	On-premise, no cloud quota
Additional agent	+€99/month	+15M

A 10% annual discount is available. Concerto Local (€999/month) deploys Shara on-premise, fully included on your own infrastructure with no cloud component: it doesn’t consume cloud STU and generates no overage. Full detail of each plan in Plans and pricing.

If you exceed your monthly quota, the conversation in progress isn’t cut off: it moves into overage, billed at a flat rate. Overage accumulates during the period and is added to your next invoice.

Plan	Overage
All paid plans	€5/M STU
Concerto Local	No overage (on-premise)

The rate is flat and identical across every paid plan: €5 for each million STU you spend above your quota. Concerto Local doesn’t apply, because inference runs entirely on your infrastructure and doesn’t bill by use.

Rollover rewards steady use by carrying over to the next month the STU you didn’t consume. It only applies to cloud plans (Concerto Local doesn’t consume cloud quota) and works with three rules:

1. It kicks in if you consume at least 80% of your base quota in the month. It’s an incentive for real use, not for stockpiling unused quota.
2. It has a cap of 20% of the base quota. Even if you have more left over, the next month you carry over at most that 20%.
3. It expires after 2 months. Rollover not used within that window is lost.

In the new month, Shara spends the rollover first and then the month’s quota. Only once both run out does overage kick in. This way, a slow month doesn’t penalize the next one, and the margin you left unused stays available for a while.

Example with Pro (140M STU/month): if in a given month you consume 120M (above the 80% threshold) and have 20M left over, you carry over up to 28M (20% of 140M), so the full 20M passes through. The following month you start by spending that 20M of rollover and, once it runs out, you continue with the base quota.

So you’re never caught by surprise, Shara alerts you as you approach your quota limit. There are three alert thresholds:

• 75%: first informational alert. You’re on a normal consumption pace; it’s a good time to check whether the month is going to be a heavy one.
• 90%: proximity-to-limit alert. Worth deciding whether to activate saving measures or plan for overage.
• 100%: you’ve used up the month’s quota. From here the service keeps running, but consumption moves into overage (€5/M) unless you have rollover available.

Alerts reach the account administrator and stay visible on the dashboard, along with the consumption breakdown by agent and by day.

Outside the business hours you configure (tenants.business_hours), Shara automatically forces low consumption. The idea is that night or weekend work (cron, monitoring, alerts) keeps running without driving up cost.

• Automatic model downgrade: Symphony drops to Sonata and Sonata drops to Prelude, so the same task consumes less STU.
• Output limit on Prelude: capped at 500 tokens for more contained replies outside business hours.
• No service cut: cron, monitoring and alerts keep running; only spending is reduced.

In practice, low-spending mode noticeably cuts costs outside business hours without leaving you uncovered. Business hours are set per tenant, so it adapts to your real working day.

Kill-switches are automatic cuts on a hard limit. They work on three levels and each one acts before the next comes into play. The amounts are billable, meaning what you’d see on the invoice.

Level	Default threshold	What it does
Per run	€5 in a single execution	Stops the execution and marks it as killed.
Per hour	€50 in the last hour	Suspends new runs for that hour and alerts the admin.
Per day	€400 in the calendar day	Suspends every agent until the next day or manual intervention.

When a kill-switch triggers, the kill_switch.triggered webhook is emitted and a banner appears in the panel. Thresholds can be raised from Settings → Kill-switches (a significant increase requires confirmation from a second admin), and there’s also a manual resume button to re-enable the agents whenever you decide. In Concerto Local these don’t apply: inference runs entirely on-premise and doesn’t bill by use.

Between the quota, the rollover, the alerts, low-spending mode and kill-switches you have several levers to keep consumption under control. In practical order:

• Size the plan to your real consumption. Look at the dashboard the first few weeks and move up or down a plan based on the STU you actually spend, not on estimates.
• Set your business hours correctly so low-spending mode covers the hours when you don’t need the premium models.
• Watch the 75% and 90% alerts to decide in time whether you expect overage or need to adjust use.
• Take advantage of rollover: keeping consumption above 80% keeps the leftover margin from being fully lost.
• Keep the kill-switches active and adjust their thresholds to your spending tolerance; they’re the safety net for an unexpected spike.
• Use overage as a buffer, not as the norm. At €5/M it’s predictable for occasional peaks; if it’s recurring, it pays off to move up a plan.

To choose a plan and see full pricing, go to Plans and pricing. The billing engine measures every call by its real cost and applies your plan’s margin, with no opaque flat rates.