Sessions and users

-H "x-vatan-session-id: thread-8f21" \
-H "x-vatan-session-name: Refund enquiry" \
-H "x-vatan-user-id: customer-42"

A conversation is a client-side idea and your end user is your own concept, so neither is knowable from the request body. Declare them and both become things you can filter, group and cost.

A session is derived, never opened or closed: it is whatever requests declared the same id. A client that crashes mid-conversation cannot leave a dangling record behind.

The first request to name a session wins. Letting a later one rename it would make the list unstable to read while you are reading it.

The user id is opaque to us on purpose. We store what you send and have no business deciding whether it is an email, a row id or a hash. Send a hash if you would rather we never held the real thing; everything on the users page works the same either way.

The request log is metadata only. Prompts and completions are not stored in it, on any plan: storing request bodies is a different product with different data-protection consequences, and not one to acquire by accident.

One exception, and it is yours to switch on. A request sent with x-vatan-cache has its answer stored so the next identical request can be served from it, for exactly the lifetime you asked for. The request itself is kept only as a hash, never as text. Nothing is cached unless you ask, nothing is cached on a streamed request, and the cache page purges the lot on one button. See caching.