Let AI Search, Read, and Work on Web Pages

Server-side search and browsing usually come from shared data-center IP addresses. Sites often answer that traffic with CAPTCHAs, rate limits, or outright blocks. Cumbersome sends the request from your own network through WebKit on your iPhone, iPad, or Mac. The site sees your network's IP address and the browser characteristics of your device.

It's private by architecture. Your device connects directly to the search engine or website. Folding Sky never proxies the request or receives the query, URL, or page contents through a backend. The search engine or site still sees the request, and your selected AI provider receives the result snippets or extracted text it needs to answer.

Web Agent keeps the current page and browsing history with the active chat. You can watch the page, scroll or type yourself, take over when a site needs human input, and then let the model continue from the same page.

The browser uses a nonpersistent WebKit data store. Closing Web Agent, disabling it, or leaving the chat discards that session. This limits what remains on the device afterward. It does not stop a website or your selected AI provider from receiving information while the session is open.

Local Web Search takes search terms and returns result titles, URLs, and snippets. Cumbersome automatically chooses which search engine to try first based on its app language. There is no local search engine picker in current versions. The model supplies the query, not an engine choice. The services used and their order can change between versions.

If an engine fails, times out, or returns an unusable results page, Cumbersome sends the same query to another search engine. A search can reach more than one engine. Expand a completed search tool row to inspect the engine that returned the result, whether fallback was used, and the requested and final URLs. It does not list every failed attempt.

Local Web Browser starts with an exact URL. It opens that page through your device and returns readable page text to the AI. It works whether Local Web Search is on or off.

When a page needs an interaction before its content appears, Local Web Browser can run JavaScript once after loading and before reading the page. This works in visible and headless modes.

The model chooses among your enabled tools. When Local Web Browser and Web Agent are both enabled, Cumbersome tells it to prefer Local Web Browser for ordinary page reading and one JavaScript action, and use Web Agent for several steps, retained page state, or your help. Local Web Search and Local Web Browser start fresh for each request and can run without an open browser window. With search and page reading both enabled, the model can find URLs and read useful results instead of relying on snippets.

Headless mode can handle up to three independent searches or page loads at once. Web Agent stays sequential because each action depends on the state left by the one before it.

Each search, page open, and extraction appears as a tool event. The result is easier to audit because you can see which sites contributed to the answer. This is especially useful for research that requires several sources rather than a single opaque search summary.

Settings > Tools shows the local and provider tools you can enable. Under MCP Servers, review configured server addresses and open a server to inspect its discovered tools and individual toggles. Provider Web Search runs on your selected AI provider and is separate from Local Web Search.

Cumbersome has no setting that requires you to approve each generated query or general tool call before it runs. Asking the AI to check first depends on the model following your instruction. If you need to review a query before it is sent, disable Local Web Search and Provider Web Search and search manually. Review other enabled browser and remote tools too, since they can still contact external services.