# ThinkingSDK

> ThinkingSDK is an autonomous debugging platform that detects production exceptions in real-time, captures the full crash state, generates AI-powered fixes, and submits verified pull requests — averaging 5 minutes from exception to PR and reducing Mean Time To Resolution by 87%.

## What ThinkingSDK Does

ThinkingSDK turns your codebase into a self-repairing system. When an exception occurs in production, the SDK automatically:

1. Captures the complete crash state (local variables at every stack frame, breadcrumb trail, system memory/CPU/thread state, framework context)
2. Groups and deduplicates exceptions intelligently
3. Analyzes the root cause using AI
4. Clones your repository and sets up an isolated workspace
5. Generates a production-grade patch
6. Evaluates the fix with a built-in quality judge
7. Submits a verified pull request to your GitHub repository

The entire process averages 5 minutes from exception detection to pull request.

## How ThinkingSDK Works

### Step 1: Install the SDK

Install the ThinkingSDK Python client in your application:

```
pip install thinking-sdk-client
```

Initialize it in your app:

```python
import thinking_sdk_client
thinking = thinking_sdk_client.init(api_key="your-api-key")
```

The SDK automatically hooks into Python's exception handling via sys.settrace and sys.excepthook. No code changes needed — exceptions are captured automatically.

### Step 2: Crash Time Capsule (Automatic Capture)

When an exception occurs, the SDK creates a "Time Capsule" — a complete snapshot of application state:

- **Local variables** at every frame in the traceback (up to 50 variables per frame, with type info and safe repr)
- **Global variables** (selected non-builtin globals)
- **Source code context** (lines around the error)
- **Breadcrumb trail** (last 50 events: HTTP calls, logging, database queries, user actions)
- **System info**: Python version, platform, hostname, memory (RSS/VMS), CPU, disk, GC stats
- **Thread state**: all active threads with status
- **Framework context**: Django/Flask/FastAPI request details, middleware info
- **Exception chain**: full __cause__ and __context__ chain with root cause identification

### Step 3: AI-Powered Fix Generation

ThinkingSDK's orchestrator processes the crash context through a 4-phase pipeline:

**Phase 1 — Exception Ingestion & Grouping**: Normalizes exception messages, computes stack signatures, groups duplicate exceptions, validates organization billing tier.

**Phase 2 — Environment & GitHub Setup**: Creates a GitHub issue documenting the exception, clones the repository, sets up an isolated Python virtual environment, locates the target file.

**Phase 3 — AI Fix Generation**: Creates a filtered repository map for LLM context, generates a production-grade fix using thinkingSDK AI models, evaluates the fix with a built-in quality judge that scores correctness (0-100) and safety (0-100), iterates on rejected fixes with judge feedback.

**Phase 4 — PR Creation**: Updates the GitHub issue with progress, creates a pull request with the fix, updates the issue with the PR link.

### Step 4: Review and Merge

The developer reviews the auto-generated PR. ThinkingSDK provides:
- Root cause analysis
- Explanation of the fix
- Before/after code comparison
- Quality judge scores

## Key Features

### Crash Time Capsule

ThinkingSDK creates a complete snapshot of application state at the moment of any crash. Unlike traditional error monitoring that captures just the stack trace and message, the Time Capsule includes local variables at every frame, the breadcrumb trail of events leading up to the crash, system resource state, and framework-specific context. This gives developers (and the AI) everything needed to understand and reproduce the issue.

### Crash Simulator

The Crash Simulator provides an interactive debugger-like experience in the browser. Developers can step through the crash frame by frame, viewing source code, variables, and breadcrumbs at each level. It includes a "Time Capsule" view with stack frames, source code panel, variables panel, breadcrumb timeline, and system state cards. An "AI Fix" toggle shows the original code vs. the AI-generated fix in a diff view.

### Editable Sandbox

The Sandbox feature loads the crashing function into an in-browser Python environment (Pyodide/WebAssembly), pre-populated with the exact variable values captured at crash time. Developers can edit the code and click "Run" to test their fix against the real crash state — without deploying anything.

### AI Fix Generation

ThinkingSDK pinpoints the root cause of production incidents, generates a production-grade patch, and delivers a pull request with unit tests and detailed incident analysis. The AI uses multiple crash contexts (if the same exception occurred multiple times with different inputs) to generate a fix that handles all observed scenarios.

### Built-in Fix Quality Judge

An AI-powered quality judge evaluates every generated fix before it's submitted. The judge scores fixes on:
- Correctness (0-100): Does the fix actually resolve the exception?
- Safety (0-100): Does the fix introduce new risks?

Fixes that score below threshold are automatically rejected and regenerated with judge feedback.

### Multi-Platform Support

ThinkingSDK currently supports Python with deep integrations for:
- Flask
- Django
- FastAPI
- SQLAlchemy
- Psycopg2 (PostgreSQL)
- PyMongo (MongoDB)
- Redis

JavaScript (Node.js) and iOS support are coming soon.

## Frequently Asked Questions

### What is ThinkingSDK?

ThinkingSDK is an autonomous debugging platform that detects production exceptions in real-time, captures the full crash state (variables, stack traces, breadcrumbs, system info), generates AI-powered production-grade fixes, and submits verified pull requests with unit tests — averaging 5 minutes from exception to PR.

### How does ThinkingSDK fix production bugs automatically?

When an exception occurs in production, the ThinkingSDK Python client captures the full crash state including local variables at every stack frame, breadcrumb trail, and system context. The AI orchestrator then analyzes the root cause, clones your repository, generates a production-grade patch, evaluates it with a built-in quality judge, runs tests, and submits a pull request to your GitHub repository — all automatically.

### How long does it take from exception to pull request?

