DEV Community: Redreamality

Can you trust your agent's score? 9 notes on leaderboards, reward gaming, silent tool failures and misbehaving graders

Redreamality — Sat, 14 Nov 2026 02:09:43 +0000

A passing score is a claim, and claims need checking. Over the past few weeks I kept reading papers that poke holes in the numbers we use to judge AI agents: leaderboards that rank systems well but models badly, agents that report success after a tool already failed, outputs that are correct while the execution path is not, and graders that misbehave themselves. These nine notes are my attempt to group that work in one place.

The order runs from "can we trust the score at all" to "can we trust the thing producing the score". Each section is my own short summary; the figures come from the papers and reports as cited in the longer write-ups on redreamality.com, which go much deeper and include checklists.

1. More tasks won't always fix a leaderboard

The first question is what a leaderboard number even supports. Hardy, Azam, Reuel, Kochenderfer and Koyejo (arXiv:2610.00651) argue that reliability depends on the claim. Using a Bayesian variance decomposition from generalizability theory over 22 benchmarks from the Holistic Agent Leaderboard, they find that rankings of deployed systems are quite stable (Eρ² around 0.935–0.994), while rankings of the underlying models are far shakier (0.148–0.841). Adding more of the same kind of task lifts ranking reliability by at most about 0.097. Pooling diverse benchmarks helps much more, taking one setting from 0.44 to 0.75 and cutting projected evaluation cost by roughly 83%.

Longer read: why agent leaderboards answer some questions and not others

2. What a passing Lean proof actually verifies

In October OpenAI published 700+ AI-generated math manuscripts with Lean formalizations for part of them, then withdrew three after a sign error surfaced, and repaired or corrected many others. The write-up splits "AI proved X" into five layers, from the informal statement down to the checked formal proof, and shows which layer a proof checker really certifies. A green Lean build tells you the formal statement follows; it does not tell you the formal statement says what the paper claims. The post ends with an audit checklist for reading such announcements.

Longer read: five layers between "AI proved it" and a checked proof

3. CheatBench: agents that game the reward

CAIS's CheatBench (arXiv:2609.36308) sets up ten environments where a shortcut exists that violates honest-work expectations: reading forbidden answers, copying another submission, touching the grading channel. On the current leaderboard, overall cheating rates run from about 11.2% to 78% across nine frontier agents, and every evaluated agent cheated in at least one setting. A low rate only means the agent skipped the traps that were planted, not that it never cheats. The note stays at the level of mechanisms and aggregate results and closes with a harness checklist.

Longer read: how CheatBench measures reward gaming

4. CIR: is a harness "refresh" a rescue or a harm?

When a long-running agent slips, the harness may re-observe the environment. Averages say this helps by a few points, but the same move can rescue a failing run or derail a good one. Xiao et al. (arXiv:2610.00372) fork each decision from the same state, with and without the refresh, and train a small router that decides from pre-decision information alone. On ALFWorld with Qwen3-14B, success goes from 70.33% (never refresh) to 73.33% with the router, clean trajectories are left alone, and the gain on stale two-step observations reaches 9.33 points. The idea that carries over is to evaluate interventions causally, not by their average.

Longer read: treating harness recovery as a causal decision

5. When tools fail, agents still claim success

A browser times out and the reply says "I verified the page". The Failure-Transparent Agents benchmark (arXiv:2609.35732) fixes the failed observation and the evidence needed for honest completion before the model answers, then audits what it claims afterwards. Across six models and 3,600 human-annotated responses, false success claims fall from 22.8% at baseline to 9.3% with a transparency instruction and 0.8% with an explicit evidence contract. That is a cheap change for most harnesses.

Longer read: failure transparency and the evidence contract

6. Correct output does not mean safe execution

SINGED (arXiv:2609.35889) looks at the opposite case: the artifact is right, but the path that produced it did something forbidden, such as an unauthorized outbound call or a write outside the output directory. The authors call these functional counterfeits. Across 7,549 audited trials, a counterfeit ranked first gets executed 45% of the time, and comparing candidates against each other cuts layered failures from 15.7% to 4.2%. Task checkers and process checks need to be separate things.

Longer read: functional counterfeits and why output checks miss them

7. ToxicBench: when tools silently lie

Here the tool call succeeds, but a proxy rewrites what comes back while the source data stays untouched. Tao and Yin (arXiv:2609.37153) pair clean and poisoned environments over numerical, label, schema and retrieval errors. On 118 tasks, poisoning drops task success by 26–39 points, and the blind-compliance rate is 0.38, 0.53 and 0.27 on LangGraph, smolagents and AutoGen. The useful distinction is between an agent that never checks and one that checks and then adopts the wrong value anyway. (Not to be confused with the image-safety benchmark of the same name.)

Longer read: silent tool poisoning in data agents

8. Every agent is right and the team is still wrong

Xin Heng's paper (arXiv:2610.02036) makes a sharp claim: local validity does not imply global coherence. In a three-role team with a shared budget of 20 command runs, ordinary teams overspend in 5 of 5 runs; showing the live count still leaves 4 of 5 over; enforcing the limit at commit time brings it to 0 of 5. When the deciding fact is hidden, extra reasoning, roles or votes do no better than a one-in-three guess, and one sentence restoring the fact brings back 40/40. Invariants need an owner in the harness, not more debate.

Longer read: global coherence as its own failure class

9. When the grader is the one misbehaving

The last note turns to the measurement layer itself. Among OpenAI's October 9 misalignment reports was a case where an RL grader that couldn't find its files fabricated scores and damaged its own environment to force a reset; other models got around GET-only restrictions and still earned reward. Read next to METR's argument that agent transcripts and log viewers should be handled as untrusted, security-critical infrastructure, and a SoK that models loss of control as competing hazards, the pattern is clear: graders, resets, logs and reward records are where incidents keep landing. The post closes with a monitoring checklist for graders, safe stops and audit trails.

Longer read: the safety layer that trusts measurement too much

Read together, these split "the agent scored well" into separate questions: what the score supports (1, 2), whether the agent earned it honestly (3), whether interventions helped (4), whether the report matches the evidence (5, 7), whether the process was clean (6), whether the team as a whole stayed within its constraints (8), and whether the grader can be trusted (9). Most harnesses I've seen answer two or three of these.

I wrote a Korean overview of several of these papers on velog.

Building with AI creative tools: 7 notes on image-to-prompt, lip-synced avatars, video watermarks, Flowith and OpenCode for writing

Redreamality — Fri, 13 Nov 2026 02:09:22 +0000

Most AI writing online is about chat and code. The tools I actually reach for on side projects are a bit different: something to reverse-engineer a prompt from a picture, a way to make a talking-head video without paying per minute, a canvas that mixes many image models, and a coding agent that turns out to be a decent writing partner. These seven notes cover that ground, roughly in the order you'd meet them while making a piece of content: images, video, workspaces, writing, and finally where to look for the next idea.

Each section is my own summary of a public page, not official material from the projects, and details such as credit counts or model lists are what the page said when I saved it. Every section links to the longer note on redreamality.com.

1. ImagePrompt.org: start from a picture, not a blank prompt box

