Providers & keys

Everycli v0.8.3 supports keys for twelve generation providers, plus Phala Cloud for hosting. You do not need every account: choose a provider supported by your signed release and enabled model offers.

Copy the full key, not a shortened prefix shown by the provider. Keys shorter than 10 characters receive an explicit minimum-length error and are not saved. Passing local format validation does not prove that a provider accepts the key.

Model existence, account access, available credits, and worker readiness are different checks. A provider may list a model publicly while excluding it from your account. The v0.8.2 worker checks OpenRouter's key-filtered catalog and Vivix's workspace model list. Fal metadata confirms that an endpoint exists, not that an account can run it. Other provider account access remains explicitly unchecked. No catalog check submits a paid generation.

If reporting a model problem, include the Everyframe contract ID, provider API ID, CLI/worker version and sanitized error code. Never send your API key. See contract IDs and current coverage.

#Which providers earn

The signed catalogue reviewed 31 October 2026 lists 100 contracts, 59 priced across 9 providers. More configured providers can expand your eligible model offers, but traffic is not guaranteed. Current offers and worker capabilities are authoritative.

Some catalogue routes require worker or CLI support beyond an older installed release. The table below distinguishes released credential support from priced contracts. Direct-provider requests and Studio traffic can use different routes.

#Pika H3 Flex

Create an API key in the Pika developer console. In everycli ui, open API keys, choose Pika, and save the key. The CLI and UI test it with a free read-only balance request. everycli balances shows spendable prepaid API funds, or the remaining spending allowance when postpaid billing is active. Account balances can be shared by several workers; do not add them together.

For an existing worker:

everycli update
everycli set-api-keys --provider pika
everycli worker-update
everycli doctor
everycli offers

If worker automation is enabled, run everycli worker-auto-update --disable before this manual setup. Once the updated worker passes fresh attestation and you have reviewed its offers, run everycli worker-auto-update --enable to enroll the new controller and credentials. Ordinary automatic updates preserve the compatible environment of existing controllers. The same VM, wallet, offers and discounts are retained.

Pika H3 Flex supports 5–15-second videos, native audio, first/last frames and image/video/audio references. 480p/768p are native; 1080p, 2K and 4K are upscaled. Reference mode needs an image or video, allows up to 12 references (9 images, 3 videos, 3 audio clips), and uses its own output and input-video rates. Quotes include the model's frame grid: a five-second request produces about 5.17 seconds. Set an offer for studio/pika/pika-h3-flex in All models after checking readiness.

#Phala Cloud hosting token

The phala prompt needs a workspace API token for Phala Cloud management, not a Private AI inference key.

1. Sign in to Phala Cloud and select the workspace where you want to deploy the miner.
2. Open Settings → API Tokens → Create Token. These tokens are workspace-scoped: they can access only that workspace's resources. Make sure it is the intended workspace and its cloud-hosting billing is configured.
3. Copy the full token, not the shortened token prefix shown in the list, and save it through the hidden prompt:

everycli set-api-keys --provider phala

The Phala token stays on your management device; it is not sent to the miner worker. The miner's generation provider uses a separate credential, such as the key entered at the fal prompt.

#If you saved a Private AI key by mistake

Replace only the local Phala credential, using the same OS user, network and --state-dir as your existing profile:

everycli set-api-keys --provider phala

After everycli init, check it without creating a VM:

everycli balances
everycli status

Inspect the Phala row with source local. A synced balance is an older snapshot, not a test of the token you just saved. A successful balance read confirms that endpoint's access, not every deployment permission. Failed checks include a safe reason and next step; run everycli update if your CLI only shows a generic error.

You do not need to register the hotkey again, erase your profile, rerun init just to replace this token, or restart an existing worker. apply-api-keys is for worker generation credentials, not the local Phala hosting token. If a deployment was already attempted, inspect status and reconcile any pending operation before retrying; do not create a duplicate VM.

#Save your keys

In everycli ui, keys are tested against free read-only provider endpoints before saving. Rejected keys are not saved, and an existing saved key is preserved when its replacement is rejected. Timeouts, restricted read permissions and unexpected responses save with an explicit unverified warning. Saved keys can be rechecked. An accepted account query does not prove every model is enabled or sufficiently funded. The CLI also tests keys with free read-only provider requests before saving them.

everycli set-api-keys
everycli providers

Input is hidden. Each prompt shows Saved — Enter keeps existing or Not saved — Enter skips. Entry ends with a plain summary naming changed providers, never key values; use --json with piped input for structured output. Keys are stored locally in owner-only credentials.json, not encrypted at rest. You do not need to maintain a .env file.

To change just one account:

everycli set-api-keys --provider fal
everycli set-api-keys --provider phala

For automation, pipe a secret manager's output into everycli set-api-keys --provider NAME --stdin. Never put the key itself in command arguments, logs or support messages.

