Make your AI assistant allowance last longer

Decide whether to keep working with your agent, wait for the allowance to reset, or review a suitable task for Lithi. Start with the task and the allowance it would use. This guide applies to an included subscription allowance. For metered API usage or purchased credits, use Cost fit.

Workload fit asks whether Lithi can do the work. Usage fit asks when to do it. Cost fit asks whether the move is worthwhile. A task can fit Lithi and still be better kept with your current agent until the binding window resets.

1. Check the task

Use only memory, history or files that you are authorized to read. They can help you find a useful work pattern: repeated tasks, item or page volume, input and output token sizes, retries, the checks that decide whether a result is accepted, and how urgent the work was. That evidence describes the workload. It does not prove your current balance, reset time, price or spending limit.

Ask the agent to summarize the evidence into a bounded task before it reasons about usage. A good summary names the input, output, review rule, permitted data and deadline. Keep an ambiguous, open-ended conversation with your current agent until you can state those boundaries.

These are candidate patterns for a fit assessment, not automatic approvals:

If the history shows no repeatable volume, acceptance rule or stop condition, keep the work with your current agent. A supported, bounded and urgent task can still be useful even when it is not huge or highly flexible; urgency belongs in the timing decision, not in a claim that the task fits. A larger batch may use many admitted Macs after approval, but you do not shard the customer task or choose placement, and more Macs do not create a linear speed multiplier. Speed and capacity depend on task requirements and available Macs; they are not promised.

2. Check the allowance and reset

Claude Code, Codex and Cursor

Ask your agent which allowance the current task uses and when it resets, using a supported reading or information you provide. For Claude Code, Codex or Cursor, check the actual plan and billing path in use; a product name alone does not establish a remaining allowance. If the task is suitable, delegation can preserve some included allowance for interactive work, though planning and review still consume resources. Continue if there is enough room, wait if the reset meets your deadline, or compare delegation when the task and timing justify it.

A context limit bounds what fits in a conversation; it is not a subscription allowance. Purchased credits fund metered usage, while API rate limits constrain request throughput. Your Lithi account has its own access, credit and execution limits. None of these changes another provider's limits.

Claude Code

Check whether this session uses an included plan allowance or metered API usage. A bounded review of permitted recorded diagnostics may leave more room for your interactive work, but Claude Code still uses its own context for preparation and review. Use Lithi with Claude Code.

Codex

Identify the pool your Codex session actually uses before comparing options. A fixed diff and its callers can be assessed for a bounded review while Codex keeps the project context and local edits. Use Lithi with Codex.

Cursor

Check the model and billing path selected in Cursor; its conversation context and usage pool are different constraints. A small set of records with stable IDs and a known rubric can be assessed separately from your interactive session. Use Lithi with Cursor.

Usage fit can preserve only the pool the task would have consumed. A different host, agent or plan does not make a usage claim for this one.

The evaluator uses the registered billing shape. A host class or plan label alone does not decide whether an allowance is available to preserve.

Preserving prepaid allowance is not the same as saving cash. If the task is inside a subscription's included allowance, its marginal cash cost is already zero. Moving it may still preserve room for later interactive work, but that is an allowance decision, not a savings claim.

A hybrid path can contain both kinds of work. Your current agent may keep planning, context-heavy reasoning or final review while Lithi handles a bounded execution. Count the current agent's retained work once and compare it with Lithi's signed quote and any preparation, transfer, verification, delivery or retry work. A subscription allowance used by the retained work and a metered API or purchased-credit charge are separate pools; do not combine them into one invented quota or rate. Lithi does not subsidize a vendor plan, top up a quota, extend a reset, or provide a way around a provider's usage policy. Those are separate provider controls.

The usage reading needs a source and an observation time. It can come from a supported local reading, an authenticated vendor reading or a categorical summary you provide from your account view. A plan name is not a reading, and a remembered limit is not evidence.

Raw balances, percentages, spend figures and exact reset timestamps stay on the machine where they were read. They do not enter a cloud reasoning context. The evaluator turns the authorized reading into a summary with a pressure band, binding window, reset bucket, projected exhaustion and reason codes. Give your agent the category it needs; do not paste a raw usage dump or an exact reset time into its context.

