Highlights
Plenty of sites hand their front page to anyone and lock everything one click deeper. Auto walks in the front door now: it takes the session that entry page gives out, then asks for the page you wanted while carrying it. Browser got the heavier work this week. It clears Cloudflare's checkbox challenge when several requests hit the same page at once, and when a page stays shut it reports what it saw instead of one flat word.
What's New
Auto opens pages that gate behind a session
An eBay listing refuses a cold request on every route we have. The same URL opens when the request carries the cookie jar eBay's own entry page hands to any visitor. No login, no borrowed account, nothing you couldn't do by hand in a tab.
Auto does it for you now. When an exit reaches the origin and still gets refused the deep page, Auto fetches the site root through that same exit, keeps whatever cookies come back, and asks again. The response tells you it happened: the winning rung reads warmup.
But cost is the interesting part. That session comes back portable, so the jar isn't welded to the exit that earned it. Follow-up reads replay through /api/proxy and land on /api/single at 2 credits. It's the same escalate-then-replay chain we wrote about for Cloudflare clearance, with a vendor's own session cookies standing in for cf_clearance.
Bounded on purpose: two tries per request, on different exits, only after the deep URL has already failed, and only when the exit reached the origin in the first place. So a site that simply blocks us pays two extra sub-calls once, not a loop. More on how the ladder picks its rungs in the Auto write-up.
Browser clears checkbox challenges when requests overlap
Browser now solves Cloudflare's checkbox widget on concurrent requests to the same page. Three at once on a news site behind Turnstile: 5.2s, 5.8s, 9.1s.
Two smaller changes rode along. A press counts only once the widget is actually gone, because Cloudflare re-issues its challenge more often than you'd expect (the first press is regularly not the end of the conversation). And a page that clears reports defenseSolved: true on the call that cleared it, which is the same call billed for the solve.
A blocked page tells you what the solver saw
"Timeout" points you at latency. Most of the time latency isn't the problem and the answer is one exit over.
When Cloudflare rejects a solve it re-issues the challenge and drops its own retry marker into the jar. Browser reads that marker. Rather than waiting out the clock, it answers in around 17 seconds, naming the vendor, the presses it made and whether clearance was granted:
Timeout after 12s: the cloudflare challenge did not complete from this exit
(2 checkbox presses, clearance granted, challenge re-issued by the site)
One of those lines tells you to send the request out a different way. The other tells you nothing.
Errors from the API layer read straighter too. A request that outlives the wait comes back as a timeout, a service we can't reach comes back as unavailable, and neither is described as a proxy problem when the request carried no proxy at all. timeout_ms on a Browser call is honoured to the full 120 seconds the API accepts, so a slow target gets the budget you set and you read the engine's own verdict rather than the gateway's. Parameters are listed in the API reference.
Billing details, and correcting an invoice in its issue month
Bulgarian invoices print a company representative (MOL) in the recipient box. Nothing in the system collected it, so that line could only ever come out empty. Billing details has the field now.
The Invoices table also offers Update details on an invoice that's still inside its issue month and whose frozen details differ from your current billing profile. The dialog names each field that changes and what it changes to, says plainly that the number, the dates and the amounts stay where they are, and confirming it is your consent, recorded on our side. An invoice in the window with nothing to change reads "Editable until" and its date, so the window is something you can see rather than something you find out about later.
Under the Hood
Every script the Dashboard runs is served from our own origin, and signing in returns you only to a path on this site.
Rollouts of the rendering service go one server at a time, and each server has to serve a real page before the next one is touched.
On the status portal, the issues endpoint serves open and resolved items over its public API, matching what the page lists.
A refusal that names itself is one call. A wait that ends in "Timeout" is a guess about what to try next, paid for at the same price. Errors are a product surface, and this week we started treating them like one.