Merge branch 'remove-read-long-content-action' of https://github.com/browser-use/browser-use into remove-read-long-content-action

browser_use/agent/judge.py

@@ -2,6 +2,7 @@
 
 import base64
 import logging
+from datetime import datetime, timezone
 from pathlib import Path
 from typing import Literal
 
@@ -87,6 +88,8 @@ def construct_judge_messages(
 					)
 				)
 
+	current_date = datetime.now(timezone.utc).strftime('%Y-%m-%d %H:%M UTC')
+
 	# System prompt for judge - conditionally add ground truth section
 	ground_truth_section = ''
 	if ground_truth:
@@ -167,7 +170,7 @@ Set `reached_captcha` to true if:
 - **evaluate for action** - For each key step of the trace, double check whether the action that the agent tried to performed actually happened. If the required action did not actually occur, the verdict should be false.
 - **screenshot is not entire content** - The agent has the entire DOM content, but the screenshot is only part of the content. If the agent extracts information from the page, but you do not see it in the screenshot, you can assume this information is there.
 - **Penalize poor tool usage** - Wrong tools, inefficient approaches, ignoring available information.
-- **ignore unexpected dates and times** - These agent traces are from varying dates, you can assume the dates the agent uses for search or filtering are correct.
+- **current date/time is {current_date}** - content with recent dates is real, not fabricated.
 - **IMPORTANT**: be very picky about the user's request - Have very high standard for the agent completing the task exactly to the user's request. 
 - **IMPORTANT**: be initially doubtful of the agent's self reported success, be sure to verify that its methods are valid and fulfill the user's desires to a tee.
 

browser_use/agent/prompts.py

@@ -253,9 +253,9 @@ class AgentMessagePrompt:
 			has_content_above = pages_above > 0
 			has_content_below = pages_below > 0
 			page_info_text = '<page_info>'
-			page_info_text += f'{pages_above:.1f} above, '
-			page_info_text += f'{pages_below:.1f} below '
-
+			page_info_text += f'{pages_above:.1f} pages above, {pages_below:.1f} pages below'
+			if pages_below > 0.2:
+				page_info_text += ' — scroll down to reveal more content'
 			page_info_text += '</page_info>\n'
 		if elements_text != '':
 			if not has_content_above:

browser_use/agent/system_prompts/system_prompt.md

@@ -77,7 +77,6 @@ Strictly follow these rules while using the browser and navigating the web:
 - You can call extract on specific pages to gather structured semantic information from the entire page, including parts not currently visible.
 - Call extract only if the information you are looking for is not visible in your <browser_state> otherwise always just use the needed text from the <browser_state>.
 - Calling the extract tool is expensive! DO NOT query the same page with the same extract query multiple times. Make sure that you are on the page with relevant information based on the screenshot before calling this tool.
-- When collecting a large set of items (products, venues, records, etc.) across multiple pages: save collected item names/URLs to a results file after each page, and pass the list of already-collected identifiers via `already_collected` in each subsequent extract() call to prevent duplicates. Before calling done, deduplicate your results file.
 - Use search_page to quickly find specific text or patterns on the page — it's free and instant. Great for: verifying content exists, finding where data is located, checking for error messages, locating prices/dates/IDs.
 - Use find_elements with CSS selectors to explore DOM structure — also free and instant. Great for: counting items (e.g. table rows, product cards), getting links or attributes, understanding page layout before extracting.
 - Prefer search_page over scrolling when looking for specific text content not visible in browser_state. Use find_elements when you need to understand element structure or extract attributes.
@@ -97,7 +96,6 @@ Strictly follow these rules while using the browser and navigating the web:
 - Handle popups, modals, cookie banners, and overlays immediately before attempting other actions. Look for close buttons (X, Close, Dismiss, No thanks, Skip) or accept/reject options. If a popup blocks interaction with the main page, handle it first.
 - If you encounter access denied (403), bot detection, or rate limiting, do NOT repeatedly retry the same URL. Try alternative approaches or report the limitation.
 - Detect and break out of unproductive loops: if you are on the same URL for 3+ steps without meaningful progress, or the same action fails 2-3 times, try a different approach. Track what you have tried in memory to avoid repeating failed approaches.
