Overview
screenpipe is designed to run 24/7 in the background with minimal system impact. This guide covers performance characteristics and optimization strategies.
Target performance: 5-10% CPU, 0.5-3 GB RAM, ~20 GB storage/month on modern hardware.
CPU Usage
Expected Usage
| Scenario | CPU Usage (Release Build) | Notes |
|---|
| Static screen | < 1% | Idle detection active |
| Light browsing | 5-10% | Event-driven capture |
| Active work | 8-15% | OCR and video encoding |
| Video calls | 10-20% | Audio transcription active |
| 3 monitors | 10-20% | Multi-monitor optimization |
| Debug build | 3-5× higher | Always use release builds |
Debug builds have significantly higher CPU usage (3-5×). Always run production builds:
Event-Driven Capture
screenpipe uses event-driven capture instead of continuous recording:
Traditional approach (wasteful):
Every 2 seconds:
1. Capture screenshot
2. Run OCR on entire screen
3. Encode to video
4. Write to database
Result: Constant CPU usage even on static screens
screenpipe approach (efficient):
On meaningful events:
- App switch
- Mouse click
- Keyboard input
- Window change
- Scroll
- Clipboard change
Idle screen:
- Hash comparison detects no changes
- Skip capture entirely
- Near-zero CPU usage
Result: CPU scales with actual activity
CPU Optimization Tips
1. Enable Idle Detection
performance:
idle_detection: true
idle_threshold: 30 # seconds of inactivity
When no events detected for 30 seconds, capture rate drops dramatically.
2. Adjust Capture Quality
capture:
quality: "balanced" # "high" | "balanced" | "light"
| Quality | OCR Workers | Capture Rate | CPU Impact |
|---|
| high | 4 | Every event | High (15-20%) |
| balanced | 2 | Most events | Medium (5-10%) |
| light | 1 | Reduced | Low (2-5%) |
3. Multi-Monitor Optimization
For 3+ monitors, use adaptive capture:
monitors:
active_priority: true # Focus on active monitor
idle_reduce_rate: 0.3 # Reduce idle monitor capture by 70%
CPU scaling:
- 1 monitor: ~5-10% CPU
- 3 monitors (equal): ~30% CPU
- 3 monitors (adaptive): ~10-15% CPU
4. OCR Backend Selection
macOS:
- Apple Vision (default): Fast, accurate, low CPU
- Tesseract: Slower, higher CPU, but works offline
Windows:
- Windows.Media.Ocr (default): Fast, native
- Tesseract: Slower, higher CPU
Linux:
- Tesseract (only option): Configure for performance
ocr:
backend: "apple-vision" # macOS only
# backend: "windows-media-ocr" # Windows only
# backend: "tesseract" # Cross-platform
5. Audio Transcription Mode
Audio transcription (Whisper) is CPU-intensive:
audio:
transcription_mode: "batch" # "realtime" | "batch"
batch_cpu_threshold: 70 # Pause if CPU > 70%
Realtime mode:
- Transcribes every 21-30 seconds
- ~27-29% CPU on Metal (macOS)
- Competes with video calls for GPU
Batch mode (recommended):
- Accumulates audio while you work
- Transcribes during idle periods
- CPU < threshold for 30+ seconds before starting
- ~5-10% average CPU impact
Batch mode is ideal for laptop users. Transcription happens during breaks, preserving battery during active work.
6. Battery Saver Mode
On laptops, enable battery optimization:
power:
battery_mode: "auto" # "auto" | "always" | "never"
battery_threshold: 20 # % battery to trigger
When on battery:
- Reduce capture rate by 50%
- Switch to “light” quality
- Disable realtime transcription
- Skip inactive monitors
CPU drops to ~2-3% in battery mode.
Memory Usage
Expected Usage
| Component | Memory Usage | Notes |
|---|
| Base app | 200-400 MB | UI and runtime |
| Video encoder | 100-200 MB | Per monitor |
| OCR worker | 50-100 MB | Per worker |
| Whisper model | 1-2 GB | Large v3 Turbo |
| Database cache | 50-100 MB | SQLite page cache |
| Total (typical) | 0.5-3 GB | Depends on config |
Memory Optimization
1. Reduce OCR Workers
ocr:
worker_count: 2 # Default: 4
Each worker uses ~50-100 MB. Reduce for low-memory systems.
2. Database Page Cache
database:
page_cache_mb: 50 # Default: 100
Lower cache size reduces memory but may slow queries.
3. Whisper Model Size
audio:
whisper_model: "base" # "large-v3" | "medium" | "base" | "tiny"
| Model | Memory | Accuracy | Speed |
|---|
| large-v3 | 1.6 GB | Excellent | Slow |
| medium | 800 MB | Good | Medium |
| base | 300 MB | Fair | Fast |
| tiny | 150 MB | Poor | Very fast |
4. Video Chunk Size
video:
chunk_duration_minutes: 5 # Default: 10
Smaller chunks reduce memory during encoding but create more files.
Storage Usage
Expected Usage
Event-driven capture (default):
- Text data: ~1-5 KB per frame
- Screenshots: ~50-200 KB per frame (JPEG)
- Video chunks: ~5-50 MB per chunk (5-10 minutes)
- Total: ~5-10 GB per month
Continuous capture (legacy):
- ~40-60 GB per month per monitor
- Not recommended
Storage Breakdown
~/.screenpipe/
├── db.sqlite # 100-500 MB (text, metadata)
├── frames/ # 2-5 GB/month (screenshots)
└── videos/ # 3-5 GB/month (video chunks)
Storage Optimization
1. Retention Policy
Automatically delete old data:
retention:
max_age_days: 90 # Delete after 90 days
max_size_gb: 100 # Delete oldest when exceeding 100 GB
2. JPEG Quality
capture:
jpeg_quality: 75 # Default: 85 (1-100)
Lower quality reduces file size:
- 85: ~150 KB per frame (high quality)
- 75: ~80 KB per frame (medium quality)
- 60: ~50 KB per frame (low quality, visible artifacts)
3. Video Codec Settings
video:
codec: "h264" # "h264" | "h265" | "vp9"
crf: 28 # Constant Rate Factor (18-32, higher = smaller)
| CRF | Quality | Size |
|---|
| 18 | Very high | ~10 MB/min |
| 23 | High (default) | ~5 MB/min |
| 28 | Medium | ~2 MB/min |
| 32 | Low | ~1 MB/min |
4. Disable Video Timeline
If you only need search (not timeline scrubbing):
video:
enabled: false # Only store screenshots, no video chunks
Saves ~50-70% storage (no video files).
5. Monitor-Specific Settings
monitors:
- name: "Primary"
capture: true
video: true
- name: "Secondary"
capture: true
video: false # Screenshots only, no video
- name: "Third"
capture: false # Skip entirely
6. Vacuum Database
SQLite can become fragmented over time:
# Reclaim space from deleted data
screenpipe db vacuum
# Or manually:
sqlite3 ~/.screenpipe/db.sqlite "VACUUM;"
Can recover 20-50% space after deletions.
Network Usage
Local-Only Mode (Default)
Network usage: Near-zero
- No account, no cloud, no sync
- Only update checks (can be disabled)
- ~1 KB/day
Cloud Sync Enabled
Text-only sync:
- ~1-5 KB per frame
- ~10-50 MB/day depending on activity
- Minimal bandwidth impact
Full sync (with video):
- ~5-50 MB per video chunk
- ~500 MB - 5 GB/day
- Requires fast, unmetered connection
Cloud AI Providers
OpenAI/Anthropic (search, summaries):
- ~1-10 KB per query
- Negligible unless doing hundreds of queries/day
Deepgram (audio transcription):
- Upload audio chunks for transcription
- ~5-20 MB/hour of audio
- Alternative: Use local Whisper (no network)
Optimization
sync:
enabled: true
mode: "text-only" # Don't sync video chunks
wifi_only: true # Pause on mobile/metered networks
bandwidth_limit_kbps: 500 # Throttle uploads
Disk I/O
screenpipe uses SQLite with Write-Ahead Logging (WAL):
PRAGMA journal_mode = WAL;
PRAGMA synchronous = NORMAL;
PRAGMA cache_size = -100000; -- 100 MB cache
Benefits:
- Concurrent reads and writes
- Reduced disk writes
- Better crash recovery
I/O Optimization
1. Use SSD
screenpipe is designed for SSDs:
- Random access for search queries
- Continuous writes for capture
- HDD will be slow and cause lag
2. Move Storage
If main drive is full, move to secondary drive:
# Stop screenpipe
screenpipe stop
# Move data
mv ~/.screenpipe /Volumes/External/screenpipe
# Create symlink
ln -s /Volumes/External/screenpipe ~/.screenpipe
# Restart
screenpipe start
3. Batch Writes
database:
batch_size: 100 # Insert N frames before committing
commit_interval_ms: 5000 # Or commit every 5 seconds
Reduces disk writes by batching transactions.
Built-in Metrics
View performance stats:
# Real-time stats
screenpipe stats
# Example output:
CPU: 8.2%
Memory: 1.2 GB
Disk: 45 GB (18 days)
Capture rate: 3.2 frames/min (idle)
OCR queue: 0
Transcription: batch mode (waiting)
System Monitoring
macOS:
# Activity Monitor
open -a "Activity Monitor"
# CLI
top -pid $(pgrep screenpipe)
Windows:
# Task Manager (Ctrl+Shift+Esc)
# Or PowerShell:
Get-Process screenpipe | Select-Object CPU,WS
Linux:
# htop
htop -p $(pgrep screenpipe)
# Or top
top -p $(pgrep screenpipe)
Logging
Enable performance logging:
logging:
level: "debug"
performance_metrics: true
Logs CPU/memory/disk metrics every minute to:
- macOS/Linux:
~/.screenpipe/logs/perf.log
- Windows:
%APPDATA%\screenpipe\logs\perf.log
Troubleshooting
High CPU Usage
Symptoms: CPU > 20% sustained
Causes:
- Debug build (3-5× slower)
- Realtime transcription during video calls
- 3+ monitors without adaptive capture
- OCR workers set too high
- Static screen not detected (hash comparison disabled)
Solutions:
# Check build type
screenpipe --version
# Should say "release", not "debug"
# Switch to batch transcription
screenpipe config --transcription-mode batch
# Enable idle detection
screenpipe config --idle-detection true
# Reduce OCR workers
screenpipe config --ocr-workers 2
# Enable adaptive multi-monitor
screenpipe config --active-monitor-priority true
High Memory Usage
Symptoms: Memory > 4 GB
Causes:
- Whisper Large v3 model loaded
- Too many OCR workers
- Large database cache
- Memory leak (rare)
Solutions:
# Use smaller Whisper model
screenpipe config --whisper-model base
# Reduce OCR workers
screenpipe config --ocr-workers 2
# Reduce database cache
screenpipe config --db-cache-mb 50
# Restart (clears memory)
screenpipe restart
Slow Search Queries
Symptoms: Search takes > 2 seconds
Causes:
- Large database (> 10 GB) without vacuum
- No FTS5 index
- Database on HDD
- Database locked by writes
Solutions:
# Vacuum database
screenpipe db vacuum
# Rebuild FTS5 index
screenpipe db reindex
# Optimize for read performance
screenpipe config --optimize-for-read true
# Move to SSD (see "Move Storage" above)
App Feels Sluggish
Symptoms: UI lag, slow frame scrubbing
Causes:
- Database on slow drive
- Too many monitors
- Video decoding on CPU (no GPU acceleration)
Solutions:
# Enable hardware video decoding
screenpipe config --hw-decode true
# Reduce timeline cache
screenpipe config --timeline-cache-frames 100
# Move database to faster drive
Benchmarks
Test System
Specs:
- CPU: Apple M1 Max / Intel i7-12700K / AMD Ryzen 9 5900X
- RAM: 32 GB
- Storage: NVMe SSD
- Monitors: 1× 4K + 1× 1080p
Configuration:
quality: "balanced"
idle_detection: true
transcription_mode: "batch"
Results (8-hour workday)
| Metric | Apple Silicon | Intel x86 | AMD x86 |
|---|
| Average CPU | 5.2% | 8.1% | 7.8% |
| Peak CPU | 14.3% | 22.7% | 19.4% |
| Memory | 1.1 GB | 1.4 GB | 1.3 GB |
| Storage | 2.1 GB | 2.3 GB | 2.2 GB |
| Frames captured | 1,247 | 1,198 | 1,224 |
| Battery impact | 4.2%/hr | 6.1%/hr | N/A |
Activity:
- 2 hours: VS Code (coding)
- 1 hour: Chrome (browsing)
- 2 hours: Zoom (video call)
- 1 hour: Slack (messaging)
- 2 hours: Idle (static screen)
Multi-Monitor Scaling
| Monitors | CPU (Adaptive) | CPU (Equal) | Storage |
|---|
| 1 | 5.2% | 5.2% | 2.1 GB/day |
| 2 | 8.1% | 11.3% | 3.8 GB/day |
| 3 | 10.7% | 18.9% | 5.2 GB/day |
| 4 | 13.2% | 26.4% | 6.9 GB/day |
Adaptive mode reduces inactive monitor capture rate.
Best Practices
Recommended configuration for most users:performance:
quality: "balanced"
idle_detection: true
battery_mode: "auto"
ocr:
backend: "apple-vision" # macOS
worker_count: 2
audio:
transcription_mode: "batch"
whisper_model: "base"
batch_cpu_threshold: 70
video:
codec: "h264"
crf: 28
chunk_duration_minutes: 10
capture:
jpeg_quality: 75
retention:
max_age_days: 90
max_size_gb: 100
monitors:
active_priority: true
idle_reduce_rate: 0.3
Expected result: 5-8% CPU, ~1.5 GB RAM, ~5 GB/month storage