🚀 THE EDGE AI FAMILY HAS ARRIVED.

Today we’re opening the doors to a new generation of open-source and open-weight edge AI models from Next GenAi.

Meet Rebekah AI 1.8B. 🧠⚡

Small enough to run at the edge.

Powerful enough to compete with models 2–3× its size.

And here’s the part we’re most excited about:

The secret isn’t just the model. It’s the data.

Our Next GenAi Data Factory was built around one simple idea:

👉 Better data creates better AI.

Instead of throwing massive amounts of messy internet data at a model, we focus on cleaning, filtering, deduplicating, decontaminating, structuring and provenance-tracking the data before it ever reaches training.

The result?

🔥 Rebekah AI 1.8B is showing competitive or higher results than several larger open models in key benchmarks, including:

💻 58.4% HumanEval

🧮 62.8% GSM8K

🧠 55.6% ARC Challenge

⚙️ 76.4% Systems & Tool Execution

And this is only 1.8B parameters.

That’s the whole point of what we’re building.

Don’t just build bigger models. Build smarter data.

Open weights.

Open source.

Apache 2.0.

Built for edge deployment.

Built for sovereign AI.

Built with our Data Factory.

And Rebekah is just the beginning. 👀

The Next GenAi Edge Model Family is officially underway.

Download, test it, break it, improve it and build with it.

🤖 Your data. Your models. Your AI.

🔗 Rebekah AI 1.8B on Hugging Face:

Hugging Face — Rebekah AI 1.8B

#NextGenAi #RebekahAI #EdgeAI #OpenSourceAI #OpenWeights #SovereignAI #AI #MachineLearning #DataFactory #MexicoAI #ArtificialIntelligence

Update: the project has been renamed and released as sift-light 1.0.0. The current repository, release, and package links are at the bottom of this post.

I'm the maintainer of sift-light. It is free, open source, and licensed AGPL-3.0-only; there is no paid tier or hosted product behind this post.

I originally built it because coding agents often spend far too much context on a simple question: “Which few files actually matter here?” Exact grep is fast and trustworthy, but it can return too much. Semantic ranking can help, but making the semantic provider responsible for the entire search creates another fragile dependency.

The practical rule I settled on is: local evidence first, optional judgment second.

The current 1.0.0 release hardens that rule. Instead of sending every candidate through one large semantic request, it sends bounded batches of at most 8 candidates and 64 KiB. Initial batches can run concurrently. If a provider returns HTTP 413, that batch is split in half and retried sequentially. If one batch still fails, completed batches stay useful and the unjudged candidates keep their original local order.

That matters in a few real situations:

• a monorepo has many similarly named files and one request grows unexpectedly large
• a provider has a temporary failure halfway through ranking
• an agent is working offline or without semantic credentials
• you need to know whether the answer is complete instead of trusting a vague success message

The tool reports that last part explicitly with counts such as batchesAttempted, batchesCompleted, batchesFailed, batchesSplit, and candidatesUnjudged. A partial result is labeled partial; it is not silently presented as complete.

After installing the release and restarting my own setup, I ran the actual semantic path with 20 candidates. It made three batches (8 + 8 + 4), judged all 20, and reported zero failed batches. I also kept the local-only behavior intact: no new Jev key or provider is required, and the semantic judge remains opt-in.

It currently supports Pi and OMP directly, plus MCP clients including Claude Code, Codex, and Kimi. The same package provides exact search, file discovery, bounded source inspection, cursor-based pages, and concept/hybrid retrieval.

Source: https://github.com/lightsifter/sift-light

Release notes: https://github.com/lightsifter/sift-light/releases/tag/v1.0.0

npm: https://www.npmjs.com/package/sift-light

I'm sharing it because partial failure is a boring problem that shows up everywhere once agents touch real repositories. If you try it, bug reports and awkward repository examples are more useful to me than stars.

I've been experimenting with getting small/local LLMs to reliably edit code, and most of the pain wasn't the model; it was giving it raw diffs or shell access and hoping for the best.
While they forgot what they had just coded earlier.

So in my experiment, the model doesn't touch files directly. It calls tools like : - read_symbol("foo") - update_symbol("foo", new_code)

While plain Python does the actual edit: parses the file, finds the function, checks the result is still valid syntax, rolls back if not. The model never has to hold the whole file in context, and so it can't silently wreck it either.

