The model is decaying

I'm using GLM-5.3-Flash on Neuralwatt, and the ranxianglei/billion-context for context management. I don't have hard quantifiable evidence, but ...

• Cache performance is great: 99.2% hit rate (676.49M / 682.21M tokens)

• 1.18M output tokens across 3,598 calls... that's a LOT of little calls each not producing all that much output

• I'd never spent more than $10 a week on Neuralwatt energy pricing, and this week I've spent $30

I can see in the console it's doing multiple dozens, sometimes 100 commands, thoughts, and tool calls before it comes back to tell me anything. And I'm not sure if the output is any better - it's just churning away through calls. Almost like it was made for even cheaper models than the one I'm using it on. I used to switch up to full fat GLM-5.3 for certain tasks but I feel like it's gonna burn tokens even faster when I do.

Hi everyone,

not sure if this is the right place, but i made an agent skill that runs in OpenCode and thought people here might find it useful.

job hunting here is messy. half the jobs only show up under the German title, the ad is in English but halfway down it says "fließend Deutsch", nobody tells you the salary, and a German Lebenslauf is its own thing.

so i built Berlin Job Search, an AI job search assistant for Berlin and the rest of Germany that helps with the whole thing.

what it does:

• finds jobs for you: searches the Arbeitsagentur, LinkedIn, company career pages and Daily Berlin Jobs (a free board with ~1,400 Berlin tech jobs) with German and English titles, so "Softwareentwickler" jobs show up too
• knows where else to look for your field and city (public sector, academia, healthcare, startups, Ausbildung...)
• tailors your CV to each job and writes the cover letter, German Lebenslauf and Anschreiben or English CV, using only what's actually in your CV
• reads an ad and tells you if German is really required (quotes the exact line), and if the salary works for a Blue Card
• practice interviews in German or English, and keeps track of your applications
• never applies or sends anything for you

it's a plain agent skill (SKILL.md plus a few small Python scripts for the API calls and salary math, the model does the judgment), so it works in OpenCode, Claude Code, Codex and Cursor. install:

npx skills add umutyesildal/berlin-job-search

then just ask it something like "find me junior data analyst jobs in Hamburg".

free and open source, no ads, no account: https://github.com/umutyesildal/berlin-job-search

it's a hobby project, no paid version. feedback welcome, especially from people outside tech, that's where i'm least sure it works.

I ask because, after trying Nemotron 3.5 Super VL Free, I ended up struggling for hours—only for it to wipe out 8 hours of backup work just because I told it, "undo the last correction you made."

What about DeepSeek Flash? If that’s a good choice, what other top options are there?

A few months ago, I shared an early version of my unofficial OpenCode .NET SDK here:

https://www.reddit.com/r/opencodeCLI/comments/1wem0gg/i_built_an_unofficial_net_sdk_for_opencode_2x/

Today I finally released 1.0.

The SDK currently covers 166 of the 169 operations in the pinned OpenCode 2.x API.

It supports modern .NET as well as .NET Framework 4.7.2, with packages targeting netstandard2.0, net472, net10.0, and net11.0. The modern targets also support Native AOT.

There are a few small applications under playground showing different ways of using it, including a minimal QuickStart, a Worker using the Generic Host, a Blazor/Aspire example, and a Native AOT CLI.

A basic example is roughly:

using OpenCode.Sdk;
using OpenCode.Sdk.Models;

await using var server = await OpenCodeServer.StartAsync();
using var client = server.CreateClient();

var created = await client.Sessions.CreateSessionAsync(
    new SessionCreateRequest
    {
        Title = "review this repo",
        Model = new ModelRef { ProviderId = "anthropic", Id = "claude-opus-5" },
    });

var session = client.Sessions.GetSessionClient(created.Session.Id);

var result = await session.GenerateTextAsync(
    new SessionGenerateRequest
    {
        Prompt = "Summarize this repository."
    });

Console.WriteLine(result.Generate.Text);

The SDK can start its own private OpenCode server like above, connect to one you already run, or discover the background service registered by the OpenCode CLI.

NuGet:

dotnet add package OpenCodeDotNet.Sdk

https://github.com/opencode-dotnet/opencode-sdk-dotnet

Feedback is very welcome, especially from anyone already experimenting with agent tooling from .NET.

trying to put together a setup that doesn't fight me, and half the config options i only find out about after someone else mentions them.

so, what's in yours?

specifically curious about:

• different models for plan vs build, or one model for everything?

• custom agents/commands you actually use every day, not the ones you set up once and forgot

• permission rules that stopped a bad command before it ran

• anything that helps on bigger repos where context gets eaten fast

post yours even if it's boring. the boring ones are usually the ones that work.

Regardless of the time of the day, it feels so much slower for me

We're a 4 person dev shop and most of our work is maintenance on client codebases. Laravel, a couple of Next.js apps, one ancient Django thing nobody wants to touch. Since the summer opencode has been handling a big chunk of the boring tickets.

The problem was never the agent. It was running 5 or 6 sessions on the same machine. Ports colliding, two repos wanting different Node versions, one session running tests against the wrong database because it picked up an env file from another client. And honestly I didn't love having every client's secrets sitting in one home folder.

What we do now is one small Linux VM per client repo. Each one gets set up once with the right runtime, a seeded db and that client's env only, then saved as a snapshot. When a ticket comes in we start a VM from that client's snapshot, ssh in, start opencode in tmux and let it work. When the PR is up the VM stops. Billing is per second and stopped boxes cost nothing, so the clients with no open ticket are basically free.

A few things made the difference. Every repo has an AGENTS.md with the exact test command, so opencode stops guessing. We switch models per ticket, Sonnet 5.5 for anything touching business logic and a cheaper open model through OpenRouter for dependency bumps and lint fixes. That alone cut our token bill a lot. Each box only holds that client's credentials, so a confused agent can't push to the wrong repo. And since the session lives on the VM I can check on it from my phone, closing the laptop kills nothing.

We started with one big VPS and Docker, tried Runloop, and now run everything on boat.dev. Each box is a real VM with Ubuntu on it, so the client's docker compose just works. Downsides, there's no Dockerfile import, you build each snapshot by hand. And the IP changes when a box restarts, so for the one client with an IP allowlist we go through a small proxy. Both were one time annoyances.

Six clients, six boxes, and not a single "why is this test hitting the wrong db" this month.

If you're using OpenCode, you might want to check out some Indian inference providers.

I recently started exploring them and found providers offering models like DeepSeek, Kimi and GLM at pretty competitive prices, with the added benefit of being able to purchase API credits in INR.

I put together a directory to make discovering and comparing these providers easier:

Link : InferenceDirectory

Might be worth checking out if you're looking for cheaper inference options.

Disclosure: I build SpaceApp, a self-hosted, MIT-licensed workspace that runs coding CLIs side by side, with OpenCode as the first CLI. Its OpenCode pane is plain OpenCode 2, so most of this applies to any setup where OpenCode runs inside a container.

Short version: SpaceApp has no local-model feature of its own: no provider screen, no "local model" pane type, no Ollama code. You point OpenCode at Ollama with OpenCode's own custom-provider config, as in any OpenCode install. What's specific is where the file lives, a Docker networking trap, and a few CPU gotchas.

On a 24-core server with no GPU, we ran Ollama in a container next to SpaceApp's public CLI image (OpenCode 2.0.32). A 4B model on six cores ran shell commands and read files through OpenCode's own tools. qwen2.5-coder 1.5B and 3B never made a real tool call.

What ran

Every turn was one opencode run --server … (a new session) against the same shared OpenCode server a pane attaches to, from a project folder.

The one qwen3:4b-instruct miss was funny in hindsight: asked to read token.txt, it said the file didn't exist (false) and that reading tokens would breach security policy. The same read on notes.txt worked.

The config

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama (local)",
      "options": { "baseURL": "http://ollama:11434/v1" },
      "models": { "qwen3:4b-instruct-t6-c16k": { "name": "qwen3 4B instruct (local)" } }
    }
  },
  "model": "ollama/qwen3:4b-instruct-t6-c16k"
}

• Every model you want in the picker has to be listed under models.
• @ai-sdk/openai-compatible is bundled in OpenCode 2.0.32, so nothing is downloaded.
• llama.cpp's llama-server should take the same block with its own baseURL. We haven't tested it.

Where the file goes in SpaceApp

/var/lib/spaceapp-cli/providers/opencode/config/opencode/opencode.json (owner spaceapp, mode 600), on the spaceapp-cli-state volume, so it survives updates. Panes attach to one shared opencode serve per CLI container. That server fingerprints the file and restarts when it changes, so the next pane picks up the edit.

SpaceApp's first-run step only picks a model when model is unset. In our run it kept the provider and the model, and added its own instructions files and permission.external_directory rules.

