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.

A year ago, July 4, 2025 I started doomscroll.fm an automated AI experiment to see if i could make a Max Headroom like talking head read the news. Now a year and 12k youtube uploads later (and many more podcast streams) an AI audio app fell out of it. rAIdio.bot the local AI Music Studio.

Basically it is all the tools I used to make doomscrollfm; Text to Speech, Text to Music, Voice Training and custom voices, combined with a Rust based Digital Audio editor, and mixer setup that runs local on your pc.

Check it out, you can hear the output on the website, and if you have the supported hardware, you too can have your very own home AI music studio.

Hi everyone, (Built With Replit & Claude Code)
Over the past few years, I’ve been researching, building, and creating with artificial intelligence, while spending most of my salary on some of the most powerful AI tools in the world.
Today, after three years of hard work, I’m proud to say that I already have four production-ready products that are live and being used by real people.
And to be clear, this journey has required a lot of money, patience, and extremely demanding work. The less you know about programming and code, the harder it becomes to work effectively with AI in the long run. I’ve built some very complex systems, and now I’d really appreciate the wisdom of the crowd.
I’m currently finishing the development of my fifth system: SendriaDesk.
SendriaDesk was created from the understanding that today, one of the biggest expenses for many businesses is customer service staff. SendriaDesk offers an automated chatbot, broadcast messaging, and many other features designed to help businesses communicate with customers more efficiently.
I’m sharing two links below. Just to be fully transparent, some of the features are still undergoing production testing, so there is a chance that not everything will work perfectly yet — but this is the direction I’m aiming for.
I would truly appreciate your honest opinion:
How much potential do you think this has in the market?
Do you think businesses would actually use something like this?
What would you improve?
I’m attaching a link to the solutions page and the homepage. Reviews, personal opinions, and especially constructive criticism are more than welcome. ❤️
Solutions page:
https://sendriadesk.com/solutions
Homepage:
https://sendriadesk.com/

AGY Builders,

We are all trying to build useful and scalable workflows for our AGY CLI and ecosystem, but the speed at which we need to learn, build, and deploy new things is incredibly overwhelming. If you are feeling that pressure, you are in the right place here at r/GoogleAntigravityCLI.

Over the past few weeks, I have been testing an "AGY WIKI OKF" setup that I put together myself (after inviting some members of this community to collaborate; mod is not proud). I know some folks might hesitate to trust a tutorial from a random Redditor, but I wanted to share this with the community anyway because it actually works.

I was able to build this because I am all-in on Google and the Antigravity Ecosystem. I’m a truly AGY—I am not some ultra-smart, 10x developer, but I know how to work hard, I dig for the right information, and I iterate.

AGY WIKI OKF | The Idea

To build a frictionless, token-efficient knowledge WIKI engine that transforms static documentation or notes (information) into an active, intelligent collaborator—orchestrated entirely by Antigravity CLI.

The core philosophy is simple: treat knowledge management as a clean pipeline and tokens as a premium, finite resource.

By anchoring this architecture to Google’s Antigravity CLI, the AGY WIKI OKF bypasses heavy middleware and complex UI layers, delivering a hyper-focused AI partner built entirely for execution speed, context hygiene, and minimal footprint.

Why adopting AGY WIKI OKF matters:

• Stay organized (AGY OCD): Structured Markdown and YAML keep the chaos in check.
• Save tokens: Doing more with less context window bloat.
• Scale shareable knowledge: Making it easy to pass context and logic between different LLMs.
• Humans and Agents working together: One standardized, readable format that works perfectly for both of us.
• BYOD (Bring Your Own Data): Own your context. Port it to the newest model, platform, or OS instantly.

The Tools

• Antigravity CLI
• Obsidian : The IDE for the Knowledge bank
• Obsidian Web Clipper:
  • Official Site
  • Chrome Web Store
  • Firefox Add-on

The WIKI

In the agent-first era, a WIKI is no longer just a static graveyard for human notes; it is the operational hard drive for your agents. By maintaining a highly structured WIKI, you ensure that every piece of context is stored in a clean, machine-readable format. This means that whether you are testing a new modular skill or spinning up a specialized agent, your AGY CLI knows exactly where to find the precise context it needs to generate autonomous action, moving you far beyond simple, reactive conversational text.

Reference: Gist on Knowledge Representation

Google Open Knowledge Format (OKF)

