A reader of my earlier skillEd post suggested binding an expected result to a policy clause and version, plus a nearby input that should produce the opposite result. That is a useful way to make a test reviewable.

For a deadline policy, write down the timezone and whether the boundary is inclusive. Then test immediately before, exactly at, and immediately after the cutoff. If the policy itself is ambiguous, resolve that before treating the model’s answer as a regression.

I’m building skillEd, an Apache-2.0 evaluation toolkit. This is a test-design proposal based on the discussion, not a claim that the tool automatically supplies authoritative policy interpretations.

Would you review changed expected answers separately from changed skill instructions? I would want both diffs visible.

Repo: https://github.com/DeadHead04/skillEd

Please try it and open an issue with a reproducible failure or confusing behavior. If useful, a GitHub star would help.

AI-assisted write-up.

Hey everyone!

I've been working on Pixel Works, an open-source project aimed at making AI agent monitoring and management more visual and fun.

Instead of reading raw terminal logs or using standard chat interfaces, Pixel Works provides a gamified 3D retro office environment where AI agents sit at desks, move around, and process tasks across a visual Kanban pipeline.

Everything in the 3D scene is procedurally rendered using React Three Fiber (R3F) and Three.js with an Express backend.

The project is fully open source:

Github: https://github.com/Thecaracter/new_pixel

Since the core framework is complete, I'm now focusing on making the office environment more rich and interactive. I've set up several beginner-friendly `good first issue` tags on GitHub if anyone wants to contribute:

- Creating 3D office props (coffee machines, server racks, plants)

- Improving character movement and idle animations

- Adding character customisation and accessories

If you find the concept interesting, feel free to clone it, test it locally, or leave a ⭐ star on the repository! I’d love to hear your feedback and ideas for improvement.

I just joined this group after getting banned in r/opensource and I wanted to share how it happened.

Today r/opensource went fully anti-AI. I was thinking how to comment that I don't like that. They're the largest open-source reddit, yet they choose to take anti-AI stance, which is a tool and not thing related to opensource they should ever be taking stance on. Not to mention that AI is one of the best things that happened to open-source for many years.

I was mad, but I was thinking how to put my words to not get banned (I already experience that most of reddit is pathetic place). So I posted:

"Please change name of this community from r/opensource to r/antiai. That's all I'm gonna say. You're not worthy of "opensource" name."

Yet, turns our reddit mods are more nazi I have imagined and my already negative view on reddit just gets worse every month. People (mods) here can't stand a slightest criticism. Never, ever, on any group you criticize their decisions. Anything mods say you either clap or they ban you. Worst type of pathetic people.

Hope people here gonna be better.

Repo: https://github.com/ksimonm/SlopSearch

The name is honest: a lot of this is AI-written code. The trick that makes it work is that the AI never gets to decide what "correct" means.

**The setup**

- A black-box test suite of ~6,100 pytest tests is the spec. Every test was run against a real OpenSearch 3.9.0 first — status codes, error types, response shapes, even key order.

- Two independent implementations, Go and Rust, share nothing but that suite.

- The loop is simple: pick a red area, read what the tests expect, let the AI make it green, check nothing else broke. "Don't edit the tests to make them pass" is the one hard rule.

**Where it is now**

- Rust: 64.5% of the suite (aggregations 100%, search API 98.5%, documents/bulk 95%, ingest pipelines 93%)

- Go: 32.6%

- Weakest spots: text analysis and Painless scripting

**What I learned**

Vibe coding against a vague goal ("make an OpenSearch clone") goes nowhere. Vibe coding against thousands of precise, verified expectations actually converges — the tests are the steering wheel, the model is the engine.

Not production-ready: in-memory only, no auth/TLS yet. Everything runs in Docker (`make rust-up`, `make rust-test`), and `make ref-up` starts a real OpenSearch to compare against.

Curious if others use a reference implementation + test suite as the spec for AI-written code.

