Python products

Build, run, and manage agent platforms. Introduction Agno is a framework and runtime for agent platforms. Build agents, run them as a service, manage your platform using a web UI. Build your agent platform using the Agno SDK. Run your agent platform using the AgentOS runtime. Manage everything using the AgentOS UI. Agno allows you to own your agent stack. Maintain control of your data, memory, and security posture (JWT-based RBAC), and turn your agent platform into a learning loop with simulations and usage data. Get started Hand this prompt to your coding agent (Claude Code, Cursor, Codex): Help me set up my agent platform. Clone https://github.com/agno-agi/agentos-railway into a folder called agent-platform, cd in, read the README, and follow the get started guide. Your coding agent will set up your agent platform and run it locally using Docker, giving you a REST API for serving your agents, a Postgres database for storing your data and traces, an MCP server, and a control plane. Deploying somewhere else? Use the same prompt but point it to a different repo. The starter templates are identical except for the deploy scripts: swap agentos-railway for agentos-docker, agentos-aws, agentos-gcp, agentos-azure, agentos-fly, agentos-render, agentos-modal, or agentos-helm. Prefer to code by hand? Build your first agent in 20 lines of code. Build your own agent platform. Read the docs. Features Production API. 50+ endpoints with SSE and websockets to build a product on top. Storage. Store sessions, memory, knowledge, and traces in your own database. 100+ integrations. Connect to GitHub, Slack, Postgres, and more using pre-built toolkits. Context Providers. Access live data from Slack, Drive, wikis, MCP, and custom sources. Human approval. Pause runs for user confirmation. Block tools that require admin approval. Observability. Monitor with OpenTelemetry tracing, run history, and audit logs. Security. Get JWT-based RBAC and multi-user, multi-tenant isolation out of the box. Interfaces. Expose your agents via Slack, Telegram, WhatsApp, Discord, AG-UI, A2A. Scheduling. Cron-based scheduling and background jobs with no external infrastructure. Deploy anywhere. Run on any cloud platform that runs containers. Docker, Railway, AWS, GCP. Use Agno with your coding agent Two options: Recommended: Add Agno docs as an MCP server. Add docs.agno.com/mcp to your favourite coding agent. Add Agno docs as an indexed source. In Cursor: Settings → Indexing & Docs → Add https://docs.agno.com/llms-full.txt. Also works in VSCode, Windsurf, and similar tools. Read the full guide here. Community X: follow for releases and demos Newsletter: monthly updates on what's shipping Contributing See the contributing guide.

darnlink Never break a Markdown link again. Deterministic, automatic, self-healing links. Markdown is excellent for documentation: it gives you fine-grained version history of how a document evolves, and it is easy for both humans and language models to read and process. It has one flaw — links break the moment you refactor. Move a folder, rename a file, and every link pointing into it dies. darnlink fixes that flaw deterministically and automatically. Run it after (or before) any reorganisation and it heals the links. It is built for trees of many nested Markdown files that get relocated and refactored over time. See it heal a link A robust link carries its target's uuid inline and stays a normal, clickable Markdown link. Move the target and the path goes stale; darnlink . --write finds it by uuid and rewrites only the path: -See the [design doc](docs/design.md)  +See the [design doc](architecture/design.md)  That's the whole idea: the link survived the move on its own. Use it in one line — no install, no clone The package is not on PyPI yet, so run it straight from GitHub with uv: # dry-run: show what it would do (writes nothing) uvx --from git+https://github.com/txemi/darnlink darnlink <folder> # apply uvx --from git+https://github.com/txemi/darnlink darnlink <folder> --write Safe by default: without --write, darnlink only reports what it would change — it never modifies a file. Upgrade plain links so they self-heal in the future (and create a UUID where the target lacks one): uvx --from git+https://github.com/txemi/darnlink darnlink <folder> --robustify --create-frontmatter --write How it works (it's simple) Point it at a documentation folder; it scans the links and does two things: Correct links → protected for the future. It writes a uuid into the target's frontmatter, and adds an invisible HTML comment carrying that same uuid next to the link at the source. The link is now anchored to the file's identity, not to its path. Already-protected links that broke (the target was moved or renamed) → repaired: darnlink finds the target by its uuid and rewrites the path. Every pass protects the correct links and repairs the broken-but-protected ones. It is deterministic (exact UUID match — no heuristics, no network), idempotent, and needs no database and no index file: a repo that uses darnlink links still works with darnlink uninstalled. A robust link stays a normal, clickable Markdown link: See [the design doc](docs/design.md)  Format spec: FORMAT.md . Excluding parts of the tree darnlink walks the whole folder by default. Skip the parts that must not be touched — vendored or submodule content, mirrors, generated output: darnlink <folder> --exclude vendor --exclude mirror --ignore-block autogrid --exclude NAME — skip any directory named NAME (repeatable). --ignore-block NAME — leave links inside generated blocks  …  untouched (repeatable). --no-create-frontmatter-for GLOB — for files a pipeline regenerates (e.g. content.md, a generated INDEX.md): never seed a uuid there (it would be wiped on the next refresh), so the link is left plain. For language models / agents If you are managing a repo of nested Markdown docs and you move folders around, the links break. Before or after a refactor, run the one-liner above on the affected folder — dry-run first, then --write to apply. You do not need to clone darnlink or read its code; the command fetches and runs it for you. Never break a link again — add it to your quality gate darnlink exits non-zero when a robust link is broken, so any gate that runs it will block the breakage before it lands. Pick the one that fits your workflow — near copy-paste: 1. pre-commit (recommended — darnlink ships a hook): # .pre-commit-config.yaml repos: - repo: https://github.com/txemi/darnlink rev: v0.1.1 hooks: - id: darnlink # fail the commit if any robust link is broken # - id: darnlink-repair # …or auto-repair in place instead of failing 2. GitHub Actions (gate every push & PR): # .github/workflows/darnlink.yml name: darnlink on: [push, pull_request] jobs: links: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: astral-sh/setup-uv@v5 - run: uvx --from git+https://github.com/txemi/darnlink darnlink . 3. Plain git hook (no framework): # .git/hooks/pre-commit (chmod +x) #!/usr/bin/env bash uvx --from git+https://github.com/txemi/darnlink darnlink . || { echo "darnlink: broken robust links — re-run with --write to repair"; exit 1 } The three run the same check (darnlink <folder>, dry-run): they report breakage and fail. To have the gate fix links instead of just failing, use --write (Actions/hook) or the darnlink-repair hook id (pre-commit). Prior art & how darnlink differs The idea of surviving refactors by anchoring to an identity isn't new, but the specific combination is a gap: emacs org-id — the closest relative: [[id:UUID]] links survive moving files. But it's org, not Markdown, the link is only the id, and resolution needs a central database (~/.org-id-locations) tied to emacs. Obsidian / VS Code / Front Matter CMS — update links on rename, but path-based and only inside the app: a git mv or any external script breaks them. They depend on the editor. markdown-link-check / dead-link-checker — only detect broken links; they neither repair nor use a uuid. Docusaurus / MkDocs / 11ty — map ids→urls at site build time; not a repo-maintenance tool. darnlink's niche: Markdown-native, no database, editor-agnostic. The link carries the human path and the uuid inline — [text](path)  — so it stays clickable and readable even when "broken", and is self-describing (uuid by the link and in the target's frontmatter). And it both repairs moved paths and upgrades plain links to robust ones. "What org-id does for emacs, but for plain Markdown and with no database." Status Early (v0.1.0). Built spec-first with GitHub Spec Kit — see .specify/ and specs/.

