Content Loss Test — How It Works
- The initial viewport is set to 1280x720px
- Elements are captured in the current state using the AXTree
- A full scroll is performed over the page, divided into 8 steps to allow element loading/rendering and stability before taking the 100% screenshot
- Once the screenshot is taken, reflow to 320px wide is applied
- Elements on the page are captured in this state
- Content loss verification begins using Computer Use
Computer Use
Computer Use is an Anthropic tool where an AI agent interacts with an environment and is fed back by its own actions, memories, and metadata. We have a main loop of 30 maximum steps where the investigation is carried out on the page in our virtual browser. The default model (claude-haiku-4-5) has access to the list of elements captured previously as well as the original screenshots. This agent is capable of executing a series of tools to carry out the investigation.
Agent Tools
- Right-click
- Scroll
- Click by backendId (referenced from the captured element list)
- Viewport size management (100% and reflow)
- Call a smart model (claude-sonnet-4-5)
- Reset the page
- Memory management (memories)
- Take screenshots to see current state
These tools are used by the agent based on context and the general prompt it receives in the main loop — it decides when to use each one.
How to Run the Test Manually
To reproduce the test manually in the browser:
- Open the page to be tested in 2 different Chrome windows
- In the first window, adjust the viewport to 1280px wide. You can use https://whatismyviewport.com/
- In the second window, adjust the viewport to 320px wide. You can use DevTools by disabling responsive mode and adjusting the viewport
- Observe elements that have been lost in this view
Limitations
- May present missing issues: Either due to the amount of content to process in each iteration or due to a systematic cache cleanup that occurs when too much has been consumed (to save tokens/costs)
- At the time of writing this documentation, there have been isolated cases of false positives, all related to interaction with elements such as hamburger menus where the agent was unable to perform the click correctly
- Click coordinates: It is common for the default model (claude-haiku-4-5) to have some uncertainty when suggesting coordinates for where a click should occur. For this, we have the "Call a smart model" tool where a single call is made with this more expensive model to resolve the clicks.
- Sticky scroll: Large pages with sticky scroll in sections cause the model to consume too many of its 30 available steps during the investigation and also make it doubt whether it is performing actions correctly. Memory/cache is also wasted.
- Elements that have the same functionality at different viewport sizes but have ambiguous meanings for the model may occasionally generate false positives (case "Try for Free" in Accessibly)
