GitHub AI Daily · 2026-10-25 (Sunday)

1. Today's picks (5)

1. mu (μ) gives a coding agent a small, fast judge — and lifts routine decisions off the big model

URL: https://github.com/qybaihe/mu ｜ ★548 ｜ MIT ｜ TypeScript, v0.2.10 published 2026-10-24 21:48 UTC

What happened
mu positions itself as a coding agent that "thinks before it acts": a small, fast judge makes the routine calls, the big model does the work, implemented on top of the pi framework. The actual changes in v0.2.10 today concentrate on making the judge system extensible:

• Several judge types coexist: openai, systemone and logprob, plus built-in nemotron, nemotron-think and nemotron-local; Nebius Token Factory and NVIDIA Nemotron series are supported as adjudication models.
• Filtering strategy is decided by request routing: logprob judges are queried per item or per segment, while other judges may batch. Whether batching happens is determined by the decision router together with the first trusted judge for that capability.
• recordState keeps a durable trail: judge requests, states and questions are all persisted — retained even when a request fails — and secrets are redacted. A documentation commit states plainly "train your own judge": the retained state is the raw material for training a custom judge.
• Failures do not block: a failed evaluation still keeps the request and state for diagnosis and retry; evaluate() returns the result directly, avoiding rebuilding the request after a failure.
• Detail fixes: default web search needs no API key (Tavily remains optional); the output token cap defaults to 8000 with thinking enabled and 2000 otherwise; a desktop fix names the sub-agents a board line dispatches by their labels.

Why it matters

• Of all the agent projects today, this is the one that maps most directly onto cost structure. Large-model calls are the cost line most likely to run away in an agent project, and "a small judge adjudicates the routine, the big model does the real work" is the concrete implementation of pushing 80% of mechanical decisions onto a cheap model. For an independent developer working under "eight hours a week and a thin cash runway", this is worth more than any multi-agent orchestration framework.
• The recordState plus train-your-own-judge design deserves separate attention: it turns an agent's own judgements into reusable training data. Over time, an agent that accumulates its own judges has a deeper moat than one that can only call a larger model.
• Adjudication is tiered by trust (the first trusted judge sets the batching strategy; the rest route by capability). That two-level "capability plus trust" routing is structurally identical to how you tier evidence in research — the same frame could manage "which conclusions may be accepted automatically, and which require human review".

2. bmlibrarian is a multi-agent biomedical literature system — and today it fixed a hard bug: reading study counts as sample sizes

URL: https://github.com/hherb/bmlibrarian ｜ ★12 ｜ Undeclared (no LICENSE file in the repo) ｜ Python, 1,296 commits, merge landed 2026-10-25

What happened
bmlibrarian is a multi-agent biomedical literature research system built around counterfactual analysis and a complete citation apparatus. It imports data from clinical trials, PubMed, PMC, medRxiv and Europe PMC, and performs literature search, semantic and full-text retrieval, fact-checking and paper review, with research quality assessment, bias-risk and transparency analysis. It ships a Qt graphical interface plus several CLI entry points.

The merge that landed today, PR #359, addresses scoring rigor for systematic reviews — a class of very specific defects:

• Study counts are no longer mistaken for participant sample sizes (writings such as N=8 studies or 18 RCTs were previously read as sample sizes).
• Sample sizes with thousands separators are supported (1,234), and the readable range was widened to 1 ~ 10⁹, removing the previous default lower bound of 5..1,000,000.
• When evaluation fails or is not enabled, each study dimension falls back to NEUTRAL_SCORE; the study-quality fallback was likewise changed to NEUTRAL_SCORE.
• Anomalous bias-risk wording is recorded, missing dimensions in paper scoring are recorded, and tests were added for boundary values, the neutral path, study counts and missing dimensions.
• The same batch also moved the LLM layer to bmlib 0.4.0, fixed model-name routing, fixed agent invocation, and — importantly — prevented chunks from different document databases leaking across calls.

Why it matters

• Bugs of the "the score is simply wrong" kind carry an outsized cost in real-world research: treating 8 studies as n=8 participants directly changes the effect estimate and the strength of the conclusion. bmlibrarian writes those boundary conditions into tests instead of relying on manual review — this is the engineering discipline an evidence-based workflow should have.
• The fix for chunks leaking between databases points at a subtler hazard: context bleed in retrieval chunking lets a model attach database A's evidence to database B's conclusion. Any project doing evidence synthesis needs this hole plugged.
• The combination of multi-agent orchestration, counterfactual analysis and a citation system covers precisely the three most labour-intensive stages of review-style content production — finding evidence, verifying it, and writing traceable citations. For work that must be evidence-based with references attached, this is an architecture worth studying.

3. OpenNutriTracker v2.5.0: an offline-first calorie and micronutrient tracker, with a new "to-log list" capture flow landing on Oct 24

URL: https://github.com/simonoppowa/OpenNutriTracker ｜ ★2,742 ｜ GPL-3.0 ｜ Dart / Flutter, v2.5.0 published Oct 23, commits continuing Oct 24

What happened
OpenNutriTracker is a free and open-source calorie tracker focused on simplicity and privacy: it logs what you eat and drink against calorie and macro targets computed from height, weight, age and activity level, and keeps the record on your phone — no company ever receives your eating history. The Oct 24 commits form one coherent feature push:

• A new "to-log list": add-food entry points are collected onto a single list, and several ways of adding food are combined onto one screen. Along the way, photo headings, tray subtitles and the "to-log" heading were fixed so they stay on one line at large text sizes, and the list is now consistent across its edges. These commits were produced with Claude collaboration.
• Health Connect permissions handled natively: grants are checked natively and the app backs off when rate-limited; the Play Store build had previously been blocked from reading workout data.
• Source-data tolerance: the app no longer crashes when Open Food Facts responses are missing fields or carry wrong field types; unparsable source URLs are dropped before reaching the info button; meal quantities with comma decimals no longer crash.
• Stability cleanup: Sentry no longer reports expected network and not-found errors; an unreadable image cache index is dropped first; every external link launch goes through the safe launcher; iOS export now uses explicit per-target match profiles and clears earlier IPAs so a failed export cannot pass with a stale artifact.

Why it matters

• This is the most mature self-hostable / local-first nutrition record keeper in today's health line, and it demonstrates that privacy-first does not mean feature-poor: IOM dietary reference intake bars, goal planning for 10 nutrients, CSV/JSON export and offline operation are all there. For functional-medicine nutrition interventions, an endpoint that keeps data on-device withstands compliance scrutiny better than any SaaS.
• The "combine all add-food methods onto one screen, plus a to-log list to catch what is still outstanding" interaction change deserves its own look. The biggest drop-off point in nutrition logging is capture friction — users do not want to log less, they find it a chore. Flattening every entry point onto one screen and using one list to hold "not yet logged" items is the standard remedy for adherence, and it applies directly to tracking questions that surface after three months of client use.
• Health Connect authorisation plus rate-limit backoff is the real-world rough edge of pulling health data in on mobile. Any project wiring up Apple Health or wearables can save themselves repeated debugging here.

4. wisp-science v1.21.0: a local-first research workbench that keeps "run code — search literature — leave an evidence trail" inside one project directory

URL: https://github.com/xuzhougeng/wisp-science ｜ ★1,055 ｜ AGPL-3.0-only ｜ Rust desktop + Python/R, Release v1.21.0 published Oct 24

What happened
wisp-science is WISP — Workspace for Intelligent Scientific Practice — an open-source, local-first AI research workbench. In one line you can search the literature, run Python and R, and query roughly 80 scientific databases, while figures, runs, decisions and drafts all stay in the same project. Data, conversations and credentials remain on your own machines, and you bring your own model.

The v1.21.0 release and the surrounding Oct 24 commits concentrate in three places:

• The research assistant is now scoped to the selected project: it works within the currently selected project and answers questions about goals, progress, conclusions, open questions and next steps from a rolling project memory.
• Main-thread notification polling on macOS was stopped, and backup and recovery for damaged project databases was added; macOS now writes wisp.log at startup and surfaces unparsable create-project responses correctly.
• An earlier batch fixed harvest recovery, workflow budget defaults, timeout accounting and gateway retries, among a string of regressions.

Wider capabilities include multi-project and multi-session management, context reuse and session forking, editable handover summaries, background SSH / sbatch long jobs, sub-agents with workflow retry, cross-platform desktop notifications, and daily backup with corruption detection. On the model side it supports TypeSafe Jev, StartLux and custom System One decision models.

Why it matters

• "Every step stays inspectable" is a hard requirement for research tooling. This project puts figures, run records, decisions and drafts in one place, which is functionally the same thing as "preserving an evidence chain" — when doing real-world research and needing to hand the analysis over for client or peer review, a reproducible trail is worth more than a polished result figure.
• Project-level rolling memory plus handover summaries suits anyone running several research threads at once: change device, change session, change sub-agent, and the research context still holds. This is an organisational structure that transfers directly to juggling multiple research lines simultaneously.
• Local-first, bring-your-own-model, and roughly 80 scientific databases lands exactly on the intersection of "data never leaves my machine" and "I can still search real literature". For functional-medicine and precision-nutrition research, literature retrieval and personal health data handling usually have to satisfy both constraints at once.

5. LLMKube v0.10.10: pulling a heterogeneous GPU farm into Kubernetes — and it actually supports Apple Silicon

URL: https://github.com/defilantech/LLMKube ｜ ★244 ｜ Apache-2.0 ｜ Go, v0.10.10 published Oct 24, further main-branch commits Oct 25

What happened
LLMKube is a Kubernetes operator for self-hosted LLM inference, orchestrating a heterogeneous GPU fleet:

• Multiple vendors: NVIDIA CUDA, AMD Vulkan and Apple Silicon Metal are all in scope; runtimes covered are llama.cpp, vLLM, TGI and mlx-server.
• One service shape: multi-GPU sharding, model caching and OpenAI-compatible endpoints, running equally well on a homelab or an on-premises fleet.
• This release: v0.10.10 was cut by release-please with the CHANGELOG updated in step; the Oct 25 main-branch commit moves Go to a unified 1.27.3 and keeps every builder image on the go.mod version (across the Dockerfile and the router-proxy build chain).
• The project describes its own cadence as frequent point releases; the README records three consecutive releases inside October 2026 alone (v0.10.2 through v0.10.4). First-time contributors have landed Intel oneAPI / SYCL GPU support and vendor-neutral DRA scheduling.

Why it matters

• Having Apple Silicon and Metal in scope matters for the local-deployment path. Most Kubernetes inference stacks assume CUDA, so a Mac on the desk usually has to be handled out-of-band. LLMKube listing mlx-server alongside llama.cpp lowers a real barrier for running private models locally on a Mac-primary workstation, with occasional multi-GPU — relevant to individuals and small teams alike.
• Unifying Go on 1.27.3 and pinning every builder image to go.mod is easy to overlook and important in production: a build artifact whose Go version disagrees with the source declaration turns "a reproducible deployment" into an empty claim.
• OpenAI-compatible endpoints plus multiple runtimes means the application layer needs no per-backend adapter. This is the same logic behind wiring local Ollama into a business system: a unified protocol matters more than a unified model, because models change and protocols do not.

2. Category roundup

① AI Coding / Programming Agents & Skill Ecosystem

② Medical / Clinical Research AI & Agent Skill Libraries

③ Health Management / Nutrition & Food AI

④ Model Layer & Agent Infrastructure

3. Trends today

• The most consistent action today is not "build a stronger agent" but "give an agent a cheap dispatch layer". mu hands routine judgement to a small judge, lemoncrow accelerates the runtime, LLMKube opens up the compute orchestration — all three cut in the same place: moving cost from per-call into fixed overhead. For independent developers this matters most, because the real killer of agent projects is not a weak model but an unpredictable bill.

• Scientific agents are starting to take the engineering form of admitting their own imperfection. nninteractive-agent's README states failure modes outright (VoxTell fails on leg muscles, foot bones and animals; open models routinely produce oversized boxes) and insists agents must not skip verification; bmlibrarian turns "study count misread as sample size" into a test case. Writing known defects into documentation and tests is the signature of importing research-grade rigour into agent projects, and it is exactly the layer that evidence-based content production needs.

• Medical AI's centre of gravity has visibly shifted from "diagnostic model" to "annotation and evidence workflow". Among today's medical entries, RetiJev takes the decision-model route (0.8B–9B, 158ms, no autoregressive decoding), nninteractive-agent takes the interactive-segmentation route (say the target, the agent finds it, places prompts, inspects, corrects), and bmlibrarian and biomcp-ts take the evidence-and-database route. Three different roads, one conclusion: not making models better at diagnosing, but making them better at searching, annotating and leaving a trail.

• Competition in nutrition and health tooling has come back to capture friction and data ownership. OpenNutriTracker merges several add-food methods onto one screen and adds a to-log list; openGym has shipped to the App Store while remaining self-hostable; Garmin_Local_Archive keeps the data local and offline — three projects, one question answered from three directions: make logging painless, and keep the data yours. That stands in direct opposition to the subscription-plus-cloud-storage model of commercial nutrition apps.

• Local-first has become the default across this batch. wisp-science, openGym, OpenNutriTracker, LLMKube and bmlibrarian — data stays local, models are brought by you, self-hosting is a first-class path — across four entirely different domains. The reasoning underneath is the same: as data sensitivity rises (health, literature, code), the marginal cost of sending data out exceeds the cost of standing up your own.

4. Repo index

Picks

• qybaihe/mu — https://github.com/qybaihe/mu
• hherb/bmlibrarian — https://github.com/hherb/bmlibrarian
• simonoppowa/OpenNutriTracker — https://github.com/simonoppowa/OpenNutriTracker
• xuzhougeng/wisp-science — https://github.com/xuzhougeng/wisp-science
• defilantech/LLMKube — https://github.com/defilantech/LLMKube

AI Coding

• https://github.com/wangmiaozero/pi-harness
• https://github.com/Graphicle-AI/graphicle
• https://github.com/Vigil-SOC/vigil
• https://github.com/automagik-dev/omni
• https://github.com/Sma1lboy/rove
• https://github.com/KongFangXun/sofagent

Medical / Clinical Research AI

• https://github.com/moritztng/tt-bio
• https://github.com/yeyuan98/biomcp-ts
• https://github.com/MIC-DKFZ/nninteractive-agent
• https://github.com/Awenbocc/RetiJev
• https://github.com/maziyarpanahi/openmed

Health / Nutrition

• https://github.com/DuarteSantos8/openGym
• https://github.com/openfoodfacts/smooth-app
• https://github.com/jrhizor/awesome-nutrition-tracking
• https://github.com/Wewoc/Garmin_Local_Archive
• https://github.com/jouaaaaaa/mcd-self-butler
• https://github.com/polaris-smart/mcd-agent-gourmet
• https://github.com/Ayech14/MealIQ

Model Layer / Agent Infrastructure

• https://github.com/kydlikebtc/awesome-jev
• https://github.com/synthetic-sciences/openscience
• https://github.com/lemoncrow-lab/lemoncrow

31 projects in this issue, all de-duplicated against previous issues. Star counts, licenses and commit times follow GitHub API and default-branch records as of 2026-10-25 11:00 Beijing Time.