What Is browser-use? And How to save 50% of tokens while using it.

If you are building AI agents that can actually do things on websites, browser-use is one of the most important open-source projects to understand right now.

And if you want to use it without being locked into a single model path, Lynkr is a clean way to put a gateway between your browser agent and whichever LLMs you want behind it.

I built Lynkr, so take the integration section with that disclosure in mind. Still, browser-use is genuinely one of the most interesting repos in the agent stack right now, and it is worth understanding on its own.

What is browser-use?

browser-use is an open-source framework for giving LLM agents access to a real browser.

In plain English:

• it opens a browser
• lets an agent inspect the current page state
• click buttons
• type into inputs
• extract information
• navigate across sites
• and complete real browser workflows from a prompt

The project’s GitHub description is:

Make websites accessible for AI agents. Automate tasks online with ease.

At the time of writing, the repo has 97.5k stars, which tells you this is not some niche experiment anymore.

Why browser-use blew up

A lot of “AI agents” stop at text generation.

browser-use matters because it pushes into the next step: agents that can interact with software the same way a user does.

That means you can build workflows like:

• filling out forms
• pulling data out of dashboards
• logging into tools and clicking through UI flows
• checking prices, calendars, tickets, or inventory
• testing internal tools
• handling repetitive browser tasks that don’t have a clean API

That’s the real appeal: many businesses do not need another chatbot. They need automation for systems that only really exist behind a browser.

What browser-use gives you

From the repo and quickstart, the project gives you a few things that make it practical:

• an open-source Python agent framework
• a browser abstraction the agent can control
• examples for common browser tasks
• a CLI for persistent browser automation
• optional cloud/browser infrastructure from the Browser Use team
• support for multiple LLM backends in its quickstart examples

Their human quickstart shows the core pattern:

from browser_use import Agent, Browser, ChatBrowserUse
import asyncio

async def main():
    browser = Browser()

    agent = Agent(
        task="Find the number of stars of the browser-use repo",
        llm=ChatBrowserUse(),
        browser=browser,
    )
    await agent.run()

if __name__ == "__main__":
    asyncio.run(main())

The important concept is simple:

• Browser() handles the browser session
• Agent(...) handles the goal and step-by-step decisions
• llm=... controls which model layer is making those decisions

That last part is exactly where Lynkr becomes useful.

Where Lynkr fits

If browser-use is the browser-side execution layer, Lynkr can sit under it as the LLM gateway.

That gives you one stable endpoint between your browser agent and the actual providers behind it.

Instead of hard-wiring one provider path everywhere, you can put this in the middle:

browser-use agent
      ↓
    Lynkr
      ↓
Ollama / OpenRouter / Bedrock / OpenAI / Azure / Databricks / others

That matters because browser agents are usually:

• multi-step
• tool-heavy
• iterative
• expensive when they retry or explore a page

And those are exactly the workloads where routing and token optimization matter.

Why use Lynkr with browser-use?

The basic answer is: browser agents create lots of LLM calls, and Lynkr helps you control that cost and flexibility.
Lynkr has tiered routing which can help you save 50-60% of your token usage.

From the current Lynkr README, the relevant levers are:
---- all these values are compared to LiteLLM

• 53% fewer tokens on tool-heavy requests
• 87.6% compression on large JSON/tool outputs
• 171ms semantic cache hits
• automatic tier routing
• zero code changes at the client boundary once the endpoint is swapped

Even though those numbers come from coding-tool workloads, the shape maps well to browser agents too:

• page-state dumps can get large
• repeated task loops can benefit from cache hits
• simple browser steps do not always need your most expensive model
• hard navigation/reasoning steps can be escalated to a stronger model

So the win is not just “use another model.”

It is:

1. one gateway endpoint
2. provider flexibility
3. routing cheap vs expensive work differently
4. lower spend on repetitive agent loops

When this combination makes sense

Using browser-use with Lynkr makes the most sense if you are doing any of these:

• running browser agents repeatedly in production
• experimenting with multiple providers for reliability or cost
• mixing local and cloud models
• trying to avoid hard vendor lock-in
• building internal automations where cost per workflow matters
• wanting one OpenAI-compatible gateway for several agent systems, not just browser-use

If you are just trying one script once, direct provider setup is fine.

If you are building a real browser-agent workflow that you will run over and over, putting a gateway in front of it starts to make more sense.

How to use browser-use

The project’s quickstart uses uv and Python 3.11+.

1. Install browser-use

uv init
uv add browser-use
uv sync

If Chromium is not already installed, their repo also mentions:

uvx browser-use install

2. Create a simple browser-use script

Start with a minimal example.

from browser_use import Agent, Browser, ChatBrowserUse
import asyncio

async def main():
    browser = Browser()

    agent = Agent(
        task="Open GitHub and find the number of stars on the browser-use repository",
        llm=ChatBrowserUse(),
        browser=browser,
    )

    result = await agent.run()
    print(result)

