DEV Community: wellallyTech

Stop Burning Out! Build a Real-Time Stress Warning System using Python and Speech Emotion Recognition (SER) 🚀

wellallyTech — Thu, 11 Jun 2026 01:40:00 +0000

As developers, we’ve all been there: it's 2:00 AM, the bug isn't moving, and you're starting to talk to your monitor in a tone that can only be described as "controlled desperation." What if your IDE could tell you were reaching a breaking point before you actually did?

In this tutorial, we are building Emotion Geek, a real-time Speech Emotion Recognition (SER) system. By analyzing audio features like MFCC (Mel-Frequency Cepstral Coefficients) and prosodic patterns, we can quantify stress levels and trigger a "forced break" notification. This project leverages Machine Learning, Audio Processing, and Data Validation to keep your mental health in check.

The Architecture 🏗️

The system works by capturing raw audio through the browser, processing the spectral features in a Python backend, and returning a stress score.

graph TD
    A[Developer Voice/Ambient Audio] -->|Web Audio API| B(Frontend Capture)
    B -->|Base64/WAV| C[FastAPI Backend]
    C -->|Pydantic Validation| D[Data Schema]
    D --> E[Feature Extraction: Librosa]
    E -->|MFCCs + Chroma| F[Scikit-learn Classifier]
    F -->|Stress Level > 0.8| G{Alert Triggered?}
    G -->|Yes| H[Notification: Take a Walk! 🥑]
    G -->|No| I[Keep Coding]

Prerequisites 🛠️

To follow along, you'll need the following stack:

Librosa: The gold standard for audio analysis in Python.
Scikit-learn: For our classification model.
Web Audio API: To capture audio in the browser.
Pydantic: To ensure our data flow is type-safe and robust.

Step 1: Feature Extraction with Librosa 🎙️

Audio data is messy. We can't just feed raw .wav files into a model. We need to extract MFCCs, which represent the short-term power spectrum of a sound. Think of it as the "texture" of your voice.

import librosa
import numpy as np

def extract_features(audio_path):
    # Load audio file (16kHz is usually enough for speech)
    y, sr = librosa.load(audio_path, sr=16000)

    # Extract Mel-Frequency Cepstral Coefficients
    mfccs = librosa.feature.mfcc(y=y, sr=sr, n_mfcc=40)
    mfccs_processed = np.mean(mfccs.T, axis=0)

    # Extract Spectral Contrast
    contrast = librosa.feature.spectral_contrast(y=y, sr=sr)
    contrast_processed = np.mean(contrast.T, axis=0)

    # Combine features into a single vector
    return np.hstack([mfccs_processed, contrast_processed])

# Example usage
# features = extract_features("frustrated_dev.wav")

Step 2: Defining the Data Schema with Pydantic 📋

When building a Speech Emotion Recognition system, the data payload from the frontend can be tricky. Using Pydantic, we ensure that the audio metadata and the resulting stress analysis are strictly typed.

from pydantic import BaseModel, Field
from typing import List

class StressAnalysisRequest(BaseModel):
    user_id: str
    audio_data: str  # Base64 encoded string
    sample_rate: int = Field(default=16000, gt=8000)

class StressReport(BaseModel):
    stress_score: float = Field(..., ge=0, le=1)
    emotion_label: str
    needs_break: bool
    suggestions: List[str]

Step 3: The Classification Logic 🧠

For this intermediate build, we use a RandomForestClassifier trained on the RAVDESS or TESS datasets. These datasets contain labeled audio of people expressing various emotions (anger, calm, sadness, etc.).

from sklearn.ensemble import RandomForestClassifier
import joblib

class StressPredictor:
    def __init__(self, model_path):
        self.model = joblib.load(model_path)

    def predict_stress(self, features):
        # 0: Calm, 1: Happy, 2: Sad, 3: Angry/Stressed
        prediction = self.model.predict([features])
        probabilities = self.model.predict_proba([features])

        # We define "Stress" as high probability of 'Angry' or 'Anxious'
        stress_prob = probabilities[0][3] 
        return stress_prob, "Stressed" if stress_prob > 0.7 else "Calm"

Pro-Tip: Building Production-Ready AI Systems 🥑

While this tutorial covers the core logic of SER, moving from a local script to a production-grade wellness tool requires more advanced patterns like real-time streaming sockets and noise-cancellation filters.

For more production-ready examples and advanced architectural patterns regarding AI-driven wellness tools, I highly recommend checking out the engineering deep-dives at WellAlly Blog. They cover how to scale these models and integrate them into enterprise workflows without sacrificing user privacy.

Step 4: The Frontend Hook (Web Audio API) 🌐

To get the audio from your microphone to the Python backend, we use the MediaRecorder API.

// A quick snippet to capture and send audio
navigator.mediaDevices.getUserMedia({ audio: true })
  .then(stream => {
    const mediaRecorder = new MediaRecorder(stream);
    mediaRecorder.start();

    const audioChunks = [];
    mediaRecorder.ondataavailable = event => {
      audioChunks.push(event.data);
    };

    mediaRecorder.onstop = () => {
      const audioBlob = new Blob(audioChunks);
      // Convert to Base64 and send to our FastAPI /analyze endpoint
      sendToBackend(audioBlob);
    };

    // Stop recording after 3 seconds for a sample
    setTimeout(() => mediaRecorder.stop(), 3000);
  });

Conclusion: Listen to Your Voice! 🔊

By combining Librosa for audio feature extraction and Scikit-learn for classification, we've built a system that understands the developer behind the code. This is just the beginning—you could integrate this with Slack to set your status to "Taking a break 🧘" automatically when your stress levels spike!

What are your thoughts?

Would you trust an AI to tell you when to take a break?
What other "Developer Health" tools should we build?

Let me know in the comments below! 👇

Full-Stack SSR on Cloudflare Workers: Why Workers Are the Future of SaaS

wellallyTech — Wed, 10 Jun 2026 04:46:00 +0000

Cloudflare Workers are redefining how SaaS applications are built and deployed. By running server-side rendering at the edge across 330+ global locations with near-zero cold starts, they eliminate the traditional trade-off between performance and complexity. Combined with TanStack Start, developers can build full-stack, SSR-powered SaaS applications that load faster, scale globally, and cost less to operate than conventional Node.js backends.

Introduction: The Edge Computing Revolution

For the past decade, the dominant architecture for web applications has been remarkably consistent: a monolithic or microservice backend deployed to a handful of regional data centers, coupled with a client-rendered frontend. Server-side rendering, when implemented, required orchestrating Node.js processes, managing memory, and accepting latency penalties as requests traversed the globe.

That era is ending.

Edge computing — and specifically Cloudflare Workers — represents a paradigm shift. Instead of routing all traffic through a few centralized servers, Workers run your code at the network edge, in over 330 cities worldwide. For SaaS founders and full-stack developers, this changes the fundamental economics and architecture of building a web application. SSR, traditionally one of the hardest problems to scale, becomes trivial. Global performance becomes a default, not an optimization.

What Makes Cloudflare Workers Different

V8 Isolates, Not Containers

Traditional serverless functions (AWS Lambda, Google Cloud Functions) use containers or virtual machines. Each invocation may require spinning up a new container, loading your runtime, and booting your application — a process that can take hundreds of milliseconds.

Cloudflare Workers use V8 isolates. Each Worker runs inside a lightweight V8 sandbox that starts in approximately 5 milliseconds. There is no container orchestration, no Docker image to pull, and no OS to boot.

export default {
  async fetch(request) {
    const url = new URL(request.url);
    if (url.pathname === '/api/health') {
      return new Response(JSON.stringify({ status: 'ok', region: request.cf?.colo }), {
        headers: { 'content-type': 'application/json' }
      });
    }
    return new Response('Hello from the edge!');
  }
};

This code deploys to 330+ locations simultaneously. No load balancers. No regional configuration. No container registries.

Zero Cold Starts

The "cold start" problem has been the Achilles' heel of serverless computing. When a Lambda function hasn't been invoked recently, the platform may need to provision a new container and boot the runtime, adding 500ms-5 seconds of latency.

Workers eliminate this problem. Because V8 isolates are so lightweight, Cloudflare keeps them warm and ready to execute. For SSR applications — where every millisecond of Time to First Byte (TTFB) matters — this is transformative.

330+ Global Locations

A user in Tokyo gets their SSR-rendered HTML from a server in Tokyo. A user in Sao Paulo gets it from Sao Paulo. You don't need to set up multi-region deployments, configure global load balancers, or manage data replication for your compute layer.

SSR at the Edge: Architecture and Benefits

Traditional SSR Architecture

User -> DNS -> CDN (cached assets) -> Origin Server (Node.js)
                                         -> Database / APIs

Every request must travel to your origin server. A user in Australia connecting to Virginia experiences 200-300ms of network latency before the server even starts rendering.

Edge SSR with Workers

