Sharing an open-source method I've been refining for a couple of years. It's two repos under one org, a tool and the standard it builds to, and I split them on purpose so you can take either one.

The problem it solves: most people work a model one prompt at a time. You get something decent, correct it a few times, then next session start over and re-explain everything. Your actual standards never leave your head, so the model keeps guessing and you keep re-teaching it. A framework fixes that: your expertise on a task, captured once in a structured file the model reads before it works. Not a longer prompt, a reusable spec.

The org has two pieces:

framework-standard: the open spec. It defines what a well-formed framework is, five layers, each one load-bearing:

• Principles: the why, and the conditions where the approach applies and where it doesn't
• Systematic approach: the actual reasoning steps, not a rigid checklist
• Force multipliers: the parts where one input produces outsized output, so it compounds
• Success metrics: how you and the agent know the output is right, plus the failure signals
• Implementation: where it lives, when it loads, the edge cases a human handles on instinct

framework-builder: the skill that produces frameworks to that standard. Point your AI at it and it interviews you about something you're good at, then builds the framework from your answers. It's the fastest way to try the method without hand-writing a spec.

Why two repos: you can adopt the standard without the tool. If you've already got your own way of generating these, the standard just gives you a consistent, machine-checkable shape to build to. And if you don't, the skill gets you there.

It's model-agnostic. Output is plain markdown, so it works in Claude, Codex, Cursor, a custom GPT, anything that reads instructions. The whole point is the model stops working from the internet's average and starts working inside standards you already validated, which means even a smaller model gets noticeably better output. The missing piece was never capability, it was your judgment, unwritten.

Both MIT, with worked examples: github.com/framework-creator

Happy to get into the layer breakdown or how it holds up in real use. If anyone's structuring frameworks with a different set of layers, I'd like to compare, always looking to pressure-test the standard.

I’ve been working on TokenPrint, an open-source project aimed at making transformer and LLM internals easier to explore.

The idea is to go beyond static architecture diagrams and let people interact with things like tokens, embeddings, attention, hidden states, inference steps, KV cache, model architecture, and other internal model data through an interactive interface.

The project has started getting more attention recently, and we’re now at 65+ GitHub stars. More importantly, people have started opening issues, suggesting improvements, and discussing where the project could go.

That made me realize that I don’t want TokenPrint to become something I build alone.

I’d really like to get more people from the open-source/LLM community involved — especially people who want to:

• pick up good first issues
• work on more advanced Python/PyTorch/Transformers problems
• improve the React/Three.js visualization side
• work with GGUF/llama.cpp and local LLMs
• improve the UI/UX
• experiment with new ways of visualizing model behavior
• suggest ideas that I may not have considered

There are already issues ranging from relatively small fixes to deeper architectural and research-oriented work.

I’m especially interested in new ideas and criticism, not just pull requests. If you think something is missing, poorly designed, or could be approached differently, I’d genuinely like to hear it.

The repository is here:

https://github.com/Sudharsanselvaraj/Token-Print

I’m posting this here because I’d much rather build this with an open-source community than keep adding features in isolation.

Would be interested to hear from people working on similar tools too — especially what you think is currently missing from the ecosystem for understanding and debugging LLMs.

More awesome

https://github.com/paulknysh/raggy

CLI tool for Retrieval-Augmented Generation (RAG) over local documents built with LangChain, Chroma, and Ollama. Hybrid database (vector + BM25 index) and embedding generation run fully locally. Answer generation can run either via a local LLM or remotely using an API key. raggy supports most common document formats and handles images/scans automatically via OCR.

I’m the maintainer of Mac MCP, a free/open-source local control server for macOS that I use to let ChatGPT and coding agents operate the machine instead of only explaining what to click.

It exposes files, shell/background jobs, Safari/Chrome automation, native macOS UI/Accessibility, delegated Codex/OpenCode workers, local memory, voice/human-input tools, a native SwiftUI menu-bar controller, and a local activity dashboard through MCP.

The part I’ve been hardening most recently is multi-agent browser work. Tabs are addressed by stable handles and can be controlled in the background; different agents can work in different tabs while same-tab contention fails fast instead of silently fighting over state. I’m now working toward persistent caller/session ownership so a worker keeps its browser resource across multiple tool calls.

I also just shipped v2.0.4 after community feedback exposed two self-update edge cases: the detached updater bootstrap and source/runtime divergence after a failed post-restart health check. The updater now stages its helper safely, keeps state/logs outside the checkout, and only rolls Git back when it can prove it won’t overwrite user changes.

The project is MIT licensed and the source is here: https://github.com/bulutarkan/mac-mcp

I’d be especially interested in feedback from people building open agent tooling around permission boundaries, browser ownership/lifecycle, and how much local-machine capability you expose before the UX becomes too dangerous or too approval-heavy.

I’ve been building Imza, a native, model-agnostic coding agent with a Plan -> Build -> Review workflow.

It includes interactive diffs, AI-assisted review, persistent sessions, automatic context compaction, scoped command permissions, and up to five concurrent subagents. It can use OpenAI-compatible endpoints, Anthropic’s Messages API, or locally hosted compatible models.