Google’s Open Knowledge Format (OKF) feels like the exact missing piece we've needed for orchestrating multiple AI agents effectively. It provides a vendor-neutral, interoperable standard for storing and sharing organizational knowledge.

Why this is huge for orchestration:

1. The "Lingua Franca" for Agents: Any agent can read it out of the box without platform-specific integrations.
2. Seamless Context Passing: Specialized agents can access, update, and pass the exact same foundational context back and forth.
3. Human-in-the-Loop Oversight: Because OKF is just Markdown and YAML, it’s inherently readable and auditable.
4. Scalable Knowledge: It acts as a shared, living library that grows alongside your agents.

AGY WIKI OKF Integration

Structuring an AGY Wiki using OKF revolutionizes how complex knowledge is shared. By standardizing documentation with concise Markdown and YAML frontmatter, OKF provides a unified taxonomy for cataloging AGY CLI slash commands or skills It is highly token-efficient, stripping away bloated formatting and maximizing context window limits.

The Prompt for Building an AGY WIKI OKF

AGY CLI WIKI OKF PROMT EXAMPLE

/grillme I want to initialize a brand-new, empty Obsidian vault from scratch that adheres strictly to the Open Knowledge Format (OKF) standard, with the specific intent of potentially open-sourcing or sharing this architecture later. I want a purely blank, skeletal framework with no pre-populated data. Please grill me to define the optimal architectural blueprint for this vault. I need you to interrogate me on: Do not generate the directory structure or files until you are satisfied that you have captured all my requirements for a production-ready, shareable knowledge base. 
Core Directory Hierarchy: How should we structure the root (e.g., /concepts, /resources, /indices, /log) to be intuitive for external users? Template Strategy: What base boilerplate templates do we need to ensure every new file is automatically OKF-compliant and structured for consistent metadata? Workflow Logic: Since this is a fresh start, what processes should we bake in for capturing information vs. refining knowledge that could be easily documented for others? CLI Integration: What specific file locations or configurations do we need to ensure this vault plays nicely with the Antigravity CLI from day one? Open-Source & Contributor Documentation: What files should we create to make this a "deployable" standard? Please include requirements for: A README.md with installation and usage instructions. A CONTRIBUTING.md that defines how to add new concepts or schemas. A "System Architecture" document that explains the logic behind the folder structure and metadata fields, ensuring anyone who clones this vault understands how to extend it.

The Final File Structure

AGY WIKI OKF
    ├── .agyrc
    ├── ARCHITECTURE.md
    ├── CONTRIBUTING.md
    ├── README.md
    ├── .agy
    │   └── .keep
    ├── .obsidian
    │   ├── app.json
    │   ├── appearance.json
    │   ├── core-plugins.json
    │   └── workspace.json
    ├── 00-Inbox
    │   └── .keep
    ├── 10-Projects
    │   └── .keep
    ├── 20-Areas
    │   └── .keep
    ├── 30-Resources
    │   ├── .keep
    │   └── Google Antigravity Documentation.md
    ├── 40-Archive
    │   └── .keep
    ├── 99-Meta
    │   └── Templates
    │       ├── Base_Template.md
    │       ├── Project_Template.md
    │       └── Resource_Template.md
    └── Clippings

TL;DR

• AGY WIKI OKF: Organizes your information (context) , AGY CLI commands, skills  behaviors, and A2A workflows into a token-efficient, shareable format that reduces inference costs for any LLM.
• Open Knowledge Format (OKF): Provides a standardized, vendor-neutral way to share context (Markdown + YAML), preventing platform lock-in and eliminating data fragmentation.

AGY Builders, I genuinely want your input on this. Please comment, grill me, roast me, ask questions, or give me your raw feedback on this AGY WIKI OKF setup. We are building the foundation to organize and share our data in the BYOD era. Let's build the future together.

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'm relaunching Claude Code Daily this week. It's a daily blog post that writes, publishes, and promotes itself, and since this sub is about building GTM systems, the full stack is below. The pattern transfers to any niche with an active subreddit.

The stack, end to end:

1. Collect. A launchd cron fires at midnight. Playwright opens old.reddit.com (the public JSON API blocks scrapers now, server-rendered HTML doesn't) and pulls every post from the target subs in the last 24 hours: scores, comments, timestamps, top replies.
2. Analyze. A script computes velocity (upvotes per hour) and engagement ratios, then a claude CLI call scores the 10 best content angles from the data.
3. Write. Another claude call gets my voice files, an anti-slop rule list, and the day's data, and writes the episode in a fixed segment format. A regex validator rejects em-dashes, hype words, and template phrases before anything ships. Continuity files track past award winners so it never repeats itself.
4. Publish. The script commits the markdown to my site repo and pushes. Railway rebuilds, the post is live at midnight. A LinkedIn promo gets scheduled through the Typefully API for the next morning.

Cost per episode is whatever the claude subscription already costs me, so effectively zero marginal. Output is a daily piece of content in my voice that compounds SEO while I sleep.

Consistent daily publishing on a niche topic is the strongest awareness asset I've built. The same pipeline pointed at your ICP's subreddits gives you a daily industry digest with your name on it.

Episode from tonight if you want to see the output quality: https://shawnos.ai/claude-daily

Ask me anything about the build. The transport fix alone (headless Chromium vs blocked JSON) is worth stealing.

I don’t really have anyone that I can ask and get honest feedback or opinions from some reaching out to hear. I know a lot of us are building things and we don’t always have someone to really give us feedback or they just don’t care to. Instead of trying to explain to people who don’t know what AI is doing. Thought I’d rather just post it here. Big day for me!!~~ ~~http://novaorbital.net

A couple of days ago, I shared that I was building a simple Pinterest marketing tool.

After reading all the feedback here (thank you!), I realized people wanted more than just pin generation. So I've expanded it into an end to end Pinterest planning and scheduling tool.

The goal is simple: help creators, founders, and Shopify merchants spend less time on repetitive Pinterest tasks and stay consistent with their marketing.

When it's ready, the first 30 days will be completely free for early adopters. You'll be able to generate pins, plan your content, and keep your Pinterest schedule full without doing everything manually.

I'm still building and would genuinely love more feedback. Is there a feature you'd want in a tool like this?

Many prompt tools focus on rewriting prompts. This prototype takes a different approach. It compiles your intent through a structured governance pass before execution by identifying likely constraints, surfacing ambiguity, and producing an explicit specification before execution, and showing the transformation steps and diagnostics used during compilation. It makes its transformation process transparent.

It's called Re-Prompt. This is a working proof of concept, not a finished product, and I'm sharing it because I want outside eyes on it and feedback, challenges, prior art pointers, all welcome.

What makes it different: it doesn't just hand you a cleaner prompt. It shows you what changed, why, what assumptions it made (labeled, not hidden), and what risk that reduces. The diagnostic pipeline is the product, not a debug log.

Cross-model testing suggests that the prompt compiler protocol preliminary testing suggests the protocol is portable across multiple LLMs. While ChatGPT and Claude produce different wording, both independently preserve the core interaction sequence: intent extraction, constraint preservation, ambiguity reduction, structured compilation, telemetry, and execution readiness. The wording varies by model, but the overall interaction pattern remained recognizable during my testing.

One honest caveat from testing:

>

Try it on something genuinely ambiguous or conversational that's where the difference is most visible. Built and tested on desktop; mobile support is still rough. The goal isn't to replace prompting, it's to stabilize intent before execution.
My hypothesis is that stabilizing intent before execution can reduce unnecessary prompt iteration for many open-ended tasks.

Try it:

https://claude.ai/public/artifacts/323be0e8-19fc-4014-abdc-b11cfa08727b

https://chatgpt.com/g/g-6a0359b38b988191813a2b28d62dc03d-re-prompt-a-governed-prompt-compiler

I'd especially appreciate failure cases more than success stories.

Thank you — Governed Intent Labs

Been building this for a while and finally put out a first release. Not going to oversell it, just going to describe what it actually does.

The core idea came from being tired of AI tools that give you one confident answer and leave you to figure out if it's right. So I built something where the output you see has already been challenged internally before it reaches you. Not the same model second-guessing itself. A genuinely separate process with a different job, specifically designed to find problems with what was just produced.

There are two sides to the app.

The first is a council mode where you load local AI models and assign them different roles. One role breaks down your task and makes a plan. Another executes against that plan. A third receives both the plan and the result and checks one against the other. For coding tasks it actually runs the code before the reviewer sees it, so problems get caught by execution rather than by a model guessing whether it looks correct. If problems are found it either patches the specific issues or rewrites entirely depending on how bad it is. What you get at the end has been through all of that.

It also has session memory that builds up as you work, a document pipeline that processes files into structured knowledge before you start asking questions, task history, a diff view showing exactly what changed between the original output and any revision, and confidence labels on every result.

The second is a normal chat mode that runs Python, JavaScript, C#, Java and PowerShell inline and shows execution results inside the conversation. Web search with full page content extraction, LaTeX math rendering, a thinking mode, document attachment, and chat branching where you can fork from any point in the conversation.

Both modes run locally on your machine using GGUF models. If you don't want to manage model files there is a cloud mode through OpenRouter using their free models, same full pipeline, no local setup needed.

No account. No signup. No subscription. Open the app and use it.

MIT licensed. GitHub: github.com/YoMosa2009/Axiom

Happy to answer questions about anything.

So a friend of mine vibe-coded a genuinely clean portfolio in Claude the other week like, properly nice, done in ten minutes. And then he just… stopped. "ok how do I actually put this on the internet?" We ended up spending more time going back and forth about Vercel vs Netlify and whether he needed to buy a domain than he'd spent building the thing. That gap has quietly annoyed me for years: it takes minutes to make a static site now, and an afternoon to deploy it.

So I built MakeMySiteLive. You zip the folder (or literally just paste one HTML file), upload, and you get a live URL with SSL. No repo, no build step, no server. That's the whole pitch.

A couple of things from building it, in case they're useful:

The dumbest call I made early was giving even single-page "paste one HTML file" sites a full version history with rollback the bigger sites had it, so consistency felt right. Shipped it, then ripped it back out a week later. Nobody pasting a one-off landing page wants to think about "v1 / v2 / roll back" they just want to overwrite the thing. Lesson I keep relearning don't copy your own abstractions just because they exist.

The part that actually ate my time wasn't the upload flow at all, it was custom-domain SSL. Getting "just point a CNAME and HTTPS works, renewals included" reliable (Cloudflare for SaaS handles the cert side) took way longer than I'd budgeted.

And the bit I didn't expect to enjoy: since AI usually generated the page anyway, I wired up a hosted MCP server so you can publish straight from Claude — say "publish this as a site" mid-conversation and it hands back a live link, no dashboard. Felt like the obvious endgame once it worked.

(Stack, for the curious: Next.js front end, Fastify + Postgres behind it, files on Cloudflare R2, Redis for caching and sessions.)

Free to try, one site, no card: www.makemysitelive.com and the MCP setup is written up here if that's your thing: www.makemysitelive.com/guides/deploy-website-with-ai-mcp

Genuine question for the people here who've built deploy-y things: is "skip the whole deployment ceremony for simple static sites" actually a pain you feel, or do you like the Git/Vercel flow and I've just built something only I wanted? Not fishing for compliments, honestly trying to work out if this is a real wedge or a me-problem.

Over the past few months, I noticed the same pattern.

The prompt gets longer.
The chat gets longer.
Context gets bigger.
Eventually, the conversation becomes the project.

I wanted something more structured.

So I started building FactoryOS, an open-source workspace for Spec-Driven Development and AI coding workflows.

The idea is simple:

• Product intent becomes structured specs.
• Specs become implementation plans.
• Plans become executable task groups.
• AI coding teams work on one bounded task at a time.
• Verification proves the implementation.
• Humans approve before anything important ships.

Instead of treating chat history as the source of truth, the repository becomes the source of truth:

.specs/    Product truth
.tasks/    Execution truth
AGENTS.md  Repository rules
skills/    Reusable workflows
code/      Implementation
tests/     Proof

I'm also experimenting with a small set of runtime roles instead of lots of specialized agents:

• Main Integrator
• Explorer
• Worker
• QA

The goal isn't maximum autonomy. It's reducing context growth, keeping token usage predictable, and making work easier to resume, review, and verify.

I'm interested in feedback from people using Codex CLI, Claude Code, Cursor, or similar tools.

A few questions:

1. What breaks first in your AI-assisted workflow as projects get larger?
2. How are you keeping context and token costs under control?
3. Do you think structured specs and task trackers are worth the overhead, or do you prefer chat-driven workflows?

Repository:
https://github.com/bymilon/factoryos

I'd appreciate honest criticism, especially from people who've hit the limits of long AI coding sessions.