# LiveObjects pricing How LiveObjects operations contribute to your message count and strategies to optimize costs. Ably bills LiveObjects operations using ObjectMessages. An ObjectMessage is the unit of change in LiveObjects. Each state mutation, such as setting a key, incrementing a counter, or creating an object, generates one or more ObjectMessages. Each ObjectMessage follows the standard inbound/outbound counting pattern. ## LiveObjects operations The following table shows how LiveObjects operations contribute to your message count: | Operation | Messages counted | | --- | --- | | [LiveMap](https://ably.com/docs/liveobjects/map.md) || | LiveMap set or remove | 1 inbound message per operation | | LiveMap create (shallow) | 2 inbound messages (create + assign) | | [LiveCounter](https://ably.com/docs/liveobjects/counter.md) || | LiveCounter increment or decrement | 1 inbound message | | LiveCounter create | 2 inbound messages (create + assign) | | ObjectMessage delivery | 1 outbound message per connected client | | [Synchronization](#synchronization) | 1 outbound message per object synchronized | | [REST API](#rest-api) fetch | 1 outbound message per object in response | | [Batch](https://ably.com/docs/liveobjects/batch.md) operation | 1 inbound message per operation in the batch | Nested object creation generates additional messages for each nested object. ## Channels Each LiveObjects channel contributes to your [channel count](https://ably.com/docs/platform/pricing.md#channels). Subscribing to updates does not affect the number of messages received by a client. Any client attached to a channel with the `object-subscribe` capability automatically receives all object messages for that channel. Subscribing to updates on an object adds a listener that is called whenever the client receives updates for that object. ## Connections Ably bills each connected client for [connection minutes](https://ably.com/docs/platform/pricing.md#connections). A connection-minute is counted for every minute a client maintains an open connection, regardless of activity. Clients that remain connected but idle still accrue connection minutes. ## Cost optimization ### Prefer flat data structures Setting a primitive value on a LiveMap costs one message. Creating a nested LiveMap costs two or more messages (one to create the object, one to assign it), plus additional messages for each level of nesting. Flatten your data model where possible to reduce the number of messages per update. ### Minimize objects per channel Each object on a channel is synchronized when a client attaches or resynchronizes. Fewer objects per channel reduces the cost of synchronization. Distribute objects across channels based on which clients need access to them. ## Synchronization During initial synchronization and resynchronization, Ably sends each object on the channel as a message. For example, if a channel contains 10 objects (such as `LiveMap` and `LiveCounter` instances), a client attaching to the channel receives 10 messages during synchronization. Similarly, if a client becomes disconnected and needs to resynchronize, it receives messages for each object that needs to be synchronized. Only [reachable](https://ably.com/docs/liveobjects/concepts/objects.md#reachability) objects are counted. Ably may send [tombstone](https://ably.com/docs/liveobjects/concepts/objects.md#tombstones) objects to the client, but these will not count towards your usage. ## REST API The [LiveObjects REST API](https://ably.com/docs/liveobjects/rest-api-usage.md) also counts messages for operations performed. When fetching objects via the REST API, each instance of an [object type](https://ably.com/docs/liveobjects/concepts/objects.md#object-types) included in the response is counted as one message. Each operation published via the REST API counts as one message. When creating objects using the `path` field, the server constructs two messages (a create operation and a `MAP_SET` operation to assign it). ## Documentation Index To discover additional Ably documentation: 1. Fetch [llms.txt](https://ably.com/llms.txt) for the canonical list of available pages. 2. Identify relevant URLs from that index. 3. Fetch target pages as needed. Avoid using assumed or outdated documentation paths.