DEV Community: Anthony Max

[Boost]

Anthony Max — Wed, 29 Jul 2026 05:04:17 +0000

Comments debate speed trade-offs and AI model fit

Anthony Max

Jul 28

How Cursor + BrowserAct Handles Dynamic Pages Without Brittle Selectors

#webdev #programming #opensource #ai

7 min read

[Boost]

Anthony Max — Tue, 28 Jul 2026 10:55:22 +0000

Comments debate speed trade-offs and AI model fit

Anthony Max

Jul 28

How Cursor + BrowserAct Handles Dynamic Pages Without Brittle Selectors

#webdev #programming #opensource #ai

7 min read

[Boost]

Anthony Max — Tue, 28 Jul 2026 10:48:04 +0000

Comments debate speed trade-offs and AI model fit

Anthony Max

Jul 28

How Cursor + BrowserAct Handles Dynamic Pages Without Brittle Selectors

#webdev #programming #opensource #ai

7 min read

How Cursor + BrowserAct Handles Dynamic Pages Without Brittle Selectors

Anthony Max — Tue, 28 Jul 2026 08:17:28 +0000

TL;DR

Modern web applications change constantly. Components are re-rendered, generated attributes may differ between builds. Even when the UI looks identical, browser automation can fail because it still relies on assumptions captured before the page changed.

In this article, I used Cursor with BrowserAct CLI to test a dynamic project filter. Instead of relying on unreliable selectors, Cursor used BrowserAct to inspect the current page state and complete the task without relying on brittle selectors.

The goal wasn't to eliminate the DOM or replace Playwright. The goal was to give an AI agent a reliable inspect → act → reassess loop that works on modern, dynamic websites.

Well, let's get started! 🏎️

🖥️ The Problem: Dynamic DOM Updates Break Old Selectors

A browser test can run successfully for weeks and suddenly fail after a harmless frontend update.

The button is still visible. The feature still works. Yet the test fails because the element it expected no longer exists.

<!-- Initial page -->
<div class="toolbar">
  <button id="date-filter-btn">Filter by Date</button>
</div>

After hydration:

<div class="toolbar toolbar--v2">
  <div class="toolbar__indent"></div>
  <button id="status-filter-btn" class="btn btn--active">
    <span>⚙️</span>
    <span>Filter by Date</span>
  </button>
</div>

await page.click("#date-filter-btn")

This may fail because the selector no longer matches the current page.

👀 Why Hard-Coded Selectors Fail

Modern browser automation works best when the application is already known. Engineers can write reliable Playwright tests because they understand the page structure in advance and maintain those tests as the application evolves.

// Playwright: Assumes you know the page structure
await page.click('#filter-button');       // Works if this ID exists today
await page.waitForTimeout(500);           // Hope this is long enough
await page.fill('input[name="search"]', 'query');  // Works if DOM hasn't changed

The challenge is different for AI agents. When Cursor operates an unfamiliar website, it cannot assume which elements exist or how the interface is structured. After every meaningful interaction, the page may change, introducing new controls or replacing existing ones. Instead of relying on selectors captured earlier, the agent needs to inspect the current page state, choose the next action based on what's actually available, and reassess after the UI updates. This is the gap BrowserAct is designed to address.

⚙️ What BrowserAct Changes for Cursor

Instead of asking Cursor to remember selectors captured earlier, BrowserAct lets the agent repeatedly inspect the current browser state before deciding what to do next.

The workflow becomes:

Open the page
Read the current state
Choose an action
Execute the action
Wait until stable
Read the state again
Verify the result

It gives Cursor a compact representation of the current page state, allowing the agent to inspect the page, act on what's currently available, and reassess after every meaningful UI change. Rather than relying on assumptions from an earlier DOM snapshot, Cursor continuously works with the page as it exists now, making it much more resilient to dynamic interfaces.

💻 Real Dynamic-Page Test

Let's move from words to action. To demonstrate a working workflow, I used a searchable list of projects.

Installation

To get started, let's install browser-act.

uv tool install browser-act-cli --python 3.12

You can check the version as follows:

browser-act --version

I'm showing the following version. Yours may be newer, but the gist remains the same:

With the Cursor app open, let's test getting the current state of our app.

Generating the first test

To do this, we'll enter the following prompt into the input:

Use BrowserAct in Cursor to test the search functionality on EmbedCatalog. Read the current page state before every action. After the page changes, refresh the page state instead of reusing previous indices. Search for a project, open its details page, and verify that the correct project information is displayed.

browser-act --session embedcatalog browser open https://embedcatalog.com

browser-act --session embedcatalog state

After that the testing process will begin.

Please note that Cursor may ask you for permission to execute commands at the time of generation. This will look something like this:

After clicking the run button, after a while our first command should execute, opening the browser. If this is your first time using automation tools, the browser may ask you to confirm the action. Simply click allow, and then the website will open:

While you're running tests, you may experience automatic browser actions. Don't worry, this is BrowserAct at work. Based on our commands, it can click buttons, scroll, and do other things to get the current page state. Instead of relying on selectors captured earlier, BrowserAct generated a compact representation of the interactive elements currently available on the page.

Don't close the page while it's running, or you may encounter an error.

After my Composer 2.5 generated the response, Cursor gave us the following result:

We didn't specify any selectors. Cursor, with the help of BrowserAct, automatically found the required input, searched for the page, and scanned it. We simply generated a simple prompt, without looking at the DOM at all.

Let's expand our test

Now let's try a more complex search option. I'll list the following commands and briefly walk through the workflow:

browser-act --session embedcatalog click <CURRENT_INDEX>
browser-act --session embedcatalog wait stable
browser-act --session embedcatalog state
browser-act --session embedcatalog fill <CURRENT_INDEX> "BrowserAct"
browser-act --session embedcatalog wait stable
browser-act --session embedcatalog state
browser-act --session embedcatalog click <CURRENT_INDEX>
browser-act --session embedcatalog wait stable
browser-act --session embedcatalog get markdown

In this workflow, Cursor first opens the search interface and waits for the page to stabilize. It then refreshes the page state, enters "BrowserAct" into the search field, waits for the results to load, and reads the updated state again before selecting the correct result. Finally, it retrieves the page content in Markdown to verify that the expected project page was opened successfully.

By entering the same thing into Cursor and adding our commands, after a while we get the following result:

The test completed successfully. After every interaction, Cursor refreshed the current page state before continuing, allowing it to adapt to the updated interface.

The verification confirmed that the correct project was opened. The project name, description, last updated date, star count, tags, and project URL all matched the search result, so the workflow finished with a PASS result without relying on hard-coded selectors.

Вот более компактная версия. Она сохраняет основную мысль, но читается заметно легче.

👀 What BrowserAct Actually Solved

BrowserAct doesn't create a selector that never breaks. Instead, it gives AI agents a better way to recover from UI changes by repeatedly inspecting the current page state before deciding what to do next.

Rather than relying on an ID, CSS selector, or XPath captured earlier, the agent works with the page as it exists now. This shifts the workflow from:

Remember → Click → Hope

to:

Inspect → Act → Wait → Inspect Again

Making browser automation more resilient on dynamic websites.

🔎 Where Playwright Still Fits

This isn't a replacement for Playwright. Playwright remains an excellent choice for deterministic browser testing, especially when engineers can use stable role locators, text locators, or test IDs.

BrowserAct solves a different problem: it helps AI agents operate unfamiliar or constantly changing websites by making decisions from the current page state instead of relying on previously captured selectors. The two tools are complementary rather than competing solutions.

✅ One Check I Still Kept Explicit

Although BrowserAct handled the dynamic page updates, I still verified the final result explicitly. A successful interaction doesn't always mean the task completed correctly loading issues, authentication, or application state can still affect the outcome.

That's why the final step validated the page content rather than assuming that the previous action had succeeded. This makes the workflow more reliable regardless of the browser automation framework being used.

🖋️ Conclusion

Today, with the help of Playwright, of course, you can write application testing, but you should understand that this practice is not ideal, especially for long-term testing of the application. Rewriting the code with new id, class, etc. will take time, when it is easier to configure the Browser layer using BrowserAct and simply work with interactivity, reading it from the browser page.

💬 Feedback

You can write your thoughts about the new features in the comments, it will be interesting to read! If you'd like to learn more about the product, BrowserAct has a YouTube channel and a Discord account where you can discuss how the tool works.

🔗 Resources:

Official website: https://www.browseract.ai/Anthony
BrowserAct GitHub: https://www.browseract.com/?co-from=Anthony&redirect=https://github.com/browser-act/skills/tree/main
BrowserAct skill: https://github.com/browser-act/skills/tree/main/browser-act
Affiliate program: https://www.browseract.com/affiliate

💎 Star BrowserAct ☆

Thanks for reading this article! ❤️

How To Cut MCP Token Costs? Save Up To 92% At Scale With Code Mode 💎

Anthony Max — Tue, 21 Jul 2026 19:03:30 +0000

Today, new artificial intelligence models are released every six months, such as GPT 5.6, Fable 5, Kimi K3 and many others.

And now the most active discussion in the technical community is the concept of tokens, which allows us to use LLM in our favorite IDEs such as Cursor.

Plans are quite expensive today and every request is important to the business. In this article, I would like to tell you how you can save your money using LLM using one tool.

Well, let's get started!

🖥️ Real example

Instead of words, let's look at one small example that I prepared for you:

Request 1 (2,350 tokens): "Fetch the data from the endpoint..."
↓ (Model reasons about what to do)
Request 2 (3,100 tokens): "Here's the response. Now transform it..."
↓ (Model reasons again)
Request 3 (2,900 tokens): "Now check these projects..."
↓ (Model reasons about results)
Request 4 (2,500 tokens): "Generate a summary based on..."
↓
Total: 10,850 tokens = $0.32 per execution

Now let's imagine that our entire business is built on these requests. The site can have as many users as you like, and each such request to LLM spends our money. Considering that the plans of providers like Claude, although not so expensive, are still a serious budget expenditure. You will have to think through a business model so that it makes a profit.

👀 What do I want to suggest in this situation?

If you have a small business and want to cut down on the costs of using tokens, I suggest you try Bifrost, which recently made a super useful feature called Code Mode.

Code Mode is a transformative approach to using MCP that solves a critical problem at scale:

The Problem: When you connect 8-10 MCP servers (150+ tools), every single request includes all tool definitions in the context. The LLM spends most of its budget reading tool catalogs instead of doing actual work.

Instead of exposing 150 tools directly, Code Mode exposes just four generic tools. The LLM uses those tools to write Starlark that orchestrates everything else in a sandbox.

📊 Comparison

Since I have written many articles on the topic of Bifrost, you already know how to work with it. Let's try to apply what I wanted. First of all, here's what I want to do:

Default Mode:
Request 1: "Use the database tool to fetch data"
  → Model reasons, calls tool
  → Response: 2,450 tokens

Request 2: "Transform the result..."
  → Model reasons, calls tool
  → Response: 3,100 tokens

Total Requests: 4+ API calls
Total Tokens: 10,850+

Now working with the solution:

Code Mode:
Request 1: "Here's what I need. Write Python to do it."
  → Model writes code (single request)
  → Python executes all tools in sequence
  → Results fed back in one batch

Total Requests: 1 API call
Total Tokens: 850

If you think this is some kind of deception, then no. The reason here is very simple. Language models are good at writing code. Bad at reasoning step-by-step through tool chains.

Round	MCP Footprint	Pass Rate (Classic)	Pass Rate (Code Mode)	Input Tokens (Classic)	Input Tokens (Code Mode)	Token Reduction	Cost (Classic)	Cost (Code Mode)	Cost Savings
1	96 tools / 6 servers	64/64 (100%)	64/64 (100%)	19.9M	8.3M	-58.2%	$104.04	$46.06	-55.7%
2	251 tools / 11 servers	64/65 (98.5%)	65/65 (100%)	35.7M	5.5M	-84.5%	$180.07	$29.80	-83.4%
3	508 tools / 16 servers	65/65 (100%)	65/65 (100%)	75.1M	TBD	TBD	TBD	TBD	TBD

At around 500 tools, Code Mode reduced average input tokens per query by roughly 14x: from 1.15M tokens to 83K tokens. See the Bifrost MCP Gateway benchmark writeup, or explore the complete benchmark report.

⚙️ Application

Let's set up a virtual key for our employee in the company. To do this, let's describe the following json:

{
  "virtual_key": "vk-data",

  "token_budget": {
    "daily_limit": 1000000,
    "monthly_limit": 20000000,
    "cost_limit": "$500/day"
  },

  "token_alerts": {
    "threshold_percent": [75, 90, 100],
    "notify": ["worker@company.com"]
  },

  "allowed_mcp_tools": [
    "database",
    "api-client",
    "csv-processor"
  ],
  "blocked_mcp_tools": [
    "file-system",
    "external-web-scraper"
  ]
}