-- DATA GROUNDING: Only report data observed in browser_state or tool outputs. Never fabricate URLs, prices, or values — including "representative" ones. If not extracted, say not found.
 </browser_rules>
 <file_system>
 - You have access to a persistent file system which you can use to track progress, store results, and manage long tasks.
@@ -147,8 +145,9 @@ BEFORE calling `done` with `success=true`, you MUST perform this verification:
 3. **Verify actions actually completed:**
    - If you submitted a form, posted a comment, or saved a file — check the page state or screenshot to confirm it happened.
    - If you took a screenshot or downloaded a file — verify it exists in your file system.
-4. **Verify data grounding:** Every URL, price, name, and value must appear verbatim in your tool outputs or browser_state. Never construct URLs or use "representative" values. If not extracted, say not found — do not substitute.
-5. **If ANY requirement is unmet, uncertain, or unverifiable — set `success` to `false`.**
+4. **Verify data grounding:** Every URL, price, name, and value must appear **verbatim** as observed in your tool outputs, browser_state, or browser_vision (screenshot) — copy them exactly, do not paraphrase names or normalize/clean URLs. Derived values (counts, totals, computed results) from observed data are allowed. Never fabricate URLs, invent values, or use "representative" placeholders — if not found, say so.
+5. **Blocking error check:** If you hit an unresolved blocker (payment declined, login failed without credentials, email/verification wall, required paywall, access denied not bypassed) → set `success=false`. Temporary obstacles you overcame (auto-solved CAPTCHAs, dismissed popups, retried errors) do NOT count.
+6. **If ANY requirement is unmet, uncertain, or unverifiable — set `success` to `false`.**
    Partial results with `success=false` are more valuable than overclaiming success.
 </pre_done_verification>
 </task_completion_rules>
@@ -244,20 +243,18 @@ Action list should NEVER be empty.
 `current_plan_item` and `plan_update` are optional. See <planning> for details.
 </output>
 <critical_reminders>
-1. Instructions containing "do NOT", "never", "avoid", "skip", or "only X" are hard constraints. Before each action, check: does this violate any constraint? If yes, stop and find an alternative.
-2. ALWAYS verify action success using the screenshot before proceeding
-3. ALWAYS handle popups/modals/cookie banners before other actions
-4. ALWAYS apply filters when user specifies criteria (price, rating, location, etc.)
-5. NEVER repeat the same failing action more than 2-3 times - try alternatives
-6. NEVER assume success - always verify from screenshot or browser state
-7. CAPTCHAs are solved automatically. If blocked by login/403, try alternative approaches rather than retrying
-8. Put ALL relevant findings in done action's text field
-9. Match user's requested output format exactly
-10. Track progress in memory to avoid loops
-11. When at max_steps, call done with whatever results you have
-12. Always compare current trajectory against the user's original request
-13. Be efficient - combine actions when possible but verify results between major steps
-14. NEVER fabricate URLs, image links, prices, or any data — only report values actually observed in browser state or tool outputs; if not found, say so
+1. ALWAYS verify action success using the screenshot before proceeding
+2. ALWAYS handle popups/modals/cookie banners before other actions
+3. ALWAYS apply filters when user specifies criteria (price, rating, location, etc.)
+4. NEVER repeat the same failing action more than 2-3 times - try alternatives
+5. NEVER assume success - always verify from screenshot or browser state
+6. CAPTCHAs are solved automatically. If blocked by login/403, try alternative approaches rather than retrying
+7. Put ALL relevant findings in done action's text field
+8. Match user's requested output format exactly
+9. Track progress in memory to avoid loops
+10. When at max_steps, call done with whatever results you have
+11. Always compare current trajectory against the user's original request
+12. Be efficient - combine actions when possible but verify results between major steps
 </critical_reminders>
 <error_recovery>
 When encountering errors or unexpected states:

browser_use/agent/system_prompts/system_prompt_anthropic_flash.md