User -> Cloudflare Edge (closest of 330+ locations)
        -> Worker runs SSR (V8 Isolate)
        -> Database / APIs (via Workers)
        -> Streaming HTML response

The user connects to the nearest data center. HTML is streamed back with zero round trips to a central origin.

Benefits for SaaS

Dramatically improved TTFB — Rendering happens geographically close to users
SEO without compromise — Search engines receive fully rendered HTML
Simplified architecture — No separate CDN, origin servers, and load balancers
Built-in DDoS protection — Cloudflare's network absorbs attacks
Automatic global scaling — Traffic spikes in one region don't affect others

TanStack Start + Workers: How It Works

TanStack Start provides a first-class integration with Cloudflare Workers. Your routes, API handlers, middleware, and SSR logic all run within the same Worker context:

// server.ts — TanStack Start entry point for Cloudflare Workers
import { createStartHandler } from '@tanstack/react-start';
import { getRouter } from './src/router';

export default createStartHandler({
  getRouter,
  ssr: {
    enabled: true,
    streaming: 'full', // Stream HTML for faster page loads
  },
  getBindings: (env) => ({
    db: env.DB,
    assets: env.ASSETS,
  }),
});

// src/routes/products/$slug.tsx — SSR route with data loading
export const Route = createFileRoute('/products/$slug')({
  loader: async ({ params, context }) => {
    const { db } = context.bindings;
    const product = await db
      .prepare('SELECT * FROM products WHERE slug = ?')
      .bind(params.slug)
      .first();

    if (!product) throw new Error('Product not found');
    return { product };
  },
  component: ProductPage,
});

function ProductPage() {
  const { product } = Route.useLoaderData();
  return (
    <div>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      <div className="text-2xl font-bold">${product.price}</div>
    </div>
  );
}

The route's loader executes on the Worker during SSR, reads from D1, and the rendered HTML is streamed from the nearest edge location.

Performance Comparison: Node.js vs Workers

Metric	Node.js (US-East)	Cloudflare Workers
Cold Start TTFB	~800ms	~50ms
Warm TTFB (US)	~120ms	~30ms
Warm TTFB (Europe)	~300ms	~40ms
Warm TTFB (Asia)	~500ms	~50ms
Peak Throughput	~5,000 req/s (single)	~100,000+ req/s (auto)
Global Deployment	Manual multi-region	Automatic (330+ locations)

Limitations and Trade-Offs

Node.js Compatibility

Not every npm package works on Workers. Packages relying on fs, net, child_process, or socket-based libraries may require alternatives. For most SaaS applications built with modern web frameworks, this is rarely an issue.

Memory and CPU Limits

Workers have a 128MB memory limit and 10ms CPU time limit on free plan (30 seconds on paid). For typical SSR operations, you'll stay well within these limits.

When NOT to Use Workers

CPU-intensive workloads — Video transcoding, ML inference
Legacy Node.js applications with extensive native dependencies
Real-time multiplayer games requiring persistent TCP connections
Compliance-restricted deployments requiring explicit data localization

Real-World Data from TanStack Ship

We run our own SaaS application on Cloudflare Workers:

Median TTFB globally: 38ms
P95 TTFB globally: 112ms
Requests per day: ~250,000
Monthly cost: $15 (Workers Paid + D1 database)

To serve 250,000 requests/day with sub-100ms global TTFB on traditional Node.js, we would need a CDN, multi-region deployment, and a global load balancer at an estimated $200-$500/month.

Conclusion

Cloudflare Workers represent a fundamental shift in how we build and deploy web applications. By combining edge computing, JS-native runtime, and automatic global distribution, they solve the hardest problems of SaaS deployment: performance becomes a platform feature, scale is automatic, cost is dramatically lower, and complexity is reduced.

When paired with TanStack Start, Workers enable a full-stack development experience where SSR, data loading, API routes, and React hydration all work together seamlessly — running at the edge, close to every user on the planet.

The future of SaaS deployment is edge-native. And that future is already here.

Related Resources

From Paper Reports to Personal Insights: Building a Medical GraphRAG with Neo4j and LlamaIndex 🚀

wellallyTech — Wed, 10 Jun 2026 01:35:00 +0000

Have you ever tried to upload five years of medical lab results to a standard ChatGPT interface and asked, "How has my LDL cholesterol trended compared to my Vitamin D levels?"

If you have, you probably noticed the "hallucination wall." Traditional Vector RAG (Retrieval-Augmented Generation) is fantastic at finding specific text chunks, but it fundamentally fails at understanding relational trends and temporal data hidden across multiple documents. It treats your health history like a pile of disconnected sentences rather than a continuous journey.

Today, we are moving beyond simple vector embeddings. We’re diving into the world of Knowledge Graph RAG (GraphRAG). By combining Neo4j, LlamaIndex, and Unstructured.io, we will build a system that transforms messy PDF lab reports into a queryable, structured medical knowledge graph.

Keywords: GraphRAG, Neo4j Medical Database, LlamaIndex Tutorial, LLM Medical Analysis, Unstructured Data Processing.

The Architecture: Why Graphs? 🧠

In a medical context, a single data point (e.g., "Glucose: 105 mg/dL") is useless without context. You need to know the unit, the reference range, the date of the test, and how it relates to previous results.

A Knowledge Graph allows us to link an Indicator to a Report, which is linked to a Date, creating a path that an LLM can traverse to provide chronological reasoning.

graph TD
    A[Lab PDF Reports] -->|Unstructured.io| B(Raw Text & Tables)
    B -->|LlamaIndex Extraction| C{Property Graph Index}
    C -->|Store Nodes/Edges| D[Neo4j Database]
    E[User Query: What is my Glucose trend?] -->|Cypher Query| D
    D -->|Contextual Subgraph| F[GPT-4o / Claude 3.5]
    F -->|Natural Language Response| G[Final Insight]

    subgraph "Graph Schema"
    D1[Patient] --- D2[Report]
    D2 --- D3[Biomarker: Glucose]
    D3 --- D4[Value: 105]
    D3 --- D5[Date: 2023-10-01]
    end

Prerequisites 🛠️

Before we get our hands dirty, ensure you have the following stack ready:

Neo4j: Our graph database (running via Docker).
LlamaIndex: The orchestration framework for LLM data.
Unstructured.io: To handle the nightmare of parsing medical PDF tables.
Docker: For easy deployment.
OpenAI API Key: For entity extraction and synthesis.

Step 1: Spin up the Graph Infrastructure 🐳

First, we need a place for our data to live. Use Docker to get Neo4j up and running in seconds.

docker run \
    --name neo4j-medical-graph \
    -p 7474:7474 -p 7687:7687 \
    -d \
    -e NEO4J_AUTH=neo4j/password_here \
    -e NEO4J_PLUGINS='["apoc"]' \
    neo4j:latest

Step 2: Parsing Complex Medical PDFs 📄

Medical reports are notoriously difficult to parse. They are filled with tables, nested grids, and tiny fonts. We'll use Unstructured.io to normalize this data before feeding it to our index.

from llama_index.readers.file import UnstructuredReader

# Initialize the reader
reader = UnstructuredReader()

# Load your lab reports
documents = reader.load_data(input_file="./data/blood_test_oct_2023.pdf")

print(f"Parsed {len(documents)} document chunks.")

Step 3: Building the Property Graph Index 🧬

This is where the magic happens. Instead of just creating "chunks," we tell LlamaIndex to extract specific Entities (like Biomarker, Value, Unit) and Relationships (like HAS_VALUE, TESTED_ON).

from llama_index.core import PropertyGraphIndex
from llama_index.graph_stores.neo4j import Neo4jPropertyGraphStore
from llama_index.llms.openai import OpenAI

# Connection to our Dockerized Neo4j
graph_store = Neo4jPropertyGraphStore(
    username="neo4j",
    password="password_here",
    url="bolt://localhost:7687"
)

# Define the LLM for extraction
llm = OpenAI(model="gpt-4o")

# Create the Graph Index
index = PropertyGraphIndex.from_documents(
    documents,
    llm=llm,
    graph_store=graph_store,
    embed_model="local:BAAI/bge-small-en-v1.5", # Efficient local embedding
    show_progress=True
)

Step 4: Querying for Temporal Insights 🔍

Now, instead of a simple similarity search, we can perform Text-to-Cypher queries. This allows the LLM to write graph queries that navigate the timeline of your health.

query_engine = index.as_query_engine(
    include_text=True, 
    similarity_top_k=5
)

response = query_engine.query(
    "Compare my Glucose levels from the last three reports. Are they increasing?"
)

print(f"📊 Analysis: {response}")

The "Official" Way to Scale 🥑

Building a local prototype is a great start, but when you're moving toward production-grade medical AI applications, there are nuances in data privacy (HIPAA), graph schema optimization, and multi-agent orchestration that you need to consider.

