Day-to-day operations

These examples use the default mainnet SN117 profile. Add --state-dir /absolute/private/profile consistently if you manage several miners.

Prefer the dashboard? Run everycli ui and follow the everycli UI guide for balances, batch offers, key changes, updates and worker controls.

#Check on your miner

everycli health
everycli status
everycli doctor
everycli providers
everycli balances
everycli offers
everycli jobs
everycli earnings
everycli status --json
everycli health --json

• Health shows a green/amber/red readiness checklist, plus separate job activity. Start here on the original management device.
• Status shows local phase, cloud workload, signed coordinator state, offers and job activity as tables by default. everycli status --json retains the full structured fields.
• Doctor checks readiness. Missing workload or attestation is normal before deployment; after activation, check for fresh admission and an active offer.
• Providers reports key presence and release permission, never key values. It does not query balances or prove model access.
• Balances reports account-credit snapshots in USD or native provider units, with source and age—not per-miner spend or profit.
• Offers reports current quotes and bids. Stale, withdrawn or absent bids cannot receive work under discount-lottery-v1.
• Jobs reports all-time activity grouped by model, also shown in Overview. Completed counts distinct accepted jobs; failed and cancelled/expired counts are attempts. These counts are not proof of payments or alpha received. Use everycli jobs --json for structured data.
• Earnings reports review-held, approved and disputed accounting. It is not a wallet balance, on-chain payment receipt or profit calculation.

Overview and everycli earnings show readable serving-fee tables. Missing provider costs or on-chain measurements are not treated as zero or net profit.

#Individual job history

Use everycli jobs to read private job history, or filter it:

everycli jobs --status completed --limit 20
everycli jobs --status failed --model studio/fal/minimax/h3-max-turbo/text-to-video
everycli jobs --summary
everycli jobs --json

Use the returned cursor with the same filters to continue a page. Changing status/model filters invalidates that cursor. History excludes prompts, media, credentials and other miners' jobs. Completed means accepted delivery, not alpha paid. Earnings is reviewed work value; actual rewards require chain evidence.

#Read the health table

Use everycli v0.8.2. everycli health checks the same local profile, permissions, signed configuration, provider-key permissions, operation journal, coordinator and cloud binding as doctor. It also checks fresh heartbeat/session evidence and worker support for your active model offers.

PASS is green, WARN is amber and FAIL is red. Missing evidence is not treated as success. Colors appear in supported interactive terminals; piped output remains plain text. Set NO_COLOR=1 to disable colors; the state words remain visible.

All green produces All readiness checks passed. It means the checked miner is ready based on that snapshot—not that traffic, provider funds, successful future generations or earnings are guaranteed. The command does not submit a paid generation, check API balances, activate keys, resume work, restart a worker or create a VM.

Zero active jobs is normal when idle. Historically accepted jobs show evidence of completed work; historical failures and other job states are listed separately. Neither an old accepted job nor an idle worker proves every model works now. Check supported provider funds separately with everycli balances.

An active offer with stale pricing or unsupported worker capabilities needs attention. Inactive or unavailable catalogue entries do not by themselves fail health. A saved optional provider key outside the signed release prevents an all-green result, but does not by itself stop other supported providers from serving. For example, a Vivix release-permission failure is not proof of an invalid Vivix key; upgrading everycli alone does not update the worker.

everycli health exits with 0 only when all checks pass, or 2 when a check fails or cannot be verified. --json returns structured checks instead of the table. status is an overview, not the all-green exit-code gate: use health for readiness monitoring.

#Connect from another device

Install everycli on the new device and use the same miner's supported local hotkey file:

everycli init --wallet my-miner --hotkey default
everycli status
everycli offers
everycli earnings
everycli balances

Use your actual wallet name; initialization needs the private hotkey locally, not just its public address. Keep that file owner-only and do not send it to support. These commands do not create a VM or require generation API keys.