Tinker Cookbook We provide two libraries for the broader community to customize their language models: tinker and tinker-cookbook. tinker is a training SDK for researchers and developers to fine-tune language models. You send API requests to us and we handle the complexities of distributed training. tinker-cookbook includes realistic examples of fine-tuning language models. It builds on the Tinker API and provides common abstractions to fine-tune language models. Installation Sign up for Tinker here. Once you have access, create an API key from the console and export it as environment variable TINKER_API_KEY. Install tinker-cookbook (includes the tinker SDK as a dependency): # Latest stable release from PyPI uv pip install tinker-cookbook # Or install the nightly build uv pip install 'tinker-cookbook @ git+https://github.com/thinking-machines-lab/tinker-cookbook.git@nightly' Using Inkling Inkling is Thinking Machines Lab's model tailored for Tinker. It is a general-purpose model that can code, reason, call tools, and process image and audio inputs. Tinker Cookbook supports sampling and post-training Inkling through the standalone tml-renderers library; install it with the inkling extra, which also pulls in the required torch>=2.10: uv pip install 'tinker-cookbook[inkling]' Pass model_name="thinkingmachines/Inkling" anywhere the cookbook accepts a model name. The appropriate renderer and tokenizer are selected automatically. Inkling supports controllable reasoning effort and multimodal audio and image inputs. See the Inkling documentation for setup and usage details. Tinker Here we introduce a few Tinker primitives — the basic components to fine-tune LLMs (see the quickstart guide for more details): import tinker service_client = tinker.ServiceClient() training_client = service_client.create_lora_training_client( base_model="meta-llama/Llama-3.2-1B", rank=32, ) training_client.forward_backward(...) training_client.optim_step(...) training_client.save_state(...) training_client.load_state(...) sampling_client = training_client.save_weights_and_get_sampling_client() sampling_client.sample(...) See tinker_cookbook/recipes/sl_loop.py and tinker_cookbook/recipes/rl_loop.py for minimal examples of using these primitives to fine-tune LLMs. Tutorials New to Tinker? The tutorials/ directory contains 20+ progressive marimo notebooks that walk through core concepts — rendering, loss functions, completers, weight management — and advanced topics such as custom RL environments, DPO, RLHF, and weight export. Run any tutorial with marimo edit tutorials/101_hello_tinker.py. See the tutorials README for the full list, or browse rendered versions on the Tinker docs site. To download the weights of any model: rest_client = service_client.create_rest_client() future = rest_client.get_checkpoint_archive_url_from_tinker_path(sampling_client.model_path) with open(f"model-checkpoint.tar.gz", "wb") as f: f.write(future.result()) Tinker Cookbook Besides these primitives, we also offer Tinker Cookbook (a.k.a. this repo), a library of a wide range of abstractions to help you customize training environments. tinker_cookbook/recipes/sl_basic.py and tinker_cookbook/recipes/rl_basic.py contain minimal examples to configure supervised learning and reinforcement learning. We also include more complete examples in the tinker_cookbook/recipes/ folder: Chat SFT: supervised fine-tuning on conversational datasets (e.g., Tulu3). Math RL: reinforcement learning for mathematical reasoning with verifiable rewards. Code RL: RL on competitive programming with sandboxed code execution (DeepCoder replication). Preference learning: DPO and a three-stage RLHF pipeline (SFT, reward model, RL). Distillation: on-policy and off-policy knowledge distillation with single- and multi-teacher configurations. Tool use: RL for retrieval-augmented generation (Search-R1 replication). Multi-agent: multi-agent RL with self-play and cross-play. Audio: SFT and RL for Inkling audio inputs, including speech recognition and speaking-style classification. VLM image classification: supervised training and evaluation for vision-language models. The recipes README covers all available recipes, including Harbor RL, rubric-based grading, VLM classification, and SDFT. Each recipe includes a README.md with implementation details, launch commands, and expected results. Evaluation (experimental) Tinker Cookbook includes a benchmark framework for evaluating trained models: from tinker_cookbook.eval.benchmarks import run_benchmarks, BenchmarkConfig results = await run_benchmarks( ["gsm8k", "mmlu_pro", "ifeval"], sampling_client, renderer, BenchmarkConfig(save_dir="evals/step500"), ) The framework currently supports 12 benchmarks (GSM8K, MATH-500, MMLU-Pro, MMLU-Redux, GPQA, IFEval, MBPP, C-Eval, SuperGPQA, IFBench, AIME 2025, AIME 2026) with verified scores against published results, plus experimental benchmarks such as LiveCodeBench, Terminal Bench, and SWE-bench. Benchmarks can also serve as inline training evaluators via BenchmarkEvaluator. Note: Benchmark scores are sensitive to evaluation configuration — system prompts, max_tokens, temperature, and timeout settings can shift results significantly. We document our exact settings alongside all reported scores. This framework is under active development; feedback and contributions are welcome. See the eval README for verified scores, configuration details, and instructions for adding new benchmarks. Documentation For the full Tinker documentation, visit tinker-docs.thinkingmachines.ai. Utilities Tinker Cookbook also provides reusable building blocks: renderers — bidirectional conversion between token sequences and structured chat messages hyperparam_utils — learning rate and hyperparameter scaling for LoRA training eval — benchmark framework and inline training evaluators (see Evaluation above) Claude Code Skills Tinker Cookbook ships with Claude Code skills that teach Claude how to use the Tinker API. Install them so Claude can help you write training code in any project: /plugin marketplace add thinking-machines-lab/tinker-cookbook Then install the tinker plugin from the Discover tab (/plugin → Discover). Once installed, two skills are available: Command What it does /tinker:research Plan and run post-training experiments — SFT, RL, DPO, distillation, evaluation, hyperparameters, model selection, and more /tinker:debug Diagnose slow training, hangs, output mismatches, renderer issues, and errors Skills also trigger automatically based on context — ask Claude to "set up SFT training" and it will load the right skill without a slash command. Skills update automatically when the repo is updated. Development Setup uv sync --extra dev pre-commit install This installs dev dependencies and registers pre-commit hooks that run ruff formatting and linting on every commit. CI enforces these checks on all pull requests. Contributing This project is built in the spirit of open science and collaborative development. We believe that the best tools emerge through community involvement and shared learning. We welcome PR contributions after our private beta is over. If you have any feedback, please email us at [email protected]. Citation If you use Tinker for your research, please cite it as: Thinking Machines Lab, 2026. Tinker. https://thinkingmachines.ai/tinker/. Or use this BibTeX citation: @misc{tml2026tinker, author = {Thinking Machines Lab}, title = {Tinker}, year = {2026}, url = {https://thinkingmachines.ai/tinker/}, }

Wan2.1 💜 Wan ｜ 🖥️ GitHub | 🤗 Hugging Face | 🤖 ModelScope | 📑 Technical Report | 📑 Blog | 💬 WeChat Group | 📖 Discord Wan: Open and Advanced Large-Scale Video Generative Models In this repository, we present Wan2.1, a comprehensive and open suite of video foundation models that pushes the boundaries of video generation. Wan2.1 offers these key features: 👍 SOTA Performance: Wan2.1 consistently outperforms existing open-source models and state-of-the-art commercial solutions across multiple benchmarks. 👍 Supports Consumer-grade GPUs: The T2V-1.3B model requires only 8.19 GB VRAM, making it compatible with almost all consumer-grade GPUs. It can generate a 5-second 480P video on an RTX 4090 in about 4 minutes (without optimization techniques like quantization). Its performance is even comparable to some closed-source models. 👍 Multiple Tasks: Wan2.1 excels in Text-to-Video, Image-to-Video, Video Editing, Text-to-Image, and Video-to-Audio, advancing the field of video generation. 👍 Visual Text Generation: Wan2.1 is the first video model capable of generating both Chinese and English text, featuring robust text generation that enhances its practical applications. 👍 Powerful Video VAE: Wan-VAE delivers exceptional efficiency and performance, encoding and decoding 1080P videos of any length while preserving temporal information, making it an ideal foundation for video and image generation. Video Demos video_demo_v2.mp4 🔥 Latest News!! May 14, 2025: 👋 We introduce Wan2.1 VACE, an all-in-one model for video creation and editing, along with its inference code, weights, and technical report! Apr 17, 2025: 👋 We introduce Wan2.1 FLF2V with its inference code and weights! Mar 21, 2025: 👋 We are excited to announce the release of the Wan2.1 technical report. We welcome discussions and feedback! Mar 3, 2025: 👋 Wan2.1's T2V and I2V have been integrated into Diffusers (T2V | I2V). Feel free to give it a try! Feb 27, 2025: 👋 Wan2.1 has been integrated into ComfyUI. Enjoy! Feb 25, 2025: 👋 We've released the inference code and weights of Wan2.1. Community Works If your work has improved Wan2.1 and you would like more people to see it, please inform us. Helios, a breakthrough video generation model base on Wan2.1 that achieves minute-scale, high-quality video synthesis at 19.5 FPS on a single H100 GPU (about 10 FPS on a single Ascend NPU) —without relying on conventional long video anti-drifting strategies or standard video acceleration techniques. Visit their webpage for more details. Video-As-Prompt, the first unified semantic-controlled video generation model based on Wan2.1-14B-I2V with a Mixture-of-Transformers architecture and in-context controls (e.g., concept, style, motion, camera). Refer to the project page for more examples. LightX2V, a lightweight and efficient video generation framework that integrates Wan2.1 and Wan2.2, supports multiple engineering acceleration techniques for fast inference, which can run on RTX 5090 and RTX 4060 (8GB VRAM). DriVerse, an autonomous driving world model based on Wan2.1-14B-I2V, generates future driving videos conditioned on any scene frame and given trajectory. Refer to the project page for more examples. Training-Free-WAN-Editing, built on Wan2.1-T2V-1.3B, allows training-free video editing with image-based training-free methods, such as FlowEdit and FlowAlign. Wan-Move, accepted to NeurIPS 2025, a framework that brings Wan2.1-I2V-14B to SOTA fine-grained, point-level motion control! Refer to their project page for more information. EchoShot, a native multi-shot portrait video generation model based on Wan2.1-T2V-1.3B, allows generation of multiple video clips featuring the same character as well as highly flexible content controllability. Refer to their project page for more information. AniCrafter, a human-centric animation model based on Wan2.1-14B-I2V, controls the Video Diffusion Models with 3DGS Avatars to insert and animate anyone into any scene following given motion sequences. Refer to the project page for more examples. HyperMotion, a human image animation framework based on Wan2.1, addresses the challenge of generating complex human body motions in pose-guided animation. Refer to their website for more examples. MagicTryOn, a video virtual try-on framework built upon Wan2.1-14B-I2V, addresses the limitations of existing models in expressing garment details and maintaining dynamic stability during human motion. Refer to their website for more examples. ATI, built on Wan2.1-I2V-14B, is a trajectory-based motion-control framework that unifies object, local, and camera movements in video generation. Refer to their website for more examples. Phantom has developed a unified video generation framework for single and multi-subject references based on both Wan2.1-T2V-1.3B and Wan2.1-T2V-14B. Please refer to their examples. UniAnimate-DiT, based on Wan2.1-14B-I2V, has trained a Human image animation model and has open-sourced the inference and training code. Feel free to enjoy it! CFG-Zero enhances Wan2.1 (covering both T2V and I2V models) from the perspective of CFG. TeaCache now supports Wan2.1 acceleration, capable of increasing speed by approximately 2x. Feel free to give it a try! DiffSynth-Studio provides more support for Wan2.1, including video-to-video, FP8 quantization, VRAM optimization, LoRA training, and more. Please refer to their examples. 📑 Todo List Wan2.1 Text-to-Video Multi-GPU Inference code of the 14B and 1.3B models Checkpoints of the 14B and 1.3B models Gradio demo ComfyUI integration Diffusers integration Diffusers + Multi-GPU Inference Wan2.1 Image-to-Video Multi-GPU Inference code of the 14B model Checkpoints of the 14B model Gradio demo ComfyUI integration Diffusers integration Diffusers + Multi-GPU Inference Wan2.1 First-Last-Frame-to-Video Multi-GPU Inference code of the 14B model Checkpoints of the 14B model Gradio demo ComfyUI integration Diffusers integration Diffusers + Multi-GPU Inference Wan2.1 VACE Multi-GPU Inference code of the 14B and 1.3B models Checkpoints of the 14B and 1.3B models Gradio demo ComfyUI integration Diffusers integration Diffusers + Multi-GPU Inference Quickstart Installation Clone the repo: git clone https://github.com/Wan-Video/Wan2.1.git cd Wan2.1 Install dependencies: # Ensure torch >= 2.4.0 pip install -r requirements.txt Model Download Models Download Link Notes T2V-14B 🤗 Huggingface 🤖 ModelScope Supports both 480P and 720P I2V-14B-720P 🤗 Huggingface 🤖 ModelScope Supports 720P I2V-14B-480P 🤗 Huggingface 🤖 ModelScope Supports 480P T2V-1.3B 🤗 Huggingface 🤖 ModelScope Supports 480P FLF2V-14B 🤗 Huggingface 🤖 ModelScope Supports 720P VACE-1.3B 🤗 Huggingface 🤖 ModelScope Supports 480P VACE-14B 🤗 Huggingface 🤖 ModelScope Supports both 480P and 720P 💡Note: The 1.3B model is capable of generating videos at 720P resolution. However, due to limited training at this resolution, the results are generally less stable compared to 480P. For optimal performance, we recommend using 480P resolution. For the first-last frame to video generation, we train our model primarily on Chinese text-video pairs. Therefore, we recommend using Chinese prompt to achieve better results. Download models using huggingface-cli: pip install "huggingface_hub[cli]" huggingface-cli download Wan-AI/Wan2.1-T2V-14B --local-dir ./Wan2.1-T2V-14B Download models using modelscope-cli: pip install modelscope modelscope download Wan-AI/Wan2.1-T2V-14B --local_dir ./Wan2.1-T2V-14B Run Text-to-Video Generation This repository supports two Text-to-Video models (1.3B and 14B) and two resolutions (480P and 720P). The parameters and configurations for these models are as follows: Task Resolution Model 480P 720P t2v-14B ✔️ ✔️ Wan2.1-T2V-14B t2v-1.3B ✔️ ❌ Wan2.1-T2V-1.3B (1) Without Prompt Extension To facilitate implementation, we will start with a basic version of the inference process that skips the prompt extension step. Single-GPU inference python generate.py --task t2v-14B --size 1280*720 --ckpt_dir ./Wan2.1-T2V-14B --prompt "Two anthropomorphic cats in comfy boxing gear and bright gloves fight intensely on a spotlighted stage." If you encounter OOM (Out-of-Memory) issues, you can use the --offload_model True and --t5_cpu options to reduce GPU memory usage. For example, on an RTX 4090 GPU:

CIQS: Causal Iteration Quantum Solution The 'million-qubit compiler' and The '1:5 QEC' by arcadialab.fr Description CIQA is an analytic quantum error correction encoder. Each logical qubit is encoded into 5 physical data qubits using a strict [[5,1,3]] perfect quantum code, with 2 ancilla qudits per logical block for syndrome extraction. Encoding angles, syndrome thresholds, and correction operators are produced by closed-form derivation, with no free parameters. CIQS (CIQM mapper/router + CIQO optimizer) is a fully analytic compilation pipeline. Every placement, routing, and optimization decision is determined by an exact criterion derived from the circuit structure. No heuristics, no stochastic components, no tunable parameters. The same input produces the same output on every run. Hardware-agnostic, supports qudits of any dimension natively. CIQA encodes first. CIQS receives the encoded circuit, isolates the encoding prefix automatically, routes across the target topology, and applies optimization exclusively to the operational gates outside the protected prefix. A single pipeline from logical circuit to hardware-ready output. Both tools are compiled binaries, free for non-commercial use. Contact for licensing options. Files In order of execution: File Role CIQA.pyd QEC encoder: 1 logical qubit to 5 physical + 2 ancilla CIQS_pipeline.cp312-win_amd64.pyd Pipeline entry point: runs CIQM and CIQO in sequence CIQM.cp312-win_amd64.pyd Mapper and router: qubit placement and SWAP insertion CIQO_v2.cp312-win_amd64.pyd Optimizer: gate removal on operational gates only --- --- CIQS_adapters.cp312-win_amd64.pyd Format adapters: Qiskit, OpenQASM 3, generic gate list CIQA_integration_guide.pdf Standalone adapter functions for external pipeline integration Requirements Python 3.9+ Qiskit >= 1.0 (for IBM hardware runs and the Qiskit adapter) qiskit-ibm-runtime (for live QPU submission) pip install numpy scipy Place all .pyd modules in your working directory or add them to your Python path. Usage With CIQA (standard path) from CIQA import CIQA from CIQS_pipeline import CIQS_pipeline, CIFPipelineResult ciqa = CIQA(n=5, d=2) encoded = ciqa.encode(logical_circuit) result = CIQS_pipeline(encoded, CouplingMap.heavy_hex(127)) Without CIQA Everything goes through CIQS_pipeline. No need to call CIQM or CIQO directly. CIQS_pipeline accepts circuits directly without QEC encoding. coupling_map is required for all input types except Perceval. from CIQS_pipeline import CIQS_pipeline, CIFPipelineResult # Qiskit result = CIQS_pipeline(qiskit_circuit, CouplingMap.line(1000)) # OpenQASM 2.0 with open("circuit.qasm") as f: qasm_str = f.read() result = CIQS_pipeline(qasm_str, CouplingMap.heavy_hex(127)) # Perceval (coupling map auto-derived from processor topology) result = CIQS_pipeline(perceval_processor) # Blackbird / Strawberry Fields result = CIQS_pipeline(blackbird_program, CouplingMap.line(100)) Topologies from CIQM import CouplingMap CouplingMap.line(n) CouplingMap.heavy_hex(n) CouplingMap.grid(rows, cols) CouplingMap.from_edges(edge_list) Results print(result.swap_count) # SWAPs inserted by router print(result.gates_removed) # gates removed by optimizer print(result.placement.valid) # True = all qubit pairs placed natively # Export qc = result.to_qiskit() qasm = result.to_openqasm() processor = result.to_perceval() For a complete end-to-end example including QPU submission, see page_curve_ibm_experiment_v5.py. External pipeline integration ciqa.encode() returns a dict with four keys: Key Type Description gates list[dict] Ordered list of physical gate operations n_logical int Number of logical qubits in the input circuit n_physical int Total physical qubits after encoding (n_logical x 5 + ancillae) report EncodingReport Encoding parameters for auditing Three gate types are produced: Ry (single-qubit rotation), CX (controlled-X), and M (measurement). Measurement gates carry _ciqa_physical: True to identify CIQA-inserted ancilla operations. Any pipeline supporting single-qubit rotations and two-qubit controlled gates can accept CIQA output directly. Adapters for Qiskit, OpenQASM 3, and a generic gate list format are in CIQA_integration_guide.pdf. Coupling map sizing at n=5: Logical qubits Data qubits (x5) Ancillae (x2) Minimum total 1 5 2 7 10 50 20 70 100 500 200 700 1,000 5,000 2,000 7,000 The downstream router may require additional qubits for SWAP insertion depending on hardware topology. Hard constraint: CIQA encoding angles are exact fixed values. Gate fusion or small-angle removal applied to the encoding prefix breaks the error correction guarantee. Pass the encoded circuit to the router without a pre-routing simplification pass. Apply gate optimization only after routing and only to gates outside the encoding prefix. When using CIQS, this is handled automatically. Performance CIQS — IBM Benchpress The full IBM Benchpress suite (892 tests, circuits up to 930 qubits) was run with CIQS on a Ryzen 5 / 32GB machine, against Qiskit's published results on a Ryzen 9 / 128GB machine. SDK Passed / Attempted Failed Wall time CIQS 892 / 892 0 1h 15m Qiskit 892 / 892 0 17h 15m QTS 877 / 892 15 >= 35h 18m Tket 814 / 892 78 >= 33h 11m BQSKit 716 / 892 176 >= 64h 08m Per-test geometric mean: CIQS at 0.051s, Qiskit at 0.310s. In the 200-433 qubit range, CIQS is 14.7x faster than Qiskit. Scaling (Heisenberg model, same hardware): Qubits Topology 2Q Gates SWAPs Gates removed Runtime 100,000 linear 499,995 0 299,997 9.6s 100,000 heavy-hex 739,658 239,663 299,997 32.5s 1,000,000 linear 4,999,995 0 2,999,997 93.4s 1,000,000 heavy-hex 7,513,506 2,513,511 2,999,997 848.8s On the linear topology, runtime scales proportionally with qubit count across three orders of magnitude. CIQA - hardware validation IBM ibm_fez (Heron r2, 156 qubits), April 3, 2026. Three independent runs, 8,192 shots each, pinned layout, live calibration data. Circuit Mean fidelity SD Bare qubit, no error 0.994 0.002 Bare qubit, X error, no correction 0.015 0.002 CIQA encoded, no error 0.818 0.011 CIQA, X error, corrected (q0 and q2) 0.847 0.008 Mean improvement over unprotected +0.832 0.008 Hayden-Preskill - combined pipeline validation The Hayden-Preskill circuit models black hole evaporation as a quantum system across multiple entangled registers over several steps. No experiment ever successfully ran this circuit, until now. Paired with CIQA, CIQS compiled and routed the circuit onto IBM Heron r2, a heavy-hex topology that never was a design target for it. The routing required 987 SWAP insertions and 120 gate removals across 300 circuits per run. The experiment ran across three IBM backends at two system sizes, with up to 307,200 shots per job. The mutual information I₂(D:R) remained within ±0.004 of zero across all runs and all time steps, indicating no measurable noise introduced by the compilation. CIQA prevents the decoherence to happen early on, allowing the very first observation of the black hole evaporation past the Page time. The results have been reproduced a dozen times. Concatenation Each physical qudit of a CIQA block can itself be encoded in another CIQA block, reducing the logical error rate at the cost of additional overhead. Level Overhead p_L at p = 0.1% 1 1:5 ~10^-5 2 1:25 ~10^-9 3 1:125 ~10^-17 Level 3 is sufficient to run Shor's algorithm. The surface code requires approximately 1:1,000 overhead to reach equivalent logical error rates at the same physical error rate. Published work CIQS, architecture and benchmarks: 10.5281/zenodo.19056796 CIQS vs Qiskit, full Benchpress comparison: 10.5281/zenodo.19896662 CIQA, architecture and benchmarks: 10.5281/zenodo.19405503 Hayden-Preskill black hole circuit, full dataset: 10.5281/zenodo.20120426 All benchmarks data, runners, QPU side data, are attached alongside their respective paper Contact If something is missing, not clear, or not working as described, please let us know. For every enquiries including licensing options: [email protected]

We're launching a product around self-configuring agents soon. Sign up here.We're hiring engineers. If this work interests you, reach out to [email protected] with your Github link. AutoAgent Like autoresearch but for agent engineering. Give an AI agent a task, let it build and iterate on an agent harness autonomously overnight. It modifies the system prompt, tools, agent configuration, and orchestration, runs the benchmark, checks the score, keeps or discards the change, and repeats. The core idea is the same: you're not touching the harness Python files like you normally would as an engineer. Instead, you program program.md, the Markdown file that provides context to the meta-agent and defines the agent-engineering loop. How it works The repo has a few files and directories that matter: agent.py -- the entire harness under test in a single file. It contains config, tool definitions, agent registry, routing/orchestration, and the Harbor adapter boundary. The adapter section is explicitly marked as fixed; the rest is the primary edit surface for the meta-agent. program.md -- instructions for the meta-agent + the directive (what kind of agent to build). This file is edited by the human. tasks/ -- evaluation tasks in harbor format. In a clean baseline branch, benchmark payloads may be omitted and added in benchmark-specific branches. .agent/ -- optional workspace artifacts for reusable instructions, notes, prompts, or skills. The metric is total score produced by the benchmark's task test suites. The meta-agent hill-climbs on this score. Quick start Requirements: Docker, Python 3.10+, uv, and whatever model-provider credentials your current agent.py harness requires. # 1. Install uv (if you don't have it) curl -LsSf https://astral.sh/uv/install.sh | sh # 2. Install dependencies uv sync # 3. Set up the environment variables required by your current agent/runtime # Example: cat > .env << 'EOF' OPENAI_API_KEY=... EOF # 4. Build base image docker build -f Dockerfile.base -t autoagent-base . # 5. Add tasks to tasks/ (see Task format section below) # 6. Run a single benchmark task rm -rf jobs; mkdir -p jobs && uv run harbor run -p tasks/ --task-name "<task-name>" -l 1 -n 1 --agent-import-path agent:AutoAgent -o jobs --job-name latest > run.log 2>&1 # 7. Run all tasks in parallel (-n = concurrency, default 4) rm -rf jobs; mkdir -p jobs && uv run harbor run -p tasks/ -n 100 --agent-import-path agent:AutoAgent -o jobs --job-name latest > run.log 2>&1 Running the meta-agent Point your coding agent at the repo and prompt: Read program.md and let's kick off a new experiment! The meta-agent will read the directive, inspect the current harness, run the benchmark, diagnose failures, modify agent.py, and iterate. Project structure agent.py -- single-file harness under test editable harness section -- prompt, registries, tools, routing fixed adapter section -- Harbor integration + trajectory serialization program.md -- meta-agent instructions + directive Dockerfile.base -- base image .agent/ -- optional agent workspace artifacts tasks/ -- benchmark tasks, typically added in benchmark-specific branches jobs/ -- Harbor job outputs results.tsv -- experiment log (created by meta-agent, gitignored) run.log -- latest run output Task format The repo ships without tasks. Add your own to tasks/ following Harbor's task format: tasks/my-task/ task.toml -- config (timeouts, metadata) instruction.md -- prompt sent to the agent tests/ test.sh -- entry point, writes /logs/reward.txt test.py -- verification (deterministic or LLM-as-judge) environment/ Dockerfile -- task container (FROM autoagent-base) files/ -- reference files mounted into container Tests write a score (0.0-1.0) to the verifier logs. The meta-agent hill-climbs on this. See the Harbor docs for full details on writing and porting tasks. Design choices Program the meta-agent, not the harness directly. The human steers the loop through program.md, while the meta-agent edits agent.py. Single-file, registry-driven harness. The implementation lives in one file for simplicity, but agent and tool registration stay structured so the harness can still evolve cleanly. Docker isolation. The agent runs in a container. It can't damage the host. Score-driven. Every experiment produces a numeric score. Keep if better, discard if not. Same loop as autoresearch. Harbor-compatible tasks. Tasks use the same format as harbor benchmarks, so the same harness can be evaluated on different datasets. Cleanup Docker images and containers accumulate across runs. Clean up regularly: # Harbor's cached task images + task cache uv run harbor cache clean -f # Full Docker nuke (all unused images, build cache, etc.) docker system prune -a -f # Lighter: just dead containers docker container prune -f If Docker becomes unresponsive (for example after many concurrent runs), restart Docker Desktop: killall Docker && open -a Docker Improving performance with skills You can equip the agent with Agent Skills for Context Engineering and context7 skills to improve performance.

Give every recurring job its own agentic app. Quickstart · Why an app · Inside a pod · Surfaces · Coding agents · Docs Website → lemma.work A Telegram bot that tracks your expenses. A research room where agents gather sources, compare findings, and challenge each other's claims. A support desk where agents triage requests in the background and people step in for decisions. Each job carries its own state, actions, and ways for people to see the work. Lemma gives each job its own app: a place for people to see and direct the work, and for agents to remember, act, and keep it moving. Open source. Runs locally. Use Claude Code or Codex through your existing subscription, Lemma-managed models, or any OpenAI-compatible or Anthropic-compatible provider. Run it on your laptop, your server, or Lemma Cloud. Build and operate Lemma apps with the coding agent you already use. Claude Code Codex OpenCode Cursor Antigravity The same agent authors the app, data, agents, workflows, and permissions — then verifies the result. Quickstart Install Lemma Desktop Download the signed online package from the latest release for macOS 14+ on Apple silicon or Windows 11 23H2+ on x86-64. On macOS, drag Lemma to Applications before opening it; on Windows, run the signed setup executable. The small installer downloads digest-verified runtime components on first use; public offline packages are not offered in this release. Choose Local, select Install local services, and create the local owner inside the app. Lemma owns its lightweight VZ/WSL2 runtime; the normal path does not install or require Docker Desktop, Podman, Homebrew, Python, Node.js, Ubuntu, or public DNS. Configure the required AI profile and optional integrations in Local Control Center. On first installation Lemma chooses a private high-port pair and keeps it stable across restarts. Local Control Center → Diagnostics shows the exact workspace, API, built-app, and OAuth callback URLs. The CLI discovers the same endpoints from Desktop automatically. See the complete local installation and operations guide. Install the CLI, point it at the local stack, and give your coding agent Lemma's skills: uv tool install lemma-terminal # The optional stack-control bootstrap registers the `local` server: curl -fsSL https://raw.githubusercontent.com/lemma-work/lemma-platform/main/install.sh | bash -s -- --cli-only lemma servers select local lemma auth login lemma skills install lemma pod create my-team --with-starter Open the generated my-team/ directory in Claude Code, Codex, OpenCode, Cursor, or Antigravity and ask it to build the app you want. Antigravity users should first run lemma skills install --target agents --scope project from inside that directory. The coding agent authors and verifies the pod through the same CLI. To let the pod dispatch runs through your local Claude Code, Codex, OpenCode, Cursor, or Antigravity login, start the daemon: lemma daemon start --background lemma daemon status Configure a provider for server-run agents and conversations Use Local Control Center → AI Providers, or apply the same transactional configuration through lemma-stack: lemma-stack config set ai.protocol=openai_compat ai.base_url=http://127.0.0.1:11434/v1 ai.default_model=qwen3 Secrets are stored in Keychain or Credential Manager, model access is validated before activation, and a failed change rolls back. See configuration for hosted providers, integrations, and agent surfaces. Use Lemma Cloud Sign up at lemma.work when you want the same stack hosted and reachable by teammates and surfaces: uv tool install lemma-terminal lemma servers select lemma-cloud lemma auth login lemma skills install lemma pod create my-team --with-starter # scaffolds a working starter (table + agent) and imports it lemma chat "what can you do in this pod?" Why an app, not another chat The shape of an agentic app follows the job. Picture three of them: Personal expenses. Send a receipt or voice note through Telegram. An agent extracts the purchase, asks when something is unclear, and keeps the ledger current. The app is where you review transactions, correct categories, and see where the money went. Research. Agents gather sources, extract claims, and challenge weak evidence in the background. The app holds the sources, claims, open questions, and evolving brief. You inspect the work, redirect the investigation, and shape the result. Customer support. Agents read new requests, gather the relevant context, draft replies, and flag decisions. The app brings together the conversation, proposed response, customer history, and the controls to edit, approve, or direct what happens next. Each app gives its job a purpose-built interface, shared state, and agents that keep working between visits. People work with what the agents produce and direct what happens next; the agents carry that direction back into the work. Work compounds inside the app Completed work leaves reusable structure behind. A triaged email becomes a record. You save repeated corrections as standing instructions, promote repeated sequences to workflows, and encode recurring judgment in agent roles — with approval gates wherever people stay responsible. A pod exports as portable files: tables, agents, workflows, permissions, apps, and the rest of the system. The same coding agent that built it can export, change, verify, and re-import it. Remix it, share it, or start from one somebody else built: lemma pod export ./support-desk # the whole system, as files lemma pod import ./support-desk # ship it back — or to another machine Inside a pod Everything in Lemma lives in a pod — a self-contained environment for one person, team, or process. A pod holds shared state, agents, workflows, permissions, and one or more apps. Primitive What it gives you Tables Typed, queryable business data with row-level security. Leads, tickets, tasks, approvals — readable by agents, owned by the pod. Files Markdown memory for preferences, playbooks, voice guides, and notes. Full-text searchable, permission-scoped, read and written by agents alongside the tables. Agents LLM workers with a role, tool grants, and access scoped to specific tables, files, and connectors. Workflows Graphs that mix agents, functions, decisions, loops, waits, and human approval steps. Triggered by schedules, webhooks, table events, chat, or the API. Functions Predictable validators, transitions, and actions alongside agent judgment. Permissions Roles for people and agents: pod-level roles, table grants, resource visibility, delegation tokens. Approvals Workflow steps that pause, route to a specific person, and resume on their decision — in the app or in Slack. Apps The UI where people see the job, direct work, and handle decisions — deployed at a URL and built on the same pod APIs as the agents. Surfaces Slack, Microsoft Teams, Gmail, Outlook, Telegram, and WhatsApp — wired to pod agents with identity resolution and conversation linking. One app, many surfaces A teammate approves a refund in Slack. A field update arrives as a WhatsApp voice note and lands as a structured record. An agent drafts a customer reply in Gmail and waits for a human before sending. The conversation is the surface — underneath, all of it reads and writes the same tables, runs through the same workflows, and respects the same permissions. Supported today: Slack, Microsoft Teams, Gmail, Outlook, Telegram, WhatsApp — each with webhook ingress, identity resolution, and agent-initiated actions. Telegram long-polling and Slack Socket Mode connect local setups directly. Surfaces Slack Teams Gmail Outlook Telegram WhatsApp Wherever your team already works, the pod shows up. A pod also works for one person. One human and a few agents — with WhatsApp as the front door and tables as the memory — make a personal assistant that keeps state, asks before it acts, and picks up tomorrow where it left off today. Build and operate with the coding agent you already have A pod can be exported as plain files, so building one is a job a coding agent is already good at: describe the system, let the agent author the bundle, and import it. The agent that builds it also tests it by creating records, running workflows, and chatting with the agents it defined. Building and operating use the same CLI. Install Lemma's skills into the agent you already use — Claude Code, Codex, OpenCode, or Cursor: lemma skills install # auto-detects Claude Code / Codex / OpenCode / Cursor lemma skills install --target claude --all-skills # or pick a target and include extras lemma skills install --target agents --scope project # Antigravity, from inside the pod directory Skills ship in lemma-skills/. Restart your coding agent after installing, then ask it to build a pod: lemma pod init my-team # scaffold a starter bundle to edit (or: lemma agent|table|workflow init …) lemma pod import ./the-pod-your-agent-wrote lemma apps deploy my-app ./index.html # deploy a no-build HTML app (or a Vite project dir) Or run your agent inside Lemma. lemma daemon start connects your local Claude Code, Codex, OpenCode, Cursor, or Antigravity to the pod: it picks up tasks from a shared queue, streams its work back through the pod, and pauses at approval gates before protected actions. Two agents working the same pod share persistent state, a task queue, and run history. lemma daemon start --background # your local agent serves pod-assigned runs lemma daemon status # pid, running state, log path lemma daemon stop Any agent operates a pod directly through the CLI: lemma table list # inspect the data model lemma record update tasks rec_8f2k --data '{"status": "done"}' lemma agent run qualifier --input '{"lead_id": "..."}' lemma workflow start follow-up # pauses at human approval steps lemma chat "what's left in the queue?" If you're reading this inside a coding agent session: that agent can work a pod right now. Python and TypeScript SDKs (with 25+ React hooks) live in lemma-python/ and lemma-typescript/. Generating your frontend elsewhere? Back it with a pod — the TypeScript SDK gives any app tables, agents, workflows, and permissions out of the box. Open, local, and portable Your machine. The full stack runs self-contained on your laptop. You choose which external services receive data. Our cloud, when you want it. lemma.work runs the same open-source stack as a hosted option for pods that need to reach teammates and surfaces. Your subscription, managed models, or your keys. Pod-assigned runs use your local Claude Code or Codex login through the daemon. Server-run agents use Lemma-managed models or an Anthropic-compatible or OpenAI-compatible key or endpoint — a cloud provider, a self-hosted gateway, or a local model. Runtime profiles are per pod, so different agents can use different models. Your code. Core is AGPLv3; SDKs, CLI, and tools are Apache-2.0. Repo layout Path Package License lemma-backend/ FastAPI backend, migrations, and infra Docker Compose AGPLv3 lemma-frontend/ Next.js frontend AGPLv3 agentbox/ Sandboxed agent workspace manager and runtime image Apache-2.0 agentbox-client/ Python client for the AgentBox workspace API Apache-2.0 lemma-stack/ lemma-stack — installer and manager for a self-contained local stack Apache-2.0 desktop/ Tauri macOS desktop app (thin shell around the lemma-stack supervisor) AGPLv3 lemma-cli/ lemma-terminal — the lemma CLI and terminal UI Apache-2.0 lemma-python/ lemma-sdk — Python SDK Apache-2.0 lemma-typescript/ lemma-sdk — TypeScript/JavaScript SDK for Node, browser, and React Apache-2.0 lemma-skills/ Built-in agent skills Apache-2.0 docs/ Installation and setup guides — install.sh One-line bootstrap installer — Everything is a normal directory in one repo. Development For contributing to the platform itself — hot-reload from source: git clone https://github.com/lemma-work/lemma-platform.git cd lemma-platform make init # install dependencies and create persistent local configuration make dev # run backend, frontend, and AgentBox with local debug/request logs make dev-public # add an ephemeral public API URL for webhooks and surfaces make logs # tail infrastructure container logs make stop # stop dev app, AgentBox, and tunnel processes make stop-all # also stop dev infrastructure Run make help for the full list. The dev stack uses explicit development ports (frontend 3710, backend 8710). Managed Desktop installations choose persistent high ports instead.

zero2robot Learn embodied AI by building a robot brain from scratch. No robot required. Read it online · Play in your browser · Newsletter: Physical AI Weekly zero2robot is a 43-chapter course (across six phases) that teaches robot learning the way you'd read a textbook, except every page is a single runnable file you study line by line and run yourself. You start from a bare simulation loop and build up, one chapter at a time, to a vision-language-action policy you train, evaluate, export, and drive in your browser, then on to the from-scratch practitioner's stack and a real-arm graduation. No framework to excavate, no black boxes. zero2robot is free and open, and it always will be. Read: each chapter is one file (bc.py, act.py, diffusion.py, ppo.py, …), ≤450 lines, no clever abstractions. The code is the product. You read every line. Run: every artifact runs on a free Colab T4 or a CPU laptop. --smoke for a fast deterministic pass, --seed everywhere, --out for artifacts. GPU owners get optional Scale Labs; nobody is ever gated behind hardware. Try: chapters ship with live browser demos (MuJoCo-WASM + ONNX). Drag the block out of the region the demonstrations covered and watch a confident policy fail. That failure has a name, and the course is built around understanding it. Honest state The buildable curriculum arc is complete: 43 chapters across six phases are built, finalized, and re-verified end to end (Phase 0 foundations through HIL-SERL post-training, the Phase 5 practitioner's stack, and the real-arm graduation). The interactive textbook is live at zero2robot.com and the MuJoCo-WASM playground at play.zero2robot.com; you can also run everything locally (below). What is honestly not finished, and is not claimed done: some GPU and Scale-Lab wall-clock cells are still unmeasured (they read TBD, never a guess). Wall-clock times in chapter prose are measured on real hardware (curriculum/common/wallclock.csv), never estimated. Quickstart git clone https://github.com/kaushikb11/zero2robot.git cd zero2robot uv sync # or: uv venv --python 3.11 .venv && uv pip install -e ".[dev,export]" # Chapter 0.1 — the simulation loop (instant, CPU) .venv/bin/python curriculum/phase0_foundations/ch0.1_sim_loop/sim_loop.py --smoke # Generate demos (deterministic, offline), then Chapter 1.1 — behavior cloning .venv/bin/python curriculum/common/envs/pusht/gen_demos.py --episodes 100 --seed 0 --out outputs/pusht-demos --no-video .venv/bin/python curriculum/phase1_imitation/ch1.1_bc/bc.py --smoke Every artifact accepts --smoke, --seed, and --out. The demo datasets are regenerated locally from seeded generators (no download needed); see datasets/datasets.yaml and python scripts/fetch_datasets.py --check. Run the interactive textbook locally: cd site && npm install && npm run dev # renders chapters from curriculum/**/prose Check your work on any chapter's exercises (instant, offline, no accounts): python -m grader.check 1.1 # runs that chapter's public exercise checks The phase map (43 chapters across six phases) The main line is 0 → 1 → 2 → 4 (post-training) → 5 (practitioner + graduation): a complete "empty file → real robot" journey on its own. Phase 3 is an optional Depth interlude, off the main line: self-contained electives you take when the itch strikes, never a wall before the payoff (Phase 4 requires nothing from it). Phase Chapters What you build 0: Foundations 0.0–0.5 (6) A quickstart on-ramp (train a tiny BC policy first, understand it later), then the simulation loop, MJCF scenes, spatial transforms, browser teleop → your first LeRobot dataset, reading episodes with rerun. 1: The Imitation Spine 1.1–1.9 (9) Behavior cloning, data curation, ACT (action chunking), diffusion & flow-matching policies, a real eval harness, and a from-scratch tiny VLA (data + training). 2: The RL Spine 2.1–2.8 (8) PPO and SAC from a blank file, 4096-robot MJX parallelism, reward design, quadruped locomotion, sim-to-real intuition labs, and a ROS-shaped runtime, without ROS. 3: Depth (optional interlude) 3.1–3.9 (9) Dreamer-style world models, a physics engine built from scratch (dynamics → constraints → contact), your engine vs MuJoCo, datasets at scale, reading the frontier, and sampling-based MPC (CEM/MPPI) that plans through the engine you built. Off the main line. Take it when the itch strikes. 4: Post-Training 4.2, 4.3 + primer (3 built) Take a trained policy and make it reliable: DAgger corrections on your own policy's failures, an offline-RL primer (BC vs AWAC), and HIL-SERL post-training. 5: The Practitioner's Stack 5.1–5.8 (8) + graduation Perception from scratch (a ViT, then contrastive vision-language), the production two-tower VLA shape and a FAST action tokenizer, LoRA and INT8 quantization by hand, and the real-arm teleop → record → train → deploy loop, plus a "go build" graduation bridge to your first real robot. Minimum viable paths (see curriculum/): a 20-hour core (0.1–0.5, 1.1–1.4, 1.6, 1.9) or the completionist run of all 43 built chapters (the 34-chapter core at ~118 learner-hours, plus Phase 5's practitioner arcs). Pointers curriculum/: the chapters. This is the product. Start at phase0_foundations/ch0.1_sim_loop/. site/: the interactive textbook (renders chapter prose + code + live demos). playground/: the MuJoCo-WASM browser playground and teleop UI. grader/: the exercise auto-checker (python -m grader.check). notebooks/: generated Colab variants of chapter code (regenerated, never hand-edited). datasets/, checkpoints/: pointers/manifests only; artifacts live on the Hugging Face Hub. No binaries in git. ARCHITECTURE.md: the repo map, the doctrine, and the CI gates. CONTRIBUTING.md: how the pieces fit and what a PR must pass.

What is Fusion Embedding 1?Fusion Embedding 1 is an open-weight multimodal embedding model that maps five modalities — text, image, video, audio, and PDF — into a single shared vector space. It is built by Eximius-Labs for retrieval, RAG, clustering, and cross-modal search, and is designed to be fully self-hostable.How it worksInstead of training a multimodal embedder from scratch, Fusion Embedding 1 takes Qwen3-VL-Embedding, an open state-of-the-art text/image/video embedding model, and freezes it byte-for-byte. It then adds an audio pathway using a frozen Qwen2.5-Omni audio tower feeding a small trained connector called the FusionResampler (about 16M parameters, under 1% of the base). Audio is aligned to text contrastively, and because text, image, and video already share the base model's vector space, audio-to-image and audio-to-video alignment emerge through the text bridge.Key featuresFive modalities, one space: text, image, video, audio, and PDF are embedded into a single vector space for retrieval in any direction between modalities.Frozen-base architecture: only the connector and a temperature parameter are trained, so the base model's retrieval quality is inherited unchanged (asserted via base_drift == 0 on every training run).Matryoshka embeddings: truncate to dimensions of 2048, 1536, 1024, 512, 256, 128, or 64 and re-normalize, with embeddings staying consistent at every size.Instruction-aware audio: the same audio clip embeds differently depending on the task, such as sound description, spoken content, or speaker and emotion.Self-hostable: no API and no rate limits; it runs quantized on a single consumer GPU for inference.Test-first engineering: the pipeline runs end-to-end on CPU-only stand-ins with 125+ unit and end-to-end tests.Who is it for?Fusion Embedding 1 is aimed at developers and researchers building retrieval-augmented generation (RAG) systems, cross-modal search engines, and clustering pipelines who need to search and compare text, images, video, audio, and PDFs within one unified vector space. Because it is open-weight and self-hostable, it also suits teams that want to avoid API dependencies and rate limits for embedding workloads.AvailabilityA research preview checkpoint, fusion-embedding-1-2b-preview, is available on Hugging Face with connector weights, a model card with benchmarks, and a packaged inference API. The source code and training pipeline are published on GitHub under the Apache-2.0 license.

Makoto An integrity hook for Claude Code that watches the agent's own tool calls and blocks the ones that fake a check. When Claude says it did something — ran the tests, cited a paper, committed the fix, verified the certificate — makoto holds that word against its record. If the deed isn't there, or the verification was quietly disabled, makoto blocks the tool call (or the end-of-turn) and hands the agent a one-line correction to retry against. It judges the agent against its own utterances and record — never the world's truth. It holds no facts ("France doesn't exist to it"); it only checks that a claimed word is kept, whole, and honored in deed. A word it lets through becomes spendable: trustworthy tender a reviewer or another agent can accept without re-deriving it. What it catches makoto fires on mechanical hook events — every PreToolUse, PostToolUse, and Stop — and blocks (exit 2, which Claude Code treats as block-and-retry) on 15 pre-checks across five families and 19 end-of-turn gates. Every pre-check and every end-of-turn gate but four blocks; there is no silent "warning" tier for those (see Fire level) — the four documented exceptions are gate.self_wired, gate.canon_fingerprints_advisory, gate.relative_path_citation, and gate.plan_item_drift (below), advisory-only checks that by design never block. Verifier weakening — a check silently neutered content.verifier_predicate_weakened loose-comparator verifier (startswith/endswith/re.match where == is meant) content.verifier_exit_masking exit-code masking (|| true, ; true, set +e on a test/build/lint) content.verifier_body_hollowed hollowed verifier body (return True / pass in a constitution check) content.env_gated_audit audit/verification code gated behind an env var · content.integrity_suppression_flag integrity-named suppression flag (*_skip = true) Fabricated evidence — a claim with no backing artifact content.phantom_citation phantom citation (Author-Year not in makoto/docs/CITATIONS.md) content.unsourced_webfetch WebFetch of a URL never seen in any prior tool result this session content.fabricated_commit_sha fabricated commit SHA/tag presented as proof of a commit content.deferred_checkbox_theater DEFERRED-style checkbox theater on an open to-do item content.illusory_authorship_trailer an illusory Claude/Anthropic authorship or generation attribution (trailer, session link, routing address, or "Generated with/by Claude" footer) — a plain "Claude Code" product-name mention is not matched content.illusory_interruption_claim a fabricated "interrupted by user" claim with no genuine harness-set interruption anywhere in this session's recorded history Self-defense content.self_mute_guard makoto self-mute (disabling or un-wiring makoto via settings.json) Scope & contract discipline — illusory progress and out-of-contract action (SPEC-5, ported by shape from Assay) event.thrash_revert a whole-file Write that reverts a file to an earlier byte-identical content after an intervening different Write (A→B→A, no net progress) gate.contract_order a result-producing call issued while a declared Plan's dependency for that step is still undischarged (its Stop-time sibling gate guards the remainder at turn end) End-of-turn gates — fire on the agent's closing claims, checked against the recorded ledger: gate.completion — "done / created X" but the artifact isn't on disk gate.advance — advancing a phase whose precondition isn't recorded as met gate.green_claim — "suite green" against a recorded test failure gate.dropped — a forward promise carrying identifying info ("I'll add def X to Y", "3 tests in Z") left undischarged at turn-end — said-but-not-done, checked against the agent's own touched-keys gate.fabricated_action — "I ran X / executed Y" in a turn with no tool call at all (presence-of-work, not command-text match) gate.named_test — "test_foo passes" against a recorded FAILED of that exact named test (coreference-pinned; the green_claim delta) gate.stale_pass — "all tests pass" against pytest's own lastfailed record still naming a live failing test (the runner's ledger, existence-filtered for staleness) gate.claimed_running — "the server is running" / "it's up and listening on port 5173" but this session's own recorded Bash evidence contradicts it: no process-start or liveness-check command ran at all this session, or the most recently recorded one ended in a direct error state (interrupted, or a non-zero exit code). Agnostic in the gate.canon sense — the failure verdict reads only those two protocol terminals, never a test-runner regex or a language/framework token; the command classifier is a broad, open-world, multi-ecosystem net (like is_test_runner's), so an unlisted launcher/healthcheck shape is a documented recall bound, never a false-block source. gate.run_promised — the forward-looking sibling of gate.claimed_running: the immediately prior turn's own message promised a first-person run-intent action ("I'll run the tests", "I'm going to restart the server", "let me deploy this") but no Bash call appears anywhere in this session's recorded history since — the word must match the world, checked one turn later. Closed first-person-auxiliary + closed process-lifecycle-verb lexicon (mirroring gate.claimed_running's own verb set), so "it's going to rain today" cannot match on either the subject or the verb axis. Stateless: the one-turn grace period falls out of history structurally never containing the row for the Stop currently being evaluated, so a promise made THIS turn can only ever be checked starting at the NEXT one — no new persistence, no Plan/PlanNode extension (a run-intent promise's only evidence is "a Bash call happened", not a located file write). gate.claimed_shipped — a completed-action sibling to gate.claimed_running/gate.run_promised, but scoped to REMOTE mutations instead of local process liveness: "I merged the PR", "pushed it to main", "it's live now" with no successful remote-mutating tool call anywhere in this session's recorded history. Evidence is a non-dry-run git push over Bash, or a successful call from a closed non-Bash tool set (merge_pull_request — requiring merged: true, not just an error-free response — and push_files, plus their mcp__github__-qualified forms); create_pull_request is deliberately excluded, since opening a PR establishes intent but does not substantiate "merged" or "live". Reads history_all_agents so a subagent's own real push/merge grounds a main-thread claim. Immediate check, no grace period — this claims something already done. gate.completion keeps sole ownership of local file-production claims; this gate never duplicates it. gate.liveness — fires on the code itself, not a claim: a statement with no live effect inside a closed function (dead/illusory work the present-closure model can prove inert). It walks the turn's touched .py ASTs, so it yields a finding per illusory statement rather than one per turn. gate.self_wired — advisory only, never blocks (see Fire level): partial-strip detection of makoto's own .claude/settings.json hook wiring — fires if PreToolUse/PostToolUse/Stop is missing a makoto-dispatching entry while at least one other still has one. It has a documented blind spot: a single edit that strips all three simultaneously disables this check in the same instant it would have fired (Claude Code reloads hook config live, not once at session start), so it provides zero coverage against that full-strip case — see docs/self-defense-asymmetry-followup.md. gate.hollow_test — fires on the code itself, not a claim: a HOLLOWED test (SPIRIT.md §4) — one that survives in name while its content is gutted, so it can never actually fail. Four sub-patterns: no assertion of any kind in the test body; an asserted tautology (assert True, or comparing an expression to itself); a broad, no-op try/except that silently swallows the only call-under-test's failure; and a test-shaped function that can never fire independently — either nested inside another function (pytest's collector never discovers it) or gated behind a skipif/skipIf condition that is provably always true. gate.canon — blocking (level="error", unlike the advisory exceptions below): two language-agnostic Stop primitives over the turn's own call stream, reading only closed protocol fields (tool_name/tool_input identity, tool_response.interrupted/.error) — no test-runner regex, no language token. canon.timeout fires when the turn's LAST tool call ended in a direct error state (interrupted, or a self-emitted error code) and closed without resurfacing or resolving it — an error resolved by a later successful call stays silent. canon.recur fires when the SAME tool call (identical name + byte-identical input) was re-issued back-to-back and every call in that consecutive run ended in the same direct error state — a stuck retry loop with nothing changed between attempts; judged per (tool, input) key, so a later success for that same key silences it even with other, different calls in between. Certified via held-out adversarial RED fixtures (planted cases that must fire) plus a near-vacuous corpus-FP check — the honest corpus almost never carries the triggering precondition (interrupted/self_error_code) at all, so a clean corpus replay alone is inconclusive, not a certification (see ANCESTRY.md §2 Part B for the corrected framing). gate.canon_fingerprints — blocking: 4 of 17 ported session-level "canon" fingerprints (SPEC-5 Task 9, from REF-lever-graded-primitives/signalminer/grade_planted.py's 27-fingerprint THE_CANON) that are robust-core, blocking-capable by construction — 0-FP on both the planted-clean and real-Claude-gold negative sets per the gold-oracle certification (nogreen_checkdisabled, nosrc_destruct, nosrc_green_timeout, notestedit_destruct). gate.canon_fingerprints_advisory — advisory only, never blocks: the other 13 of the same 17 fingerprints — each either rests on a soft/claim atom (claimed_pass_no_run, tool_timeout, assertion_weakened) the gold-oracle finding doesn't certify as robust, or is one of that finding's explicitly-named worst-disqualified fingerprints. Recorded to the audit log per SPEC-5's total-retention rule, never emitted as a block decision. gate.contract_order — blocking: the Stop-time remainder guard over a declared Plan (SPEC-5, ported by shape from Assay's ContractOrder pattern) — fires when the turn ends with the plan's dependency remainder still non-empty. Its PreToolUse sibling guard is a pre-check, not a Stop gate; see makoto/checks/contractOrder.py. Inspect the live catalog with makoto pattern list; see one pattern in full with makoto pattern show content.phantom_citation. Discharging a permanent session-level block gate.canon_fingerprints (and canon.timeout within gate.canon) read the session's own recorded call stream. Once a fingerprint's atoms go true they stay true forever, so without a real discharge path a single sanctioned action (e.g. an owner-approved destructive command) would otherwise block every remaining Stop for the rest of the session. The only discharge is an operator-attributed release, re-derived from the host-written transcript at check time and never trusted from ledger content, so no tool call or file write can forge it. Say, as a real message in the conversation (never inside a tool call or file write): makoto release.operator <fingerprint-id>: <your reason> makoto verifies the turn is genuinely user-authored, non-synthetic, and timestamped after the finding first fired, then discharges that exact fingerprint for the rest of the session. The discharge is chain-appended (kind="release.operator") for the audit trail; the block decision itself is always re-derived from the transcript, never read back from that row. Legitimately writing a flagged shape? Annotate the line with makoto-allow: <reason> (any comment style, case-insensitive). makoto won't fire on it, and your rationale is on the record — an auditable note, not a silent bypass. if os.environ.get("ENABLE_AUDIT_TRAIL"): # makoto-allow: app feature, gates user-facing audit logging write_audit_trail() See docs/SPIRIT.md — 誠 (makoto), the constitution every pattern derives from: a word is real the way water is wet, a constitutive property, not an after-the-fact audit. Install (plugin) /plugin marketplace add Clear-Sights/Makoto /plugin install makoto@makoto Enabling the plugin is the whole install: .claude-plugin/plugin.json + hooks/hooks.json auto-wire dispatch on enable. Claude Code registers PreToolUse, PostToolUse, Stop, SubagentStop, and SessionStart hooks pointing at ${CLAUDE_PLUGIN_ROOT}/makoto/_dispatch_shim.sh automatically (which execs python -m makoto._dispatch). ~/.claude/settings.json is NOT modified — the plugin system manages its own hook registry. State dir + makoto.db are created lazily on the first hook invocation. Companion setting (optional): suppress the harness auto-trailer An illusory AI-authorship commit trailer reaches a commit through two doors. Pre-Check content.illusory_authorship_trailer blocks the agent-authored one — the trailer typed into a git commit message or into file content, the surface no setting can reach. The other door is Claude Code's own automatic append, which a setting governs. To close it at the source, set in ~/.claude/settings.json:

Runloom Go-style stackful coroutines for Python. Write blocking code — fiber(fn), plain recv/send, no async/await — and run a million of them across every core in one process. Hand-rolled asm context switch + C work-stealing scheduler + netpoll, built for free-threaded Python 3.14t (GIL off). import threading, runloom from urllib.request import urlopen runloom.monkey.patch() def crawl(url): # urlopen() looks blocking -- but monkey.patch() parks the goroutine on the # socket instead of the OS thread, so all 64 fetches overlap on real cores. body = urlopen(url, timeout=10).read() print(threading.get_native_id(), len(body)) def main(): for _ in range(64): runloom.fiber(crawl, "http://example.com") runloom.run(8, main) # 8 hub threads -> real cores on 3.14t (GIL off) Runloom vs Go Same box (64c, free-threaded CPython 3.13t), 8 hubs / GOMAXPROCS=8, warm steady-state. Go ≈ 2.1 M spawn/s here. metric runloom Go verdict spawn — pure C (c_entry) 2.29 M/s 2.10 M/s beats Go spawn — Python (runloom.fiber) 1.35 M/s 2.10 M/s 0.65× context switch ~75 ns yield · ~560 ns chan RT ~50 ns Gosched ~parity conn/s — churn (new conn per req) ~75–78 k/s ~75–78 k/s parity req/s — keep-alive echo, Python handler 596 k/s 603 k/s 0.99× — parity (C handler beats Go) memory — empty parked fiber 8.8 KB 2.7 KB 3.3× (the one real gap) The short story: on spawn, scheduling, and throughput, runloom trades blows with Go and beats it on raw spawn — a stackful coroutine runtime on CPython matching a compiled language even with a Python handler (596 k vs 603 k req/s at saturation; a C handler beats Go). The one honest gap left is memory: a suspended fiber carries a CPython eval frame, ~3.3× Go's per-fiber RSS. Full cross-runtime numbers + cold spawn-vs-N curves: benchmark report · perf summary. runloom.optimize("throughput") # runloom.fiber -> max spawn rate (fiber_fast) runloom.optimize("memory") # runloom.fiber -> small right-sized stacks (default) Install pip install runloom import runloom # scheduler + channels, plus monkey/time/context/sync/aio Prebuilt wheels (no compiler needed) for CPython 3.11–3.14 on Linux (x86_64/aarch64), macOS (arm64/x86_64), Windows (AMD64); source build elsewhere. No runtime dependencies. What it is Hand-rolled asm context switch (x86_64 SysV, aarch64) — ~80 ns/swap, no syscall; Windows Fibers / POSIX ucontext fallback. M:N work-stealing scheduler (3.13t) — Chase-Lev deque per hub, per-hub MPSC submission, woken goroutines routed back to their origin hub. Per-goroutine PyThreadState snapshot — cframe, datastack, exc_info, contextvars, recursion; a million yielded goroutines share their hub threads with no frame-chain cliff. netpoll — epoll / kqueue / IOCP / WSAPoll / select; goroutines park transparently on fd readiness, lost-wake-free 3-state park-commit. Go-style channels — Chan(capacity), select, for v in ch. Stall isolation + recovery — one unanticipated blocking call stalls only its hub, and the runtime detects + recovers it (default on, 3.13t). monkey.patch() makes blocking stdlib (socket, time, threading, …) cooperative, so existing blocking code runs unchanged. Already have async def code? The runloom.aio bridge runs it on the single-threaded scheduler (runloom.aio.run(main()) ≈ asyncio.run) — a zero-rewrite port path, not a multi-core speedup (use the sync API with run(n>1, main) for that). Honest limitations The multi-core win needs free-threaded CPython 3.13t (3.11+ for the frame snapshot at all). On a GIL build runloom still runs — cheap spawn, the goroutine model, netpoll — but single-core like asyncio. runloom doesn't make Python faster per core. CPython's ~80 k pure-Python ops/s/core is a constant it can't raise; it lets one process hit that on every core at once with a blocking model. The scheduler itself is Go-class. Higher memory per goroutine than Go (~3.3× for an empty fiber — the CPython eval frame; a C handler closes most of it). Preemption fires only at Python bytecode boundaries — a goroutine inside a tight pure-C call (e.g. numpy) holds its hub until it returns (same as Go + cgo). Linux x86_64 / 3.13t is the primary, heavily-validated target (2 M-conn runs, fuzzing, sanitizers, formal models); other backends are maintained in-step but less deeply exercised. Platform support OS / arch switch netpoll tested Linux x86_64 fcontext-asm epoll yes — hw, 3.11 / 3.12 / 3.13t / 3.14t (primary) Linux aarch64 fcontext-asm epoll qemu macOS x86_64 / arm64 fcontext-asm kqueue hw, 3.14t FreeBSD / GhostBSD fcontext-asm kqueue hw, 3.12 Windows 10/11 / Server 2022 Fibers IOCP→WSAPoll→select hw, 3.14t Solaris / Android / other BSD ucontext / asm select / epoll / kqueue review Docs & layout Full guide in docs/: Quickstart · Asyncio bridge · Sync API · Channels · M:N parallelism · Cookbook · API reference Dir Contents src/runloom_c/ C extension: scheduler, channels, netpoll, asm backends, M:N hubs, stall recovery src/runloom/ Python layers: aio, sync, monkey, time, runtime tests/ · examples/ · benchmark/ · docs/ tests · runnable examples · benchmarks + perf harness · docs Build from source (contributors): pip install -e . from a clone (needs a C compiler; scripts/install.sh / scripts\install.bat bootstrap one). To hack on runloom against free-threaded CPython, use a 3.13t interpreter.

python

Explore categories

How Product Visit works