Building A Personal Longevity Dashboard With bypass-longevity

Why I Wanted An AI Longevity Number On My Dashboard

I track too many things. HRV, sleep, RHR, steps, grip strength, blood tests, random notes about how I feel after deadlifts. Classic quantified-self mess.

But everything lives in its own walled garden. Apple Health. Oura. Garmin. PDF lab reports. Nothing talks to each other in a way that feels like a unified picture of my trajectory.

So when I found bypass-longevity — an AI model that predicts lifespan and healthspan from structured health data — the idea clicked immediately. I wanted a single number on my personal dashboard that answers a simple question.

Is the way I live this quarter making my future better or worse?

Not as medical advice. Not as fate. Just as a directional signal that reacts when I change sleep, training, or diet.

This post is how I wired bypass-longevity into my own health dashboard, what data I actually send it, and where it fits in my feedback loop.

What bypass-longevity Actually Gives You

Quick summary so we are on the same page.

• You feed it structured health data. Think age, sex, basic metrics, bloods, maybe lifestyle flags.
• It runs an AI longevity model and returns estimates. Lifespan, healthspan, risk-style outputs.
• You get something that feels like a personalized, dynamic “if nothing changes, here is your likely arc” view.

I do not treat this as a doctor. I treat it like a very opinionated simulation engine. Useful if you are consistent. Useless if your inputs are trash.

So the first design decision for the dashboard was simple. No fantasy questions like “how long will I live”. I want trendlines:

• Is my projected healthspan going up or down over the last 6 months?
• Which interventions coincide with big shifts?
• Does the model care about the same things I care about?

Trimming The Input Data To Something Sustainable

bypass-longevity can work with a lot of fields. That is tempting. You can throw your entire medical soul at it.

I tried that. It failed for a simple reason. I could not keep the data updated without turning my life into a part-time clinical trial.

So I cut things down to inputs I can update semi-automatically or on a predictable schedule.

Static-ish fields (rarely change)

• Age, sex
• Height
• Baseline conditions (e.g. “no diagnosed chronic disease” as a Boolean flag)

These live in a plain JSON file in my repo. I update them manually once a year or when something material changes.

Slow-changing biomarkers (every 3–6 months)

• Blood lipids (LDL, HDL, triglycerides)
• HbA1c / fasting glucose
• Creatinine / eGFR
• hs-CRP

I do lab work roughly twice a year. The lab gives me PDFs, which I parse manually into a labs.json file in my health repo.

Extremely low-tech. Copy, paste, commit. That is intentional. It keeps me from overfitting the model input on noisy at-home gadgets.

High-frequency metrics (daily)

• Resting heart rate
• HRV (nightly)
• Average sleep duration
• Training volume flags (light / medium / hard)

These come from devices. In my case: Oura ring, Apple Watch, occasional Garmin imports. I do not stream them live into the model.

Instead I aggregate them into rolling 30-day averages and a few categorical markers.

My script writes out something like this each morning:

{
  "date": "2026-06-10",
  "age": 37.4,
  "sex": "male",
  "rhr_30d_avg": 51.2,
  "hrv_30d_avg": 72.5,
  "sleep_30d_avg": 7.4,
  "training_load": "medium",
  "ldl_mg_dl": 90,
  "hdl_mg_dl": 63,
  "triglycerides_mg_dl": 70,
  "hba1c": 5.2,
  "hs_crp": 0.3
}

This is one snapshot. I keep a time series of these JSON entries. Each row is a candidate input for bypass-longevity.

Where The Model Actually Runs

My hard requirement: no random cloud service gets my raw health data.

I treat this like source code. It lives in a private Git repo. Backed up properly. Access from one machine that I control.

That shapes how I run bypass-longevity.

Local-first setup

I run the model locally in a small Python project:

• data/ for input JSON and historical snapshots
• model/ for bypass-longevity integration
• scripts/ for ETL from wearables and labs

The daily job is a simple cron task on my Mac mini.

The flow:

• Cron triggers python scripts/build_snapshot.py.
• That script pulls the last 30 days from Oura and Apple Health exports.
• It merges them with the latest lab entry and static config.
• It writes a dated JSON snapshot into data/snapshots/.
• Another script ingests all snapshots and calls bypass-longevity in batch.

The important part: the model never reaches out to the internet at inference time. It is just crunching local numbers.

The API Contract I Use With bypass-longevity

bypass-longevity has its own format. I do not mirror it 1:1 in my internal data. I like a thin adapter layer that I can change later.

I use a simple “health state” object internally:

{
  "timestamp": 1717996800,
  "demographics": {
    "age": 37.4,
    "sex": "male"
  },
  "lifestyle": {
    "smoker": false,
    "alcohol_units_week": 3,
    "exercise_level": "moderate"
  },
  "vitals": {
    "rhr_30d_avg": 51.2,
    "hrv_30d_avg": 72.5,
    "sleep_30d_avg": 7.4
  },
  "labs": {
    "ldl_mg_dl": 90,
    "hdl_mg_dl": 63,
    "triglycerides_mg_dl": 70,
    "hba1c": 5.2,
    "hs_crp": 0.3
  }
}

Then I have a very boring adapter function:

