> ## Documentation Index > > Fetch the complete documentation index at: https://lithi.ai/llms.txt > > Use this file to discover all available pages before exploring further. # 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](/docs/compute/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: | Candidate work | Evidence to confirm first | | --- | --- | | Extract the supplier, invoice date and total from a repeatable invoice set, keeping invoice IDs and source pages | A representative sample, item count, fields, missing-field rule and review check | | Extract fields or citations from a bounded set of forms, scans or other documents and images | The source format, permitted data profile, page volume and accepted evidence shape | | Review a bounded multi-file code or test change against a repeatable rubric | The files in scope, findings format, test or build evidence and stop condition | | Compare or evaluate a declared set of records, outputs or model candidates | The comparison set, scoring rule, quality threshold and required human review | 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 {#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](/docs/compute/clients/claude-code). #### Codex {#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](/docs/compute/clients/codex). #### Cursor {#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](/docs/compute/clients/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. | Current billing shape | What usage fit means | | --- | --- | | Subscription with an included allowance | Check the allowance, its binding window and its reset. A plan allowance counted in credits still belongs here when it is included in the subscription. The subscription fee is not a per-task saving claim. | | Your own metered API key | No included allowance is at stake. Use the actual measured API meter and a current quote in cost fit. | | A metered pool or purchased or prepaid credits | These are direct-cost pools, not an included allowance to preserve. Use cost fit and keep the pool's own unit. | | Unknown billing shape | Keep the result unresolved until the pool and its billing shape are known. | 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. | Pressure | Meaning | | --- | --- | | `LOW` | No quota interruption is needed. | | `WATCH` | Look more closely at a large upcoming task. | | `HIGH` | A suitable bounded task may warrant a no-spend assessment. | | `CRITICAL` | Surface eligible bounded work for assessment. | | `EXHAUSTED` | Compare waiting for the reset with any available overage. | | `UNKNOWN` | The reading cannot support a pressure decision. | 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: ```text title="Technical evaluator details" kind="rules" 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: ```text title="Make urgency and reset choices explicit" kind="rules" 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.