if __name__ == "__main__":
    asyncio.run(main())

This verifies that:

• Python is set up correctly
• the browser launches
• the agent can take a goal and act on it

That gets you the baseline.

3. Install Lynkr

Now add the gateway layer.

npm install -g lynkr

4. Start Lynkr with a provider behind it

For a simple cloud setup, the current Lynkr README shows OpenRouter like this:

# .env
MODEL_PROVIDER=openrouter
OPENROUTER_API_KEY=your-key
FALLBACK_ENABLED=false
PORT=8081
PROMPT_CACHE_ENABLED=true
SEMANTIC_CACHE_ENABLED=true

Then start Lynkr:

lynkr start

For a free/local path, Lynkr also supports local providers like:

• Ollama
• llama.cpp
• LM Studio

That means you can test browser agents locally first, then move harder tasks to cloud models later.

5. Point browser-use at Lynkr

This is the part that depends on which LLM wrapper you use inside browser-use.

The repo’s README shows examples like:

• ChatBrowserUse()
• ChatGoogle(...)
• ChatAnthropic(...)

The general pattern is:

• if your selected browser-use model wrapper supports a custom base URL / OpenAI-compatible endpoint, point it at Lynkr
• Lynkr then forwards the request to the actual backend provider you configured

The integration idea is the same as any other app using a gateway:

browser-use LLM client → Lynkr base URL → chosen providers

Because Lynkr exposes an OpenAI-compatible surface and already supports routing clients like Claude Code, Cursor, Codex, Cline, and Continue, the practical fit is strongest when your browser-use stack can talk through an OpenAI-style endpoint.

A practical architecture to think about

If you are building a serious browser automation system, this is the architecture I would use:

Your app / worker
      ↓
 browser-use
      ↓
   Lynkr
      ↓
Simple tasks → cheap/local model
Hard tasks   → stronger cloud model
Retries      → cached/routed through same gateway

That gives you a few operational wins:

• one place to change providers
• one place to add caching/routing
• one place to enforce model policy
• one place to swap local/cloud behavior

What kinds of browser-use tasks benefit most?

The biggest benefit is not “every browser step becomes cheap.”

The biggest benefit is that not every step deserves the same model.

Examples:

Good candidates for cheaper tiers

• page classification
• checking whether an element exists
• extracting a small piece of text
• moving through obvious deterministic UI steps
• repeated workflows you run every day

Good candidates for stronger models

• ambiguous navigation
• dense multi-step forms
• recovery after unexpected UI changes
• reasoning-heavy extraction tasks
• flows with messy instructions from users

This is exactly why a gateway helps. Browser agents are not one homogeneous workload.

A realistic example

Say you are automating a support workflow:

• log into admin panel
• search user account
• open billing page
• check subscription state
• update a field
• confirm success
• export some result back to your app

Without a gateway, every step may go to the same expensive provider.

With Lynkr in the middle, you can move toward:

• cheap model for straightforward navigation
• stronger model when the page layout becomes ambiguous
• cache/reuse repeated context patterns
• preserve one integration point in your app

That’s a much better shape as soon as workflows become frequent.

What Lynkr does not replace here

Important distinction:

• browser-use is still the browser automation layer
• Lynkr is still the LLM gateway layer

Lynkr does not replace the actual browser agent runtime.

It sits underneath it and makes the model side more flexible.

That is why this pairing is interesting: they are complementary, not redundant.

Tradeoffs and honesty section

Since I built Lynkr, it is worth stating the tradeoffs plainly.

Using a gateway adds another layer to operate.

That is worth it when you care about:

• provider control
• cost routing
• caching
• consistent integration across multiple tools

It is not automatically worth it for:

• one-off experiments
• tiny local scripts you run once a week
• very early prototypes where simplicity matters more than control

So the right mental model is not “everyone needs a gateway.”

It is “browser agents become more infrastructure-like very quickly, and gateway control starts paying off once that happens.”

Why browser-use is worth learning even if you do not use Lynkr

Even without the Lynkr angle, browser-use matters because it represents a bigger shift:

we are moving from LLMs that answer questions to LLM systems that can operate software.

That changes the shape of automation.

The future stack is not just:

• prompt in
• text out

It is increasingly:

• goal in
• browser actions
• tool calls
• retries
• extraction
• completion

And browser-use is one of the clearest open-source projects showing that shift.

Final take

If you want to understand modern browser agents, start with browser-use.

If you want to run those agents with more control over cost, routing, and provider choice, put Lynkr underneath them as the LLM gateway.

That combination gives you:

• browser automation on top
• provider flexibility underneath
• one stable endpoint for your model layer
• a cleaner path to scaling beyond a single hard-wired provider

If you want to try it, start here:

• browser-use: https://github.com/browser-use/browser-use
• Lynkr: https://github.com/Fast-Editor/Lynkr

If you’re already using browser-use, I’d be curious about one thing:

would you rather optimize for the strongest possible model on every step, or route browser-agent work by difficulty and cost?