And enable Code Mode for the product:

{
  "virtual_key": "vk-product",
  "code_mode": {
    "enabled": true,
    "max_code_memory": 512,  // MB
    "allowed_imports": ["requests"],
    "blocked_imports": ["subprocess", "os"]
  },
  "mcp_token_budget": 1000000
}

Let's say our company works with Code Mode enabled, here are the results the business will have when working:

Organization Token Budget: 100,000,000 tokens/month

├─ Engineering: 40,000,000 tokens
│  ├─ Backend services: 30,000,000 (Code Mode enabled)
│  ├─ Data processing: 10,000,000 (Code Mode enabled)
│
├─ Product: 20,000,000 tokens
│  ├─ Analytics: 15,000,000 (Code Mode enabled)
│  ├─ User research: 5,000,000 (No Code Mode needed)
│
├─ Research: 40,000,000 tokens
│  ├─ Experiments: 30,000,000 (Mixed mode)
│  └─ Exploration: 10,000,000 (Text)

As a result, we fit within the company's budget. If we were to create a budget based on a simple request for LLM, then we would use more tokens for requests, and accordingly, money would also be spent on tokens.

💻 Using Code Mode with multiple MCP tools at once

Also, along with code mode, you can configure MCP Tool Groups, which will allow us to conveniently configure the context without adding several dozen tools there manually.

{
  "mcp_tool_groups": [
    {
      "name": "api-integration",
      "tools": [
        "http-get",
        "http-post",
        "http-auth",
        "rate-limiter"
      ],
      "required_for": ["backend", "integrations"]
    },
    {
      "name": "data-transformation",
      "tools": [
        "csv-parse",
        "json-transform",
        "data-validate",
        "format-output"
      ],
      "required_for": ["data-processing", "analytics"]
    }
  ]
}

Then assign Tool Groups to Virtual Keys:

{
  "virtual_key": "vk-backend",
  "allowed_tool_groups": [
    "database-operations",
    "api-integration"
  ],
  "code_mode": {
    "enabled": true,
    "max_code_memory": 512,
  }
}

This will also save time on use, improve security, and, most importantly, LLM will only see groups of tools, not the entire list, which will save time on data processing.

Without Tool Groups (50 tools visible):
├─ Initial prompt: 8,000 tokens (reading all tool definitions)
├─ Code generation: 4,000 tokens
└─ Total: 10,000 tokens

With Tool Groups (5 tools visible):
├─ Initial prompt: 1,500 tokens (reading relevant tools only)
├─ Code generation: 600 tokens
└─ Total: 4,000 tokens

✅ Conclusion

In my opinion, the code mode is not just a function, but a super method in the approach of enterprises to the agency economy. At scale, Code Mode achieves a 58% to 85% reduction in token count depending on complexity, which directly translates to 56% to 83% cost savings. You can spend this money on marketing.

🔗 Resources:

Bifrost GitHub: https://github.com/maximhq/bifrost
Bifrost Docs: https://docs.getbifrost.ai
Bifrost CLI: npx -y @maximhq/bifrost-cli

Thanks for reading this article! ❤️

I'd love to hear your thoughts on this mode in the comments!

[Boost]

Anthony Max — Sat, 18 Jul 2026 12:55:57 +0000

Anthony Max

Jul 18

TypeScript 7 is officially released! 🚨

#webdev #javascript #programming #opensource

124

3 min read

TypeScript 7 is officially released! 🚨

Anthony Max — Sat, 18 Jul 2026 12:52:21 +0000

Hello everyone! The long-awaited TypeScript 7 was finally released the other day. And the new features it brings are truly astonishing.

Several months ago I already wrote an article on this topic, but today I would like to write again about this event in programming.

Well, let's get started!

👀 What did they do?

First of all, it is worth noting that the implementation of TypeScript 7 is now done in the Go programming language. As Microsoft said, they tried to make the functions as close to the old code as possible in order to minimize bugs.

This was done to speed up the compilation of TypeScript code into machine-readable code, in short. Since VS Code runs on TypeScript, its speed is correspondingly increased. Editor operations now nearly instantaneous (e.g., finding first error in VS Code from ~17.5s to <1.3s). And not just a text editor.

