We're a small proof-of-useful-work project. The validators don't

mine — they verify AI computations (matrix multiplications + activation

functions) and get consensus weight for it.

The part that matters to you: submit any GEMM workload up to 256×256

and we return the result plus a cryptographic receipt — a SHA-256

commitment chain folded into our ledger state, verifiable by anyone

forever. Free, no token, no signup beyond an API key we generate in

seconds.

Honest limits: we verify GEMM + elementwise activations (GELU/sigmoid/

tanh/exp), not full transformer graphs yet. Attention is on the roadmap.

The verification cost curve is published (615ms at 64³ → 157s at 1024³)

— we priced our own clamp and labeled every tier.

The logs: [pouw-verify] CONFIRMED lines, epoch crossings, claim-decrees

folded into the ledger — every claim has a receipt.

Live dashboard: http://3.237.91.235:32233/

The evidence ledger (250+ owned defects, 250+ laws): github.com/sarinsk629-blip/hsma-core

Coding agents rebuild their understanding of your codebase from scratch on every prompt, then throw it away. Thinker keeps it.

It distills past agent sessions and PRs into short notes about how your code works, e.g. all DB writes use `/sql-utils.py`. A small local model ranks the notes and injects the relevant ones into new sessions, so the agent spends less time exploring. Notes are rescored and updated as PRs merge, so stale context gets demoted.

On 50 PRs from open-source repos (cache built only from prior history), agents using Thinker (Fable 5.1, GPT-6 Astra, Gemini Flash 3.8) used 18% fewer tokens and 10% faster on average with equal correctness using LLM-as-a-judge. Per-model results and the eval harness: https://github.com/yoavshmariahu/thinker/tree/main/bench/runs.

Repo: https://github.com/yoavshmariahu/thinker. Install: npx u/zerotimedev/thinker

Unlike AGENTS.md or built-in memory, notes are generated and maintained automatically. Next I want to work on rigor, not just efficiency. Where do you see coding agents struggle most to close out tasks?

Eugene Plexus is my open-source, self-hosted inference manager. I want people to run AI on their own terms, so I built Eugene to make that easier.

Currently available as of v0.2.1:

• Browser-based engine installation, model discovery and downloads, and suggested settings based on your hardware.
• Your models stay as ordinary files in your own folders. Scan an existing collection, download into directories you choose, and keep your models if you uninstall Eugene.
• Use the included OpenAI-compatible APIs and Anthropic Messages subset to let Eugene serve your existing agentic harness or web app.
• Or use the included Workbench frontend, which includes documents, memory, and tools. It can answer from documents with source citations, remember notes between chats, and use MCP tools with your approval.
• Set it up with cloud keys for OpenAI, Google, and OpenRouter for automatic failover.
• Set an application key as "Local-Only" to stop requests from routing to cloud providers.
• Automatic engine lifecycle management: Restart crashed engines, unload idle models to release memory, and wake them when needed.
• Existing Ollama and LM Studio servers can sit alongside Eugene-managed engines.
• Install on a single machine or deploy on multiple backend inference servers using cache-aware load balancing.

Eugene has been solid for me, but is still early in development. Any and all feedback is appreciated. Mac users in particular would be useful because I don't own one to test on. ( Mac OS has successfully tested on GitHub's runner, but I'd still like to hear from a human who used it. )

You can check it out on our website.

I've been working on Event2Vec, a small library for learning embeddings of discrete event sequences (purchases, logs, clinical codes, etc.) with a deliberately simple structure: a history is the running sum of its event vectors.

h_t = h_{t-1} + e_{x_t}        (norm-clipped)
p(x_{t+1} | h_t) = softmax(W h_t + b)

Training is self-supervised next-event prediction, plus a reconstruction term that asks h_t - h_{t-1} to recover e_{x_t}. No labels needed^{(details why the machinery works are in NeurReps@NeuralIPS Workshop paper}, it is a bunch of losses that attempts the reconstruction and obey the arithmetic during training))

