Limitations & FAQ

#Getting started

I deleted my VM in Phala, but everycli still shows it. In the current CLI, a profile without a local VM record can use everycli reconnect to check the workspace and explicitly retire the stale binding with the same hotkey. Verify that you deleted the VM; a wrong-workspace token can also return 404. Recovery preserves identity and earnings but revokes old authorization. It does not delete cloud storage or create another VM. Recovery details.

What does os_catalog_changed mean? Phala no longer lists the exact approved OS image/hash. Update everycli and reconnect to fetch a reviewed replacement. The server will not substitute an unreviewed OS. OS-image guidance.

Why does the coordinator reject my profile while my Phala key tests successfully? These are different credentials. Deploy now attempts one automatic refresh using the same attached hotkey before any paid cloud request. If that cannot finish, check your computer's clock, then run everycli reconnect with the same local hotkey and original profile. It refreshes the signed miner authorization after confirmation without deploying a VM or discarding keys. The UI has Worker → Reconnect profile.

Can I edit many model offers at once? Yes. Every Models tab has row selection and select-all for editable models in that tab. Apply one discount or withdraw selected offers, review the exact quotes once, then inspect per-model results. Changed quotes are not auto-approved, and uncertain requests are not retried.

Where is my miner UID? The dashboard shows the UID from your last finalized registration check beside a shortened, copyable hotkey. Use Refresh UID to check current membership. A missing or mismatched lookup says UID not checked.

Is mainnet available? Yes. EveryFrame uses SN117 on Finney. These guides use everycli v0.8.7. Start here.

What should I update for v0.8.7? Run everycli update, then restart everycli ui. Worker updates now wait through temporary status errors before confirming completion. The CLI fixes do not require a new generation-worker image. If an earlier worker update stopped with unapproved_running_compose, run everycli reconcile and continue it from Worker → Worker software. To add Pika H3 Flex to an existing worker, save a Pika key and follow the Pika upgrade steps, including the one-time manual controller migration when worker automation is enabled.

Why does Start say an earlier start is unresolved? A saved start_intent records an earlier attempt whose outcome is not yet confirmed. everycli reconcile checks Phala's operation status and history without repeating a paid cloud request. If it cannot confirm failure or a running VM, inspect the existing VM in Phala. Start it there only when no operation is pending, then reconcile after it reports running. See stopped-worker recovery.

Why did a healthy worker report stale attestation? v0.8.2 fixes a ten-minute age limit that could reject an otherwise current admitted session. Readiness now checks its signed session expiry and a fresh heartbeat. If Phala reports stopped, start that same VM and wait for a new attestation. Expired sessions and offline workers are still rejected.

Is there a browser interface? Run everycli ui for private local setup and management. It checks keys before saving, keeps your setup step and lets you rename the local worker label. The compact every… name is a display label, not a change to your miner identity or signed VM name. Keep the pairing URL private; closing the UI does not stop hosting.

Is there a guided setup? Yes. Run everycli setup --wallet my-miner --hotkey default --provider fal --max-hourly-usd 0.06 in an interactive terminal. It checks registration, collects keys privately, initializes your profile and asks you to confirm a paid hosting quote. It stops on existing or uncertain deployments and prints a numbered checklist for activation, fresh admission, resuming and model offers. New setup does not accept --yes or --json.

Can I return to the remaining setup steps? Run everycli setup --continue in the original management profile. It reprints the checklist from the local deployment journal without network calls, activation or paid work; use status and doctor for live readiness. It supports --json without a terminal. Reconcile uncertain operations first; never deploy a duplicate VM.

How do I see a command's options? Use everycli help deploy or everycli deploy --help. Every command has its own help and example, with no profile required.

Does “No local miner profile found” mean my hotkey is unregistered? No. Use the same OS user, network and --state-dir as before, or initialize with your hotkey on a fresh device. Do not deploy a duplicate worker. init checks finalized membership separately; if the hotkey is unregistered, it names SN117 and prints a suggested btcli registration command.

Do I need an invitation or miner token? Not for a new public mainnet miner. init proves ownership of your registered hotkey and downloads the signed configuration automatically. Exact workload attestation remains required.

Does register-hotkey register me on chain? No. It checks finalized membership and records your identity locally. Register with your wallet tool first. Everycli neither pays registration fees nor signs on-chain transactions.

Why does my CLI still ask for an invitation? Check everycli --version and run everycli update. If an old binary is shadowing it, check command -v everycli. Existing token-based deployments need a coordinated migration; do not delete their credentials or deploy a duplicate VM.

Why did my upgrade not show download progress? The installed binary performs the upgrade. Older versions can retain their old output during that upgrade. Current releases show readable stages and download progress by default; --json suppresses progress. Redirected logs use plain milestones. See upgrade everycli.

Can I upload my wallet to support? No. Signing uses your local hotkey file; neither the coordinator nor VM receives the private key. The current signer requires an owner-only, unencrypted sr25519 JSON keyfile. See wallet compatibility.

#Models and money

Are all providers ready for jobs? No. The reviewed CLI accepts 11 generation-provider key types, but a saved key does not enable an unpriced or incompatible route. The catalogue reviewed 31 October 2026 has 100 contracts, 59 priced across 9 providers. providers explains release permissions; offers shows model readiness, pricing and bids. Before setup, offers shows the signed public catalogue without a wallet, provider key or VM. A listed new provider may require a newer compatible release. Traffic is not guaranteed.

