DEV Community: Reno Lu

Concat is a local CapCut alternative with an MCP server, so an agent can cut your video

Reno Lu — Thu, 22 Oct 2026 17:44:13 +0000

Concat is pitched as a free CapCut replacement, and its listed features include auto-captions, text-to-speech, background removal, keyframes, multi-track cutting, 4K export. For developers, the more important line is further down. Concat ships an MCP server built in, so an AI agent can edit video with it, plus a JSON-RPC API for scripts. A video editor that an agent can drive, running entirely on your own disk, is a different tool from a consumer app with an AI button.

The README describes Concat as an open-source editor for macOS, Windows, Linux and Android, with iPhone and iPad builds that are sideloaded. Everything runs on a native Rust engine with a GPU compositor. It is licensed AGPL-3.0 and, in its own words, in beta: it works, and it still has edges.

Local by design

The README's "none of the catches" list is short: no watermark, no account, no subscription, no upload. The AI pieces follow the same rule. Captions use local Whisper, where you pick a model size and get styled captions on the timeline. Voices come from free local text-to-speech, or from voice cloning based on a few seconds of a recording. Background removal handles people and objects, or you paint the mask yourself. The README says these models download once from Settings and then work offline, and that your footage never leaves your disk.

If I were editing client footage, interviews or internal recordings, that last point would matter to me more than the effect count. There is a CODE_SIGNING.md that the README says explains why Windows builds are not signed yet and what Concat sends over the network, which it summarizes as nothing you did not ask for. That document is worth a read before installing an unsigned build on a work machine.

The machine interface

The README lists three ways to drive Concat without the mouse:

An MCP server started with concat --mcp, with setup in docs/MCP.md. The README calls it one line to set up and names Claude among the agents that can edit with it.
A JSON-RPC API for scripts.
gRPC and a command-line tool, which the README says a build from source adds.

The developer docs on the project website cover the Concat API and its transports. The README does not list the individual MCP tools or RPC methods, so it does not show how fine-grained the control is, for example whether an agent can place a keyframe or only run whole operations. That is the first thing I would check in the docs before planning an automated pipeline around it.

The README's "Good for" list includes Shorts, Reels, tutorials, screen recordings and podcast clips. Topics on the repository include video-editing automation and YouTube automation.

The voice cloning question

Voice cloning from a few seconds of a recording is a capability worth pausing on. The README presents it as a feature alongside free local voices, and it does not describe consent checks or restrictions. If your team adopts Concat, decide up front whose voices you will clone and get permission in writing. The README does not mention consent checks of any kind.

Getting it running

The README gives two download routes: the project website, which hands you the right build, and GitHub Releases with installers, packages and checksums for every platform. Windows is x86_64 only for now, with ARM builds paused. If SmartScreen blocks the unsigned build, the README says to choose More info and then Run anyway. On macOS it gives an xattr -dr com.apple.quarantine command for an unsigned app. Linux gets .deb, .rpm, AppImage, an Arch package and a community Flatpak.

Building from source needs Rust 1.93 or newer, FFmpeg 7 or newer development libraries, cmake and a C++ compiler, then cargo run -p concat from the src directory. CI runs cargo fmt --check and cargo clippy with warnings denied.

The project's advice to contributors is to grab a release, use it, and find where it breaks. I would apply the same advice to an evaluation. For a team weighing it, I would cut one real video by hand first, then try the same edit through MCP and see how much of it the agent can actually do.

GitHub: https://github.com/jub0t/Concat

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

jev-chat judges a conversation before it drafts a reply, and leaves the send button to you

Reno Lu — Wed, 21 Oct 2026 17:47:05 +0000

jev-chat-jarvis puts judgment before drafting. Its README observes that most AI tools skip that step and go straight to writing a reply. Jev, per its README, first works out what the other person really means, how risky the moment is and the best way to respond, and only then drafts replies. The last step is also deliberate: Jev fills the box, and you press send. It never sends on its own.

The project, published as jev-chat, calls itself a chat decision assistant. It ships five apps across Android, Windows, macOS and iOS under the MIT license, and all of them follow the same three steps: read, judge, then draft, check and rank.

Judgment before drafting

The README's "Why jev-chat?" section frames the problem as reading the other person: are they upset, testing you, or just chatting? A judgment model answers that before any text is written, and every draft is then checked against the judgment and ranked so the best fit comes first. Tapping a draft fills it into the message box.

I like that ordering as a pattern. Keeping "what is going on here" apart from "what should I say" means the judgment is a separate step from drafting, checking and ranking. The README does not describe how the judgment is shown to the user in detail, but its screenshots are labeled "analysis" and "scored replies", which suggests both are visible.

How it reads your chats

Reading is where the platforms differ, and the README is specific:

Android: through the accessibility service, as an overlay on chat apps. The global edition targets WhatsApp chats in English; the Chinese edition covers chats in Chinese on QQ, Feishu, X and WhatsApp.
Windows: beside your chat window, reading it with screenshots and on-device OCR or system text APIs.
macOS: an overlay that reads the chat on screen and judges with a local model, on Apple Silicon.
iOS: a custom keyboard. You copy a message and see intent, risk and replies on the keyboard. There is no App Store build yet, so you build it with Xcode.

The README says Jev does not modify the chat app or log in to it. On Android, setup means turning on the accessibility service and the overlay permission.

The privacy model and the account risk

On Android, the README states that chat text, plus any background you turn on, goes only to the model provider you configure, with your own key. The project says it runs no server and never receives your chats, and that screenshots used for OCR never leave the phone. For the other platforms it points to each project's own README.

So on Android, your configured model provider receives your chat text. My rule would be simple: whatever you would not send to that provider's API, do not let Jev read. Setup requires enabling the accessibility service, and I would read the README's linked privacy policies before granting it.

The README also includes a plain warning: using Jev inside apps such as QQ, Feishu, X or WhatsApp may not comply with their terms of service, and your account could be restricted or banned. It leaves the decision to you. If I were considering Jev for a work account, I would show that warning to my compliance team.

