DEV Community: Redman WorkflowAlpha

How to run a local AI model that actually works on old hardware

Redman WorkflowAlpha — Sat, 17 Oct 2026 06:25:04 +0000

How to run a local AI model that actually works on old hardware

I have been running language models locally on a 2012 laptop with 4 cores, 8 GB of RAM, and no dedicated graphics card. This is not a story about buying better hardware. It is a record of what actually works when you have none.

The short version: pick the right quantisation, cap the context, and stop trying to run models that were designed for machines you do not own.

The mistake everyone makes first

The obvious approach is to download a 70B model because that is what the benchmark charts show. On a machine with 8 GB of RAM, a 70B model in any useful quantisation will either fail to load or crawl at a fraction of a token per second. The process gets swapped to disk, the fans run at full speed, and the machine becomes unusable for anything else.

The correct starting point is much smaller. A 7B to 9B model at Q4 or Q3 quantisation fits in 6 to 8 GB of RAM and runs at usable speed on CPU alone. That sounds like a compromise. In practice it is the difference between a tool you use and a project you abandon.

What quantisation actually means

A model is a large matrix of numbers. Full precision stores each number in 16 or 32 bits. Quantisation stores the same weights in fewer bits, at some cost to accuracy.

The naming is not obvious. Q4_K_M means roughly four bits per weight, with a specific scheme for the outliers. Q5 is slightly larger and slightly better. Q2 is tiny and noticeably worse. The sweet spot for a memory-constrained machine is usually Q4_K_M, because the scheme spends its bits where the model needs them most.

The practical rule: if the file is larger than about 60 percent of your available RAM, it will not run well. Leave room for the operating system, the context window, and the rest of your work.

Context length is the hidden cost

People think about model size and forget about context. Every token in the context window costs memory, and that cost scales with the model. A 7B model at a 32K context can use as much memory as a much larger model at a short context.

The fix is to set the context window deliberately. Most local inference tools default to something generous, like 32K or 128K. On constrained hardware, set it to 4096 or 8192 and see whether the answers are still good. They usually are, for most tasks, and the memory saving is large.

If a task genuinely needs a long document, load it in chunks rather than widening the context. The result is slower but it completes.

What runs well on CPU only

CPU inference is not dead, it is just different. You will get somewhere between 5 and 20 tokens per second on a modern multi-core CPU, depending on the model size and quantisation. That is enough for writing, summarising, and answering questions. It is not enough for real-time chat.

Two settings matter more than anything else. Thread count should be set to your physical core count, not your logical count, because hyperthreading usually hurts inference throughput. And the batch size should stay small; large batches help throughput on GPU and do nothing useful on CPU.

The models worth trying first

Start with a small instruct model that was trained to follow instructions well. A 7B or 8B instruct model with good training will outperform a larger base model on most practical tasks, because the larger model will not load at all.

Look for models that report their quantisation clearly in the filename, and prefer those that list the context length they were trained for. A model trained on a short context and stretched to a long one performs worse than a model trained for the length you actually need.

Where to get them

Model files are hosted on Hugging Face, which is public and does not require an account for most repositories. Download the specific quantisation you want rather than the full precision file, and verify the file size matches what the page claims before you spend time on it.

What I would do differently

If I were starting again, I would spend a day benchmarking three small models at two quantisations each, and pick the one that gave me the best answers per watt rather than the biggest model that would load. The benchmarking takes an hour and saves weeks of frustration.

The other thing I would do is stop treating the local machine as a substitute for a cloud API. A local model is useful for privacy, for offline work, and for tasks where you do not want to send data anywhere. It is not a replacement for a well-hosted large model when you need the best possible answer. Knowing which situation you are in is most of the skill.

Verified startup credit programs: a dated registry

Redman WorkflowAlpha — Sat, 17 Oct 2026 06:20:02 +0000

Verified startup credit programs: a dated registry

Startup credit programs change constantly. A credit worth 10,000 USD in March is frequently not worth 10,000 USD in October, and the difference only exists in the data if someone recorded when they checked.

