emileriksenkeev makes sydOS feel faster where lawyers notice it

The fork focuses on perceived speed, cutting delays in document work and chat without chasing backend problems that were not there.

workflowinfrastructure

A measured review found the service itself was already responding quickly. The drag came from the interface: slow rendering, repeated requests for basic counts, and a chat display that released answers at a fixed, sluggish pace.

Chat answers now appear at an adaptive rate, so a long response can read as complete in roughly two seconds instead of eight.
Project and entity totals are collected in batches, avoiding repeated lookups as users browse.
Documents can appear once the matter is loaded, without waiting for chat and review data.
Background knowledge-building work uses a lower reasoning setting by default, while spreadsheet support loads only when needed.

The compression and sign-in improvements are sensible polish, but the real lesson is the diagnosis: test where the delay lives before spending time fixing it.

So what Teams using AI for document-heavy matters should care because waiting for the interface feels like waiting for the legal work itself.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

2 commits from emileriksenkeev/sydOS, oldest first. Source extracted verbatim from the harvested git log.

SHA	Subject	Author	Date
`20c75bf2`	perf: safe quick wins - gzip, cached auth token, batched counts, faster doc paint	emileriksenkeev	2026-07-14	↗ GitHub
commit body - backend: add compression middleware (excludes SSE) for smaller JSON over the SG tunnel - backend: replace GET /projects and /projects/entities N+1 count loops with grouped project_counts()/entity_counts() RPCs (one round-trip) - frontend: cache the Supabase access token via onAuthStateChange so getAuthHeader no longer awaits getSession() before every request (incl. the chat POST) - frontend: ProjectPage paints Documents as soon as getProject resolves; chats/ reviews load in the background instead of blocking the spinner Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
`899eac7e`	perf(feel): adaptive chat drip, low-effort wiki thinking, lazy ExcelJS	emileriksenkeev	2026-07-14	↗ GitHub
commit body Measured investigation found the backend near-idle (~2ms local TTFB); the slow FEEL came from the frontend, not compute. - useAssistantChat: replace the fixed 8 chars/tick (~500 c/s) drip ceiling with an adaptive drain (max(8, ceil(gap/12))) so a fast stream catches up within a few hundred ms. A ~4000-char answer now finishes painting in ~2s, not ~8s. - Thread thinkingEffort through StreamChatParams/runLLMStream; default stays 'high' for interactive chat, wiki builder now runs 'low' - no user watches the background thought stream across its up-to-40 tool iterations. - exportToExcel: lazy import('exceljs') inside the export handler instead of a static top-level import, removing the ~270KB chunk from the tabular route's initial bundle. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-918.md from inside the repo you want the changes in.

⬇ Download capture-thread-918.md