> 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.07.01.md).
# Helvia.ai Release 2026.07.01
## 1. Keep Agents Running With LLM Fallback Configurations
You can now add more than one configuration inside a single LLM integration. The first configuration is your primary, and any others act as ordered fallbacks. If the primary configuration returns an error, the agent automatically retries the request against the next configuration in line, so your agents keep responding.
**Why it matters:** Until now, a single LLM integration relied on one configuration. If that provider had an outage, every feature that depended on it stalled. Fallbacks remove that single point of failure and protect everything routed through the LLM, including agent replies, session analysis, language detection and agent testing.
**Example use case:** You run a customer-facing agent on a primary LLM provider. You add a second configuration of the same provider type as a fallback. When the primary returns errors during a provider incident, the traffic is shifted to the fallback and your customers never see an interruption.
**How it works:** Open the LLM integration and add one or more **LLM configurations**. The first configuration is the primary, and the rest are tried in order. Fallbacks must be the same provider type as the primary, so an OpenAI integration falls back only to OpenAI, Azure to Azure, and Gemini to Gemini.
## 2. Search Chat Sessions By Signal
You can now filter sessions by the signals produced during session analysis, not just by variables or tags set inside your workflows. Signals are the outputs of analysis, such as resolution status or sentiment, so you can find sessions by what actually happened in them.
**Why it matters:** Before, signals generated by session analysis were not searchable through the console. Now those outcomes can be searched through a direct filter.
**Example use case:** You want every conversation your agent marked as unresolved last week. You open the search filter, choose **Search by signal**, pick the signal, and review only the sessions that need follow-up.
**How it works:** Go to **Observatory > Sessions > Chat Sessions**, open the search filter, and select **Search by signal**. Choose the signal you want, such as sentiment or resolution, and enter the value to match.
## 3. Easier Navigation With Clearer Chat Sessions Screen
The Chat Sessions screen has been redesigned into a two-pane layout. The sessions list sits on the left and is resizable, and a tabbed pane on the right shows the conversation and its details. You can drag the divider to give each side the space you need.
**Why it matters:** The previous fixed three-column layout crowded the content, especially on laptop screens. Reading a conversation and its details at the same time meant working in cramped panes. The new layout gives you room to read and adjusts to your screen.
**Example use case:** You are reviewing a long conversation on a laptop. You widen the sessions list to scan contacts, then narrow it again to focus on the transcript and the interaction details side by side.
**How it works:** Go to **Observatory > Sessions > Chat Sessions**. Drag the divider between the list and the right pane to resize. Select a message in the conversation to switch the right pane to the interaction details.
## 4. Shared Tags Filter Across The Observatory
The Tags filter is now shared across all Observatory subcategories. Set your tag filter once and it applies everywhere tags are relevant, so you no longer re-enter the same tags on each screen. You can both include and exclude tags in a single combined filter.
**Why it matters:** Previously the Tags filter was tied to each table on its own. Moving between Observatory screens meant setting the same tags again and again. A shared filter removes that repetition and keeps your view consistent as you move around.
**Example use case:** You are investigating sessions tagged "billing" but want to exclude those tagged "resolved". You set that include-and-exclude filter once, then move across Observatory screens with the same filter already applied.
**How it works:** Set the Tags filter in the **Observatory** filter row and choose tags to include or exclude. Subcategories that do not use tags ignore the filter automatically.
## 5. See Token Usage In The Interaction Logs
Interaction Logs now show the token usage for each LLM response using the LLM v2 node. When you open an interaction's details, you can see the input, output, and total tokens for that step. This gives you direct visibility into how much each LLM call consumed.
**Why it matters:** Token usage was captured behind the scenes but never surfaced, so understanding the cost of a given interaction meant estimating. Showing it per interaction makes usage transparent and easier to monitor.
**Example use case:** An agent's responses feel longer than expected. You open the interaction details for a recent session, check the input and output tokens, and confirm where usage is concentrated before adjusting your prompts.
**How it works:** Go to **Observatory > Interaction Logs** and open an interaction's details. The input, output, and total token rows appear for responses from the current LLM v2 node. The same usage is available in the raw **Payload** tab.
## 6. Default Data Retention For New Workspaces
New Workspaces now start with a default data retention period of three months. Agents that do not have their own retention period set inherit the value from their parent Workspace. That inherited value is now shown in the Agent's settings. You can revert an Agent back to the inherited value at any time.
**Why it matters:** A clear default makes data retention predictable from the moment a Workspace is created, which supports privacy and governance. Showing the inherited value makes it clearer what retention actually applies to an Agent.
**How it works:** When you create a Workspace, the data retention field is pre-filled with the three month default. In an Agent's privacy settings, the retention field shows the value inherited from the Workspace, with the option to revert to the inherited.
**Note:** Existing Workspaces are not affected by this change.\
\
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.helvia.ai/resources/release-notes/helvia.ai-release-2026.07.01.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.