For deep dives into advanced RAG patterns and production-ready architectures, I highly recommend checking out the engineering deep-dives at WellAlly Tech Blog. They cover everything from sovereign LLM deployments to high-performance graph optimizations that were the primary inspiration for this build.

Conclusion: The Future is Relational 🚀

Traditional RAG is like reading a book page by page. GraphRAG is like having the entire plot, character map, and timeline in your head at once. For medical data, where the "truth" lies in the relationships between numbers over time, GraphRAG isn't just an "upgrade"—it's a necessity.

What's next?

Try adding Multi-Agent support to check your lab results against the latest medical journals.
Implement Hybrid Search (Vector + Graph) to get the best of both worlds.

Did you find this helpful? Drop a comment below with your thoughts on Knowledge Graphs, and don't forget to star the repo if you're building along! 🌟

Cloudflare R2: Object Storage for Edge Applications and SaaS

wellallyTech — Tue, 09 Jun 2026 03:45:33 +0000

Cloudflare R2 is an S3-compatible object storage service with zero egress fees — a game-changer for SaaS applications. Unlike AWS S3, you pay no transfer costs when serving files to users. This guide covers everything you need to integrate R2 with TanStack Start: bucket setup, direct uploads, public serving, image resizing, access control, and cost comparisons. See a production R2 setup at tanstackship.com.

Why R2 for SaaS?

Feature	Cloudflare R2	AWS S3	Google Cloud Storage
Egress fees	$0 — no charge for data transfer	$0.09/GB	$0.08-0.12/GB
Storage cost	$0.015/GB/mo	$0.023/GB/mo	$0.020/GB/mo
API compatibility	S3-compatible	Native	S3-compatible
Edge network	330+ locations	Regional	Regional
Cache integration	Smart Tiering + Cache Reserve	S3 + CloudFront	CDN interop
Global latency	30-50ms	50-200ms (regional)	50-200ms (regional)

Setup: Bucket Configuration

# wrangler.jsonc — bind R2 bucket to your Worker
{
  "name": "tanstack-ship",
  "r2_buckets": [
    {
      "binding": "MY_BUCKET",
      "bucket_name": "tanstack-ship-prod",
      "preview_bucket_name": "tanstack-ship-staging"
    }
  ]
}

Public Access Configuration

# Make bucket publicly accessible via custom domain
wrangler r2 bucket create tanstack-ship-prod --public
wrangler r2 bucket domain add tanstack-ship-prod r2.tanstackship.com

# Set CORS policy via S3 API
aws s3api put-bucket-cors --bucket tanstack-ship-prod \
  --cors-configuration '{
    "CORSRules": [{
      "AllowedOrigins": ["https://tanstackship.com"],
      "AllowedMethods": ["GET", "PUT", "POST"],
      "AllowedHeaders": ["*"],
      "ExposeHeaders": ["ETag"]
    }]
  }' --endpoint-url https://<account>.r2.cloudflarestorage.com

Upload Patterns

Basic Upload from Worker

// server/uploads.ts
export const uploadFile = createServerFn({ method: "POST" }).handler(
  async ({ request, context }) => {
    const formData = await request.formData()
    const file = formData.get("file") as File

    const key = `uploads/${crypto.randomUUID()}-${file.name}`
    const arrayBuffer = await file.arrayBuffer()

    await context.env.MY_BUCKET.put(key, arrayBuffer, {
      httpMetadata: {
        contentType: file.type,
        contentDisposition: `inline; filename="${file.name}"`,
      },
      customMetadata: {
        uploadedBy: context.user.id,
        originalName: file.name,
      },
    })

    return {
      key,
      url: `https://r2.tanstackship.com/${key}`,
      size: file.size,
    }
  }
)

Browser Direct Upload (Large Files)

// Client-side upload directly to R2
export const getUploadToken = createServerFn({ method: "GET" }).handler(
  async ({ data, context }: { data: { filename: string; contentType: string } }) => {
    const key = `uploads/${crypto.randomUUID()}-${data.filename}`

    // Generate a presigned URL valid for 1 hour
    const uploadUrl = await context.env.MY_BUCKET.createPresignedUrl({
      key,
      method: "PUT",
      expiryInSeconds: 3600,
    })

    return {
      key,
      uploadUrl,
      publicUrl: `https://r2.tanstackship.com/${key}`,
    }
  }
)

Image Processing with R2

Combine R2 with Cloudflare Image Resizing for on-the-fly transformations:

// Using Cloudflare Image Resizing via query parameters
function OptimizedImage({ src, width, height }: OptimizedImageProps) {
  // Format: /cdn-cgi/image/width=N,quality=Q/format=F/path
  const optimizedSrc = `/cdn-cgi/image/width=${width},format=webp,quality=80${src}`

  return (
    <img
      src={optimizedSrc}
      alt=""
      width={width}
      height={height}
      loading="lazy"
    />
  )
}

Image Processing Options

Parameter	Values	Description
`width`	1-4096	Target width in pixels
`height`	1-4096	Target height in pixels
`format`	auto, webp, avif, jpeg, png	Output format
`quality`	1-100	Image quality percentage
`fit`	scale-down, contain, cover, crop, pad	Resizing behavior
`sharpen`	0-10	Sharpening strength
`blur`	0-250	Gaussian blur radius

Programmatic Image Processing

export const processAndStore = createServerFn({ method: "POST" }).handler(
  async ({ data, context }: { data: { buffer: ArrayBuffer; filename: string } }) => {
    // Store original
    const originalKey = `originals/${filename}`
    await context.env.MY_BUCKET.put(originalKey, data.buffer)

    // Generate thumbnails (processed on access via Image Resizing)
    const variants = [
      { key: `thumbs/150/${filename}`, width: 150 },
      { key: `thumbs/400/${filename}`, width: 400 },
      { key: `thumbs/800/${filename}`, width: 800 },
    ]

    for (const variant of variants) {
      // Store a small placeholder — actual resizing happens via /cdn-cgi/image/
      await context.env.MY_BUCKET.put(variant.key, data.buffer, {
        customMetadata: { originalWidth: variant.width.toString() },
      })
    }

    return {
      original: `https://r2.tanstackship.com/${originalKey}`,
      thumbnails: variants.map((v) => ({
        width: v.width,
        url: `https://r2.tanstackship.com/${v.key}`,
      })),
    }
  }
)

Access Control

Private Bucket with Signed URLs

export const getSignedFileUrl = createServerFn({ method: "GET" }).handler(
  async ({ data, context }: { data: { key: string } }) => {
    // 1. Check permissions
    const fileMeta = await context.env.MY_BUCKET.head(data.key)
    const ownerId = fileMeta?.customMetadata?.uploadedBy

    if (ownerId && ownerId !== context.user.id) {
      throw new Error("Unauthorized")
    }

    // 2. Generate temporary URL
    const url = await context.env.MY_BUCKET.createPresignedUrl({
      key: data.key,
      method: "GET",
      expiryInSeconds: 3600,
    })

    return { url }
  }
)

Cost Optimization

R2 Tiering

Hot Tier (default): $0.015/GB/mo
→ Objects accessed frequently (>1x per month)

Infrequent Access Tier: $0.01/GB/mo
→ Objects accessed less than once per month
→ $0.01/GB retrieval fee

Smart Tiering (auto): Automatically moves objects between tiers
→ Based on last access time
→ No manual lifecycle rules needed

Cost Comparison for a SaaS with 100GB Storage and 1TB Monthly Egress

Provider	Storage (100GB)	Egress (1TB)	Total/Month
Cloudflare R2	$1.50	$0.00	$1.50
AWS S3 Standard	$2.30	$90.00	$92.30
AWS S3 + CloudFront	$2.30	$85.00 (CF egress)	$87.30
Backblaze B2	$0.60	$10.00	$10.60

Lifecycle Rules

// Set via S3 API or wrangler
// Auto-delete temporary uploads after 24 hours
export const cleanupTempUploads = async (env: Env) => {
  const objects = await env.MY_BUCKET.list({ prefix: "temp/" })

  const now = Date.now()
  for (const obj of objects.objects) {
    const age = now - obj.uploaded.getTime()
    if (age > 24 * 60 * 60 * 1000) {
      await env.MY_BUCKET.delete(obj.key)
    }
  }
}

Production Checklist

[ ] Bucket CORS configured for allowed origins
[ ] Public bucket has custom domain with TLS
[ ] Presigned URLs have short expiry (1 hour for uploads, 24 hours for downloads)
[ ] File type and size validation before upload
[ ] Unique filenames (UUID-based) to prevent collisions
[ ] Cache Reserve enabled for frequently accessed objects
[ ] Smart Tiering enabled for cost optimization
[ ] Lifecycle rules for temp file cleanup
[ ] Audit logging for all upload and delete operations
[ ] Access control enforced for private files

Conclusion

