Hey everyone,

I just open-sourced TuneForge.

The goal is simple: let your coding agent manage the full LLM improvement loop without ever leaving the chat window.

You can now tell your agent something like:

“Build me a customer support bot from this FAQ”

…and it can:

• Generate a clean synthetic instruction dataset (with LLM judging for quality)

• Run LoRA supervised fine-tuning on any Hugging Face causal LM

• Do a quick policy-gradient RL step using Ollama as the reward judge

• Merge the adapter, evaluate on a test set, and iterate

Everything runs locally, uses 4-bit quantization so it fits on modest hardware, and uses background jobs (with job_id polling) so long training tasks don’t freeze the MCP connection.

It’s built around the Model Context Protocol (MCP) for seamless integration with Claude Desktop, Cursor, Zed, Continue.dev, etc.

Tech: Python + Transformers + PEFT + bitsandbytes + Ollama + SQLite for job state.

Super early stage (just released), MIT licensed.

Would love feedback or ideas on what to add next. If you’re into agentic fine-tuning workflows, give it a try and let me know how it goes!

Local coding models have a repo-context problem.

When using llama/qwen/mistral/gemma for coding, the hard part is often not the model itself. It is getting the right files/functions into context without dumping too much raw source.

Long context helps, but it does not solve retrieval.

If the model never sees the right file, it still guesses.

I’ve been building SigMap, a zero-dependency CLI that creates a compact repo map for coding workflows.

Instead of sending raw source first, it extracts:

• function signatures
• classes/interfaces
• exports
• import relationships
• ranked file matches per query

The workflow is simple:

repo map first → find likely files → read full source only where needed

Benchmarked across 18 repos / 90 tasks:

• 81.1% hit@5 vs 13.6% random baseline
• ~6× better file retrieval
• 96.9% token reduction in the benchmark setup
• 41.4% fewer prompts per task

No embeddings. No vector DB. No npm dependencies.

This is not meant to replace LSPs, grep, agent search, MCP tools, or full-file reads.

It is meant to give local coding models / agents a cheap first-pass structure map before deeper inspection.

Repo: https://github.com/manojmallick/sigmap

Benchmark suite: https://github.com/manojmallick/sigmap-benchmark-suite

Curious how people here handle repo context with local coding models.

Are you mostly using grep/search, RAG, repo maps, MCP tools, or just relying on longer-context models?

Edit: Good point from the comments — SigMap core is model-agnostic. The docs currently look too focused on proprietary assistants, so I’ll add clearer examples for VSCodium/Open VSX, Continue, Cline/Roo Code, Aider, OpenHands, and local Ollama/llama.cpp workflows.

apple's safari mcp server only exposes 17 tools and runs inside an isolated webdriver session, while the community safari-mcp implementation has around 96 tools and can work with existing browser sessions.

the difference is pretty interesting. apple seems to be treating mcp as a clean-room debugging environment rather than giving agents access to your actual browser state.

there's also the bigger issue that most browser automation tooling is still heavily chromium-first.

this comparison goes deeper into both approaches:

https://rune.codes/hub/tech-trends/the-safari-mcp-server-could-change-how-developers-debug-websites

do you think browser mcp tools should be isolated by default, or is access to real browser sessions more useful?

We've been building and testing an MCP server for library upgrades and migrations over the last few weeks, and one pattern kept showing up.

The biggest source of wasted effort isn't hallucination in the classic sense. It's an agent operating on outdated knowledge and not realizing it.

An agent that doesn't know what changed between versions doesn't fail cleanly. It writes plausible code, hits a build error, tries a different plausible fix, hits another error, and keeps going in circles. Each of those loops costs tokens and time, and none of them would be necessary if the agent knew the actual breaking change upfront.

Current documentation tools solve a different problem. They tell an agent what the API looks like today. They don't tell it what changed, what replaced it, or what silently behaves differently now. Knowing the current API and knowing the migration path are not the same thing.

For example:

• Next.js 14 → 15 changed several request APIs from synchronous to async
• The Vercel AI SDK 4 → 5 removed and renamed multiple interfaces
• The MCP SDK's upcoming v2 turned out to be a package restructuring, not a version bump

The agent often knows both versions exist. It has no idea what actually changed between them. So it starts guessing.

We've been building a way to give agents that missing piece directly: Asynthetic, an MCP server that serves hand-curated migration maps. Each one contains only the breaking changes for a specific version jump, with before/after code, deprecation timelines, peer compatibility requirements, and a citation back to the original source on every single entry. Nothing in the data path is LLM-generated. When there's no verified answer for what you asked, it returns found: false and tells the agent not to guess instead of making something up.

The part that took the most time wasn't writing the maps. It was verifying them. For the Next.js 14 → 15 map, every breaking change entry was tested against real builds, both Turbopack and Webpack, dev and production. Some of what the official docs say turned out to be incomplete in practice. Turbopack silently doesn't enforce the removal of the old u/next/font package the way Webpack does, so a default dev setup won't show you the break, only CI will. The React 19 "requirement" for the App Router isn't actually build-enforced either. An App Router app runs fine on React 18.3.1 in testing. None of that is a knock on the Next.js team's docs. It's just the gap between what a migration guide says and what a compiler actually does, and that gap is exactly what we wanted the tool to capture. It's in the map now as a caveat the agent can read.

