Scope decision: minimal CLI for one-off scripted prompts?

Motivation

Simon Willison's llm is CLI-first — cat file.py | llm "explain this" — and that shell-scriptability is a large part of its ~500k monthly downloads; it owns the "one-off scripted prompt" niche. chatlas has Chat.console() (chatlas/_chat.py, an interactive REPL loop over input()/chat()), but no non-interactive shell entry point, and no console-script registered in pyproject.toml. ellmer, the R sibling, has no CLI at all — R isn't typically invoked as a Unix filter the way Python scripts are, so this isn't something we can just "align with ellmer" on. This is filed as an open question, not a commitment.

Proposed approach (sketch, for discussion)

A minimal chatlas console-script, thin enough to not become a second product:

echo "def f(x): return x*2" | chatlas -m anthropic/claude-sonnet-4-6 "review this"
chatlas "what is 2+2"                       # default provider/model via ChatAuto()
chatlas -m google "summarize" --schema mymod:Answer < notes.txt

Built directly on ChatAuto (chatlas/_auto.py), which already resolves "provider/model" strings and the CHATLAS_CHAT_PROVIDER_MODEL env var — the CLI would just be an argparse shim over it:

• Positional prompt argument, or read from stdin if piped (mirroring cat file | llm "...").
• -m/--model maps straight to ChatAuto's provider_model positional arg.
• --schema module:ClassName importable Pydantic model, feeding chat_structured(data_model=...).
• No history/session persistence, no fragments/templates system, no plugin ecosystem — those are exactly the things that make llm a bigger maintenance surface, and are explicitly out of scope for a v1.

Alternatives / prior art

• Status quo: users write a 5-line Python script themselves (ChatAuto().chat(sys.stdin.read())). Arguably that's already "minimal enough" and keeps chatlas a library, not an app.
• Point people at llm: it already does this well, is provider-pluggable, and is actively maintained — a chatlas CLI could just be redundant surface area with a different provider list to keep in sync.
• ellmer has no CLI; there's no cross-project precedent to inherit here either way.

Arguments for

• Trivial surface area if scoped to "single prompt in, text out."
• Adoption funnel — a pip install chatlas shell one-liner is a low-friction discovery path for Python + posit users.
• ChatAuto already does the heavy lifting; this is largely an argparse wrapper.

Arguments against

• llm already owns this niche well; differentiation is unclear.
• Any CLI, once shipped, accrues feature requests (session history, output formats, piping semantics) that pull toward llm-scope.
• Not ellmer-aligned (no R precedent), and chatlas has generally stayed close to ellmer's API surface philosophy.

Open questions

Is this worth doing at all, and if so, how minimal can v1 stay? Maintainer input requested before any implementation work starts.

Drafted from a competitive review of llm / Pydantic AI / LangChain / LiteLLM (July 2026); filed via Claude Code on behalf of @cpsievert.

Start by reading chatlas/_chat.py, chatlas/_auto.py, and pyproject.toml, then review the proposed commands and listed alternatives. Done means maintainers decide whether a CLI is worthwhile and record a minimal v1 scope or close the proposal; implementation should wait for that decision.