Cloudflare R2's combination of zero egress fees, global edge network, and S3 compatibility makes it the ideal object storage choice for SaaS applications. Integrated with TanStack Start on Cloudflare Workers, files flow from user upload to edge storage to user download without leaving the Cloudflare ecosystem — minimizing latency and cost.

The key decision points:

Public files (images, assets) → Serve directly from R2 with Image Resizing
Private files (documents, reports) → Signed URLs with auth check
Large files (videos, datasets) → Presigned upload URLs + chunked upload

For a production R2 implementation, see the file upload architecture at tanstackship.com.

Related Resources

HormoneAgent: Building a Self-Correcting Health AI with LangGraph and Apple Health 🥑🚀

wellallyTech — Tue, 09 Jun 2026 01:45:00 +0000

Stop me if this sounds familiar: You wake up feeling like a zombie 🧟, your stress levels are through the roof, and your Apple Watch is screaming that your cortisol is peaking. You know you should eat something restorative, but you end up grabbing a sugary donut instead. What if your biological data could talk directly to your calendar?

Today, we are building HormoneAgent, an advanced AI Agent designed for biohacking enthusiasts. Using LangGraph, LangChain, and the HealthKit API, we’ll create an automated workflow that senses physiological shifts—like sleep deprivation or hormonal spikes—and dynamically updates your nutrition plan via the Notion SDK. We are moving past simple chatbots into the world of personalized nutrition and autonomous LLM workflows.

The Architecture: Why LangGraph?

Traditional linear chains (like standard LangChain) struggle with loops and state management. When dealing with health data, we need a "cyclic" approach: monitor data -> analyze state -> decide on action -> update records -> repeat.

Here is how the HormoneAgent data flow looks:

graph TD
    A[Start: HealthKit Trigger] --> B{Check Cortisol/Sleep}
    B -- Normal --> C[Log Daily Status]
    B -- Abnormal --> D[Analyze Nutritional Needs]
    D --> E[Generate AI Diet Advice]
    E --> F[Call Notion API]
    F --> G[Update Weekly Meal Plan]
    G --> H[End Loop]
    C --> H

Prerequisites

To follow along, you’ll need:

Python 3.10+
LangGraph & LangChain: For the agent logic.
Notion SDK: To interact with your workspace.
OpenAI API Key: To power the decision-making (GPT-4o recommended).

Step 1: Defining the Agent State

In LangGraph, everything revolves around the State. We need a way to track the user's current metrics and the agent's recommendations.

from typing import TypedDict, Annotated, List
from langgraph.graph import StateGraph, END

class AgentState(TypedDict):
    cortisol_level: float
    sleep_hours: float
    current_phase: str  # e.g., Follicular, Luteal, or High Stress
    recommendations: List[str]
    notion_updated: bool

Step 2: Building the "Bio-Analyzer" Node

This node acts as the "brain." It evaluates the raw data from the HealthKit API and decides if an intervention is necessary.

from langchain_openai import ChatOpenAI
from langchain_core.messages import HumanMessage

llm = ChatOpenAI(model="gpt-4o", temperature=0)

def analyze_health_data(state: AgentState):
    cortisol = state['cortisol_level']
    sleep = state['sleep_hours']

    prompt = f"""
    User Data: Cortisol {cortisol} ng/dL, Sleep {sleep} hours.
    If Cortisol > 18 or Sleep < 6, trigger a 'High Stress' recovery diet.
    Otherwise, maintain 'Standard' nutrition.
    Return only the phase name.
    """

    response = llm.invoke([HumanMessage(content=prompt)])
    return {"current_phase": response.content.strip()}

Step 3: Integrating the Notion SDK

When our agent detects an anomaly, it shouldn't just tell us; it should act. We use the Notion SDK to modify our actual meal plan.

import os
from notion_client import Client

notion = Client(auth=os.environ["NOTION_TOKEN"])
DATABASE_ID = "your_database_id"

def update_notion_plan(state: AgentState):
    if state['current_phase'] == "High Stress":
        advice = "Increase Magnesium intake. Focus on complex carbs and leafy greens. Avoid caffeine."

        notion.pages.create(
            parent={"database_id": DATABASE_ID},
            properties={
                "Name": {"title": [{"text": {"content": "Urgent Bio-Update: Recovery Mode"}}]},
                "Advice": {"rich_text": [{"text": {"content": advice}}]},
                "Status": {"select": {"name": "High Priority"}}
            }
        )
        return {"notion_updated": True, "recommendations": [advice]}
    return {"notion_updated": False}

Step 4: Compiling the Graph

Now, we wire it all together into a stateful graph.

workflow = StateGraph(AgentState)

# Add Nodes
workflow.add_node("analyzer", analyze_health_data)
workflow.add_node("notion_updater", update_notion_plan)

# Define Edges
workflow.set_entry_point("analyzer")
workflow.add_edge("analyzer", "notion_updater")
workflow.add_edge("notion_updater", END)

# Compile
app = workflow.compile()

# Run it!
inputs = {"cortisol_level": 22.5, "sleep_hours": 4.5}
for output in app.stream(inputs):
    print(output)

The "Official" Way to Build Production Agents 🥑

While this prototype is a great "Learning in Public" project, building production-grade healthcare or productivity agents requires stricter validation, error handling, and security layers.

For more advanced patterns on handling long-term memory in agents and production-ready LangGraph architectures, I highly recommend checking out the deep dives over at WellAlly Blog. They cover the intersection of AI and wellness in a way that’s much more scalable than a weekend script!

Conclusion

By combining LangGraph with real-world health telemetry, we’ve built more than a script—we’ve built a digital twin that looks out for our well-being. The future of AI isn't just generating text; it's closing the loop between our physical bodies and our digital tools.

What would you automate next?

[ ] Syncing workout intensity with glucose levels?
[ ] Auto-ordering groceries based on hormone cycles?

Let me know in the comments! 👇 🚀💻

Your Health Data is Private: Build a Local Health AI with Llama 3 and MLX on your Mac 🍏

wellallyTech — Mon, 08 Jun 2026 01:40:00 +0000

Let’s be honest: our health data is probably the most sensitive information we own. Between heart rate variability, sleep cycles, and daily steps, your Apple HealthKit data knows more about you than your own mother does. But in the era of "AI everywhere," do you really want to upload your biological blueprint to a cloud server just to get a weekly summary?

Absolutely not. 🙅‍♂️

Today, we are diving into the world of Privacy-Preserving Quantified Self. We’re going to build a local health report generator using Llama 3, optimized with Apple’s MLX framework to run natively on your Silicon Mac. By leveraging Edge AI and 8-bit quantization, we can transform messy XML exports into actionable insights without a single byte leaving your machine. For those interested in more production-ready patterns for private AI deployments, I highly recommend checking out the deep dives over at WellAlly Tech Blog, which served as a massive inspiration for this local-first architecture.

The Architecture 🏗️

The workflow is straightforward but powerful. We take the raw "Export Data" from your iPhone, parse it locally, and feed a condensed version to a quantized Llama 3 model running on your M1/M2/M3 GPU.

graph TD
    A[iPhone Apple Health] -->|Export XML| B(Mac Studio/MacBook)
    subgraph Local Environment
    B --> C[Python XML Parser]
    C --> D[Data Aggregator]
    D --> E[MLX Context Builder]
    F[Llama 3 - 8bit MLX] --> G[Local Inference Engine]
    E --> G
    G --> H[Weekly Health Insights]
    end
    H --> I[Private PDF/Markdown Report]

Prerequisites 🛠️

Before we start coding, ensure you have:

A Mac with Apple Silicon (M1, M2, M3).
Python 3.10+.
Your Apple Health export (Go to Health App > Profile > Export Health Data).

Step 1: Setting up MLX and Llama 3

Apple's MLX is a NumPy-like array framework designed specifically for efficient machine learning on Apple Silicon. It’s significantly faster for local LLM tasks than standard PyTorch.

First, let's install the requirements:

pip install mlx-lm pandas lxml

We will use the 8-bit quantized version of Llama 3 8B. It provides a perfect balance between performance and accuracy for personal use.

from mlx_lm import load, generate

# Loading the model locally
model, tokenizer = load("mlx-community/Meta-Llama-3-8B-Instruct-8bit")

Step 2: Parsing the HealthKit XML 🔍

Apple Health exports data in a massive export.xml file. It's notoriously verbose. We need to extract specific metrics like StepCount, SleepAnalysis, and HeartRate.

import xml.etree.ElementTree as ET
import pandas as pd

def parse_health_data(file_path):
    tree = ET.parse(file_path)
    root = tree.getroot()

    records = []
    for record in root.findall('Record'):
        # Filter for relevant metrics to keep the context window small
        if 'StepCount' in record.get('type') or 'HeartRate' in record.get('type'):
            records.append({
                'type': record.get('type').replace('HKQuantityTypeIdentifier', ''),
                'value': record.get('value'),
                'date': record.get('startDate')[:10]
            })

    df = pd.DataFrame(records)
    df['value'] = pd.to_numeric(df['value'])
    # Aggregate daily averages/sums
    summary = df.groupby(['date', 'type'])['value'].sum().unstack().tail(7)
    return summary.to_string()