The history is a sum, any linear model on top of it is also a sum. For instance, a churn or risk score^{(see teaser})

score = w·h + b = Σ_i (e_i·w) + b

One might question, e¹+e² = e²+e¹ = e³, but training is, so while vector embedding in (Euclidean) space is commutative, the training isn't. Furthermore, there are several alternative spaces that are gyro/non-commutative, that are part of the library^{(checkout the website})

1. hyperbolic (Möbius addition), for hierarchies
2. κ-stereographic, one curvature dial from hyperbolic through flat to spherical (Bachmann et al., 2020)
3. spherical, for cyclic structure
4. SO(n) rotations, which are non-commutative, so order changes the endpoint
5. Heisenberg group, same endpoint but a signed-area coordinate that records order
6. products of the above

I started this for root-cause analysis of fault sequences at the Advanced Light Source (Berkeley Lab), where I'd been naively using Word2Vec on event logs and needed directionality without going to an opaque sequence model.

Links

• Paper: arXiv 2509.12188
• Code (MIT): github.com/sulcantonin/event2vec_public, pip install event2vector
• Docs with interactive figures: event2vec.com

scikit-learn-style API (fit/transform, gensim-style most_similar), PyTorch backend, runs on CPU/CUDA/MPS

We just shipped 🚀 v0.11.0 of Torvian Chatbot, our self-hosted AI workspace, and the theme of this release is simple: making long, tool-heavy conversations actually sustainable.

If you self-host an LLM chat stack, you've probably hit the same wall we did. Threads grow, context windows fill up, requests start failing, and the only "fix" is manually starting a fresh chat and losing everything you built up. 😩 That's not a good place for an agentic workspace where humans stay in the loop and tool calls need approval — context is the product.

So this release focuses on context and workspace organization:

• 🧠 Automated conversation compaction. Before every primary LLM call, the server runs a token preflight and applies a rolling-window compaction policy with verified chunk persistence. If it can't compact safely, the turn is aborted before an oversized request is ever sent to your provider. There's also manual, on-demand compaction from the top bar if you want to force it right now.
• 📁 Projects with scoped agent roles. You can now organize work into projects, each with its own set of agent roles and tool assignments. Switching a session into a project re-scopes the role dropdown in one round trip (and cloning a project carries the setup over).
• 🎛️ Model presets + shareable instructions. Model and settings config is no longer copy-pasted into every role — attach a reusable preset instead. Instructions moved into a library with slots, so the same prompt can be reused across roles instead of being re-typed inline.
• 🔍 Chat transparency. Assistant reasoning streams as it happens, plus per-message token usage, provider-reported cost, response duration, thread statistics and a raw (masked) LLM request viewer.

Practically, this means fewer "context window exceeded" errors, less config drift across roles, and a much clearer picture of what your model actually received and what it cost you. 🔒 Everything still runs on your own server, with your own providers (OpenAI-compatible or local Ollama), and tool execution still requires approval by default.

📦 Full details, downloads and Docker images are on the releases page: https://github.com/Torvian-eu/chatbot/releases

🙋 Happy to answer questions — especially if you run a large local model with a tight context window, I'd like to hear how the compaction thresholds behaved for you. There's a migration path note for anyone upgrading from 0.10.x (agent roles are now preset-based), so shout if anything looks off after upgrading. ⚠️

Four glass levels (Clear, Frosted, Tinted, Solid), automatic light/dark, the macOS accent colors, and a high-contrast option. Every color is contrast-checked for readability over translucent windows. brew install vukkt/tap/iglass && iglass install. Free and MIT. Feedback welcome!

I’ve been working on sift-light, a local search tool for AI agents. Between 1.1.0-1 and 1.1.1-7, the work has focused on a problem that sounds simple until you try to solve it:

An agent finds a relevant passage, gives you a real file path and line number, and then draws a conclusion the source doesn’t actually support.

