Features / Agents

Switch Agents, keep your workspace.

Run Codex, Claude Code, Kimi Code, and OpenCode in the same local workspace—using their official CLIs and the subscriptions you already have, with no extra fees.

01 · Multi-Agent

Official CLIs. One place to work.

Bottega runs Codex, Claude Code, Kimi Code, and OpenCode through their official local CLIs. It does not replace their harness with a generic Agent layer.

Authentication, subscription access, and quotas stay with the provider. Model and reasoning-effort controls come from each CLI's live catalog, so an option appears only when that backend can actually accept it.

A Chat keeps its workspace and history. After an Agent switch, the new Agent can recover saved images and files from earlier messages.

Ship the release notes

Which PRs merged since 0.1.9 would a user actually notice?

Six of the eighteen. Agent parity is the one people will feel first; the two internal refactors fold into a line.

Draft the 0.2.0 release notes from the merged PRs since 0.1.9.

Plan

0.2.0 release notes

Summary

Six headline changes since 0.1.9, grouped by what a user notices first.
Agent parity is the lede — Kimi and OpenCode now reach the same permission ladder as Codex.
Two internal refactors fold into one line; nobody outside the repo felt them.

Sequence

Group the 18 merged PRs by the surface a user touches, not by the package they landed in.
Write each entry as what changed — the PR number is provenance, not news.
Mirror the file into docs/, then read both back so the two can never disagree.

Files

CHANGELOG.md — six entries, newest first, absolute dates.
docs/changelog/README.md — the public mirror, same six entries.

Not in this pass

The 0.1.x backfill — older entries are a separate decision about how far back the record goes.
Release tagging and the download page; they read this file, they do not write it.

Plan above. Say go and I will write it; say which grouping you want changed and I will redraw it first.

Responding

Ask anything

Approve for me

02 · Conversation parity

One interaction model, not one Agent.

Each Agent Harness has its own runtime model. To keep the experience consistent, Bottega provides one interaction layer and adapts streaming replies, tool status, Plan mode, queued messages, and more to each backend.

Ordinary Codex Chat uses its native App Server and checks the actual protocol and required capabilities. Native titles and isolated editing retain separate CLI 0.163.0-alpha.10.2 qualification. Ask for approval uses your decision; Approve for me uses Codex’s automatic reviewer. Electron launches can request the permissions they need. Approval can be refused, and a refusal does not switch the Chat to Full access.

Codex workspace modes allow network access, temporary-directory writes and ordinary reads outside the workspace. Bottega’s previous credential-path denials and internal read-only fences no longer apply to Codex commands.

Full access is broader. Plan follows the selected permissions and does not enforce filesystem read-only access. Unsupported strict roles are refused before execution.

Here is the current capability coverage, which continues to evolve:

CapabilityCodexClaudeKimiOpenCode

Streaming replies✅✅✅✅

Model / Thinking selection✅✅✅✅

Tool status✅✅✅✅

Plan mode✅✅✅✅

Queue mode✅✅✅✅

User approvals✅✅✅✅

@ mentions✅✅✅✅

Browser Use✅✅✅✅

Fork✅✅✅✅

Edit previous message✅✅✅✅

03 · Cross-Agent collaboration

Beyond a unified experience, Agents finish the work together.

Let Claude frame the problem and create a Plan, then pass the necessary context to Codex for implementation. When it is done, the result returns automatically to the original Chat for review, revision, or handoff to the next Agent.

Each Chat keeps its own Agent, workspace, and task history. Messages can run immediately or wait in a queue; the process stays visible, and every result remains traceable and reusable.

Unify the nav bar

Nav implementation

Plan

Navigation implementation plan

Unify the nav bar

Nav implementation

[From Section @Unify the nav bar (source_section_id=sec_7f2a3c)]

@Unify the nav bar · also verify the mobile breakpoints

Unify the nav bar

Nav implementation

[From Section @Nav implementation (source_section_id=sec_91b4e0)]

Plan intent and implementation match; no blocking issues.

First let Claude turn the problem
into a Plan

Drop the work into
another Chat's queue

When it finishes, the result returns on its own

Back in the original Chat — review it,
or hand it to the next Agent

Three frames of one machine. Everything outside the skeleton is the product's own text — the Plan title, the inbound message header, the review verdict; the two handoffs call send_to_section and expect_reply.