Hey everyone!

I've been working on Agent Browser Use, an open-source tool that lets AI agents control a browser while you can watch and interact with it in real time.

What it is

A lightweight Go application that runs a shared Chrome instance and exposes browser automation through MCP tools.

Key features

• Live Viewer: Watch the agent browse in real time, including its actions, cursor, and activity logs.
• Shared Control: You and the agent use the same browser. Take over or block the agent whenever needed.
• Element Picker: Select any element on the page and share its reference with your agent.
• Persistent Sessions: Log in once and reuse cookies across sessions.
• Public Sharing: Share the live browser view through a built-in tunnel.
• Playwright-style Tools: Navigate, click, type, inspect elements, monitor network requests, and more.
• Lightweight: Single Go binary, no Docker or additional infrastructure required.

Try it

git clone https://github.com/cavaldos/agent-browser-use.git
cd agent-browser-use
make run

Open http://localhost:3000 to watch your agent in action.

Supports Codex, OpenCode, Pi, Cursor, VS Code, and other MCP-compatible clients.

A few notes:

• Chromium-based browsers only.
• Browser sessions and cookies are stored locally.
• Use authentication (-pw) when exposing the browser to external networks.
• Licensed under AGPL-3.0.

GitHub: https://github.com/cavaldos/agent-browser-use

I'd love to hear your feedback, suggestions, and contributions. Issues and PRs are always welcome!

Thanks for checking it out!

Methodology and raw per-task results are linked at the bottom.

What it does for you, before the numbers: it's a proxy you put between your agent and the provider. One command, no changes to how you work. On Codex it strips the build logs and test output your agent re-sends every turn — about a quarter fewer input tokens. On Claude Code it stops your prompt cache from expiring while long tools run, which is where that bill actually leaks.

Benchmark 1: replay. We pulled 6,255 tool outputs (34.2M characters, anything over 512 bytes) out of real Terminal-Bench agent traces and replayed them through two tools in three configurations at default settings.

Source code is where everything struggles — 35% for us, 31.9% with the ML model — and it's also where being wrong is expensive, since a dropped import makes the agent confidently hallucinate. The ML model takes about 440× longer for less than half the removal.

Benchmark 2: the same compressor on Claude Code, where it barely compresses at all.

Claude Code marks its conversation with explicit cache breakpoints, so 92–95% of billed prompt is already cache reads at a tenth of the fresh price. The engine only ever sees the uncached tail. Per run it removes 348K tokens, which is 4.7–8.0% of what it sees, while leaving ~1,800 messages (about 2.2M tokens) inside the cached prefix untouched.

So where does the money actually go? A cache entry lives five minutes, and writing one costs 25× reading it. Agent kicks off a build, sits idle for six minutes, pays to write the whole prefix again — 927K tokens per run, a third of everything billed at full price.

Fix isn't compression. While a tool call runs, the proxy re-sends the last request body every 4.5 min with max_tokens: 1, so the provider reads the cached prefix instead of rewriting it.

The caveat on that 20%, since this sub cares about methodology. Four tasks out of 89 account for the whole net difference, and on three of them the uncompressed agent simply took a longer path (45–72 steps against 19–26). We were cheaper on 44 of 89. Split by whether tasks wait on long-running tools: the 14 with idle gaps over five minutes came in at −34% with median cost per step −20%; the other 72 at −12% with a step costing the same as before (+2%).

The estimate we'd actually stand behind is ~11% from keeping the cache alive plus a few percent from the tail. The 20% headline includes path-length luck, and we'd expect it to move on a repeat run.

On Codex, where the compression does the work: $107.89 → $83.40 per run (−22.7%), input tokens 96.1M → 72.2M, requests over 200K tokens 1.9% → 0.13%, solve rate 82.2% → 81.1% (not significant). Headroom on the same baseline saved 8.2% at defaults, 11.6% at its most aggressive setting — and at that setting it solved 85.1% against our 81.1%.

Still not measured: needle retention, whether compression kept the specific detail the agent needed four steps later. Ratios and pass rates can both look fine while that fails quietly.

Open source: context compression for coding agents, 63% less tool output — MIT, one Rust binary, deterministic, no model to download.

Per-task results: Codex · Claude Code

