KISS Sorcar is a small local-first agent framework you drive with a prompt

Local first, and the provider is yours

KISS Sorcar is described as a free, simple, local-first, bring-your-own-key AI agent framework. It runs as a browser or mobile web app served by a local daemon, and it offers a Python client API for scripting tasks. The most consequential sentence in the README is about where your data goes. Your prompts and code go directly to the model provider or local endpoint you configure, never through our servers. For an agent framework that runs shell tools and writes files, that is the property that determines whether it is usable on a work laptop, and it is also why there is no account system and no hosted component in the architecture. The package is published on PyPI as kiss-agent-framework at version 2026.10.19, requires Python 3.13 or newer, and the badge in the README names the licence as Apache 2.0 even though the repository records a custom classification, so the LICENSE file is the one to read.

The idea is that a paragraph beats a pipeline

The central claim is stated directly in the README. Multi-model workflows take a paragraph of prompt, not a pipeline, and complex AI systems and techniques can be replaced with a paragraph of prompt in KISS Sorcar. That is a strong claim and it is the design philosophy rather than a feature list, so it is worth knowing what it implies before you evaluate the project. If a workflow can be described in prose, then a framework that gives the model a long-lived loop, tools, memory and a browser is sufficient, and the machinery of separate orchestrated stages is optional. The framework is named for the KISS principle, Keep It Simple, Stupid, and the README quotes Einstein on the subject. The name Sorcar pays homage to P. C. Sorcar, and the repository layout reflects the lightweight intent, with a sorcar directory, a src/ directory, an rsorcar entry point, a website directory and a Dockerfile, rather than the deep package hierarchy a larger framework would have.

The web app, the daemon and the client API

There are three ways to use it and the README treats them as peers. The web and mobile app is the interface, served by the local daemon so the same thing works from a phone on the same network. The kiss-web daemon is the process that does the work, and the reference documentation for every sorcar.run() option, the tools, the hooks and the guide for authoring a Sorcar Extension Agent live in src/kiss/server/README.md. The Python client API is the scripting path, so the same task can be triggered from code rather than typed. The third-party agents documentation covers the messaging and service agents, sign-in and worked examples. The dependency list shows what the client side leans on, with the openai and anthropic clients, the anthropic extra pulling boto3 for SigV4 signing of Bedrock model requests, google-genai for Gemini, and pydantic plus pydantic-settings for configuration. The pydantic-settings pin carries a comment naming the CVE it fixes, which is a sign the maintainers track security advisories in their dependency constraints rather than only in release notes.

Extension agents, skills and MCP servers

The extension mechanism is what makes the framework extensible without becoming a framework. A Sorcar Extension Agent is documented in the server README as the authoring guide, and skills, MCP servers and customisation have their own section. The skills and MCP surface is the interesting part for a long horizon task, because both give the agent capabilities that are not hard-coded into the loop. Skills are packaged instruction and procedure bundles, and MCP servers bring external tools over a standard protocol rather than requiring a plugin for each service. There is a separate reference for the messaging and service agents, which covers talking to third party agents and sign-in. The features document is described as the complete feature inventory, checked against the source tree, which is a good sign about how it is maintained, and the routing document at the repository root covers model routing separately from the model list.

Installing it and running the container

The quick install is a single command that pipes the install script into a shell:

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

The container path is the one worth reading closely, because its comments explain the requirements rather than assuming them. The image is debian:bookworm-slim and contains the kiss-web daemon and its web app and nothing else, with the entrypoint cloning the repository, running install.sh and starting kiss-web in the foreground on port 8787. The base packages are listed with reasons: bash, git and curl for the clone and the uv and cloudflared downloads, perl for the new-session re-exec and the update lock, ca-certificates for every https download, sudo so the Playwright step can install Chromium's system libraries, and build tools for the few Python packages uv has to compile. uv is pinned to version 0.12.19 and downloaded for the target architecture, with an unsupported architecture case that exits. The container runs as an ordinary user with passwordless sudo, and the comment says that passwordless sudo is for the playwright install-deps call only. The Dockerfile also notes that releases before 0.11.15 carry two file write and deletion advisories, which is worth knowing if you pin an older image.

The benchmark table, and how to read it

The README leads with a Terminal-Bench 2.0 comparison against Pi, Codex CLI and Claude Code, and the honesty about the limits is unusual. The setup is described: the same 30 sampled tasks, the same seven models, three attempts per task, graded by the official verifier, with the system prompt cut to 727 words of coding rules, and the KISS Sorcar column run on 630 attempts on 25 September 2026 with no turn cap and a 50 dollar budget per attempt, while the other three columns are the study's published numbers under a 100-turn cap. The reported means are 75.6% of attempts solved for KISS Sorcar against 70.0% for Pi, 65.7% for Codex CLI and 65.1% for Claude Code. The project then says plainly that thirty tasks is a small sample, that the pooled 95% interval contains all three published means, and that only Pi was rerun, on one model. The paired rerun on the sampled tasks gives 80.0% against 68.9% for Pi, and on the 57 tasks the study did not sample, 82.5% against 71.9%. Reading the cost column alongside the success column is the more useful exercise, since the mean cost per attempt is 1.03 dollars against 0.51, 0.55 and 0.77.

Editorial conclusion

Adopt KISS Sorcar if you want an agent runtime you can inspect and script, where your prompts go to the provider you choose and never through someone else's server, and where long horizon tasks are handled with skills and extension agents rather than a large pipeline. Do not adopt it as a hosted product, since the whole point is the local daemon, and be cautious about the benchmark claims in the README, which are the project's own numbers with a small task sample. Verify first that you can run Python 3.13, that the model provider you want is on the supported list, and that the extension agent and MCP surfaces fit the way you intend to extend the runtime.

Frequently asked questions

Official sources

1. Issues
2. ksenxx/kiss_ai on GitHub
3. README
4. Releases