Chat, code, and agent modes
Chat stays tool-free. Code runs the focused tool loop. Agent plans, runs isolated subagents in a fixed order, then synthesizes one answer.
Full capability map
What it does.
What comes next.
Kolkrabbi is being built one independently tested checkpoint at a time. This page keeps the promise honest: working behavior is separated from settled design and future work.
- Available nowIn the current source and test suite.
- Designed, not shippedThe contract is settled; implementation remains.
- PlannedOn the roadmap and still subject to hardening.
01 / WORKING
Useful already.
These capabilities exist in the current binary. Public installer availability is a separate release checkpoint and is not implied here.
One effort dial
Quick, standard, deep, and ultra select model tiers. Agent mode also uses effort to bound the number of planned tasks.
Gateway or local models
OpenRouter works today. An OpenAI-compatible base URL can also point Kolkrabbi at Ollama, LiteLLM, vLLM, or another compatible endpoint.
Safe key onboarding
kolk key <key> classifies and masks the value, refuses known subscription
tokens, verifies OpenRouter when reachable, and stores credentials outside config.
Five focused tools
Read, list, write, edit, and shell execution cover the first code loop. Side effects ask for confirmation unless the user explicitly enables yolo mode.
Local sessions and memory
Conversations save atomically and can resume. Project instructions come from
KOLKRABBI.md or AGENTS.md in the working directory.
File checkpoints
Writes and edits snapshot their previous state. /changes shows touched files
and /rewind restores the latest turn's file changes.
Private usage history
Token, cost, latency, mode, effort, and optional 1–5 ratings stay in local JSONL. The
kolk stats table sends no telemetry.
Small, tested core
A static Go binary, a standard-library-only core, offline end-to-end tests, strict architecture rules, and five target builds protect the working surface.
02 / ACCESS
Your account, your key, your choice.
Additional authentication paths are designed around a hard boundary: Kolkrabbi should not capture or reuse a subscription credential owned by another tool.
Any supported API key
The provider-agnostic command will infer supported key shapes where safe, ask once when ambiguous, and support explicit provider input for CI or uncommon formats.
Claude Agent subscription
Kolkrabbi will hand sign-in to the user's own unmodified claude CLI and run
it as a backend. The vendor owns authentication; Kolkrabbi stores no subscription token.
Codex subscription
Codex will use the same external-agent seam after its policy review, offline fixtures, login handoff, capability mapping, and redaction gates are complete.
Backends in the same Kolkrabbi session
Switching between API and subscription backends will retain the local transcript and project context. Provider-owned history is replayed with an explicit label.
Login without lock-in
Optional browser login and vendor CLI handoff complement paste-a-key onboarding. Neither replaces the zero-config path or makes a config file mandatory.
Inspectable credential sources
Environment, provider environment, and one named store follow a visible first-hit chain. Optional OS keychain storage and source explanations remain opt-in.
03 / CONTINUITY
When a limit hits, the work stays.
This target policy is planned and not active today. It will prefer explicit, explainable continuation over a silent change in model or billing path.
Know which limit stopped work
A subscription limit, account quota, endpoint capacity problem, budget stop, and model refusal remain distinct. Reset times and cooldown scope are preserved when available.
Explain the next move
Kolkrabbi will preserve the turn, say which backend stopped, and show how the project continues with the best-rated eligible configured model for that task.
Respect every configured option
The continuation chain will consider eligible subscription and metered backends in priority order while skipping known cooldowns instead of repeatedly hitting a cap.
Ask before free fallback
After configured subscription and paid options are unavailable, Kolkrabbi will ask before continuing with a free model. The model, tradeoffs, and retained context are shown.
Automatic switching
An opt-in policy will follow the same visible eligibility and cooldown rules without asking at each switch. Silent auto-switching is never the default.
Stop honestly when all limits are reached
If no eligible backend remains, the session pauses with reset information and a resume path. It does not discard work, loop through capped accounts, or pretend success.
04 / WORKFLOWS
More capable, still calm.
Advanced behavior remains optional. The first run stays install, key, and use.
Task-aware model routing
Planner, editor, researcher, tester, synthesizer, and critic roles can choose different models using capability, price, latency, and the user's own ratings.
Computed free-model defaults
A refreshed catalog will rank eligible free models and map effort levels automatically, with account limits distinguished from endpoint capacity.
Careful long-running progression
Saga advances one bounded chapter at a time: plan, act, verify, checkpoint, report, and decide whether to continue under explicit time, cost, and progress limits.
Deeper code mode
Repository awareness, diff previews, multi-hunk edits, formatters, automatic test loops, plan mode, conversation undo, and commit assistance extend the focused code loop.
Routed agent teams
Parallel-capable subagents, optional worktree isolation, role-specific models, retries, a critic, and clear partial-failure synthesis build on today's ordered agent mode.
MCP, skills, commands, and hooks
Namespaced external tools, Markdown commands, reusable skills, and lifecycle hooks will extend Kolkrabbi under the same permission and provenance rules.
05 / SAFETY
Local by default. Explicit at the edges.
Safety claims are only useful when architecture and tests can enforce them.
Confirm side effects
Shell, write, and edit operations ask before running. Yolo mode is an explicit session choice rather than a hidden default.
Secrets stay out of model context
Opaque secret handles, restricted store imports, sink-specific scrubbing, safe masks, and child-process environment subtraction form the settled credential boundary.
Permission rules and path jail
Allow, ask, and deny rules will apply by tool and pattern, with project-root boundaries, hardline destructive-command blocks, and visible scope.
Optional execution sandboxes
Platform isolation and container paths will let unattended work run inside declared boundaries. Yolo inside a sandbox stays different from unrestricted host access.
Language-neutral event protocol
Versioned schemas, typed payloads, golden frames, forward-compatible fields, and one envelope prepare identical CLI, daemon, desktop, and mobile streams.
Budgets and offline gates
Tests, lint, architecture checks, platform builds, binary-size and startup budgets, installer safety, and release contracts run without spending model credits.
06 / INTERFACES
One core, more places to use it.
The terminal remains first. Later clients attach to the same versioned core rather than rebuilding model behavior independently.
Interactive and scripted terminal
Run a REPL, pass a one-shot prompt, resume a session, select mode/model/effort, or point at a compatible endpoint from one command.
Themes
Multiple terminal themes, a quiet presentation, and NO_COLOR support will
change appearance without changing behavior or requiring setup.
Full terminal UI
Multiline input, history, completions, streaming Markdown, diffs, collapsible tool calls, clear reasoning controls, and a mode/model/context/cost status line.
Local model dashboard
Session analysis, ratings, cost, speed, task categories, comparisons, and routing insight will stay in a local database with no hosted telemetry service.
Attachable local service
NDJSON, child stdio, and HTTP plus server-sent events will carry byte-identical event envelopes so a client can attach, replay, and cancel turns consistently.
Desktop, iPad, Android, and Windows
Thin desktop and mobile clients plus complete Windows support arrive as additive frontends and platform ports after the protocol and service surfaces are stable.
07 / WATCH
See the whole flow.
Two short walkthroughs will live here. Their media sources have not been supplied yet, so these are accessible placeholders rather than broken players.
Coming soon
English explainer
Install, first key, chat, code, agent, model switching, and local history.
Próximamente
Explicación en español
Instalación, primera clave, chat, código, agentes, cambio de modelo e historial local.