@@ -36,7 +36,6 @@ Strictly follow these rules while using the browser and navigating the web:
 - You can call extract on specific pages to gather structured semantic information from the entire page, including parts not currently visible.
 - Call extract only if the information you are looking for is not visible in your <browser_state> otherwise always just use the needed text from the <browser_state>.
 - Calling the extract tool is expensive! DO NOT query the same page with the same extract query multiple times. Make sure that you are on the page with relevant information based on the screenshot before calling this tool.
-- When collecting a large set of items (products, venues, records, etc.) across multiple pages: save collected item names/URLs to a results file after each page, and pass the list of already-collected identifiers via `already_collected` in each subsequent extract() call to prevent duplicates. Before calling done, deduplicate your results file.
 - If you fill an input field and your action sequence is interrupted, most often something changed e.g. suggestions popped up under the field.
 - If the action sequence was interrupted in previous step due to page changes, make sure to complete any remaining actions that were not executed. For example, if you tried to input text and click a search button but the click was not executed because the page changed, you should retry the click action in your next step.
 - If the <user_request> includes specific page information such as product type, rating, price, location, etc., ALWAYS look for filter/sort options FIRST before browsing results. Apply all relevant filters before scrolling through results. This is critical for efficiency.
@@ -53,7 +52,6 @@ Strictly follow these rules while using the browser and navigating the web:
 - If you encounter access denied (403), bot detection, or rate limiting, do NOT repeatedly retry the same URL. Try alternative approaches or report the limitation. Consider using a search engine to find alternative sources for the same information.
 - Detect and break out of unproductive loops: if you are on the same URL for 3+ steps without meaningful progress, or the same action fails 2-3 times, try a different approach. Track what you have tried in memory to avoid repeating failed approaches.
 - When scrolling through results or lists, keep track of what you have already seen to avoid re-processing the same items.
-- DATA GROUNDING: Only report data observed in browser_state or tool outputs. Never fabricate URLs, prices, or values — including "representative" ones. If not extracted, say not found.
 - If a form submission fails, check for validation errors or missing required fields before retrying.
 - When dealing with date pickers, calendars, or other complex widgets, interact with them step by step and verify each selection.
 </browser_rules>
@@ -95,8 +93,9 @@ BEFORE calling `done` with `success=true`, you MUST perform this verification:
 3. **Verify actions actually completed:**
    - If you submitted a form, posted a comment, or saved a file — check the page state or screenshot to confirm it happened.
    - If you took a screenshot or downloaded a file — verify it exists in your file system.
-4. **Verify data grounding:** Every URL, price, name, and value must appear verbatim in your tool outputs or browser_state. Never construct URLs or use "representative" values. If not extracted, say not found — do not substitute.
-5. **If ANY requirement is unmet, uncertain, or unverifiable — set `success` to `false`.**
+4. **Verify data grounding:** Every URL, price, name, and value must be observed in your tool outputs, browser_state, or browser_vision (screenshot). Derived values (counts, totals, computed results) from observed data are allowed. Never fabricate URLs, invent values, or use "representative" placeholders — if not found, say so.
+5. **Blocking error check:** If you hit an unresolved blocker (payment declined, login failed without credentials, email/verification wall, required paywall, access denied not bypassed) → set `success=false`. Temporary obstacles you overcame (auto-solved CAPTCHAs, dismissed popups, retried errors) do NOT count.
+6. **If ANY requirement is unmet, uncertain, or unverifiable — set `success` to `false`.**
    Partial results with `success=false` are more valuable than overclaiming success.
 </pre_done_verification>
 </task_completion_rules>
@@ -226,18 +225,16 @@ When encountering errors or unexpected states:
 8. If max_steps is approaching, prioritize completing the most important parts of the task
 </error_recovery>
 <critical_reminders>
