Opencli como yt-dlp para cada sitio web.

Good news — this is basically its own genre of tool, and there’s one project in particular that does almost exactly what you’re picturing.

The big one: OpenCLI

There’s a tool called OpenCLI whose entire purpose is “yt-dlp, but for every website.” It turns a website into a deterministic CLI command instead of you opening a browser tab. It comes with built-in adapters for sites like Bilibili, Zhihu, Reddit, HackerNews, and Twitter/X, plus desktop apps like Cursor and ChatGPT, and reuses your logged-in Chrome session so you don’t re-auth. It connects to Chrome through a small browser-bridge extension and a local daemon that auto-starts when needed.

opencli twitter download elonmusk --limit 20 --output ./twitter
opencli bilibili hot -f json
opencli github repo jackwener/opencli --format table

If the site you need isn’t covered yet, you can write a new adapter declaratively in YAML rather than scripting selectors by hand, and it reuses Chrome’s existing login state instead of handling auth separately. Worth a look: github.com/jackwener/opencli (there are a few forks floating around with slightly different adapter counts).

One honest caveat: this works by automating your real logged-in browser session against sites that didn’t design an API for this. That’s fine for personal use, but it’s the kind of thing that can occasionally trip ToS/anti-bot detection on sites that care a lot about that (Twitter/X, Instagram). Worth knowing before you point it at an account you can’t afford to lose.

Purpose-built tools for specific things (the actual yt-dlp lineage)

gallery-dl downloads image galleries and collections from many image-hosting sites, and ddgr is a command-line utility to search DuckDuckGo from the terminal — both work the same philosophy as yt-dlp: one binary, one site (or family of sites), no browser.

Your actual question: Claude via aichat, and GLM

You’re right that Claude’s API isn’t free — Anthropic doesn’t have a no-cost API tier, only paid pay-per-token. aichat already supports Claude (and 20+ other providers) through a unified interface, including OpenAI, Claude, Gemini, Ollama, Groq, Mistral, Deepseek, and ZhipuAI (GLM) among others — so GLM is a first-class citizen in aichat, not a workaround.

GLM specifically: Zhipu offers two models free to all registered users — GLM-4.7-Flash and GLM-4.5-Flash — no subscription required, not just a trial. The API is OpenAI-compatible, which is exactly the format aichat expects. For paid tiers if you want a stronger model, the Coding Plan currently starts around $10/month billed quarterly, with GLM-5 costing roughly 3-5x less per token than Claude Sonnet.

To wire it into aichat, your ~/.config/aichat/config.yaml would look roughly like:

model: zhipuai:glm-4.5-flash
clients:
  - type: zhipuai
    api_key: your-key-from-z.ai

Get the key by signing up at z.ai or open.bigmodel.cn — no card needed for the free Flash models.

Want me to also dig up the exact config syntax/model name strings aichat expects for ZhipuAI (their docs sometimes shuffle naming between zhipuai, glm, and z.ai)?

Short answer: technically yes, but the project’s own docs steer you away from true headless mode — and for a good reason.

Why not pure --headless: OpenCLI’s main selling point is reusing your already-logged-in browser session plus a set of anti-detection patches (spoofing navigator.webdriver, fake plugin lists, etc.). Real headless Chromium has a slightly different fingerprint than headed Chrome, which can trip the very anti-bot/Cloudflare-style detection those patches are trying to dodge — so sites may start blocking or logging you out. That’s likely why their own CI/CD guide doesn’t tell you to use --headless; instead they recommend running a normal headed Chrome inside a virtual display.

What actually works (no visible window, no real headless either):

xvfb-run --auto-servernum google-chrome \
  --remote-debugging-port=9222 \
  --user-data-dir="$HOME/chrome-debug-profile" \
  --remote-allow-origins="*" &

export OPENCLI_CDP_ENDPOINT="http://127.0.0.1:9222"
opencli doctor

xvfb-run gives Chrome a fake virtual display, so it never actually opens a window on your screen, but the browser is still “headed” as far as the page/site can tell — fingerprint stays normal. This is exactly the pattern from their CI/CD docs (browser-actions/setup-chrome + xvfb-run).

If you want to try real --headless anyway:

google-chrome --headless=new \
  --remote-debugging-port=9222 \
  --user-data-dir="$HOME/chrome-debug-profile" \
  --remote-allow-origins="*" &

export OPENCLI_CDP_ENDPOINT="http://127.0.0.1:9222"
opencli doctor

CDP works identically over headless, so opencli doctor/your commands should connect fine — just expect some site adapters (especially login-gated ones like Bilibili/Zhihu/Reddit) to be more prone to bot checks or session weirdness.

One thing worth double-checking before you go further: their CDP/remote docs are written around the Browser Bridge extension + daemon flow, not the extension itself, when you go this route — so make sure you’re not also trying to run the Chrome extension at the same time as a CDP-only headless instance, since the daemon picks one connection method.

If you tell me your setup (local machine vs. server, which OS, are you doing this for CI) I can give you the exact one-liner for your case.

En Arch el binario se llama simplemente chromium (no google-chrome), y necesitás el paquete xorg-server-xvfb para lo de la pantalla virtual.

Instalar xvfb (si no lo tenés):

sudo pacman -S xorg-server-xvfb

Lanzar Chromium “headed” dentro de un display virtual (recomendado, evita el fingerprint de headless):

xvfb-run --auto-servernum chromium \
  --remote-debugging-port=9222 \
  --user-data-dir="$HOME/chrome-debug-profile" \
  --remote-allow-origins="*" &

export OPENCLI_CDP_ENDPOINT="http://127.0.0.1:9222"
opencli doctor

Si preferís probar con headless real igual:

chromium --headless=new \
  --remote-debugging-port=9222 \
  --user-data-dir="$HOME/chrome-debug-profile" \
  --remote-allow-origins="*" &

export OPENCLI_CDP_ENDPOINT="http://127.0.0.1:9222"
opencli doctor

Un par de cosas específicas de Arch a tener en cuenta:

• El paquete chromium de Arch a veces necesita la flag --no-sandbox si lo corrés como root o dentro de ciertos contenedores/sandboxes, aunque en un entorno normal de usuario no debería hacer falta.
• Si usás Wayland (es lo default en muchas instalaciones recientes de Arch), Chromium puede intentar usar el backend Wayland nativo en vez de X11, lo cual puede interferir con xvfb. Si xvfb-run no funciona como esperás, forzá X11 agregando --ozone-platform=x11 al comando de chromium.
• Si tenés systemd, te conviene correr esto como un servicio (systemd --user) en vez de un & suelto, para que sobreviva si cerrás la terminal — avisame si querés el .service para eso.

Después de correr cualquiera de los dos, opencli doctor te va a confirmar si la conexión CDP funcionó. Contame qué te tira esa salida si algo no anda.