pith. sign in

arxiv: 2606.04056 · v1 · pith:DX5QG2KZnew · submitted 2026-06-02 · 💻 cs.SE · cs.MA· cs.PL

Token Budgets: An Empirical Catalog of 63 LLM-Agent Budget-Overrun Incidents, with an Affine-Typed Rust Mitigation as a Case Study

Sajjad Khan This is my paper

Pith reviewed 2026-06-28 08:59 UTC · model grok-4.3

classification 💻 cs.SE cs.MAcs.PL
keywords LLM agentsbudget overrunsaffine typesRusttoken budgetsdelegationempirical studycompile-time safety
0
0 comments X

The pith

Affine ownership in Rust makes LLM-agent token budget overruns compile errors instead of runtime dollar losses.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper presents a catalog of 63 confirmed budget-overrun incidents in LLM agents from 21 frameworks, grouped into an eight-cluster taxonomy. It then introduces a Rust library that treats token budgets as affine resources so that delegation, cloning, or reuse after handoff are rejected by the borrow checker. In tests, a delegation-fanout pattern that causes all 30 runs to overshoot under asyncio produces zero overshoots with the Rust approach. The library achieves this at operational parity with other methods across multiple runtimes and providers. This addresses cases where a single faulty retry loop can incur large unmonitored costs.

Core claim

By encoding token budgets with affine types in Rust, the delegation-fanout race that appears in 11 catalogued incidents becomes a compile-time error, whereas the same pattern in asyncio and three other disciplined alternatives produces overshoots in 30/30 and 0/30 cases respectively; the resulting system reports zero cap violations and zero false refusals in live-API tests with N=160.

What carries the argument

The affine token budget type in the 1,180-line Rust crate, which enforces that a budget cannot be used after it has been delegated.

If this is right

  • The 11 documented delegation-fanout incidents are rejected at compile time.
  • Zero budget cap violations occur across five runtimes, three providers, and N=160 live tests.
  • Static over-reservation factor is 4-6x while adaptive is 2.11x.
  • Operational cost matches concurrent work with no false refusals.
  • The dollar cap remains runtime arithmetic but is made non-bypassable by the type layer.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Similar affine modeling could apply to other shared resources like API rate limits or memory allocations in agent systems.
  • Integration with Python via FFI or a typed wrapper might bring some guarantees to higher-level languages without full rewrite.
  • Binary-level verification would further strengthen the approach beyond compile-time checks.
  • The taxonomy of failures could guide design of new orchestration frameworks to avoid the identified clusters.

Load-bearing premise

The cost of each operation can be estimated accurately enough that the runtime cap arithmetic reflects actual spend, and the affine rules cannot be bypassed by unsafe code or runtime reflection.

What would settle it

A program using the Rust crate that completes a delegation-fanout pattern and spends more than the declared budget cap.

Figures

Figures reproduced from arXiv: 2606.04056 by Sajjad Khan.

Figure 1
Figure 1. Figure 1: Overshoot rate on the LANG-001 multi-step retry-loop workload at [PITH_FULL_IMAGE:figures/full_fig_p011_1.png] view at source ↗
read the original abstract

