bug: tutorial city has excess agent use even with no beads

[dlstadther]

Before you continue

• I searched existing issues and did not find a duplicate.
• I read the relevant docs and contributor guidance.

Gas City version

0.14.0

Environment

mac, zsh

Reproduction

1. gc init ~/gc-test
2. gc start
3. wait a short time
4. observe agent sessions (2 mayor sessions; then 3 dogs looping new sessions)
5. depending on your usage plan, session usage will get consumed fairly quickly (Claude Pro plan session used 75% in ~10 minutes)

Expected behavior

No rigs and no user-created beads shouldn't consume excess usage. Or at least the "tutorial" config template should be light enough to allow users to make mistakes and get the hang of gascity.

Actual behavior

Claude session limits are hit in a matter of minutes (on Pro plan). (Yes, this is a small plan which wouldn't be suitable for serious gascity usage, but there's no reason why this shouldn't be acceptable for a tutorial-level trial and small experimentation)

Logs, screenshots, or traces

√ ~/gc-tutorial > gc version
0.14.0

√ ~/gc-tutorial > gc init ~/gc-test
Welcome to Gas City SDK!

Choose a config template:
  1. tutorial  — default coding agent (default)
  2. gastown   — multi-agent orchestration pack
  3. custom    — empty workspace, configure it yourself
Template [1]:

Choose your coding agent:
  1. Claude Code  (default)
  2. Codex CLI
  3. Gemini CLI
  4. Cursor Agent
  5. GitHub Copilot
  6. Sourcegraph AMP
  7. OpenCode
  8. Auggie CLI
  9. Pi Coding Agent
  10. Oh My Pi (OMP)
  11. Custom command
Agent [1]:
[1/8] Creating runtime scaffold
[2/8] Installing hooks (Claude Code)
[3/8] Writing default prompts
[4/8] Writing default formulas
[5/8] Writing city configuration
Created tutorial config (Level 1) in "gc-test".
[6/8] Checking provider readiness
[7/8] Registering city with supervisor
Registered city 'gc-test' (/Users/dlstadther/gc-test)
Installed launchd service: /Users/dlstadther/Library/LaunchAgents/com.gascity.supervisor.plist
[8/8] Waiting for supervisor to start city

√ ~/gc-tutorial > cat city.toml
[workspace]
name = "gc-tutorial"
provider = "claude"

[[agent]]
name = "mayor"
prompt_template = "prompts/mayor.md"

[[named_session]]
template = "mayor"
mode = "always"

√ ~/gc-tutorial > echo "starting at 25% usage"
starting at 25% usage

√ ~/gc-tutorial > gc start
Registered city 'gc-tutorial' (/Users/dlstadther/gc-tutorial)
Installed launchd service: /Users/dlstadther/Library/LaunchAgents/com.gascity.supervisor.plist
[8/8] Waiting for supervisor to start city
City started under supervisor.

√ ~/gc-tutorial > gc stop
Unregistered city 'gc-tutorial' (/Users/dlstadther/gc-tutorial)
Reconciliation triggered.
City stopped.

Additional context

agentsview for this local gc-test project

[dlstadther]

Just realized I ran gc start in the wrong directory. The details above describe the problem, but did a poor job at showing the re-production of it.

The gc-tutorial directory was created the exact same as gc-test and had zero direct interactions with the mayor.

Interestingly, i ran gc start from the gc-tutorial directory, but agentsview still shows agent sessions occurring in gc-test. Does this mean that gc start enables the supervisor for ANY and ALL city configs?

[julianknutsen]

If you have additional cities registered in ~/.gc/cities.toml, those will be reconciled during the supervisor startup. For testing there is a foreground one you can run:

Local per-city controller (legacy standalone, one process per city):
gc start --foreground [path]   # or --controller (alias)

If there are cities you don't want to start you can use this:

gc suspend [path]      # sets workspace.suspended = true in city.toml
gc resume [path]       # clears suspended + halt flag

Great feedback on the "if I haven't configured anything, I expect no tokens to be consumed".

[dlstadther]

If you have additional cities registered in ~/.gc/cities.toml, those will be reconciled during the supervisor startup. For testing there is a foreground one you can run:

Local per-city controller (legacy standalone, one process per city):
gc start --foreground [path]   # or --controller (alias)

If there are cities you don't want to start you can use this:

gc suspend [path]      # sets workspace.suspended = true in city.toml
gc resume [path]       # clears suspended + halt flag

To clarify, i had ~/gc-tutorial/ and ~/gc-test/ with their own city.toml. Running gc start appears to allow any city on the machine to run. I think that's what you're saying, just clarifying that there is no cities.toml file anywhere, but rather multiple separate city.toml.

Great feedback on the "if I haven't configured anything, I expect no tokens to be consumed".

Thanks. Do you need me to file a specific thing in Wasteland or here for this exact statement?

[dlstadther]

Actually, i understand what you mean now; i didn't realize on gc init a ~/.gc/ directory is created and a cities.toml file is maintained there.

[dlstadther]

Another follow-up (perhaps a separate item that deserves its own Issue):

• gc stop will only stop the city for the CWD

This feels counter-intuitive to gc start. If gc start starts the supervisor for ALL enabled cities, I would expect gc stop to do the inverse. However, gc stop only appears to stop the city in the CWD.