Review and lifecycle

Before a model receives traffic, your provider and endpoint are reviewed, its public name and prices are approved, and its offer passes automated verification. The platform applies these checks to all providers and may re-review any provider, endpoint or offer at any time. The dashboard, the terminal UI, the CLI and the desktop app show the same statuses with the same labels.

Misrepresenting a model, its capabilities, its usage or its data handling leads to suspension and to withholding or reversal of earnings.

What is reviewed

Once your provider and endpoint are approved, a new technical setup goes live when our team approves it, verification passes and its prices are approved. Metadata and price updates reuse the technical pass. Hosted offers go live once their name and prices are approved. Offers remain subject to administrator review at any time.

Review decisions

Administrators decide with a written reason, which you see as feedback next to the status.

A hold on a model also applies to any other model on the same endpoint that resolves to the same public model, so renaming a native model ID can't get around it.

To resubmit a provider, correct its name in the terminal UI (Endpoint › Settings) or the dashboard and choose Resubmit for review. Endpoints work the same way with Edit and Submit for review. Saving never resubmits by itself. From the CLI:

numes provider review save-provider --profile NAME --name "New name"numes provider review submit-provider --profile NAMEnumes provider review save-endpoint --profile NAMEnumes provider review submit-endpoint --profile NAME

Model statuses

Each listing (one model on one endpoint) shows the first status that applies, in this order:

Three modifiers can accompany a status:

A rejected or returned model is listed even if no offer was ever created, so you can always see and answer review feedback.

When review proposes a different public name, for example to map an imported model to an existing catalogue entry, the native ID used for upstream requests stays the same. Confirm it with Accept name; your capabilities and prices are kept. Past requests keep their original model.

Endpoint statuses

Provider statuses are In review, Changes requested, Rejected, Suspended, Approved and Deleted.

Editing an approved endpoint's connection, credentials or data policy saves a separate candidate. The approved setup keeps serving with Update in review until you submit the candidate and it's approved. Applying it creates new offer revisions. Changing the connection target or dialect requires full verification after review; credentials and data-policy changes reuse the existing pass.

Upstream account problems

When the upstream account behind an endpoint runs out of credit or quota, or the upstream rejects its key, routing stops sending the endpoint traffic. The endpoint shows Not serving with the reason upstream_funding_required or upstream_key_rejected. Customers' requests go to other providers in the meantime.

Top up the upstream account or fix the key. You don't need to pause, resume or republish: routing tries the endpoint again by itself and resumes traffic once a request succeeds.

Dormant endpoints

An endpoint whose agent hasn't connected for a long time shows Offline (or Not connected) with the reason dormant. Nothing changes on its own: its models stay off routing and the endpoint stays registered. The provider page lists it under Needs attention with the date it lost its agent.

• The machine is gone. Delete the endpoint (see Deleting supply).

• The machine is coming back. Start the agent. If its credentials were lost, use Reconnect agent.

Verification

Verification proves that an offer works end to end through the same path customers use: the gateway, your connection, the agent and your source. Automated checks exercise every capability you declare (streaming, usage reporting, tools, structured output, media and cancellation) with synthetic requests, never customer data. For chat models they include objective quality checks.

Some checks are optional and appear under Optional checks. They're recorded as evidence and never keep a model from going live.

The platform also runs additional, unannounced checks, including behavioral analysis, to confirm that endpoints serve the model they advertise.

Hosted offers aren't verified before they go live. They show Checking only while recovering after repeated failures.

Verification and retries

A technical pass has no daily expiry. Full verification runs for a new model, changed model weights, deployment, tokenizer, prompt template, connection target or dialect, encryption mode, or added capabilities after our team approves that setup. Removing capabilities, changing context or output ceilings, prices, capacity, location, data policy, credentials or sharing does not rerun the full suite. These changes still follow their own validation and review rules.

Approved full checks have bounded automatic retries. Invalid configuration, rejected authentication and unsupported capabilities wait for repair and review. Further full checks require our team. Recovery checks can be retried after fixing the source. Checks run only while the endpoint is connected; a disconnected endpoint's models show Not serving with the reason endpoint_offline until it reconnects.

Fixing a failed check

The failure detail names the failed check and an error code: configuration_invalid, endpoint_unavailable, authentication_failed, model_unavailable, unsupported_capability, protocol_error, invalid_response, usage_evidence_missing, cancelled, timeout, activation_policy_failed, gateway_unavailable or coordination_lost. The last two are platform failures and never count against you.

Where to see it:

• Dashboard. Expand the model in the provider overview to see recent checks and what failed.

• Terminal UI. Last check on the model's Overview.

• Desktop app. The model's Verification details.

Each shows the failed check, what happened, whether retrying can help and the next steps. The exact codes are under Details in the terminal UI and Technical details in the desktop app.

