KISS Sorcar

Open-source general-purpose AI agent for long-horizon tasks and AI discovery

KISS Sorcar is a free, simple, local-first, bring-your-own-key AI agent framework. It runs as a VS Code extension and a browser/mobile web app, both served by a local daemon, and offers a Python client API for scripting tasks. Your prompts and code are sent directly to the model provider or local endpoint you configure — not through our servers. It supports multi-model workflows just via prompts. Agents run as daemons hosted by the local server (a standalone sorcar terminal command can also run a task without the daemon). Complex AI systems/techniques can be replaced with a paragraph of prompt in KISS Sorcar.

curl -fsSL https://raw.githubusercontent.com/ksenxx/kiss_ai/main/scripts/install.sh | bash

KISS Sorcar vs Claude Code vs Cursor

What is in the Name

KISS Agent Framework is a deliberately small agent runtime organized around the KISS principle ("Keep it Simple, Stupid"). The name “Sorcar” pays homage to P. C. Sorcar, the legendary Bengali magician, evoking the idea of an agent that performs feats that appear magical yet are grounded in disciplined engineering. Note: Sorcar also means government in Bengali.

Installation

Full install from source

curl -fsSL https://raw.githubusercontent.com/ksenxx/kiss_ai/main/scripts/install.sh | bash

If the Update button in the settings UI fails, run the full installation command again. It will not delete your history. The installer targets macOS and Linux on x86_64, aarch64, and arm64. It installs or checks the tools needed to run KISS Sorcar and build/install the VS Code extension.

Python package install

If you only want the Python package (the kiss-web daemon, the Python client API, and the messaging-agent entry points):

pipx install kiss-agent-framework
# or
uv tool install kiss-agent-framework

KISS Sorcar requires Python 3.13+.

Configure model access

Provide at least one model backend. You can use environment variables such as:

export ANTHROPIC_API_KEY=...
export OPENAI_API_KEY=...
export ZAI_API_KEY=...
export MOONSHOT_API_KEY=...
export TOGETHER_API_KEY=...
export OPENROUTER_API_KEY=...
export GEMINI_API_KEY=...

You can also set API keys, a custom model endpoint, and custom HTTP headers in the Settings panel of the VS Code extension or web app.

You can register your own models (e.g. a local vLLM/Ollama endpoint or a provider model not in the bundled catalog) in the Custom Models section of the Settings panel; entries are stored in ~/.kiss/MY_MODELS.json and appear in the model picker alongside the bundled catalog.

VS Code Extension Installation

To install only the KISS Sorcar extension, open Visual Studio Code, search for KISS Sorcar in the extension marketplace, install it, and relaunch VS Code. Press ESC if you do not have a specific API key ready, but configure at least one model backend before running tasks.

Using KISS Sorcar

KISS Sorcar has three client interfaces, all served by one local daemon: the VS Code extension, the remote web/mobile app, and the Python client API. A fourth interface, the sorcar terminal command, runs a SorcarAgent directly in the current directory without the daemon: sorcar -t "Summarize README.md" runs an inline task, sorcar -f task.txt runs the file's content as the task (exactly one of -t/-f is required; see sorcar --help for the model, budget, and work-dir flags).

VS Code extension and web/mobile app

Open the KISS Sorcar sidebar in VS Code (or the remote web app in a browser) and type or speak your task. The chat interface provides:

