FluxA Model Management

Keep a merchant's model balance funded so paid LLM calls succeed. This skill covers the money side only: discovering vendors, checking balances, reading spend history, and topping up. It does not make the model call itself.

All operations use the planner CLI.

Setup

Install the CLI globally:

npm install -g @fluxa-pay/planner

Auth is automatic: planner uses an fxalive key if one is set (planner login <key> or FLUXA_KEY), otherwise it mints a short-lived agent credential from your local fluxa-wallet. Topping up additionally requires a registered wallet (fluxa-wallet init) because it signs a spending mandate.

Onboarding walkthrough (first-time setup)

Use this the first time a user wants to get set up. Narrate each step and stop at the gate before spending. The final step charges real money (minimum 5 MC = $5) and asks the user to sign a spending mandate, so never run it without an explicit go-ahead.

Step 1 - Verify the setup (read-only, safe).

planner vendors    # confirms the CLI works and reaches the platform
planner balance    # confirms auth works; lists the user's funded merchants

Tell the user what you see. If planner balance says "no merchant balances yet", that is expected on a fresh account.

Step 2 - Pick a merchant with the user. Show the planner vendors list (slug, model count, price range) and ask which one to fund. Map a model to its merchant with planner models --vendor <slug> if they are choosing by model.

Step 3 - Confirm the charge, then get a go-ahead. State the exact cost before spending: "Topping up <merchant> with N credits costs $N (minimum $5) and grants N x 100,000 Units." Ask the user to confirm. Do not proceed without a clear yes.

Step 4 - Run the first topup.

planner topup <merchant> --credits 5

The first topup prints a mandate authorization URL. Handle it exactly as in [Topping up: the mandate step](#topping-up-the-mandate-step): ask before opening the link, then wait for the user to approve. The mandate is signed once and reused for later topups in the window.

Step 5 - Confirm it worked.

planner balance <merchant>   # balance should now show the added Units, status ok
planner ledger <merchant>    # the topup appears as a +N entry

Report the new balance back to the user. They are now set up; from here, use [The core loop](#the-core-loop) to keep merchants funded.

The core loop

planner vendors                      # discover fundable merchants (slug, models, price)
planner balance                      # check Units balance per merchant; flags low / owed
planner topup <vendor> --credits 5   # prepay Units (signs a spending mandate once)
planner ledger <vendor>              # optional: see what is burning Units

To map a specific model to the merchant you fund:

planner models --vendor <slug>       # models + Units rates for one merchant

When to top up

planner balance flags each merchant:

• low when the balance is under three days of recent burn

(balance < 7-day average daily burn x 3).

• owed when the balance is negative.

Rule of thumb for an agent: if a merchant is low or owed, top it up before the next batch of calls so a paid request does not fail with a 402.

Money model

• 1 Unit = $0.00001.
• 100,000 Units = $1 = 1 Monetize Credit (MC).
• Top-ups are charged in MC, minimum 5 MC ($5). 1 MC grants 100,000 Units.
• planner topup <vendor> --credits <N> tops up N MC.
• planner topup <vendor> --bundle <slug> buys a preset tier instead.

Topping up: the mandate step

planner topup settles via x402 and needs a signed spending mandate. The first top-up in a budget window prints an authorization URL. When you need the user to open it:

1. Ask first using the AskUserQuestion tool with options "Yes, open the link"

and "No, show me the URL".

1. If yes, open it: open "<authorizationUrl>".
2. If no, show the URL and ask how to proceed.

Once signed, planner reuses the mandate for later top-ups in the same window, so the user signs once, not once per top-up.

Command reference

Common mistakes