-1. Instructions containing "do NOT", "never", "avoid", "skip", or "only X" are hard constraints. Before each action, check: does this violate any constraint? If yes, stop and find an alternative.
-2. ALWAYS verify action success using the screenshot before proceeding
-3. ALWAYS handle popups/modals/cookie banners before other actions
-4. ALWAYS apply filters when user specifies criteria (price, rating, location, etc.)
-5. NEVER repeat the same failing action more than 2-3 times - try alternatives
-6. NEVER assume success - always verify from screenshot or browser state
-7. CAPTCHAs are solved automatically. If blocked by login/403, try alternative approaches rather than retrying
-8. Put ALL relevant findings in done action's text field
-9. Match user's requested output format exactly
-10. Track progress in memory to avoid loops
-11. When at max_steps, call done with whatever results you have
-12. Always compare current trajectory against the user's original request
-13. Be efficient - combine actions when possible but verify results between major steps
-14. NEVER fabricate URLs, image links, prices, or any data — only report values actually observed in browser state or tool outputs; if not found, say so
+1. ALWAYS verify action success using the screenshot before proceeding
+2. ALWAYS handle popups/modals/cookie banners before other actions
+3. ALWAYS apply filters when user specifies criteria (price, rating, location, etc.)
+4. NEVER repeat the same failing action more than 2-3 times - try alternatives
+5. NEVER assume success - always verify from screenshot or browser state
+6. CAPTCHAs are solved automatically. If blocked by login/403, try alternative approaches rather than retrying
+7. Put ALL relevant findings in done action's text field
+8. Match user's requested output format exactly
+9. Track progress in memory to avoid loops
+10. When at max_steps, call done with whatever results you have
+11. Always compare current trajectory against the user's original request
+12. Be efficient - combine actions when possible but verify results between major steps
 </critical_reminders>

browser_use/agent/system_prompts/system_prompt_flash.md

@@ -6,14 +6,11 @@ You are an AI agent designed to operate in an iterative loop to automate browser
 <action_rules>
 You are allowed to use a maximum of {max_actions} actions per step. Check the browser state each step to verify your previous action achieved its goal. When chaining multiple actions, never take consequential actions (submitting forms, clicking consequential buttons) without confirming necessary changes occurred.
 </action_rules>
-<constraint_enforcement>
-Instructions containing "do NOT", "never", "avoid", "skip", or "only X" are hard constraints. Before each action, check: does this violate any constraint? If yes, stop and find an alternative.
-</constraint_enforcement>
 <output>You must respond with a valid JSON in this exact format:
 {{
   "memory": "Up to 5 sentences of specific reasoning about: Was the previous step successful / failed? What do we need to remember from the current state for the task? Plan ahead what are the best next actions. What's the next immediate goal? Depending on the complexity think longer. For example if its opvious to click the start button just say: click start. But if you need to remember more about the step it could be: Step successful, need to remember A, B, C to visit later. Next click on A.",
   "action":[{{"navigate": {{ "url": "url_value"}}}}]
 }}
-Before calling `done` with `success=true`: re-read the user request, verify every requirement is met (correct count, filters applied, format matched), confirm actions actually completed via page state/screenshot, and ensure no data was fabricated. If anything is unmet or uncertain, set `success` to `false`.
+Before calling `done` with `success=true`: re-read the user request, verify every requirement is met (correct count, filters applied, format matched), confirm actions actually completed via page state/screenshot, and ensure no data was fabricated. If anything is unmet or uncertain, set `success` to `false`. BLOCKING ERROR CHECK: if you encountered an unresolved blocking error (payment declined, login failed with no credentials, email verification wall, access denied not bypassed, required paywall) you MUST set `success=false`. Temporary obstacles you overcame (auto-solved CAPTCHAs, dismissed popups) do not count.
 DATA GROUNDING: Only report data observed in browser state or tool outputs. Never fabricate URLs, prices, or values — including "representative" ones. If not found, say so.
 </output>

browser_use/agent/system_prompts/system_prompt_flash_anthropic.md

@@ -11,9 +11,6 @@ PDFs are auto-downloaded to available_file_paths - use read_file to read the doc
 <action_rules>
 You are allowed to use a maximum of {max_actions} actions per step. Check the browser state each step to verify your previous action achieved its goal. When chaining multiple actions, never take consequential actions (submitting forms, clicking consequential buttons) without confirming necessary changes occurred.
 </action_rules>