// Detect dark theme var iframe = document.getElementById('tweet-2074892178745327926-246'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2074892178745327926&theme=dark" }

To prove my point, let's check the performance benchmarks:

Benchmark 1: Compile Times Between Typescript 6&7

Codebase	TypeScript 6	TypeScript 7	Speedup
vscode	125.7s	10.6s	11.9x
sentry	139.8s	15.7s	8.9x
bluesky	24.3s	2.8s	8.7x
playwright	12.8s	1.47s	8.7x
tldraw	11.2s	1.46s	7.7x

Benchmark 2: Aggregate Memory Usage in TypeScript 6&7

Codebase	TypeScript 6	TypeScript 7	Cumulative Memory
vscode	5.2GB	4.2GB	-18%
sentry	4.9GB	4.6GB	-6%
bluesky	1.8GB	1.3GB	-26%
playwright	1.0GB	0.9GB	-11%
tldraw	0.6GB	0.5GB	-15%

Benchmark 3: Performance with --checkers 8 in TypeScript 6&7

Codebase	TypeScript 6	TypeScript 7 (--checkers 8)	Speedup
vscode	125.7s	7.51s	16.7x
sentry	139.8s	12.08s	11.6x
bluesky	24.3s	2.01s	12.1x
playwright	12.8s	1.16s	11x
tldraw	11.2s	1.06s	10.6x

These are the official benchmark results. And they're truly impressive. I can say that VS Code used to take quite a while to open on my old MacBook, but with these new features, everything will be much faster now.

⚙️ Functional changes

In addition to speed and rewriting all functions in Go, the following benefits are now added:

Performs parsing, type-checking, and emitting in parallel with experimental --checkers and --builders for fine-tuning microsoft

This gives developers complete control over the balance between performance and memory consumption. On CI runners or with limited resources, parallelism can be reduced without losing functionality.

New --singleThreaded for debugging or resource-limited environments

Solves a rather important debugging problem and ensures predictability of results when reproducing bugs.

Type-checking workers can be scaled without scaling builder workers

If you didn't know, type-checking workers handle complex type-checking logic, while builder workers assemble project references; their work is limited by the project dependency graph.

This means that now when setting parameters such as --checkers 6 and --builders 4 can be configured flexibly for each project to ensure the best project build performance.

The --watch mod has also changed, now it uses Parcel's file-watcher ported to Go for assembly, and eliminates expensive polling on large node_modules.

There are also some minor changes in JavaScript and in the configuration file, but overall they are not that important.

💬 My opinion

I believe that speeding up fundamental features like TypeScript, even if it's just rewriting functions in Go, has a significant impact on development. Websites today have quite a few modules and run on modern frameworks like Next.js, Remix, Nuxt, and many others. And they all still run on TypeScript, so it's difficult to comprehend how much time a tenfold speedup in version 7 will save. For developers, VS Code and the Cursor built on top of it will allow them to develop websites even faster.

What do you think about this? It will be interesting to read!

❤️ Thank you very much for reading the article!

Why AI Agents Need a Real Browser Layer, Not Just Playwright Scripts

Anthony Max — Fri, 17 Jul 2026 10:08:02 +0000

Over the past few years, AI has ceased to be just an experimental technology and can now be called a digital worker. It can search for information, fill out forms, work with CRM, analyze documents, and perform complex multi-step processes.

However, along with this growing capability, a new problem has emerged: most existing solutions use the browser exclusively as an automation tool. These are most often Playwright or Selenium, where the agent's actions are limited to specific actions in a script.

This approach is great for website testing, but it's insufficient for autonomous artificial intelligence. Therefore, a full-fledged browser layer is needed to transform a web page into a structured working environment for the model. BrowserAct provides such a layer.

Well, let's get started.

👀 Why Playwright Isn't Enough?

Playwright is an excellent tool for testing. It gives you complete low-level control: click selectors, type into inputs, run JavaScript, take screenshots. That's perfect when you know the page structure in advance and you're testing a specific application.

This is more than sufficient for testing, but an AI agent typically has a much broader range of tasks. For example, it needs to know which page to open, which elements to view, and much more. Each new website becomes a new context that the AI must understand independently. Playwright only provides low-level browser control APIs. All the logic for understanding the page resides in the language model itself, so this approach is unsuitable.