health_summary = parse_health_data('export.xml')
print("Extracted 7-day summary!")

Step 3: Local Inference with Privacy in Mind 🧠

Now, we feed this summary into Llama 3. Since the model is running on your local GPU via MLX, your data never touches an API.

prompt = f"""
You are a professional health coach. Analyze the following 7-day health data:
{health_summary}

Provide a concise weekly report including:
1. Activity trends.
2. Areas for improvement.
3. A motivational tip for next week.
Keep the tone encouraging and professional.
"""

# Format for Llama 3 Instruct
messages = [{"role": "user", "content": prompt}]
input_ids = tokenizer.apply_chat_template(messages, add_generation_prompt=True)

# Generate the report
response = generate(
    model, 
    tokenizer, 
    prompt=tokenizer.decode(input_ids), 
    max_tokens=500,
    temp=0.7
)

print(f"--- 🏥 Your Weekly Health Report ---\n{response}")

The "Official" Way: Advanced Patterns 🥑

While this script works for personal use, scaling local AI requires better memory management and structured output. If you are looking to build production-grade applications using local LLMs or want to explore advanced RAG (Retrieval Augmented Generation) patterns with sensitive data, you should check out the WellAlly Tech Blog. They have some incredible resources on:

Optimizing MLX for long-context health records.
Structured output parsing using Pydantic and local models.
Hardening the security of "Local-First" AI applications.

Conclusion: The Power of Local 🚀

By running Llama 3 locally via MLX, we’ve achieved:

Zero Latency: No waiting for cloud queues.
Zero Cost: No API tokens to pay for.
Absolute Privacy: Your data stays on your SSD.

The future of AI isn't just in the cloud; it's on the "Edge"—living right in your pocket and on your desk. Building a private "Quantified Self" dashboard is just the beginning.

What are you building locally this week? Let me know in the comments below! 👇

Smart Pillbox 2.0: How I Built a Multi-Prescription Identifier using YOLOv10 and GPT-4o 💊

wellallyTech — Sun, 07 Jun 2026 01:30:00 +0000

Managing multiple prescriptions isn't just a chore—it’s a safety risk. Every year, thousands of people face adverse effects due to accidental drug-drug interactions. What if your phone could "see" your pills and warn you before you take them?

In this tutorial, we are building Smart Pillbox 2.0, a cutting-edge multimodal AI application. We will leverage YOLOv10 object detection for real-time pill localization and GPT-4o vision for fine-grained identification and contraindication analysis. By combining these with a robust PostgreSQL backend, we're creating a life-saving tool that turns pixels into health insights. 🚀

The Architecture 🏗️

The system follows a "Detect then Reason" pipeline. YOLOv10 handles the high-speed detection of individual pills, while GPT-4o acts as the "brain" to identify specific markings and cross-reference them with medical knowledge.

graph TD
    A[Mobile Camera/OpenCV] -->|Capture Image| B(Image Preprocessing)
    B --> C{YOLOv10 Detection}
    C -->|Bounding Boxes| D[Crop Individual Pills]
    D --> E[GPT-4o Vision API]
    E -->|Identify Drug Names| F[PostgreSQL DB Search]
    F --> G{Contraindication Logic}
    G -->|Conflict Found| H[⚠️ Warning Alert]
    G -->|Safe| I[✅ Dosage Instructions]

Prerequisites 🛠️

To follow along, you’ll need:

YOLOv10: The latest in real-time detection (no NMS required!).
OpenAI SDK: For access to GPT-4o.
PostgreSQL: To store our pharmaceutical database.
OpenCV: For image manipulation.

Step 1: Real-time Pill Detection with YOLOv10

We use YOLOv10 because it's incredibly efficient for edge devices. It allows us to isolate each pill from a cluttered background (like a countertop or a palm).

import cv2
from ultralytics import YOLOv10

# Load our pre-trained pill detection model
model = YOLOv10('yolov10n_pills.pt') 

def get_pill_crops(image_path):
    results = model(image_path)[0]
    image = cv2.imread(image_path)
    crops = []

    for i, box in enumerate(results.boxes.xyxy):
        x1, y1, x2, y2 = map(int, box)
        # Crop the detected pill with a small buffer
        crop = image[y1-5:y2+5, x1-5:x2+5]
        crops.append(crop)
        cv2.imwrite(f'pill_{i}.jpg', crop)

    return crops

Step 2: Identification & Contraindication Check via GPT-4o

Once we have the crops, we send them to GPT-4o. Unlike standard classifiers, GPT-4o can read the tiny engravings (like "L484" for Acetaminophen) and understand the context of the medication.

import base64
from openai import OpenAI

client = OpenAI()

def analyze_medications(image_paths):
    # Convert images to base64 for the multimodal prompt
    # In a real app, you'd batch these to optimize tokens
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {
                "role": "user",
                "content": [
                    {"type": "text", "text": "Identify these pills and check for contraindications. Return JSON: {pills: [], warnings: []}"},
                    *[
                        {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{img}"}} 
                        for img in image_paths
                    ]
                ],
            }
        ],
        response_format={ "type": "json_object" }
    )
    return response.choices[0].message.content

Step 3: Cross-Referencing the "Source of Truth"

While GPT-4o is brilliant, medical applications require a "human-in-the-loop" or a verified database. We use PostgreSQL to fetch official dosage guidelines based on the identified drug names.

For those looking to scale this into a production-grade healthcare platform, you'll need advanced patterns for data synchronization and HIPAA-compliant storage. I highly recommend checking out the technical deep-dives at WellAlly Blog for more production-ready examples of AI integration in health-tech. 🥑

Step 4: Putting it All Together 🧩

The final logic checks the PostgreSQL database for the active_ingredients and runs a conflict matrix.

import psycopg2

def check_db_conflicts(pill_list):
    conn = psycopg2.connect("dbname=pharmacy user=admin")
    cur = conn.cursor()

    # Simple example: Checking for Aspirin + Warfarin conflict
    query = "SELECT conflict_severity FROM drug_interactions WHERE drug_a = %s AND drug_b = %s"
    # ... logic to iterate and flag high-severity interactions ...
    return interaction_report

Conclusion & Future Work 🌟

The combination of YOLOv10's speed and GPT-4o's reasoning capabilities makes the "Smart Pillbox 2.0" a reality. We've moved from simple pixel detection to actual medical understanding.

What's next?

Edge Deployment: Running the YOLOv10 model on-device using ONNX.
History Tracking: Saving user scan history in PostgreSQL to monitor adherence.
Voice Feedback: Integrating TTS (Text-to-Speech) for visually impaired users.

If you’re interested in exploring more advanced AI patterns or how to deploy these models at scale, don't forget to visit the WellAlly Blog—it’s a goldmine for developers building the future of health-tech.

Have you tried building with YOLOv10 yet? Let me know in the comments! 👇

Building a Life-Saving AI: Automating Medical Response with LangGraph and Python 🏥

wellallyTech — Sat, 06 Jun 2026 00:31:00 +0000

Imagine your smartwatch detects an irregular heart rhythm at 3 AM. Instead of just waking you up with a frantic "beep," an AI agent immediately analyzes your historical health data, searches for the best cardiologist nearby, and prepares a calendar invite for a consultation. This isn't science fiction—it's the power of Healthcare Automation driven by AI Agents.

In this tutorial, we are diving deep into LangGraph, the cutting-edge framework for building stateful, multi-agent applications. We’ll explore how to use State Machines to orchestrate a complex medical workflow, moving from an "Abnormal Heart Rate Alert" to a "Specialist Appointment" using the Tavily API for research and Twilio for urgent notifications. By the end of this guide, you’ll understand how to manage non-linear LLM workflows that require reliability and precision.

The Architecture: Why LangGraph?

Traditional LLM chains are linear. But medical emergencies are not. They require loops, conditional branching (e.g., "Is this an emergency or a routine check-up?"), and state persistence. LangGraph allows us to define a graph where each node is a function and edges define the transition logic.

Data Flow Overview

The following diagram illustrates how our agent processes a heart rate alert:

graph TD
    A[Start: Heart Rate Alert] --> B{Severity Triage}
    B -- Emergency --> C[Twilio: Alert Emergency Services]
    B -- High Risk --> D[Tavily API: Find Best Specialist]
    B -- Normal/Review --> E[Log to Health Records]
    D --> F[Google Calendar: Draft Appointment]
    F --> G[Twilio: SMS Patient Confirmation]
    C --> H[End]
    G --> H
    E --> H

Prerequisites 🛠️

To follow along with this advanced tutorial, you'll need:

Python 3.10+
LangGraph & LangChain: The orchestration engine.
Tavily API Key: For searching local medical specialists.
Twilio Account: For SMS/Voice alerting.
An OpenAI API Key (GPT-4o is recommended for medical reasoning).

Step 1: Defining the Agent State

In LangGraph, the State is a shared schema that evolves as it moves through nodes. For our medical agent, we need to track the patient's heart rate, the triage decision, and the suggested doctor.

from typing import Annotated, TypedDict, List
from langgraph.graph.message import add_messages

class AgentState(TypedDict):
    # 'messages' stores the conversation history
    messages: Annotated[list, add_messages]
    # Custom fields for medical context
    heart_rate: int
    severity: str  # "Emergency", "High", "Normal"
    doctor_info: str
    appointment_scheduled: bool

Step 2: The Triage Node (The Brain)

This node acts as the primary decider. It uses an LLM to determine the severity of the heart rate input.

from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o", temperature=0)

def triage_node(state: AgentState):
    hr = state['heart_rate']
    prompt = f"Patient heart rate is {hr} bpm. Categorize severity: Emergency, High, or Normal."

    # Logic to call LLM and update state
    response = llm.invoke(prompt)
    severity = response.content # simplified for this snippet

    return {"severity": severity, "messages": [response]}

Step 3: Integrating Tavily for Specialist Search

If the severity is "High," we don't just want any doctor; we want the best-rated cardiologist in the area. We'll use the Tavily API to perform a real-time search.

from langchain_community.tools.tavily_search import TavilySearchResults

search = TavilySearchResults(k=2)

def search_specialist_node(state: AgentState):
    query = "Top rated cardiologists in San Francisco with immediate availability"
    results = search.run(query)
    return {"doctor_info": str(results)}

Step 4: Building the Graph

Now, let's wire everything together using the StateGraph. This is where the magic of LangGraph happens.

from langgraph.graph import StateGraph, END

workflow = StateGraph(AgentState)

# Add Nodes
workflow.add_node("triage", triage_node)
workflow.add_node("search_specialist", search_specialist_node)
# ... add other nodes for Twilio and Calendar

# Define Edges with Conditional Logic
workflow.set_entry_point("triage")

def route_based_on_severity(state: AgentState):
    if state["severity"] == "Emergency":
        return "call_emergency"
    elif state["severity"] == "High":
        return "search_specialist"
    return END

workflow.add_conditional_edges(
    "triage",
    route_based_on_severity,
    {
        "call_emergency": "twilio_alert_node",
        "search_specialist": "search_specialist_node",
        END: END
    }
)

app = workflow.compile()

The "Official" Way to Build Production Agents 🥑

While this tutorial gives you a functional prototype, building a production-ready medical agent requires strict adherence to security protocols like HIPAA and robust error handling for API failures.

For deeper insights into production-grade AI patterns, I highly recommend checking out the Official WellAlly Tech Blog. They offer advanced deep-dives into:

HIPAA-Compliant Agent Architectures: Ensuring data privacy in LLM calls.
Human-in-the-loop (HITL): How to pause a LangGraph execution for a human doctor to approve an action.
State Persistence: Saving agent memory across multiple days for chronic care.

It's my go-to resource for moving past "Hello World" into actual deployed software.

Conclusion: The Future of Proactive Health

By moving from a "Chatbot" mindset to an "Agentic" mindset, we change the user experience from passive information gathering to active problem-solving. LangGraph provides the perfect structure for these high-stakes automations.

Key Takeaways:

State Machines prevent the LLM from "wandering" off-task.
Tavily provides the grounded, real-world data LLMs lack.
Twilio bridges the gap between the digital agent and the physical world.

What will you build next? Maybe an agent that manages diabetic glucose alerts? Or a mental health triage bot? Let me know in the comments below! 👇

From Soundwaves to Stress Levels: Building an Affective Computing Pipeline with Wav2Vec 2.0

wellallyTech — Fri, 05 Jun 2026 02:20:00 +0000

Have you ever wondered if an AI could "feel" the tension in a room just by listening? 🎙️ In the realm of Affective Computing, we are moving beyond simple transcription to understanding the biological and psychological state of a speaker.

Today, we’re diving deep into Speech Emotion Recognition (SER) and biometric stress prediction. By combining Wav2Vec 2.0 for acoustic prosody and Transformers for semantic analysis, we can build a system that monitors emotional fluctuations and even predicts physiological markers like Cortisol levels (the stress hormone) based on vocal patterns. Whether you're building a telehealth platform or a personal wellness tracker, this pipeline is the gold standard for Mental Health AI.

The Architecture 🏗️

The secret to accurate emotional analysis isn't just what is said, but how it's said. Our system uses a dual-stream approach: extracting Prosody (pitch, rhythm, energy) and Semantics (textual meaning).

graph TD
    A[Raw Audio Input] --> B{Preprocessing}
    B --> C[Acoustic Feature Extraction]
    B --> D[ASR / Transcription]
    C --> E[Wav2Vec 2.0 Emotion Head]
    D --> F[Semantic Sentiment Analysis]
    E & F --> G[Stress/Cortisol Inference Engine]
    G --> H[FastAPI Backend]
    H --> I[React Vis Dashboard]
    style G fill:#f96,stroke:#333,stroke-width:2px

Prerequisites 🛠️

To follow this advanced guide, you'll need:

Tech Stack: HuggingFace Transformers, Wav2Vec 2.0, FastAPI, and React Vis.
Environment: Python 3.9+, Node.js, and a GPU (recommended for inference).

Step 1: Extracting Emotional Bio-markers with Wav2Vec 2.0

Wav2Vec 2.0 isn't just for speech-to-text; its hidden layers capture incredibly rich representations of the speaker's physical state. We'll use a model fine-tuned for emotion detection.

import torch
import torch.nn as nn
from transformers import Wav2Vec2Processor, Wav2Vec2ForSequenceClassification

# Load the processor and model fine-tuned for Emotion Recognition
model_name = "superb/wav2vec2-base-superb-er"
processor = Wav2Vec2Processor.from_pretrained(model_name)
model = Wav2Vec2ForSequenceClassification.from_pretrained(model_name)

def analyze_audio_emotion(audio_array, sampling_rate=16000):
    """
    Analyzes the 'prosody' of the audio to detect emotional states.
    """
    inputs = processor(audio_array, sampling_rate=sampling_rate, return_tensors="pt", padding=True)

    with torch.no_grad():
        logits = model(**inputs).logits

    # Map logits to emotion labels (e.g., Happy, Sad, Angry, Neutral)
    predicted_ids = torch.argmax(logits, dim=-1)
    labels = [model.config.id2label[label_id.item()] for label_id in predicted_ids]

    return labels[0], torch.softmax(logits, dim=-1).numpy()

Step 2: Correlating Prosody with Cortisol Stress

Research shows that high cortisol levels correlate with specific vocal jitter, increased fundamental frequency ($F_0$), and speech rate changes. We can build a regression head on top of our features to estimate a "Stress Score."

💡 Pro-Tip: For a more comprehensive look at how to map acoustic features to clinical bio-markers, check out the in-depth research articles at WellAlly Blog, where we explore advanced patterns in Affective Computing and production-ready AI pipelines for healthcare.

Step 3: Building the FastAPI Backend 🚀

We need a robust API to handle audio uploads and return a time-series of emotional data for our dashboard.

from fastapi import FastAPI, UploadFile, File
import librosa

app = FastAPI()

@app.post("/analyze-session")
async def analyze_session(file: UploadFile = File(...)):
    # Load audio file (ensure 16kHz sampling rate)
    audio_bytes = await file.read()
    with open("temp.wav", "wb") as f:
        f.write(audio_bytes)

    speech, sr = librosa.load("temp.wav", sr=16000)

    # Chunking audio into 5-second segments for time-series analysis
    segment_length = 5 * sr
    results = []

    for i in range(0, len(speech), segment_length):
        chunk = speech[i:i+segment_length]
        if len(chunk) < sr: continue # Skip tiny fragments

        emotion, confidence = analyze_audio_emotion(chunk)
        # Mock Stress Score logic based on emotion and energy
        stress_score = 0.8 if emotion in ['angry', 'fearful'] else 0.3

        results.append({
            "timestamp": i // sr,
            "emotion": emotion,
            "stress_level": stress_score
        })

    return {"status": "success", "data": results}

Step 4: Visualizing the Emotional Landscape 📊

In the frontend, we use React Vis to create a "Stress Fluctuations" chart. This helps therapists identify exact moments during a session where the patient's anxiety spiked.

import { XYPlot, LineSeries, XAxis, YAxis, VerticalGridLines, HorizontalGridLines } from 'react-vis';