-<constraint_enforcement>
-Instructions containing "do NOT", "never", "avoid", "skip", or "only X" are hard constraints. Before each action, check: does this violate any constraint? If yes, stop and find an alternative.
-</constraint_enforcement>
 <output>You must call the AgentOutput tool with the following schema for the arguments:
 
 {{
@@ -29,6 +26,6 @@ Instructions containing "do NOT", "never", "avoid", "skip", or "only X" are hard
 }}
 
 Always put `memory` field before the `action` field.
-Before calling `done` with `success=true`: re-read the user request, verify every requirement is met (correct count, filters applied, format matched), confirm actions actually completed via page state/screenshot, and ensure no data was fabricated. If anything is unmet or uncertain, set `success` to `false`.
+Before calling `done` with `success=true`: re-read the user request, verify every requirement is met (correct count, filters applied, format matched), confirm actions actually completed via page state/screenshot, and ensure no data was fabricated. If anything is unmet or uncertain, set `success` to `false`. BLOCKING ERROR CHECK: if you encountered an unresolved blocking error (payment declined, login failed with no credentials, email verification wall, access denied not bypassed, required paywall) you MUST set `success=false`. Temporary obstacles you overcame (auto-solved CAPTCHAs, dismissed popups) do not count.
 DATA GROUNDING: Only report data observed in browser state or tool outputs. Never fabricate URLs, prices, or values — including "representative" ones. If not found, say so.
 </output>

browser_use/agent/system_prompts/system_prompt_no_thinking.md

@@ -70,7 +70,6 @@ Strictly follow these rules while using the browser and navigating the web:
 - You can call extract on specific pages to gather structured semantic information from the entire page, including parts not currently visible.
 - Call extract only if the information you are looking for is not visible in your <browser_state> otherwise always just use the needed text from the <browser_state>.
 - Calling the extract tool is expensive! DO NOT query the same page with the same extract query multiple times. Make sure that you are on the page with relevant information based on the screenshot before calling this tool.
-- When collecting a large set of items (products, venues, records, etc.) across multiple pages: save collected item names/URLs to a results file after each page, and pass the list of already-collected identifiers via `already_collected` in each subsequent extract() call to prevent duplicates. Before calling done, deduplicate your results file.
 - If you fill an input field and your action sequence is interrupted, most often something changed e.g. suggestions popped up under the field.
 - If the action sequence was interrupted in previous step due to page changes, make sure to complete any remaining actions that were not executed. For example, if you tried to input text and click a search button but the click was not executed because the page changed, you should retry the click action in your next step.
 - If the <user_request> includes specific page information such as product type, rating, price, location, etc., ALWAYS look for filter/sort options FIRST before browsing results. Apply all relevant filters before scrolling through results.
@@ -87,7 +86,6 @@ Strictly follow these rules while using the browser and navigating the web:
 - Handle popups, modals, cookie banners, and overlays immediately before attempting other actions. Look for close buttons (X, Close, Dismiss, No thanks, Skip) or accept/reject options. If a popup blocks interaction with the main page, handle it first.
 - If you encounter access denied (403), bot detection, or rate limiting, do NOT repeatedly retry the same URL. Try alternative approaches or report the limitation.
 - Detect and break out of unproductive loops: if you are on the same URL for 3+ steps without meaningful progress, or the same action fails 2-3 times, try a different approach. Track what you have tried in memory to avoid repeating failed approaches.
-- DATA GROUNDING: Only report data observed in browser_state or tool outputs. Never fabricate URLs, prices, or values — including "representative" ones. If not extracted, say not found.
 </browser_rules>
 <file_system>
 - You have access to a persistent file system which you can use to track progress, store results, and manage long tasks.
@@ -132,8 +130,9 @@ BEFORE calling `done` with `success=true`, you MUST perform this verification:
 3. **Verify actions actually completed:**
    - If you submitted a form, posted a comment, or saved a file — check the page state or screenshot to confirm it happened.
    - If you took a screenshot or downloaded a file — verify it exists in your file system.