const browserA = await chromium.launch();
const pageA = await browserA.newPage();
const contextA = await browserA.createBrowserContext({
  storageState: './profiles/account-a.json', // Manual session file
});

When working with sessions, you may notice that we'll need to store files and update them manually for the website. If we want to test our application, we'll have to configure everything this way each time.

// Playwright forces you to choose selectors before running
// If the page updates or selectors change, your script breaks
await page.click('#button-id-123'); // What if this you move button in component?
// You'd need to re-scan the page and update your script

// There's no built-in "read current page state and tell me what changed"

We need to know exactly which button is on the page. Otherwise, the script simply won't work.

What AI really needs to work effectively is:

Clean page readout
Parallel account isolation

To do this, let's now try the browser layer, which will help us.

💻 Creating a Browser Layer with BrowserAct.

BrowserAct is a browser automation CLI built for AI agents.

Its partners include Google Cloud, Oracle and others.

Let's now try to make a browser layer. First, let's register, and then go to the dashboard.

There will be a block like this, click on the install button and simply copy the text into AI on your computer. I will insert this prompt into Cursor.

Since I'm in ask mode in the cursor, the agent simply output the file, installing dependencies from which I installed the cli.

After this, we'll be prompted to install several dependencies.

uv tool install browser-act-cli --python 3.12

You can check the version as follows:

browser-act --version

If you're in a mode where AI can edit files, everything will happen automatically. If you're doing it manually, after the cli appears in the terminal, you'll need to get the actual workflow content:

browser-act get-skills core --skill-version 2.0.2

The CLI serves skill content that always matches the installed version, so instructions never go stale. Do NOT truncate the output — none of which are available through --help.

Browser-act can run basic Chrome and chrome-direct browser automation without an API key. But if you want to access other features, you can register, as we did earlier, and enter the following:

browser-act auth login
browser-act auth poll

Or set a key directly:

browser-act auth set <your_api_key>

⚙️ Multi-Account Isolation

Now, let's imagine a case where we need to automatically test our application for, say, several people visiting the site and using the same functionality.

// You'd have to manually manage profiles for each account
const browserA = await chromium.launch();
const pageA = await browserA.newPage();
await pageA.click('#login-button-id');
const contextA = await browserA.createBrowserContext({
  storageState: './profiles/account-a.json', // Manual session file
});
// testSomeFunction()

const browserB = await chromium.launch();
const pageB = await browserB.newPage();
await pageB.click('#login-button-id');
const contextB = await browserB.createBrowserContext({
  storageState: './profiles/account-b.json', // Another session file
});
// testSomeFunction()

// Now you're managing session files, proxy rotation, and fingerprints by hand.

If one account's context crashes, you need to reload session manually. This means that if you want to do something like what happened with GitHub Actions when your functionality was tested, you won't be able to do it here.

# Account A: Use browser with identity-a
browser-act --session account-a browser open <browser_a> https://example.com
browser-act --session login-redirect button 1
browser-act --session account-a login_workflow
# test_some_function_workflow

# Account B: Use browser with identity-b (cookies, proxy, fingerprint)
browser-act --session account-b browser open <browser_b> https://example.com
browser-act --session login-redirect button 1
browser-act --session account-b login_workflow
# test_some_function_workflow

# Both run in parallel.
# Each browser keeps its own:
# - Cookies
# - Login session
# - Proxy identity
# - Fingerprint

In this case, if you have BrowserAct configured, your tests won't need to be constantly updated. You can continue working on the functionality without any worries, and if any issues occur, such as users' IDs being generated identically within a second, the tests will detect them, while you'll never learn about the bug manually.

✅ Import Once, Reuse Always

Another advantage of BrowserAct is the ability to import profiles from a running browser:

# 1. You're already logged in on your local Browser
# BrowserAct discovers it and lists available profiles:
browser-act browser list-profiles

# Output:
# Profile ID           Name                 Email
# profile_a      Default              myaccount1@example.com
# profile_b      Work Account         myaccount2@example.com

# 2. Create a managed browser from your existing Chrome profile
# (includes cookies, localStorage, IndexedDB, session storage)
browser-act browser create \
  --type chrome \
  --name "work-automation" \
  --desc "Logged-in work account for testing" \
  --source-profile profile_a

