Each day I pick five projects that are rising on GitHub this week, 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-19.

1. apache/maka ⭐ 5,847 · TypeScript

GitHub: https://github.com/apache/maka

In one line: A local agent workspace that writes every model call, tool call and permission decision to an append-only log, with the desktop app, the terminal and the evaluator all reading that log.

What it is: An Apache incubating project that reached 5,847 stars and 146 contributors in five months. The core is a Runtime Host: each state root has exactly one execution and write authority, and the Electron desktop app, TUI, CLI, bots and evaluation client all cross the same protocol boundary. Data stays in local SQLite. The evaluation work is published task by task: the project reports that on all 89 Terminal-Bench 2.1 tasks with the same DeepSeek V4 Flash model, Maka passed 61/89 (68.54%) and OpenCode passed 49/89 (55.06%); 16 tasks passed only under Maka and 4 only under OpenCode, with an exact McNemar test at p=0.0118.

What stands out:

  • The log is the source of truth, not an audit trail bolted on later. The UI, the next prompt and crash recovery are all projections of RuntimeEvents. Context pruning changes what the provider sees, never the history. Old tool output can leave the prompt without leaving the log.
  • It accounts for "ran out of budget" separately from "could not do it." In the same report, 15/89 Maka cells hit budget exhaustion (16.85%) against 24/89 for OpenCode (26.97%). This report keeps budget-exhausted cells as scored failures while reporting the rate separately, which is closer to real operations.
  • Cost is measured per pass, not per run. $0.031718 versus $0.031712, a 0.02% difference, and the report states plainly that this is a single-run point estimate, not a test of equivalence. I would read the task-level results before using the aggregate to choose a runtime.
  • Multiple machines do not merge execution authority. Peer Mesh handles membership and connections, a Rust native addon handles direct peers, and each state root still has one writer.
  • Local-first has a stated price. API keys sit in a local plaintext file protected only by the OS account, and older JSONL transcripts are not imported after an upgrade, so an upgraded workspace can show empty threads.

Compared with: For this comparison, I would start with Maka's published per-task CSV, paired test and cost model. Its event-first architecture is useful to examine alongside the workflow definitions in LangGraph or Temporal; these are different design choices, not evidence that other runtimes lack auditability.

