* 🪙 fix: Persist Context Snapshot + Summary Marker After Summarization
The post-summarization context is correctly compacted by the SDK, but the
breakdown wasn't reliably reaching the client, leaving the gauge on the
whole-history estimate (stuck at 100% forever once a conversation compacts).
Two server changes in buildResponseMetadata:
- Snapshot guard: persist the breakdown when a PRIMARY usage event follows the
latest snapshot (tracked via contextUsageSink.latestUsageIndex, recorded in
the on_context_usage handler) instead of a brittle snapshot-vs-primary count.
A summarization detour adds an extra snapshot whose only following usage is
tagged 'summarization', which the count guard could miscount and drop.
- Summary marker: whenever a turn compacts (summaryTokens > 0), persist a
lightweight metadata.summaryUsedTokens (the pre-invoke compacted context size)
UNCONDITIONALLY — so even when the full snapshot can't be saved (interrupted
final call) or never reaches the client, the per-message estimate has a signal
to cap the discarded history.
Tests: client.contextMetadata.spec (guard + marker, incl. marker-survives-drop)
and a real-pipeline summarization integration test.
* 🪙 fix: Cap the Context Estimate at the Summary Marker
When the gauge falls back to the per-message estimate (no usable snapshot on the
branch), sumBranch summed the ENTIRE branch history — after a summarization that
discarded most of it, this over-counts and pins the gauge at 100% in perpetuity.
sumBranch now stops at the deepest summarized response (metadata.summaryUsedTokens)
and records it as summaryBaseline; the walk counts only post-summary messages,
and useTokenUsage adds the baseline. So the estimate reflects the compacted
context (summary + recent turns), not the discarded history. USD/default
behavior unchanged when no marker is present.
Test: sumBranch caps a huge pre-summary history at the compacted baseline.
* 🪙 fix: Address Codex Review on the Summarization Marker
- Branch cost/usage is no longer truncated at the summary marker — sumBranch
caps only the CONTEXT-window count there and keeps accumulating provider
usage/cost to the root (cumulative spend isn't discarded by compaction).
- findBranchSnapshotAnchor stops at a summarized response with no snapshot of its
own, so it can't recover a stale PRE-summary snapshot and show discarded
history; the summary-baseline estimate is used instead.
- Abort path: buildAbortedResponseMetadata now persists the summaryUsedTokens
marker (pre-invoke, no completedOutputTokens ambiguity, so safe on abort) so a
STOPPED summarized turn isn't re-summed on reload.
- Marker baseline fallback now includes summaryTokens (a separate breakdown
field) so it doesn't under-report the compacted size. DRY'd into a shared
computeSummaryUsedTokens used by the completion and abort paths.
- Estimate popover surfaces the summary baseline as a row so the displayed rows
reconcile with the header total.
Tests: sumBranch cost-not-truncated + anchor-stops-at-marker (client);
computeSummaryUsedTokens fallback + abort marker (packages/api).
* 🪙 fix: Attribute Persisted Context Usage to the Snapshot Run
Match the post-snapshot primary usage to the latest snapshot's runId before
persisting metadata.contextUsage. Parallel/direct runs interleave snapshots and
usage (A snapshot → B snapshot → A usage → B no-usage); the prior index-only
guard persisted B's snapshot with A's output. finalCallOutputTokens now filters
completedOutputTokens to the snapshot's run. Untagged events (older lib/resume)
match any run for back-compat.
* 🪙 fix: Harden Summary Marker Against Tool-Loops, Stale Anchors, and Emit Races
Codex round on the summarization marker:
- Avoid double-counting earlier tool-loop outputs in the summary marker: those
outputs sit in BOTH the latest snapshot's pre-invoke baseline AND the response
message's tokenCount the client estimate adds on top. computeSummaryUsedTokens
now subtracts the run's prior primary outputs (priorRunOutputTokens) — the live
path bounds them by the snapshot's usage index, the abort path by all primaries
(an interrupted final call emits none). Single-call turns subtract 0.
- Stop treating pre-summary anchors as active: sumBranch no longer sets
containsAnchor once the context is capped at a summary marker, so a stale
pre-summary snapshot can't override the summary-baseline estimate.
- Capture latestUsageIndex BEFORE awaiting emitEvent: a yield (resumable SSE /
Redis) during parallel runs could let this call's own usage advance the index
past the event that proves the snapshot completed, dropping a valid breakdown.
* 🪙 fix: Subtract Summarization Output from the Summary Marker
recordCollectedUsage folds the summarization call's completion into the response
message's tokenCount, while the generated summary is also in the snapshot baseline
as summaryTokens. The client estimate (summaryBaseline + responseTokenCount) thus
counted the summary twice — inflating the gauge after compaction even on a
single-call turn whenever the full snapshot is unavailable. priorRunOutputTokens
now also counts summarization-tagged output (still excluding subagent/sequential,
which recordCollectedUsage keeps out of the reported total), so the marker
subtracts it. Updated unit + guard tests.
* 🪙 fix: Refine Marker Subtraction for Summarization RunId and Abort Boundary
Two Codex follow-ups on the marker-subtraction logic:
- Subtract summarization output regardless of runId: the summarize detour is its
own model-end call that may carry a distinct runId, but its output still lands
in this response's tokenCount AND the snapshot baseline (summaryTokens). It is
now counted unconditionally (still within the response's own usageEmitSink),
while primaries keep the parallel-run runId filter.
- Don't subtract primaries on the abort path: the job stores no snapshot/usage
boundary, so a primary that completed AFTER the latest snapshot is NOT in the
baseline; subtracting it would cancel real output and under-report. priorRun-
OutputTokens gains an includePrimary flag (false for abort) — abort subtracts
only the always-pre-snapshot summarization output.
* 🪙 fix: Run-Scope Summary Subtraction and Stop Subtracting on Abort
Two Codex follow-ups, resolved by reverting the round-4 detour:
- Run-scope the summarization subtraction: the summarize detour inherits the
graph run id (traceConfig spreads config.metadata.run_id), so its usage shares
the answer snapshot's runId — it is NOT a distinct run. priorRunOutputTokens now
filters summarization by runId like primaries, so a parallel sibling run's
summary (different runId, in the sibling's baseline) is no longer subtracted from
this branch's marker. Drops the includePrimary flag added last round.
- Stop subtracting on the abort path: abort tokenCount is countTokens(text)
(abortMiddleware) or absent (agents route) — it does not fold in summarization or
earlier-call output the way recordCollectedUsage does, so the marker must keep
the full baseline. buildAbortedResponseMetadata now subtracts nothing.
* 📨 feat: Custom Headers on Built-in Provider Endpoints
Add a `headers` config option to the built-in `openAI`, `anthropic`, and
`google` endpoints (incl. Anthropic/Google Vertex), mirroring the custom
endpoint header mechanism. Values support the same placeholder resolution
(env vars, `{{LIBRECHAT_USER_*}}`, `{{LIBRECHAT_BODY_CONVERSATIONID}}`) and
are resolved at request time so dynamic values like conversationId resolve
against the live request — without losing provider-native request shaping.
Closes#13082. Covers #13713: forwarding conversationId to a reverse proxy
is now `X-Conversation-Id: '{{LIBRECHAT_BODY_CONVERSATIONID}}'` — an unknown
header is ignored by the native Anthropic API, so no 400 and no metadata
gating needed.
- Schema: `headers` on `baseEndpointSchema` (openAI/google/anthropic/all).
- New `mergeHeaders`/`resolveConfigHeaders` utils centralize the per-provider
header locations (`configuration.defaultHeaders`, Anthropic
`clientOptions.defaultHeaders`, Google `customHeaders`); provider-managed
headers (auth, `anthropic-beta`) always win on collision.
- Each initializer threads configured headers (endpoint over `all`) into the
right place; request-time resolution runs across all locations in the main
and title flows.
* 🩹 fix: Cast endpoints.all to TEndpoint for headers DeepPartial widening
Adding `headers` (a Record) to `baseEndpointSchema` makes `DeepPartial<TCustomConfig>`
widen its value type to `string | undefined`, which is not assignable to the
concrete `TEndpoint['headers']: Record<string, string>` at the `loadedEndpoints.all`
assignment. Cast at the assignment site, mirroring the existing
`anthropicConfig as TAnthropicEndpoint` cast in the same function.
* 🛡️ fix: Harden built-in endpoint custom headers (Codex review)
Address Codex P2 findings on the custom-headers feature:
- Anthropic title requests: `omitTitleOptions` strips the `clientOptions`
carrier, which dropped its `defaultHeaders`. Preserve just the header carrier
so gateway/reverse-proxy metadata still reaches title generation.
- mergeHeaders: match header names case-insensitively so an override (e.g. a
provider-managed `Authorization`/`anthropic-beta`) replaces/uniones a
case-variant from the base instead of emitting two names a client may collapse.
- OpenAI: withhold admin-configured headers when the user supplies the base URL
(`user_provided`), since values may carry `${SECRET}`/token placeholders that
must not reach a user-controlled endpoint — mirrors the custom-endpoint guard.
- Azure: honor global `endpoints.all` headers (same OpenAI carrier) while keeping
Azure-managed `api-key`/version headers authoritative.
Adds tests for each.
* 🔐 fix: Resolve-once + provider-managed header safety (Codex review round 2)
Address Codex P2 findings:
- Azure: keep global `endpoints.all` headers unresolved at init and let
request-time `resolveConfigHeaders` resolve them once, avoiding a
second-order env expansion of already-substituted user values.
- Google: `resolveConfigHeaders` no longer template-resolves the
provider-managed `Authorization` header (built from a possibly user-provided
key), so a user key like `${ENV}` can't leak server environment values.
- Model fetches: thread configured headers (endpoint over `all`) + user object
through `getOpenAIModels`/`getAnthropicModels` → `fetchModels`, so a
gateway-fronted built-in provider receives the header on `/models` too. Fixed
`fetchModels` to merge custom headers for Anthropic instead of overwriting
them (managed `x-api-key`/version still win).
Adds/updates tests for each.
* 🧯 fix: Header provenance, memory/title coverage, idempotency (Codex round 3)
Address Codex P2 findings, including two regressions from the prior round:
- Google auth (findings 6 & 8): move native Google header resolution to init
(`initializeGoogle`), resolving admin templates BEFORE the key-derived auth
header is built. resolveConfigHeaders no longer touches Google `customHeaders`,
so admin `Authorization` templates resolve again (fixes the round-2 regression)
while the SDK auth header (possibly a user-provided key) is never env-expanded.
- Memory runs: memory extraction now calls `resolveConfigHeaders`, so native
Anthropic (and OpenAI) headers resolve for memory requests too.
- Vertex titles: restore the ORIGINAL `clientOptions` object reference (not a
copy) when preserving headers across `omitTitleOptions`, so the Vertex
`createClient` closure and the resolved headers stay on the same object.
- Reuse: `resolveConfigHeaders` is now idempotent (resolve-once per header map),
preventing a second pass from env-expanding values already substituted with
user/body data when an agent object flows through buildAgentInput twice.
Adds/updates tests for each.
* 💸 feat: Per-Agent Endpoint Token Config in Multi-Endpoint Billing
Price each collected/emitted usage item with the producing agent's resolved
endpoint token config, instead of the primary agent's for the whole graph.
Previously AgentClient.recordCollectedUsage and the subagent usage emitter used
a single this.options.endpointTokenConfig (the primary's) for every usage item.
A connected agent or subagent on a different custom endpoint that shares a model
id with an entry in the primary's tokenConfig was therefore mis-priced (a model
absent from it already fell back to the built-in rate map — no regression).
- Tag each usage with its producing agent: ModelEndHandler stamps
usage.agentId = agentContext.agentId; createSubagentUsageSink stamps the
child's subagentAgentId (UsageMetadata gains an optional agentId).
- buildAgentToolContext retains endpointTokenConfig so initialize.js can build
an agentId -> endpointTokenConfig map from agentToolContexts (the one map that
holds every agent, including pure subagents pruned from agentConfigs).
- AgentClient.resolveAgentEndpointTokenConfig(usage) looks up that map by
agentId, falling back to the primary config; used by both the billing path
(new optional resolveEndpointTokenConfig on recordCollectedUsage) and the
subagent cost emitter.
- recordCollectedUsage's resolver is optional and falls back to the batch
endpointTokenConfig, so the shared responses.js/openai.js call sites are
unchanged.
- Tests: two-endpoint graph with a colliding model id prices per-agent; resolver
nullish falls back to batch; subagent sink tags the child agent id.
* fix: Align emit-path cost with per-agent billing; honor known-agent built-in pricing
Addresses Codex review on the per-agent endpoint token config:
- Emit path (callbacks.js) now prices each on_token_usage event with the
producing agent's config (resolved via usageCost.resolveEndpointTokenConfig),
so streamed/persisted metadata.usage.cost matches the per-agent balance
transaction. The agentId tag is resolved server-side and stripped from the
emitted/persisted payload.
- Resolver (resolveAgentTokenConfig) now treats a known agent's config as
authoritative, including undefined → built-in pricing, so a known non-custom
agent in a custom-primary graph is no longer charged the primary's rates.
Only untagged/unknown usage falls back to the primary config.
- endpointTokenConfigByAgentId records every known agent (value may be
undefined) so the resolver distinguishes known-no-rates from unknown.
* 💾 feat: Persist Context Breakdown & Branch/Total Usage Cost
Persist the granular context breakdown and per-response usage/cost on the
response message metadata, and re-derive branch + total usage/cost from a
per-message index so the popover survives reloads and is branch-aware live.
- Add aggregateEmittedUsage + buildPersistedContextUsage helpers in
packages/api; capture the latest visible snapshot and every emitted
on_token_usage payload via contextUsageSink/usageEmitSink.
- Attach metadata.contextUsage (Part A) and metadata.usage (Part B) on the
agents response message in sendCompletion.
- Carry per-message usage on the token index; add sumTotalUsage/setEntryUsage
and branch-scoped usage on sumBranch.
- Repurpose the session accumulator into a single in-flight pending holder;
flush it into the index at finalize; hydrate breakdowns on load.
- Render branch cost with a conditional all-branches total in the breakdown.
* 🧹 chore: Remove orphaned com_ui_session_cost i18n key
* 🩹 fix: Address Codex review — normalize usage server-side, fix reload deltas
- Persist per-event-normalized display units in metadata.usage (TResponseUsage)
so reloaded mixed-provider turns match the live session; client reads them
directly instead of re-normalizing with a single stamped provider (P2).
- Persist completedOutputTokens (final call output) on metadata.contextUsage so
a reloaded multi-call turn adds the post-snapshot delta, not the full
tokenCount the snapshot already counts (P2).
- buildIndex preserves a prior entry's immutable usage when a rebuilt cache
message lacks metadata.usage, so a mid-session rebuild (regenerate) keeps a
sibling branch's flushed cost (fixes the e2e regenerate failure).
- Track costKnown so turns saved with contextCost off don't render $0.00 when
cost display is later enabled (P3).
- Use an epsilon for the all-branches cost comparison to avoid a spurious total
row from float summation order (P3).
- Update unit/integration/e2e tests for the new shapes; regenerate e2e asserts
the all-branches total after reload (deterministic via persisted metadata).
* 🩹 fix: Address Codex round 2 — pending leak, cost coverage, reload delta
- Clear the in-flight pending usage on terminal abort/error (resetLive), so a
stopped generation's tokens no longer merge into the next response (P2).
- costKnown now means COMPLETE coverage (ANDed): a branch mixing cost-bearing
and cost-less turns is flagged incomplete and the cost row is hidden rather
than rendering an under-reported total (P2).
- Drop the tokenCount fallback for completedOutputTokens on reload: only the
persisted post-snapshot delta is used, so a multi-call turn whose provider
emitted no usage_metadata no longer double-counts earlier output (P2).
- Update tokens.spec for AND coverage semantics + incomplete-cost case.
* 🩹 fix: Address Codex round 3 — no-usage snapshots, total coverage, provider-less cache
- Skip persisting metadata.contextUsage when the response emitted no primary
usage event: without a known post-snapshot output the granular gauge would
undercount the reply on reload, so fall back to the coarse per-message
estimate instead (P2).
- Gate the all-branches cost row on totalUsage.costKnown so an incomplete total
(a sibling saved without cost) never renders an under-reported figure (P2).
- aggregateEmittedUsage/finalCallOutputTokens now normalize per-event with the
client's magnitude fallback (normalizeEventUnits) instead of billing
splitUsage, so provider-less cached events match live on reload (P2).
- Add backend test for the provider-less cached case.
* 🩹 fix: Address Codex round 4 — abort attribution, complete cost coverage
- aggregateEmittedUsage persists cost only when EVERY call was priced; a partial
pricing failure now omits cost so the client treats coverage as unknown rather
than reading an under-reported sum as authoritative (P2).
- finalizeUsage flushes pending into the response entry only when events were
folded this session (eventCount > 0), so a late/second resumable subscriber
carrying persisted metadata.usage keeps it instead of being overwritten with
an empty pending record (P2).
- On user stop, attribute the in-flight pending usage to the partial response
(new attributePending handler) instead of discarding it in resetLive — the
stopped reply's billed tokens are kept and still can't leak into the next
response; resetLive's discard remains for the error path (P2).
* 🐛 fix: Persist branch cost across branch switches via sticky usage history
Branch cost vanished on switching to a sibling branch (until a new turn) — the
cost analog of the granularity bug. buildIndex rebuilds the token index from the
messages cache; a sibling generated this session whose cache message lacks
metadata.usage (and is transiently dropped from the cache during regenerate)
lost its live-flushed usage, so sumBranch found none and the cost row hid.
Fix: a sticky per-response usage map (conversationId → messageId → usage),
written by setEntryUsage and never rebuilt from the cache — the usage counterpart
of snapshotsByAnchorFamily for the breakdown. buildIndex/upsertEntries restore an
entry's usage from it when the message carries none; cleared on convo switch and
migrated with the index. Add unit coverage for the drop-then-readd regression and
an e2e assertion that branch cost survives a branch switch.
* 🐛 fix: Re-index on branch switch so branch cost survives the switch
The sticky usage history alone didn't fix the reported branch-switch cost drop:
on a branch switch no cache `updated` event fires, so the index subscriber never
re-ran, and the post-regenerate rebuild was skipped while `isSubmitting` was
still true — leaving the index stale and missing the now-viewed branch's
response entirely (sticky can only restore entries present in a rebuild).
Re-index from the messages cache on every tail change (created/finalize AND
branch switch), not just while submitting. The cache holds the full message set
at switch time, so the viewed branch's response is re-added and its usage
restored from metadata.usage or the sticky history → sumBranch finds it and the
branch cost renders. Verified locally: the branch-switch e2e now passes (the
cost section shows both the branch row and the all-branches total). Also fixed
that e2e assertion to target a single cost value (strict-mode safe).
* 🩹 fix: Handle stopped-stream usage — reset pending + persist abort metadata
Codex round (stop/abort edges):
- Resumable explicit-stop (intentional SSE close) reset UI state but never
cleared pendingUsageFamily, so usage folded before the stop leaked into the
next response in the conversation. Discard pending on intentional close
(resetLive); a resume re-folds via backfillUsage, so nothing is lost.
- The abort save path (abortMiddleware) persisted the stopped response without
metadata.usage/contextUsage, so its cost + breakdown vanished on reload.
Rebuild both from the job's persisted tokenUsage (emitted payloads incl. cost)
and contextUsage snapshot — parity with the normal sendCompletion path;
breakdown gated on a primary usage event like buildResponseMetadata.
Deferred (per scope decision): mid-stream branch-switch transiently shows the
streaming branch's pending on the viewed sibling (cosmetic, until finalize).
* 🩹 fix: Persist abort metadata on the real agents route + tighten snapshot gate
Codex round (corrects last round's wrong-path fixes):
- Stopped AGENTS responses are saved by routes/agents/index.js (/chat/abort),
not abortMiddleware — so last round's metadata fix never ran for them. Moved
the rollup/snapshot builder into packages/api as buildAbortedResponseMetadata
(shared, unit-tested) and applied it in BOTH abort save paths, so a stopped
agent reply keeps its cost + breakdown on reload.
- Persist the breakdown only when the FINAL visible call emitted usage: track a
per-response snapshot count and require primaryUsageCount >= snapshotCount.
Previously any earlier primary usage event passed the gate, so a multi-call
turn whose final call emitted no usage_metadata used an earlier call's output
as completedOutputTokens (already counted by the latest snapshot) → reload
over-reported. Now it falls back to the coarse estimate.
Resumable stop pending-reset (prior round, 3cde6fe035) already flows through
clearAllSubmissions → SSE close → the intentional-close handler's resetLive.
Deferred per scope: mid-stream branch-switch pending attribution (tracked).
* 🩹 fix: Abort breakdown over-count + resume re-fold after pending discard
Codex round (on the re-applied abort/snapshot work):
- buildAbortedResponseMetadata now persists ONLY the usage/cost rollup, not the
context breakdown. The abort path can't tell whether the final call emitted
usage (the job stores only the latest snapshot, not a count), so persisting
the breakdown risked reusing an earlier call's output as completedOutputTokens
(already in the snapshot) → reload over-count. Stopped/incomplete responses
now fall back to the coarse gauge estimate, which is safe and apt.
- resetLive now also forgets the conversation's folded usage-event identities
(clearUsageFolded). Discarding pending on a terminal/intentional close left
the folded keys set, so a later resume's backfillUsage saw the persisted
events as duplicates and never rebuilt pending — leaving the response's usage
missing until a full reload. Clearing them lets the resume re-fold.
* 📊 feat: Real-Time Context Window & Token Usage Tracking
* 🧪 fix: Align Pricing Spec Dep Signatures with TxDeps
* 🩹 fix: Resolve Codex Findings for Context Usage Tracking
* 📊 feat: Granular Tool Token Breakdown with Deferred Splits
* 🧪 test: Cover Session Cost in Mock E2E and Scope Usage Selectors
* 🧪 test: Live Host-Pipeline Usage Verification (Env-Gated)
* 🧪 test: Local Real-Provider Multi-Turn E2E Harness
* 🪙 fix: Keep Tagged Usage Buckets Out of the Live Context Estimate
* 🩹 fix: Scoped Token-Config Fallback and Sequential Visibility for Usage Events
* 🩹 fix: Address Usage Review Findings — Cost Timing, Scoped Caches, Finalized Output
- carry the post-snapshot output estimate into the context snapshot at
finalize so the gauge keeps the last response after live resets
- accumulate per-rate billable units and price the session cost at
render, so usage events arriving before the token-config load still
count once it resolves
- pass user-scoped token-config cache keys through loadConfigModels
fetches and drop the controller's unscoped fallback to prevent serving
another user's resolved config
- tag emitted usage events with a per-run seq so resume dedupe never
drops a distinct call with an identical payload
- admit the static tokenConfig override in the custom endpoint schema so
it survives zod parsing into req.config
* 🩹 fix: Align Client Usage Accounting with Backend Cost Semantics
- classify cache tokens by provider (shared inputTokensIncludesCache from
data-provider, consumed by both the backend billing path and the client)
instead of a magnitude heuristic, so Anthropic/Bedrock turns where cache
is smaller than uncached input no longer under-bill input
- mirror resolveCompletionTokens on the client so Vertex-style hidden
thinking tokens are reflected in the Output row and session cost
- prefer endpoint pricing over adapter-provider pricing so a custom
endpoint can price a known model name without built-in rates shadowing it
- carry static cacheRead/cacheWrite overrides through the tokenConfig
schema and buildTokenConfigMap
* 🩹 fix: Honor Static Token Config in Billing; Tighten Usage Freshness
- initializeCustom now uses a static endpoint tokenConfig as the agent's
endpointTokenConfig (billing + balance checks), not just the advertised
UI config — previously the gauge showed admin rates while the agent
billed against built-in tables
- invalidate the token-config query alongside models on user-key add/
revoke so context windows and pricing refresh without a reload
- include maxContextTokens in ChatForm's stabilized conversation memo so
the gauge reflects a changed context-window setting immediately
- feed the live output estimate from the legacy content path (direct and
assistants streams), setting from cumulative part text rather than
accumulating deltas
* 🩹 fix: Resume Usage Dedup, Agent Pricing, and Partial Override Billing
- fold usage events idempotently by (runId, seq) so resume backfill no
longer resets the conversation totals — a mid-stream reconnect keeps the
usage of prompts already completed earlier in the session
- tap replayed pending message/reasoning/content events so output streamed
past the resume snapshot reaches the live estimate, not just the message
- resolve cost against the agent's backing endpoint (Agents conversations
report endpoint `agents` / provider `openAI`, neither of which keys a
custom endpoint's tokenConfig)
- getMultiplier/getCacheMultiplier fall back to the standard tables for
models absent from a partial endpointTokenConfig, so a partial static
override no longer bills non-listed models at defaultRate while the UI
shows the correct pattern rate
* 🩹 fix: Repaired Output in Gauge, Cache-Rate Keys, Config Gate, Usage Cleanup
- live/completed gauge counts the repaired completion (normalized output),
so under-reporting providers don't drop the response from used context
- translate static tokenConfig cacheWrite/cacheRead onto the write/read
keys getCacheMultiplier reads, so cache tokens bill at the configured
rate instead of the prompt-rate fallback
- clear the token index and usage atoms when leaving a conversation, so
visited histories don't accumulate in memory for the tab's lifetime
- wait for startupConfig before mounting the gauge, so a deployment with
contextUsage disabled never briefly mounts it or fires the token-config
query on first load
* 🩹 fix: Move Token-Config Resolution to TS; Key Live Usage by Created Convo
- extract the token-config resolution (override gathering + cache lookup +
buildTokenConfigMap) into resolveTokenConfigMap in packages/api, leaving
the /api controller a thin request-scoped wrapper (CLAUDE.md TS rule)
- getConvoKey prefers the user message's real conversationId once the
`created` event stamps it, so a new chat's first-response live gauge and
totals land under the id TokenUsage subscribes to instead of NEW_CONVO
* 🩹 fix: Clear Stale Redis Job Usage; Live-Tap Legacy Streams; Share Fetched Config
- DEL the Redis job hash before re-creating it so a reused streamId can't
inherit a prior run's contextUsage/tokenUsage and backfill stale usage
- tap the legacy {message,text} stream branch (non-agent OpenAI/Anthropic
streams) into the live estimate, not just the content path
- copy a deduped fetch's token config to every sibling endpoint sharing the
baseURL/key/headers, so /token-config resolves each by its own name
* ⏪ revert: Don't DEL Redis job hash in createJob (breaks cross-replica resume)
createJob is an idempotent join — a second replica calls it for the same
streamId to share an in-flight stream's state. DELeting the hash wiped the
prior replica's persisted created/usage state, so a joining replica missed
the created event (GenerationJobManager cross-replica integration test).
Reverts the F1 change from 2bfce0c34b; the stale-usage concern doesn't
arise in practice (streamId is unique per generation).
* 🩹 fix: Best-Effort Usage Emit; Tag Hidden Sequential-Agent Usage
- wrap the ModelEndHandler usage emit in try/catch so a failed telemetry
delivery (closed SSE / Redis publish error) can't abort the handler
before thought-signature capture, which would break resumed tool calls
- tag hidden sequential-agent usage as 'sequential' (non-primary) so the
client folds it into session cost/totals but not the live context gauge,
instead of letting an undefined usage_type inflate the visible gauge
* 🩹 fix: Refetch Stale Token Config on Mount; Normalize Vertex for Lookup
- useTokenConfigQuery refetches on mount when stale, so a user-key change
that invalidates tokenConfig while the gauge is unmounted takes effect on
return instead of serving the prior key's resolved config
- normalize a Vertex-backed agent's provider (vertexai) to the google
token-config key, so Gemini context windows and rates resolve instead of
showing unknown context / $0 cost
* ✨ feat: Server-Side Per-Event Cost (Authoritative Pricing for the Gauge)
Move usage-cost pricing to the single source of truth. The backend prices
each model call with the same billing functions (premium tiers via
getMultiplier(inputTokenCount), cache rates) and emits the USD cost on
on_token_usage when interface.contextCost is enabled; the client sums
emitted costs instead of re-deriving from base token-config rates.
- computeUsageCostUSD reuses prepareTokenSpend/prepareStructuredTokenSpend
so the emitted cost matches what is billed (incl. premium thresholds)
- getDefaultHandlers gains a usageCost pricing context; initialize.js wires
db.getMultiplier/getCacheMultiplier gated on contextCost (agents path)
- client UsageTotals carries a summed costUSD; retire the client-side rate
lookups (costFromUnits/calcUsageCost) that drifted from backend pricing
and produced the provider-keying / cache-key / Vertex / premium findings
- keep normalizeUsageUnits for the displayed token counts; token-config is
still used for the context-window meter
Fixes the premium-tier session-cost under-report (gpt-5.x / gemini-3.1
above their input thresholds).
* 🩹 fix: Branch-Accurate Usage Snapshot + Clearer Gauge Track Contrast
- re-anchor the context snapshot from the user message to the response
message at finalize. Regenerating a response branches off a shared user
message, so anchoring on it made the snapshot read as "active" on both
branches — switching to the sibling branch showed the wrong (other
branch's) context. The response message is branch-unique, so sibling
branches now correctly fall back to their own per-branch totals.
- raise the gauge ring's track/fill contrast (muted track, prominent fill)
so the used portion reads clearly as a fill-level indicator
* 🩹 fix: Tag Sequential Usage in Billing; Emit Subagent Cost; Reset Live on Resume Errors
- tag hidden sequential-agent usage `usage_type: 'sequential'` on the
COLLECTED usage (not just the emit), and treat it as non-primary in
recordCollectedUsage (billed, excluded from the reported output total) so
hidden intermediate output stops inflating the parent's tokenCount/pruning
- emit on_token_usage from the subagent usage sink (tagged `subagent`, with
authoritative cost when contextCost is on) so the gauge's session
cost/totals include billed subagent usage; it stays out of the live meter
- call resetLive on the resumable 404 and max-retry terminal branches so the
gauge doesn't keep counting stale in-flight tokens after the stream ends
* 🎨 fix: Contrast the Popup Context Bar; Revert Ring Restyle
- raise the popup breakdown's context progressbar contrast (muted
surface-tertiary track, prominent text-primary fill) — that's the bar the
contrast feedback was about
- revert the gauge ring restyle (kept its original border-heavy track /
text-secondary fill); the ring wasn't the element in question
* 🩹 fix: Stop Snapshot Granularity Leaking Across Branches; Revert Tree Memo
- a null-anchor context snapshot was treated as active on every branch,
leaking one generation's granular breakdown onto sibling branches. Require
a non-null (response-message) anchor on the viewed branch instead, so
siblings without a matching snapshot fall back to their own totals.
- revert the buildTree WeakMap memo in messages.ts. buildTree is pure (builds
from shallow copies) so the memo was behaviorally identical, but it was the
feature's only change to core branch-navigation selectors — removing it
matches upstream and rules it out of branch-navigation debugging.
* 🪙 fix: Thread Endpoint Token Config to Agent Billing, Cost, and Context Limits
Custom-endpoint agents resolve an endpointTokenConfig during agent init but
it never reached the AgentClient, so spending, emitted cost, and runtime
max-token resolution all fell back to default rates for those agents.
- Surface options.endpointTokenConfig on the returned InitializedAgent.
- Pass it to the AgentClient (this.options.endpointTokenConfig) so the
spending path bills at configured rates.
- Thread it through usageCost to computeUsageCostUSD so emitted per-event
cost matches billing.
- getModelMaxTokens/getModelMaxOutputTokens fall back to the built-in map
for models absent from a partial override (matches buildTokenConfigMap);
consolidates the duplicated fallback in pricing.ts.
* 🪙 fix: Preserve Granular Breakdown Across Branch Switches
The granular context breakdown lives only in the live on_context_usage
snapshot — a single per-conversation slot, anchored to the latest response
and overwritten by each generation. Switching to a branch generated earlier
this session lost its tool/skill/system rows and fell back to coarse totals.
Retain each generation's finalized snapshot in a per-conversation map keyed
by its branch-unique response id (snapshotsByAnchorFamily). When the live
snapshot is off the viewed branch, walk the branch tail for its deepest
stored anchor and render that breakdown. Bounded by generation count and
cleared on conversation switch; the live/just-generated path is unchanged.
* 🪙 fix: Harden Resume Seeding and Subagent Usage Emission
- useResumableSSE: skip the trailing-output live seed when the resume
carries a context snapshot; the snapshot's messageTokens already counts
produced output, so seeding it again inflated usage until the next reset.
- AgentClient subagent emitter: await GenerationJobManager.emitChunk like
every other caller (it persists before publishing), so a floating promise
can't race job cleanup and a Redis/publish failure is caught by the
emitter's try/catch instead of surfacing as an unhandled rejection.
* 🧪 test: Playwright Coverage for Context Breakdown Granularity
Add a test-only data-testid distinguishing the granular snapshot breakdown
(context-breakdown) from the coarse message-history estimate
(context-estimate), then assert granularity in the mock e2e harness:
- renders the granular breakdown from the live on_context_usage snapshot
(guards that the snapshot event actually reaches the popover, not just the
usage totals).
- preserves the granular breakdown after switching branches — regenerate to
overwrite the single live snapshot, switch back, and confirm the rows
survive via the per-anchor snapshot history map.
Branch regenerate/sibling selectors mirror the existing chat.spec branch test.
All three usage specs pass against the mock pipeline.
* 🪙 fix: Correct Resume Live-Seed, Fallback Re-index, and Subagent Emit Flush
Codex round on the prior commit:
- countTrailingOutputChars now counts only output at the very END of the
aggregated content (0 when the model paused at a tool call), and the resume
path always seeds it. The earlier skip-trailing-tool-parts behavior plus the
skip-seed-when-snapshot gate together over- or under-counted in-flight
output on resume; one rule fixes both — pre-invoke snapshot budget is never
double-counted, and genuine in-flight output is no longer dropped.
- useTokenUsage re-indexes from the messages cache on tail change while
submitting. The cache subscriber is muted during streaming, so without a
context snapshot (non-agent streams) sumBranch missed the created tail and
dropped history + prompt until finalize. Bounded — tailId only shifts on
created/finalize/branch-switch.
- AgentClient tracks subagent usage emit promises and flushes them in
chatCompletion's finally. The sink fires the emitter without awaiting, and
resume reads the usage emitChunk persists (HSET), so cleanup must not race
it or resumed clients miss billed subagent usage.
* 🧾 fix: Bill Subagent Child-Run Model Usage in Parent Transactions
* 🩹 fix: Type Subagent Usage Sink Structurally Until SDK Release
* 🔧 chore: Update @librechat/agents dependency to version 3.2.35 in package-lock.json and related package.json files
* 🗄️ fix: Gate Request-Scoped MCP Servers Out of Persistent Tool Cache
PR #13626 established that request-scoped MCP servers (runtime
OPENID/GRAPH/BODY placeholders) must not use the persistent 12h tool
cache, but only gated three of five touchpoints. The panel endpoint
still back-filled the cache and the OAuth callback still wrote to it,
while agent loading read those entries ungated — pinning ephemeral
model-spec/agent toolsets to stale definitions for up to 12h.
Centralize the invariant in createMCPToolCacheService: a getServerConfig
resolver dep gates both writers and a new service-owned getMCPServerTools
read, so every current and future caller is covered. Callers that already
hold the parsed config pass it to skip resolution; the per-call skipCache
flag and duplicated call-site gates are removed in favor of the single
config-based mechanism. Resolution failures fail open to preserve prior
behavior.
* 🩹 fix: Address Codex Review on Cache Gating
- Repair getCachedTools.spec.js, which destructured the relocated
getMCPServerTools directly from the module; its coverage now lives in
the service-level tools.spec.ts.
- Resolve the merged (Config-tier-aware) server config in the OAuth
callback before writing tool definitions, so the cache gate detects
request-scoped servers supplied via admin Config overlays that the
base registry lookup cannot see.
- Discover tools actively for request-scoped servers in the panel
endpoint via ephemeral reinitialization: such servers have no stored
app/user connections, so the previous getServerToolFunctions fallback
returned an empty toolset once the cache read was gated.
* 🧵 fix: Address Second Codex Review on Cache Gating
- Resolve the merged server config before the OAuth callback reconnects,
so the connection itself uses Config-tier overlays rather than only
the subsequent cache write.
- Pass Config-tier candidates into the panel's request-scoped discovery,
matching the reinitialize route: reinitMCPServer forwards configServers
(not the provided serverConfig) to its OAuth discovery fallback.
- Document the accepted read-path trade-off: the gate resolver sees base
configs only, all writers pass merged configs, so a pre-gating or
overlay-divergent entry survives at most one cache TTL.
* 🚏 chore: Rework Cache Gating for BODY-Only Request Scoping
After #13673 narrowed requiresEphemeralUserConnection to BODY
placeholders, the central gate follows the predicate unchanged, but the
panel's active discovery no longer serves a purpose: the only remaining
request-scoped class cannot connect outside a chat turn, so the
reinitialization attempt would always fail at the missing-body check.
Remove that path; OpenID/Graph servers are persistent user-scoped again
and flow through the stored-connection and cache lookups as before.
Flip test fixtures that used OPENID placeholders to denote
request-scoped configs over to BODY placeholders.
* 🪟 fix: Check Config Overlays in Agent-Loading Cache Reads
The cache service's registry resolver sees only base YAML/DB configs, so
a BODY placeholder introduced by a request-tier Config overlay was
invisible to the gate on the agent-loading read path: model-spec and
ephemeral-agent expansion could read a leftover persistent entry and pin
stale concrete tool names instead of the mcp_all fresh-discovery path.
Check the raw overlay candidate inline in loadEphemeralAgent and
loadAddedAgent — a pure placeholder scan with no extra IO — and skip the
cache read when the overlay makes the server request-scoped. Widen
UserScopedConnectionConfig so raw (pre-inspection) configs qualify for
the scoping predicates, which only check key presence.
* 🧪 test: Guard Run-Scoped MCP Definition Handoff Boundaries
The original ClickHouse breaker storm regressed precisely at field
pass-through boundaries that unit tests of each end could not see:
initializeAgent dropping mcpAvailableTools from its destructure, and the
agent tool context losing it on the way into ON_TOOL_EXECUTE. Add direct
guards on both hops: the loadTools result must surface on the
initialized agent, and the captured toolExecuteOptions closure must
forward it to loadToolsForExecution.
* 🛟 fix: Auto-Recover from Stale Service Worker Assets After Deploys
- 404 missing static assets in the SPA fallback instead of serving index.html
- inline recovery script unregisters stale SWs and reloads once on chunk failure
- route vite:preloadError into the same recovery path for stale lazy chunks
* 🛟 fix: Address Review — SW-Side Recovery, Scoped Unregister, Shared Fallback
- importScripts'd sw-heal.js pings window clients on activation and reloads
ones that can't pong: stale pages carry no recovery code of their own
- scope SW unregistration to the deployment base for subpath installs
- preventDefault vite:preloadError only when a recovery reload was initiated
- extract createSpaFallback and apply the asset 404 guard to experimental.js
* feat: Add GitHub skill sync
* fix: Address GitHub skill sync CI
* fix: Harden GitHub skill sync review paths
* fix: Prevent overlapping skill sync runs
* fix: Address GitHub skill sync review findings
* fix: Satisfy Git ref lint rule
* fix: Address GitHub sync review follow-ups
* fix: Match skill frontmatter closing fence
* fix: Address GitHub sync review cycle
* fix: Address GitHub sync review follow-ups
* fix: Harden GitHub skill sync worker
* fix: Format GitHub sync rollback log
* fix: Address GitHub sync review feedback
* fix: Format skill import parse handling
* fix: Coerce scalar skill frontmatter and correct scheduler timer clear
- parse: coerce numeric/boolean name and description scalars to strings instead of dropping them to empty (restores pre-refactor behavior; preserves absent-vs-empty distinction for the when-to-use fallback)
- scheduler: clear the setTimeout handle with clearTimeout rather than clearInterval
- test: cover non-string scalar frontmatter coercion
* fix: Tolerate trailing whitespace after SKILL.md opening frontmatter fence
extractFrontmatterBlock required the opening fence to be exactly '---\n', so an opener with trailing spaces/tabs (e.g. '--- \n') silently dropped all frontmatter even though the closing-fence regex already tolerates it. Match the opener with /^---[ \t]*\n/ for symmetry. Addresses Codex P3 (parse.ts:24).
* feat: Run GitHub skill sync under a per-source tenant context
Under TENANT_ISOLATION_STRICT, the sync ran with no async tenant context, so the tenant-isolation mongoose hooks threw on every Skill/SkillFile/AclEntry operation; in non-strict mode synced skills were written tenant-less and never matched tenant-scoped reads. Add an optional per-source tenantId to the skillSync config; when set, each source sync runs inside tenantStorage.run({ tenantId }) so skills, files, and public ACL grants are created and listed within that tenant, and the skill row is stamped with the tenantId for correct dedup. Sources without tenantId keep the prior single-tenant behavior. Avoids runAsSystem. Addresses Codex P2 (sync.js:70).
Lock/status/credential bookkeeping stays outside the tenant context (those collections are intentionally global).
* test: Restore dropped tenant-context coverage for GitHub skill sync
The prior commit shipped the getTenantId import in github.spec.ts without the tenant tests that use it (lost in an interrupted edit), which failed the eslint --max-warnings=0 CI job on an unused import. Restore both github.spec.ts tenant tests (tenant-scoped run stamps tenantId and executes inside the tenant ALS context; no-tenant run stays ambient) and the two config-schemas tenant tests (accepts tenantId, rejects __SYSTEM__).
* test: Restore dropped github.spec tenant-context tests
The previous commit's github.spec.ts edit did not apply (anchor mismatch), so the getTenantId import remained unused and failed eslint --max-warnings=0. Add the two tenant tests that use it: a tenant-scoped run stamps tenantId and executes inside the tenant ALS context, and a no-tenant run stays ambient.
* feat: Scope synced skill author to tenant and harden tenant-context sync
Addresses the latest Codex review on the per-source tenant change:
- makeSourceAuthorId now folds tenantId into the synthetic author hash so the
same source mirrored into different tenants gets distinct author ids (clearer
audits, no cross-tenant author collisions). Single-tenant author ids stay
stable (suffix omitted when tenantId is absent).
- syncSourceInTenantContext uses an async callback per the tenant-context
contract so the ALS store propagates across awaited Mongoose calls.
- Tests: same-source/different-tenant yields distinct authors; mirror cleanup
is scoped to the source and deletes only its absent-upstream skills.
* fix: Repair tsc error and guard external edits in github skill sync
- Fix TS2352 in github.spec mirror-cleanup test: build the existing-skill mock via makeSkill with authorName instead of an under-typed 'as CreateSkillInput' cast (this was the failing TypeScript CI check on f00ce3c5a).
- 808: commitExistingRemoteSkillAfterFileSync re-reads to clear our own file-sync version bumps, but now compares refreshed content against the pre-sync snapshot (body/name/description/always-apply) and throws SKILL_CONFLICT on a concurrent external edit instead of overwriting it.
* docs: Note skillSync source tenantId is effectively immutable
Changing/adding/removing a source's tenantId orphans previously mirrored skills in the old tenant (a tenant-scoped sync cannot clean another tenant's data without runAsSystem, which is intentionally avoided).
* fix: Key GitHub skill upstream identity on source id and path only
Addresses Codex finding (github.ts:217): makeUpstreamId previously included owner/repo, so repointing a source to a renamed or replacement repository (same source id) changed the upstreamId, made findSkillBySourceIdentity miss the existing mirror, and then collided on the (name, author, tenantId) uniqueness constraint — leaving the source stuck failing. Identity now keys on the stable source id + root path only. The feature is unreleased, so there is no stored-id migration. Updated spec upstreamId fixtures to the new format; the existing ref-independent identity test now also covers repo moves.
* fix: Scope GitHub skill mirror deletion to the source tenant
Addresses Codex P1 (github.ts:1047/1057): an ambient source (no tenantId) runs listSkillsBySource without tenant context, which under non-strict isolation returns github-synced skills across all tenants. The mirror-deletion pass then treated other tenants' skills as absent-upstream and could delete them. Filter existingSyncedSkills to rows whose tenantId matches the source's configured tenantId (absent = its own ambient bucket) before deleting, so a sync never removes another tenant's mirrored skills. Covered by a test where an ambient run leaves a tenant-b-owned skill untouched.
* fix: Apply tenant-scoped mirror deletion implementation
The prior commit (75ccfa3fc) added the test but the source change to github.ts was lost in an interrupted edit, leaving a failing test with no implementation. This adds the actual guard: the mirror-deletion pass skips skills whose tenantId does not match the source's configured tenantId (absent = ambient bucket), so an ambient source whose listSkillsBySource returns cross-tenant rows under non-strict isolation cannot delete another tenant's mirrored skills.
* fix: Resolve global access role outside tenant context for synced skill grants
Addresses Codex P2 (github.ts:1166): default access roles (incl. skill_viewer) are seeded globally with no tenantId under runAsSystem, but a tenant-scoped sync wraps ensurePublicViewer in the source's tenant context. The PermissionService grantPermission resolved the role via a tenant-isolated AccessRole query, so the global role did not match and tenant-scoped syncs failed with 'Role skill_viewer not found'. The sync adapter now resolves the role inside runAsSystem (matching the global seed) and writes the ACL entry in the active tenant context, so the AclEntry is tenant-scoped (visible to tenant users) while the role lookup still succeeds. Covered by service tests for the resolve-vs-write split and the missing-role failure.
* fix: Strip placeholder frontmatter booleans and check skill conflict before file sync
- 1083 (github.ts:759): toCleanFrontmatter now drops a non-boolean always-apply (e.g. the 'always-apply:' / 'always-apply: # TODO' placeholder, which js-yaml yields as null). The boolean is already captured in the dedicated alwaysApply field; persisting null left ambiguous frontmatter on the synced skill.
- 1080 (github.ts:1057): for an existing mirrored skill, check for an external content edit (via getSkillById + hasExternalSkillEdit) BEFORE syncSkillFiles mutates the bundled files, so a concurrently edited skill fails fast with SKILL_CONFLICT without partial file rewrites. The post-file-sync check still guards edits that land during the file sync window.
Tests: placeholder always-apply is dropped from synced frontmatter; concurrent-edit conflict leaves files unmutated (no upsert/delete).
* fix: Harden GitHub skill sync review paths
* fix: Reuse moved GitHub skill mirrors
* fix: Scope GitHub sync identity conflicts
* test: Fix GitHub sync conflict mock typing
* fix: Support nested env-backed skill sync
* fix: Keep skill sync config base-only
* fix: Scope GitHub skill identity lookup by tenant
* fix: Harden GitHub skill sync admin gates
* fix: Guard existing skill sync permission grants
* feat: Trigger skill sync from resolved config
* fix: Scope resolved skill sync by tenant
* test: Allow manual skill sync status tenant scoping
* refactor: Extract skill sync trigger orchestrator
* test: Complete orchestrator status fixture
* chore: Bump data provider version
* fix: Restrict skill sync server credentials
* test: Complete admin skill sync status fixtures
* fix: tighten skill sync trigger safeguards
* fix: preserve alwaysApply skill sync alias
* chore: sort skill sync imports
* fix: preserve skill sync request scope
* fix: harden skill sync review edges
* refactor: move skill sync admin access to api package
* fix: add skill sync declaration return types
* fix: satisfy skill sync type checks
* fix: resolve codex skill sync review findings
* fix: harden skill sync review edges
* fix: resolve codex skill sync edge findings
* fix: satisfy API declaration build after rebase
* 🤫 fix: Silent MCP OAuth Refresh on Mid-Session 401
Avoids the hourly interactive re-auth prompt when an MCP server
(e.g. Azure Entra ID) returns 401 mid-session by attempting a refresh
token exchange first, and only falling back to the interactive OAuth
flow when no refresh token is stored or the refresh server rejects it.
Resolves#13364.
* fix: Use distinct flow type for silent token refresh to avoid cache hit
Addresses the Codex review on PR #13369: `attemptSilentTokenRefresh` was
reusing the `'mcp_get_tokens'` flow type, so
`FlowStateManager.createFlowWithHandler` would short-circuit and return
the same tokens cached by an earlier `getOAuthTokens` call — the very
tokens the server just rejected — without executing the forced-refresh
handler.
Switch silent refresh to the distinct `'mcp_force_refresh_tokens'` flow
type so coalescing still works but stale `mcp_get_tokens` cache entries
are not reused. After a successful refresh, invalidate the
`mcp_get_tokens` flow cache so the next `getOAuthTokens` call reads the
freshly persisted tokens from storage rather than the stale cached
value.
Add a regression test that simulates the real
`FlowStateManager.createFlowWithHandler` cache-hit behavior for
`mcp_get_tokens` and verifies the silent refresh handler still runs and
returns the freshly refreshed tokens.
* fix: Address Codex round-2 review on silent MCP OAuth refresh
Three follow-up findings from Codex on PR #13369:
1. The new `mcp_force_refresh_tokens` flow type was itself cached by
`FlowStateManager.createFlowWithHandler`, so a subsequent 401 within
the refreshed token's `expires_at` could re-serve the just-rejected
token without ever re-running the refresh handler.
2. The factory's `oauthRequired` listener was removed immediately after
the initial `attemptToConnect` succeeded, so a real mid-session 401
emitted by `MCPConnection.connectClient` during transport recovery
had no listener — the OAuth handled-promise would simply time out
instead of triggering the silent refresh.
3. Routing the silent refresh through a distinct flow type broke
coalescing with the `mcp_get_tokens` lock used by `getOAuthTokens`,
letting two paths concurrently redeem the same stored refresh token.
For providers that rotate refresh tokens (e.g. Azure Entra) the
second redemption is rejected, kicking the user back into interactive
OAuth despite a successful refresh elsewhere.
Resolution:
- Drop `FlowStateManager` from the silent-refresh path entirely. Replace
with a process-local `inflightSilentRefreshes` Map keyed by
`userId:serverName` that holds only the in-flight Promise (no cached
result), so every fresh 401 after settlement triggers a fresh
redemption while concurrent 401s for the same user/server still share
one redemption.
- Stop calling `cleanupOAuthHandlers()` on successful initial connect,
keeping the OAuth handler attached for the connection's lifetime so
mid-session 401s actually reach `attemptSilentTokenRefresh`.
- Add a regression test reproducing the stale-cache scenario by faking
the `mcp_get_tokens` cache hit and asserting silent refresh still runs
against storage and returns the fresh tokens.
- Add a coalescing test asserting two concurrent oauthRequired events
for the same user/server result in a single `forceRefreshTokens` call.
- Clear `inflightSilentRefreshes` in `beforeEach` to prevent
cross-test leakage; switch the silent-refresh test mocks to
`mockResolvedValueOnce` / `mockImplementationOnce` so leftover mock
state cannot leak into later test cases.
Acknowledged remaining gap: the silent refresh still races
`getOAuthTokens`'s `mcp_get_tokens` flow when both run concurrently
(narrow window when an existing connection's local `expires_at` is
still valid but the server invalidated the token, and a new connection
is being created in parallel). The race is self-healing on the next
401 and documented inline.
* fix: Address Codex round-3 review on silent MCP OAuth refresh
Three more findings from Codex on PR #13369:
1. The in-flight silent-refresh promise was unbounded. If
`forceRefreshTokens()` ever hung (slow provider, dropped TCP), the
`inflightSilentRefreshes` lock stayed occupied forever and every
later 401 for the same user/server joined the stuck promise instead
of starting a fresh attempt or falling back to interactive OAuth.
2. The interactive-OAuth fallback didn't invalidate the
`mcp_get_tokens` flow cache after persisting fresh tokens. For
providers that don't issue refresh tokens (so silent refresh
returns null), the old cache could still feed stale access tokens
to the next `getOAuthTokens` call until its TTL expired — causing
an immediate reconnect with the same just-rejected token.
3. When silent refresh failed, the handler fell through to
`handleOAuthRequired()` whose recent-completion fast path can
reuse a COMPLETED `mcp_oauth` flow within `PENDING_STALE_MS`. Those
cached tokens are exactly the ones the server just rejected, so
the connection would keep adopting them and looping on 401s until
the cache aged out.
Resolution:
- Wrap `runSilentRefresh()` with a 60-second `withTimeout` (well under
`connectClient`'s 120s OAuth timeout). On timeout the `.catch`
resolves to null and the `finally` clears the in-flight entry, so
the next 401 starts fresh and falls through to interactive OAuth.
- Extract two helpers — `invalidateGetTokensFlow` and
`invalidateCompletedOAuthFlow` — and call them from the right
branches: clear `mcp_get_tokens` after silent-refresh success AND
after interactive-OAuth `storeTokens`; clear the COMPLETED
`mcp_oauth` state (plus its CSRF mapping) before falling through to
interactive OAuth so the fast-reuse path can't re-serve the
rejected tokens.
- Add three regression tests: hung refresh release-the-lock under
fake timers, completed-OAuth cache invalidation pre-fallback, and
`mcp_get_tokens` invalidation after interactive token store.
* fix: Address Codex round-4 review on silent MCP OAuth refresh
Three more findings from Codex on PR #13369:
1. (P1) The silent-refresh in-flight lock keyed only by
`userId:serverName`. In multi-tenant setups where two tenants share a
userId (e.g. username-based IDs) and the same MCP server name, a
concurrent mid-session 401 from tenant B would join tenant A's
in-flight refresh and adopt tenant A's freshly minted tokens onto a
tenant-B connection — a cross-tenant credential leak.
2. (P2) `invalidateGetTokensFlow` deleted the `mcp_get_tokens` flow
state regardless of its status. When another connection was
currently in `getOAuthTokens()` (PENDING flow) and joiners were
monitoring it, the unconditional delete made those waiters see
"Flow state not found" and unnecessarily fall back to interactive
OAuth — even though fresh tokens were already being written.
3. (P2) The 60s `withTimeout` wrapping `runSilentRefresh()` only races
the promise; it does not cancel the underlying `forceRefreshTokens`
/ refresh-token HTTP request. If the request returned after a
subsequent interactive OAuth had stored newer tokens, the late
completion would `storeTokens` over the newer state. This requires
a provider that doesn't rotate refresh tokens AND a refresh slower
than 60s AND a successful interactive OAuth in that window — narrow
but real.
Resolution:
- Capture `getTenantId()` into a new `factory.tenantId` field at
factory construction time (before the OAuth handler closes over it
outside the original request's async context) and include it in the
silent-refresh lock key as `tenantId:userId:serverName`.
- `invalidateGetTokensFlow` now calls `getFlowState` first and only
deletes when `status === 'COMPLETED'`. PENDING lookups are left
alone so concurrent `getOAuthTokens` waiters via `monitorFlow` can
still settle.
- For (3), document the race as a known limitation inline. Fully
closing it requires threading an `AbortSignal` through
`MCPTokenStorage.forceRefreshTokens` and the OAuth refresh handler
to skip the late `storeTokens` after timeout — out of scope for this
PR's surgical change.
- Add `getTenantId` to the `MCPOAuthConnectionEvents` test's
`@librechat/data-schemas` mock so the factory constructor doesn't
blow up under that suite.
- Add three regression tests: per-tenant lock isolation, PENDING-state
preservation under `invalidateGetTokensFlow`, and (reused) the
existing interactive-store invalidation test now driven through
`getFlowState` returning the COMPLETED state.
* fix: Address silent MCP OAuth refresh review
Restore captured tenant context around token storage and OAuth fallback paths so mid-session callbacks do not lose tenant scope.
Thread AbortSignal through forced refresh and OAuth token requests, cap silent refresh by the connection OAuth timeout, and prevent timed-out refreshes from writing stale credentials after fallback.
Complete pending mcp_get_tokens flows with fresh tokens, add missing FlowState createdAt test fixtures, and cover the new tenant/abort/cache behaviors.
* fix: Tighten tenant-scoped MCP token refresh
Cap silent refresh by both the factory connect timeout and the connection OAuth wait timeout so fallback OAuth wins before the outer connect attempt expires.
Tenant-scope mcp_get_tokens flow ids for both token lookup and refresh invalidation, preventing cross-tenant flow completion or cache deletion when tenants share user ids and server names.
Add regression tests for the omitted initTimeout budget and tenant-prefixed token flow locks.
* fix: Reserve MCP OAuth fallback budget
* fix: Harden MCP OAuth refresh races
* fix: Keep MCP OAuth fallback route-compatible
* test: Add SDK MCP OAuth refresh repro
* fix: Address MCP OAuth refresh review findings
* fix: Address MCP OAuth tenant review findings
* fix: Close MCP OAuth route tenant gaps
* fix: Preserve MCP OAuth refresh flow guards
* fix: Avoid reprocessing MCP OAuth reauth config
* fix: Release timed-out MCP refresh locks
* fix: Release MCP OAuth request callbacks
* fix: Tenant-scope remaining MCP OAuth flow lookups
* ci: Sort imports in MCP OAuth test suites
* 🛡️ feat: Reject chat messages matching configured credential patterns
Adds an opt-in `messagePiiFilter` middleware mounted on the agent
chat route ahead of `moderateText`. When the configured patterns
match the user's input the request is refused with 400, so the
credential never reaches OpenAI moderation, the model, or MongoDB.
Three starter patterns ship by default and operators can subset
them or add their own regex via `customPatterns` in librechat.yaml.
* 🧪 test: Memoize compiled patterns + add middleware spec
Memoize the compiled pattern array via a WeakMap keyed by the
messagePiiFilter config object so repeat requests against the same
config skip the per-request RegExp construction. Cache entries are
released automatically when the config object itself rotates.
Adds packages/api/src/middleware/messagePiiFilter.spec.ts covering
the default-starter rejections, the starterPatterns subset and
empty-array semantics, customPatterns matching layered on top of and
in place of the starters, the no-config and empty-text pass-through
paths, and a memoization regression check.
* 🛡️ fix: Skip invalid customPattern regexes instead of crashing the request
Admin DB overrides for `messagePiiFilter.customPatterns` reach
`req.config` via `mergeConfigOverrides`, which deep-merges raw
override values without re-running `configSchema`. A typo'd regex
like `(` would slip past the YAML-load validation and throw inside
`new RegExp(...)` during `compile()`, returning 500 for every chat
request until the operator rolled the override back.
Wrapped the per-pattern compile in a try/catch that logs the
invalid pattern id + reason and skips it, so other valid patterns
(starters and other custom entries) keep filtering. Added a
regression test alongside the existing spec.
* 🛡️ feat: Extend PII filter to OpenAI-compatible and Responses agent APIs
The chat-route middleware operates on `req.body.text`, but the remote
agent API endpoints (`/api/agents/v1/chat/completions`,
`/api/agents/v1/responses`) accept the same prompt content as a
`messages` array or an `input` field. A caller using their API key
could send a credential-shaped value through either route and bypass
the configured PII filter even though they share the same agent and
model backbone the middleware is meant to guard.
Factored out `findPiiMatchInMessages`, a tolerant walker that handles
both `content: string` and `content: ContentPart[]` user-message
shapes against the same compiled, cached pattern list. Wired it into
the OpenAI-compat controller after agent lookup and into the
Responses controller right after `convertToInternalMessages`. Each
returns the endpoint's native 400 error shape
(`sendErrorResponse` / `sendResponsesErrorResponse`) with the
`message_pii_filter_block` code when a user message matches.
* 🩹 test: Add findPiiMatchInMessages to OpenAI + Responses controller mocks
The OpenAI-compat and Responses controller specs mock `@librechat/api`
with a hand-listed object. The new `findPiiMatchInMessages` export
wired into both controllers in 3ea35af9a was missing from those
mocks, so the production lookup returned undefined and the controllers
threw at request time under jest. Added the missing entries (default
mock: returns null so the handlers fall through to the existing happy
paths). All 278 agents-controller tests pass locally.
* 🧹 refactor: Namespace messagePiiFilter under messageFilter.pii + fix import order
Renames the yaml field `messagePiiFilter` to `messageFilter.pii`, the
module to `messageFilterPii`, the factory to `createMessageFilterPii`,
the type to `MessageFilterPiiConfig`, and the error code to
`message_filter_pii_block`. The wrapper `messageFilter` namespace
gives future safety filters (e.g. `messageFilter.toxicity`) a place
to plug in without restructuring the config later. The
`findPiiMatchInMessages` helper kept its name because it already
describes what it does at the value level.
Also fixes import order Danny flagged on the OpenAI-compatible and
Responses controllers: `findPiiMatchInMessages` was appended at the
bottom of two `require('@librechat/api')` destructures rather than
placed in the length-sorted slot the house style expects.
* 🧹 chore: Length-sort the general require destructure in responses.js
Reorders the general sub-group inside the `require('@librechat/api')`
destructure shortest to longest so the whole block conforms to the
length-sort rule the file's `// Responses API` sub-group already
follows. Pure reorder, no other changes.
* 🧹 chore: Length-sort the defaultConfig block in AppService
Reorders the `defaultConfig` keys in `packages/data-schemas/src/app/service.ts`
shortest-line to longest-line, with the explicit-value entries
(`mcpConfig`, `fileStrategies`, `cloudfront`) trailing the shorthand
ones. Pure reorder, no behavior change.
* fix: Resolve MCP Runtime User Placeholders
* fix: Harden MCP Runtime Placeholder Connections
* fix: Update MCP Source Tag Test Expectations
* fix: Complete MCP Runtime Placeholder Reinit
* fix: Harden MCP Request Scoped Runtime Configs
* fix: Align MCP OAuth Tests With Domain Policy
* fix: Harden MCP Runtime Resolution Edges
* fix: Avoid MCP Runtime Reprocessing Pitfalls
* fix: Reuse MCP Request Scoped Tool Discovery
* fix: Validate MCP Body Runtime Fields
* 🛡️ refactor: Harden runtime placeholder edges from review
- Warn at inspection when a trusted server URL contains runtime
placeholders but no domain allowlist restricts the resolved target
- Document the three resolution sites that must stay in sync so the
validated config always matches the connected one
- Note the per-call connect cost of ephemeral GRAPH/BODY connections
- Drop the no-op removeUserConnection in callTool's ephemeral cleanup;
ephemeral connections are never stored, and removing the entry could
orphan a still-connected cached connection after a config change
* 🪪 fix: Cover oauth_headers, Graph URL gating, and request-scoped reconnects
Address Codex review:
- Resolve runtime placeholders in oauth_headers (processMCPEnv + Graph
pre-pass) and include the field in placeholder detection, so OAuth
discovery/token requests no longer send literals; consolidate the
detection field lists into one helper
- Defer the early domain gate when the URL still carries a Graph
placeholder (resolved async later); the authoritative
assertResolvedRuntimeConfigAllowed check still enforces policy
- Bypass the 10s reconnect throttle for request-scoped servers, which
re-fetch tool definitions on every message by design
* ⏳ fix: Extend and decouple MCP OAuth flow timeouts
The OAuth auth button disappeared after 2 minutes (the internal OAuth
handling timeout) while the flow state lived for 3 minutes, leaving users
who didn't click immediately stuck in an unrecoverable re-auth loop. The
handling timeouts also reused the connection/init timeout, so a short
initTimeout would shrink the OAuth window further.
- Add MCP_OAUTH_HANDLING_TIMEOUT (10m) and MCP_OAUTH_FLOW_TTL (15m) to mcpConfig
- Decouple the reactive/proactive OAuth waits from initTimeout/connectionTimeout
- Use OAUTH_FLOW_TTL for the FlowStateManager TTL and the UI status window
- Ensure the flow TTL outlives the handling timeout, fixing the
"Flow state not found" race
- Remove dead FLOW_TTL constant and document new env vars
Fixes#13615
* ⏳ fix: Coordinate OAuth pending window with handling timeout
Address Codex review: the extended OAuth wait was still capped by other
timeouts that were not updated.
- Align PENDING_STALE_MS (button validity + pending-flow reuse window)
with MCP_OAUTH_HANDLING_TIMEOUT so a flow stays reusable for the full
wait instead of 2 minutes (Finding 3)
- Clamp MCP_OAUTH_FLOW_TTL to never fall below the handling timeout so a
callback near the deadline still finds its flow state (Finding 2)
- Floor attemptToConnect's timeout to the handling window for OAuth
servers so the reactive in-connect OAuth wait is not killed by the
30s connection timeout (Finding 1)
- Update flow staleness tests to reference the threshold symbolically
* ⏳ fix: Align OAuth window across status, action flows, and client polling
Address Codex round 2: extending the server wait exposed three more
windows that were still capped or now over-extended.
- checkOAuthFlowStatus reports a PENDING flow as active only within the
usable PENDING_STALE_MS window, not the longer Keyv retention TTL, so
the connect button reappears instead of a stuck 'connecting' state
- Give Action (custom tool) OAuth its own FlowStateManager on the prior
3-minute TTL so the longer MCP OAuth TTL can't leave an action tool
call waiting up to 15 minutes
- Extend the MCP server-card client polling to the 10-minute handling
window so a user who completes OAuth after 3 minutes is still picked up
* 🧪 test: Make stale-flow CSRF test track PENDING_STALE_MS
The CSRF-fallback stale-flow test hardcoded a 3-minute age, which is now
within the 10-minute PENDING_STALE_MS window and was wrongly treated as
active. Derive the age from PENDING_STALE_MS so it tracks the constant.
* ⏳ fix: Add grace buffers and surface OAuth timeout to the client
Address Codex round 3 (near-deadline edges):
- Clamp MCP_OAUTH_FLOW_TTL to handling timeout + 60s grace (not equality),
so flow state outlives the wait instead of expiring at the same instant
- Extend attemptToConnect's OAuth floor by a 60s grace so a user who
authorizes near the deadline still gets the post-OAuth reconnect
- Surface OAUTH_HANDLING_TIMEOUT on the connection-status response and
have the client poll for the configured window instead of a hardcoded
10 minutes, so a tuned server deadline isn't capped on the client
* ⏳ fix: Refresh client OAuth timeout from the first status refetch
If the connection-status cache is empty when polling starts, the client
captured the 10-minute fallback and never picked up a tuned oauthTimeout.
Re-read it after each refetch so a longer configured deadline is honored
even on a cold cache.
* 📝 refactor: Type oauthTimeout on MCPConnectionStatusResponse
Declare the oauthTimeout field on the shared response type in
data-provider instead of an ad-hoc inline cast in the client hook, and
replace the pre-existing 'as any' on the status query read with the
typed getQueryData. Type-level only; no runtime change.
When a skill is primed fresh this turn (manual $-popover or always-apply) AND
also appears in history as a `skill` tool_call, its SKILL.md body was injected
twice — once by injectSkillPrimes and once reconstructed by formatAgentMessages.
- add `collectFreshSkillPrimeNames` helper (packages/api) — union of manual +
always-apply prime names
- client.js: pass the set as `skipSkillBodyNames` to formatAgentMessages for
both the initialMessages and memoryMessages paths so the body reconstructs
once. Names not primed this turn still reconstruct (sticky manual re-prime).
Requires `@librechat/agents` with `skipSkillBodyNames` support; the published
dist silently ignores the unknown option until upgraded.
* 🧰 fix: Flatten union schemas for Gemini/Vertex MCP tool compatibility
`@langchain/google-common`'s `zod_to_gemini_parameters` throws "Gemini cannot
handle union types" on any genuine `anyOf`/`oneOf` (e.g. discriminated unions),
so MCP tools shipping union-typed schemas crash on the Google endpoint while
working fine on OpenAI/Claude.
Add `flattenJsonSchemaUnions` (packages/api) to collapse unions to their first
non-null member and multi-entry `type` arrays to a single nullable type, and
apply it in `createToolInstance`'s existing `isGoogle` branch so only the
Google/Vertex path is affected. Lossy by design, mirroring the existing
empty-object fallback.
Closes#13612
* 🩹 fix: Address Codex review — preserve fields, strip null enums, cover definitions path
- Preserve parent-level `properties`/`required` when collapsing a union: merge the
chosen branch into the parent instead of overwriting, so args declared outside the
union (e.g. always-required fields) still reach Gemini.
- Drop the `null` member from `enum` when a union/type-array makes a field nullable,
keeping Gemini's required homogeneous-enum invariant.
- Propagate the Google-flattened schema to the definitions/deferred-tool path:
thread `provider` into `loadToolDefinitions` and flatten there, and store the
flattened schema on `mcpJsonSchema` so `extractMCPToolDefinition` no longer emits
raw unions on Google/Vertex.
* 🎨 style: Sort imports in tools/definitions per import-order check
* ♊ feat: Broaden union flatten into a full Gemini schema sanitizer
The union flatten alone wasn't enough — real GitHub MCP tools on Gemini also 400
with `Invalid value ... (TYPE_STRING), true`, because Gemini's function-calling
Schema (https://ai.google.dev/api/caching#Schema) accepts only a restricted JSON
Schema subset, and `enum` is `Type.STRING`-only.
Rename `flattenJsonSchemaUnions` → `sanitizeGeminiSchema` and broaden it (one pass,
Gemini-gated) to cover the documented subset:
- Keep only string `enum` values; drop the keyword for non-string types (fixes the
reported boolean-enum 400, incl. boolean `const` normalized to `enum: [true]`).
- `const` → single-value string enum, or drop if non-string.
- Merge `allOf` intersections; fold `exclusiveMinimum`/`exclusiveMaximum` into
`minimum`/`maximum`.
- Strip unsupported keywords: `additionalProperties`, `default`, `$schema`, `$id`.
- (Existing) collapse `anyOf`/`oneOf`, multi-entry `type` arrays, nullable.
Grounded in Google's Schema docs rather than reverse-engineered from 400s. Verified
end-to-end against the real `@langchain/google-common` converter. Complements
danny-avila/agents#232 (langchain bump), which defers schema flattening to LibreChat.
* 🩹 fix: Gate enum retention on the effective (collapsed) type
Codex review: a mixed-type enum like `type: ['integer','string'], enum: [1,'auto']`
collapsed the type to `integer` but still kept the string value `'auto'`, yielding
`{type:'integer', enum:['auto']}` — a non-string type with an enum, which Gemini
rejects. Keep `enum` only when the effective collapsed type is string (or unset),
and stamp `type: 'string'` on a surviving typeless enum (e.g. a string `const`
discriminator) so it satisfies Gemini's Type.STRING enum requirement.
* feat: surface message feedback (thumbs up/down) as Langfuse scores
When Langfuse tracing is enabled, the message feedback endpoint now posts a
boolean `user-feedback` score (1/0 + tag/comment) to Langfuse for the
assistant message's trace; clearing feedback deletes the score. Fire-and-
forget, so the feedback UX never blocks on Langfuse.
Linking is lookup-free: the run opts into deterministic Langfuse trace ids
(`langfuse.deterministicTraceId`, passed to the agents Run), so the trace id
is sha256(messageId)[:32]. The feedback route recomputes the same id and
scores by it.
- api/server/services/Langfuse.js: POST/DELETE /api/public/scores (env-gated)
- api/server/utils/langfuseTrace.js: traceIdForMessage(messageId)
- api/server/routes/messages.js: fire feedback score after the Mongo write
- packages/api: pass langfuse.deterministicTraceId to the run
- bump @librechat/agents to ^3.2.21 (adds LangfuseConfig.deterministicTraceId)
Closes#13537
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* fix: match Langfuse trace environment for feedback scores
@librechat/agents passes no environment to its Langfuse tracer, so
@langfuse/otel falls back to LANGFUSE_TRACING_ENVIRONMENT and otherwise to
Langfuse's "default". The score helper instead fell back to NODE_ENV, so a
deployment with only NODE_ENV=production filed scores under "production" while
the trace stayed on "default" — the score never landed on the trace.
Use LANGFUSE_TRACING_ENVIRONMENT only, and omit `environment` when unset so
Langfuse defaults both score and trace to "default".
Addresses Codex review on #13544.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* fix: don't require LANGFUSE_BASE_URL to post feedback scores
The agent tracer emits traces with just the public/secret keys (defaulting to
Langfuse Cloud, or via the legacy LANGFUSE_BASEURL alias), but the score helper
disabled itself unless LANGFUSE_BASE_URL was set — so an otherwise-traced
deployment silently posted no scores. Resolve the base URL the same way the
tracer does (LANGFUSE_BASE_URL -> LANGFUSE_BASEURL -> Cloud) and gate enablement
on the credentials only.
Addresses Codex review on #13544.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* fix: only post feedback scores for agent-endpoint messages
The feedback route is shared by all message types, but deterministic Langfuse
trace IDs are only enabled for agent runs. Rating a message from a non-agent
endpoint (with Langfuse configured) posted a user-feedback score for
sha256(messageId) that no trace will ever match, leaving orphan scores.
Gate scoring on isAgentsEndpoint(message.endpoint); `updateMessage` now returns
`endpoint` so the route can check it.
Addresses Codex review on #13544.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* fix: gate feedback scoring by !isAssistantsEndpoint, not isAgentsEndpoint
The previous gate used isAgentsEndpoint, which only matches the literal
`agents` endpoint. But provider endpoints (anthropic, openai, custom, …) run
through the agents runtime as ephemeral agents and DO emit deterministic
AgentRun traces, so isAgentsEndpoint('anthropic') === false suppressed scoring
for the common case. Only the OpenAI/Azure Assistants endpoints use a separate
runtime with no agent trace, so gate on !isAssistantsEndpoint instead.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* style: sort message method imports
* fix: honor Langfuse tracing gates for feedback scores
* refactor: move Langfuse feedback logic to api package
* fix: support Langfuse host for feedback scores
* test: type Langfuse feedback fetch mock
* chore: compact Langfuse feedback comment
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-authored-by: Danny Avila <danny@librechat.ai>
Immediate title generation discarded an already-generated title when the
user stopped the turn, both in the backend (skipped saveConvo) and the
frontend (rolled back the streamed title), leaving the chat as "Untitled"
in the interim and "New Chat" after refresh.
Split the title abort into two signals: `signal` still cancels an in-flight
title model call on Stop, while a new `discardSignal` discards an
already-generated title only when the stream is superseded by a newer run
or the turn fails. A plain user Stop now persists and keeps the title.
The frontend no longer rolls back a real, already-applied title on an
aborted final event.
* feat: make OpenID token reuse window configurable via OPENID_REUSE_MAX_SESSION_AGE_MS
The OpenID session-token reuse window in AuthController was a hardcoded 15-minute
constant, forcing /api/auth/refresh to perform a real refreshTokenGrant against the
IdP every 15 minutes even when the current access token is still valid. IdPs that
rotate and revoke the previous access token on refresh then invalidate a token that
is still in use by downstream consumers of the reused OpenID token (e.g. MCP servers
that receive {{LIBRECHAT_OPENID_TOKEN}} and introspect the bearer), producing
~15-minute 401 cycles regardless of the access token's actual lifetime.
Read the window from process.env.OPENID_REUSE_MAX_SESSION_AGE_MS via the existing
math() helper, so it accepts an arithmetic expression like SESSION_EXPIRY (e.g.
60 * 60 * 24 * 1000), defaulting to the existing 15 minutes so behavior is unchanged
unless explicitly configured. The existing 30s-before-expiry guard still forces a
refresh before genuine expiry, so a larger window remains safe.
* fix: extend OpenID reuse session lifetime
---------
Co-authored-by: Danny Avila <danny@librechat.ai>
