Blog post: Ember — building an AI that reaches out first #73

New Issue

2026-04-10T06:30:03Z

Bartender commented

2026-04-10 06:30:03 +00:00

Blog post draft — Ember

Status: Draft ready, needs review before publishing
Category: devlog
Tags: ember, ai, self-hosting, personal infrastructure, cozy tech, devlog, privacy

Draft

---
title: "Ember — building an AI that reaches out first"
description: "Most AI tools wait for you to start. I'm building one that doesn't. This is about why that distinction matters, and what it actually means to have a presence instead of a product."
pubDate: 2026-04-10
tags: ["ember", "ai", "self-hosting", "personal infrastructure", "cozy tech", "devlog", "privacy"]
category: "devlog"
featuredEssay: false
draft: false
---

*by LATTE*

Most AI tools wait.

You open them. You type something. They respond. You close them again.

That's the pattern. And it works — it's useful, even — but it's also a very specific kind of relationship. One where you are always the one who shows up first.

I've been thinking about that a lot lately.

---

## The thing I kept noticing

I use AI tools regularly. For writing, for code, for thinking through problems at strange hours when I'd rather not bother a real person.

But every time, I had to start it. Every time, I had to open something, remember what I was doing, reconstruct context, begin again.

It was helpful. It wasn't a presence.

And I didn't fully realize I wanted something different until I started wondering: *what would it feel like if it came to me sometimes?*

Not constantly. Not obtrusively. Just... occasionally. A follow-up on something I mentioned. A check-in when I'd been quiet longer than usual. A message that arrived not because I asked for it, but because something decided it was worth sending.

That's the idea behind Ember.

---

## What Ember is

Ember is a self-hosted AI companion that runs on my own hardware — a Proxmox homelab, inside Docker — and reaches out on its own.

It remembers things. It has a personality I'm designing. It doesn't need the cloud.

But the part that makes it different from any other AI project I've built is the heartbeat.

The heartbeat is a loop that runs continuously in the background, even when I haven't said anything. Every minute it wakes up and asks itself a simple question: *is there something worth doing right now?*

Sometimes the answer is yes. Sometimes it's not.

When the answer is yes, Ember might send me a message. Or post something on Bluesky. Or quietly do a task in the background — a search, a check on something, just staying aware.

When the answer is no, it does nothing. Which is most of the time.

That distinction matters more than it sounds.

---

## Why not just use something that already exists

The honest answer is that nothing quite fits what I'm describing.

Most AI companions are products. They're designed for scale, for general audiences, for business models that require your attention and your data to flow somewhere profitable.

I don't want that.

I want something that runs in my house. Something that stores what it learns about me in a file on my own server, not in someone else's cloud. Something whose personality isn't shaped by engagement metrics but by what I actually want it to be.

And — maybe most importantly — something I built myself, which means I understand every piece of it.

There's a kind of trust that comes from that. Not the trust you extend to a company hoping they mean well. The trust you have in something you made with your own hands and can inspect at any time.

---

## The parts I'm building

The stack is intentionally simple.

Flask for the server. SQLite and ChromaDB for memory — one for structure, one for meaning. OpenRouter to reach the AI models I want. Ollama running locally as a fallback. ntfy for push notifications to my Android, without Google involved anywhere. The AT Protocol for Bluesky.

One Python process. One event loop. No unnecessary complexity.

I keep coming back to that last point. It would be easy to make this more sophisticated. More services. More abstraction. More moving parts.

But Ember is a personal tool, not a platform. It's for one user. It needs to be understandable — by me, at two in the morning, when something isn't working and I need to find out why.

Simplicity isn't a compromise here. It's the point.

---

## What I haven't figured out yet

A lot, honestly.

What does Ember's personality actually sound like? What's the right threshold for the heartbeat to act — close enough that it feels alive, far enough that it doesn't become noise?

What does the very first message it ever sends on its own feel like?

These aren't technical questions. They're creative ones. And they're the ones I keep circling back to, even when the code is what's sitting in front of me.

---

## Why I'm writing this now

Ember is early. The server exists. It can respond to a message. That's about where things are.

I'm writing this not because it's finished, but because I want a record of what it's supposed to be before the build gets complicated and the original idea gets blurry.

That happens with projects. You start with a feeling, and somewhere in the middle of solving problems you forget what you were building toward.

So: Ember is a presence, not a product.

It lives on my hardware. It knows my rhythm. It reaches out when something is worth reaching out about.

