Agent usage charging method and device, storage medium and computer equipment

Abstract

The invention provides an Agent usage charging method and device, a storage medium and computer equipment, and the method comprises the steps: responding to an Agent starting operation request initiated by a user, determining a pre-freezing cost, freezing an amount corresponding to the pre-freezing cost in an account of the user, and starting Agent operation; collecting and converting consumption data generated in the operation process of the Agent; determining a charging rule corresponding to the usage data, and calculating actual consumption cost according to the usage data and the charging rule; and performing expense settlement according to the pre-freezing expense and the actual consumption expense. In this way, the Agent usage can be accurately charged, and the cost calculation accuracy is remarkably improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to an Agent usage billing method, apparatus, storage medium, and computer equipment. Background Art

[0002] With the widespread adoption of large models, agent technology is being used to connect language models with external tools, becoming a crucial component of intelligent applications. In actual operation, agents frequently call models and tools, resulting in significant resource consumption. Therefore, how to measure usage and manage billing has become a pressing issue in agent system design. Currently, there are two mainstream approaches: one is to avoid statistics altogether and instead rely on token consumption data provided by upstream model service providers; the other is to estimate usage based on the number of agent runs.

[0003] However, neither approach accurately reflects actual consumption, exposing a core flaw in current agent-based billing frameworks: the lack of a systematic design mechanism. In actual operation, agent systems often trigger model inference and related function calls multiple times, resulting in a certain degree of computing resource consumption and external service dependency. The lack of raw data collection and structured management of these call processes makes it difficult to fully understand resource usage, further limiting resource scheduling and optimization capabilities. Summary of the Invention

[0004] The purpose of this application is to solve at least one of the above-mentioned technical deficiencies, especially the technical defect in the prior art that it is difficult to accurately reflect actual consumption.

[0005] In a first aspect, the present application provides an Agent usage billing method, the method comprising:

[0006] In response to the Agent startup request initiated by the user, after determining the pre-freeze fee, freeze the amount corresponding to the pre-freeze fee in the user's account and start the Agent;

[0007] Collect and convert usage data generated by the Agent during operation;

[0008] Determine the billing rules corresponding to the usage data, and calculate the actual consumption costs based on the usage data and its billing rules;

[0009] Cost settlement is carried out based on the pre-frozen costs and actual consumption costs.

[0010] In one embodiment, the step of determining the pre-freeze fee includes:

[0011] Determine the number of input units corresponding to the Agent and the maximum number of output units corresponding to the Agent;

[0012] The pre-freeze cost is simulated and calculated based on the number of input units and the maximum number of output units.

[0013] In one embodiment, the step of determining the pre-freeze fee further includes:

[0014] Predict the pre-freeze fee based on the agent's historical average consumption fee or historical maximum consumption fee.

[0015] In one embodiment, the step of collecting and converting usage data generated by the Agent during operation includes:

[0016] Collect resource consumption data returned by each node during the Agent's operation;

[0017] The resource consumption data is converted according to the preset standard structure specifications to obtain the usage data.

[0018] In one embodiment, the step of determining the billing rules corresponding to the usage data includes:

[0019] If the statistical type of usage data is data unit, the billing rule corresponding to the usage data is billing by data unit;

[0020] If the statistical type of usage data is usage, the billing rule corresponding to the usage data is billing based on usage.

[0021] In one embodiment, the step of determining the billing rules corresponding to the usage data further includes:

[0022] If the statistical type of usage data includes data unit and usage, the billing rule corresponding to the usage data is combined billing, which includes billing by data unit and billing by usage.

[0023] In one embodiment, the step of performing fee settlement based on the pre-frozen fee and the actual consumed fee includes:

[0024] If the pre-freeze fee is greater than the actual consumption fee, the difference between the pre-freeze fee and the actual consumption fee will be refunded to the user's account;

[0025] If the pre-frozen fee is less than the actual consumption fee, the user will be requested to make up the difference between the pre-frozen fee and the actual consumption fee.

[0026] In a second aspect, the present application provides an Agent usage billing device, the device comprising:

[0027] A pre-freeze fee determination module is used to respond to an Agent startup request initiated by a user, determine the pre-freeze fee, freeze the amount corresponding to the pre-freeze fee in the user's account, and start the Agent;

[0028] Usage data collection module, used to collect and convert usage data generated by the Agent during operation;

[0029] The actual consumption cost calculation module is used to determine the billing rules corresponding to the usage data and calculate the actual consumption cost based on the usage data and its billing rules;

[0030] The expense settlement module is used to settle expenses based on pre-frozen expenses and actual consumption expenses.

[0031] In a third aspect, the present application provides a storage medium: the storage medium stores computer-readable instructions, and when the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the Agent usage billing method in any of the above embodiments.

[0032] In a fourth aspect, the present application provides a computer device, comprising: one or more processors, and a memory;

[0033] The memory stores computer-readable instructions, and when the computer-readable instructions are executed by one or more processors, the steps of the Agent usage billing method in any one of the above embodiments are executed.

[0034] It can be seen from the above technical solutions that the embodiments of the present application have the following advantages:

[0035] The Agent usage billing method provided in this application ensures that the fee guarantee mechanism is completed before the official operation by freezing the estimated fee before the Agent is started, thereby avoiding the problem of operation interruption due to insufficient user account balance; during the operation of the Agent, the usage data is collected and converted in real time, realizing the monitoring and structured management of actual operation behavior; further, according to the corresponding billing rules, the usage data is accurately billed, which significantly improves the accuracy of fee calculation and breaks through the limitations of traditional reliance on token statistics or rough estimates of the number of runs by model service providers; finally, through the comparative settlement of pre-frozen fees and actual fees, flexible and transparent fee income and expenditure management is achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0037] Figure 1 A flowchart of the Agent usage billing method provided in an embodiment of the present application;