#Providers and release support

A quoted contract still needs the installed worker's release permission, a valid provider credential, fresh attestation and an explicit offer.

Pika H3 Flex is supported in everycli v0.8.3. Existing workers need the Pika setup and worker update before serving Pika jobs.

A model served through Fal uses FAL_KEY, regardless of its maker. An OpenAI or Google model served through OpenRouter uses OPENROUTER_API_KEY. Follow the provider column, not the model brand.

#Billing-only credentials

everycli balances supports Fal, Phala credited funds, OpenRouter account credits, BFL, Runway, Pika and native Vivix W credits. BFL and Runway credits are converted at their published $0.01 per credit. Other unsupported provider APIs display unsupported rather than an invented balance.

From v0.5.6, Fal uses the normal generation key through an undocumented read-only balance endpoint. A changed response or failed request is unavailable, never zero. An optional Fal admin key uses the documented billing API: save it with set-api-keys --provider fal-billing (FAL_ADMIN_KEY for file import). OpenRouter account credits may require a management key saved with --provider openrouter-billing (OPENROUTER_MANAGEMENT_KEY).

Vivix uses its generation key and undocumented read-only /v1/balance endpoint. A credits are not substituted and W credits are not converted to USD. Malformed/missing W balances and request errors are unavailable, not zero. Worker balance improvements require a separately verified signed worker update; installing the CLI alone does not replace your VM.

These billing-only keys are saved privately on the management device and never enter the worker environment. They do not replace generation credentials. balances --publish shares only a dated balance snapshot for hotkey-only viewing. See remaining API credits.

#Vivix W1: top up W credits

For Vivix W1 mining, fund W credits, not A credits. Both balances can exist in the same account, but A credits do not fund W1 jobs. The deployed API key must belong to the workspace holding those W credits.

everycli balances and the API keys page show the native W balance. It is not converted to USD. A failed or missing balance query stays unavailable; it is not treated as zero.

#Apply changes to a worker

Saving or removing a key affects local state only. For an already activated worker:

everycli apply-api-keys
everycli status

The command confirms the mutation, drains work, refuses to restart while jobs remain and encrypts permitted credentials to the admitted workload's pinned app key. Wait for fresh post-restart admission, then run everycli resume.

To remove a local key, use everycli remove-api-key --provider NAME, then apply the remaining keys. Local removal does not revoke it remotely. At least one approved generation provider must remain configured; stop the worker if retiring the last one.

Without an interactive terminal, removal requires explicit --yes; --json does not imply consent. If you omit confirmation, the CLI explains how to approve it and leaves the key unchanged.

If that provider has no saved key, the command reports nothing removed, makes no credential change and does not ask for confirmation. A successful removal reports removal, not a save. Removing a local key never revokes its remote counterpart.

For initial setup, follow Deploy your miner and use activate after the first accepted attestation.

#Check what can actually run

everycli providers
everycli offers
everycli doctor

providers shows a readable table of key presence, release permission and a reason. Before initialization, permissions are Unknown (null in --json), not denied: there is no signed release to inspect yet. After initialization, permissions come from that release. A saved key does not confirm account access, balance or worker readiness. Use everycli providers --json for structured output; offers is where you inspect enabled model quotes and your bids.

Funding an unpriced provider route will not unlock it. Additional contracts require verified pricing, reviewed release permissions, live validation and explicit coordinator enablement. Installing a new CLI alone does not update an existing worker or its model allowlist.

#Candidate contracts

These are older fixed-contract examples, not the complete current provider catalogue. They do not establish whether another route to the same model is priced. See the generated provider table above and current offers. See Models & reward targets for current coverage.

The speech deadline is not a requested clip length; delivered speech must be between 0.1 and 120 seconds. Inputs remain {model, prompt[, seed]}; seed is accepted only by contracts that support it. Arbitrary voices, provider endpoints, durations, uploaded references and raw provider request bodies are not accepted.

#Recovery and key isolation

• Credentials go only to their authorized provider API. Output CDN downloads do not receive provider authentication headers.
• Paid POST requests are not automatically retried or redirected. An uncertain submission can incur cost without accepted work.
• Asynchronous jobs with a durable provider ID can resume polling against the original provider, model and deadline.
• The ElevenLabs adapter returns synchronous bytes; after a worker restart it cannot recover unaccepted output from provider history. It times out rather than submitting a second paid request.
• Only Google media GETs permit bounded redirects to a narrow allowlist, with authentication stripped. Other output downloads reject redirects.

Read key protection and trust assumptions before adding credentials.

#Balances in the UI

Open API keys in everycli ui to see each provider’s remaining balance, status and last check time. Use Refresh to check again. Saved-key balances can be checked before miner initialization, and refreshing preserves any key you are typing. Vivix is shown in W credits. Unavailable balances remain unknown rather than being displayed as zero.