Mervin Praison

Loop engineering means you stop being the person who types every prompt to a coding agent — and start designing a small system that discovers work, delegates it, checks it, remembers progress, and repeats. The leverage moves from prompt craft to loop design: six primitives that now ship inside tools like Claude Code and the Codex app instead of bespoke bash you maintain forever.

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
graph TD
  subgraph Stack["Three layers"]
    H[Harness engineering] --> L[Loop engineering]
    L --> O[Orchestration layer]
  end
  H -->|one agent runtime| T[Tools memory sandbox]
  L -->|schedule + verify| P[Six primitives]
  O -->|fleet + PR lifecycle| R[Reactions state machine]

  classDef agent fill:#8B0000,color:#fff
  classDef hook fill:#189AB4,color:#fff
  classDef decision fill:#444,color:#fff

  class H,L,O agent
  class T,P,R hook

Where the conversation landed in 2026

The shift is no longer niche. Boris Cherny, who leads Claude Code at Anthropic, described it on the Acquired podcast as: “I don’t prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops.” Peter Steinberger put the same idea on X: “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.” Both are saying the human job moved up one floor — from typing each turn to designing feedback systems.

That floor has three names in practice. Harness engineering is the runtime around one agent (tools, memory, permissions). Loop engineering is the harness that runs on a schedule, spawns helpers, and feeds itself from disk. Orchestration is the layer above when you need fleets of agents across worktrees, PRs, and CI — with automatic routing of failures back to the right session.

The universal five-stage cycle

A prompt gives instructions for one turn. A loop gives a job: discover → plan → execute → verify → iterate until done. You set the goal; the loop runs itself.

Open loops vs closed loops

Closed loops need five ingredients on disk: goal (precise done), context (VISION.md, ARCHITECTURE.md, RULES.md), action (scoped tools), feedback (tests, lint, structured errors), and a stop condition (/goal text, Stop hook, or orchestrator brief). Without a quality gate, AI drifts; with one, it improves.

Single-agent loop vs fleet loop

What changed in agentic development

For roughly two years, “good AI coding” meant writing strong prompts and feeding enough context each turn. You typed, read, typed again — the agent was a power tool and you held the handle every step.

Loop engineering is the next layer: a recursive goal where you define purpose and done, and the system iterates until a verifiable condition holds. You design once; the loop pokes agents on a schedule or across turns. This sits one floor above agent harness engineering (the environment one agent runs in) and the factory model (the system that builds software) — same family of ideas, but the harness now runs on a timer, spawns helpers, and feeds itself from disk-based memory.

The six primitives every loop needs

The agent forgets; the repo does not. Long-running loops depend on external state — not context window — to remember what was tried, what passed, and what is next. Common context files beyond SKILL.md: VISION.md (what success looks like), ARCHITECTURE.md (stack and layout), RULES.md (forbidden actions), GUARDRAILS.md (always-on checklists), and AGENTS.md (repo map for agents).

Codex app vs Claude Code — same shape, different names

Once you see the shared shape, the debate shifts from “which tool” to “which loop design still works in either seat.”

1. Automations — the heartbeat

Automations turn a one-off agent run into a loop. In the Codex app you configure project, prompt, schedule, and environment (local checkout or background worktree). Runs with findings land in a Triage inbox; empty runs archive themselves. Internal uses include daily issue triage, CI failure summaries, commit briefings, and regression hunts. Automations can call $skill-name so recurring logic stays maintainable.

Claude Code reaches the same outcome via /loop (interval reruns), cron scheduling, lifecycle hooks, Desktop scheduled tasks (persistent while app is open), Cloud Routines (runs when laptop is closed), or GitHub Actions for headless runs.

Interactive pick: /goal vs /loop vs Stop hooks

# Claude Code — run until tests and lint are clean (v2.1.139+)
/goal all tests in test/auth pass and the lint step is clean

# Check spend and evaluator reasoning
/goal

# Stop early
/goal clear

# Headless single invocation
claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"

# Codex — long-running performance goal (cookbook pattern)
/goal Reduce p95 checkout latency below 120 ms, verified by the checkout benchmark,
while keeping the correctness suite green. If blocked, stop with evidence.

