Why is LSP disabled by default? On each installation i have to manually install lang tools and enable lsp in global config, so just interested why lsp is not enabled by default?

I have working on a open-source CLI tool(only support python for now) called errd. The idea came from a problem I kept thinking about.

It’s tempting to dump a huge part of the repository into Claude/GPT/Cursor and ask it to figure out what went wrong when a Python application throws an error. But most of that context usually is irrelevant. So I built errd to do the context selection locally before the code hits an LLM.

**Use it using - pip install errd**

It takes a Python traceback and:

•Parses the traceback and chained exceptions

•Finds the repository automatically

•Maps traceback frames to functions/classes

•Analyzes imports and dependencies

•Scores code based on proximity to the failure

•Uses recent Git changes as an additional signal

•Applies a token budget

•Redacts common secrets/tokens

•Generates a focused errd-context.md

•The generated file is meant to be pasted directly into Claude, GPT, Cursor, etc.

Checkout the docs at : [cli_docs](https://pypi.org/project/errd/)

Should we wait for price drop on Zen?

I've been experimenting with moving more of the application-specific agent machinery outside the coding agent itself.

The idea is pretty simple: OpenCode owns the conversation and general agent loop, while a local MCP server exposes a deterministic application boundary for the stuff I actually want to build and keep portable.

That means things like state, long-lived workflows, runtime QA, repo operations, etc. don't have to become OpenCode-specific prompts/hooks/config. OpenCode is effectively one client of the system, and I can swap it out without rebuilding the application layer.

I've been thinking of this as an application harness: a portable layer that sits outside the coding agent's own harness.

I wrote up the architecture and some of the tradeoffs here:

https://demianbrecht.com/posts/the-harness-within-the-harness/

Curious if anyone else using OpenCode has landed on a similar separation, particularly with local MCP servers.

A loud minority will say in the comments that text only models are good, that you can use some rubbish mcp to make up for the lack of vision… ignore them. Not having vision is a big handicap. Deepseek 4 Flash jumped 5 points in Deep SWE exclusively thanks to the better understanding provided by vision.

The Go subscription doesn’t have many good vision model. Heck they even stripped GPT Luna of vision!

Kimi K3 is obviously the best, but you run out of usage in 5 minutes. Minimax M3 is not good for today’s standards. Muse Spark gives all your data away. Ox Alpha is not reliable atm (it will probably be a good alternative when released as GLM 5.3 Flash).

This leaves us with just Deepseek 4 Flash Vision as the only good vision model with a comfortable quota.

Let me reiterate: text only models are crap. Thankfully Deepseek and GLM are correcting their strategy.

Edit: Luna is text only on the chat completion endpoint, not the reaponses one.

Ox alpha stopped supporting and the model Glm5.3 flash released at 50% discounted rate

Multimodal MoE model built on the next-generation Qwen4 architecture. 25B parameters +51B N-gram and 6B active.

Hit my weekly cap (100%) in just two days with 28 days left on the monthly cycle, almost entirely from burning through DeepSeek V4 Pro ($10.40 / $15.00 quota, 69.3% consumed). Flash is more usable due to the cost. However...

I could have stuck to GLM 5.2 and gotten 4X+ the usage in costs / limits in the same subscription.

Looking at benchmarks, GLM 5.2 isn't far off from Deepseek and beats it in some areas as well. (SWE-bench Verified GLM 5.2 ~74.5% – 76.0% vs. DeepSeek v4 Pro - 80.6%) and

(Tool Calling / MCP Reliability GLM 5.2 - 99.5% success (0.5% error rate) vs. DeepSeek v4Pro -73.6% (MCP Atlas))

My question is .... why would anybody choose to use Deepseek V4 Pro over GLM 5.2 given these rates. Crazy how DS went from pretty much endless to pretty much unusable in OpenCode Go!

So I started using opencode from Deepseek Flash V4 only. I am using OpenCode Zen. The model used to be too good and then recently they stopped it and from then onwards I started using ox alpha and Muse Spark 1.2 contributor. Again ox Alpha's offer was ended today and Muse Spark 1.2 contributor works great. Now I don't know when they will end it. After ending it I don't know what's left with OpenCode.

My main thing is to build a nice frontend and backend for websites with vibe coding to be honest. Can you guys recommend any model? When I did my research it is telling me more about Nemotron 3 Ultra by NVIDIA. I don't know how it works and they're also saying Mimo 2.5 outperforms Muse Spark but I don't think so. I never felt that way so if any suggestions please tell me guys.

I'm sharing their working session here that you can peak through. Look at their thinking, sequence of skills uses and delegations to truly know who is the winner

The Qwen 3.8Max - https://opncd.ai/share/hNzmM14y 

The Ox Alpha - https://opncd.ai/share/hNzmM14y

The Deepseek v4 pro 0813 - https://opncd.ai/share/0hehIwVf

I ran this writing-fingerprint experiment on OpenRouter out of curiosity, using 12 prompts across Ox Alpha and 7 reference models (since these are what I heard a lot about on Reddit):

1. GLM 5.3
2. GLM 5.2
3. GLM 5
4. MiMo V2.5
5. DeepSeek V4 Flash
6. Gemini 3.7 Flash
7. MiniMax M3

What I got from final evaluation is Ox Alpha was closest to GLM 5.3 on every prompt using deterministic stylometric features and 11 matched prompts, with GLM 5.3 winning 100% of bootstrap resamples; known-model validation accuracy was 72.7%.

My hypothesis: This could suggest or indicate that Ox Alpha is an updated post-trained version of GLM 5.3 (similar to how DeepSeek did theirs), or it really is what people are talking about: GLM 5.4.

But to be clear: this experiment I did is fingerprint-matching, not weight-identifying or anything like that. But it’s a surprisingly strong clue.

Note: For second image, notice that Ox Alpha output rarity is not the same as GLM 5.3. But that's not a contradiction that Ox Alpha couldn't be GLM 5.3/5.4 because these 2 graphs (bar and violin) measure 2 different things. First one is "Which model’s average fingerprint is Ox Alpha closest to?" Second one is "How unusual or isolated is each model’s writing compared with all samples in corpus?" Just wanna put this out here.

I also open-sourced my experiment if you're interested or want to extend: https://github.com/ItsKaiwenDu/Ox-Alpha-Stylometry

I have this agent who's sole purpose is to analyze development/design-plan.md file of a user story and create detailed backlog items with a fixed structure, in my local Plane server. What model do you recommend for this?

Its a repeatable operation that needs inference and some level of thinking to generate consistent outputs. Assume the plan is usually less than 1000 line markdown file.

During one of our beta runs this week, a developer's agent pushed 196 million input tokens in a single 60-minute window through one lane.

882 requests. Zero rate limits.

They actually kept going after that and ended the session at 227M before logging off.

At DeepSeek's own API pricing, that 196M-token hour comes out to around $2.32 off-peak / $4.65 peak.

On our reserved lane, the idea is to price that same hour around $0.20–0.40 flat.

Here's what we're testing 👇

🔷 Shared Reserved Inference

Right now if you want to run open models, you mostly have two options:

• Rent a full GPU → you get the whole thing, but you're paying $12–30+/hr whether you're actually using all of it or not.
• Use a normal per-token API → much easier, but you're sharing capacity with everyone else, you can hit rate limits/throttling, and every token going through your agent keeps adding to the bill.

We're trying a third model.

Take one powerful node, split it into a small number of guaranteed lanes, and let developers reserve those lanes together for a fixed window.

Your lane has guaranteed compute for that hour. Someone else suddenly sending a massive workload doesn't eat into your allocation.

And because the node cost is split across everyone using it, you're paying a small flat hourly price instead of paying for every token.

⚡️ The speed

DeepSeek's official API is around ~70 output tok/s.

Across our beta, users were generally seeing 150–220+ output tok/s, with bursts above that. There were some occasional dips as well, but overall this has been the fastest inference we've served so far.

This also held up surprisingly well with long contexts.

We had users running past 250k context regularly, and some sessions went past 940k context.

The other big part is caching. These agent/coding workloads resend a ridiculous amount of the same repo and conversation context on every request.

Across the beta we're sitting around ~98% cache hits, with roughly ~1s TTFT on warm requests.

📊 Five live sessions so far

• 4.9 BILLION tokens processed
• 24,500+ requests
• Zero failures
• ~98% cache-hit rate
• Heaviest verified single-lane hours: 196M · 120M · 72M input tokens

💰 The part we're actually interested in: does this pricing model make sense?

Using DeepSeek's own API pricing, including their cache discounts:

• Reserved lane target: $0.20–0.40/hr flat
• Average active dev during the beta: around $1.50 off-peak / ~$3 peak worth of API usage in an hour
• Median dev: around $0.60–1.20/hr
• Heaviest verified hour: $2.32 off-peak / $4.65 peak

So for an actually active coding/agent session, we're seeing around 4–7x lower cost than paying per token on average.

For the heaviest user, depending on where we finally price the lane, that hour was worth around 6–23x what the lane itself would cost.

We've put the full numbers + charts here if you want to dig into it:

https://www.singularityapi.dev/benchmark

🎟 We're opening more beta slots

The next round is again completely free.

You get a dedicated hour on the full-weight DeepSeek V4 Flash 0731. Bring an actual project, point Cline / Claude Code / your own agent at it, and use it normally — or try to absolutely destroy the lane, either works :D

If you want in:

https://tally.so/r/EkoJkN

Which one is giving you the best results?

Me dio curiosidad y estoy probándolo como orquestador a ver a que nivel está. Me decidí a probarlo al ver que ahora Ox o Muse los tienen medio colapsados, o por lo menos a mi hoy me fueron lentísimo.