v0.5.0 — follows the composition's startup dependency to webStartup

v0.5.0 — follows the composition's startup dependency to webStartup

• Fixes the usage channel on every 0.2.1 harness release, including
  0.2.1-rc.3. The bundle patch repaired the composition's connection row
  by restating its inject as [webRuntime, webServer]. 0.2.1-rc.1 moved that
  row's startup dependency to the webStartup service (the 0.2.0 line injects
  webRuntime) — and 0.4.2 already listed 0.2.1-rc.1/rc.2 as compatible
  while still restating the old name, its predecessors admitting the 0.2.1
  line through an unbounded engines.dsh — so on 0.2.1-rc.1, rc.2, and
  rc.3 a required row waited for a service no composition provides and the
  whole boot failed with 1 required plugin did not activate. The patch now
  restates [webStartup, webServer]. Deployments have been working around this
  with a profile-level - id: connection patch, which is now redundant and can
  be deleted.
• engines.dsh becomes >=0.2.1-rc.1 and the @deepseek-ai/dsh-* peer floors
  move with it. The 0.2.0 line is out: it names the startup service
  webRuntime, and a static patch cannot restate both spellings — the row would
  have to inject a name that release does not provide. dsh.compatibility
  records the verdict per release, so an installer reads the same answer instead
  of discovering it at boot.
• The patch is now pinned by a test, not by memory.
  tests/composition.test.ts reads the installed @deepseek-ai/dsh-web-app
  composition (@deepseek-ai/dsh-web-app is a development dependency for
  exactly that reason) and fails when the row it patches injects something this
  bundle does not restate, when the two lists stop matching the constant the
  mount diagnostic names, when webRuntime reappears, or when
  dsh.compatibility.dshReleases disagrees with engines.dsh. The same file
  asserts the composition and the pi-ai adapter come from one harness release.
  A rename upstream now breaks pnpm test instead of a user's boot.
• The mount-time diagnostic for a refused channel names the whole requirement —
  the connection row must inject webStartup + webServer — instead of only
  webServer, so a log line after a harness upgrade says what to re-check.
• Development dependencies move to 0.2.1-rc.3, so typecheck and tests run
  against the contract this build is installed into. The lockfile also resolves
  @earendil-works/pi-ai 1.4.0 (a minor inside the ^1.1.0 range the
  0.2.1-rc.3 harness declares); tests/generation.test.ts pins the wire
  contract for both context shapes through that copy, so the transcript
  boundary is verified rather than assumed.
• Migration: one step, and only for a deployment that carries the workaround.
  Delete the profile-level - id: connection patch that added webStartup —
  this bundle now does it — and restart. Nothing else moves: the provider id,
  settings namespace, credential reference, model catalog, and both UI seats are
  unchanged. Design rationale and the rejected alternatives (leaving the
  workaround to users; injecting webServer on this plugin's own row; moving
  the usage channel off the connection service):
  ADR 0008.

Install: dsh plugin --profile web add github:Asheblog/dsh-ollama-cloud

Tarball: dsh-ollama-cloud.tgz (prebuilt) or dsh-ollama-cloud-0.5.0.tgz (pinned)

v0.4.1 — a transient read failure no longer sticks

A transient failure no longer leaves the panel reading "unavailable". The panel's read travels through whatever sits in front of the endpoint, and in this deployment that is a local proxy that intermittently answers a single 502 Bad Gateway (observed live: 502, then 200 on a reconnected tunnel) or resets the connection. One such moment became 「读取用量失败。」/「额度不可用」, and the row kept that answer until its next poll — fifteen minutes — or a manual refresh. Two incidents had the panel failing at boot while a read a minute later answered with real numbers; boot is also when the catalog refresh fires roughly nineteen requests at the same endpoint through the same proxy.

readUsage now retries once when the first attempt failed transiently: a transport failure before any response, a 429, or any 5xx from the endpoint or from anything in front of it. UsageError.retryable carries that judgement, so the policy is visible on the error and testable, and a single attempt never retries on its own. Everything else is reported at once — a refused credential or a body this build cannot decode fails identically on a second attempt, so retrying it would only delay the diagnostic.

An attempt that ran out its timeout is still not retried: it already spent the whole budget, and a doubled wait would tell the user nothing new.

The sidebar's interval becomes 60 seconds while the last read failed and returns to 15 minutes as soon as a read lands, so a blip that outlives the retry heals by itself. Sixty seconds is also the rate the endpoint's own documentation recommends, so a failed row cannot turn the panel into a rate-limit problem for itself.

