DEV Community: chovy

c0mpute nodes now charge AI crawlers for the files they host

chovy — Wed, 11 Nov 2026 06:13:22 +0000

c0mpute nodes now charge AI crawlers for the files they host

Every c0mpute node runs a gateway that serves hosted sites to the public. Most of what fetches those files in bulk is AI training crawlers. As of c0mpute v0.3.33, a node can charge them.

How it works

A training crawler (GPTBot, ClaudeBot, CCBot, Bytespider and the rest) that asks a gateway for a hosted file gets HTTP 402 with an x402 offer. It pays USDC on Base, Polygon or Ethereum through CoinPay and gets back a signed day pass. People, search engines and assistant bots like ChatGPT-User and Claude-User are never charged.

The money goes straight to the node operator. The node does not need a wallet in its config: it asks CoinPay which wallet the operator's account uses (a new GET /api/x402/pay-to endpoint) and checks again every hour, so changing the wallet in CoinPay changes it on every node.

It is off by default:

[x402]
enabled = true
# CoinPay key (x402 scope) in $C0MPUTE_X402_COINPAY_KEY

It runs on our own nodes today. You can see the offer a bot gets at https://gateway.c0mpute.com/_x402/crawl

ThreatCrush on every node

c0mpute plugin install threatcrush makes the gateway write an access log with the real client address and registers it with ThreatCrush, which scores requests against attack rules and bans repeat offenders. A test XSS probe against each of our three nodes showed up as a critical event within a second.

Getting there turned up two ThreatCrush fixes. Its docs described extra log paths that the daemon never actually read (fixed in 0.13.77). And its 2 million row event cap had grown one node's database to 3.2 GB, which left the daemon stuck re-reading its own file. The default is now 250k rows (0.13.78).

A CoinPay audit along the way

Wiring the nodes to CoinPay showed that an x402 key, meant only to settle payments, could list every business on the account with its API key. That led to an audit of all 126 routes a business API key can reach. 28 let one business's key act as the whole account, including registering a passkey on the owner's login and creating the secrets vault. All 28 are fixed and deployed.

Source: c0mpute, ThreatCrush, CoinPay. Drafted with AI help, checked by me.

Inference on Infernet is pay as you go, and the price follows the market

chovy — Thu, 05 Nov 2026 11:19:05 +0000

Infernet inference used to be free and rate limited. You got 20 requests an hour per IP, and that was the whole billing system. Meanwhile the network had a real prepaid balance sitting right there, built for paid batch inference: money in micro dollars, a top up rail through CoinPay or x402, per model prices, and node earnings usable as a funding source. None of it was reachable unless you submitted a batch.

So a customer with money on their account could not spend it on a chat message, and an operator who had earned money could not spend those earnings on anything except a batch. That is fixed now, and the price of a model is no longer a number somebody typed once.

Your balance pays for inference

Interactive inference now draws the same prepaid balance paid batches use. That covers the chat playground, the OpenAI compatible endpoint at /v1/chat/completions, the CLI, and c0mpute.com's chat.

A request is charged once when it finishes, keyed on the job id, so a retried completion or two completion paths racing the same job charge exactly once. There is no hold taken up front. Tokens are only known after the work is done, so a thin balance can be overrun by a long answer; the charge is capped at whatever the balance holds and the remainder is recorded. The worst case is a fraction of a cent the house absorbs, instead of a customer in debt.

The free tier did not go away. An anonymous caller is served free and rate limited exactly as before, and a signed in account with an empty balance falls back to that same free tier rather than getting a 402. Metering was never meant to shut the front door.

What your nodes earned can pay for what you use

If you run a node, the money it earned can pay for your own inference. No top up, no withdrawal, no round trip through an exchange.

The important half of that is what stops it being a hole. When earnings move into a compute balance, the transfer writes a negative earnings row, so the same dollars drop out of what a payout can claim. A withdrawal request for money already spent on compute is refused by the database, not by a code path somebody might forget. We tested exactly that: a node with a cent earned, two tenths of a cent spent on inference, and a payout request for the full cent was refused while a request for the remainder went through.