When you like an image but can't put its style into words, an image-to-prompt tool does the describing for you. ImagePrompt.org takes an upload and writes back a text prompt covering the subject, setting, art style, palette, lighting and mood, and sometimes pose, composition and camera angle. You can ask for a general description or for output shaped for Flux, Midjourney or Stable Diffusion. Free users get five Prompt Credits a day, and the reset time shows in your local timezone. The site says uploads are processed only long enough to write the prompt and then deleted. NSFW images are blocked, and abstract or very busy pictures tend to get vaguer descriptions, so treat the result as a first draft you edit rather than a finished prompt.

2. A talking-head video on your own machine with Easy-Wav2Lip

This tutorial, from a Chinese AI forum, makes the case that a narrated or live-selling style avatar video doesn't need a paid online service. The recipe is simple. Film yourself for 20 to 30 seconds in front of a green screen, with the phone on a tripod, speaking at an even pace and keeping your hands fairly still. Record the voice yourself or generate it with CapCut's text-to-speech, exporting audio only as a .wav. Then run Easy-Wav2Lip locally, load the clip and the audio in its web UI, set quality to Enhanced and turn on mouth tracking. If the teeth come out missing, switching to the Wav2Lip_GAN model is the suggested fix. The last step is keying out the green in CapCut (chroma key) or After Effects (Roto Brush), then adding a background, subtitles and music.

3. DeMark-World: how video watermark detection and inpainting fit together

DeMark-World, which grew out of SoraWatermarkCleaner, is an open-source framework that finds and removes the visible watermarks AI video models stamp on their output. The README lists Sora, Runway, Pika, Kling, Gemini/Veo and Luma. I keep the note mostly for the pipeline, which is a neat two-stage design. A YOLO model detects the watermark box frame by frame, and frames where detection misses borrow an averaged box from their neighbours. Then an inpainting backend fills the region: LaMa if you want speed, E2FGVI-HQ if you need the fill to stay consistent across frames. It ships a Streamlit UI, a Python API, a CLI and a REST server (port 5344 in the example), plus a GPU docker-compose file. It's Apache 2.0, but those watermarks exist to show a clip is AI-generated, so check the model provider's terms and be honest about where your footage came from.

4. Flowith as a canvas for many image models

Flowith calls itself an agentic workspace, and its home page shows why: one canvas gives you flows, a flow library, media history, a "Knowledge Garden" and a knowledge market. The image side is the most crowded part. When I saved it, the model picker listed Seedream 5.0 Pro, GPT Image 2.5 and Grok Image 2.0 among many others, some marked NEW and some discounted. Next to the models sit small single-purpose apps such as background removal, relighting, upscaling, crop and resize, virtual try-on and social post templates. The appeal is not having to switch sites every time you want to compare two models on the same brief. The model list changes often, so check the live page before you plan around one.

5. Flowith knowledge bases you can buy, through one example

The other half of Flowith is its knowledge market, where people sell curated knowledge bases that the AI can answer from. The page I noted is a bioinformatics base from a creator listed as Yiming-Shi-PhD (BrainMed Lab). It promises to pull frameworks, methods and open debates out of the literature, spot gaps and trends that suggest research directions, and lay out a field visually. The useful design detail is the side-by-side trial: the same question answered by the "standard" AI and by the AI backed by the knowledge base, so you can judge the difference before you pay. Purchases are one-off with lifetime access and updates, resale is forbidden, and the creator receives 80% after tax. It's a small but concrete example of packaging your expertise as context rather than as a course.

6. OpenCode as a writing partner: Plan first, then Build

A Chinese OpenCode tutorial has a lesson that has nothing to do with code: using the agent to write articles. The complaint it answers is familiar. Ask the AI for a finished piece in one shot and quality swings wildly. The fix is three stages. In Plan mode you agree on the topic, structure and outline without touching files. In Build mode the agent writes the draft into a file. You then stay in Build mode and iterate, pointing at the draft with @filename to revise, polish or expand. The lesson includes a prompt template that casts the AI as a senior content strategist and returns positioning, a section outline, key points per section and alternative titles. If the voice drifts between sessions, it suggests pinning style preferences in AGENTS.md, the same file you'd use for code conventions.

7. BuilderPulse: one build idea a day, with its sources

To close, something for deciding what to make next. BuilderPulse is a daily brief for indie hackers and micro-SaaS founders. It says it cross-checks more than 300 public signals each day, from Hacker News, GitHub Trending, Product Hunt, Hugging Face, Google Trends, Reddit, Indie Hackers, Lobsters and DEV, and boils them down to one concrete idea, a reason why it matters now, and links to the sources. The issue I saved suggested a local-first memory system for agents that distils sessions into searchable notes, pointing to a 1,900% week-over-week jump in searches for agent memory. Whether or not you build that, the format is worth copying: one idea, one reason, evidence attached. The content is CC BY-NC 4.0, so commercial reuse needs the author's written permission.

Images (1), video (2 and 3), workspaces (4 and 5), writing (6) and choosing what to build (7): that covers most of a small content project from first sketch to the next idea. Pick the step where you lose the most time and start there.

A Japanese version of this list is on Qiita.

From sketch to launch as a solo builder: 8 notes on journey maps, PWA packaging, free SEO tools and AI product revenue

Redreamality — Wed, 11 Nov 2026 02:10:30 +0000

There's a stage in every solo project where writing code stops being the slow part. The slow part becomes drawing how people will actually use the thing, deciding where to ship it, and figuring out how anyone will find it. These are eight notes I keep for that stretch, ordered roughly the way the work goes: design, packaging, getting found, and reading the market.

None of this is official material from the services mentioned. Each section is my own summary of a public page, and the numbers are whatever the page said when I saved it. The market figures in the last section are estimates, and the source says so itself. Each section ends with a link to the longer note on redreamality.com.

1. User journey maps: draw today and tomorrow separately

Before adding features, it helps to put on one page how a user moves through the product right now and where they get stuck. A guide from the Chinese product-management site Woshipm defines a journey map as a left-to-right timeline told from the user's side, a story of how they reach a goal. It has three parts: a user model, the experience itself (key activities, concrete actions, touchpoints, an emotion curve and pain points), and the opportunities you pull out of it. The idea I use most is splitting the map in two. The As-Is map describes the current journey and lives in the problem space. The To-Be map describes the fixed version and can drop the emotion curve and pain points, keeping only activities, actions and touchpoints. When several roles are involved, the guide uses swimlanes and arrows to show who depends on whom.

2. Overflow: turn screens into a flow you can present

If a journey map is mostly words, Overflow is for the screens themselves. You import designs from your design tool with layers and prototype links intact, then wire them together on a canvas as a user flow. There are three ways to look at the result: a bird's-eye canvas of the whole flow, a prototype view that steps through one screen at a time, and a story view for interactive, self-guided walkthroughs. For async review it has shared folders, editor invites, full version history and comments you can pin anywhere. You can also push a project to Overflow Cloud, get a public link and embed it in a blog or internal tool, then keep iterating and update the link when you're ready. The site says more than 500,000 designers and PMs use it. Even if you work alone, a published flow is a good reference for future you.

3. Maoken: free-for-commercial-use Chinese fonts

