Post

Are you using open models on a regular basis? If yes, I’d love to hear about it! - what’s your use-case? - local or through an inference provider? - how has the experience evolved over time? - anything you miss from the closed models, if you’ve used them? Would appreciate reposts for visibility 🙏

28 reposts54 likes

I run a portion of all of my automated work through open models via an inference provider. When the observed difference in output becomes negligible, I demote that task to an open model full-time. Partly cost optimization, but mostly to ensure my tooling is still valuable when token subsidies end.

It's kind of hard to describe without providing a ton of background, but basically all of the code generation steps in our automated issue workflow are now done by cheaper models. The issue shaping, implementation validation, etc are still done by high-end models.

30k foot view is Opus says what tests to write. A cheap model writes them. Opus verifies that they're the right tests covering the right things and that they're actually failing. Then the cheap model writes the implementation to satisfy the tests. Opus reviews that work.

I have a fairly sizable local lab for running open weights. I use it to replace casual chat LLMs, I only use cloud tokens for coding, but would like to transition usage to entirely local inference. Focus of my work is to have a fully local autonomous stack with in-weight learning.

Are you creating your own model for in-weight learning or are you using some existing base model and building on top of that? How often do you update the weights? Do you have problems with catastrophic forgetting?

It's a lot of *infrastructure*. Less exciting work has happened (so far) at the model side than making sure weights are check-pointed and distributed via Git / Huggingface, server side sandboxed tool use, OIDC / Oauth scopes and policy, etc. Model-wise, working with Qwen3 dense models.

I started some work on Qwen3 Omni model architectures and Janus, but priority is a complete agentic loop. The next release will have MCP support with enough tools to instruct the model to re-train itself. After the loop is closed, I'll worry about the *quality* of the results.

I’ve been using Kimi 2.5 via the OpenCode free preview, it’s not the smartest thing at solving problems, but it does a good job for planning & drafting docs that other models can then pick up on. Briefly tried Qwen 3 coder via ollama locally, but it’s slow and often fails at tool calls.

Both, and the quest for a local model that is good enough to serve as a replacement if/when the AI giants’ bubble bursts. But that’s more a prepper’s mindset than actually using it for serious work.

- textual analysis of song lyrics (text corpus). extracting keywords, analyzing metaphors (!), tagging emotions. - local (RTX 3090) - i decide EXACTLY when to update model. models got good enough in llama 3.1 timeframe (haven't updated since) - closed models are better but cheat by knowing songs!

Yeah. The original experience was a collection of Pydantic AI agents and a loose collection of torch and various bits. Today I've switched over to goose for the easy to use recipes that can be used as sub agents and let you specify a model. Unfortunately the logging leaves a lot to be desired.

I have mostly abandoned thinking models for loops and supervisors. I use a fair amount of obsidian (basic features, mostly just markdown, webclipper, and quickadd). Having a couple of goose recipes/Pydantic AI agents to go parse through todo and reminders to take care of my pets is the most basic.

For actual work, I use GLM at the moment to go through and build grpc connectors, write documentation, and create diagrams with the mermaid MCP. Mostly not necessarily to write the code but to improve code quality. And embeddings. Lots of local vector search/hybrid search.

My eventual end goal here is to replace platform offerings (ie: Claude) with a multi model pipeline of tools and structured outputs. This is the exact same thing any developer did when learning monolith bad, microservices good.

Been running local models for about 5 months. I started with a laptop but then I upgraded to a proper tower with most current GPU, CPU money could buy and 64gb ddr5 ram. I'm mostly using it for research and report writing. I only get hallucinations if there isn't any data, otherwise, all good.

Used GLM-5 through OpenCode as the implementer of a plan that Opus created. Price was the main factor. It felt fast, and got the job done.

I do exactly the same, have a Claude subscription with a custom "create-spec" skill and then use opencode and free/cheaper models (with a custom "implement-spec" skill 😅) to implement.

There are many advantages. I like to try tiny models like Phi3-mini or Gemma3 4B and to enhance their performance. You can develop simple agents and try to solve basic conversational tasks with them, like orchestration. Some of them even capable of tool calling, but it's not stable yet

ive only used the zai coding plan for months. the difference between their top models and anthropics is nowhere near worth the price difference for me. ive never hit the limits of the cheapest plan. i also run a small qwen model locally for simple stuff, like tagging and summaries in karakeep.

1. Extracting summaries/info from paragraph to page-length texts across medium scale (100-1000 books); also framing and answering questions about them. 2. Local. 3. I’ve gotten better at it and have realized that reasoning models can be overkill. 4. I don’t try open for coding and big concept tasks.

Motivation is slightly cost, but more that I can share an open workflow with students and collaborators without making *them* pay or introducing complex accounting.

Have you developed a good sense for categories of tasks that don’t require reasoning? What’re some examples?

Not sure I have a well-worked-out theory. I have observed a) non-reasoning models suffice for most summary and extraction tasks b) reasoning models may be slower or more fragile — can overrun token limits and, more tentatively, c) reasoners can sometimes "overthink," overreacting to one detail +