Open Source Radar · 2026-11-06: Browser tools for agents move to the command line

By Renchao Wu. Originally published on widechaos.cn.

These five projects come from the GitHub Trending entry point captured on 2026-11-06, plus keyword search over repositories. After de-duplication the run produced 12 candidates, ranked by relevance to the work I am doing, then distinctiveness, then heat. Every star count and judgment below rests on that day's GitHub API snapshot, each project's README, its release records and recent commits. I also read the CompanyOS LICENSE in full, LocalStack's own announcement about its community edition, and the Playwright MCP README as a comparison point. None of the five was installed or run.

1. vercel-labs/agent-browser ⭐ 46,003 · Rust

GitHub: https://github.com/vercel-labs/agent-browser

In one line: A browser reduced to one shell command per step for an AI agent, with each page returned as compact text carrying element references.

What it is: A native Rust CLI that works one step at a time. open loads a page, snapshot -i returns the interactive elements, each tagged with a reference such as @e1, click @e1 acts on it, and get url checks the result. The browser stays open between commands: the CLI sends each command to a background daemon that drives Chrome over the DevTools Protocol. Every --session gets its own daemon and browser, and by default a headless browser closes and its daemon exits after an hour without commands. The repository was created in January 2026, ships under Apache-2.0, and main is still moving today.

What stands out:

• References expire, and a failed click fails loudly. A reference describes the page at the moment of the snapshot, so after navigation or a DOM change you must take a new one. When a target is covered, hidden, disabled or outside the viewport, the command returns an error. A consent banner covering the button counts as failure, so the agent has to dismiss it and retry. Silent success is harder to debug than failure, which matters for a tool built for agents.
• The skill ships with the binary. agent-browser skills get core returns instructions matching the installed CLI; --ref loads one section, --full adds the complete command reference. The skill installed into an agent is only a thin stub telling the agent to read skills get core. Bundling the instructions with the installed binary can reduce version drift; it does not prove that every instruction matches runtime behavior.
• One daemon per session. The hot path is a single short shell call, the documented sessions use separate processes and browsers, and an idle session cleans up after an hour, saving state first when persistence is configured.
• Debugging sits at the same layer as acting. The command table includes console, errors, trace, profiler, vitals, a11y and react; diff, record and download provide comparison and capture-related commands; their presence does not establish deterministic replay.
• Three ways in: direct CLI calls, an stdio MCP server via mcp, and batch or integration paths through webmcp, plugin and batch. The browser can be a local Chrome for Testing, the Lightpanda or Obscura engine, Mobile Safari in the iOS Simulator, or a cloud provider such as Browserbase or Browserless.

Compared with: Against Playwright's MCP server, the difference is the shape of the interface an agent gets: MCP tool calls on one side, a command line on the other. Playwright MCP's own README says coding agents increasingly favour CLI-based workflows exposed as skills over MCP, because CLI calls avoid loading large tool schemas and verbose accessibility trees and are more token-efficient; MCP stays relevant for exploratory loops that need persistent browser context and rich introspection. agent-browser sits on the CLI side and binds its skills to the binary version, and I found no equivalent mechanism in the Playwright MCP documentation.

Recent updates: v0.41.2 (2026-11-03) made skills loadable by section (skills get <name> --ref <ref>); it added a warning when a newer stable Chrome lists CVE fixes, without blocking commands; and it fixed two failures that interrupted long tasks, one where omitting or changing a timeout restarted the session and one where a bare open dropped configured profiles and relaunched Chrome with a temporary one.

Who it's for: People already driving a CLI-style coding agent who want that agent to open and read pages on its own. Two caveats: the default browser is a separately downloaded Chrome for Testing, and with a cloud browser provider the page renders on a third party's machines, where login state and billing follow that provider's terms; that boundary needs a look first.

My take: ⭐⭐⭐ It turns how an agent uses a browser from a tool call into a command line, and bundles skills with the executable to reduce documentation-version drift.

Checked: read the README, release records and recent commits, plus the Playwright MCP README for comparison; did not install it or drive a browser.

2. alibaba/zvec ⭐ 16,190 · C++

GitHub: https://github.com/alibaba/zvec

