Skip to content

Releases: thelabs-id/kayon

Kayon v1.5.2 — fit reserve re-measured against the shipped runtime

Choose a tag to compare

@github-actions github-actions released this 17 Jul 18:16

If you are on 1.5.0 or 1.5.1, Kayon will offer this update itself. Click Download, then Relaunch to update.

The fit reserve is right for the runtime Kayon actually ships

  • 1.5.1 fixed the fit engine to read each model's vocabulary and compute the reserve from that. It turns out that was measured against an older llama.cpp than the one Kayon bundles.
  • The bundled runtime (llama.cpp b10056) does not keep that reserve in your GPU memory at all. It moved the output buffer to system RAM, so vocabulary now costs no VRAM.
  • What is left grows with your context length, and the old model had no term for that. So at short context it reserved too much, and at long context it could reserve too little and tell you a model fits when it does not. This release measures the current runtime and reserves what it really uses: the model's width plus the context.
  • Checked against llama.cpp's own numbers across six models and two context lengths, the prediction now matches what it allocates to within a rounding error.

Mixture-of-Experts models reserve conservatively

  • Expert models allocate memory the width formula does not describe. Measured on one, the real figure was about double the estimate.
  • Rather than guess from a single measurement, Kayon reserves a deliberately generous fixed amount for any expert model until there is enough data to model it properly. This can only make Kayon more cautious about whether an expert model fits, never less.

The bundled runtime is now pinned and checksummed

  • Kayon records the exact llama.cpp build it ships, verifies its checksum before staging it, and refuses to build against anything that does not match. Before this, the bundled runtime was an unlabeled local build that reported its version as "1".
  • Releases are now built by GitHub Actions from that pinned runtime, not by hand.

Windows will warn that the publisher is unknown. Kayon is not code-signed yet; that is separate from the update signature, and it is coming.

Kayon v1.5.1 — honest fit reserve

Choose a tag to compare

@caesarlab caesarlab released this 17 Jul 10:30

If you are on 1.5.0, Kayon will offer this update itself. Click Download, then Relaunch to update.

Kayon was too pessimistic about what fits

  • The fit engine reserved 1.5 GB of your VRAM beyond the model weights and KV cache. The real figure is about 256 MB. On an 8 GB card that is 16% of your VRAM, held back for nothing.
  • So Kayon has been telling people models would not fit when they fit comfortably. If a quant you wanted showed as a split or a no, check it again.
  • The 1.5 GB was not measured. It was a figure carried over from a CUDA build that Kayon does not actually ship. This release measures the real runtime instead of trusting the number.

The reserve is now read from your model, not assumed

  • It turns out this reserve has almost nothing to do with model size. It is the output buffer, so it scales with the model's vocabulary. A 70B model needs the same amount as a 3B one with the same tokenizer.
  • Kayon now reads each model's vocabulary out of its own file and computes the figure. Predicted against what llama.cpp actually allocates: 96.0 MB predicted vs 97.1 observed at one vocabulary, 250.5 vs 254.5 at another.
  • Every model in the catalog gets its own number now, from 250 MB for Llama up to 512 MB for Gemma 4.

The runtime is Vulkan, and now says so

  • Kayon's README, settings screen and documentation all claimed a CUDA runtime. The bundled llama.cpp has no CUDA backend in it; it is the Vulkan build. Every one of those claims is corrected.
  • Vulkan is the deliberate choice. The CUDA build plus its runtime is about 600 MB against Vulkan's 20 MB, and a 30x download is too much to pay for faster prompt processing. It is slower than CUDA on NVIDIA, and that is the trade.
  • The GPU details on the dashboard still mention CUDA. That is your driver's CUDA version read from NVIDIA's own library, which is true and stays.

Kayon will no longer guess an offload

  • If Kayon cannot compute an honest verdict for a model, it now refuses to load it rather than falling back to putting every layer on the GPU. That fallback was most likely to fire on exactly the small cards it would then run out of memory on.

Windows will warn that the publisher is unknown. Kayon is not code-signed yet; that is separate from the update signature and is coming.

Kayon v1.5.0 — per-user install and self-update

Choose a tag to compare

@caesarlab caesarlab released this 17 Jul 06:13

Read this before installing if you already have Kayon. This version installs to your user account instead of Program Files, so it will not replace an existing install. Uninstall your current Kayon first (Settings, Apps, Kayon), then run this installer. Your models, chats and settings live in your profile and survive either way.

