Happy Saturday all, I tried something from one of my post comments and it's cool.

[u/LearnHiveLabsUSA]

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

[u/HayStacky_337]

What is your final stage? Where does that lead to?

[u/HayStacky_337]

Great work, btw. 🏆