Reporting AI Spend to ActiveManage
An installation can send ActiveManage an hourly summary of its AI use, and ActiveManage can set a monthly and a weekly AI spend cap for that installation, which the installation then enforces itself. This is how AI spend is watched across separately hosted client installations as well as ActiveManage's own service.
Where to find it
Architect Panel → Activity:
- AI Usage — the Reporting to ActiveManage card, shown once the installation is enrolled
- AI Spend Notices — the installation-cap warnings
Architect Panel → Automation:
- Tasks — AI Spend Monitor - Report to ActiveManage, the hourly report
The AI Spend Monitor tile itself is ActiveManage's own console and appears only on ActiveManage's master installation.
What is sent, and what is not
- Sent: for each day, tenant, feature and model, the number of calls and errors, the tokens, the provider cost estimate and any charges; each tenant's code, name, plan and credit state; and the platform version.
- Never sent: prompts, answers, request or response content, who made a call, or any key.
Tenant names do leave the installation, so they are worth a line in your data processing agreement with ActiveManage.
Enrolling an installation
- ActiveManage registers the installation and issues a reporting key, shown once as two lines of configuration.
- Your hosting administrator adds those two lines to the installation's server configuration file. They are deliberately not a Site Settings value, so the key cannot be read or changed from a screen.
- In Tasks, switch on AI Spend Monitor - Report to ActiveManage. It ships disabled and runs hourly.
- Within the hour, open AI Usage and check the Reporting to ActiveManage card shows a Last accepted report and no Last error.
- Make sure ActiveManage notice address and Send notices from e-mail account are set on AI Settings, so cap warnings go somewhere.
The first report fills in roughly the previous five weeks. With AI billing off the installation still reports usage, just with no charges.
The installation cap
The card shows Monthly AI cap and Weekly AI cap, each as used against the cap with a bar, and the caps' version, when they were received and their state. The month is the UK calendar month and the week Monday to Sunday, UK time.
- Below 80%: AI works normally.
- At 80%: one notice per month or week to the installation's platform administrators and the notice address, recorded on AI Spend Notices.
- At 100%: every AI call is refused before it is sent, with a sentence saying the installation has reached the AI spend limit set by ActiveManage.
The cap counts all AI use, architects and sign-up work included, and is enforced even when AI billing is off, measured then from the run log's cost estimates at the billing rate and markup. There is no top-up for an installation cap: ActiveManage raises it. Caps stay in force while ActiveManage cannot be reached, and stop applying once the installation is no longer enrolled.
What goes wrong, and how to tell
- The card says "not enrolled - the caps below are not in force": the configuration lines are missing or blank. Caps received earlier are still displayed, but they no longer apply.
- "the reporting key in config/config.php is not valid": the key line was copied wrongly. Ask ActiveManage to rotate it and paste the new line.
- Last error mentions a signature mismatch: the key does not match ActiveManage's record, usually after a rotation. Paste the new key.
- Last error mentions clock skew: the server's clock is more than five minutes out. Your hosting administrator should fix its time synchronisation.
- Reports refused as switched off: ActiveManage has paused reports from this installation; it retries after a day.
- Never reporting: the task is not switched on, the task engine is not running, or the two lines are missing.
After a failure the installation backs off and tries again later; Next attempt on the card says when, and how many failures there have been in a row.
Worked example
A client installation is enrolled and given a monthly cap. On the 22nd its architects receive an 80% notice. They open AI Usage, group usage by feature, and find a custom app's background job running far more often than intended. The developer fixes the schedule, spend levels off, and the cap is never reached. Had it been, AI would have stopped with a plain explanation until ActiveManage raised the cap or the month ended.
Recommendations
- Enrol before switching AI on widely, so spend is visible from the first day.
- Set the notice address, or the 80% warning reaches nobody on your side.
- Check the card after any server move; clock and key problems show there first.
- Agree the cap with ActiveManage before a known busy period, rather than after it is hit.