• @ file/folder mentions with ranked project-file completion.
• Per-task git worktree isolation — worktrees are pre-warmed in the background for fast task start, with auto-commit and merge on success, or an interactive merge/discard prompt — toggle both in the Settings panel.
• A pre-run task classifier that detects whether the task may create or modify files in the project (code, docs, reports, presentations, data — anything that could become git-tracked) and so needs a worktree — tasks that write no files (questions, Internet answers given in the reply, git-only operations) skip worktree isolation, and simple tasks get a lite system prompt for faster starts. With an OPENROUTER_API_KEY it asks the ~typesafe/jev-latest decisions model one typed question (about 0.2 s and $0.00003 per task; on a 415-prompt benchmark it matched hand labels more often than the LLM classifiers, see benchmarkings/task_classifier/); otherwise, or if that call fails, it falls back to one fast non-agentic call on the run's own model (structured output, with one plain-text retry if that fails; skipped for cc/* and codex/* models). Both are Settings-panel checkboxes: "Classify tasks before running" (classify_tasks) and "Classify with Jev" (classify_with_decisions; unticked pins the LLM classifier).
• A model picker, per-task budget caps, chat history with resume (filtered to the current workspace by default), an agent dashboard (burger menu, bottom-left), and inline rendering of tool-generated images in the chat panels.
• Image and PDF attachments: attach files to a task via the picker, paste, or drag-and-drop — images (HEIC/HEIF converted, oversized ones re-encoded) and PDFs are sent to the model along with the prompt.
• Persistent agent memory (on by default): standard Sorcar runs get seven memory_* tools (search, pull, read, write, list, refresh, delete) and a memory protocol, so agents recall lessons, preferences, and decisions across tasks (not for Docker runs, cc/*/codex/* models, runs that drop the built-in toolset, or runs whose model_config supplies its own system_instruction). Pages are Markdown files under ~/.kiss/memories with a SQLite vector index (OpenAI embeddings when an OPENAI_API_KEY is available, otherwise a fully offline hashed embedder). Toggle it — or point it at a custom directory — in the Settings panel, or set KISS_USE_MEMORY=0.
• Wake-word voice chat ("sorcar, …") via the mic button, including steering a running agent by voice.
• Live steering: inject a message into a running agent, or switch its model mid-run. Wrapping the message in <task>…</task> tags instead queues it as a follow-up task that runs sequentially after the current task finishes.
• Tab mirroring — every VS Code window and web client opened on the same workspace shows the same tabs with the same contents; the tab bar is scoped to the client's workspace directory, and sub-agents dispatched with run_agent open their own tab in the calling workspace.
• Scheduled automations: ask in plain language ("every weekday at 9am, summarize my unread Slack messages") and the built-in cron agent (also runnable from the shell as kiss-cron) creates, lists, pauses, resumes, or removes the schedule. A job runs an unattended LLM task or a plain shell command and can deliver its result to an authenticated messaging channel (25 of the 32 channels support delivery, e.g. telegram:123456, email:user@example.com).

The remote web app is the same interface served over a cloudflared tunnel: copy the URL and password from the Settings panel and open it on any device. Its desktop mode adds a docked Task Info sidebar next to the chat — live token, cost, step, elapsed-time, machine, work-dir, and budget metrics for the visible tab's running task, plus a Task update: a short report, written by the bundled task_update agent (src/kiss/agents/seas/task_update_sea.py), of what that task has done so far and its partial results. The agent runs when the panel first shows the task, every 10 minutes after that, and whenever you press the refresh button at the top right of the report; it runs as a sub-agent in the task's own chat and its cost counts towards the task.

The kiss-web daemon

The kiss-web daemon hosts the agents, chat sessions, and the web app, and services every client command — including config reads/writes, default-model lookup, and the wake-word listener — over its socket. The VS Code extension starts it automatically; you can also manage it yourself:

# Start the daemon (serves the web app and the extension).
kiss-web

# Pin the daemon's working directory.
kiss-web --workdir "$HOME/projects/my-repo"

# Print the active remote (cloudflared) URL and exit.
kiss-web --url

# Trust the daemon's TLS certificate in this user's browsers and exit.
kiss-web --trust-ca

The web app is always served over HTTPS. The Cloudflare URL uses Cloudflare's certificate; the Local (https://127.0.0.1:PORT) and LAN (https://<lan-ip>:PORT) URLs use a certificate the daemon issues from a machine-local certificate authority kept in ~/.kiss/tls/ (ca.pem, ca-key.pem). Browsers warn about that certificate until they trust the CA, once per device:

• On the machine running the daemon: kiss-web --trust-ca adds ca.pem to the Chromium/Firefox NSS databases (Linux, needs certutil from libnss3-tools), the login keychain (macOS) or the user Root store (Windows). Restart the browser afterwards.
• On a phone or tablet on the same network: open https://<lan-ip>:PORT/ca.crt, install the downloaded certificate, then enable trust for it (iOS: Settings > General > About > Certificate Trust Settings; Android: Settings > Security > Encryption & credentials > Install a certificate > CA certificate). Compare the SHA-256 fingerprint printed by kiss-web --trust-ca with the one the device shows.

The CA certificate is public; the CA key never leaves ~/.kiss/tls/. The server certificate is re-issued automatically when it is expiring or when the machine's LAN address changes, so the CA has to be trusted only once. The password gate and the LAN lockdown while no remote_password is set are unchanged.

Python client API

Any Python process can run a task on the daemon with kiss.server.sorcar.run and block until it finishes (up to timeout, one hour by default):

from kiss.server import sorcar

result = sorcar.run("Summarize README.md", work_dir="/path/to/repo")
print(result.text, result.success, result.cost, result.tokens, result.steps)

# Continue the same chat (the agent sees the prior task as context):
follow_up = sorcar.run("Now fix the typos you found", chat_id=result.chat_id)

run() accepts keyword options mirroring the chat interface — model, work_dir, scope_work_dir (workspace directory the task's tab is scoped to, when different from the execution work_dir), chat_id, use_worktree, auto_commit, max_budget, model_config (custom endpoint/headers), use_web_tools, classify_tasks (per-run task-classifier override; None falls back to the daemon's persisted setting), use_memory (per-run persistent-memory override — the memory_* tools plus the memory protocol; None falls back to the daemon process's non-empty KISS_USE_MEMORY environment variable, else its persisted setting), is_parallel, timeout (how long the client waits for the result — 3600 seconds by default, None waits indefinitely; on expiry the client raises TimeoutError while the daemon task keeps running), stop_on_timeout (also stop the task when timeout expires; default False), sock_path (daemon socket override), parent_task_id / parent_tab_id (attach the run as a sub-agent of a calling task, nesting its tab and history row under that task — how the run_agent tool dispatches), parent_reviewer (mark that sub-agent run as part of a reviewer's sub-tree so its own run_parallel refuses to spawn further reviewers; default False) — plus options to customize the agent itself:

• tools="/path/to/my_tools.py" — a Python file whose get_tools() function returns the functions the daemon registers as extra agent tools. The functions are never serialized: only the path travels over the socket, and the daemon imports the file, calls get_tools(), and runs the tools in its own process.
• system_prompt — replace the default system prompt for the run (and its sub-agents); append_to_system_prompt / append_to_prompt — append text to the system prompt or task prompt instead of replacing them.
• append_basic_tools=False — restrict the agent to finish plus your tools file, dropping the built-in toolset.
• extension_agent_path — run a full Sorcar Extension Agent (SEA), a Python file that computes the run's parameters and tools on the daemon; see Sorcar Extension Agents (SEAs) below.

Sorcar Extension Agents (SEAs)

A Sorcar Extension Agent (SEA) is a plain Python file whose path you pass as extension_agent_path to sorcar.run(). The daemon imports the file on every run and calls its top-level X() functions — named after run()'s parameters — to compute the run's parameters; parameters without a getter keep whatever the caller passed. One file can define the task prompt, system prompt, model, budget, tools, and safety hooks — a complete custom agent:

# weather_agent.py — a minimal SEA
import requests

def prompt() -> str:
    return "Look up the current weather in San Francisco and report it."

def max_budget() -> float:
    return 0.50

def use_worktree() -> bool:
    return False  # no repo changes expected

def if_append_basic_tools() -> bool:
    return False  # restrict the agent to finish + our tools

def system_prompt() -> str:
    return ("You are a weather assistant. Use the get_weather tool "
            "to look up weather, then call finish with the result.")

def get_weather(city: str) -> str:
    """Return current weather for a city from wttr.in.

    Args:
        city: City name to look up.
    """
    resp = requests.get(f"https://wttr.in/{city}?format=3", timeout=10)
    resp.raise_for_status()
    return resp.text.strip()

def tools() -> list:
    """Return the tools the agent may call."""
    return [get_weather]

from kiss.server import sorcar

result = sorcar.run(
    "placeholder",  # required non-blank; overridden by prompt()
    extension_agent_path="weather_agent.py",
)

Key points:

• Overridable parameters. Every sorcar.run() parameter except timeout, stop_on_timeout, sock_path, parent_task_id, parent_tab_id, parent_reviewer, and extension_agent_path itself has a getter named after it: prompt(), work_dir(), model(), chat_id(), system_prompt(), tools(), use_worktree(), auto_commit(), max_budget(), model_config(), if_append_basic_tools() (overrides append_basic_tools), append_to_system_prompt(), append_to_prompt(), scope_work_dir(), use_web_tools(), classify_tasks(), use_memory(), is_parallel(), and tool_profile(). use_web_tools(), classify_tasks(), and use_memory() return a bool, or None to fall back to the daemon's default (the persisted setting — for use_memory() a non-empty KISS_USE_MEMORY environment variable on the daemon process wins over the stored value). tool_profile() returns the name of the tool profile the run's built-in toolset is cut down to — "full", "review", "shell", or "bash" (Bash only; the bundled /sh agent uses it) — or "" for the daemon's usual choice.
• Atomic, type-checked overrides. Getters run in the daemon process and are re-imported from source on every run. Each return value is type-checked; overrides apply only after every getter succeeds, and a broken getter fails the task with a diagnostic in TaskResult.text.
• Tools, two ways. tools() may return a list of callables — making the script its own tools file — or the path of a separate Python file whose get_tools() (or tools()) returns the callables. Either way the tools execute in the daemon process; nothing is serialized over the socket. tools() overrides (does not append to) the caller's tools argument.
• Hook getters. llm_call_hook() and tool_call_hook() return functions with no run() equivalent (callables can't travel the wire). llm_call_hook(new_messages) runs before every LLM call and its return value replaces the outgoing messages; tool_call_hook(name, args) runs before every tool call — returning "OK" lets the tool execute, any other string suppresses the call and is given to the model as the tool's result:

# guarded_agent.py — veto dangerous shell commands
def veto_destructive(name, args):
    if name == "Bash" and "rm -rf" in str(args.get("command", "")):
        return "Blocked: destructive command"
    return "OK"

def tool_call_hook():
    return veto_destructive

The full authoring guide — every getter's semantics, error handling, chat continuation, model configuration, and a complete worked example — is in src/kiss/server/README.md.

Slash commands. Name the file xxx_sea.py and it is also a chat command: typing /xxx some text in the VS Code extension or web app makes the session call run_agent with that file and "some text" as the task. The bundled channel agents are registered this way (/slack, /gmail, ...), as is /ask <question>, which answers a question about the current task from its persisted events in ~/.kiss/sorcar.db; typed into a running task's tab it runs as a nested sub-agent without interrupting the agent, and the reply appears as an "Answer" panel in the transcript. List your own SEA folders, one per line, in ~/.kiss/SEAS.md; they are picked up within two seconds, no restart needed. Syntax, precedence, and the dispatch flow are documented in docs/sea-commands.md.

Skills, MCP servers, and customization

• Agent Skills loaded from ~/.kiss/skills, <project>/.kiss/skills, Claude skill directories, .agents/skills, and bundled Sorcar skills.
• MCP server discovery from ~/.kiss/mcp.json, <project>/.kiss/mcp.json, and <project>/.mcp.json; OAuth tokens are persisted under ~/.kiss/mcp_auth/. A curated catalog of privacy-first MCP connectors (fetch, time, memory, GitHub, Slack, Google Workspace, WhatsApp, …) ships in connectors/ with enable.py/verify.py CLIs.
• "Tricks" (inject-instruction) entries are the concatenation of two ## Trick-sectioned Markdown files: (1) ~/.kiss/MY_INJECTION.md — your personal tricks, auto-created on first read with a starter trick and never overwritten thereafter; (2) the bundled src/kiss/INJECTIONS.md, read directly from the package so every upgrade delivers the latest bundled tricks. Edit ~/.kiss/MY_INJECTION.md to customise; your tricks are listed first.
• Welcome-screen sample-task chips are the concatenation of two ## Task-sectioned Markdown files: (1) ~/.kiss/MY_TASK_TEMPLATES.md — your personal tasks, auto-created on first launch with the seed ## Task\n\nHi!\n and never overwritten thereafter; (2) the bundled src/kiss/SAMPLE_TASKS.md — sample tasks shipped with the extension, read directly from the package so every upgrade delivers the latest chips. To customise your chips edit ~/.kiss/MY_TASK_TEMPLATES.md; to reset it remove the file.

Messaging & Third-Party Agents

KISS Sorcar includes 43 third-party agents that act on messaging services, mailboxes, devices, and web services on your behalf. 32 are messaging-channel agents:

BlueBubbles · DingTalk · Discord · Email (IMAP/SMTP) · Feishu · Gmail · Google Chat · Home Assistant · iMessage · IRC · LINE · Matrix · Mattermost · Microsoft Teams · Nextcloud Talk · Nostr · ntfy · Phone Control · QQ · Signal · SimpleX · Slack · SMS · Synology Chat · Telegram · Tlon · Twitch · Webhook · WeCom · WeiXin · WhatsApp · Zalo

Nine more are service agents that give Sorcar authenticated API tools for productivity and data services:

Brave Search (kiss-brave) · Firecrawl (kiss-firecrawl) · GitHub (kiss-github) · Google Calendar (kiss-gcal) · Google Docs (kiss-gdocs) · Google Drive (kiss-gdrive) · Google Sheets (kiss-gsheets) · Notion (kiss-notion) · PostgreSQL (kiss-postgres)

In a chat task, just say what you want ("send 'running late' to Alice on WhatsApp", "list my open GitHub PRs") — Sorcar dispatches the matching agent through its run_agent tool. Besides the task and the optional agent name (empty runs a plain Sorcar sub-session through the bundled src/kiss/agents/seas/dummy_sea.py), the tool takes a workspace (account identifier for multi-account channels such as Slack; default "default") and the same optional per-run options as sorcar.run() — model_name, max_budget, timeout, chat_id, system_prompt, tools, model_config, use_worktree, auto_commit, use_web_tools, classify_tasks, use_memory, is_parallel, append_basic_tools, append_to_system_prompt, append_to_prompt — as strings ("true"/"false" for booleans, a JSON object for model_config); an empty value keeps the default. Channel and cron sub-tasks always run without a worktree or auto-commit. Each agent also has its own CLI entry point (kiss-slack, kiss-gmail, kiss-whatsapp, …) for running tasks directly from the shell.

Channels also work inbound: gateway-capable messaging channels can become prompt surfaces of their own. A one-shot --channel poll tick (normally scheduled as a recurring cron job — just ask for "an always-on Telegram gateway" in chat) drains new inbound messages and runs each as a Sorcar task, with persisted thread continuity across ticks, a delivery ledger, per-channel model/budget overrides, sender allow-lists (--allow-users), and an optional pairing handshake (--pairing, --approve, --list-pending) so only approved senders can drive the agent.

Two infrastructure agents round out the set: an A2A agent (kiss-a2a) exposing Sorcar over the agent-to-agent protocol, and an OpenAI-compatible server (kiss-oai) that serves Sorcar behind an OpenAI-style HTTP API. It also ships a Govee smart-home CLI for controlling IoT lights (on/off, brightness, color, and color temperature) via the Govee Developer API.

Credential isolation (Muse auth). On Linux, credentials for the 24 Muse-supported connectors (the six Google services — Google Chat's service-account mode excepted — plus Slack, GitHub, Notion, Discord, Home Assistant, Firecrawl, Brave Search, ntfy, Govee, LINE, Mattermost, Nextcloud Talk, Synology Chat, Twitch, Zalo, BlueBubbles, Microsoft Teams, and Telegram) are isolated by default behind a Meta-Muse-style security boundary: legacy tokens auto-migrate into a vault owned by a local auth daemon on first use (a one-time hand-off of the real credential; plaintext copies are then scrubbed on a best-effort basis), the agent process holds only opaque surrogate tokens that the daemon swaps for the real ones at the network edge, and every boundary-routed API request is host-allowlisted (credential-free, bodyless GET/HEAD redirect hops are the one permitted off-list exception), classified read vs. write, and checked against an allow/deny/ask policy with an audit log. Reads are allowed by default; writes ask for a grant. For Microsoft Teams, after the one-time enrollment hand-off, the daemon performs the OAuth token exchange itself, keeping the vaulted client secret out of ordinary agent API requests. Where the provider supports a poll-based grant, connecting works like the Muse app's Connect button — the user signs in and approves in their own browser, nothing is pasted back: GitHub, Twitch, and Microsoft Teams use the OAuth device authorization grant (RFC 8628) with a public client ID, Nextcloud Talk uses Login Flow v2, Matrix uses the OAuth 2.0 device grant of homeservers backed by Matrix Authentication Service (matrix.org included), and Signal links this computer like Signal Desktop via a signal-cli link QR code; the refresh tokens these sign-ins produce are renewed by the daemon (oauth2_refresh_token credentials) or, for Matrix, by the agent itself. Providers without such a grant get a safe hand-off instead of browser automation: on a headless host the six Google services return the consent URL for the user to approve in their own browser and paste back the resulting localhost redirect URL, and Slack/Discord ask the user to create the bot in their own browser and paste back the bot token — the agent never asks for a password or 2FA code. Manage it with python -m kiss.agents.third_party_agents.muse_auth (status, enroll, import, grant, revoke, audit, clear, daemon, stop, and an export command that reads a vaulted credential back out for recovery); opt out with KISS_MUSE_AUTH=0.

These agents live in src/kiss/agents/third_party_agents/; a prompt-oriented usage guide with a complete agent catalog and 26 worked examples is in src/kiss/agents/third_party_agents/README.md.

Models Supported

KISS Sorcar ships a catalog of 688 models across 9 provider categories, with built-in prices, context lengths, and capability flags (fc function calling, gen generation, emb embedding, dec typed decisions via OpenRouter's /api/alpha/decisions). The source of truth is src/kiss/core/models/MODEL_INFO.json. Models are grouped below by the provider that routes them (i.e., whose API key or CLI serves the model); open-weight openai/gpt-oss-* and google/gemma-* models are served via Together AI.

Current catalog capability totals:

• 666 generation-capable models
• 501 function-calling-capable models
• 11 embedding models
• 2 decision models

Full model list:

Contributing

Contributions in the form of issues are welcome. KISS Sorcar should be able to help implement and review them.

License

Apache-2.0. See LICENSE.

Citation

If you use KISS Sorcar in your research, please cite:

@misc{sen2026kisssorcar,
  title         = {KISS Sorcar: A Stupidly-Simple General-Purpose and Software Engineering AI Assistant},
  author        = {Sen, Koushik},
  year          = {2026},
  eprint        = {2604.23822},
  archivePrefix = {arXiv},
  primaryClass  = {cs.SE},
  url           = {https://arxiv.org/abs/2604.23822}
}