/goal on Claude Code starts a turn immediately; after each turn Haiku (by default) judges yes/no from the transcript — it does not run tools. Codex /goal is thread-scoped with explicit budget accounting and pause/resume. Pair either with auto mode so each turn skips per-tool confirmations.

2. Worktrees — parallel without collisions

Two agents editing the same file is the same failure mode as two engineers on one branch without coordination. A git worktree is a separate working directory on its own branch, sharing history but not files. Codex threads use worktrees natively; Claude Code offers --worktree sessions and isolation: worktree on subagents that clean up after themselves.

Worktrees remove mechanical collision; your review bandwidth still caps how many parallel agents you can actually supervise.

3. Skills — stop paying intent debt every session

Agents start cold. Every missing convention becomes a confident guess — intent debt. A skill is intent written outside the chat: a folder with SKILL.md, optional scripts, references, and assets. Both Codex and Claude Code load skills when you invoke $name or when the task matches a tight, boring description (clever descriptions match too often).

# Example skill layout
my-project-skill/
  SKILL.md          # conventions, build steps, forbidden patterns
  scripts/
  references/

Skill vs plugin: the skill is the authoring format; a plugin bundles skills and connectors for teammates to install once.

4. Connectors — act in your real environment

MCP connectors let the loop read Linear/Jira, query databases, hit staging APIs, and post to Slack. That is the difference between “here is the fix” and “open the PR, link the ticket, ping the channel when CI is green.” Plugins package connectors with skills so onboarding is one install, not tribal memory.

Feedback signals that keep loops honest

Strongest systems stack multiple signal types: deterministic for reliability, visual/critic for judgment, human gates on high-stakes merges. Signals must route back automatically — full logs, diffs, scores — without you copy-pasting CI output each turn.

5. Sub-agents — maker vs checker

The model that wrote the code is too lenient grading itself. A second agent — different instructions, sometimes a different model — catches rationalised mistakes. Typical trio: explore, implement, verify against spec. In fleet setups, a validator agent reports truth without fixing — failures loop back to the builder.

# Codex — custom subagent (simplified .codex/agents/security-reviewer.toml)
name = "security-reviewer"
description = "Read-only security pass on diffs"
instructions = "Find auth, injection, and secret-leak risks. No edits."
model = "strong"
reasoning_effort = "high"

Sub-agents cost extra tokens (each runs its own model + tools). Spend them where a second opinion unlocks unattended runs — the only reason you can walk away from a loop.

Orchestration — when one loop is not enough

Single-session /goal loops solve “finish this migration without me re-prompting.” Fleet-scale work needs an orchestration layer: deterministic plumbing plus an orchestrator agent for judgment.

Open-source reference implementations like Agent Orchestrator (npm install -g @aoagents/ao) ship reactions engines, worktree isolation, and orchestrator prompts out of the box. The pattern: inner agents execute in bounded loops; outer orchestrator coordinates; environmental signals keep loops honest; you stay on vision and judgment.

Walkthrough: one morning triage loop

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
sequenceDiagram
  participant Auto as Morning automation
  participant Skill as Triage skill
  participant State as STATE.md
  participant WT as Worktree
  participant Maker as Fix sub-agent
  participant Check as Review sub-agent
  participant MCP as Connectors

  Auto->>Skill: Run on schedule
  Skill->>State: Write CI failures + issues
  loop Each actionable item
    Auto->>WT: Open isolated checkout
    WT->>Maker: Draft fix
    Maker->>Check: Submit diff
    Check-->>Maker: Approve or reject
    Maker->>MCP: Open PR + update ticket
  end
  Auto->>State: Log done / blocked for human inbox

• 06:00 — Automation fires; triage skill reads yesterday’s CI, open issues, recent commits.
• Findings — Written to STATE.md or a Linear board (memory outside the chat).
• Per item — New worktree → maker sub-agent drafts fix → checker sub-agent runs against project skills + tests.
• Ship — Connectors open PR and update tickets; blocked items land in your inbox.
• Tomorrow — State file tells the loop what was tried, passed, or still open.

You designed this once. You did not prompt each step — that is the whole point.

Prompt engineer vs loop engineer

Self-check: is your loop healthy?

What loops do not remove — three sharper risks