LLM-agent budget overruns are a documented production failure class: a single retry loop can spend thousands of dollars before an operator notices, and the in-process integrity properties that would prevent it (no aliasing, no double-spend, no use-after-delegation of a cost-bearing value) are enforced, if at all, by ad-hoc wrappers rather than by the type system. Our central contribution is empirical: a catalog of 63 confirmed production incidents from 21 orchestration frameworks (2023-2026), each backed by a quoted GitHub issue and, where reported, a dollar loss, organized into an eight-cluster failure taxonomy (inter-rater Cohen's kappa = 0.837, N = 113), plus 47 supplementary structural entries. As one mitigation evaluated against this taxonomy, we build token-budgets, an 1,180-line Rust crate (no unsafe) that operationalizes affine ownership so that cloning, double-spending, or using a budget after delegating it are compile errors rather than runtime hazards an operator must remember to avoid. The dollar cap is runtime arithmetic under an estimator assumption; the affine layer makes that arithmetic non-bypassable. On single-agent workloads a 4-line Python counter matches the crate at 0/30 overshoot, so the distinguishing value is non-bypassability under operator error in multi-agent delegation: the delegation-fanout race documented in 11 incidents is rejected by the borrow checker at compile time, while the same pattern under asyncio overshoots 30/30 and three disciplined alternatives overshoot 0/30. Across five runtimes, three providers, and a temperature-stratified live-API test (N = 160), the approach reports zero cap violations and zero false refusals, at operational parity with concurrent work. Static over-reservation is 4-6x (2.11x adaptive). Binary-level cap-soundness on the running binary is left open.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 0 minor

Summary. The paper claims to deliver an empirical catalog of 63 confirmed LLM-agent budget-overrun incidents drawn from GitHub issues across 21 frameworks (2023-2026), organized into an eight-cluster taxonomy (Cohen's kappa = 0.837 on N=113), plus 47 supplementary entries. As mitigation, it presents an 1,180-line Rust crate using affine ownership to make cloning, double-spending, and post-delegation use compile errors; the dollar cap remains runtime arithmetic under an estimator assumption, but the affine layer renders that arithmetic non-bypassable. It reports that the delegation-fanout pattern (11 incidents) is rejected by the borrow checker, while asyncio overshoots 30/30 and alternatives overshoot 0/30; across five runtimes, three providers, and a temperature-stratified live-API test (N=160) the crate shows zero cap violations and zero false refusals at operational parity, with static over-reservation of 4-6x (2.11x adaptive). Binary-level soundness on the running binary is left open.

Significance. If the empirical catalog is reproducible and the mitigation's non-bypassability holds under validated estimators, the work supplies both a structured failure taxonomy useful for LLM-agent engineering and a compile-time integrity mechanism that addresses delegation races missed by runtime wrappers. The zero-violation result across heterogeneous runtimes and the explicit contrast with asyncio are concrete strengths. The contribution is tempered by the acknowledged estimator assumption, which limits the strength of the dollar-overrun prevention claim.

major comments (2)
  1. [Abstract] Abstract: the central claim of zero cap violations (N=160) and non-bypassability rests on an unvalidated runtime cost estimator; the paper explicitly states the dollar cap is 'runtime arithmetic under an estimator assumption' and leaves 'binary-level cap-soundness on the running binary' open. This is load-bearing because systematic under-estimation would permit actual dollar overruns even though affine types block double-spending of the (under-estimated) token.
  2. [Abstract] Abstract: the reported quantitative results (63 incidents, kappa=0.837, 0/30 overshoots, N=160 tests, zero violations) are given without raw data, full incident-collection methodology, or crate implementation details, preventing independent verification of the catalog and the zero-violation claim.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We appreciate the referee's careful reading and constructive feedback. We address the two major comments below. Where the comments identify areas for improvement in clarity and verifiability, we agree to make revisions.

read point-by-point responses

  1. Referee: [Abstract] Abstract: the central claim of zero cap violations (N=160) and non-bypassability rests on an unvalidated runtime cost estimator; the paper explicitly states the dollar cap is 'runtime arithmetic under an estimator assumption' and leaves 'binary-level cap-soundness on the running binary' open. This is load-bearing because systematic under-estimation would permit actual dollar overruns even though affine types block double-spending of the (under-estimated) token.

    Authors: The manuscript already qualifies the dollar cap as 'runtime arithmetic under an estimator assumption' and explicitly leaves binary-level soundness open. The contribution of the affine types is to make the (estimator-provided) budget non-bypassable at the source level, which addresses the delegation races in the taxonomy. We acknowledge that this does not provide end-to-end dollar soundness without a validated estimator. We will revise the abstract and add a dedicated limitations subsection to make this dependency and the open question more prominent. We do not claim binary-level soundness. revision: partial

  2. Referee: [Abstract] Abstract: the reported quantitative results (63 incidents, kappa=0.837, 0/30 overshoots, N=160 tests, zero violations) are given without raw data, full incident-collection methodology, or crate implementation details, preventing independent verification of the catalog and the zero-violation claim.

    Authors: The full paper provides the incident collection methodology in Section 3 (including search terms, inclusion criteria, and inter-rater process), with each of the 63 incidents linked to its GitHub issue. The crate is 1,180 lines with source available in the supplementary materials and on GitHub. The N=160 test methodology is detailed in Section 5, including the temperature stratification and runtime configurations. To improve verifiability, we will add an explicit 'Data and Code Availability' section with links to the raw annotation spreadsheet (anonymized where necessary) and the full crate repository. We agree this will strengthen the paper. revision: yes

Circularity Check

0 steps flagged

No circularity; empirical catalog and Rust artifact rest on independent data collection and type-system construction.

full rationale

The paper's derivation chain consists of (1) collecting 63 GitHub-backed incidents into an eight-cluster taxonomy and (2) implementing an 1,180-line affine-typed Rust crate whose borrow-checker rules are stated directly as compile-time rejections of aliasing/double-spend patterns. No equations, fitted parameters, or predictions appear; the dollar-cap arithmetic is explicitly labeled 'runtime arithmetic under an estimator assumption' with binary-level soundness left open. No self-citations are invoked as load-bearing uniqueness theorems, and the zero-violation result (N=160) is reported as an empirical outcome under the stated estimator rather than a definitional identity. The work is therefore self-contained against external benchmarks.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

This is an empirical catalog plus engineering artifact paper; the claims rest on the representativeness of the 63 GitHub-sourced incidents and the correctness of the Rust implementation under standard Rust semantics. No mathematical free parameters are fitted and no new physical or logical entities are postulated.

pith-pipeline@v0.9.1-grok · 5907 in / 1256 out tokens · 36141 ms · 2026-06-28T08:59:14.735187+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. Silent Failure in LLM Agent Systems: The Entropy Principle and the Inevitable Disorder of Autonomous Agents

    cs.MA 2026-06 unverdicted novelty 4.0

    LLM agent systems accumulate disorder leading to silent failures, formalized by the exponential Entropy Principle S(t) = S0 * e^(alpha * t) with empirically measured alpha, countered by proposed PIG Engine and ADE protocols.

Reference graph

Works this paper leans on

88 extracted references · 1 linked inside Pith · cited by 1 Pith paper

  1. [1]

    Linear types can change the world

    P. Wadler. “Linear types can change the world.” InProgramming Concepts and Methods, M. Broy and C. Jones, eds., North-Holland, 1990, pp. 561– 581

    1990

  2. [2]

    Guidelines for performing systematic literature reviews in software engineering

    B. Kitchenham and S. Charters. “Guidelines for performing systematic literature reviews in software engineering.” EBSE Technical Report EBSE- 2007-01, Keele University and Durham University, 2007

    2007

  3. [3]

    Krippendorff.Content Analysis: An Introduction to Its Methodology

    K. Krippendorff.Content Analysis: An Introduction to Its Methodology. 3rd edition, SAGE Publications, 2013

    2013

  4. [4]

    B. G. Glaser and A. L. Strauss.The Discovery of Grounded Theory: Strategies for Qualitative Research.Aldine, 1967

    1967

  5. [5]

    Recommended steps for thematic synthesis in software engineering

    D. S. Cruzes and T. Dybå. “Recommended steps for thematic synthesis in software engineering.” InProc. Int. Symp. on Empirical Software Engineering and Measurement (ESEM), IEEE, 2011, pp. 275–284

    2011

  6. [6]

    Saldaña.The Coding Manual for Qualitative Researchers.3rd edition, SAGE Publications, 2016

    J. Saldaña.The Coding Manual for Qualitative Researchers.3rd edition, SAGE Publications, 2016

    2016

  7. [7]

    Guidelines for conducting and reporting case study research in software engineering

    P. Runeson and M. Höst. “Guidelines for conducting and reporting case study research in software engineering.”Empirical Software Engineering, 14(2):131–164, 2009

    2009

  8. [8]

    Wohlin, P

    C. Wohlin, P. Runeson, M. Höst, M. C. Ohlsson, B. Regnell, and A. Wesslén.Experimentation in Software Engineering.Springer, 2012

    2012

  9. [9]

    The promises and perils of mining GitHub

    E. Kalliamvakou, G. Gousios, K. Blincoe, L. Singer, D. M. German, and D. Damian. “The promises and perils of mining GitHub.” InProc. Working Conf. on Mining Software Repositories (MSR), ACM, 2014, pp. 92–101 (extended as “An in-depth study of the promises and perils of mining GitHub,”Empirical Software Engineering, 21(5):2035–2071, 2016)

    2014

  10. [10]

    Typestate: a programming language concept for enhancing software reliability

    R. E. Strom and S. Yemini. “Typestate: a programming language concept for enhancing software reliability.”IEEE Trans. Software Engineering 12(1):157–171, 1986

    1986

  11. [11]

    Typestate-oriented programming

    J. Aldrich, J. Sunshine, D. Saini, and Z. Sparks. “Typestate-oriented programming.” InCompanion to OOPSLA 2009, ACM, 2009

    2009

  12. [12]

    RustBelt: securing the foundations of the Rust programming language

    R. Jung, J.-H. Jourdan, R. Krebbers, and D. Dreyer. “RustBelt: securing the foundations of the Rust programming language.”Proc. ACM on Programming Languages2(POPL), 2018

    2018

  13. [13]

    https://github.com/sajjadanwar0/ token-budgets-experiments

    AgentGuard-style callback: a representative loop-detection and bud- get circuit-breaker baseline (a LangChain BaseCallbackHandler) implemented for this evaluation; see experiments/ollama_ replication.py in the artifact. https://github.com/sajjadanwar0/ token-budgets-experiments

  14. [14]

    ATXP documentation, 2026

    ATXP: per-agent payment wallets returning HTTP 402 when depleted. ATXP documentation, 2026. https://docs.atxp.ai/

    2026

  15. [15]

    https://docs.rs/tokio/

    tokioproject, tokio::time::Instant and budget-pacing documen- tation. https://docs.rs/tokio/

  16. [16]

    https://docs.rs/tokio/

    tokioproject, tokio::sync::Semaphore (concurrency permits). https://docs.rs/tokio/

  17. [17]

    Maximum Context Length Ex- ceeded Due to Base64-Encoded Image in Prompt

    LangChain GitHub issue #24107: “Maximum Context Length Ex- ceeded Due to Base64-Encoded Image in Prompt” (254,201-input-token single-image overflow on Phi-3-vision). https://github.com/langchain- ai/langchain/issues/24107

  18. [18]

    OM issues in tool heavy environments

    Mastra GitHub issue #14598: “OM issues in tool heavy environments” (2- million-token observer-LLM call documented). https://github.com/mastra- ai/mastra/issues/14598

  19. [19]

    Max turns exceeded

    OpenAI Agents SDK GitHub issue #844: “Max turns exceeded” (maintainer admission of architectural gap in graceful degradation). https://github.com/openai/openai-agents-python/issues/844

  20. [20]

    Simple testing can prevent most critical failures: an analysis of production failures in distributed data-intensive systems

    D. Yuan, Y . Luo, X. Zhuang, G. R. Rodrigues, X. Zhao, Y . Zhang, P. U. Jain, and M. Stumm. “Simple testing can prevent most critical failures: an analysis of production failures in distributed data-intensive systems.” In USENIX OSDI 2014, pp. 249–265

    2014

  21. [21]

    Learning from mistakes: a comprehensive study on real-world concurrency bug characteristics

    S. Lu, S. Park, E. Seo, and Y . Zhou. “Learning from mistakes: a comprehensive study on real-world concurrency bug characteristics.” InProc. ASPLOS XIII, ACM, 2008, pp. 329–339. 24

    2008

  22. [22]

    Move: a language with programmable resources

    S. Blackshear, E. Cheng, D. L. Dill, V . Gao, B. Maurer, T. Nowacki, A. Pott, S. Qadeer, Rain, D. Russi, S. Sezer, T. Zakian, and R. Zhou. “Move: a language with programmable resources.” Diem Association technical report, 2020. https://developers.diem.com/docs/technical-papers/ move-paper/

    2020

  23. [23]

    seL4: formal verification of an OS kernel

    G. Klein, K. Elphinstone, G. Heiser, J. Andronick, D. Cock, P. Derrin, D. Elkaduwe, K. Engelhardt, R. Kolanski, M. Norrish, T. Sewell, H. Tuch, and S. Winwood. “seL4: formal verification of an OS kernel.” InProc. SOSP 2009, ACM, pp. 207–220

    2009

  24. [24]

    Becker.governor: a Rust crate for rate-limiting via non-cloneable direct token buckets

    A. Becker.governor: a Rust crate for rate-limiting via non-cloneable direct token buckets. crates.io, 2018–present. https://crates.io/crates/governor

    2018

  25. [25]

    Agent Contracts: a formal framework for resource- bounded autonomous AI systems

    Q. Ye and J. Tan. “Agent Contracts: a formal framework for resource- bounded autonomous AI systems.” arXiv preprint 2601.08815, January 2026 (last revised 25 March 2026, v3; accepted at COINE 2026 workshop, AAMAS 2026, Paphos, Cyprus). https://arxiv.org/abs/2601.08815. Ref- erence implementation: https://github.com/flyersworder/agent-contracts (PyPI:ai-ag...

    arXiv 2026

  26. [26]

    Deny capabilities for safe, fast actors

    S. Clebsch, S. Drossopoulou, S. Blessing, and A. McNeil. “Deny capabilities for safe, fast actors.” InProc. AGERE! 2015, ACM, pp. 1–12

    2015

  27. [27]

    LiteLLM proxy — Budget management

    BerriAI. “LiteLLM proxy — Budget management.” LiteLLM Documen- tation v1.78, 2025. https://docs.litellm.ai/docs/proxy/users

    2025

  28. [28]

    Loom: A tool for testing concurrent Rust code

    Tokio Maintainers. “Loom: A tool for testing concurrent Rust code.” https://docs.rs/loom/latest/loom/, version 0.7.x, 2024

    2024

  29. [29]

    FrugalGPT: How to use large language models while reducing cost and improving performance

    L. Chen, M. Zaharia, and J. Zou. “FrugalGPT: How to use large language models while reducing cost and improving performance.”arXiv preprint arXiv:2305.05176, 2023

    Pith/arXiv arXiv 2023

  30. [30]

    tower::Limit: A middleware that limits the number of in-flight requests

    Tower Maintainers. “tower::Limit: A middleware that limits the number of in-flight requests.” Rust crate documentation, https://docs.rs/tower/ latest/tower/limit/index.html, 2024

    2024

  31. [31]

    Verus: Verifying Rust programs using linear ghost types

    A. Lattuada, T. Hance, C. Cho, et al. “Verus: Verifying Rust programs using linear ghost types.”Proceedings of the ACM on Programming Languages (OOPSLA), 2023

    2023

  32. [32]

    tokencap: Token budget enforcement for AI agents. Hard limits, configurable policy, zero infrastructure required

    pykul. “tokencap: Token budget enforcement for AI agents. Hard limits, configurable policy, zero infrastructure required.” 2025. https://github. com/pykul/tokencap

    2025

  33. [33]

    VerusBelt: A Semantic Foundation for Verus’s Proof-Oriented Extensions to the Rust Type System

    T. Hance, L. Elbeheiry, Y . Matsushita, and D. Dreyer. “VerusBelt: A Semantic Foundation for Verus’s Proof-Oriented Extensions to the Rust Type System.” PLDI 2026

    2026

  34. [34]

    Multivariate amortized resource analysis

    J. Hoffmann, K. Aehlig, and M. Hofmann. “Multivariate amortized resource analysis.” ACM TOPLAS, 34(3), 2012. [Cited as exemplar of static resource analysis tradition.]

    2012

  35. [35]

    KEVM: A Complete Formal Semantics of the Ethereum Virtual Machine

    E. Hildenbrandt et al. “KEVM: A Complete Formal Semantics of the Ethereum Virtual Machine.” CSF 2018, pp. 204–217

    2018

  36. [36]

    Ethereum: A secure decentralised generalized transaction ledger

    G. Wood. “Ethereum: A secure decentralised generalized transaction ledger.” Ethereum Yellow Paper, Byzantium revision, 2018

    2018

  37. [37]

    Proving expected sensitivity of probabilistic programs with randomized variable-dependent termination time

    P. Wang, H. Fu, K. Chatterjee, Y . Deng, and M. Xu. “Proving expected sensitivity of probabilistic programs with randomized variable-dependent termination time.”Proc. ACM Program. Lang., 4(POPL), Article 25, 2020

    2020

  38. [38]

    Iris from the ground up: A modular foundation for higher-order concurrent separation logic

    R. Jung, R. Krebbers, J.-H. Jourdan, A. Bizjak, L. Birkedal, and D. Dreyer. “Iris from the ground up: A modular foundation for higher-order concurrent separation logic.”Journal of Functional Programming, vol. 28, e20, 2018

    2018

  39. [39]

    RustHorn: CHC-based verification for Rust programs

    Y . Matsushita, T. Tsukada, and N. Kobayashi. “RustHorn: CHC-based verification for Rust programs.”ESOP 2020: Programming Languages and Systems, LNCS 12075, pp. 484–514, Springer, 2020

    2020

  40. [40]

    RefinedRust: A type system for high-assurance verification of Rust programs

    L. Gaeher et al. “RefinedRust: A type system for high-assurance verification of Rust programs.”Proc. ACM on Programming Languages, vol. 8, no. PLDI, Article 192, June 2024

    2024

  41. [41]

    Syntax and semantics of quantitative type theory

    R. Atkey. “Syntax and semantics of quantitative type theory.”LICS 2018: Logic in Computer Science, ACM/IEEE, 2018, pp. 56–65

    2018

  42. [42]

    The KeyKOS nanokernel architecture

    A. C. Bomberger, A. P. Frantz, W. S. Frantz, A. C. Hardy, N. Hardy, C. R. Landau, J. S. Shapiro. “The KeyKOS nanokernel architecture.” USENIX Workshop on Micro-Kernels and Other Kernel Architectures, 1992

    1992

  43. [43]

    EROS: A fast capability system

    J. S. Shapiro, J. M. Smith, D. J. Farber. “EROS: A fast capability system.” SOSP 1999: Operating Systems Principles, ACM, 1999, pp. 170–185

    1999

  44. [44]

    CHERI: A hybrid capability-system architecture for scalable software compartmentalization

    R. N. M. Watson et al. “CHERI: A hybrid capability-system architecture for scalable software compartmentalization.”IEEE Symposium on Security and Privacy, 2015, pp. 20–37

    2015

  45. [45]

    Joe-E: A security-oriented subset of Java

    A. Mettler, D. Wagner, T. Close. “Joe-E: A security-oriented subset of Java.”NDSS 2010

    2010

  46. [46]

    Robust composition: Towards a unified approach to access control and concurrency control

    M. S. Miller. “Robust composition: Towards a unified approach to access control and concurrency control.” PhD thesis, Johns Hopkins University, 2006

    2006

  47. [47]

    GASTAP: A gas analyzer for smart contracts

    E. Albert, P. Gordillo, A. Rubio, I. Sergey. “GASTAP: A gas analyzer for smart contracts.”IEEE Access, vol. 10, pp. 50472–50495, 2022

    2022

  48. [48]

    MadMax: Surviving out-of-gas conditions in Ethereum smart contracts

    N. Grech, M. Kong, A. Jurisevic, L. Brent, B. Scholz, Y . Smaragdakis. “MadMax: Surviving out-of-gas conditions in Ethereum smart contracts.” Proceedings of the ACM on Programming Languages, vol. 2, OOPSLA, article 116, 2018

    2018

  49. [49]

    Cost monitoring and budget enforcement for Amazon Bedrock

    Amazon Web Services. “Cost monitoring and budget enforcement for Amazon Bedrock.” AWS documentation: CloudWatch billing alarms, AWS Budget actions, and automatic Bedrock service revocation on budget threshold breach. https://docs.aws.amazon.com/bedrock/latest/userguide/ cost-mgmt.html

  50. [50]

    Refinement types for Haskell

    N. Vazou, E. L. Seidel, R. Jhala, D. Vytiniotis, and S. Peyton Jones. “Refinement types for Haskell.” InProc. ICFP, 2014

    2014

  51. [51]

    Weakest precondition reasoning for expected runtimes of randomized algorithms

    B. L. Kaminski, J.-P. Katoen, C. Matheja, and F. Olmedo. “Weakest precondition reasoning for expected runtimes of randomized algorithms.” Journal of the ACM, 65(5):1–68, 2018

    2018

  52. [52]

    Raising expectations: Automating expected cost analysis with types

    P. Wang, D. Fu, A. K. Bouajjani, H. Yang, and J. Hoffmann. “Raising expectations: Automating expected cost analysis with types.”Proc. ACM Program. Lang., 4(ICFP):1–31, 2020

    2020

  53. [53]

    Linear Haskell: practical linearity in a higher-order polymorphic language

    J.-P. Bernardy, M. Boespflug, R. R. Newton, S. Peyton Jones, and A. Spiwack. “Linear Haskell: practical linearity in a higher-order polymorphic language.”Proc. ACM Program. Lang., 2(POPL):1–29, 2018

    2018

  54. [54]

    Large-scale cluster management at Google with Borg

    A. Verma, L. Pedrosa, M. Korupolu, D. Oppenheimer, E. Tune, and J. Wilkes. “Large-scale cluster management at Google with Borg.” In Proc. EuroSys, 2015

    2015

  55. [55]

    Resource quotas

    Kubernetes Authors. “Resource quotas.” https://kubernetes.io/docs/ concepts/policy/resource-quotas/, accessed 2026-05

    2026

  56. [56]

    New directions in communications (or which way to the information age?)

    J. S. Turner. “New directions in communications (or which way to the information age?).”IEEE Communications Magazine, 24(10):8–15, 1986

    1986

  57. [57]

    Garcia-Molina and K

    H. Garcia-Molina and K. Salem. “Sagas.” InProc. SIGMOD, 1987

    1987

  58. [58]

    Leases: an efficient fault-tolerant mechanism for distributed file cache consistency

    C. Gray and D. Cheriton. “Leases: an efficient fault-tolerant mechanism for distributed file cache consistency.” InProc. SOSP, 1989, pp. 202–210

    1989

  59. [59]

    Language primitives and type discipline for structured communication-based programming

    K. Honda, V . T. Vasconcelos, and M. Kubo. “Language primitives and type discipline for structured communication-based programming.” In Proc. ESOP, 1998

    1998

  60. [60]

    CosmWasm gas metering

    Confio and the CosmWasm contributors. “CosmWasm gas metering.” https://docs.cosmwasm.com/docs/architecture/gas/, accessed 2026-05

    2026

  61. [61]

    Gas: The economic model

    NEAR Protocol. “Gas: The economic model.” https://docs.near.org/ concepts/protocol/gas, accessed 2026-05

    2026

  62. [62]

    Runtime compute units

    Solana Labs. “Runtime compute units.” https://docs.solana.com/ developing/programming-model/runtime#compute-budget, accessed 2026- 05

    2026

  63. [63]

    Create, edit, or delete budgets and budget alerts

    Google Cloud. “Create, edit, or delete budgets and budget alerts.” https: //cloud.google.com/billing/docs/how-to/budgets, accessed 2026-05

    2026

  64. [64]

    The algorithmic foundations of differential privacy

    C. Dwork and A. Roth. “The algorithmic foundations of differential privacy.”Foundations and Trends in Theoretical Computer Science, 9(3– 4):211–407, 2014

    2014

  65. [65]

    Rényi differential privacy

    I. Mironov. “Rényi differential privacy.” InIEEE Computer Security Foundations Symposium (CSF), 2017, pp. 263–275

    2017

  66. [66]

    Deep learning with differential privacy

    M. Abadi, A. Chu, I. Goodfellow, H. B. McMahan, I. Mironov, K. Talwar, and L. Zhang. “Deep learning with differential privacy.” InACM CCS, 2016, pp. 308–318

    2016

  67. [67]

    Quantitative program reasoning with graded modal types

    D. Orchard, V .-B. Liepelt, and H. Eades III. “Quantitative program reasoning with graded modal types.”Proc. ACM Program. Lang., 3(ICFP), Article 110, 2019

    2019

  68. [68]

    Combining effects and coeffects via grading

    M. Gaboardi, S.-y. Katsumata, D. Orchard, F. Breuvart, and T. Uustalu. “Combining effects and coeffects via grading.” InProc. ICFP, 2016, pp. 476–489

    2016

  69. [69]

    Rate limit service and global rate limiting architec- ture

    Envoy Proxy. “Rate limit service and global rate limiting architec- ture.” https://www.envoyproxy.io/docs/envoy/latest/configuration/other_ features/rate_limit, accessed 2026-05

    2026

  70. [70]

    Enforcing policies and quotas via the Envoy data plane

    Istio. “Enforcing policies and quotas via the Envoy data plane.” https: //istio.io/latest/docs/tasks/policy-enforcement/, accessed 2026-05

    2026

  71. [71]

    Rate-limiting and response-ratelimiting plugins

    Kong. “Rate-limiting and response-ratelimiting plugins.” https://docs. konghq.com/hub/kong-inc/rate-limiting/, accessed 2026-05

    2026

  72. [72]

    Scaling your API with rate limiters

    P. Tarjan. “Scaling your API with rate limiters.” Stripe Engineering Blog,

  73. [73]

    https://stripe.com/blog/rate-limiters

  74. [74]

    Dominant resource fairness: Fair allocation of multiple resource types

    A. Ghodsi, M. Zaharia, B. Hindman, A. Konwinski, S. Shenker, and I. Stoica. “Dominant resource fairness: Fair allocation of multiple resource types.” InNSDI, 2011

    2011

  75. [75]

    mClock: Handling throughput variability for hypervisor IO scheduling

    A. Gulati, A. Merchant, and P. J. Varman. “mClock: Handling throughput variability for hypervisor IO scheduling.” InUSENIX OSDI, 2010

    2010

  76. [76]

    DSPy: Compiling declarative language model calls into state-of-the-art pipelines

    O. Khattab, A. Singhvi, P. Maheshwari, Z. Zhang, K. Santhanam, S. Vardhamanan, S. Haq, A. Sharma, T. T. Joshi, H. Moazam, H. Miller, M. Zaharia, and C. Potts. “DSPy: Compiling declarative language model calls into state-of-the-art pipelines.” InProc. ICLR, 2024

    2024

  77. [77]

    Capsicum: practical capabilities for UNIX

    R. N. M. Watson, J. Anderson, B. Laurie, and K. Kennaway. “Capsicum: practical capabilities for UNIX.” InUSENIX Security Symposium, 2010. 25

    2010

  78. [78]

    First-class state change in Plaid

    J. Sunshine, K. Naden, S. Stork, J. Aldrich, and É. Tanter. “First-class state change in Plaid.” InOOPSLA, 2011

    2011

  79. [79]

    Obsidian: typestate and assets for safer blockchain programming

    M. Coblenz, R. Oei, T. Etzel, P. Koronkevich, M. Baker, Y . Bloem, B. A. Myers, J. Aldrich, and J. Sunshine. “Obsidian: typestate and assets for safer blockchain programming.”ACM TOPLAS, 42(3), 2020

    2020

  80. [80]

    Enforcing high-level protocols in low-level software

    R. DeLine and M. Fähndrich. “Enforcing high-level protocols in low-level software.” InPLDI, 2001

    2001

Showing first 80 references.