Loading…
Manage API credits for Whisper audio transcription. Add billing credits here when transcription fails with "credit_balance_exhausted".
Balance: —
OpenAI — Billing ↗Manage API keys and monitor usage in Google AI Studio. Billing is tied to a Google Cloud project.
Balance: —
Manage API keys, view rate limits, and top up credits in the Anthropic Console.
Balance: —
Anthropic Console — Dashboard ↗ Anthropic Console — Billing ↗Manage API keys, view rate limits, and monitor token usage on the DeepSeek platform.
Balance: —
DeepSeek Platform — API Keys ↗ DeepSeek Platform — Usage ↗Manage the personal access token (PAT) used by the voice "fix it" handoff (modules/voiceFeedback.js). No balance API — the card only reports whether the token is configured.
Token: —
Devin — API Tokens (PATs) ↗
Rates are USD per 1,000,000 tokens, stored internally as
integer micro-USD so sub-cent calls are never rounded away. Keyed on the
resolved model the provider actually served — not the
claude/gemini/deepseek alias the app
requests, because the fallback chain chooses the model.
Loading…
The live GBP/USD rate is fetched hourly from the European Central Bank (via Frankfurter API) and stored automatically. The buffer is subtracted from the live pair rate so the tenant gets slightly less credit per pound — protecting the platform against GBP strengthening. The effective rate is what every balance display and checkout uses. Internal accounting stays in micro-USD.
Sets the model pre-selected in every tenant's engine picker, and the fallback for
server-initiated calls that name no model. A tenant can still override it per request,
and a user's own saved choice is remembered in their browser — so changing this mainly
affects new users and anyone who has never picked a model.
There is deliberately no temperature control. Anthropic does not support
the temperature parameter on Claude 4.7+ models (it returns a 400), and Gemini and
DeepSeek are already pinned at 0.2 in the gateway — so the only thing such a control
could do is make output less deterministic.
Balances are integer micro-USD internally. Reserve debits immediately and the unused portion is refunded when the call settles, so a balance is deliberately pessimistic while work is in flight. A negative hard-stop floor lets a trusted firm run into arrears rather than have a hearing-prep session die mid-way.
Loading…
What a tenant can buy. Price and credit are set independently
and on purpose — the credit is NOT derived from the display FX
rate, so editing gbp_per_usd never silently changes what a
pack gives. The suggested figure below is only a prompt; the stored value
is whatever you set.
Loading…
Every checkout attempt, including abandoned and failed ones — a row is written before the buyer is sent to PayPal, so a tenant reporting "I paid and nothing happened" can always be traced. Revenue counts completed orders only; a refund moves an order out of that state.
Loading…
Raw provider cost from real metered calls. No markup is applied yet — the per-tenant multiplier and credit ledger arrive in the next chunk.
Tenant-attributed view over request_log. Metadata only — no
request/response bodies or AI content. Severity is derived:
critical = 5xx / network failure,
error = any failed request (incl. provider 4xx
like credit exhaustion — a failed analysis is a real customer impact),
info = success. Rows with no tenant are
platform jobs (e.g. case-law sync) shown as System / unattributed.
Click the Logs tab to load…
When a user tells Elsa an answer is wrong, the complaint is checked against the live interface before it reaches you. Corrections that are provable from the interface (Elsa named a tab or window that does not exist) are applied automatically and do not appear here. What is listed below is what the interface cannot settle on its own: needs review = both sides refer to real controls, so the disagreement is about the order or the choice of step; rejected = the correction itself refers to something that does not exist, so the user is probably mistaken. Approving applies the correction to everyone; rejecting discards it. Corrections change the answer only — never a prompt, never the workflow, never code.
Click the Corrections tab to load…
The last 50 decisions, including the ones applied automatically. Shown so a wrong call can be spotted and reversed — a decision here is one row, not a deployment.
Loading…
The phrasings Elsa recognises as ordinary conversation rather than as a question to answer — greetings, thanks, farewells, yes/no, stop, repeat. Before this list existed, a bare “morning” had no command verb in it, so the rules had nothing to match and Elsa replied “Are you talking to me?”. Adding a phrasing here fixes that kind of mistake without a code change.
Two things worth knowing before you add one. Only phrasings of four words or fewer are ever matched — that is deliberate, and it is what stops “good morning, I want to file an N244” being treated as nothing but a greeting. And the match is exact: the whole sentence must be the phrasing, not merely contain it. Longer speech skips this list entirely and goes to Elsa as a real question.
Click the Corrections tab to load…
When Elsa refuses to act on something and the user immediately says it another way that does work, that pair is proof she was wrong the first time. The local model reads those pairs and decides which refusals were genuine instructions rather than the microphone mangling the words. The safe ones are added here automatically — nobody approves them first. That is a deliberate setting, and this list is where its mistakes become visible.
Each row shows the phrasing Elsa now accepts, what the user actually said that worked, and how confident the model was. A row that shows never used after a few days is probably noise and worth removing. Learning is capped per day so one bad run cannot flood the list.
Click the Corrections tab to load…