Agent.Space Share and Flex solve different budget problems. Choose Share when you expect to use supported OpenAI models regularly and want a fixed allowance that follows its native usage cycle. Choose Flex when you want metered access to other available models and prefer to pay only for the requests you make.
You do not have to treat this as an either-or decision. A common setup is Share for a steady GPT workflow and Flex for occasional work on other model families. The important constraint is that the selected model determines which balance funds a request: Share and Flex stay separate and do not automatically cover each other.
This comparison reflects the Agent.Space product contract on August 28, 2026. Check the live pricing and model list before purchasing because available models and listed rates can change.
Share vs Flex at a glance
The table is a decision framework, not a promise that every model is always available. The current model selector and pricing page remain the source of truth.
What Agent.Space Share is
Share provides fixed GPT capacity through an Agent.Space plan. The allowance is benchmarked to the corresponding Agent service and follows that service's native usage cycle. When the cycle resets, the plan allowance resets; unused allowance does not become Flex or carry forward as a cash-like balance.
That structure works best when your workload is recurring. Examples include:
- using Codex for development on most working days;
- keeping a consistent OpenAI-model workflow across several projects;
- preferring a known plan tier over tracking the cost of every request.
Share is not an upstream provider account, a shared login, or a resale of an official subscription. Agent.Space manages access and resource matching around supported Agent harnesses and models. If you need the complete native interface or an upstream-only feature, evaluate the official service separately.
What Agent.Space Flex is
Flex is a metered balance for other models currently available through Agent.Space. Rather than replenishing on a plan cycle, it is deducted according to the selected model's listed rate. This makes it useful when model choice or request volume varies.
Purchased Flex does not expire. Promotional Flex is different: a bonus can have its own validity period, so do not plan long-term usage from a promotional balance without checking its terms.
Flex tends to fit workloads such as:
- trying a model for one bounded task before making it part of a regular workflow;
- routing different tasks to Kimi, GLM, MiniMax, DeepSeek, Claude, Grok, or another currently supported model;
- maintaining a backup pool for occasional non-OpenAI requests;
- paying for irregular use without committing to a fixed cycle.
Do not use an old screenshot or a hard-coded price table to estimate current spend. Model availability and rates are dynamic, so calculate from the live model list and the size of the work you actually plan to run.
Five questions that make the choice easier
1. Which model do you need?
Start here because the model determines the funding source. Supported OpenAI models use Share allowance. Other available models use Flex. Choosing a balance first and then trying to force an incompatible model onto it leads to avoidable failed requests.
If the task depends on a particular model, verify that model in the live selector before comparing plans.
2. Is the workload steady or uneven?
A repeated daily workflow is easier to plan with fixed capacity. A one-off evaluation, a short burst, or a changing mix of models is usually easier to manage with a metered balance.
Look at a normal month, not your busiest day. A high-activity launch week does not necessarily justify a larger recurring plan, while small daily requests can add up to a predictable baseline.
3. Do you value a fixed allowance or precise usage control?
Share makes the capacity decision at the plan level. Flex makes it request by request. Neither is inherently more economical without knowing the model, request pattern, and current rate.
If your priority is budget predictability, identify the smallest Share tier that covers a normal cycle. If your priority is granular control across models, start with a bounded Flex amount and review actual request history before adding more.
4. What happens to unused value?
Unused Share allowance resets with its cycle and does not convert into Flex. Purchased Flex remains available until you use it, while promotional Flex may expire under the promotion's terms.
This difference matters for seasonal work. A fixed plan can be wasteful during long idle periods; a purchased Flex balance can wait for the next project. Conversely, a stable high-frequency GPT workflow may benefit more from recurring capacity than from metered planning.
5. How much operational complexity do you want?
One Share plan can be simple for a consistent GPT workflow. Flex adds model choice but also asks you to watch current rates and request-level usage. Using both is practical, but your team should know which models draw from which balance.
The Agent.Space Developer API guide explains how model discovery and request history expose that distinction for verified server integrations.
When using Share and Flex together makes sense
The two balances complement each other when your work has a stable core and a variable edge.
For example, a team might use a Share plan for its regular Codex implementation work, then use Flex to compare a supported non-OpenAI model on a focused review or research task. This keeps the recurring workflow predictable without limiting every task to one model family.
The boundary still matters: Agent.Space does not silently move a request from Share to Flex when one balance is unavailable, and it does not use Share to pay a Flex-funded model. If a request fails, check the selected model and its funding source rather than assuming the other balance will take over.
This is similar to the broader Agent.Space architecture: the model, Agent harness, Session, Workspace, and commercial access are separate choices. How Agent.Space works explains those layers and why changing one does not automatically change the others.
Common selection mistakes
- Treating Share like stored credit. It is a plan allowance with a usage cycle, not a balance that rolls forward.
- Treating every Flex amount the same. Purchased and promotional Flex can have different expiration rules.
- Assuming the cheapest listed model is the cheapest completed task. A lower per-unit rate does not guarantee fewer retries or less total usage.
- Expecting automatic balance failover. Share and Flex remain separate even when both are present.
- Buying for a benchmark instead of a workflow. Choose from your model requirement, task frequency, and review process—not a generic leaderboard.
If long-running work is driving the decision, also separate commercial allowance from project continuity. A balance funds requests; it does not define what survives between runs. The guide to persistent coding Agent Sessions covers that project-state question.
A practical buying checklist
Before choosing, write down:
- The model or model families the task actually requires.
- How many days in a normal cycle you expect to use them.
- Whether the work is repetitive or made of irregular bursts.
- Whether unused recurring allowance would be acceptable.
- Who will monitor rates, request history, and balance ownership.
Choose Share for a consistent OpenAI-model baseline, Flex for metered access to other available models, or both when you genuinely have both patterns. Then revisit the decision using real usage rather than forecasts alone.
Compare the current Agent.Space plans and Flex rates, verify that the models you need are available, and start with the smallest option that can support one real workload.