Verification stays human

An unattended loop is also an unattended mistake machine. Even with a verifier sub-agent, “done” is a claim, not proof. Ship code you confirmed works — especially when diff sizes balloon because agents touch more files than necessary.

Comprehension debt accelerates

The faster the loop ships code you did not write, the wider the gap between what exists and what you understand. Read the reasoning, skim the diff, trace the decision log — or the loop makes the debt grow faster, not slower.

Cognitive surrender

When automation feels smooth, it is tempting to stop having opinions. Loop design with judgement keeps you the engineer; loop design to avoid thinking is the same UI with opposite outcomes. Two teams can run identical loops — one moves faster on work they deeply understand; the other outsources understanding entirely. The loop cannot tell the difference. You can.

Parallel pattern: scheduled content factories

The same week loop engineering went mainstream for coding, creators published parallel “factory” playbooks for media. @0x_fokki’s X Article I Built an AI Animation Factory That Runs 24/7 is not a coding-agent harness — Claude is used as a scriptwriter, not a repo editor — but it shows the same design move: stop hand-driving each step, design a pipeline that runs on a schedule with human approval gates.

Fokki’s pipeline chains six tools end-to-end:

Claude → Midjourney → Runway → ElevenLabs → Suno → Make
script → frames → motion → voice → music → publish

One Make scenario runs Monday and Thursday at 08:00: pull scripts from Google Drive, batch Midjourney scene prompts, download frames, send dialogue to ElevenLabs, pair images with Runway motion clips, assemble in a CapCut template, upload to YouTube with generated metadata, clip a 30-second X preview, post Patreon early access, and ping Telegram on completion. A separate on-demand webhook turns client briefs into finished explainers in shared Drive — quoted turnaround ~6 hours after a one-time ~5-hour setup.

Four SKUs share the pipeline: animated story series (6–10 min), brand explainers (60–90 sec), motion comics, and children’s bedtime channels. The human job is narrow: pick the story, pick the style, approve the output — roughly four hours of direction for a “24/7” factory, per the author.

What transfers to coding loops

• Scheduled heartbeat — the factory does not wait for you to open a chat; neither should triage or CI-repair loops.
• Stage-specialised tools — one brain trying to script, illustrate, animate, and score is the creative version of one agent grading its own code.
• Performance direction in prompts — Fokki writes ElevenLabs stage direction (pauses, volume drops), not raw dialogue paste; coding loops need equally explicit done conditions in /goal text.
• Human gate on output — “approve the episode” maps to Triage inbox review and PR merge — optimise human time, do not remove judgment.
• Setup once, run indefinitely — the Make scenario is the media equivalent of wiring automations + skills once, then letting the loop compound.

Treat revenue figures in social factory posts as illustrative, not audited benchmarks. The architectural lesson is stable: factories — code or content — are designed loops with explicit stages, schedules, and gates. Coding loop engineering just demands harder oracles (tests, type checks, diffs) because “shipped” is easier to fake than “sounds convincing.”

Token economics and balance

Loops are not free — patterns diverge wildly if you are “token rich” vs “token poor.” Direct prompting still matters for ambiguity and architecture. Loops handle repetition; you handle judgement. The leverage point moved — it did not disappear.

Performance summary

Early June 2026 delivered one of the densest open-weight release windows on record — spanning chat models, image generation, speech, music, vision, video, and 3D. The roundup below maps 25+ notable drops across modalities, with specs drawn from official model cards and repos rather than hype alone.

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
graph TD
  W[Open-weight release week] --> L[LLMs and MoE chat]
  W --> I[Image DiT checkpoints]
  W --> A[Audio TTS and ASR]
  W --> V[Vision VLMs and OCR]
  W --> M[Music and realtime audio]
  W --> X[Video world and 3D]

  L --> D[Deploy: MLX ONNX vLLM]
  I --> D
  A --> D
  V --> D
  M --> D
  X --> D

  classDef agent fill:#8B0000,color:#fff
  classDef hook fill:#189AB4,color:#fff

  class W agent
  class L,I,A,V,M,X,D hook

Large language models and edge chat

Links: Nemotron 3 Ultra · Gemma 4 12B · LFM2.5-8B-A1B · Mellum2 Thinking