The signed coordinator view describes the existing miner. A fresh device has no local deployment record or cloud credentials, so its local phase may say not_deployed and cloud, health or doctor checks can be incomplete even when the remote worker exists. Do not deploy again to fix that display. A hotkey-only login does not restore its deployment state. Keep using the original management profile, or deliberately replace the old VM using the separately confirmed flow below.

#Replace a worker from another computer

In the current CLI, initialize the same hotkey and save a Phala workspace API token for the account hosting the old VM. everycli status lists workloads matching this miner's signed name. This is replacement, not importing the old management profile.

everycli status
everycli delete --app-id EXACT_APP_ID
# Repeat that same delete command until it reports deleted.
everycli deploy --max-hourly-usd 0.06

Deletion is permanent: active work and VM storage are lost. Both deletion and new hosting require explicit confirmation. A durable journal prevents duplicate DELETE requests after timeouts; a failed lookup is never proof of deletion. The new deployment is blocked until deletion is confirmed, and checks coordinator replacement support before spending on hosting. The coordinator verifies the old binding, invalidates old sessions and requires fresh attestation on the new VM. Then follow activation, fresh admission and resume as for a new deployment. Model offers remain unchanged; verify them before accepting work.

The UI offers Delete and deploy again for the same flow. If you close it, use the Worker page's Check deletion action before starting a replacement. Do not delete a worker you intend to keep running.

Balances require an available snapshot from the management device or a compatible balance-reporting worker, as described below; signing in from another device does not query provider accounts by itself.

#Recover an interrupted initial preparation

If adding a key reports reconciliation_required, and status shows phase: provision_intent with a null local app ID, update to v0.8.2 and run:

everycli update
everycli reconcile

The UI equivalent is Re-sync operation. Recovery requires an unbound, idle coordinator and a successful complete Phala workspace inventory with no matching workload. It archives only an uncommitted initial preparation in owner-only deployment-recovery.json, preserves credentials and the hotkey profile, and does not create, retry or delete a VM. If it succeeds, save your API keys and run everycli reconnect to fetch the current signed deployment before deploying.

This is not a reset command: committed/uncertain creations, replacement deployments, pending worker updates, outages and conflicting cloud state remain blocked. Do not erase the journal or repeatedly run init to bypass them.

#Remaining API credits

For an existing miner on a fresh device, first follow connect from another device. A balance snapshot alone does not configure a profile.

Use everycli balances. Fal now reads balances with your normal generation key; a separate billing key is optional. BFL and Runway balances are also supported. OpenRouter account-credit reads may need separate billing credentials:

everycli set-api-keys --provider fal-billing
everycli set-api-keys --provider openrouter-billing
everycli balances

Only configure accounts you use. These optional billing-only keys stay on your management device; do not replace generation keys or run apply-api-keys for billing-only changes. Phala uses its existing local hosting key and displays paid plus granted credits, excluding post-paid limits and outstanding invoices.

To read balances from a second, hotkey-only device, run this on the initialized management profile:

everycli balances --publish

Then use everycli balances on the second device. No API keys are transferred. Owner-reported snapshots are marked stale after 15 minutes—not live provider queries from your laptop. Publish again to refresh them. Workers on the separately signed balance-reporting image can also send periodic, attested reports using their already-deployed generation keys. Updating the CLI alone does not enable that worker feature; use everycli worker-update when a compatible package is available. Phala hosting and provider billing/admin keys remain local and are not sent to the worker.

Shared account balances must not be added across miners. unavailable means the query failed, the response changed or billing permission is missing; unsupported means this snapshot does not support that balance lookup. From v0.4.1, the CLI displays native Vivix W credits and the updated worker checks deployed balances once per minute. Run both everycli update and everycli worker-update; upgrading only the CLI does not change the deployed worker. A credits are not W credits, and neither is presented as USD.

#Change API keys

everycli set-api-keys --provider fal
everycli providers
everycli apply-api-keys

Saving a key only changes local state. For an already activated worker, apply-api-keys asks for confirmation, drains work, refuses to restart while jobs remain, verifies admission and encrypts permitted saved keys to the pinned app key. Wait for fresh post-restart admission, then:

everycli status
everycli resume

To remove a local key, use everycli remove-api-key --provider NAME, then apply the remaining keys. Removal does not revoke the credential at its provider or remove it from a running worker until applied. At least one approved provider must remain configured; stop the worker if retiring the last one. Revoke leaked keys at the provider immediately.

After reviewing the removal, add --yes to skip its confirmation question. It prints one removal summary; with --json, it returns only the structured result. An absent local key is a no-op.

Before first activation, use activate, not apply-api-keys. See Providers & keys.

#Reconnect a saved profile

During deployment, everycli v0.8.2 automatically attempts one same-hotkey refresh if the coordinator's preflight rejects authorization. This happens before paid cloud operations; a later failed deployment is never automatically resubmitted. The live hosting quote still needs approval. If an older profile did not save its signer path, recovery can locate the exact same public hotkey in the standard wallet directory. Missing, unreadable, or mismatched keys require attention. Running init again on the same existing public profile refreshes it in place without discarding provider keys or deployment history.

A coordinator HTTP 401 means the saved miner authorization was rejected; it does not mean the Phala workspace token is wrong. A superseded authorization can be rejected even before its expiry. Check your computer's clock first, then use the same original profile and hotkey:

everycli reconnect --wallet my-miner --hotkey default
everycli doctor

You can use --hotkey-file FILE, or omit wallet flags when the profile has saved the signer path. The UI equivalent is Worker → Reconnect profile. Reconnect asks for confirmation, verifies finalized registration and hotkey ownership, and fetches the current signed configuration. It verifies the exact workload binding, preserving API keys, labels and deployment records. No VM is created, deleted, started or updated, and offers and accepting-work state are not changed.

An interrupted local commit is recorded in owner-only profile-recovery.json; rerun everycli reconnect to finish. Do not delete the journal. Pending cloud operations or worker updates must be reconciled first. A mismatched running workload fails closed; never bypass its signed configuration checks.

If the worker was deleted, it remains deleted after reconnect. Deploying a replacement requires a separate reviewed everycli deploy --max-hourly-usd LIMIT. An executable update never silently reconnects your profile or deploys a VM.

#Recover a VM deleted in Phala

If you deleted a VM directly in Phala, the coordinator can still remember its app ID. A fresh device without a local deployment record may then report reconnect_target_mismatch or cloud_workload_not_found on older versions.

Update everycli, reopen the UI, and use Worker → Reconnect profile, or run:

everycli update
everycli reconnect --wallet my-miner --hotkey default
everycli doctor

The CLI looks up the exact app and checks your Phala workspace catalog. If it cannot find the VM, it asks whether to retire the old coordinator binding. A 404 is not proof of deletion: the API token may belong to a different workspace. Only approve if you deleted that VM. Your hotkey signs the exact app ID and authorization version; Phala credentials are not sent to EveryFrame.

The server refuses recovery if the binding changed, the worker has a fresh heartbeat, or jobs remain active or uncertain. Successful retirement revokes old delegates, preserves your miner identity and earnings history, and leaves the miner drained. It does not delete any VM or storage or end cloud billing. Deploy a replacement separately after reviewing its hosting quote; new attestation is required before it can accept jobs.

This recovery path is for profiles without a local VM record. Keep existing deployment journals and reconcile uncertain operations; do not delete them to force recovery. Automatic updates and authorization repair never silently retire a remote binding.

#When an approved OS image is retired

os_catalog_changed or deployment_os_unavailable means the signed OS is no longer offered by Phala. deployment_catalog_unavailable means its availability could not be checked; that is not proof the image was removed.

The server checks the catalog every minute. New unbound deployments can refresh to a reviewed release before paying for a VM. Existing workers retain their exact OS policy and compatible worker-update path. Everycli accepts production OS versions only from the pinned coordinator's signed release and verifies the exact image hash. It never selects an arbitrary latest image.

