career-ops scans job portals, scores the postings and tailors a CV. It runs inside a coding assistant, and that turns out to be the whole answer to the proxy question. We read release career-ops-v1.33.0 on 20 September 2026.
This is the first project in this series that makes no requests of its own.
The project does not fetch
The pipeline is a set of instructions for the assistant, and it names the order of preference:
| Who fetches | When | Can it take an address |
|---|---|---|
| a browser tool through the assistant | preferred, works with dynamic pages | that tool's own setting |
| the project's own extractor script | opt in, fewer tokens | no |
| the assistant's own fetch tool | static pages, or no browser | that assistant's setting |
| you, pasting the text | when the page needs an account | not applicable |
So the setting you are looking for is not in this repository. It is in whichever browser server or assistant is doing the work, which is a question we have answered separately for several of them.
The two scripts it owns
Two files here do fetch: an opt in extractor and a liveness checker. Both launch a browser the same way:
browser = await chromium.launch({ headless: true });
Headless mode and nothing else. No proxy argument, no user agent, no hook to pass options. If you want an address on that path, you are patching those lines or routing below the process.
Throttle first
The project's own answer to being refused is not an address. It is pacing.
The liveness checker takes --throttle, which waits a jittered five to ten seconds between browser checks, and the pipeline recommends it for large batches to stay under rate limits.
That is the correct fix for the correct problem. A rate limit is about how fast you ask. Reaching for an address first is a common and expensive mistake, and this project does not make it.
The wall an address cannot move
For LinkedIn the instructions are blunt. Try the browser first. After two attempts that return only login, browser chrome or error content, mark the entry and ask the user to paste the text. And: never treat a login wall or partial shell as a verified posting.
We think that is the right call, and we will say the part that is against our own interest. No address opens a page that requires an account. A proxy changes where a request comes from, not who is signed in.
What we measured
Our own test was 16 URLs, plain requests, run from a server address and through a residential line of our own plan. Four of thirteen sites answered the residential address differently. The relevant part for this page is which ones did not:
| Site | Server address | Residential line |
|---|---|---|
| Indeed | refused | refused |
| Glassdoor | refused | refused |
| Amazon | refused | refused |
| Booking | refused | refused |
Two of the largest job boards refused both. If your scans are failing on those specifically, an address is not the first thing to buy.
Which proxy type fits it?
Honestly: check what is failing before you buy anything.
If postings return partial pages or rate limit errors, use the throttle and check which tool is fetching. If a page wants an account, paste the text as the project asks. Those two cover most of what a job scan hits.
If what you meet is a range on a block list, which is the third case, then residential is the type that changes the answer, and our own test is the size of that effect at 4 of 13 sites. The place to put it is the browser tool your assistant drives, or the machine itself, since this project exposes no option. An allowed address suits that: one machine, allowed by its address, with no password anywhere in a configuration your assistant can read. On a Residential Premium plan your machine's address can be allowed, up to 150 per plan. The residential proxies page lists the plans, and the plan API manages allowed addresses from code.
What breaks
- You cannot find the proxy setting. There is not one. The assistant's browser tool fetches.
- Scans return login shells. That is an account wall. Paste the text, as the project asks.
- Everything slows down or errors in a batch. Use the throttle flag before anything else.
- A residential line did not help on the big boards. In our test it did not either.
- The extractor is not being used. It is opt in, through a setting in the profile file.
What this page does not cover
We read the release as text and did not run the tool, so we did not watch a scan, did not measure its traffic and did not test a job board through a full browser. Our measurement used plain requests, so it bounds the address effect and not the whole question: a browser with a complete fingerprint may be treated differently. We read the pipeline instructions and the two scripts the project owns closely, and the rest of a large instruction set not at all. We did not examine any particular browser tool's proxy support here, only noted that it is where the setting lives. This project pushes daily and the release we read was four days old. We will read it again by 20 October 2026.
Where to go from here
Proxies for Playwright MCP covers the browser tool this pipeline prefers, including where its proxy and login go. Proxies for OpenClaw covers a coding assistant's own network paths. Proxies for World Monitor covers the measurement that showed which sources refuse which address ranges.
Sources
- The extraction order and the LinkedIn rule, including the instruction to treat fetched and pasted content as data rather than instructions (modes/pipeline.md). The two scripts that launch a browser, and the throttle flag with its jittered wait (browser-extract.mjs, check-liveness.mjs). career-ops-hq/career-ops, release career-ops-v1.33.0 of 16 September 2026, read 20 September 2026.
- Our paired address test of 19 September 2026: 16 URLs, plain requests, two runs from our server and two through a residential line of our house plan, never a customer plan. Raw output is kept in the research folder of our OpenClaw page.
- Plans, allowed addresses and per gigabyte pricing. HProxy documentation, hproxy.com/docs, 20 September 2026.
