Skip to content

koto 1.5.0

Choose a tag to compare

View all tags
@jpzk jpzk released this 18 Oct 14:03
Immutable release. Only release title and notes can be modified.
1.5.0
aa78533

koto 1.5.0

pi coding agent in the guest, Venice + MiniMax through the proxy (#37, #40, #35)

  • The rootfs ships pi 0.84.4 at /opt/pi. It's pinned by sha256, runs offline (PI_OFFLINE=1, no telemetry, no version check), and fcguest/verify-rootfs.sh checks it.
  • Venice (#40): the proxy accepts pi's chat-completions route from the guest and relays it to the Venice API, using the host's Venice key. Budget key: venice/apikey.
  • MiniMax (#35): there's a new provider=minimax, served by an Anthropic-compatible proxy leg (POST /anthropic/v1/messages). The default model is MiniMax-M3. The host key in creds/minimax.key is billed as minimax/apikey (sk-api- keys) or as minimax/subscription (M Plan). For M Plan, the 5h and weekly windows are read from token_plan/remains and exported as koto.llm.ratelimit.*. Set KOTO_MINIMAX_REGION=cn for the mainland endpoints.
  • The rootfs ships a pi template at /usr/local/share/koto/pi/models.minimax.json. It points at the in-guest proxy and holds only a placeholder key.
  • In both cases the real key stays on the host. The guest sends a placeholder, and the proxy swaps it for the real key.
  • Scope: pi is installed and routed, but the guest agent turn doesn't launch pi automatically yet (runPi is follow-up work). Today pi runs from the group's shell or as a tool.

Venice account balance (#34)

  • Shows the Venice account balance as reported by Venice response headers. The balance is account-wide, not per key, and the USD/DIEM buckets are passed on as Venice sends them. Only the inference key is used: no admin key and no billing API call.
  • Shown in <koto-context> and the TUI as a credits line.
  • OTel exports it as koto.llm.balance, plus request-limit gauges.
  • There's no per-key spend tracking.

Verification before release

Each leg ran a fresh nested end-to-end test on a group with network=none:

  • pi made a bash tool call and gave its final answer through the proxy.
  • The daemon logged the proxied provider call and its budget key.
  • The repo's own OTLP receiver got the koto.llm.* datapoints.
  • A hash probe of the guest env and filesystem found no copy of the key.

Upgrade note

  • koto, koto-tui and rootfs.img are rebuilt. The rootfs is byte-identical to the image both e2e runs used.
  • firecracker 1.17.0 and vmlinux 6.1.186 are byte-identical to 1.4.0.
  • New groups need the new rootfs to get pi.

koto 1.5.0 for linux/x86_64.

component version
koto 1.5.0
koto-tui 1.5.0
firecracker 1.17.0
vmlinux 6.1.186
rootfs.img fedora44

Install: curl -fsSL https://kotovm.com/install.sh | sh -s -- --version 1.5.0,
or from a clone of this tag: make fetch && make install && make wizard.

SHA256SUMS is signed by A6E69ED6BC4779F3281721484CC1AFDE15B64EA3 (SHA256SUMS.asc); both routes
verify that signature, and the unpacked bytes against the artifacts.sha256
committed at this tag, before anything is installed.

🤖 Generated with Claude Code

Assets 10
Loading