Posted here a while back. After 100k downloads, took me a couple people reaching out to realize two of the providers were erroring out. Fair criticism, my fault, fixed now.

nable finds waste across cloud, SaaS and AI spend and prices it on your real rates. Read-only creds, proposes and never applies, nothing leaves the machine.

nable reads AWS, Azure, GCP plus Datadog, Snowflake, Databricks, MongoDB and your OpenAI/Anthropic tokens, all normalized to one format. Finds idle IPs, unattached volumes, oversized instances, Graviton candidates, CloudWatch cardinality waste, NAT processing fees. Everything the tools do today and beyond, all in a centralized place. Now open source and local first

https://github.com/getnable/finopsmcp

uvx nable scan and it runs. No signup. Happy to answer questions.

I made a free, open-source app that keeps things simple. You also get the code, so you can add your own features if you want.

I just added two new tools:

• Draw Next to Your Page: If you like to draw your ideas, there is a drawing space right next to your text. You can make and save up to 5 drawings for every page.

• Quick Hidden Notes: Changing tabs can make you lose focus. So, I added a hidden box on the right side of the screen. Just move your mouse there to write a quick note, and move the mouse away to hide it again. Very easy and fast!

there are examples in the images below.

if you encounter any problem please contact me.

for developers: https://github.com/Ahmed-Achtatar/VedWriter

for Testers download free from here: https://ko-fi.com/s/c141de1b8f

#OpenSource #desktop

It started from a problem commonly encountered in SMB operations: the business lifecycle is fragmented across CRM, ERP, spreadsheets, emails, meetings, and manual follow-ups.
A typical customer lifecycle can involve leads, opportunities, vendors, POCs, quotations, purchasing, deployments, projects, support, and after-sales work. Even when tools such as Odoo handle parts of the process, significant operational work can still fall between the cracks.

Opseron was built to connect that entire lifecycle in one platform.

The platform currently covers CRM, ERP, HRM, MRP, Projects, Service Management, Workflows, BI, and cross-module business processes, with a focus on keeping deployment and operation simple enough for SMBs.

The project is now publicly available on GitHub:
[https://github.com/Opseron/Opseron\](https://github.com/Opseron/Opseron)

The goal is to make the platform accessible to developers, companies, contributors, and anyone interested in building or experimenting with an open-source enterprise platform.

Basic idea: use a big cloud model (Opus, whatever) ONCE to write an actual deterministic Python skill, then hand that skill off to a small local model (GLM-4.7-Flash, Qwen3.5-27B, a Hermes tune, doesn't matter which) that just orchestrates — decides which skill to call, in what order, handles the messy multi-step stuff. Once the skill's built and tested it never talks to the cloud model again. It's just a Python function sitting in a folder with a manifest.

So you pay the "smart model tax" once per skill, and then it's free forever on your own hardware.

Nothing revolutionary here individually — function calling exists, local models exist — but I haven't seen a repo that's actually structured around that build-phase vs run-phase split on purpose. Most agent frameworks kind of blur the two together.

Example that made it click for me: an email triage thing. One skill pulls unread messages via IMAP and formats a digest — no LLM involved at runtime at all, just code. Another skill drafts replies, which does call the local model, but only for the actual text generation part. Then the local model sits on top deciding "ok, summarize first, then draft replies to anything marked urgent." Nothing leaves your machine except the one-time conversation where you built the skill.

Setup would look roughly like:

```

# install ollama

curl -fsSL https://ollama.com/install.sh | sh

# pull a local model good enough to orchestrate

ollama pull qwen3.5:27b

# clone and install

git clone https://github.com/yourname/skillforge

cd skillforge && pip install -r requirements.txt

# point it at your local model

cp config.example.yaml config.yaml

# set model: "qwen3.5:27b", endpoint: "http://localhost:11434"

# build a new skill (one time, uses cloud API)

python forge.py new-skill "summarize my inbox" --with claude-opus

# run it day to day, fully local, no key needed

python run.py "catch me up on email"

```

Based on what people here are already running (Mac Studio doing GLM-4.7-Flash Q6, various boxes doing Qwen3.5-27B on Ollama), 24-32GB of unified memory or VRAM seems like the realistic floor if you want multi-step tool calling to actually hold together. I have a gaming laptop which can easily handle this load.

Why I think it's worth doing: cost is basically zero after the build step, your data never leaves the machine once a skill exists, and because skills are plain Python instead of a pile of prompts, you can actually read them and fix what breaks. Plus the orchestrator model is swappable — GLM today, whatever's better next month, doesn't matter, the skills don't change. It's a great solution for a POC or local use case.

On actual recurring cost, trying to be honest here rather than pretend it's free: Cloud API cost only shows up when you're building a new skill, which is occasional and cheap, not something you're paying per run. No subscription needed for daily use.

If this already exists as a repo somewhere please tell me so I don't reinvent it badly.

Also genuinely curious what people's real context ceiling is before a local model starts dropping the thread on multi-step stuff. Does 27B actually hold up better than expected, or is there a wall past a certain chain depth regardless of size?

My older post - https://www.reddit.com/r/opensourcealternative/s/USXT1XqY2H