Skip to main content
This document provides a comprehensive overview of RTK’s architecture, including the proxy pattern, module organization, and filtering strategies.

System Overview

Proxy Pattern Architecture

RTK uses a command proxy architecture that sits between the user and underlying CLI tools:

Key Components

Design Principles

  1. Single Responsibility: Each module handles one command type
  2. Minimal Overhead: ~5-15ms proxy overhead per command
  3. Exit Code Preservation: CI/CD reliability through proper exit code propagation
  4. Fail-Safe: If filtering fails, fall back to original output
  5. Transparent: Users can always see raw output with -v flags

Command Lifecycle

Six-Phase Execution Flow

1

PARSE

Clap parser extracts command, arguments, and global flags:
2

ROUTE

Main.rs matches the command enum and routes to the appropriate module:
3

EXECUTE

Module executes the underlying command and captures output:
4

FILTER

Module applies filtering strategy based on command type:
5

PRINT

Filtered output is displayed to the user:
6

TRACK

Token savings are recorded in SQLite database:

Verbosity Levels

Module Organization

Module Categories

RTK has 51 total modules organized into categories:

Command Module Pattern

Each command module follows a standard pattern:

Filtering Strategies

Strategy Matrix

RTK uses 12 different filtering strategies optimized for different output types:

1. Stats Extraction (90-99% reduction)

Used by: git status, git log, git diff, pnpm list

2. Error Only (60-80% reduction)

Used by: runner (err mode), test failures

3. Grouping by Pattern (80-90% reduction)

Used by: lint, tsc, grep (group by file/rule/error code)

4. Deduplication (70-85% reduction)

Used by: log_cmd (identify patterns, count occurrences)

5. Structure Only (80-95% reduction)

Used by: json_cmd (schema extraction)

6. Code Filtering (20-90% reduction)

Used by: read, smart (language-aware stripping via filter.rs)

7. Failure Focus (94-99% reduction)

Used by: vitest, playwright, runner (test mode)

8-12. Additional Strategies

  • Tree Compression (ls): Flat list → hierarchy (50-70%)
  • Progress Filtering (wget, pnpm): Strip ANSI bars (85-95%)
  • JSON/Text Dual Mode (ruff, pip): JSON when available (80%+)
  • State Machine Parsing (pytest): Track test state (90%+)
  • NDJSON Streaming (go test): Line-by-line JSON (90%+)
See ARCHITECTURE.md lines 308-413 for detailed filtering strategy descriptions with visual diagrams.

Core Design Patterns

1. Package Manager Detection (JS/TS modules)

Why this matters:
  • Preserves CWD correctly
  • Works in monorepo structures
  • Uses project-local dependencies
  • Consistent CI/CD behavior

2. Lazy Static Regex

Performance: Avoids regex recompilation overhead (~5-10ms per call)

3. Exit Code Preservation

Critical for: CI/CD pipelines, pre-commit hooks, git workflows

Token Tracking System

RTK tracks token savings in a SQLite database:

Token Estimation

Automatic Cleanup

Retention: 90 days (configurable via HISTORY_DAYS constant)

Configuration System

Two-Tier Configuration

  1. User Settings (~/.config/rtk/config.toml)
  2. LLM Integration (CLAUDE.md)
    • Global: ~/.config/rtk/CLAUDE.md
    • Local: ./CLAUDE.md (project-specific)
    • Created by: rtk init [--global]
Configuration is loaded on-demand to maintain <10ms startup time. No file I/O during command execution.

Performance Characteristics

Targets

Optimizations

  • Zero async overhead: Single-threaded, no tokio
  • Lazy regex compilation: Compile once, reuse forever
  • Minimal allocations: Borrow over clone
  • No startup I/O: Config loaded on-demand
  • LTO + strip: Link-time optimization + symbol stripping

Error Handling

RTK uses anyhow::Result<()> for error propagation:
Rules:
  • Always use .context("description") with ?
  • Never use .unwrap() in production code
  • Graceful degradation: If filter fails, fallback to raw command
  • Preserve exit codes for CI/CD reliability

Next Steps