The workflow decision
For browser download workflows, the useful comparison is whether Notte or Steel can meet the following outcome: The application receives the complete expected file, verifies its content marker and associates it with the originating account and job.
A successful click does not establish that the download completed or that the file survives session cleanup. Browser profile persistence does not imply persistent downloaded files.
A proposed acceptance case
A signed-in job requests a report from a website and transfers the completed file to application storage. A download beginning is not the delivery outcome.
This is an evaluation design, not a claim that this workflow has been executed successfully on every provider.
| Part of the test | Required observation |
|---|---|
| Controlled input | A controlled report with a known filename, expected content marker and application-owned destination. |
| Pass condition | The application receives the complete expected file, verifies its content marker and associates it with the originating account and job. |
| Negative case | Close the browser before a deliberately delayed download completes. The job must detect the missing or partial artifact instead of reporting a delivered report. |
| Evidence to retain | Website report ID, file byte count, content verification and destination object reference. |
Documented mechanisms, side by side
These labels describe product mechanisms. The linked source and the acceptance case determine whether a mechanism meets this workflow's requirement.
| Requirement | Notte | Steel |
|---|---|---|
| Code execution | Python Functions | External worker |
| Scheduled execution | Native | External scheduler |
| Recordings / replay | Documented | Documented |
Sources: docs.notte.cc [1] ↗docs.notte.cc [2] ↗docs.steel.dev [3] ↗docs.steel.dev [4] ↗
Where the code runs
Notte: Functions deploy Python code with a run() entry point. Invoke them over HTTP or with an SDK, inspect run history, and roll back code by redeploying an earlier version as the latest version.
Steel: The reviewed browser documentation establishes sessions, profiles and credentials. It does not establish a hosted Python handler with deployment and invocation APIs. An external worker can control a Steel browser; price and operate that worker separately.
Deployment ownership
Notte: Use a remote browser from your existing process or deploy the browser automation as a Notte Function. These choices put lifecycle, scheduling and monitoring responsibilities in different places.
Steel: Compare managed Steel with the documented self-hosted path explicitly. Self-hosting gives the team infrastructure responsibility that a hosted browser subscription would otherwise cover.
Pricing model
Notte: The public usage rates are $0.01 per browser-hour, $0.05 per Function-hour and $10 per GB of managed proxy traffic. Paid plans return their price as usage credits. Price the relevant meters and plan eligibility for the workload.
Steel: Hosted browser plans and a self-hosted browser have different cost structures. For self-hosting, include the worker, compute, networking, storage and operations rather than assigning the open-source code a zero operating cost.
Sources: notte.cc [1] ↗docs.steel.dev [2] ↗
What should change the choice?
Notte belongs on the shortlist when saved account state and an executable browser workflow simplify the report job. Confirm the chosen file-transfer API and storage boundary in the current docs before moving the delivery step.
Steel: Steel's managed and self-hosted choices make infrastructure ownership a concrete deciding factor. Keep that option on the shortlist when operating the browser is intentional; evaluate Notte when owning fewer execution and authentication components is the actual goal.
A working download-to-storage pipeline is a reason to retain the current provider until an equivalent artifact path is demonstrated. Neither a replay nor a successful page navigation proves that a file arrived.
Sources: docs.notte.cc [1] ↗docs.notte.cc [2] ↗notte.cc [3] ↗docs.steel.dev [4] ↗docs.steel.dev [5] ↗docs.steel.dev [6] ↗
The cost boundary
Use the same attempted work and eligible account capacity in both estimates. The browser-hour rate does not include every proxy, execution or identity meter, and the cost of an incomplete job is still part of the workflow budget.
The workload evidence should include: Website report ID, file byte count, content verification and destination object reference.
Sources: notte.cc [1] ↗docs.steel.dev [2] ↗
Make a bounded pilot
Check download completion, file type, byte count and application access before stopping the session; verify retained results afterward.
Use the same authorized account, input and final-state check in each configuration. Treat a missing product contract as an open question; do not turn an undocumented capability into an unsupported claim or a successful test result.
- Separate website report generation from provider file retrieval in the current code.
- Keep the destination and content check unchanged while replacing the retrieval path.
- Test delayed and interrupted downloads before switching scheduled report delivery.