HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
bennyschmidt
next-token-prediction
JavaScript2024–2024
bennyschmidt / next-token-prediction

next-token-prediction

Next-token prediction in JavaScript - build fast language and diffusion models.

4Distinct people
11Mentions
0Explicit recommenders
145GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Next-token prediction in JavaScript - build fast language and diffusion models.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 5:05:26 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by week11 dated mentions

Observed mentions: 2024-04-10 21:27:07 UTC to 2024-09-03 04:41:06 UTC. Weeks start Monday, UTC.

0122024-04-08 00:00:00 UTC to 2024-04-15 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 commentsApr 82024-04-15 00:00:00 UTC to 2024-04-22 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-04-22 00:00:00 UTC to 2024-04-29 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2024-04-29 00:00:00 UTC to 2024-05-06 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-05-06 00:00:00 UTC to 2024-05-13 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2024-05-13 00:00:00 UTC to 2024-05-20 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-05-20 00:00:00 UTC to 2024-05-27 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-05-27 00:00:00 UTC to 2024-06-03 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-06-03 00:00:00 UTC to 2024-06-10 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-06-10 00:00:00 UTC to 2024-06-17 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-06-17 00:00:00 UTC to 2024-06-24 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsJun 172024-06-24 00:00:00 UTC to 2024-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-07-01 00:00:00 UTC to 2024-07-08 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-07-08 00:00:00 UTC to 2024-07-15 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-07-15 00:00:00 UTC to 2024-07-22 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-07-22 00:00:00 UTC to 2024-07-29 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-07-29 00:00:00 UTC to 2024-08-05 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-08-05 00:00:00 UTC to 2024-08-12 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-08-12 00:00:00 UTC to 2024-08-19 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-08-19 00:00:00 UTC to 2024-08-26 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-08-26 00:00:00 UTC to 2024-09-02 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2024-09-02 00:00:00 UTC to 2024-09-09 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 commentsSep 2

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Apr 82024-04-08 00:00:00 UTC2024-04-15 00:00:00 UTC211
Apr 152024-04-15 00:00:00 UTC2024-04-22 00:00:00 UTC101
Apr 222024-04-22 00:00:00 UTC2024-04-29 00:00:00 UTC202
Apr 292024-04-29 00:00:00 UTC2024-05-06 00:00:00 UTC101
May 62024-05-06 00:00:00 UTC2024-05-13 00:00:00 UTC110
May 132024-05-13 00:00:00 UTC2024-05-20 00:00:00 UTC000
May 202024-05-20 00:00:00 UTC2024-05-27 00:00:00 UTC000
May 272024-05-27 00:00:00 UTC2024-06-03 00:00:00 UTC000
Jun 32024-06-03 00:00:00 UTC2024-06-10 00:00:00 UTC000
Jun 102024-06-10 00:00:00 UTC2024-06-17 00:00:00 UTC000
Jun 172024-06-17 00:00:00 UTC2024-06-24 00:00:00 UTC000
Jun 242024-06-24 00:00:00 UTC2024-07-01 00:00:00 UTC000
Jul 12024-07-01 00:00:00 UTC2024-07-08 00:00:00 UTC000
Jul 82024-07-08 00:00:00 UTC2024-07-15 00:00:00 UTC000
Jul 152024-07-15 00:00:00 UTC2024-07-22 00:00:00 UTC000
Jul 222024-07-22 00:00:00 UTC2024-07-29 00:00:00 UTC000
Jul 292024-07-29 00:00:00 UTC2024-08-05 00:00:00 UTC000
Aug 52024-08-05 00:00:00 UTC2024-08-12 00:00:00 UTC000
Aug 122024-08-12 00:00:00 UTC2024-08-19 00:00:00 UTC000
Aug 192024-08-19 00:00:00 UTC2024-08-26 00:00:00 UTC000
Aug 262024-08-26 00:00:00 UTC2024-09-02 00:00:00 UTC202
Sep 22024-09-02 00:00:00 UTC2024-09-09 00:00:00 UTC202

What Hacker News says

1 sources
Very nice, thanks for sharing! I noticed their token sequence length is fixed: Constructing 7-gram LM ... Created trie with 21,502,513 nodes. People on here will be happy to say that I do a similar thing, however my sequence length is dynamic because I also use a 2nd data structure - I'll use pretentious academic speak: I use a simple bigram LM (2-gram) for single next-word likeliness and separately a trie that models all words and phrases (so, n-gram). Not sure how many total nodes because sentence lengths vary in training data, but there are about 200,000 entry points (keys) so probably about 2-10 million total nodes in the default setup. "Constructing 7-gram LM": They likely started with bigrams (what I use) which only tells you the next word based on 1 word given, and thought to increase accuracy by modeling out more words in a s
Read the rest
equence, and eventually let the user (developer) pass in any amount they want to model (https://github.com/google-research/google-research/blob/5c87...). I thought of this too at first, but I actually got more accuracy (and speed) out of just keeping them as bigrams and making a totally separate structure that models out an n-gram of all phrases (e.g. could be a 24-token long sequence or 100+ tokens etc. I model it all) and if that phrase is found, then I just get the bigram assumption of the last token of the phrase. This works better when the training data is more diverse (for a very generic model), but theirs would probably outperform mine on accuracy when the training data has a lot of nearly identical sentences that only change wildly toward the end - I don't find this pattern in typical data though, maybe for certain coding and other tasks there are those patterns though. But because it's not dynamic and they make you provide that number, even a low number (any phrase longer than 2 words) - theirs will always have to do more lookup work than with simple bigrams and they're also limited by that fixed number as far as accuracy. I wonder how scalable that is - if I need to train on occasional ~100-word long sentences but also (and mostly) just ~3-word long sentences, I guess I set this to 100 and have a mostly "undefined" trie. I also thought of the name "LMJS", theirs is "jslm" :) but I went with simply "next-token-prediction" because that's what it ultimately does as a library. I don't know what theirs is really designed for other than proving a concept. Most of their code files are actually comments and hypothetical scenarios. I recently added a browser example showing simple autocomplete using my library: https://github.com/bennyschmidt/next-token-prediction/tree/m... (video) And next I'm implementing 8-dimensional embeddings that are converted to normalized vectors between 0-1 to see if doing math on them does anything useful beyond similarity, right now they look like this: [nextFrequency, prevalence, specificity, length, firstLetter, lastLetter, firstVowel, lastVowel] For example, here's the embedding for "dog": [0.6666666666666666, 0.6, 0.45714285714285713, 0.15, 0.12, 0.24, 0.56, 0.56] where it used to just be 1D: { dog: 23 } Up until now I've only effectively used nextFrequency to predict the next word, but with these other 7 metrics I'm able to store more info about each word and being vectors am able to store it efficiently, and do what all the smart people keep saying like dot product similarity index etc. The big boys are using like 1536D arrays etc. but with just 7 it still works, and it's weird that it works. Thanks again for sharing!
In Show HN: Next-token prediction in JavaScript

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.