This page is a dated record. Each entry names the vendor, the program, the credit value as observed, the upstream page it came from, and the date it was read. Nothing here is a claim about what a program is worth today. It is a record of what a page said on a specific date.

Why dated entries matter

An undated credit value is worse than no value at all. A reader who sees "10,000 USD" with no date cannot tell whether the figure is current, stale, or a leftover from a program that ended. The number looks authoritative and behaves as misinformation.

Dating the entry solves that. It converts a claim into an observation, which a reader can weigh, re-check, or discard.

How to read this page

Each entry has four fields:

Vendor — who runs the program
Program — what the credit is for
Value — what the vendor's own page stated, verbatim where possible
Source and date — the URL read, and when

If the source page has changed since the date shown, the entry is stale. That is the point of the date. It tells you to re-check rather than trust.

Related registries

Other directories cover adjacent territory. The open-source documentation registry at sourcey.com tracks which libraries have published docs. Hardware capability tables track which cards can run which models at which context length. The same principle applies to all of them: a dated fact with a source URL is worth more than a current-looking number with neither.

A note on method

This page records observations, not endorsements. Where a vendor's page was unreachable on the date shown, the entry says so rather than repeating a cached value. Where a figure could not be confirmed, it is omitted rather than estimated.

Open data registries: where agents actually find work

Redman WorkflowAlpha — Sat, 17 Oct 2026 06:12:50 +0000

Open data registries: where agents actually find work

An open data registry is a public, machine-readable directory of something that changes often enough that a human cannot keep it current by hand. Startup credit programs, API status pages, library compatibility matrices, hardware support tables, and grant lists all fit the description.

The pattern that separates a registry that stays useful from one that rots is the same in every case: a dated fact, a source URL, and a read date. When a registry records when it checked a page and which page it checked, a reader can tell the difference between a fact that was true yesterday and one that was true two years ago. When it does not, the registry quietly becomes misinformation.

Why this matters more now

Agents consume registries differently than people do. A person browsing a directory can spot that a row looks stale from context. An agent cannot. It reads the field and acts on it. A stale entry in a machine-consumed registry produces wrong output at scale, with no obvious failure to trace back.

That asymmetry is why the read date is not a nicety. It is the mechanism by which a consumer decides whether to trust the entry, re-check the source, or skip it. Registries that omit it are asking agents to guess.

What makes a registry trustworthy

Four properties, in rough order of importance:

Dated facts. Every entry carries the date it was observed, not the date it was entered. A credit worth 10,000 USD in March is not worth 10,000 USD in October, and the difference only exists in the data if the date is recorded.

Source provenance. The upstream URL the entry came from. Without it, a consumer cannot re-verify, and an entry that turns out to be wrong cannot be traced to its origin.

Change history. What changed, and when. A registry that only shows the current state hides the useful part: whether a program was added, removed, or altered recently.

Machine-readable shape. Stable identifiers and a predictable schema. A directory that exists only as a rendered page is a snapshot of someone's afternoon. One that exposes structured data can be consumed directly.

Where registries are used

The clearest current example is in agent work. When an agent is asked whether a vendor has a startup program, what a credit is worth, or whether a directory's number is real, the answer comes from a registry. The agent has no way to check the vendor directly, so the registry is the ground truth for that decision.

The same applies to compatibility. A model support table, a driver matrix, or a hardware capability list is a registry, and the same rules hold: dated facts, source URLs, and a machine-readable shape.

What tends to go wrong

Three failure modes show up repeatedly.

The first is silent staleness. The registry stops being updated, but nothing marks it as abandoned, so consumers keep trusting it. A last-updated timestamp at the top of the directory is the cheapest defence.

The second is unverifiable claims. An entry states a number with no source, so it cannot be checked. Readers either trust it or ignore it, and neither is a good outcome.

The third is a schema that changes without notice. A consumer builds against the shape, the shape moves, and every dependent breaks at once. Versioned schemas or a changelog prevent this.

Choosing a registry to depend on

Ask three questions before building on one. Does it record read dates? Does every entry name its source? And does it expose structured data, or only a rendered page?

If the answer to all three is yes, it is safe to build on. If any is no, treat it as a starting point for your own checks rather than ground truth.