Licensing terms worth knowing

The code is MIT licensed and the README says commercial use is allowed without payment or permission. It adds two conditions in its own words: keep LICENSE and NOTICE and credit the source in your product, and do not use the names "Jev Chat Assistant" or "jev-chat", or the chatjevs.com domain, to imply endorsement.

Who it fits

The status column shows a mix of preview, released and source-only apps. The global WhatsApp edition is a preview at v0.1.0, the Chinese Android edition is at v1.7, the Windows and macOS apps are released, and iOS is source only, built with Xcode. If I were trying it, I would configure a provider and key I already trust, use it on low-stakes conversations, and check whether the intent and risk read matches mine before relying on the ranking.

GitHub: https://github.com/jev-chat/jev-chat-jarvis

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

Strata runs a 125B model on a 12 GB gaming GPU by leaning on system RAM, and the README spells out the cost

Reno Lu — Tue, 20 Oct 2026 17:37:32 +0000

Strata's README puts the instruction I would read first in a warning box, not in the speed table. While the model starts, your PC can be slow or stop responding for one to three minutes, because Strata loads 35 to 55 GB into RAM and locks part of it for the graphics card. Strata runs Qwen3.8-Flash-Next, a 125-billion-parameter model, on supported NVIDIA and AMD gaming PCs with at least 12 GB of VRAM and 32 GB of system RAM, and much of the model sits in that RAM.

The project calls itself a one-click install for Windows and Linux, with experimental community paths for Apple Silicon, Intel Arc, AMD Strix Halo and older GPUs. It serves the model on localhost with OpenAI- and Anthropic-compatible endpoints and optional image input. The README says nothing leaves your PC.

RAM is the main constraint on model size

The "Which model should I pick?" table is organized by RAM, with one exception: on a 32 GB system, a 24 GB card also runs Q2_0 and IQ2_XS. The requirements ask for 12 GB of VRAM or more and 32 GB of RAM or more, and the table maps memory to quantization:

32 GB: the Coder version, a coding model with half of the experts removed.
48 GB: IQ2_XS, or Q2_0 for speed.
64 GB: IQ2_XS recommended, with IQ3_XXS and IQ3_S also fitting.
96 GB or more: IQ3_S, or Unsloth's UD-IQ4_XS at roughly 4 bits.

The README lists what you give up at the small end. The Coder version reaches 91% of the full model's SWE-bench Verified score as measured by its authors, and it is weaker outside code, including Chinese and other CJK text. For those, the README points you back to sizes that keep every expert. The larger Unsloth files work with less RAM, but Strata then reads part of them from the SSD while it answers, which the README calls much slower: 7 to 8.5 tokens per second for UD-Q4_K_XL on a 64 GB PC.

The speed numbers and their conditions

The README's speed tables come from two machines it describes as ordinary gaming PCs: an RTX 5070 with 12 GB, a Ryzen 5 7600 and 64 GB of RAM, and an RX 9070 XT with 16 GB, a Ryzen 9 3900X and 47 GB. On the NVIDIA box it reports 94 tokens per second of output at Q2_0 and 53 at IQ3_S, with prompt reading between 1,620 and 2,650 tokens per second on a 32K-token input. The engine versions differ between rows, and the full tables are in docs/DETAILS.md.

For agent use, the README also covers concurrency and first-message time. By default Strata answers one request at a time and queues the rest; setting "parallel": 2 allows two, and on a 12 GB card that makes each answer slower. And Strata reads the first message of a chat in full at about one minute per 30,000 tokens, while follow-ups start in seconds. If your agent opens with a large context dump, I would expect to wait on that first message. The BENCH.bat script (./bench.sh on Linux) measures chat, 4K and 16K prompts and an agent-style session using your own settings.

Wiring agents to it

Once running, Strata opens a browser app at http://127.0.0.1:8080 with Chat, a live Monitor of the model and your hardware, and an About page. For other tools you add an OpenAI-compatible provider at http://127.0.0.1:8080/v1, and the README says any API key and any model name work. Anthropic-style clients use /v1/messages, and for Claude Code the README sets ANTHROPIC_BASE_URL=http://127.0.0.1:8080, and the Responses API for Codex CLI lives at /v1/responses.

The install itself can be handed to an agent: the README offers a one-line prompt asking your coding assistant to follow docs/AI_SETUP.md. The assistant then checks your card, RAM and disk and picks a model. There is also an MCP server so AI tools can install, start and stop Strata.

Set a key for network access

Serving to your phone or another PC uses START-HERE.bat --setup --host 0.0.0.0 --api-key <secret>, and the README adds: always set a key. If you only need the model on the same machine, I would leave the host setting alone.

For a first run, budget about 80 GB of free disk, preferably SSD, and a roughly 70 GB download that resumes if interrupted. Expect the slow start the README warns about, and run the benchmark before you decide which size to keep.

GitHub: https://github.com/Niko1221/Strata

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

Laya answers typed questions in one forward pass, and its README says fine-tuning is where accuracy jumps

Reno Lu — Mon, 19 Oct 2026 18:54:03 +0000

The number I would read first in the laya README is not the 33 ms latency. It is the gap between 0.362 and 0.766. On the project's own typed-decisions benchmark, the base English checkpoint scores 0.362 accuracy across 2,000 decisions, and the fine-tuned laya-typed-decisions checkpoint scores 0.766. The README says this directly: the shipped checkpoints work zero-shot, but fine-tuning on decisions from your own domain is where accuracy jumps. I read that as two separate stages for any pilot: zero-shot evaluation, then fine-tuning.

Laya describes itself as a multilingual, non-autoregressive "System 1" decision engine. You hand it some state, such as an email, a ticket, a block of text or a JSON document, plus a set of typed questions. It answers all of them in a single forward pass and generates no text. In the README's words, there is nothing to parse and nothing to hallucinate.