# 3. Now your browser is ready to use. No login code needed.
browser-act --session test_some_function_workflow browser open work-automation https://example.com/dashboard

In addition to multi-account, this makes testing much easier, whereas PlayWright uses files for everything, which is generally inconvenient.

👀 What is the difference between Playwright and BrowserAct?

At first glance, Playwright and BrowserAct may seem to solve the same problem—they both interact with web browsers. In reality, they operate at different levels of abstraction and are designed for different use cases.

With Playwright, every interaction must be explicitly programmed. You need to know which page to open, which selector to use, when to wait for an element, and how to handle every possible variation of the website. This deterministic approach is ideal for automated testing, where the expected behavior of the application is already known. Instead of exposing only low-level browser APIs, BrowserAct provides an AI-friendly browser layer that enables language models to interact with websites in a more structured and reliable way. It handles many of the browser-related complexities, allowing the AI agent to focus on reasoning and decision-making rather than DOM manipulation.

Feature	Playwright	BrowserAct
Primary purpose	Browser automation and testing	Browser layer for AI agents
Interaction model	Imperative scripts	AI-driven workflows
Login flow handling	Manual implementation	Built-in support
Workflow designer	No	Visual workflow builder
AI integration	External implementation	Native AI-oriented architecture
Structured browser actions	Limited	Yes

For traditional QA automation or end-to-end testing, Playwright remains one of the best choices available. However, if your goal is to build autonomous AI agents that can navigate websites, complete multi-step workflows, handle authentication, extract structured data, or interact with modern web applications, BrowserAct provides a significantly higher-level abstraction.

Rather than replacing Playwright, BrowserAct builds on the idea of browser automation and extends it with the capabilities that modern AI agents require.

💬 Feedback

🖋️ Conclusion

Playwright remains an excellent automation tool, but its capabilities are limited. Autonomous AI agents require much more: context awareness, memory, planning, and the ability to adapt to constantly changing interfaces.

A fully-fledged Browser Layer becomes the missing link between the language model and the browser. It transforms the complex DOM into a semantic representation, reducing the load on the LLM. With BrowserAct, you can implement it quickly and easily.

🔗 Resources:

💎 Star BrowserAct ☆

Thanks for reading this article! ❤️

[Boost]

Anthony Max — Mon, 13 Jul 2026 14:54:07 +0000

Anthony Max

Jul 13

I created a platform with a list to help you share your projects 🔥

#webdev #javascript #programming #opensource

2 min read

I created a platform with a list to help you share your projects 🔥

Anthony Max — Mon, 13 Jul 2026 14:43:35 +0000

Hello everyone! Today I'd like to share my new commercial open source project.

One day, I had the idea to create a platform for projects. But I noticed that in most similar services, you just add your project, and the platforms don't care at all. I'd like to do it differently. It's called List a project and promote it!.

But first, I'd like to say that the name was invented in ten minutes. It may be long, but I think it's perfectly fitting.

Well, let me tell you in more detail.

👀 What is this platform?

This platform represents the same lists we've become accustomed to, but with one caveat: all projects included in the list are taken into long-term, periodic promotion.

I don't like the word "promotion" because it's so overused, and when we hear it, we immediately think of website advertising. However, here it's simply appropriate, so that's why it's used.

Also, it would be great if you supported the project with your star (now he only has one)! Thanks ❤️!

💎 Star List a project and promote it! ★

🔎 What kind of promotion is this?

Essentially, we're not focused on building an audience on the platform, although that's important too. The idea is to periodically work on a project, like an ant working on its visibility. The platform accepts a certain number of projects per month, and the project team will simply add them to relevant articles and create content about them on other platforms. For example, tweets, etc.

daily.dev - Where developers discover what's next

Free, personalized developer news aggregator. Stay current on web dev, AI tools, and software engineering - curated daily from trusted sources for engineers.

daily.dev

This flow allows us to work on projects as efficiently as possible. Also, if we move on to the next month, the number of projects will allow us to work on those from previous months.

⚙️ What did I use to create this platform?

For me the stack was obvious:

Next.js v16 (App Router)
Tailwind v4
ShadCN

It could have been done in PHP, but I wanted to make the lightest possible version for the first version, because later I wanted to connect the API, database, create registration, and so on.