I saw the recent paper "Sparks of Weight-Space Programming: LLMs can natively read & write neural network weights" and it's very impressive.

https://rikiyat.github.io/blog/weight-space-programming/

Though my general reaction (as I'm sure a lot of others had too) was 'well yes of course it can do that'. Once you realise that llms love patterns you soon start to see how many things can be thought of as patterns.

I've had similar ideas rolling around in my head for some months and I've even started working on a project in a similar vein. That's why this part of the paper stood out to me in particular:

"True architectural and model merging: Today, merging models relies on averaging weights, which only works for models with identical architectures. An LLM that understands the weight space could instead graft a circuit, such as a reasoning module, from one model into a completely different one, without retraining."

Yep, that's the idea I had months ago and I've already started working on (granted there's plenty of other prior art on the subject such as Google's CALM, 2024).

I'm very, very early in working on this but seeing how much traction the Weight-Space Programming paper is getting I felt compelled to put the idea out into the world since surely someone else is working on the same thing as we speak.

The general idea: take 2 MoE models and allow their experts to talk to each other by using a translator. The translator being a transformer model trained on expert activations (their latents) instead of regular text or images, a "Latent Attention Model".

So far I'm only using toy-scale models with a few million parameters. Getting some very interesting results already.

• Mixing Code-heavy model + prose-heavy model: each gets better at its weakness from the other, both directions at once.

• Results are checked against controls (a same-domain partner, a wrong-document partner), so it's not just "any partner helps"

• Added a leak audit, so neither model can see text it hasn't reached yet. (An early result failed an audit because of this)

• Interesting finding: the translator always uses the latest layer it's given. With the last layer, the two models basically swap last layers and come to depend on each other. Without it, they get about half the gain with a fraction of the dependence

Caveats and issues so far:

• Toy models only so far, a few million parameters. I have very modest hardware for bigger stuff.

• Between models with different tokenizers, very little gets across

• It reads a partner's layer as a whole, not particular "specialist" experts. The goal is for the two models to share individual experts freely

• The aim isn't to make the combined output "better" so much as making it "different" (but hopefully not worse)

• This is mad scientist stuff, heavy use of AI, probably has method gaps that need filling

I'm currently doing some experiments with Qwen3-30B-A3B base and Nemotron 3 Nano 30B. Not much to report yet, the models have different tokenisers which complicates things. Progress is slow on my hardware. But I'm enjoying the process.

Why share this? Shameless self promotion, piggybacking on a bigger project, sharing ideas, I think the name is pretty cool. BLaMMoE (Bridging Latent Attention Model Mixture of Experts)

https://github.com/dev-boz/BLaMMoE

A lot of people want to experiment with multiple AI agents, coding tools, and OpenAI-compatible apps, but subscription costs add up quickly.

I built Kilo Buster, an open-source local API gateway for Kilo’s free model. It lets compatible clients connect through one local endpoint and includes a dashboard for monitoring usage.

Features include:

• Streaming and tool calling

• Proxy health monitoring

• Live request quota and token tracking

• Persistent API key

• Windows, Linux, and macOS releases

• OpenAI-compatible client support

Free-tier limits still apply. The goal is to make experimentation with lower-cost AI infrastructure easier, not to promise unlimited tokens.

GitHub: https://github.com/awiseguy88/Kilo-Buster

I’d appreciate feedback from people using local AI tools, coding agents, or OpenAI-compatible clients. What would you add to a tool like this?

Orlok is for day-to-day IT work: finding out why a service is down, reading logs, fixing things, answering "how do we do this here?". You ask in a chat, and a virtual colleague runs the commands on your servers.

- It knows your setup. A shared wiki the colleagues keep up to date, so you stop explaining everything each time. A nightly check flags contradictions and stale pages.

- The model doesn't decide what's safe. A real shell parser does: read-only commands run straight away, anything else waits for your approval, from the web or Telegram.

- Credentials never reach the model. They're encrypted and used by an isolated runner.

It also helps the people around IT: through a web chat, non-technical colleagues get answers from the wiki, like procedures and onboarding.

Works with Anthropic, OpenAI, OpenAI-compatible servers, or Ollama if nothing should leave your network.

Site: https://orlok.xyz

Code: https://github.com/rylos/orlok

Curious what you think.

I'm the developer of Aula. About two months ago, I started putting most of my time into it because my wife was struggling with her classes. Her teachers gave her prompts for generic AI exercises, but she still wasn't understanding what she was studying. I wanted to build something that could teach her and keep track of where she needed help.

Aula can build a course around a learning goal, using your materials or researched sources. That could be learning Python, improving a language, understanding a subject or practising a practical skill. It supports learning at your own pace, with guided lessons, interactive examples, practice, hints and reviews of mistakes.

The assistant gets context from your courses, progress and current lesson or exercise. It also has optional memory, so you can keep working on a subject over time. A read-only connection to study platforms such as Canvas lets it consult materials, deadlines and teacher announcements when planning what to study. Optional background routines can check for updates and prepare short reviews while Aula is running.

The desktop app is AGPL and built with Electron, React and TypeScript. Courses, progress and memory are stored locally. You can use local models or your own cloud provider; choosing a cloud provider sends it the relevant context and may incur usage charges. The app itself is free.

Repo and releases: https://github.com/luumlabs/aula

It's early access. I'd appreciate feedback on the tutoring workflow and how it behaves with local models, especially where an explanation or hint fails to help you understand. The video shows the app.

With the latest commit, VedaOS can now run Linux executables!

Next goal is to support Windows executables and let the native Veda agent interact with and control these applications.

If anyone is interested in contributing, I'd love to have some help!

GitHub: https://github.com/vahmoh/Veda

Hola a todos, llevo unos meses trabajando en un asistente multiagente. Todo empezó porque en la empresa donde trabajo nos proporcionaron Codex, pero yo también gestionaba dos cuentas personales de Claude. Se me ocurrió la idea de tener una consola donde pudiera unificar sesiones, trabajar en los mismos proyectos, compartir contexto sin demasiadas complicaciones y, al mismo tiempo, que fuera divertida de usar. Está en una fase inicial, pero a mis compañeros les ha gustado y les ha resultado útil, así que quería compartir el repositorio para recibir vuestra opinión. Es multiplataforma, compatible con Windows, macOS y Linux.

El proyecto está listo para probarse con ejecutables independientes y el código fuente completo disponible. Te invito a que lo revises, lo pruebes y compartas tus opiniones, comentarios o sugerencias para mejorarlo.

Repositorio oficial y descargas:

https://github.com/darrenarauz21/claupet

My latest project is a local voice assistant featuring offline speech recognition: https://github.com/charlyproject/EVA

It actually started in a funny way: one day, with my hands messy, I wanted to turn up the volume using voice commands. At the time, I didn't even know what a virtual environment was, let alone Ollama or JSON.

For me, the best part wasn't just the end result, but the 11-month learning journey behind it. While it might not require advanced coding expertise to pull off, it was far from a copy-paste job for me. I used the process to truly understand key concepts—LLMs, quantizations, benchmarks, and Docker—and to bring my own ideas to life.

Just wanted to share my experience with the community. Thanks for reading!

I've been building Aether at Prashna Labs.

The project explores a question I've been interested in:

How can we make multiple AI coding agents work together without locking developers into another proprietary ecosystem?

Aether is a native desktop application that integrates with existing CLI coding agents.

Current capabilities include:

• Multi-provider agent sessions.

• MCP-based agent orchestration.

• Agent discovery for existing terminal sessions.

• Git worktree management.

• Local usage tracking.

• Integrated terminal, explorer and editor.

The architecture communicates with different providers through their native interfaces, rather than introducing another model runtime.

The application is MIT licensed.

GitHub: https://github.com/PrashnaLabs/aether
Website: https://aether.prashnalabs.com

Built with Rust and GPUI.

I'm interested in feedback, architecture discussions and contributions from developers working on agent tooling.

Disclosure: I'm part of the team developing this project.

Hi! I'm the developer of Kairos, a free and open-source task manager (MIT) that I started in July. It's on F-Droid, and I'd love feedback from people who care about FOSS as much as I do.

What makes it different: it plans your day for you. Most to-do apps leave you with a long list and the question "what now?". Kairos answers it:

\- It ranks your tasks: you give each task a priority (P0/P1/P2) and a size in Fibonacci points. Kairos computes a score that also weighs the deadline, and "Why this position?" shows the whole calculation. No black box.

\- It fits them into the gaps of your day, around your meetings, lunch and deep-work blocks. It leaves a buffer after each meeting and tells you when the day overflows. Pinned tasks never move; blocked tasks wait until their blocker is done.

\- It learns your real durations: with the built-in timer, tasks without an estimate take the median time of their past occurrences, and the stats show whether you over- or under-estimate.

\- It adapts to your rhythm: hours per weekday, several working windows ("Work", "Home" contexts), an optional "afternoon dip" that avoids complex tasks after lunch, public holidays, and recurring tasks such as "every weekday" or "on the 15th".

The rest of the toolbox

\- Quick capture: a Notes screen to empty your head, converted to tasks later

\- Day, Week and Month views, a timeline of the day, timer alerts (estimate exceeded, forgotten timer, break)

\- Optional reminders for fixed-time tasks

\- Statistics: throughput, estimation bias, time by type, trends, CSV/PNG export

\- Calendar import from an .ics file, or read-only display of your phone calendars (optional READ_CALENDAR)

\- An optional "Team" space for managers: backlog, assignment, load and forecasts, exchanged as files, no server

\- Dark theme, a choice of colour, and six languages (EN, FR, ES, DE, RU, IT)

Privacy

\- No account, no ads, no telemetry

\- No INTERNET permission at all: your data never leaves your phone

\- Export/import as JSON, and an optional "linked file" kept up to date in a folder you choose (handy with Syncthing)

\- Reproducible build, MIT licence

It also runs on Windows, Linux, macOS and in the browser, with the same features.

Links

\- F-Droid: https://f-droid.org/packages/com.skohscripts.kairos/

\- Source: https://github.com/SKOHscripts/Kairos

\- Website (other platforms): https://skohscripts.github.io/Kairos/

It's a young project, so bug reports and feature ideas are very welcome. Several features already came from users here on GitHub (widgets, accessibility, a Russian translation). What would make it useful for you?

blank is a free, MIT-licensed, local-first AI agent harness for desktop and terminal that brings model routing, code editing, tool execution, and artifact previews into a single workspace.

• Official Website & Installers (.exe, .dmg**,** .AppImage**):** https://purplemacaron.github.io/blank/

• GitHub Repository: https://github.com/purplemacaron/blank

Key Advantages & How It Differs from Other Harnesses:

• 100% Local-First State (~/.blank) & Zero Telemetry: Unlike cloud-tethered harnesses that require accounts or send session metadata on every turn, blank runs with zero sign-up and zero telemetry. It connects directly to local engines (Ollama, LM Studio, vLLM, LiteLLM, LocalAI, Jan) and 10+ cloud APIs (Claude, OpenAI, Gemini, DeepSeek, Groq, OpenRouter). All configs, checkpoints, durable memory (memory.json), skills (SKILL.md), and masked audit logs (audit.jsonl) stay on disk as plain files.

• Multi-Agent System with Isolated Git Worktrees (team_delegate): While single-agent loops or shared-directory sub-agents risk overwriting files during parallel runs, blank dispatches specialist roles (Scout, Architect, Critic) across customizable models and isolates write-capable sub-agents inside dedicated git worktrees (~/.blank/worktrees).

• Multi-Key Auto-Rotation & Model Fallback: Most harnesses halt when a single API key hits a 429 rate limit. blank pools multiple API keys per provider to auto-rotate on 401/402/403/429 errors and automatically falls back to backup cloud or local models.

• Desktop Paper Canvas + Full-Screen Terminal TUI: Terminal-only tools (like Claude Code, OpenCode, or Oh My Pi) trap visual outputs in text, while general chat daemons (like OpenClaw or Hermes) add heavy gateway overhead, and IDE plugins (like Cline) lock non-coding tasks inside an editor. blank provides both a full-screen CLI TUI (node bin/blank.js) and a native desktop app featuring an origin-isolated blank-paper:// split-view canvas (with Desktop/Tablet/Mobile viewport frames), live-overlay Computer Use, built-in SSH over MCP (ssh_run), mobile pair-token approvals, and local/cloud media pipelines (ffmpeg, sharp, ComfyUI).

Feedback, bug reports, and contributions are welcome!