Three question types instead of a prompt

The quickstart shows all three question types. A customer writes that they were billed twice for March and will cancel unless refunded today. The code defines three questions against that message:

department is a choice question with criteria for billing, technical and other.
urgency is a score question over "not urgent", "soon" and "blocking".
churn_risk is a noul question, which the README's comment describes as returning the probability that the answer is yes.

router.predict(state, questions) returns structured answers for each, plus a routing field naming which checkpoint handled the request. For a triage step in a support queue, that output gives you a choice you can switch on and a probability you can threshold, with no free text to validate.

The README says the models are trained with reinforcement learning against strictly proper scoring rules, which it calls RLCD, and the fine-tuning loop includes a temperature calibration step. If you plan to act on the noul probability rather than just the top choice, that calibration is the part to check on your own data.

A router over three checkpoints

Laya ships three checkpoints and a Router that picks one per request. The README's table lists them:

laya: ModernBERT-large, 421M parameters, 512-token context, for English.
laya-multilingual: mmBERT-base, 322M parameters, 1,024 tokens by default and up to 8,192, for 100+ languages, listed as 2x faster.
laya-typed-decisions: ModernBERT-large, 421M parameters, 1,024 tokens, for the typed-decisions workflows.

The router detects script and language and sends non-English text to the multilingual model. The README's example routes a Hindi billing complaint and a Spanish crash report through the same call, and both come back from laya-multilingual with the expected department.

The limits it states itself

The long-document note includes measured results. laya-multilingual ships with a 1,024-token limit that cuts long documents off, so you pass max_len=8192 to read further. The README reports that 16 to 18 of 20 requests were answered correctly with up to about 4,000 tokens of text before them, and that beyond that the results vary from 8 to 17 of 20. Its advice is to check long-document accuracy on your own data. I would take that literally and keep long inputs out of any automated path until you have.

The latency figures come with their hardware: 33 ms for one question and 7.2 ms per question batched, measured on a T4. A separate BENCHMARKS.md collects every run, and the README says it states the limits plainly.

Where it plugs in

The base install is python -m pip install laya on Python 3.10 or newer. Optional extras add an HTTP server, an MCP server, ONNX Runtime, a TileLang GPU fast path, pydantic models, and wrappers for LangChain, LlamaIndex and CrewAI. The 0.4.11 release notes add a Rust SDK that ports the Python SDK onto ONNX Runtime, with 210 offline tests checked against goldens from the Python implementation, and a LayaToolSelector for routing tools in agent loops. A TypeScript package, laya-ts, lives in the same repository.

There is also a CLI: laya "My payment failed twice" --preset triage answers a ready-made question set.

How I would try it

Pick one narrow decision your team already makes by hand, such as routing inbound tickets, and run laya zero-shot against a few hundred labeled examples. Compare your zero-shot result with the README's base-checkpoint score of 0.362, treating it as a reference point rather than a prediction for your data. If the decision is worth automating, the README points to a Kaggle 2xT4 notebook and an Apple Silicon script that run the full loop: build a dataset, train with RLCD, calibrate temperatures, evaluate and export. On the project's benchmark, fine-tuning moved accuracy from 0.362 to 0.766, so I would plan for that step from the start.

GitHub: https://github.com/NandhaKishorM/laya

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

mono-color-skill Writes Print Taste Down as Rules an Agent Can Check

Reno Lu — Fri, 16 Oct 2026 17:04:48 +0000

My reading of the README is that mono-color-skill is less an aesthetic than a spec. The name points to one ink, and the README's tagline covers both one-ink and controlled two-ink work, yet the README states that the skill defaults to controlled two-ink, with one dominant plate and one narrowly assigned accent plate, and that pure one-ink applies when a request explicitly asks for one-ink or monochrome. That default, and the numbers attached to it, are the part worth studying if you write skills for agents.

Adjectives like "restrained" or "editorial" give a model little to hold. This repo writes its visual system down as quantities, role assignments, and a refusal list, then has the agent inspect what it generates.

Defaults written as numbers

The ink rule reads like a config file. In two-ink work, the README says the dominant plate normally carries 70 to 85 percent of the printed area and the accent plate carries 15 to 30 percent. The accent is not free decoration: it "must have a specific job such as dates, annotations, selected objects, or overprint intersections." Two edge cases are closed in writing. The substrate is not a third color, and the darker color created where two plates overlap is not a third ink. Those sentences remove readings of "no more than two printing inks" that would otherwise stay open.

Empty space gets the same treatment. Visible empty paper occupies 25 to 55 percent of the canvas on an asymmetric editorial grid, and the README says it controls pacing. The composition step pairs that range with "one deliberate disruption," which reads to me as a budget for breaking the grid once, not an open invitation.

The palette is enumerated with hex values. The one-ink palette has eight inks, from Cobalt / Ultramarine at #2148B8 to Charcoal at #30343A, and a separate list gives nine two-ink recipes such as Cobalt + Terracotta and Cyan + Brick Red. Substrates are three paper tones, each with a list of the work it supports: Neutral White #FAFAF7 for crisp cultural, social, event, and image-led work; Cool Gray #E9E9E5 for architecture, technology, charcoal-led systems, and restrained branding; Pale Beige #F5F1E8 for tactile, travel, food, intimate, archival, or explicitly nostalgic subjects.

Naming what it will not make

The "Not this" section is the part I would borrow for my own skills. It lists outputs the skill rejects: a full-color photograph with a monochrome filter; a glossy mockup, 3D render, gradient poster, or cinematic scene; a centered template, card grid, sticker collage, or decorative blob system; marketing copy, invented branding, fake sponsors, URLs, or QR codes. To my mind, a negative list like this gives an agent concrete things to check against, where a positive description alone leaves the boundary vague.