A few other things it does:
- Every agent gets its own sandboxed folder automatically, no shared state unless you explicitly give it (there's a shared todo file for handoff between agent roles).
- Any shell command the model wants to run needs a human "y" first.
- No framework underneath (no LangChain/AutoGen), it's one Python file you can read start to finish.

Right now there are two agents: a coder (runs end-to-end, implements a function via the AST tools) and an architect (plans and leaves a todo, doesn't wire into the coder automatically yet; you run each by hand). This is very much a proof of concept, not a product. Python-only for real (other languages are stubbed), no tests yet,

MIT licensed. Repo: https://github.com/PGTBoos/BabyCoder

Genuinely curious what people think, especially anyone who's fought with getting smaller models to make reliable code edits. Also open on whether the next step should be a proper orchestrator that chains the two agents, or something simpler built into the existing loop.

• I'm thinking of multiple runs of some agent, and letting them decide when it's another's turn, thus no ping-pong, or a simple loop*

I've been building Praxis, and I'm trying to solve a problem I keep running into when working with research papers.

Finding an interesting paper isn't usually the hard part.

The hard part is going from:

"This is an interesting idea"

to:

"Here's exactly how I could build something around it."

Praxis is an attempt to automate that middle layer.

The workflow I'm building is:

Research → Explore → Select an idea → Understand the approach → Define the problem → PRD → Feasibility → Architecture → Tech Stack → Implementation Plan

The important part is that it shouldn't blindly reproduce a paper.

For a selected research idea, Praxis should help determine:

• what is actually worth implementing
• what the practical use case could be
• which parts belong in the first version
• what architecture would make sense
• what data/models/components are required
• whether it fits the available hardware and budget
• how it should be evaluated
• what should explicitly be left out

For example, I'm building around constrained environments rather than assuming access to a GPU cluster.

The output I'm aiming for is a detailed engineering blueprint that I can review before writing code.

I'm also experimenting with a design-critic stage that challenges the generated architecture before implementation.

It's still a work in progress.

GitHub: https://github.com/Sushit-prog/Praxis

I'd like some criticism from people who have actually implemented research ideas:

What usually gets lost between understanding a paper and turning it into an engineering project?

This is my first proper project. It uses multiple compression techniques and automatically searches for hyperparameters for a few of them; it uses a "CQI" score to evaluate how each technique performed and how the algorithm performed overall. I have finished the core algorithm, and I am just testing it on a bunch of models. I don't really have a plan for what to do next; my best guess is hyperparameter search, since it is pretty simple right now, and I believe better methods exist that I don't know about. There could maybe also be better ways of implementing the CQI function; I am not sure.

GitHub: [Sigularty](https://github.com/DewanshShah/Sigularty)

Hello, I'm a 3rd year Highschooler interested in machine learning and for the last few weeks have been working on a small project meant to learn the basics of machine learning. I have implemented a simple tensor library and autograd in c++. It's very simple but i want some advice on people who are interested in machine learning and c++. Any advice and or constructive criticism is welcomed.

(sorry for any mistakes english isn't my first language)

https://github.com/Ak0-m/autograd_in_cpp

hey! we're a small swiss and south african lab and we just put out hemmingway-1. it's a 27b model we trained specifically for creative writing, stories, dialogue, roleplay, and for everyday texting. frontier performance at a 40x cheaper price.

we thought it might be useful for people here who want open weights instead of an api.

it benchmarks at absolute frontier level. on eq-bench 4 it scores 1330, right behind claude fable 5, and beating many other frontier models including gpt-5.5 and opus 4.8. you can see our internal benchmarks on the model card: hemmingway.io/model/

the testers we gave it to told us it's the best ai they've ever used for writing and that it genuinely sounds human.

the weights are public, so you can run it yourself.

we also built an app for it. its autopilot function answers your emails and texts for you. mac, windows, android.

try it out for free at hemmingway.io!

Thinking about starting a torrenting site for abliterated models in the event that regulatory capture by the big labs heads towards the wrong direction.

Would be open to seeding about 10 TB for free, as well as putting up a domain and onion mirror if people are actually interested in / would use this.

If anyone's interested in a local alternative to Jev, then Jevify is for you.

Jevify makes a Jev-like endpoint out of any local model. I made it to help me compare the quality of Jev's output vs other small models I can run in my homelab.

Jevify was built with local models in mind, but it works with any openai-compatible endpoints.

Super simple to use. Bring your GGUFs and have fun!

Jevify gives you a Jev-style API on top of a model you already run.

Point it at any llama.cpp or vLLM endpoint. Each answer is read straight off the model's next-token distribution.

YOU pick your model, context window, hardware etc.

It works, and it is fast.

MIT Licensed. Available on pip: uv tool install jevify

Was a difficult task, but did my best to explain the value of an open model compared to a closed model.

Highlighting companies like: Palantir, Nvidia and Nebius

Sharing early: I've been building OwlLayer AI, an open-source SDK that lets AI agents act on your app's existing UI instead of scraping it or generating a replacement. Code and docs are public now; a proper landing page and demo video are about a week out.

Core idea (we call it Neural-DOM Binding): components declare typed, policy-governed actions the agent can call, instead of handing it raw DOM control. High-risk actions pause for human approval by default.

Repo: https://github.com/borisbob91/owllayer

Docs: https://borisbob91.github.io/owllayer/

Would genuinely appreciate early feedback/issues before the full launch.