[Due for payment 2026-08-21] [$250] Concierge optimistic reveal: switch to a flat cadence

[MelvinBot]

Problem

Concierge's optimistic reply reveal ("trickle") feels noticeably slow compared to ChatGPT and Claude. It's driven by an ease-out curve over a fixed total duration, which produces a variable rate (~13–19 chars/sec at the start decaying to ~7 chars/sec at the end, ~6.7 avg) rather than a steady typing feel.

Updated plan (flat cadence, optimistic path only)

Present the optimistic response at a flat, constant cadence — drop the ease-out curve and the fixed-total-duration knob from the optimistic reveal so it reveals at a steady rate regardless of length. Once server streaming speed improves, the "balanced timing" that these knobs provided is no longer needed.

Important constraint — do not touch the server-response trickle. DEFAULT_STREAM_DURATION_MS and easeOut are not optimistic-only. They are also consumed by the server-streamed reveal in src/pages/inbox/usePusherDraftPacing.ts (via getRevealDurationMS + easeOut, and TICK_INTERVAL_MS for its tick). So they cannot be deleted outright without changing server-response behavior. The plan scopes the flat-cadence change to the optimistic path only and leaves the shared constants and the server path exactly as they are on main.

Changes

1. Revert the earlier shared-constant tweak. DEFAULT_STREAM_DURATION_MS (15,000) and TICK_INTERVAL_MS (80) go back to their main values. The first version of this work lowered these two constants, but because the server path reads them too, that also made server-streamed replies abrupt (the behavior Shawn flagged). Reverting them fully restores server-response pacing.
2. Flat cadence for the optimistic path in src/hooks/usePendingConciergeResponse.ts: the optimistic reveal no longer uses DEFAULT_STREAM_DURATION_MS or easeOut. It now reveals at a constant rate via a new dedicated constant OPTIMISTIC_FLAT_MS_PER_TOKEN (~30 chars/sec), with linear progress instead of ease-out. Total duration scales linearly with length, so every reply reveals at the same steady rate.
3. easeOut, DEFAULT_STREAM_DURATION_MS, and getRevealDurationMS remain in ConciergeRevealUtils.ts because the server path still uses them.

Open question (follow-up)

Shawn noted the abruptness may partly come from the server sending a complete message mid-reveal, which trips the 1.5s ACCELERATED_REMAINING_MS hard limit (the accelerator compresses the remaining optimistic reveal into 1.5s when the canonical reply lands). That's a separate knob from the cadence and is left unchanged here — worth deciding whether to tune it once the flat cadence is validated.

Slack thread: https://expensify.slack.com/archives/C090U774ZH7/p1784303172343289

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022087097302676205837
• Upwork Job ID: 2087097302676205837
• Last Price Increase: 2026-08-11

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

🤖 Draft PR created: #96508
Please mark it as "Ready for review" when it is ready for review.

[marcochavezf]

Working on it in the PR

[marcochavezf]

PR ready for review #96508

[marcochavezf]

