Pick Your Agent's Web Tool With Evidence

Compare Apify and Exa for coverage, latency, and query cost.

Introduction

30 Second Summary

A recommendation can sound convincing when it comes with a brand name and a polished feature list. The real test is whether the tool finds the pages you need at a speed and price that work for you.

In this project, you will build an evidence-based comparison of Apify and Exa with five web queries that matter to you. You will use saved responses plus measurements for coverage, latency, and cost to choose the web tool for a short question-answering script.

What You'll Build

Your finished benchmark turns the same five questions into a side-by-side table where coverage gaps, response times, and per-query costs make the stronger tool visible.

By the end of this project, you'll have:

A repeatable benchmark that runs the same five queries through Apify and Exa before saving every raw response for inspection.
A side-by-side results table that shows coverage gaps, latency, and cost per query.
A working question-answering script that uses the service your evidence identifies as the winner.
Secret Mission: An optional challenge to push your evidence-based comparison skills further.

Are there any prerequisites?

You need a laptop with Python or Node. You also need free accounts for Apify and Exa.

Before We Start

Choosing a web tool from a vendor page leaves you with someone else's evidence. A fair comparison starts from one clean workspace with equal access to both services.

Apify and Exa rely on private API keys to authorize requests. In this step, you will create both accounts before securing each credential outside your project folder.

In this step, get ready to:

Create an empty local workspace for the comparison.
Create an Apify account with a securely stored API token.
Create an Exa account with a securely stored API key.

Create the comparison workspace

Your workspace gives every response a predictable home later in the project. Starting with an empty folder also makes it clear that no comparison evidence exists yet.

macOS

Click an empty area of your Desktop.
Press Shift+Cmd+N to create a folder.
Type web-tool-comparison as the folder name.
Press Return.
Confirm that the web-tool-comparison folder appears on your Desktop.

Windows

Press Windows+E to open File Explorer.
Select Desktop in the left sidebar.
Press Ctrl+Shift+N to create a folder.
Type web-tool-comparison as the folder name.
Press Enter.
Confirm that the web-tool-comparison folder appears on your Desktop.

The empty folder is your clean baseline. Every result added later can be traced to a comparison run.

Press Cmd+Space on macOS or the Windows key on Windows to open your app search.
Type Terminal into the search field.
Press Enter to open the terminal.

You'll see a terminal window ready for commands. Keep it available beside your empty workspace.

Folder or terminal missing?

Check that your file browser is showing the Desktop before creating the folder. Use your operating system's built-in command-line app if searching for Terminal returns no result.

Help me create the workspace and open a terminal on my computer.

Create and secure your Apify token

An Apify API token grants programmatic access to your account. A project-specific token keeps this comparison separate from your other work.

Open the official Apify Console sign-up page in your browser.
Authenticate with your preferred method so the Apify Dashboard opens.
Complete any account verification that Apify requests.
Select Settings in the left panel.
Select API & Integrations.
Find the Personal API tokens section.
Select + Create a new token.
Use web-tool-comparison as the token description.

Copying a live credential can feel risky. This token goes straight into secure storage without entering the comparison folder.

Finish creating the personal token.
Copy the new token when Apify displays it.
Create an entry named APIFY_TOKEN in your password manager.
Paste the token into the secure entry.
Save the secure entry.
Return to the Personal API tokens section.
Confirm that the web-tool-comparison token is listed.

Why keep the token outside the workspace?

Project folders can later be copied or committed to version control. Keeping the token in secure storage prevents the credential from travelling with your comparison files.

Your Apify access is ready. The dashboard holds the active token while your password manager protects its value.

Cannot access your Apify token?

Finish any pending email verification before returning to the dashboard. Check that you are inside your personal account when looking for the token settings.

Help me find my Apify token settings without exposing the credential.

Create and secure your Exa key

Exa uses its own credential for search requests. Saving it under Exa's supported environment name makes the key easy to identify when you connect the comparison script.

Open the official Exa API Keys page in your browser.
Authenticate with Google or email so the Exa Dashboard opens.
Complete any account verification that Exa requests.
Return to the API Keys page after authentication.
Use the key-creation control on the page to create an API key.
Use web-tool-comparison as the key name if Exa asks for one.