One refusal targets a specific association. The README says the work is not automatically retro, yellowed, sepia, distressed, or nostalgic because it uses halftone or limited inks. Contemporary editorial is the default, and vintage treatment appears only when requested. Pale Beige paper stays available for the subjects the README lists.

Copying grammar, not pictures

The originality rule comes with a number as well. The README says the visual system was informed by a twelve-image research set, and it points to a references document with an image index, research notes, and attribution status. Rule 7 reads "References are grammar, not templates," and attaches a threshold: at least four structural variables change from every supplied reference. The refusal list adds that the output is not a reconstruction of a reference poster or artist signature. Even the repo's own generated examples are labeled as outputs, "not templates to reproduce."

Identity gets a counterweight. Rule 6 says supplied people, objects, and scenes remain recognizable. Rule 3 describes what happens to a photograph: it becomes dots, grain, clipped highlights, ink pooling, and mild registration drift between plates. Put together, a photo you supply should still read as its subject after that treatment, while the layout is rebuilt around the subject, intent, words, and image role.

The inspection step

The README describes five steps: read the input, choose the layout, assign the plates, compose the page, then generate and inspect. That final step names what to check: ink count, identity, hierarchy, texture, and originality. To my reading, ink count, identity, and originality each line up with a numbered rule: Rules 1, 6, and 7. The declared output is a generated raster image, the exact production prompt, and a short recipe. Having the prompt and recipe next to the image gives a reviewer something to compare against the rules.

Installation is a git clone into ~/.claude/skills/mono-color followed by a Claude Code restart, and the README says other agent environments can load SKILL.md as the skill entry point. If you maintain skills of your own, read this README beside one of yours and count how many of your instructions an agent could fail in a way you could detect.

GitHub: https://github.com/yanliudesign/mono-color-skill

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

Reef adds a receipt header to inference responses, then learns from reports

Reno Lu — Thu, 15 Oct 2026 17:29:51 +0000

Reading the reef README, the detail I would study before any training recipe is a response header. Reef inference responses include x-reef-agent-record-id, and the README calls its value a receipt. A later report names the receipts it evaluates, and Reef matches that feedback to the recorded interactions. That link between what the agent did and how it gets judged is where anyone running this in front of users should start asking about review and rollback.

The README describes Reef as open-source infrastructure for continual self-improving agents, then gets specific about the mechanics: Reef connects agent inference, feedback, learning, and versioned delivery, and it can target either model weights or an agent's harness, including its prompts, rules, and skills.

A receipt on each inference response

Reef exposes an inference endpoint that the README describes as OpenAI- and Anthropic-compatible, taking the provider's own request body at /v1/chat/completions and /v1/messages. Each request carries an x-reef-scenario header. A new scenario name creates a scenario using the deployment's configured recipe, and the README states that requests do not select recipes.

The response adds the receipt header. Your code then posts to /reef/report, and a report can carry a numeric score, a feedback field holding plain text or a structured object, and references listing the receipts being judged. The endpoint validates reports against a report schema.

Because the receipt travels with the response, the judgment does not have to happen inline. The harness example tells you to run your tests first and then report the actual result. The recipe table also lists a "Learning from usage" category for real interaction where "no one reports a score or feedback arrives late."

The loop in four steps

The README splits each learning cycle into four steps and names the modules behind each. Serve handles agent requests and records interactions (service/, runtime/). Observe matches feedback to recorded interactions and handles eligibility (storage/records.py, train/processors/). Grow produces an update from eligible records through a recipe (recipe/, train/). Commit applies the configured selection policy and publishes accepted updates, with candidate evaluation in train/evaluation/, version history in artifact/, and delivery in surface/.

The two learning surfaces use that loop differently. On the weight path, the SAO example deployment uses each eligible scored rollout to run a training step. Per the README, once the recipe has enough feedback it trains, synchronizes the updated weights to the serving runtime, and later requests use the current version without restarting Reef. That path needs a trainable model and a supported GPU stack.

The harness path needs a model endpoint instead of training GPUs. The harness-evolve recipe points at an upstream provider, which is a local Ollama server in the example. A reef-pi harness installed from the running server then executes tasks and sends reports such as reef-pi report --score 0 --feedback "missed the empty-token case".

Where the gate sits

For an operator, the question is what stands between a bad report and a changed agent. The README answers it for the harness tutorial: failed reports trigger a candidate skill update, Reef evaluates that candidate against the current harness on the tutorial's three coding tasks, and it publishes the candidate only if it wins. The README points to the tutorial for customizing the tasks and the evaluation. If you adopt this path, those tasks are part of the publication decision, so they deserve the care you would give a test suite.

For weights, the README's SAO walkthrough describes training and synchronization but does not spell out an evaluation step before new weights reach serving. The general Commit step does mention a configured selection policy, so the architecture has a place for a gate. What the SAO example puts there is not described in the README text I worked from.

What it says about review and rollback

Reef keeps versions. Its comparison table lists version management and staying live through updates as abilities that an inference engine or an RL training framework lacks on its own. The Commit step writes to a version history, and the installation note says artifact and checkpoint functionality requires the git-lfs system package, with Reef initializing Git LFS locally for its artifact repositories.

The part of the README I read does not describe operations built over that history. I found no command there for rolling back to an earlier version, no way to pin a scenario to a known-good artifact, and no human approval step before an accepted update is published. Before relying on rollback in production, read the docs or the artifact/ module.

Getting a feel for it

The package installs with uv pip install reef-infra, and the README says to use a source checkout for the training examples. The minimal starting point runs Reef as a pure inference server with uv run reef serve --inference.model-path Qwen/Qwen2.5-1.5B-Instruct. If you want to watch the gate work without training GPUs, the documented harness example uses a local Ollama model, and a failing report is what sets a candidate update in motion.

GitHub: https://github.com/Human-Agent-Society/reef

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

scroll-craft gives coding agents design rules and checks for building scroll-driven sites

Reno Lu — Wed, 14 Oct 2026 17:40:59 +0000