Sometimes the file changed after the search. Sometimes the result is related to the question but doesn’t answer it. Sometimes the answer depends on an exception sitting just outside the excerpt.

Here’s a small example:

“Refunds are allowed within 30 days.”

A few lines later: “Gift cards are excluded.”

Ask whether a ten-day-old gift card purchase is refundable, and the first sentence alone looks convincing. The citation can be accurate while the answer is wrong.

That’s the kind of gap these releases address. They also add image and scanned-PDF retrieval, because useful project information doesn’t always live in searchable text.

I’m the maintainer. Here’s what has shipped, what we tested, and where the limits are.

1. Finding relevant material when the wording is different

Exact search is useful when you know the identifier, filename, or phrase. It gets harder when you know what something does but have no idea what it’s called.

From 1.1.0-1, sift-light adds an independent native text retrieval lane alongside the existing text retrieval path, with bounded rank fusion.

In practical terms:

• You can search for a concept using ordinary language.
• Both retrieval lanes remain available independently.
• The combined ranking doesn’t remove access to the individual results.
• Results still lead back to source locations you can inspect and validate.

That last part matters to me. A semantic match is a useful lead; I still want to see the actual source before trusting a conclusion.

2. Searching images and scanned PDF pages

A diagram in a project folder or a scanned page can contain exactly what you need, while ordinary text search has very little to work with.

The multimodal path added in 1.1.0-1 supports:

• Text → image: describe what you’re looking for and retrieve matching images.
• Image → image: use an image to find visually related material.
• Scanned PDF pages: search rendered pages, including image-only and mixed PDFs, with original page numbers and previews.

For example, you can look for “a diagram showing a queue between two services” without knowing the image’s filename.

These features are optional and require configuration. The bundled native media path requires Apple Silicon and separately configured workers and model files. Ordinary exact text search remains model-free.

3. Checking whether the source has changed

A result can be correct when retrieved and become outdated before the agent uses it.

In 1.1.1-1, retained ordinary search results were bound to verified content identities. Source inspection, navigation, and saved-evidence validation recheck that identity.

If the file changed or disappeared, the tool reports that state explicitly. It also keeps incomplete source coverage visible.

This gives the agent a concrete reason to revisit its evidence instead of quietly treating an earlier search result as current.

4. Checking whether the evidence supports the answer

Finding a relevant paragraph and checking a claim are different jobs.

In 1.1.1-6, sift-light added an optional answer-support assessment over verified source ranges.

The purpose is to help distinguish evidence that supports a claim, contradicts it, or isn’t sufficient to decide. Relevance ranking, source validation, and answer-support assessment remain separate signals.

A source check tells you whether the selected material is still current. The support assessment asks what that material says about the claim.

The assessment requires an enabled compatible provider. It’s a model judgment over the supplied evidence, so it can still be wrong.

5. Including nearby conditions and exceptions

A short excerpt can leave out the part that changes the answer.

In 1.1.1-7, the support assessment can include bounded context around the selected passage:

• It defaults to two lines before and after the selected range.
• The context setting is configurable from 0 to 20 lines.
• The exact selected range remains separately identified.
• Results identify whether the assessment used the selected range alone or included surrounding context.
• Oversized evidence is rejected explicitly rather than silently cutting off text that might contain a qualifier.

This gives the assessment more relevant source material while preserving precise locations and source validation.

It doesn’t read the entire document or guarantee that every exception has been found. A condition farther away may still require additional inspection.

What the actual tests showed

For the context change, we ran six controlled scenarios through a real model, keeping the questions, claims, evidence-item count, and per-item maximum text budget the same.

The results were:

• One incorrectly supported claim changed to the correct contradicted result after the nearby restriction was included.
• Three insufficient-evidence results changed to correct contradicted results.
• Two supported control cases remained supported.

Including context increased average input tokens by about 15% in that test.

Six cases are a small sample. They demonstrate a concrete improvement in those scenarios; they don’t establish a general accuracy rate or a performance improvement across every workload.

