Open Source Radar: Freigaben wandern vom Prompt in die Pipeline

Posted on Oct 28 • Originally published at widechaos.cn

By Renchao Wu. Originally published on widechaos.cn.

Each day I pick five projects from GitHub's candidate pool, which mixes the Trending page with topic searches, mostly AI agents and developer tools. I read each project's README, release notes and recent commits; I did not install them unless an entry says so. Stars and other numbers are from GitHub as of 2026-10-28.

In one line: turns the coding agents running on your own machine into conversations you can approve from a browser or a phone.

What it is: Ovis is a front end for herdr. herdr describes itself as the runtime that coding agents live on: it keeps the terminals of Claude Code, Codex, OpenCode and similar tools in a background server so they survive a closed client or a dropped SSH connection, and it marks each pane as working, blocked or idle. Ovis opens a window onto that: browser, Mac app and phone all see the same sessions. The project was created on 2026-09-17 and has 1,561 stars now; it is TypeScript on Bun, with React and xterm.js in the front end.

Compared with: the project's own FAQ names the alternatives. collie is a mobile terminal for herdr, tmux and zellij, with a status dashboard, key pad, quick replies and voice input, served by its own bridge; roamgate is a browser client for herdr with a file explorer and diff annotations; herdr-remote is a macOS menu-bar app with a Telegram bot behind a relay and a free tunnel. Against Happy, Paseo and CloudCLI UI the split is architectural: those start and manage agents through their own wrapper, daemon or server and ship their own apps, while Ovis only acts as a window. These are the project's claims; I did not install the others to check them.

Recent updates: v0.4.19 (2026-10-27) lets you update an older Ovis on a given PC from its own card, brings Antigravity chat to Windows, shows pictures from omp sessions and Codex tools, renders OpenCode subagents as background tasks, and can revoke every paired device at once. The same day shipped remote-v38, which gives the SSH remote bridge runtimes a SHA-256 manifest. A checksum manifest alone does not establish publisher authenticity.

Who it's for: people already using herdr across several machines who are often away from the keyboard. Without herdr, look elsewhere.

My take: ⭐⭐⭐. It invents no new capability; it moves the moment when an agent is stuck waiting for one sentence onto a phone, and its documented live-menu check addresses stale options. I have not tested races between verification and submission.

Checked: read the README, docs/guide.md, the v0.4.18 and v0.4.19 release notes and the last five commits; did not install.

In one line: a 1.3B-parameter document parsing model that turns PDFs and document images into Markdown or JSON with layout coordinates.

What it is: OXR comes from the SoMark team and was created on 2026-10-05. It splits the job in two: a layout analysis model cuts regions, and the OXR model handles recognition with reading order folded into that stage. The README says this is the main difference from comparable tools, which either give layout to the recognition model or use a dedicated model that also handles reading order. Output is Markdown or JSON, with bounding boxes per element.

Compared with: the project's benchmark document gives full component tables for three benchmarks, with an accuracy snapshot dated 2026-10-05, and notes that peer scores come from published papers, model cards and a pinned commit of the relevant leaderboard README. Overall scores are 87.84 on olmOCR-bench (second place Infinity-Parser2-Pro at 87.60), 97.18 on OmniDocBench (second place TeleOCR at 96.91) and 87.76 on DocParsingBench (second place PaddleOCR-VL-1.6 at 85.17). The three reported overall margins are 0.24, 0.27 and 2.59 points, but the components do not all lead.

On OmniDocBench, Formula CDM is only 0.85 points ahead of the runner-up TeleOCR (97.44 against 96.59), and Table TEDS is actually 0.20 points behind (96.62 against 96.82). On DocParsingBench, Formula leads by 10.17 points (85.76 against 75.59). Which component is strongest cannot be read off the total, so fit depends on which element types dominate your documents.

All of these numbers are the project's own; I ran no evaluation and did not reproduce them on another machine.

Recent updates: no formal release; main still sits on the 10-05 launch. Commits from 10-19 to 10-24 are README, badges and community links (a WeChat QR code, LinkedIn), with no code movement.

Who it's for: people whose documents are table-heavy and who must process them locally; the README's examples include financial reports, exam papers, newspapers and handwriting. The documented local setup starts at 24GB; I have not tested lower-memory alternatives. Check permission and data-handling terms before submitting confidential scans to a hosted API.

My take: ⭐⭐⭐. The part worth learning is the module split: layout on its own, replaceable, with recognition and reading order bound together. That the top score leads by 0.24 points says more than the top score itself.

The model uses Apache 2.0 with additional terms, according to its licensing documents. Those terms address consolidated commercial thresholds for the user and affiliates, attribution for online services, and a separate written licence for a competing hosted API. Read the exact code and model grants for the intended use.

Checked: read the README, the full docs/benchmark.md, the additional license terms and the last five commits; did not install or run any evaluation.

GitHub: https://github.com/elayadesign/ai-design-skills

In one line: a design skill collection for coding agents, currently one skill, where 18KB of Markdown spends half its length on what a page should say and half on visual values that are not up for debate.

What it is: the repo is organised one folder per skill, and you install only what you need: copy into.claude/skills/ for Claude Code, download into.cursor/rules/ for Cursor, paste into AGENTS.md for Codex,.windsurfrules for Windsurf,.clinerules for Cline, or straight into a system prompt. The whole repo is 38KB of text with no code. landing-page-design has two parts: Part A covers strategy and structure, Part B is the visual system. The opening fixes precedence: when this file conflicts with a framework default, the file wins; when the user's explicit request conflicts with it, the user wins.

