What problem are you trying to solve?
not here to write another complaint about a 'free' service to just immediately get relegated as triage.
Before posting this a scanned ~220 issues and about 10% were user frustrations; primarily about the difference between their (maybe unrealistic) expectations and what they experienced. I have also experienced some frustrations while using the service(through the desktop app). All my frustrations have been directly from the user-facing messaging/information exposure to be not-representative or incomplete compared to what i have been actively affected by.
One way an Org can limit user frictions is with messaging consistency to help the user establish realistic expectations.
What would you like to happen?
I suggest a messaging consistency pass and maybe set up the framework for automating this in the future because you are sometimes going to change your terms/services and the messaging is in many places.
Now that your are experimenting with controlling your service-offer-deliverables in an increasingly granular resolution via multiple dimensions/axes: Freebucks flat currency denomination/and rates per model, Sessions count: daily/weekly/monthly/concurrently, promotional offers and peak pricing, tabs newly enforced 1 tab-per-model, and more,
How to offer more clarity to the user?
Here are a few specific examples (may become irrelevant as you are updating daily):
When there is an error message to make the block to UX explicitly clear:
When a model is unavailable. "Why" is it not available rather than offering users to restart app or pay more to unlock etc.
if limiting free users to 1 tab at a time of a model(example: GLM 5.3 flash)
1/3 tabs doesn't sufficiently communicate that each model is limited to 1 tab.
I appreciate you are updating your app and services quite rapidly now and are adapting the usage/pricing offer to make the business viable. At the same time there is a way to make it less friction for current users, and in an automated way for yourself.
Area
CLI (terminal client)
Contribution
What problem are you trying to solve?
not here to write another complaint about a 'free' service to just immediately get relegated as triage.
Before posting this a scanned ~220 issues and about 10% were user frustrations; primarily about the difference between their (maybe unrealistic) expectations and what they experienced. I have also experienced some frustrations while using the service(through the desktop app). All my frustrations have been directly from the user-facing messaging/information exposure to be not-representative or incomplete compared to what i have been actively affected by.
One way an Org can limit user frictions is with messaging consistency to help the user establish realistic expectations.
What would you like to happen?
I suggest a messaging consistency pass and maybe set up the framework for automating this in the future because you are sometimes going to change your terms/services and the messaging is in many places.
Now that your are experimenting with controlling your service-offer-deliverables in an increasingly granular resolution via multiple dimensions/axes: Freebucks flat currency denomination/and rates per model, Sessions count: daily/weekly/monthly/concurrently, promotional offers and peak pricing, tabs newly enforced 1 tab-per-model, and more,
How to offer more clarity to the user?
Here are a few specific examples (may become irrelevant as you are updating daily):
When there is an error message to make the block to UX explicitly clear:
When a model is unavailable. "Why" is it not available rather than offering users to restart app or pay more to unlock etc.
if limiting free users to 1 tab at a time of a model(example: GLM 5.3 flash)
1/3 tabs doesn't sufficiently communicate that each model is limited to 1 tab.
I appreciate you are updating your app and services quite rapidly now and are adapting the usage/pricing offer to make the business viable. At the same time there is a way to make it less friction for current users, and in an automated way for yourself.
Area
CLI (terminal client)
Contribution