My reading of the scroll-craft README puts its build rules ahead of the scroll animation. What stands out is the fingerprint gate, which requires a plan change when it fails, and the headless browser pass, which reports problems including contrast on the composited page. Several of its rules are written as things a build may not do.

The problem it names

The README claims the bulk of AI website output fails in one of two directions: well behaved and forgettable, or a flashy scroll animation with 2.1:1 body text, a headline that wraps to six lines on a phone, and the same six sections every other AI page has. Its stated answer is to treat interaction and craft as one job rather than two.

The skill works with Codex, Claude Code, or another coding agent that can read instructions, edit files, run commands, and inspect a browser. The README says agents use their own tools for file access, shell commands, browser inspection, and user questions, while the design workflow is shared. It also ships as a Claude Code plugin, installed with /plugin marketplace add nateherkai/scroll-craft and then /plugin install nateherk-design. For Codex, you copy the complete scroll-craft folder into your project's .agents/skills/ directory. The README notes that the ten-site rebuild it documents was built with Codex.

Rules that stop repetition

The uniqueness rules come first. It defines eight page grammars (filmic one-shot, chaptered editorial, live surface, continuous world, typographic poster, gallery, split stage, rhythmic cutlist) and calls them mutually exclusive, with each one forbidding what the others require. Every build must invent a signature move, one bespoke interaction that exists on that site alone. The README rules out a recoloured spotlight as a candidate.

Then comes the fingerprint gate. A new build must differ from every page you have already made on at least 4 of 6 dimensions: grammar, nav, hero, act shape, close, signature move. If a plan fails, the README says to change the plan, not the record. The registry lives at <workspace>/FINGERPRINTS.md and starts empty, which the README calls correct, since the gate exists to stop you repeating yourself. Your first build has nothing to clear. An EXAMPLES.md file holds the author's twelve-row table, offered as illustration rather than constraint.

A design floor written as numbers

The craft rules read like a style guide with the vague parts replaced by values. Typography gets two families maximum, a 45 to 75ch measure, tracking that tightens as size grows, and line height inverse to measure. Spacing uses a 4px base, more space above a heading than below it, and fluid section padding so a phone does not inherit desktop air. Colour gets six roles and one accent, secondary text tinted rather than flat grey, and no pure black.

Before any act exists, the skill asks for a feeling curve: one line per act naming the emotion and what on screen causes it. Two adjacent acts with the same feeling means one is filler. It also calls for one engineered peak, which gets the asset budget, the silence in front of it, and more scroll room than anything else on the page. A page with three peaks, the README says, has none.

There is a refuse list too. It bans identical feature-card grids, 01 / 06 counters, scroll cues, gradient text, em dashes, invented statistics, fake dashboards, AI-purple gradients, and the cream-and-brass artisan palette. Brand guidelines count as inputs, not decoration: point it at a brand kit and the kit's hard rules win, including rules that forbid things the skill would otherwise reach for.

The browser check and its stated limit

A headless browser walks the finished page at every scroll position, waits for the video playhead to settle, and reports four kinds of problem. Dead scroll is scroll that changes nothing on screen. Cues that never reach full opacity are copy the reader only ever sees faded. Contrast is measured per line at the brightest frame that passes under it, with the direction picked per line so light-on-dark and dark-on-light are both graded. And a clip stuck on a poster is one that silently never decoded. The requirements table lists playwright-core plus Chrome for this pass, with npm i playwright-core run in the build folder.

After that, it writes a contact sheet. The README gives the reason: a machine can prove a page works and cannot tell you it means anything.

Setup gets its own guard. The README says to run doctor before anything else, because common setup faults otherwise surface later as misleading errors, such as a stripped ffmpeg reporting a missing filter as a syntax error in your command. A full ffmpeg build is needed so clips scrub rather than play. KIE_AI_API_KEY is optional and only matters if you want assets generated; building from your own photos and footage needs no key.

The engine, scrollcraft.js plus its CSS, is never edited per project. You theme it with six colour tokens and two fonts and write your own semantic HTML around it.

GitHub: https://github.com/nateherkai/scroll-craft

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

EverRoom treats memory as something a source has to earn

Reno Lu — Tue, 13 Oct 2026 19:39:23 +0000

My reading of the EverRoom README is that one of its key design decisions concerns what the workspace declines to remember. The project describes itself as a local-first personal context workspace for files, conversations, memory, and AI agents, yet much of its documentation explains what a source goes through before it earns a place in long-term knowledge. The README states the thesis directly: context "should be assembled from evidence, scoped to a place of work, and made visible enough for a person to govern."

Status comes first. The README marks Everroom as under active development, names macOS as the current development target, and warns that APIs, storage schemas, and agent contracts may change while the first complete local workflow is being finished. Read everything below as a description of a direction and a partially built system, not a finished product.

Memory as a routing outcome

The README positions the project against a specific pattern. It says Everroom is not intended to be "another chat client, a thin RAG screen, or a notebook that quietly accumulates unreviewed summaries." My reading is that the section on how a Room works is where that position becomes concrete. Sources are linked to a Room and kept with stable identity and version history. Routing and evidence checks then decide whether a piece of material becomes a Room wiki page, an entity candidate, a memory document, or only a link.

That final option carries the idea. A source can sit in a Room, attached and traceable, without being turned into permanent memory. The README describes the goal as a workspace that "can become more useful over time without turning every source into permanent memory."

The product model table draws the same lines. Evidence is versioned, addressable source material with positions and provenance, and the README says it protects "the difference between a source and a model's interpretation." Knowledge covers wiki pages, entities, links, and route decisions built from that evidence. Memory is conversation capture plus layered MemoryCore derivations labeled L0-L3, listed as having a visible lifecycle.

The Room draws the boundary

A Context Room is the working surface for a project, person, topic, or ongoing responsibility, and the README contrasts it with "a global prompt dump." When an Agent handles a request, it receives only the Room-scoped tools and documents needed for that request. Knowledge tools resolve the current Room or session before reading wiki pages, sources, or materials. According to the README, agents do not receive a global unbounded corpus by default.

