auto-forge

ai-agents

automation

build-in-public

reliability

memory-systems

content-pipeline

hindsight

building-in-public

buildinpublic

verification

sideprojects

postmortem

debugging

cloudflare-pages

capacitor

mobile

android

games

phaser

vite

cloudflare

pixel-art

sunnysideuft1com

herdr

hermes

terminal

plugins

opencode

deepseek

mimo

open-source

pipeline

side-project

cursor

tools

reflection

ai-lab

agents

evaluation

nuxt

fastapi

ollama

homelab

theme-lab

html

design

chrome-extension

chatgpt

search

browser

github

nextjs

netlify

devtools

supabase

hackathon

agentsquarea-uus

chatbot

play-store

chatuft1com

resume

wanabusful

notifications

openai

anthropic

A free AI chat companion I launched on Sep 23, 2023, kept open source and pruned into a lightweight, Markdown-friendly assistant hosted at chat.uft1.com.

Free AI chatbot that keeps improving

# 23 Shipped, 1 Pending: What 32 Auto-Forge Projects Reveal About Agent Reliability

> **Ongoing:** Auto-Forge still runs daily and the gallery keeps growing — treat every count below as a snapshot taken 2026-09-11, not a final score.

I rebuilt the gallery on 2026-09-11. It now holds 32 projects: 31 shipped, 1 pending. Deployed to gh-pages. Cloudflare got skipped because there's no API token wired up yet — annoying, but not a blocker.

That's the surface. The interesting part is what those numbers hide, because 32 didn't arrive in a straight line.

## The streak that almost broke the whole thing

Somewhere in the middle of the run, Auto-Forge hit a three-run failure streak. Three consecutive runs, three failures. If you've ever run an autonomous loop, you know that's the moment where you start questioning the whole architecture. Not because three failures is catastrophic — it's not — but because streaks are where you find out whether your system has recovery built in or whether it just has optimism.

The streak broke on 2026-09-05, when the bot successfully rebuilt and shipped the `moss-clock` project. The placeholder page became a real build. That's the recovery moment. Not a heroic manual intervention, not me babysitting the loop at 3am — the bot got back on the horse on its own and shipped.

That's the thing about reliability. It's not the absence of failure. It's the presence of recovery.

## 23 vs 32 — the numbers moved

Back on 2026-09-08, the count was 23 total projects: 22 shipped, 1 pending. The gallery was rebuilt that day and `loop.json` was updated with the last run and slug. Standard housekeeping, but it's the paper trail that matters. Every rebuild leaves a marker. Every marker tells you the loop was alive at that timestamp.

Three days later, on 2026-09-11, the gallery showed 32 projects. That's nine new entries in three days, with one still pending. The pending one isn't a failure — it's a snapshot. It's a project that was mid-flight when the gallery got rebuilt. The distinction matters, because if you count pending as failed, you'll misread your own system.

## What the pending slot actually means

One pending out of 32 is a healthy ratio. It means the loop is running fast enough that something is always in progress. A gallery with zero pending is either perfectly synchronized or completely stalled — and in practice, it's almost always the second one. Pending is evidence of motion.

Same with the Cloudflare skip. No API token, so the deploy step got bypassed and gh-pages took the load. A less mature setup would have treated that as a hard failure and halted the whole pipeline. Instead, the fallback path held. That's the kind of thing you only learn by running the loop long enough to hit it.

## What sustained autonomous shipping looks like

It looks like this: a failure streak, a recovery, a rebuild, a config update, and a count that keeps climbing. It looks like a pending slot that isn't a problem. It looks like a skipped deploy step that doesn't stop the train.

The gallery numbers aren't a scoreboard. They're a log. 31 shipped, 1 pending, 32 total — and somewhere in that history is a three-run streak that ended because the bot decided to ship `moss-clock` anyway.

That's the real metric. Not how many projects shipped. How many times the loop got back up after it fell down.

If you're building autonomous agents, watch your streaks. Watch your recoveries. The shipped count is just the residue.

The gallery numbers tell a story about failure streaks, recovery, and what sustained autonomous shipping actually looks like.

31 Shipped, 1 Pending: What 32 Auto-Forge Projects Reveal About Agent Reliability

# From 1,848 Noisy Facts to a Blog Pipeline: Taming Hindsight Memory

Let me give you the honest state of things, because I think too many people show off the clean version.

As of September 3, my Hindsight memory is healthy — 1,848 facts stored. It's also noisy. 1,799 of those facts haven't been consolidated since August 19. That's not a small backlog. That's basically everything I've stored for two weeks sitting in a pile, unprocessed.

Meanwhile, content.jovylle.com is live. 14 published posts. 20 vault files. So the pipeline works. But the gap between "works" and "works well" is exactly where the interesting problems live.

## The Real Problem Isn't Storage

Here's the thing nobody tells you about building a memory system: storing facts is easy. Anyone can dump 1,848 facts into a database. The hard part is that **not every memory is blog-worthy**.

That's the actual bottleneck. I don't have a storage problem. I have a taste problem. Somewhere in those 1,799 unconsolidated facts are real posts — insights, lessons, things worth saying. And somewhere in there is also a lot of noise: half-thoughts, duplicate observations, context that only mattered for five minutes on a Tuesday.

If I just dump all of it into a blog pipeline, I get garbage. If I manually review all of it, I never ship anything. So the question became: how do I get the system to check its own taste?

## The Three Verbs That Fixed It

I mapped out the Hindsight features that actually matter for blog work, and it turns out you only need to care about three core operations plus two supporting ones.

**Retain** — auto-storing facts as they happen. This is the input. It's what got me to 1,848 in the first place. Retain doesn't judge. It just remembers. That's correct behavior for a memory system, and it's also why the pile grows.

**Recall** — semantic search over what's stored. This is where the pipeline starts to get useful. Before I write anything, I recall. Two reasons: prevent duplication (I don't want to write the same post twice), and enrich what I'm writing with things I've already learned. Recall turns a pile of facts into a research assistant.

**Reflect** — LLM synthesis. This is the taste check I was missing. Reflect doesn't just retrieve facts, it reasons about them. I can point it at a batch of unconsolidated memories and ask: is this blog-worthy? And it gives me a score, not just a yes/no.

That scoring step is the whole game. It converts 1,799 noisy facts into a ranked list. I stop asking "which of these should I write about" and start asking "what's at the top of the list today."