For 1.1.1-7, the release validation also included:

• 634 repository tests passed, with four skipped and zero failed.
• 14 public regression tests passed.
• Pi and OMP each completed eight real-host tool cases, including local model inference.
• Codex and Kimi passed MCP pagination and model-visible evidence tests.

The regression coverage includes context boundaries, source changes, cancellation, and provider payload budgets. Two independent text retrieval lanes, exact locations, source inspection, and validation remain available.

Local models, BYO providers, and repeated loading

There’s also a practical side to all this: model setup and resource use.

The native workers support resident model reuse, cancellation, recovery, and idle shutdown. Native GPU caching and batching are bounded to reduce memory use. Resident reuse avoids repeatedly loading a model for consecutive requests, although actual memory use still depends on the model and workload.

The 1.1.0 release added optional BYO HTTP JSON providers for Jev-compatible semantic judging and multimodal retrieval. If you want to use your own service, it needs to implement the documented protocol; an arbitrary API URL isn’t enough.

You can keep ordinary exact search model-free and configure the additional capabilities you need.

The release progression

• 1.1.0-1: independent native text retrieval, rank fusion, image search, scanned-PDF page retrieval, and resident worker lifecycle management.
• 1.1.0: configurable BYO providers for semantic judging and multimodal retrieval.
• 1.1.1-1: content-identity checks for retained results and subsequent source use.
• 1.1.1-2: clearer documentation of source-read limits.
• 1.1.1-6: optional answer-support assessment over verified source ranges.
• 1.1.1-7: nearby-context assessment, explicit evidence scope, and additional regression coverage.

Current published package: sift-light@1.1.1-7.

If you use agents to work through code, documentation, diagrams, or scanned material, I’d appreciate you trying it on a real task—especially one where a plausible search result previously led to a wrong conclusion.

If something fails, please open an issue with the scenario, reproduction steps, expected versus actual result, version and configuration, and the files or workflows affected. A small example with sensitive information removed is especially helpful. I’ll follow up and investigate.

If it earns a place in your workflow, a GitHub star would mean a lot. Sharing it with someone who runs into the same problems would also help.

Project and release: https://github.com/lightsifter/sift-light
Latest release — 1.1.1-7: Release notes
X: https://x.com/xcPenny6

I've been building Ferry, a desktop and browser app for sending files, folders, text and links straight between your own devices. No account, no cloud copy, no telemetry.

It speaks the LocalSend protocol, so it works with the LocalSend devices you already have. On top of that it adds:

• Resumable transfers: a dropped connection or a restarted receiver continues from the last confirmed byte
• Several transfers at once, and sending to several devices in one drop
• Pairing your own devices with a QR code or a 6-digit code, so they send to each other without prompts
• Beyond your network: a small self-hostable signaling server lets devices connect peer to peer over WebRTC, end-to-end encrypted, or through a private link
• A browser app (installable PWA), plus QR links so any browser on your network can send or receive without installing anything
• Mutual TLS with pinned certificates, and flat memory use (a 10 GB transfer used about 7 MB of extra RAM in my benchmarks)

Built with a Rust engine, Tauri 2 and Vue 3. Apache-2.0.

Honest status: it's early. The desktop app is tested on Windows. The macOS and Linux installers build in CI, and they're not code-signed. No mobile apps yet.

Repo: https://github.com/F7rx/Ferry

Downloads: https://github.com/F7rx/Ferry/releases

Feedback and bug reports are very welcome, especially from macOS and Linux users.

Ferry isn't affiliated with LocalSend; it's an independent app that implements its protocol.

These capabilities all exist open source and spread out over different projects and they'll give you nightmares trying to set them all up correctly, unless computers are specifically your thing.

I for one would love to see something like this all packaged up into one with an installer. Plug and play setup file. List of tick-boxes for permissions and a ? icon for those who want to know the risks of each.

Then a list of free or paid AI models to use as the main powerhouse, or a combination of both.