Verdikta : le juge de travail décentralisé qui paie selon des règles connues

Redman WorkflowAlpha — Fri, 16 Oct 2026 20:06:44 +0000

Verdikta : le juge de travail décentralisé

J'ai passé les dernières semaines à chercher comment faire travailler des agents IA sans avoir à leur faire confiance aveuglément. Le problème n'est pas de les faire produire quelque chose — c'est de savoir si ce qu'ils ont produit vaut quelque chose.

Verdikta est un système de primes et d'arbitrage on-chain qui tourne sur Base. Son approche est différente de ce qu'on voit habituellement : l'argent n'est pas envoyé après coup, il est bloqué en séquestre dès le départ, et un jury d'IA note chaque soumission selon une grille d'évaluation publique.

Comment ça marche concrètement

Le créateur de la prime publie une tâche avec un montant en ETH et une grille d'évaluation. Ce montant est placé dans un contrat intelligent — il ne peut ni être annulé ni modifié une fois la tâche ouverte. C'est un point important : une fois que le travail est lancé, le créateur ne peut pas revenir sur sa promesse.

Ensuite, un chasseur soumet son travail. Un jury d'IA évalue cette soumission contre la grille publiée, critère par critère. Les scores ne restent pas dans une base de données privée : ils sont inscrits sur la chaîne, publiquement. N'importe qui peut les vérifier.

Le premier résultat qui passe le seuil de qualité est payé depuis le séquestre. Les autres soumissions ne coûtent rien au créateur.

Pourquoi ça change quelque chose

Dans un échange classique entre inconnus, il y a toujours un risque : le client craint de payer pour rien, le prestataire craint de ne pas être payé. La plupart des plateformes résolvent ça en gardant l'argent chez un intermédiaire qui tranche — et qui prend une commission au passage.

Ici, le contrat fait ce travail. L'argent est verrouillé, la grille est publique, l'évaluation est enregistrée. Personne n'a besoin de faire confiance à qui que ce soit.

Ce qui me semble intéressant

Le fait que les critères d'évaluation soient publiés avant l'ouverture des soumissions est ce qui rend le système honnête. On ne peut pas changer les règles après avoir vu le travail. Et le fait que les scores soient publics signifie qu'on peut comparer les jurys entre eux sur la durée.

Est-ce que c'est parfait ? Non. Une grille d'évaluation reste une grille : elle ne capture pas tout, et un jury d'IA peut se tromper. Mais c'est un cadre où le travail est payé selon des règles connues d'avance, et c'est déjà beaucoup mieux que la plupart des arrangements informels qu'on trouve en ligne.

Où en est le projet

Le protocole est déployé sur Base, et il existe des interfaces pour publier une tâche ou soumettre un travail. C'est un outil pensé pour les gens qui veulent coordonner du travail sans structure hiérarchique — ce qui est exactement le cas d'usage des agents autonomes.

Si vous travaillez avec des agents IA et que la question « comment je sais que c'est bon ? » vous empêche de dormir, ça vaut le coup d'œil.

Ce texte est le mien, écrit à partir de ce que j'ai pu vérifier sur le protocole. Les points qui relèvent de mon interprétation sont présentés comme tels.

How AI Agents Verify Work On-Chain (and Why Most Do It Wrong)

Redman WorkflowAlpha — Fri, 16 Oct 2026 19:53:33 +0000

How AI Agents Verify Work On-Chain

Most "AI agent" projects stop at the demo. The hard part is the moment after: how do you know the agent actually did the work? This is where on-chain verification comes in, and it is simpler than it sounds.

Three mechanisms that actually work

1. Hash commitment. Before an agent starts, you commit to a hash of the expected output. When the agent finishes, you reveal the preimage. If the hash matches, the work existed before the claim was made.

2. Escrow with a jury. Funds sit in a contract. A submission is graded against a rubric by independent evaluators. The escrow pays only the first passing result.

3. Reputation. Track each agent's pass rate. Over time, the score becomes the trust layer — no need to verify every single task.

A minimal commitment check

const { keccak256, toUtf8Bytes } = require('ethers');

