AI providers & agent settings

Singularity does not call provider APIs directly. It prepares the ticket, starts a local process and drives the selected provider’s CLI. First install that CLI using its vendor’s recommended method, open a terminal, run it once and complete authentication.

The simplest check is to ask the CLI for a response from a project directory. If it requests sign-in, folder trust or an update, handle that before starting a Singularity ticket.

Install Claude Code, run claude, then follow Anthropic’s interactive sign-in. The model list (Auto plus the Claude models available to your account) is loaded from the provider catalogue, so it can change without this page being updated.

Its tab controls permission mode, effort, extended or adaptive thinking, Opus-only fast mode, prompt caching, extended context, memory, thinking and output limits, and agent teams.

Install the Codex CLI, run codex and sign in to your OpenAI account through the offered flow. The models shown come from the Codex catalogue available on the machine, alongside Auto.

The tab exposes personality, approval policy, sandbox mode, reasoning effort and summary, plus the editor used to open references. Security choices change the process permissions: prefer workspace access unless broader access is explicitly required.

Install the GitHub Copilot CLI, run copilot and authenticate with GitHub. Your account and organisation must allow Copilot. Auto and the models returned by Copilot then become available.

The tab controls approval mode (suggest, auto-edit or full-auto), web search, plan mode and delegation. Start with suggest mode on a sensitive repository.

Install Cursor and its agent CLI, then run agent to complete sign-in. Auto and the models published by Cursor populate the selector. A key can also be entered in the tab; its field is masked.

Settings cover permissions (force, shell or plan), shell-mode prompts, web search and session-history persistence.

Install Gemini CLI, run gemini and choose the offered Google sign-in. Auto and the permitted Gemini models are discovered through the catalogue.

This is the most detailed tab: approvals, attempt and turn limits, session compression and retention, loop detection, plan routing, overage strategy, text or JSON output, sandbox, Vim mode, automatic updates, notifications and IDE integration.

Install the Mistral Vibe CLI and verify that it starts from a terminal. Then configure a profile or a Mistral key in the tab’s masked field. Auto and the models returned by the provider are offered.

You can enable offline models, choose YOLO, ask or plan permission mode, and control web search and history persistence.

Install Ollama, start its local daemon and verify ollama list. Singularity uses http://127.0.0.1:11434 by default and points Claude Code at that server. The tab can search, pull, delete and refresh models; it also recommends models suited to available RAM and CPU through llmfit or a heuristic.

Pull a model before selecting it. A small quantised model is faster and uses less memory, but follows long instructions and complex refactors less reliably. CPU-only generation is substantially slower; insufficient RAM or GPU memory can make a model impractical. Keep a remote provider available for demanding work.

The provider setting defines the default model for new agents in the workspace. Auto — pick based on context lets prequalification choose an eligible model for the task.

The ticket’s agent selector can override it for that run: reserve a stronger model for a migration or use a faster one for a mechanical fix. The ticket choice takes precedence without changing the workspace default.

Under “Models for automatic selection”, uncheck a model to prevent Auto from choosing it. It remains available for manual selection. Use this to avoid a model that is too expensive, slow, deprecated or unsuitable for your repository.

When a provider exposes reasoning depth, you can also remove levels from ticket selectors. This can prevent minimal reasoning on critical code or maximum reasoning on short tasks. Exclusions narrow automatic choices; they uninstall nothing.

Measure a ticket batch by recording usage for the same scope before and after execution, then separate variable spend, subscriptions and human time. Tokens and session estimates do not establish the amount billed. No per-ticket cost or savings are guaranteed.