Run everycli update and everycli reconnect. If the error persists, a replacement OS may still need server-side review. Catalog outages or missing approved images do not retire your existing binding. Do not bypass hash or attestation checks.

#Miner authorization

Current miner authorizations do not expire. The CLI and worker prove possession of their scoped delegate keys on each request. Revoking or replacing the hotkey binding still revokes those delegates.

The signed setup configuration has a separate validity period. From everycli v0.8.1, it refreshes automatically before management changes using an existing non-expiring authorization. The refresh changes only its dates; it does not redeploy the VM, change provider keys or restart the worker. Status and emergency shutdown do not require this configuration refresh.

For a legacy profile that still reports expiring authorization, migrate once using the same profile and hotkey:

everycli reconnect
everycli apply-api-keys
everycli status

reconnect creates non-expiring local authorizations. Applying keys installs the worker authorization after the normal drain and attestation checks. Do not edit signed certificates by hand.

#Stop and restart

everycli stop --drain-only
everycli status
everycli stop
everycli reconcile

Draining blocks new assignments while active work finishes. If jobs remain, stop returns with the VM still running. It does not schedule a later shutdown: wait for zero active jobs and run stop again.

Shutdown does not delete the VM or its storage. To stop during a coordinator outage, use everycli stop --force after reviewing its warning: in-flight work may be lost. It still verifies the exact cloud target. To remove this VM and storage, use everycli delete --app-id EXACT_APP_ID, then rerun until removal is confirmed. Check final charges in Phala Billing. Other VMs and provider subscriptions are separate; there is no automatic total-budget cutoff.

To restart the same saved workload:

everycli start --max-hourly-usd 0.06
everycli reconcile
everycli status

Wait for fresh admission and resume. If credentials were never activated, activate first. The hourly ceiling limits the compute rate, not total spend. start does not create a replacement VM.

If the exact workload cannot be verified or cloud management itself is unavailable, use the authenticated Phala console to inspect it. Never guess a deletion target.

#Recover a stopped worker

In v0.8.2, doctor and health report the verified Phala VM state. If the local phase says running but Phala reports stopped, everycli start --max-hourly-usd 10 can restart that same VM after you review the hosting quote. It does not create another VM. Reconcile once Phala reports running, then wait for accepted fresh attestation before everycli resume.

An unresolved start_intent or starting record blocks another start. Run everycli reconcile: it reads Phala's operation status and history, without resubmitting the request. A confirmed failed start can restore the local stopped phase; absent, unrelated or still-pending evidence leaves the operation unresolved. Review the failure in the existing VM's Phala Operations before trying again.

For recovery with an older CLI, inspect that same VM in Phala. If no operation is pending, start it there. Once it reports running, run everycli reconcile and everycli doctor. Fresh post-restart attestation is still required before resuming. Keep the existing profile and deployment journal.

#Logs, labels and uninstalling

everycli logs
everycli label --name "studio-worker-1"

Logs show bounded, sanitized structured worker events; they do not enable public logging. Use the authenticated Phala console for private or boot logs. Labels are local to this profile and do not change the signed cloud VM name.

Before uninstalling, stop or delete each managed VM as appropriate and confirm remaining charges. Run everycli auto-update --disable, locate the executable with command -v everycli, and remove that exact file plus its adjacent everycli.rollback backup if no longer needed. Remove installer PATH entries only if unused. Preserve private profiles and journals while any workload or uncertain operation remains. Uninstalling does not stop hosting or revoke keys.

#Apply an approved update

v0.8.3 adds the Pika provider and its signed worker configuration. To add Pika, use the Pika setup instructions. An existing automatic controller keeps its compatible environment during ordinary updates; Pika setup uses a reviewed manual controller migration on the same VM.

v0.8.2: run everycli update, then everycli worker-update to install the Fal availability fix on the existing VM. Workers with automatic updates already enabled receive it without the manual worker-update command. Confirmed provider models remain available when a later catalog batch fails or is rate-limited. The signed retired-model list can disable retired routes without changing offers, discounts or API keys.