The loop is meant to close on itself. Document changes are committed through the document kernel, recorded as operations, and sent back through the same ingest path. The README calls the loop "deliberately reversible": a generated summary is useful only when a person can inspect where it came from, correct it, and let the correction flow back into the next task.

Engineering notes along the same line

Several implementation notes in the README read to me as the governance idea applied at the storage and process level.

The ingest layer identifies and normalizes a source once, then fans it out to Knowledge, Memory, or Room links according to a recorded policy snapshot. Original files and parsed Markdown have one storage owner, and downstream systems keep stable references, hashes, and provenance instead of copying the source into several databases.

Document edits go through a transactional commit core and outbox. Knowledge and Memory fan-out happens after the authoritative document version is committed, and the README says this means an external service failure cannot corrupt the document.

Connector calls are prepared against real Action Schemas and real connections before execution. Tokens remain in trusted processes, and destructive or externally visible actions are designed to require approval.

The README also lists explicit fallback states for the fake Agent runtime, disabled MemoryCore, unavailable connectors, and model failures, with the stated aim that a missing optional service should not make local documents inaccessible.

The desktop uses Electron 39 and React, with local storage on SQLite WAL, Drizzle ORM, FTS5, and content-addressed objects.

What the main branch holds now

The README says the main branch contains the first integrated product loop, and its status table separates "Available" from "Available, evolving." The desktop workspace, the local gateway, and agent sessions are marked available. Evidence and ingest, Knowledge Rooms, Context Docs, Reality Perception (user-triggered microphone and system-audio capture with transcription), agent work management, and files and understanding carry the evolving label. Memory is available when enabled. Connectors sit at "Foundation available," with provider coverage still expanding.

Some features require optional local services or model credentials, though the README says the desktop can still start with the isolated development runtime. The prerequisites list macOS, Node.js 22 or newer, and pnpm 11.15.1.

The README also names what the first release does not begin with: continuous screen recording, an autonomous multi-agent swarm, enterprise administration, or mandatory cloud synchronization. The open question for me is how the "only a link" route behaves once a Room fills with a real project's worth of material, and the project's own status note says the complete workflow around it is still being finished.

GitHub: https://github.com/NxcoreAI/EverRoom

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

phone-harness gives your agent a real phone, while its README leaves guardrails unspecified

Reno Lu — Mon, 12 Oct 2026 21:28:32 +0000

My reading of the phone-harness README is that the question of trust rests on a human responsibility it names in one line of the Limits section: "Connecting the phone is always the user's job." Once you make that connection, the agent drives. The project connects Claude Code, Codex, or any agent to your real phone, and the task in the README's Demo section is "Buy me a Waymo to Delah Coffee from my current location." That is an agent asked to pay for something. If you run agents for a living, the thing to check is what sits between the agent and that purchase. The README describes setup steps you perform with your own hands, but does not say they constrain later actions.

What the agent gets

The README says the agent "sees the screen, taps, types, and reads the result." It claims no jailbreak, no Xcode, and nothing installed on the phone. Control runs through the Mac's iPhone Mirroring window on iPhone and through adb on Android.

On iPhone, iPhone Mirroring renders the phone as a Mac window and forwards mouse and keyboard as touches. The harness captures that window, runs OCR on it with Apple's Vision framework to get text with tap-ready coordinates, and posts HID-level events for taps, swipes, and typing.

On Android, adb is the transport. screencap is the capture, the phone's accessibility tree is the text source, and input is the hands. The README says this works over USB or Wi-Fi, with no window needed.

The same helpers work on both platforms, and phone-harness config set platform ios|android picks the default. The README's usage example looks like this:

phone-harness <<'PY'
open_app("Notes")
tap_text("New Note")
type_text("hello from the harness")
print([o["text"] for o in ocr()][:10])
PY

Helpers are pre-imported. The README points to SKILL.md as the agent's day-to-day guide and to helpers.py for the full list. I have not read either file for this piece.

Where the human stays in the loop

Setup is itself delegated to an agent. You paste a prompt into Claude Code or Codex telling it to clone the repo into ~/.phone-harness, read install.md first, install it so phone-harness is a command on your PATH, register it as an agent skill named phone-harness using phone-harness skill as the body, then read onboarding.md and walk you through it. The agent installs the tool that will later drive your phone. That ordering deserves a look before you paste anything.

What the README leaves to you during setup are the pairing and permission steps. The agent asks which phone is your default and walks you through "the parts that need your hands": pairing iPhone Mirroring and granting Accessibility and Screen Recording, or turning on Android developer options and approving adb. phone-harness --doctor checks the chain.

The Limits section lists a few more points where a person has to act or where the harness falls short. Unlocking the iPhone pauses mirroring, and a PIN-locked Android needs the user. OCR sees text, not icons, so unlabeled controls need a screenshot and a vision-capable model. There is no multi-touch and no camera or Face ID flows, and DRM video renders black. The README lists these under Limits and does not present them as safety features, and neither would I.

What the README does not cover

For a tool whose Demo section asks an agent to buy a Waymo ride, the README says nothing about several things an operator would want to know. It does not mention confirmation prompts before purchases or messages, an allowlist of apps, a log of what the agent tapped, a dry-run mode, or a way to cap what a connected agent can do. Whether any of that exists in the code or in SKILL.md, the README does not say.

It also advertises Phone Harness Cloud, described as hosted iPhones and Androids "with stealth, real numbers, 2FA, and unlimited devices." The README gives no further detail on how that service works.

How I would try it

Given what the README does say, the practical move is to limit the exposure yourself. Use a spare device or a secondary account rather than the phone that holds your payment methods and primary email, since the README does not describe app allowlists or action-level controls. Run phone-harness --doctor to confirm the chain, then start with the kind of task in the usage example, opening Notes and reading text back, before handing it anything that costs money. On the iPhone path the phone is rendered as a window on your Mac, so you can keep that window in view while the agent works.

