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

Developer Renchao Wu published an Open Source Radar roundup of five GitHub Trending projects, led by Vercel Labs' agent-browser, a native Rust CLI that gives AI agents one shell command per browser step, returning pages as compact text with element references like @e1. The tool runs a background daemon driving Chrome over the DevTools Protocol, keeps the browser open between commands, and bundles version-matched skill instructions into the binary via `agent-browser skills get core`. Wu notes Playwright MCP's own README argues CLI-based workflows are more token-efficient than MCP tool calls, and flags that none of the five projects was installed or run.

By Renchao Wu. Originally published on widechaos.cn https://widechaos.cn/blog/oss-radar-2026-11-06-en . 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. GitHub: https://github.com/vercel-labs/agent-browser 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: 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. 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. 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. GitHub: https://github.com/alibaba/zvec 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. 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. GitHub: https://github.com/ConardLi/garden-skills 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. 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. 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. 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. GitHub: https://github.com/floci-io/floci 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. 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. / 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. GitHub: https://github.com/kortix-ai/CompanyOS 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. /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. 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. | Project | What it is | Most distinctive | Who it's for | Worth a deep look | |---|---|---|---|---| | agent-browser https://github.com/vercel-labs/agent-browser | Browser CLI for agents | Skills released with the binary | People running CLI-style coding agents | ⭐⭐⭐ | | zvec https://github.com/alibaba/zvec | In-process vector database | Dense, sparse, full-text and filters in one query | Single-machine retrieval, no concurrent writes | ⭐⭐ | | garden-skills https://github.com/ConardLi/garden-skills | Six agent skill packs | Deterministic rendering, acceptance split from taste | Agent-driven content production | ⭐⭐ | | floci https://github.com/floci-io/floci | Local AWS emulator | No account or token, MIT, commercial use | Local and CI tests with AWS dependencies | ⭐⭐⭐ | | CompanyOS https://github.com/kortix-ai/CompanyOS | Multi-agent runtime | Per-session cloud computer plus independent verifier | Long-running agents, self-hosted | ⭐⭐ |