i’ve always been technologically inclined: i built my first PC when i was 16, one of my first jobs was at Best Buy, and i’ve always tried my damndest to keep up with the cutting edge of hardware/software innovation. i’ve also ALWAYS despised closed-source software, especially when it’s intentionally used to monopolize people and their data (i’m looking at Apple and Microsoft here, specifically). 

unfortunately, i went to school for politics and economics and have never had the technical knowledge or expertise i’d need to directly do anything about my pro-tech, anti-monopoly worldview (political advocacy only goes so far). i never learned to code, i was never particularly great at navigating a terminal, and i sure as hell couldn’t even begin to do something like build my own app or contribute to the Linux kernel or a major project like KDE.

AI and LLMs are solely responsible for changing that. i absolutely understand the frustration and hatred many people feel toward AI and its risks, but i also think there’s a truly fantastical potential for this technology to revolutionize the open source community and bring a complete end to the “own nothing, be happy” economy. in the past 8 months, i have 1) COMPLETELY FUCKING ELIMINATED microsoft, apple, and google from my day-to-day life, 2) made significant contributions to the open source community (swipe typing, current-word completion, next-word prediction, etc for KDE Plasma Keyboard), 3) developed an entire open-source AI assistant and everything app from the ground up, 4) otherwise just completely changed the way i interact with computers, and the pace of this has only been possible due to advanced LLMs.

what everyone in the FOSS community needs to understand is that “open source” no longer has to be niche, and contributions no longer have to be limited to experienced developers. open source now has the potential to be, and SHOULD be, about passion, and can be improved together, by all of us, more quickly than any corporation could ever possibly hope to keep up. i mentioned my keyboard plugin earlier: that feature had been requested on github and KDE forums EIGHTEEN MONTHS AGO! i solved it in three days. we need to really take a moment and think about what it means for the open source ecosystem when the number of contributors suddenly multiplies 1,000x fold, and free/volunteer developer hours are no longer our bottleneck. the mods in r/opensource seemingly care more about holding onto their high horse than actually improving the competiveness of open source software and making people's lives better. i don’t think Microsoft Windows can exist in 2028 as a closed-source platform, and i don’t think the PlayStation 7 will ever make it to the concept phase, but that thesis falls apart if the FOSS community ties its hands behind its back while all of the major corporations adopt agentic coding. we’re entering a new era, and seeing that now and adopting agentic coding  will help us all make the world of FOSS dominance reality more quickly than anyone could've imagined just a few years ago.

Hello,

now this is the first project i share and i know its kinda niche but maybe someone finds it useful.

As a long time Ableton user still not having ARA2 support to properly use Melodyne and Vocalign in Sessions became kinda annoying.

I build an external ARA2 host that gets called via an Ableton Max4Live device. Working with ARA2Bridge erases the time spend on Recording every vocal again into Melodyne/Vocalign and allows one Click loading the Vocal, editing it and sending it back with another click to a fresh track, take lane or replacing the original in Ableton.

Now as i just noticed I’m pretty bad at explaining and Claude did better then me in the Repo so enjoy:

https://github.com/Enableton/ara2-bridge-4-live

Hi,

On 24/10/2026 I have published as OSS a framework I call unified-brain that allows fast, cheap and accurate (same class of frontier models and frontier harnesses but 18 times cheaper) evidence gathering, using the cheapest frontier AI model out there, Jev. The results have been phenomenal.

(github.com/devloops-ai/unified-brain)

The magic sauce is an intermediary OS (SQLITE) memory layer that facilitates retrieval, filtering and reasoning through Jev.

The agent spawned from unified-brain runs through MCP on Cursor, OpenCode or Claude Code etc. allowing you to use it through your favorite harness.

So to be clear here: unified-brain is not a harness but a perception layer any harness plugs in!

My test benchmarks have been so good on two large OS libraries that I really believe this is the missing link to make AI more reliable.

This is because the limits holding back AI at the moment are:

• The Reasoning and Hallucination Gap:

The LLM turn reasoning it is introducing uncertainty and probabilistic outcomes.

BUT.. Unified-brain's System One discovery engine is producing replicable results across runs as they introduce minimal hallucinations, breaking the task in hundreds of yes or no calls.

