What is the problem your project solves?

Two walls stand between an idea and a trained model

The first is compute. Training capacity is concentrated in a handful of clouds, rented by the hour, and priced for companies rather than people. A student in Bengaluru with a good hypothesis and a CSV file has no realistic path to training on it. Meanwhile the hardware already exists — it is just scattered. Every gaming rig, every workstation, every laptop sits at single-digit utilisation for most of its life. The world is not short of silicon. It is short of a way to point the idle silicon at a problem.

The second wall is expertise, and it is the one nobody talks about. Suppose you solve compute. You still have to know that total_charges is collinear with tenure × monthly_charges, that 900 rows will overfit a 68k-parameter network, that your target needs label encoding while your categoricals need one-hot, that a 3-shard split of a small dataset makes every shard worse. That knowledge is the actual gate. Renting a GPU to someone who does not have it just gives them an expensive way to train a bad model.

Why it matters

These two walls compound. Cheap compute without expertise produces garbage. Expertise without compute produces nothing. Almost every "democratise AI" effort attacks exactly one of them, which is why the floor has not actually moved.

The people this locks out are not marginal. They are the clinic with three years of patient records, the logistics operator with a spreadsheet of delivery times, the undergraduate with a research idea and a second-hand laptop. They have the data and the questions. They do not have a cluster or an ML team.

The impact if both walls come down

If idle consumer hardware can be pooled into a real cluster, and if plain English is enough to direct it, then the requirement for training a model collapses to: own a machine, or have a question and a CSV.

That is a genuinely different world. Compute stops being a thing you buy from three companies and becomes a thing a community contributes to and draws from — with the people who supply it getting paid. And the ML expertise that currently gates the whole field becomes something the system supplies on your behalf, and explains, rather than something you must already possess.

How you are solving it?

Disclosure first

Everything described here was written during the hackathon, starting from an empty directory. No prior code, no prior submission, no template. Nothing in this project has been presented anywhere before. The full history is one continuous build.

What Club GPU is

A marketplace where members contribute idle machines, and other members upload a dataset, describe what they want in plain English, and get a genuinely trained model back — sharded across whatever hardware is online, metered per second, and settled against a credit ledger.

upload CSV ─▶ profiled on arrival (types, ranges, cardinality, nulls)
                     │
"predict churn" ─▶ Claude reads the profile, writes a concrete plan
                     │
           plan compiled to a model spec; data fitted + encoded once
                     │
     ┌────── sharded across the cluster ──────┐
     ▼               ▼                        ▼
  node A          node B                   node A
     └── every epoch: train, submit params, ───┘
         wait at barrier, get averaged model
                     │
         best-scoring round saved + NumPy predictor

Three things had to be built

1. A real training engine, in Go, from scratch

The hard constraint was that a provider node must be one binary — no Python, no CUDA, no cgo. So there was no framework to reach for. I wrote one.

Dense tensors, explicit hand-derived forward and backward passes, AdamW with decoupled weight decay and gradient-norm clipping, cosine schedule with warmup, LayerNorm, GELU, dropout, residual blocks, multi-head self-attention, and an FT-Transformer — the architecture that makes each table column a token so attention can learn which columns inform which.

A framework you wrote yourself is worth exactly as much as its gradient check, so every backward pass is verified against central-difference numerical differentiation:

And it demonstrably learns: 96.3% on two spirals (not linearly separable), 96.0% on an XOR-style interaction where no single feature is predictive, R² 0.994 on regression.

2. Real distributed training, not an ensemble

Shards do not train separate models that get merged. They train one model together through a synchronous parameter-averaging barrier:

1. Every shard builds the same model from the same spec and seed — bit-identical, so round 0 needs zero transfer.
2. Each trains one epoch on its own rows.
3. Each submits its parameters and blocks.
4. Once every live shard has arrived, the server computes a row-weighted average and releases all waiters with the new global model.

A barrier is a liveness hazard, so: reclaimed shards are explicitly dropped from the expected set; every round has a deadline after which partial contributions are averaged and flagged; a shard submitting NaN is rejected outright rather than poisoning the shared model; and a reassigned shard rejoins at the current round instead of restarting.