Compared with: it divides work with the same author's redesign-skill rather than competing with it: that one diagnoses why an existing site looks template-generated, this one builds from scratch, and each points at the other. The content realism and motion ideas are adapted from Leon Lin's taste-skill (MIT); the SKILL.md appends that license in full and notes that overlapping sections were rewritten. What is unusual is how prescriptive it is: it turns design choices into values and prohibitions, and decides who wins a conflict.

Recent updates: no release. On 10-25 a design-to-motion skill was added; on 10-26 it gained guidance for screenshot sources and a small entrance animation for site heroes, and on the same day the sections overlapping taste-skill were rewritten with credit; on 10-27 that skill moved to its own repository. So the collection grew one skill and lost it within two days, and still holds one.

Who it's for: people who want explicit landing-page layout defaults rather than selecting every value during generation. One-pass correctness is not established. It is tied to the Tailwind scale, so outside Tailwind the snap-to-step rule needs a replacement scale; the style is locked down as well, which makes pages look like each other.

My take: ⭐⭐. The content is not new; what interests me is the specificity of its instructions and file structure; a Markdown rule is not runtime enforcement: strategy first, values after, a design-values block at the end that changes the whole file when edited.

Checked: read the README, the full SKILL.md, the LICENSE and the last five commits; did not generate a page from it.

GitHub: https://github.com/kortix-ai/suna

In one line: a self-hosted agent platform that treats a company as a git repository, with each session on its own sandbox and branch and every artefact landing through a change request.

What it is: the repository is still named suna; the product is now Kortix, created 2024-10-05. A project is a git repo plus a kortix.yaml holding agents (role instructions in Markdown), skills, memory, connectors and triggers. Each session gets a disposable Linux sandbox in the cloud on its own branch, where the agent can install and run software within the configured permissions, with committed repository changes preserved. External calls and side effects are not undone by discarding a branch; reaching main requires a change request that a person reviews.

Compared with: the README names n8n, OpenHands, Paperclip and Onyx-style chat tools. Its split: n8n fits fixed flows; OpenHands is a coding-agent control centre for engineering teams; Paperclip adds an org chart, budgets and a task board on top of existing Claude Code or Codex runs; Onyx-style tools are a chat window over documents. Kortix wants the platform to run the agents, one cloud computer per session, all configuration in one repo.

The table is marked as reflecting publicly documented behaviour as of July 2026, and I did not check each competitor's docs; what can be verified independently is the mechanism: per-session sandbox, branch per session, merge through a change request, configuration in git, all of which match the CLI commands ( kortix sessions new, kortix cr ls, kortix ship ).

Recent updates: v0.14.8 (2026-10-23) makes every new session run pi and marks OpenCode deprecated while existing sessions keep it, and adds sharing of a single assistant response. v0.14.7 (10-22) adds project transfer between organisations or accounts, a per-project default reasoning effort, and running a session on your own machine through kortixd with a ChatGPT subscription.

Who it's for: teams that want agents with audit trails and approvals; any proposed hosted-service use needs review of the actual licence and any separate grant. The stack is not light: cloud sandboxes, SSO and a connector broker all have to land.

My take: ⭐⭐. The institution is the thing to copy: configuration in git, changes through a change request, merge denied by default. The stack itself is too heavy for a single user.

Checked: read the README, the LICENSE, the v0.14.7 and v0.14.8 release notes and the last five commits; did not deploy it.

GitHub: https://github.com/dramaclaw/dramaclaw

In one line: a self-hostable production line for AI short drama, with an infinite canvas for experimentation and a pipeline that covers episode planning, scripts, storyboards, voice-over and the final cut.

What it is: created 2026-03-27. Two surfaces share one asset library and one built-in agent. XiaHua is a node-based infinite canvas with 18 node types where you generate, edit and connect images, video, audio, 3D sets and scripts, then promote what works back into a series; XiaJi is the pipeline that takes a manuscript or screenplay through episode planning, scripts, storyboards and first frames, voice-over and export; Xia Director spans both, turning a creative brief into a node graph that runs after confirmation, with progress tracking and failure recovery.

Compared with: the README includes a capability table where competitor names are partly masked (L*TV, R*Hub, T*Now, S*ko, U*dream and others) and the note says the comparison is based on publicly available product docs and positioning. Masked names cannot be matched to specific documents and the ticks have no published criteria, so I do not accept a claim such as "the dual track is unique to it". What can be checked sits at the mechanism level: canvas nodes keep their own generation history, the asset library and the series project onto each other, skills are exportable, and Agent Kit speaks MCP.

Recent updates: v2.0.6 (2026-09-28) adds video extension that keeps the original aspect ratio, model-backed resolution and frame-rate enhancement including interpolation, and MP3 output for separated audio. v2.0.5 (09-17) lets archived generated media be delivered and accessed instead of relying on expiring links, and adds two LingShan image models to the community edition. Releases stop at 09-28 while main keeps moving, with the storage preflight and Portuguese localization on 10-26.

Who it's for: small teams with a script who want to assemble a short-drama or e-commerce video line themselves. Watch the license: the project describes Elastic 2.0 as source-available and permitting standalone and commercial use subject to its terms, and keeping the Powered by DramaClaw notice in the UI is what the project asks for. What it restricts is providing the software itself to others as a hosted or managed service using its features; the README says the hosted-SaaS grant is not open yet. Trademarks and brand assets are not licensed with the code.

My take: ⭐⭐. The engineering is substantial, but the comparison table cannot be verified and the license has its own terms; read both before deciding.

Checked: read the README, the NOTICE, the LICENSES directory and the head of license-inventory.csv, the v2.0.4 to v2.0.6 release notes and the last five commits; did not deploy it.