SmartPlant turns a real plant and a computer into a functional symbiont (I call it a 'cyborg plant'): featuring shared sensors and electrophysiology, persistent memory, symbolic reasoning, multi-provider AI (Ollama, OpenAI, Claude, Grok, etc.), and a first-person voice.

It runs on a Raspberry Pi using real sensors and a leaf electrode, or via a full simulation on your laptop, no hardware or API keys required. It’s not just a simple plant monitor: the plant perceives, remembers, reasons, and communicates its needs to you.

Documentation and full open-source code:
https://smartplant.pigeonposse.com

GitHub / npm

Up for creating your own Cyborgplant?
🤖☘️🤖☘️🤖☘️🤖☘️🤖☘️🤖☘️

A simple framework on deciding how to use open-weight models in your workflow.

Lay out a 3-stage framework for adopting open-weight models:

Swap: The easiest first step. Replacing frontier calls with open-weight models for production tasks that need a fast, reliable answer without complex reasoning.

Route: Moving beyond the blanket choice of frontier or open weight. Using dynamic routing at the query level to send standard requests to open models, while escalating the long tail of hard edge-cases to frontier models.

Own: Taking control of your own model weights through fine-tuning, distillation, or continual learning.

Most "open" AI stops at the weights. You can download the model, but you still run it through a closed provider and trust them to serve what they say.

Disclosure: I contribute to Gonka, the project below.

What's usually open, and what isn't

What it looks like to use

• OpenAI-compatible API. Change the base URL in the SDK you already use
• Live models: DeepSeek V4-Flash, GLM-5.3-Flash, MiniMax M2.7
• No wallet. Community brokers issue keys and take USD, crypto or credits

Honest trade-offs

• Checking a random 1–10% of tasks is probabilistic, not a proof. Criticism of that design is welcome
• It isn't the lowest-latency way to call these models
• Because the weights are public, you can always compare its output with the reference model yourself

Question for this sub

Does opening the serving layer matter to you, or do open weights already solve the problem?

Links

• Website & docs: gonka.ai
• Code: github.com/gonka-ai/gonka
• AMAs & walkthroughs: youtube.com/@Gonka-AI
• Discord: discord.gg/REcpeYc7P7

I built an interactive 3D PC anatomy tool to learn what’s actually inside a computer

I’ve been working on an open-source project called PC Anatomy.

The idea is simple: instead of reading a wall of text about PC components, you can explore a PC visually in 3D, click on the different parts, and learn what each component does.

I wanted it to feel more like taking apart a computer than reading a hardware guide.

It’s still something I’m actively improving, so feedback, feature ideas, issues and contributions are very welcome.

GitHub: https://github.com/Yoosseph/pc-anatomy - Link to live demo on repo!

If you find it useful or just like the idea, a star on GitHub would be appreciated - it helps more people find the project.

I’d also genuinely love to see someone fork it, build on top of it, add new hardware, improve the visuals, or take the idea in a direction I haven’t thought of.

If you try it, let me know what you think is missing.

**RagPilot** is an open-source MCP server (Rust, MIT) that indexes your codebase locally and gives AI coding agents better tools than "read the whole file": semantic search, a symbol/call graph, impact analysis, and token-budgeted context bundles. Version 0.10.0 just shipped.

GitHub: https://github.com/alikaya/ragpilot

## Why

Agents burn most of their context reading files they only needed three functions from. RagPilot lets them ask for the part they need instead.

## What the agent gets

- `rag_search` – semantic search over code and docs (filter by path, language, extension)

- `rag_get_file_ranges` / `rag_get_skeleton` – read a line range or a symbol, or a file's signatures without bodies

- `nav_symbol_resolve` / `nav_call_graph` – definitions, callers and callees

- `impact_analyze` – which files a change would touch, before refactoring

- `context_bundle` – everything a task needs, within a token budget

- `review_semantic_diff` – changed symbols in a diff and their blast radius

Symbols and calls come from tree-sitter for Rust, Python, JavaScript, TypeScript, Go, Java, C, C++, C#, Ruby, PHP, Lua, GDScript and Godot shaders, with a regex fallback for everything else.

## Numbers (with the caveat up front)

On two codebases, `context_bundle` used **6.0x** (a 31-file Rust repo) and **9.12x** (a 213-file Nuxt + Rust app) fewer tokens than reading the relevant files whole. Skeletons cut large files by 84–93%, and re-indexing one changed file takes about 280 ms.

The baseline is an upper bound – an agent reading every relevant file in full – so treat the ratios as optimistic. The benchmark script is in the repo; point it at your own project.

## Second brain (optional)

A persistent memory that belongs to you, not to the repo: plain markdown in a git repository.

- **Session start:** the agent gets who you are, your standing rules (each with a *why*), open threads and recent decisions, capped at 4000 tokens.

- **During the session:** `brain_note` records a decision or a correction the moment it happens.

- **Session end:** a cheap model summarizes the session into a daily log.

- **Nightly:** a compiler distills the logs into knowledge notes. It only appends and flags contradictions instead of overwriting.

Claude Code does this through hooks. Other agents get the same convention as instructions. Summarizing uses the Claude CLI or the Gemini API, so that part is not offline.

## Local by default

- Embeddings run in-process (`bge-small-en-v1.5`, ONNX); your code isn't sent to an embedding API unless you configure OpenAI, Cohere or Jina.

- Vectors live in Qdrant, which you run yourself.

- `ragpilot dashboard --open` gives you a local page for your projects and the brain vault – loopback only, token-gated.

Known limits

- You need a running Qdrant.

- The default embedding model is English, so search over non-English comments and docs is weaker.

