PackagesCity CLI

Models and Tables

Use downcity to inspect models, schema, and table data, and understand how that connects to the City data layer.

The CLI is most often used for two things:

  • models
  • tables

Why models are a first debugging stop

Many "the AI path is wrong" issues are not provider failures. They are model-layer issues:

  • was the model actually registered?
  • is the default model the one you expected?
  • do the stored model rows look correct?

Why tables matter just as much

When you debug runtime behavior, you usually end up checking tables such as:

  • cities
  • env
  • usage event tables
  • accounts-related tables
  • entitlement and webhook tables

Common model-focused entry points

city
city federation login
city federation status

Use these commands to:

  • inspect models exposed by Federation AIService
  • select a City base and sign in with City
  • confirm local Agents can resolve City connection settings before startup

Common table-debugging scenarios

Scenario 1: did a service really create or write data?

If you enabled accounts, usage, or Stripe payment services, what matters is whether your actual City has the tables and rows you expect.

Scenario 2: why does usage, payment, or auth look wrong?

Looking at the tables first is often the fastest way to distinguish:

  • the call never happened
  • the service was not enabled
  • the tables were not created
  • the write failed

A common workflow

city
# or start a local agent
city agent start .
city federation status

Then continue inside the interactive panel to inspect:

  • tables
  • schema
  • rows

Relationship with the City data layer

The CLI does not define the data model. It exposes the runtime data layer that City already owns.

That is why this page fits naturally with Store and Table:

  • @downcity/city owns the controlled data layer
  • downcity owns the human inspection and debugging entry

Common misunderstandings

Table inspection is not "low-level debugging"

For City, services, usage, and payment, table facts are often the fastest truth source.

The CLI is not a general-purpose DB IDE

It is better understood as a City-oriented operations tool.

Looking at models alone is not always enough

Models, service tables, usage events, and env data can all affect one city flow, so you often need to inspect them together.

CLI Quickstart

First-time Downcity CLI usage starts by separating fed/downfed from city/downcity.

Operations and Debugging

The boundary between fed, city, Admin City, and direct database inspection, and when the CLI is the better tool.

Table of Contents

Why models are a first debugging stopWhy tables matter just as muchCommon model-focused entry pointsCommon table-debugging scenariosScenario 1: did a service really create or write data?Scenario 2: why does usage, payment, or auth look wrong?A common workflowRelationship with the City data layerCommon misunderstandingsTable inspection is not "low-level debugging"The CLI is not a general-purpose DB IDELooking at models alone is not always enoughRead next