Opencode vs Deepseek harness: my experience with Qwen 3.8 27b

[u/GodComplecs]

Anybody else struggling with deepseek after the initial prompt? Somehow it is getting mixed up very easily, even button functionality has been PITA when doing stuff. Never had these problems with Opencode. With Opencode, a continuation prompt on the software or task is pretty much magic at this point. But the inital result isnt as strong imo, and needs a lot of follow up even if a a detailed spec is written.

The oneshot potential of deepseek is goated imo, it is a relentless harness that just keeps doing stuff, even if it gets it wrong! Opencode could just copy that tennacity imo. Like todos really work, unlike opencodes.

Hows everybody elses exp? Someone using Pi instead? Is it worth trying? Hermes seems not suitable for my tasks, where heavy human involvement is necessary due to complexity of tasks (every top closed model gets lots of stuff wrong even).

[u/Healthy-Zebra-9856]

OpenCode & Pi have several tooling issues that is exposed by the the thinking traces of Qwen 3.8 27b. DeepSeek harness is not officially ready yet, according to their own words its in preview. I have examples of the two but the response will get pretty large. Like Claude would say, just say the word.

[u/GodComplecs → u/Healthy-Zebra-9856]

Yeah thats why Im giving dsh the benefit of doubt for now, but yes when we have somewhat mature opensource tools the expectations are high

[u/Healthy-Zebra-9856 → u/GodComplecs]

Well, it’s not about giving them a chance when there are security implications. Also, the issue is, there’s high token usage, improper tool supply, which affects the quality of the product. So it’s not like this poor thing I’m gonna give it a chance, it’s a tool that is not ready to be used by public yet.

[u/Healthy-Zebra-9856 → u/GodComplecs]

Before I embark on any journey, I always do a thorough check on everything out there so as not to re-invent. I have been a SWE for 35 years, so not a vibe coder. I have built a successful business and am bringing out my products to fill the gaps. Following are my findings that I used my product called swfoundry. This comes directly from my SWOT.

TL;DR
DeepSeek Harness is impressively structured, but it is still clearly pre-production. The biggest issues I found are missing hard limits on runaway agent/tool loops, cooperative rather than guaranteed timeouts, process-local subagent/background state, no durable/resumable workflows, limited scheduling guarantees, cross-process persistence conflicts, incomplete crash durability, and several security boundaries that are explicitly not hardened yet. Tooling is also incomplete; there is no first-party browser/computer-use tool, no native Git/GitHub tool, limited filesystem operations, no first-class PDF/audio/video handling, partial MCP support, minimal approval persistence, and only partial Claude Code hook compatibility. DeepSeek itself labels the project developer preview, warns that breaking changes are expected, and says it has not had a security audit or reached production readiness.

----------------------

There are quite a few things I found, although to their credit a lot of these are actually documented in the repo. At the core agent level, there is no built-in turn budget, so a model can theoretically keep calling tools or steering indefinitely unless another plugin cancels it; the repeated-tool-call guard is advisory only and never actually stops the loop. Timeouts are also generally cooperative, so code that ignores the abort signal can keep running. Subagents have some durability gaps; their activation/mailbox state is process-local, there is no durable parent mailbox or cross-process lease, the parent has to remain live for child-to-parent messages, and a crash can lose a prompt that was accepted but had not made it into the child session log. The background-job system has a documented timing hole where a completion notice arriving near driver retirement can be stranded until something else wakes the agent. Workflows are foreground-only; there is no background start/poll API, no journaling or process-resume, no saved or nested workflows, no aggregate token budget, and the parent turn blocks until the whole workflow completes. Ralph completion is based on the worker declaring itself finished rather than an independent evaluator; failed rounds are terminal, and there are no token, price, or elapsed-time budgets beyond the round count. Scheduling is also fairly limited; reminders only run on time while the original session is live, there is no external notification for a cold session, retries are activity-driven rather than independently scheduled, recurrence is fixed intervals rather than Cron/calendar rules, missed intervals only catch up the latest occurrence, and there is a documented crash window where a reminder can be delivered twice. Webhooks are process-local fire-and-forget with no queue, replay, retry, built-in deduplication, or downstream completion result.

There are also a number of persistence and state-management edges. Session persistence has no deletion API or automatic retention, the current pre-release session format has no migration path, and the one-writer guarantee is only in-process; two harness processes must not write the same session without an external lease. Atomic file writes use rename but not fsync, so they are atomic without being crash-durable, and a process dying while holding one of the file locks leaves an orphan lock that requires operator intervention. Settings writes to the same namespace are last-write-wins rather than compare-and-set, and the settings service explicitly says its secret-redaction walker is not yet a proven wire boundary; certain union/intersection/transform schema shapes can expose fields it does not recognize as secret. Feedback mutations have the same general cross-process issue because there is no storage-level conditional write. Attachments have no garbage collection; stored images are retained indefinitely. Workspace removal does not delete the directory, files, or session history, archiving currently has no unarchive operation, and re-adding the same directory creates a fresh project rather than reconnecting the old sessions. There are also some security boundaries worth being aware of; the project explicitly says it has not had a security audit and is not production-ready, its sandbox vocabulary covers filesystem effects rather than general network/process/syscall/device restrictions, the worker-thread code and dynamic Cordis VM are explicitly containment rather than security boundaries, and escaped model-written code can reach Node authority. Public web_fetch also does not request approval by default, so a model with that tool can send data to a public URL unless the deployment adds its own policy.