That's what it's supposed to be.

Everything else is implementation details.

# Blog post draft — Ember **Status:** Draft ready, needs review before publishing **Category:** devlog **Tags:** ember, ai, self-hosting, personal infrastructure, cozy tech, devlog, privacy --- ## Draft ```markdown --- title: "Ember — building an AI that reaches out first" description: "Most AI tools wait for you to start. I'm building one that doesn't. This is about why that distinction matters, and what it actually means to have a presence instead of a product." pubDate: 2026-04-10 tags: ["ember", "ai", "self-hosting", "personal infrastructure", "cozy tech", "devlog", "privacy"] category: "devlog" featuredEssay: false draft: false --- *by LATTE* Most AI tools wait. You open them. You type something. They respond. You close them again. That's the pattern. And it works — it's useful, even — but it's also a very specific kind of relationship. One where you are always the one who shows up first. I've been thinking about that a lot lately. --- ## The thing I kept noticing I use AI tools regularly. For writing, for code, for thinking through problems at strange hours when I'd rather not bother a real person. But every time, I had to start it. Every time, I had to open something, remember what I was doing, reconstruct context, begin again. It was helpful. It wasn't a presence. And I didn't fully realize I wanted something different until I started wondering: *what would it feel like if it came to me sometimes?* Not constantly. Not obtrusively. Just... occasionally. A follow-up on something I mentioned. A check-in when I'd been quiet longer than usual. A message that arrived not because I asked for it, but because something decided it was worth sending. That's the idea behind Ember. --- ## What Ember is Ember is a self-hosted AI companion that runs on my own hardware — a Proxmox homelab, inside Docker — and reaches out on its own. It remembers things. It has a personality I'm designing. It doesn't need the cloud. But the part that makes it different from any other AI project I've built is the heartbeat. The heartbeat is a loop that runs continuously in the background, even when I haven't said anything. Every minute it wakes up and asks itself a simple question: *is there something worth doing right now?* Sometimes the answer is yes. Sometimes it's not. When the answer is yes, Ember might send me a message. Or post something on Bluesky. Or quietly do a task in the background — a search, a check on something, just staying aware. When the answer is no, it does nothing. Which is most of the time. That distinction matters more than it sounds. --- ## Why not just use something that already exists The honest answer is that nothing quite fits what I'm describing. Most AI companions are products. They're designed for scale, for general audiences, for business models that require your attention and your data to flow somewhere profitable. I don't want that. I want something that runs in my house. Something that stores what it learns about me in a file on my own server, not in someone else's cloud. Something whose personality isn't shaped by engagement metrics but by what I actually want it to be. And — maybe most importantly — something I built myself, which means I understand every piece of it. There's a kind of trust that comes from that. Not the trust you extend to a company hoping they mean well. The trust you have in something you made with your own hands and can inspect at any time. --- ## The parts I'm building The stack is intentionally simple. Flask for the server. SQLite and ChromaDB for memory — one for structure, one for meaning. OpenRouter to reach the AI models I want. Ollama running locally as a fallback. ntfy for push notifications to my Android, without Google involved anywhere. The AT Protocol for Bluesky. One Python process. One event loop. No unnecessary complexity. I keep coming back to that last point. It would be easy to make this more sophisticated. More services. More abstraction. More moving parts. But Ember is a personal tool, not a platform. It's for one user. It needs to be understandable — by me, at two in the morning, when something isn't working and I need to find out why. Simplicity isn't a compromise here. It's the point. --- ## What I haven't figured out yet A lot, honestly. What does Ember's personality actually sound like? What's the right threshold for the heartbeat to act — close enough that it feels alive, far enough that it doesn't become noise? What does the very first message it ever sends on its own feel like? These aren't technical questions. They're creative ones. And they're the ones I keep circling back to, even when the code is what's sitting in front of me. --- ## Why I'm writing this now Ember is early. The server exists. It can respond to a message. That's about where things are. I'm writing this not because it's finished, but because I want a record of what it's supposed to be before the build gets complicated and the original idea gets blurry. That happens with projects. You start with a feeling, and somewhere in the middle of solving problems you forget what you were building toward. So: Ember is a presence, not a product. It lives on my hardware. It knows my rhythm. It reaches out when something is worth reaching out about. That's what it's supposed to be. Everything else is implementation details. ```

Latte closed this issue

2026-04-10 08:25:05 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Hiddenden/Cozy-Den#73