mlx-optiq

Accounts and billing

How you sign in, how a machine gets a key, and what the dashboard does with it. For what a Boost is and how to ask for one, see Boost overview.

Signing in

Sign-in is Google only, and asks for nothing beyond your name and email address. That is deliberate: any sensitive or restricted scope would drag the project into Google's manual data-access review, and Boost has no use for your Drive or your mail.

The consent screen is company-level and verified, so you see an ordinary Google sign-in rather than an unverified-app warning.

What we store Your email address, a Boost balance, and one row per machine you connect. No prompts, no code, no repository contents.

The dashboard

The OptiQ Cloud dashboard: Boost balance with a buy button, a Connect a machine panel showing the optiq cloud login command, auto top-up, and the API tokens list.
cloud.mlx-optiq.com after signing in.

Four things, and deliberately not much else: your balance and a button to buy more, the command that connects a machine, auto top-up, and the list of machines you have connected.

Connecting a machine

A terminal cannot receive a browser redirect, so OptiQ uses the device-code flow. Run this on the machine that runs optiq serve:

$ optiq cloud login

  Your code:  EH4Y-67C6
  Approve at: https://cloud.mlx-optiq.com/link

Waiting for approval...
Connected. Token saved to ~/.optiq/code/config.json
Signed in as you@example.com - 128 Boosts available.
Restart `optiq serve` to start using Boost.

Open that URL, check the code matches what your terminal printed, and approve. The check is the point: approving is what grants a machine the right to spend your Boosts, so a page that granted one merely by being opened would turn a forwarded link into an attack.

How the key reaches your coding agent

It does not. Your agent never sees a cloud key, and that is the whole shape of the design:

  1. optiq cloud login writes the token into your OptiQ config, on your machine.
  2. optiq serve reads it at startup and holds it in memory.
  3. Your agent talks to optiq serve with whatever local key it already used. Nothing changes on its side.
  4. When a turn asks for a Boost, the server calls OptiQ Cloud with the token. The agent is never told, and needs no plugin.

So a compromised agent config leaks a local key, not a cloud credential, and pointing a new agent at OptiQ needs no secret at all.

Where the token lives ~/.optiq/code/config.json, written 0600. It is never placed in a repository file, and never sent to a model.

Machines and tokens

One token per machine. The dashboard lists the prefix, when each was last used, and a button to revoke it; only a hash is stored, so a token is shown once at issue and never again.

CommandWhat it does
optiq cloud statusAccount, balance, model and mode.
optiq cloud logoutRevokes the token, then forgets it locally.
optiq cloud logout --keep-remoteForgets it locally only.

Logout revokes by default because forgetting a working credential is not logging out: a laptop lost afterwards could still spend your Boosts.

Auto top-up

Off unless you turn it on. When on, it buys a pack once your balance falls below a threshold you choose, up to a monthly cap you set.

The cap is the part that matters. Automatic spending without one is how a runaway loop becomes a surprising invoice, so the cap is checked in the same statement that claims the top-up, and several Boosts arriving at once cannot each start their own purchase.

What you are charged for

  • One Boost per episode, however many cloud calls the tool loop takes.
  • An episode that produced nothing is refunded automatically.
  • A Boost that never reached the cloud is not charged at all.
  • Purchased Boosts are a one-off pack, not a subscription.