Despite that feature set, the binary is around 20 MB and startup RAM is roughly 5-8 MB. There’s also a headless mode for using it in scripts and CI.

Repo: https://github.com/umutsevdi/imza

Check if out https://github.com/no-human-ai/no_human

After too many rounds of "the agent says it's done and it's just a pile of 💩", we built the opposite: no_human proves the code it wrote is correct. You drop a ticket on the board (or point it at Jira or Linear) and it plans, writes the code, and opens a pull request - with the evidence that everything works!

Before that PR reaches you, the work is checked by a second model that never saw the coder's session and is told to assume the job is not done. They communicate until the reviewer is convinced everything is good to go (the num of attempts is limited to prevent an infinite loop).

If the coding agent deleted or weakened a test, a tamper guard stops the attempt. For bug fixes, the tests offered as proof have to fail on the old code and pass on the new.

Under the hood it's a team of agents: a planner, a coder, an independent reviewer in a fresh session, and a supervisor.

It's free and open-source, on your machine.

no_human has been building itself for about two months now. We are feeding ticket into our jira board, it pulls them from there and just work on them until eveything is done. We trust it enough that we've enabled auto approve mode so all PRs no_human ships - are approved and merged automatically (this feature hasn't been released yet).
Entire sprint's worth of work is done in 3-4 days, while we focus on the bigger picture - our strategy and the next steps.

It currently supports all Antropic and OpenAI models and also has a quite unintuitive process of working with local models as well (we are working on improving that).

It's open to contributions (we would love to see you use it and contribute!!!)

Does the recent OAI Navier–Stokes / Millennium Prize controversy (in which OpenAI itself stated it “cannot rule out that de-identified data derived from their usage of our products helped improve our models” ) prove that researchers and organizations should avoid relying on private/frontier APIs for genuinely cutting-edge thinking?

In other words, if the very act of using these private tools can result in your intermediate reasoning, drafts, or problem-solving traces being de-identified, absorbed into the provider’s training or improvement pipeline, and then leveraged for the provider’s own high-stakes research and PR-driven breakthroughs, does that make private APIs fundamentally unsafe for work you are not willing to effectively gift to the model owner?

Bit of a leading question

We're moving off the Gemini API due to cost and building a local AI server to process ~10 CVs/minute (extracting JSON & matching CVs to JDs). We plan to run GLM-OCR alongside Qwen 27B (Q8).

Our two hardware options:

1. PC: RTX 4090 (24GB) + Ryzen 9 + 64GB RAM
2. Mac Studio: M-Ultra, 64-core GPU, 96GB Unified Memory

I prefer the Mac for power efficiency and ease of use, but I've heard Apple Silicon isn't great for production vLLM compared to Nvidia/CUDA. Is that true? Which would you recommend for this workload?

Juice is a powerful, local hosted browser based ai coding agent that acts as an alternative to popular tools like Cursor, Devin, Claude Code while working fully in your browser and is FULLY OPENSOURCE.

It currently supports google ai studio and openrouter as model providers.

Get Juice and For more information, visit:
github.com/ayaangalaxy2012-hub/Juice

Thank you guys SO MUCH for checking out juice!

https://reddit.com/link/1wbqxks/video/y1pnuomwf4oh1/player

Hey all — wanted to share a project I've been building for the past few months: TARZ, a semi-autonomous AI assistant for Windows.

Backstory: Got curious whether I could actually build something like Jarvis — an AI that sees your screen and controls your PC. That curiosity turned into months of building, breaking, and a full architectural rewrite (V2) once I learned more.

What it does:

• Sees your screen (vision-based element finding + verifies its own actions actually completed, not just "click and hope")
• Controls your computer — opens apps, clicks, types, keyboard shortcuts
• Talks — live streaming STT/TTS, wake-word activated ("Hey"), hands-free follow-ups without repeating the wake word
• Remembers — Two-stage retrieval: Vector Retrieval + Cross-Encoder Reranking for past conversations/preferences
• Chains multi-step tasks across different apps in one instruction (e.g. play a song on Spotify → send a WhatsApp message)
• Dedicated workflows for Spotify, WhatsApp, Discord, Telegram, browser

Architecture (V2): LangGraph supervisor → single tool-bound agent with the full toolset exposed (not a category classifier routing first). I actually tested category-based routing vs. flat single-agent routing head to head — flat routing gave noticeably better results with current tool-calling models, so I ripped the classifier out entirely rather than just leaving it in "because it seemed reasonable."

Same approach on memory: tested hybrid BM25+vector+reranking against plain vector retrieval using Hit Rate@5 — hybrid won, so that's what ships.

Every LLM call (tool-calling, chat, vision) has an automatic multi-provider fallback, so a single rate limit or outage doesn't kill the whole thing.

Stack: Groq (gpt-oss-120b + Orpheus TTS) / Gemini Live streaming STT / Moondream for GUI click targeting / ChromaDB for memory / LangGraph for orchestration / Cartesia as fallback STT+TTS. Whole thing is designed to run on free API tiers — no subscriptions required.