3. The marketplace and the delivery

Node registry with heartbeats and reaping, long-poll shard leasing, slot accounting, retry-with-failover, per-second metering, and a double-entry credit ledger with a platform fee.

Output is a downloadable bundle: weights, model card, the fitted preprocessing pipeline, the learning curve, and a generated predict.py that reimplements the exact forward pass in NumPy — so the model works with no Club GPU code at all. There is also a live inference endpoint.

It actually works

Real run on 900 rows, FT-Transformer, 67,906 parameters, 3 shards:

round  1: train 0.9574  val 0.8057  acc 0.620  auc 0.708
round 22: train 0.5905  val 0.6088  acc 0.696  auc 0.744  <- saved
round 60: train 0.5397  val 0.6416  acc 0.635  auc 0.748

Textbook overfitting — so the platform ships round 22, not round 60. Predictions from that model on unseen rows: 2 months + 7 support tickets + month-to-month → churn=yes (97.2%); 70 months + two-year contract → churn=no (90.9%).

What is not real, stated plainly

• No GPUs. Training runs on the CPU. A node's "VRAM" is self-declared and used for scheduling and pricing, not measured. GPU kernels are the obvious next step; the scheduler already treats a shard as an opaque unit of work.
• Credits are a ledger. Topping up writes a row; no money moves.
• No pretrained weights. A request for a BERT gets a transformer trained from scratch, and the substitution is recorded in the job's warnings rather than hidden.

Everything else — the gradients, the models, the metrics on a held-out split, the distribution and its failover, the predictions — is real.

How Did You Use Claude?

Claude is the intelligence layer of the product, not a dev-time helper

The planning agent runs in the product's request path. Remove it and the platform loses the thing that makes it usable by a non-expert.

Model: claude-opus-5 via the Messages API (Go SDK), with adaptive thinking, prompt caching on the system prompt, and a forced tool call (submit_training_plan) carrying a strict JSON schema — so the plan arrives as validated structured data, not prose to be regex'd.

What Claude receives: the user's plain-English request plus a statistical profile of the dataset — column types, ranges, cardinality, null counts, top values. Never the raw rows. That is both a privacy property and a token bound: a 60,000-row file costs the same to plan as a 600-row one.

What Claude returns: target column, task type, architecture, epochs, batch size, learning rate, optimizer, shard count and sharding strategy, ordered preprocessing steps, evaluation metric, a rationale written for the customer, and specific warnings. The scheduler compiles that directly into an executable model spec.

Claude's plans were genuinely good — and caught a bug in my code

From the profile alone, on the churn dataset, it independently derived:

• the class balance (428/472) from the top-values histogram
• that total_charges is near-collinear with tenure × monthly_charges — "mean 2424 is close to 36.2 × 67.8"
• that both money columns had exactly 200 distinct values across 900 rows, so the file was probably synthetic. It was. I had generated it an hour earlier.
• that gradient-boosted trees beat a neural net at 900 rows
• that "don't miss real churners" means tuning the decision threshold for F2, not resampling

Then it chose hyperparameter_sweep over data_parallel specifically because 300 rows per shard would degrade every model — every shard needed all 900 rows. My scheduler was ignoring the strategy field and splitting the rows anyway. Claude's reasoning is what exposed the bug; the run had been quietly contradicting its own plan.

Designed to degrade honestly

With no API key the platform falls back to a deterministic heuristic planner reading the same profile, and stays fully functional. Every job records which planner produced its plan, so a result is never ambiguous about its provenance. When Claude names something the engine cannot build (boosted trees, a pretrained BERT), the nearest neural equivalent runs and the substitution is written into the job's warnings — never silently swapped.

Claude also built it

The entire codebase — the Go training engine, the hand-derived attention backward pass, the barrier, the React dashboard, the docs — was written with Claude Code across one continuous session. Notably, Claude wrote the gradient-checking suite that then caught its own bug in Dense.Backward (a double transpose) on the first run, before a single line of training code had shipped.

What is the deployed URL for this project?

https://github.com/gijutsu-hub/pushtoprod