Kayon updates itself now

  • Kayon checks on launch whether a newer version exists, and tells you. It does not download it.
  • Click Download when you want it. When the download finishes you get Relaunch to update, and the update applies on that click.
  • Because Kayon now installs for your user rather than the whole machine, updating no longer raises a Windows administrator prompt. This is also why the install location changed.

The update check plays by the same rules as everything else

  • The check asks GitHub for a version file. It sends no identifiers, no telemetry, nothing about you or your machine beyond the request itself.
  • It is written to the network log, exactly like model downloads and catalog lookups. An update path that skipped the log would make the log a lie.
  • Settings has a switch to turn it off. With it off, Kayon makes no update request at all, and there is still a Check for updates button for when you want one.
  • Nothing is downloaded without your click. That is the same rule models already follow.

Signed, and checked before anything runs

  • Every update is signed with a key that never leaves the developer's machine, and Kayon verifies that signature against a key built into the app before it runs a single byte.
  • An installer that fails the check is refused, not executed. This was tested by feeding it a forged artifact and confirming it was rejected.
  • This matters more than the convenience: an updater is the one feature that downloads and runs code.

Also in this release

  • Deleting a chat deletes that chat's workspace folder and the files in it, from 1.4.1. A folder you attached yourself is still never touched.

Windows will warn that the publisher is unknown. Kayon is not code-signed yet; that is separate from the update signature above and is coming.

Kayon v1.4.1 — deleting a chat deletes its files

Choose a tag to compare

@caesarlab caesarlab released this 16 Jul 19:00

Deleting a chat now deletes its files

  • Deleting a chat used to remove two database rows and nothing else. The chat's workspace folder, and every file in it, stayed on disk permanently.
  • That included documents you attached. A chat you deleted because it held something sensitive kept the PDF you gave it.
  • The folders were also unreachable. Kayon's file routes require a live chat, so the leftovers were invisible inside the app while sitting in plain view in Explorer.
  • A delete that looks final should be final, so a chat's workspace now goes when the chat goes.

A folder you attached is never touched

  • Only the workspace Kayon created for a chat, at ~/.kayon/workspace/<chat>/, is removed.
  • If you attached your own folder to a chat, it is yours. Deleting the chat leaves it and everything in it alone, the same way Kayon never writes to Ollama's model store.
  • Kayon deletes only what Kayon created.

Old leftovers are reclaimed on launch

  • Every version up to 1.4.0 left a folder behind for each chat you deleted, so your install is probably carrying a pile of them.
  • On first launch, 1.4.1 removes the workspaces of chats that no longer exist. Directories that Kayon did not create are left alone, even if you parked them in the workspace folder.

Run the installer over any earlier version. Library, chat history and settings survive.

Kayon v1.4.0 — artifact and document viewer

Choose a tag to compare

@caesarlab caesarlab released this 16 Jul 14:06

Artifacts and documents, viewable in the app

  • A Files panel in Chat lists the session workspace: documents you attached and files the model wrote, together.
  • Click one to open it in place. Markdown, text and code, images, real PDF pages with paging and zoom, and HTML.
  • PDFs render page-for-page, not as extracted text. The engine and every asset it needs ship inside the installer, so viewing a document never sends it anywhere. The installer grows from 16.3 MB to 18.6 MB to pay for it.
  • The viewer is read-only. Save a copy is an explicit click; nothing is written for you.

Artifacts render, but they do not run

  • An artifact's JavaScript does not execute, and this is deliberate rather than unfinished.
  • A content policy can stop a page from fetching, but nothing stops a script from navigating itself to https://somewhere/?your=data. A navigation is not a fetch, so no policy catches it. This was tested, not assumed: with scripts enabled, a test artifact really did reach a live external site.
  • Running artifact scripts and promising that nothing leaves your machine are mutually exclusive here. The promise wins.
  • So a chart or React artifact shows as static markup. The viewer says so on the artifact itself, and names the remote URLs it refused to load. Save a copy to run it in a browser you trust.

Two file-access bugs, both present in earlier versions

  • A crafted request could read your entire chat database through the session file route. Session ids are joined into a folder path, and an id of .. walked up to Kayon's own data directory.
  • A crafted request could read any file your account can read/C:/Windows/win.ini returned the file. The web server joined the request path onto its asset folder, and on Windows an absolute path throws the base away.
  • Both are fixed and pinned by tests. Neither needed a model, a tool call, or your permission to trigger, so updating is worth doing even if you never open an artifact.

