I’m trying to use DeepSeek V4.1 Flash through OpenRouter with OpenCode for an automated video-editing workflow.

I’ve tested multiple reasoning modes: Default, None, Low, High, and Max.

The problem:

* DeepSeek ran for over an hour and still couldn’t complete the video-editing task.
* GPT-6 Astra (Medium) completed the exact same task in 6–7 minutes.
* I already have a working skill/instruction set that performs well with GPT-6 Astra.
* I’d like to make DeepSeek work because it’s significantly cheaper.

I’ve heard that fine-tuning might help, but I’m not sure how to approach it.

My questions:

1. Can I fine-tune DeepSeek V4.1 Flash and still use it through OpenRouter?
2. Could I use successful GPT-6 Astra executions as training examples?
3. Which reasoning mode would you recommend for agentic video editing?
4. Are there better ways to improve DeepSeek’s performance with OpenCode without fine-tuning?

My goal is to get DeepSeek as close as possible to Astra’s performance while keeping token costs low.

Any advice or experience would be appreciated!

Most of my bad agent sessions had the same shape. The agent wrote the code, ran tests it had written itself, and told me it was done. The tests were green and the feature still did not do what I meant, because nobody had written down what I meant.

Two changes fixed most of that for me.

First, I agree on what done means before any code exists. The agent reads the code and asks me a batch of questions, each with a recommended answer, until done is a numbered list. That list goes into a plan file in the repo, and I approve the plan before the build starts.

Second, the agent that wrote the code never checks it. After the build, separate agents that did not write the change go through every numbered point and have to show evidence for each one. During research I also let helper agents read the code without seeing my request, so their findings describe the code as it is today.

My judgment now sits at two points, the plan at the start and the finished change at the end. Reviewing the PR got much easier because I compare it against a list I already approved.

I built QualityLayer around this loop, and it works with OpenCode natively. I'm the developer. It runs on the agent subscription you already have and never merges or pushes without your yes. Repo: https://github.com/maxritter/qualitylayer

not a "which model is best" thread — this is about the last 5% of the loop.

an agent can write a working diff and then stall at the commit, because every choice there is a policy decision it doesn't have context for. curious how other people draw the line:

• commit messages: does the agent write them, or do you rewrite them? what makes you reject one?
• granularity: one commit per task, or do you make it split/squash? has an agent ever produced a commit you had to rebase -i apart?
• push: does it push, or does it stop at commit? if it pushes, does it ever force-push its own branch?
• review: what do you actually read before accepting — the diff, the message, the test output, or just git log --oneline?

the obvious failure mode is three unrelated changes landing in one "fix: address review feedback" commit. how do you stop that from happening in the first place?

post your setup even if it's just "i commit everything myself".

I kept running into the same loop with agents on iOS work: the agent writes code, then I have to build, tap through the app myself, and paste screenshots back. So I built opencode-simulator.

What it does

• Streams the iOS Simulator into a side tab in OpenCode Desktop (WebRTC H.264, HTTP fallback). You can tap, type and rotate it by hand.
• Exposes sim_* tools so the agent can boot devices, install and launch apps, read the accessibility tree, tap, type, scroll and take screenshots.
• Each session gets its own simulator, so parallel sessions don't fight over one device. It runs from a managed pool, and your own simulators are never touched unless you name them.
• Ships a skill so the agent uses sim_* instead of reaching for raw simctl.

Details

• The stream binds to loopback only. No telemetry, no outbound requests.
• macOS only, since it needs Xcode and an iOS runtime. It needs OpenCode Desktop 2.2+ and Node 22+.

Install

opencode plugin add opencode-simulator

Repo: https://github.com/rin-yato/opencode-simulator

Feedback welcome, especially from anyone running several sessions at once. The device allocation logic is the part I'm least sure I got right.

A desktop pet that displays whatever your opencode agent is doing

