Money, Limits and Members

The wallet

Your account pays for runs from a prepaid wallet. Nothing runs until the wallet holds money: each model call a run makes is reserved against it before the call is made. A model reply costs its tokens plus a fixed amount per model call. A tool call that runs on our servers, a loop’s own tool or a read of a web page, costs the compute it used, measured on each call. A call that costs less than a millionth of a dollar is added to the run’s running total, not dropped, so a run’s tool calls cost what they used together. It counts toward the run’s budget and the loop’s caps at once, and it is taken from the wallet with the run’s next model call, or when the run ends. Under By run on Wallet & budgets, each run lists what it spent on each model, and the fixed amounts per model call, the live streaming and the tool calls on lines of their own. What each model and each search, document and page costs is on Pricing. A request your server makes to read records under an API key is charged after it is served: once an hour, all of one key’s requests from the hour before are taken from the wallet in one charge. If the wallet cannot cover that charge, it is taken once the wallet holds enough.

Adding money by card opens soon. Until then, we add credit to your account. Wallet & budgets shows the wallet and, for each loop, what it has spent this month, what is held for calls not yet settled, and its monthly cap, and what each user has spent against the per-user cap. Loops are listed by what they spent, most first, and the first ten show; Show all lists the rest. Under each loop the three users who spent most show, then one line saying how many more there are and what they spent together, with Show all to list them. A member of your account is named. A signed-in visitor is named too when your site’s id for them is one of your members, and reads as “a signed-in visitor” when it is not. Any other user is named by kind and id: a signed-out visitor by the end of the id the platform gave them, and an API user by the id your server sent. The wallet’s balances are shown to the cent, rounded down, and what was spent to four decimals, so the lines add up to the total. A loop that is no longer in your library reads A removed loop, and an archived one keeps its name with (archived).

Plans

Your account is on one of two plans. Both prices for everything are on Pricing.

• Pay as you go has no monthly fee. A new account starts here.
• Pro costs a fee each month and lowers every price. The fee is taken from the wallet when you subscribe and again at each renewal.

The Plan card on Wallet & budgets shows your plan and, on Pro, when it renews. Only an owner of the account can change it. Subscribe to Pro first asks you to confirm, naming the fee and the day Pro renews; Subscribe then takes the first fee. If the wallet holds less than the fee, nothing is taken, and the card says how to add credit while card top-ups are not open. Cancel Pro keeps Pro until the end of the month already paid, and that fee is not refunded; until then, Keep Pro undoes the cancel without a new fee. If the wallet cannot cover a renewal, the account goes back to pay as you go, and the card says why.

Four budgets

Every run is held to four limits, set in the loop’s record and checked before every call:

A search the run makes is held to the same four, so it never takes the run past its budget: when the budget has too little left, the search runs by words alone, or does not run.

Amounts are in millionths of a US dollar, so 50000 is five cents. A run’s budget must not be more than the per-user cap, and the per-user cap must not be more than the monthly cap: publish refuses a record that breaks the order and names it.

Give one person more, without a publish

An override replaces one cap for one person, or for the whole account, on one loop or on every loop. It applies every month until you remove it, a new version of the loop keeps it, and it holds no money: the wallet still pays and still binds. Only an owner sets or removes one, through PUT and DELETE on /api/billing/budget-overrides; any member can list them with GET.

{"loop_id": "assistant", "subject": "member:<user id>", "level": "per_user", "micros": 2000000}

• level is per_run (one run’s budget, set when the run starts), per_user (one person’s month on the loop) or monthly (the loop’s month across everyone, so it takes no subject). Leave out loop_id for every loop, and subject for the whole account. A per_run override applies to runs started from the console, the run API, a webhook or a batch; a test case runs at the loop’s own values, and so does a run a new record starts. A scheduled run takes its budget from the automation that wakes it, so give it more with a per_wake override on that automation.
• subject is the person as a run names them: member:<user id> for someone in your account, visitor:<id> or signed_assertion:<id> for a person on your site.
• The most specific override wins: this person on this loop, then this person on every loop, then the account on this loop, then the account on every loop, then the loop’s own value. Every other cap still binds.
• An override that would put the per-user cap above the monthly cap is refused, and the refusal names the level to raise too.

An automation that wakes runs, such as a loop’s schedule, declares two caps on its wake_agent step: budget_micros for each run it wakes and daily_cap_micros for what its wakes may be given in one UTC day. An override replaces either one on that automation, without approving it again:

{"claim": "loop_job_hunt", "level": "daily_cap", "micros": 5000000}

• level is per_wake or daily_cap, and claim names the pipeline whose step wakes the runs; a loop’s schedule wakes them from the pipeline loop_<loop id>. Naming the schedule is refused, and the refusal names the pipeline to use instead. It takes no loop_id and no subject: the runs it wakes are the account’s.
• An override that would put per_wake above daily_cap is refused, naming the level to change too.
• When the daily cap stops a wake, the automation’s run row names the override that set the cap.
• Remove one with DELETE and ?level=<level>&claim=<name>.

In the console, Wallet & budgets lists every override under Spending limits you set: the amount, for whom, on which loop or automation, which cap it replaces, and who set it and when. A loop’s schedule trigger is two automations, named by the loop: “Job hunt’s schedule” says when it fires and is its one row on Schedules, and “Job hunt’s scheduled run” wakes the runs and carries their caps, so it is the one you cap here. Any member can read the list. An owner presses Add an override and picks what it caps:

• A loop: the loop (or every loop), the cap, and the person (or everyone on the account).
• An automation: one of the automations that wake runs, and each run it wakes or its day of wakes. The form shows what the automation itself declares for both.