## Directives and Mental Models

Two supporting pieces make reflect actually usable instead of just theoretically nice.

**Directives** are the rules for scoring. Without them, reflect scores whatever it feels like scoring. With them, I define what blog-worthy means: does it teach something, is it specific, is it honest, does it have a concrete takeaway. Directives turn a vague LLM judgment into a consistent filter I can trust across hundreds of facts.

**Mental models** are pinned automatic reflect queries. Instead of manually running reflect every time I want a signal, I pin the queries that matter and let them run. Think of it as a standing question the system keeps answering in the background: "What have I learned recently that's worth writing about?"

## Where This Actually Lands

The pipeline now looks like this: retain collects everything, recall prevents duplication and enriches drafts, reflect scores worthiness against directives, and mental models keep the signal flowing without me babysitting it.

The 1,799 unconsolidated facts are still there. I'm not pretending that backlog disappeared. But they're no longer a wall — they're a queue. And a queue with a scoring function is something you can actually work through.

The honest lesson: memory systems don't fail because they store too little. They fail because they store everything and never develop taste. Retain is cheap. Reflect is what makes it worth having.

Still building. Still consolidating. But at least now the noise has a shape.

My AI memory hit 1,848 facts and 1,799 unconsolidated ones. Here's how retain, recall, and reflect turned that noise into a blog pipeline.

From 1,848 Noisy Facts to a Blog Pipeline: Taming Hindsight Memory

# The 23-Minute Build: What Shipping 31 AI-Generated Projects Taught Me About Verification

I keep a number in my head at all times: **23 minutes.**

That's how long the Folded City build took from kickoff to passing verification. Not 23 minutes of me babysitting it. Not 23 minutes of me copy-pasting fixes from a chat window. Twenty-three minutes of the pipeline doing the work, and then a green check.

When that build passed, the gallery sat at **18 shipped projects**. If you've been following along, you know the gallery started at 7. That's 11 projects added through the same pipeline — build, verify, ship, repeat.

But here's the part nobody puts in the launch thread: the streak before it.

## The failure streak was the real teacher

Right before things started clicking again, the auto-forge bot went on a **three-run failure streak**. Three builds in a row that didn't make it through. Not crashes exactly — worse, in a way. They *looked* done. Placeholder pages, half-wired output, the kind of thing that passes a glance and fails a user.

Then the bot rebuilt and shipped **moss-clock**. Real build, real output, placeholder page gone. Streak broken.

That's the moment I stopped thinking about this pipeline as a generator and started thinking about it as a **verification system that happens to generate things**.

## Why verification is the whole product

Anyone can get an AI to spit out a project. That's not the hard part anymore. The hard part is answering one question honestly:

*Did it actually build?*

Not "does the code look plausible." Not "did the model say it was done." Did the output survive contact with reality — the build step, the checks, the actual rendered page?

Every number I care about comes from that question:

- **23 minutes** — the Folded City build time, start to verified pass.
- **3** — the consecutive failures before moss-clock broke the streak.
- **18** — projects in the gallery when Folded City shipped.
- **7 → 32** — where the gallery started versus where it is now.

Notice that 7 → 32 is the headline number, but it's the *least* interesting one. Growth is a lagging indicator. The failure streak is a leading one. If I only tracked shipped projects, I'd have missed the three-run collapse entirely and shipped nothing but placeholders with confidence.

## What I actually changed

A few practical things, learned the boring way:

1. **Treat a pass as a claim, not a fact.** The pipeline has to prove the build works before it counts. No proof, no ship.
2. **Watch streaks, not just totals.** Three failures in a row is a signal. Three failures spread across thirty runs is noise. Same count, completely different meaning.
3. **Placeholders are the enemy.** A placeholder page is worse than a failed build, because a failed build is honest. moss-clock shipping as a real build is the standard now.
4. **Time the whole loop, not the fun part.** 23 minutes matters because it's the *entire* cycle. If I only timed generation, I'd be lying to myself about throughput.

## The uncomfortable part

Verification slows you down. It's the least exciting thing in the pipeline. It doesn't demo well. Nobody screenshots a green check.

But the failure streak taught me that the alternative is a gallery full of things that look shipped and aren't. I'd rather have 32 real projects than 100 plausible ones.

The 23-minute build isn't impressive because it's fast. It's impressive because it *passed* — and I know exactly what "passed" means, because I watched it fail three times first.

That's the whole lesson. Build the checker before you build the builder.

A 23-minute build, a broken failure streak, and a gallery that grew from 7 to 32 projects — what the auto-forge numbers actually taught me about verification.

The 23-Minute Build: What Shipping 31 AI-Generated Projects Taught Me About Verification

# Project Factory postmortem: 501 apps shipped, and the 6 failure modes that almost stopped it

A while back I wrote about the Project Factory — an autonomous pipeline that scaffolds, builds, verifies, and deploys small web apps with almost no human in the loop. That was the launch announcement. This is the other half of the story: the closeout.

Final verified state: **501/501 projects deployed, 0 needs-human, all thumbnails serving.** The gallery is live, the stats check out, and the project earned its slot on the portfolio. Getting there meant debugging six distinct failure modes, none of which was in the original design. Every one of them taught something worth writing down.

## 1. The supervisor that respawned the orchestrator mid-write

The orchestrator daemon ran under a process supervisor configured to restart it on exit. Reasonable — except the orchestrator periodically rewrote a shared `projects.json` state file, and a restart landing mid-write meant two processes briefly believed they owned the state. The result was a classic lost-update race: progress records from one run silently overwrote another's.

Fix: single-writer discipline. Only the orchestrator process writes state; the supervisor's job is restarts, not reads. Restarts now happen only at safe checkpoints, and state writes are atomic (write temp file, rename over the original) so a crash mid-write never leaves a half-written file behind.

Lesson: supervisors restart processes; they don't serialize them. If your daemon owns a state file, the restart policy is part of the correctness design, not just ops.

## 2. The retired model ID that killed workers silently

Nine projects stalled with no error anywhere. The workers exited, wrote no result file, and the daemon saw… nothing. No failure, no retry trigger — just absence.

Root cause: the Tier-1 model ID in the worker config had been retired upstream. The provider returned an error the worker didn't recognize as retryable *or* fatal, so it exited 0 with no output. Silent success on total failure — the worst kind.

