Order Sidera project memory through x402

Send supported LLM session logs as one tar.zst archive. Sidera measures the original JSONL bytes and assesses the processing work, returns the exact price and approximate processing time, and requests payment only after you review that measured quote.

The delivered files are memory.md and losslessly compressed original logs raw.tar.zst. Use the agent usage guide to search the memory and follow its source references.

For the purchase decision, read the Sidera batch vs. GPT-6 Astra cost argument: a sourced, step-by-step calculation covering local preprocessing, artifact generation, consistency checks, consolidation, caching and Batch/Flex rates.

The public API base is:

https://shadowharness.com

Run the complete purchase with the Node.js client

Use the downloadable purchase client and its installation and wallet guide with Node.js 22.23.1 or newer. It prepares the archive locally and keeps the free estimate, order, formal quote, payment attempt and delivery in one private state file. The LLM can prepare the logs and obtain the formal quote, the user approves payment with an existing wallet, and the LLM resumes to receive the files. This flow works without giving the LLM wallet-signing access.

After downloading the bundle and running npm ci --ignore-scripts, choose the project sessions using step 0 below. Pass each chosen file explicitly, or a directory whose complete contents you intend to send:

node sidera-client.mjs prepare --state ../sidera-private/order.json --codex /path/to/project/first-session.jsonl --codex /path/to/project/later-session.jsonl

Review the exact archive contents before sending them. This reads the local input manifest and prints only selected paths, sources, sizes and conversation counts:

node -e "const fs=require('node:fs');const m=JSON.parse(fs.readFileSync(process.argv[1],'utf8').replace(/^\uFEFF/,''));console.table(m.files.map(f=>({source:f.source,originalPath:f.originalPath,archivePath:f.archivePath,bytes:f.bytes,userRecords:f.userRecords,assistantRecords:f.assistantRecords})));console.log({files:m.files.length,originalBytes:m.totalOriginalBytes,conversationRecords:m.totalConversationRecords});" ../sidera-private/order.input-manifest.json

Confirm that these are the intended sessions. The LLM then obtains the estimate, creates and uploads the order, and requests the unsigned payment challenge:

node sidera-client.mjs estimate --state ../sidera-private/order.json
node sidera-client.mjs submit --state ../sidera-private/order.json --email buyer@example.com
node sidera-client.mjs pay --state ../sidera-private/order.json

prepare checks each selected native log and creates one tar.zst archive plus an input manifest. You can combine --claude, --codex, --grok and --gemini, or pass an existing supported raw/ directory. estimate obtains and saves estimate_id; submit uses that same estimate to create one order, upload and print the formal price, adjustment reason, approximate duration, expiry and quote hash. Email is required only for creation; --email-file can read it from a private file.

pay with only --state is an unsigned quote review. It requires no wallet or signer and sends no payment. The LLM presents the returned orderId, finalUSDC, quoteHash, expiresAt, network and recipient to the user, along with any price change, adjustment reason and approximate processing time. Include the local state path and the approval command below; keep request keys, order tokens and signatures in the private state file.

The user approves payment. On the same machine and in the installed client directory, the user uses that same private state file, connects an existing wallet through the local signer module or existing-wallet RPC adapter, and executes the approved payment command. The README supplies the signer interface and RPC configuration. Review the formal amount and expiry before approving.

In the following command, 0.02 is only an example cap. Replace it with the formal USDC amount the user approves, replace QUOTE_HASH_FROM_PAY_OUTPUT with the displayed quoteHash, and use the user's existing signer module path. For example, a formal quote of 0.030000 requires an approved cap of 0.03, rather than the example 0.02:

node sidera-client.mjs pay --state ../sidera-private/order.json --max-usdc 0.02 --approve-quote QUOTE_HASH_FROM_PAY_OUTPUT --signer-module /absolute/path/to/existing-wallet-signer.mjs

After the user's payment command, the LLM continues with the same state to check processing, verify both files and acknowledge delivery:

node sidera-client.mjs resume --state ../sidera-private/order.json --wait --output ../sidera-private/delivery

The client uses Base USDC, checks quote changes, amount, expiry and signature terms, and signs and sends payment once. resume checks progress, downloads and verifies both files by size and SHA-256, then acknowledges delivery. Keep the same private state after interruptions; it prevents parallel or repeated payment attempts. It never creates a wallet or key. The HTTP interface also supports Polygon and Solana for other x402 clients.

For direct HTTP integration, use the steps below and the complete OpenAPI. Discovery links the current guides and client.

Data handling

Existing conversation records. Sidera processes the raw logs you choose to upload from past conversations with LLM tools. It organizes the existing record of those interactions into reusable memory. Personal information in the logs is used only to produce and deliver your order and to provide the recovery described below.

Partial use of U.S. models. Some structuring steps use models developed by U.S. companies (excluding xAI). Text needed for these steps is sent to their AI APIs for processing with model-training use disabled.

Isolation and access. Each order runs in an isolated container. Uploads and downloads use HTTPS, and access to your order data and completed files requires your private order token. Other customers cannot access your order.