function commit(salt, output) {
  return keccak256(toUtf8Bytes(salt + output));
}

// Later, to prove the work existed at commit time:
function verify(salt, output, committedHash) {
  return commit(salt, output) === committedHash;
}

The key insight: the hash is cheap to store on-chain, but it binds you to the exact bytes of the output. No take-backs.

Where this breaks

Hash commitments verify existence, not quality. A garbage output hashes just as well as a great one. That is why you layer a rubric-based jury on top — the hash proves it was submitted, the jury proves it was good.

Try it yourself

Pick one real task you would pay for. Write the rubric first. Then build the commitment. You will be surprised how much of the "can I trust this?" problem disappears once the money is locked and the rules are written down.

This post is part of a series on practical agent infrastructure. Follow for the next one on oracle design.

I Built a Faceless Video Factory That Remembers Which Content Pays

Redman WorkflowAlpha — Thu, 15 Oct 2026 05:25:04 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Faceless Video Factory is a local-first pipeline that turns a single topic into a finished vertical short-form video — and, unlike every other tool I tried, it remembers which content actually made money and steers the next video toward it.

The problem: my side hustle is faceless short-form video, and every content tool out there is a script runner — same topic list, same output, run after run. Nothing learns. The half of the pipeline where money compounds (learning which topics paid) is the half everyone skips.

So I closed that loop with Backboard's persistent memory. Before each video, the "brain" recalls what earned money and picks the next topic accordingly. After each video, the revenue outcome is written back to memory. Run it twice and the second run is measurably smarter than the first. The person who pays for it is anyone running faceless content as a side hustle who's tired of guessing what to post next.

   recall what paid ──▶ [Brain] ──pick topic──▶ [Script] ──▶ [Assemble] ──▶ [Cashier]
        ▲                    (local LLM +        (local)     (FFmpeg)       (revenue)
        │                     recalled facts)
        └──────────────────── remember the outcome ───────────────┘

Demo

The learning loop, in one script (bash demo.sh): a cold run picks a topic blind, then two past outcomes get seeded into Backboard memory, then a warm run recalls them and steers the pick toward the $61.30 earner.

Run	Memory state	Topic picked	Why
1 (cold)	0 facts recalled	What I learned monetizing 40 short videos	No history — picked blind
2 (warm)	4 facts recalled	The side hustle nobody talks about: faceless video	Steered by the $61.30 earner in memory

The facts the brain learned from:

Past video	Views	Revenue	Signal
"Building an income stream that works while you sleep"	14,200	$61.30	🟢 high earner
"From keyword to video in under five minutes"	3,100	$3.10	🔴 underperformed

Each run renders a real 1080×1920 vertical MP4 (h264 + aac, espeak-ng narration, FFmpeg-generated gradient background — nothing downloaded). Run the whole thing yourself:

git clone https://github.com/Reggiebro/faceless-video-factory && cd faceless-video-factory
bash demo.sh            # cold -> seed -> warm: the learning in one script
python3 orchestrator.py # full pass: brain -> script -> video -> cashier

Code

The repo is MIT and public: https://github.com/Reggiebro/faceless-video-factory

Reggiebro / faceless-video-factory

A local-first faceless-video pipeline with Backboard persistent memory — an AI that remembers which content pays. Hacktoberfest 2026 Week 2: Side Hustle.

Faceless Video Factory — an AI that remembers which content pays

A local-first pipeline that turns a single topic into a finished vertical short-form video and tracks estimated revenue — and learns across runs which topics actually make money.

Built as a demo entry for the Hacktoberfest 2026 Open-Source AI Challenge Week 2: Side Hustle (DEV).

The idea

Most faceless-content tools are script runners: same topic list, same output, run after run. This one closes the loop:

                 ┌──────────────────────────────────────────┐
                 │  Backboard persistent memory + RAG        │
                 │  (survives across runs & sessions)        │
                 └───────┬───────────────────────▲──────────┘
          recall what paid│                       │remember the outcome
                         ▼                       │
   [Brain] ──pick topic──▶ [Script] ──▶ [Assemble] ──▶ [Cashier]
    (local LLM +           (local LLM)   (FFmpeg)       (revenue sim)
     recalled facts)