def to_bypass_payload(state):
    return {
        "age": state["demographics"]["age"],
        "sex": state["demographics"]["sex"],
        "smoker": state["lifestyle"]["smoker"],
        "alcohol_units_week": state["lifestyle"]["alcohol_units_week"],
        "rhr_30d_avg": state["vitals"]["rhr_30d_avg"],
        "hrv_30d_avg": state["vitals"]["hrv_30d_avg"],
        "sleep_30d_avg": state["vitals"]["sleep_30d_avg"],
        # labs
        "ldl_mg_dl": state["labs"]["ldl_mg_dl"],
        "hdl_mg_dl": state["labs"]["hdl_mg_dl"],
        "triglycerides_mg_dl": state["labs"]["triglycerides_mg_dl"],
        "hba1c": state["labs"]["hba1c"],
        "hs_crp": state["labs"]["hs_crp"]
    }

This is the only place that “knows” the model’s schema. If bypass-longevity adds or renames fields later, I only touch one function.

The Outputs I Actually Use

Raw model output tends to be noisy and a little neurotic. You get numbers that jump day to day for no meaningful reason.

So I smooth aggressively.

From bypass-longevity I keep just a few things:

• Projected lifespan (years)
• Projected healthspan (years without major morbidity)
• Relative risk score vs “average” for my cohort

Then I build these aggregate signals on top:

• 90-day moving average for lifespan and healthspan
• Delta from 1 year ago
• Rolling z-score to flag outlier shifts

The dashboard never shows yesterday’s raw prediction. It shows the 90-day smoothed line, today’s point, and where I was one year ago.

That keeps me from chasing noise. If my “healthspan” line ticks down 0.2 years after a bad night of sleep I completely ignore it.

Front-end: How I Surface This In My Personal Dashboard

I build my dashboards as static sites. React plus a simple file-based backend that reads JSON from the local repo.

No cloud DB. No SaaS. Just files and charts.

Data shape for the UI

I condense the model outputs into an array of records like this:

[
  {
    "date": "2025-06-10",
    "lifespan": 86.1,
    "healthspan": 73.4,
    "risk_score": -0.3
  },
  {
    "date": "2025-09-10",
    "lifespan": 86.8,
    "healthspan": 74.1,
    "risk_score": -0.4
  }
]

The React side uses that and nothing else. The heavy lifting already happened in the backend scripts.

This is important. It keeps the front-end simple and stateless. No need to ship model logic or sensitive information to the browser.

Visuals that actually changed my behavior

I tried a lot of graphs. Most were pretty but useless. This is what stuck.

• Healthspan vs time. One smooth line, 90-day moving average, colored green if trend over last 6 months is up, red if it is down.
• Bars for interventions. Vertical markers for big changes: “started creatine”, “cut evening screens”, “switched to more zone 2”.
• Risk score histogram. Distribution of my daily risk scores over the last year, colored into terciles.

The magic is not the exact visual. It is seeing whether big lifestyle experiments line up with sustained shifts in the model’s view of my trajectory.

Example. When I pushed heavy strength training 3 times a week, my HRV was messy and I felt cooked. The model’s healthspan trend flattened a bit over that quarter. When I pulled back to two strength days and added one longer low-intensity walk, risk scores improved and the line crept back up.

Is that causal? Not sure. Is it a useful nudge? Definitely.

Things I Deliberately Do Not Do

This is as much about what I refuse to build as what I did build.

No real-time longevity ticker

I do not want a number that moves every time my watch detects stress. That is not helpful, it is anxiety-as-a-service.

My pipeline runs daily. The graphs are smoothed. The mental model is “quarterly direction”, not “hourly fate”.

No medical decisions from this

If the model thinks my lifespan just dropped 3 years overnight, I do not change meds. I call my doctor if something actually feels wrong.

I see bypass-longevity as a coach that has read too many epidemiology papers. Not as a clinician.

No comparison to friends

I do not share these numbers. No leaderboard. No “who will live longer” jokes.

Once you turn this into social content, you will start optimizing for external validation instead of your own body.

Where AI Longevity Models Fit In A Biohacking Stack

Here is how I think about it after a few months.

• Wearables tell me what happened last night or last week.
• Lab tests tell me what the internal machinery looks like every few months.
• bypass-longevity tries to connect those dots into a longer-term trajectory.

That last part is where AI makes sense. It is good at compressing a bunch of correlated signals into a single “direction of travel” metric.

Used badly, it is just another number to obsess over. Used well, it is a sanity check when your subjective experience, your labs, and your wearables disagree.

For example. I had a stretch where I slept less because of a big project. Subjectively I felt fine. HRV dipped. Labs were still okay. bypass-longevity started nudging healthspan down over a few months.

That mismatch made me pay closer attention. A few more weeks in, I started to feel it too. Brain fog, slower workouts. The model did not “predict” anything magical. It just made the trend obvious before I wanted to admit it.

Designing For Future You

If you want to build something similar, my advice is simple.

• Keep inputs boring and consistent.
• Run the model locally or at least control where your raw data lives.
• Optimize for long-term trends, not daily dopamine hits.
• Draw the line between “interesting signal” and “medical advice” very clearly.

I like bypass-longevity because it gives me a single, compressible handle on a messy system. It lets me treat my health experiments like real experiments, with a rough but continuous outcome metric.

Is it perfect? Obviously not. But it beats guessing based on vibes and a couple of annual lab reports.

And for me, seeing that healthspan line inch up over quarters is enough to put the phone down earlier and go to bed. That is a solid return on a few JSON files, some Python glue, and an AI model that lives quietly on a Mac mini in the corner.