Retention and recovery. Download and acknowledge within 24 hours after processing completes. The used worker is deleted after delivery acknowledgement or at the end of that window, once the deliverables have been verified for recovery. Recovery data is kept for seven days and then permanently deleted. Recovery requires an email from the same address used for the order and the exact order ID. The delivery and cancellation sections below describe recovery requests and deletion of unpaid orders.

0. Locate and select your logs

On macOS, Windows or Linux, use an agent with local file and shell access. Check the CLI's actual storage settings first; common starting locations are below. ~ means your user home directory (normally /Users/<you> on macOS or %USERPROFILE% on Windows).

Start with the project and the history you want to recover. Inspect candidate sessions' recorded project or working directory, timestamps and conversation text with your local file tools. Match their content to the requested project; a storage directory or filename alone does not establish that match. For a question about a current decision, include its earlier reasoning and later corrections or unfinished work when present.

Pass the selected whole session files individually using repeated source flags, such as --codex first.jsonl --codex later.jsonl; combine flags for different CLIs. A directory flag recursively includes every .jsonl file beneath it. It does not filter by project, date or topic. Use a directory only when you have checked all of its sessions. prepare runs locally without HTTP, uploading or payment; it validates the supported format and conversation text and records the exact selection in the private input manifest. Its validation does not decide which project's history you intended.

Read the manifest using the command above and compare each originalPath, source, size and conversation count with your intended selection before submit. If the selection needs changing, leave the originals unchanged and run prepare with the corrected files and a new private --state path. Keep an existing order's state for recovery.

Use full session logs, not a prompt-only history.jsonl or CLI settings and credentials. For manual archive preparation, copy the selected files without editing their contents into the layout below; if originals share a filename, name each copy with its unique session ID. Other formats do not become supported JSONL by changing the extension.

Codex response_item-only files are outside this input format. The client's prepare command stops before creating an order if any selected file has no supported conversation text. Choose complete native logs rather than exporting only another record layer.

The byte total is enough for a free estimate before upload or compression. Use GET, with bytes in the URL query set to the selected original JSONL byte total (totalOriginalBytes in the prepared manifest), rather than the compressed archive size. This operation does not accept POST or a JSON request body. Save the returned UUID estimate_id and use it when creating the order. The estimate does not reserve capacity or determine the final bill:

GET https://shadowharness.com/v1/quote?bytes=100000000

Replace 100000000 with the measured original byte total. After a successful GET, follow the response's next_action method, URL and required fields, carrying estimate_id into creation. If a request returns HTTP 400 or 405, read the error and the latest discovery/quote next_action, correct the method and required values, and then continue. Do not repeat the same failing request or guess another POST for the quote operation. The client estimate command performs the GET and carries the saved estimate forward.

Storage references: Claude Code, Codex configuration, Gemini CLI.

1. Prepare one input archive

Put 1–10,000 original JSONL session files under the matching source directory:

raw/claude/<session>.jsonl
raw/ext-codex/<session>.jsonl
raw/ext-grok/<session>.jsonl
raw/ext-gemini/<session>.jsonl

Combine all selected sessions into one tar.zst file: a tar archive compressed with Zstandard. From the directory containing raw/, create it and check its file list:

tar --zstd -cf input.tar.zst raw
tar -tf input.tar.zst

Check compression support before creating an order. No additional installation is needed if your existing tar supports Zstandard. GNU tar uses the zstd executable; a bsdtar build with libzstd can compress directly. If your environment lacks that support, a Zstandard-capable tool is required. See the GNU tar compression documentation.

On macOS, Finder's Compress action creates ZIP, which is not accepted. The system tar may need an external zstd command. If it is missing and you already use Homebrew, brew install zstd provides it. Use this macOS command to omit Finder metadata, then check the file list with tar -tf input.tar.zst:

COPYFILE_DISABLE=1 tar --zstd --exclude='.DS_Store' --exclude='._*' -cf input.tar.zst raw

ZIP files, multiple archives, links, sparse files and other paths are not accepted. Each filename must start with an ASCII letter or digit, contain only letters, digits, _, ., or -, and end in .jsonl.

You may replace personal or confidential information with dummy text or numbers before uploading. Preserve the supported CLI log structure and field formats.

Standard prices assume typical session logs. Logs that require more work to interpret content and organize decisions, changes and their relationships may receive a higher quote. If you edit logs before uploading, the quote is assessed from the submitted content; removing material does not guarantee a proportionally lower price. Review the final amount before paying. It is fixed when you pay.

2. Create a private order

Generate a secret random request_key with at least 128 bits of entropy, encoded as 32–128 URL-safe letters, digits, _, or -. Keep it private. Send it with the email address that should receive the order confirmation:

POST https://shadowharness.com/v1/orders
Content-Type: application/json

{
  "request_key": "EXAMPLE_ONLY_GENERATE_A_NEW_RANDOM_SECRET",
  "email": "buyer@example.com",
  "estimate_id": "<estimate_id from GET /v1/quote>"
}