This credential deserves the same care as your Apify token. Keep the value away from screenshots or project files while you store it.

Copy the new key when Exa displays it.
Create an entry named EXA_API_KEY in your password manager.
Paste the key into the secure entry.
Save the secure entry.
Return to the API Keys page.
Confirm that your new key is listed.

Why use these credential names?

APIFY_TOKEN is Apify's supported environment variable name. EXA_API_KEY is Exa's supported environment variable name.

Matching those names in secure storage reduces guesswork when you connect each service later.

Cannot create an Exa key?

Confirm that authentication finished before returning to the API Keys page. If you belong to an existing team, ask its administrator for the required invite.

Help me create an Exa key without exposing the credential.

Before you check, what evidence should prove that your workspace is clean while both services are ready?

Return to the Desktop in Finder or File Explorer.
Open the web-tool-comparison folder.
Confirm that the folder contains no files.
Switch back to the terminal window from earlier.
Confirm that the terminal is available for the next step.
Open your password manager.
Confirm that an entry named APIFY_TOKEN exists.
Confirm that an entry named EXA_API_KEY exists.

Your local setup is ready. The empty folder confirms that no queries or comparison records have been created.

Return to the Apify Dashboard.
Confirm that the project token remains listed.
Return to the Exa API Keys page.
Confirm that the project key remains listed.

You'll now have an empty comparison workspace with a terminal ready beside it. Both dashboards remain accessible without exposing either credential.

That is the sensitive setup handled: both credentials are protected while your workspace stays clean. Next, you'll run one query through each service to inspect the raw result shapes.

Inspect Both Tools' Raw Results

A fair web-tool choice starts with evidence from the same input. Separate demo queries would blur the comparison.

Your accounts are active. Your credentials are available securely.

You will send one exploratory query to Apify and Exa. Their raw JSON responses reveal the parsing work each service creates.

In this step, get ready to:

Send one exploratory query to Apify.
Send the identical query to Exa.
Compare the top-level response shapes.

Run the exploratory query with Apify

Apify runs web jobs as Actors. The synchronous endpoint waits for the Actor to finish before returning its dataset items.

Keep This First Test Controlled

Both requests can consume account credits. This step limits the run to one query per service.

The Apify request can sit quietly for a few minutes while its Actor finishes. The synchronous endpoint returns the response when the run completes.

Before you run this, do you expect the response to be a flat list or a nested payload?

Return to the terminal session from earlier.
Use your existing secret-loading method to expose the Apify key as APIFY_TOKEN.
Send Latest research in LLMs to Apify by running this request:

curl -X POST 'https://api.apify.com/v2/actors/apify~google-search-scraper/run-sync-get-dataset-items' \
  -H "Authorization: Bearer $APIFY_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"queries":"Latest research in LLMs","maxPagesPerQuery":1}'

What Does This Request Do?

The POST request starts the Google Search Results Scraper Actor.
The synchronous endpoint returns the default dataset items in the response.
The APIFY_TOKEN environment variable authenticates the request without placing the key value in the command.
The maxPagesPerQuery value keeps the run to one search-results page.

Wait for the request to finish.
Confirm the terminal prints a raw JSON payload containing search results.

Your first live payload is here. Apify answered your exact test query.

Apify Did Not Return Results?

Confirm your existing secret-loading method exposed APIFY_TOKEN in this terminal session.
Check the Apify dashboard from earlier to confirm whether the Actor run is still active.
Copy the request again if the terminal reports a malformed command.

Help me troubleshoot this Apify request.

Run the same query with Exa

Exa exposes a search endpoint with its own response envelope. The query text stays identical for a fair comparison.

Before you run this, do you think Exa will wrap its search hits the same way as Apify?

Use your existing secret-loading method to expose the Exa key as EXA_API_KEY.
Send Latest research in LLMs to Exa by running this request:

curl -X POST 'https://api.exa.ai/search' \
  -H "x-api-key: $EXA_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"query":"Latest research in LLMs"}'

What Does This Request Do?

The POST request sends the query to Exa's search endpoint.
The EXA_API_KEY environment variable supplies the credential through the x-api-key header.
The request body sends the same query text used for Apify.
Exa returns the unmodified API response directly to the terminal.

