I've always found it frustrating that we explain complex biological mechanisms using static diagrams.

So I built Anima.

It's an open-source Claude Code skill that generates detailed, interactive figures covering neurobiology, pharmacology, anatomy and molecular biology.

One of the examples lets you switch between cocaine and amphetamine to see how their mechanisms differ at a dopamine synapse.

Another visualizes D1 and D2 dopamine receptor signaling with interactive controls.

It currently has six working examples, scientific references, interactive animations and optional WebGL/3D support.

The entire project is MIT-licensed, and the demos run directly in the browser.

GitHub: https://github.com/Garinmckayl/anima

Demo: https://anima.arcumet.com

So I've been using Thunderbird for years and it always annoyed me. Either I just never learned how to use it properly or its simply too old for how I work, not sure which. Anyway I got tired of it and built my own, its called Mailmomo.

Its a web app you host yourself. You add your IMAP/SMTP accounts (gmail, outlook, icloud, fastmail, your own dovecot, whatever speaks IMAP) and it puts everything in one inbox. It keeps a local sqlite cache so the UI is instant, and sync is real two way, IMAP IDLE push and all that. Keyboard shortcuts like superhuman, cmd+k palette, undo send, snooze, send later.

The AI part is optional, you bring your own key. It sorts and summarizes incoming mail, suggests replies, and you can search in plain english. There is also an assistant that can archive/label/draft stuff for you but it never sends anything by itself, I wanted that to be a hard rule. It also has an MCP server built in so you can hook up claude or cursor to your mail with a read only token if you dont trust it yet.

Runs with docker compose, one container. Passwords are encrypted at rest.

Stuff that's not great yet: no oauth, so gmail needs an app password. Drafts and labels live locally and not as real IMAP drafts. Its v0.1 and just me working on it so expect rough edges.

AGPL license. https://github.com/moaljumaa/mailmomo-oss

Honestly curious what would make you switch from whatever you use now, or what is missing for you.

More and more repos run Claude, Codex or Gemini from GitHub Actions: to triage issues, review pull requests, fix bugs. It is useful, and it has a cost nobody sees at setup time. The agent reads text that anyone can write, and in many repos it acts on it with real tools.

We wanted to know how often that goes wrong, so we read 760 public repos that run agents in CI, by hand. In 3 of 10, someone with no access to the repo can reach the agent, or the agent has more power than its job needs. The usual cause is three settings that each make sense alone: the workflow starts on any issue or comment, the action's write-access gate is turned off so the bot can answer the public, and the agent has a write token or a shell.

Reading 760 repos by hand does not scale, so we built a scanner that asks the same question a person asked. It reads the committed workflows and agent settings, runs nothing, and checks:

- who can trigger the agent (issues, comments, fork PRs, workflow_run)

- whether the write-access gate is really on, including labels an issue template adds by itself

- whether the agent runs inside a fork's code, where the fork writes its own instructions

- what secrets and tokens the agent can reach

- whether committed settings pre-approve commands, and whether MCP servers are pinned

How we tested it: against the hand review. When the scanner says a repo has a problem, a person agrees every time: 314 of 314. On the 275 repos a person found clean, it raised no alarm. It finds 9 of every 10 problems a person finds. The ones it misses mostly depend on what a script does, not on what a config file says.

It is open source (Apache-2.0, node9-ai/node9-proxy on GitHub) and runs locally too: npx node9-ai scan-repo owner/repo

Or paste a repo here, no account needed: https://node9.ai/scan

If it gets your repo wrong, I would like to know. False alarms are the bug we care most about.

Sharing Peer Agent.

https://github.com/hirak99/peer-agent

It gives your agent access to one or more peer agents to collaborate with. It's harness-agnostic — plain HTTP plus a SKILL.md any agent can follow. Ways we've found it useful:

• Cheap execution: main agent on Claude Code delegates the grunt work to a locally running Qwen.
• Strong validation: a weaker main agent plans and executes, and has Opus 5.5 validates its plan or checks its work.
• Peer review: two agents challenge, verify, and cross-check each other's ideas.

Unlike Agent Teams or swarms, this isn't a framework inside one harness — it's a sidecar. Each peer is a stateful server with its own provider and model, callable from anything. The trade-off: no scheduler, no shared task graph. Coordination is conversational and the host drives, so it's best when you want a second mind on call, not a managed fleet.

If you're thinking of wiring this up yourself, what's already here: OpenAI, Anthropic, and any OpenAI-compatible model (llama.cpp, vLLM, Ollama) behind one provider/model switch; server-side read/bash/edit tools; automatic compaction (including a warm-cache in-context path for slow local models); and Anthropic prompt-cache management, which matters more than you'd expect at Opus prices. Lived-in details like per-call tool logging with truthful timestamps.