In one line: A vector database that lives inside the process, able to combine dense vectors, sparse vectors, full-text search and structured filters in a single query.

What it is: An in-process vector database from Alibaba, shaped like a SQLite for vector search: no separate database service is required, and data is stored in a local directory. The host application still needs configuration and operational controls. Indexes scale from memory to disk, with HNSW, IVF, DiskANN and RaBitQ available; official SDKs cover Python, Node.js, Go, Rust, Java and Dart/Flutter, and platforms run from Linux, macOS and Windows to Android and iOS. The repository was created in December 2025, ships under Apache-2.0, and has iterated to 0.8.0 within a year.

What stands out:

• Embedded deployment with an exclusive writer. Several processes may read the same collection simultaneously, but writes are exclusive to one process. That decides the shapes it fits: desktop and edge applications are plausible uses; concurrent writers, tenant isolation and access control need separate design and verification.
• Dense, sparse, full-text and filters share one schema. Sparse vectors and keyword full-text search can be pushed down together with structured filters, including LIKE and floating-point ranges, offering a documented route to hybrid retrieval in one engine. Fusion quality still needs evaluation on the intended data.
• Durability comes from a write-ahead log. The project documents crash and power-failure durability through its WAL. I did not test recovery, storage behavior or durability settings. Index types scale from memory to disk depending on data size, but the README lists no switchable storage modes.
• The trade-off is stated in the release notes. Version 0.8.0 added uniform UINT4 quantization, which avoids reconstructing scores point by point during a query; sharing one min/max range across all indexed points can increase quantization error and reduce recall. The project says so itself, which is more credible than a QPS chart alone.
• Chinese full-text search works out of the box. The default Jieba dictionary and HMM model are embedded in the native library, so no dictionary path is needed. The same release removed global configuration entry points such as init(jieba_dict_dir=...), a breaking change that requires code edits on upgrade.

Compared with: Against service-based vector databases such as Milvus or Qdrant, the difference is the deployment shape and the failure surface; the index algorithms are common ground. A service adds a networked process and operational responsibilities. Multi-tenancy and scaling depend on the product and deployment; I did not compare those implementations here. zvec compiles the library into the process, avoiding a separate database server. Backups, upgrades, file access and crash recovery remain operational responsibilities. Whether that trade is worth it comes down to three things: write throughput and concurrent reads in practice, the quality of score fusion between full-text and vectors in hybrid queries, and the recall-versus-latency curve of the disk indexes at realistic data sizes. I measured none of them. The footnote in the README gives one configuration only, GIST 1M, L2 distance, INT8 quantization, HNSW on a 16-core ARM64 machine; the full methodology sits on the docs site's benchmark page, which I did not read, so those numbers do not generalise to other datasets.

Recent updates: v0.8.0 (2026-10-21) extended builds and wheels to Intel Mac and Windows ARM64 and DiskANN to Windows, Android and iOS; it lowered peak memory during IVF and DiskANN builds and merges; it added Turbo PQ with 4-bit FastScan, backed by SIMD distance kernels and precomputed residual tables for IVF; and it put HNSW, IVF and DiskANN on a shared page cache, with DiskANN falling back to direct I/O under cache pressure.

Who it's for: Cases where the data fits on one machine and writes do not run concurrently, such as desktop apps, command-line tools, edge devices and retrieval prototypes on a laptop. It is not the right fit for multiple writers, multi-tenancy or independent scaling. The repository lists Apache-2.0; inspect the applicable license and bundled dependencies for the intended use.

My take: ⭐⭐ It fills in the "vector database as SQLite" path and is honest about the trade-offs; the constraint to check before adopting is single-process writes.

Checked: read the README, the v0.8.0 release notes and recent commits; did not install it, build an index or run a benchmark.

3. ConardLi/garden-skills ⭐ 14,230 · JavaScript

GitHub: https://github.com/ConardLi/garden-skills

In one line: Six skill packs written to the SKILL.md format, covering code-rendered video, web design, image generation, long-form article layout and local knowledge retrieval.

