Skip to main content
Scrapestein is the graph-building agent inside the Scrapist editor. It can create a new graph or improve the currently selected graph. It works in an isolated draft until you approve the final save and activation.

​
Start A Session

1

Open Scrapestein

Open a graph in the editor, expand the right sidebar if needed, and select Scrapestein.
2

Choose the target

Select Improve this graph to start from the selected version, or Create a new graph to start with an empty draft.
3

Describe the complete behavior

Include the event source, matching rules, output actions, launch platforms, naming, images, fee sharing, and any important edge cases.
4

Choose a model and thinking level

Luna favors speed, Terra balances speed and complex planning, and Sol is intended for the most demanding work. A higher thinking level can use more AI credits.
5

Draft expected behavior

Click Draft expected behavior. Scrapestein begins with test events and expected side effects before changing a graph.
Scrapestein keeps your request and its replies in one conversation. The workflow sections appear in that conversation as work progresses, with generated examples and reviews placed beside the discussion that produced them.

​
Review Expected Behavior

Scrapestein proposes examples before it builds. Each example contains an input event and the side effects that should result.
  1. Expand every test.
  2. Check the author, post type, text, media, and other event fields.
  3. Check the number and details of expected launches, trades, trace notifications, or other effects. Test matching does not enforce effect order.
  4. Edit the test name, description, input event, or expected effects when needed.
  5. Add or remove tests until the contract covers both successful and rejected events.
  6. Click Confirm expected behavior.
This is the main behavior confirmation. Scrapestein may still ask a question when a missing detail would materially change the workflow.
Include negative tests. For example, if only one account should trigger a launch, add tests for a different account, a similar handle, a missing address, and an invalid address.

​
Follow The Build

After approval, the conversation progresses through these sections: You can send a correction at any point when the agent is waiting. While it is running, the send control becomes a stop button.

​
Approve The Final Graph

Scrapestein does not save or activate the finished draft without final approval.
  • For a new graph, the final action is Create and activate graph.
  • For an existing graph, the final action is Save new version and activate.
The approval applies only to the exact reviewed and tested draft. If that draft changes, Scrapestein must prepare a new final review.
Final approval can activate launch or trading actions. Verify exposed variables, wallets, buy amounts, fees, launchpads, and instance limits before approving.

​
Improve An Existing Graph

Select the graph and exact version in the resource controls before starting the session. Improve this graph uses that version as the baseline and saves successful work as a new version. The baseline remains available. If the selected graph changes while the session is open, Scrapestein will not silently apply an outdated draft. Reopen or restart the session against the version you want to change.

​
Resume Or Stop Work

Sessions are durable. Return to Scrapestein to reopen an earlier session and continue from its current step. The session list also shows its phase, model, and AI credits used.
  • Use the stop button to cancel the current run. Its conversation remains in the session list, but a cancelled run cannot continue.
  • A recoverable save or activation can be resumed without rebuilding the graph or repeating the same approval.
  • Delete a session when you no longer need its conversation or draft. Billing audit records remain.
AI credit use is shown below the conversation while a session is open. Start with clear behavior and concrete examples to reduce avoidable clarification and revision calls.

​
Write A Strong Request

State behavior, not canvas layout. A useful request includes:
  • The source event, such as a tweet, Truth Social post, Instagram post, story, profile change, or follow change.
  • Exact author and post-type matching rules.
  • How to select or validate addresses, names, tickers, and media.
  • Every action that should happen, including whether sibling actions are independent.
  • Exact launchpads and image styles when they matter.
  • Which settings should remain editable as exposed variables.
Example:
When elonmusk posts a valid Solana contract address in an original tweet, use the first valid address. Launch a Pump.fun coin named and ticked elon, use standard ASCII artwork, and send its fee share to that address. Also launch a Four.meme coin whose name and ticker are the first four address characters, using gold-on-black ASCII artwork. Expose only the settings needed to fund and submit both launches. Do nothing for other authors or posts without a valid address.
For an address-driven dual launch like this, review the contract and plan for these details:
  • Model an original post as TWEET with the exact author handle, body text, and image list. Decide explicitly whether replies, quotes, and retweets should also trigger.
  • Make every eligibility input affect the result. Compare the broken tweet’s Author Handle with elonmusk using ==, combine that result with Extract Solana Pubkeys > Matched? through And, and use the combined result to gate execution. Merely declaring an author_handle function input does not enforce the author rule if nothing reads it.
  • Treat the address as a Solana public key when it feeds Pump.fun Fee Share From Wallet. Connect it to the exact recipient input, which accepts one scalar string containing a valid Solana public key. Connect the node’s fee_share output to the Pump.fun launch. Do not connect the recipient address to the launch action’s wallet input; that wallet funds and signs the launch. Select the first valid public key when several appear, and include invalid, missing, and multiple-address tests.
  • The extracted address may be missing, so pass it through If Exists before either launch. Only send the unwrapped address to required launch inputs, and keep both launches off the execution path when no address exists.
  • Expect two launch effects from the same eligible event. Use the canonical platform IDs pump_fun for the Solana launch and four_meme for the BNB launch, with strict names and tickers where the request determines them.
  • An execution output connects to one next action. Chain the two impure launch-function calls on the eligible path instead of connecting one execution output to both calls. Do not place Await TX Response between them when the second launch does not depend on the first transaction’s confirmation.
  • Keep address selection and the derived four-character name or ticker in a pure function. Keep each launch responsibility focused in an impure function.
  • Treat ASCII and BNB_GOLD as graph-building requirements, not launch-effect fields. Require an image in the tests, then verify that the Pump.fun image path uses ASCII and the Four.meme path uses BNB_GOLD during graph review.
  • Make Pump.fun fee sharing Strict in the positive test and use that fixture’s concrete address with 10,000 basis points. See Testing for the assertion shape.

​
Cover The Address And Author Boundary

Use at least these scenarios for the example request: For every positive case, make the Pump.fun name and ticker exactly elon. Make the Four.meme name and ticker exactly the first four characters of the extracted address. Require an image for both effects, and inspect the graph to verify the renderer styles because launch effects do not record ASCII or BNB_GOLD. If the seven launch settings are still intentionally unset while Scrapestein tests the draft, every scenario should supply explicit test-only values for them. Test-only wallet, amount, tip, and Gwei values do not become the graph’s saved defaults.

​
Review The Seven Launch Settings

For this request, Scrapestein should present these required, fund-sensitive settings together during the Variables review: Each exposed setting needs its own Get Variable node connected to the matching function input. Declaring the variable without that getter does not use it. Review all seven values together before approving the draft. A Solana launch has no gas or Gwei input. Do not invent website, X, bundle, or suggest-only variables unless the request asks for them or the existing graph already uses them. See Events, Launch and action nodes, Pump.fun fee sharing, and Test automations for supported behavior.