Recent updates: 0.2.1-dev.91 (2026-10-18, nightly). Commits on 10-19 include prepare 0.2.2 and correct source packaging (#6148) plus two UI fixes: a race between session settings and sending (#6150), and preserving running tool state on reconnect (#6145). The formal Apache release is still 0.2.0, and the nightly is explicitly marked as not approved by a release vote.

Who it's for: Teams building their own agent runtime who care whether a run can be replayed afterwards, and anyone doing compliance review that needs execution traces. Expect version churn during incubation, and keep nightly builds out of production.

My take: ⭐⭐⭐. The feature list is not the point; the event log and the published evaluation are worth reading the architecture doc for.

Checked: read the README, ARCHITECTURE.md, the Terminal-Bench report under docs/eval, releases and recent commits. Not installed.

2. zvec-ai/zvec-grep ⭐ 4,118 · Rust

GitHub: https://github.com/zvec-ai/zvec-grep

In one line: Ripgrep, BM25 and vector search behind one local MCP interface, so an agent finds evidence with fewer calls.

What it is: The command is zg, the index lives in .zvec-grep/ under the project root, humans use the CLI and agents use MCP. Embeddings run locally by default; remote embeddings receive data only with explicit permission. The vector engine underneath is Alibaba's zvec. Three months brought 4,118 stars and 15 contributors, with only two formal releases (v0.1.5 and v0.2.0) while the main branch moves much faster.

What stands out:

  • Lexical and vector queries share one interface. One MCP call can carry both fts and vector inputs: exact identifiers go through lexical matching, vague descriptions go through embeddings, and the results are fused and ranked.
  • Code gets structure. The index keeps symbols, signatures and breadcrumbs; change #181 on 10-19 adds symbol metadata and file-graph contracts, aiming to make cross-file call chains searchable objects rather than text chunks.
  • The benchmark measures retrieval quality and cost. SWE-QA20 uses 20 fixed questions across 11 repositories pinned to commits, with hybrid, fts and vector arms repeated five times each for 300 calls; there are also BEIR with 75,128 documents, DuRetrieval with 100,001 passages, and Quarry with 20 repositories in eight languages. Metrics are Hit@1/5/10, MRR and nDCG, plus output size and latency.
  • CI compares retrieval quality. Every pull request runs a base / head / delta comparison and posts it back as a PR comment, so retrieval regressions surface before merge.
  • Slow version numbers, moving interfaces. v0.2.0 calls itself the first full public preview, so read the breaking changes before upgrading.

Compared with: ripgrep offers lexical and regex matching only; zvec-grep adds ranked lexical and vector retrieval with a project-local index. For alternatives such as claude-context or an IDE index, I would check the configured embedding provider, data path and index visibility separately. The difference here is two fusible arms plus an index that lives inside the project, where it can be inspected, deleted or rebuilt.

Recent updates: v0.2.0 (2026-08-27) brought hybrid retrieval, structure-aware indexing, managed agent integrations, local and remote embeddings, and incremental updates. 10-15 added Pi agent support (#250); 10-19 added symbol metadata (#181) and fixed an EPIPE when stdout closes early (#241).

Who it's for: Teams whose code and documents sit in the same tree and whose agents keep failing to find things, and anyone who wants data to stay on the machine. Apache-2.0, Node 22 or newer.

My take: ⭐⭐⭐. I would start an evaluation with one subdirectory, then check the retrieval results and indexing cost before expanding to an entire workspace.

Checked: read the README, benchmarks/README, releases and recent commits. Not installed.

3. simstudioai/sim ⭐ 29,836 · TypeScript

GitHub: https://github.com/simstudioai/sim

In one line: A visual platform that puts agents, workflows, tables, files and knowledge bases into one workspace, hosted or self-hosted.

What it is: Chat on the left, a workflow editor on the right, and shared tables, files and knowledge underneath. The README claims 270+ integrations, 5,400+ actions and 520+ triggers. The repository dates to 2025-01, with 53 contributors and more than 100 releases, including three versions in four days. The stack is Next.js, Bun, PostgreSQL, Drizzle and ReactFlow, with E2B for remote code execution, isolated-vm for isolated execution and Trigger.dev for background jobs.

What stands out:

  • The product unit is a workspace, not a single flow. Tables are a built-in database, files are storage shared by the team and every agent, and knowledge bases are synced documents; one permission model covers all of them.
  • Self-hosting is a first-class path. npx sim-setup creates a deployment directory, generates secrets, provisions the database and starts images, with doctor, config and add <capability> alongside; email, storage, sandbox, jobs, cache and knowledge can be enabled separately.
  • Most of v0.9.26 is security work. It removes a client route that let a run's actor rewrite its own log and cost (#9183), revokes sessions and OAuth grants on password reset (#9178), pins Salesforce instance URLs to Salesforce domains and guards custom-field egress (#9177), and ends OAuth grants when SCIM changes an address (#9181). These changes concern tenant-facing access boundaries; the release notes alone do not establish deployment scale or security.
  • The desktop app reuses the same backend. The macOS 12+ client can point at a self-hosted deployment instead of running a second runtime.
  • Self-hosting is not light. The docs require Node 20+ and Docker, and local development notes call for 12GB of memory or more.

Compared with: Sim’s built-in tables, files and knowledge bases are the features I would compare against n8n, Dify or Langflow. Shared storage and permission boundaries need checking in each deployment; an integration count alone says little about whether a workflow fits.

Recent updates: v0.9.26 (2026-10-17) lets Chat read and write Project files (#9034), adds Microsoft Sentinel ingestion (#9162), expands Databricks API coverage (#9163) and adds core Oracle Fusion financial operations (#9165); computer use rolls out per organization (#9182).

Who it's for: Teams stringing several SaaS tools into agent workflows while requiring data to stay in their own database. Budget for self-hosting operations, and expect uneven depth across 270 integrations.

My take: ⭐⭐. Worth reading for the capability plug-in model and the log permissions design; moving the whole platform in is heavy.

Checked: read the README, the v0.9.24 to v0.9.26 release notes and recent commits. Not deployed.

4. QwenLM/qwen-code ⭐ 28,567 · TypeScript

GitHub: https://github.com/QwenLM/qwen-code

In one line: An open-source coding agent for the terminal with documented entry points for IDEs, desktop, the web and four chat platforms.

What it is: qwen is the main entry point, with SubAgents, Agent Teams, dynamic workflows, Auto-Memory, Auto-Skills, hooks, MCP, Plan Mode, LSP, a sandbox, Git worktrees and computer use. There are also VS Code, Zed and JetBrains plugins, a desktop app, a qwen serve web UI, TypeScript, Python and Java SDKs, and a headless mode. The repository dates to 2025-06, with 420 contributors and more than 100 releases.

What stands out:

  • Multiple models head to head on one task. Agent Arena runs the same task across several models; that makes model comparison an explicit workflow to inspect.
  • The daemon is a service, not another terminal. qwen serve turns the agent into a multi-client execution body over HTTP and SSE (ACP), so the CLI, IDE, web UI and chat channels share one session.
  • Chat channels live in the main repository. Telegram, DingTalk, WeChat and Feishu, started with qwen channel start; the skeleton from inbound message to agent reply is already there.
  • SWE-bench is reported as a range, not a peak. Seven versions on the same Qwen 3.7 Max model, 500 tasks and three trials per version average 76.40% to 77.80%. Stable across versions, with no single best score to advertise.
  • Protocols are not locked in. OpenAI, Anthropic, Gemini and Qwen protocols, plus third-party providers and local models through Ollama or vLLM, switchable at runtime.

Compared with: For embedding in another system, I would compare Qwen Code’s three SDKs, daemon protocol and channel support with the interfaces exposed by Claude Code, Gemini CLI, OpenCode and Cline. A shared feature name does not establish behavioural parity.

Recent updates: v0.25.3-preview.0 (2026-10-16) is mostly stability work: journal-only settlement of interrupted turns (#14160), stopping each child's running turn when a subagent closes (#14218), and a restart-proof runtime drain (#13986). 10-19 added warming workspace-isolated workers when an empty session is created (#14599), a configuration template for the managed distribution (#14631), and private file turns through the hosted harness (#14487).

Who it's for: Teams that want an open-model coding agent without a single-protocol lock-in, and developers embedding coding ability into their own product. Apache-2.0, Node 22 or newer. Expect fast iteration on preview builds.

My take: ⭐⭐⭐. The valuable part is turning the agent into a service, not the terminal UI.

Checked: read the README, the v0.25.3-preview.0 and nightly release notes, and recent commits. Not installed.

5. makecindy/cindy ⭐ 3,193 · TypeScript

GitHub: https://github.com/makecindy/cindy

In one line: An open-source agent client that puts Claude Code, Codex and other harnesses into one companion across desktop, mobile and chat.

What it is: The repository holds only the client: an Electron desktop app, an Expo / React Native mobile app and shared packages; the backend lives in a private repository. The first harnesses are Claude Code and Codex, and models and harnesses mix freely, with a mid-task switch that keeps the workspace, memory, skills and tools intact; one task can be planned, executed in parallel and reviewed by different harness and model combinations. The repository dates to 2026-07, with 142 contributors, 68 releases and version numbers still in 0.1.x.

What stands out:

  • Memory sits above the harness. Switching harness, switching models or compressing context does not lose it, and since v0.1.111 changing the primary computer migrates conversations, attachments, to-dos and routines.
  • Steps only the owner can do go back to the owner. Logins, passwords and verification codes become a card on the owner's device, and the task continues after it is filled in; the project says card contents stay on the device and are excluded from model input, records and push notifications. I did not verify that data path.
  • Chat bots can be your own. Telegram, Feishu, WeCom, DingTalk and Discord, with one companion on several platforms; direct messages enter the main task while group chats and stranger DMs get separate sessions, and external members are limited to guest permissions with no command execution.
  • A program-level heartbeat. It finds tasks that are stuck, waiting for confirmation, failing or hitting a quota, and the workbench splits into "waiting on you" and "in progress."
  • 1,755 open issues against 3,193 stars is a high ratio, which could be open triage or could be noise; with a closed backend, check the maintenance rhythm before adopting.

Compared with: Cindy’s documented combination is local execution, swappable harnesses and continuous memory across entry points. I would compare those behaviours directly with a single-harness client or a hosted service, including what still depends on its closed backend.

Recent updates: v0.1.111-beta (2026-10-19) makes the companion follow the account, adds bring-your-own chat bots, the program-level heartbeat and MCP Apps interactive cards; v0.1.110 (10-16) adds on-device voiceprints and one primary computer per companion; v0.1.109 (10-15) turns logins and verification codes into device cards.

Who it's for: People already using Claude Code or Codex who want the same persona to continue on mobile and in chat. Apache-2.0 covers the client only; server-backed capabilities require the official service or your own model keys.

My take: ⭐⭐. The interaction and permission design is worth borrowing; the product itself is still early.

Checked: read the README, the v0.1.109 to v0.1.111 release notes and recent commits. Not installed.

At a glance

Project Category Most distinctive Who it's for Worth a deep read
maka Agent runtime Append-only event log behind every surface Teams auditing and replaying agent runs ⭐⭐⭐
zvec-grep Workspace search Ripgrep, BM25 and vectors in one fused interface Mixed code and docs, slow agent search ⭐⭐⭐
sim Agent workspace Tables, files, knowledge and flows in one place Many SaaS tools, data must stay home ⭐⭐
qwen-code Coding agent Daemon plus SDKs turn the agent into a service Embedding coding into your own product ⭐⭐⭐
cindy Agent client Swappable harnesses with continuous memory Individuals already on Claude Code or Codex ⭐⭐

This week's notes

  • Task-level evidence makes a runtime easier to assess. Maka ships per-task A/B results, a paired test and cost per pass in the repository, which is more convincing than another post claiming a benchmark lead. When evaluating an agent framework, ask whether it will publish per-task results.
  • Retrieval is becoming agent infrastructure. zg's benchmark records retrieval quality, tool calls, output size and latency, not a single recall number. Retrieval quality, output size and latency need to be measured together. A smaller result is useful only if it still contains the evidence the task needs.
  • Coding agents are splitting into two shapes. qwen-code goes daemon, SDK and four chat channels, becoming a service other systems call; cindy goes multi-harness across desktop, mobile and chat, becoming a person's permanent entry point. They expose different entry points for the same underlying coding work.
  • Security fixes in a same-day release say more about a project's stage than new features do. Most of Sim v0.9.26 is OAuth revocation, SCIM changes, log write permissions and egress restrictions, which are concrete boundaries to include in a deployment review. The number of security fixes alone cannot establish production readiness.