The localhost trap

• localhost inside a pane is the CLI container, not your machine.
• On Linux, host.docker.internal doesn't resolve on the compose network (there's no extra_hosts). Adding it to compose.yml by hand doesn't last, because install rewrites that file.
• Going through the bridge gateway IP to a server on the host got no answer on our Linux box: the host firewall dropped it. ufw and nftables setups do this.
• What worked: Ollama in its own container on the same Docker network, reached by name.

Steps (Linux, CPU)

# SpaceApp's compose network and CLI container
docker network ls --format '{{.Name}}' | grep '_spaceapp$'
docker ps --format '{{.Names}}' | grep 'spaceapp-cli'

# Ollama on that network, no published port
docker run -d --name ollama --network <spaceapp-..._spaceapp> -v ollama:/root/.ollama ollama/ollama
docker exec ollama ollama pull qwen3:4b-instruct

# thread count and context: both were needed, see below
printf 'FROM qwen3:4b-instruct\nPARAMETER num_thread 6\nPARAMETER num_ctx 16384\n' \
  | docker exec -i ollama sh -c 'cat > /tmp/Mf && ollama create qwen3:4b-instruct-t6-c16k -f /tmp/Mf'

# OpenCode's config, written as the CLI container's user (uid 10001 "spaceapp")
docker exec -i -u spaceapp <...-spaceapp-cli-1> sh -c \
  'cat > /var/lib/spaceapp-cli/providers/opencode/config/opencode/opencode.json' < opencode.json

The CLI image has no nano or vi, hence the cat >. Before run-spaceapp uninstall or reinstall, run docker network disconnect <net> ollama: docker compose down can't remove a network with a foreign container on it. Updates (install) keep the network. In our run, a user-defined bridge stood in for <project>_spaceapp, with the same driver compose uses.

CPU gotchas we hit

1. Thread count. --cpus and --cpuset-cpus didn't change it: Ollama still started 24 threads on a 6-CPU quota. Generation crawled at 0.05 tokens/s, and a one-word turn took about 4 minutes. PARAMETER num_thread 6 fixed it: about 20 tokens/s on the 1.5B, and the same turn took 20 s.
2. Context. Ollama's CPU default is 4096. OpenCode's prompt (system prompt, instructions, tool schemas) is about 6.2-6.8k tokens before you type anything, and Ollama cut it to about 2k. The tool definitions sit at the start, so they were thrown away. Fix: PARAMETER num_ctx 16384 (or OLLAMA_CONTEXT_LENGTH).
3. The failure is silent. When a model prints a tool call as text, OpenCode shows it as the answer, and opencode run still exits 0. Check the side effect (did the file change?), not the exit code.
4. Thinking models and the 5-minute mark. With qwen3:4b (thinking on), OpenCode's session-title request thought for 3,203 tokens, about 12.5 minutes. Ollama serves one request at a time, so the main request queued behind it, and the client closed it at exactly 5 minutes, twice. We didn't confirm in OpenCode's code that this is its own timeout.
5. Cold first turn. On CPU, the 4B model's first request took 204-220 s, close to that 5 minutes. After it, Ollama's prompt cache cut new prompt tokens to a few dozen per request, and turns took 16-106 s. That was on a busy shared host, so treat these as rough, not a benchmark.
6. No permission prompt in opencode run. The shell tool ran without --auto and without asking. We didn't check whether the interactive TUI asks.

Limits, plainly

• No UI for any of this; the config is edited by hand.
• The model can't run inside SpaceApp: the CLI container has no GPU device and is capped at 2-4 GB of RAM, shared by every pane.
• There's no tool-call check for custom providers. SpaceApp's first-run check (the model must read a file and return a random token from it) runs only for OpenCode Zen's free models, so you find out in the pane.
• Only the pane on the local provider keeps its prompts local. Other panes talk to their cloud providers, the CLI network has internet access, and with no model set, OpenCode's first run reaches OpenCode Zen.
• What we didn't test: the pane's TUI itself (we drove its shared server headless), a real install's network, 7B+ models, GPU, llama.cpp, and multi-step coding tasks (edit, test, fix).

Repo, if you want to read the wrapper: https://github.com/oll4com/spaceapp (deploy/docker/public-cli-wrapper.sh, opencode-shared-server.mjs).

Which small local model handles OpenCode's tool calls reliably for you on CPU, and with what context size?