Tool cards

  • Tool calls now start collapsed. The header keeps the name, the status and a one-line result, so a short answer is not buried under its own plumbing. Click to expand. A call waiting for your approval stays open, because its arguments are what you are approving.
  • The dot and the tool name are no longer jammed together.
  • Models answer the question now instead of describing the calculator. Asked "what is 1024 * 768?", a 3B model used to explain the function and its JSON shape; it now replies 786432.

Chat

  • A turn that breaks mid-stream keeps its tool trace. Code may have run and files may have been written before the failure, and that record used to be the one thing that vanished on reload.
  • Calls interrupted by a broken stream are marked interrupted, so reopened history never shows an Approve button that no longer does anything.
  • Reopening Kayon returns to the chat you had open, instead of a blank composer.

Run the installer over any earlier version. Library, chat history and settings survive.

Kayon v1.3.2 — forgiving attached-file names

Choose a tag to compare

@caesarlab caesarlab released this 15 Jul 18:25

This download has been withdrawn. Versions up to 1.3.2 shipped a flaw in the local web server: a crafted request could read any file your Windows account can read, and another could read the chat database. Both were found in review and fixed in 1.4.0. The installer has been removed from this release so nobody installs it by accident. The notes below are kept as the record. Please use the latest release.


Fix: the model couldn't find your attached file

  • Attach a file called Project Roadmap - Timeline.pdf, ask the model to read it, and it would fail. Small models truncate a long name and call read_file("Timeline.pdf"), or try ./ and ~/ variants. Nothing matched, and after a cascade of errors the model gave up and invented a summary of a file it never opened.
  • read_file now resolves a truncated or approximate name to the right file, with a unique case-insensitive basename match: exact first, then suffix, then substring. So Timeline.pdf opens Project Roadmap - Timeline.pdf.
  • The match is re-validated through the workspace scope guard, so a symlink still can't escape.
  • When nothing matches, the error lists the real filenames, so the model retries with the right one instead of hallucinating.
  • The attach note now quotes exact filenames.

Together with the PDF text extraction in 1.3.1, attaching a PDF and asking for a summary works end to end. A larger tool-capable model writes the better summary.

Run the installer over any earlier version; library, chat history and settings survive.

Kayon v1.3.1 — read PDFs

Choose a tag to compare

@caesarlab caesarlab released this 15 Jul 18:11

This download has been withdrawn. Versions up to 1.3.2 shipped a flaw in the local web server: a crafted request could read any file your Windows account can read, and another could read the chat database. Both were found in review and fixed in 1.4.0. The installer has been removed from this release so nobody installs it by accident. The notes below are kept as the record. Please use the latest release.


Fix: attached PDFs are readable

  • Attaching a PDF and asking the model to read or summarize it produced nonsense. read_file read the raw bytes as UTF-8, and a PDF is binary, so the model saw %PDF-1.4 1 0 obj << /Type /Catalog instead of the document's words. No prompt could fix that, because the text never reached the model.
  • read_file now extracts a PDF's text. The whole file is parsed, since a PDF keeps its xref at the end.
  • PDFs over 25 MB, and scanned or image-only ones with no text layer, return a clear message rather than failing cryptically. OCR is out of scope for now.
  • Non-PDF binaries such as images, office docs and archives are refused with an explanation instead of being fed to the model as replacement-character garbage.

One caveat worth setting expectations on: summary quality still depends on the model. A 3B model reads the file correctly and still summarizes weakly. A larger tool-capable model does much better with the same text.

Builds on 1.3.0. Run the installer over any earlier version; library, chat history and settings survive.

Kayon v1.3.0 — tools (agentic tool calling)

Choose a tag to compare

@caesarlab caesarlab released this 15 Jul 17:39

This download has been withdrawn. Versions up to 1.3.2 shipped a flaw in the local web server: a crafted request could read any file your Windows account can read, and another could read the chat database. Both were found in review and fixed in 1.4.0. The installer has been removed from this release so nobody installs it by accident. The notes below are kept as the record. Please use the latest release.


New: tools

When a loaded model's GGUF chat template actually supports tool calling, Kayon detects it at load and never guesses. Chat then gains a built-in tool set driven by a server-side agent loop.

  • The model's tool calls run locally, results feed back, and the loop continues until a final answer.
  • Every call, with its name, arguments and result, shows up inline and is persisted with the message, so old chats stay auditable.
  • The set: calculator (a deterministic evaluator, no eval), read_file, list_dir, write_file, read_selection, a Python code interpreter, and web search and fetch_url.

