What ThinkingSDK Is Not

ThinkingSDK is purpose-built for one thing: catching and fixing runtime exceptions autonomously. Understanding what it is NOT helps you use it correctly and set the right expectations.

Not an APM or Telemetry Service

ThinkingSDK does not replace Datadog, New Relic, or Prometheus. We do not:

• Collect request latency percentiles (p50, p95, p99)
• Track throughput or requests per second
• Monitor server uptime or health checks
• Generate service dependency maps
• Provide infrastructure monitoring (CPU, disk, network)
• Aggregate custom business metrics over time
• Build dashboards for operational metrics

We capture system state (CPU, memory, threads) only at the moment of a crash — as forensic context for debugging, not for continuous monitoring.

If you need APM, use Datadog or New Relic alongside ThinkingSDK. They complement each other: APM tells you something is slow, ThinkingSDK tells you why it crashed and fixes it.

Not a Logging Service

ThinkingSDK does not replace your logging infrastructure. We do not:

• Ingest or store application logs
• Provide log search or filtering (use ELK, Loki, CloudWatch)
• Aggregate log volumes or patterns
• Alert on log patterns or keywords
• Provide structured logging pipelines

We capture log messages only as breadcrumbs — the trail of events leading up to a crash. These are stored per-exception, not as a continuous log stream.

Keep your existing logging. ThinkingSDK reads from it (via the Python logging integration) but does not replace it.

Not a Feature Flag or A/B Testing Platform

ThinkingSDK does not:

• Manage feature flags or rollouts
• Run A/B experiments
• Track conversion funnels
• Provide user segmentation
• Control release toggles

SDK configuration (thinking.start() options and thinkingsdk.yaml) controls SDK behavior (capture settings, batching), not your application's feature flags.

Not a User Analytics Platform

ThinkingSDK does not:

• Track user sessions, page views, or click events
• Build user behavior funnels
• Provide cohort analysis
• Track user retention or churn
• Generate product usage reports

We track user context only when an exception occurs — to help you understand who was affected and what they were doing when the crash happened.

Not a General-Purpose Error Tracker

This is the important distinction from Sentry and similar tools:

ThinkingSDK goes beyond detection. The entire pipeline — from crash capture to pull request — is autonomous.

What ThinkingSDK IS

A single sentence: ThinkingSDK catches production exceptions, freezes the full crash state, generates an AI fix, and opens a pull request.

The three pillars:

1. Crash Time Capsule

Every exception is captured with the complete frozen state — local variables at every stack frame, breadcrumb trail, system snapshot (memory, CPU, threads), and execution context. Browse it in the Time Capsule viewer.

2. Crash Simulator

Load the frozen crash state into an isolated sandbox. Edit variables, modify code, re-run — all without touching production. Verify your fix works before it ships.

3. AI Fix Generation

ThinkingSDK connects to your GitHub repository, reads the exception in context, generates a fix, evaluates it with a quality judge, runs tests, and opens a pull request. Average time from exception to PR: 5 minutes.

When to Use ThinkingSDK

Use it when:
- Your production application throws runtime exceptions
- You want exceptions fixed autonomously, not just reported
- You want full crash forensics (variables, stack, system state)
- You want PR-ready fixes, not just alerts

Don't use it for:
- Performance monitoring or latency tracking
- Log aggregation or search
- Uptime monitoring
- Business analytics
- Infrastructure observability