What the agent does
This run has no repository. The agent starts in its own cloud computer with one connection: Semrush, connected once by the person who owns the API key, and named in the request's connections. Rush lists Semrush as a remote MCP server at mcp.semrush.com that is read only and spends that account's Semrush API units, so the run can look things up but cannot change anything in the Semrush account.
The agent reads the three domains from the prompt and pulls the same data for each one, so the comparison is like for like: monthly visit estimates for the last six months, the split of traffic by channel (direct, search, referral, social, paid and the rest, as Semrush reports them), and the top pages by estimated traffic. It keeps the raw numbers as it goes rather than retyping them later, which is where hand-built competitor spreadsheets usually go wrong.
Then it does the arithmetic and writes the report. For each domain it computes the month-over-month change and the six-month change, the share of each channel, and which of the top 10 pages gained or lost the most. It compares across domains, too: which competitor grew while the others were flat, whose growth came from search rather than paid, and which pages on a competitor's site are pulling traffic in a topic your site does not cover.
The output is one Markdown file, traffic.md, written in the sandbox and returned as an artifact on the session. Where Semrush has no estimate for a month or a domain, as can happen for small sites, the report says so in place instead of filling the gap.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Use the Semrush connection to read 6 months of traffic estimates, traffic channels and top pages for the domain and the two competitors named after this prompt. Write traffic.md comparing monthly visits, channel mix and the top 10 pages of each, and note the largest gains and drops.\n\nDomain: example.com\nCompetitors: competitor-one.com, competitor-two.com",
"connections": [
"semrush"
]
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
What comes back is traffic.md as an artifact on the session, with a download link that works for an hour; reading the session again gives a fresh one. It opens with a one-paragraph summary, then a monthly visits table with one column per domain, the channel mix for each domain as a table of shares, and the top 10 pages of each with their estimated traffic. A closing section lists the largest gains and drops, each with the page or channel responsible and the months it moved in.
Before acting on it, a reader checks two things. First, that the numbers are Semrush's estimates, not analytics from the sites themselves, so they compare domains well but will not match your own analytics exactly. Second, that every figure in the summary appears in a table below it; the agent writes the tables from the data it read, so a summary claim without a row is worth questioning.
The session's transcript keeps every Semrush call the agent made with its arguments and the data that came back. If a number looks wrong, that record shows whether it came from Semrush or from the agent's arithmetic.
Run it on every first of the month
Traffic estimates move monthly, so a monthly run is enough. Add an automation with a schedule trigger, such as the cron 0 9 1 * * with your timezone, and this prompt; each run reads the latest six months and writes a fresh traffic.md. Comparing two months' reports shows how the picture shifted.
From your own scheduler, send this request and set a webhook URL on the API key. When run.completed arrives, read the session from its session_url, take the traffic.md link from its artifacts and post it to the channel where the team discusses growth.
The use case this job follows, with its automation and trigger: Produce a report or file, no repo.
Why run it on Rush?
Assembling this by hand means exporting the same three reports for three domains, pasting them into one sheet and redoing it next month. On Rush one request does the reading and the arithmetic in the agent's own sandbox, and the transcript keeps every Semrush call and response, so the report comes with the data it was built from.
It needs no laptop, no repository and no one's afternoon. Runs for several competitor sets, or for each product line, start side by side, each with its own report, and the Semrush connection stays read only throughout.
Frequently asked questions
How does the run get access to Semrush?
The key's creator connects Semrush once through POST /me/connections and finishes the sign-in in a browser while signed in to the Rush console. A run started with the API key gets only the connections it names, so the request lists the connection in connections.
Does this use my Semrush API units?
Yes. The Semrush connection reads with the connected account and spends its API units, as Semrush meters them. Three domains over six months is a fixed set of lookups, so the cost per run is predictable from your Semrush plan.
Can the agent change anything in my Semrush account?
No. Rush lists the Semrush connection as read only: it can research keywords, competitors and traffic and read your projects, but not create or edit them.
Can I compare more than two competitors?
Yes. List more domains after the prompt and the agent reads the same data for each. The tables grow by one column per domain, and the API units the run spends grow with them.