Image generation — Ideogram 4 open weights

The surprise headline: Ideogram 4 shipped its first-ever open weights — a 9.3B flow-matching Diffusion Transformer (DiT) trained from scratch. Reported leaderboard placement: #2 overall behind GPT Image 2 on aggregate arenas, top open-weight on Design Arena and LMArena, with particular strength on text-rich layouts (posters, UI mockups, labelled diagrams).

Link: Ideogram 4.0 technical blog · Hugging Face collection

Audio, speech, and music — four TTS labs in one week

Links: Higgs Audio v3 · dots.tts · Magenta RealTime 2 · Nemotron ASR via NVIDIA HF

Vision, VLMs, and document AI

Video, world models, and 3D

Links: Cosmos3-Super · NVIDIA Cosmos 3 blog · nvidia/Cosmos

Glossary — abbreviations from the roundup

How to navigate the flood

• Laptop / phone: Gemma 4 12B QAT, LFM2.5-8B MLX, Mellum2 for coding agents.
• Design & posters: Ideogram 4 open DiT for text-heavy layouts.
• Voice products: Higgs v3 for expressive tags; dots.tts for fully continuous Apache 2.0 pipelines.
• Robotics / sim: Cosmos3-Super for multimodal world + action reasoning.
• Datacenter LLM: Nemotron 3 Ultra + NVFP4 on Blackwell for throughput.

Watch the week in 60 seconds

Video: demonstration from Niels Rogge on LinkedIn.

Release-week summary

INSID3 is a training-free in-context segmentation method that segments objects, parts, or personalised instances in new images from a single annotated reference — using only frozen DINOv3 features, with no segmentation decoder, fine-tuning, or auxiliary models such as SAM.

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
graph TD
  R[Reference image + mask] --> E[Frozen DINOv3 encoder]
  T[Target image] --> E
  E --> D[Positional debias SVD projection]
  E --> C[Agglomerative clustering]
  D --> S[Seed cluster selection]
  C --> S
  S --> A[Cluster aggregation cross + self similarity]
  A --> M[Segmentation mask + CRF refine]

  classDef agent fill:#8B0000,color:#fff
  classDef hook fill:#189AB4,color:#fff
  classDef decision fill:#444,color:#fff

  class R,T,M agent
  class E agent
  class D,C,S,A hook

What in-context segmentation asks for

In-context segmentation (ICS) mirrors few-shot prompting in language models: you supply one visual example with a mask, and the system must segment the same concept in unseen images. The paper unifies three settings under one formulation:

Why prior pipelines needed decoders or SAM stacks

Three-stage pipeline on frozen DINOv3

INSID3 never updates weights. Given reference image I^r with binary mask and target I^t, it extracts patch embeddings from a frozen DINOv3 encoder, then runs three stages:

• Fine-grained clustering — agglomerative clustering on original target features (threshold τ = 0.6) yields coherent object- and part-level region candidates without fixing cluster count K.
• Seed-cluster selection — backward nearest-neighbour filtering in debiased feature space narrows candidates; cross-image prototype similarity picks the seed cluster most aligned with the reference mask.
• Cluster aggregation — merges the seed with clusters whose combined cross-image × intra-image self-similarity score exceeds α = 0.2, recovering full object extent beyond the seed alone.

Unlocking DINOv3: positional debiasing

DINOv3’s dense features carry strong semantic correspondence, but cross-image similarity also shows a systematic positional bias: patches at the same absolute coordinates spuriously match even when semantics differ — especially in low-content background regions. The authors estimate a low-dimensional positional subspace by passing a Gaussian noise image through the encoder, taking the top-s right singular vectors from SVD, and projecting reference and target features onto the orthogonal complement. Debiased features drive cross-image matching; original features drive intra-image clustering and self-similarity aggregation.

On semantic correspondence (SPair-71k, DINOv3-Base), debiasing lifts PCK@0.10 from 46.8 to 52.6 (+5.8 points) — showing the fix generalises beyond segmentation.

Region grouping without supervision

DINOv3 patch embeddings exhibit strong local consistency: neighbouring patches on the same object or part cluster naturally. Agglomerative merging on original features decomposes the target into structured region candidates that INSID3 then matches and expands — no K-means preset and no SAM mask proposals.