What it is: A skill collection where each of the six skills is its own directory, installable together or alone: motion-showreel for code-rendered short motion pieces and product films, web-video-presentation for web video and decks, web-design-engineer for web design, gpt-image-2 for image generation, beautiful-article for turning any source into a laid-out article, and kb-retriever for local knowledge retrieval. Each ships a README, and some add on-demand reference docs, scripts and assets, which the README marks optional. Each is released by version and offers a pinned zip with a checksum. The compatibility table lists Claude Code, Claude.ai, Cursor, Codex CLI, Gemini CLI and OpenCode, all marked as tested.

What stands out:

• A rendering pipeline with a documented determinism gate. The skill documentation says every output of motion-showreel (stills, contact sheets, three-direction boards, proxies and masters) comes from the same render(t) page. Motion blur, supersampling and film grain are render flags, not a second generation pass. Using one rendering path gives technical checks a shared target; I did not test repeatability across machines or versions.
• Picture and sound share one timeline. Cuts, hits and sound effects land on the same numbers; music can come from a built-in zero-dependency synth or Tone.js with a sampled piano, or from the user's own track with beat and drop detection.
• Technical acceptance is separated from taste. The skill specifies checks for size, frame rate, duration, frame count, black frames, loudness, true peak, loop seam and determinism, with subjective decisions returned to the user. Instructions alone do not establish that every host enforces those gates. The result can be restated and checked rather than argued from taste.
• Three prescribed checkpoints, with decisions recorded item by item. beautiful-article runs source, plan, double confirmation, build, final review and repair, confirming article type, theme, layout, image strategy, cover and delivery format individually, with no silent defaults.
• The retrieval instructions set a ceiling. kb-retriever reads layered data_structure.md files to navigate, then narrows candidates, then reads local windows, with at most five search rounds. PDF and Excel files must be learned before processing, using the bundled reference docs rather than trial and error.

Compared with: This review did not establish how representative other skill collections are. This one is six process packs with release flows and acceptance criteria. Each skill is released separately (motion-showreel 0.1.0, web-design-engineer 1.3.0, web-video-presentation 1.2.2, kb-retriever 1.0.1); technical acceptance and aesthetic judgment are split inside each skill; and one install path uses a pinned zip with a SHA-256 checksum for unattended setups. The cost is scale: six skills is far narrower than an aggregator.

Recent updates: motion-showreel v0.1.0 (2026-10-11) shipped with showreels, UI morphs, kinetic typography and beat-synced music; its QA workflow gained per-shot motion analysis, text-framing checks, and grid and heat-map measurement tools for reference video; builds gained a determinism gate, loop-seam validation and layer-mode checks. Main was still adding render context through 2026-10-25, passing frameTime and fps into rendering so text does not blend across subframes at cuts, though that path is optional and only active when RENDER_CONTEXT is enabled.

Who it's for: People doing content production with agents that support SKILL.md, such as Claude Code or Cursor. Two things to watch: the skills call external services, with narration in motion-showreel going through Gemini or MiniMax TTS and gpt-image-2 using GPT Image 2 or OpenAI-compatible image APIs, so which provider you use, whose key it takes and how billing works depend on what you connect; and "tested" is the author's claim across six runtimes, which needs re-checking on any other agent.

My take: ⭐⭐ The six skills are the vehicle; what is worth reading is the discipline of versions, acceptance criteria and checkpoints.

Checked: read the README, each skill's release notes and recent commits; installed no skill and rendered no video.

4. floci-io/floci ⭐ 30,514 · Java

GitHub: https://github.com/floci-io/floci

In one line: A local emulator for selected AWS APIs, with a documented Compose setup and shared endpoint on port 4566.

What it is: A local AWS emulator that keeps LocalStack's port convention, which can simplify endpoint changes. Port compatibility alone does not establish application-level migration compatibility. It implements services in three groups: stateless ones (SSM, SQS, SNS, IAM, KMS, EventBridge, Step Functions, CloudFormation, API Gateway, Bedrock Runtime and others) run in-process; stateful ones (S3, DynamoDB and DynamoDB Streams) use its own storage backends; container services (Lambda, RDS, ElastiCache, Neptune, ECS, EC2, MSK, EKS, OpenSearch, CodeBuild, Managed Flink) run real Docker containers. Athena runs through a DuckDB sidecar. MIT licensed, created in February 2026.