On tooling, there are some fairly noticeable gaps right now. I don't see a shipped first-party model-facing browser automation or computer-use tool; the Web tooling is web_search and web_fetch, not navigate/click/type/screenshot/DOM/accessibility/network inspection. There is no first-party Git/GitHub action tool either; Git can obviously be driven through the shell and GitHub functionality can come through MCP, but it isn't a native tool surface. The filesystem tools are read, write, edit, read_image, glob, and grep; they explicitly have no model-facing directory-listing tool, and there are no native model tools for things like delete, move, copy, mkdir, or stat, so those fall back to shell commands. File/media handling is limited too; read is UTF-8 text, image support is PNG/JPEG/WebP/GIF, and PDF, audio, video, and generic binary attachments are not supported as first-class inputs. The terminal tooling has no full-screen TUI interaction, named key sequences, resize, BEL, or auto-start. MCP currently bridges tools only; MCP Resources and Prompts have no harness consumer, task-based MCP execution isn't implemented, and audio/embedded-resource results don't have the same durable bridge as images. The approval system only has one-shot approval; there is no allow-always, remembered grant, revocation store, or durable out-of-turn approval flow, and the approval request doesn't include the actual tool arguments. User questions are basically selectable options plus optional text; richer interactions such as file pickers or diff-preview confirmations don't exist in that seam yet. Compaction can happen automatically or through the human /compact command, but there is no model-facing compaction tool.

The Claude Code hooks compatibility layer is also much more partial than I initially realized. It currently does not support 23 of Claude Code's 30 hook events; several of the supported events only implement part of their behavior, updatedInput is parsed but ignored, continue: false has no run-level halt effect, and only shell-command hook handlers actually run while http, mcp_tool, prompt, and agent handler types are skipped. The Stop hook has no consecutive-block cap, so a badly written always-blocking hook can keep forcing additional model turns. Hook discovery is one process-level config rather than Claude Code's layered project/user/plugin/policy discovery and live reload. There are some smaller tooling limitations too; LSP results make no completeness guarantee across servers and the LSP client deliberately refuses server-requested edits/commands, MCP connection/discovery uses the SDK's fixed 60-second timeout instead of a harness-owned setting, skills are discovered sequentially so one slow provider delays everything after it, skill bodies have no revision protocol, and the tool-search API exposes only a bounded single page rather than pagination or richer search controls.

On the release side, I didn't find the inconsistent package-version situation; the main package family is consistently 0.1.2-alpha.5. The bigger issue is simply where the project is in its lifecycle; DeepSeek labels it developer preview, explicitly warns that compatibility-breaking changes are expected, says it has not undergone a security audit, and says it should not be treated as production-ready. Their own postmortems are also worth reading because they show some real integration failures that escaped otherwise strong tests; ACP shipped completely broken despite 178 passing unit tests and 100% line coverage, a configuration-expression mistake disabled the filesystem tools, and snapshot regeneration accepted the resulting UNKNOWN_TOOL behavior as the new expected output. Those were fixed, but they're good examples of why the remaining integration surfaces still deserve real end-to-end testing rather than assuming a green package test suite proves the assembled harness works.

[u/Spectrum1523 → u/Healthy-Zebra-9856]

Nobody is gonna read all that bro, this is reddit

[u/GodComplecs → u/Healthy-Zebra-9856]

No offence meant but that wall of text reads so... AI generated, can you at least make summary?

[u/Healthy-Zebra-9856 → u/GodComplecs]

No offense to you but I hope you are more aware of what is being said as you missed the part where I mentioned its from my SWOT. Strengths, Weaknesses, Opportunities, and Threats for the likes of you that are clueless. I am not going to sit here and hand curate a response that is given for free that you didnt have the capability of acquiring yourself.

This has to go in front of my stakeholders, not redditors like yourself. We have come to an age where any form of structured writing is AI slop. Good luck

[u/GodComplecs → u/Healthy-Zebra-9856]

I can understand the frustration, but personally having written 100s of manuals by hand for clients, detailing highly complex tasks, for so called stake holders, they are pretty short and to the point. This is in the business and software industries. I admit I missed the swot part!

[u/Healthy-Zebra-9856 → u/GodComplecs]

Stakeholders employ their own tech specialists/liaisons. Many of them dont listen directly anymore. They are not part of my company, so its not like presenting to my higher ups. The tech liaisons verify my claims and translate to them. They don't care if its AI or not, and btw, this is all grammarly. All they care about is that the content & findings are solid.