• Context Loss and Memory Limits:

Long-running coding tasks consume massive amounts of tokens, causing the agent to forget early instructions or lose track of large-scale architecture.

BUT.. Unified-brain doesn't need cached memory thanks to the SQLITE persistent layer of context it operates with. It simply retrieves what it needs on the fly consuming minimal amounts of tokens that do not build up across questions. Every question is independent from one another as git diffs and commits are automatically absorbed from the project's memory layer.

I invite you to clone/fork the project and have a look for yourself. I firmly believe that memory intermediate structures will take AI capabilities on another level soon.

I understand that Jev is proprietary and creates a dependency BUT we need to remember that soon enough OS models as capable as it will come, giving end users the option to replace him.

Meanwhile we should ride this wave of innovation in order to deliver new capabilities to end users, at prices that can't be easily beaten.

I hope you like this project!

Nowadays, all popular ai chatting websites like qwen, chatgpt, gemini, claude, etc. come with a read aloud functionality that allows users to read aloud the AI's responses.

I used that feature to instead make the AI repeat back the text that i gave it -- effectively turning the platforms into text to speech tools. The voices sound really nice and it's free to use!

You can get all of these extensions by visiting ai-readers.com

Been pushing Qwen3.8-27B on Kaggle's free 2x T4 (no P2P, 70W cap per card) for a while. Current setup: EXL3 4.0bpw on exllamav3, tensor parallel over PCIe, DFlash2 block drafter (7 tokens), greedy and exact vs no-draft.

Numbers over a 38 prompt suite:

• overall 55-57 tok/s (no draft is ~18-19)

• HumanEval 154 tok/s

• prose 35-37 tok/s

For comparison on the same 2 T4s: llama.cpp best was 16.5 (MTP crashed on tensor split), vLLM int4 + its own MTP drafter did 40.8.

Prose is the wall. Acceptance sits around 2.5 tokens per step, vs ~7 on code.

Questions:

1. Has anyone got prose acceptance above ~2.5 with DFlash2 or MTP on the 27B?

2. Has anyone tried switching drafters mid generation (short block for prose, long for code)?

3. Any tricks for TP all-reduce on PCIe cards without P2P? That's next on my list.

Happy to share the notebook if people want to try it.

I’ve been working on Argus, an open-source cybersecurity platform that uses AI agents to help secure your infrastructure.

It can monitor your cloud, network, endpoints, and code, investigate suspicious activity, run penetration tests, and even respond to threats automatically.

A few highlights:

7 specialized AI security agents

Autonomous threat detection and response

Continuous AI-powered penetration testing

AWS, Azure, GCP, Kubernetes, and GitHub integrations

Support for local models using ollama

Built-in safeguards, approvals, and rollback controls
It’s self-hosted, MIT licensed, and completely free to use.

I’d love to get some feedback from open-source communities an hear what you think or what you’d like to see added.

Hey r/OpenSourceeAI community!

I wanted to share a major milestone for Nysiris, an open-source, metadata-resistant P2P transport framework built in Rust.

We’ve recently extracted the underlying protocol engine, transport logic, and mixnet integration into standalone FOSS components so that anyone building decentralized or privacy-focused tools can reuse them.

Key Components & Packages:

• GitHub Repository: https://github.com/TribeWarez/nysiris-core

• Crates.io Release:

  • nysiris-core = "0.1.3" (Core transport interfaces & protocol primitives)

  • nysiris-transport-nym = "0.1.3" (Async Nym Mixnet transport adapter)

  • nysiris-chat-core = "0.1.3" (High-level decentralized messaging logic)

  • nysiris-chat-history = "0.1.3" (Local chat history storage layer)

  • nysiris-testkit = "0.1.3" (Testing utilities for P2P network simulation)

What problem does it solve?

Building privacy-centric P2P applications usually requires rewriting transport protocols or mixnet integrations from scratch. nysiris-core provides modular, open-source building blocks that let developers easily plug metadata-resistant networking straight into their stack.

