Leo Premium
Brave Bot can register itself against a Leo Premium subscription in a Brave install on this machine and spend its own credentials on the premium tier.
bravebot import-leo-creds # from the stable Brave install
bravebot import-leo-creds beta
bravebot import-leo-creds nightly
bravebot import-leo-creds development
bravebot import-leo-creds --forget # remove what was imported
Without a channel, stable is what importing means.
What it does, and does not do
This registers as a new device. Only the subscription's order id is read from the browser profile. The credentials themselves are generated here and signed by Brave, exactly as a second browser on another machine would do it. The browser keeps its own, and nothing it holds is spent.
Before anything is registered, the order is checked: an unpaid order, one asking for no credentials, one asking for an implausible number, and one without interval metadata are all refused. The Leo item is picked out of a multi-item order rather than assumed to be the only one. A batch is then verified against the issuer's key before it is stored, and tokens are matched by value rather than by position.
How credentials are spent
Credentials arrive in batches covering a few days and are spent one per request. A spent credential is
never offered again, consecutive spends hand out different credentials, and spending past the end of a
batch is refused. This holds across every bravebot running on the machine, delegates included: each
spend is recorded in the file before the credential is sent, so two sessions never present the same one.
A credential recorded as spent whose request was then abandoned is not offered again either.
A credential is never sent to the non-premium host. The premium host and the credential travel together, because a credential belongs to a deployment. A build with no premium host configured stays on the free tier rather than sending one where it does not belong.
Nothing is written back unless a credential was actually spent, so a session that spends nothing never touches the store. A write that is interrupted leaves the last good batch in place rather than half of a new one.
Where they are kept
In one file under ~/.bravebot, readable by your account alone before anything is written to it and
still after a re-import over an existing one: mode 0600 on macOS and Linux, and on Windows an access
list granting only your account. A platform with neither has the import refused. Nothing asks you for a password, and the file is not
encrypted at rest, as the browser these are imported from keeps the same secret unencrypted in its own
profile.
One file, not one per channel. You have one subscription however many Brave builds are installed,
so importing from Nightly replaces what was imported from Stable rather than sitting beside it. The
channel only says which browser profile to read the order id from, which is a fact about your machine
rather than about the agent, so --forget takes no channel. Forgetting removes the file, and is not
an error when there was nothing to remove.
A malformed or empty file is reported as such rather than treated as absent credentials, and a credential without a token is rejected on load. With no home directory there is nowhere a secret belongs, and that is reported rather than guessed at.
When a subscription cannot be read
Finding nothing has two causes, and they are not the same fact.
Nothing imported is the free tier working as intended, and nothing is said about it. An endpoint belonging to no environment, such as a local one, is this case too. No credential belongs near it by design. So is a machine with nowhere to keep credentials at all: reported as a broken batch, that would tell somebody who has never held a subscription that theirs could not be used.
A batch that exists and cannot be spent is reported to you, with the reason and what to do about it. That covers a file that could not be read, one holding nothing, one another version wrote, and one imported for an environment this endpoint does not accept. A credential only verifies against the deployment that signed it, so a batch from the wrong Brave channel is refused with the reason rather than passed over.
Only a turn that could have spent a credential is told. Which service answers is decided by the model you picked, and only Brave's endpoint has any notion of a subscription. A turn whose model is served by AWS Bedrock or by a gateway therefore says nothing about the store, however unusable what is stored may be. That turn ran on the model you chose, so there is no downgrade to report, and the credential it did not spend is one that service would not have accepted.
The downgrade is said out loud because its only other symptom is the agent appearing to get worse for no reason. The request goes out on the free tier, where the endpoint answers a premium model name by substituting a weaker model rather than failing: a 200 and an ordinary reply. A request that silently lost its credential still returns something that reads like an answer, and nothing else on your screen would connect that to the store.
Which tier a turn actually ran on
What /status says about the tier is what the last turn actually did, not what the build was
compiled with. Before the first turn it says premium is available, rather than claiming it is or is
not in use.
The opening screen draws the tier beside the confinement, from the configuration, in the same words
/status uses before a turn has run. It deliberately does not read the credential store: a
stored batch may be expired, exhausted, or issued for another environment, so finding one would not
settle the tier either. A pane too narrow for the wordmark still reports both.
Where the server reports using a model other than the one you asked for, both are shown: the
choice you made and the model that actually answered. This is said once when it starts happening
rather than every turn. The automatic entry (automatic-bravebot, shown as Automatic) resolving
to a concrete model is not a substitution: that is the server choosing per request, which is what
picking it means.
Requirements and limits
- macOS and Linux to import, including a machine with no desktop session. Nothing here needs one.
Importing is not supported on Windows, since no Brave profile is located there. A batch imported on
another machine and copied to
~/.braveboton Windows is spent normally. - The build must know the premium host. Without it, premium is unavailable.
- A credential only works against the deployment that issued it, so import from the Brave channel matching the environment the binary is configured for. A mismatch is refused before a request is made, rather than sent and answered with a 401.
- Sign in to Leo in that Brave install first: a subscription that is not in the profile cannot be imported.
- The stored batch is a bearer secret in a file you own. It is not encrypted at rest, which is what
the browser does with the same secret, and anything running as you can read it. That includes a
program
runlaunches, which is deliberately unconfined.
Checking what you have
bravebot doctor
reports whether a subscription is imported, which environment it was issued for, and how many of its credentials are still unspent. Counts only: a credential is a bearer secret, so none of it is printed.