Wait for the request to finish.
Confirm the terminal prints a second raw JSON payload containing search results.

The second live payload is in place. Both services have now received the same query text.

Exa Did Not Return Results?

Confirm your existing secret-loading method exposed EXA_API_KEY in this terminal session.
Copy the request again if the terminal reports invalid JSON.
Check your Exa dashboard from earlier to confirm whether the request reached your account.

Help me troubleshoot this Exa request.

Compare the response shapes

A response shape determines how much parsing an agent needs before it can use a result. The raw payloads let you inspect that structure without assumptions.

Before you compare the first characters, do you expect both services to wrap their result lists the same way?

Scroll back to the first character of the Apify response in your terminal.
Identify whether the Apify response begins with [ or {.
Scroll to the first character of the Exa response.
Identify whether the Exa response begins with [ or {.
Compare where each response stores its individual search hits.

You will see the Apify response begin with [ because its top-level value is an array. Each page item contains searchQuery plus nested organicResults.

You will see the Exa response begin with { because its top-level value is an object. Its search hits live under results.

Why Does the Shape Matter?

An Apify parser reaches into each page item before iterating through organicResults. That structure preserves search-page context around the individual links.

An Exa parser starts from the results array inside a request-level object. Fields such as requestId sit beside the result list.

The commands reference environment variable names. Your actual key values stay out of the response output.

You can now read both payloads without guessing. Next, you will choose five queries from your own domain. Those queries become your benchmark evidence set.

Run and Save Your Five Queries

You have already inspected one raw response from Apify. You also inspected one raw response from Exa.

A useful benchmark needs questions that match your agent's real research work. Fixed wording keeps the comparison fair across both services.

In this step, get ready to:

Document five queries that represent your agent's web research needs.
Run the same five queries through Apify.
Run the same five queries through Exa.

Choose five real research queries

Your query set defines what this comparison can prove. Choose questions that your agent genuinely needs to answer.

What makes a useful query set?

Each query should represent a real research need from your work. A realistic set gives you evidence that applies to your own agent.

Write each query as a complete search request. You use that exact wording for both services.

Switch back to the local comparison workspace from your exploratory run.
Create a file named benchmark-queries.txt inside the comparison folder by using the new-file control in the workspace file sidebar.

You should see benchmark-queries.txt in the file sidebar.

Write five numbered queries in benchmark-queries.txt.
Save benchmark-queries.txt.
Count the numbered lines to confirm the file contains exactly five queries.

Good work. Your benchmark now has a fixed input set that keeps the provider comparison fair.

Why fixed wording matters

A wording change can alter the result set. Keeping each query identical isolates the provider as the main difference.

Run and save the Apify responses

Each untouched JSON payload becomes evidence for one benchmark query. The filename connects that payload to its service plus its query number.

Return to the Apify request flow from your exploratory run.
Create a folder named responses inside the comparison folder by using the new-folder control in the workspace file sidebar.
Submit the first query from benchmark-queries.txt to Apify.
Save the complete raw result as responses/apify-query-1.json.
Submit the second query from benchmark-queries.txt to Apify.
Save the complete raw result as responses/apify-query-2.json.
Submit the third query from benchmark-queries.txt to Apify.
Save the complete raw result as responses/apify-query-3.json.

Three Apify Responses Saved

Your first three Apify payloads now have numbered filenames. Those numbers point back to the matching lines in benchmark-queries.txt.

Submit the fourth query from benchmark-queries.txt to Apify.
Save the complete raw result as responses/apify-query-4.json.
Submit the fifth query from benchmark-queries.txt to Apify.
Save the complete raw result as responses/apify-query-5.json.
Expand the responses folder in the workspace file sidebar.

You should see five Apify files. Their names should run from apify-query-1.json through apify-query-5.json.

You are halfway there. Five untouched Apify payloads now map back to your documented query set.

Run the Exa queries and verify the evidence set

Exa must receive the same five inputs in the same order. Matching query numbers let you compare each pair later without guessing.

Return to the Exa request flow from your exploratory run.
Submit the first query from benchmark-queries.txt to Exa.
Save the complete raw result as responses/exa-query-1.json.
Submit the second query from benchmark-queries.txt to Exa.
Save the complete raw result as responses/exa-query-2.json.
Submit the third query from benchmark-queries.txt to Exa.
Save the complete raw result as responses/exa-query-3.json.

Three Exa Responses Saved

You now have three matched response pairs. Each pair shares one query number across both service filenames.

Submit the fourth query from benchmark-queries.txt to Exa.
Save the complete raw result as responses/exa-query-4.json.
Submit the fifth query from benchmark-queries.txt to Exa.
Save the complete raw result as responses/exa-query-5.json.

Before you inspect the workspace, how many query lines do you expect? How many raw response files should sit beside them?

Return to the workspace file sidebar.
Open benchmark-queries.txt.
Count the numbered query lines.
Expand the responses folder.
Count the raw response files.
Open each response file once to confirm it contains a complete raw payload.

You should see five numbered lines in benchmark-queries.txt.

Under responses, you should see apify-query-1.json through apify-query-5.json.

You should also see exa-query-1.json through exa-query-5.json.

Missing a response file?

A missing file leaves a gap in the evidence set. An empty file also leaves a gap.

Match the missing filename to its service prefix.
Match the missing filename to its query number.
Rerun that numbered query through the matching service.
Replace the missing or empty file with the complete raw response.

Help me check why my saved benchmark response is missing or empty.

Your screenshot only needs to prove that the evidence files exist. Keep credentials outside the captured area.

Hide every terminal pane or file that could show an API key.

Your benchmark evidence set is complete. Next, you'll measure how long each service takes to answer the same five queries.

Measure Request Latency

Your five-query evidence set already shows what each provider returns. Your choice now needs another signal: the time each identical request takes to finish.

Request latency is the elapsed time from sending a call until its complete response arrives. You will measure every Apify call with one timing boundary.

You will apply the same boundary to every Exa call. This gives you ten comparable measurements.

In this step, get ready to:

Prepare one latency record for the five benchmark queries.
Capture elapsed seconds for all ten service calls.
Verify each timing remains tied to its benchmark query.

Set up the latency record

A shared record keeps each timing beside the query that produced it. Each row represents one identical comparison between the two services.

Return to the comparison workspace from earlier.
Add a latency section containing five query rows plus separate elapsed-seconds fields for Apify plus Exa.

You should see one row for every documented query. Each row should have two empty timing fields.

Save your documented benchmark evidence set.

What Counts as Elapsed Time?

Elapsed time begins when a request is sent. It ends when the complete response arrives.

The same boundary keeps the two services comparable for this benchmark run.

Time all ten requests

Latency can shift between calls. A consistent process gives every provider the same test conditions.

The ten saved raw responses remain your content evidence. Your new latency record captures the timing evidence separately.

Open a stopwatch on your phone.
Select the first documented query in your benchmark evidence set.
Reset the stopwatch to zero.
Start the stopwatch.
Immediately rerun the existing Apify request with the query text unchanged.
Stop the stopwatch when the complete Apify response arrives.
Record the displayed seconds in the Apify field for the selected query.

The first row now contains an Apify timing tied to the exact query you sent.

Reset the stopwatch to zero.
Start the stopwatch.
Immediately rerun the existing Exa request with the same unchanged query.
Stop the stopwatch when the complete Exa response arrives.
Record the displayed seconds in the Exa field for the selected query.

That first pair establishes the timing pattern for the remaining four queries.

Keeping one query pair together reduces the chance of attaching a timing to the wrong request.

Move to the second documented query.
Repeat the Apify timing sequence for the selected query.
Repeat the Exa timing sequence for the selected query.
Record both elapsed values in the matching query row.
Continue the same query-by-query sequence through the fifth query.
Save your completed latency record.

That careful pass gives every query a fair timing pair.

A Timing Looks Wrong?

An unusually large value can come from starting too early or stopping after extra work. A failed request does not produce a completed-call latency.

Rerun the affected query with its text unchanged.
Replace only the affected timing with the successful call's elapsed seconds.

Help me diagnose an inconsistent latency measurement in my Apify and Exa benchmark.

Check the latency evidence

A complete latency record proves that both services received equal coverage. It also keeps each result traceable to its original query.

Before you inspect the completed record, which provider do you expect to be faster across most queries?

Count the populated Apify elapsed-seconds fields.
Count the populated Exa elapsed-seconds fields.
Match each timing pair to its documented benchmark query.
Confirm every recorded timing uses seconds.
Confirm the five saved Apify responses remain in the comparison workspace.
Confirm the five saved Exa responses remain in the comparison workspace.
Save the final latency record.

You should see five Apify measurements. You should also see five Exa measurements.

Each measurement should sit beside the benchmark query that produced it.

Your latency evidence is complete. Every provider call now has an elapsed-seconds value that someone else can trace back to the query.

Your comparison now has a traceable latency snapshot for all ten calls. Next, you will record dashboard consumption so cost can join the evidence.

Calculate Cost Per Query

Your benchmark now has ten saved responses plus latency measurements for every call from Apify and Exa. You can already compare speed against coverage.

Dashboard consumption gives you the cost evidence for those same runs. This step isolates five calls per service so unrelated account activity cannot distort your cost per query.

In this step, get ready to:

Isolate the five benchmark calls in each service dashboard.
Record the usage consumed by both benchmark sets.
Calculate a comparable cost per query for each service.

Attribute Apify benchmark usage

Your Apify account activity can include the exploratory request from earlier. The cost record needs to represent only the five calls in your documented benchmark set.

Attributing usage can feel fiddly when several requests sit close together. Your five saved Apify responses give you a fixed count to match.

Return to the Apify dashboard from earlier.
Navigate to the account area that reports usage for recent calls.
Limit the displayed period to the session when you ran the five benchmark queries.
Identify the five calls that correspond to your documented query set.
Exclude the earlier exploratory call from the benchmark total.
Record the total consumption exactly as the dashboard reports it: your Apify benchmark usage.
Determine the monetary equivalent using the current plan conversion shown in the dashboard.
Record the resulting amount with its currency: your Apify benchmark cost.

That is the first cost trail pinned down. Your Apify record now traces exactly five benchmark calls from usage to monetary cost.

Cannot isolate five Apify calls?

Narrow the displayed period around the benchmark session.
Compare the activity order with your five saved Apify responses.
Remove any entry associated with the exploratory query from your total.

Ask for help if the dashboard totals still include unrelated activity: help me isolate five benchmark calls in my Apify usage record.

Attribute Exa benchmark usage

The Exa cost record needs the same five-query boundary. A shared request count keeps the comparison tied to identical work.

Return to the Exa dashboard from earlier.
Navigate to the account area that reports usage for recent calls.
Limit the displayed period to the session when you ran the five benchmark queries.
Identify the five calls that correspond to your documented query set.
Exclude the earlier exploratory call from the benchmark total.
Record the total consumption exactly as the dashboard reports it: your Exa benchmark usage.
Determine the monetary equivalent using the current plan conversion shown in the dashboard.
Record the resulting amount with its currency: your Exa benchmark cost.

You now have a matching cost trail for Exa. Both services have five attributed calls plus their original usage units.

Cannot match the Exa total?

Reduce the displayed period to the benchmark session.
Compare the activity count with your five saved Exa responses.
Check that the exploratory query remains outside the total.

Ask for help if the five-call total remains unclear: help me match my Exa dashboard usage to five benchmark calls.

Calculate cost per query

The cost per query is the total monetary benchmark cost divided by the number of benchmark calls. Each service has the same denominator of five.

Why use the benchmark total?

The dashboard total captures the consumption produced under your account plan. Dividing that total by five produces an average that can sit beside your latency results.

Keep the original usage unit next to the monetary value. That source trail lets another person check your calculation.

Calculate the Apify cost per query by dividing your Apify benchmark cost by 5 in a calculator.
Record the quotient with its currency: your Apify cost per query.
Calculate the Exa cost per query by dividing your Exa benchmark cost by 5 in a calculator.
Record the quotient with its currency: your Exa cost per query.
Save the completed usage and cost record in your existing comparison workspace.

Before you compare the two quotients, which service do you expect to have the lower average cost per query?

Compare your Apify cost per query with your Exa cost per query.
Verify the Apify calculation by multiplying your Apify cost per query by 5 in a calculator.
Verify the Exa calculation by multiplying your Exa cost per query by 5 in a calculator.

One per-query value should be lower unless both are equal at the precision you recorded. Each reverse calculation should recover its original benchmark cost apart from rounding in the final displayed decimal place.

Do the totals fail the reverse check?

Confirm that each calculation uses a denominator of 5.
Check that each service uses its own benchmark total.
Repeat the calculation with the unrounded quotient.

Ask for help if the arithmetic still does not reconcile: help me check my cost-per-query calculations.

Your cost evidence is complete. Next, you can place cost beside coverage plus latency to make the final tool choice.

Choose and Wire Your Winner

Ten saved responses now capture what Apify plus Exa returned. Latency records plus cost calculations complete your evidence set.

Scattered evidence makes a decision hard to audit. A side-by-side table makes every trade-off visible.

You will use that table to select a winner. A short script will prove your chosen tool can answer a real question.

In this step, get ready to:

Build a comparison table covering all five benchmark queries.
Choose a winning service from your recorded evidence.
Wire the winner into a script that answers a question.

Build the comparison table

Coverage shows whether a response contains the information your query needed. A missed result names a useful item that the service failed to return.

What counts as a miss?

Record a miss when the saved response omits a result that matters to the query. Name the missing result clearly enough for another person to verify it against the raw response.

Keep subjective preferences out of this field. Your notes should point to visible evidence.

Return to the part of your comparison workspace that holds the documented query set.
Create a table with columns for Query, Apify coverage, Apify missed results, Apify latency, Apify cost per query, Exa coverage, Exa missed results, Exa latency, Exa cost per query, and Winner.
Add one row for each of your five documented queries.

You should now see five query rows with matching evidence columns for both services.

Fill the Apify coverage cells from the five saved Apify responses.
Fill the Apify missed results cells from the same responses.

Each row should now show what Apify covered plus any useful result it missed.

Fill the Exa coverage cells from the five saved Exa responses.
Fill the Exa missed results cells from the same responses.

Each row should now show the same coverage analysis for Exa.

Copy all ten elapsed-second values into their matching latency cells.
Copy each service's calculated cost per query into its matching cost cells.

Every query row should now contain coverage, missed results, latency, plus cost per query for both services.

Preserve the raw evidence

Your table summarizes the benchmark. The ten raw response files remain unchanged so another person can inspect every claim.

Choose the winner

A defensible decision reflects the needs of your agent. Your preferred balance of coverage, latency, plus cost determines which differences matter most.

Write your most important decision priority above the comparison table.
Mark the better service in the Winner cell for each query row.

The Winner column should now reveal where each service performed better against your priority.

Write the overall winning service below the table.
Add a short rationale that cites specific coverage, missed-result, latency, plus cost evidence.

Your decision should now be traceable from the overall winner back to individual query rows.

Add one limitation that describes where the other service performed better.

Why record a limitation?

A limitation shows that you considered the full table. It also tells a future reader when the other service could become the stronger choice.

Wire the winning service

The table supports your choice. A working API call proves that choice can serve a real agent workflow.

What does the script need to prove?

The script has one job. It sends a question to your winning service through the request pattern you already tested.

Accept one question at run time.
Load the winning service's credential from your existing secure source.
Send the question through the winning service.
Print useful answer content from the returned response.

Choose a filename that matches your benchmark language: winner_answer.py or winner_answer.js.
Create winner_answer.py or winner_answer.js inside your existing comparison workspace with its file editor.

You should now see the new script beside your benchmark evidence.

The script uses your live service credential. Its value stays in the secure source that already protected it during the benchmark.

Move the working request logic from the winning service's exploratory call into winner_answer.py or winner_answer.js.
Point the credential lookup at the same secure source used during the benchmark.

Before the first run, what response shape do you expect from the winning service? Hold that prediction for the result.

Execute winner_answer.py or winner_answer.js with the same run method used for your benchmark.

You should see a raw response from the winning service. That proves the request logic plus secure credential source work inside the new script.

Save winner_answer.py or winner_answer.js with the fixed exploratory query replaced by question input.
Save the script with its printed output narrowed to useful answer content from the response.

The next run asks for one question. Before you run it, what useful answer do you expect from your chosen query? Keep that expectation in mind.

Execute winner_answer.py or winner_answer.js with the same run method.
Provide one of your five documented benchmark queries when the script requests a question.

You should see useful result content that answers the question through your winning service. Your credential value should remain absent from the script plus terminal output.

Script not returning an answer?

Confirm that the request logic belongs to the service marked as your overall winner. Check that the secure credential source remains available to the script.

If the response arrives without useful output, compare your extraction logic with the raw response shape from the successful first run.

Help me debug my winner-answer script without exposing my API key.

That is the decision proven. You now have a comparison table anyone can audit plus a working script that uses the service your own evidence selected.

Secret mission

Pressure-Test Your Web Tool Choice

Change the priority behind your score. Then rerun the winner on its weakest query to find the boundary of your recommendation.

Clean Up Your Resources

Choose what to keep from this benchmark before you move on. Only future API calls can consume credits or incur charges.

Resources you used:

The local comparison workspace folder containing your benchmark evidence and winner-answer script.
The active Apify API key stored securely outside the project files.
The active Exa API key stored securely outside the project files.

Keep everything running

No action is needed. Choose this option if you plan to rerun the benchmark or refine the winner-answer script.

Keep the comparison workspace unchanged so its raw responses remain available as evidence.
Keep both API keys stored securely outside the project files.
Run future API calls only when you want fresh benchmark data.

Pause - I'll come back to this later

Preserve the evidence while removing access for the service you did not select. The winner-answer script stays ready for your next session.

Use your completed comparison table to identify the service you did not select.
Use the API credential controls in that service's dashboard from earlier to revoke the unused key.
Confirm the dashboard no longer shows the unused key as active.
Keep the winning service's key stored securely outside the project files.

Your ten raw responses remain available locally. Your comparison table and winner-answer script remain available too.

Delete - I don't want to use this again

Remove the local evidence and revoke both service keys. Choose this only if you no longer need to reproduce the comparison.

Deletion Is Permanent

Deleting the comparison workspace removes all ten raw responses and the completed evidence table.

Revoking both API keys prevents the winner-answer script from making another request until you add a new key.

This cleanup is intentionally final. Your Apify and Exa accounts remain available for a future benchmark.

Delete the comparison workspace folder:

macOS

Your file browser gives you a visible way to remove the workspace without guessing its path.

Use the file browser to locate the comparison workspace folder from earlier.
Select the comparison workspace folder.
Move the selected folder to Trash using the file browser's delete control.
Open Trash in the file browser.
Review the contents of Trash for unrelated files you want to keep.
Empty Trash to permanently delete the comparison workspace folder.

Windows

Your file browser gives you a visible way to remove the workspace without guessing its path.

Use the file browser to locate the comparison workspace folder from earlier.
Select the comparison workspace folder.
Move the selected folder to the Recycle Bin using the file browser's delete control.
Open the Recycle Bin in the file browser.
Review the contents of the Recycle Bin for unrelated files you want to keep.
Empty the Recycle Bin to permanently delete the comparison workspace folder.

Revoke both API keys:

Use the API credential controls in the Apify dashboard from earlier to revoke the active Apify API key.
Confirm the Apify dashboard no longer shows that key as active.
Use the API credential controls in the Exa dashboard from earlier to revoke the active Exa API key.
Confirm the Exa dashboard no longer shows that key as active.

That closes the benchmark cleanly. Neither saved evidence nor active credentials remain.

Nice Work!

Strong work. You built an evidence-backed web-tool benchmark that compares Apify with Exa on queries from your own domain.

You've learned how to:

Run the same five queries through Apify and Exa. Save all ten raw responses as evidence that someone else can inspect.
Measure latency for every call. Calculate cost per query from dashboard usage.
Turn coverage gaps into a comparison table that marks missed results. Use that evidence to select a winner. Configure a short question-answering script with the winning service.
Secret Mission: Apply your evidence-first approach in an optional challenge that pushes your evaluation skills further.

Your saved evidence makes the winning choice easy to explain. It also gives you a benchmark you can reproduce when either service changes.

Ready to quiz yourself?