[0038] Figure 2 A schematic diagram of the structure of the Agent usage billing device provided in an embodiment of the present application;

[0039] Figure 3 A schematic diagram of the internal structure of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0040] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0041] This application provides an Agent usage billing method. The following embodiments are described using the method applied to a computer device as an example. It is understood that the computer device can be any device with data processing capabilities, including but not limited to a single server, a server cluster, a personal laptop, a desktop computer, etc. Figure 1 As shown, the method may include the following steps:

[0042] S101: In response to an Agent start-up request initiated by a user, after determining a pre-freezing fee, freezing an amount corresponding to the pre-freezing fee in the user's account, and starting the Agent.

[0043] An agent is an intelligent program running on a computer device that, driven by user instructions, can call upon large language models and external tools to complete specific tasks. A user is an operator who interacts with the system through a terminal device and possesses an account identity. An agent start request is a command issued by a user through an interface operation or program call to activate the agent to perform a task. Pre-frozen fees are the estimated total fees corresponding to the resource usage of the upcoming agent task. A user account is a virtual account tied to the user identity, used to record balances, fee freezes, and settlement information.

[0044] In this step, the computer device responds to the Agent start-up request initiated by the user through interface clicks, API calls or other interactive methods, and then authenticates and verifies the permissions of the request to ensure that the source of the request is legal and has the permission to start the Agent. Subsequently, the request information will be parsed, including but not limited to the task type, task parameters, expected goals, etc. After that, a comprehensive analysis of the Agent task to be run can be performed based on the preset resource consumption model. The analysis dimensions include the specifications of the selected large language model, the call frequency and single resource overhead of external tools, the expected running time, the complexity of the call chain, and the average resource consumption of historical similar tasks. The pre-freeze fee is dynamically calculated, and a detailed cost assessment is generated, marking the proportion of each resource item in the total fee.

[0045] Once the fee is determined, an account freeze operation is triggered. The current user account balance is retrieved from the database to determine whether it meets the required freeze amount. If the balance is sufficient, a freeze instruction is issued, transferring the corresponding amount from the available balance to the frozen balance. A unique transaction number is generated in the account flow to facilitate settlement and fund release upon task completion. Simultaneously, a record is created in the freeze record table, containing fields such as the user ID, task ID, frozen amount, freeze time, task description, and estimated resource usage, ensuring traceability of the fund freeze process. After this operation is completed, the system returns a confirmation message to the scheduling control module, indicating that the Agent task has met the requirements for execution.

[0046] The Agent startup process is then officially triggered. The task scheduling engine loads the task execution environment, including initializing the language model, preheating the cache, preparing the external API call interface, and activating the internal workflow engine. The entire Agent operation process is continuously tracked by the monitoring system, which logs and collects metrics for various resource call behaviors.

[0047] Furthermore, if a user initiates multiple concurrent tasks, such as batch-generating multiple copywriting articles or performing large-scale data analysis with a single click, a pre-freeze fee will be calculated for each Agent task, and the account will be frozen independently for each task. A one-to-one correspondence will be established between the task ID and the frozen funds ID. In this mode, batch processing and parallel freezing mechanisms can be used to optimize performance and avoid system bottlenecks caused by frequent submission of single operations. Furthermore, pre-freeze warnings can be issued based on the user-defined budget cap. If the user's set budget for a single task or the total budget is lower than the estimated cost, a prompt will pop up to guide the user to adjust parameters or top up their balance.

[0048] It can be understood that determining the pre-freeze fee and freezing the account can achieve preliminary verification of the user's payment ability and resource guarantee before the task starts, effectively preventing the task from being forced to terminate due to insufficient account balance during operation, thereby improving the stability of the Agent and user experience.

[0049] S102: Collect and convert usage data generated by the Agent during operation.

[0050] Usage data refers to the resource consumption data of the Agent during the above operation process, including but not limited to the number of model call tokens, the number of external interface calls, CPU / GPU usage time, memory usage, response time, etc.

[0051] In this step, after the Agent is started and enters the running state, the computer device can immediately activate a usage data collection mechanism, which consists of multiple sub-modules, including a model call monitoring module, a tool call tracking module, a system resource monitoring module, and a task execution log collection module. Each module monitors resource consumption in different dimensions in real time. For example, the model call monitoring module records the token input and output length, execution time and call identifier of each model inference request through a lightweight probe integrated on the model interface call path, and automatically associates it with the unique ID of the Agent task; the tool call tracking module uses middleware to intercept external API requests and collect call targets, parameter sizes, response status and time consumption indicators. The system resource monitoring module uses the underlying resource monitoring service to record the CPU load, memory usage and GPU utilization of the running process; the task execution log collection module is responsible for summarizing all stage execution information, including step time, exception information and state switching.

[0052] The raw data is temporarily cached in a local data buffer, and then deduplication and denoising are performed on the data to remove duplicate or abnormal records. Field mapping and unit unification are then performed, for example, model tokens are standardized according to a unified billing unit, or CPU usage seconds are converted into core seconds required for pricing. All collected data is then associated and aggregated according to the task ID, and finally a structured usage data object is output and stored in the billing usage record table.

