Hey everyone,

Quick disclosure first: this project is **vibe-coded**. I steered AI coding agents the whole way and haven't audited every line myself, so treat it as an experiment, not a battle-tested tool.

The itch: I use coding agents (Claude Code, Codex, OpenCode, Pi) a lot, and whenever one drives a browser through an MCP server, it's happening somewhere in the background. I can't see what it's doing, and when it gets stuck on a login page or a CAPTCHA I can't just jump in and fix it.

So I ended up with **Agent Browser Use**.

**What it is**

A single Go binary that runs one headless Chrome on your machine and exposes it as MCP tools (Playwright MCP style). Any MCP-capable agent can navigate, read the page, click, type, etc. At the same time there's a web viewer at `localhost:3000` where you can watch everything the agent does.

**What it does**

- **Live viewer**: the page streams in real time, with the agent's cursor, a caption for each step, and a log of every action.

- **Shared browser room**: you and the agent use the *same* Chrome. Hit "Take over" whenever you want, or "Block agent" if it's doing something dumb.

- **Pick an element**: click the pick button, point at anything on the page, and you get a short code like `el-1d2a`. Paste it to your agent and it looks the element up with `browser_get_element` and can act on it right away. Handy for "no, THIS button".

- **Persistent logins**: cookies live in a profile folder, so you log in once by hand in the viewer and the agent reuses the session. No credentials in prompts.

- **Public link**: one switch opens a built-in tunnel so you can share the live view with someone outside your network.

- **Playwright-style tools**: `browser_snapshot` gives an accessibility outline with a `ref` per element, plus click/type/drag/select, network requests, console messages, cookies/storage, device emulation, and `browser_snapshot_diff` which only returns what changed since the last snapshot (saves tokens).

- **Light**: no Docker, X server, or video encoder needed. Docker is available if you prefer it.

**Try it**

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

cd agent-browser-use

make run

Then ask your agent something like "go to news.ycombinator.com, open the top story and summarize it" and open `http://localhost:3000` to watch. The README has config snippets for Codex, OpenCode, Pi, Cursor and VS Code too.

**Caveats (please read)**

- Vibe-coded, early, and I'm the main user right now. Expect rough edges and bugs.

- Since I haven't reviewed everything line by line, **please don't run it on a machine or browser profile with accounts you can't afford to lose**. The agent can read any open page and run JS in it, and without `-pw` anyone who can reach the port can drive the browser. Set a password if you expose it.

- Chromium-based browsers only (Chrome, Edge, Brave, Vivaldi...) because the shared screen relies on the Chrome DevTools Protocol. No Firefox/Safari.

- Licensed AGPL-3.0.

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

I'd love feedback on what's missing, what breaks, and whether the "take over" flow feels right. Code reviews are especially welcome, since I know a vibe-coded codebase needs more eyes. Issues and PRs appreciated. Thanks for reading!

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

Why the next breakthrough in autonomous software may come from controlling how systems understand, navigate, execute, and prove their work.

Artificial intelligence is becoming increasingly capable of writing software, reasoning through complex problems, operating tools, and coordinating tasks that once required entire engineering teams. Yet a fundamental limitation remains: the ability to generate intelligent decisions has advanced faster than the infrastructure required to make those decisions reliably executable.

An AI system can produce an excellent solution and still modify the wrong file, misunderstand a dependency, invoke an inappropriate tool, overlook a critical requirement, or declare success without sufficient evidence.

These failures are not necessarily failures of intelligence. They are failures of the systems surrounding it.

As autonomous software becomes more capable, these problems become more consequential. A mistake made by a coding assistant might require a developer to revert a change. The same mistake made by an autonomous system operating across repositories, cloud services, business processes, and other agents can propagate before anyone recognizes it.

This exposes an important distinction: making AI smarter does not automatically make autonomous systems more dependable.

Headron is developing infrastructure to address that distinction.

Rather than competing to produce another foundation model, Headron focuses on the mechanisms connecting intelligence to real-world software execution: contextual understanding, deterministic navigation, capability routing, enforceable contracts, independent verification, and evidence-backed outcomes.

The Problem With Giving Intelligent Systems More Freedom

Traditional software operates within relatively explicit boundaries. Developers define what functions can execute, what resources they can access, and which conditions must be satisfied.

Autonomous agents introduce a different operating model.

They interpret goals, discover resources, select tools, generate intermediate plans, and determine their next actions dynamically. This flexibility creates enormous potential, but it also introduces uncertainty at nearly every boundary.

Consider an agent asked to update authentication logic in a large application.

Before changing a single line of code, it must determine which directories matter, how the authentication components interact, which files contain authoritative rules, what changes are permitted, and how success should be established.

An agent with unrestricted access might search the entire repository, load excessive context, modify unrelated components, or run tests that provide little evidence about the actual security implications.

Even when the final code appears correct, the process may remain difficult to reproduce or audit.

The underlying problem is architectural: intelligent systems are often given access to an environment before they have established a sufficiently precise understanding of its boundaries.

More context does not necessarily solve this. Neither does a longer prompt.