A failure now carries its diagnosis as a hover title — OLLAMA_USAGE_FAILED: https://ollama.com/api/balance answered 502 — on the failure line and on the empty panel, so a screenshot of a failure says which layer broke. The visible copy stays localized and actionable; the title names a URL and a status, never a secret.

Prebuilt tarball attached under both names: dsh-ollama-cloud-0.4.1.tgz, and the unversioned dsh-ollama-cloud.tgz that the market's registry entry and the README's install command use.

Design rationale and the rejected alternatives (retrying timeouts; retrying everything): docs/adr/0007-transient-failures-retry-and-recover.md.

v0.4.0 — the quota panel reads /api/balance

The quota panel reads the account allowance from GET <base>/balance. The endpoint it was built on (/usage) had stopped answering the limits object it decoded — it now returns the request/token/cost time series Ollama documents — so every read was rejected as malformed and both surfaces showed their failure states ("云端用量 / 读取用量失败。", "额度不可用"). The endpoint that does report an allowance is /balance: per window, how much is left (remaining_percent) and when it resets (resets_at). The panel now reads that, converts the remaining share into the consumed fraction its meters draw, and shows whichever windows the plan actually has (session / weekly / monthly) — membership is the endpoint's answer, so a monthly window needs no plugin change.

The per-model "usage sources" section, and the models field on the channel's wire window, are deleted. The retired shape carried per-window model counts; the current contract has none (Ollama lists breakdowns by model and API key as "coming soon"), so the section could never render again. Nothing user-visible is lost, and a field no endpoint sends is the exact phantom-contract class this release removes.