The dashboard's Last check shows a passed date only when a successful check is retained. A failed check without a retained pass shows the failure instead of a passed date.

Then act on the cause:

• The source was down or misconfigured. Repair it, then retry a recovery check or contact support for another full check. In the terminal UI, press t on an endpoint (all failed models) or a model; in the dashboard, choose Check again. From the CLI:

  Shell

  Copy Shell code

  numes provider verification retry --profile NAMEnumes provider verification retry --profile NAME --model llama3.2:3b

  A retry first checks locally that the source, credentials and connection are ready. It doesn't publish anything.

• The offer declares something the source can't do. Retrying won't help. Press p on the endpoint to revalidate and republish, or turn off the unsupported capability for that model and publish.

• activation_policy_failed. The check passed, but the revision couldn't go live, for example because its public name or a parent approval changed. The detail names the step, such as identity_review_required or parent_approval_required.

A transient failure never needs a fake edit or a new revision.

Before you publish a self-hosted model, the agent runs its own capability checks against your source. If one fails, nothing is submitted, and the terminal UI or desktop app shows the failed check with next steps. In the terminal UI, press d for the exact codes and e to edit the model. Your selections are kept, so you can fix the source, or turn off an optional capability, and retry.

Recovery after repeated failures

If a model fails repeatedly in customer traffic, routing stops sending it traffic until it passes a targeted recovery check. Other models on the endpoint keep serving. The model shows Checking with the reason "being checked again after failures". Failures caused by customers or by the platform aren't counted against you.

Only a passing check returns the model to Live; heartbeats and discovery can't. If recovery fails, the model shows Check failed with the reason recovery_failed: fix the source and choose Check again. Recovery checks test readiness and one declared capability; they retain the model’s original technical pass.

Hosted models recover the same way. Their recovery check goes through your upstream key, which bills it like an ordinary request.

Pausing and stopping

You can pause an endpoint once it is approved. Pausing one in any other state is refused, and Resume stays available if an administrator suspends the endpoint after you paused it.

Pause to take supply out of rotation, for example during maintenance. A pause stops new requests; requests already running finish. A stopped agent still looks like supply that should be working, and its models may need checking again when it returns.

Reconnecting the agent

During planned gateway maintenance, the agent reconnects automatically. A retiring gateway allows pending stream connections to arrive for a short window, then refuses new stream connections while accepted requests finish within their deadlines. Keep the agent running; you do not need to replace its credential. Losing both gateway connections can interrupt work, and uncertain requests are never replayed automatically.

The endpoint credential is the secret your agent uses to connect. When an endpoint shows Not connected because its credential was revoked or its connection must be set up again, choose Reconnect agent:

• Terminal UI. On the endpoint, open Settings and choose Reconnect agent. It issues a new credential, stores it in the profile's owner-only secret store and restarts the endpoint if it was running. Models and terms are kept.

• Dashboard. Open the endpoint's actions and choose Reconnect agent. The new credential is shown once. Use this when the agent reads its credential from an environment variable, then update that variable.

Either way, the previous credential stops working immediately and requests running on it are cancelled. The endpoint, its models and their history are unchanged.

If you believe a credential was exposed, reconnect the agent, ask platform support to revoke the endpoint's credentials, or delete the endpoint.

To replace an upstream source key, use the terminal UI endpoint settings or numes provider source configure, or Replace key for hosted sources.

Deleting supply

• Endpoint. In the dashboard, open the endpoint's actions and choose Delete endpoint. Its agent access is revoked, its offers retired and new requests stop while running ones finish.

• Provider. Owners and administrators can choose Delete provider and type its name to remove it with all its endpoints. Provider operators can delete endpoints but not the provider.

Deletion keeps your history, including usage and earnings. Your balances and payout access remain, subject to any holds. There's no restore: a returning machine must register a new endpoint and go through review again.

Removing a profile in the terminal UI, the desktop app or with numes provider profile remove also deletes its endpoint, then the local files. Choose the keep option (--keep-endpoint) to delete only local files; the endpoint then shows Offline until you delete it in the dashboard.

Next steps

Review updates

A review decision records the selected model's exact submitted terms. Existing mapping, price and activation requirements still apply. Other pending declarations that can reuse an approved mapping advance on a later reconciliation pass; they do not delay the selected decision. Rejected declarations stay closed, and a blocked completion needs its reported cause fixed before it is retried.

If a dashboard decision response is lost, its outcome is unconfirmed. Retry the same decision using its original receipt rather than submitting changed terms.

Public names after a catalogue refresh

When your upstream refreshes its model catalogue, an update to the same source keeps its reviewed public name. Changed prices and capabilities still go through their normal review and verification. You don't need to confirm the same name again when your accepted offer already uses it. If review changes the public name, confirm the replacement with Accept name before the update continues.