OneGlanseI build and maintain OneGlanse on my own. I would rather spend that time improving the open-source app than running proxies and browsers for everyone.
Browsers are harder to run than API calls
A service can call a model API from one server. OneGlanse instead opens ChatGPT, Perplexity, Gemini, Claude, and Google AI Overview in a browser, submits prompts through each product interface, and captures the rendered response and available citations.
That lets OneGlanse see what people get on the actual websites. A hosted service would have to operate many authenticated browsers while managing:
- Residential proxy capacity and IP reputation
- Provider bot detection and verification challenges
- Browser fingerprints
- Authenticated sessions and session expiry
- Provider rate limits
- Retries and failed browser runs
- UI changes that break automation
- Concurrent browser workers and their compute cost
The cost and operational work grow with the number of prompts, users, regions, and providers. For a solo-maintained project, operating that infrastructure would take substantial time away from improving the product.
Why proxies matter
Browser automation on cloud servers usually comes from datacenter IP ranges. AI product interfaces can challenge, rate-limit, or block that traffic more aggressively than residential traffic. OneGlanse's self-hosted mode supports routing provider traffic through a residential proxy.
Running this centrally for every user would mean paying for proxy capacity and managing IP reputation, geography, sessions, and provider-specific failures. Self-hosted users instead control the proxy and infrastructure for their workload.
I would also have to manage everyone’s logins
The supported AI products use authenticated user sessions. In local mode, you sign in through a browser on your machine. In self-hosted mode, you can transfer saved sessions to your own Agent server.
A hosted OneGlanse service would also need to securely operate third-party account sessions for many users. Running OneGlanse yourself keeps those sessions on your own machine or server, instead of putting them in a service I operate.
Why not just use the APIs?
Model APIs would simplify collection infrastructure, but they would change what OneGlanse measures. Product interfaces can add retrieval, citations, source cards, recommendation ordering, and formatting that differ from the underlying model API. OneGlanse exists to observe that product surface.
The same design choice that makes UI collection useful also makes centralized collection more expensive and difficult to operate reliably.
Read why OneGlanse moved from Chromium to Camoufox for the engineering history behind its browser choice.
Could I host it later?
Yes. Operating this infrastructure centrally is possible. It would require solving the cost and reliability of browser automation, proxy management, bot detection, session handling, and provider-specific failures at scale.
Right now I would rather spend that time making the free, open-source version better. You can run it locally or on your own server. If the project grows enough to support the browser infrastructure, a hosted version could make sense.