Build anything for Chinese-speaking users and font licensing is the first wall you hit. Maoken collects Chinese fonts that are free for commercial use; it listed 848 when I saved the note. You can filter by language (Chinese, Latin, Japanese, Korean), by style (sans, serif, rounded, calligraphy, handwriting) and by license: author statement, OFL, IPA, MIT, GPL, CC-BY, CC0 and others. Entries explain derived fonts too, such as one built on Source Han Serif. There's a copyright check and a list of fonts whose status is questionable, which is the part I'd actually lean on. One catch: the site also sells its own fonts (9.9 to 79 yuan) on the same pages, so read the label before you download.

4. PWABuilder: get a web app into the app stores

If you don't have time to write a native app, wrapping a PWA for the stores is the short path. PWABuilder's docs split the toolkit into three pieces. PWA Starter is the team's own production template, with a manifest and a Workbox-based service worker already in place. PWABuilder Studio is a VS Code extension that creates a new PWA or converts an existing web app, manages the manifest, service worker and icons, and validates the app against the store checks. PWABuilder.com itself generates packages you can upload to the Microsoft Store, Google Play and the iOS App Store, plus side-loadable packages for testing first. My note came from the Google Play packaging page, but knowing those three pieces is enough to find your way around.

5. Thirty free SEO tools for a zero budget

Once it's live, search has to find it. SEO consultant Lauren Galvez's list of 30 free tools covers technical, on-page, off-page and local SEO. Alongside the Google staples (Search Console, Analytics, Keyword Planner, PageSpeed Insights, Rich Results Test) it includes Screaming Frog, free for sites up to 500 URLs, Ahrefs Webmaster Tools, Semrush's free tier, Merkle's SERP simulator for checking whether titles get cut off, and generators for robots.txt, XML sitemaps and hreflang tags. It's upfront about free-tier limits, like 500 URLs for the sitemap generator and 50 URLs at a time for hreflang. For a small site it reads like a sensible first checklist.

6. Wanwei Ads: contextual ads for a developer audience

If you pay for reach with a developer product, ads that match the article usually fit better than big banners. Wanwei Ads is a Chinese ad network aimed at developers, product and ops people, and gamers, serving across sites such as the CSDN blog, W3Cschool, Vue.js and ThinkPHP. The page says it avoids large banners and screen-hogging formats, matches only on site type and page topic, and doesn't tag individual users. Impressions are free and you pay per click, which is easy for a small team to try. The stats on the page were 5.51 billion total impressions, 1.877 million total clicks and a 37% advertiser renewal rate. There's also a publisher signup, so if you run a tech blog it's worth reading from the other side.

7. A course outline for shipping to overseas markets

This one isn't a tool. I kept it as a map of what people in the Chinese indie scene learn when they set out to build for overseas users. It's the sales page for an AI-assisted coding course built around Cursor, and the curriculum runs in this order: prep, tools, Cursor development, full-stack, real projects, SEO, then promotion and operations. The stack it teaches is Next.js, Tailwind CSS, shadcn/ui, Better Auth, Stripe, Resend, Vercel, Cloudflare and Zeabur, which is a fair snapshot of what solo builders reach for today. There's a free tier and two paid tiers (1,299 and 1,999 yuan), so I treat it as a hint about learning order, not an endorsement.

8. Gefei's estimates of which overseas AI products make money

Last, the market. Gefei, who builds SEO-driven AI tools for overseas users, put together a deck that sorts AI products by input and output (text, image, audio, video and so on) and estimates traffic and revenue for each category. The estimates combine traffic heuristics, visits to payment domains, ad spend and known revenue of similar products, and the deck says plainly that they're rough. With that caveat, July figures in it include about 61.27 million monthly visits for Suno, about 10.67 million for Midjourney and $570K MRR for Jenni AI. What I find useful isn't the exact numbers but the relative size of each category and the way the estimate is built.

Put together, design (1 and 2), look and distribution (3 and 4), getting found (5 and 6), and learning and market sense (7 and 8) cover most of the places a solo project stalls. Pick one and open it before your next release.

A Japanese version of this list is on Qiita.

Writing and publishing without leaving your editor: 7 notes on Slidev, Mintlify, Wenyan and AI-drawn diagrams

Redreamality — Mon, 09 Nov 2026 02:01:44 +0000

Most of what developers publish isn't code: it's slide decks, product docs, PDFs with no bookmarks, blog posts and architecture diagrams. The friction is usually in the last mile, where plain text has to become something a reader can open. I keep short notes on the third-party tools that remove that friction. These seven are the ones I come back to; the opinions are mine, the projects belong to their authors.

Slides as a Markdown file

If a deck can live in git, it can be reviewed, diffed and rebuilt. Slidev takes that literally: one slides.md, extended Markdown, real code blocks, Mermaid diagrams, and per-slide HTML/CSS when the default look isn't enough. It exports to PDF or PNG, or builds into a single-page app you can host statically. The write-up I keep is about deploying to Cloudflare Pages, including the Playwright detail needed for a downloadable PDF. Details in my Slidev notes for people who dislike PowerPoint.

Docs that are meant to be read by agents too

Mintlify pitches its hosted docs as infrastructure for both people and AI agents, with self-updating content, access control and connections to existing systems. The page leans on adoption numbers and customer case studies, so read it as a vendor's claims rather than a benchmark. Still, the framing — docs as something an agent queries, not just a site humans skim — is worth noticing. Here's what Mintlify says about itself.

One Markdown source, several Chinese platforms

Wenyan is a Markdown formatter that renders for WeChat Official Accounts, Zhihu and Toutiao from the same source. It ships as a desktop app, a web app, a CLI for CI pipelines and an MCP server, which makes it a rare case where the same renderer serves a hand-written post and an automated pipeline. I summarised the whole family in this overview of the Wenyan toolchain.

Letting an AI client push a draft to WeChat

The MCP flavour is the interesting one if you already work through Claude Desktop. It converts Markdown to WeChat rich text, uploads local images and the cover, and drops the result in the draft box, with theme changes by natural-language request. Two practical traps: you must set the app ID and secret as environment variables, and the machine's IP has to be on the account's allow-list or uploads fail. The setup is covered in the wenyan-mcp note.

Putting a table of contents back into a PDF

Plenty of PDFs, especially ones exported from TeX, have no outline, which makes a 400-page book painful to navigate. pdf.tocgen infers headings from font attributes and position: pdfxmeta extracts the heading metadata into a recipe, pdftocgen builds the ToC from it, and pdftocio writes it into the file. It won't help with scanned documents, which is the main limitation to know. The pdf.tocgen workflow is written up in my garden.

Diagrams from a sentence, still editable

smart-excalidraw-next turns a natural-language description into an Excalidraw diagram: flowcharts, architecture, sequence and ER diagrams, mind maps, 20+ types in all. Because the output is real Excalidraw, you tweak it on the canvas instead of re-prompting. You can bring your own OpenAI or Anthropic key, or an admin can configure a shared server-side model behind a password. It runs on Next.js and starts with pnpm dev. See the smart-excalidraw-next summary.

A blog with GitHub Issues as the database

The most frugal publishing stack in this list: each post is an issue, comments come from Gitalk, images live on a separate branch served by jsDelivr, and Vercel deploys the front end. Reading posts through GitHub's GraphQL API even gives you rendered HTML, so you skip the Markdown pipeline. The one rule is to keep the token out of the repo. The full recipe is in this GitHub-as-database blog guide.

What these have in common is that none of them asks you to leave plain text behind: slides, docs, WeChat posts, PDF outlines, diagrams and even a whole blog stay as files you can version. Pick the one that matches the friction you hit this week.