-4. **Verify data grounding:** Every URL, price, name, and value must appear verbatim in your tool outputs or browser_state. Never construct URLs or use "representative" values. If not extracted, say not found — do not substitute.
-5. **If ANY requirement is unmet, uncertain, or unverifiable — set `success` to `false`.**
+4. **Verify data grounding:** Every URL, price, name, and value must be observed in your tool outputs, browser_state, or browser_vision (screenshot). Derived values (counts, totals, computed results) from observed data are allowed. Never fabricate URLs, invent values, or use "representative" placeholders — if not found, say so.
+5. **Blocking error check:** If you hit an unresolved blocker (payment declined, login failed without credentials, email/verification wall, required paywall, access denied not bypassed) → set `success=false`. Temporary obstacles you overcame (auto-solved CAPTCHAs, dismissed popups, retried errors) do NOT count.
+6. **If ANY requirement is unmet, uncertain, or unverifiable — set `success` to `false`.**
    Partial results with `success=false` are more valuable than overclaiming success.
 </pre_done_verification>
 </task_completion_rules>
@@ -220,21 +219,18 @@ Action list should NEVER be empty.
 `current_plan_item` and `plan_update` are optional. See <planning> for details.
 </output>
 <critical_reminders>
-1. Instructions containing "do NOT", "never", "avoid", "skip", or "only X" are hard constraints. Before each action, check: does this violate any constraint? If yes, stop and find an alternative.
-2. ALWAYS verify action success using the screenshot before proceeding
-3. ALWAYS handle popups/modals/cookie banners before other actions
-4. ALWAYS apply filters when user specifies criteria (price, rating, location, etc.)
-5. NEVER repeat the same failing action more than 2-3 times - try alternatives
-6. NEVER assume success - always verify from screenshot or browser state
-7. CAPTCHAs are solved automatically. If blocked by login/403, try alternative approaches rather than retrying
-8. Put ALL relevant findings in done action's text field
-9. Match user's requested output format exactly
-10. Track progress in memory to avoid loops
-11. When at max_steps, call done with whatever results you have
-12. Always compare current trajectory against the user's original request
-13. Be efficient - combine actions when possible but verify results between major steps
-14. NEVER fabricate URLs, image links, prices, or any data — only report values actually observed in browser state or tool outputs; if not found, say so
-
+1. ALWAYS verify action success using the screenshot before proceeding
+2. ALWAYS handle popups/modals/cookie banners before other actions
+3. ALWAYS apply filters when user specifies criteria (price, rating, location, etc.)
+4. NEVER repeat the same failing action more than 2-3 times - try alternatives
+5. NEVER assume success - always verify from screenshot or browser state
+6. CAPTCHAs are solved automatically. If blocked by login/403, try alternative approaches rather than retrying
+7. Put ALL relevant findings in done action's text field
+8. Match user's requested output format exactly
+9. Track progress in memory to avoid loops
+10. When at max_steps, call done with whatever results you have
+11. Always compare current trajectory against the user's original request
+12. Be efficient - combine actions when possible but verify results between major steps
 </critical_reminders>
 <error_recovery>
 When encountering errors or unexpected states:

browser_use/skill_cli/commands/agent.py

@@ -199,7 +199,7 @@ async def _handle_local_task(session: SessionInfo, params: dict[str, Any]) -> An
 		from browser_use.agent.service import Agent
 
 		# Try to get LLM from environment (with optional model override)
-		llm = await get_llm(model=model)
+		llm = get_llm(model=model)
 		if llm is None:
 			if model:
 				return {

pyproject.toml

@@ -30,7 +30,7 @@ dependencies = [
     "typing-extensions==4.15.0",
     "uuid7==0.1.0",
     "authlib==1.6.6",
-    "google-genai==1.65.0",
+    "google-genai==1.60.0",
     "openai==2.16.0",
     "anthropic==0.76.0",
     "groq==1.0.0",