r/OpenSourceAI

Hi, i built this agentic ai,

Closed-loop system that ships standalone Python agents.

What's different:

- Interviews you until it understands the request before building anything

- Two testing stages: prompt validation via LLM invoke, then real subprocess execution of generated code. Not the same thing.

- Self-referential: injects its own source as a reference template for generation

- Structured rating schema drives iteration. Human approval gate before anything saves.

Runs on Qwen3.6-35B a3b Q8_0 locally.

https://github.com/0c33/Agentic-Ai

Give a shot and tell me what do you think.

The sequence is always the same: registry launches and grows fast, minimal vetting because the priority is growth, first wave of incidents, community outrage, tooling catches up, security becomes a baseline expectation. npm took about three years to go from event-stream to npm audit being standard. Docker Hub took similar.

MCP is at step 2 heading into step 3. The numbers from a scan of 500 Smithery servers this month: 18.8% had security findings, 6 had live hardcoded credentials, none were caught by a pre-publication scan because there is no pre-publication scan. A Check Point research disclosure in February showed an 8.7 CVSS attack chain against Claude Code where the entire payload was natural language in a config file.

The difference from npm is what the malicious content does. An npm package executes unauthorized code. A malicious MCP skill file gives unauthorized instructions to an agent that already has access to your tools, file system, and APIs. The LLM cannot distinguish between instructions from the user and instructions from a skill file. Both arrive in the context window and both get acted on. Existing security tooling has no model for this.

The fix is the same three layers it always is: pre-publication registry scanning, CI integration for consumers, and a public advisory database. None of the three exist yet in any mature form for MCP.

Whether the timeline is one year or three depends on whether registry operators move proactively or wait for a sufficiently public incident. Based on how npm and Docker played out, my bet is on the incident coming first.

We built a static scanner for this: pip install bawbel - scans skill files and MCP server configs without executing anything. The vulnerability database it checks against the AVE.

`🧬 Flux‑Genotype – A CPU LLM that rewrites itself`

I've been working on an open-source kernel called **flux-genotype**. It orchestrates local models (TinyLlama, Llama 3.2, Hermes 3, DeepSeek-Coder) into a self-modifying ecosystem. Everything runs on **CPU** — I tested it on a Xeon without AVX2, 20 GB RAM.

> **Important:** this is an alpha. It works, it mutates, it evolves — but there's a lot of work ahead. The **MetaDesigner**, in particular, is the module I'm focusing on next. Right now it proposes architectural changes by writing new `.flux` files, but the validation and application pipeline needs to be more robust. The vision is to make it fully autonomous: an external architect that watches the ecosystem, diagnoses weaknesses, and rewrites the structure to improve confidence. It's not there yet, but the foundation is solid.

## How it works

1. Ask a question → fast model (TinyLlama) answers.
2. Judge model evaluates the answer (0–1). Initially this was Llama 3.2.
3. If confidence drops below the golden ratio threshold (≈0.618), the ecosystem mutates its own structure.
4. A **MetaDesigner** (Hermes 3) writes new `.flux` architecture files, which get validated by a Lark parser and applied.
5. The system tracks confidence history with EMA and adapts temperature dynamically.

## Real example of self‑modification

The mutation can also replace the Judge. During one of the growth cycles, the MetaDesigner proposed swapping the Judge from **Llama 3.2** to **DeepSeek-Coder 6.7B**. The new configuration was tested, scored better, and the ecosystem applied the change permanently.

The system is not just tweaking parameters — it's rewriting its own **division of labor between models**.

## Why this is different

- It mutates its own architecture, not just model weights.

- It can replace its own Judge with a different model if performance improves.

- It has memory (confidence history with Exponential Moving Average).

- It uses a custom language (`.flux`) with a formal grammar — not YAML, not JSON.

- It runs on modest hardware. No GPU. Just a CPU and 20 GB of RAM.

## If you want to understand the architecture deeply

I wrote a **technical manifesto** that defines FLUX as a formal Architecture Description Language for self-evolving cognitive ecosystems. It covers the fractal design, the OODA loop, the role of the golden ratio, and the long-term vision (including the MetaDesigner). It's in the repo:

📄 `/papers/FLUX-Kernel.pdf`

## The companion novel

There's also a novel called **"IF THIS IS A ROBOT"** (in Italian and English, CC BY-NC-SA 4.0) that tells the story of a guy who finds this kernel running on a forgotten server. The novel is basically the kernel's manual. But the code stands on its own.

## Links

