Evaluation design
Controlling network context in CAPTCHA comparisons
Track local transport and worker networking separately so route changes do not become unsupported claims about solver quality.
By the easycaptcha team · Published
Your application connects to the solving API, and the token worker may use separate networking for challenge traffic. A proxy configured in the HTTP client controls the former. A token request’s proxy field controls the worker context described by that task contract.
Independent network paths
Changing one does not automatically change the other. Keep both visible in an evaluation without storing their passwords or credential-bearing URLs in general logs.
Record configuration, not secrets
Use a non-secret route identifier, environment, transport backend, and whether a worker proxy was supplied. Record when configuration changes so results can be segmented around the change.
| Failure stage | Evidence to retain |
|---|---|
| Before an accepted ID | Local transport outcome and uncertainty |
| During accepted work | Task ID and terminal or pending state |
| During final submission | Application observation and intended context |
Those stages require different recovery decisions. A local network timeout does not establish the worker failed, and a worker failure is not proof the local client could not reach the API.
Avoid hidden cohort changes
If route, browser, task family, and solver all change together, a difference in acceptance has several possible causes. Design smaller comparisons or state that the trial evaluates the combined configuration rather than a single component.
Use the same intended application operations and observe downstream acceptance. A returned token or cookie does not show that the application consumed it successfully under the expected conditions.
Keep retry costs visible
An uncertain creation should not trigger automatic work through another route merely because the first response was lost. Record all admitted work associated with the intended operation and reconcile known IDs. Unknown states belong in the report.
Worker proxy instructions defines easycaptcha’s request fields. Proxy terminology explains vendor-label differences, and cohort design keeps a changed network population from being presented as evidence of a model improvement.
Frequently asked questions
Why distinguish the solver's network path from the application's?
They can vary independently and affect different stages. Record the path relevant to the operation instead of treating all traffic as one connection.
Does configuring a proxy automatically guarantee acceptance?
No. Match the documented task requirements and measure the actual verification outcome in your intended workflow.
How can easycaptcha fit into my integration tests?
Use the documented recognition or token API for the hCaptcha stage, preserve task IDs, and inspect terminal results. Measure verifier acceptance and application completion separately from job completion.