chat
owlette chat drives cortex ai conversations from the terminal. site-scoped (every verb requires --site), with optional machine narrowing on new. tier: ready — all five verbs are wired to canonical /api/cortex/conversations/* routes. Older /api/chat/* routes are compatibility aliases only.
mutations carry an auto-generated Idempotency-Key so a network retry never double-creates, double-deletes, or double-renames. send streams the assistant reply to stdout as deltas arrive (ai-sdk v3 line-prefixed protocol).
verbs
new
start a new conversation.
owlette chat new --site <siteId> [--machine <machineId>] [--title <title>] [--idempotency-key <key>]| flag | required | purpose |
|---|---|---|
--site <siteId> | yes | site to scope the conversation to |
--machine <machineId> | no | narrow to a single machine (omit for site-wide) |
--title <title> | no | human-readable title (cortex auto-titles otherwise) |
--idempotency-key <key> | no | override the auto-generated cli-chat-new-<uuid> |
backing endpoint: POST /api/cortex/conversations. emits { conversationId, siteId, machineId, title } on success.
list
cursor-paged conversation list for a site.
owlette chat list --site <siteId> [--limit <n>] [--cursor <token>]| flag | required | purpose |
|---|---|---|
--site <siteId> | yes | site to list conversations for |
--limit <n> | no | page size, integer 1–100 (default 25) |
--cursor <token> | no | opaque page_token from a prior response |
backing endpoint: GET /api/cortex/conversations?siteId=&page_size=&page_token=. tabular output renders conversationId | title | machine | messages | updatedAt; --json emits { conversations, nextPageToken }.
send
append a message and stream the assistant reply to stdout.
owlette chat send <conversationId> <message> [--idempotency-key <key>]text deltas (ai-sdk frame 0:"…") are flushed to stdout as they arrive so users see the model think rather than wait for the full reply. error frames (3:"…") are surfaced on stderr and set exit 1. with --json the cli buffers the full reply and emits { conversationId, content } once at the end.
backing endpoint: POST /api/cortex/conversations/{conversationId} (AI-SDK text stream). idempotency-key is sent for replay safety even though the server skips its cache for streamed responses.
delete
soft-delete a conversation (recoverable for 30 days).
owlette chat delete <conversationId> [--yes] [--idempotency-key <key>]interactive [y/N] prompt by default. --yes skips it. when stdin is not a tty and --yes was not supplied, the cli refuses rather than delete silently.
backing endpoint: DELETE /api/cortex/conversations/{conversationId}. responses include alreadyDeleted: true when the conversation was already tombstoned (still exit 0).
rename
set a new title on a conversation.
owlette chat rename <conversationId> <title> [--idempotency-key <key>]backing endpoint: PATCH /api/cortex/conversations/{conversationId} with body { title }.
exit codes
0— success1— generic error (network, 5xx, malformed stream, upstream cortex error, bad--limit, missing required flag, non-tty without--yes)2— usage error (no token)
notes
- scope: site-scoped on every verb;
newaccepts an optional--machinefor single-machine cortex sessions. - tier: ready (public-api Wave 2.9).
- streaming: only
sendstreams.new/list/delete/renameare simple json round-trips. - idempotency: every mutation auto-generates a unique key; pass
--idempotency-keyto deduplicate across script-level retries. - soft-delete:
deleteis reversible for 30 days via the dashboard. there is no hard-delete verb on the cli. - see also: cortex API docs at docs/api/cortex.md; per-machine context is fetched server-side from the machine's last heartbeat and process snapshot.
audit-log
inspect a site's tamper-evident audit log from the cli. records form a hash chain (each record carries the previous record's hash) so you can detect tampering by walking the chain — audit-log get returns the chain links plus a verification report alongside the record. both verbs are site-scoped, tier A — ready.
deploy
⚠️ disambiguation — read this first. owlette deploy … is the classic agent-installer deploy noun: it pushes a silent installer exe (with /SILENT-style flags) at a list of machines and tracks per-target install status. it is NOT owlette roost deploy, which is the content-addressed atomic-deploy surface for roost versions. same word, different surfaces. if you want the new content-addressed flow, jump to roost deploy.