Entry points (no sixth tab): Ask in the Library header (desktop button, phone icon), Ask about this deck in the deck menu, Ask a question on study/homework results (compact result travels as context), and a Chat row in the desktop sidebar. Phones get a full-screen route with back + New chat; the tab bar steps aside. - Client-side retrieval: chunk scoped decks (~800 tokens), BM25 against the question + recent turns, top chunks under ~7k tokens, each labelled with deck + section. Notes come from the deck's stored sourceText (already kept for Regenerate); decks without it fall back to generated content and the UI says so. - Stateless server: /api/chat validates against the CHAT_MODELS allowlist, trims the history to ~6k tokens, caps context at ~9k and streams token/thinking/done/error NDJSON. /api/chat/extract reduces attachments to text through the existing vision step. - UI: user bubbles + full-width assistant text, streaming with stop, auto-scroll that pauses with a jump-to-bottom button, safe markdown (React nodes, no HTML injection; KaTeX dynamically imported only when a message has math), Thinking row for reasoning, copy/regenerate/ edit-and-resend, model + context pickers (last model remembered), composer with visualViewport keyboard handling, safe-area, 16px textarea, Enter-to-send on desktop. - Usage-limit failures keep the draft and show the shared message with Settings/Ollama actions; stopping maps the reader abort to a clean stopped state; offline disables sending with a reason. - Settings: Keep notes text for chat toggle; deck menu: Delete notes text. RATE_LIMIT_CHAT + CHAT_MODELS in .env.example and README. - Tests: chat suite (63 checks, stub Ollama) wired into run-all. Full set: 12/12 suites, 487 checks. SW -> freezmo-v32. Also: tests/model-compare.mjs (diagnostic) benchmarks two models on the same notes (latency, repair rounds, activity types) so the gpt-oss vs gemma default can be decided on numbers; defaults unchanged.
30 lines
1 KiB
TypeScript
30 lines
1 KiB
TypeScript
/**
|
|
* Pure helpers shared by the chat route (server) and the chat UI (client):
|
|
* token budgeting and the sliding history window. No directive, no deps, so
|
|
* both sides can import it.
|
|
*/
|
|
|
|
/** Rough token estimate (≈4 chars per token) — good enough for budgeting. */
|
|
export function estimateTokens(text: string): number {
|
|
return Math.ceil(text.length / 4);
|
|
}
|
|
|
|
/** How much conversation history the sliding window keeps (≈6k tokens). */
|
|
export const HISTORY_TOKEN_BUDGET = 6000;
|
|
|
|
/** Keeps the most recent turns that fit the budget (sliding window). */
|
|
export function trimHistory<T extends { role: "user" | "assistant"; content: string }>(
|
|
messages: T[],
|
|
budget = HISTORY_TOKEN_BUDGET,
|
|
): T[] {
|
|
const kept: T[] = [];
|
|
let used = 0;
|
|
for (let index = messages.length - 1; index >= 0; index -= 1) {
|
|
const message = messages[index];
|
|
const cost = estimateTokens(message.content);
|
|
if (kept.length > 0 && used + cost > budget) break;
|
|
kept.unshift(message);
|
|
used += cost;
|
|
}
|
|
return kept;
|
|
}
|