[0053] In high-concurrency scenarios, for example, when an enterprise customer uses an agent to concurrently trigger multiple rounds of conversations to generate tasks, usage data is recorded separately for each agent instance and classified and archived using task tags and user account fields, thereby supporting subsequent user account splitting, statistical reporting, and resource optimization analysis.

[0054] Furthermore, to improve data reliability, a data rollback and recollection mechanism can be designed. If network jitter or process interruption causes partial data loss, key call records can be recollected based on the collected context information, or the system can automatically roll back to a partially stable state and recollect data, ensuring the integrity and accuracy of usage data.

[0055] As you can see, by collecting usage data during the Agent's operation, we can fully understand the actual consumption of each task. By converting this raw data into a unified format and making it billable, we can support subsequent precise matching of billing rules and generate actual cost records. This avoids the drawbacks of traditional methods that rely on crude token measurement provided by upstream service providers or estimate based solely on the number of runs, making usage statistics more detailed, transparent, and traceable.

[0056] S103: Determine the billing rules corresponding to the usage data, and calculate the actual consumption cost based on the usage data and the billing rules.

[0057] Billing rules are predefined mapping logic used to convert usage data into fee values. These rules can include unit price information based on unit resource consumption, discount policies, pricing models for different service levels, and tiered billing structures. Actual consumption costs refer to the actual amount a user should pay for this Agent run, calculated by the computer device based on the collected usage data and the corresponding billing rules, and are usually expressed in monetary units.

[0058] In this step, a set of applicable billing rules can be retrieved and loaded from the rule database based on metadata such as the service identifier, model version, usage pattern, user level, and billing cycle corresponding to the current Agent run. These billing rules can be in the form of a JSON structure, database table, or nested function, supporting dynamic condition matching based on different dimensions. For example, for inference calls using advanced large language models, a floating unit price based on the "token × price" model is matched; for Agent behaviors that call external plug-ins or tools, a "number of tool calls × single price" or "external service unit traffic × price" model is matched; and if the user is a key customer enterprise account, VIP discounts or monthly package priority rules are also added.

[0059] After matching the rules, the structured usage data is deconstructed into fields and mapped with parameters. First, various usage detail fields are extracted, such as "Total number of tokens for model calls = 15328", "Number of external API requests = 12", "GPU time = 3.5s", etc.; then, according to the mapping method defined in the billing rules, the corresponding unit price calculation dimension is matched by field. For example, if the model token price is 0.001 yuan / 1,000 tokens, the total number of tokens divided by 1,000 is multiplied by the unit price; if the call of an external OCR tool is 0.05 yuan each time, it is multiplied by the number of calls; if the billing model includes tiered pricing, such as "0.001 yuan / 1,000 for the first 10,000 tokens and 0.0008 yuan / 1,000 for the excess", the usage is automatically split and priced in segments.

[0060] After the mapping is completed, the system will calculate the results into a detailed expense list, marking the source of each item, such as "token consumption fee", "tool call fee", "resource usage fee", etc., and perform a summary calculation to obtain the total value of "actual consumption fee".

[0061] Furthermore, you can add taxes, floating factors, and currency conversions, and generate subsequent settlement instructions based on user-defined "deduction policies," such as frozen deductions, monthly settlements, and points deductions. For concurrent tasks or large-scale Agent tasks, asynchronous calculation and bill compression grouping can be used to reduce system overhead.

[0062] As you can see, matching usage data with billing rules and calculating actual costs accordingly helps achieve a precise mapping between resource consumption and cost accounting. This not only avoids billing errors caused by traditional methods based on run counts or rough token estimates, but also ensures transparent, explainable, and consistent billing for different users in different usage scenarios.

[0063] S104: Expense settlement is performed based on the pre-frozen expenses and the actual consumption expenses.

[0064] In this step, after the computer device completes the Agent task execution and billing process, it automatically enters the expense settlement phase. First, the pre-frozen expense amount from this Agent execution is queried and accurately compared with the actual consumption amount just calculated. This comparison is performed by the system's settlement engine, which supports high-precision floating-point calculations and multi-currency amount comparisons to ensure accurate financial processing.

[0065] After the task is completed and the actual consumption costs are obtained, the computer equipment initiates a unified cost settlement process. This process first performs a cost discrepancy analysis based on the difference between the pre-frozen costs and the actual consumption costs. This discrepancy is used as input to determine the settlement direction: fund refund, additional deduction, or full fund deduction. During this process, the optimal settlement path is dynamically matched based on multiple factors such as the pre-set billing policy template, task type, and user level to ensure fairness and consistency in settlement operations. Finally, actual settlement is carried out based on the discrepancy analysis results.

[0066] In actual application scenarios, taking the AIGC content generation platform as an example, when a user initiates an image generation or text generation task, the platform will freeze the fees based on the estimated consumption of the model call, and then settle the fees based on actual expenses after the task is completed, greatly improving the platform's billing flexibility and user experience guarantee capabilities.

[0067] Furthermore, to enhance financial transparency and compliance, the computer device can generate detailed expense statements after settlement, including fields such as frozen amount, actual consumption, refund or deduction amount, and final settlement time, for user reconciliation. This detailed statement can be presented through the user interface or returned to the enterprise-level accounting system via an API for reconciliation and accounting.

[0068] It can be understood that by settling fees based on the comparison of pre-frozen fees with actual consumption fees, accurate management and efficient scheduling of user account funds can be achieved, thereby improving the system's billing accuracy and fund security.