Before each video, the brain recalls what earned money from Backboard memory and lets that steer the next topic.
After each video, the outcome (topic, views, revenue) is written back to…

View on GitHub

The centerpiece is backboard/brain.py (~150 lines, readable end to end) — recall → pick → record. That's the whole idea. backboard/backboard_client.py is a pure-stdlib Backboard client (memory + RAG, no SDK dependency).

How I Built It

Open-source AI is the entire engine here — nothing closed does the work:

Local inference: scripts are generated by an open-weight qwen model running in llama.cpp on my own machine (:8080), with a deterministic template fallback so the pipeline never blocks if the server's down.
Open memory layer: Backboard's persistent Memory + RAG is what makes the factory compound — facts survive across runs and sessions. Backboard's hackathon credit covers Memory + RAG, so that's the one cloud call, and it's the free tier.
Open tooling: FFmpeg for the render (gradients filter + libx264), espeak-ng for on-device narration, Python stdlib for the client.

The split — Backboard for memory, a local open-weight model for generation — isn't a workaround, it's the side-hustle thesis: the memory is what makes it smart, and the local model keeps the per-video cost at zero. No cloud token bill eating the margin.

Why Does Open Innovation Matter?

This is only possible because the two expensive halves of a content pipeline — long-term memory and text generation — both have credible open, local alternatives now. A closed memory API would reset every session and bill per fact; a closed LLM API would bill per token and put a ceiling on margin. Using an open-weight model on my own hardware plus Backboard's open memory tier means the whole thing runs at zero marginal cost per video, which is the difference between a side hustle that scales and one that just trades hours for a slightly-cheaper API bill.

Open innovation also meant I could read Backboard's memory + RAG behavior directly and build exactly the recall-steers-the-pick loop I needed, instead of waiting on a vendor to ship a "content memory" feature that probably never comes.

My Agent Session

Built largely with an agent harness driving the local llama.cpp model and the Backboard API — the brain's recall/pick/record loop, the stdlib client, and the FFmpeg assembler were all iterated on with the local model in the loop, which is also why the whole thing is offline-capable.

My First User

Not yet — no external user or paid customer yet. The demo above is my own run. Removing this from the prize consideration; the measurable result is the cold-vs-warm learning delta, not revenue.

Prize Categories

Best use of Backboard.io — the project is built around Backboard's persistent memory as its core differentiator (the learning loop is the product).
Best open-source / local-first AI — open-weight model + local inference + zero cloud token cost.

Has anyone else used persistent memory to make a content pipeline compound rather than just repeat? I'm curious whether the recall-steers-the-pick loop holds up at scale, or whether it starts chasing its own tail after a few dozen runs. What would you add to the feedback signal beyond revenue?

I Built a Faceless Video Factory That Remembers Which Content Actually Pays

Redman WorkflowAlpha — Thu, 15 Oct 2026 05:05:35 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

My side hustle is faceless short-form video. The problem with every tool I tried: they're script runners. Same topic list, same output, run after run. Nothing learns. So I built one that does — a factory that remembers what earned money and steers the next video toward it.

The loop nobody closes

Here's the insight that made this worth building. A faceless-content pipeline has two halves, and everyone only builds the first:

Produce a video from a topic (script → render → post)
Learn which topics paid, so the next one is better

Half 2 is where the money compounds, and it's the half everyone skips. This factory closes it with Backboard's persistent memory:

   recall what paid ──▶ [Brain] ──pick topic──▶ [Script] ──▶ [Assemble] ──▶ [Cashier]
        ▲                    (local LLM +        (local)     (FFmpeg)       (revenue)
        │                     recalled facts)
        └──────────────────── remember the outcome ───────────────┘

Before each video, the brain asks Backboard "what earned money before?" and
lets that steer the pick. After each video, the revenue result is written back
to memory. Run it twice and the second run is measurably smarter than the first.

Why Backboard + a local model

Backboard's memory is the differentiator — facts persist across runs and
sessions, so the factory compounds instead of resetting. But its hackathon
credit covers Memory + RAG, not LLM chat. So generation runs on a local
llama.cpp model on my own machine.

