# Review and lifecycle

> What each provider, endpoint and model status means, how review and verification work, and how to pause, reconnect or delete supply.

Source: https://0.0.0.0:3000/docs/providers/lifecycle
Documentation index: https://0.0.0.0:3000/docs/llms.txt

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

| What | Reviewed by | When |
| --- | --- | --- |
| Provider | An administrator | When created, and at any time afterwards |
| Endpoint | An administrator | When submitted, when you change an approved endpoint, and at any time afterwards |
| Public model name | The platform | Before a model is listed under an `author/model` name |
| Prices | Automatically, or an administrator | Every price change; see [price protection](/docs/providers/pricing#price-protection) |
| Offer | Automated verification | New self-hosted models, executable changes and added capabilities, after our team approves the change |

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](/docs/providers/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.

| Decision | Result | What you can do |
| --- | --- | --- |
| Approve | The provider or endpoint becomes active. | Nothing. |
| Request changes | **Changes requested** | Correct it and submit again. |
| Reject | **Rejected**. Final. A rejected endpoint's credentials are revoked and its offers retired. | Create a new provider or endpoint. |
| Suspend | **Suspended**. Stops an approved provider, endpoint or model. | Contact platform support. Republishing can't lift it. |
| Retire (models only) | **Retired**. The model can't be offered on that endpoint again. | Nothing. |

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:

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

## Model statuses

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

| Status | Label | Meaning | What to do |
| --- | --- | --- | --- |
| `retired` | Retired | An administrator removed the model permanently. | Nothing. |
| `suspended` | Suspended | An administrator suspended the model, or a hold on the same model applies. | Contact support. |
| `withdrawn` | Removed | You removed the model from the endpoint. | Publish it again to create a new offer. |
| `paused` | Paused | You or the endpoint paused it. | **Resume**. |
| `rejected` | Rejected | The model submission or its prices were rejected. | Publish corrected terms as a new revision. |
| `changes_requested` | Changes requested | Review asked for corrections, proposed a different public name, or returned the prices. | Read the feedback; **Accept name**, or correct and **Publish again**. |
| `in_review` | In review | The model name or its first prices are being reviewed, or a submission is being completed. | Wait, or **Retry submission** if it's blocked. |
| `waiting_for_approval` | Waiting for approval | The model is ready and waits for your provider or endpoint approval. A hosted model with the reason `activation_pending` goes live shortly. | Wait. |
| `verifying` | Checking | Verification is queued or running, or the model is being checked again after failures. | Keep the agent running. |
| `check_failed` | Check failed | Verification failed. | Fix the cause, then **Check again**. See [Fixing a failed check](#fixing-a-failed-check). |
| `not_serving` | Not serving | The model can't take traffic now, for example because the endpoint is offline, routing paused it after failures, capacity is exhausted or it is awaiting recovery. | Read the reason. |
| `live` | Live | The model is receiving traffic. | Nothing. |

Three modifiers can accompany a status:

| Modifier | Label | Meaning |
| --- | --- | --- |
| `update_pending` | Update in review | A newer revision is in review or being checked; the approved one keeps serving. |
| `update_rejected` | Update rejected | The newer revision wasn't accepted; the approved one keeps serving. |
| `degraded` | Degraded | The endpoint's latest report isn't ready, or one of its models is waiting for recovery after repeated failures. |

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

| Status | Label | Meaning |
| --- | --- | --- |
| `rejected` | Rejected | Final. Create a new endpoint. |
| `suspended` | Suspended | An administrator suspended it. |
| `paused` | Paused | You paused it. |
| `changes_requested` | Changes requested | Edit the endpoint and submit it again. |
| `draft` | Draft | Not yet submitted for review. |
| `in_review` | In review | An administrator is reviewing it. |
| `not_connected` | Not connected | The agent has never connected, its credentials were revoked, or it must reconnect. For hosted endpoints, the key was rejected or is being checked. See [Reconnecting the agent](#reconnecting-the-agent). |
| `offline` | Offline | The agent was connected before but isn't now. |
| `no_models` | No models | Nothing is published on it. |
| `not_serving` | Not serving | Connected, but no model is eligible. Open a model to see its blocker. |
| `serving` | Serving | At least one model is live. |

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](#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](/docs/providers/measurements#task-quality).

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](/docs/providers/hosted) offers aren't verified before they go live. They show **Checking** only while [recovering after repeated failures](#recovery-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:

  ```bash
  numes provider verification retry --profile NAME
  numes 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

| | Pause | Stop the agent |
| --- | --- | --- |
| How | **Pause** on an endpoint or a model, in the dashboard or terminal UI | `numes provider stop`, closing the service, or shutting down the machine |
| Status | **Paused** | Endpoint **Offline**, models **Not serving** |
| Effect | Removed from routing deliberately. Nothing is reopened for review. | Routing can't reach you and verification can't run. |
| Undo | **Resume** | Start the agent |

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

:::cards
- {gauge} [Measurements and quality](/docs/providers/measurements) What the platform measures and how it affects routing.
- {coins} [Pricing your models](/docs/providers/pricing) Price protection and what a price change triggers.
- {terminal} [Terminal UI](/docs/providers/terminal-ui) Where each status and action appears.
- {shield} [Provider security](/docs/providers/security) Credentials and the outbound connection.
:::

## 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.