Why can I offer discounts on only three models? Your existing worker may still use the legacy configuration. Run everycli update, then everycli worker-update on the original management profile. Public miners receive compatible signed updates for their own VM; fresh verified attestation unlocks the expanded permissions. Inspect offers and make new offers explicitly. Do not redeploy, edit signed files or copy old bids automatically.

Why does a MiniMax model need Fal? The provider route determines the billed account. MiniMax through Fal uses a Fal key; direct MiniMax is a different contract.

I resumed. Why is there no work? You also need a current model offer, fresh admission, matching credentials and capability, no pause and available customer demand. Run doctor, status and offers. Registration or deployment does not guarantee assignments.

What do I pay? Your chain registration, Phala compute/storage and actual provider usage. The hourly flag caps the compute rate only. There is no automatic total-budget cutoff. Submitted requests can cost money even if they fail or earn no reward.

Does earnings show money already paid? No. It shows reviewed or pending coordinator accounting, not your wallet balance. Eligible work can contribute to validator weights and mainnet alpha emissions; approval, submission, reveal and actual receipt are separate. There is no automatic USD settlement. See rewards.

Does bidding lower my provider bill? No. It lowers your reward target and affects assignment odds. Review the costs before offering a discount.

Does a 10% miner discount currently save customers 10% credits? Not yet. The 13 October live test confirmed discounted miner work value, but the website still charged 30 credits for a video instead of 27. Customer-credit pass-through remains unresolved; do not describe it as a shipped feature.

#Hosting and operation

How do I update the worker without downloading JSON? On everycli v0.8.2, run everycli worker-update from the original management profile. It discovers the compatible signed package, updates the same VM and restores its previous accepting/paused state after attestation. Use --check to inspect availability first. Existing offers and discounts stay unchanged. See worker updates.

How do I check whether my miner is working? On the original management device, run everycli health for a green/amber/red readiness table, then everycli status for deployment and job activity. All green means the current checks passed; it is not a paid generation test or balance check. Zero active jobs is normal when idle. Historical accepted jobs show past completed work, not proof that every model works now. Both commands support --json. See read the health table.

Why does a saved Vivix key fail a health check? A release-permission failure means the signed worker configuration does not permit that key—not that the provider rejected it. Updating everycli alone does not update the deployed worker. Other supported providers may still serve, but the unresolved check prevents an all-green result. Read everycli offers for model readiness; do not create a duplicate VM.

Which Phala key do I need? In Phala Cloud, select the intended workspace and open Settings → API Tokens → Create Token. Do not use Private AI → API Keys: those are inference keys, not cloud-management tokens. Save the full workspace token with everycli set-api-keys --provider phala. If you saved the wrong kind, replace only that local credential; you do not need a new hotkey or miner. See token setup and recovery.

Do I need a GPU or my own server? No. Install the prebuilt CLI locally; it deploys a small Phala TDX worker. Generation happens at the provider.

Can I use a normal VPS or my own TDX host? Not with the current public configuration. It pins the Phala workload, approved OS and KMS policy. Unknown measurements are rejected.

Do I need GitHub registry credentials? No. Public downloads and the approved public worker image do not require a registry login.

Why is doctor not ready? Before deployment, missing workload and attestation checks are expected. After deployment, inspect admission status. After activation or key changes, wait for a fresh post-restart session. An active model offer is also required for routing.

How do I change API keys? Use set-api-keys, then apply-api-keys for an already activated worker. Wait for fresh admission, then resume. Local removal does not revoke a leaked key at its provider.

Does miner authorization expire? Current authorizations do not expire. For a legacy profile, run everycli reconnect with the same hotkey, then everycli apply-api-keys once to install non-expiring worker authorization. The separate signed setup configuration refreshes automatically before management changes in v0.8.1. Short-lived TEE sessions and fresh request proofs continue to protect each connection. See miner authorization.

My terminal died during deploy. Run reconcile. It checks the saved operation without blindly creating another VM and can finish the public app binding. Do not erase your state or repeatedly retry an ambiguous paid operation.

Does stop end all billing? No. It requests shutdown after work is idle and retains storage. If it returns while jobs remain, run it again after they finish. stop --force can stop the verified VM during a coordinator outage, but may lose in-flight work. To remove the VM and storage, use delete --app-id EXACT_APP_ID, confirm the irreversible action, and check completion. Other resources and provider subscriptions are separate; confirm final charges in Phala Billing.

Can I replace a worker from another computer? Yes, deliberately—not by blindly running deploy. Initialize with the same hotkey and save a Phala workspace token that can access the old VM. The CLI/UI verifies its signed identity before deletion, records the operation and confirms cloud removal before replacement. The new VM must pass fresh attestation. Follow replace a worker from another computer.

Does a CLI update require redeploying a healthy worker? No—do not delete the VM. everycli update updates the CLI/UI. To gain worker failure-reporting and balance improvements, run everycli worker-update --check, then review everycli worker-update when a compatible package is available. The signed update restarts the same VM and requires fresh attestation; upgrading only the CLI leaves the deployed worker unchanged.

Can the operator see my prompts or keys? The coordinator is the source of jobs and sees prompts and outputs. Provider keys are encrypted to the admitted workload and are not exposed through normal status or log flows. The local credential store is unencrypted; your workstation, approved release and Phala KMS remain trusted.

#Current limitations

• No guarantee of traffic, provider reimbursement or profit.
• No automatic total-budget cutoff or USD settlement; VM deletion requires explicit confirmation.
• No encrypted local keychain storage or encrypted-wallet reader.
• No automatic migration of old token-based workers.
• No automatic enabling of every catalogue contract or guarantee that every model has passed a paid test.