Benchmark results across nine datasets

The paper evaluates one-shot semantic (COCO-20i, LVIS-92i, ISIC, SUIM, iSAID, chest X-ray), part (PASCAL-Part, PACO-Part), and personalised (PerMIS) segmentation. Primary metric: mean IoU (mIoU) on the final mask. INSID3 averages 55.1 mIoU across all nine benchmarks — +7.5 points over prior work on average and +8.1 over the strongest SAM-based training-free baseline (GF-SAM with DINOv3).

Speed and deployment

INSID3 runs about 3.4× faster than GF-SAM and 29.8× faster than Matcher while using roughly 3× fewer parameters than dual-VFM pipelines. Inputs default to 1024×1024; reducing to 768px trades a small mIoU drop for substantially faster inference. Masks are bilinearly upsampled to original resolution with optional CRF refinement.

Run INSID3 locally

# Clone and install (uv or conda — see GitHub README)
git clone https://github.com/visinf/INSID3
cd INSID3
uv sync && source .venv/bin/activate

# Download frozen DINOv3 Large weights into pretrain/
# dinov3_vitl16_pretrain_lvd1689m-8aa4cbdd.pth

from models import build_insid3
from utils.visualization import visualize_prediction_segmentation as visualize

model = build_insid3()  # optional: mask_refiner="crf", image_size=768
model.set_reference("ref_image.jpg", "ref_mask.png")
model.set_target("target_image.jpg")
pred_mask = model.segment()

# Batch eval example
# python inference_segmentation.py --dataset coco --exp-name insid3-coco

Official code: visinf/INSID3 (Apache 2.0). Colab demo and semantic-correspondence inference (`model.match(ref_kps)`) are also documented in the repository. Accepted as a CVPR 2026 Oral.

Performance summary

Harness-1 is a 20B open-source search agent that trains with reinforcement learning inside a state-externalizing harness — the environment keeps candidates, curated evidence, verification logs, and deduplicated history so the policy only decides what to search, keep, verify, and when to stop.

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
graph TD
  Q[Search query] --> P[20B policy]
  P -->|search curate verify| T[Retrieval tools]
  T --> H[Stateful harness]
  H --> C[Candidate pool]
  H --> E[Curated evidence set]
  H --> V[Verification records]
  H --> R[Budget-aware context render]
  R --> P
  P -->|submit| A[Final evidence set]

  classDef agent fill:#8B0000,color:#fff
  classDef hook fill:#189AB4,color:#fff
  classDef decision fill:#444,color:#fff

  class Q,A agent
  class P agent
  class T hook
  class H,C,E,V,R hook

Why append-only transcripts break long-horizon search

Most search agents are trained as policies over growing chat logs: search, read, append, repeat. The model must simultaneously search well and act as memory, note-taker, verifier, and librarian. Patrick Jiang’s launch thread argues RL on that setup optimises recoverable bookkeeping the environment could maintain more reliably — and sparse final rewards rarely say whether failure came from bad search, forgotten evidence, or missing verification.

What the harness stores vs what the policy decides

The agent operates over a workspace, not a raw search box. RL then learns a structured interface — search, curate, revisit, verify, submit — instead of surviving an ever-longer transcript.

Training stack and data scale

The thread emphasises that much of the behavioural prior can live in the harness interface — not only in massive task-specific datasets.

Benchmark results across eight retrieval suites

The paper evaluates web, finance, SEC, patent, and multi-hop QA settings (eight benchmarks total). Primary metric: curated recall — fraction of gold evidence documents present in the final curated set. Harness-1 averages 0.730 curated recall and 0.807 trajectory recall.

Harness-1 beats the next strongest open subagent (Tongyi DeepResearch 30B) by +11.4 curated-recall points. Among tested searchers, only Opus-4.6 scores higher on average curated recall; the launch claims Context-1-class cost and latency at near-frontier search quality. Frontier baselines run as zero-shot retrievers under the Context-1 harness in the paper setup.

Transfer and ablations