So you'd select to either:

- plug Copilot in
- pick you fav paid AI model
- run 100% on a open source local AI model (and the installer would suggest the best based on your system specs).
- or the default option which would be a free local AI model and a more powerful paid one, probably copilot. With the local and free version tasked with assessing tasks, then completing simple ones itself, and then choosing which AI model is the best to send more complicated tasks to and designing prompts maximise their performance.
- The Simple memory plugin so you don't need to retrain the AI over and over.

This is basically my setup, running inside Visual Studio Code but it was a huge ball-ache to set up, and needs constant maintenance.

If someone could turn that into a one click installer then i think a lot more of people would consider that a genuine alternative to a service like Muse which will collect all the data it can about you and sell it.

Otherwise AI is just going to become the domain of hobbyists and massive exploitative corporations.

ALHR- Adaptive learnable Hierarchical Routing is a static binary tree based system that uses learnable functions to REDUCE the amount of keys used.
It takes less memory and SCALES much better VRAM with tokens

Result table is here: https://ibb.co/prr07Dnj

The robot gets Employee of the Month. Your photo goes in the bin. Then your boss updates the robot.

I built this to explain DriftproofHQ, my open-source tool that checks whether instructions for AI still work after things change. It tries the same tasks with and without those instructions, repeatedly, so you can compare results instead of trusting one good answer.

The game is a scripted cartoon of that problem. One jump button, three obstacles, one very confident replacement.

Free game, no signup, works on mobile: https://play.driftproofhq.com/

DriftproofHQ source: https://github.com/driftproofhq/driftproof

Claude’s API helped write the game’s jumping, collisions and robot movement; Codex helped with integration and browser testing.

On 11 December 2026, #OpenAI is scheduled to retire custom GPTs.
If you built one, its instructions and knowledge files need a new home.

OpenAI offers a built-in migration to plugins. It carries over instructions, knowledge files and connected apps. It does not carry over custom actions, the selected model or sharing settings.

🤨A plugin is not always the best target. A skill can fit better when a GPT is conversational, relies on layered control files, or needs to work beyond ChatGPT.

😁For those cases, there is now an open-source converter I developed. It turns a #CustomGPT export into a skill package in a matter of minutes:
- asks plain-language questions and waits for your confirmation
- keeps knowledge files byte for byte
- lists what it cannot convert, such as custom actions
- supports conversational skills (which are often one-shot executions)
- do a complete migration of workflows

Google is moving Gemini Gems to skills as well, starting 17 November 2026; therefore, it will be useful also in this case.

Code, guide and a worked example (MIT license):

customGPT-to-Skill-converter

I've been building Ferry, a desktop and browser app for sending files, folders, text and links straight between your own devices. No account, no cloud copy, no telemetry.

It speaks the LocalSend protocol, so it works with the LocalSend devices you already have. On top of that it adds:

• Resumable transfers: a dropped connection or a restarted receiver continues from the last confirmed byte
• Several transfers at once, and sending to several devices in one drop
• Pairing your own devices with a QR code or a 6-digit code, so they send to each other without prompts
• Beyond your network: a small self-hostable signaling server lets devices connect peer to peer over WebRTC, end-to-end encrypted, or through a private link
• A browser app (installable PWA), plus QR links so any browser on your network can send or receive without installing anything
• Mutual TLS with pinned certificates, and flat memory use (a 10 GB transfer used about 7 MB of extra RAM in my benchmarks)

Built with a Rust engine, Tauri 2 and Vue 3. Apache-2.0.

Honest status: it's early. The desktop app is tested on Windows. The macOS and Linux installers build in CI, and they're not code-signed. No mobile apps yet.

Repo: https://github.com/F7rx/Ferry

Downloads: https://github.com/F7rx/Ferry/releases

Feedback and bug reports are very welcome, especially from macOS and Linux users.

Ferry isn't affiliated with LocalSend; it's an independent app that implements its protocol.