Audit agent fallback billing before scheduling work

An agent's main ChatGPT login does not prove that every side task or backup provider uses that subscription. Before scheduling work, audit the main model, auxiliary models, fallback chains and job overrides as separate routes. A successful chat is only the first check.

This guide uses Hermes Agent as a concrete configuration example, checked on 12 November 2026. It is an offline review procedure, not a claim that we ran a paid job or tested a provider outage. Browse the ChatGPT-compatible apps for other documented integrations.

Which routes should you inspect before enabling a schedule?

Make a routing inventory before editing anything. Record the provider, model, endpoint, account and intended payer for each row. Do not record passwords, keys or the contents of authentication files.

Route	Configuration to inspect	Decision to record
Main conversation	model	Subscription sign-in or API billing?
Compression, vision and titles	auxiliary	Inherit main model or use an override?
Main backup chain	fallback_providers, legacy fallback_model	Which alternative accounts are allowed?
Side-task backups	Each task's fallback_chain	Can a helper reach another paid provider?
Child agents and scheduled jobs	Delegation and job-specific settings	Does this run inherit the reviewed route?
External tools	Tool/service configuration	Who pays for search, images or hosting?

Hermes's provider reference documents a ChatGPT/Codex subscription provider and separately warns about auxiliary models. OpenAI's authentication guide distinguishes ChatGPT sign-in from API-key authentication. Keep that distinction in the inventory even when both routes display an OpenAI model name.

What does auxiliary auto actually mean?

According to the current configuration reference, auxiliary auto starts with the main chat model. Explicit provider/model settings override that choice, and a custom base_url directs a task to that endpoint. Do not read auto as a promise to find the cheapest model.

Here is a deliberately hypothetical configuration-review example. The main subscription connection is already configured elsewhere; this fragment does not install or authenticate anything:

# review-example.yaml, illustrative fragment, not a complete Hermes configuration
auxiliary:
  compression:
    provider: openrouter
    model: openai/gpt-4o-mini
  title_generation:
    provider: auto
    model: ""
fallback_providers:
  - provider: openrouter
    model: openai/gpt-4o-mini

The review finds two OpenRouter routes: compression and the main fallback. A ChatGPT login does not turn either into subscription-funded inference. The title task starts with the main route, but its failure path still needs checking.

If the intended policy is to start both helpers on the main route and remove that explicit backup, the corresponding review fragment becomes:

# review-example-revised.yaml, illustrative fragment only
auxiliary:
  compression:
    provider: auto
    model: ""
  title_generation:
    provider: auto
    model: ""
fallback_providers: []

This change removes the two routes shown, not every possible route in a real installation. Inspect the whole effective configuration for inherited values, custom endpoints, legacy keys and per-task chains. Preserve unrelated settings rather than replacing the entire file with a fragment.

Can a fallback change the account that pays?

Yes, when the configured backup uses a different funding route. Hermes's fallback guide describes main failover and independent auxiliary resolution. It also distinguishes unpinned scheduled jobs, which inherit the configured chain, from jobs pinned to their own provider/model/endpoint. Review the actual job, not just your interactive default.

Write the policy in plain language first: for example, “stop for review rather than use another paid provider.” Then check whether each configured route implements it. That sentence is a suggested operating policy, not a Hermes setting or a guarantee that deleting one YAML key enforces it everywhere.

Treat reliability and spending permission as separate decisions. A backup can be desirable for urgent work, but it should have a named account owner and an accepted spending boundary. Do not add credentials merely to make a red warning disappear.

How should you verify a changed configuration?

The model configuration guide describes inspecting the current model with hermes config get model --json and hermes status, and notes that configuration changes can require a new session. Use its current instructions for your installed surface.

For a controlled verification, choose a non-sensitive, read-only task. Record the installed version, effective route, start/end usage and any warning. Test one helper at a time. A short prompt that never triggers compression cannot establish how compression is funded.

Do not deliberately exhaust a subscription or revoke a working login just to test failure handling on a production schedule. Use a separate test profile and explicit spending permission for any authenticated failure experiment. Until that evidence exists, label the audit configuration-reviewed, not runtime-verified.

What belongs in the scheduling sign-off?

Keep a short record containing the intended payer, permitted backup routes, enabled helpers, job overrides, external tools and the person who can stop the run. State what remains untested. Recheck it after changing providers or importing another configuration.

For initial authentication, use Hermes on your ChatGPT plan. For a failing sign-in, use the login diagnosis guide. For the broader budget, see BYOK versus subscription costs. This audit answers a narrower question: which paths can this particular scheduled task take, and have you accepted each payer?