Any rough ETA for 3.8.51?

[stormsia]

I'm waiting for 3.8.51 and was wondering if there's any rough idea when it might drop?

[saifkamaal]

I see the build keeps failing 🥺

[diegosouzapw]

Hi @stormsia. Honest answer: there is no date, and I would rather not invent one.

What gates it is the release-green check on release/v3.8.51, tracked in #13866. As of tonight it reports one hard failure, a docs-sync gap, plus a file-size ratchet that gets rebaselined at release anyway. That is the "build keeps failing" @saifkamaal is seeing — it is the continuous validation on the branch, not a broken build of the code itself.

If what you are waiting for is the OpenCode free-tier fix: that merged yesterday as #14013 into the release branch, so the omniroute:next Docker tag and an install from the branch already carry it. latest moves only when the tag is cut.

I will post here when the tag goes out.

[stormsia]

Thanks — but the fix doesn't seem to be in omniroute:next yet. I pulled next (sha256:80eade3c516c4b4e0b9ab07a72a96648155722fbf311cfb4bc058cc4d1e18b3a) and OpenCode still returns 403 on the free tier. Has next been rebuilt since #14013 merged, and is this the current digest?

[texastoland]

I documented my build in #14191 and there's already a patch queued in #14195 🍻

[stormsia]

@diegosouzapw Thanks — but the fix doesn't seem to be in omniroute:next yet. I pulled next (sha256:80eade3c516c4b4e0b9ab07a72a96648155722fbf311cfb4bc058cc4d1e18b3a) and OpenCode still returns 403 on the free tier. Has next been rebuilt since #14013 merged, and is this the current digest?

[xiaoyaner0201]

@stormsia — a data point on what actually gates this, since the thread has been quiet.

I measured the release-green pipeline on release/v3.8.51 today and posted the full analysis on #13866. Short version of where the blockers stand:

The code-level hard failures are nearly cleared. Of the 11 reported on the last full sweep, 6 are addressed by two open PRs (#14164 and #14255 — I traced and fixed the ESLint one, which turned out to be a single test file whose bulk-suppression cap was voided, not 87 separate defects; root cause in #14254). Composed together they take ESLint errors from 92 to 0, verified on a merged worktree.

The remaining four are not code problems. Unit tests, integration tests and npm-pack all exceeded their ceilings and were killed; tarball boot-smoke was skipped because pack produced no dist/. Nothing was actually tested.

The measurable cause is concurrency, not quality. Over the last 60 release-green runs, 87% of the per-push runs (48 of 55) were cancelled — 44 of them within 8 minutes, i.e. before the gate's own ~5-8 min runtime. Median gap between pushes to the branch is 0.1 minutes, and the workflow keys its concurrency group by event with cancel-in-progress: true. During a merge wave each push cancels the previous run, so the per-merge signal that should catch a base-red at its source cannot complete precisely when it matters most.

Every quality ratchet in the same sweep is green (ESLint warnings 0 vs baseline 1050, cognitive complexity 1316 vs 1437, dead-code / type-coverage / CodeQL all within baseline). The tree is not decaying — the validation cannot finish.

So on your original question: still no date, and I would not invent one either. But the honest shape of it is that the contributor-fixable portion is nearly done, and what remains is CI capacity and one workflow concurrency setting. I suggested three concrete changes on #13866; none need new infrastructure.

One practical note for anyone tracking this: the 2026-09-20 full sweep failed at 67 minutes with the runner receiving a shutdown signal. Because it ended as cancelled rather than a verdict, no comment was posted to #13866 — so that thread's last entry is from 09-19 and the branch looks quieter than it is. Reading the issue alone will give you a stale picture.

Re omniroute:next — your observation was right. The tag's last push is 2026-09-17 13:33 UTC, and #14013 (the OpenCode free-tier fix) merged 2026-09-18 15:57 UTC. The image predates the fix by a day, so pulling next does not currently get you it.

[diegosouzapw]

@stormsia you are right, and I owe you a correction: omniroute:next does not carry the OpenCode fix. I said it did without checking the image, only the branch.

What is actually going on, verified on the Actions history:

• The next tag on Docker Hub was last pushed 2026-09-17 13:33 UTC (digest sha256:80eade3c..., the one you pulled). fix(opencode): match the upstream free-tier request contract #14013 merged the next day, 15:57 UTC.
• Every Publish to Docker Hub run since then has died. The wave of 09-18 was cancelled run-by-run by the workflow's own cancel-in-progress, and the runs that did get to build all failed the same way: FATAL ERROR: Ineffective mark-compacts near heap limit - JavaScript heap out of memory inside npm run build, on both amd64 and arm64 (runs 35371642030, 35419272620, 35421210360, 35425194666).
• The Docker build runs webpack with a 6144 MB V8 ceiling (Dockerfile OMNIROUTE_BUILD_MEMORY_MB), while the CI build jobs use 12288 MB for the same command. Something in the 195 commits between the last green image and the first OOM pushed the build past 6 GB. I have opened fix(ci): Docker :next channel stuck at 2026-09-17 — every publish since OOMs npm run build at the 6144 MB heap ceiling #14325 to track it; the image will not move until that lands.

@xiaoyaner0201 thank you for the measurement on the tag timing, it is what made me go look.

Until the channel is unblocked, the fix is only reachable from source: git clone -b release/v3.8.51, then npm install && npm run build && npm run start, or docker build --build-arg OMNIROUTE_BUILD_MEMORY_MB=12288 . if you want an image. I will post here when next is rebuilt with the fix and again when v3.8.51 is tagged.

[diegosouzapw]

Update, as promised: omniroute:next now carries the OpenCode free-tier fix.

The tag was rebuilt today at 2026-09-22 20:31 UTC, digest sha256:87e1c516e013e2a1c0d568a128df7d2c10bee9ab5971aead9e9f98bf9415fdf5, from ea3c1226 — which has #14013 in its history. @stormsia, the digest you pulled (80eade3c, 09-17) is the stale one; re-pull and you should get the new one:

docker pull diegosouzapw/omniroute:next
docker image inspect diegosouzapw/omniroute:next --format '{{index .RepoDigests 0}}'

What unblocked it: the publish had been failing with a V8 heap OOM inside npm run build (the Docker build was capped at 6144 MB while the CI build jobs used 12288 MB for the same command). #14469 raised the Docker build-arg to 12288 MB and closed #14325; the first full run after that merged is the one that produced this image.

v3.8.51 itself is still untagged — that gate is unchanged and I will post here again when it ships.

[nitinprajwal]

I tried the :next Docker image as suggested, with a clean redeployment, but I’m still seeing the same error in Opencode provider.

The image digest I’m currently running is:

diegosouzapw/omniroute@sha256:ffe4a885c610b61768a4d9bff2f6581ece0d4ec66fda5524dc424a33ded1fbe8

The image was last updated on 2026-09-23 at 05:11:41 UTC.

Is there something I’m missing here, or is there any particular configuration required for this to work?

[diegosouzapw]

@nitinprajwal Thanks for the digest and the screenshots. Your image does contain the fix: ffe4a885 was published on 09-23, after #14013 went in. What you're seeing is the part of that fix that is learned at runtime, and your container hasn't learned it yet.

Since 09-17 the upstream only accepts a keyless OpenCode request when it declares a set of tools whose names match the official client's. Six or more matching names passed when we measured on 09-18; one made-up name, or twelve, did not. What it accepts also differs by model and has shifted from one day to the next, so #14013 doesn't hardcode a list. It remembers the tool names from requests that came in with tools and were accepted, and reuses them for requests that arrive with none (open-sse/executors/opencodeFreeTierContract.ts).

Two things follow for your setup:

• The dashboard test sends no tools. "Test" / "Test all models" build a plain chat request without a tools array. With nothing learned yet it goes out with a single placeholder tool, _noop, and most free models refuse that. So the 403 toast in your screenshot is expected on a fresh container. It doesn't mean real traffic is failing.
• The learned list lives in memory (opencodeToolObservation.ts), so every redeploy starts empty again.

Please check it with a real client: send a request to an oc/...-free model from OpenCode, Claude Code or any agent that declares its tools. If that works, the fix is doing its job and only the tool-less test is refused.

If you also want tool-less requests to work from a cold start (the dashboard test, or scripts that never send tools), set the names yourself. OPENCODE_FREE_TIER_PLACEHOLDER_TOOLS takes a comma-separated list, is read on every request, and is documented in .env.example. Add it to the container's environment, for example:

environment:
  - OPENCODE_FREE_TIER_PLACEHOLDER_TOOLS=bash,read,glob,grep,edit,write,webfetch,task

Those are OpenCode's own tool names. Given how often the upstream's rule has moved, treat that list as a starting point, not a guarantee.

If a real request with tools still gets the 403, post the model id and the app.log lines around it and I'll dig further.

[nitinprajwal]

Thanks for the explanation @diegosouzapw . Tested it with a real OpenCode request, and it’s working now. Looks like the fix is working as expected.

[saifkamaal]

It's been some time since the release is stuck, do we have any updates or ETA now ?

[diegosouzapw]

@nitinprajwal Good to hear, and thanks for testing it with a real client. That confirms the fix: tool-carrying requests learn the names, and only the tool-less dashboard test gets refused on a cold container.

@saifkamaal No date yet, and I'd rather not give you one I'd have to take back. Where it stands: the release process hasn't started. It begins with a release-freeze issue, and that'll be the first visible signal. Before it can start, the release/v3.8.51 branch has to pass the release-green check, and it currently has one open failure (#14547, a docs-sync gate). When the freeze opens I'll post here.

In the meantime, diegosouzapw/omniroute:next is rebuilt from that branch and carries everything merged so far, including the OpenCode free-tier fix above.

[diegosouzapw]

Update, as promised: the v3.8.51 release process has started. The freeze opened today (#15080), the release branch is closed to further merges, and development moved on to release/v3.8.52.

That is not a release date. What still has to happen after the freeze is the full CI pass on the release PR, the merge to main, and the publish. I can't give you an ETA for the tag, and I'll post here when it's out. In the meantime diegosouzapw/omniroute:next carries everything that's in the release.