What stands out:

• No account, no token, no feature gates. This is the most direct difference, stated in the first line of the project; credentials can be any non-empty value unless stricter per-service auth checks are explicitly enabled.
• Container-backed execution for selected services. Selected services use Docker containers, which exposes some runtime behavior. It does not establish full AWS error semantics, IAM equivalence or coverage for every configuration.
• Four storage backends. In-memory, persistent, hybrid and write-ahead log, chosen by durability needs; multi-account isolation is handled separately.
• Images and native binaries. The README says each release also ships a standalone floci-aws binary for Linux, macOS and Windows. The asset lists for 2.4.0, 2.3.0 and 2.2.0 that I fetched are empty, so the actual download path is unconfirmed and this is not a verified install route yet.
• The console is replaceable. /_floci/ui pulls a sidecar container for browsing resources; any image implementing the console contract can be attached, provided it listens on PORT, serves GET /api/health and talks to AWS_ENDPOINT_URL.

Compared with: The difference comes from a real shift in the ecosystem. LocalStack's own announcement states that from March 2026 Community and Pro unify into a single image, running it requires an account and an auth token, pinned prior tags run without auth but opt out of future service and security updates, and the free tier is for non-commercial use. floci documents an MIT-licensed, token-free alternative; API fidelity and dependency requirements still need evaluation. The README's comparison table also cites start-up around 24 ms, idle memory around 13 MiB and an image near 90 MB; those are the project's own figures and I did not re-measure them. To decide whether it can replace a service, the relevant test is whether the APIs you actually call behave the same: SQS visibility timeouts, DynamoDB conditional writes, Lambda runtimes. Breadth of coverage is not fidelity.

Recent updates: 2.4.0 (2026-10-31) routed API Gateway v2 VPC link integrations to Cloud Map service instances; completed Auto Scaling support for DescribeTags, EnterStandby and ExitStandby plus suspended-process reasons; added a logically air-gapped backup vault; and filled in CloudFormation support for RDS cluster and instance AssociatedRoles and AWS::EC2::PrefixList.

Who it's for: Teams with AWS dependencies that need integration tests locally or in CI, especially commercial use, which LocalStack's free tier excludes. Two caveats: the console and container services need the Docker socket, so the CI runner's permission model has to be checked; and services with incomplete coverage need a fallback to real cloud or a mock.

My take: ⭐⭐⭐ Worth evaluating when its documented licensing and account model fit. Test the specific AWS calls and failure cases the application relies on.

Checked: read the README, the 2.4.0 release notes and recent commits, plus LocalStack's announcement about its community edition; started no container and ran no comparison test.

5. kortix-ai/CompanyOS ⭐ 20,387 · TypeScript

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

In one line: An agent runtime that treats the company as an operating system, giving each session its own cloud computer, waking agents on events, and letting long jobs outlive a single context.

What it is: A cloud-native agent harness. You write agents on the open-source harness pi, and it deploys them and supplies what a single session cannot: always-on execution, event triggers, parallelism, long jobs across contexts, and shared team memory and permissions. Every agent, skill, rule and connector is a file in one git repository, declared by kortix.yaml. The repository was created in October 2024, in TypeScript.

What stands out:

• Compute and state are separate. Each session runs on its own cloud computer, sleeps 15 to 20 minutes after the last turn, and wakes with its full history on the next message or event; state lives in the git repository, in Drive, in the session's /workspace and in the session record. The project describes compute suspension during idle periods and horizontal allocation across session machines. I did not verify billing, residual resources or capacity limits.
• A full context is replaced, not summarised. When a context fills, the agent continues in a fresh one and searches the session's complete record for the exact lines it needs; the project's wording is that nothing is summarised. Keeping the full record available is a retrieval strategy; it does not prove that relevant details will be found or that a long-running job resumes correctly.
• Events are filtered before any model runs. Schedules, signed webhooks, connector events, app events and merged change requests all start agents, with a filter in code dropping noise first. A session can subscribe to events from its own work, and an agent sets its own check-in before stopping.
• A separate session decides completion. A goal is stated once in plain words, an agent owns it end to end and wakes itself on a schedule, a separate verifier session confirms it is done, and changes land through a change request a person approves.
• One AI for a whole team. Teammates share the same agents, skills, memory and connectors, with roles, groups and per-resource permissions; connectors cover more than 3,000 apps plus MCP, OpenAPI, GraphQL and raw HTTP, and the README says connector credentials remain server-side. I did not audit credential handling or tool-mediated data exposure.