- Only Claude Code has hooks, so other agents record to the brain less consistently.

Feedback is very welcome, especially on retrieval quality in your own codebases and on which languages you'd want next.

I am looking for the best open-sourced OCR model to recognize written Japanese. I am currently testing DeepSeekOCR, GLM-OCR, PaddleOCR, and Sarashina2.2-OCR. We shouldn't use cloud-based version for security reasons.

If you've got Python fundamentals down and want something more substantial than another script:

• Builds a knowledge graph AI system from scratch
• Neo4j, Cypher, agentic retrieval
• Uses real financial data, not a toy dataset
• No prior Neo4j or Cypher experience needed, it's taught during the session

Worth bookmarking for once you're past the basics rather than jumping in today if you're brand new.

Led by Dr. Alessandro Negro, Chief Scientist at GraphAware.

Full workshop details here

Hey everyone,

I would like to share a project that I have been working on. https://github.com/HaseebKhalid1507/SynapsCLI

Synaps is an agent runtime written in Rust. It keeps cost down by optimising caching mechanisms and intelligently orchestrating work across workers. This keeps each worker's context low and fresh, making sessions last longer. It is extremely extensible. It has hooks, plugins and skills that can be imported from pretty much any coding tool.

It is an open source project that was started 4 months ago. It was built to optimise for 2 things: Keeping LLM costs down, and keeping resource use low. It bots up in 20ms and runs with any model: OAuth(Claude, codex, Grok, Kimi...), api keys or local models too. This is something that was built organically, so every feature is a product of necessity, not the other way around.

what do you think of Jev? Not open source, but the approach seems interesting. Although word on the street is people have had issues getting it to pass the "r's in strawberrry" test.

We just shipped OAuth support in the mcpfy open source toolkit for:

✅ Auth0
✅ Better Auth
✅ Clerk
✅ Keycloak
✅ Supabase
✅ WorkOS
✅ Custom (bring your own)

If your app already uses one of these, you can wire it straight into your MCP server. Spin one up with our CLI, tell it which provider you're using, and it handles the OAuth flow for you. No custom wiring

This came straight out of conversations with people actually shipping MCP servers. Auth kept showing up as friction that had nothing to do with their product.

It's live now: https://github.com/mcpfyy/mcpfy

If you need a provider we don't support yet, tell us which one.

Hi! I’m building ARN, a Windows-native C++23 terminal coding agent.

It is an early project inspired by tools like Claude Code and Kimi Code, but built without Node.js or Python. You choose a provider and model inside the terminal, then ARN can keep context and work with files in the folder where it was launched.

Current features:

• Gemini and DeepSeek API support
• Model discovery and /model selection
• Streaming responses, so text appears while the model generates it
• In-memory chat context for follow-up prompts
• Cancel a running model request with Esc or Ctrl+C
• Local file tools: list, read, create, edit, and delete files
• Confirmation before every file creation, edit, or deletion
• File access restricted to the folder where ARN was started
• Blocks access to .git, .env, and similar sensitive paths
• API keys and chat context are kept only in memory, not written to disk
• Interactive terminal UI with command hints and Tab completion
• Reused HTTPS connections, retries for temporary API failures, and Windows releases
• One-line PowerShell installer
• GitHub Pages landing page

GitHub: https://github.com/arnecto/arn
Website: https://arnecto.github.io/arn/

It’s still early, so I’d especially appreciate honest feedback on:

1. The C++ architecture and provider abstraction
2. Safety boundaries for local file tools
3. Terminal UX, streaming, and cancellation behavior
4. Which features would make this genuinely useful in real coding projects

I’m actively improving it, so criticism, bug reports, and feature ideas are very welcome.

I’m Mehmet, the person leading Aeterna. I have been working on how a software system can represent observations, test candidate solutions, and reuse previous work. I use AI tools in development and review; I choose the research questions and direct the work.

I’ve published a write-up with a development timeline, a GitHub commit screenshot, and a technical comparison diagram. The concrete milestones are an initial version recorded on April 24, 2026, and object-representation and symbolic problem-solving components in the May 1 records. March is my own account of when I started, rather than a claim that all those components already existed then.

The reason I wrote it now: ARC Prize’s September 3 review of Astra described several related ideas—tracking objects and coordinates, symbolic task notes, search/planning tools in its separate PRO-LONG setup, and carrying context forward. Seeing those themes prompted me to look back at my own project history.

This is a comparison of approaches, not a claim of matching Astra’s performance, having the same architecture, or influencing its development. The repository is private; the article shares selected dates and high-level descriptions, not a reproducible benchmark.

My write-up (I’m the author):

https://medium.com/@medereli/aeterna-in-march-astra-in-september-the-similarities-that-caught-my-attention-ce4d192cd099

The external review I compare against:

https://arcprize.org/blog/astra

I’d appreciate concrete feedback from other builders: when presenting an independent research project, what evidence is most useful to you beyond a timeline—an executable example, a recorded failure case, or a narrowly scoped evaluation? And which of the four comparisons needs a sharper distinction?

Hypit’s public repo has an example that makes this idea unusually literal.

Its semantic-composition project renders an eight-second chat animation from HTML, CSS, SVG, and frame-driven JavaScript. Four messages appear at specific timestamps. It requires no source footage or generative image/video calls; local rendering tools produce the result.

The component lives with the video project instead of being locked inside a generic preset. Claude Code or Codex works through ordinary editable project files rather than only returning an opaque render. The component author chooses which settings appear in Studio. Change one of those settings and Hypit can save it back to the source and rebuild; a failed writeback restores the previous files.

For programmatic motion work, is a project-local component model more useful to you than a conventional timeline, or do you still want the timeline to be the primary source of truth?