Skip to main content

Session

Session is the main runtime context for chat and API interactions. If your handler needs to know “who is talking?”, “what happened earlier?”, or “where should I send the reply?”, the answer is usually on Session. In hosted apps, that identity is app-scoped. Session is not telling you about some global Capsule user. It is telling you about the current user of this deployed app.

Worked example

This is the kind of session-aware flow you see in a real app:
In one handler, Session gives you:
  • the live conversation history for the model call
  • a reply target for text and structured blocks
  • a way to surface background work back into the chat UI

Core fields

Small example:
On hosted web apps, session.user comes from the app’s sign-in flow. External channels such as Telegram may provide a channel-scoped platform user id until that identity is explicitly linked to an app user. The same email can appear in another Capsule app too, but it is still a separate app user in that other app’s context.

Common methods

Real LLM usage usually looks like this:
session.chat_messages(msg) is useful because it already merges Capsule history into the alternating user / assistant format most LLM APIs expect.

Streaming helpers

stream_reply()

The accumulated text is written to session history when the context exits, which means a streaming response still becomes part of the conversation record.

stream_reply_from(stream)

This is the one-liner for async model streams such as BAML outputs. In practice it saves you from rewriting the same async with session.stream_reply() loop over and over.

Structured UI helpers

The Session object is also how chat handlers render richer UI.

show_task(...)

show_integration(...)

Use require_integration(...) when the current flow cannot continue without credentials:

show_browser(...)

Use this when a chat or workflow should surface a live browser view back to the user.

prompt_file(...)

RequestContext

Use RequestContext in @app.data() and @app.endpoint() handlers when you need caller metadata outside chat.

Fields

Example:
If a page or endpoint needs to know who is calling it, RequestContext is the right abstraction. If a chat turn needs to know who is calling it, you already have Session.

Messages and attachments

Message

Example:

Attachment

Attachment represents a file attached to a user message. Useful fields:
  • name
  • content_type
  • url
  • size
Use await attachment.download(path) to save it locally.

Blocks and uploads

Block

Block(type, payload) is the low-level structured UI primitive used by helpers like show_task() and show_integration(). If you are writing normal app code, prefer the higher-level helpers first. Reach for raw Block(...) only when you need a custom block type.

FileUpload

Returned by prompt_file(...). Useful fields:
  • name
  • content_type
  • url
  • size
  • path when auto-downloaded
Use await upload.download(path) if you want to save it manually.

Identity types

UserInfo

Common fields:
  • id
  • email
  • org_id
  • owner_id property for owner-scoped runtime identity

SessionChannel

Describes the transport, such as chat or Telegram.

Exceptions

These are part of the public session-facing API:
  • IntegrationTimeout
  • IntegrationDeclined
  • FileUploadTimeout

current_session()

Returns the active runtime Session when one exists. In scheduled handlers and some background contexts, this may be a synthetic session with identity and integrations but no live reply target. Example:

See also