The author describes phone-harness as free and maintained in their own time, with sponsorship as the way to keep it that way.

GitHub: https://github.com/ShawnPana/phone-harness

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

delivery-harness lets the rule engine set the payout and keeps the model advisory

Reno Lu — Sun, 11 Oct 2026 17:50:53 +0000

One short line in the delivery-harness README captures a central design decision: compensation amounts are decided by the rule engine, never by the model. For a project that calls itself an AI harness, much of what the README describes reads like a fence around the model, keeping its output advisory while deterministic code holds the numbers.

Scope comes first. The README calls the repository an educational MVP and says it is not a production-ready delivery or compensation system. Its business tools return synthetic data, state is mostly held in memory, and there is no authentication, authorization, tenant isolation, or rate limiting. The authors warn against exposing it to the public internet, submitting real personal or order data, or executing compensation decisions without authentication, policy enforcement, and human approval. I read it as a reference implementation to study and run locally.

What stays deterministic

The README lists two synchronous workflows: abnormal-order analysis and compensation suggestion. Around them sit four locally registered tools covering orders, ETA, station capacity, and compensation rules, and each tool derives its result from its arguments. Synthetic orders vary by order ID across six named scenarios, one of which is delivered on time.

The README also describes a deterministic timeline that splits an order into dispatch wait, to-shop, merchant prep, and on-road legs. According to the README, that timeline is reported alongside the model's answer "as the baseline it has to beat."
On the compensation side, the rule engine owns the amount, and the README points to an architecture decision record for that choice. For DAMAGED complaints, the caller passes a damage_level of FULL or PARTIAL; without evidence, the policy returns zero and requires manual review. The property harness.compensation.approval-threshold defaults to 10.0, and payouts at or above that value require a human approver.

Failure handling follows the same split. When a completed workflow has an unavailable optional dependency, the README says the run is reported as DEGRADED, the deterministic result remains available, and the affected step is recorded as failed.

Where the model sits

The model is reached through an OpenAI-compatible chat-completions client behind an interface, which the README says makes the workflows testable without a model. The default HARNESS_LLM_ENDPOINT points at localhost on port 11434, qwen2.5:7b is the example model, and the Compose port binds to 127.0.0.1 only.

Knowledge retrieval is in-memory and lexical, scored by query-term overlap, with a rule and case base seeded at startup. The README flags ingested documents as a prompt-injection trust boundary, a habit worth copying into any harness that lets operators add knowledge.

The fields needs_human_review and approval_required are derived from guardrail outcome, parse success, model confidence, and baseline agreement. The README calls this reporting, not authority, and says nothing here executes a payment. Its advisory checker detects a small set of phrases and amount conditions, and the README states that it is not a policy engine.

Tests and evaluation

The suite has 112 tests, and both workflows run end to end against a stub model transport, so no test needs Ollama or a Docker daemon. The README names buildsDifferentEvidenceForDifferentOrders as the load-bearing test. It asserts that two different orders produce two different prompts, which the README calls the property every other measurement depends on.

Evaluation runs live in memory, and scorers report "not measured" instead of a perfect score when a case declares no expectation. The README describes the scorers as lexical and calibrated to catch regressions, not to certify quality, and says six synthetic cases cannot establish accuracy. It adds that modelVersion and promptVersion on a run are metadata labels that do not yet select a model or change the workflow prompt.

What is not implemented

The README also lists capabilities the project does not claim as implemented, a list worth checking if you are sketching an AI layer over an operational process like refunds or dispatch exceptions. It names autonomous agent planning, production tool integrations, durable persistence, vector embeddings and Milvus RAG, authentication, rate limiting, distributed tracing, and automatic compensation execution. The known limitations add that rules, documents, cases, evaluations, feedback, metrics, and traces are lost on restart, and that retrieval splits CJK text on whitespace and punctuation rather than segmenting it.

GitHub: https://github.com/diudiu-tech/delivery-harness

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

What chat-on-steroids Grants ChatGPT on Your Machine

Reno Lu — Sat, 10 Oct 2026 17:32:23 +0000

My reading of the chat-on-steroids README is that the sentence a security reviewer needs sits inside a collapsed installation notes section: "Shell commands run with your normal user privileges." The capability pitch leads the page, and several of the controls fit in a few bullet points further down. Anyone deciding whether to install this should read the feature list with that privilege line in mind.

What the app hands to a ChatGPT conversation

The README describes a desktop app, which it abbreviates as CoS, that works through a ChatGPT conversation. According to the README, you can "Let ChatGPT read and edit files, run tests, keep terminals open and use your desktop," and follow the tool results as they arrive. A companion extension loads into Chrome as an unpacked extension, and the README says pairing is automatic.

The README then goes past a single session. You can split independent jobs across workers and bring their results back, and "Workers keep their context, so the next task can pick up where they left off." Goal "follows unfinished work," Loop "keeps working within your brief," and Compact & Resume carries the session and worker history into a fresh chat. You can send a correction while work runs.

Read as an access inventory, the documented features include file reads and edits, open terminals, desktop use, a companion browser extension, and workers that keep context between tasks.

The README also makes a usage claim in bold on the page: it "Uses your ChatGPT conversation. Does not consume Codex quota." It adds that your account's model availability, usage and context limits still apply. That is the project's statement, and nothing in the README lets me check it.

The controls the README documents

Setup begins with approving your project folder under Settings > Workspace. The installation notes say to "choose your approved folders and review capabilities before connecting," and one screenshot is captioned "Folder and capability settings." The README does not spell out how folder approval is enforced.

Per the README, fresh installs enable Core capabilities and two workers, and Windows also enables Desktop permissions. A Windows user who clicks through setup therefore starts with Desktop permissions on. The README does not say that macOS or Linux installs enable them by default.

