Skip to content
Swytchcode logo Swytchcode logo Swytchcode Docs docs

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.

Terminal window
swy config telemetry disable

Check the current state at any time:

Terminal window
swy config telemetry status

You can also read or set the underlying key directly:

Terminal window
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:

Terminal window
export SWYTCHCODE_NO_TELEMETRY=1

Your commands keep working as normal. Usage reporting for billing still runs (see 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.

Terminal window
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 <id> or swy audit policy --info <id> for full detail. See the Command Reference 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.

Terminal window
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, 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.

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

Learn how the CLI authenticates your account and securely manages provider credentials.

Pricing

Monthly live-command limits and what each plan includes.

Workspaces and teams

Where logs and approval settings live, and how to pin a project.

Managed Authentication

Explore how provider credentials are securely resolved during execution.

CLI Overview

Learn more about the architecture and core concepts of the Swytchcode CLI.