Set up with an AI agent

Open your coding agent on the computer you want to use, then give it one of these prompts. The agent should inspect that machine, install the correct public build, and verify the result.

Create a node code on Nodes only for the first option. Put it in a private environment file on that machine; do not paste it into the prompt.

Set up an account-linked listener

Set up a WaveBeasts listener node on this machine. This is an account-linked sensor uploader, not the full game engine.

Official resources:
- Guide: https://wavebeasts.com/docs/nodes/
- Python listener: https://wavebeasts.com/download/wavebeast-node.py
- Account identity: GET https://wavebeasts.com/api/account
- Submission: POST https://wavebeasts.com/api/snapshot
- Both APIs use X-WB-Node-Token with my WB_NODE_TOKEN.

1. Inspect the OS, Python 3 availability, network access, existing WaveBeast processes/services, and real sensors. Reuse an existing working installation instead of starting duplicate listeners. Explain which sensors actually work. The client uses nmcli on Linux for Wi-Fi; it does not invent readings when nmcli or a sensor is absent.
2. Download the official Python file into a durable user-owned directory. It uses only Python's standard library. Read it before running it. No private source checkout or Go installation is required.
3. Use WB_SITE=https://wavebeasts.com and a private environment file for WB_NODE_TOKEN. Have me create a device on https://wavebeasts.com/nodes/ if I have no code yet. Do not put the token in chat, logs, shell history, a committed file, or a public service definition. Restrict the file to the current user. Read it without displaying its contents.
4. Verify the code with GET /api/account. Show only the account name/plan and device name; keep credentials private. A 403 means a revoked or invalid node code. Do not retry it indefinitely.
5. Run one cycle using WB_ONCE=1. Check the response/log, not just the exit code: this client may exit zero after a failed request. Confirm an accepted HTTP 200 snapshot and the number of real signals. No sensors is a setup limitation to report, not a reason to fabricate entropy or loop faster. If a code is the only available real input, help configure that explicitly.
6. Passive scans must wait at least 1800 seconds (30 minutes), even if next_snapshot_in or retry_after is shorter. Honor longer server waits and persist the last attempt across restarts. Include client.id, client.app_v and scan_mode=auto in snapshots. Report the installed version to POST /api/node/check-in using the node-token header. The supplied listener handles this. Never bypass the server's cadence. On connection failures, back off rather than busy-looping.
7. If I want it always running, use the OS-appropriate per-user background mechanism: systemd --user on supported Linux, launchd on macOS, or Task Scheduler on Windows. First verify the foreground run. Use absolute executable/script paths and an environment file or secure wrapper. On systemd use Restart=on-failure, RestartSec=15, PYTHONUNBUFFERED=1, and WantedBy=default.target. Do not create a root service by default. Explain whether it stops at logout, and arrange boot/startup only when requested.
8. Additional actual sensors may be supplied with WB_ENVIRON_URL (a JSON endpoint) or WB_SIGNALS_CMD (a command producing a JSON array of signals). Each signal uses kind, normalized strength from 0 to 1, and value. Test adapters separately; never log secrets. Do not use random or synthetic readings for gameplay.
9. Report the install path, sensor sources, service/task name, status, accepted snapshot result and cadence. Include exact start, stop, status/log and uninstall commands. Uninstall must remove the service and program without deleting unrelated files. Do not claim success until the real API test passes.

Set up local play and the GUI

Install the complete WaveBeast engine and browser GUI for LOCAL play on this machine. This is not the thin Python listener. No account or subscription is needed.

Official guide: https://wavebeasts.com/docs/local-play/
Public downloads: https://github.com/chvolk/wavebeast-dl/releases/latest
Asset URL prefix: https://github.com/chvolk/wavebeast-dl/releases/latest/download/

1. Inspect OS and CPU architecture and check for an existing engine/database on port 8777. Reuse a working setup and preserve existing data. Select the matching release asset:
   Linux x86_64: wavebeast-linux-amd64
   Linux aarch64/arm64: wavebeast-linux-arm64
   Linux armv7: wavebeast-linux-armv7
   macOS Intel: wavebeast-macos-amd64
   macOS Apple Silicon: wavebeast-macos-arm64
   Windows x64: wavebeast-windows-amd64.exe
   Do not guess for an unsupported OS/architecture. The source is private; use public binaries, not a source clone or an APK on a desktop OS.
2. Download the binary over HTTPS into a durable user-owned application directory, using a temporary filename until the download completes. If the release API provides an asset SHA-256 digest, verify it. Make it executable on Unix. Do not disable OS security checks globally; explain any platform-specific launch prompt.
3. Choose a durable, writable SQLite path in the user's application-data directory. Start the engine with -addr 127.0.0.1:8777 -db ABSOLUTE_DATABASE_PATH (quote paths correctly for this shell). The same settings can use WAVEBEAST_ADDR and WAVEBEAST_DB. Do not bind to all interfaces, expose it on the public internet, overwrite a collection, or use a temporary database.
4. Verify GET http://127.0.0.1:8777/capabilities returns JSON with engine=wavebeast. Load http://127.0.0.1:8777/ and check the GUI, styles, shop and collection. If port 8777 is already in use, identify its owner; do not kill unrelated processes. Use a different loopback port if needed and report the actual URL.
5. Demonstrate a real manual scan with a code I choose or genuine available sensors. Outcomes can be a beast, resources, or nothing. Respect the roughly 300-second yield cooldown; do not treat a non-beast outcome as failure. Explain that local collection and wallet are on this device and separate from the online account.
6. Restart using the same database path and confirm the collection/inventory persists. If automatic startup is desired, add a per-user systemd service, launchd job, or Windows scheduled task with absolute paths; verify its logs and avoid duplicate engines.
7. Optional account linking: use World > Link account and a node code from https://wavebeasts.com/nodes/. The World tab validates the code and displays account identity. Linking is optional. Submitted account scans are server-rolled; Premium imports of existing local beasts remain unverified and cannot trade or enter the ladder.
8. Optional shell-backed sensors require WAVEBEAST_ALLOW_EXEC=1. Only enable this if I specifically want trusted local command adapters; leave it off otherwise. Read /capabilities for the supported signal contract and use actual sensor values, not random numbers.
9. Report the installed asset/version, application and database paths, GUI URL, successful API/UI checks, and any unavailable sensors. Include exact start/stop/status/update instructions. Back up the SQLite database safely while the engine is stopped before replacing binaries; keep data separate from the executable. Uninstall must preserve my collection unless I explicitly request its deletion.

What a successful setup looks like

A listener has sent an accepted snapshot with real sensor readings and honors the server’s next allowed time. Local play opens a working GUI at http://127.0.0.1:8777, keeps its database in a durable directory, and survives a restart without losing the collection.