• In-domain vs Context-1: +7.9 curated-recall points on source-family benchmarks.
• Held-out transfer: +17.0 points — the thread’s headline generalisation result.
• Harness ablation: disabling harness mechanisms changes behaviour (shallower search, less verification, worse curation), not just information availability; BrowseComp+ recall drops ~12.2% relative in reported ablations.

Open release and local serving

# Install and serve with vLLM (Linux, Python 3.11+, CUDA GPU)
git clone https://github.com/pat-jj/harness-1
cd harness-1
uv sync --extra vllm
export HARNESS1_HF_MODEL=pat-jj/harness-1

# Smoke test
uv run python inference/hf_inference.py \
  --model pat-jj/harness-1 \
  --prompt "Briefly describe Harness-1."

# Full BrowseComp+ eval: see docs/run_vllm_browsecompplus.md
# Requires local BrowseComp+ files + Chroma retrieval collection

Weights: pat-jj/harness-1 on Hugging Face. Public eval path documented for BrowseComp+; in-domain web/SEC/patent corpora require building compatible Chroma indexes (Context-1 data-gen pipeline). Metrics exported include recall, trajectory recall, final-answer recall, and precision.

See Harness-1 in action

Video: demonstration from Patrick Jiang on X.

Performance summary

PaperBanana is Google Research’s agentic framework for turning methodology text into publication-ready diagrams and statistical plots; the community paperbanana package (MIT, llmsresearch/paperbanana) ships a full CLI, Python API, Gradio Studio, and MCP server on top of the arXiv paper’s five-agent design.

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
graph TD
  S[Method text + caption] --> R[Retriever]
  R --> P[Planner]
  P --> Y[Stylist]
  Y --> V[Visualizer]
  V --> C{Critic}
  C -->|Revise description| V
  C -->|Final image| O[Publication figure]

  classDef agent fill:#8B0000,color:#fff
  classDef hook fill:#189AB4,color:#fff
  classDef decision fill:#444,color:#fff

  class S,O agent
  class R,P,Y,V hook
  class C decision

The research problem: illustrations block AI scientists

LLM agents can draft papers and run experiments, but methodology diagrams still demand Illustrator, TikZ, or hours of manual layout. PaperBanana (arXiv:2601.23265, Google Cloud AI Research) formalises the task as mapping source context S and communicative intent C (the figure caption) to an image I, optionally guided by reference examples from a curated set. The official codebase is now branded PaperVizAgent at google-research/papervizagent; the paper name PaperBanana remains the common label.

Five agents: retrieve, plan, style, render, critique

Phase 1 is linear planning (Retriever → Planner → Stylist). Phase 2 loops Visualizer and Critic for T = 3 rounds by default. Google’s experiments use Gemini-3-Pro as VLM judge and Nano-Banana-Pro for image generation.

PaperBananaBench results

Google built PaperBananaBench from NeurIPS 2025 methodology figures: 584 curated samples split into 292 test and 292 reference cases. A VLM-as-a-Judge scores faithfulness, conciseness, readability, and aesthetics against human diagrams.

Reported gains vs vanilla image generation: +17.0% overall, with the largest jump in conciseness (+37.2%). Ablations show the Retriever supplies structural patterns, the Stylist boosts conciseness and aesthetics, and the Critic recovers faithfulness lost during styling.

Open-source implementation: what llmsresearch/paperbanana adds

Akshay Pachaar’s community repo is an unofficial MIT implementation (not affiliated with Google). It extends the published pipeline with optional Input Optimizer (context enricher + caption sharpener), 13 bundled reference diagrams, and multi-provider support:

Quick start

pip install paperbanana

# Methodology diagram (OpenAI or Gemini via .env)
paperbanana generate \
  --input method.txt \
  --caption "Overview of our framework" \
  --optimize --auto

# Statistical plot
paperbanana plot --data results.csv \
  --intent "Bar chart comparing accuracy across benchmarks"

# Batch manifest
paperbanana batch --manifest figures.yaml --optimize

# Local web UI
pip install 'paperbanana[studio]'
paperbanana studio

Providers include OpenAI (gpt-5.2 + gpt-image-1.5), Azure OpenAI / Foundry, Google Gemini (free tier via AI Studio), and OpenRouter. Install paperbanana[pdf] for PyMuPDF paper ingestion.

When to use diagrams vs plots

Performance summary