[0069] In the above embodiment, by freezing the estimated cost before the Agent is started, the cost guarantee mechanism is ensured to be completed before the formal operation, avoiding the problem of operation interruption due to insufficient balance in the user account; during the operation of the Agent, the usage data is collected and converted in real time, realizing the monitoring and structured management of actual operation behavior; further, according to the corresponding billing rules, the usage data is accurately billed, which significantly improves the accuracy of fee calculation and breaks through the limitations of traditional reliance on model service providers' token statistics or rough estimates of the number of operations; finally, by comparing and settling the pre-frozen costs with the actual costs, flexible and transparent cost income and expenditure management is achieved.

[0070] In one embodiment, the step of determining the pre-freeze fee includes:

[0071] Determine the number of input units corresponding to the Agent and the maximum number of output units corresponding to the Agent;

[0072] The pre-freeze cost is simulated and calculated based on the number of input units and the maximum number of output units.

[0073] The number of input units refers to the number of text, data, or instruction fragments input to the large model system in user requests or agent tasks. It is usually measured in tokens or character blocks and is one of the basic indicators for evaluating computing resource usage. The maximum number of output units refers to the theoretical maximum length of the response, action result, or reasoning text that the agent may generate during execution. It is also measured in tokens or result units and is used to simulate peak resource demand.

[0074] Specifically, after receiving a user-initiated Agent execution request, the computer device first performs a dual semantic and structural analysis of the request content. Specifically, it reads the Agent configuration file or task template, identifies the input type involved in the task (e.g., natural language, structured data, file content), and the task intent (e.g., question answering, data generation, tool invocation), and converts it into quantifiable data units. Based on a natural language processing model, the input text is segmented and encoded, and the total number of tokens is calculated using the Token Counter module, which serves as an initial estimate of the number of input units.

[0075] Next, we enter the output capacity modeling phase. This phase primarily relies on a task type-output prediction mapping model. Based on a large number of historical task trajectories, this model summarizes multiple output dimensions corresponding to different types of agent tasks, including the average number of response tokens, maximum response length, call chain depth, and the number of external plug-in / tool calls. Combining the task analysis results with this mapping model, we predict the output paths that may be involved in the current task. If the task allows for the automatic invocation of multiple tools or the ability to generate multiple rounds of responses, we dynamically expand the maximum output capacity, for example by raising the maximum token output limit to the sum of multiple rounds of response tokens, thereby estimating the maximum number of output units.

[0076] To improve estimation accuracy, a contextual response impact factor can be incorporated into output modeling. This factor measures the impact of task context on response complexity. For example, if the task scenario includes user historical context, lengthy background instructions, or accompanying knowledge documents, the output cap is automatically multiplied by an expansion factor to simulate the computational resource consumption associated with higher response complexity.

[0077] After modeling the number of input and output units, the system enters the cost estimation module. This module has a pre-set resource billing model, which includes a table of unit price configurations for different model resources, such as billing by input token, billing by output token, and pricing by model version. This model is called to perform a combined operation on the number of input units and the maximum number of output units. Specifically, the number of input units is multiplied by the unit input price to obtain the input cost estimate; the maximum number of output units is multiplied by the unit output price to obtain the output cost estimate. The total simulation cost is calculated using a pre-set formula, such as: Pre-freeze Fee = Input Estimate + Output Estimate × Output Risk Adjustment Factor.

[0078] In this embodiment, determining the number of input units and the maximum number of output units enables structured and quantitative modeling of the resource scale of the task to be initiated by the agent. This allows for a reasonable estimate of resource consumption even without a realistic execution path. Simulating and calculating pre-freezing costs allows for a pre-assessment of potential costs before actually invoking a large model or external tool, facilitating early deployment of cost control. This avoids the risk of unexpected resource overdrafts caused by fluctuations in actual operation.

[0079] In one embodiment, the step of determining the pre-freeze fee further includes:

[0080] Predict the pre-freeze fee based on the agent's historical average consumption fee or historical maximum consumption fee.

[0081] The historical average cost is the arithmetic mean of the costs incurred by the agent over multiple past task execution cycles, reflecting the agent's resource consumption level in typical tasks. The historical maximum cost is the highest single cost incurred by the agent in previous tasks, and is typically used to represent the upper limit of resource consumption under extreme task loads.

[0082] Specifically, when a computer receives a user request to initiate an Agent task, it first calls the historical data extraction module to index the Agent's historical run records. This historical data can be filtered by task type, model version, input and output scale, and multiple representative execution samples can be extracted. This screening process can be judged by feature vector similarity to ensure that the sample data has statistical reference value.

[0083] Next, the cost statistics phase begins. In this phase, the computer uses its built-in aggregate calculation engine to calculate the actual cost of each task in the selected sample. It calculates the arithmetic mean of all samples as the historical average cost. It also identifies the single execution record with the highest cost, which it deems the historical maximum cost. These two cost values represent the agent's resource consumption baselines for standard and heavy-load tasks, respectively.

[0084] After obtaining the above statistical values, the computer device selects an appropriate prediction model to estimate the cost based on the preset billing strategy. For example, when the user request does not provide task scale parameters or content complexity information, the historical average consumption cost can be used as the prediction value for the pre-freeze cost. When the task involves high complexity, multiple rounds of interaction, or large-scale output scenarios, the historical maximum consumption cost is used instead to ensure the adequacy of computing resources. In addition, based on the business scenario, a weighted fusion model can be used, such as: pre-freeze cost = α × historical average cost + β × historical maximum cost, where α + β = 1, to improve the flexibility and robustness of the prediction.