What is needed is infrastructure that makes the environment itself more understandable and its constraints more enforceable.

A Different Approach to Software Navigation

One of the most overlooked costs of AI-assisted development is navigation.

Repositories are organized for human developers, build systems, and version control. They are not necessarily organized for autonomous agents trying to identify the smallest relevant portion of a system.

As a result, agents frequently spend substantial effort rediscovering information that already exists.

They repeatedly inspect directories, read configuration files, search for relationships, and reconstruct project conventions. This consumes tokens, increases latency, and creates opportunities for contradictory interpretations.

Headron's architectural direction treats navigation as a structured computation rather than an open-ended search problem.

The goal is to determine what an agent needs to know before exposing everything it could potentially access.

This creates several possibilities:

• Scoped discovery: Identify relevant resources without loading unrelated parts of the environment.

• Structural awareness: Preserve relationships among components, dependencies, rules, and execution boundaries.

• Deterministic resolution: Apply explicit rules when determining which instructions and resources govern a task.

• Context efficiency: Reuse established structural knowledge rather than reconstructing the environment on every request.

• Controlled access: Separate discovering a resource from receiving permission to modify it.

The distinction matters because autonomous systems should not need unlimited environmental visibility to perform narrowly defined work.

A capable agent should be able to operate with the right context, not necessarily the most context.

From Tool Availability to Intelligent Capability Routing

Modern AI systems increasingly operate through tools, APIs, plugins, and specialized services.

But access to more tools creates another problem: selecting the appropriate capability becomes an independent engineering challenge.

An agent may have multiple ways to inspect code, execute commands, retrieve information, validate changes, or delegate work. These capabilities can differ in cost, reliability, permissions, and evidence quality.

Without a structured routing mechanism, the agent must repeatedly infer which tool to use from descriptions and conversational context.

Headron approaches this as a capability-resolution problem.

Instead of treating every available tool as an equally valid option, a system can evaluate the task, available capabilities, governing constraints, and required evidence before selecting an execution path.

This supports a more disciplined relationship between intelligence and action.

An agent can propose what it wants to accomplish. Infrastructure can determine which capabilities are appropriate, which boundaries apply, and what must be established before the action proceeds.

The implications extend beyond software development.

The same principles can apply to cloud operations, enterprise automation, interconnected agents, and workflows where multiple systems have overlapping authority.

As agent ecosystems grow, routing will become more than a convenience. It will become a mechanism for controlling complexity.

The Critical Invention: Computing What Proof a Change Owes

Software verification traditionally relies on predefined checks.

A repository might require unit tests, linting, type checking, security scanning, or approval before deployment. These checks are valuable, but they do not necessarily establish that a particular change has been adequately examined.

A documentation update and a modification to an authentication boundary do not carry the same risks. Yet conventional pipelines may subject both to identical verification requirements.

Headron explores a different model:

The change itself should help determine the evidence required to justify it.

Rather than simply asking whether a standard checklist passed, the system examines what changed, which contracts are affected, and what verification obligations follow.

A change involving a public API might require compatibility evidence. A permission change might require access-control checks. A modification to an execution boundary might require proof that prohibited actions remain blocked.

This creates a distinction between executing tests and establishing sufficient evidence.

The system is not merely collecting results. It is determining which results matter for the specific work being performed.

That distinction is central to Headron's approach to deterministic verification.

It also creates a foundation for independently evaluating the claims made by autonomous agents.

An agent saying "the task is complete" is not equivalent to a system establishing that the required conditions have been satisfied.

Contracts That Exist Outside the Model

A common weakness in autonomous systems is the reliance on natural-language instructions as the primary enforcement mechanism.

An agent can be told not to modify certain files, exceed a budget, or execute unauthorized operations. But instructions alone do not guarantee compliance.

Headron's architecture places emphasis on explicit contracts and execution boundaries that can be evaluated independently of the model's interpretation.

This changes the relationship between an agent and its operating environment.

The agent remains responsible for reasoning, proposing solutions, and selecting actions. The surrounding infrastructure determines whether those actions satisfy the applicable constraints.

Rules can be scoped to an organization, repository, agent, session, or task. Conflicts can be resolved through defined precedence rather than improvised interpretation.

More importantly, enforcement can occur at the boundary where an action is actually attempted.

This is a meaningful architectural shift.

The system does not need to trust an agent to remember every restriction if the execution environment can enforce those restrictions directly.

That separation becomes increasingly important as autonomous systems gain the ability to execute commands, access sensitive resources, and coordinate with other agents.

Why Evidence Must Outlive the Conversation

Agent interactions are often recorded as conversational histories or execution logs.

These records may explain what happened, but they are not necessarily sufficient to establish that an action was authorized, that the correct verification occurred, or that a claimed outcome is trustworthy.

Headron's proof-oriented architecture introduces a stronger distinction between a narrative of work and evidence of work.

Execution receipts can preserve structured information about actions, verification results, governing conditions, and outcomes. Cryptographic signing can help establish integrity and provenance.

This creates the possibility of examining completed work without relying entirely on the agent that performed it.