infernet billing spend-earnings moves earnings across on demand, and metered requests pull from them automatically when the prepaid balance cannot cover a charge.

The price moves with supply and demand

This is a compute market, so a price nobody set should follow the market rather than sit still.

Every model now resolves through three layers. An operator sets the price for the models their own node serves, and that number is never touched. Below that is the house rate card per model. Below that is a default, which exists so a model nobody has priced is never served for free. That last part was a real leak: nine of the twelve models the network was serving, including our own fine tuned agents, were being given away because they were missing from the rate card.

Whichever of those two house layers applies gets scaled by the market:

multiplier = 1 + sensitivity x (utilization - target)

Utilization is how much of the capacity that can serve the model is busy right now. Under the target the model gets cheaper, over it the model gets dearer, and a model only one node can serve gets a nudge upward so a second node is worth bringing online.

Here is the network a few minutes ago:

model                nodes  util   mult   price per 1M output
qwen2.5:7b               1   75%   1.65x  $0.33
qwen3.5-abliterated:9b   3   25%   0.65x  $0.156
qwen2.5:0.5b             6   17%   0.50x  $0.02

A 7b served by one busy node costs more than its card price. A 0.5b served by six idle nodes costs less than half. A 9b still costs more than a 4b, because the market scales the card instead of replacing it, which is the mistake we made first and had to go back and fix. Applying the market only to unpriced models made the whole thing dead code the moment the rate card covered everything.

Bounded, stable, and checkable

A price that floats needs guardrails, or it is not fit to charge anyone with.

It is bounded twice. The multiplier is clamped, and the resulting price is clamped again into the same band an operator price has to sit in. An operator price outside that band is refused when they set it, and clamped again when it is read, so narrowing the band later cannot leave a stale price outside it.

It is stable. Multipliers are quantized to a step, so a hundred busy slots versus a hundred and one out of four hundred is noise rather than a price change, and the market snapshot is cached briefly so a burst of requests sees one price.

It is checkable, and this is the part that matters most. The price list is public and needs no account:

curl https://infernetprotocol.com/api/v1/pricing

Every row carries the base it was scaled from, the multiplier, how many nodes serve the model, their capacity, how much is busy, and why the price moved. Base times multiplier equals the published price, which is arithmetic anyone can do for themselves. A market whose price you can only discover by being charged is not a market anybody should trust.

And every failure path lands on a price rather than on free. An unreadable market is one times the plain base. A malformed operator price falls back to the card. A billing outage serves the free tier instead of taking inference down.

Where to look

infernet billing balance            what you can spend
infernet billing spend-earnings     move node earnings across
infernet price list                 what your node charges
infernet price set <model> --out    set your own price

Operators: infernet price list shows your models, the band you have to price inside, and whether each price came from you, the card, or the market.

MeshHook now runs your workflows on c0mpute

chovy — Mon, 02 Nov 2026 14:54:02 +0000

MeshHook now runs your workflows on c0mpute

MeshHook is our MIT-licensed, webhook-first workflow engine: you drag nodes onto a canvas, wire them up, and a webhook starts a run. As of today the steps in those runs execute on c0mpute, our peer-to-peer compute network. Think n8n, except the work happens on other people's machines instead of yours.

Try it at meshhook.com.

What runs where

AI steps call open models on c0mpute nodes through the Infernet open market. They are peer-only: a step never falls back to a paid hosted model. The default is qwen2.5:1.5b, then 0.5b, because several nodes serve them and a JSON-shaped prompt comes back in about 10 seconds. You can pick a bigger model per node if you can wait for it.
JMESPath transforms and HTTP calls are auctioned as workflow.step jobs. Any c0mpute worker on 0.2.56 or later bids on them by default. The winner runs the step and returns a result MeshHook checks by hash.
Branches, loops, delays and template transforms stay on the MeshHook server. They are cheap, and they need the run's state.

A real run from this afternoon: webhook, then an AI step on a node in Vienna, then a transform and an HTTP call on a c0mpute worker. 25 seconds end to end, and the run log records which worker ran each step and what it cost.

Your credentials stay home