Then comes the privilege line. Shell commands run with your normal user privileges. The README does not describe a sandbox for those commands, a per-command approval step, an allowlist, or an audit log. The project may still have some of these. The footer links to a SECURITY.md file, and since its contents are not in the README, I will not describe them here.

Distribution trust is a gap the README raises itself. Under an "Unsigned beta" note, it says Windows is not publisher-signed and macOS is unsigned and unnotarized. It tells you to verify the package against the release checksums. On Linux it requires a Secret Service keyring and recommends the DEB, and it notes that when unprivileged user namespaces are disabled, the AppImage launcher can fall back to --no-sandbox.

The listed requirements include a ChatGPT account or workspace with Developer mode and custom MCP apps, plus Chrome 116 or newer or a current Edge. The second setup step has you connect Core through Settings > Setup and add it in ChatGPT's Developer mode, and it links to a tunnel setup guide. The README itself does not explain what the tunnel exposes or how it is authenticated.

How I would approach an evaluation

If I were reviewing chat-on-steroids for a team, I would treat its shell-command capability as operating with my local user privileges, because that is what the privilege note says. Starting from the README's own notes, my checklist would look like this. Verify each package against the release checksums before running it. Approve only the project folder needed for the evaluation. Review capabilities before connecting, not after. On Windows, decide on purpose whether Desktop permissions should stay enabled, and consider whether two workers are needed at all.

I would read the linked tunnel guide and SECURITY.md before connecting.

Updates add their own routine. The README says that after updating you should reload the companion extension and refresh the CoS apps in ChatGPT when prompted.

The project is MIT licensed, and its README states it is not affiliated with or endorsed by OpenAI.

GitHub: https://github.com/totec448-spec/chat-on-steroids

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

qwen-audio-agent keeps the voice talking while your coding agent works

Reno Lu — Fri, 09 Oct 2026 18:35:03 +0000

Reading the qwen-audio-agent README, what stands out is the architecture: a realtime voice layer sits in front of an agent you may already run, such as Qwen Code, OpenCode, Codex or Claude Code, keeps the spoken conversation going, and hands tool work to that backend. The README frames the goal as presence: conversation should not grind to a halt because the Agent is looking something up, calling a tool, or working on a task.

Two lanes, one assistant

The architecture section describes the routing. Questions that can be answered directly are answered immediately; when tools or sustained processing are needed, the task is delegated to the backend Agent. The README adds that throughout, the user always faces the same assistant.

The feature list fills in the concurrency. Frontend conversation and background tasks run in parallel, and you can ask about progress or cancel at any time. You can create multiple independent tasks that the backend Agent executes asynchronously, with continuous status tracking. When a task completes, its result returns to the current conversation, where you can ask follow-up questions or request modifications. The voice side is described as full-duplex realtime interaction with natural interruption and sustained multi-turn conversation.

The README calls this a "foreground conversation + background task" design.

Bring your own backend

The backend side is where I would spend evaluation time. The README says integration reuses your preferred Agent's model configuration, tools, MCP, Skills, and authentication. Backends connect over ACP, and the support table lists how each one gets there: native ACP for Qwen Code, OpenCode, Qoder, MiniMax Code, Kimi Code, Hermes, CodeBuddy and DeepSeek; a built-in ACP bridge for OpenClaw; and an external ACP adapter for Codex, Claude Code and Pi.

Each row carries a rating. According to the README, five stars mean a thoroughly tested recommended integration, while four stars indicate active development or not yet fully verified. Codex, Claude Code, Pi, DeepSeek, MiniMax Code, Hermes and CodeBuddy sit at four stars today, so if your team works in one of those, read the backend documentation before planning around it. There is also a "None" row for frontend-only mode, which needs no config.

The News section records that backend Agents were unified under the ACP architecture in v0.9.0, when the project was open-sourced. The v2.0.0 entry says the next major version is under active development, with ongoing work on the Agent architecture, task lifecycle, multimodal input, memory, and extensibility.

Getting it running

The README asks for Node.js 22.22.2+ or 24.15.0+ with npm 10+, and recommends the global npm install:

npm install -g qwen-audio-agent

Then qwenaudio config creates your config. The example sets DASHSCOPE_API_KEY, QWEN_AUDIO_REALTIME_MODEL for the voice frontend, AGENT_PROTOCOL for the backend (leave it empty or set it to none for frontend-only mode), and an optional QWEN_AUDIO_AGENT_BACKEND_MODEL. The comment on that last variable says explicit values use standard ACP, while an empty value reuses the Agent config.

You start the Gateway in one terminal with qwenaudio and the TUI in another with qwenaudio tui, or use qwenaudio webui for the browser UI. DashScope realtime voice is the default. The README lists Speech-to-Speech and ModelBest MiniCPM-o 4.5 as alternatives, with local or hosted endpoints selected through their service URL, and the v1.3.0 note describes the speech-to-speech integration as supporting fully local VAD, STT, LLM, and TTS.

A desktop app is also available. It provides a persistent floating voice orb with a built-in Gateway, automatic idle sleep, local voice wake, and customizable appearance, and the README includes build scripts for macOS, Windows and Linux.

Beyond the desktop

The README says the current framework focuses on desktop productivity, then argues the same split can expand to other scenarios. Its table marks a smart cockpit example and the VoiceMem and LightRAG integrations as available, an AI Passport hardware card as experimental and currently half-duplex only, customer support and embodied intelligence as planned, and a livestream assistant as exploratory.

The smart-cockpit reference scenario ships in the repository, and the README describes its cockpit UI, small A2A Agent, and cockpit service as customer-replaceable examples. LightRAG connects through the generic KnowledgeProvider, and the README notes that the core npm package includes neither LightRAG nor VoiceMem Python code or dependencies. Lightweight Markdown memory remains the default.

GitHub: https://github.com/QwenAudio/qwen-audio-agent

Curated by Agent Palisade — practical AI for small and mid-sized businesses.