Owner demand by metro: where Cybercab owners have reserved stalls

Stall reservations by metro across the 21 US markets DockDuty sells, from the same dated snapshot every page on this site is built from. These are reservations, not vehicles: a number here is a refundable deposit naming a preferred market, never a car on site, a customer being served or an operating stall. No DockDuty depot is operating yet.

Aggregates only, no owner data, ever · Maintained by DockDuty’s founders (who we are, how this site is researched and corrected) · CC BY 4.0 · Part of DockDuty Data

Stall reservations by market

One row per market DockDuty sells, in the order of the network market table. A market at 0 is one no owner has elected yet, not one ruled out; every row is open for reservations. Each market name links to its market page, and each row has a permalink (for example /owner-demand.html#phoenix).

Cite this dataset

@misc{dockduty2026ownerdemand,
  author       = {{Dock Duty LLC}},
  title        = {Owner Demand by Metro: Cybercab stall reservations, as of September 27, 2026},
  year         = {2026},
  howpublished = {\url{https://dockduty.com/owner-demand.html}},
  note         = {Dataset, CC BY 4.0. Snapshot generated 2026-09-27T14:00:28.507Z}
}

Methodology

What counts

One stall reservation is one Cybercab stall reserved through the reserve flow with a refundable deposit that has been paid or is clearing. The count uses the same status gate the checkout uses to hold a stall, so a reservation here is a reservation the order book also holds. The deposit names a preferred market, and that election is what puts the stall in a metro’s row.

What is excluded

Unpaid, failed, cancelled and refunded checkouts never count, and a refund removes the stall from every number on this page at the next snapshot. Two internal test reservations placed on September 20, 2026 (one stall each, never paid) were cancelled on September 23, 2026 and are excluded by status like any other cancelled checkout.

What a reservation is, and is not

A reservation is a refundable deposit that holds a place in the order book and elects a preferred market. It is not an operating stall, not a vehicle on site and not a customer being served. No DockDuty depot is operating anywhere, no depot lease has been executed, and Depot #1 is targeted for Orlando in Q4 2026. Tesla has not published the terms under which a privately owned Cybercab would earn on its network; nothing here assumes them.

The two books

The founding class was a fixed book that closed with all founding stalls reserved (the close date is under the totals above); the totals show it as stalls reserved out of stalls offered. Priority Owner reservations have been taken since and remain open. The totals above show both books; the market table does not split them, because a per-market split of the smaller book would start to identify individual orders.

A metro at zero

A market showing 0 is one no owner has elected yet. It is not a market DockDuty has ruled out, and every row in the table is open for reservations today. Whether a market moves from “Demand open” to “Next on roadmap” is a roadmap decision recorded in the network market table, not a threshold this count triggers.

Aggregates only

This dataset publishes counts and nothing else: no owner or account counts by market, no per-market largest order, no order sizes, no names, no dates of individual reservations. The largest single reservation is published as one network-wide figure. Nothing on this page can be traced to a person, and no field will be added that could be.

Cadence

The snapshot behind this page, traction.json, is refreshed by a weekly scheduled run (a reviewed pull request, opened only when the counts changed) and whenever a release runs the refresh block in the README. Its generatedAt timestamp (copied into generated_at in the JSON download) is the authoritative time the counts were taken; the date shown on this page is that timestamp’s UTC calendar date. The page also carries a browser-side refresh from the live API; when it succeeds, the dated line is replaced by a live label.

Limitations

• Counts are stall reservations. They are not vehicles, customers, revenue, or any measure of a depot’s capacity or progress.
• The live API serves through a short edge cache (about 30 seconds), so a number read from it can trail a payment or refund by that long.
• A refund lowers a count. A number cited from an earlier snapshot can therefore be higher than the current one; cite the snapshot date.
• A market election is the owner’s stated preference at checkout. It says where an owner wants a stall, not where a depot will be.
• DockDuty sells the stalls this dataset counts, so it is not a neutral party. The dataset reports DockDuty’s own order book, and nothing in it is a forecast or investment advice.

Sources

• The public inventory API: the read-only endpoint that reports the counts and the per-market breakdown. Capacity at checkout is enforced separately by the reserve flow from fresh database state, using the same paid-or-clearing status set this count uses.
• traction.json: the dated snapshot of that API that every count on this site is written from.
• The order book: the public ledger of reservations, with the live count.
• The network market table: the single source of each market’s status, coordinates and reserve link.
• The 21 market pages, linked from each row, for what each market’s status means on the ground.

Definitions

Stall reservation

One stall reservation is one Cybercab stall reserved with a paid or clearing $450 refundable deposit that names a preferred market. Reservations are not vehicles on site, not customers and not operating stalls. Unpaid, failed, cancelled and refunded checkouts never count.

Counted statuses

paid, processing. A checkout counts from the moment its deposit is paid or clearing, which is the same gate the reserve flow uses to hold the stall.

Excluded statuses

pending, failed, cancelled, refunded. An unpaid, failed, cancelled or refunded checkout never counts, and a refund removes a stall from every number on this page at the next snapshot.

Founding and Priority Owner

The two reservation books. 50 of 50 founding stalls are reserved and that class closed on September 5, 2026; 62 Priority Owner stalls have been reserved since. The largest single reservation on either book is 13 stalls, published network-wide only.

status

The market table’s vocabulary for where a market stands, one value per row:

• in-development (In development): Site selection is underway. No lease has been signed and nothing is under construction. Depot #1 is targeted for Q4 2026.
• priority (Next on roadmap): Named on the published roadmap after Orlando. No site, lease or date.
• demand (Demand open): Owners can reserve and name this market. That records demand; it is not a depot project or a commitment to open.

depot_status

Derived from status, so a reader can filter on the ground layer without parsing labels:

• site-selection: Site selection underway, no lease executed, nothing built.
• none: No site under evaluation.

Columns

market, slug, state, lat, lon, status, status_label, depot_status, stall_reservations, market_page, reserve_url, as_of, and in the CSV only source_url (the live API every row is drawn from). lat and lon are the metro centroids the network map plots, not depot sites; no DockDuty depot exists yet.

Corrections

Found a number that does not match the order book, a market that is missing, or a definition that reads wrong? Write to support@dockduty.com and say which row or field. Corrections follow the editorial policy and are logged in the change log below. A count that changed because a deposit was paid or refunded is not a correction; the next snapshot carries it.

Change log

September 27, 2026

First publication. One row per market in the network market table, joined to the traction.json snapshot; counts are stall reservations with a paid or clearing deposit, network-wide totals from the same file.

The change log is written from the same file that writes the table and the downloads, so the method cannot change without an entry here. Routine snapshot refreshes are not logged; the date line and generated_at carry them.