AI Chat Interface#

Sure's AI chat interface provides a conversational assistant embedded in the main app layout. It operates in two distinct modes depending on viewport: a desktop right sidebar that slides in/out alongside the main content, and a dedicated full-screen mobile view accessible via the bottom navigation bar. All chat interactions go through the same underlying models and background jobs regardless of where they are triggered.

Related systems (out of scope here):

• LLM Tool Calling — how the AI invokes application functions (e.g., create_category)
• AI Bank Statement Extraction — document-specific parsing pipeline

Layout Integration (Desktop vs. Mobile)#

Chat is wired into app/views/layouts/application.html.erb at the outermost shell level.

Desktop: A collapsible right sidebar 1 is shown or hidden based on Current.user.show_ai_sidebar?. It lazy-loads the active chat via a turbo_frame_tag pointing at chat_view_path. The sidebar is guarded by a consent overlay: when Current.user.ai_enabled? is false, a blurred _ai_consent partial covers the chat area 2.

Mobile: The bottom nav includes an icon-assistant tab that links to chats_path 3. This is marked mobile_only: true so it's excluded from the 84px icon-based desktop left nav 4. In "intro" UI layout mode, the mobile nav is replaced with simplified Home + Intro tabs 5.

The Turbo frame identifier for the chat sidebar is the symbol :sidebar_chat, returned by the chat_frame helper. The chat_view_path helper resolves the correct URL for the frame based on the current chat state and params[:chat_view] 6.

Consent Management#

Before a user can interact with the AI, they must opt in. The consent gate has two layers:

1. ai_available? 7 — infrastructure check. On self-hosted deployments, it verifies that at least one LLM provider (OpenAI or Anthropic) has valid credentials, or that an external assistant is configured. On cloud, it returns true unconditionally.
2. ai_enabled? 8 — requires both ai_available? and the user's ai_enabled boolean to be true.

The _ai_consent partial presents different copy depending on availability:

• If ai_available? → shows an opt-in form that PATCHes user[ai_enabled]=true to user_path 9.
• If not available → shows an "unavailable" message with no action button 10.

A disable note is always shown below (t(".disable_note")), indicating the setting can be turned off later 11.

Chat Views and Controller#

Routes: Standard REST resource. Key paths: GET /chats (index), GET /chats/:id (show), POST /chats (create), POST /chats/:id/retry (retry).

ChatsController 12:

• index — lists the user's chats in descending creation order; explicitly sets @chat = nil to override the application-level "last viewed chat" default.
• show — loads the chat and calls set_last_viewed_chat, persisting it as the user's last_viewed_chat.
• create — calls Chat.start! with the prompt and AI model, then redirects to chat_path with thinking: true.
• retry — calls chat.retry_last_message! and redirects back to the chat.

Index view 13: If no chats exist, shows an ai_greeting partial and the messages/chat_form inline. If chats exist, renders a list with a new_chat_path link.

Show view 14: Subscribes to real-time updates via turbo_stream_from @chat. Renders ordered conversation_messages (or the ai_greeting if empty), an error partial if needed, and a sticky chat form at the bottom.

Message Lifecycle#

The Message model uses Rails STI with two concrete types:

Status states: pending → complete / failed 16. A pending assistant message renders as "Thinking…" in the UI until content arrives via broadcast.

Async flow:

1. UserMessage is created → after_create_commit calls ask_assistant_later, which creates a blank pending AssistantMessage and enqueues AssistantResponseJob on the high_priority queue.
2. The job calls message.request_response(...) → chat.ask_assistant(message) → assistant.respond_to(message).
3. Assistant::Responder streams chunks back; each text chunk calls append_text! on the pending message, triggering after_update_commit broadcasts to all subscribers.
4. On failure, chat.add_error stores a JSONB error payload and broadcasts the error partial.

Undelivered response watchdog: If a worker dies before completing a response, handle_undelivered_response! can be called by the client. It re-reads the row under a lock, and only acts if the message is still pending and has aged past UNDELIVERED_RESPONSE_TIMEOUT (60 seconds server-side) 17. Partially-streamed content is demoted to failed rather than deleted.

Error classification: Chat#classify_error_message pattern-matches the raw error string against rate-limit, 5xx, and auth patterns to return a user-friendly i18n key 18 19.

Key Files#