# CLI Data & Telemetry The Swytchcode CLI is designed to be production-ready while respecting developer workflows and privacy. In addition to executing tools and managing integrations, the CLI can optionally collect anonymous telemetry, synchronize execution history across devices, and measure API usage for billing. These features are independent of tool execution and can be configured based on your environment. --- ## Telemetry Swytchcode can optionally report anonymous command-outcome events to help improve the reliability and performance of the CLI. Telemetry is designed to be lightweight and never affects the execution of your commands. Information that may be collected includes: - The CLI command that was executed - Whether the command succeeded or failed - Execution duration - CLI version - Platform information Telemetry does **not** change how your application behaves and is never required for normal CLI operation. --- ### When is telemetry sent? Telemetry is only sent when the CLI can associate events with an authenticated account. This includes: - Users logged in with `swy login` - CI environments using `SWYTCHCODE_TOKEN` If you are not authenticated, telemetry events are not sent. --- ### Non-blocking by design Telemetry is completely asynchronous. Command execution never waits for telemetry to complete. If telemetry cannot be delivered - for example because you're offline or the telemetry service is unavailable - your command continues normally. Telemetry failures never affect: - command output - exit codes - tool execution - API requests --- ### Disabling telemetry Telemetry, product analytics, and crash-report consent are controlled by a single switch: `telemetry_enabled`. ```bash swy config telemetry disable ``` Check the current state at any time: ```bash swy config telemetry status ``` You can also read or set the underlying key directly: ```bash swy config get telemetry_enabled swy config set telemetry_enabled false ``` Once disabled, no telemetry, analytics, or crash-report events are sent - there is no separate opt-in for any of them. --- ## Turning off background checks Besides your commands, the CLI makes two small background checks, each at most once a day: - **Update check:** asks whether a newer CLI version is available, so it can tell you. - **Plan check:** reads your plan and this month's usage, so it can tell you when you're close to your limit. If you've reached the limit, the CLI checks again after 10 minutes before blocking, so an upgrade takes effect quickly. Neither one sends anything about your commands. To turn off telemetry, analytics and the update check together, for example on a locked-down network, set: ```bash export SWYTCHCODE_NO_TELEMETRY=1 ``` Your commands keep working as normal. Usage reporting for billing still runs (see [Usage Metering](#usage-metering)). --- ## Local Execution History Regardless of whether telemetry or cloud sync is enabled, Swytchcode keeps a record of every command you run on your own machine under `~/.swytchcode/audit/`: outbound network calls, policy-violation entries, and execution stats. Use it to see what ran, what it called, and whether it worked. Each day's history is kept for 90 days, then deleted automatically. ```bash swy audit # choose what to view swy audit stats # total runs, success rate, last run, top provider swy audit network [-n N] # recent outbound network calls swy audit policy [-n N] # commands blocked or held by your policies swy audit clear # delete all local audit files ``` - The record is stored locally and is only readable by you. Sensitive values in requests and responses are redacted. - You don't need to sign in to see it. - When a command fails, the CLI also adds a one-line note (time, tool and CLI version, never arguments) to `.swytchcode/logs/error.log` in your project. It keeps the most recent entries only. - To manage your policy rules, use `swy policy`. That's separate from the audit history. Every network call and policy-violation entry gets a unique id (`nw_...` / `pol_...`) - pass it to `swy audit network --info ` or `swy audit policy --info ` for full detail. See the [Command Reference](/reference/commands/#system) for the complete `swy audit` surface. --- ## Cloud Sync Cloud Sync is an optional backup of your local audit history to your Swytchcode account, so your team can view it in one place. It's off by default. Once enabled, history is uploaded automatically once a day in the background. It never slows down or interrupts your commands. Only a summary of each command is synced - which method ran, when, whether it succeeded, how long it took, and its workspace - never payloads, network details or credentials. Those stay in your local audit log. ```bash swy config cloud enable swy config cloud status swy config cloud disable ``` Cloud Sync is: - Optional and disabled by default - Managed only through `swy config cloud` - it is not a plain `config get`/`set` key like `telemetry_enabled` Because Cloud Sync operates independently of tool execution, disabling it does not affect the runtime or API calls. Synced history is stored in each workspace's [log storage](/guides/workspaces/#logs), so turn log storage on for the workspace too; without it, uploads for that workspace are skipped. It is kept for as long as your plan's log retention. The upload runs with the first command you run after midnight (your computer's time). If it fails, for example because you're offline, the CLI tries again later, at most every 15 minutes. A large backlog is sent over a few days. Team members' history goes to the same workspace. Commands run outside a linked workspace, such as demo runs, stay local. --- ## Usage Metering Live API executions are measured for usage and billing purposes. Every plan includes a monthly number of live commands. Current limits are on [swytchcode.com/pricing](https://www.swytchcode.com/pricing). Only real executions are metered. Operations such as: - Dry runs - `--explain` - Demo executions - Local validation are not included in usage measurements. You can run your first 2 live commands without signing in. After that, run `swy login` to keep going. Commands run with an API key (`swy_key_...`), for example in agents and CI, count toward your monthly limit like any other command. So do commands run for your app's end users. A command counts once it gets a response from the provider, whatever that response is. Retries don't count again. Commands stopped before anything is sent (by a policy, a missing credential, an unset base URL, or the monthly limit) don't count. The CLI reports your usage to your account in batches, at the latest about 15 minutes after a command, so the count in your dashboard can lag slightly behind. Usage metering is separate from telemetry. Disabling telemetry does **not** disable usage metering for billable executions. --- ## Privacy Swytchcode separates operational data from runtime execution. - Telemetry helps improve the CLI experience. - Cloud Sync stores execution history for your workspace. - Usage metering tracks billable executions. - Tool execution continues independently of these services. You can choose whether to enable telemetry and Cloud Sync without affecting how your applications execute tools. --- ## Best Practices For most development environments, we recommend: - Enable telemetry to help improve CLI reliability. - Set `SWYTCHCODE_NO_TELEMETRY=1` in environments where outbound analytics are not permitted. - Enable Cloud Sync if you work across multiple machines. - Review your organization's privacy and compliance requirements before enabling telemetry. --- ## What's Next? - [Authentication](https://docs.swytchcode.com/cli/authentication/) - Learn how the CLI authenticates your account and securely manages provider credentials. - [Pricing](https://www.swytchcode.com/pricing) - Monthly live-command limits and what each plan includes. - [Workspaces and teams](https://docs.swytchcode.com/guides/workspaces/) - Where logs and approval settings live, and how to pin a project. - [Managed Authentication](https://docs.swytchcode.com/guides/managed-authentication/) - Explore how provider credentials are securely resolved during execution. - [CLI Overview](https://docs.swytchcode.com/cli/overview/) - Learn more about the architecture and core concepts of the Swytchcode CLI.