Bug: Token consumption is 2 times higher!

[akpost25-cyber]

Browser Use Version

0.11.1

Bug Description, Steps to Reproduce, Screenshots

I ran a list of 20 tasks and the token consumption in version 0.8.1 was 1,000,000, and in version 0.11.1 the consumption for the same tasks was over 2 million!

Failing Python Code

LLM Model

gpt-4.1-mini-2025-04-14

Operating System & Browser Versions

Linux Mint 21.3 Cinnamon

Full DEBUG Log Output

[sauravpanda]

I will have a look at this over this week, thanks for pointing out! If possible can you send me the list of task if they are not proprietary?

[akpost25-cyber]

Here's the scenario example:

1. Go to URL.
2. Type 'Steam' in the search field.
3. Find the first paragraph and save it as 'wiki.txt'.
   ->next_agent - this is the tag at which the previous agent ends and the new one starts in the same browser session.
4. Scroll to the bottom of the page.
5. Find the date the page was last modified.
6. Save it as 'date.txt'.
   ->next_agent
7. In the first paragraph, collect all internal links (blue).
8. Save the link texts as a comma-separated list.
9. Save as 'links.txt'.

Here are the resources spent:
0.11.2
LLM: gpt-4.1-mini-2025-04-14
Total time for 1 task: 2m 38.98s
Total 188653 tokens used
Total 0.0799 USD used

0.8.1
LLM: gpt-4.1-mini-2025-04-14
Total time for 1 task: 1m 42.76s
Total 111918 tokens used
Total 0.0483 USD used

[wstcttt]

probably caused by use_judge=True by default?

[akpost25-cyber]

No, i disabling it. And token consumption has increased by 25-50% since version 0.9.0. Version 0.11.2 consumes almost 100% more than 0.8.1!

[prandata]

I've been digging into this. Did some quick comparisons between the 0.8.x and 0.11.x codebases.

Preliminary findings on what's consuming extra tokens:

1. DOM state serialization changes - The buildDomTree output in 0.11.x includes significantly more element metadata (ARIA roles, interactive states, visibility flags). This gets passed to the LLM on every step.

2. History structure expansion - AgentHistory now includes next_goal and evaluation_previous_goal fields (related to Bug: ... no 'next_goal' and 'evaluation_previous_goal' in history #3767). Even with use_judge=False, the history structure is larger.

3. System prompt growth - The default system_prompt.md has grown between versions. More examples, more formatting instructions.

4. Action schema overhead - The available actions list is now more detailed with richer descriptions.

The 68% increase (112K → 189K) for the same Wikipedia task is substantial. The DOM serialization change is probably the biggest contributor since it compounds with every step.

I can profile the exact token breakdown per LLM call if that would help narrow it down. Would also be useful to test with include_attributes=False or reduced DOM depth to see how much the state serialization contributes.

[sudhanshu112233shukla]

Hi guys !!
do check the PR , I have divided our problem in two phase , i have commited the phase 1 and when you guys can confirm i will proceed with phase 2.

[akpost25-cyber]

2. **History structure expansion** - `AgentHistory` now includes `next_goal` and `evaluation_previous_goal` fields (related to [Bug: ... no 'next_goal' and 'evaluation_previous_goal' in history #3767](https://github.com/browser-use/browser-use/issues/3767)). Even with `use_judge=False`, the history structure is larger.

next_goal and evaluation_previous_goal also exist in version 0.8.1. Their absence is only a bug when using browser-use's llm.

[laithrw]

@pdaxt has a good analysis. These changes were made to improve task completion accuracy and were necessary.

If you'd like to cut down on token usage, you can set max_history_items. When history exceeds the cap, it keeps the first item + the most recent N-1 items, dropping everything else. You could also disable vision, but this is not recommended.

Additionally, message compaction (#4042) has since been merged. Message compaction summarizes older history instead of re-sending everything, cutting down on token usage.

[rcholic]

Yeah, seeing this across several frameworks. The DOM tree serialization in recent versions likely started capturing deeper metadata and accessibility trees, which geometrically blows up the token count on complex sites.

Feeding raw or lightly-parsed DOM into the context window is a losing battle against token limits, especially when chaining 20+ tasks.

We got tired of burning API credits on DOM bloat, so we built an open-source Rust-backed DOM compaction engine (predicate-runtime). Instead of sending HTML, it calculates spatial geometry and visual cues locally, compiling the page into a dense semantic table (id | role | text | importance).

It cuts token burn by ~90%. We recently used it to run a full Amazon checkout on a tiny local 4B model because the prompt per step drops to ~1,200 tokens.

You can plug it directly into your existing browser-use loop using our plugin wrapper to strip the noise. It will likely bring your consumption well below your old 0.8.1 levels. See the example for integrating into browser-use to save your token cost: https://github.com/PredicateSystems/predicate-runtime-python/tree/main/examples/browser-use