Two maps are live right now, Next 14 → 15 and Vercel AI SDK 4 → 5, 40 breaking changes total, all cited. A third map for the MCP SDK is sitting there marked stale on purpose, because v2 turned out to be a package split rather than a version bump, and shipping nothing was better than shipping something wrong for that transition.

The part worth discussing isn't a specific number. It's that most of the cost in these agent loops seems to come from wrong turns, not from the actual fix once the agent knows what to do. Preventing the wrong turn seems to matter more than making any individual edit faster.

It's free, public beta, works hosted over Streamable HTTP or fully offline through npx asynthetic. Source-available under BSL, converts to Apache in 2030.

Repo's here if you want to look under the hood or find a case where a map is wrong: github.com/asyntheticai/asynthetic

Curious if others running Cursor, Claude Code, Devin, or similar agents are seeing the same pattern during upgrades and large dependency migrations.

I built a small open-source CLI because AI kept struggling with SQL against a large Oracle schema. It makes AI schema-aware before it writes SQL.

The workflow is simple:

1. Search database metadata
2. Pull table context
3. Run small read-only checks
4. Save useful SQL
5. Store domain notes in Markdown

It is Oracle-only right now and still early, but it has already helped in my own AI coding workflow. Used it mainly with github copilot

Repo: oracledb-navigator

Curious if others are solving AI + database context in a similar way.

I’ve been working on Curion, a memory system for AI agents built around a simple idea:

The main agent should not have to manage memory manually.

Most AI agents are useful inside a single session, but they still lose important context between sessions. Project decisions, implementation history, constraints, unresolved tasks, and previous reasoning often disappear unless I manually write long handoff notes.

At first, the obvious solution seems to be giving the agent memory tools: save, search, update, delete, edit.

But that creates a second problem.

If the main agent has to manage memory by itself, it can easily receive too many raw memories. Some are relevant, some are stale, some are only partially related, and some may conflict with newer information. The agent then has to spend context and attention deciding what matters.

That creates context bloat.

Curion takes a different approach.

I think of Curion as a librarian for AI agents.

A good librarian does not just throw every possibly related book at you. They understand the question, know how information is organized, filter what matters, notice conflicts, ask clarifying questions when needed, and return the most useful context.

That is what Curion is meant to do for agent memory.

The main agent only needs to say:

“I want to remember this.”

or

“I need to recall something about this.”

Curion handles the rest.

When saving memory, Curion can decide how information should be stored, whether it relates to existing records, whether something should be updated, and whether a conflict requires clarification.

When recalling memory, Curion does not just dump raw search results into the agent’s context. It retrieves relevant records, evaluates what is useful for the current task, synthesizes the context, and clearly says when nothing relevant was found.

The analogy I use is human memory. When we want to remember something, we do not consciously search through billions of memories. We ask for what we need, and the relevant memory appears automatically beneath the surface.

Curion is built around that same interface idea for AI agents.

It is project-first: Curion focuses on the project the agent is currently working in. It can also use cross-project recall when information from another project is actually relevant.

Curion is not just a save/search tool. It is a collaborative memory layer: a specialized memory librarian that helps agents remember responsibly, reduces context bloat, and gives the main agent only the context it actually needs.

GitHub: https://github.com/geanatz/curion

NPM: https://www.npmjs.com/package/@geanatz/curion

Portfolio: https://geanatz.com

SeekYou – unified host intelligence across 15 sources, runs free on Cloudflare.
- Built a tool that takes any IP, domain, or ASN and queries 15 sources in parallel: open ports, CVEs, BGP, RDAP, cert history, passive DNS, 5 threat feeds, exposed buckets, Wayback snapshots — all in one report.
- 4-layer parallel execution (total time ≈ slowest source, not sum of all).
- KV caching per source, circuit breakers, per-IP rate limiting.
- Typed diff engine — get alerted when ports open, CVEs appear, or certs expire on monitored hosts.
- Runs entirely on Cloudflare free tier (~5k lookups/day).
Source: https://github.com/Teycir/SeekYou (https://github.com/Teycir/SeekYou)