Compared with: It describes a particular multi-agent deployment design by treating a session as a compute unit with a lifecycle: its own cloud computer, sleep and wake, continuation across contexts, event-driven starts. The split from graph-orchestration frameworks shows up on long jobs: a graph is good at stringing together known steps, while this project describes goal ownership, scheduled continuation and a separate verifier session. That separation does not make verification independently reliable by itself. The README lists deployments including a research assistant at the Hong Kong Institute of AI for Science at City University of Hong Kong, fibre-route design at a US telecom infrastructure company, and an international executive search firm, all stated by the project.

Recent updates: v0.14.19 (2026-11-04) brought voice calls into sessions, so you can call a session's agent from the session or agent page with screen sharing while the chat keeps what was said (behind the voice_call flag); speech-to-text and text-to-speech go through the LLM gateway under the same budgets and access rules as model calls; Discord became a regular channel; and self-hosted sessions start from a project snapshot in bundled object storage. One availability fix: an invalid kortix.yaml no longer takes a project down, which keeps the last valid version and refuses the broken push.

Who it's for: Teams that want many agents running long jobs, with self-hosting and shared context and permissions. Check the licence first: the repository LICENSE is Elastic License 2.0, which forbids providing the software to third parties as a hosted or managed service where that service gives users access to a substantial set of its features, while the README calls the project open source throughout. I read the white-label licence text too. That text describes a no-fee arrangement with an exclusivity condition: Platinum supplies the listed sandboxes, volumes, runners, AI compute and inference. This is not a determination of eligibility or the complete obligations for a deployment. It also states that Kortix may end the agreement at any time with written notice, leaving up to 90 days to move existing customers, while termination for breach takes effect immediately with no transition period. Anyone planning to offer it as a service should read both texts rather than the README's wording.

My take: ⭐⭐ The architecture is worth reading, and "replace the context, search the full record" is an unusually honest answer for this class of system; the gap between the licence and the README's wording is the real barrier to adoption.

Checked: read the README, the v0.14.19 release notes, recent commits and the full LICENSE; deployed nothing and ran no session.

At a glance

Notes from this issue

• The interface an agent gets for a browser is splitting in two, and the evidence comes from a competitor's own docs. Playwright MCP acknowledges that coding agents prefer CLI plus skills because it saves tokens, and leaves MCP for exploratory loops that need persistent context. agent-browser takes the CLI side and binds its skills to the binary. The thing to watch is whether instructions and the executable can drift apart.
• Vector databases are swinging back to embedded, with a hard constraint. zvec puts dense, sparse, full-text and filtering inside one process and uses a WAL for durability, at the cost of single-process writes. The line in its release notes about shared min/max ranges increasing quantization error and reducing recall says more about the real trade-off than any QPS chart.
• Skill packs are acquiring release discipline. Six skills with separate versions, pinned checksums, a prescribed technical acceptance list, taste left to the human, and retrieval capped at five rounds. That sits a level above a prompt collection because it admits that finishing and doing well are different things.
• The local-cloud opening was vacated by the incumbent. LocalStack folded its community edition into a unified image that needs an account and a token, with the announcement describing a non-commercial free tier; floci offers a differently licensed, token-free option for evaluation. The test is plain: clean licence, low barrier, and fidelity you verify yourself.
• Long jobs now compete on session lifecycle, and the licence needs saying plainly. A cloud computer per session, idle sleep, waking with history, replacing a full context and searching the record, completion confirmed by an independent verifier: these are runtime design, not model capability. On the other side, a README can say open source throughout while the LICENSE is Elastic License 2.0. Before adopting, read the LICENSE itself.