Operator CLI

The layer command runs Layer's matching pipeline by hand. API users don't need it — it's for whoever operates Layer. The scheduled jobs run the same code every 6 hours.

Setup

cd ~/dev/layer
git pull && npm install
npm link          # once: puts `layer` on your PATH

Every command says which database it's using, shows live progress, ends with ✓ or ✗, and suggests the next command. Add --local to use a local practice copy instead of the production database. Without npm link, run npm run layer -- <command>.

Keys

The CLI reads secrets from the macOS Keychain or the environment. Save each one once with savekey <name>:

Commands

The schedule

Vercel runs the pipeline every 6 hours (UTC): :00 pull Kalshi, :05 pull Polymarket, :10 pull Polymarket US, :15 find candidates, :30 grade, :45 check settled matches and snapshot coverage. Grading also runs at :30 every other hour, so a big batch of new candidates is worked through within a day. Every Monday at 13:00 UTC, venue-docs checks each venue's API changelog and docs index (Kalshi, Polymarket, Polymarket US). layer status shows whether it's running on time.

The :30 grade job screens pairs with Jev first, then Claude grades what's left until this month's Claude budget is spent ($100 by default, set with LAYER_GRADE_MONTHLY_USD), then Jev gives its second opinion. The :15 candidates job searches polymarket.com first, then Polymarket US, each with an equal share of the time left. Settle checks both Polymarkets' results (Polymarket US through its /v1/markets/<slug>/settlement), at most 15 requests a second to each venue, retrying a 429 or 5xx up to three times; a check that still fails is retried next run, and the run summary (and layer settle) lists why each one failed. When a venue is switched off with layer venue off, its ingest job is skipped and its pairs aren't searched, graded or settled; Kalshi off stops candidates, grade and settle.

When something breaks

The schedule reports problems as GitHub issues, so nobody has to be watching layer status:

• A job fails → an issue titled [job failed] <job> (label job-failure) with the error. More failures of the same job are added as comments. The job's next clean scheduled run closes it. A run that never records a result (the function timed out or crashed) counts as a failure, reported on the next scheduled call.
• A venue suddenly lists far fewer markets → if open events or open markets fall more than 30% from the last good pull, the ingest stops before closing anything and fails, which opens the issue above. This catches silent venue changes (a new filter, broken paging) that don't return errors. If the drop is real, run layer ingest <venue> --accept-drop.
• A venue announces an API change → the weekly venue-docs job compares each venue's changelog and docs page list with the previous week and opens a [venue change] issue (label venue-change) quoting each new or edited entry and listing added or removed pages. Its first run only records a baseline.

Every new issue (any of the above, a terms change or a settlement mismatch) is also emailed to LAYER_ALERT_EMAIL through Resend (RESEND_API_KEY, sender LAYER_ALERT_FROM). A comment on an issue that's already open isn't emailed. Without the key or the address, issues still open but no email goes out.

Issues go to the repo in GITHUB_REPO using GITHUB_ISSUES_TOKEN. To check the failure path in production, call a job with ?fail=test; the job's next clean run closes the issue it opens.

Once a week (Mondays 13:50 UTC) the terms job runs the same check as layer terms. It reads the venues' public documents, not their APIs, so it runs even while a venue is switched off. If a document can't be downloaded, or the download looks like a block page instead of the terms, the run fails and shows in layer status.