The coding-agent toolbox around the model: 8 notes on CLAUDE.md, mcp2cli, OpenCode and worktrees

Redreamality — Sat, 07 Nov 2026 02:12:07 +0000

Once you use a coding agent every day, the model itself stops being the main lever. What changes the experience is the stuff around it: how you write the instruction file, whether every MCP schema lands in context on every turn, how you split work across trees, and whether the UI the agent ships still looks like an AI demo. I keep short reading notes on that peripheral stack in my digital garden. These eight are the ones I reopen most. None of them are tools I built — they're third-party projects and posts, and the takes below are just my own.

Keep CLAUDE.md short and general

An LLM does not remember your codebase across sessions, so CLAUDE.md (or AGENTS.md) is the onboarding doc it rereads every time. The useful frame is WHAT / WHY / HOW: stack and layout, why the project exists, how to build, test and typecheck. Stuff that only matters for one task tends to get ignored — Claude Code even injects a system-reminder that context might be irrelevant — so the more specific the file gets, the more of it the model quietly drops. Prefer progressive disclosure (pointers to other markdown files, file:line instead of pasted snippets), leave style to linters, and write the root file by hand instead of trusting /init. I sketched the argument in my notes on writing a good CLAUDE.md.

Stop shipping every MCP schema every turn

Add a few MCP servers and the tool definitions alone start eating the context window. mcp2cli takes the opposite approach: at runtime it turns MCP servers, OpenAPI specs or GraphQL endpoints into a CLI, with no codegen. Claimed savings are 96–99% of the tokens you'd otherwise spend on schemas each turn. It handles OAuth (fetch, cache, refresh), passes secrets via env: / file: prefixes, can bake named connection configs, and has --json / --toon output aimed at LLMs. The mental model I like is simple — tell the agent "call the CLI when you need it" instead of stuffing every tool definition into the prompt.

When you do want MCP as the agent substrate

If you'd rather build on MCP than work around it, lastmile-ai's mcp-agent is the cleanest Python take I've found. It treats Anthropic's "Building Effective Agents" patterns (router, orchestrator-workers, evaluator-optimizer, swarm and friends) as composable pieces, manages MCP server lifecycles, and can grow a simple agent into a Temporal-backed durable workflow with pause, resume and retry — without changing the agent API. You can also expose the app itself as an MCP server for Claude Desktop or Cursor. More detail in this mcp-agent overview.

An open-source coding agent with permission tiers

For a terminal agent you can actually install many ways (npm, Homebrew, scoop, pacman, a desktop app), look at sst's OpenCode. What stuck with me is how it splits built-in agents by privilege: build is full-power, plan is read-only and asks before running bash, and @general is a subagent for multi-step search. Cutting permissions per agent rather than per tool call is a design I'd like more harnesses to copy. Here's my short OpenCode note.

Read other products' system prompts (carefully)

Curious what a well-tuned agent is being told under the hood? The community repo that collects system prompts, tool defs and model notes for Cursor, Devin, Replit, Windsurf, v0 and others is a useful comparison set — with the usual caveat that these are unofficial dumps, not vendor docs. At ~144k stars it's hard to miss. I use it when rewriting my own CLAUDE.md or tool descriptions; see the system-prompts collection write-up.

Design skills that scrub the "AI look"

Ask an agent to build a UI and you often get the same gradients and card stacks. Impeccable is a design-skills pack for coding agents (Claude Code, Cursor, Codex, OpenCode and others) with commands like typeset, layout, polish and audit, plus 61 detection rules aimed at the usual AI tells. The operational bit I liked: keep a PRODUCT.md and a DESIGN.md so later agents inherit the product constraints and visual system. Notes here: Impeccable design skills for AI harnesses.

Git worktrees as concurrent activity slots

On the human side of the workflow, matklad's write-up on git worktrees changed how I parallelize agent work. He doesn't treat worktrees as a branch substitute. He keeps five fixed ones — main (read-only snapshot for comparison), work, review, fuzz, scratch — and assigns each to an activity that can run at the same time. That maps cleanly onto "agent reviewing over here while I implement over there." Dig into how matklad uses git worktrees.

An extreme case: 2,500 PRs in a month

Finally, a different kind of signal: lauren's X thread on shipping 2,500 PRs to production in a month (originally meant for Cursor Compile in London). The claim isn't "type faster" — it's that weak type systems and lint rules only go so far, and once a codebase can formally verify itself, review stops being the bottleneck and shipping gets very fast. They're bullish on Bend for that reason. Not a playbook you copy tomorrow, but a useful upper bound on how much verification you can push onto the machine. Summary in my note on the 2,500-PR month.

Put together, the productivity of a coding agent seems to depend less on which model you pick and more on keeping instructions short, not polluting context with tool schemas, giving concurrent work its own trees, and moving verification onto something deterministic. If any of these look useful, the notes above link through to the original repos and posts.

Pages I open on day one of a new project: 8 notes on free-for-dev, public-apis, offline Docker pulls and SQLite at 4M QPS

Redreamality — Thu, 05 Nov 2026 02:10:47 +0000

When I start a new side project, the same handful of pages end up open in my browser before I write any code. Some are giant lists that save hours of searching, a couple are small tools that fix one annoying problem, and one is a benchmark write-up that changed how I think about databases. I keep a short reading note on each in my digital garden, and these eight are the ones I return to most.

Lists worth bookmarking before you build