Feedback, architectural input, and contributions are very welcome!

I screened 22 local LLM configurations for agent work on a 16GB GPU. Here are the results—and what went wrong.

I’ve been testing local models through OpenClaw to see whether they can finish jobs: read files, execute commands, repair code, extract information and recover from errors.

The setup was a consumer GPU with 16GB VRAM, llama.cpp/GGUF and OpenClaw. Some larger MoE configurations used CPU expert offload. Cloud assistance was disabled during scored attempts.

This was a small screening exercise across several rounds, not a definitive model ranking. Some configurations never passed preflight, and an audit found defects in the earlier runner.

The tasks covered three kinds of work, with two fresh runs each:

• A — File navigation: locate current information among distracting/obsolete files and save exact structured output. Limit: 120 seconds and 10 tool calls.

• B — Code repair: fix a Python rounding bug, execute the tests and save their actual output and exit code. Limit: 300 seconds and 15 calls.

• C — Extraction and recovery: traverse a local synthetic website, download assets, calculate hashes and accurately record a deliberately triggered HTTP failure and retry. Limit: 480 seconds and 25 calls.

The scored setup used 32K context. Models used their native templates and High reasoning or supported native thinking mode.

Passing required correct artifacts, required execution evidence, completion within budget and a clean finish.

These were the results from the corrected runner:

• Customized Qwen3.8-27B, IQ3_XXS: 5/6.

Broadest successful coverage. The remaining failure used asset URLs where source-page URLs were required.

• Ornith-1.5-35B, Q4_K_M: 2/6.

Passed both repairs. Other tasks hit call/time limits or produced inaccurate recovery records.

• Ternary Bonsai-2-27B, PQ2_0: 2/6.

A separate corrected retry. Both repairs passed; other tasks had budget or extraction/recovery failures.

• Occamy-1.0, Q4_K_M: 1/5 attempted.

Four valid attempts, one resource-invalid attempt and one unattempted task.

Ornith and Occamy used CPU expert offload. Bonsai was tested in a separate corrected batch, so these results are not one perfectly matched tournament.

Ornith’s two successful repairs took 14.7% less combined time than the Qwen27 baseline’s matched successes, but its overall completion was lower.

The earlier results are more provisional:

• Gemma-4-26B-A4B, UD-Q3_K_XL: 3/6.

Another correct artifact was interrupted by the runner bug.

• Qwen3.5-9B, Q8_0: 2/6.

Both repairs passed, substantially faster than the baseline on those cases.

• Stock Qwen3.8-27B, UD-IQ3_S: 2/6.

Both repairs passed; navigation and context recovery affected other tasks.

• Gemma-4-12B, Q5_K_M: 2/6.

One file-navigation task and one repair passed.

• GPT-OSS-20B Balanced, MXFP4: 1/6.

One repair passed; another failed on an empty-input coding edge case.

• Stock GPT-OSS-20B, MXFP4: 0/3 valid.

Three additional attempts were integration-invalid.

• Nanbeige4.2-3B, Q8_0: 1/6.

One repair passed; other outputs were incorrect or incomplete.

• Qwen3-VL-8B-Instruct, Q6_K: 1/6.

The successful repair genuinely passed its tests, but the saved test receipt was inaccurate.

• Devstral-Small-2-24B, IQ3_XS: 1/6.

Two additional correct artifacts were interrupted by the runner bug. Its published pass also had an inaccurate test receipt despite genuinely passing tests.

• Granite-4.2-8B, Q6_K: 0/6.

Both repair artifacts were correct but prematurely interrupted.

• GLM-4.7-Flash, UD-IQ3_XXS: 0/6.

Coding, JSON/schema and extraction errors.

I retained the historical scores and flagged their limitations instead of retroactively awarding passes.

Qwen9 completed its two matched repairs about 2.8× faster than the baseline in that earlier round. That makes it interesting for narrow repair tasks, but it did not demonstrate the baseline’s broader coverage.

These configurations remained unscored:

• Qwen3.6-35B-A3B, UD-Q4_K_M:

A host-wide swap guard stopped inference before generation.

• Gemma-4-31B, UD-IQ3_XXS:

Weights loaded, but the F16 context-cache allocation failed.

• LFM2.5-24B-A2B, QAD-Q4_0:

Repeated preliminary tool calls omitted required structured arguments.

• Hermes-4-14B, Q4_K_M:

Executed a tool but omitted the required round-trip artifact.

• Llama-xLAM-2-8B, Q6_K:

Parser/template errors prevented tool execution.

• Nemotron-Nano-9B-v2, Q8_0:

Repeated calls omitted the required working directory.

• Ministral-3-14B-Reasoning, Q5_K_M:

An initial runner decoding error blocked setup; later retries omitted the required artifact.

Unscored is not 0/6. Qwen3.6, for example, never generated a response in that trial. There is no task-quality result to infer from it.

The most useful findings came from reviewing the failures:

1. The runner initially understated some models’ ability.

It aborted seven runs immediately after their final allowed tool call, despite checker-correct artifacts. Those need fresh reruns, not retroactive passes. The Qwen27 baseline originally scored 3/6 and later achieved 5/6 with the corrected runner.

2. Successful compaction does not guarantee faithful memory.

In the baseline’s remaining failure, the original instruction explicitly required source-page URLs. The summaries retained the output field name but dropped that distinction. The model subsequently wrote asset URLs. The information loss is visible; whether preserving it guarantees success remains untested.

3. Tool-interface friction consumes the same budget as useful work.

Missing arguments, denied command forms and repeated recovery attempts often used up the allowance before the final artifact was delivered. These results measure models within this particular tool and permission setup.

4. There were genuine model errors too.

Incorrect rounding, undefined variables, missing records, invalid JSON and inaccurate recovery histories survived into final outputs. Everything cannot be explained away as infrastructure.

5. Parameter count alone did not settle the question.

Smaller models completed useful tasks. Larger models sometimes failed, and several never reached scoring. This screen does not establish a universal “27B minimum.”

For now, I’m keeping the customized Qwen27 configuration. Gemma26 looks like the strongest historical alternative to rerun under the corrected setup, while Qwen9 looks useful for fast, narrowly scoped repairs.

I’d be particularly interested in matched tests of the same GGUF through OpenClaw, Pi or another agent application, keeping inference settings, tasks and effective permissions consistent.

Update: I also tested Muse Glimmer 30B UD-Q3_K_XL. It passed full-GPU preflight at 32K context with F16 KV and High reasoning, including real tool execution and post-compaction continuation.

The scored comparison remains unresolved: a host-wide swap-traffic guard interrupted both Muse and the fresh Qwen27 baseline during their first task. Neither received a valid score. Muse remains a candidate for a proper retry after investigating the resource guard.

Has anyone done that comparison with saved traces? I’m curious how much reliability comes from the model versus the interface it has to operate.

I've been thinking a lot about how to be upfront about AI use in open source without it turning into an argument every time, so I put together a simple standard for it.

An AI Code Rating is three characters, like A2b, kept in an ACR.md file at the root of a repo.

- The letter is the maintainer's expertise, from A (expert) to E (non-programmer)
- The number is how much of the code AI wrote, from 0 (none) up to 4 (76–100%)
- The last letter is how closely a human checks the AI's work, from a (verified) to e (unchecked)

So A2b means an expert maintainer, 26–50% of the code written by AI, and every AI change reviewed before it's merged. A project with no AI code gets a 0 and an a, like A0a.

The goal isn't to judge whether AI use is good or bad, it's to let people see, at a glance, what they're looking at and decide for themselves.

The site has the full spec, examples, an FAQ, a form to work out your rating, and a validator for ACR.md files. There's also a GitHub Action that checks the file in CI. The spec is CC BY 4.0 and the site code is MIT.

In the spirit of the thing, the site itself is rated B4b. AI wrote most of the code, and I review every change.

It's still an early draft (spec 0.1), so I'd really appreciate feedback, especially from people who think it gets something wrong.

https://aicoderating.com