# Activity

Source: https://convergingthought.com/docs/product/requests

> Follow status, routing, token usage, results, and charges for each admitted operation.



[Activity](/internalize/app/requests) shows durable jobs for the selected project, newest first. It includes API and playground work. Each row represents an admitted model operation, not every HTTP polling request or failed authentication attempt.

## Find a request [#find-a-request]

Filter the loaded rows by request ID or status, and use the type selector to show inference or internalization. The initial view loads 50 records. **Load earlier requests** fetches another page.

The text and type filters operate on loaded records. If an older job is missing, load more history or read its known ID through the API. An empty filtered table is not proof that the operation never existed.

## Read the row [#read-the-row]

| Column  | Interpretation                                      |
| ------- | --------------------------------------------------- |
| Request | A shortened job ID; open it for the full identifier |
| Type    | Inference or internalization                        |
| Status  | The latest durable lifecycle state                  |
| Tokens  | Recorded input plus output inference tokens         |
| Cost    | Settled charge, or Pending while unresolved         |
| Started | Admission time                                      |

Internal training tokens are not customer inference-token usage. A successful internalization can therefore have a fixed fee without a matching count of teacher or training tokens in this table.

## Open details [#open-details]

Select a request ID to inspect the full ID, status, phase, adapter snapshot, token counts, reserved amount, charged amount, and start time. The result block contains the answer or candidate metadata when available.

For learning, the Adapter field is the parent selected at admission. The new candidate is inside the result. For inference, Adapter is the version used for that answer. This distinction is useful when an update finishes during another request.

The console's request ID is the durable job ID. The `X-Request-Id` returned by an API call identifies a single HTTP attempt and is a separate diagnostic value. Keep both when reporting transport problems.

## Diagnose by state [#diagnose-by-state]

Queued or running means continue observing. Ready means a learning candidate exists, so check activation. Rejected means the candidate failed validation. Failed means a known error; inspect the result, error, and settled charge. Reconciliation required means stop resubmitting and preserve the job for investigation.

Copying the ID is enough for most support triage. Avoid sending the result block when it contains private model content. Use [safe diagnostics](/docs/troubleshooting/diagnostics) to prepare a small report, and [job recovery](/docs/troubleshooting/jobs) to decide what action is appropriate.