Build an AI Error Explainer with Telnyx AI Inference

Every developer has seen an error message that looks obvious only after the fix is already known.

A stack trace gives you evidence: file names, line numbers, exception classes, function calls, and sometimes a very specific failure. But in a real workflow, that trace usually arrives with pressure attached. A deploy failed. A customer-facing request is broken. A CI job is red. Someone needs to understand what happened and what to try next.

The error-explainer-python example shows how to turn that moment into a small AI-assisted debugging API with Telnyx AI Inference.

Code:

What the example builds

The app is a Flask service with four routes:

• POST /explain accepts a stack trace and returns a structured diagnosis
• GET /analyses lists recent diagnoses
• GET /analyses/<id> fetches one diagnosis by ID
• GET /health returns basic service status

The main route is POST /explain. It accepts:

• stack_trace: the error text to diagnose
• language: optional programming language context
• context: optional runtime or environment notes

The response is structured JSON instead of a long paragraph. A successful response can include:

• root_cause
• severity
• confidence
• likely_culprit
• suggested_fix
• fix_snippet
• related_errors
• prevention
• generated_at
• language

That shape is the most important part of the example. The app is not just asking a model, "What does this error mean?" It is asking for output that another system can use.

Why structured debugging output matters

If you paste a stack trace into a chat box, you may get a helpful answer. But if you are building a real developer tool, you usually need something more predictable.

Structured output lets you:

• show severity in a dashboard
• route high-severity diagnoses to Slack
• store diagnoses for later review
• attach suggested fixes to CI failures
• compare confidence across repeated errors
• render a concise incident summary for support teams

The example stores generated analyses in memory and assigns each one an ID. That is intentionally simple, but it demonstrates the shape of a debugging workflow: submit error, get diagnosis, retrieve it later.

How it uses Telnyx AI Inference

The app sends requests to:

POST /v2/ai/chat/completions

The default model in .env.example is:

AI_MODEL=moonshotai/Kimi-K2.6

The Flask app builds a prompt that asks the model to act like a senior software engineer diagnosing a stack trace. It includes the provided language and context if available, truncates very long traces, and asks for JSON with a specific set of fields.

The system prompt is intentionally direct:

You are a senior software engineer who diagnoses errors from stack traces. Return JSON only.

When the response comes back, the app parses the JSON, adds an ID and timestamp, stores the analysis in memory, and returns it to the caller.

Run the example

Clone the examples repo:

git clone https://github.com/team-telnyx/telnyx-code-examples.git
cd telnyx-code-examples
git switch feat/error-explainer-python
cd error-explainer-python

Create your environment file:

cp .env.example .env

Add your Telnyx API key:

TELNYX_API_KEY=your_telnyx_api_key
AI_MODEL=moonshotai/Kimi-K2.6
HOST=127.0.0.1

Install dependencies and start the app:

pip install -r requirements.txt
python app.py

Check the server:

curl http://localhost:5000/health

Explain a stack trace:

curl -X POST http://localhost:5000/explain \
  -H "Content-Type: application/json" \
  -d '{
    "language": "python",
    "context": "Flask production server with gunicorn",
    "stack_trace": "Traceback (most recent call last):\n  File \"app.py\", line 42, in handle_request\n    resp = requests.post(url)\nrequests.exceptions.ConnectionError: HTTPSConnectionPool(host=api.example.com, port=443): Max retries exceeded"
  }' | python3 -m json.tool

List recent analyses:

curl http://localhost:5000/analyses | python3 -m json.tool

Where this pattern can go

This example is small, but the workflow is realistic.

You could extend it to:

• explain CI failures automatically
• summarize production exceptions for on-call engineers
• send high-severity diagnoses to Slack
• attach suggested fixes to GitHub pull requests
• store repeated error patterns in a database
• add a small web UI for support or platform teams
• tune prompts for a specific codebase or framework

The important design pattern is that AI is not replacing debugging judgment. It is turning raw error text into a structured first pass that helps a developer decide what to investigate next.