Bolt prompt to integrate an LLM chatbot
Wiring an LLM into an app inside Bolt means one non-negotiable: the provider key lives in .env and every call goes through a server route the WebContainer runs, never the browser bundle. This prompt adds a docked, streaming chat panel to an existing project and handles the states demos skip, stop, retry, offline, reload.
Last updated
Add a chat assistant to the existing app in this Bolt project without restructuring it.
Server side: server/chat.ts, an Express route POST /api/chat that proxies to the LLM provider. Read the key from LLM_API_KEY in .env, keep .env out of version control, and never let the key reach the client bundle. Stream the reply back as server-sent events so tokens render as they arrive. A missing key returns 503 with { error: "missing_key" } instead of crashing the WebContainer process. Disable compression middleware on this route so SSE chunks flush.
Client side: a ChatPanel component docked to the right edge, collapsible. Parts: message list, a textarea growing to four lines, a send button disabled while a reply streams. Send the last 20 messages as context and drop older ones.
States:
- First open shows a short hint describing what the assistant can help with in this app.
- Streaming shows a cursor at the end of the incoming message plus a Stop button that aborts the fetch and keeps the partial text.
- Provider errors and rate limits render inline in the transcript with a Retry link, and the user's draft stays in the box.
- Offline disables send with a tooltip saying why.
Persist the transcript to sessionStorage so a preview reload mid-test does not wipe the conversation.
Log one line per request on the server with model, token counts if the provider returns them, and latency.
Acceptance: with a key in .env, ask a question and watch tokens stream in the preview, hit Stop halfway and confirm the partial reply stays, then remove the key and confirm the 503 path renders as an inline error.Same task in other tools
Questions about this prompt
Why proxy through a server route instead of calling the provider from React?
Anything in the client bundle is public, including your API key, and Bolt previews are easy to share. The Express route keeps the key on the server side of the WebContainer, and it gives you one place to log latency, truncate history, and swap providers later without touching the panel.
How do I ground the assistant in my app's actual data?
Start by injecting a system message in server/chat.ts describing the app and its current state, serialized from your store or database at request time. If answers need real records, fetch them in the route and prepend them as context. Keep the last-20-messages cap so the payload stays bounded.
Streaming works, then the reply dies mid-sentence with no error. What should I check?
Three usual causes in this setup. The SSE response is buffered behind compression middleware, so confirm compression is disabled for /api/chat. The provider hit its output token limit, so raise it. Or the preview reloaded on a file save mid-stream, which is why the transcript persists to sessionStorage.