Builders-welcome post with the substance up front (disclosure: I'm the maintainer). OmniRoute is a free, MIT, self-hosted AI gateway — one OpenAI-compatible endpoint over 237 providers — built around two problems: runs dying on a provider 429, and tokens bleeding on tool/log output.

One endpoint, 237 providers — 90+ of them free. You point any tool or agent at a single OpenAI-compatible endpoint (localhost:20128/v1) and it can reach 237 LLM providers without you rewriting anything. 90+ have free tiers and 11 are free forever (no card), which aggregates to ~1.6B documented free tokens/month — and that's honest, pool-deduped math (we count each shared pool once instead of inflating it; the methodology is public in the repo). There's a one-command setup-* for 13+ coding tools (Claude Code, Codex, Cursor, Cline, Roo, Kilo, Gemini CLI…), so switching your existing setup over takes seconds.

Fallback combos — so it never stops mid-task. A "combo" is a ladder of models the router walks automatically: your subscription first, then API keys, then cheap models, then free ones. When a provider returns a 500 or you hit a rate limit, it slides to the next target in milliseconds, mid-request, and your tool never even sees the error. There are 17 routing strategies (priority, weighted, round-robin, cost-optimized, auto/coding:fast…) plus three resilience layers — a per-provider circuit breaker, a per-key cooldown, and a per-model lockout — so one dead key can't take down a whole provider.

Fusion — an ensemble mode for the hard steps. Beyond simple routing, there's a fusion strategy that fans a single prompt out to a panel of different models in parallel and then has a judge model synthesize one best answer (mixture-of-agents, built in). It's cost-aware, so easy turns stay on one fast model and it only fuses when the step is worth it.

A 10-engine compression pipeline — the part most routers don't have. Every request flows through a transparent compression pass you can toggle/stack per combo. Instead of one trick, it stacks the best of the open-source ecosystem: RTK filters command/tool output (git diffs, test logs, builds) at 60–90%, Microsoft's LLMLingua-2 does ML semantic pruning, Caveman handles prose, session-dedup strips repeats across turns. Critically, code, URLs and JSON are preserved byte-perfect, and a default-on inflation guard throws the compressed version away and sends the original if compressing would actually grow the prompt — it never makes things worse. On tool-heavy sessions that's ~89% average input-token reduction (an 8k-token git diff becomes a few hundred). Full credit to every upstream project (RTK, Caveman, LLMLingua-2, Troglodita) is in the README.

Agent-native — the agent can drive the router itself. There's a built-in MCP server (95 tools across 30 audited scopes, over stdio / SSE / streamable-HTTP), plus A2A (v0.3, JSON-RPC 2.0) support. That means an agent can query providers, switch combos, read its own remaining quota and manage memory through the gateway — not just consume tokens through it.

It's 100% local (zero telemetry, AES-256-GCM at rest), MIT-licensed, has a prompt-injection guard on every LLM route, opt-in memory, and runs on npm, Docker, desktop or your phone via Termux.

For context on whether it's worth your time: it's grown to ~9.8K GitHub stars, 1,490+ forks and 280+ contributors in ~4.5 months, with 21,000+ automated tests and 1,830+ issues closed — so it's a battle-tested project, not a brand-new experiment.

npm install -g omniroute

GitHub: https://github.com/diegosouzapw/OmniRoute · Site: https://omniroute.online

Would value a critique of the routing/compression architecture from this crowd.

I've finally had enough. I have wasted too many hours doomscrolling Insta to find reference videos and creators for my niche for my own startup, so I built an MCP to do it for me.

ScrollScanner lets Claude search Instagram, then a vision model actually watches each candidate reel so you can search by format in plain English "single-cut talking head, on-screen text, advertising dog walking software" and only true matches come back, each with the reason it matched. Everything ranks by outlier score (views ÷ the account's own median) instead of follower count, which is great for surfacing micro-creators.

One-line add in Claude Code, or drop the URL into Settings → Connectors on Desktop/web. Would love feedback from this crowd on the tool design and what other research moves you'd want it to make.

Link is scrollscanner.com

I kept watching coding agents answer "what calls this function" by grepping, opening three files, and reading them top to bottom to find four call sites. On a big repo that eats the context window fast.

basemind indexes a repo once and answers structurally. The MCP tools return paths, line numbers, and signatures instead of file bodies, so a lookup costs a fraction of reading the source. What it exposes:

• Code map (300+ languages): outline, search_symbols, find_references, find_callers, call_graph, find_implementations. An expand escape hatch pulls a single function's full body when the agent actually needs it.
• Git at symbol resolution: blame_symbol, symbol_history (when a symbol's body changed), recent_changes, diff_outline.
• Document RAG over 90+ formats with text extraction and OCR built in, plus semantic and full-text search.
• Shared memory and an agent-to-agent comms channel (rooms, DMs, inbox) for running more than one agent on the same repo.

Runs three ways over one local index: a Claude Code plugin, a plain MCP server, or a CLI. Works with Claude Code, Codex, Cursor, Gemini CLI, Copilot CLI, OpenCode and a few others. Rust, MIT.

On token savings: it ships a heuristic counter (an outline is modelled at about 1/5 of reading the file, a caller lookup about 1/3 of grep plus read). It's an honest estimate, not a benchmark, and tools with no fair baseline (memory, git wrappers) count zero.

Honest limitations: it's an index, so it lags edits between scans. serve watches by default and there's a rescan, but a cold first scan is slower (worst case in my tests is the TypeScript compiler, 81k files, about 18s), and the git-history index costs 6 to 22% of your .git on disk.

https://github.com/Goldziher/basemind

Curious how others here are feeding repo structure to agents over MCP.

Ask questions across your Markdown notes using a fully local Graph RAG engine. Built for Obsidian vaults, works with any folder of Markdown files. Extracts entity-relation triples from wikilinks & YAML frontmatter, retrieves answers via hybrid search (vector + BM25 + temporal). Multilingual. No cloud. Runs on Ollama.

https://github.com/benmaster82/Kwipu