1. Choose a control task. Use a representative small fix with a starting commit, fixed data, acceptance criteria and tests. List all batch tickets, including failures. Compare workflows from the same starting state.
2. Record the configuration. Note provider, CLI version, actual model (including Auto switches), effort, agent count and subscription or API billing. Identify the billing account/project without recording secrets.
3. Capture before. Save timestamps and timezone, counter source, period, currency, per-model tokens and cache data where available. Isolate other account activity or declare attribution unavailable. In interactive Claude Code, use /usage in the relevant session. For an orchestrated batch without access to that session, use the provider record for an isolated scope, not a newly opened empty CLI session.
4. Run and log. Include failures, retries, subagents and fixes after review. Time preparation, machine waiting, human review and integration separately; session wall time is not human working time.
5. Capture after. Wait for agents and counters to finish updating. Save capture time and covered window using the same source and scope. Archive each session before resets; a negative delta or changed period invalidates subtraction.
6. Reconcile. Subtract before from after in the same unit. Reconcile API estimates with provider billing when available. Sum only disjoint periods; do not double-count parent and subagent totals. Report attempted, accepted and rejected tickets, quality and review time. A per-accepted-ticket average applies only to this batch and includes failed attempts in its numerator.

How do you track Claude Code usage?

The official Claude Code costs documentation, checked on 11 October 2026, describes /usage: Session estimates token cost; plan bars track subscription limits. The session amount is not a Pro or Max subscription bill. For API billing, check the billed account’s Claude Console Usage view (sign-in required). Check command availability in your CLI version and record freshness.

Illustrative example: three tickets, not a benchmark

Fictional figures, not measured. An isolated API scope shows cumulative provider amounts of USD 12.00 at 10:00 UTC and USD 13.80 at 10:40 UTC on 11 October 2026, in the same period and currency: an illustrative USD 1.80 delta. The fictional log records three tickets attempted, two accepted, one rejected, four attempts and 18 minutes of review. A real record must include the actual model and CLI version; this example ran no model.

If the records are complete and exclusive to the batch, 1.80 / 2 = USD 0.90 per accepted ticket for this example only, including the failure. This is neither a price nor a forecast. For a subscription, record quota changes and actual billed overages instead; do not convert quota percentages into money. Allocating a share of a subscription is an explicit accounting convention, not observed marginal spend.

Copyable measurement record

Batch / tickets / starting commit:
Criteria / tests / data:
Provider / CLI version / model(s) / effort / agents:
Subscription or API / billing scope:
Source / period / timezone / currency / taxes:
Before: timestamp, amount or quota, available tokens/cache
After: timestamp, amount or quota, available tokens/cache
Attempts / errors / retries / accepted and rejected tickets:
Preparation / waiting / review / integration minutes:
Observed delta / invoice reconciliation / redacted evidence:
Limits: concurrent use, delays, resets, cache, excluded fees

Cache, contracted rates, currencies, taxes, credits and other devices can prevent exact attribution. Mark missing counters “unavailable”, never zero. Keep the Singularity licence, provider subscriptions, overages, remote execution and human time on separate lines without counting included usage twice. See pricing and provider costs and use this record with the Claude Code comparison protocol.

Singularity does not upload your code to an AI provider by itself. Only the CLIs you installed and configured communicate with external services, under their own terms, settings and retention policies. Prompts, file excerpts and tool results required by the agent may therefore pass through the selected provider.

With Ollama on the local address and a locally executed model, inference stays on the computer, although the initial model download contacts the Ollama registry. A remote Ollama endpoint or cloud model is no longer local. See the data policies for all seven integrations. Always check the configured URL and agent permissions before handling a confidential repository.

Retention depends on the provider, plan and account actually used by the CLI. This review of vendor documentation, checked on 11 October 2026, helps locate the applicable policy; it is neither a Singularity commitment nor a review of your contract.

Before handling a confidential repository, check authentication, endpoint, model, sharing options and organization policies. No training, no retention and local history are separate matters. No universal retention period is inferred here: consult the sources for legal and abuse exceptions, voluntary feedback and stateful services. Web tools, extensions/MCP, CLI logs and histories may have their own destinations and retention, even with local inference.