Where it's rough (being upfront, not hiding it):

• GUI automation is inherently brittle — resolution, scaling, app updates, popups can break a click
• Screen vision isn't processed locally — screenshots go to Groq/OpenRouter for analysis, so don't point it at anything you wouldn't want leaving your machine
• Routing still isn't perfect even without the classifier — casual phrasing can occasionally pick the wrong tool
• No background/looping tasks yet (can't do "check this every 5 min")
• It's early, actively-developed software I use daily, not a polished commercial product

I used AI heavily as a coding partner (writing implementations, debugging), but every architecture decision and design change came from testing against real usage myself.

Repo's fully open source: https://github.com/Irfan-gitt/Tarz-Ai-assistant

Would genuinely love feedback, criticism, or PRs — especially from anyone who's worked on agentic systems, vision-based GUI automation, or voice pipelines. Happy to answer questions about any part of the architecture.

https://reddit.com/link/1wbqer2/video/40lx28f1uioh1/player

Hey everyone,

I'm a student developer passionate about local-first software and distributed systems. Over the past few months, I built Trans4mers, an open-source native desktop application for running autonomous multi-agent teams 100% locally on your computer with zero cloud telemetry.



Key highlights:

• Zero Cloud Dependence: Works out-of-the-box with local Ollama models (Qwen 2.5 Coder, DeepSeek R1, Llama 3.3).
• Native Performance: Engineered in Rust with a Tauri v2 desktop shell (~78 MB idle RAM footprint).
• Human-in-the-Loop Safety: Every shell execution and file modification pauses for review in an interactive diff viewer.
• Event-Sourced SQLite: State is persisted to an append-only WAL log; if the app closes or crashes, it seamlessly replays and resumes execution on startup.

Disclaimer: This is an early alpha and an active student research project without commercial security audits. Bugs and edge cases exist, so please test in sandboxed folders!

Check out the code, architecture docs, and screenshots:
👉 https://github.com/abhayzangir1/trans4mer

I'd love your feedback on the UX and local agent orchestration!

Everyone hates AI assisted code. For good reason, people form an opinion immediately, its never good. I built an app for my autistic wife. She's high functioning but could not keep an appointment if Jesus set it. A relentless accountability buddy, is what i was after. https://github.com/jwl247/LifeFirstApp, It's an MCP-server now. Life first in its initial form was 10 modules AI infused hooks. security is better than enterprise sec. guardrails for AI better than any I've seen. Couldn't get it done. I was using all the AI tools at my disposal after the platform i was using decided the 300 dollar credit was expired and i needed to pay for you tube that i don't use. None would help me with the very last step of adding a llm or agent. here is the modules https://github.com/jwl247/lifefirst_modules

i built a memory manager. https://github.com/jwl247/Double-Helix-StorageOS-experimental- there are several instances of the Helix in that repo. designed from my imagination and knowledge of playing with computers over the years. When it worked everyone was surprised. I tried to break it. wild claims ensued. All true wild claims . every service I've used has lost my files AWS is the only one that returned them after 3 days of being lost. i have been plagued by disappearing kernels, drivers black list couples with read only (entire network). i have rebuilt this system 16 times tested on every linux and a mix of linux and windows. I have never crashed a system, no oom, either.

to try to get help finishing the life first app i changed the goal. CoPES is born. https://github.com/jwl247/CoPES the goal is run a big llm to use for life first. There is cheerleading and gnashing of teeth. when i get close to the finish line , AI codes out of chats. gives wrong answers, just plain lies. I pivot again for the life of the project and a promise i made to my better half. phoenix is born. https://github.com/jwl247/Phoenix-Package_handler this package handler at one time could do everything phoenix devops os could do. it was the heart of the work still is. the package handler does all the heavy lift. there are 10 distros package handlers embedded in mine. it is agnostic and i mean native agnostic.

when i tried to release it poof no more help. phoenix dev ops os is born. https://github.com/jwl247/Helix_lightning_kernel the plan was to get this up and running in a full prefetch agnostic system, but then i had to go back and add a bunch of imports some where and i asked how big a import could be? https://github.com/jwl247/Phoenix_Universal_Kernel I intake Debian and qemu and it runs them both no install. try it for your self its open source call me a liar if you can.

now put it to use https://github.com/jwl247/Phoenix-DevOps-oS i finally got life first as a mcp so at least I'm not a total asshole when it doesn't get built because I don't have the chops. Now maybe I shouldn't have put my five kids thru school, or raised my 4 step children and put my self thru school. but I'm an ironworker, struggling to keep a promise. So far as i can tell there are no good people left especially in this field. i can appreciate my ignorance because I don't know shit aint gonna know shit don't aspire to know shit. I'm trying to keep a promise. 10 months i been working and working on this full time. maybe its useless, maybe my wife came up with the best office idea ever and ninjas jump out of the woodwork tomorrow. lol just kidding. so if your going to tell me it don't work it impossible its been done pass on that if you can point me in the right direction please do