The v0.8.2 worker checks provider catalogs before advertising models, reports fixed availability statuses, and refuses a paid submission when its catalog check has excluded that model. A definitive pre-submission refusal can move to another eligible miner; ambiguous paid requests are never automatically retried. These checks only narrow existing signed permissions. They do not change model IDs, grant new offers, or prove sufficient balance or successful generation.

The v0.8.2 worker preserves moderation, invalid-input and billing failure categories through signed reports and retries. It excludes echoed request data from classification and renews sessions for the coordinator's 12-minute maximum deadline. It retains provider balances and the safe-failover patch. everycli update updates the local CLI/UI; use everycli worker-update for the separately signed same-VM worker update when available. Do not delete a healthy VM to upgrade. Compatible packages preserve the VM's existing reviewed OS, including older deployments; fresh attestation is still required.

During v0.5.6 verification, a temporary paused worker passed real hardware attestation and delivered a fresh, signed Fal USD balance using its generation key. No customer requests or paid generations were submitted. BFL/Runway have parser and request fixture coverage, not live-account validation. This test does not certify every miner or provider.

Failure-category regression tests cover transient reporting errors, preserved Vivix/Fal categories and echoed-input exclusion. They do not submit paid provider jobs. The new worker requires a coordinator that accepts categorized failure reports; it never silently falls back to reasonless reports after an error.

On 15 October, a paused v0.5.7 candidate passed hardware attestation and received a 25-minute session. It had zero offers and jobs and no generation keys installed. Its temporary VM and storage were deleted after verification. This confirms the image's admission, not live paid-provider failure handling.

On 19 October, the paused v0.8.2 candidate passed hardware attestation and reported a current, signed Fal catalog snapshot: 51 contracts (41 listed, 8 deprecated, 2 removed), plus a fresh signed Fal balance. It had zero offers and jobs; no paid generation was submitted. Its temporary VM/storage were deleted and test miner disabled. This verifies Fal reporting from the pinned worker, not live OpenRouter/Vivix account access or paid generation behavior.

everycli update upgrades only your local CLI, with readable download progress, checksum verification and installation stages. Use everycli update --check to check without installing. Add --json to either command for one structured result or error without progress. See installation and upgrades.

With everycli v0.8.2, update an existing worker from its original management profile:

everycli worker-update --check
everycli worker-update

The check is optional and read-only. The update automatically fetches the latest compatible, signed package for your miner and VM; you do not need to find or download JSON. After one confirmation it:

1. Pauses new assignments and lets active jobs finish.
2. Updates the same VM, with generation keys disabled until fresh attestation.
3. Verifies the updated workload, reactivates previously enabled keys, and waits for fresh post-restart attestation.
4. Restores the miner's previous accepting/paused state. A paused miner stays paused; existing offers and discounts stay unchanged.

It does not create a replacement VM, start a stopped VM, automatically bid on newly supported models, or submit a paid test generation. Run everycli health and everycli offers afterward. Provider accounts can incur charges again when a previously accepting miner resumes work.

Progress and the summary are readable by default. For non-interactive use, explicitly approve the update:

everycli worker-update --json --yes

--json produces structured output without progress; it does not imply consent by itself. Waiting is bounded to about ten minutes. If the command pauses or is interrupted, rerun it on the same profile to continue from worker-update.json. Do not delete that journal or redeploy. Ambiguous commit or key-activation responses require reconciliation rather than repeating a cloud request. OS advisory locks are released when a process exits; a leftover lock file alone does not mean another CLI is running.

#Recover a v0.3.7 worker-update preparation failure

The current CLI includes the recovery fix for updates that change permitted environment variables, including Vivix. If the old CLI left update_provision_intent after update_compose_mismatch, first upgrade the CLI, then continue from the original management profile:

everycli update
everycli worker-update
everycli health

