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

llimo

Language and image modeling in pure JavaScript.

3Distinct people
6Mentions
1Explicit recommenders
18GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Language and image modeling in pure JavaScript.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

> enough training data > good chat interface I'm going to try to do that here: https://github.com/bennyschmidt/llimo I totally understand your skepticism, and am also surprised…

_akhe used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

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, 10:02:05 AM 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 week6 dated mentions

Observed mentions: 2024-04-11 06:56:00 UTC to 2024-09-02 20:08:25 UTC. Weeks start Monday, UTC.

01232024-04-08 00:00:00 UTC to 2024-04-15 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 commentsApr 82024-04-15 00:00:00 UTC to 2024-04-22 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-04-22 00:00:00 UTC to 2024-04-29 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-04-29 00:00:00 UTC to 2024-05-06 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-05-06 00:00:00 UTC to 2024-05-13 00:00:00 UTC (exclusive): 0 mentions; 0 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): 1 mentions; 0 submissions, 1 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 UTC303
Apr 152024-04-15 00:00:00 UTC2024-04-22 00:00:00 UTC000
Apr 222024-04-22 00:00:00 UTC2024-04-29 00:00:00 UTC000
Apr 292024-04-29 00:00:00 UTC2024-05-06 00:00:00 UTC000
May 62024-05-06 00:00:00 UTC2024-05-13 00:00:00 UTC000
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 UTC101

What Hacker News says

3 sources
Sure, artificial neural network is a great analogy. But that leaves out what it literally is, which is a next-token prediction library that you can use like this: // Predict the next word agent.getTokenPrediction('what'); // Predict the next 5 words agent.getTokenSequencePrediction('what is', 5); // Complete the phrase agent.complete('hopefully'); // Get a top k sample of completion predictions agent.getCompletions('The sun'); And it has this ability to predict because it's based on a language model that turns mere sentences like: "I want to be at the beach", "I will do it later", "I want to know the answer" into a single model: { I: { want: { to: { be: { ... }, know: { ... } } }, will: { ... } }, ... } This model - call it a prefix tree (tr
Read the rest
ie), call it a Markov model or "chain", or "just lookups", anything you like - but it's more specifically than all those a language model. Embeddings: Where my embeddings differ is that they're kept in a structure reflective of their source context. That's how I know what the meaning of the word is. OpenAI's embedding is like this: Text: "The dog" Embedding: { "object": "embedding", "index": 0, "embedding": [ -0.006929283495992422, -0.005336422007530928, -4.547132266452536e-05, -0.024047505110502243, ... ], } And those values, particularly those for "dog" will be - like you said - computable with others to find things like similarity, etc. And using that math, they can tell you what the next word will be - and probably a lot of other useful chat-specific things I haven't gotten into. My method is also commonly used in machine learning, and would be TF-IDF vectorization except that I don't fully vectorize the semantics, because it's just based on frequency and token structure: { "the": { "dog": { "was": 834, "is": 721, "will": 36 "has": 442 } } } This system predicts "was" as the next word because it usually is the next word after "dog" (in the source data). This library was built to ultimately provide completions, not have a conversation, so no doubt OpenAI's approach works better for chat. I am however already making a chat model. Here's my approach if anyone cares: The completer already gives great completions and fast, but some of them make no sense to what was asked. The chat model I'm working on here (https://github.com/bennyschmidt/llimo/pull/1) can just get all completions and use parts-of-speech codes to match a completion to the cursor. I don't have this fully implemented yet, but you can get the idea in this PR. This is like an NLP layer specific to chat - has nothing to do with the next-token prediction in general, and there are no NLP libraries in `next-token-prediction` (the npm). The example I've been using to explain this is: User: "Where is Paris?" Convert to cursor: "Paris is" Get completions: "in France", "really nice", "a first name", etc. Analyze input: "Where is" refers to a location Analyze completions: "in France" refers to a location Answer: "Paris is in France" I hope it makes sense! Thanks for your comment. Edit: And yes, again, the library does not claim to "be an LLM" - it's not that at all, it's actually a next-token prediction library that has methods like `getTokenPrediction` etc. Though you are set up to build an LLM with this if you train enough data :) The library is not going to provide a `chat` function like GPT, not going to provide an img2img API like Stable Diffusion, that would be whatever chat-based or image-based LLM is being made with this library.
In Show HN: Next-token prediction in JavaScript
_akhe·Apr 11, 2024Recommendation phrase
> enough training data > good chat interface I'm going to try to do that here: https://github.com/bennyschmidt/llimo I totally understand your skepticism, and am also surprised it works so well as a sentence-finisher, even with hardly any data (a handful of books). Think about it like this: If you had a file with billions of sentences: "Paris is in France" "Apples grow on trees" "Gold is worth more than silver" "I know where to go!" etc... Then you can complete virtually any sentence. Say the user enters "Paris" - you can easily find and return "is in France" by simply searching for "Paris" in the text then slicing out the rest of the sentence, "is in France" -- or just give the next word "is" for more of an auto-suggest feel. But if there were 4 sentences starting with "Paris", it gets slightly more complex, now I have to rank them to kn
Read the rest
ow which one is the best suggestion: "Paris is in France." "Paris is nice this time of year." "Paris Hilton liked my post!" "Paris was my favorite city overall." In this case, "is" is still the best because it scores higher than "Hilton" and "was" - because it follows "Paris" more frequently. So in addition to the text file of billions of sentences, I need to make a ranking system to give a point score to every possible word in the file at every possible position it might be in. To make it all faster (because a super massive text file is not feasible), the billions of sentences are not actually represented in a single text file, but as a deeply nested JavaScript object our computers are more optimized to traverse and lookup, along with the point values for each word. At this point, _with enough sentences on file_ with ranked suggestions and fast lookups, you can complete almost anything a user could input. This is what I shared today. > good chat interface To put the sentence-finisher to use as a chat bot, all you need to do is convert the user's question or "prompt" into the beginning of a sentence. For example: "Where is Paris?" -> "Paris is" and let the completer give you "in France". So the answer is: "Paris is in France." Does this make sense?
In Show HN: Next-token prediction in JavaScript
Hell yeah :) At first I thought a simple Show HN titled "Next token prediction in 100 lines of JavaScript" would be cool, but the project grew and now it's a few different modules and things going on. A couple people have basically said "but what does it do?", "what value does it add?" So I am planning a series of examples with videos for use cases like: Auto-completion, auto-correct, spell checking, search/lookup, and if I can get around to making an ImageDecoder, could get into "next-pixel prediction". Beyond prediction, I want to make a YouTube video when I can show a working example of a really good chatbot than anyone can just npm install and use, would be funny to give some of the open models a run for their money - but you're right, it's just a hobby project for now. Working on that in a separate project: https://github.com/bennysc
Read the rest
hmidt/llimo Thanks for the comment and motivation to write about it!
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.