Skip to main content

Overview

RTK’s tracking system records every command execution in a local SQLite database, providing comprehensive analytics on token savings, execution times, and usage patterns. The system:
  • Stores command history in SQLite (~/.local/share/rtk/tracking.db)
  • Tracks input/output tokens, savings percentage, and execution time
  • Automatically cleans up records older than 90 days
  • Provides aggregation APIs (daily/weekly/monthly)
  • Exports to JSON/CSV for external integrations
  • Supports project-scoped tracking for multi-project workflows
For CLI usage, see rtk gain Command. This page covers the underlying architecture and programmatic API.

Architecture

Data Flow

Storage Locations

Default paths:
  • Linux: ~/.local/share/rtk/tracking.db
  • macOS: ~/Library/Application Support/rtk/tracking.db
  • Windows: %APPDATA%\rtk\tracking.db
Custom database path (priority order):
  1. RTK_DB_PATH environment variable
  2. tracking.database_path in ~/.config/rtk/config.toml
  3. Default platform-specific location

Data Retention

Records older than 90 days are automatically deleted on each write operation to prevent unbounded database growth.

Database Schema

Table: commands

Migration support: The system automatically adds new columns if they don’t exist (e.g., exec_time_ms, project_path were added later).

Table: parse_failures

Public API

Core Types

Tracker

Main tracking interface for recording and querying command history.

GainSummary

Aggregated statistics across all recorded commands.

DayStats, WeekStats, MonthStats

Temporal statistics (Serializable for JSON export).

TimedExecution

Helper for timing command execution (preferred API).

Utility Functions

Usage Examples

Basic Tracking

Querying Statistics

Project-Scoped Tracking

Passthrough Commands

For commands that stream output or run interactively (no output capture):

Custom Database Path

Environment Variable

Config File

Programmatic

Integration Examples

GitHub Actions - Track Savings in CI

Custom Dashboard Script

Rust Integration (Using RTK as Library)

Performance Considerations

  • SQLite WAL mode: Not enabled (may add in future for concurrent writes)
  • Index on timestamp: Enables fast date-range queries
  • Index on project_path: Enables fast project-scoped queries
  • Automatic cleanup: Prevents database from growing unbounded (90-day retention)
  • Token estimation: ~4 chars = 1 token (simple, fast approximation)
  • Aggregation queries: Use SQL GROUP BY for efficient aggregation

Security & Privacy

  • Local storage only: Database never leaves the machine
  • No telemetry: RTK does not phone home or send analytics
  • User control: Users can delete ~/.local/share/rtk/tracking.db anytime
  • 90-day retention: Old data automatically purged
  • Project paths: Stored as canonical absolute paths (e.g., /Users/foo/project)

Troubleshooting

Database locked error

If you see “database is locked” errors:
  • Ensure only one RTK process writes at a time
  • Check file permissions on ~/.local/share/rtk/tracking.db
  • Delete and recreate: rm ~/.local/share/rtk/tracking.db && rtk gain

Missing exec_time_ms column

Older databases may not have the exec_time_ms column. RTK automatically migrates on first use, but you can force it:

Incorrect token counts

Token estimation uses ~4 chars = 1 token. This is approximate. For precise counts, integrate with your LLM’s tokenizer API:

Future Enhancements

Planned improvements (contributions welcome):
  • Export to Prometheus/OpenMetrics format
  • Support for custom retention periods (not just 90 days)
  • SQLite WAL mode for concurrent writes
  • Per-project tracking with multiple databases
  • Integration with Claude API for precise token counts
  • Web dashboard (localhost) for visualizing trends

See Also

rtk gain Command

CLI interface for viewing token savings analytics

rtk discover Command

Find missed savings opportunities in Claude Code session history