---
title: "Force Sleep Endpoint"
method: POST
path: "/api/mind/v2/perspective/{identity_id}/sleep-now"
tags: ["mind-v2"]
---

# Force Sleep Endpoint

`POST /api/mind/v2/perspective/{identity_id}/sleep-now`

## Request

- Base URL: `https://app.thinqos.com` (the document declares no server; this is the origin it was published from)
- URL: `https://app.thinqos.com/api/mind/v2/perspective/{identity_id}/sleep-now`
- Auth: none declared

TOS-6024: force one full sleep cycle NOW (owner/admin only).

The owner-facing counterpart of the scheduled quiet-hours dispatcher: an
owner training or tuning an agent should be able to run the whole sleep
pipeline (settle -> replay -> decay -> consolidate -> dormancy ->
feedback -> retrospect -> REM -> prior_seed -> waking_validate) on
demand instead of waiting for the Mind's derived quiet window and its
20h recycle cadence, so consolidation/lesson-processing is immediately
testable.

Authorization mirrors the other ORG-WIDE mutating routes here
(``require_admin=True``): self, an active owner of the agent, or the org
OWNER role. An org admin/edit member is refused - a forced cycle rewrites
the Mind's salience and confidence wholesale, the same class of act as
``/rebuild``, not a per-belief edit.

The cycle runs as a detached background task (it can take minutes);
admission is validated synchronously so a refusal (no Mind, already
sleeping) is an immediate 404/409 with the real reason, not a silent
no-op. There is deliberately no recent-activity gate here (TOS-7771): a
forced cycle is for testing and power use; only the scheduled dispatcher
waits for the Mind to go quiet. While it runs, `/sleep-status`
reports ``state: "sleeping"`` and the `/sleep-report` timeline records
the episode with ``trigger_reason: "administrative"``.

## Path parameters

- `identity_id` string, uuid, required

## Headers

- `x-impersonate-identity-id` string, nullable

## Response `202`

Successful Response

- V2ForceSleepResult: TOS-6024: acceptance receipt for a forced (owner-triggered) sleep run. The heavy work (settle -> decay -> consolidate -> ... -> waking_validate) runs in a detached background task AFTER this response is sent - it can take minutes, far past any request timeout - so this model carries acceptance, not outcomes. The caller watches the resulting episode through the existing `/sleep-status` poll and `/sleep-report` timeline.
  - `accepted` boolean, required
  - `detail` string, required

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/thinqos/apis/thinqos-api.md) · [All operations](https://skmtc.dev/thinqos/apis/thinqos-api/llms.txt) · [OpenAPI document](https://skmtc.dev/thinqos/apis/thinqos-api/revisions/5fdd1072e877?raw)