A remaining reading just outside 0–100 is clamped instead of dropping the window (100.4 is a percentage's rounding artefact, not a missing window), and a window the endpoint reports without a reset instant keeps its entry — its label then falls back to the documented cadence (session 5h, weekly 7d, monthly 30d).

New: scripts/check-live-allowance.mjs (pnpm run check:live) drives the real endpoint through the host decode, the wire projection, and the browser half's own decoder, and prints each window's remaining share. Every unit test in this repository pins a mock, and a mock is written from the same assumption as the code it feeds — which is how this drift went unnoticed while the suite stayed green. It needs the key and the network, so it stays out of pnpm check.

The wire window is now { usage, resetsAt? }, which is why this is a minor release rather than a patch.

Prebuilt tarball attached under both names: dsh-ollama-cloud-0.4.0.tgz, and the unversioned dsh-ollama-cloud.tgz that the market's registry entry and the README's install command use.

Design rationale, the live evidence, and the rejected alternatives (reading /api/usage too, or as a fallback; surfacing purchased.balance_usd here): docs/adr/0006-allowance-from-balance.md. It supersedes the endpoint assumption in ADR 0003, whose placement and channel decisions stand.

v0.3.0 — self-updating catalog

The catalog now updates itself. At mount — and then on a configurable interval (default: daily) — the plugin asks the configured endpoint what it serves (GET /api/tags + POST /api/show) and adopts the answer for the running session, so a model Ollama adds, retires, or re-levels no longer waits for a plugin release. Adopting a catalog moves the revision the connection reader memoizes on, so the new model list and every model's thinking levels reach the route — and any surface that lists this provider's models — without a restart.

A disk cache (<harness home>/cache/dsh-ollama-cloud/catalog.json, written atomically and validated on read) makes the first model list of any boot — and an offline boot — the endpoint's last answer instead of the shipped snapshot. The snapshot is demoted to two jobs: display names for ids it already knew, and the fallback before any fetch has succeeded.

/api/show outcomes are now answered separately: a described model gets its metadata; a model the endpoint answers 404/410 for is retired from the catalog even while its own listing still names it; a model whose detail request merely failed stays listed with what the listing said, because one slow request must not hide a real model for a whole interval. An empty listing is refused outright — a model picker with nothing in it cannot be recovered from.

New configuration: autoRefresh (default true) and refreshMinutes (default 1440; 0 refreshes at mount only), both re-read at every tick. While the refresh is off the scheduler still ticks on an idle cadence without touching the network, so switching it back on needs no reload.

Prebuilt tarball attached under both names: dsh-ollama-cloud-0.3.0.tgz, and the unversioned dsh-ollama-cloud.tgz that the README's install command uses.

Design rationale, including the rejected alternatives: docs/adr/0005-live-endpoint-catalog.md.

v0.2.3

Keeps the plugin's stylesheet across a hot reload. The client module system claims every untagged <style> in the document for whichever factory materializes next and deletes a plugin's claimed tags when that plugin is replaced, so this plugin's untagged sheet could be removed by an unrelated plugin's rebuild — leaving the new markup rendered with no styling at all. The element now carries data-plugin="dsh-ollama-cloud" (the official preset's convention), and a head observer re-appends it if anything removes it anyway.

Prebuilt tarball attached.

v0.2.2

Redraws the sidebar quota row as a progress bar: label and percentage on one line, the bar under it. The bar fills with the remaining share and takes the severity hue from it (ok / warn / critical), so it agrees with the "remaining" label instead of pointing the other way. The reset line moves into the button's hover title, and the collapsed 56px rail keeps only the mini bar and its number.

Prebuilt tarball attached, so this release installs without a source build.

v0.2.1 — pi-ai generation alignment (fixes DSH 0.2.0-rc.2)

Fixes every chat request failing instantly on DSH 0.2.0-rc.2.

0.2.0-rc.2 moved the harness to pi-ai 0.87, whose context carries the system prompt and the tool declarations inside the transcript; the 0.2.0 build of this plugin declared pi-ai ^0.85.1, so request construction died before any network I/O with Cannot read properties of undefined (reading 'length') (code PI_AI_ERROR). The mirror case — a 0.87 build on a pre-0.87 harness — silently dropped the system prompt and every tool declaration; both are fixed.

Install

dsh plugin --profile <profile> add https://github.com/Asheblog/dsh-ollama-cloud/releases/latest/download/dsh-ollama-cloud.tgz

Or github:Asheblog/dsh-ollama-cloud — the repository tracks lib/, so a source install needs no build authorization.

What changed

• @earendil-works/pi-ai is declared at ^0.87.1 — the generation dsh-llm-pi-ai@0.2.0-rc.2 declares — and the development dependencies moved to 0.2.0-rc.2.
• The route normalizes the request context at its own boundary (idempotently), so one release serves both context contracts and 0.2.0-rc.1-era harnesses keep working.
• pnpm check and a scheduled pi-ai-drift workflow fail when this package's pi-ai range and the harness's admit no common version; the plugin also logs a best-effort mount-time warning naming the drift.
• Regression tests pin both context shapes at the wire level; ADR 0004 records the decision and amends ADR 0001.

Verification

157 tests, typecheck, artifact check (67 entries), and a real chat request against Ollama Cloud through the desktop host's proxy environment and its stored credential.

Requires DSH 0.2.0-rc.1 or newer (peers >=0.2.0-rc.1).

Assets

• dsh-ollama-cloud.tgz — prebuilt plugin (asset name is version-free on purpose, so releases/latest/download/... never rots)
• dsh-ollama-cloud.tgz.sha256 — checksum

v0.2.0 — account usage in the UI

Ollama Cloud usage is now visible where you work, and the plugin no longer needs any provider-UI shell:

• A usage card inside the Models page row (settings.models.provider-card): one meter per billing window with its remaining share and reset line, the primary window's per-model request counts, a write-only API key field, and a refresh button.
• A sidebar quota row (sidebar.footer.action) showing the remaining share, expanding into per-window detail; refreshed on mount and every 15 minutes.

Usage is read on the host over the plugin's own connection channel (/ollama-cloud), so the API key never reaches the browser. A local or self-hosted endpoint's 404 renders as "does not report cloud usage" and the last good snapshot keeps showing.

Install (unchanged URL — latest follows this release):

dsh plugin --profile web add --force \
  https://github.com/Asheblog/dsh-ollama-cloud/releases/latest/download/dsh-ollama-cloud.tgz

The bundle patch now also repairs the composition's connection row (inject: [webRuntime, webServer]), which is what lets the usage channel mount on the desktop composition — restart the app once after installing so the host reloads the plugin. Verified against the live service for chat, thinking levels, web search/fetch, and usage reading.

v0.1.0

Ollama Cloud provider for DeepSeek Harness: install it and the provider is configured, with per-model thinking strength you can adjust.

• Registers the ollama-cloud route; chat is delegated to the official @deepseek-ai/dsh-llm-pi-ai adapter on Ollama's OpenAI-compatible /v1 surface.
• Ships a curated catalog of the 17 models Ollama Cloud served on 2026-09-29, each with the thinking levels its own /api/show metadata reports and the default effort that metadata declares. Models the metadata does not ladder take the standard ladder and claim no default.
• Adds llm/discoverModels (/api/tags + /api/show) and registers Ollama's web search/fetch endpoints as ctx.web providers.
• Resolves credentials through the harness credentials seam (OLLAMA_API_KEY by default; an empty reference suits a local server).

Install:

dsh plugin --profile web add --force \
  https://github.com/Asheblog/dsh-ollama-cloud/releases/latest/download/dsh-ollama-cloud.tgz

Verified on DSH 0.2.0-rc.1 against the live service: chat, switching a model's reasoning level, web search and fetch.