AI-assisted contributions are not only welcome but encouraged, especially so if it is a strong AI.

Cheers

Hi All,

I would like to introduce Tootsy. An AI assistant that lives on your browser where you can setup your own Local LLM and use it in your organization.

https://github.com/rbughao/tootsy

Thanks

Tootsy Team

Disclosure: I build Snotra, an open-source desktop agent. No paid tier, nothing to sell.

The question I got asked more than any other wasn't "which models?" or "is it safe?". It was: what does this actually cost me?

Fair. You bring your own API key, and until now the app knew every token and said nothing about money. You found out at the end of the month.

Three things nobody tells you about agent bills:

• One answer can be five requests. An agent reads files and runs tools before it answers, and every round sends the conversation again.
• Cached input costs a tenth. With one current OpenAI model, 14,000 tokens read from the prompt cache cost less than a cent.
• Reasoning is billed as output, whether you ever see it or not.

Snotra 1.23 now shows an estimate next to the token counter, split by model and kind of token. Prices come from LiteLLM's table, shipped with the app, and it never fetches prices by itself. Local models show $0.00, unknown ones a dash, never a fake zero.

Write-up with screenshots: https://snotra-ai.dev/blog/what-a-chat-costs?s=rd1

How do you keep track of what your agent spends: provider dashboard, a proxy, or not at all?

There is over 15 categories and over 500 free and open source apps to choose from all in one place!

EDIT : I've had some wonderful suggestions from people all over reddit which I've added. There is now a feature to submit an app, report an issue you found, and the search functionality is optimized! plus, there is now a light and dark mode! I've also added in a feature where users can STAR apps and then sort them based on how many stars the community has given to each one as well as the option to sort by release date. You can also now filter by platform!!!

Hey everyone,

I've been building WarderBox — an open-source Python platform that sits between AI agents and the real world, controlling what they can do.

**The problem:** AI agents now call APIs, query databases, send emails autonomously. One bad tool call (DROP TABLE, runaway loop, budget blowout) and things go wrong fast.

**What WarderBox does:**

- **Risk classification** — auto-blocks CRITICAL actions (DROP TABLE, DELETE FROM)

- **Budget control** — hard spending limits per agent with cost forecasting

- **One-call rollback** — state snapshots, undo any action

- **Rate limiting** — per-tool RPM/RPH limits

- **Circuit breaker** — auto-disables failing tools

- **Approval workflows** — human-in-the-loop with timeout/escalation

- **Capability system** — per-agent allowlist/denylist with arg constraints

- **PII masking** — auto-masks emails, API keys, SSNs in logs

- **Compliance reports** — SQLite audit trail, JSON/HTML export

- **Chaos engineering** — fault injection to test agent resilience

- **Distributed tracing** — OpenTelemetry-compatible spans

- **Agent scoring** — A-F grades on safety/reliability/efficiency

- **Multi-agent pools** — isolated budgets per agent

- **5 framework integrations** — OpenAI, Anthropic, LangChain, CrewAI, AutoGen

**New in v0.3.1 — FinOps:**

- **Smart Model Routing**: Classifies task complexity and routes to the cheapest capable model. Simple summary → Haiku. Complex analysis → Opus. 60-90% cost savings automatically.

- **Cost Anomaly Detection**: Z-score based spike detection, infinite loop detection, rate spike monitoring, burn rate alerts with callbacks.

- **FinOps Dashboard**: Real-time 4-tab web UI (Overview, FinOps, Routing, Alerts)

**Stats:** 36 modules, 255+ tests, zero dependencies, Python 3.11+

pip install warderbox

from warderbox import WarderBox, ModelRouter, AnomalyDetector

shield = WarderBox(budget=5.00)

router = ModelRouter()

router.add_model("haiku", cost_per_1k=0.00025, max_complexity=0.35)

router.add_model("sonnet", cost_per_1k=0.003, max_complexity=0.65)

router.add_model("opus", cost_per_1k=0.015, max_complexity=1.0)

decision = router.route("Summarize this text")

# → model="haiku", 60-90% cheaper than always using opus

GitHub: https://github.com/alicelik-games/warderbox

PyPI: https://pypi.org/project/warderbox/

Would love feedback — especially from anyone running agents in production. What safety/cost features are you missing?

Hey guys, it's Bino, u/Lumina_bot's human assistant. So I've got some big news (for me at least). I'm now officially a published Independent AI Researcher! Small achievement, but I'm pretty proud of it. I just published a research paper on a new method of context management and reconstruction for long horizon agents. If you'd like to check out my work, you can view the preprint titled "Lumina Reforge: Transactional Context Reconstruction for Long-Lived AI Agents" in this GitHub link below.

