Host and co-host on X Spaces: what each one can do

Running an X Space with other people eventually stops you on the same question: am I allowed to do this? You want to approve a speaker request and cannot find the control. You summon a bot and it declines.

There are three roles, and they can do different things.

The three roles

Host (creator). The person who made the Space. In the X API this is creator_id, and there is exactly one. It cannot be handed to somebody else partway through.

The host can end the Space, manage speakers, and name co-hosts.

Co-host. Named by the host, and recorded in host_ids. There can be several.

A co-host can do what running the room needs — approving speaker requests, muting speakers. They cannot end the Space.

Speaker and listener. Speakers can talk; listeners can only listen. Neither has any control over the room.

A listener can send a speaker request. Approving those is the host's and co-hosts' job.

Naming a co-host

Co-hosts are named by the host while the Space is running, chosen from the people who are already speakers.

The person named receives an invitation, and becomes a co-host by accepting it. Until they accept, they are not one — so "I made them a co-host but they cannot do anything" usually means the invitation is still sitting there.

For a long Space, or one where the host may step away, naming a co-host early keeps things moving. It also covers the host's connection dropping.

Who may summon a bot

For a bot like Comeyomi, summoning is restricted.

Only the host or a co-host of that Space can summon Comeyomi. A summon posted by a listener or a speaker does not bring it in.

That restriction is deliberate. Summoning puts third-party audio into the Space, so it belongs to the people responsible for running it.

If you summoned it and it did not come, check first whether you are host or co-host. If you have not accepted a co-host invitation, X may show you on the running side while your permissions are still those of a speaker.

Who may change the bot's settings

The same split applies to the bot's settings once it has joined. Anything affecting the whole Space is host and co-host only.

Action	Anyone	Host / co-host
Change your own reading voice	●
Change the Space's default voice		●
Reading speed and speech volume	check only	change
Effect volume	check only	change
Conversation wait	check only	change
Timer		●

Settings that affect only you are open to everyone; settings everyone hears belong to the people running the room.

When an account without permission tries to change something, the bot says so and the setting stays as it was. It is not an error, so it is easy to think you changed something when you did not.

Where people get stuck

Speaker requests go unnoticed. Concentrating on the conversation means missing the screen. Naming a co-host and splitting the approvals is the practical answer.

With a reading bot, having requests announced aloud means noticing without looking.

The host steps away and the room stalls. With a co-host, it carries on. Without one, nobody can add speakers.

Only the host can end it. A co-host cannot. If the host drops and does not return, the Space stays open.

Hosting from a private account. A private account may need the bot to be following it before the bot can join at all. Conditions differ per tool, so check before you go live rather than during.

A shape that works

For a Space that will fill up:

• The host concentrates on running it and talking
• One or two co-hosts handle speaker request approvals
• The bot's settings are something a co-host can change too
• The reading mode changes as the speakers change

Deciding the roles in advance removes the pauses where everyone waits to see who will do something. Designing the permissions is the preparation for that.

---

How to summon Comeyomi is in the usage guide; the settings are in reading settings.