Skip to content

desktop: V1-era sessions fail on free models after upgrading to V2 while new sessions work #60352

Open

Description

@OSCUK

Summary

OpenCode Desktop 2.2.2 (the current build, same version as the working CLI 2.2.2) rejects every free model with:

This version of OpenCode Desktop no longer supports free models.
Update to the latest version at https://opencode.ai/download to keep using them.

There is no newer version to update to, and the CLI at the same version still serves free models fine. So opening any pre-V2 session (all of which were created on free models) in Desktop fails immediately, which makes existing sessions look "incompatible" after upgrading to V2.

Environment

  • opencode version: 2.2.2 (CLI opencode --version → v2.2.2); Desktop OpenCode.exe FileVersion/ProductVersion 2.2.2.0, installed at C:\Users\<user>\AppData\Local\Programs\@opencode-aidesktop
  • OS: Windows_NT 10.0.19045 (win32 x64)
  • Terminal: Unavailable: ran headless through the OpenCode API
  • Shell: C:\WINDOWS\system32\cmd.exe
  • Install/channel: release (curl/installer CLI + Windows Desktop build)
  • Active plugins: None found in config

Reproduction

  1. Open OpenCode Desktop 2.2.2 and select any free model (e.g. beam-free, big-pickle, flint-40b-free).
  2. Open an existing session created before the V2 upgrade (example: ses_088d2eaabffetnUk3FhEqgBsbb, agent plan, model opencode/beam-free, 4,416+ messages, directory D:/laragon/www/master).
  3. Send a message.

Expected Behavior

Desktop 2.2.2 uses the same free-model endpoint and quota as the CLI 2.2.2, which works in the same account at the same time. Old sessions continue normally, or an accurate reason is given if free models are genuinely unavailable to Desktop.

Actual Behavior

Every turn fails before any output:

{
  "type": "provider.free-limit",
  "message": "Free usage limit reached. Connect a provider or subscribe to OpenCode Go to keep going, or switch models.",
  "status": 429,
  "response": { "body": "{\"type\":\"error\",\"error\":{\"type\":\"FreeUsageLimitError\",\"message\":\"Free usage limit reached. Free models work in OpenCode (https://opencode.ai); subscribe to OpenCode Go to keep going: https://opencode.ai/go\"}}" },
  "retryAfterMs": 16452000
}

and in the Desktop client:

AI_APICallError: This version of OpenCode Desktop no longer supports free models.
Update to the latest version at https://opencode.ai/download to keep using them.

Additional Context

The session store migrated correctly, so this is not old-session data corruption:

  • opencode.db (SQLite): 58 rows in session, 60 in session_v2; 0 sessions exist only in the legacy table.
  • Session version column values are V1-era (local, 1.18.18–1.19.3) plus two 2.2.1 rows.
  • All but 1 of the 60 session directories still exist on disk (the one missing is an unrelated workspace path).
  • opencode api get /api/session/<id>/message returns the full V1 session history without error.

Relevant log lines (~/.local/share/opencode/log/opencode.log):

level=ERROR message="Failed to drain Session" cause="AI.Error: Free usage limit reached ... subscribe to OpenCode Go"
level=ERROR message=process session.id=ses_088d2eaabffetnUk3FhEqgBsbb error="This version of OpenCode Desktop no longer supports free models."

The 429s repeat every few minutes for hours (15:31, 15:46, 16:59, 18:58, 19:00, 19:07, 19:14, 19:25) while a separate free-model session (ses_e76f54ba6ffelXXofXfpmFzK1r, big-pickle) runs normally in the same time window.

Related reports: #58687, #58536, #58569, #58550.

Reporter's observation from #58687

Posted by @OSCUK in the related free-limit report:

My 2 cents... Same issue like the others, but I figure out that if you create a new session, it works. So sessions made in Version 1.x.x some how all give this issue, but if you create a new session there is no issues at all, both Windows app and CLI. Hope it helps and can be confirmed by others

This matches what is reproducible here: a session created after the upgrade (ses_e76f54ba6ffelXXofXfpmFzK1r, big-pickle) runs normally, while sessions created under V1.x fail on the same account with the same free model.

Workarounds tried: none successful; the Desktop update prompt offers no newer build.

