A multi-agent coding assistant that runs on your machine.

Saleha is a local-first, multi-agent AI coding assistant in Python. It talks to local models through Ollama (or a cloud provider, if you configure one) and ships a CLI, an interactive TUI, and a REST/SSE server. This page describes what actually works today — speculative features live in ROADMAP.md.

$ git clone https://github.com/MDaftab76678-1945/Saleha.git $ cd Saleha && pip install -e . $ ollama run qwen2.5-coder:7b $ saleha run "add input validation to the login handler"
Local
runs on Ollama, no API keys
CLI
plus TUI and REST/SSE server; saleha --help lists every command
Tests
run pytest saleha/tests/ for the current count
Agents
named personas in saleha/skills/agent_*.md
Python
3.12 or newer, all-local runtime
Free
no monthly cost — no API keys

What's actually here

Every item maps to real code and real tests. Paths are given so you can check them yourself.

Agentic coding loop

Plans a task, edits files, runs the test command, and iterates on failures — a real ReAct-style loop, not a single prompt.

saleha/core/loop/agentic_loop.py · saleha run

Multi-agent roles

Planner, Coder, Tester, Debugger agents, orchestrated for multi-step or multi-role tasks.

saleha/agents/ · saleha team

AST-aware indexing & patching

Symbol scanning and unified-diff patch generation — edits parse-checked, not string-spliced.

saleha/core/graph/codebase_indexer.py · saleha scan

Sandboxed execution

Generated or untrusted code runs in a subprocess or Docker container with resource limits and an audit log.

saleha/core/harness/code_executor.py · saleha exec

Static security scanning

AST-based SAST for shell=True, bare except, hardcoded secrets, SQL string formatting, and more.

saleha/core/verification/security_scanner.py · saleha sast

Retrieval & memory

A persistent solution-memory store, a lightweight RAG / graph layer, and fast local code search.

saleha/core/memory/memory_store.py · rag/graph_rag.py

Model routing

Routes requests across configured local (Ollama) and remote backends, with a runtime-probing smart router.

saleha/core/platform/model_provider.py · smart_router.py

Project scaffolder

saleha new fastapi|express|go <name> copies a starter service from a template and verifies it builds — deterministic, no model call.

saleha/core/project/project_scaffolder.py

Souls persona system

Ten JSON-configured personas (temperature, allowed tools) plus a prompt bundle. A real prompt layer — not a claim about model cognition.

souls/ · saleha/core/cognitive/soul_engine.py
architectartisanauditor sagesentinelsovereign speedrunnersrealchemist minimalist

How a task runs

saleha run "<goal>" is a plan → act → observe cycle. Each iteration edits files, runs the project's own test command, and feeds failures back in — it does not stop at "looks done".

Planner→ Coder (AST patch)→ Run tests in sandbox→ pass? ↩ no → Debugger → Reflexion → Verify (SAST + real output)→ Report

Two rules the loop enforces, learned from this project's own audit history: a step that cannot run says so (no component returns a reassuring default it did not earn), and the verifier is real (“tests passed” comes from executing the code, not a hardcoded flag).

The one measured number

Twelve real programming tasks, each with a test suite verified to fail on wrong code first. Two local models, run end-to-end through the agent. This is not SWE-bench and not a leaderboard — it is a local measurement on one machine.

modelpasstime
deepseek-coder:6.7b11 / 12368s
qwen2.5-coder:3b10 / 12115s

Both models missed the same task (an LRU cache — the one problem that needs state held across calls). The 3B model is ~3× faster for one fewer task solved; for a tool meant to run locally all day, that trade favours the smaller model. An earlier version of this measurement was itself wrong — the harness was executing the model's own test code and mis-scoring two passes as failures. That was found and fixed; the number above is post-fix. Script: scripts/measure_real_pass_rate.py.

What is scaffolding, not a finished feature

Earlier copy for this project claimed more than the code did. Being precise about the gaps is the point — a contributor can build on honest scaffolding; they cannot build on a fabricated result.

Named but not what the name implies

  • swarm_consensus.py is a three-phase (propose/prepare/commit) voting protocol among agent roles inside one process. It does not run across machines or tolerate partitions — read it as "structured agent voting," not distributed consensus.
  • formal_smt_verifier.py calls Z3 for real (division and index-bounds proofs). formal_verifier.py only generates Lean4-shaped text as a template and never invokes Lean — scaffolding for a feature that is not implemented.
  • hyperbolic_engine.py is real 16-dimensional Poincaré-ball vector math used as a deterministic task-routing heuristic — not emergent swarm cognition.
  • design-vision infers a layout family and calls the model for JSX/CSS; with no model reachable it returns a labelled template. It does not parse images or Figma files.

Why this page reads the way it does

Much of this project's recent history is an audit: finding places where a component claimed work it had not done — a hardcoded "tests passed", a benchmark scoreboard with invented numbers, an orchestrator that reported success without calling a model — and replacing the fabricated half with something measured. Every pass of that is recorded in NOTEBOOK_IMPORT.md, each finding paired with the probe that proved it. A tool that cannot report what it actually did cannot be trusted or improved; that is the whole reason for the work.