The new CLI verifies that the exact existing VM still runs its original signed configuration before retrying preparation. Preparation only caches a candidate; it does not commit or restart the VM. You can explicitly run everycli reconcile for this verification. Changed VM identities/configurations and uncertain commit or key-activation operations still fail closed. Do not delete the journal, redeploy, or remove keys to bypass the checks.

If no compatible package is published, the command reports that and changes nothing. This does not mean every provider is already supported. Signed release permission and current model offers still determine readiness; there is no arbitrary latest-image pull or verification bypass.

Advanced/manual use remains available with everycli worker-update --release signed-update.json. That path retains its separate reconcile, attestation, activation and resume steps; it cannot be combined with --check.

Changing only API keys does not require a worker release: use set-api-keys and apply-api-keys.

#Provider failure diagnostics

After installing the safe-failover worker patch, run everycli status --json and inspect coordinator.recentFailures. This private, signed response lists up to 20 recent submission failures for your miner, including the model, attempt, timestamp and a fixed safe reason. It does not expose API keys or raw provider responses. Older failures whose provider error was discarded cannot be reconstructed by updating.

A confirmed pre-generation auth, billing, capacity or missing-key rejection can be retried on a different eligible miner, within the same job's limits. This does not guarantee another miner is available. An ambiguous submission or an accepted paid generation is never blindly retried. See selection and pricing.

Routing excludes a provider with a fresh, attested non-positive balance bound to the current worker policy/session: W credits for Vivix, USD for Fal/OpenRouter. This is zero-only gating. Any positive balance remains eligible, even if it may not cover the next job; there is no per-job affordability check. The coordinator also rechecks before issuing a generation start grant. A credits cannot fund W1. Stale, unavailable or unsupported balance results are not treated as zero, and owner-published balances cannot override attested reports. External spending on a shared account may still change the balance between checks.

#Live verification and limitations

On 30 October 2026, an isolated attested v0.8.2 worker completed a FLUX 3 image and an H3 Max Turbo video. Both outputs passed receipt signature, job/input/output hash and TEE session-policy verification. Modified receipts were rejected by the verifier.

The operator-funded jobs stayed explicitly labeled as tests and were not reward-eligible or published to the gallery. The temporary VM and storage were removed after verification. These results verify those model/settings paths; they are not a guarantee for every provider, miner or alpha payout.

Use everycli offers and everycli doctor for your current provider and worker readiness. If a website request fails despite green readiness checks, preserve its render ID so assignment and provider diagnostics can be checked. Keep the existing workload and its journal.

#Recover an interrupted operation

everycli reconcile inspects uncertain cloud operations without blindly resubmitting paid requests. It can also complete the idempotent public app binding, so it is not strictly read-only.

Keep the profile, pending intent and app ID. Do not delete state or create a duplicate VM to clear an error. The OS releases the operation lock when its owning process exits, including after a crash. Do not delete a lock file to bypass a live command; use the saved journal to reconcile uncertain cloud operations.

#Running more than one miner

Each miner needs its own registered hotkey, separate private profile and exact workload binding. Use --state-dir on every command for that profile, including registration and key setup:

everycli status --state-dir /absolute/private/miner-two

Public onboarding binds one app per registered hotkey. Deleting a VM does not automatically erase its coordinator binding. Contact support before replacing or migrating a bound deployment.

#Non-interactive use

--json gives machine-readable output and never implies consent. Mutations that require confirmation need an interactive answer or explicit --yes. Secret input via --stdin is supported for one provider at a time; never place key values in command arguments.

New setup is interactive only and rejects --yes and --json; automate its individual steps instead. setup --continue reprints the local post-deployment checklist and supports --json without a terminal, but never performs the remaining steps for you. Without a terminal, removing a saved key needs --yes; an absent key returns a no-op without confirmation. CLI success exits with 0 and command errors or unsuccessful checks exit with 2. See command help and diagnostics.

The CLI prints sanitized error codes instead of provider bodies, credentials or stack traces. Preserve those codes when requesting help.