Activity

  1. opencodejr commented on Oct 29, 2026

    @opencodejr

    Thanks for the detailed write-up and the database and log checks. They're very helpful.

    I think this is a duplicate of #59387, the main thread for free-tier problems. It lists both errors you're seeing: This version of OpenCode Desktop no longer supports free models and Free usage limit reached.

    Possible duplicates and related issues, ordered from most to least likely:

    One thing worth checking: the v2 code doesn't contain the "This version of OpenCode Desktop no longer supports free models" text. That message comes from the hosted service, and so far it has only been seen with v1 Desktop. Your Desktop install path (...\Programs\@opencode-aidesktop) looks like a v1 Desktop install, and the v1 built-in updater never offers a v2 build. Could you check Settings → About in the Desktop app? If it shows 1.x, please download v2 Desktop manually from https://opencode.ai/v2/docs.

    If it still happens on v2 Desktop, please add your findings to #59387 (your version, the "old V1 sessions fail, new sessions work" observation, and the session IDs and log times). The free-tier limits are applied by the service, so a maintainer with account access needs to look at it there.

    The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different.

  2. OSCUK commented on Oct 29, 2026

    @OSCUK
    Author

    Quick follow-up on the version question, because the "looks like a v1 install" theory does not hold:

    • resources/app.asar -> package.json: @opencode/desktop 2.2.2
    • Windows uninstall entry: OpenCode 2.2.2 (DisplayVersion 2.2.2)
    • OpenCode.exe file version: 2.2.2.0
    • The string no longer supports free models does not appear anywhere in the 224 MB 2.2.2 app.asar (binary search, 0 occurrences)

    So this client cannot be generating that message. It arrives from the hosted service, which is consistent with your note that v2 code has no such text - but it means a current v2.2.2 Desktop is being rejected as outdated by the service, not that the install is v1.

    That is why I think this is not purely a duplicate of #59387: #59387 covers free-tier quota, while this adds a server-side client-version rejection that hits a current v2.2.2 install.

    Happy for it to be tracked in #59387 instead if one thread is preferred - but the "probably v1, upgrade" explanation is ruled out by the checks above. Reproduced on Windows 10 (19045), Desktop 2.2.2, same account where CLI 2.2.2 free models work.

  3. OSCUK commented on Oct 30, 2026

    @OSCUK
    Author

    Follow-up after testing 2.2.3, plus a result that narrows the cause.

    2.2.3 does not fix it. Same old session, same model, same prompt -> 429 FreeUsageLimitError. The v2.2.3 release notes contain no mention of the free limit, the 429, or the Desktop "no longer supports free models" string, so this was expected.

    It follows the session, not its age. I forked and re-imported the transcript through the public API and tried a free-model turn in each copy:

    Session Result
    Original V1-era session provider.free-limit
    POST /api/session/{id}/fork (full history) provider.free-limit
    POST /api/session/{id}/fork (trimmed to 5 messages) provider.free-limit
    POST /api/experimental/session/import (IDs remapped) provider.free-limit
    Same import with fresh time.created provider.free-limit
    POST /api/session brand-new session, same prompt works

    Two things worth noting:

    1. A 5-message fork is rejected while a brand-new session with one message succeeds, so the discriminator is not history size, session age, or ID format. It looks like eligibility is only established server-side when the client creates a session fresh.
    2. The importer does not remap message IDs. Importing a transcript from the same store fails with UNIQUE constraint failed: session_message.id until every msg_ ID is regenerated client-side. Might be intended, but it made export -> import from the same install a manual job.

    Net effect for the reporter's situation: there is no supported way to carry an existing conversation into a working free-tier session - fork and import both inherit the block. Full detail and payloads: #59387 (comment).

  4. opencodejr commented on Oct 30, 2026

    @opencodejr

    Closing this as a duplicate of #59387, the main thread for free-tier problems. We waited a day for a reply explaining how this is different and didn't hear back.

    The This version of OpenCode Desktop no longer supports free models message comes from the hosted service. So far it has only been seen with v1 Desktop, and your install path (...\Programs\@opencode-aidesktop) looks like a v1 Desktop install. Please check Settings → About. If it shows 1.x, download v2 Desktop manually from https://opencode.ai/v2/docs, because the v1 updater won't offer it.

    If it still happens on v2, please add your findings to #59387: the version, the observation that V1-era sessions fail while new sessions work, and the session IDs and log times. A maintainer with account access needs to look at it there. Thanks for the thorough investigation!

  5. OSCUK commented on Nov 4, 2026

    @OSCUK
    Author

    Confirming this is not version-related and not database-related.

    Tested on 2.2.5 (desktop) and 2.2.2 (CLI) against a clean 58-migration database with a single project row: a newly created session answers normally, while the same session exported and re-imported immediately fails with provider.free-limit. Server log shows AI.Error.QuotaExceeded raised when draining the session, so the refusal is upstream and keyed to session provenance, not to local state or the client version.

    Reproducible without any V1 history: create session -> send ok (succeeds) -> export -> import -> send ok (fails).

    Same behaviour with a pre-V2 session migrated by the 2.2.1 upgrade: it is refused in the original store and still refused after import into the clean database, while brand-new sessions work. Importing with a caller-supplied session ID, forking, and POST /api/experimental/session/import all produce the same result, which is why the client version makes no difference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions