DEV Community: Sergio Wolf Knapik

Are Local LLMs Actually Worth It?

Sergio Wolf Knapik — Sat, 26 Sep 2026 16:59:02 +0000

Hey everyone, I'm Wolf, and I survived another week!

This is update #2 in my journey building Wolf.IA.

Last week, I talked about finally hitting an MVP and having to face the hard part: marketing and distribution. Specifically for Wolf.Engine, a platform designed for building multimodal AI agents.
(Hey, feel free to give it a spin, too! Pretty please? wolf.ia.br/engine)

The feedback I received last week pointed out that my second project (focused on the Brazilian accounting framework) would actually be much easier to market and sell right now. And you guys are totally right. The Engine is still my pride and joy, but I need a cash cow to keep the operation alive.

So right now, I am:

Looking for distribution channels: Marketing is definitely not my superpower; I’m still completely lost.
Refining the accounting tools: Once this part matures a bit more, I'll launch targeted outreach.
Anxious as hell.
Developing the local app for the Engine: Dubbed Wolf.Park, it's still in its early stages, but I'm really happy with how it's shaping up!

During development, I decided to benchmark a few local models via Ollama + OpenCode. The whole point of building Wolf.Park right now is to slash my API costs, so if local models can shoulder any of the workload, that's a huge win.

The catch: My GPU is an RTX 4060 Ti with only 8GB of VRAM. That's tight for heavier models.

Here were the response times for generating a simple Python script to read and update text files:

┌────────────────┬───────────────┐
│     MODEL      │ Response Time │
├────────────────┼───────────────┤
│ gemma4:12b     │ 12m 29s       │
│ gemma4:26b     │ 8m 48s        │
│ gemma4:e4b     │ 1m 37s        │
│ gemma4:e2b     │ 31s  (!!)     │
│ ornith-1.5:9b  │ 11m 41s       │
│ qwen3.8:27b    │ 25m 40s       │
└────────────────┴───────────────┘

(I also tested qwen3.6 and phi4, but both were disqualified: the former hung for over 30 minutes without outputting anything, and the latter lacked support for tool usage in my setup).

All the tested models managed to produce files and functional code, but the quality varied:

gemma4:e4b and gemma4:e2b included unnecessary (though harmless) imports;
gemma4:e4b and qwen3.8:27b relied on lazy design patterns, dumping values into global variables instead of passing arguments between functions;
ornith-1.5:9b used overly generic exception handling.

However, one thing surprised me: ornith-1.5:9b was the only model that, after writing the script, actually tested its own code. It was also the only one that took the time to write a detailed explanation of how the script works.

Based on this small (and admittedly limited) experiment, I drafted this multi-agent workflow:

[User Request]
       │
       ▼
1. LOCAL GENERATION
   ├── Agent 0: gemma4:e4b ──> Generates base code
   ├── Agent 1: gemma4:e4b ──> Independent reviewer (harsh critic persona)
   ├── Agent 2: gemma4:e2b ──> Runs local linter & style review
   └── Agent 3: gemma4:e2b ──> Generates pytest unit tests
       │
       ▼
2. CLOUD REVIEW & ESCALATION
   └── DeepSeek v4 Pro ──> Reviews code + generated tests
       │
       ├───> [Approved] ──> Sent to human review.
       │
       └───> [Rejected: Low Difficulty]
       │         │
       │         └──> Gemma e4b/e2b attempt fixes
       │
       └───> [Rejected: Medium Difficulty or Low with Persistent Error]
       │         │
       │         └──> Ornith-1.5:9b attempts fix
       │
       └───> [Rejected: High Difficulty or Medium with Persistent Error]
       │         │
       │         └──> DeepSeek v4 Pro attempts fix
       │
       └───> [Architectural Impasse / 3rd Round Failure / High with Persistent Error]
       │         │
       │         └──> Gemini 3.8 Flash attempts fix
       │
       └───> [Unresolved Impasse / 4th Round Failure / Critical Escalation]
                 │
                 └──> GPT 6 Astra attempts fix ──> Sent to human review.

Will this actually work in practice? I don't know yet. Wolf.Park is being built to make orchestrating this kind of pipeline seamless, but for now... I'll be testing this scheme manually throughout the week.

Drop a comment below if you have any suggestions for local models I should benchmark and potentially plug into this pipeline!

Cheers!

I Built a Pretty Cool SaaS. Now What?

Sergio Wolf Knapik — Sat, 19 Sep 2026 20:58:31 +0000

Hello! My name is Sergio, but everyone calls me Wolf.

This is the first piece in a series I plan to write documenting my journey building my company, Wolf.IA, developing the wolf.ia.br platform, and sharing my mental state (among other things) throughout this whole process.

Forgive me if this sounds like venting or self-pity. That's not the intention. I just want to be clearly honest about what building a solo AI startup really looks like from the inside. Everything I describe below is my raw, current reality.

It has been 15 months. In the beginning, intense studying: understanding how AI works, the mechanics of LLMs, the differences between providers, and how to wrangle different APIs just to build a tiny functional app.

Back then, I was experimenting with Gemini 2.5 Pro. Yesterday, I deployed version 1.7.3 of Wolf.Engine, my AI agent platform, which:

Lets you create and chat with agents powered by Gemini, GPT, Claude, DeepSeek, Sabiá, GLM, and Mistral;
Features a very complex biomimetic memory system that prevents context rot;
Provides virtually infinite long-term memory without requiring manual context window management;
Includes Mini-RAG, a session-scoped knowledge base for chatting with your documents;
Offers deep agent customization (behavioral clans, speech styles, personality sliders);
Integrates natively with Telegram bots (your agent lives in your pocket, sharing the exact same long-term memory);
Generates and previews functional files (HTML, interactive code, CSV, Markdown) right in the chat;
Bilingual interface in PT-BR and EN.