[0085] In this embodiment, by extracting the agent's historical average or maximum cost, we predict the pre-freeze cost required for the upcoming task, enabling rapid estimation without relying on specific task input. This prediction method enables reasonable resource reservation based on historical statistical patterns, effectively preventing interruptions or failures caused by insufficient resources during task execution. This improves resource utilization and ensures user experience. Furthermore, by incorporating historical maximum costs, we provide sufficient early warning for extreme task scenarios.

[0086] In one embodiment, the step of collecting and converting usage data generated by the Agent during operation includes:

[0087] Collect resource consumption data returned by each node during the Agent's operation;

[0088] The resource consumption data is converted according to the preset standard structure specifications to obtain the usage data.

[0089] Nodes refer to the functional modules or execution sub-stages that agents rely on during task execution, such as model inference nodes, data preprocessing nodes, and interface call nodes. These nodes independently record and report the resource information they use. Resource consumption data refers to the raw operational metrics reported by each node during operation, including CPU utilization, GPU usage, memory usage, I / O counts, call duration, and storage space usage. The preset standard structure specification is a predefined multi-field data structure template that specifies the field naming, unit conversion, data type, and nesting level requirements for converting resource consumption data into usage data.

[0090] Specifically, when the Agent task is initiated, the computing device deploys lightweight collection scripts on each Agent node, or monitors metrics and aggregates data through a unified runtime monitoring service, such as a sidecar process or a metrics collection agent. During task execution, each node records its resource usage in real time at preset intervals or upon state change events, and transmits the data through an internal communication link or event bus. Upon receiving resource consumption data from each node, preliminary data validity verification and formatting are performed, such as standardizing timestamp precision, field order, and unit identifiers. Next, field mapping, unit conversion, and data extraction are performed on the resource consumption data according to pre-set structural specifications. For example, the "GPU_Memory_MB" field in the original report is uniformly mapped to "gpu_memory_used" and the unit converted to "GB," and the "compute_time" field is standardized to "execution_duration_seconds." This conversion process is accomplished using a field mapping dictionary and a rule engine to ensure flexibility and maintainability.

[0091] After completing the standard structure conversion, a structured usage data object is generated. This object features clear field classification and nested hierarchy, accurately describing the agent's resource usage at each node and time period. This conversion process is applicable not only to single-task processing but also to batch processing scenarios where multiple agents are executing concurrently. Resource consumption data from multiple agents can be merged, split, or labeled using asynchronous messaging or task number indexing strategies, further improving data integration efficiency and conversion accuracy.

[0092] In this embodiment, by collecting resource consumption data returned by each node during the Agent's operation and converting it according to a preset standard structure specification, it is possible to ensure that the resource records used by the system are uniform, resolvable, and billing-compatible. This execution method enables the efficient integration of heterogeneous data reported by different nodes into standardized usage data, thereby providing an accurate and traceable basis for subsequent fee settlement, bill generation, and resource scheduling. Compared to relying on a single node to roughly estimate resource consumption, this method not only improves the granularity and credibility of usage data, but also enhances billing fairness and scalability in multi-task, multi-user environments.

[0093] In one embodiment, the step of determining the billing rules corresponding to the usage data includes:

[0094] If the statistical type of usage data is data unit, the billing rule corresponding to the usage data is billing by data unit;

[0095] If the statistical type of usage data is usage, the billing rule corresponding to the usage data is billing based on usage.

[0096] Among them, statistical type refers to the classification of the measurement dimension of resource usage data, including but not limited to data units or usage. The former means that the pricing is based on the number of discrete processing units, such as the number of model inputs, data rows or task requests processed; the latter means that statistics are based on continuous resource usage, such as CPU time, GPU memory usage, network bandwidth, etc.

[0097] Specifically, the computer device collects and processes the Agent's usage data and accurately bills it based on pre-set rules and pricing. It first identifies the statistical type of usage data, selects the appropriate billing rule based on the type, and then performs subsequent processing. Specifically, there are two main usage types: by data unit (i.e., by token), and by usage volume. Each type corresponds to a different billing method and pricing, ensuring accurate cost calculation based on the actual resource consumption of the task.

[0098] For token-based billing, fees are calculated based on different token categories, such as input tokens, cache tokens, and output tokens. Fees are calculated by reading the number of input, cache, and output tokens for a task and matching them with the corresponding price items. Input tokens are raw data units submitted by users and are billed based on the preset input token price. Cache tokens represent temporary data, which consumes system resources and is therefore charged based on the cache token price. Output tokens are processed data and are charged based on the output token price.

[0099] In contrast, usage-based billing is suitable for tasks that consume resources based on duration or frequency. The fee is calculated based on the task's runtime or number of executions, using a preset unit price. If the task is billed by duration, the task duration is read and multiplied by the unit price to determine the total fee. If the task is billed by number of times, the total fee is calculated based on the number of task executions multiplied by the unit price.

[0100] During the fee calculation process, you can also dynamically select the price item based on the task. Two price types can be included: standard price and cost price. For routine tasks, standard price can be used for billing; for certain specific customers or scenarios, cost price can be selected to provide more competitive pricing. The specific breakdown of price items includes input token price, cache token price, output token price, and unit price for billing based on usage. These price items correspond to different resource consumption categories, ensuring that the corresponding costs can be accurately allocated to each resource consumption.