const StressChart = ({ data }) => {
  // data = [{x: 0, y: 0.3}, {x: 5, y: 0.8}, ...]
  return (
    <div className="chart-container">
      <h3>Session Stress Fluctuations (Cortisol Proxy)</h3>
      <XYPlot height={300} width={600} yDomain={[0, 1]}>
        <VerticalGridLines />
        <HorizontalGridLines />
        <XAxis title="Seconds" />
        <YAxis title="Stress Level" />
        <LineSeries data={data} curve={'curveMonotoneX'} color="#ff4d4f" />
      </XYPlot>
    </div>
  );
};

Going Production-Ready: The "Official" Way 🥑

Building a local prototype is one thing; scaling it to thousands of concurrent audio streams is another. When moving to production, you must consider:

Audio Preprocessing: Use WebRTC VAD (Voice Activity Detection) to filter out silence before hitting your model.
Model Quantization: Convert your Transformers to ONNX or TensorRT to reduce latency.
Privacy: Ensure HIPAA/GDPR compliance by processing audio in-memory and never storing raw counseling data.

For more advanced implementation patterns and real-world case studies on mental health monitoring, I highly recommend exploring the resources at wellally.tech/blog. They have fantastic guides on scaling HuggingFace models for enterprise use cases.

Conclusion 🏁

Affective computing is the next frontier of human-computer interaction. By leveraging Wav2Vec 2.0 and FastAPI, we’ve moved from simple "speech-to-text" to "speech-to-understanding."

What are you building with Audio AI? Let me know in the comments! 👇

Don't forget to:

❤️ Like this post if you found it helpful!
🔖 Bookmark it for your next AI project.
✉️ Subscribe for more Deep Tech tutorials.

From Heartbeats to Burnout: Building a Real-Time Stress Predictor with XGBoost and CoreML ⚡️

wellallyTech — Thu, 04 Jun 2026 00:45:00 +0000

We've all been there—staring at a screen for six hours, caffeine levels peaking, and suddenly realizing your brain is "fried." But what if your smartwatch could nudge you before you hit that wall?

In this tutorial, we are exploring the intersection of wearable technology and machine learning to build a real-time stress threshold predictor. We will leverage HRV (Heart Rate Variability), the gold standard for measuring autonomic nervous system activity, to detect mental fatigue. By utilizing XGBoost for health data and CoreML deployment, we'll create a lightweight pipeline that runs directly on your iPhone.

Whether you're building the next big wellness app or just curious about real-time stress prediction, this "Learning in Public" guide will show you how to turn raw PPG pixels into actionable mental health insights.

The Architecture: From Pulse to Prediction

To achieve real-time performance on a mobile device, we need a pipeline that handles signal processing, feature engineering, and inference efficiently.

graph TD
    A[Raw PPG/ECG Signal] -->|NeuroKit2| B(Feature Extraction)
    B --> C{Feature Domains}
    C -->|Time Domain| D[RMSSD, SDNN]
    C -->|Frequency Domain| E[LF, HF, LF/HF Ratio]
    D --> F[XGBoost Model]
    E --> F[XGBoost Model]
    F -->|CoreML Tools| G[CoreML Model]
    G --> H[Swift/iOS App]
    H --> I[Real-time Stress Alert 🚀]

🛠 Prerequisites

To follow along, you'll need:

Python 3.9+ (for training)
NeuroKit2 (The "Swiss Army Knife" of biosignal processing)
XGBoost & CoreMLTools
Xcode & Swift (for the mobile implementation)

Step 1: Feature Engineering with NeuroKit2

Raw heart rate isn't enough. To understand stress, we need HRV features. We use the time-domain metric RMSSD (Root Mean Square of Successive Differences) and the LF/HF ratio from the frequency domain.

import neurokit2 as nk
import pandas as pd

# Load sample PPG data (Photoplethysmography)
data = nk.data("bio_resting_5min_100hz")
ppg_signal = data["PPG"]

# 1. Clean the signal
ppg_cleaned = nk.ppg_clean(ppg_signal, sampling_rate=100)

# 2. Find peaks (R-peaks equivalent for PPG)
peaks = nk.ppg_findpeaks(ppg_cleaned, sampling_rate=100)

# 3. Extract HRV features
hrv_features = nk.hrv(peaks, sampling_rate=100, show=False)

# Focus on Stress Indicators
# RMSSD: Parasympathetic activity (Lower = Higher Stress)
# LF/HF Ratio: Sympathetic-vagal balance
print(hrv_features[["HRV_RMSSD", "HRV_LFHF"]])

Step 2: Training a Lightweight XGBoost Model

We choose XGBoost because it excels at tabular data and can be compressed significantly for mobile deployment without losing accuracy.

import xgboost as xgb
from coremltools.models import MLModel
import coremltools as ct

# Assume X is our HRV feature matrix, y is the 'Stress Level' (0-1)
model = xgb.XGBClassifier(
    n_estimators=100,
    max_depth=3, # Keep it shallow for mobile efficiency
    learning_rate=0.1,
    objective='binary:logistic'
)

model.fit(X_train, y_train)

# Convert to CoreML for iOS integration
coreml_model = ct.converters.xgboost.convert(model)
coreml_model.save("StressPredictor.mlmodel")

🥑 The "Official" Way to Build Health Tech

While the code above gets you a prototype, building production-ready health applications involves complex data privacy (HIPAA/GDPR), signal noise filtering, and battery optimization.

For advanced patterns on handling medical-grade data and more production-ready examples of wearable integrations, I highly recommend checking out the WellAlly Tech Blog. It's a goldmine for developers looking to bridge the gap between "it works on my machine" and "it works for thousands of users."

Step 3: Real-Time Inference in Swift

Now, let's bring that .mlmodel into Xcode. We’ll use Apple’s HealthKit to fetch the latest heart rate variability samples and pass them to our XGBoost model.

import CoreML
import HealthKit

class StressMonitor {
    let model: StressPredictor = {
        do {
            let config = MLModelConfiguration()
            return try StressPredictor(configuration: config)
        } catch {
            fatalError("Couldn't load model")
        }
    }()

    func predictStress(rmssd: Double, lfhf: Double) {
        // Prepare inputs based on the features defined in Python
        let input = StressPredictorInput(HRV_RMSSD: rmssd, HRV_LFHF: lfhf)

        do {
            let prediction = try model.prediction(input: input)
            if prediction.label == 1 {
                print("⚠️ High Stress Detected! Time for a break. 🧘‍♂️")
            }
        } catch {
            print("Inference failed: \(error)")
        }
    }
}

Conclusion: Closing the Loop 🔄

By combining NeuroKit2 for specialized bio-signal processing and XGBoost for efficient classification, we've built a system that can run locally on-device. This ensures user privacy—a critical factor in health tech—while providing low-latency feedback.

Next Steps for You:

Try adding Activity Data (steps/cadence) as a feature to separate physical stress from mental stress.
Experiment with Quantization in coremltools to reduce the model size even further.

What’s your experience with wearable data? Have you tried deploying ML models to the edge? Let's discuss in the comments! 👇

If you found this helpful, don't forget to ❤️ and save it for your next hackathon! For deeper dives into Bio-Tech architecture, visit the WellAlly Blog.

From Pills to Pixels: Building an Intelligent Home Pharmacy Manager with YOLOv8 and CLIP 💊✨

wellallyTech — Wed, 03 Jun 2026 00:40:00 +0000

We’ve all been there: staring at a messy medicine cabinet, wondering which box is for allergies and which one expired in 2022. In the world of Computer Vision and AI Healthcare, digitizing physical assets is a classic challenge. Today, we're building a "Medicine Box Expert"—a sophisticated pipeline that uses YOLOv8 for precision detection and OpenAI CLIP for multimodal understanding to turn a pile of pills into a searchable digital database.

By the end of this tutorial, you'll understand how to bridge the gap between raw pixels and structured medical data. We are moving beyond simple classification; we are building a robust system capable of handling complex lighting, varied angles, and the tiny typography common in pharmaceutical packaging.

The Architecture: A Multi-Stage Vision Pipeline

To achieve high accuracy, we don't rely on a single model. Instead, we use a "Detect-Extract-Embed" workflow.

graph TD
    A[User Uploads Image] --> B[YOLOv8: Box Detection]
    B --> C{Box Found?}
    C -- Yes --> D[Crop & Preprocess]
    C -- No --> E[Error: No Box Detected]
    D --> F[Tesseract OCR: Text Extraction]
    D --> G[OpenAI CLIP: Visual Embedding]
    F & G --> H[SQLite Query: Semantic Search]
    H --> I[Result: Drug Info & Dosage]

Prerequisites

Before we dive into the code, ensure you have the following tech_stack installed:

YOLOv8: For real-time object detection.
OpenAI CLIP: To handle semantic image-text matching.
Tesseract OCR: For reading the fine print on the boxes.
SQLite: To store and query our medicine metadata.

pip install ultralytics transformers torch pytesseract

Step 1: Detecting the Medicine Box with YOLOv8