I consider this version polished enough for real-world, everyday use. Every new user starts with three pre-configured official agents, each built around a distinct archetype. The UI is clean and distraction-free (at least in my opinion). Stripe billing and subscription tiers are fully wired up. Countless bugs have been hunted down and squashed over the past months. It took endless calculations, tests, and sleepless coding nights to get here. I am genuinely proud of the result, and I know it's truly useful.

But... now what?

As of today, I have exactly one paying subscriber. My monthly recurring revenue is 20 bucks.

And here lies my biggest hurdle: I am not a salesperson. I don't understand marketing. I don't like social media. I am neurodivergent, deal with social anxiety, and struggle with chronic depression.

And my financial runway has completely run out. Right now, I am being financially supported by my wife.

I recently had a meeting with an advertising agency (they actually liked the Engine! Who knows, maybe they'll even become clients!), but the cost of outsourcing marketing... I’d need roughly $5,000 USD for a 6-month campaign. My actual marketing budget is zero.

So, what’s the plan from here?

First, I’m going to focus on building my own proprietary local daemon and tool-calling system, which I’m calling the "Troll Bridge". With it, I can build a dedicated local app, inspired by OpenAI Codex, Claude Code, and OpenCode.

This will finally allow me to migrate ALL of my own development agents into my own system, running on 100% pure dogfooding. Wolf.Engine’s future development will be built by the Engine itself.

This gives me massive advantages: zero context rot, no need for manual /compact commands, and no agents losing their persona or forgetting project decisions halfway through. But above all: it will be significantly cheaper to run.

That might sound counterintuitive at first, with the underlying LLM APIs being the same, but here's why:

When using tools like OpenCode or standard agent interfaces, you pass the entire accumulating conversation history as context on every turn, making each message progressively more expensive than the previous one;
With Wolf.Engine, the agent's digested memories are decoupled from the active window and kept at a stable token size window. Conversations don't exponentially bloat in cost as you work.

In parallel, I will start sharing Wolf.Engine on X(itter), Reddit... Yeah, wish me luck. But I need people to know that my platform exists.

After that, I'll expand a bit more on the specialized Fiscal BI tools I've already developed (and some prototypes). That part is tailored specifically for the Brazilian market, because of specific accounting rules and tax laws.It’s a smaller, local market, but it has concrete enterprise pain and far less competition.

Well, that's it for this one. Next week, I'll be back to tell you if I survived.

Cheers to everyone out there building against the odds! 🐺

P.S.: I used one of my AI agents to translate my original text, as English is not my native language. Some errors mights have gone through, because I ended up rewriting a big chunk of the text.

Multi-Provider LLM Router, or How I Got Tired of Forgetting Which API Format I Had To Use

Sergio Wolf Knapik — Thu, 10 Sep 2026 03:53:49 +0000

If you've ever built an application that integrates with multiple LLM providers (Anthropic, Google, OpenAI, DeepSeek), you already know the pain:

Each provider has its own distinct Python SDK.
Streaming responses using Server-Sent Events (SSE) requires divergent parser logic.
Thinking / Reasoning blocks are formatted completely differently.

I recently extracted the core streaming router from my platform into an open-source FastAPI template. Here is how it works.

Objective

A single asynchronous endpoint:
POST /v1/chat/stream

It accepts a unified request payload and returns a standardized SSE stream emitting four clean events:

event: thinking — Internal model reasoning tokens (streamed in real-time).
event: content — User-facing response text.
event: tool_call — Function calling requests.
event: done — Stream completion ([DONE]).

Architecture

Instead of pulling heavy wrapper frameworks, use direct asynchronous HTTP via httpx.AsyncClient and the official Google GenAI SDK:

fastapi-multi-llm-starter/
├── app/
│   ├── config.py       # Pydantic Settings loading environment variables
│   ├── main.py         # FastAPI app with CORS, health check & test playground
│   ├── models.json     # Dynamic model catalog (Claude, Gemini, GPT)
│   ├── router.py       # Unified multi-provider async stream dispatcher
│   └── schemas.py      # Strict Pydantic v2 validation models
├── tests/              # Automated unit tests (pytest)
├── requirements.txt
└── README.md

Dynamic Model Catalog

I disliked the idea of hardcoded models, so I decoupled them into a models.json file:

{
  "models": [
    {
      "id": "claude-sonnet-5",
      "name": "Claude Sonnet 5",
      "provider": "Anthropic",
      "thinking": true
    },
    {
      "id": "gemini-3.8-flash",
      "name": "Gemini 3.8 Flash",
      "provider": "Google",
      "thinking": true
    },
    {
      "id": "gpt-5.6-terra",
      "name": "GPT 5.6 Terra",
      "provider": "OpenAI",
      "thinking": true
    }
  ]
}

Now, if you want to add another model, you just edit the JSON. The backend and the embedded UI dynamically populate available models via GET /v1/models.

Testing Playground

The repository includes a testing playground running directly at http://localhost:8000/. You can immediately test prompts, check streaming latency, and verify reasoning blocks without setting up a frontend framework.

Of course, you'll need your own API keys.

Open Source Code

The full core code is open-source under the MIT License on GitHub:

👉 github.com/wolfnomknight/fastapi-multi-llm-starter

Includes full pytest test coverage, .env.example, and clean Pydantic v2 schemas.

Feel free to fork it, use it in your side projects or micro-SaaS, and let me know if you run into any issues or have ideas for additional providers!