Then the owner sets the amount; Remove takes one away. When the API refuses one because the caps would be out of order, the form says so in the same words and in dollars, for example “Each run it wakes would be $5.00 on Job hunt’s scheduled run, more than its day of wakes ($2.00). Raise its day of wakes too.” An automation’s caps also have the platform’s limit: at most $10 for each run it wakes and $100 for its day of wakes, and the form says that in dollars too. Any other refusal shows as the API wrote it.

A run that its daily cap stopped says so on Schedules, and an owner sees Give this automation more beside it. It opens Wallet & budgets with Spending limits you set first and the automation and its day of wakes filled in; for a schedule, that is the scheduled run it fires.

A run that stopped on a cap says on All runs which cap stopped it, in dollars: for example “this person’s month on the loop has $0.0007 left and the call needs $0.0021”. It also offers the way past it there: Give this person more where the person’s own month stopped them, or Give this loop more where the loop’s month did. It opens Wallet & budgets with Spending limits you set first and the loop, the person and the cap filled in. The person who was stopped never sees it.

A scheduled automation and an email delivery are paid from the wallet alone. Each firing of an automation costs a fixed amount and is held before it runs: if the wallet cannot cover it, the run stops before any step, and its row on Schedules says the wallet could not cover it. Each email a loop sends costs a fixed amount too, held before it is sent. An email the wallet cannot cover is not sent, and it is tried again for about three hours, so adding money in that time sends it. An email the mail service refuses is not charged. Neither counts toward a loop’s monthly cap or a per-user cap. Wallet & budgets shows what a loop’s emails cost this month on their own line under the loop, with the loop’s total for the month, and never in the spend shown beside its cap. A webhook delivery costs nothing. A sign-in code a page emails to the people it invites costs what an email costs, but it is charged after it is sent and never held, so nobody is kept from signing in by an empty wallet; your daily email quota bounds it (see Open a page to the people you invite).

A test case counts toward the wallet, the loop’s monthly cap and its own run budget, never toward a per-user cap. It is you checking a version before you publish it, not a user of the loop, so publishing a version with several test cases does not use up your own per-user cap.

A run that meets a limit still starts, then ends with the ending over_budget and the message you wrote for it. Your server reads that ending; there is no payment error code. Your users never see a budget, a price or a model, only the conversation. When the budget for one run stops an answer partway, the user reads the part already written ending in ”…”, then your message.

The last line of every run

end_messages in the record holds the user’s last line for each way a run can end: completed, over_budget, lapsed, check_failed, stopped, and otherwise for every ending you did not name. otherwise is required, so a person never meets an ending as silence. The platform never writes a closing line for you. When the run’s last reply already said those exact words, the person reads them once, not twice. When the reply that ends the run says nothing, your completed line is that reply: the person reads it as the conversation’s last message, in the console as in the chat on your site.

After a save that a form filled, the person reads your completed line. The model never sees what the user typed on a form, so it cannot know what the record holds. The first reply after such a save shows your completed line in place of the model’s words, whether or not that reply ends the run. The run’s record keeps the model’s words, marked as not shown. Write completed as what the user should read once their details are saved, such as “Thanks, your booking request is saved.” Every other reply keeps the model’s own words.

A run whose same step keeps failing in the same way stops rather than keep paying. With one of your users in the chat, it ends at once with your otherwise line, because nobody from your account is there to decide; in your own run on the console it asks you first whether it may try again.

Limits on who may start runs

Each loop’s identity.limits bound the people who reach it:

• per_ip — run starts, new-visitor sign-ins and searches from one network address in a window, for example 30/1m. They share one count, so a new visitor’s first conversation spends two: per_ip: 10/1h lets about five new visitors start one conversation each from one address in an hour.
• per_subject_runs — runs by one user in a window, for example 5/1d.
• concurrent_runs — optional: how many runs started through the run API may be running or waiting at once.

When one of these refuses, your user reads when to come back in words, for example “You have started as many conversations here as are allowed for now. You can try again in about 4 hours.” The answer is a 429, and its Retry-After header carries the exact seconds for programs.

Each route of the API also has its own rate limit. A refused request answers 429 with a sentence that names the limit, and a Retry-After header with the seconds to wait.

Members

Members lists the people who can sign in to the account, and the role each holds. Above the list it says what each role may do in one line, and More opens the full list of what only an owner may do. A member signs in with Google; your users never have an account here. An owner also sees each member’s sign-in address under their name, so two people with the same name, or with none, can be told apart; a member with no name is listed by that address. A member sees names, and each owner’s address, because an owner is who they ask; someone with no name reads as “an owner”, “a member” or “a viewer”. Where a member meets something only an owner may do, the console says so and names the owner to ask, with their address: “Only an owner of this account can add money to the wallet. Ask its owner, Sam Lee (sam@example.com), to do it, or to make you one.”

A viewer is for someone in your organisation who uses your pages but builds nothing. A viewer signs in with Google like any member.

An owner invites someone: enter their email address and a role, and press Send invitation. The email names who sent it, the account it is for, and what the role may do. They open the link in the email and sign in with Google as that address to join. A link that was already used, has expired or was withdrawn, or a sign-in as another Google address, opens the login page with a line that says so. An owner can make a member an owner, a viewer or a member again, and remove a member; a member or an owner can leave. Once they join, their Home names the account and their role, as in “You are a member of Acme.” Getting started and Your loop is live are an owner’s, so a member or a viewer does not see them. The account always keeps at least one owner. A role change applies to the person’s next request, with one exception: a page they already had open keeps working for up to 12 hours, and a live view for up to 15 minutes.

Owners also see the account’s Audit log, a tab of Members: the changes members made, newest first, and who made each one. Opening the Assistant panel is not a change, so it is not in the log.