- **Repo:** [github.com/flux-genotype/nodo_zero](https://github.com/flux-genotype/nodo_zero)

- Kernel is **MIT-licensed**. Novel is **CC BY-NC-SA 4.0**.

Happy to answer questions, and **open to collaborators** who want to help push the MetaDesigner forward.

https://preview.redd.it/e5mlrb1pby1h1.png?width=1650&format=png&auto=webp&s=96b31df64005a0d96a4e5900cd5c8dd39426e013

I've been building Kasetto: a single Rust binary that takes one YAML config and syncs Skills and MCP servers into every AI agent on your machine or your teammates' machines. Supported: Claude Code, Cursor, Codex, Windsurf, Copilot, Gemini CLI, and more.

Sources can be GitHub, GitLab, Bitbucket, Codeberg, Gitea, self-hosted instances, or local directories. MCP configs are auto-merged into the right format per agent so you don't have to hand-edit four different settings files every time you add a server.

The core idea: the YAML is the source of truth. Version it, share it, bootstrap a teammate's whole agent setup in one command. No registry, no boilerplate — any directory with a SKILL.md is a skill.

>Inspired by uv - what uv did for Python packages, Kasetto aims to do for AI skills.

What it gives you:

• Declarative - one YAML describes your entire setup. Version-controlled, readable, auditable.
• Multi-agent - Claude Code, Cursor, Codex, Windsurf, Copilot, Gemini CLI, and more. One config, every agent updated.
• Enterprise & private repos — GitHub, GitLab, Bitbucket, Codeberg, Gitea, and self-hosted instances out of the box.
• Skills & MCP - any directory with a SKILL.md is a skill. MCP server configs are auto-merged into every supported format (Cursor JSON, Claude JSON, Copilot VS Code, Codex TOML).
• Fast - written in Rust. SHA-256 content hashing and lock file diffing mean only what changed gets touched.
• Universal - single static binary for macOS, Linux, and Windows. Install as kasetto, run as kst. CI-friendly with --json output and proper exit codes.

A kasetto.yaml looks like this - multiple agents, multiple sources, pinned refs/branches, per-skill paths, and an optional extends: for inheriting a shared team base:

# inherit a shared base config — overrides merge on top
# extends: github.com/acme/kasetto-base/raw/main/kasetto.yaml
agent:
  - claude-code
  - cursor
  - opencode

scope: project # or global
# destination: ./.agents/skills  # optional, override install path

skills:
  - source: github.com/acme/frontend-pack
    skills: "*"

  - source: gitlab.com/team/internal-tools
    branch: master
    skills:
      - react-patterns
      - go-standards

  - source: codeberg.org/oss/shared
    ref: v2.1.0
    skills:
      - name: custom-lint
        path: rules/custom-lint
      - name: format-helpers
        path: rules/format

mcps:
  - source: github.com/acme/mcp-pack
    mcps: "*"

  - source: github.com/acme/monorepo
    ref: v1.4.0
    mcps:
      - github
      - linear

Running it:

# uses ./kasetto.yaml in the current directory
kst sync

# or point at a shared team config over HTTPS
kst sync --config https://example.com/team-skills.yaml

Want bare kst sync to always pull from a remote URL? Persist it once in ~/.config/kasetto/config.yaml:

source: https://github.com/pivoshenko/pivoshenko.ai/blob/main/kasetto.yaml

After that, kst sync resolves the URL automatically — no --config flag needed. Then to see what landed:

kst list      # interactive browser with vim-style navigation
kst doctor    # version, paths, last sync status

For a real, runnable example: pivoshenko/pivoshenko.ai is my public config — it pulls skills from Anthropic, Vercel Labs, Apollo, and a few independent authors into Claude Code and OpenCode. Fork it, point your own config at it with extends:, or use it as the source: above.

Install:

curl -fsSL kasetto.dev/install | sh
# or: brew install pivoshenko/tap/kasetto
# or: cargo install kasetto

Docs: https://kasetto.dev

Repository: https://github.com/pivoshenko/kasetto

Happy to hear feedback, especially from anyone juggling skills across multiple agents or sharing setups across a team.

Got frustrated reinstalling ComfyUI every time I rented a GPU. Custom nodes, models, configs every session started with 45 minutes of setup before I could actually generate anything. Docker images got stale fast and different providers have different base images so nothing was truly portable.

So I built swm. It's a CLI that handles GPU rental and setup across 10 cloud providers.

For ComfyUI specifically:

• swm gpus -g a100 --max-price 2.00 --sort price shows you the cheapest GPU across RunPod, Vast ai, Lambda, and 7 others
• swm pod create — spins up whatever's cheapest
• swm setup install comfyui — installs ComfyUI on the pod
• Your whole workspace (custom nodes, models, outputs, everything) syncs to S3 so next session you just pull and it's all there. No starting from scratch every time.

The other thing that's saved me a lot of money is the lifecycle guard. It watches GPU utilization and if nothing's happening for 30 minutes (configurable), it saves your workspace and terminates the instance. I used to fall asleep or get distracted mid-session and wake up to stupid bills. Doesn't happen anymore.

It also works with vLLM, Ollama, Open WebUI, SwarmUI, and Axolotl if you do more than just SD.

Free, open source, Apache 2.0. pipx install swm-gpu

Site: https://swmgpu.com GitHub: https://github.com/swm-gpu/swm 

Curious if anyone else has been dealing with the same setup-every-time problem or if I'm the only one who was doing it wrong lol. Open to feedback on what to build next.

I'm trying to keep costs reasonable while still having something reliable enough to leave running all day. curious what VPS providers people here recommend for balancing simplicity and uptime. is hostinger 1-click openclaw a good option if not then i would need some more insights help your girl out hahah im desperate to make this work

Hi everyone,
I've been following the local LLM scene for a while, but I lack the deep technical background in C++ or low-level CUDA programming to understand the inner workings of quantization frameworks.
Recently, I’ve been reading about **TurboQuant** and its performance claims. I know there are repos out there with implementations, like the one by **TheTom**, but it got me wondering: **Why hasn't it been integrated or ported into the main llama.cpp project yet?**
Is there a fundamental architectural incompatibility between how llama.cpp (GGML) handles inference and how TurboQuant is designed? Or is it simply a matter of community priority, given that formats like GGUF (with IQ/Q quantizations) are already highly optimized and widely adopted?
Thanks for the answers!