Spending cloud credit from a terminal
Anthropic gave every Claude Code account $250 of cloud-session credit, expiring in about five weeks. We had more than one account, so we had more than one $250. The question was how to spend it without burning the machine on the desk.
That machine is a MacBook Air with 16 GB, and we know exactly where its wall is: run the full unit suite and a browser suite at the same time and the kernel's memory watchdog reboots the box. The cloud sessions run somewhere with no wall we could find. So the work was to route as much as possible over there and keep the Air for what only the Air can do.
Three hours the long way, then the first page of --help
The first afternoon I opened cloud sessions through the browser: Safari, an AppleScript that sets the URL, JavaScript that finds the editable box, pastes the prompt, waits 800 ms, and clicks the button whose accessible name is "Send". It worked. It also stole the front tab on every launch, and when a session asked a multiple-choice question I needed more JavaScript to pick "Other" and fill the textarea through the native value setter. Fine, and ridiculous.
Then: `claude --help | grep cloud`. There is a `--cloud` flag. Three seconds.
It has one rule: it wants a real terminal, and refuses a pipe. So the final shape is a fifteen-line wrapper that starts tmux on its own socket, runs `claude --cloud "<prompt>"` inside it, answers the one-time "trust this folder?" prompt, and exits.
I am leaving the three hours in because they are the point. The complicated method worked; that is exactly why nobody checked the first page of `--help`.
The cloud's three walls are the Air's job description
Once launching was cheap, the sessions started telling us what they could not do, and each refusal became a rule.
**It cannot read your repos through the API** — a ticket lookup gets a 403 — so prompts carry the whole ticket, and the launch folder must be a full clone: a `--depth 1` clone gives the cloud a snapshot with no remote, and a finished branch has nowhere to go.
**It does not have your keys.** Anything that needs a token in the local keychain stays on the Air. The cloud writes the code and the tests; the Air runs the one command that needs a credential.
**It is not your operating system.** The containers are Linux; on a Mac `/var` is a symlink to `/private/var`, and three of six new tests went red locally over exactly that. Cloud does the work, the Air runs each result once before it merges.
That is the whole division of labor: a terminal as the dispatch desk, cloud sessions as the hands, the machine on the desk as the acceptance bench.
How the money went
About $60 a day, $5 to $7 per pull request, across a day that closed around fifteen of them and shipped two releases. The plan's weekly quota did not move; the gift is charged first. The cockpit barely wrote code — it read, merged, answered the sessions' questions, ran the local checks.
Two things that did not pay: asking a session to "write out the full report verbatim" (six refused; the safety layer reads that as extracting reasoning — if you want an artifact, have it push a branch), and launching from temporary local clones with no remote, which left twenty-three finished reports with nowhere to land.
The first account's credit ran out on the fifth day. Its line on the usage page did not go to zero; it disappeared. The second account still showed $250 of $250 — which is how we learned the credit is per account, not per person.
The second account, with nothing connected
The second account had never used Claude Code and had no GitHub connected. That turned out to be the useful experiment: what can a cloud session do with no repository access at all?
Quite a lot, as long as the work is read-only. We launched sessions from a full local clone with the review question in the prompt, told each one that its reply was the only artifact, and scraped the reply from the page. Five sessions — one on the account's default model, one cheap probe, three on Opus — cost **$7 in total** and produced four tickets, one of them a real P1 in a Durable Object that the machine on the desk could then confirm line by line. Under $2 per review. The cloud never needed a key, a push, or a "trust this repository" click; the terminal, the cloud, and the Air each did only their part.
Two flags worth knowing. `--model` travels to the cloud: `claude --model opus --cloud "…"` opens an Opus session. `--effort` does not; the session inherits the account's default, and the page will tell you when that default is the expensive one. Pick the model per launch, and set effort on the account.
One trap on our side: a script that reads the session page to see whether it is finished will call it "idle" during a tool call, because the "responding" status text only shows between tools. Wait for the verdict, not for silence.
The shape that stayed
A terminal as the dispatch desk. Cloud sessions as the hands — with a repository when they need to push, without one when they only need to read. The machine on the desk as the acceptance bench, doing what needs its keys or its operating system, and confirming what the cloud found before anything is filed.
Keep reading
-
Someone recommended a tool. We looked it up and did not install it.
A link arrived with a recommendation attached. The first answer I gave came from memory. What replaced it took one fetch of a docs page and one question about why a middle layer was needed at all.
-
A setting that turns itself off
A question about rebooting a laptop from outside turned, over three messages, into a different question, and then into sixty lines of shell whose only job is to undo a firmware setting when nobody remembers to. Neither half of that would have happened alone.
-
The 400 GB Shortcut That Ran for Zero Seconds
Why an ephemeral cloud sandbox quietly died in twenty minutes while a throttled MacBook finished 139 gigabytes.