[0101] In actual operation, the task's usage data is first read and the applicable billing rules are selected based on the statistical type. Then, the corresponding fee calculation is performed based on the task's specific usage data and the preset price items to determine the cost of each usage item. At this point, standard prices or cost prices can be selected based on the needs of different customers or tasks to ensure that fee calculations are consistent with contracts and market policies.

[0102] In one example, the token and pay-per-use standard structure is:

[0103] {

[0104] "item": "deepseek-v3-241226",

[0105] "type": "model",

[0106] "prompt_tokens": 52,

[0107] "completion_tokens": 4,

[0108] "total_tokens": 56,

[0109] "prompt_tokens_details": {

[0110] "cached_tokens": 0

[0111] },

[0112] "completion_tokens_details": {

[0113] "reasoning_tokens": 0

[0114] }

[0115] {

[0116] "item": "web_search",

[0117] "type": "item",

[0118] "quantity": 1

[0119] }

[0120] The standard structure of the expense item is as follows:

[0121] {

[0122] "item": "deepseek-v3-241226",

[0123] "method": "token",

[0124] "prices": {

[0125] "standard": {

[0126] "prompt_tokens": "0.00020000",

[0127] "completion_tokens": "0.00020000"

[0128] },

[0129] "vendor": {

[0130] "prompt_tokens": "0.00000120",​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​

[0141] "vendor": "0.10000000"

[0142] }

[0143] }

[0144] In this embodiment, by classifying and identifying the statistical types of usage data and matching applicable billing rules accordingly, it is possible to select the pricing method that best reflects actual costs based on resource usage characteristics. This dynamic matching strategy based on statistical types enables the selection of the most reasonable and fair billing model when handling tasks with diverse business models and various resource usage patterns, thereby improving the accuracy and transparency of cost calculations. At the same time, it effectively avoids the problems of excessive or unfair billing caused by a unified billing method.

[0145] In one embodiment, the step of determining the billing rules corresponding to the usage data further includes:

[0146] If the statistical type of usage data includes data unit and usage, the billing rule corresponding to the usage data is combined billing, which includes billing by data unit and billing by usage.

[0147] Specifically, the usage data statistics type is determined based on the specific needs of the task. If the statistics type is data unit and usage, combined billing is used. These two types of data will be billed separately and ultimately combined.

[0148] First, the usage data of the data unit is billed. Assuming that multiple data units are generated during the execution of the task, the number of data units is read according to the measurement standard of each data unit and multiplied by the corresponding unit price. For example, when inputting data, each token data unit may have a fixed fee, and the fee for inputting the token is calculated based on this standard. Next, the usage data of the usage is billed. The usage here may include the running time of the task, the storage space consumed, etc. Based on the usage data, the resource consumption is read, and the fee is calculated based on the relevant price items. For example, if the usage is billed by duration, the duration of the task is read and multiplied by the unit duration price to calculate the corresponding fee.

[0149] Once these two fees are calculated, combined billing is performed. In combined billing mode, the per-data-unit and per-usage fees are calculated separately and then added together to arrive at the total cost of the task. For example, if a task uses 10 data units, each costing 0.05 yuan, and the task lasts 2 hours at a price of 0.10 yuan per hour, the final calculated cost is 0.7 yuan.

[0150] In this embodiment, a combination of data unit billing and usage-based billing is used to achieve accurate billing for different types of resource consumption. By distinguishing between the two billing methods and combining them, a more comprehensive coverage of various resource consumption scenarios can be achieved while ensuring the fairness and accuracy of fee calculations. By billing by data unit, the consumption of each data block or resource unit can be accurately billed, ensuring that each minimum consumption unit is reasonably billed; while by billing by usage, it is possible to dynamically bill for quantitative resources such as time and bandwidth, further enhancing the flexibility and accuracy of billing.

[0151] In one embodiment, the steps of performing fee settlement based on the pre-frozen fees and the actual consumed fees include:

[0152] If the pre-freeze fee is greater than the actual consumption fee, the difference between the pre-freeze fee and the actual consumption fee will be refunded to the user's account;

[0153] If the pre-frozen fee is less than the actual consumption fee, the user will be requested to make up the difference between the pre-frozen fee and the actual consumption fee.

[0154] Specifically, during the resource settlement process, to ensure accurate balance of user account funds, a determination must first be made as to whether there is a discrepancy between the pre-frozen fee set by the user prior to resource use and the actual cost of the resource used. This discrepancy directly influences whether a refund or a rebate will be processed.

[0155] When it is detected that the pre-frozen fee is higher than the actual consumption fee, the fee difference that needs to be refunded to the user is automatically identified. At this time, the difference is first calculated and a refund instruction is generated. This instruction contains information such as the refund amount, the target user account, and the original transaction order number. The computer device then executes the refund operation to the designated user account through the interface of the fund management module. After the refund is successful, the refund amount is recorded in the user's account balance and the corresponding account flow is generated. To protect the user's right to know and the transparency of funds, a message notification component can also be used to simultaneously send a refund success notification to the user. The notification content includes the refund amount, account change details, and a queryable transaction number. This notification can be flexibly sent through pop-up windows within the app, SMS, email, and other methods to improve the user experience and enhance the system's perceptibility.

[0156] If the pre-frozen fee is less than the actual consumption fee, it indicates that the user's resource usage has exceeded the original budget. After calculating the difference, a reimbursement request is generated. This request will clearly list the amount to be reimbursed, the payment deadline, and the recommended payment method. It will be sent to the contact information associated with the user's account to promptly remind the user to pay the outstanding fee to avoid affecting the normal use of subsequent services. After the user's payment is successfully made, the user's account balance will be automatically updated, the reimbursement amount will be deducted, and the new account balance will be synchronized to the database in real time. A corresponding payment voucher can also be generated to ensure that every reimbursement is accurately recorded. After the reimbursement operation is completed, the settlement can be finally confirmed, all relevant account records can be updated, and a complete transaction voucher can be generated.

[0157] In this embodiment, when the pre-freeze fee exceeds the actual consumption fee, a refund is executed to ensure that the user's account balance is not improperly deducted, thereby improving user experience and fairness. If the pre-freeze fee is less than the actual consumption fee, issuing a refund request to the user ensures that the system can promptly recover the excess cost, avoiding funding issues caused by resource consumption exceeding the budget.

[0158] To facilitate understanding of the solutions of this application, specific examples are provided below for illustration.

[0159] In the early days of an intelligent conversation platform, it offered its services using a fixed quota system, limiting each registered user to a maximum of 200 conversation requests per day. While this solution superficially controlled service frequency, the platform lacked accurate billing capabilities and was unable to quantify the actual resource consumption of the Agents invoked for each conversation, making it difficult to assess the true daily cost per user. This fixed-number, no-cost approach posed a potential loss to the platform if users frequently invoked high-consumption Agents, while simultaneously failing to demonstrate service value when users used the service less frequently. This created a significant disconnect between the platform's revenue and costs.

[0160] After integrating the Agent usage billing method described in this application, the platform has officially launched a refined billing mechanism. Each newly registered user is given a 50-unit billing quota. Each time a user calls the Agent, the system automatically calculates the actual computing resources consumed, such as input tokens, output tokens, and cached tokens, and calculates the cost of each call accordingly. This fee is automatically deducted from the user's billing quota, allowing users to flexibly choose the number of calls and the required resource intensity before their quota is exhausted. This encourages users to be more rational in their resource utilization and improves the platform's cost control and revenue forecasting capabilities.

[0161] Furthermore, when platforms delivered customized Agent business service solutions to enterprise clients, they were previously unable to accurately assess the resource consumption of a single Agent run. This resulted in project quotations not reflecting the true service costs and hindered price agreement with clients. However, by integrating the Agent usage billing method described in this application, platforms can now, during the initial Proof of Concept (POC) phase, record and analyze usage data generated by actual Agent runs, assessing the average cost per call and the expected usage scale of individual clients, thereby estimating the client's likely monthly consumption. This foundation allows the platform to develop more accurate, transparent, and quantifiable pricing strategies for clients, significantly increasing customer trust and reducing business communication costs.

[0162] Furthermore, the platform further opens up the billing module capabilities corresponding to the Agent usage billing method described in this application to the developer tool ecosystem. For example, a chart generation tool or data visualization tool, which originally couldn't be independently billed, couldn't aggregate user usage or call multiple functions. After integrating this system, developers can bind standard usage units based on the tool's internal call logic, such as per-call, per-token, or per-duration, and the system will automatically complete billing statistics for each call.

[0163] The following describes the Agent usage billing device provided in the embodiment of the present application. The Agent usage billing device described below and the Agent usage billing method described above can be referenced to each other. Figure 2 As shown, the present application provides an Agent usage billing device, which includes:

[0164] The pre-freezing fee determination module 201 is used to respond to the Agent startup request initiated by the user, determine the pre-freezing fee, freeze the amount corresponding to the pre-freezing fee in the user's account, and start the Agent;

[0165] Usage data collection module 202, used to collect and convert usage data generated by the Agent during operation;

[0166] The actual consumption cost calculation module 203 is used to determine the billing rules corresponding to the usage data and calculate the actual consumption cost based on the usage data and the billing rules;

[0167] The fee settlement module 204 is used to settle fees based on the pre-frozen fees and actual consumption fees.

[0168] In one embodiment, the pre-freeze fee determination module 201 includes:

[0169] The unit number determination unit is used to determine the number of input units corresponding to the Agent and the maximum number of output units corresponding to the Agent;

[0170] The pre-freeze cost calculation unit is used to simulate and calculate the pre-freeze cost based on the number of input units and the maximum number of output units.

[0171] In one embodiment, the pre-freeze fee determination module 201 further includes:

[0172] The pre-freezing cost prediction unit is used to predict the pre-freezing cost based on the historical average consumption cost or the historical maximum consumption cost of the Agent.

[0173] In one embodiment, the usage data collection module 202 includes:

[0174] Resource consumption data collection unit, used to collect resource consumption data returned by each node during the Agent's operation;

[0175] The usage data obtaining unit is used to convert the resource consumption data according to a preset standard structure specification to obtain usage data.

[0176] In one embodiment, the actual consumption cost calculation module 203 includes:

[0177] a first charging rule determining unit, configured to determine, if the statistical type of the usage data is data unit, that the charging rule corresponding to the usage data is charging by data unit;

[0178] The second charging rule determining unit is configured to determine, if the statistical type of the usage data is usage, that the charging rule corresponding to the usage data is charging based on usage.

[0179] In one embodiment, the actual consumption cost calculation module 203 further includes:

[0180] The third charging rule determination unit is configured to determine that, if the statistical type of the usage data includes data unit and usage, the charging rule corresponding to the usage data is combined charging, and the combined charging includes charging by data unit and charging by usage.

[0181] In one embodiment, the fee settlement module 204 includes:

[0182] a first fee settlement unit, configured to refund the difference between the pre-freezing fee and the actual consumption fee to the user's account if the pre-freezing fee is greater than the actual consumption fee;

[0183] The second fee settlement unit is configured to request the user to make up the difference between the pre-freezing fee and the actual consumption fee if the pre-freezing fee is less than the actual consumption fee.

[0184] In one embodiment, the present application further provides a storage medium storing computer-readable instructions. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the Agent usage billing method as described in any of the above embodiments.

[0185] In one embodiment, the present application further provides a computer device having computer-readable instructions stored therein. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the Agent usage billing method as described in any one of the above embodiments.

[0186] Schematically, as Figure 3 As shown, Figure 3 This is a schematic diagram of the internal structure of a computer device provided in an embodiment of the present application. The computer device 300 can be provided as a server. Figure 3 Computer device 300 includes a processing component 302, which further includes one or more processors, and memory resources represented by memory 301 for storing instructions executable by processing component 302, such as applications. The applications stored in memory 301 may include one or more modules, each corresponding to a set of instructions. Furthermore, processing component 302 is configured to execute the instructions to perform the agent usage billing method of any of the above-described embodiments.

[0187] The computer device 300 may further include a power supply component 303 configured to perform power management of the computer device 300, a wired or wireless network interface 304 configured to connect the computer device 300 to a network, and an input / output (I / O) interface 305. The computer device 300 may operate based on an operating system stored in the memory 301, such as Windows Server™, Mac OS X™, Unix™, Linux™, Free BSD™, or the like.

[0188] Those skilled in the art will understand that Figure 3 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0189] Finally, it should be noted that, in this article, relational terms such as first and second are merely used to distinguish one entity or operation from another, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprise," "include," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. Without further restriction, an element defined by the phrase "comprising a..." does not exclude the presence of other identical elements in the process, method, article, or device comprising the element. Herein, "one," "said," "the," and "its" may also include plural forms unless the context clearly indicates otherwise. A plurality refers to at least two, such as 2, 3, 5, or 8. "And / or" includes any and all combinations of the relevant listed items.

[0190] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referenced to each other.

[0191] The above description of the disclosed embodiments is intended to enable one skilled in the art to implement or use the present application. Various modifications to these embodiments will be readily apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application is not limited to the embodiments shown herein, but is intended to conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An Agent usage billing method, characterized in that: The method comprises: In response to a request from a user to start the Agent, after determining a pre-freeze fee, freeze an amount corresponding to the pre-freeze fee in the user's account and start the Agent; Collect and convert usage data generated by the Agent during operation; Determine the billing rules corresponding to the usage data, and calculate the actual consumption cost based on the usage data and the billing rules; Cost settlement is performed based on the pre-frozen costs and the actual consumption costs.

2. The Agent usage billing method according to claim 1, characterized in that: The step of determining the pre-freeze fee includes: Determine the number of input units corresponding to the Agent and the maximum number of output units corresponding to the Agent; The pre-freeze fee is calculated by simulation according to the number of input units and the maximum number of output units.

3. The Agent usage billing method according to claim 1, characterized in that: The step of determining the pre-freeze fee also includes: The pre-freeze fee is predicted according to the historical average consumption fee or the historical maximum consumption fee of the Agent.

4. The Agent usage billing method according to claim 1, characterized in that: The step of collecting and converting the usage data generated by the Agent during operation includes: Collect resource consumption data returned by each node during the operation of the Agent; The resource consumption data is converted according to a preset standard structure specification to obtain the usage data.

5. The Agent usage billing method according to claim 1, characterized in that: The step of determining the billing rules corresponding to the usage data includes: If the statistical type of the usage data is data unit, the billing rule corresponding to the usage data is billing by data unit; If the statistical type of the usage data is usage, the billing rule corresponding to the usage data is billing based on usage.

6. The Agent usage billing method according to claim 1, characterized in that: The step of determining the billing rules corresponding to the usage data further includes: If the statistical type of the usage data includes data units and usage, the billing rule corresponding to the usage data is combined billing, and the combined billing includes billing by data unit and billing by usage.

7. The Agent usage billing method according to claim 1, characterized in that: The step of performing fee settlement based on the pre-frozen fee and the actual consumption fee includes: If the pre-freezing fee is greater than the actual consumption fee, the difference between the pre-freezing fee and the actual consumption fee is refunded to the user's account; If the pre-freezing fee is less than the actual consumption fee, a request is made to the user to make up the difference between the pre-freezing fee and the actual consumption fee.

8. An Agent usage billing device, characterized in that: The device comprises: A pre-freezing fee determination module is configured to respond to an Agent startup request initiated by a user, determine a pre-freezing fee, freeze an amount corresponding to the pre-freezing fee in the user's account, and start the Agent; A usage data collection module, used to collect and convert the usage data generated by the Agent during operation; an actual consumption cost calculation module, configured to determine a billing rule corresponding to the usage data and calculate the actual consumption cost based on the usage data and the billing rule; The fee settlement module is used to perform fee settlement based on the pre-frozen fee and the actual consumption fee.

9. A storage medium, characterized in that: The storage medium stores computer-readable instructions, which, when executed by one or more processors, enable the one or more processors to execute the steps of the Agent usage billing method according to any one of claims 1 to 7.

10. A computer device, characterized in that: include: one or more processors, and memory; The memory stores computer-readable instructions, and when the computer-readable instructions are executed by the one or more processors, the steps of the Agent usage billing method according to any one of claims 1 to 7 are executed.

Images