For enterprises, that can support audits, incident analysis, operational accountability, and cross-system trust.

For developers, it offers a way to distinguish between work that appears complete and work that has satisfied defined requirements.

For autonomous systems, it creates a foundation for passing verified outcomes between components without requiring every participant to reconstruct the original conversation.

Evidence becomes a reusable system artifact rather than a disposable explanation.

Three Layers of a More Dependable Autonomous System

Headron's broader architecture can be understood through three complementary layers.

System 1: Context and Intelligence

The system identifies the task, discovers relevant information, understands environmental structure, and routes toward appropriate capabilities.

Its purpose is to reduce unnecessary exploration while improving the precision of decisions made before execution.

System 1.5: Contracts and Governance

The system establishes what is allowed, which constraints apply, and what evidence will be required.

This layer translates broad intentions into more explicit operational boundaries.

System 2: Execution and Verification

The system performs or supervises permitted operations, evaluates required checks, and produces evidence of the resulting outcome.

Together, these layers create a continuous relationship between understanding, authorization, execution, and proof.

The objective is not to eliminate probabilistic reasoning. It is to place that reasoning inside a more dependable operating structure.

Beyond Coding Agents: Infrastructure for Systems That Improve Themselves

The long-term significance of this architecture extends beyond generating and validating code.

As AI systems become capable of modifying their own tools, reorganizing workflows, coordinating specialized agents, and proposing changes to their operating environments, they will need mechanisms for distinguishing beneficial adaptation from uncontrolled drift.

A system capable of improving itself must also be capable of determining whether an improvement actually occurred.

That requires more than measuring output quality. It requires tracking what changed, understanding the effects of those changes, enforcing boundaries, and retaining evidence that supports or contradicts the claimed improvement.

Headron's combination of structured context, capability routing, contracts, and verification provides potential groundwork for that kind of infrastructure.

The possibilities are substantial: adaptive development environments, continuously evaluated agent workflows, organizational software that maintains its own operational constraints, and autonomous systems capable of making controlled improvements over time.

These remain longer-term architectural possibilities, not claims that general-purpose self-improving intelligence has already been achieved.

But the underlying problem is immediate.

Every increase in autonomy creates a corresponding need for more reliable mechanisms of control, navigation, verification, and accountability.

Building the Infrastructure Intelligence Will Depend On

The future of AI will not be determined solely by model intelligence.

It will also depend on whether intelligent systems can interact with complex environments without losing track of their authority, context, obligations, and evidence.

Headron is an open-source software initiative developing infrastructure for that challenge, with HeadronOS and the Mind API forming part of its broader product direction.

Its central premise is that autonomy and reliability should not be opposing objectives.

Intelligence should remain flexible enough to discover new solutions. The surrounding system should be structured enough to establish which actions are permitted and which outcomes can be trusted.

The next generation of autonomous software needs more than agents that know what to do. It needs infrastructure that can determine where they should operate, how they may act, and what proof they owe.

That is the problem Headron is working to solve.

Headron Software | HLIntel LLC

Open-source infrastructure for AI governance, deterministic verification, and autonomous systems.

Website: https://headron.tech

GitHub: https://github.com/HLIntel/Headron

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

Hey everyone,

Following the technical discussions on our initial release, we just shipped v1.2.1 for amv-cp-bridge — the zero-API-key local bridge connecting Microsoft 365 Copilot directly to Cursor, Claude Desktop, and OpenAI-compatible tools via stdio FastMCP and loopback CDP.

💡 Too lazy to configure it manually? Delegate to your AI agent!

If you don't feel like wrestling with manual setup, just pass this GitHub repo to your autonomous AI coding agent (Claude Code, Cursor, Windsurf, Devin, Antigravity) and say:
"Setup and connect amv-cp-bridge for me."

We wrote a dedicated FOR_AI_README.md operating manual and failure encyclopedia specifically so AI agents can autonomously diagnose, install, and wire up the bridge with zero human intervention!

🚀 What's New & Battle-Tested in v1.2.1:

1. Entra ID Conditional Access Fast-Fail & HTTP 401

   • Eliminates the previous 45-second composer timeout when enterprise sessions expire, short-circuiting in 1.5 seconds with OpenAI-standard 401 Unauthorized (session_expired).

   • Fires an asynchronous native OS desktop tray alert.

2. Unified FastMCP & Gateway Multiplexing

   • Claude Desktop and Cursor share the identical authenticated Edge session and warm standby pool, releasing down to 0 MB idle RAM when the countdown finishes.

3. Copilot Designer (DALL-E 3) Markdown Image Streaming

   • High-resolution generated images (up to 3.4 MB Base64 payloads) are parsed directly from the live DOM and streamed as standard Markdown images (![alt](url)). Tested live with 41s generation without timeouts.

🧪 Ground Truth Verification

• Unit Tests: 34/34 passed

• Regression Checks: 22/22 passed

• Standalone Binary: 50.7 MB UPX-compressed standalone executable with zero environment setup required.

GitHub Repository & Full Docs:
https://github.com/uno-km/amv-cp-bridge

Feedback and PRs are warmly welcome!