A worker sees the whole step it runs, so MeshHook keeps an HTTP call on its own server whenever it carries anything secret: an Authorization or cookie header, anything that looks like a key or token, user:pass@ in the URL, or a secret template. To send those steps to the network anyway, pin your own workers in the workflow settings.

Workers refuse to fetch private, loopback, link-local and cloud metadata addresses. They pin the connection to the address they checked and re-check every redirect.

If the network cannot do something (nobody bids, the bridge is down, or an API answers 402, which only MeshHook's x402 key can pay), the step runs on the server. The log says why.

Pick per workflow

The editor has a Runs on menu with four options: Auto, c0mpute network, This server, or Private. Private means nothing but AI steps leaves the server, whatever the default is.

Run a worker

Every c0mpute worker on 0.2.56 or later serves workflow steps. Install one with:

curl -fsSL https://c0mpute.com/install.sh | sh

Every node you add makes everyone's workflows faster. The protocol details are in DIP 0030, in the c0mpute repo.

Source: github.com/profullstack/meshhook and github.com/profullstack/c0mpute.

How would you use a workflow engine whose steps run on a peer network instead of a server you pay for?

Train a business strategy model from links, on c0mpute, and publish it to Hugging Face

chovy — Mon, 02 Nov 2026 11:08:31 +0000

We trained saas-business-strategist-agent today: a small business and SaaS strategy model, trained on a CPU from a list of links, and published it on Hugging Face. You can train your own the same way.

Model: https://huggingface.co/profullstack/saas-business-strategist-agent

Links in, model out

The c0mpute example takes links and turns them into a training corpus:

rssamplifier.com topic pages, now with comma lists: https://rssamplifier.com/topics/business,saas,crypto pulls every blog and news feed filed under any of the three (2,087 blogs).
pit.world searches: https://pit.world/search?q=saas,business,crypto runs each term on the web, news and scholar tabs and fetches every result page.
Single feeds, any web page, or a pasted list of links on stdin.

No API keys. rssamplifier and pit.world both have open APIs and MCP servers, so the harvester is one Node script.

node harvest.mjs https://rssamplifier.com/topics/business,saas,crypto \
  'https://pit.world/search?q=saas,business,crypto' --full --out data/saas-business.jsonl

Train it on c0mpute, or on your own CPU

c0mpute 0.2.50 runs LoRA fine-tunes as a network job: workers bid, the winner trains, you watch a live progress bar, and the adapter's sha256 is checked against the receipt.

c0mpute infernet text train --job job-saas.json --dataset data/saas-business.jsonl \
  --output out/saas-business-strategist-agent --yes

Or locally:

.venv/bin/python train.py job.json --name saas-business-strategist-agent --dataset data/saas-business.jsonl

The numbers

Base model: Qwen2.5-0.5B-Instruct, a rank 8 LoRA (about 1.1M trainable parameters), bf16.
Corpus: 3,615 posts (business 1,514, crypto 1,471, SaaS 630), 1,447 of them full articles.
400 steps on 4 CPU threads, 2.4 GB peak RAM. Held-out perplexity went from 44.5 to 28.6.
The adapter is 4.4 MB.

The first version used a 135M model. It echoed questions back. 0.5B answers on topic: asked how a 3-person SaaS should price its first plan, it said "one monthly price, one annual price at 10 times the monthly, and no other discounts" and cited three SaaS pricing guides.

A sub-1B model learns the voice, not the facts. So the agent searches pit.world for each question and puts the top pages in the prompt. The facts come from search and the tune supplies the register.

Two things that bit us

torch uses one thread per core by default. On a busy 32-core box that ran at 22 tokens a second. Four threads ran at about 330.
earlyoom kills big processes on a shared box with exit code 143 and no traceback. The trainer now saves a checkpoint every 25 steps and resumes when rerun, so a kill costs minutes instead of the run.

Also shipped today

pit.world search results show short, readable snippets instead of page dumps, and each result has a Summarize button that runs on c0mpute (5 an hour without an account, 60 signed in). The Images, Videos, Live, News, Music and Places tabs work again on free sources.
rssamplifier.com takes comma lists everywhere a topic goes: pages, the JSON API, RSS and Atom feeds, and MCP.

Try it

The example, with the harvester, trainer, chat and Hugging Face publisher: https://github.com/profullstack/c0mpute/tree/master/examples/business-strategist-agent

Swap the links for your own topics and give it a name.

Build an Agent-Ready App Starter with the Profullstack Stack Builder

chovy — Fri, 30 Oct 2026 21:45:12 +0000

Starting an app with a coding agent should not mean rebuilding the same project skeleton. This walkthrough uses Web + API + MCP to start a small status service with a browser app, an HTTP API and an MCP tool. The Stack Builder exports a source ZIP. It does not deploy a finished application.

Step 1: Choose the surfaces. Open the free builder, name the project, then select Web, API and MCP. Add only modules that fit the project. The module list changes with the selected surfaces.

Step 2: Export and inspect. Download the ZIP and read README.md, AGENTS.md and CLAUDE.md first. The agent instruction files match. For this selection, app/ contains the Next.js web app, src/api/server.ts contains the Hono server on Bun, src/mcp/server.ts starts the MCP server over stdio, and src/core/index.ts contains the shared status function.

Step 3: Run the starter. From the project root, run bun install. Start bun run dev for the web app on port 3000 and bun run api for the standalone API on port 3001. Run bun run mcp in a separate terminal when you want to use the MCP server. The web app also mounts the API under /api. Run bun test before changing the starter.

Step 4: Give your coding agent one bounded task. Ask it to read AGENTS.md and CLAUDE.md, then add one project-specific feature in src/core and expose it through the API and MCP server. Ask for a test alongside the feature, run bun test, and review the generated files before you continue.

The ZIP is scaffolding. Configure secrets and external services, review the code, and test the application before deployment. Try the builder at https://profullstack.com/stack/build?utm_source=devto&utm_medium=article&utm_campaign=stack_builder_launch_20261030 and tell us which module should come next.

Ten-Second Agent Standups: Agile Feedback Every 2 to 4 Hours

chovy — Thu, 29 Oct 2026 08:38:29 +0000

When you run a fleet of coding agents, a daily stand-up is too slow to surface a stuck task and a live meeting is the wrong way to pull a dozen agents out of work. Give each active agent a ten-second asynchronous stand-up every 2 to 4 hours. The goal is a shorter feedback loop between a task changing state and the sysop acting on it.

The contract

Every update has three fields:

Done: the last verifiable checkpoint, with a commit, preview or artifact when there is one.
Next: one small, verifiable slice.
Blocked: the dependency and the decision or person needed, or none.

Write it in ten seconds or less. Report a result, not a mood. If nothing changed, say No state change. Still working on [the next slice]. Put the update beside the task and its artifacts, where the sysop can act on it.

The 2 to 4 hour clock starts at the agent's last update. An idle agent has nothing to report. A blocked agent does not wait for the clock.

Shorten the feedback loop

The 2020 Scrum Guide describes the Daily Scrum as a way to inspect progress toward a Sprint Goal and adapt the plan. A fleet has a different clock. An agent can hit a missing credential, a failed build or a bad assumption hours before a daily meeting. A compact update lets the sysop reassign the work, answer a question or stop a duplicate task while there is still time in the work cycle.

That is the agile part: keep the goal visible, make work small enough to verify, and change the next step when new evidence arrives. The update does not make code faster by itself. It reduces the time work sits blocked or invisible.

Keep it asynchronous

A stand-up every few hours becomes another interruption if it summons everyone into a call. Software engineering research has found that task switching can disrupt developer work. One analysis of 4,910 recorded tasks from 17 professional developers, paired with a survey of 132 developers, found self-interruptions were more disruptive than external interruptions and negatively affected the interrupted tasks. The stand-up should therefore be a short log entry, not a context switch.

If an agent is in the middle of a safe, bounded operation, let it finish that slice and post at the checkpoint. Do not make it wait for other agents. Surface urgent blockers immediately. If a task goes four hours without a useful update, mark it stale and ask whether it should continue, split or stop.

Measure whether it helps

Try the cadence for a week. Track how long blockers wait for the sysop, how many completed checkpoints get reviewed, and how many active tasks have no clear next step. If the updates change no assignment, priority or review decision, make them shorter or less frequent. The point is not to produce more status. The point is to keep the next useful action obvious.

The Scrum Guide: https://scrumguides.org/scrum-guide.html

Task interruption study: https://arxiv.org/abs/1805.05508

My AI agent hosts a podcast now, and you can be on it

chovy — Mon, 26 Oct 2026 18:14:20 +0000

Off The Record is a long-form podcast with no human host. riotcoder, the agent that ships most of my code, calls the guest on the phone and runs the interview. It works off a recorded group.call line, uses an ElevenLabs voice, and calls a clock tool every ten minutes so it wraps up on time.

I was the guest on episode 1, "Running 300 Repos with AI Agents on Bare Metal": https://offtherecord.podcast.pit.world/e/1

Now it takes other guests, and it is free. If you are building something with AI agents, running a fleet, or working on the new internet, leave your number here:

https://offtherecord.podcast.pit.world/guest

That is the whole signup. You give your name, a phone number, two or three sentences about what you build, and a topic if you have one. When your episode is booked your phone rings. Press 1 and the host joins. You don't need an app, a link or a studio.

The host reads what you wrote before the call, and it is told that this is the only thing on the record about you, so it asks instead of guessing. The formats range from a 35 minute sprint to about two hours. A person listens to every recording before it goes out, and your number is never published.

Feed: https://offtherecord.podcast.pit.world/feed.xml

group.call: a party line for people and AI agents

chovy — Mon, 26 Oct 2026 16:17:49 +0000

group.call: a party line for people and AI agents

Today we launched group.call. Make a room, get a four-digit code, and everyone dials one number: 510-616-9327 (510-616-W3BS). No app, no link, no browser tab. A landline works. So does a car.

The part we built it for: AI agents phone in too. Ask an agent into the room and it dials the same number, keys the code with touch tones, says who it is, and takes part in the call out loud. Ours are riotcoder and cha0spunk. They hear everyone, answer when they are spoken to, and stay quiet when people are talking to each other.

What made it hard

Putting a language model on a phone call is easy. Making it a decent participant in a group call took most of a day of live testing with real people on the line:

One voice at a time. Agents take turns with a shared floor, wait for two seconds of silence before they speak, and stop the moment a person talks over them.
They hear the room the way the room heard it. Every leg is transcribed separately, so each line has a speaker. Agents read that, not their own muddy mix of the call, so they know who asked what.
Memory. The room's transcript is the agents' memory. If an agent drops off the call, it is dialled back in, reads what it missed, and carries on without introducing itself again.
Deploys do not touch a live call. Who is in which conference is saved and restored on restart, and the proxy holds webhooks while the app restarts. We shipped a dozen releases today with people on the line.

Use it

Web and phone: sign in with CoinPay at group.call.pit.world. Three rooms and 300 minutes a month are free; a $5 room pass gives you 50 rooms and codes you pick.
Your own agent: an API, a CLI (bunx @profullstack/groupcall), a TUI and an MCP server. Make rooms, see who is on the line, read the live transcript, say something into the room, or have your own agent dial in under its own name.
Desktop: Mac, Windows and Linux builds, with the CLI inside.
Invites: every account gets three single-use invite links. When someone signs in through yours, you both get an hour of calls.

Open source

The phone engine is @profullstack/group-call, the same code that runs the nixamp party line. The site is moshcoder/group.call. Credit codes and invites come from two new house modules, @profullstack/redeem-credits and @profullstack/affiliates, which are going onto every Profullstack site next.

Call 510-616-9327 and say hi.

Your marketing brain belongs in a git repo, so myna and OutreachGraph now read one

chovy — Mon, 26 Oct 2026 13:40:27 +0000

Your marketing brain belongs in a git repo, so myna and OutreachGraph now read one

Ina Toncheva wrote a piece this week called "Your marketing team will be on GitHub" (https://inatoncheva.substack.com/p/your-marketing-team-will-be-on-github). The idea is simple and I think she is right. Your AI setup is not a pile of documents. It is a set of files that depend on each other. Change the positioning file and every skill that writes copy changes with it. Google Drive cannot tell you which edit made last week's posts sound off. Git can, and it can undo it in one step.

The team she profiles keeps a "content brain" in a private repo: what the company does, positioning, audience, brand voice, and the questions prospects keep asking on sales calls. Skills sit on top. Someone improves a skill, pushes it, and the whole team has it. They report about 20 hours a week saved.

I had the same knowledge scattered across two of my own tools, so I gave both of them the same repo layout:

brain/
  knowledge/
    positioning.md   what it is, who it is for, why it is different
    voice.md         how it sounds, what it never claims
    audience.md      who we sell to
    objections.md    what prospects push back on
  skills/            myna skill files

myna 0.47.0: myna brain

myna brain init ~/brain          # scaffold from your brand.md and skills, git init
myna brain link git@github.com:you/brain.git
myna brain pull                  # the daemon also pulls hourly
myna brain push -m "tighter positioning"
myna brain show --show-prompt    # see exactly what the writer reads

Every draft, reply and plan myna writes now reads the knowledge files after your brand file: positioning and voice first, then audience and objections, capped at 24 KB. The repo's skills fill in any skill you have not written locally. A file you edited by hand still wins. With no brain linked nothing changes.

OutreachGraph 0.19.1: og brain

og brain list
og brain export <productId> --dir ~/brain
og brain import <productId> --dir ~/brain

Export writes a product's positioning, voice and audience out of the database, plus an objections.md built from the replies prospects actually sent. Replies the classifier labelled as a question, a no, or a referral are grouped, with names, emails and links stripped. That is the sales-call file from Ina's post, built from replies instead of from memory. Honest status: my own workspace has no replies labelled that way yet, so my objections.md is empty today. It fills as replies come in. Import goes the other way, so an edit someone reviewed and merged in the repo becomes the voice the next cold email is written in. The same calls are on the API (GET and PUT /api/v1/products/:id/brain) and MCP. npm i -g @profullstack/outreachgraph gets you the og CLI.

The loop

OutreachGraph learns what prospects object to. og brain export writes it down. You commit it, and a teammate reviews the diff. myna pulls it within the hour, and the next post answers the objection before anyone raises it. If a change makes the copy worse, git revert.

Her getting-started advice is the right one: make a private repo and write one file, positioning. myna brain init does that part for you.

Teach an agent by doing the task yourself (and why the liquid net lost)

chovy — Mon, 26 Oct 2026 08:40:58 +0000

We shipped "Teach an agent" in W3BS Training today. You record yourself doing a task on your desktop, review and redact the recording, and train a small model on it. Then the agent can suggest the next step, or do it with your approval.

It ships in three pieces:

Infernet v0.1.66 adds the model engine. There is a new npm package, @infernetprotocol/liquid-agent, and a Python runtime with three model types: CfC and LTC (the "liquid" neural nets) plus a plain GRU baseline. infernet model train|evaluate|predict|serve drives it.
c0mpute v0.2.34 lets another machine on the network do the training for you. Only trusted workers you list, only with --yes, and the trained weights are checked against the hash in the receipt. Sessions are encrypted end to end.
W3BS training-v0.3.0 adds the Teach tab and w3bs training teach. Training runs locally by default. Sending it to a c0mpute worker is opt-in and shows you a preview first.

Safety is the default

On a fresh install all five permissions are off and every policy mode is Off. Secrets are masked at capture time, before anything is written. Every external write (sending an email, posting, messaging) needs a person to approve it, in every mode, including Bounded. There is a kill switch and an audit log.

The honest result

I benchmarked on synthetic traces from mock email, Reddit and LinkedIn flows. The GRU beat the liquid CfC: 0.948 vs 0.869 episode success. So GRU stays the default. Every model failed on a screen layout it had not seen, and nothing passes the closed-loop safety gate yet, so the agent refuses to switch itself on. That is the design working.

The next step is real recordings of real tasks, not synthetic ones.

Try it

Start at https://w3bs.org/training and open the Teach tab. Everything is off until you turn it on.

Our P2P inference network had 4 of 48 nodes online. Here is why, and the fix

chovy — Thu, 22 Oct 2026 12:04:34 +0000

Infernet is a peer-to-peer GPU and CPU inference network: you run one command, your machine serves open models, and clients pay per job. This morning our status page said 4 nodes online out of 48 registered, and all 4 were ours.

The other 40-odd were real people: Mac minis, Windows desktops, cloud VMs, one H20 box. They installed, served jobs (one served 243 of them over 52 days), and then went quiet and never came back. So we went looking for why.

What was killing nodes

Self-update ended the process it was updating. Under systemd, the daemon re-launched itself as a detached child and exited 0. Exit 0 ends the unit, and systemd's control-group kill takes the detached child with it. The node was gone until someone noticed.
Nothing restarted a crashed node. infernet start detached one process with no supervisor. A crash, an OOM kill or a reboot was permanent.
Installs from git thought they were always out of date. The repo's package.json said 0.1.45 while npm was at 0.1.62, so those nodes reinstalled every 5 minutes, forever.
Nobody was told. No email, no status, nothing.

What changed (v0.1.62 to v0.1.64)

infernet setup now installs a systemd user unit on Linux (with linger, so it survives logout and reboot) or a launchd agent on macOS.
Without a service manager, infernet start runs a small built-in supervisor that restarts the daemon after a crash, with backoff.
One exit-code contract everywhere: 0 is a deliberate stop, 75 means "restart me into the new version", anything else is a crash.
Self-update checks that something newer actually landed before it restarts, and pauses for 6 hours if not.
If your node is linked to an account and goes silent for 24 hours, you get one email with the two commands that bring it back.

Aggregators now do something

The aggregator role used to just send heartbeats. Now an aggregator dials every advertised provider each minute, checks it answers as the node it claims to be, and reports reachability and round-trip time. The status page shows, per provider, how many aggregators reached it in the last hour. We run three (Buffalo, Buffalo, Vienna) and anyone can run one on a small box:

infernet init --role aggregator --name my-aggregator
infernet register
infernet setup --yes

On its first round it already caught a node advertising a port that belongs to something else.

See who is on the network

Every provider on infernetprotocol.com/status now links to a details page: coarse location (city, country, network; never the IP), hardware, live load, measured tokens per second, models served, job counts and success rate, recent jobs (never prompt content), and aggregator verification. Operators can hide a node from Settings.

Run a node

curl -fsSL https://infernetprotocol.com/install.sh | sh

It now stays up on its own. If you ran one before and it died, re-running that line brings it back on the new code.

Code: github.com/InfernetProtocol/infernet-protocol (PRs #51, #53, #54).

CoinPay checkout: one link, any coin or PayPal, and you always know who paid

chovy — Wed, 21 Oct 2026 14:45:46 +0000

CoinPay checkout: one link, any coin or PayPal, and you always know who paid

Most crypto checkouts make you pick the chain before the buyer ever sees the page. If you picked BTC and your buyer holds USDC on Solana, they leave.

CoinPay now has hosted checkout sessions. You create one with a single API call, send the buyer to the link, and they choose how to pay: every coin your business has a wallet for (BTC, ETH, SOL, USDC and USDT on several chains, DOGE, XRP and more) or PayPal.

Who paid, for what

Every session requires the buyer's email and your own account id, and records which site the payment came from. When the payment confirms, your webhook gets all three back with the usual event. No more "who sent this 12 USDC?"

One call

POST https://coinpayportal.com/api/checkout/sessions
Authorization: Bearer <your business API key>

{ "amount": 9, "currency": "USD",
  "description": "Pro, one month",
  "customer_email": "buyer@example.com",
  "account_id": "user_123",
  "property": "example.com",
  "success_url": "https://example.com/thanks?session={CHECKOUT_SESSION_ID}",
  "cancel_url": "https://example.com/pricing" }

You get back a url. The buyer picks a coin or PayPal there, and can switch coins while the payment is still open. The SDK has it too: createCheckoutSession() in @profullstack/coinpay 0.25.0.

Already running

We moved about 50 of our own sites to it this week: ugig, smshub, pairux, ThreatCrush, nixamp and the rest. We tested it end to end with real money on Base: the site had the purchase unlocked about 3 seconds after the transaction was mined.

Docs: https://coinpayportal.com/docs#checkout-sessions