A new order returns HTTP 201 with state: "uploading" and an upload_deadline_at 60 minutes ahead; complete the upload before then, or the request expires and a new one is required. Save the order_id, private order_token, upload_url, payment_url, status_url and cancel_url. Repeat the same request_key and email to recover a lost receipt; do not create a second order.

estimate_id links the free estimate to this order and appears in creation and status responses. Use one estimate for one request key. A different request key for an already used estimate returns HTTP 409 estimate_order_conflict; an unknown or unsuccessful estimate returns HTTP 400 estimate_not_found. Legacy direct clients may omit this optional field.

3. Upload for measurement

Upload the archive with the order token:

PUT <upload_url>
Authorization: Bearer <order_token>
Content-Type: application/zstd

<input.tar.zst bytes>

The server safely expands the archive, measures the original JSONL bytes and SHA-256 values, and assesses the content using the same supported record formats as processing. An archive with no supported conversation records is rejected before payment. A successful measurement returns HTTP 200 with state: "awaiting_payment", including:

• input.original_bytes and input.compressed_bytes
• pricing.price and pricing.amount_micro_usdc: the final amount to pay
• pricing.standard and pricing.adjustment_reason, when the quote exceeds the standard guide
• delivery.estimated_duration_seconds.{min,max}
• quote.expires_at, quote.valid_for_seconds and quote.pricing_notice

The standard guide uses decimal MB: 1 MB = 1,000,000 original bytes, rounded up once for the whole order. Compression does not lower the measured size. The uploaded content is assessed before payment, and the final quote may exceed that guide. If it does, pricing.standard shows the original-size reference price and pricing.adjustment_reason explains why; pay the final pricing.price, not the reference amount.

4. Review the quote and pay through x402

The measured quote is valid for 60 minutes. If you cancel or do not submit payment before expiry, Sidera deletes the uploaded data and order workspace and returns the worker to the pool. A new request and upload are then required. A payment already being settled is retained until its outcome is known.

Request the x402 challenge from the order's own payment URL:

POST <payment_url>
Content-Type: application/json

{"request_key":"<same request_key>"}

The HTTP 402 response supplies a PAYMENT-REQUIRED header and an accepts[] list. Select one USDC option on Base, Polygon or Solana. Check the amount, network, terms_sha256, pricing, processing estimate and quote expiry before signing. The payment body needs only the same request_key; email was saved at creation. An LLM without signing access presents this formal quote and hands payment approval to the user using the client flow above. The user connects an existing x402-capable wallet to create PAYMENT-SIGNATURE, then sends the same POST body with that header once. The purchase client supplies an executable Base signer flow with an explicit amount cap and quote-hash approval; official x402 buyer documentation describes the SDK interface for other integrations.

Successful settlement returns HTTP 201 and starts processing. HTTP 202 with settling or payment_review means the payment outcome is still being checked; do not pay again.

After settlement, Sidera emails the order ID, amount, network, transaction ID, approximate completion window, order-specific status API and support instructions. Mail delivery is retried without stopping paid processing.

5. Check progress and download both files

Poll at the interval returned by the API, currently 60 seconds:

GET <status_url>
Authorization: Bearer <order_token>

Each order has its own status URL and token. Keep the token private. Status checks do not require another payment.

When state is done, the response contains authenticated artifact URLs for memory.md and raw.tar.zst. Download both with the same Bearer token and compare their byte sizes and SHA-256 values with artifacts[].

After both checks pass, acknowledge delivery by sending the exact two name-to-hash pairs:

POST <delivery_receipt_url>
Authorization: Bearer <order_token>
Content-Type: application/json

{
  "memory.md": "<SHA-256 from artifacts[]>",
  "raw.tar.zst": "<SHA-256 from artifacts[]>"
}

Download and acknowledge within 24 hours after processing completes. On acknowledgement, or at the end of that window, the worker is deleted after the two artifacts have been verified. Recovery data is kept for seven days and then permanently deleted. It is not available through a public API. To request it during that period, email shadowharness@gmail.com from the same address used to place the order and include the exact order ID; requests from another address are not accepted.

The raw archive includes USAGE.md, raw-archive.mjs, and each logical original beside its .sidera compressed frames and index. Keep these together so source byte ranges from memory.md remain drillable.

Cancellation, refunds and recovery

• Every request uses a fresh dedicated container from acceptance onward. Before payment, POST <cancel_url> with the Bearer token deletes the uploaded input and that container; expiry also deletes the container.
• After payment, customer-requested cancellations are not accepted because processing costs are incurred from the start.
• If log formatting fails and no deliverables can be produced, we will refund the processing payment. You do not need to retry processing.
• A wallet window closing or a rejected signature does not notify the server; the measured quote expires after 60 minutes instead.
• If a payment response is lost, check the same order's status. The purchase client's resume does this without another signature or payment send. Retain the original private state for support if settlement remains unclear.
• If no worker is available, the gateway returns HTTP 503 no_available_worker with Retry-After: 60; retry the same request key after that interval.
• Once an order's container has been deleted, its URLs answer HTTP 410 with order_cancelled, order_expired or order_retired, according to the order's final state.

For trouble or delays, email shadowharness@gmail.com with the order ID and transaction ID. Do not include the private order token.