See it in action
Real PRs. Real content. Real results. Watch how merged pull requests transform into engaging social content.
feat: add OPENCODE_DISABLE_FILETIME_CHECK flag
We shipped a tiny switch that removes a surprisingly annoying workflow blocker. Set OPENCODE_DISABLE_FILETIME_CHECK to skip the pre-edit timestamp check (some folks hit it with ~0.2s gaps). Result: no more forced re-reads when you already have context.
We shipped a tiny switch in OpenCode that removes a surprisingly annoying workflow blocker: you can opt out of the pre-edit check that was forcing unnecessary re-reads.
Some of our users told us they’d get blocked from editing even when the file content was already in context. The tool would insist on re-reading the file first, and it broke momentum fast.
The worst part: even a split-second timing mismatch could trigger it. We saw reports where 0.2s between read and edit was enough to throw the error.
+2 more tweets
The tiny switch that removes a surprisingly annoying workflow blocker. In OpenCode, we’ve had a safety check before edits: if the file timestamp didn’t match what OpenCode last saw, we’d stop and require a re-read. In theory, that protects you from making changes against stale context. In practice, it was getting in the way of real work. We heard from users who were already holding the right context, but still got blocked from editing — sometimes because of tiny timing differences. One report: even 0.2s between read and edit could still trigger the error. So we shipped an escape hatch. If you’re a power user and you know what you’re doing, you can now set `OPENCODE_DISABLE_FILETIME_CHECK` to bypass that pre-edit verification. That means quick edits can proceed without being forced to re-read the file first, when you already have the content. This is one of those “convenience vs safety” tradeoffs we try to make explicit. Defaults should keep you safe. But developers also need control when the tool’s guardrails become friction. Key takeaway: you can now opt out of the pre-edit check that was forcing unnecessary re-reads, making quick edits smoother when you already have the context.
fix: don't update session timestamp for metadata-only changes (resolves #9494)
Renaming a session no longer makes it jump to the top of your session list. We shipped a small bugfix so “info-only” changes (rename, archive, share) don’t bump activity. Result: your session list stays predictable and reflects what you actually worked on.
We shipped a small bugfix that stopped renamed sessions from “cutting the line” in your list.
If you manage a lot of sessions, list order matters. Before, a rename (or other info-only edit) could make a session look newly active and jump to the top, even though nothing meaningful changed.
Now, changing a session title or other metadata won’t bump it up the list. Your session list reflects actual activity, not housekeeping.
+1 more tweets
The small change that stopped renamed sessions from “cutting the line.” In OpenCode, a lot of us keep many sessions around. The session list becomes a map of what we were actually working on most recently. We noticed a confusing behavior: when we renamed a session (or made other info-only updates like archive/unarchive, share/unshare, or an auto-generated title), the session could jump to the top of the list. Nothing “active” happened, but it suddenly looked newly touched. That’s noisy. And when you’re switching between real work streams, that noise costs time. So we shipped a small bugfix: renaming a session no longer makes it jump to the top of your session list. Under the hood, we made it possible for metadata-only edits to avoid updating the session timestamp. The point isn’t the implementation though—it’s the contract: the list should reflect actual activity, not housekeeping. It’s one of those UX details that feels minor until it disrupts your flow. Our goal with OpenCode is to keep the interface predictable and trustworthy, especially when you’re managing lots of context. Renaming a session no longer makes it jump to the top of your session list.
fix: correct dot prefix display in directory names for RTL text rendering issue #9579
File paths in the Session changes panel now display correctly. Tiny punctuation bug: a dot-prefixed folder like .opencode/ made filenames look suspicious. We fixed the display so the dot stays with the folder name, making change reviews clearer and more trustworthy.
Tiny punctuation bug, big trust hit: some file paths in OpenCode’s Session changes panel looked wrong. Dot-prefixed folders (like `.opencode/`) made filenames look suspicious.
When you’re reviewing changes, the path is part of the signal. Before: the dot from a dot-prefixed folder could read like it belonged to the filename. It made the path confusing and easy to second-guess.
We shipped a bugfix to how paths are displayed in the Session Review panel and the Session Turn display. Now the dot stays with the folder name where it belongs.
+1 more tweets
The tiny punctuation bug that made file paths look wrong. In OpenCode’s Session changes panel, we noticed something subtle but annoying during review: paths that included dot-prefixed folders (like “.opencode/”) could *look* like the dot belonged to the filename. Nothing about the underlying change was wrong—but the display made it easy to second-guess what you were actually reviewing. Was that a hidden file? Did the filename change? Or is it just a folder name with a dot? This matters most when you’re scanning a Session review quickly and relying on the UI to be trustworthy. If the path display is even slightly misleading, the whole review flow feels less reliable. We shipped a bugfix in both the Session Review panel and the Session Turn display so dot-prefixed folders render correctly, keeping the dot with the folder name where it belongs. Small detail. But it’s the kind of detail that makes change reviews clearer—and reduces that tiny “wait, what changed?” pause. File paths in the Session changes panel now display correctly, so dot-prefixed folders no longer make filenames look wrong.
feat(model): adding ollama local
Want to keep it local? We just shipped Ollama as a model provider option in ValueCell. Pick a model that runs on your own machine and keep things in your control. ValueCell now supports a local Ollama provider.
Want to keep it local? We just added Ollama as a model provider option in ValueCell.
Before this, if you wanted to run ValueCell with a model on your own machine, you couldn’t pick a local Ollama option. You had to choose a different provider instead.
Now, there’s a local Ollama option you can select as your model provider. Simple choice, big difference in how you can run things.
+2 more tweets
Want to keep it local? — we added a new option for running with a model on your own machine. We’ve been working on ValueCell and one thing kept coming up: not everyone wants (or can) rely on an online provider for model access. Some people prefer keeping usage on their own machine. So we shipped a new model provider option: Ollama. What that changes: Before, using the app meant choosing a different provider. Now, you can select a local Ollama option as the model provider. The real win here isn’t a flashy feature. It’s flexibility. We want ValueCell to fit into different setups and comfort levels—whether that’s “keep it local,” “keep it simple,” or “keep it under our control.” This also nudged us to tighten up the little details around adding a new provider (config updates, icons, formatting). Not glamorous, but it’s the kind of polish that makes the experience feel coherent. Bottom line: you can now use a local Ollama option as your model provider, giving you more flexibility in how you run ValueCell.
feat(i18n): enhance i18n coverage
More of the app now reads naturally in supported languages. We chased down those “why is this still in English?” moments and added missing translations across ValueCell. Result: clearer screens, smoother navigation, and a more consistent experience.
That tiny language update that makes the whole app feel more polished: we just shipped more consistent translations in ValueCell. More of the app now reads naturally in supported languages.
We kept running into those “why is this still in English?” moments. Even when most of a screen is translated, one missing or odd phrase can make the whole thing feel shaky.
So we added additional translation coverage across the product. The goal was simple: make the wording consistent, so the app feels complete in supported non-English languages.
+2 more tweets
Turning “why is this still in English?” moments into a smoother experience. This week in ValueCell, we shipped a small update that makes the whole product feel more finished for people using it in supported non‑English languages. The change is simple: more of the app’s text is translated consistently. Before, some screens had missing or inconsistent wording. That kind of thing doesn’t always block you, but it does create tiny moments of doubt—where you pause, re-read, or wonder if you’re in the right place. After this update, more of ValueCell reads naturally across the supported languages. The experience feels clearer and more predictable, with fewer “wait, what does this mean?” speed bumps. It’s a good reminder for us: internationalization isn’t just a checkbox. The small gaps are the ones people notice most, because they show up right when someone is trying to move fast. We’ll keep working through these polish passes as we build in public. More of the app now reads naturally in supported languages, making the experience clearer and more consistent.
Ready to transform your PRs?
Connect your GitHub and start generating content from your merged PRs.
Connect GitHubFree while in beta. No credit card.