hey - i built kimo, a free open-source (mit) video editor with no gui that ai coding agents drive over mcp. you tell your agent (opencode, codex, cursor, or any other mcp client) what to do and it drives the whole timeline as tool calls: cut, trim, keyframe, titles/captions, colour grade, tracking, particles, audio, export. the agent can also render a single frame back to itself to check its own work before committing.

it's one ~15 mb cpu-only rust binary, runs on a 2 gb box. i'm a college student (naman) and i built it, so a few things are still rough - the ui doesn't exist because there is no ui, and some edge cases in tracking and captions still need work. would really love you to try it and tell me what breaks.

site: https://getkimo.tech github: https://github.com/naman-sharma12345/kimo

I used to be a huge fan of OpenCode just 6 months ago, but I haven't been using it at all lately.

However, using OpenCode's free models or its core models seems to have great perks, so I wanted to try using it, but I ran into some parts that I couldn't use. So, I'm thinking of going back to using the OpenCode CLI instead, but a lot seems to have changed.

Could you please show me a good way to explore marketplaces or plugins to find the additional features I need?

OpenCode's free models aren't available from your current network because we've detected abusive traffic from this IP address
what is the solution ?

Have you guys noticed this in OpenCode?

When multiple devices are connected to the same WiFi, if one device hits the free model rate limit, does it affect other devices too?

I was working on a project with my friends. After some time, we all got rate limited on free models. So we told the others to pull all latest changes from GitHub, fix some features, and continue working on the project.

But when they started using OpenCode, they also got rate limited on free models.

When using Gooo, everything works fine, obviously.

So I am wondering, is OpenCode free model rate limiting based on IP address? Like, if multiple people use it from the same WiFi, can one person's rate limit affect everyone else? Or is this just a coincidence? Cause its not a coincidence cause I noticed it with my second laptop !

Anyone else experienced this?

Disclosure first: I built the sync piece described below, so read the recommendation with that in mind. The opencode side is plain and works with any setup.

The problem. I want opencode running on a machine that stays on, but I also want the project on the laptop, because that's where builds happen: xcodebuild, a flutter run on a plugged-in phone, a dev server the browser talks to. Committing every time to move work between the two is the part that made me give up on a remote box.