free-for-dev. This is the list I check before paying for any hosted service. It collects SaaS, PaaS and IaaS offerings that have a real free tier, and it's aimed at people doing infrastructure and DevOps work. The inclusion rules are what make it trustworthy: only hosted services count (no self-hosted software), a free trial doesn't qualify, any time-limited free tier has to last at least a year, and services that lock TLS behind a paid plan are rejected. It covers the big clouds (Google Cloud, AWS, Azure, and Oracle's generous Always Free tier) alongside code hosting, CI, and a long tail of APIs. My notes on the free-for-dev list and its inclusion rules summarize the first part of it.

public-apis. If you need test data or want to wire a quick demo to something real, the public-apis repository is the usual starting point. It's a community-maintained, MIT-licensed collection of free APIs grouped by topic, and with roughly 485k stars it's one of the most-starred repositories on GitHub. I mostly use it to answer "is there a free API for this?" in under a minute. Here's my short entry on public-apis.

awesome-cto. This one is less about code and more about the job around it. It's an opinionated reading list for CTOs and VPs of engineering, tilted toward startups and fast-growing companies. You'll find essays on how the CTO role differs from VP Engineering, how a founder-CTO's job changes over time, hiring and interview loops, engineering management, architecture choices like trunk-based development and microservices, and the business side, including fundraising and technical due diligence. See what's inside the awesome-cto reading list.

SaaS Starter Stack. For anyone trying to ship a small paid product, this repository lists free or cheap building blocks by layer: frameworks (Astro, Next.js, Nuxt, Remix, SvelteKit), boilerplates, databases such as Supabase and Pocketbase, hosting from Vercel to Hetzner and Coolify, payments through Stripe, Lemon Squeezy or Paddle, plus analytics, feedback, live chat and email tools. It also includes interviews with founders whose products make at least $500 in monthly recurring revenue, which is the part I found most useful. I wrote up the SaaS Starter Stack by layer.

Small tools that remove one headache

docker-pull-tar. Moving container images into a machine with no internet access is a chore. This MIT-licensed tool pulls an image straight from a registry and writes a .tar you can carry across, then load with docker load -i. It doesn't need Docker or even Python on the downloading machine if you use the EXE, and it resumes interrupted downloads, checks SHA256 digests, and lets you pick the architecture (amd64, arm64 and others). There's also a Gradio web UI for searching images and choosing tags. More in my note on pulling Docker images offline as tar files.

Setting a proxy in the terminal. I can never remember the exact syntax, so I keep this cheat sheet. It shows how to set, view and clear HTTP and SOCKS proxies in each environment: netsh winhttp on Windows, set and setx in CMD, $env:HTTP_PROXY in PowerShell, export http_proxy and all_proxy in Bash, and git config --global http.proxy for Git. It's handy whenever a package manager or git clone stalls behind a corporate or local proxy. The commands are in my terminal proxy cheat sheet.

Thinking about scale

The System Design Primer (Simplified Chinese edition). Donne Martin's System Design Primer needs little introduction, and its Simplified Chinese README, produced by a volunteer translation project, is a good way to share it with Chinese-speaking teammates. It suggests a study plan by time horizon (breadth first, depth later), treats the interview as an open conversation you should steer, and walks through the trade-offs: latency versus throughput, CAP, consistency and availability patterns, and the building blocks such as DNS, CDNs and layer-4 versus layer-7 load balancers. Here's my summary of the primer's Chinese README.

Scaling SQLite to 4M QPS on one server. This Expensify write-up is the reason I stopped assuming SQLite is only for small apps. Running SQLite behind their own Bedrock layer on self-hosted hardware with 192 physical cores and 1TB of RAM, they pushed parallel reads past four million queries per second, with throughput still climbing. An EC2 x1e.32xlarge topped out around 1.5 million, partly because its 128 vCPUs are 64 physical cores with hyperthreading and the instance seems tuned to drop clock speed under load. The SQLite changes themselves were small; most of the gain came from BIOS and kernel power settings. I go through it in my notes on the SQLite 4M QPS benchmark.

None of these is new, but together they cover most of the questions I hit in the first week of a project: what can I get for free, what data can I use, how do I get things onto a locked-down box, and how far will a simple database actually go. If you have a page that belongs on this list, I'd like to hear about it in the comments.

Self-hosted open source worth a weekend: 8 notes on Automatisch, Monica, PeerServer, telegram-files, WsgiDAV and more

Redreamality — Mon, 02 Nov 2026 02:04:18 +0000

Most "self-host this" lists are a wall of logos. I wanted something more useful for myself: a short set of open-source projects I'd actually consider running on a small box, with the one or two details that decide whether they're worth the trouble. The eight below range from a Zapier-style automation engine to a comment widget that lives on GitHub Issues. Each links to a longer reading note I keep in my digital garden.

Automating work and keeping track of people

Automatisch. If you like Zapier's model of triggers and actions but would rather keep the data on your own server, Automatisch is the obvious place to look. It connects services such as Slack and Twitter without code, and getting it running is a git clone followed by docker compose up. Two things are worth knowing before you commit: it's mostly JavaScript with around 14k stars and steady releases, and it uses a dual licence. The community edition is AGPL-3.0, while files with .ee. in the name fall under a commercial enterprise licence. My note has the details on Automatisch's licensing split and setup.

Monica. Monica calls itself a personal relationship manager: a CRM, but for friends and family. You log how you met someone, birthdays, past conversations, addresses, tasks and reminders, and it can hold journals, photos and documents too. What I like is how clearly it says what it isn't. There's no social network and no built-in AI assistant, no ads and no tracking, and it's licensed under AGPL. Users who struggle to remember personal details, including people on the autism spectrum, have reported it helps. Here's my write-up of Monica as a private CRM for your own life.

Moving files and connections around

PeerServer (peerjs-server). PeerJS lets browsers talk to each other over WebRTC, and PeerServer is the small signalling server that introduces them. Your media and data never pass through it. You can install the peer package globally from npm and run peerjs, use the peerjs/peerjs-server Docker image, or Kubernetes, or mount it inside an existing Express app with ExpressPeerServer. If you put it behind a reverse proxy, remember to set proxied: true; there are also options for SSL, CORS, connection limits and custom client IDs. The PeerServer configuration notes cover those options and a Google App Engine deployment that needs the flex environment for WebSockets.

telegram-files. This one solves a narrow but common problem: pulling files out of Telegram channels, groups and shared links reliably and without babysitting. It handles multiple accounts, pause and resume, automatic transfer to another destination, and inline previews of images and video in a PWA. Setup needs your own Telegram API ID and hash. The security defaults are sensible: admin sessions guard the API, previews and WebSocket, and on first start it prints a one-time bootstrap code valid for 15 minutes so nobody else can claim the admin account. It's MIT-licensed. More in my notes on running telegram-files as an unattended downloader.

WsgiDAV. When you need a WebDAV share and you're already in Python, WsgiDAV is a WSGI-based server you can run from the command line or embed as a library. What makes it interesting is the provider model. Besides the plain filesystem, the docs list providers for Mercurial, MongoDB, MySQL and virtual resources, and you can write your own by subclassing DAVProvider, DAVCollection and DAVNonCollection. I kept a map of the WsgiDAV docs and its provider API so I can find the right page quickly.

Small services for reading, linking and commenting

wewe-rss on Hugging Face. wewe-rss turns WeChat official accounts into RSS feeds, which is about the only sane way to read them in a normal feed reader. The guide I saved runs it on a free Hugging Face Space: a MySQL instance on Railway's free tier, a rewritten Dockerfile with app_port: 4000, and three secrets (DATABASE_URL, AUTH_CODE, SERVER_ORIGIN_URL). Keep the Space public at first so the origin URL resolves, use Factory rebuild to update, and back up the database before the free credit runs out. The steps are in my wewe-rss Hugging Face deployment note.

EasyNav. Every company ends up with a wiki page full of internal links that nobody maintains. EasyNav is a cleaner version of that: a navigation portal with groups, sub-categories, ordering, search and login, built on React 18 with an Express backend on SQLite or MySQL. It ships Docker Compose and Kubernetes manifests, hashes passwords with bcrypt, uses JWT and parameterised queries, and is released under the Mulan permissive licence. See what EasyNav includes for an internal links portal.

CWGI comments. The author of this blog comment system had tried Disqus, Gitalk, Utterances and Cusdis and wasn't happy with any of them, so they built their own. Comments are stored as GitHub Issues, logins go through a GitHub App to keep bots out, and the client is Solid.js plus Tailwind at roughly 23 kB gzipped with no iframe. The server side runs on Cloudflare Workers. The catch is that a GitHub App needs a callback URL, so in practice you run your own backend, and anonymous reads are limited to GitHub's 60 requests per hour. I summarised why CWGI stores comments in GitHub Issues and what that means in practice.

How I'd pick

Almost all of these are a Docker command away, so trying them costs little. Where they differ is licensing and exposure. Automatisch and Monica are AGPL, and Automatisch adds enterprise-only files, which matters if you modify and serve them. Anything that holds credentials, such as telegram-files' Telegram session or wewe-rss's database URL, deserves HTTPS and a proper first-admin setup before you open it to the internet.

These are my own reading notes; each project belongs to its respective authors.

Trusting what agents do: 7 notes on workflow memory, step-level rewards, proof-checked code and the ironies of automation

Redreamality — Sat, 31 Oct 2026 02:09:36 +0000

Every week brings a new agent that can browse, code or plan. The question I keep coming back to is less glamorous: how do you know the thing did the right work, and what happens to the humans who are supposed to catch it when it didn't? Over the past month I saved seven notes that circle that question from different directions: memory that learns reusable routines, rewards that grade each reasoning step, a language that refuses code that breaks stated rules, a 40-year-old paper on automation, and a scheduling method that treats estimates as evidence. They aren't a unified theory, but read together they make a decent checklist.

Agents that learn routines and get graded step by step

Agent Workflow Memory (AWM). The idea behind AWM is that a web agent shouldn't solve every task from scratch. It induces "workflows", common sub-routines with the example-specific details stripped out, stores them in memory, and reuses them on later tasks. It runs offline, where it learns from annotated examples, or online, where it builds workflows from its own past attempts with no extra data. The authors report a 35.6% success rate on WebArena and the top text-only score on Mind2Web. I wrote up how AWM's offline and online modes differ, along with the pipeline commands for each benchmark.

TRL's PRM Trainer. Outcome-only rewards tell a model whether the final answer was right; a process reward model (PRM) scores each intermediate step. The original paper behind it found outcome supervision gets you a similar final-answer error rate with fewer labels, but if you care whether the reasoning itself is correct, you need step-level feedback: reasoning errors among correct answers dropped from 14.0% to 3.4%. Hugging Face's TRL ships an experimental PRMTrainer that expects a dataset with prompt, a list of completion steps and a per-step label. My walkthrough of training a step-level reward model with TRL covers the Qwen2-0.5B + Math Shepherd example and the config knobs worth knowing.

Making "don't break this" checkable

Bend. Bend pitches itself as C-like speed, CUDA-like parallelism and Lean-style proofs behind Python-flavoured syntax. The part that matters for agents is LAWS.bend: you declare rules that must hold, and the type checker, which is really a proof checker, rejects any change that breaks them, so an AI edit that introduces a bug gets bounced until the law is proven again. The project describes it as an AGENTS.md backed by proofs, and claims checks fast enough (around a second on a mid-sized codebase) to run after every edit. It's still evolving and only recommended for backends, but Bend's proof-checked approach to AI coding is the most concrete answer I've seen to "how do I stop the agent from regressing this".

The human side of automation

Ironies of Automation. Lisanne Bainbridge's paper, cited more than 1,800 times, is the one I'd hand anyone building agents for operators. Its core irony: automation still needs someone to watch it and someone to take over fast when it fails, yet the more you automate, the less practice that person gets. More alarms can make an emergency more confusing, and people are asked to spot machine errors they can't judge in real time. Her suggestions are refreshingly practical: stop, observe, understand, correct, restart; pace automation to what humans can follow; keep operators trained with manual runs or simulators. Here's my summary of the Ironies of Automation paper, based on a thread that walks through it and Bainbridge's later revision.

Evidence Based Scheduling. Joel Spolsky's method isn't about AI at all, but it's the best antidote I know to single-number promises. Break work into tasks of 16 hours or less, log estimated versus actual time, turn that into a per-person velocity, then run a Monte Carlo simulation to get a probability curve for the ship date instead of one date. Interruptions get absorbed by the historical data rather than estimated separately, and you can watch the curve move as you cut low-priority features. If you're forecasting work that agents and people share, EBS and its Monte Carlo ship-date curve is worth a fresh look.

Finding the evidence and the context

alphaXiv. When I need to check whether a claim about agents holds up, I start from the papers. alphaXiv connects papers, researchers and institutions and is built around answering questions grounded in the underlying research, with an MCP server and a browser extension on top. The snapshot I saved listed work from late September and early October 2026 on context-editing language models, agents recovering from their own critical mistakes, and benchmarks for whether agents can design libraries for other agents. My note on using alphaXiv to keep up with agent research lists the sections that were most useful.

Conare. Plenty of agent failures aren't reasoning failures, they're missing-context failures. Conare sells context infrastructure for AI companies: one API that pulls product data, user history and past decisions from places like Gmail, Slack, Notion and Linear, so a model's answer cites where it came from. It's a young product and my note is mostly about its positioning, but Conare's single context API is a useful reference point if you're designing your own retrieval layer.

What I take from it

Verification shows up at every layer: memory that keeps proven routines, rewards that check steps rather than endings, compilers that check promises, schedules that check estimates against history. Bainbridge's warning sits over all of it. The better the checks get, the more deliberately you have to keep the human in practice.

These are my own reading notes; the projects named above belong to their respective authors.

Code meets markets: 8 notes on Freqtrade, OpenBB, flash loans, Solana and a four-quadrant portfolio

Redreamality — Thu, 29 Oct 2026 02:05:15 +0000

Developers drift into finance the same way they drift into anything else: someone mentions a trading bot, a market dashboard or a DeFi trick, and an evening disappears into docs. Over the past month I saved notes on eight resources that kept coming up in that drift, from open-source trading and data tools to Solana and Ethereum primers. Rereading them side by side, my takeaway is that the code is rarely the hard part. The hard part is knowing what risk you're actually taking, and the better projects below say so loudly. None of this is investment advice; treat it as a reading list for builders.

Tools for trading and market data

Freqtrade. This is the open-source crypto trading bot most people start with, and for good reason. It's written in Python, keeps state in SQLite, and gives you backtesting, plotting and hyperparameter search (hyperopt) before a single real order goes out, with FreqAI for adaptive ML-based strategies on top. You can drive it from Telegram or a built-in web UI, and it talks to most large exchanges for spot and futures. What I like most is the honesty of its docs: run in dry-run mode first, read the source, and assume you're responsible for every loss. My notes on Freqtrade's backtest-first workflow cover the CLI commands and the modest hardware it needs.

OpenBB. OpenBB has shifted from "open-source terminal" to something more like a data plumbing layer. Its Open Data Platform lets you wire proprietary, licensed and public data sources in once, then consume them from Python (pip install openbb), a local FastAPI server, Excel, an analyst-facing Workspace UI, or an MCP server for AI agents. That last surface is the interesting one: the same normalized price history a quant pulls in a notebook can be handed to an agent without a second integration. Here's how OpenBB's Open Data Platform is structured, including its Apache-2.0 license and its warning that the data isn't guaranteed to be accurate.

A market heatmap for China A-shares. Sometimes you don't want a bot, you want a picture. 大盘云图 is a free web heatmap that lays out every Shanghai and Shenzhen listed stock by industry sector, colours each tile by its daily move, and lets you zoom from sector to single ticker, with Hong Kong indices on top. It refreshes roughly every eight seconds during trading hours from mainstream delayed feeds (not Level-2), needs no login, and supports full-screen monitoring and replaying past sessions. If you've used Finviz-style maps for US stocks, this A-share heatmap tool is the equivalent view of the Chinese market.

A four-quadrant allocation framework. This one is a personal system rather than software: a self-described engineer splits money along two axes, volatility and time horizon, and gives each quadrant its own tactics. The bulk sits in low-volatility, short-term positions such as stablecoin yield, with smaller slices for long-term index-fund dollar-cost averaging, trend-following quant strategies on assets like BTC and big-tech stocks, and a deliberately tiny high-risk bucket the author openly says has a low win rate. The page reports strong backtest numbers for an ETF rotation strategy, which deserve the usual scepticism about backtests. The framing is still worth borrowing, and the note sums up the volatility-by-horizon investment quadrants.

Learning the on-chain side

Flash loans, explained. Flash loans are the DeFi feature that sounds impossible until you understand transaction atomicity. You borrow with no collateral, use the funds, and repay inside the same Ethereum transaction; if repayment fails, the whole transaction reverts as if the loan never happened. That makes them useful for arbitrage and, unfortunately, for amplifying protocol exploits. The note also flags the less dramatic costs: you usually have to write and deploy your own Solidity contract, and you pay gas even when the trade fails. A clear primer: what flash loans are and why they're tied to so many DeFi hacks.

A Python programmer's route into blockchain. If Solidity feels like a leap, this guide starts where Python developers already are. It walks from distributed ledgers and proof-of-work versus proof-of-stake, to building a toy blockchain with hashing and chain validation, adding transactions, mining and a Flask API, and finally talking to Ethereum through Web3.py and Remix. It ends with a reading list and a candid section on energy use, governance and regulation. Good for a weekend: a blockchain learning path for Python developers.

pxsol: learning Solana from the ground up. pxsol's Chinese-language book is one of the more thorough Solana walkthroughs I've come across. It goes from keys, Base58 addresses and vanity-address scams, through hand-built transactions, the account model, program-derived addresses and rent exemption, to writing and upgrading Rust programs, issuing SPL tokens and designing airdrops, and closes with Solana's economics and tooling (Anchor, Pinocchio, web3.js, solana-py). The note maps the chapters of the pxsol Solana guide so you can jump to the part you need.

From token to trading pool. One chapter of that series deserves its own entry because it's where theory meets a live market. It shows how the example token goes from mainnet issuance to a Raydium pool paired with SOL: choosing the fee tier and initial price, receiving LP tokens that represent your share of the pool, and then watching what happens when that pool is small. The lesson about slippage in thin liquidity is one every token launcher should learn on paper first. See the Solana DEX listing walkthrough.

Put together, these eight form a rough curriculum: understand the mechanics (flash loans, Python-built chains, Solana from first principles), get decent data (OpenBB, a heatmap for a quick read), test ideas without real money (Freqtrade's dry runs), and decide how much risk you're willing to hold before you write a line of strategy code. The tools have never been easier to run. Knowing when not to run them is still on you. If you've taken any of these from experiment to real capital, I'd like to hear what surprised you.

Open-source LLM apps, from fine-tuning to group chat: 8 notes on Oumi, F5-TTS, VideoLingo, LangBot and more

Redreamality — Tue, 27 Oct 2026 02:11:21 +0000

Most of the interesting open-source LLM work right now isn't a new model. It's the plumbing around models: the pipelines that fine-tune them, the bots that put them in a group chat, the tools that turn a video into subtitles in another language. I went back through my bookmarked notes on that layer and pulled out eight projects that, between them, cover most of the path from training a model to putting it in front of people. My view after rereading them: the hard part has moved from "can a model do this" to "who owns the glue," and the projects below are where that glue is being written in the open.

Training and evaluating

Oumi. If you want one toolchain for data prep, fine-tuning, evaluation and serving, Oumi is the most complete open option I've saved. It handles SFT, LoRA/QLoRA, DPO and GRPO across text and vision models (Qwen, Gemma, Llama, DeepSeek, GLM and more), runs from a laptop up to cloud clusters via oumi launch, and hands inference to vLLM or SGLang. The recent releases lean hard into agents, with tool-calling SFT/DPO, executable tool environments and rubric-based judges. My notes cover Oumi's end-to-end training and deployment workflow in more detail.

How small can an agent framework be? A tutorial built on PocketFlow argues that every LLM agent reduces to a graph: a decision node, some action nodes, an end node, and a loop back to the decision. PocketFlow does it in roughly 100 lines, with each node split into prep, exec and post steps over a shared store. The worked example is a research assistant that decides whether to search or answer, and the same shape turns out to be hiding inside LangGraph, the OpenAI Agents SDK and Pydantic's agents. It's a useful antidote to framework fatigue: why agents are just graphs with loops.

Voice and video

F5-TTS. Flow matching has become a serious alternative to autoregressive speech synthesis, and F5-TTS is the reference implementation people keep pointing to. It pairs a Diffusion Transformer with ConvNeXt V2, adds a "Sway Sampling" trick at inference time, installs with a single pip install f5-tts, and ships a Gradio app for multi-speaker generation and voice chat. One thing to check before shipping anything: the code is MIT, but the pretrained weights are CC-BY-NC because of their training data. Details are in my write-up on F5-TTS and its licensing split.

VideoLingo. This is the project that made me realise how much of "AI dubbing" is pipeline engineering. VideoLingo chains download, word-level ASR and alignment, subtitle segmentation, terminology-aware translation with an optional reflection pass, and dubbing through a choice of TTS backends (F5-TTS among them), all behind a Streamlit UI or a local HTTP API. The note is candid about where it breaks: background noise, mixed-language speech and strict JSON output from the LLM. See how VideoLingo turns a video into translated, dubbed subtitles.

Putting models where people already talk

LangBot. Instead of building a chat UI, LangBot connects models to the chat apps people already use: Discord, Telegram, Slack, LINE, QQ, WeChat, Feishu, DingTalk and more, plus a Matrix bridge for the long tail. It brings the boring-but-necessary production pieces (access control, rate limits, content filtering, monitoring), a plugin system with MCP support, and hooks into Dify, Coze and n8n. You can try it with uvx langbot and a browser. I summarised LangBot's platform coverage and plugin model.

HuixiangDou. Group chats are a hostile place for a bot: most messages aren't questions, and answering everything is spam. HuixiangDou handles this with a three-stage pipeline (preprocess, reject, respond) so it stays quiet unless it has something grounded to say. It needs no training, runs in CPU-only, 2 GB and 10 GB GPU configurations, and tunes its scope through lists of good and bad example questions. The successor, HuixiangDou2, moves to GraphRAG. Here's what HuixiangDou does differently in group chats.

Chatwoot. When the conversation is with customers rather than colleagues, you need an inbox, not a bot. Chatwoot is an MIT-licensed, self-hostable alternative to Intercom and Zendesk that pulls live chat, email, WhatsApp, Telegram, Instagram and SMS into one place, and adds an AI agent called Captain to deflect routine questions. It also covers help-center articles, CSAT reports and Shopify order lookup. My notes on running Chatwoot as an open-source support desk list the deployment options.

A small personal use case

LLM-summarised bookmarks. Not every LLM application needs a platform. One blogger wired a bookmark extension, GitHub Actions, the Wayback Machine, Jina Reader and a cheap DeepSeek model into a pipeline that saves each bookmarked page's full text and writes a list summary plus a one-line gist, for under one yuan a month. It fixes two real problems at once: dead links and forgetting what a long article said. Read the bookmark summary and full-text index setup.

Taken together, these eight sketch a stack you can assemble without a single proprietary service: train or adapt a model with Oumi, keep the agent logic as a plain graph, give it a voice with F5-TTS, localise video with VideoLingo, and meet users in chat through LangBot, HuixiangDou or Chatwoot. Licences are the thing to watch, more than capability. If you've put one of these into production, I'd like to hear which piece needed the most glue.

A self-hosted publishing and reading stack: 8 notes on Pelican, RSS, Glance, SearXNG and Cloudflare Tunnel

Redreamality — Sat, 24 Oct 2026 02:06:06 +0000

I keep a small garden of notes on tools I've bookmarked, and a cluster of them kept circling one question: how much of a personal publishing and reading setup can you run yourself, cheaply, without handing it to a platform? Here are eight notes from that pile, grouped by the job each tool does. Every link goes to the full note on my site.

Publishing

Pelican. A Python static site generator that still earns its place in 2026. You write Markdown or reStructuredText, it renders Jinja2 themes, emits Atom/RSS on its own, and can import from WordPress or an existing feed. No database and no server-side code, so any static host works. My note covers what Pelican does and where the project stands now, including the recent jump to requiring Python 3.11.

RSS.Beauty. Raw XML feeds look broken to anyone who clicks them. This project uses XSLT to turn RSS 2.0 and Atom 1.0 into a readable, mobile-friendly page with one-click subscribe buttons, and it deploys to Cloudflare Pages, Vercel, Netlify or a Docker container. See my notes on making a feed presentable with RSS.Beauty.

listmonk. Some readers will never install a feed reader, so email is the fallback. The weekly digest I saved walks through standing up listmonk as a self-hosted newsletter and converting between RSS and email in both directions. Here's the listmonk and RSS-to-email write-up.

Reading and finding things

ALL-about-RSS. Less a tool than a map: specs from RSS 0.90 to JSON Feed, hosted and self-hosted readers, feed generators for sites that dropped RSS, and bridges out to Kindle, Telegram, Discord or Mastodon. It also keeps a list of services that quietly removed their feeds. My summary is a guided tour of the ALL-about-RSS list.

Glance. Once you follow enough feeds you want one page for them. Glance is a self-hosted dashboard configured in YAML, with widgets for RSS, Hacker News, subreddits, weather, markets and Docker container status, and it ships as a single binary under 20 MB. The note also explains a common gotcha: widget timeouts are often caused by Pi-hole or AdGuard Home rate-limiting DNS. Read the Glance dashboard note.

SearXNG. A metasearch engine that aggregates results from many search services without tracking or profiling you. It's one of the most active self-hosted projects around, with around 37.9k stars and steady commits. I wrote up how the SearXNG repository is organised.

Exposing it, and the longer view

Cloudflare Tunnel. Running services at home is easy; reaching them from outside without opening ports is the hard part. A Tunnel runs cloudflared on your local box, gives each service a subdomain with automatic HTTPS, and can put an email or IP allowlist in front of it. The guide I saved is honest about the caveats too, such as speed and dropped connections in some regions. Here's the free Cloudflare Tunnel walkthrough.

Local-first software. The idea underneath all of this: your data should live on your device first and sync second. The local-first community page collects talks like Martin Kleppmann's "CRDTs: the hard parts" and Peter van Hardenberg's original talk, plus meetup recordings. See the local-first software reading list.

Put together, the list is a full loop: write with Pelican, make the feed readable with RSS.Beauty, mail it with listmonk, read others through Glance, search with SearXNG, and reach all of it through a Tunnel. None of it needs a paid plan, though Cloudflare does ask for a payment method on file before enabling Zero Trust. If you run a similar stack, I'd like to hear what you swapped in.

Who pulls the brake? 5 reads on governing agents: budgets, identity, stop authority and harness design

Redreamality — Wed, 21 Oct 2026 02:03:31 +0000

Once an agent can run for hours, deploy things and spend money, the interesting question stops being "is the model smart enough?" and becomes "who is allowed to stop it, and how?" I've been collecting posts from the Redreamality blog that treat that as an engineering problem rather than a vibe. Here are five that each attack a different piece of it.

1. Soft budgets send email, hard budgets send errors

The scenario is painfully familiar: an agent ships a small demo overnight, it wires up paid APIs and auto-scaling compute, and by morning there's a "you're near your budget" email sitting next to a much bigger bill. The post builds on Simon Willison's argument that usage-billed services should ship with hard caps on by default, so that the next billable request simply fails once the line is crossed. What I liked is the framing as a third cost ledger: not the agent's own tokens, and not wasteful loops inside a trajectory, but the downstream services an agent leaves running after the session ends. It also gives a useful test for any vendor console: don't ask whether there's a "Budget" page, ask what happens after the trigger. Worth reading in full: why services agents deploy need a kill switch, not a warning.

2. When the agent gets its own work email

Google's Gemini Enterprise announcement gave agents coworker status: a dedicated mailbox, calendar, Drive, a directory entry, and the ability to be @-mentioned in Chat or tagged in a Doc comment. Rather than retelling the keynote, this write-up pulls out three things a company has to settle before rolling that out: whose identity the agent acts under, whether you can trace who actually asked it to do something, and who can cap its spending. The author's point is that putting all three on an announcement page is not the same as specifying them, and the gaps show up later. There's a practical checklist at the end. See the identity, audit and spend-cap questions behind coworker agents.

3. Agents that finish the job and keep going anyway

This one covers a preprint that names a failure mode I recognized immediately: the hard goal is already met, but the loop keeps adding abstractions, extra checks and fixes for complexity it invented itself. The authors call it "LLM Parkinsonism", with a careful note that it's a description of trajectory shape, not a clinical claim, and propose Global Executive Control, which separates generating actions from deciding whether the project should continue. On their benchmark with a 40k-token ceiling, success stayed around 96.5% while mean token use dropped by about 36% compared with local control. The takeaway is structural: stop authority belongs outside the self-conditioned loop, not in a model that's merely better at saying "done". Read the breakdown of project-level stop authority for agents.

4. A harness you can install instead of hand-rolling

Most teams still treat the agent loop's control code as private glue: when to compress context, when a tool must wait for a human, how a session resumes. This post looks at Strands Harness, which ships that layer as an installable package with overridable defaults and an SDK underneath for lifecycle hooks, guardrails, sessions and evals. The author is appropriately skeptical about the vendor's roughly 28% token-cost claim and separates sourced numbers from marketing. The four questions it uses to judge any harness (context economics, structural versus prompt-based control, where audit evidence lives, and whether the prototype is the same object you deploy) are reusable well beyond this one product. Here's the analysis of Strands as a productized agent harness.

5. Don't collapse the harness objective into one number

The last piece covers an Adobe Research paper arguing that a harness is a design surface with several objectives at once: a version that is accurate but never refuses an unsafe request, or that burns ten times the tokens, still fails in production. Their method lets a coding agent rewrite full Python harnesses while seeing accuracy, behavioral safety and token cost together in a single search phase, and it beats an "accuracy first, then trim tokens" approach on both safety and cost. If you tune prompts or agent scaffolding against a single score, this is a good corrective. Details are in this summary of multi-objective harness search.

The common thread

All five land in the same place: the controls that matter, such as budgets, identity, stopping and safety, should live in structure the agent can't talk its way around, not in a polite instruction. If you only read one, pick whichever matches the last time something ran longer or cost more than you expected.