(Marco's agent): @MelvinBot two confirmed defects on
App PR 96508, branch claude-conciergeTrickleSpeed.
I read both at the head commit 81c0b8831954f2912aeb2c487e3b3cbf5e1ca0e7 myself, both hold.

1. Cap the optimistic reveal duration at the hard cap

getOptimisticRevealDurationMS() in src/libs/ConciergeRevealUtils.ts:29-31 is unbounded:

function getOptimisticRevealDurationMS(tokenCount: number): number {
    return Math.max(1, tokenCount - 1) * OPTIMISTIC_FLAT_MS_PER_TOKEN;
}

(tokenCount - 1) * 11 > 60_000 (TRICKLE_HARD_CAP_MS) once tokenCount > 5455, and
tokenizeForReveal.ts emits roughly one token per visible character, so a detailed multi-paragraph
reply can reach that length. In usePendingConciergeResponse.ts:232-233, the running interval
completes on elapsed >= TRICKLE_HARD_CAP_MS even when progress is still below 1, so
completeAndApply() dispatches the fully revealed HTML instead of continuing the timed cadence to
the real end. The jump lands near the 90%+ mark rather than from an early partial state, since
effectiveDuration can't exceed the cap by more than a few seconds for plausible reply lengths, but
it is still a visible snap rather than a smooth finish.

Cap the computed duration at the hard cap in getOptimisticRevealDurationMS() itself:

return Math.min(TRICKLE_HARD_CAP_MS, Math.max(1, tokenCount - 1) * OPTIMISTIC_FLAT_MS_PER_TOKEN);

One line.

2. Restore the mid-trickle acceleration when the canonical action lands

usePendingConciergeResponse.ts used to shorten a running trickle the instant the canonical
REPORT_ACTIONS entry (persistedAction) appeared mid-reveal, compressing effectiveDuration to
elapsed + ACCELERATED_REMAINING_MS (1,500ms). This PR removes that mechanism entirely along with
the accelerateRef it used. I confirmed on the current head that accelerateRef no longer appears
anywhere in the file. persistedAction is now read only inside completeAndApply() at line 189,
which only runs at natural completion (progress >= 1) or the hard cap. So nothing shortens the
loop when the canonical action lands early, and the optimistic trickle keeps ticking through its
full original duration even after the real ReportActionsList-driven reveal for the persisted
action is ready to show server-added follow-up buttons and deep-link markup.

The mechanism this removes is the hook's main synchronization path between the optimistic trickle and
the server write landing, not an edge case, so this is likely to be reachable on a large share of
replies rather than a rare one. I haven't measured how often the race actually resolves that way in
production.

Restore a mid-trickle acceleration path equivalent to the deleted accelerateRef, adapted to the
current getOptimisticRevealDurationMS()-based duration. effectiveDuration is currently declared
const at line 149 and needs to go back to let, and you'll need to restore the
useEffect(() => {...}, [persistedAction]) that called it. Roughly the 45 lines this PR removed from
usePendingConciergeResponse.ts (45 deletions, 5 additions in the commit that took the mechanism
out).

Before you push either fix

This PR is not a draft. It's marked ready for review, and its only assignee is marcochavezf, not
you, even though you're the PR's author. Your own comment history on this PR already shows repeated
successful pushes to claude-conciergeTrickleSpeed, so push access here is most likely settled, but
confirm before pushing rather than assume from a different PR's history. If you can push, push both
fixes as commits on the existing branch. If you find you can't, say so on the PR and stop there.
Don't open a competing PR for these fixes.

[MelvinBot]

Both fixes are pushed to claude-conciergeTrickleSpeed on #96508 (81c0b88 → 9c9d29d). I confirmed push access first: I'm the PR author and marcochavezf is the assignee, so both authorization checks passed.

1. Cap the optimistic reveal duration at the hard cap — getOptimisticRevealDurationMS() now clamps to TRICKLE_HARD_CAP_MS so the running interval can no longer be forced to complete via the elapsed >= TRICKLE_HARD_CAP_MS branch instead of the timed cadence.
src/libs/ConciergeRevealUtils.ts:30 — commit c4ff7b6

2. Restore the mid-trickle acceleration when the canonical action lands — restored the accelerateRef mechanism as the exact inverse of the commit that removed it (692c249, 45 insertions / 5 deletions). effectiveDuration is back to let, and the useEffect(..., [persistedAction]) fires the accelerator so a running trickle compresses to elapsed + ACCELERATED_REMAINING_MS (1,500ms) instead of ticking through its full duration after the server write lands.
src/hooks/usePendingConciergeResponse.ts:62-70 (reconciliation effect), :223-233 (accelerator) — commit 9c9d29d

Checks run locally (all passed)

• npm run fmt — clean, no changes beyond the two touched files
• npm test -- tests/unit/hooks/usePendingConciergeResponse.test.ts — 17/17 passed
• npm run typecheck-tsgo — clean
• npx eslint on both files — clean
• npm run react-compiler-compliance-check check src/hooks/usePendingConciergeResponse.ts — passed (the restored accelerateRef pattern still compiles)