--- name: run-larry-prover description: Help a user set up and verify a Larry prover, including release checks, cost estimates, cloud configuration, and a first supervised run. Use when someone wants to help run Larry, including people without a technical background. --- # Help run Larry Guide the user from interest to a working prover with plain-language explanations. Do the technical preparation yourself. Explain each decision in terms of cost, reliability, and what the user needs to do. A prover supplies computing for Larry's thinking cycles and can earn payments; profit is not guaranteed. ## Start with the release and the user's budget Use the source at https://github.com/ahrussell/larry and the operator's published release. Clone into a dedicated directory if no checkout exists. Read `prover/larry/README.md`, `prover/larry/config.py`, `deploy/dstack/README.md`, and `deploy/release/README.md` from that revision. The configuration and runner code resolve discrepancies in dated documentation. Find the released agent address, chain ID, orchestrator, approved inference compose and image, and any required remote-publication and key-custody settings. Verify the chain and contract identities through a read-only RPC. A file named `candidate` or `burn-in` is not evidence of a production release. If the release is unresolved or the approved hardware/key service is unavailable to this user, explain the specific missing prerequisite and finish the preparation that can be done without it. Do not deploy a different Larry or change the approved compose to work around it. Before paid activity, establish the user's cloud/compute spending limit and the amount they authorize for bonds and gas. Reuse an already stated budget. Read the actual bond, auction terms, reimbursements, competition, and recent successful payouts. Estimate revenue separately from cloud charges, model costs, gas, and forfeiture risk, naming the sample window and assumptions. Testnet payouts are not earnings. Do not infer profit from an auction ceiling or a few successful runs. Do not promise ten-minute setup without measuring the entire path, including account provisioning. ## Prepare the setup - Prefer the production `dstack` runner, which rents a confidential VM for each cycle. The `local` runner cannot supply production hardware attestation. Use the cloud tooling and version documented by the checked-out runner; do not guess current CLI flags. - Prepare an isolated Python environment and install `prover/larry/requirements.txt`. Make the ABI artifacts required by the pinned client available through the repository's documented build path. - Help the user create a dedicated prover wallet, cloud account, and inference-provider credentials if needed. Explain these as the account that pays deposits, the computer rental, and the model budget. Keep secret entry local; never ask for private keys in chat or print them. Store local configuration with owner-only permissions and keep it out of Git. - Fill the documented environment with verified values: `AGENT_ADDRESS`, `RPC_URL`, `EXPECTED_CHAIN_ID`, `EXPECTED_ORCHESTRATOR`, `PRIVATE_KEY`, `OPENROUTER_API_KEY`, `DSTACK_COMPOSE`, and the cloud credentials. Apply codehash pins when the release supplies them. Include the release's required remote-publication settings and custody configuration; a run that settles but cannot publish is not complete. - Preserve the approved compose byte for byte. Its identity is checked on chain. Runtime secrets go through the supported encrypted environment, not edits to measured literals. An operator-held vault key is not something a public prover can invent or borrow; verify the release supports independent operators. - Set a transaction-value limit consistent with the user's bond budget. This limit does not cap aggregate cloud or model spending: configure provider budgets and explain that distinction. - Give the client a persistent, owner-only state directory. Bid salts and pending submissions must survive restart. Keep the client's exclusive lock enabled. ## Verify before unattended operation Run import/configuration checks and read-only connectivity checks first. `python -m prover.larry` is a live tick, not a dry run: depending on the current phase it can spend funds. Do not use it as an installation test before paid activity is authorized. Inspect the client's bid model. Never fabricate successful prior attempts, set `--forfeit-prior-attempts` to an invented count, or lower a risk estimate just to get a first bid. Help perform the documented supervised readiness run or explain the missing evidence. Within the authorized budget, supervise a real run using the approved release and production runner. Confirm its transaction receipt succeeded, the intended agent's cycle settled, required record publication completed, and the temporary VM was deleted. A transaction hash or local console result alone does not establish success. Report any residual VM so the user can stop its billing. Only after this succeeds, install the documented periodic tick with absolute paths to the environment and persistent state. Verify the scheduler can find its cloud CLI and credentials, that overlapping ticks retain the lock, and that failures reach an agreed notification destination. Do not message other people or subscribe the user to a service without authorization. ## Hand over a setup the user can operate Give the user the status of the first cycle, links to the public receipt and published record, where to see spending, and the next scheduled run. Provide exact local commands for pausing future bids and inspecting activity. Explain that pausing while a bid is committed does not remove the obligation to reveal and finish it: let an in-flight cycle complete before stopping, or disclose the potential bond loss. Document how to inspect and delete leftover cloud VMs and recover pending refundable funds using the client. Keep secrets out of the handover. If setup remains incomplete, name the actual blocker, what is ready, and whether any paid resources remain running. Avoid a generic success message.