Documentation Index
Fetch the complete documentation index at: https://docs.monolex.ai/llms.txt
Use this file to discover all available pages before exploring further.
Two Scenarios: Vim vs LLM Streaming
Terminal emulators face two fundamentally different usage patterns.The Two Usage Patterns
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā SCENARIO 1: VIM / INTERACTIVE EDITING ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¤
ā ā
ā Input: Frequent, continuous keystrokes ā
ā Output: Small, incremental (one char, one line) ā
ā Critical Metric: INPUT LATENCY ā
ā User Expectation: Instant response to keystrokes ā
ā ā
ā āāāāāāāāāāāāāāāāāāāāāāā ā
ā ā Game Analogy: ā ā
ā ā ā ā
ā ā COMPETITIVE FPS ā (CS2, Valorant) ā
ā ā ā ā
ā ā Every millisecond ā ā
ā ā of input lag ā ā
ā ā matters ā ā
ā āāāāāāāāāāāāāāāāāāāāāāā ā
ā ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā SCENARIO 2: LLM STREAMING / HIGH OUTPUT ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¤
ā ā
ā Input: Rare (user is watching, not typing) ā
ā Output: Massive, continuous (thousands of lines/sec) ā
ā Critical Metric: VISUAL STABILITY ā
ā User Expectation: Smooth, readable streaming text ā
ā ā
ā āāāāāāāāāāāāāāāāāāāāāāā ā
ā ā Game Analogy: ā ā
ā ā ā ā
ā ā 4K VIDEO STREAMING ā (Netflix, YouTube) ā
ā ā ā ā
ā ā Input latency ā ā
ā ā is irrelevant ā ā
ā ā Buffering prevents ā ā
ā ā stuttering ā ā
ā āāāāāāāāāāāāāāāāāāāāāāā ā
ā ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
Traditional Terminals: One Optimization Only
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā TRADITIONAL TERMINAL IN VIM SCENARIO ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¤
ā ā
ā Keystroke --> Parse --> Render --> Display ā
ā ā ā
ā v ā
ā ~13-31ms latency (optimized!) ā
ā ā
ā Output volume: Low (matches render capacity) ā
ā Reflow frequency: Low (no accumulation) ā
ā ā
ā Result: PERFECT ā
ā ā
ā Like: FPS-optimized hardware playing FPS game ā
ā ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā TRADITIONAL TERMINAL IN LLM SCENARIO ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¤
ā ā
ā LLM chunk --> Parse --> Render (immediately!) ā
ā LLM chunk --> Parse --> Render (immediately!) ā
ā LLM chunk --> Parse --> Render (immediately!) ā
ā ...4000 times per second... ā
ā ā
ā Output volume: Massive (exceeds render capacity) ā
ā Reflow frequency: 4000-6700/sec (unsustainable) ā
ā ā
ā Result: CATASTROPHIC FAILURE ā
ā ā
ā Like: Playing 4K video without buffering ā
ā Using FPS reflexes to watch Netflix ā
ā ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
MonoTerm: Adaptive to Both
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā MONOTERM IN VIM SCENARIO ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¤
ā ā
ā Keystroke --> Rust Parse --> Grid Update --> ACK --> Render ā
ā ā ā
ā v ā
ā ~50ms latency (acceptable for editing) ā
ā ā
ā Output volume: Low ā
ā ACK cycle: Fast (low output = quick turnaround) ā
ā ā
ā Result: GOOD ENOUGH ā
ā ā
ā Like: Adaptive sync monitor ā
ā Not the absolute fastest, but smooth ā
ā ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā MONOTERM IN LLM SCENARIO ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¤
ā ā
ā [Rust Backend - No Reflow Zone] ā
ā ā
ā LLM chunk --> Grid Update (memory only) ā
ā LLM chunk --> Grid Update (memory only) ā
ā LLM chunk --> Grid Update (memory only) ā
ā ...100 times... (DOM never touched) ā
ā ā
ā [Frontend - ACK Gated] ā
ā ā
ā "Ready?" <āā ACK <āā Snapshot received --> Single render ā
ā ā
ā Output volume: Massive (absorbed by backend) ā
ā Reflow frequency: 5-10/sec (sustainable) ā
ā ā
ā Result: OPTIMAL ā
ā ā
ā Like: Buffered 4K streaming ā
ā Smooth playback regardless of source bitrate ā
ā ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
Comparison Matrix
| Scenario | Game Analogy | Traditional | MonoTerm |
|---|---|---|---|
| Vim | Competitive FPS | Optimal (~13-31ms) | Good (~50ms) |
| LLM Streaming | 4K Video | Crash (no buffer) | Optimal (ACK buffer) |
Why Reflow is Different from Frame Drop
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā FRAME DROP (Game) - Cheap ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¤
ā ā
ā Frame 1 --> Render --> Display ā
ā Frame 2 --> [GPU busy] --> SKIP (free) ā
ā Frame 3 --> Render --> Display ā
ā ā
ā Cost of skip: ~0 (just don't render) ā
ā Result: Momentary stutter, recovers instantly ā
ā ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā REFLOW (Terminal) - Expensive ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¤
ā ā
ā Chunk 1 --> DOM update --> REFLOW (16ms, blocking) ā
ā Chunk 2 --> DOM update --> queued (waiting) ā
ā Chunk 3 --> DOM update --> queued (waiting) ā
ā Chunk 4 --> DOM update --> queued (waiting) ā
ā ā ā
ā v ā
ā CANNOT SKIP! ā
ā ā ā
ā v ā
ā REFLOW 1 (16ms) --> blocking ā
ā REFLOW 2 (16ms) --> blocking ā
ā REFLOW 3 (16ms) --> blocking ā
ā REFLOW 4 (16ms) --> blocking ā
ā ā
ā Cost: Cumulative debt that must be paid ā
ā Result: Progressive slowdown --> freeze --> crash ā
ā ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
Better Analogy: Shader Compilation
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā NORMAL GAME ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¤
ā ā
ā Shaders compiled at load time ā
ā Gameplay: Just render with pre-compiled shaders ā
ā ā
ā Result: Smooth 60fps ā
ā ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā REFLOW STORM = COMPILING SHADERS EVERY FRAME ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¤
ā ā
ā Frame 1 --> Compile shader --> 50ms freeze --> Render ā
ā Frame 2 --> Compile shader --> 50ms freeze --> Render ā
ā Frame 3 --> Compile shader --> 50ms freeze --> Render ā
ā ā
ā Effective FPS: ~15 (unplayable) ā
ā Input during compile: Ignored ā
ā ā
ā This is what LLM streaming does to traditional terminals. ā
ā ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
MonoTerm Solution: Off-Thread Processing
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā GAME PATTERN MONOTERM PATTERN ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¤
ā ā
ā Shader compilation stutter Parsing (expensive) ā
ā --> Pre-compile at load --> Rust backend (no DOM) ā
ā ā
ā GC spikes Grid updates ā
ā --> Object pooling --> Memory only (no reflow) ā
ā ā
ā Asset loading hitches DOM updates ā
ā --> Stream in background --> Only on ACK (controlled) ā
ā ā
ā Pattern: Do expensive work Pattern: Do expensive work ā
ā OUTSIDE gameplay OUTSIDE the UI thread ā
ā ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
Key Insight
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā THE AI ERA SHIFT ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¤
ā ā
ā The AI era introduced a new terminal usage pattern: ā
ā ā
ā HIGH OUTPUT, LOW INPUT ā
ā ā
ā Traditional terminals only optimize for: ā
ā ā
ā LOW OUTPUT, HIGH INPUT (Vim, shell) ā
ā ā
ā MonoTerm handles both: ā
ā ā
ā Interactive editing --> ACK cycles quickly ā
ā LLM streaming --> ACK absorbs the flood ā
ā ā
ā One architecture. Two optimal modes. Zero crashes. ā
ā ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
Related Research
- Terminal Analysis - Architecture comparison
- Architecture Diagrams - Flow visualizations
- Success Factors - Why the architecture works