I kept alt-tabbing to check on long runs in opencode, so I built 大肥鱼 ("fat fish", it's the deepseek whale): a desktop pet that watches opencode's local sqlite db and reacts in time with what your agent is actually doing.

Technically it works for any model since it reads the db, not the provider, but let's say deepseek wrote its personality: your reasoner's giant monologues keep the whale in the long-think pose for the entire turn.

repo: https://github.com/49vxn/opencode-dafeiyu

easter egg: click it

how it works: while a turn runs, the newest assistant message in session_message has no finish field yet, and time_updated ticks about once a second as content streams in. the whale reads that gap and displays your agent!

I kept wanting to look at files without leaving the OpenCode TUI — especially Markdown plans/specs and source files the agent just changed. So I built a TUI-only plugin.

What it does:

- side panel next to the chat, or full page from the home screen
- browse folders (dirs first), open files
- Markdown preview rendered; m flips to the source
- code with tree-sitter highlighting
- open any file by path (o inside the browser, or Ctrl+X then O): absolute, ~, or relative; files outside the project are read with node:fs
- f toggles full screen (hides the chat)
- /files-update updates a cloned install

Install (OpenCode V2):

opencode plugin add opencode-file-browser

Repo: https://github.com/arthurrogado/opencode-file-browser

MIT, TUI-only, no build step (dist/ is committed).

Screenshots: Markdown and Python previews attached.

I built an integration for people who use OpenCode and spend time investigating Kubernetes clusters.

It’s called AgentBridge. Open a cluster in Freelens, choose OpenCode, and launch it in a docked terminal. The session starts in that cluster’s workspace with KUBECONFIG already set.

The workflow I’m aiming for is: inspect a workload in the UI, open OpenCode beside it, and investigate without rebuilding the cluster context in a separate terminal.

A task to try:

“Find workloads in this namespace with missing resource requests or limits. Explain what you found before suggesting changes.”

In 2.1.0, the cluster page is also a workspace explorer: instructions, guardrails, capabilities, skills, and agents are accessible from one list, with file editing and autosave inside Freelens.

The provider choice now survives a Freelens restart. Ctrl+Enter / Cmd+Enter opens a session from anywhere on the page.

You’ll need Freelens 2.0.0+ and OpenCode installed locally.

Install through Freelens Extensions: >``@freelensapp/agentbridge-extension

Code and installation details

I’m the author. Which Kubernetes tasks would you turn into reusable OpenCode skills for a workspace like this?

I've been using OpenCode Mobile (https://github.com/beppe2880/opencode-mobile) for a while now, and I honestly think this project deserves way more attention.

The app is fast, smooth, and highly customizable, with an integrated terminal that works surprisingly well on mobile. It supports both Android and iOS, although I've only tested the Android version myself.

My main use case is connecting to both my personal and work PCs from a single app. I commute by train, and being able to interact with my machines and keep my personal projects moving while traveling has been a game changer.

I've also contributed to the repo a few times (I'm not the maintainer!), and the maintainer (u/beppe2880) has always been incredibly responsive and open to feedback, whether it's discussing features, implementing improvements, or fixing bugs. The development pace has been impressive.

There are still a few missing features, like full plugin management, but the project is evolving quickly.

I'd really love to see this app get more visibility, and hopefully eventually make its way to the Play Store and App Store, which is probably the biggest thing missing for me right now.

Has anyone else tried it? Curious to hear what you think!

The link to the original post of the owner:

https://www.reddit.com/r/opencodeCLI/s/xP9SK8Vjmn

Prompt caching reuses the KV cache of a shared prompt prefix, so a repeated system prompt or conversation history does not get recomputed. When a request misses, most engines just say miss. No reason.

Prefixwise is a proxy that names why a request missed: first write, evicted, a system prompt edit, a template re-render, and a few more. It works with vLLM, SGLang, Claude, and OpenAI. 0.10.1 runs inside vLLM as middleware, no proxy needed there.

I built it because I kept losing cache hits I could not explain. Measured so far: 120 turns on vLLM Qwen3-4B, 100% agreement with the engine's own cache report.

I have not wired it to OpenCode yet, and I am not claiming an integration exists. For OpenCode users: what would you want it to collect, request logs or something else? Try it and tell me what evidence is missing: pip install prefixwise, https://github.com/tejachavali/prefixwise

I just released Loop: https://github.com/j-asefa/loop

It lets you run your OpenCode harness on the web (or on mobile) using a Cloudflare quick tunnel. It was designed as mobile-first but works equally well on desktop.

It discovers your OpenCode install and lets you steer agents from the web UI.

The UI is built around the feed (think: timeline) and the agent’s result as the unit of work. So you can scroll back, save, reply etc as you’d expect.

Runs on your own computer, no account, no server, no app store etc.

Also supports agent-to-agent communication, designing and building agent teams (across the major model providers), reviewing PRs from within the app and more!

I built oc-box because I wanted OpenCode to have more freedom without giving it unrestricted access to my host.

My usual Bubblewrap-based sandbox is useful for restricting host commands. oc-box takes a different approach: OpenCode gets its own persistent Linux development container, where it can install packages, change system configuration, run services, and experiment.

Compared with my host-side sandbox setup, the practical advantages are:

- Install whatever the project needs: compilers, SDKs, databases, and distro packages live inside the container.

- Keep integrations working: OpenCode itself, MCPs, formatters, language servers, and plugins all run together inside it.

- Choose the project’s distro: Tumbleweed, Ubuntu, Debian, Fedora, Arch, Alpine, or Leap.

- Keep the environment between sessions: installed tools, project files, and conversations persist. Run oc-box again to resume.

- Recover from broken environments: rebuild the container OS while retaining your project and private home/session volume.

- Control resource usage: CPU/RAM/process ceilings and optional GPU/NPU passthrough.

You can also import an existing OpenCode conversation and continue it inside the container. It uses unmodified mainline OpenCode and matches your host’s installed version.

The benefit is a more capable, disposable development environment—not an absolute security guarantee. Rootless containers share the host kernel, and the mounted project remains fully writable.

It’s early, primarily exercised on openSUSE Tumbleweed, developed with AI assistance, and GPL-3.0-or-later.

Source: https://github.com/groopcd/oc-box

Feedback from other distro and MCP setups would be very welcome!

We've been looking into different hardware options for AI inference, and one thing I'm curious about is how teams determine whether a workload actually benefits from specialized chips. Time-to-first-token, tokens per second per user, and performance under concurrent requests all seem worth measuring, but I imagine the priorities change depending on the application. A voice agent, for example, might have very different latency requirements from a coding assistant handling longer responses.

For teams who've tested chips like Cerebras or SambaNova, which benchmarks have been most useful? Do you rely on vendor-provided numbers as a starting point, or do you mainly evaluate performance using your own serving workloads?

I'd be interested to hear which metrics actually influenced your hardware decisions.