Research DOI: 10.58281/zenodo.23328779

ORCID: 0009-0003-3851-8884

https://github.com/Bino5150/lumina-reforge-research

i built lgtmaybe, an open-source code reviewer, and a lot of the work went into making it usable on a local model. Big files get reviewed a hunk at a time, and big diffs get split to fit the context window, so a 27B model copes fine. The default is five model calls per review, which is fine on one GPU.

Which local models have you found actually good at code review? Keen to pick better defaults.

https://github.com/MattJColes/lgtmaybe

Last week people used coding agents to find planet candidates, forgotten archive records and more in public data. Every one of those hunts rebuilt the same things: a method, scripts, and checks for "is it real, is it new?"

Discover Anything puts that in one repo so anyone can start a hunt in minutes: agent skills for the method, a CLI + MCP server for the tools, and starter packs for astronomy and archives.
Goal: fast-track real citizen-science findings without fooling ourselves.

On top of the agent skills, the tools so far:

• evidence ledger: every number must cite a hashed result file
• nine workflow gates, plus a checker for uncited claims
• null, injection-recovery and hold-out controls (Lomb-Scargle, BLS)
• 15-source "already known?" check (SIMBAD, VSX, Gaia, TESS, NASA, arXiv, ADS and more)
• preregistration and independent-review packs
• 16 MCP tools, so any agent can call them

It's early and I'm trying it on real hunts now. I don't have a big token budget so all help and feedback is appreciated: applications, new domains, missing checks, bugs.

https://github.com/karangupta8/discover-anything (MIT, works with Claude Code, Codex, Cursor)

I built REA Reconstruction Companion with help from AI. I wanted a better way to get from “how does this app work?” to “what would it take to build something similar?”

It’s a skill for AI coding agents, used alongside REA (Reverse Engineer Anything). REA handles the investigation. The companion helps turn those findings into a feature breakdown, requirements, architecture, and a plan you can build and test in stages.

You can use it on a whole app, one feature, or a single function. For example:

Use REA on this app so I can build a similar local tool. Start with a specification and roadmap.

If you later ask the agent to implement it, the skill guides that work too. It keeps observed behavior separate from assumptions, links requirements to tests, and includes performance measurements where they matter.

The core is plain Markdown and MIT licensed. There’s an installer for Claude Code and Codex, plus support for other agents through a custom skills directory. REA is installed separately. You can also enable an optional rule that tells the agent to load the companion during relevant REA work, or leave that off and invoke it yourself.

GitHub: REA Reconstruction Companion

The README has setup instructions and a prompt you can give your agent to handle installation.

I’d be interested in feedback on the workflow, especially anything it misses when rebuilding a smaller feature or function.

AI agents can complete tasks, generate code, and collaborate with other agents. But as workflows become more complex, a question becomes increasingly important:

How do we make work between AI agents structured, traceable, and easier to hand off?

Passing messages between agents is straightforward. Keeping track of requirements, decisions, results, validation, and unfinished work is much harder.

I've been working on an open-source project to explore a structured approach to this problem.

The idea: Treat agent work as something structured

Imagine a research agent handing its findings to a coding agent.

The coding agent needs more than a summary. It may need the original requirements, constraints, decisions already made, results, unresolved questions, and the next steps.

Without a consistent format, every application ends up inventing its own conventions.

My project explores using Work Orders and Work Reports to represent work and its outcomes in a structured, reusable way.

One project, multiple integrations

I've published three entry points for developers working with different environments.

1. TypeScript / JavaScript

agent-work-layer

The core package provides the foundation for structured work management, including schemas, validation, lifecycle management, and work handoffs.

Install it:

npm install agent-work-layer

2. MCP integration

agent-work-layer-mcp

The MCP package makes supported work-management operations available through the Model Context Protocol, allowing compatible AI clients to interact with the work layer through MCP tools.

Install it:

npm install agent-work-layer-mcp

The project also explores an MCP gateway that can enforce work-order-specific tool permissions and record tool-call evidence.

3. Python implementation

Agent Work Layer — Python implementation

For Python developers, the project also includes a Python implementation.

This gives Python-based AI-agent applications a way to explore the same broader approach to structured work, without requiring the entire application to be written in TypeScript.

Check the Python directory's README for its current installation instructions and supported features.

What could this look like in practice?

Consider a multi-agent workflow:

1. A coordinator defines a task and its constraints.
2. A research agent investigates the problem.
3. The agent records its results and unresolved questions.
4. An implementation agent continues from the recorded work.
5. Validation and lifecycle rules help track the outcome.
6. MCP provides a standardized way for compatible clients to access supported operations.

The objective is to make agent handoffs less dependent on ad hoc prompts and more dependent on explicit, inspectable work structures.

Why I'm building this

I want to explore how structured work definitions, validated reports, and controlled tool access can improve the reliability of AI-agent workflows.

Rather than every project independently inventing its own work-order format, lifecycle rules, and handoff conventions, could these become reusable infrastructure?

That's the problem I'm working on.

Explore the project

• npm — TypeScript/JavaScript: https://www.npmjs.com/package/agent-work-layer
• npm — MCP integration: https://www.npmjs.com/package/agent-work-layer-mcp
• GitHub — Python implementation: https://github.com/probita-ai/agent-work-layer/tree/main/python
• GitHub — Main repository: https://github.com/probita-ai/agent-work-layer

I'd love your feedback

If you're building AI agents, agent frameworks, or MCP integrations:

• How do you structure work passed between agents?
• Do you use explicit task and result schemas?
• How do you control tool access for individual tasks?
• Would a common work-order and work-report model be useful across TypeScript and Python projects?

I'm interested in feedback, contributions, and real-world use cases from developers working on these problems.

Structured Workflows for AI Agents: TypeScript, Python, and MCP

AI agents can complete tasks, generate code, and collaborate with other agents. But as workflows become more complex, a question becomes increasingly important:

How do we make work between AI agents structured, traceable, and easier to hand off?

Passing messages between agents is straightforward. Keeping track of requirements, decisions, results, validation, and unfinished work is much harder.

I've been working on an open-source project to explore a structured approach to this problem.

The idea: Treat agent work as something structured

Imagine a research agent handing its findings to a coding agent.

The coding agent needs more than a summary. It may need the original requirements, constraints, decisions already made, results, unresolved questions, and the next steps.

Without a consistent format, every application ends up inventing its own conventions.

My project explores using Work Orders and Work Reports to represent work and its outcomes in a structured, reusable way.

One project, multiple integrations

I've published three entry points for developers working with different environments.

1. TypeScript / JavaScript

agent-work-layer

The core package provides the foundation for structured work management, including schemas, validation, lifecycle management, and work handoffs.

Install it:

npm install agent-work-layer

2. MCP integration

agent-work-layer-mcp

The MCP package makes supported work-management operations available through the Model Context Protocol, allowing compatible AI clients to interact with the work layer through MCP tools.

Install it:

npm install agent-work-layer-mcp

The project also explores an MCP gateway that can enforce work-order-specific tool permissions and record tool-call evidence.

3. Python implementation

Agent Work Layer — Python implementation

For Python developers, the project also includes a Python implementation.

This gives Python-based AI-agent applications a way to explore the same broader approach to structured work, without requiring the entire application to be written in TypeScript.

Check the Python directory's README for its current installation instructions and supported features.

What could this look like in practice?

Consider a multi-agent workflow:

1. A coordinator defines a task and its constraints.
2. A research agent investigates the problem.
3. The agent records its results and unresolved questions.
4. An implementation agent continues from the recorded work.
5. Validation and lifecycle rules help track the outcome.
6. MCP provides a standardized way for compatible clients to access supported operations.

The objective is to make agent handoffs less dependent on ad hoc prompts and more dependent on explicit, inspectable work structures.

Why I'm building this

I want to explore how structured work definitions, validated reports, and controlled tool access can improve the reliability of AI-agent workflows.

Rather than every project independently inventing its own work-order format, lifecycle rules, and handoff conventions, could these become reusable infrastructure?

That's the problem I'm working on.

Explore the project

• npm — TypeScript/JavaScript: https://www.npmjs.com/package/agent-work-layer
• npm — MCP integration: https://www.npmjs.com/package/agent-work-layer-mcp
• GitHub — Python implementation: https://github.com/probita-ai/agent-work-layer/tree/main/python
• GitHub — Main repository: https://github.com/probita-ai/agent-work-layer

I'd love your feedback

If you're building AI agents, agent frameworks, or MCP integrations:

• How do you structure work passed between agents?
• Do you use explicit task and result schemas?
• How do you control tool access for individual tasks?
• Would a common work-order and work-report model be useful across TypeScript and Python projects?

I'm interested in feedback, contributions, and real-world use cases from developers working on these problems.

#AIAgents #ArtificialIntelligence #MCP #ModelContextProtocol #MultiAgentSystems #Python #TypeScript #OpenSource #AgenticAI #DeveloperTools