n8n + Streamlit AI Agent

Claude is the default for this stack because multi-step agent logic benefits from strong instruction-following and long context: an n8n workflow that fetches records, builds a prompt from them, and asks for structured output tends to stay on track end to end. OpenAI is the pick when the workflow leans on its ecosystem: it is the most widely integrated LLM across n8n's community nodes and AI tooling, and it has a wide ladder of model tiers from cost-efficient to flagship reasoning. Both bill per token, so the cost profile is similar. The swap itself is one model node in n8n; nothing in Streamlit or PostgreSQL changes either way.

Almost everything is free open source: n8n self-hosted, Streamlit, Python, and PostgreSQL cost nothing beyond the server they run on, and a $5 to $10 a month VPS runs the whole stack for a small team. The variable line item is the LLM: Claude and OpenAI bill per token, and an internal tool doing a few thousand interactions a month on mid-tier models typically lands in the tens of dollars. n8n's cloud plans ($20 Starter, $50 Pro, billed yearly) trade the self-hosting work for hosted execution, and Streamlit's Community Cloud hosts small apps free. See the Pricing section below for the breakdown.

Streamlit calls an n8n webhook URL with the user's input and waits for the workflow to finish, receiving the final output as JSON. Two behaviors bite teams the first week. First, a multi-step workflow with LLM calls can run longer than the default webhook or HTTP timeout, so long tasks need either a larger client timeout or the async pattern: n8n returns a execution-id immediately and Streamlit polls for the result. Second, Streamlit reruns its whole script on every widget interaction, so an unprotected webhook call fires on every click; wrap it with Streamlit's cache_data decorator keyed on the input, or move the call behind an explicit submit button. PostgreSQL sidesteps both issues for anything the workflow has already computed.

The LLM token bill, then Streamlit. Token spend grows linearly with usage and is the first number to move: caching repeated prompts and stepping mid-tier models down for simple steps is the main lever. Streamlit's rerun-per-interaction model is built for small internal audiences, not many concurrent users; one shared instance serves a team fine but degrades as a product-grade frontend. n8n is the sturdier layer: self-hosted execution is unlimited, and cloud plans scale by execution count (2,500 a month on Starter, 10,000 on Pro). PostgreSQL at this stack's data volumes is rarely the constraint. The honest ceiling is a few dozen daily users; past that, graduate the frontend to a real web framework and keep the n8n workflows as the API layer.

Same architecture, different job. The pipeline stack is data in, charts out: n8n ingests and transforms on a schedule, PostgreSQL stores the history, and Streamlit renders it; nobody interacts with the workflow at run time. This stack is interactive: a user's input at a Streamlit widget triggers an n8n workflow through a webhook, an LLM processes it, and the response comes back to the same screen. That difference changes the cost profile (per-token LLM spend exists only here) and the failure modes (this stack worries about webhook latency; the pipeline stack worries about ingestion schedules). If no LLM belongs in the loop, the pipeline stack is the simpler and cheaper choice.