> For the complete documentation index, see [llms.txt](https://docs.helvia.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.helvia.ai/resources/release-notes/helvia.ai-release-2026.09.23.md).

# Helvia.ai Release 2026.09.23

23 September 2026

## 1. Connect LLM Nodes With Any OpenAI-Compatible Model Provider

Up to now, LLM nodes could only talk to OpenAI's hosted API. This release brings in a new OpenAI-Compatible integration that lets you connect any endpoint that speaks the OpenAI chat-completions API — just point it at a Base URL and add an API key if the endpoint needs one.

**Why it matters:** If your team already runs its own model gateway or leans on another provider — a self-hosted server like vLLM or Ollama, or an aggregator like LiteLLM, OpenRouter, Together, or Groq — you can now bring it into Helvia.

**Example use case:** Say you host an open-weight model behind an internal gateway to keep data in-region. You add an OpenAI-Compatible integration pointing at your gateway, then pick it in your LLM node so both your answers and your embeddings run on your own endpoint.

**How it works:** In the Integrations page of a Workspace, create a new OpenAI Compatible integration. You'll need a Base URL; the API key is optional, so keyless local servers are fine. Requests only ever go to the endpoint you set, never back to OpenAI. Your existing OpenAI integrations configured with “customUrl” carry on exactly as before.

<img src="https://604830754-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FBM1xs3i59ajeTgi4uVfN%2Fuploads%2FgiJM4VnrZnizLDDlPUPT%2Funknown.png?alt=media&amp;token=098d009e-2b81-40a4-8f86-45568dfb137e" alt="" width="375">

## 2. A New Session Analysis Plugin

Session Analysis is what summarizes and classifies your conversations once they wrap up. This release gives it a fresh home on Helvia's modern Generation path, with richer, per-model configuration — and your current setup stays put as "Session Analysis (Legacy)."

**Why it matters:** The legacy plugin runs on an older path with fewer options to work with. The new one hands you finer control over the model and its settings, and brings session analysis in line with the rest of the platform — all without asking you to switch before you're ready.

**Example use case:** Maybe you'd like your post-session summaries to run on a particular model, tuned just so. You switch that one agent over to the new plugin, set the model up the way you like it, and leave everything else on the legacy plugin until it suits you to move.

**How it works:** Both plugins live side by side, and you migrate agent by agent on your own timeline. Each agent keeps a single active Session Analysis provider across the two. The new plugin does everything the old one did — basic and expert modes, automatic runs on session completion, and classification tags.

<img src="https://604830754-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FBM1xs3i59ajeTgi4uVfN%2Fuploads%2FsgEwC1wE63HIMHyZ9CTF%2Funknown.png?alt=media&amp;token=e117e42b-9639-49a6-9d83-726abbc9daba" alt="" width="563">

## 3. See Which Flow Produced Each Event in the Observatory

When you open an event in the Observatory's per-event view, you can now see the flow that was running the moment it fired — its name, and for subflows the exact subflow — right there alongside everything else.

**Why it matters:** "Which flow was running when this happened?" used to mean rebuilding the session, which added up across every investigation. Now the answer is sitting on the event itself.

**Example use case:** A visitor flags a reply that seems off. You open the session, find the event, and can see at a glance which flow or subflow produced it — so you head straight there in the Designer to make the necessary fixes.

**How it works:** Every new interaction event now records the flow's name and ID. The view shows the current name, tells you when a flow has since been renamed, and marks any that have been deleted. Events from before this release don't carry the attribution, so they show a dash.

<img src="https://604830754-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FBM1xs3i59ajeTgi4uVfN%2Fuploads%2FeOvJFo4YmtGLyYlYNmL4%2Funknown.png?alt=media&amp;token=887540fb-a80e-4496-bf19-0dbf1ad642c8" alt="" width="563">

&#x20;

<img src="https://604830754-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FBM1xs3i59ajeTgi4uVfN%2Fuploads%2FUQYklwWwc2S7jHEv855j%2Funknown.png?alt=media&amp;token=674e6e52-0843-4b0a-9623-63c7a15101ad" alt="" width="563">

## 4. WebChat upgrade

The WebChat widget has been upgraded to the latest version of its underlying rendering engine, bringing the newest improvements, fixes and security updates to the chat experience. As part of the upgrade, some of the widget's internal markup and styling variables have been refreshed.

{% hint style="warning" %}
If your widget's look and feel comes from custom CSS on your own page (rather than from the styling options in the console's Deployment settings), take a quick look after the release to confirm everything still renders the way you expect. If your styling comes from the console's Deployment settings, no action is needed.
{% endhint %}

**Need a hand?** If you'd like us to review custom styling, just reach out and we'll help you align it.

\
\
\
\ <br>