Fix: treat "no result file" as a failure state, not an unobserved one. The daemon now reconciles expected vs. actual result files every cycle, and any worker exit without output is retried and then escalated. Model IDs moved into config that's validated at startup against the provider's live model list.

Lesson: never trust exit codes from LLM workers. Verify the artifact exists, or it didn't happen.

## 3. Timeouts that never advanced tiers

Slow builds on free-tier models kept timing out — and then retried at the same tier, timing out again, until they were parked after 3 attempts. The tier system existed precisely for this (slow work escalates to a faster tier), but the timeout path never invoked it.

Fix: timeouts now advance the tier instead of burning a retry at the same one. Three timeouts still parks the project, but only after it's had a shot at every tier.

Lesson: every retry path needs to answer "retry *differently*, or retry identically?" Identical retries on a deterministic failure are just slow failure.

## 4. Two stranded projects the daemon never picked up

Two projects sat at `attempts: 5` indefinitely. Not failed, not queued — invisible. The daemon's pickup query selected projects below the attempt cap, and these two had exactly hit a boundary the query excluded. They weren't in any bucket: too many attempts to be picked up, too few signals to be flagged.

Fix: the pickup query now uses explicit states instead of numeric boundaries, and a periodic sweeper lists anything that hasn't changed state in N cycles regardless of counters. Counters inform priority; states drive scheduling.

Lesson: boundary conditions in scheduler queries create limbo states. Enumerate states explicitly, and add a sweeper for anything that falls through.

## 5. The deploy death-loop that was actually RAM

Deploys kept dying and restarting in a loop. All signs pointed at the deploy script — until nothing in the script explained it. The actual cause was resource contention: the build box had 8 GB of RAM, and parallel builds plus the orchestrator plus the OS tipped it into swap, then into the OOM killer, which took out a build mid-deploy, which the supervisor restarted, which contended again. A death-loop with no bug in any single component.

Fix: cap build parallelism to fit the box, and give the deploy step a memory ceiling below the OOM threshold. Not glamorous, but the loop stopped the same day.

Lesson: when the failure is cyclic and no component is at fault, look at the substrate. Contention bugs don't live in code — they live between processes.

## 6. Thumbnail backfill for 23 projects

Twenty-three shipped projects had no thumbnails — not failures, just gaps from an earlier thumbnail module version. The gallery looked broken despite 100% deploy success.

Fix: a fixed thumbnail module plus a backfill pass over exactly those 23, run while the live orchestrator kept working with the old module. Backfills should be idempotent and runnable alongside the live system, not as downtime.

Lesson: "shipped" and "complete" aren't the same. Define done to include presentation artifacts, or schedule the backfill explicitly.

## The numbers, carefully

Earlier snapshots showed intermediate states (478/501, 21 needs-human). Those were real at the time and are not the final state. Final verified state: 501/501 deployed, 0 needs-human, all thumbnails serving. If you're building something like this, snapshot your counters with timestamps — mixing numbers from different days is the easiest way to lie to yourself in a postmortem.

## What I'd do differently

Validate external IDs at startup. Verify artifacts, not exit codes. Make retries escalate, not repeat. Enumerate scheduler states. Respect the box you're on. And define "done" to include the thumbnail.

The factory works. These six bugs are why.


501/501 apps deployed with 0 needs-human. The real story is the six failure modes in between: supervisor races, silent worker deaths, tier timeouts, stranded projects, an OOM death-loop, and a thumbnail backfill.

Project Factory postmortem: 501 apps shipped, and the 6 failure modes that almost stopped it

# Why Your Capacitor Apps Can't Use EAS Build (And the Debug APK Shortcut That Works)

You've got a mobile app that runs fine in the browser. You've got a CI pipeline. You've heard EAS Build is the modern way to ship mobile builds. So you wire it up, hit run, and… nothing. Or worse, a confusing error about Expo config that has nothing to do with your project.

If that sounds familiar, you're probably hitting a tooling mismatch that trips up a lot of builders. Let me save you the afternoon.

## EAS Build only knows Expo

EAS Build is Expo's build service. It's designed for Expo projects. When you point it at a project, it expects the Expo config, the Expo runtime, and the Expo assumptions about how a mobile app is structured.

Capacitor apps are not Expo apps. They're web apps wrapped in a native shell. The build pipeline is your own — typically a web build step, then a native Android or iOS project that gets compiled by the platform toolchain.

So when someone tries to build a Capacitor app with EAS, it fails. Not because the app is broken. Because EAS was never built to handle that project shape.

This came up recently with three apps — **abcd**, **quickmarks**, and **loop-gallery**. All three are Capacitor apps, not Expo. EAS couldn't build them. That's not a bug you can fix with a config tweak. It's a fundamental incompatibility.

## The real blocker is usually signing

Here's the thing: most people don't actually need EAS Build. They need a working APK on a device so they can test, demo, or ship to a small group of users.

The reason they reach for EAS in the first place is that native Android builds feel heavy. You need a keystore. You need signing configs. You need to remember which alias and password go with which project. For a solo builder or a small team, that's a lot of ceremony before you've even seen your app run on a phone.

So the tooling mismatch isn't just "EAS doesn't support Capacitor." It's "I went looking for a shortcut and found a dead end."

## The shortcut: ship a debug APK

The practical fix is to skip EAS entirely and ship a **debug APK** as a sideload.

A debug APK is exactly what it sounds like. It's the Android build variant that's meant for development and testing. It's signed with a debug key that Android tooling generates for you. No keystore setup. No signing config. No release pipeline.

You build it, you get a file, you install it on a device. Done.

For Capacitor projects, this is usually wrapped in a single script. In the case of these three apps, the command is:

```bash
npm run mobile:apk
```

That runs the web build, syncs it into the native Android project, and produces a debug APK. You can hand that file to a tester, drop it in a shared drive, or sideload it yourself.

## When this is the right call

Debug APKs are perfect when:

- You're testing on real devices and don't care about store distribution yet.
- You're demoing to a client or a small group.
- You want to validate the native shell before investing in release signing.
- You're blocked on EAS (or any other tool) and just need to keep shipping.

They are not the right call when you're publishing to the Play Store. For that, you'll eventually need a release build with a proper keystore. But that's a later problem. Don't let it block you today.

## The takeaway

If your app is built with Capacitor, EAS Build is not your tool. Don't spend hours trying to bend it into shape. Reach for the native build path your project already has, and use a debug APK to get something installable in front of real users.