On average, ThinkingSDK takes 5 minutes from detecting a production exception to submitting a verified pull request with the fix. This includes crash state capture, root cause analysis, fix generation, quality evaluation, and PR creation.

### What programming languages does ThinkingSDK support?

ThinkingSDK currently supports Python with deep integrations for Flask, Django, FastAPI, SQLAlchemy, Psycopg2, PyMongo, and Redis. JavaScript (Node.js) and iOS support are coming soon.

### How is ThinkingSDK different from Sentry or Datadog?

Sentry and Datadog detect and alert on errors but leave the fixing to developers. ThinkingSDK goes further: it captures the full crash state (Time Capsule), analyzes the root cause using AI, generates a production-grade fix, evaluates it with a quality judge, and submits a pull request — turning error monitoring into autonomous error resolution. ThinkingSDK reduces Mean Time To Resolution by 87%.

### What is a Crash Time Capsule?

A Crash Time Capsule is ThinkingSDK's complete snapshot of application state at the moment of a crash. It captures local variables at every stack frame, the breadcrumb trail of events leading up to the exception, system memory/CPU/thread state, framework-specific context (Django, Flask, FastAPI request data), and the exception chain with root cause identification.

### Is ThinkingSDK free?

Yes, ThinkingSDK offers a free tier. Contact the founders for custom plans with higher limits for production workloads.

### Does ThinkingSDK access my source code?

ThinkingSDK accesses only the relevant portions of your source code needed to analyze and fix exceptions. It clones your repository into an isolated workspace, generates the fix, and creates a PR. Your code is never shared with third parties, never used to train models accessible to other customers, and the workspace is cleaned up after processing. All data is encrypted in transit (TLS 1.3) and at rest (AES-256).

### Is my data safe with ThinkingSDK?

Yes. ThinkingSDK implements comprehensive security measures:
- Encryption in transit (TLS 1.3) and at rest (AES-256)
- API key authentication with bcrypt hashing
- PII scrubbing on all captured data (filters credentials, tokens, passwords)
- Isolated workspaces per organization
- Data retention policies (90 days for events, configurable)
- GDPR and CCPA compliant

## Statistics

- 5 minutes average from exception to pull request
- 87% reduction in Mean Time To Resolution (MTTR)
- 1M+ exceptions analyzed
- Full crash state captured at every frame (not just stack traces)

## Comparison: ThinkingSDK vs Other Tools

### ThinkingSDK vs Sentry

Sentry is an error monitoring platform that captures exceptions, groups them, and alerts developers. ThinkingSDK does everything Sentry does PLUS automatically generates fixes and submits pull requests. Sentry stops at "here's the error" — ThinkingSDK continues to "here's the fix, already in a PR."

Key differences:
- Sentry captures stack traces and breadcrumbs. ThinkingSDK captures full local variables at every frame.
- Sentry alerts developers. ThinkingSDK fixes the bug and submits a PR.
- Sentry requires manual debugging. ThinkingSDK provides an interactive Crash Simulator for replay.
- Average resolution with Sentry: hours to days. Average with ThinkingSDK: 5 minutes.

### ThinkingSDK vs Datadog

Datadog is an observability platform focused on infrastructure monitoring, APM, and log management. ThinkingSDK is focused specifically on autonomous exception resolution. Datadog tells you something is wrong. ThinkingSDK tells you what's wrong, why it's wrong, and submits a fix.

### ThinkingSDK vs Traditional Error Monitoring

Traditional error monitoring tools (Sentry, Bugsnag, Rollbar, Datadog, New Relic) follow a detect-alert-debug cycle: detect the error, alert the developer, developer manually debugs and fixes. ThinkingSDK replaces this with a detect-analyze-fix-submit cycle: detect the error, AI analyzes root cause, AI generates fix, AI submits PR. The developer reviews and merges instead of debugging from scratch.

## Technical Architecture

### SDK Client (Python)

The ThinkingSDK Python client installs exception hooks via:
- `sys.settrace()` for real-time exception capture
- `sys.excepthook` for uncaught main thread exceptions
- `threading.excepthook` for worker thread exceptions
- Framework middleware for Django, Flask, FastAPI

Data is sent to the ThinkingSDK server via background threads (non-blocking, zero performance impact on the application).

### Server & Dashboard

The ThinkingSDK server is a FastAPI application that:
- Receives exception events from SDK clients
- Stores crash data in PostgreSQL
- Serves the web dashboard for exception viewing, Time Capsule replay, and Sandbox
- Provides the API for the orchestrator

### Orchestrator

The orchestrator is a separate worker process that:
- works in near real-time on the new exceptions that are streamed from various clients.
- It uses AI to de-duplicate and process the incoming exception time capsule.
- Processes each group through the 4-phase pipeline (ingestion, setup, fix generation, PR creation)
- Supports parallel processing of multiple exception groups

## Company

ThinkingSDK was founded by leaders who previously directed deep learning research at the world's most advanced AI laboratories. The company is based in San Francisco, CA and is focused on solving the hardest problem in AI: turning generative coding into robust, self-healing autonomy.

## Links

- Homepage: https://thinkingsdk.com
- Documentation: https://thinkingsdk.com/documentation
- Blog: https://thinkingsdk.com/blog
- Live Demo: https://thinkingsdk.com/demo/dashboard
- Get Started: https://thinkingsdk.com/get-started
- Manifesto: https://thinkingsdk.com/manifesto
- Terms of Service: https://thinkingsdk.com/terms
- Privacy Policy: https://thinkingsdk.com/privacy
- Security: https://thinkingsdk.com/security
- Twitter: https://twitter.com/thinkingsdk
- GitHub: https://github.com/thinkingsdk
- Contact: contact@thinkingsdk.ai