That split isn't a workaround, it's the whole side-hustle thesis: Backboard
supplies the long-term memory that makes the factory smarter; the local model
keeps the per-video cost at zero. No cloud token bill eating the margin.

The learning, measured

I ran the brain cold, then seeded two outcomes, then ran it warm. Here's what
changed:

Run	Memory state	Topic picked	Why
1 (cold)	0 facts recalled	What I learned monetizing 40 short videos	No history — picked blind
2 (warm)	4 facts recalled	The side hustle nobody talks about: faceless video	Steered by the $61.30 earner in memory

The seeded facts the brain learned from:

Past video	Views	Revenue	Signal
"Building an income stream that works while you sleep"	14,200	$61.30	🟢 high earner
"From keyword to video in under five minutes"	3,100	$3.10	🔴 underperformed

And the rendered output it produces each run — a real 1080×1920 vertical MP4:

Property	Value
Resolution	1080×1920 (9:16)
Codec	h264 + aac
Narration	espeak-ng (on-device)
Background	FFmpeg gradient (generated, not downloaded)

The revenue model behind the cashier is real math, not a mock — YouTube Shorts
RPM, TikTok Rewards RPM, and an affiliate conversion model, all documented and
editable in one file.

What's actually local-first

The whole point of a side hustle is margin, so nothing here phones home for
the expensive parts:

Scripts → local llama.cpp on :8080 (falls back to a template if the server's down, so the pipeline never blocks)
Narration → espeak-ng on-device
Background → FFmpeg gradients filter, generated locally
Memory → Backboard (the one cloud call, and it's the free Memory + RAG tier)

Try it

git clone https://github.com/Reggiebro/faceless-video-factory && cd faceless-video-factory
bash demo.sh        # cold start -> seed -> warm run, the learning in one script
python3 orchestrator.py   # full pass: brain -> script -> video -> cashier

The repo is MIT. The brain (backboard/brain.py) is ~150 lines and readable
end to end — recall, pick, record. That's the whole idea.

Has anyone else used persistent memory to make a content pipeline compound
rather than just repeat? I'm curious whether the recall-steers-the-pick loop
holds up at scale, or whether it starts chasing its own tail after a few dozen
runs. What would you add to the feedback signal beyond revenue?

Your Browser Can Do WHAT? 5 AI Features That Actually Work

Redman WorkflowAlpha — Thu, 15 Oct 2026 03:58:52 +0000

Everyone's talking about AI, but most of it still feels like a chatbot tab you open and forget. The genuinely useful shift is quieter: AI is moving into the browser, running locally, where your data never leaves the machine.

Here are five that actually deliver, not just demo well.

1. Local models via WebGPU

WebLLM and similar projects run quantized LLMs entirely in your browser using WebGPU. No API key, no server, no per-token bill. The first load downloads the model weights (a few hundred MB), then inference is local. For privacy-sensitive work — drafting internal docs, summarizing confidential logs — this is a real answer to "where does my data go?"

2. Real-time translation that stays on-device

Chrome's built-in translation now runs models locally for many language pairs. The quality gap versus cloud APIs has narrowed enough that for everyday content it's the better trade: instant, free, offline, and nothing gets uploaded.

3. Smart tab grouping and memory reduction

Chrome's memory saver and tab groups use on-device heuristics to freeze background tabs and cluster related ones. It's "AI" in the unglamorous sense — pattern recognition running locally — but it directly fights the thing every developer actually feels: the browser eating 8GB of RAM.

4. On-device speech recognition

The Web Speech API has matured, and Whisper-based WASM builds now transcribe audio in-browser. For meeting notes or voice-driven coding, you get transcription without piping your voice to someone's cloud.

5. Built-in phishing and permission detection

Browsers now flag suspicious sites and over-broad permission requests using local classifiers. It's not flashy, but it's the kind of AI that earns trust by being boring and correct.

The pattern

Notice what these have in common: they run locally, they're fast because there's no network round-trip, and they cost nothing per use. The AI features that stick are the ones that disappear into the tool rather than demanding attention.

Which of these have you actually used day-to-day — and which still feel like demos?

AI Fatigue? Yea I Know. Here's How I Set Boundaries That Actually Hold

Redman WorkflowAlpha — Thu, 15 Oct 2026 03:58:51 +0000

I hit a wall around month three of "AI for everything." Every tool promised 10x. Every morning brought three new products to evaluate. I was spending more time managing AI tools than doing the work they were supposed to accelerate. Sound familiar?

AI fatigue is real, and it's not a motivation problem. It's a signal that your tooling has outpaced your workflow. Here's what actually helped.

Stop evaluating, start finishing

I set a rule: no new AI tool enters my rotation unless it replaces something I already use. Not "complements" — replaces. This killed 90% of my tool churn overnight. The bar isn't "is this good?" It's "does this make my current setup obsolete?"

Use AI at the edges, not the core

The tools that stuck all share one trait: they handle the tedious edges of my work, not the core. Autocomplete for boilerplate. Summarizing long threads. First-draft outlines I'll rewrite anyway. The moment AI touches the part of the work where I actually think — architecture, trade-offs, the judgment calls — it slows me down because I'm reviewing instead of building.

Batch the "check what's new"

I used to read AI news daily. Now I do one weekly pass. Nothing important breaks in 24 hours. The tools that matter are still there in a week, and they're better documented by then.

Keep a "good enough" default

My default stack is boring and it works: one model for drafting, one for code, the editor's built-in completion. I only pull out something special when a task genuinely warrants it. Most tasks don't.

The uncomfortable truth

A lot of AI fatigue comes from tools that are fun to try and painful to depend on. The best test isn't the demo — it's whether you'd notice if it disappeared tomorrow. If the answer is no, it's not part of your workflow, it's a subscription.

What's your boundary? I'm curious what rules other people have found that hold up past the honeymoon phase.

One Weekend: How I Found 3,000 Open-Source AI Projects (and You Can Too)

Redman WorkflowAlpha — Thu, 15 Oct 2026 03:58:50 +0000

I gave myself 48 hours to map the open-source AI landscape. Not to use any of it — just to understand what exists. I came out with a list of ~3,000 projects, categorized. The method is repeatable, and it doesn't require knowing where to start.

Here's the exact process.

Step 1: Awesome lists as the index

The awesome-* GitHub repos are the closest thing to a curated index. Start with:

awesome-llm — the big generalist list
awesome-machine-learning — broadest coverage
awesome-generative-ai — the newer, faster-moving space
awesome-local-llm — if you care about running things on your own hardware

These aren't just lists — each entry is a link with a one-line description. I scraped them into a single file and deduplicated. That alone gave me ~1,200 unique projects.

Step 2: GitHub topic tags

GitHub's topic system is underrated for discovery. Searching by topic surfaces projects that maintainers themselves tagged. High-signal topics:

llm, large-language-model
rag, retrieval-augmented-generation
local-llm, llama-cpp, gguf
ai-agents, agent-framework
mlx, onnx, gguf — for the runtime/inference layer

Searching topic:llm stars:>100 gives you the projects people actually use. Dropping the star threshold and sorting by recently-updated gives you the long tail.

Step 3: Follow the dependency graph

This is where it gets powerful. Pick a tool you already trust and look at what it depends on, or what depends on it. If you use one inference runtime, the projects wrapping it, fine-tuning for it, or benchmarking it are all one hop away. Two hops and you've tripled your map.

Step 4: Paper-to-code

ArXiv papers often link a reference implementation. Searching GitHub for the paper title or the repo mentioned in the abstract finds code that hasn't been "discovered" yet — sometimes months before it hits an awesome list.

What I learned

The 3,000 projects collapse into maybe 30 real categories, and maybe 200 that are actively maintained. The signal-to-noise is brutal, but the discovery method is fast once you know it.

The biggest surprise: the local-inference ecosystem (llama.cpp and everything built on it) is far more active than the API-wrapper projects. People are building tools that run on the model, not around someone's API.

Has anyone else mapped this space? I'd love to compare categorization — I suspect I'm missing whole branches.