If a reading is missing or fails, the result is INSUFFICIENT_USAGE_DATA. It is never treated as LOW, and it never becomes permission to continue or to offload. Supply an authorized categorical summary or wait for a usable reading. Lithi does not change a vendor's quota, reset or allowance.

3. Choose continuing, waiting or Lithi

The evaluator maps each window to a pressure band. The band triggers a closer look; it is not a recommendation by itself.

The recommendation also uses urgency, whether the work is bounded and parallelizable, workload fit, privacy fit, pool identity and overage availability. A pressure band alone never creates an offer.

• CONTINUE means there is no usage reason to interrupt your current work.
• WAIT_FOR_RESET means the binding window is close to resolving and the task can wait. A non-urgent task waits when the reset bucket is <15m; a deferrable task can also wait when it is <1h.
• ASSESS_LITHI means suitable work may be worth a no-spend quote. The next steps still include keeping your current agent and waiting for the reset.
• COST_FIT_ONLY means no included allowance is at stake.
• INSUFFICIENT_USAGE_DATA means the reading is absent or unusable.

An unsuitable, unbounded or privacy-unresolved task stays with the current agent even when the allowance is under pressure. A usage recommendation requires your approval and has paid_activity: NONE; it does not submit work.

4. Set the rules your agent follows

Your rules can name eligible tasks and data, maximum charge or allowance headroom, quality threshold, latest completion time, reset bucket and the condition that pauses when a fact is unknown. These rules guide a user-controlled assessment; they do not authorize automatic transfer or execution.

Keep assessment, current quote, input-transfer permission and paid execution approval separate.

Technical evaluator details

Read this section when integrating the evaluator. The local evaluator considers the window's own elapsed time and reset. Once at least 5% of a window has elapsed, it computes:

pace = used_fraction ÷ elapsed_fraction_of_window

When pace is above 1, it escalates that window's pressure by one level. Before 5% has elapsed, projected exhaustion is unknown. With several windows, it selects the highest resulting pressure, then uses pace and usage to break ties. For example, 66% used after two days of a seven-day window gives a pace of 2.31; after six days it gives 0.77.

API pressure is a different constraint

An API can be rate-limited even when there is no included allowance to preserve. That is throughput pressure: separate request and token limits can slow the current path. Cost fit may add API_RATE_LIMIT_CONSTRAINED and ask you to weigh throughput against cost, but that reason never overrides the like-for-like comparison, quality threshold, privacy fit or approval requirement. A rate-limited path can still return LITHI_HIGHER_COST, SIMILAR_COST or NOT_COMPARABLE.

Choose the next action

Keep the current agent when its interactive context matters, wait when the reset is near, or request a no-spend estimate for suitable bounded work. Offloading can preserve room in the one included pool the task would have consumed; it does not remove the task's input, output, data, quality, approval, quote, capacity or execution limits. A usage result never promises a subsidy, quota top-up, or evasion of provider limits.

Make urgency and reset choices explicit

Treat urgency as a user policy. One useful planning calculation is:

urgency ratio = deadline headroom ÷ estimated end-to-end duration

Deadline headroom is the time left before the deadline. Estimate the whole path: preparation, quote and approval, transfer, execution, verification, delivery and a retry or review reserve. A ratio below one means the estimate does not fit the time left. An unknown duration means no speed claim; ask for a better estimate or keep the current path. This ratio is a planning calculation for your decision, not a Lithi Kit wire field and not a promise of capacity.

Set the reset threshold yourself. For example, a non-urgent task may wait when the binding reset is under fifteen minutes, while a deferrable task may wait when it is under an hour. If the deadline is before that reset, compare the approved Lithi quote and timing with waiting. If the deadline is after the reset and the work can wait, waiting may be better. A pressure band alone cannot decide.

The existing helper applies its documented rules. A host policy can add stricter conditions; it cannot bypass fit, privacy or approval checks. Every usage result requires human approval and represents paid_activity: NONE until you approve the actual work.