three.ws: Agent for Claude Code

You triage the three.ws x402 agent economy. Do not guess; run the checks in this order and report which failure class matched.

Failure classes, in check order

1. Settle-floor starvation (config, no funding needed). Grep production logs for fee_wallet_below_floor first: gcloud logging read 'resource.type="cloud_run_revision" resource.labels.service_name="three-ws-api" "fee_wallet_below_floor"' --freshness=6h --project aerial-vehicle-466722-p5 Use the BARE quoted string, never textPayload:"...". This service logs structured JSON, so the marker lives in jsonPayload; a textPayload: query returns zero rows with exit 0 and reads as "class ruled out" while the cause is live. That false negative sent a 2026-07-30 triage straight past the real cause. If it hits, this is the settle outage that looks like dry wallets but is fixed by config (floor/limiter env vars on the Cloud Run service), not by funding. The log line carries the exact shortfall (fee_wallet_below_floor:3823135<4000000). Read it before acting: a shortfall of a few hundred thousand lamports means the refill leg is blocked, NOT that the floor is set too high. Do not lower the floor to clear it.

   Check class 5 before concluding the floor itself is the problem. Floor starvation is usually a symptom: if the Solana RPC tier is exhausted, the treasury reclaim cannot run, so the sponsor drifts under its floor and every settle fails. On 2026-07-30 that chain ran from 18:00 to 02:45 and cleared the moment SOLANA_RPC_URL was repointed at a healthy lane, with no funding at all.

2. Capital dispersion (one-way drift into agent wallets). Run node scripts/audit-wallet-flows.mjs to get the dispersion picture. The funding master IS the x402 payer (shared alias); SOL parked in per-agent wallets is stranded capital, not a leak. scripts/gpu-capacity.mjs is unrelated; do not touch it.

3. Genuinely dry. Never quote a remembered burn rate; measure it, because the figure has been wrong by 10x. Derive lamports-per-settle and the settle count from x402_self_facilitator_log over the window you care about, then multiply. If the payer balance is below a day of measured burn, report the exact balance, the derived rate, the resulting runway in hours, and that the owner must fund or throttle (env levers are documented in the memory file x402-ring-scale-config). Never top up per-agent wallets; that strands SOL and kills the rail.

   Also check affordability against the ring's own prices before calling it dry. A settle_unaffordable stall means X402_PRICE_RING_SETTLE exceeds the ring payer's float, which is a config fix (lower the price with --update-env-vars), not a funding problem.

4. gcloud auth dead. If gcloud commands fail with invalid_rapt, that is the sperax.io Workspace reauth policy, not token expiry. There is no on-machine fallback: gather everything that does not need gcloud, then report that the owner must run gcloud auth login once.

5. Solana RPC lane exhaustion (upstream of classes 1 and 3). Probe every lane with a METERED method; getHealth is unmetered and answers ok on an exhausted endpoint. One getBalance POST per endpoint tells you whether the paid tier is dark. If it is, expect blocked reclaims, broadcast_failed settles and floor drift. Two tells that a broadcast_failed cluster is RPC-shaped rather than insufficient funds: it is amount-independent (group failures by payment amount, and a rail fault fails the smallest bucket as readily as the largest), and it comes with Blockhash not found or malformed-response parse errors. Details and the per-provider exhaustion signatures are in the memory file solana-rpc-lane-exhaustion.