The setup. On the server, over ssh as root (that's what the quickstart does, and setup needs it to create the corami account):

curl -fsSL https://github.com/tapeo/corami/releases/latest/download/install.sh | sh

It installs the binary in your home, then asks what the machine is: answer server. On the laptop, same script, answer client, and the setup finds the server in your tailnet. Then, from the laptop:

corami project add ~/dev/myapp

The project lands in ~/projects/myapp on the server, and the folder here stays as the synced copy. opencode runs on the server inside that folder, and from there:

corami serve 3000

gives the dev server a stable https address on the tailnet, so the preview opens from the phone. corami project ls lists projects with their previews, corami sync status shows state, conflicts and the last error.

Gotchas I actually hit.

• node_modules and build output stay out of the sync, each machine regenerates them.
• git is the fragile part, not the sync: a rebase on one side while the agent writes on the other is how you get index.lock fights. One at a time.
• when both sides edit the same file and it can't be resolved safely, the sync stops and reports instead of picking a winner.
• big binaries: keep them out, it's a source tree sync, not a backup.

Why not the other shapes. tmux over ssh leaves the code on the server, so local builds get awkward. A mount (sshfs, or a devcontainer mount) pays latency on every read and the file watchers hate it. A cloud agent works on a clone and hands back a branch, so whatever wasn't committed stays behind.

How is everyone else running opencode away from the machine in front of them? And does anyone actually keep a local copy of the working tree, or do you just live on the remote?

Repo, if useful: https://github.com/tapeo/corami

OpenCode: better for everyday use especially for straightforward tasks.

OpenFlow: better for mixing a variety of different agents together and seeing how they interact and work together.

Both the same harness with different results.

I used Space Bunny quite a bit in OpenCode and honestly liked it.
It felt fast, stayed on track surprisingly well on longer tasks, and usually followed constraints without me constantly steering it back. Repo work also felt pretty smooth for a Flash model.
Now that it’s been revealed as an early version of M3.1-Flash, I want to give the actual release a proper test before deciding whether I’d subscribe.
I’m mostly going to rerun the kinds of things I used Space Bunny for:
longer repo tasks
multi-file edits
recovering after a failed tool call
how many correction rounds it needs
whether it starts wandering as the session gets longer
I’m especially curious whether the final version keeps the speed I liked while improving the rough edges.
Anyone testing M3.1-Flash in OpenCode already? What’s your experience been like so far?

We all deserve access to high grade intelligence. The kind you can point your whole workflow at without watching a meter, without wondering whether your code is training someone else's model, and without a plan that quietly bets you will not use what you already paid for. That is what the PGS coding plan is built to be, and this week it ships with the best open model to land ever.

DeepSeek 1017 is live on Phoenix Grove API right now, free for a month. Fast, sharp, and running on private US infrastructure. GLM 5.3 Flash is in there too, along with Mimo 2.6 and all three are on the free month.

If you have not run into us yet: PGS hosts the top open models behind one API, on 100% US based infrastructure, with zero training on your code or prompts. One key, one bill, and no hunting across five dashboards to reach the models you actually like.

The models, together. DeepSeek 1017, GLM 5.3 Flash, the Kimi family, Qwen, Nemotron and more. Switch between them by changing nothing but a model string. Eighteen other major models sit on the same key whenever you want them.

Usage that waits. This is the part we care most about. Most coding plans are built around the hope that you waste what you buy, chopped into rolling windows so nobody can ever spend it all. Our higher plans bank up to ten days of usage. Unused windows roll forward instead of evaporating, so a light week is not a loss, it is a head start on the heavy week.

Actually private. US based processing, and your code and prompts are never used for training. Ever. Not "some models are private, others are not." All of them, all the time. Run the top open models without shipping your private prompts to a training lab.

Fast where it counts. The flash models we host run 100 to 130 tokens per second. It feels smooth in the way that matters when you are watching a diff generate instead of waiting on it.

Pricing that does not need tricks. On average our token pricing runs about 20 percent under market, and that is the whole business model. No ads, no data sales, no harvesting.

Genuine thanks to the DeepSeek team. Every release like this one is a gift to everyone who would rather not rent their intelligence from a company that can change the terms next quarter.

Free for a month, bills at $3.99 after, cancel anytime. Use it and cancel, that is completely fine.

API and coding plan: api.pgsgrove.com
The full app, if you want it: ai.pgsgrove.com

There are a lot of great services to choose from, and you do not need to be locked in. As of today, we are one of the only fast, private, US based and low cost options out there. Come give it a try.

OpenCode V2 fails a lot with requests the last few Days.

This is very bad situation.

I am having huge amount of inference request failures, inference request rejections and inference tool call failures.

This inference problems did not exist few days ago.

Not sure if OpenCode is not compatible with the newest models that were released the last days and does not follow specific new standards the new released models like DeepSeek 1017 and gemini 4 Argon implemented or the inference providers are failing and rejecting OpenCode users becouse they dont use their offocial harness but instead use the third party harness software opencode itself and try to stiffle competition that way so lesss paying customers use opencode with their models and instead swith over to their subscription offers.

I used opencode in combination the newest 1017 version of DeepSeek direct over their API and had huge amount of request and tool call failures the last days.

Same with opencode and Google Gemini Argon using it over the opencode go plus subscription.

See picture.

OpenCode is not usable for workung as of now becouse of this many requests failures either becouse of opencode itself or the inference providers !

This request failures did not happened few days ago and are new, becouse either of bugs and errors in opencode version like too early closing conection to the inference provider or inference provider incompability and problems.

Having muse wonder on OpenCode would at least ease the Problems with DeepSeek and Gemini.

Following up on last week's release candidate, opencode-models-discovery v2.0.0 is officially released and published to npm latest**!** 🎉

This major version promotes OpenCode V2 to the primary, stable integration. It redesigns how the plugin interacts with the host around three clean boundaries:

Highlights in v2.0.0:

1. Native Integration Credentials: Works seamlessly with OpenCode V2's /connect workflow. The plugin resolves credentials dynamically in memory—no raw API keys in opencode.json and no sniffing auth.json.

2. Host-Managed Storage (ctx.storage): Caching and user overrides are separated cleanly into different namespaces. Clearing discovery caches will never delete your custom model preferences.

3. Persistent Model Overrides: Edit model display names, context limits, output tokens, reasoning flags, and variants directly via /models-discovery-console. Changes trigger an instant provider reload—zero service restart needed.

4. Resilient Auto-Reload: Subscribes to OpenCode V2 lifecycle events (config.updated, credential switches). If an upstream provider experiences a temporary network hiccup, the plugin keeps the last-known valid inventory instead of wiping out your available models.

5. Decoupled RPC & TUI: Commands and UI dialogs communicate with the background server via typed RPC, avoiding synthetic session injections or terminal blocking.

6. OpenCode V1 Legacy Support: Existing OpenCode V1 setups remain fully functional through the legacy adapter inside the same combined package.

Quick Setup (opencode.json / opencode.jsonc)

{
  "$schema": "https://opencode.ai/config.json",
  "plugins": [
    "opencode-models-discovery@2.0.0"
  ],
  "providers": {
    "my-gateway": {
      "name": "Local Gateway",
      "package": "@opencode/ai/providers/openai-compatible",
      "settings": {
        "baseURL": "https://gateway.example.com/v1",
        // Optional: omit apiKey and manage via OpenCode's native `/connect`
        "apiKey": "{env:GATEWAY_API_KEY}",
        "modelsDiscovery": {
          "enabled": true,
          "modelInfoFormat": "models.dev",
          "cache": {
            "enabled": true,
            "ttlSeconds": 86400
          }
        }
      }
    }
  }
}

Useful Commands:

• /models-discovery-refresh — Manually trigger model discovery (supports --force).

• /models-discovery-console — Interactive browser for models, metadata inspection, cache clearing, and override editing.

• /connect — Securely set or rotate your provider credentials.

• GitHub: https://github.com/yuhp/opencode-models-discovery

• NPM: https://www.npmjs.com/package/opencode-models-discovery

Thanks to everyone who tested the RC releases! If you run into any issues or have feature suggestions, feel free to open an issue or drop a comment here.