Workspace and artifacts

  • Every chat has one: a folder you attach, or an auto-created ~/.kayon/workspace/<session>/.
  • Attach files and they are copied in. Files the model writes land there as artifacts.
  • Filesystem and code tools work only inside it. .., absolute paths and symlink escapes are refused.

Web is opt-in

  • A per-session toggle, off by default, gates search and fetch_url.
  • DuckDuckGo is the default: no key, no account, straight from your machine, and every query hits the network log.
  • fetch_url is SSRF-guarded. Loopback and private addresses are refused, the vetted IP is pinned against DNS rebinding, and every redirect hop is re-checked.

Side effects ask first

  • code always wants a per-call Approve or Deny.
  • write_file only asks when writing into a folder you attached, so artifacts in the auto-workspace appear without a click.

The confirmation is the security boundary. code runs an isolated-mode, cwd-scoped, output-capped, killed-on-timeout Python subprocess, but it is honestly not a sandbox: approved code has your OS permissions. A real sandbox is a later goal. Approve only what you trust.

Also fixed

  • The "best pick" now only crowns a model that actually runs. On a machine where nothing fits, it used to crown an unverifiable 26B and call it "the most capable model that fits". You now get an honest "no model fits this machine" notice.
  • A weak model that loops on a tool returns a real answer instead of "stopped after 8 iterations", and a repeated call never executes its side effect twice.
  • Enter now commits a chat-title rename.
  • The tools UI uses line-art icons instead of emoji.

Verified

  • Backend end-to-end against the real API, database and network log.
  • A full UI click-through.
  • 25 tests passing, and a Codex review iterated to clean.

Kayon v1.2.2 — hide sidecar console window

Choose a tag to compare

@caesarlab caesarlab released this 15 Jul 03:41

This download has been withdrawn. Versions up to 1.3.2 shipped a flaw in the local web server: a crafted request could read any file your Windows account can read, and another could read the chat database. Both were found in review and fixed in 1.4.0. The installer has been removed from this release so nobody installs it by accident. The notes below are kept as the record. Please use the latest release.


Fix: no more console window

  • Starting a model popped a console window on screen.
  • The llama.cpp llama-server sidecar, and the nvidia-smi fallback used when NVML is unavailable, are console-subsystem executables, so Windows opened a console when spawning them.
  • Both now start with CREATE_NO_WINDOW. Kayon already captures their stdout and stderr, so logs and the health check are unaffected. The window simply never appears.

Builds on 1.2.1, the desktop CSRF fix. Run the installer over any earlier version; your library and settings survive.

Kayon v1.2.1 — desktop CSRF fix

Choose a tag to compare

@caesarlab caesarlab released this 14 Jul 17:10

This download has been withdrawn. Versions up to 1.3.2 shipped a flaw in the local web server: a crafted request could read any file your Windows account can read, and another could read the chat database. Both were found in review and fixed in 1.4.0. The installer has been removed from this release so nobody installs it by accident. The notes below are kept as the record. Please use the latest release.


Critical fix. This replaces 1.2.0

Don't use 1.2.0. In the installed desktop app it silently rejected every action that changed anything.

What went wrong

  • The Tauri window loads from tauri.localhost and calls the local API on 127.0.0.1:9518. Those are different origins, so the browser stamps every request cross-site.
  • The CSRF guard checked Sec-Fetch-Site before it checked the Origin allow-list, and rejected anything cross-site. Every write returned 403 without a word: load and chat, downloads, pause/resume/cancel, Ollama adopt, delete, settings, the telemetry toggle.
  • Reads still worked, so the app looked alive while doing nothing.
  • The silence had a second cause. The 403 body was plain text, so resp.json() threw inside an un-caught handler and the UI showed nothing at all.

The fix

  • The guard now treats the Origin allow-list as authoritative. A browser sets Origin on every mutating request and scripts can't forge it, so it is the right thing to trust.
  • A Kayon origin, including tauri.localhost, passes. A foreign origin is still rejected, and Sec-Fetch-Site only matters when no Origin is present. Defence against real cross-site pages is unchanged.
  • The logic lives in a pure csrf_check() with regression tests pinning the tauri.localhost case.
  • apiFetch() no longer throws on a non-JSON or non-2xx response. It returns {ok:false, error}, so a rejected call surfaces as a visible error instead of a silent no-op.

Verified

  • The exact request WebView2 sends, Origin tauri.localhost with Sec-Fetch-Site: cross-site, now returns 200.
  • evil.example and no-origin cross-site still return 403.
  • 20 tests pass, and the Codex review found nothing.

Upgrade

Run the installer over any 1.2.0 install.