What features would you like to see added?
Extend the existing Insights feature into a privacy-conscious agent statistics view that can be enabled and rolled out through LibreChat configuration.
The goal is to give agent owners/admins lightweight operational visibility into agent usage, quality, and token cost without exposing user message content by default, and without requiring a new statistics subsystem for the first iteration.
Business Requirements
1. Extend existing Insights metrics for agents
The agent insights/statistics view should include metrics such as:
- conversations started
- messages/responses
- responses completed
- responses failed
- responses interrupted/cancelled
- thumbs up/down feedback counts
- feedback categories/reasons, where available
- token totals, where already available
- token cost / spend, where available
- daily unique users, without exposing user identities
- last used timestamp
- usage trend over a selected date range
2. Reuse existing data first
For a first phase, these metrics could be derived from existing conversations, messages, feedback, and transaction/usage data.
This should reuse the existing agent attribution logic, especially root agent attribution via initial_agent_id / agent_id.
A separate agent statistics collection should not be required for the initial version if the existing data can provide useful short-range insights.
3. Protect user privacy
Agent statistics should not expose user message content by default.
Existing Insights-style views that show recent/user messages are problematic for broader rollout, especially in enterprise environments. At minimum, showing message content should be configurable and possible to disable. Preferably, the default agent statistics view should only expose aggregate metrics unless an administrator explicitly enables detailed inspection.
Agent owners should get operational visibility into their agents, not unrestricted conversation inspection.
4. Move Insights configuration into librechat.yaml
ENABLE_INSIGHTS is currently an environment-level switch. It would be helpful to make Insights configurable through librechat.yaml, consistent with other LibreChat features.
This would allow deployments to enable the Insights UI/API globally while controlling actual access through roles, groups, and agent permissions.
Example intent:
interface:
insights: true
or a more detailed structure if needed:
insights:
enabled: true
showMessageContent: false
The important requirement is that deployments can roll this out to selected user groups without relying only on a single env-only toggle.
5. Keep the first phase lightweight
The first phase should stay scoped to short date ranges and owner/admin use cases, because live aggregation over conversations and messages may become expensive on larger installations.
For installations with millions of messages, this should not become a dashboard that repeatedly scans large historical collections.
More details
Possible Second Phase
If agent statistics become broadly used, or if larger installations need longer reporting windows, the same product surface could later move to read-optimized daily aggregates.
A daily per-agent aggregate could store counters such as:
- conversations started
- responses completed / failed / interrupted
- thumbs up/down counts
- feedback categories
- token totals
- token cost / spend
- daily unique users
- last used timestamp
These counters could be updated from existing write points such as conversation creation, message completion/error/abort, feedback updates, and transaction/usage recording.
This would allow the UI to read a small number of daily aggregate records instead of scanning historical messages.
Which components are impacted by your request?
No response
Pictures
No response
Code of Conduct
What features would you like to see added?
Extend the existing Insights feature into a privacy-conscious agent statistics view that can be enabled and rolled out through LibreChat configuration.
The goal is to give agent owners/admins lightweight operational visibility into agent usage, quality, and token cost without exposing user message content by default, and without requiring a new statistics subsystem for the first iteration.
Business Requirements
1. Extend existing Insights metrics for agents
The agent insights/statistics view should include metrics such as:
2. Reuse existing data first
For a first phase, these metrics could be derived from existing conversations, messages, feedback, and transaction/usage data.
This should reuse the existing agent attribution logic, especially root agent attribution via
initial_agent_id/agent_id.A separate agent statistics collection should not be required for the initial version if the existing data can provide useful short-range insights.
3. Protect user privacy
Agent statistics should not expose user message content by default.
Existing Insights-style views that show recent/user messages are problematic for broader rollout, especially in enterprise environments. At minimum, showing message content should be configurable and possible to disable. Preferably, the default agent statistics view should only expose aggregate metrics unless an administrator explicitly enables detailed inspection.
Agent owners should get operational visibility into their agents, not unrestricted conversation inspection.
4. Move Insights configuration into
librechat.yamlENABLE_INSIGHTSis currently an environment-level switch. It would be helpful to make Insights configurable throughlibrechat.yaml, consistent with other LibreChat features.This would allow deployments to enable the Insights UI/API globally while controlling actual access through roles, groups, and agent permissions.
Example intent:
or a more detailed structure if needed:
The important requirement is that deployments can roll this out to selected user groups without relying only on a single env-only toggle.
5. Keep the first phase lightweight
The first phase should stay scoped to short date ranges and owner/admin use cases, because live aggregation over conversations and messages may become expensive on larger installations.
For installations with millions of messages, this should not become a dashboard that repeatedly scans large historical collections.
More details
Possible Second Phase
If agent statistics become broadly used, or if larger installations need longer reporting windows, the same product surface could later move to read-optimized daily aggregates.
A daily per-agent aggregate could store counters such as:
These counters could be updated from existing write points such as conversation creation, message completion/error/abort, feedback updates, and transaction/usage recording.
This would allow the UI to read a small number of daily aggregate records instead of scanning historical messages.
Which components are impacted by your request?
No response
Pictures
No response
Code of Conduct