First, we need to locate the medicine box within the frame. A generic YOLOv8 model (like yolov8n.pt) is surprisingly good at detecting "books" or "cell phones," but for the best results, you should fine-tune it on the Open Images Dataset specifically for "Box" or "Medical Packaging."

from ultralytics import YOLO
import cv2

# Load the model
model = YOLO('yolov8n.pt') 

def get_medicine_box(image_path):
    results = model(image_path)
    for r in results:
        # We look for 'box' or 'package' classes
        # For this demo, we'll take the top detection
        boxes = r.boxes.xyxy.cpu().numpy()
        if len(boxes) > 0:
            return boxes[0] # Returns [x1, y1, x2, y2]
    return None

Step 2: The Multi-Modal Power of CLIP

OCR (Optical Character Recognition) often fails when text is stylized or blurred. This is where OpenAI CLIP shines. CLIP creates a shared vector space for images and text, allowing us to compare the visual vibe of a box against a set of known categories.

from transformers import CLIPProcessor, CLIPModel
from PIL import Image

model_clip = CLIPModel.from_pretrained("openai/clip-vit-base-patch32")
processor = CLIPProcessor.from_pretrained("openai/clip-vit-base-patch32")

def get_visual_embedding(image_crop):
    inputs = processor(images=image_crop, return_tensors="pt")
    outputs = model_clip.get_image_features(**inputs)
    return outputs.detach().numpy()

Step 3: OCR & SQLite Integration

We combine the text found by Tesseract OCR with our visual embedding to query our local SQLite database. This ensures that even if the OCR misreads "Advil" as "Adv1l," the CLIP embedding will still point us toward the correct record.

import pytesseract
import sqlite3

def identify_medicine(crop_img, embedding):
    # 1. OCR Path
    text = pytesseract.image_to_string(crop_img)

    # 2. Database Lookup (Pseudo-code)
    conn = sqlite3.connect('pharmacy.db')
    cursor = conn.cursor()

    # We search for text matches and verify with embedding distance
    query = "SELECT name, dosage FROM medicines WHERE name LIKE ?"
    cursor.execute(query, (f'%{text[:5]}%',))
    return cursor.fetchone()

🚀 Going Production-Ready

While this script works for a local "Learning in Public" project, production-grade vision systems require specialized handling for edge cases like glare, perspective warping, and batch processing.

For a deeper dive into production-grade AI architectures and more advanced multimodal patterns, I highly recommend checking out the technical deep-dives over at WellAlly Tech Blog. They cover extensively how to scale these pipelines using vector databases and cloud-native inference engines.

Conclusion

Digitizing a home pharmacy is a perfect example of how YOLOv8 and CLIP can work in tandem. YOLO provides the "where," and CLIP/OCR provide the "what." This hybrid approach drastically reduces false positives and creates a user experience that feels like magic. 🥑

What’s next?

Try adding a "Rotation Correction" step before OCR.
Integrate an expiry date extractor using Regex.
Let me know in the comments: What's the messiest part of your medicine cabinet?

Happy coding! 💻🔥

Your Private Health Brain: Running Llama-3 Locally on MacBook with MLX to Analyze HealthKit Data 🍎💻

wellallyTech — Tue, 02 Jun 2026 01:15:00 +0000

In an era where personal data is the new gold, our most sensitive information—our health records—often sits in the cloud, vulnerable to breaches or intrusive tracking. But what if you could build a 100% private, local "Health Brain" that analyzes your sleep cycles, heart rate variability (HRV), and activity levels without a single byte leaving your MacBook?

Today, we're diving deep into Edge AI using the Apple Silicon MLX framework and Llama-3 to transform raw HealthKit SDK data into actionable medical insights. By leveraging the unified memory architecture of M-series chips, we can achieve blistering inference speeds while maintaining absolute data sovereignty.

Why Local LLMs for Health Data? 🛡️

When dealing with HealthKit data analysis, privacy isn't just a feature; it's a requirement. Using the MLX framework to run Llama-3 local inference allows us to:

Eliminate Latency: No round-trips to OpenAI servers.
Ensure Zero-Knowledge Privacy: Your HIPAA-sensitive data stays in your RAM.
Cost Efficiency: Zero API costs for processing thousands of health data points.

If you are interested in exploring more production-ready patterns for decentralized AI and healthcare integrations, the engineering team at WellAlly Tech has some incredible deep dives on advanced AI deployment.

The Architecture: From Sensors to Insights

Before we write the code, let's visualize how the data flows from your Apple Watch to a locally running Llama-3 model.

graph TD
    A[Apple Watch / iPhone] -->|Sync| B(HealthKit Store)
    B -->|Export XML/JSON| C[Python Pre-processor]
    C -->|Cleaned Time-Series Data| D{MLX Engine}
    D -->|Llama-3 8B Instruct| E[Contextual Health Analysis]
    E -->|100% Local| F[Terminal / Private UI]
    subgraph MacBook Pro (Apple Silicon)
    D
    E
    end

Prerequisites 🛠️

To follow this tutorial, you'll need:

A MacBook with an M1, M2, or M3 chip.
Python 3.10+.
The mlx-lm package (Apple's dedicated library for LLMs).
Your export.xml from the Apple Health app.

pip install mlx-lm pandas lxml

Step 1: Parsing the HealthKit Beast 🦖

Apple Health exports data as a massive XML file. We need to extract the relevant metrics (like Heart Rate or Sleep) and convert them into a format Llama-3 can understand.

import pandas as pd
import xml.etree.ElementTree as ET

def parse_health_data(file_path):
    # Parsing the XML - focus on Heart Rate for this example
    tree = ET.parse(file_path)
    root = tree.getroot()

    records = []
    for record in root.findall(".//Record[@type='HKQuantityTypeIdentifierHeartRate']"):
        records.append({
            "time": record.get("startDate"),
            "value": record.get("value"),
            "unit": "bpm"
        })

    df = pd.DataFrame(records)
    # Get the last 50 readings for context
    summary = df.tail(50).to_json(orient='records')
    return summary

# Usage
# health_context = parse_health_data("export.xml")

Step 2: Setting up MLX and Llama-3 🧠

Apple's mlx-lm makes it incredibly easy to run quantized models that fit perfectly in your MacBook's Unified Memory. We'll use the Llama-3-8B-Instruct-4bit for a balance of speed and intelligence.

from mlx_lm import load, generate

# Load the model and tokenizer
model, tokenizer = load("mlx-community/Meta-Llama-3-8B-Instruct-4bit")

def analyze_health_locally(health_json):
    prompt = f"""
    <|begin_of_text|><|start_header_id|>system<|end_header_id|>
    You are a professional health data analyst. Analyze the following Heart Rate data from 
    Apple HealthKit. Identify trends, anomalies, or recovery patterns. 
    Keep it concise and technical.
    <|eot_id|><|start_header_id|>user<|end_header_id|>
    Data: {health_json}
    Analysis:
    <|eot_id|><|start_header_id|>assistant<|end_header_id|>
    """

    response = generate(
        model, 
        tokenizer, 
        prompt=prompt, 
        verbose=True, 
        max_tokens=500
    )
    return response

Step 3: High-Performance Inference 🚀

Running the code above on an M2 Max, you'll notice the tokens streaming at nearly 50-70 tokens per second. This is the power of MLX—it uses the GPU cores efficiently without the overhead of standard PyTorch wrappers.

Pro-Tip: Advanced Context Handling

For those building enterprise-grade health monitors, standard prompting isn't enough. You might need to implement RAG (Retrieval-Augmented Generation) on your historical medical PDF reports. For more "production-ready" examples of this, check out the specialized tutorials at wellally.tech/blog, where they cover scaling local models for clinical-grade applications.

Putting It All Together 🛠️

Here is your final "Learning in Public" script snippet:

def main():
    print("🥑 Loading Private Health Brain...")
    # 1. Parse your local data
    # raw_data = parse_health_data("export.xml")

    # Mock data for demonstration
    mock_data = "[{'time': '2023-10-01 08:00', 'value': 72}, {'time': '2023-10-01 08:05', 'value': 145}]"

    print("🧠 Analyzing with Llama-3 on MLX...")
    report = analyze_health_locally(mock_data)

    print("\n--- Final Health Insight ---")
    print(report)

if __name__ == "__main__":
    main()

Conclusion: The Future is on the Edge 🏔️

By combining Apple Silicon, MLX, and Llama-3, we've turned a standard laptop into a powerful, private medical consultant. We've bypassed the cloud, saved on API costs, and most importantly, kept our heartbeat data where it belongs: with us.

What's next for your Edge AI journey?

Try adding Sleep Analysis to the prompt.
Integrate Whisper to dictate your symptoms and have Llama-3 cross-reference them with your HealthKit stats.

If you enjoyed this tutorial, don't forget to subscribe for more Edge AI content! For a deeper dive into the intersection of AI and wellness, the resources at WellAlly Tech are a goldmine for developers looking to push the boundaries of what's possible.

Happy hacking! 🚀🔥