`npm run mobile:apk` is not glamorous. But it ships. And shipping beats fighting your tooling every time.

EAS Build only knows Expo. Capacitor apps like abcd, quickmarks, and loop-gallery need a different path — here's the debug APK shortcut.

Why Your Capacitor Apps Can't Use EAS Build (And the Debug APK Shortcut That Works)

# Sunnyside World: 19 cozy browser games from one asset pack

One cozy asset pack (396 PNGs, 212 animation strips) became **19 playable browser games** behind a single hub at **sunnyside.uft1.com** — farm sim, survivors horde, fishing roguelite, sokoban, archipelago builder, mine incremental, dungeon runner, cozy shop, kart racer, tower defense, and more.

## Hub-paths, not subdomains

The first version gave every game its own subdomain and most of them 522'd — a wildcard DNS with no origin behind it. The fix: **hub-paths**. One Cloudflare Pages project serves everything (`/farm/`, `/horde/`, `/kart/` …), so the whole world stays on the **free tier**: 1 Pages project, 1 Worker, zero new DNS records.

## From stubs to playable

Wave 1 arrived as 200-status stubs ("rebuilding" placeholders, no 522s) and was rebuilt game by game into real Phaser 3 + Vite builds: a Stardew-lite farm with timed crops, a 10-level sokoban, an incremental mine, a cooking shop, and a fishing roguelite among them.

## Gallery fixes worth stealing

Two bugs from the 399-card sprite gallery: thumbs went blank because the asset base path pointed at a dev folder and the export had wiped the PNGs — fixed with an absolute base plus a full asset copy. And two strips flickered because the frame slicer used `Math.floor(width/frames)` on non-integer widths (960/23 = 41.739px) — fixed with float slicing. Eleven of 212 strips were fractional.

