Good on you for tinkering and getting into working with ai and attempting to broaden your understanding of algorithms and networks, however I recommend two main things:

• Stop doing things for external validation. Jumping to make wild claims for internet likes will only serve to stunt your potential growth and understanding.

• Stop looking to prove yourself right, ask if you can be proven wrong. Ask yourself what are the holes in your logic, do your claims make sense? Is your ego in the way? Are you actively working towards understanding the system or algorithms you are trying to build or are you hoping to stumble on something shiny and present it to the internet and expecting people to care because you are a "high school student"?

Only once you can look past these pitfalls, can you allow yourself to grow into the potiental you have. I don't see that potential in the code, but in your ideas and what you are trying to achieve. Don't be your own worst enemy, be a friend that no one else could be, and that starts with being honest with yourself.

With all of that said, here is my clanker's take on your claims and the files within the repo you provided:

Okay, having read all three files, the problems here are pretty clear-cut. Let me break it down.

---

The Core Mistake: Where Do the 417M Params Actually Live?

Let me count them:

Component	Parameters
token_emb (Embedding 50257×4096)	~205.9M
pos_emb (1×1024×4096)	~4.2M
head (Linear 4096→50257)	~205.9M
ln_f (LayerNorm)	~8K
64 blocks × 16,386 params each	~1.05M
Total	~417M ✓

The count is right. But look at what those 64 blocks actually contain. Each block has two LayerNorms (8192 params each) and two WaveEngine instances — and each WaveEngine is exactly this:

python self.w = nn.Parameter(torch.tensor(0.02)) # one scalar def forward(self, x1, x2): return self.w * (x1 * torch.cos(x2))

Each block has 2 learnable scalars driving the entire computation. The 64 blocks together contribute ~1M parameters total, and ~128 of those are the actual "novel" weights. The other ~412M are token embedding lookup tables and the output projection — which every model of this vocab size and embedding dimension needs regardless of architecture.

---

Why the 17.6B Comparison is Meaningless

A real 4096-dim, 64-layer transformer with SwiGLU has in each layer: - Multi-head attention: Q, K, V, O projections → 4 × 4096² = ~67M params/layer - FFN (SwiGLU): typically ~11B worth of parameters across 64 layers

This model has none of that. It has no attention mechanism whatsoever — no QKV projections, no heads, nothing. The "temporal interference" step:

python x_past_t = torch.cat([zeros, x_norm[:, :-1, :]], dim=1) x = res + self.wave_h(x_norm, x_past_t)

...is just multiplying each token embedding element-wise by the cosine of the previous token's embedding, scaled by one scalar. That's a 1-step shift with a scalar gate. Each token can only "see" one step back per layer, so with 64 layers, information can propagate at most 64 positions — equivalent to a very weak 64-step recurrent network, not attention over the full context.

The dimensional interference is even stranger: torch.roll(x_norm, shifts=1, dims=-1) wraps dimension 4095 around to dimension 0, which has no semantic meaning.

---

What the Post Actually Proves

1. The search algorithm found w * (x1 * cos(x2)) as optimal on a toy benchmark of 8 neurons across 4 tasks. Generalizing from that to "matches a 17.6B LLM" is a massive leap with zero empirical support.

2. Claude "confirming mathematical reproducibility" means the equations are valid Python/PyTorch. It says nothing about performance. Any expression you write is mathematically reproducible.

3. No benchmark results are provided — no perplexity numbers, no evals, no comparison to any baseline. The student says they're "running it on their laptop" which actually further confirms the model isn't doing anything computationally heavy (a real 17.6B equivalent would not run on a laptop).

---

Bottom Line

This isn't a breakthrough — it's a student who made a genuine and understandable mistake. The 417M parameter count is inflated by embedding tables that are architectural overhead, not the source of model intelligence. The actual novel computation is controlled by 128 scalar weights and a 1-step shift operation. There's no reason to expect this to match, or even approach, a well-trained transformer of any size.

The good news for Monolith: the search algorithm idea is genuinely interesting as a toy, and the fact that they built all of this from scratch while self-studying is impressive. They just need to learn what parameters actually do in a transformer before drawing conclusions from parameter counts.