RTK collects anonymous, aggregate usage metrics once per day to help improve the product. Telemetry is disabled by default and requires explicit consent during rtk init or rtk telemetry enable.
Which commands are used most and need the best filters
Which filters are underperforming and need improvement
Which ecosystems to prioritize for new filter development
How much bash output RTK removes before it reaches the model
Whether users stay engaged over time or churn after trying RTK
This data directly drives our roadmap. For example, if telemetry shows that 40% of users run Python commands but only 10% of our filters cover Python, we know where to invest next.
Count unique installations. SHA-256 of a per-device random salt stored locally (~/.local/share/rtk/.device_salt). Not reversible. No hostname or username included.
Top 5 commands with 0% bash output reduction — these need filters
parse_failures_24h
3
Filter fragility — high count means filters are breaking
low_savings_commands
["rtk <cmd>:25%"]
Commands with a weighted bash output reduction <30%, net-negative ones included — filters to improve. The rate is SUM(saved)/SUM(input) over every call of the command, the same figure as the rtk gain By Command table, so high-volume calls are not diluted by passthrough calls. Exact 0% is left to passthrough_top. The example is a placeholder, not a measured value
avg_savings_per_command
68.5
Unweighted average across distinct command names (each filter counts once regardless of invocation volume); each command’s own rate is weighted by volume before the outer average, and commands that never had any input are skipped
A USD value derived from the estimated tokens saved and a fixed internal constant. It is not a measured cost and does not reflect any provider’s pricing
Telemetry requires explicit opt-in consent (GDPR Art. 6, 7). Consent is requested during rtk init or via rtk telemetry enable. Without consent, no data is sent.
Terminal window
rtktelemetrystatus# Check current consent state
rtktelemetryenable# Give consent (interactive prompt)
rtktelemetrydisable# Withdraw consent
rtktelemetryforget# Withdraw consent + delete local data + request server erasure
Environment variable override (blocks telemetry regardless of consent):
Server-side: telemetry records are retained for a maximum of 12 months, then automatically purged.
Server-side (erasure log): IP addresses in the erasure audit log are anonymized after 6 months (GDPR — IP is personal data).
Client-side: the local SQLite database (~/.local/share/rtk/history.db) retains data for 90 days by default (configurable via tracking.history_days in config.toml). Deleted entirely by rtk telemetry forget.
Under the EU General Data Protection Regulation, you have the right to:
Access your data: rtk telemetry status shows your device hash; the telemetry payload is fully documented above.
Rectification: since data is anonymous and aggregate, rectification is not applicable.
Erasure (Art. 17): run rtk telemetry forget to delete local data and send an erasure request to the server. Alternatively, email contact@rtk-ai.app with your device hash.
Restriction of processing: rtk telemetry disable stops all data collection immediately.
Portability: the local SQLite database at ~/.local/share/rtk/history.db contains all locally stored data.
Objection: rtk telemetry disable or export RTK_TELEMETRY_DISABLED=1.
Run rtk telemetry forget — this disables telemetry, deletes your device salt, ping marker, and local tracking database (history.db), then sends an erasure request to the server.
If the server is unreachable, the CLI prints your full device hash and fallback instructions to email contact@rtk-ai.app for manual erasure.
You can also email contact@rtk-ai.app directly to request manual erasure.