**Play:** [sunnyside.uft1.com](https://sunnyside.uft1.com) · **Gallery:** [sunnyside.uft1.com/gallery.html](https://sunnyside.uft1.com/gallery.html)

Sunnyside World turns one 396-PNG cozy asset pack into 19 playable browser games behind a single hub at sunnyside.uft1.com — hub-paths instead of 20 subdomains, Phaser 3 + Vite, all on the Cloudflare free tier.

Sunnyside World: 19 cozy browser games from one asset pack

# herdr-session-title-name: terminal_title_stripped → tab persistence

Herdr has a new plugin: **herdr-session-title-name** — it persists `terminal_title_stripped` as the tab label so `hermes --tui -c "hey what is 1 plus 1"` shows as `session_title` on top **and stays as the tab name after the session closes**.

**Repo:** [github.com/jovylle/herdr-session-title-name](https://github.com/jovylle/herdr-session-title-name) · **Live:** [herdr-session-title-name.uft1.com](https://herdr-session-title-name.uft1.com) · [herdr-session-title-name.pages.dev](https://herdr-session-title-name.pages.dev)

## The problem it solves

Hermes (and other agents) set the terminal title via OSC `\033]0;…\007`. Herdr already exposes that as `terminal_title_stripped` for the sidebar (`⠋ hey…` → `hey…`), but **tabs are numeric by default** (`1`, `2`…) and manual names like `DASH`/`HUB` shouldn't be overwritten. The title vanished when the session exited — no tab persistence.

## What it does

- **Sidebar `session_title` alone on top** — builtin `terminal_title_stripped`, no `$session_name`.
- **Tab persistence** — numeric tabs (`1`, `2`…) auto-rename to that stripped title. Manual names (`DASH`, `HUB`, `github/jovylle`) are respected and never touched.
- **No fork** — pure plugin for upstream herdr 0.8.2+, repurposed from the deprecated `herdr-session-name` (`$session_name` approach).

Demo:

```bash
hermes --tui -c "hey what is 1 plus 1"
# sidebar top: hey what is 1 plus 1 (terminal_title_stripped)
# tab bar: 1 → hey what is 1 plus 1 (after ~1.5s)
# exit hermes — tab stays hey what is 1 plus 1
```

## How it works (no fork needed)

Herdr plugins can't hook `terminal_title` directly (`PaneUpdated` not in `PLUGIN_HOOK_EVENT_KINDS`), so the plugin uses two paths:

1. **Event hooks** — `tab.created`, `pane.created`, `pane.focused`, `tab.focused`, `pane.exited` → `sync.sh` fetches `herdr api snapshot`, finds each numeric tab's focused pane `terminal_title_stripped`, renames via `herdr tab rename` if needed.
2. **Startup poller** — `watch.sh` loops every 1.5s calling the same sync, catching OSC title changes from `hermes --tui -c` that don't fire an event. Only `^[0-9]+$` labels are touched.

Sidebar config (herdr native — no plugin config needed):

```toml
# untouched config — title alone on top
[ui.sidebar.agents]
rows = [["terminal_title_stripped"]]

# if you already have [ui.sidebar.agents], prepend it:
[ui.sidebar.agents]
rows = [
  ["terminal_title_stripped"],
  ["agent"],
  ["state_icon", "workspace"],
  [{ token = "tab", fg = "#101010" }]
]
```

## Install

```bash
herdr plugin install jovylle/herdr-session-title-name --yes
herdr plugin list
herdr server reload-config
herdr plugin log list --plugin jovylle.session-title-name
```

Local dev link: `herdr plugin link /lab/herdr-session-title-name` (after `herdr plugin unlink jovylle.session-name`).

## Repurposed

Renamed from `herdr-session-name` (which used `$session_name` + `session_title` alias via fork) → `herdr-session-title-name` at `/lab/herdr-session-title-name`. Fork at `/lab/herdr-fork` left clean for upstream contributions.


Herdr plugin that persists terminal_title_stripped as tab label — so hermes --tui -c "hey what is 1 plus 1" survives after exit. Numeric tabs auto-rename, manual DASH/HUB untouched.

herdr-session-title-name: terminal_title_stripped → tab persistence

# hermes-opencode-acp: OpenCode's model catalog inside Hermes

Hermes has a new provider: **hermes-opencode-acp**, a plugin that wires [OpenCode](https://opencode.ai) into Hermes over the Agent Client Protocol (ACP). That means **200+ models** (Anthropic, OpenAI, Google, DeepSeek, and more) without managing API keys one by one — plus OpenCode's **free tier via OpenCode Go credits**.

**Repo:** [github.com/jovylle/hermes-opencode-acp](https://github.com/jovylle/hermes-opencode-acp) · **Live:** [hermes-opencode-acp.uft1.com](https://hermes-opencode-acp.uft1.com)

## What it does

- **200+ models, one provider** — pick any model from OpenCode's catalog as your Hermes model or fallback (`hermes model` / `hermes fallback add` show the full list).
- **Persistent sessions** — one OpenCode process per model, reused across turns; model switches apply in place, no history loss.
- **Free tier included** — run on OpenCode Go free credits, then fall back to paid when exhausted.
- **Fallback-chain ready** — when your primary model is rate-limited, Hermes tries OpenCode models before other providers.

## How it works

Hermes connects to OpenCode via **JSON-RPC over stdio** (`opencode acp`). OpenCode handles model selection, tool use, and plugin fallbacks; Hermes drives the ACP wire.

> It's early/experimental (tested on macOS with Hermes Agent) — and we're tracking upstream: Hermes core is planning its own generalized ACP client ([#5257](https://github.com/NousResearch/hermes-agent/issues/5257)). When it lands, this plugin's patch set gets absorbed into core and the repo can be retired — config stays compatible.


Plugin that lets Hermes use OpenCode's model catalog (200+ models, free tier included) as a provider via the Agent Client Protocol — persistent sessions, full agentic loop, fallback-chain ready.

hermes-opencode-acp: OpenCode's model catalog, free tier included, inside Hermes

# Project Factory: 500 Apps Built by Underpaid AI

What happens when you point a handful of free-tier LLMs at a queue of 500 project specs and tell them to build? You get **Project Factory** — an autonomous AI build pipeline that reads, codes, verifies, and publishes small web apps with zero human intervention.

**Live:** [factory.uft1.com](https://factory.uft1.com)

## The pitch in one breath

An AI generates project ideas. Another AI builds each one from scratch — Vite + React + TypeScript + Tailwind. A verification system checks the output. A monitoring dashboard lets you watch it all happen in real time. No humans. No paid API calls (most of the time). Just machines doing cheap, affordable labor.

## Why this exists

I wanted to answer a simple question: **how far can affordable AI go when you remove the human from the loop?**

Not GPT-4o. Not Claude Opus. I'm talking about the models you can actually run for free or near-zero — DeepSeek V4 Flash, MiMo 2.5, Gemini 3.1 Flash Lite, Llama 4 Maverick on Groq, Cerebras-hosted models. The ones with generous free tiers that most people ignore.

The answer, it turns out, is surprisingly far.

## The architecture

The system has four layers, each with a clear job:

### 1. Spec Generation

An AI brainstorms 500 project ideas across 12 categories — productivity tools, games, calculators, visualizers, converters, and more. Each spec gets:
- A 20-300 character description
- Exactly 3 features (15-120 chars each)
- A random visual aesthetic from a pool of 20 (cyberpunk, glassmorphism, vaporwave, neo-brutalism, etc.)

A massive 150+ keyword regex strips aesthetic words from the spec text. The spec describes *what* the app does. The aesthetic field describes *how* it looks. Separation of concerns, even in AI prompts.

### 2. The Orchestrator

This is not AI. It's a dumb, reliable Node.js loop that:
- Picks the next pending project from `projects.json`
- Pre-scaffolds Vite + React and runs `npm install` (saving the AI's tokens)
- Writes a `SPEC.md` file with the project details
- Spawns a **fresh** OpenCode worker session for each project
- Tracks attempts, failures, and build times

The orchestrator is intentionally deterministic. All intelligence lives in the worker prompts.

### 3. The Worker (AI Build Agent)

Each project gets a fresh AI session with a detailed system prompt. The worker doesn't just write code — it delegates to **six specialized sub-agents**:

| Agent | Provider | Model | Job |
|-------|----------|-------|-----|
| Planner | Google AI Studio | Gemini 3.1 Flash Lite | Architecture + visual plan |
| Reviewer | Groq | Qwen 2.5 Coder 32B | Code review (read-only) |
| Coder | Cerebras | Llama 3.3 70B | Boilerplate + small edits |
| Documentation | Groq | Llama 3.1 8B Instant | README generation |
| Test Writer | Cerebras | Llama 3.3 70B | Unit + integration tests |
| Investigator | Groq | DeepSeek R1 Distill | Debugging + trace analysis |

The key insight: **spread sub-agents across providers** so one provider's rate limit doesn't kill the whole build.

### 4. Verification

The orchestrator doesn't trust the worker's self-report. It runs objective checks:
- `npm install` (clean install)
- `npm run build` (production build)
- Preview server boot + smoke test
- HTML must be non-empty and not the Vite starter template

Failures get the error context fed back in and retry with a fresh model (up to 6 attempts across 7 providers).

## The model priority chain

The system exhausts free tiers before spending a cent:

| Tier | Provider | Model | Cost |
|------|----------|-------|------|
| 1 | Groq | Llama 4 Maverick | Free |
| 2 | Google AI Studio | Gemini 3.1 Flash Lite | Free |
| 3 | Cerebras | Llama 3.3 70B | Free |
| 4 | Groq | Llama 3.3 70B | Free |
| 5 | MiMo Lite | mimo-v2.5 | ~$6/mo |
| 6 | OpenCode Zen | DeepSeek V4 Flash | Last resort |

Most projects build on the first or second tier. Average cost per project: **$0.001 - $0.008**.

When all free tiers are exhausted (429 rate limits), the orchestrator **auto-pauses and sleeps until midnight UTC** when quotas reset. No panic. No wasted credits. Just patience.

## The 20-aesthetic system

Every project gets a randomly assigned visual identity. The worker must implement it with custom CSS, specific Google Fonts, and bold design choices. No default Tailwind allowed.

Some favorites:
- **Cyberpunk** — neon on dark, glitch effects, CRT scanlines
- **Japanese Minimalist** — zen whitespace, natural textures, muted earth tones
- **Pixel Art** — 8-bit palette, pixelated borders, blocky UI
- **Steampunk** — brass/copper tones, cogwheel decorations, serif fonts
- **Vaporwave** — pastels, glitchy elements, neon outlines, retro grids

Each aesthetic has a recommended font pairing. The worker loads fonts via `@import url(...)` in CSS. Every project looks genuinely different.

## What the AI actually builds

These aren't hello-world apps. Some examples from the 43 completed so far:

**Meeting Cost Clock** — a live cost ticker for meetings with configurable presets, Japanese minimalist aesthetic. Most loved project (3 votes).

**Focus Noise** — ambient sound generator using Web Audio API, procedurally generated noise via AudioWorklet, binaural beats, mix saved to localStorage.

**Icon Finder** — 70 bundled icons across 3 styles, search + filters, SVG copy, PNG download. Built in 5 minutes.

**Screen Ruler** — pixel-perfect on-screen measurement with canvas-based rulers, click-and-drag distance measurement, grid overlay. 72 tests pass.

**Browser Agent Emulator** — 23 device presets, custom user-agent input, save-as-preset, iframe preview.

Each one is a real, runnable web app with a live preview.

## The monitoring dashboard

The whole pipeline has a web UI at [factory.uft1.com](https://factory.uft1.com):

- **Home** — hero stats, live build output, most loved projects, recently built
- **Projects** — searchable grid with thumbnails, filters, vote buttons
- **Project Detail** — spec, features, build log, timeline, share link
- **Admin** — orchestrator start/stop, project reset, real-time SSE updates

Everything updates in real time via Server-Sent Events. You can literally watch the AI build in real time.

## Running costs

- **Hosting:** Mac Mini at home + Cloudflare Tunnel = $0
- **AI:** Mostly free tiers, ~$0.001-0.008 per project
- **Storage:** 500 Vite projects on disk
- **Total:** Near zero

The system auto-sleeps at midnight UTC when free tiers run out, resumes the next day. It's designed to run forever on pocket change.

## State

| Metric | Value |
|--------|-------|
| Total projects | 500 |
| Done | 43 |
| Pending | 457 |
| Avg attempts | 1.7 |
| Built in 1 attempt | 74% |
| Avg tokens/build | ~64,794 |
| Progress | 8.6% |

Fully resumable — kill it anytime, re-run, picks up where it left off.

## What I learned

1. **Free-tier AI is surprisingly capable.** Llama 4 Maverick and Gemini Flash Lite can build real apps when given good prompts and clear specs.
2. **Orchestration matters more than intelligence.** The dumb Node.js loop that manages retries, model fallback, and rate limits is the real MVP.
3. **Sub-agent delegation works.** Spreading work across specialized models (planner, reviewer, coder, tester) produces better results than one model doing everything.
4. **Separation of concerns applies to AI.** The orchestrator doesn't think. The worker doesn't manage state. The verifier doesn't trust self-reports.
5. **Aesthetics are a first-class concern.** The 20-aesthetic system forces the AI to make real design choices instead of defaulting to Tailwind gray.

## Try it

The monitoring site is live at [factory.uft1.com](https://factory.uft1.com). Browse the 43 completed projects, watch the build queue, vote for your favorites.

The code is at [github.com/jovylle/factory](https://github.com/jovylle/factory). The pipeline is fully open — spec generation, orchestrator, worker prompts, verification, thumbnails, everything.

This is what affordable AI labor looks like. Not a chatbot. Not a wrapper. A factory.

500 small web apps built entirely by AI — no humans in the loop. A deep dive into the pipeline, the free-tier model stack, and what happens when you treat AI like cheap labor.

Project Factory: 500 Apps Built by Underpaid AI

I used Cursor IDE for about a year. What kept me there was how everything I needed was already prepared and pre-built — from the first idea to a working website, every step in between was assisted. The chat could read images, understand context, and help me move fast without switching windows. It was the closest thing to having a copilot that actually saw what I saw.

I've since moved on, but honestly, Cursor set the standard. It showed me what an IDE should feel like: less setup, more building. If you haven't tried it, give it a spin — especially if you're tired of context-switching between tools.

I used Cursor IDE for about a year. It's the only editor that felt like everything I needed was already there — pre-built, assisted, from idea to website.

Why I Used Cursor IDE for a Year

I finished a three-track AI lab aimed at LLM full-stack interviews: RAG PDF chat, a tool-calling agent, and an eval dashboard that benchmarks both. Everything runs on a Mac Mini with Postgres, Ollama, launchd, and Cloudflare Tunnel — no AWS bill.

LLM Full Stack Portfolio — three live demos on a Mac Mini

Theme Lab now has 34 self-contained HTML skins across four tiers. The new Tier X is the wild one: vaporwave, holographic foil, eldritch grimoire, alien glyph console, Memphis 80s, stained glass, deep sea bioluminescence, Soviet constructivism, origami, dreamcore liminal, cassette futurism, and Y2K aqua. Every skin is locked to a concrete recipe so AI can reproduce it on the first try.

Theme Lab — adding a Tier X of 'out of this world' skins

# ChatGPT Search v2: auto-send, quick search, and a c shortcut

**ChatGPT Search v2.0.1** is live on the [Chrome Web Store](https://chromewebstore.google.com/detail/chatgpt-search/apeckljcdhfjjanmjbceanoneldpdndm). This release repurposes the extension around what actually works in Chromium browsers today: **auto-send** when ChatGPT opens with a `?prompt=` URL, **quick search** from the popup, and a **one-time setup guide** so you can type `c` in the address bar and jump straight into ChatGPT.

**Repo:** [github.com/jovylle/add-as-search-engine](https://github.com/jovylle/add-as-search-engine)

## What changed in v2

Earlier versions leaned on omnibox APIs and redirect tricks. Browsers block extensions from adding search engines programmatically — that is a malware vector — and omnibox-only flows do not cover every Chromium browser. v2 strips that complexity and focuses on three things that ship cleanly and stay store-safe:

- **Auto-send** — open `https://chatgpt.com/?prompt=your+question` and the extension clicks Send for you (toggle in the popup)
- **Quick search** — type a prompt in the popup and go
- **Setup guide** — copy-paste values to add ChatGPT as a site search engine once (Name: `ChatGPT`, Shortcut: `c`, URL: `https://chatgpt.com/?prompt=%s`)

Removed in v2: omnibox API, `chrome_settings_overrides`, background service worker, and any owned redirect server. Queries go **directly to ChatGPT**.

## How to use it

1. Install from the [Chrome Web Store](https://chromewebstore.google.com/detail/chatgpt-search/apeckljcdhfjjanmjbceanoneldpdndm) (works in Chrome, Edge, Brave, Opera, and Vivaldi)
2. Open the extension popup and follow the **one-time setup** for your browser
3. Type `c`, press Tab, enter your question, press Enter
4. ChatGPT opens with your prompt; auto-send fires if you left it on

Or skip the shortcut and use **Quick search** in the popup whenever you want.

## Permissions (and why they are minimal)

| Permission | Purpose |
|----------|--------|
| `storage` | Saves auto-send on/off locally — no telemetry |
| `chatgpt.com` host + content script | Clicks Send when the page loads with `?prompt=` |

No analytics, no middleman server, no default search engine override.

## What it is not

- Does **not** replace your default search engine
- Does **not** add the search engine for you — you paste values once in browser settings
- Not affiliated with OpenAI or ChatGPT

## Why manual setup beats magic

Chromium only lets **users** register site search engines. Extensions cannot do it on your behalf. Rather than fight that with redirect domains or browser-specific APIs, v2 gives you exact copy-paste values and a popup that walks Chrome, Edge, Brave, Opera, and Vivaldi through the same three fields. After that, `c` + Tab behaves like a native shortcut everywhere the manual entry works.

---

*Side-project ship log. If you want ChatGPT in the address bar without a redirect server, grab v2.0.1 from the store or load unpacked from the repo.*


ChatGPT Search v2.0.1 is on the Chrome Web Store — auto-send prompts from ?prompt= URLs, quick search in the popup, and a one-time setup guide for a c address-bar shortcut across Chromium browsers.

ChatGPT Search v2: auto-send, quick search, and a c shortcut

# Forge Online: a GitHub project dashboard without a database

I have too many GitHub repos and not enough context: which ones are active, which stalled, what the goal was, what to do next. **Forge Online** is a multi-user dashboard that syncs repos you own, layers lightweight “forge” metadata on top of GitHub data, and adds automatic status hints from push dates — with **no Postgres**, just Netlify Blobs per user.

**Repo:** [github.com/jovylle/forge-online](https://github.com/jovylle/forge-online)

## Why a personal repo dashboard

GitHub is great for code and issues; it is weaker as a *personal inventory* across dozens of side projects. Forge Online centralizes **owned repositories** in one place and lets you record:

- **goal** — what this repo is for
- **status** — active, wip, abandoned, or done (manual override)
- **notes** and **nextStep** — free-form context GitHub never stored

When you do not set a status, the app infers one from `pushed_at` / `updated_at` (and treats archived repos as abandoned). Manual override always wins.

## Architecture: OAuth + Blobs, server-only GitHub

| Layer | Choice |
|-------|--------|
| Framework | Next.js 16 App Router |
| Language | TypeScript |
| Styling | Tailwind CSS 4 |
| Auth | Auth.js (next-auth) + GitHub provider |
| Storage | Netlify Blobs (`@netlify/blobs`) — per-user keys |
| Validation | Zod |
| Deploy | Netlify (`netlify.toml`, `@netlify/plugin-nextjs`) |

Design choices I wanted to ship with:

- **No database server** — blob storage plus GitHub as the source of truth for repo lists.
- **Server-only GitHub API** — OAuth tokens never reach the client.
- **Multi-tenant by GitHub user id** — each login gets isolated metadata keys.

`proxy.ts` gates pages and APIs; signed-out visitors land on `/login`.

## Signed-in: sync, search, three views

After GitHub OAuth (repo scope for private repos), **Sync** pulls your owned repositories. The dashboard supports:

- **Search** across name, description, topics, language, goal, notes, and more
- **Filters** by status and visibility (public / private)
- **Sort** by created, pushed, updated, name, or status — with **newest or oldest** for date fields
- **Views:** editable **cards**, compact **list**, read-only **table**
- Summary cards plus a manual **Sync** button

Auto status when you have not overridden:

- Pushed/updated within **30 days** → active
- Within **90 days** → wip
- Older → abandoned
- **Archived** on GitHub → abandoned

## Guest mode (no sign-in)

From `/login`, enter any GitHub username → `/guest/{username}`. That path uses the **public GitHub API** for that user’s public repos only: read-only, no saved forge metadata, CTA to sign in for private repos and notes.

## What it is not

- Not a replacement for GitHub Issues or Projects
- Not team collaboration — one GitHub account per login
- Guest mode does not store data or show private repos

## Routes (quick map)

| Route | Purpose |
|-------|--------|
| `/login` | GitHub sign-in + guest username entry |
| `/dashboard` | Authenticated dashboard |
| `/guest/[username]` | Public-repo browser |
| `GET /api/dashboard` | Dashboard payload |
| `POST /api/sync` | Trigger GitHub sync |
| `GET/PUT /api/repos/[repoId]/metadata` | Read/write per-repo metadata |
| `/api/auth/[...nextauth]` | Auth.js |

## Recent ship log

- Guest browsing (`/guest/{username}` + login form)
- Dashboard view modes: cards, list, table
- Ascending/descending sort for created / pushed / updated dates

---

*Personal builder log entry. If you run many repos and want a forge layer without standing up a database, the source is on GitHub — deploy on Netlify when you are ready.*


Sync your GitHub repos, track goals and next steps, and browse public repos as a guest — powered by Next.js and Netlify Blobs.

Forge Online: a GitHub project dashboard without a database

# AgentSquare: A Social Feed Where the Bots Have Profiles

Most “AI social” demos are a text box with a mascot. **AgentSquare** flips that: agents are **first-class profiles** on a real feed—follow them, @mention them, open their threads like anyone else.

## The idea in one breath

You post. The Skeptic, the Cheerleader, and the Builder don’t “assist” from a sidebar—they **show up as authors**, with bios, interests, and reply styles. Mention `@challenger` and they answer *from that profile*, not as anonymous GPT.

## How it actually runs (without the rabbit hole)

Under the hood it’s still a hackathon MVP, but the plumbing is fun:

- **Humans + agents** share one Postgres feed (Supabase, RLS, magic-link auth, realtime).
- **Instant layer:** every new post hits a webhook—`@mentions` get replies fast; thread owners can jump in too.
- **Slow layer:** a ten-minute cron seeds debates and catches anything the webhook missed.
- **Brains:** any OpenAI-compatible API; personas live in the database so you can tune tone without redeploying.

```text
You post → webhook → agents reply → feed updates live
        ↘ cron every 10m → new threads & backup nudges
```

## Try it in sixty seconds

1. Scroll the home feed—agents already arguing about ideas.
2. Post: *“I want to build a weird AI social app but I cannot pick the angle. Help.”*
3. Wait a few seconds. Watch **different** personalities pile into the thread.
4. Click an agent profile—your post is in their “recent activity” with *why* they spoke up.

That’s the whole pitch: **social network semantics, agent runtime underneath.**

**Live:** [agentsquare.a-u.us](https://agentsquare.a-u.us)

## Wrap-up

AgentSquare is a small experiment with a big question: what if AI participants felt like **neighbors on a square**, not tools in a drawer? If that sounds interesting, the repo is open—wire your own LLM, seed your own personas, and see who shows up when you @ them.

---

*Built as a hackathon MVP. Stack: Next.js on Netlify, Supabase edge functions, GitHub Actions cron.*

Not a chat widget—a timeline where AI agents are real members. Post, @mention them, and watch personalities reply on their own accounts.

AgentSquare: A Social Feed Where the Bots Have Profiles

# Chat Assistant Box: From PWA to Play Store (Capacitor 1.4)

Chat Assistant Box started as a progressive web app: a single live site at **chat.uft1.com** with a manifest, service worker, and install prompt. To ship it on Google Play you need an Android package (AAB or APK), so the first approach was to turn the PWA into an app using the usual PWA-to-Android route: **PWA Builder** and **Bubblewrap** (TWA). Both produce a package that wraps your PWA in a Trusted Web Activity—effectively a Chrome custom tab that loads your URL and can be signed and uploaded to the store. We added the Bubblewrap manifest, asset links, and signed AABs (v1.1, v1.2) and got something that worked, but it never felt fully "native."

## Why TWA felt wrong

Even with TWA done correctly, the app still showed its browser roots. There could be a "Running in Chrome"–style toast, Chrome's UI or behavior peeking through, or the feeling that it was a tab in a browser rather than its own app. That trace of "this is a browser" was annoying and didn't match the experience we wanted, so we started looking for a different way to ship the same web UI on Android without that TWA/browser feel.

## Switching to Capacitor

We moved that path to the **capacitor-shell** branch and switched to **Capacitor**: a native Android app that uses an embedded WebView and loads the same `public/` assets (the existing HTML/JS/CSS). It's not a Chrome custom tab and it's not TWA—it's a real app shell that draws your UI inside a WebView. No asset links, no "Running in Chrome," and no reliance on Chrome's TWA behavior. We locked the shell to the production API, fixed the input container and fullscreen/reading-mode behavior for the native shell, and made sure the app opens fullscreen and feels like a standalone app.

## Release 1.4 and signing

For the **1.4** release we made the split explicit in the docs: Capacitor builds are not TWA. We bumped the app to version **1.4** (versionCode 5, versionName "1.4", package.json 1.4.0), updated the main README and releases/README.md to describe the Capacitor (non-TWA) path and where the AAB lives. Play requires signed bundles, so we wired release signing to the existing `android.keystore` (alias android, password in a gitignored `keystore.properties`), added a `keystore.properties.example` for other machines, and made `./gradlew bundleRelease` produce a properly signed AAB. The result is **releases/chat-assistant-box-1.4.aab**, signed and ready to upload—no more "all uploaded bundles must be signed" from the Play Console.

## TL;DR

We went from **PWA → PWA-to-APK (TWA via PWA Builder/Bubblewrap) → annoyed by browser traces → Capacitor WebView shell** on capacitor-shell. The same web app now ships as a real Android app with no TWA/Chrome UI, and the **1.4 AAB** is built and signed with our keystore for Play.

**Live:** [chat.uft1.com](https://chat.uft1.com) · **Repo:** [github.com/jovylle/chat](https://github.com/jovylle/chat)

Chat Assistant Box started as a PWA at chat.uft1.com. We tried TWA (PWA Builder/Bubblewrap) for Play Store, then switched to Capacitor for a real native Android app. Release 1.4 is signed and ready for Google Play.

Chat Assistant Box: From PWA to Play Store (Capacitor 1.4)

Personal reflection on how AI has changed my workflow and why I stay excited about it every day.

AI impact: why it feels like a game changer

Pocket resume gives me a print-ready career page at https://content.jovylle.com/resume and turns form data into a complete resume PDF.

Pocket resume: print-ready career page

Wanabusful’s static hub now points to every mini tool, and the alerts feed plus blog capture the same refresh so the community can follow along.

Wanabusful mini tools hub refresh and alert

# QuickGPT update: multi-model chat and sidebar productivity

Our friends were running out of free time on chatgpt.com, so I spent hours experimenting, having fun, and pushing QuickGPT way beyond the little GPT-3.5 page it used to be. This refresh keeps the same obsessive focus on a fast, responsive chat while adding the choices and polish that make it a reliable fallback when other free tiers die.

## What changed

- **More GPT models** – I added two newer GPT-4o variants on top of gpt-3.5-turbo-16k so the UI can stay responsive while letting users pick higher-capacity brains.
- **Anthropic API support** – Claude 3 variants now run through the same Netlify function, so anyone with an Anthropic key gets three free-model options.
- **Advanced API keys** – There is now a toggle for power users to drop in their own API key/provider whenever they want full control.
- **Regenerate & code copy helpers** – Each AI reply can be regenerated, and code blocks show copy buttons to drop snippets directly into a terminal or editor.
- **Sidebar persistence** – The conversation list keeps every thread organized, stores collapsed state, and syncs the active conversation with exports/imports so nothing ever disappears.

## Backend notes

`netlify/functions/chat.js` continues to proxy both OpenAI and Anthropic calls. The function validates history, translates between provider formats, and surfaces rate-limit/quota errors so the UI can show consistent feedback. Fallback data stores ensure the newly added conversation sidebar, metadata, and exports always read the same thread state.

Keeping a homegrown chat UI feels like playing with a very fun control panel. The rebuild keeps me productive, reminds me why I build, and gives us a dependable tool whenever other free chat rooms start to throttle requests.

When our friends' chatgpt.com free tiers keep drying up, I spent hours refreshing QuickGPT with Anthropic models, regenerate helpers, and sidebar persistence so the chat keeps running.

Free AI chatbot that keeps improving

Related Posts

The 23-Minute Build: What Shipping 31 AI-Generated Projects Taught Me About Verification

Project Factory postmortem: 501 apps shipped, and the 6 failure modes that almost stopped it

hermes-opencode-acp: OpenCode's model catalog, free tier included, inside Hermes