# FinOps LLM — Complete Research & Knowledge Base (llms-full.txt) Content-Signal: ai-train=no, search=yes, ai-input=yes This document contains the complete text of all 820 public pages on finopsllm.com. ================================================================================ # FinOps LLM - AI cost management and LLM observability URL: https://finopsllm.com/ FinOps for production AI AI cost control for the era of tokens. Understand your LLM costs , find the waste, and put a plan into production. Our managed FinOps service audits and optimizes AI spend across providers, with savings reconciled to your invoices. Book free audit → Tour the platform ● Invoice-first audits ● 40–60% typical reduction ● Read-only by default ● Multi-cloud Cost overview Illustrative data MTD spend $70,280 ↓ 57.4% vs. baseline Savings $94,720 reconciled to invoice Cache hit-rate 38.1% +4.2 pts WoW Quality Δ +0.2% 7-day A/B active Daily LLM spend · 45 days $5,500/d today DEMO DATA · customer-042 · sample cockpit view FIG. 01 — Request routing schematic · per-request cost Reconciled against → OpenAI Anthropic Gemini Bedrock Azure Groq Together Mistral SEC. 01 — Platform FinOps for AI, on four pillars. The FinOps Foundation framework — visibility, attribution, optimization, accountability — applied to LLM spend. Same discipline. Different unit of cost. FIG. 02-A PILLAR 01 Visibility Token-level cost data ingested from every provider. Reconciled hourly. Filterable by provider, model, feature, team, customer, environment. OpenAI · Anthropic · Bedrock · Gemini · Azure · Groq · Together · Mistral Hourly ingestion · <5 min reconciliation lag Read-only by default · NDA + DPA on request FIG. 02-B PILLAR 02 Attribution & chargeback Every token mapped to a feature, team, and customer cohort. Monthly chargeback and showback, exported to your finance system or as CSV. Custom dimensions · feature, team, tier, region Cohort spend · customer-tier P&L NetSuite · QuickBooks · CSV · API FIG. 02-C PILLAR 03 Anomaly detection Real-time alerts when spend, latency, or quality deviates from a feature's rolling baseline. Slack, PagerDuty, email — and auto-throttle when it matters. Per-feature rolling baselines · seasonality-aware Slack · PagerDuty · email · webhook Optional auto-throttle & budget enforcement FIG. 02-D PILLAR 04 Automated optimization Routing, caching, and compression deployed behind feature flags, A/B tested seven days minimum, graduated only on quality & cost wins. Routing tree · per-request quality classification Semantic cache · sub-10ms hit latency Quality SLO + auto-rollback on regression SEC. 02 — Optimization Six levers, one parts list. Most teams combine three or four. The audit ranks which dominate your spend surface and projects savings before any commitment. PART № LEVER FUNCTION RANGE OPT-01 Model routing Each request classified by complexity and routed to the cheapest model that meets your quality bar. 30–50% OPT-02 Semantic caching Near-duplicate prompts fingerprinted with embeddings; identical answers served from sub-10ms cache. 20–40% OPT-03 Prompt compression System prompts audited, examples deduplicated, retrieved context compressed. Every change A/B tested. 15–30% OPT-04 Batch & async pricing Non-interactive workloads routed to batch endpoints (up to 50% discount) with SLO-aware queueing. 10–50% OPT-05 Provider arbitrage Identical capability often costs 2–3× more at one provider. Route by capability-per-dollar. 20–35% OPT-06 Fallback chains Smart retries and tiered fallbacks beat worst-case over-provisioning while holding SLO. 5–15% SEC. 03 — Engagement Assembly sequence: five weeks. Every engagement follows the same four phases. Most customers see their first reconciled provider invoice by the end of week five. STEP 01 · WEEK 01 Audit — map every dollar. Ingest provider invoices, gateway logs, usage telemetry. Full spend map by provider, model, feature, team — ranked by dollar waste. STEP 02 · WEEK 02 Plan — rank by waste. A prioritized engineering plan respecting compliance, latency SLOs, and release process. You sign off on every change. STEP 03 · WEEKS 03–05 Ship & A/B. Optimizations ship behind feature flags, A/B tested 7 days vs. baseline, graduated to 100% traffic. Cockpit goes live alongside. STEP 04 · ONGOING Reconcile — compound. The platform watches for drift; savings compound. Every month closes with a signed Statement of Savings. SEC. 04 — Pricing Pay on results. There is one engagement and it is priced on verified savings. Tidal Telemetry is separate software, free in beta. ★ MOST POPULAR · PAY ON RESULTS Performance Free audit. Then you only pay when we save you money — measured against a locked baseline, reconciled to provider invoices. 15–25 % of verified savings · no savings, no fee Free audit · 1-week turnaround · countersigned baseline Full optimization stack · routing, cache, compression, arbitrage Live cockpit + chargeback + monthly signed statements Engineering pair · weekly reviews Quality SLO enforcement & auto-rollback Minimum: $20K/month LLM spend Book free audit → SELF-SERVE · SEPARATE PRODUCT Tidal Telemetry Our LLM observability product — request access and run it yourself. No managed engagement required. Free in beta no credit card · beta users keep a free plan One line of code · ~50 auto-instrumented libraries Plain OpenTelemetry ingest · the SDK is optional Per-call cost, tokens, latency and errors as traces Isolated per-project storage and ingest key Built-in MCP server for agent-driven setup No engagement prerequisite · use it and never talk to us See Tidal Telemetry → SEC. 05 — Reference Common questions. Missing something? Email hello@finopsllm.com — we respond within one business day. How much can we save? [+] Typical reduction in the first full billing cycle after implementation is 40–60% , depending on architecture and traffic mix. Real targets are set after a provider-invoice audit and workload review. Does FinOps LLM support chargeback & showback? [+] Yes. Token-level attribution to providers, models, features, teams, and customer cohorts. Monthly chargeback and showback exported to NetSuite, QuickBooks, CSV, or API . Custom dimensions supported. How do you handle customer data? [+] Read-only by default. Billing and usage data is enough for most attribution work. Prompt and output data is only accessed with explicit approval, for specific optimizations that require it. NDA and DPA available on request. How long does implementation take? [+] Attribution and dashboards go live in under a week . Optimization implementation takes 3–5 weeks; savings appear on the first full provider invoice after go-live. Will optimization hurt output quality? [+] No. Every routing, caching, and compression change is A/B tested against production for seven days minimum before promotion. Regressions auto-rollback. Quality is monitored continuously alongside cost. Which providers are supported? [+] OpenAI, Anthropic, Gemini & Vertex AI, AWS Bedrock, Azure OpenAI, Groq, Together, Mistral, Cohere, Fireworks, Replicate, and most OSS endpoints. Multi-provider deployments typically have the largest savings surface. SEC. 06 — Research Engineering guides that show up in AI answers. Deep dives on LLM cost attribution, monitoring, caching, and governance. Cited by Microsoft Copilot when buyers research AI FinOps. GUIDE NEW Chargeback vs showback Which FinOps cost allocation model fits your team, and how to migrate from visibility to budget accountability. High search demand GUIDE NEW IT chargeback and showback for AI Apply chargeback and showback to LLM and GenAI spend: allocation rules, implementation steps, and common mistakes. High search demand GUIDE NEW Showback comes before chargeback Why leading FinOps teams start with showback, clean their data, and only then transfer budget ownership. High search demand GUIDE 296 FinOps for LLM The complete framework for visibility, attribution, optimization, and accountability across LLM and GenAI spend. Copilot citations GUIDE 274 LLM cost monitoring How production teams track token spend, set alerts, and build a real-time cost cockpit across providers. Copilot citations GUIDE NEW LLM cost monitoring in production Production monitoring stack, alert runbooks, and the metrics that catch spikes before they hit your invoice. High citation demand GUIDE 93 Agent spend guardrails Budgets, rate limits, and circuit breakers for autonomous agents that can loop, retry, and surprise you. Copilot citations GUIDE NEW Agent guardrails for production Runtime controls, kill switches, and production metrics that keep agents from becoming runaway bills. High citation demand GUIDE 86 How much does GPT-5 cost? Token pricing, expected tiers, and how to model spend for reasoning and frontier models. Copilot citations Browse all research → SEC. 07 — Start here Start with a clear picture of your AI spend. About a week. Read-only access. We return with a full map of your spend, ranked by waste, plus a baseline our cockpit can track against. Free. No implementation commitment. Book free audit → hello@finopsllm.com 30-min discovery · read-only by default · NDA + DPA on request · no commitment --- # About FinOps LLM · Attribution and Cost Governance URL: https://finopsllm.com/about FinOps for teams running production AI. FinOps LLM is focused on one problem: making LLM and GenAI spend attributable, governable, and optimizable without slowing engineering teams down. The product direction combines provider invoice reconciliation, token-level attribution, anomaly detection, model routing, semantic caching, prompt caching, and chargeback/showback workflows. How we work Read-only billing and usage access by default. Optimization targets set after a real provider-invoice baseline. Quality and cost changes measured together, not separately. Contact: hello@finopsllm.com What we actually do An engagement starts with a baseline, not a recommendation. We reconcile the provider invoices against usage exports for a full billing period, so every later claim of savings is measured against a number both sides already agreed on. Optimization proposals that arrive before that baseline exists are guesses — the invoice is the only ledger that settles the argument. From there the work is ordinary and unglamorous: attribute spend to the teams and features that caused it, find the workloads whose cost per successful task is out of line with their value, and change the cheapest things first. Prompt caching and batch routing usually come before model substitution, because they do not change what the user sees and therefore do not need a quality trial to justify. What we won't do Quote a savings percentage before the baseline. Published numbers from vendor case studies rarely survive contact with a different traffic mix. Read prompts or outputs by default. Baseline attribution needs billing and usage metadata, not content. Content review happens only when a named optimization requires it and the customer approves it. Ship a change without a quality measurement. A cost reduction that quietly degrades answers is a product regression wearing a finance costume. Who this is for Teams past the experiment stage — production LLM traffic, a bill large enough that someone in finance has started asking about it, and enough engineering ownership that the answer can actually change. If AI spend is still on a single company card and nobody is being asked to explain it, the honest advice is to wait and set up attribution first, which is the one thing worth building before you need it. Back to FinOps LLM --- # بحث الويب للوكلاء يتحول إلى مركز تكلفة · FinOps LLM URL: https://finopsllm.com/ar/research/agent-web-search-cost-center بحث الويب للوكلاء يتحول إلى مركز تكلفة آخر تحديث September 10, 2026 · نُشر أول مرة September 10, 2026 إجابة سريعة: ينتقل وكلاء الذكاء الاصطناعي من المعرفة الثابتة إلى البحث المباشر على شبكة الإنترنت، وهذا يغير النموذج المالي للتكلفة جذرياً. يمكن لطلب مستخدم واحد الآن أن يطلق عدة عمليات بحث على الويب، واستدعاءات... ينتقل وكلاء الذكاء الاصطناعي من المعرفة الثابتة إلى البحث المباشر على شبكة الإنترنت، وهذا يغير النموذج المالي للتكلفة جذرياً. يمكن لطلب مستخدم واحد الآن أن يطلق عدة عمليات بحث على الويب، واستدعاءات نماذج متكررة لتفسير كل نتيجة، ومحاولات إعادة عند فشل الأدوات، وصياغة نهائية للحل. لم تعد طبقة البحث بنية تحتية مجانية خفية؛ بل أصبحت جزءاً مستقلاً يُفوتر بالاستخدام الفعلي. على سبيل المثال، توثق منصة Amazon Bedrock AgentCore ميزة البحث على الويب كإمكانية مسعرة بنحو 7 دولارات لكل 1,000 استعلام بحث. وتختلف الأسعار بحسب المزود والمنتج، ولكن الدرس المالي لـ FinOps عالمي: احتسب استدعاءات أدوات البحث كعمل قابل للفوترة جنباً إلى جنب مع رموز الإدخال والإخراج. الطلب الواحد قد يتحول إلى عشرات الاستعلامات ينشأ تضخم البحث من التخطيط الذاتي للوكيل؛ فقد يعيد الوكيل صياغة السؤال، ويبحث في مصادر متعددة، ويتتبع الروابط، ويعيد المحاولة عند انتهاء المهلة، ويبحث مجدداً عند اكتشاف أدلة متناقضة. إذا كان التطبيق يسجل فقط طلب المستخدم الأصلي، فستشاهد المالية ميزة منخفضة الحركة بينما يرى المزود حمولة عمل ضخمة من استدعاءات الأدوات المكلفة. سجل معرف المهمة الأصلية، ومزود البحث، وعدد الاستعلامات، والنتائج المسترجعة، ومرات إعادة المحاولة، وما إذا كانت النتيجة قد غيرت الإجابة النهائية. ثم احسب تكلفة البحث لكل مهمة ناجحة. فالبحث الذي لا يسهم أبداً في إجابة مفيدة هو مرشح فوري لتعديل السياسة وليس مجرد بند تكلفة نتقبله سلباً. ضوابط التحكم في ميزانية البحث وضع سقف أقصى لعدد استعلامات البحث لكل مهمة ولكل فئة من فئات المستخدمين. استخدام مسح أولي خفيف للاستكشاف، وحجز البحث العميق للمهام الاستراتيجية عالية القيمة. التخزين المؤقت للاستعلامات الثابتة وتوحيد الفروق اللغوية البسيطة في صياغة الأسئلة. إيقاف البحث فور بلوغ عتبة الأدلة الكافية بدلاً من ترك المخطط يستمر في الاستكشاف اللانهائي. تطبيق تأخير تصاعدي لإعادة المحاولة ووضع سقف لها بشكل مستقل عن إعادة استدعاء النماذج. قياس حداثة المعلومات مقابل الإنفاق تكون حداثة المعلومات ذات قيمة فقط عندما تغير القرار المتخذ. قارن جودة الإجابة ونجاح المهمة عبر أعماق بحث مختلفة: بدون بحث، وبحث لمرة واحدة، وبحث متعدد مقيد. بعض مسارات العمل تتطلب أحدث البيانات؛ والبعض الآخر يدفع تكلفة استرجاع متكرر لحقائق تتغير ببطء شديد. قدم التقارير المالية متضمنة ثلاثة أرقام معاً: تكلفة النموذج، وتكلفة البحث، والتكلفة لكل مهمة ناجحة. يمنع هذا نموذجاً رخيصاً من الظهور بمظهر عالي الكفاءة بينما يعوض ضعفه بالاعتماد على أعداد هائلة من عمليات البحث المدفوعة. مقالات ذات صلة أثر تكلفة خوادم MCP التكلفة لكل مهمة ناجحة أدوات الخوادم تُفوتر خارج عداد الرموز هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # قياس إجمالي هامش ربح ميزات الذكاء قبل الإطلاق · FinOps LLM URL: https://finopsllm.com/ar/research/ai-feature-gross-margin قياس إجمالي هامش ربح ميزات الذكاء قبل الإطلاق آخر تحديث September 2, 2026 · نُشر أول مرة September 2, 2026 إجابة سريعة: يتحمس مهندسو المنتجات لطرح قدرات الذكاء الاصطناعي التوليدي لمستخدميهم، لكن إطلاق هذه الميزات دون قياس دقيق لاقتصاديات الاستدلال قد يحول منتجاً رابحاً إلى خدمة خاسرة تلتهم أرباح الشركة السحابية. يوضح... يتحمس مهندسو المنتجات لطرح قدرات الذكاء الاصطناعي التوليدي لمستخدميهم، لكن إطلاق هذه الميزات دون قياس دقيق لاقتصاديات الاستدلال قد يحول منتجاً رابحاً إلى خدمة خاسرة تلتهم أرباح الشركة السحابية. يوضح هذا الدليل كيفية قياس الهامش الإجمالي لميزات الذكاء بدقة في مرحلة الاختبار والتجهيز (Staging). القياس قبل الإطلاق وليس بعد الفاتورة يجب تزويد الميزة بأدوات القياس عن بعد أثناء تطويرها. سجل الرموز المستهلكة في كل طلب، وحجم استدعاءات الأدوات، ومعدلات التخزين المؤقت، والتكلفة الإجمالية بالدولار لكل حساب مستخدم. محاكاة سيناريوهات الاستخدام الكثيف تكشف العيوب الاقتصادية في التصميم قبل أن تصبح التزامات مالية واقعية. الانتباه لذيل الاستخدام المرتفع (Usage Tail Risk) إن الاعتماد على متوسط التكلفة لكل مستخدم يمثل فخاً خطيراً. في ميزات الذكاء الاصطناعي، يتبع الاستهلاك غالباً توزيع القوة (Power Law): 5% من المستخدمين يستهلكون 80% من إجمالي رموز الاستدلال. إذا كان تسعير المنتج ثابتاً، فإن هؤلاء المستخدمين المفرطين سيقضون تماماً على هامش ربح بقية الحسابات. ربط الأرقام بقرارات الإطلاق والتسعير بناءً على نتائج بيئة الاختبار، يمكن اتخاذ قرارات مبكرة مثل: تحديد سقف استهلاك شهري عادل، أو إتاحة الميزة فقط للباقات الأعلى سعراً، أو تحسين المطالبات والتخزين المؤقت لتقليص تكلفة الاستدلال بنسبة 60% قبل فتح الباب لكافة المستخدمين. مقالات ذات صلة التكلفة لكل مهمة ناجحة الباقة المجانية كتكلفة اكتساب حلقات إعادة المحاولة والإنفاق الخفي هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # انحراف إنفاق الذكاء: الحجم والسعر والمزيج · FinOps LLM URL: https://finopsllm.com/ar/research/ai-spend-variance-bridge انحراف إنفاق الذكاء: الحجم والسعر والمزيج آخر تحديث August 27, 2026 · نُشر أول مرة August 27, 2026 إجابة سريعة: عندما تتجاوز فاتورة استهلاك نماذج الذكاء الاصطناعي الميزانية المحددة، يحتاج الفريق الهندسي إلى تقديم إجابات دقيقة للإدارة المالية بدلاً من التبريرات الغامضة. يوفر جسر الانحراف الرباعي لغة مشتركة تربط... عندما تتجاوز فاتورة استهلاك نماذج الذكاء الاصطناعي الميزانية المحددة، يحتاج الفريق الهندسي إلى تقديم إجابات دقيقة للإدارة المالية بدلاً من التبريرات الغامضة. يوفر جسر الانحراف الرباعي لغة مشتركة تربط بين الأرقام المحاسبية والقرارات المعمارية في الكود. المحاور الأربعة لجسر انحراف الإنفاق يتم تحليل فارق التكلفة عبر تفكيكه إلى: انحراف الحجم (Volume): ناتج عن تغير أعداد المستخدمين أو تكرار الطلبات الإجمالية على الميزة. انحراف السعر (Rate): ناتج عن تغير أسعار المزودين، أو الخصومات، أو تبدل أسعار التخزين المؤقت. انحراف المزيج (Mix): يعكس تحول مسارات التنفيذ بين نماذج خفيفة ورخيصة ونماذج تفكير متقدمة وباهظة. انحراف الكفاءة (Efficiency): يقيس التغير في عدد الرموز المستهلكة لإنجاز نفس العمل، متضمناً أطوال السياق وإعادة المحاولة. بناء جسر الانحراف الهندسي من خلال تسجيل بيانات كل استدعاء (النموذج، رموز الإدخال، رموز الإخراج، رموز التخزين المؤقت، زمن الاستجابة، النتيجة)، يمكن للفرق حساب تأثير كل محور بدقة. يتيح هذا النهج معرفة ما إذا كانت الميزانية بحاجة للتعديل لمواكبة نمو الأعمال الفعلي، أم أن الكود يحتاج لتحسينات عاجلة لإزالة الهدر في السياق والمطالبات. مقالات ذات صلة مراقبة تكاليف نماذج اللغة الكبيرة توزيع تكاليف الذكاء الاصطناعي كيفية إعداد ميزانية الذكاء الاصطناعي هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # مقارنة تكلفة Azure OpenAI مع OpenAI المباشر · FinOps LLM URL: https://finopsllm.com/ar/research/azure-openai-vs-direct-cost مقارنة تكلفة Azure OpenAI مع OpenAI المباشر آخر تحديث September 19, 2026 · نُشر أول مرة July 12, 2026 إجابة سريعة: على أساس الدفع حسب الاستخدام القياسي، تتطابق أسعار Azure OpenAI مع واجهة OpenAI API المباشرة في عمليات النشر العالمية: على سبيل المثال 2.50 دولار لكل مليون رمز إدخال و15 دولاراً لكل مليون رمز إخراج... على أساس الدفع حسب الاستخدام القياسي، تتطابق أسعار Azure OpenAI مع واجهة OpenAI API المباشرة في عمليات النشر العالمية: على سبيل المثال 2.50 دولار لكل مليون رمز إدخال و15 دولاراً لكل مليون رمز إخراج للنماذج المتقدمة. لا يكمن الفارق الاقتصادي في السعر الأساسي للطلبات، بل في ثلاثة محاور هيكلية: وحدات الإنتاجية المخصصة (PTU) ، و رسوم مناطق البيانات الإقليمية ، و خصومات المؤسسات عبر اتفاقية مايكروسوفت (EA) . 1. الإنتاجية المخصصة (PTU) مقابل المحاسبة بالرمز توفر Azure سعة مخصصة للنماذج عبر وحدات PTU. حسب الطلب تبلغ تكلفة الوحدة دولارين في الساعة. ومع حجز لمدة شهر واحد، تنخفض التكلفة إلى حوالي 260 دولاراً لكل وحدة شهرياً — وهو خصم يصل إلى 82% مقارنة بالسعر بالساعة (ويصل إلى 85% للالتزامات السنوية). نقطة التعادل لحجز PTU تتطلب عادةً معدل استخدام مستمر يتجاوز 65% إلى 75% . إذا كان حجم العمل أقل من ذلك أو متقطعاً، فإن الفوترة القائمة على الرموز تكون أكثر توفيراً. 2. الرسوم الإقليمية لسيادة البيانات تعكس نقاط النهاية العالمية لـ Azure أسعار الولايات المتحدة المباشرة. ومع ذلك، تفرض عمليات النشر المحصورة إقليمياً (مثل مراكز بيانات أوروبا أو الخليج) رسوماً إضافية تتراوح بين 10% إلى 20% لضمان إقامة البيانات وسيادتها. 3. تكاليف البنية التحتية الإضافية تتطلب بيئة Azure مكونات مرافقة: نقاط النهاية الخاصة (Private Endpoints)، وتسجيل Azure Monitor، ونقل البيانات عبر الشبكة الافتراضية، ورسوم بوابة API Management. تضيف هذه المكونات ما بين 4% إلى 8% على التكلفة الفعلية، مقابل توفير أمان متقدم وتحكم في الوصول RBAC. مقالات ذات صلة خصومات الإنفاق الملتزم به لماذا يصعب مقارنة أسعار المزودين هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # الوكلاء في الخلفية يغيرون ساعة FinOps · FinOps LLM URL: https://finopsllm.com/ar/research/background-agents-cost-clock الوكلاء في الخلفية يغيرون ساعة FinOps آخر تحديث September 10, 2026 · نُشر أول مرة September 10, 2026 إجابة سريعة: يغير التنفيذ في الخلفية (Background Execution) العلاقة الكلاسيكية بين زمن تواجد المستخدم وتكلفة الحوسبة. عندما يعمل الوكيل بشكل غير متزامن، فإن استهلاك الرموز، واستدعاءات الأدوات، ومحاولات إعادة... يغير التنفيذ في الخلفية (Background Execution) العلاقة الكلاسيكية بين زمن تواجد المستخدم وتكلفة الحوسبة. عندما يعمل الوكيل بشكل غير متزامن، فإن استهلاك الرموز، واستدعاءات الأدوات، ومحاولات إعادة التنفيذ تستمر في العمل لساعات طويلة بعد أن يغلق المستخدم متصفحه أو يغادر مكتبه، مما يحول ساعة التكلفة إلى تدفق مستمر لا ينام. ساعة التكلفة غير المتزامنة في التطبيقات التفاعلية، يتوقف الإنفاق فور توقف المستخدم عن الكتابة. أما في مهام الخلفية (مثل مسح المستودعات البرمجية، أو تدقيق آلاف المستندات، أو مراقبة البيانات)، فإن الوكلاء يعملون بحرية تامة. في غياب حواجز الميزانية الصارمة، يمكن لخلل منطقي بسيط في التخطيط الذاتي أن يولد ملايين الرموز في ليلة واحدة دون أي رقابة بشرية. الضوابط الثلاث للوكلاء في الخلفية للسيطرة على إنفاق المهام غير المتزامنة: ميزانية قصوى لكل مهمة (Task Budget Cap): تخصيص سقف مالي محدد لكل مهمة خلفية؛ فور بلوغه يتوقف الوكيل ويحفظ حالته في انتظار الموافقة البشرية. مهلة زمنية صارمة (Strict Wall-Clock Timeout): تحديد حد أقصى للوقت المسموح للمهمة بالعمل فيه، لمنع العلوق في حلقات تفكير مفرغة. إغلاق الحلقة والتوثيق (Loop Closure): إشعار المستخدم فور اكتمال العمل وتوثيق التكلفة الإجمالية المحققة في سجلات النظام. مقالات ذات صلة ميزانيات الوكلاء الثلاث حواجز إنفاق الوكلاء المستقلين التكلفة لكل مهمة ناجحة هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # Claude Opus 5.5: $4/$20 و$0.20 قراءة الذاكرة المؤقتة · FinOps LLM URL: https://finopsllm.com/ar/research/claude-opus-5-5-cost-model نموذج تكلفة Claude Opus 5.5 آخر تحديث September 22, 2026 · نُشر أول مرة September 22, 2026 أصدرت Anthropic Claude Opus 5.5 ( claude-opus-5-5 ) في 22 سبتمبر 2026. السعر الأساسي هو $4 لكل مليون رمز إدخال و$20 لكل مليون رمز إخراج، انخفاضاً من $5 و$25 على Opus 5. هذا انخفاض بنسبة 20%. بالنسبة لمعظم أحمال العمل الإنتاجية، الانخفاض الفعلي أكبر، لأن السعر الذي تحرك أكثر هو السعر الذي تستبعده الصورة الأساسية. الأسعار التي تهم نوع الرمز Opus 5.5 Opus 5 Fable 5.1 الإدخال (غير مخزن مؤقتاً) $4.00 / MTok $5.00 / MTok $10.00 / MTok الإخراج $20.00 / MTok $25.00 / MTok $50.00 / MTok كتابة الذاكرة المؤقتة (5 دقائق) $5.00 / MTok $6.25 / MTok $12.50 / MTok قراءة الذاكرة المؤقتة $0.20 / MTok $0.50 / MTok $0.25 / MTok الوضع السريع (الإدخال / الإخراج) $8 / $40 — — كل صف أقل بنسبة 20% باستثناء قراءة الذاكرة المؤقتة، وهي أقل بنسبة 60%. عند $0.20 فهي الآن أرخص من $0.25 في Fable 5.1. هذا يعكس الصف الوحيد حيث اعتادت Fable على الفوز. في نموذج تكلفة Fable 5.1 ، كان بإمكان حمل عمل مخزن مؤقتاً بكثافة أن ينتهي به الحال أرخص على Fable منه على Opus 5. ضد Opus 5.5 لا يحدث هذا بعد الآن. Fable يكلف أكثر على كل نوع رمز. لماذا المهمة النموذجية تكلف حوالي 40% أقل مطالبة Anthropic هي انخفاض بنسبة 40% في التكلفة للوظيفة النموذجية، وليس 20%. الإضافية تأتي من كفاءة الرمز. تقول Anthropic أن Opus 5.5 يحقق نفس النتيجة برموز إدخال وإخراج أقل بحوالي 20% ويكتب إخراجاً أقل تفصيلاً بحوالي 40%. السعر المنخفض مضروباً في الرموز الأقل يركب: 0.8 × 0.8 = 0.64، وهو تقريباً خصم 36-40% اعتماداً على المزيج. إليك خطوة وكيل واحدة: 200,000 رمز إدخال، 90% يُقدم من الذاكرة المؤقتة، و20,000 رمز إخراج. السطر Opus 5 Opus 5.5 (نفس الرموز) Fable 5.1 20K إدخال غير مخزن مؤقتاً $0.100 $0.080 $0.200 180K إدخال مخزن مؤقتاً $0.090 $0.036 $0.045 20K إخراج $0.500 $0.400 $1.000 الإجمالي $0.690 $0.516 $1.245 على الرموز المتطابقة، Opus 5.5 أرخص بنسبة 25% من Opus 5، وليس 20%، بسبب خصم الذاكرة المؤقتة. إذا كان انخفاض الرموز بنسبة 20% صحيحاً لحمل العمل الخاص بك، فإن الخطوة تنخفض إلى حوالي $0.41، وهو 40% تحت Opus 5 وثلث تكلفة Fable. الإخراج لا يزال حوالي 80% من الفاتورة في هذا المثال. هذا هو المكان الذي يستحق فيه تقليل الإطالة. التكلفة لكل مهمة مقارنةً بـ GPT-6 Sol وGPT-6 Astra وFable 5.1 أسعار القائمة لكل مليون رمز، وخطوة الوكيل نفسها المذكورة أعلاه (200 ألف رمز إدخال، 90% منها من الذاكرة المؤقتة، و20 ألف رمز إخراج) محسوبة على كل نموذج. النموذج الإدخال $/MTok الإخراج $/MTok قراءة الذاكرة المؤقتة $/MTok خطوة الوكيل نفسها GPT-6 Sol $2.00 $10.00 $0.20 $0.276 Claude Opus 5.5 $4.00 $20.00 $0.20 $0.516 Claude Opus 5 $5.00 $25.00 $0.50 $0.690 Claude Fable 5.1 $10.00 $50.00 $0.25 $1.245 GPT-6 Astra $10.00 $50.00 $1.00 $1.380 التكلفة المقيسة لكل مهمة على مؤشر Artificial Analysis Intelligence Index v4.3.2، بتاريخ 22 سبتمبر 2026، مرتبة حسب النتيجة. GPT-6 Sol هو الطريق الأرخص إلى أي نتيجة حتى 47.5. فوق ذلك يكون Opus 5.5 الأرخص في كل مستوى: يحقق Opus 5.5 high نتيجة 53.6 مقابل 1.82 دولار، بينما يحقق GPT-6 Astra max نتيجة 52.7 مقابل 3.26 دولار وFable 5.1 max نتيجة 53.4 مقابل 7.63 دولار. النموذج Intelligence Index التكلفة لكل مهمة رموز الإخراج لكل مهمة GPT-6 Sol · medium 39.8 $0.25 6,500 GPT-6 Sol · xhigh 44.1 $0.53 16,000 GPT-6 Astra · low 45.8 $0.82 4,400 GPT-6 Sol · max 47.5 $1.06 31,200 Claude Opus 5 · high 48.1 $3.61 46,200 Claude Opus 5 · max 50.8 $5.86 72,500 Claude Opus 5.5 · medium 51.2 $1.34 25,700 Claude Fable 5.1 · high 51.2 $3.91 38,100 GPT-6 Astra · max 52.7 $3.26 27,200 Claude Fable 5.1 · max 53.4 $7.63 78,100 Claude Opus 5.5 · high 53.6 $1.82 35,600 Claude Opus 5.5 · max 57.6 $5.98 119,200 كل إعدادات GPT-6 Astra فوق low وكل إعدادات Opus 5 وكل إعدادات Fable 5.1 أغلى من إعداد لـ Sol أو Opus 5.5 يحقق النتيجة نفسها أو أعلى. تعتمد التكلفة لكل مهمة على مزيج مهام المعيار. أعد تشغيل حركة مرورك الفعلية قبل تبديل النموذج. هل هو جيد بما يكفي لاستبدال Fable? تضع Anthropic Opus 5.5 كمطابق لـ Fable 5.1 على معظم المهام. تدعم الأرقام المنشورة ذلك لأعمال الترميز والوكالة: Terminal-Bench 4.0: 66.4%، مقابل 52.3% لـ Opus 5 و55.8% لـ Fable 5.1. FrontierCode v1.1: 54.4%، مقابل 48.0% لـ Opus 5 و50.3% لـ Fable 5.1. CursorBench 4.0: 57.8%، مقابل 46.6% لـ Opus 5. GDPval-AA v2.1: 1846 Elo، مقابل 1708 لـ Opus 5. صنفته Artificial Analysis أولاً في مؤشرها للذكاء في يوم الإطلاق. تقول Anthropic أيضاً أنه بجهد افتراضي (متوسط) فهو يتفوق على GPT-6 Astra بأقصى جهد في عمل المعرفة لحوالي خُمس التكلفة لكل مهمة. هذه مقارنة بائع، لذا تعامل معها كفرضية للاختبار. رياضيات التكلفة أعلاه هي الجزء الذي يمكنك التحقق منه بنفسك. الوضع السريع يكلف 2× الوضع السريع يكلف $8 في و$40 خارجاً، ضعف السعر القياسي بالضبط، مقابل ما يصل إلى 2.5× السرعة. النموذج القياسي أيضاً أسرع بحوالي 30% من Opus 5. استخدم الوضع السريع للمسارات التفاعلية المرتبطة بالكمون حيث ينتظر المستخدم. احفظه بعيداً عن الأعمال الدفعية والوكلاء في الخلفية والتقييمات. عندما يكون الوضع السريع مُفعلاً بشكل افتراضي، تتضاعف تكلفة الوحدة ولا يظهر لوحة المعلومات شيئاً غير عادي حتى تصل الفاتورة. ماذا تفعل هذا الأسبوع ثبّت معرف النموذج. وجّه الإنتاج إلى claude-opus-5-5 بشكل صريح وسجل المعرف في كل طلب، بحيث يمكن تقسيم التكلفة لكل طلب حسب النموذج بعد الهجرة. أعد البناء على حركة المرور الخاصة بك. أعد تشغيل عينة من الطلبات الحقيقية على كلا النموذجين وقارن الرموز لكل مهمة مكتملة، وليس لكل نداء. يُعتبر ادعاء كفاءة الرموز بنسبة 20% هو الجزء الأكثر احتمالاً للاختلاف حسب حمل العمل. أعد التحقق من إعدادات الجهد. إذا انتقل حمل العمل إلى Fable أو إلى الحد الأقصى من الجهد للحصول على الجودة، اختبر Opus 5.5 أولاً بوسط. هذا هو الإعداد الذي تقيس Anthropic عليه. أعد تشغيل قرار توجيه Fable. يجب إعادة تقييم أي مسار أرسل حركة مرور مخزنة مؤقتاً بكثافة إلى Fable للحصول على قراءة ذاكرة مؤقتة أرخص. ذهب هذا الميزة التكلفة. راقب نسبة ضربة الذاكرة المؤقتة. بـ $0.20 مقابل $4.00، يكلف إخفاق الذاكرة المؤقتة الآن 20× ضربة. تغيير قالب الموجه الذي يكسر البادئة يكلف أكثر مما كان عليه على Opus 5. تقول Anthropic أن Sonnet 5.5 و Haiku 5.5 ستتبع في الأسابيع القادمة. احتفظ بسخام الإعادة من الخطوة 2 بحيث يمكن إعادة البناء لكل إصدار في فترة ما بعد الظهر. مقالات ذات صلة نموذج تكلفة Claude Fable 5.1 اقتصاديات تخزين الموجهات مؤقتاً مستويات جهد Opus 5.5 هي السعر الحقيقي اقتصاديات الوضع السريع Opus 5.5 هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # التكلفة لكل مهمة ناجحة مقابل تكلفة الطلب · FinOps LLM URL: https://finopsllm.com/ar/research/cost-per-successful-task التكلفة لكل مهمة ناجحة مقابل تكلفة الطلب آخر تحديث August 27, 2026 · نُشر أول مرة August 27, 2026 إجابة سريعة: يعد قياس التكلفة لكل طلب مفيداً، لكنه ليس الوحدة التي يشتريها المستخدم. الطلب الذي يفشل، أو يعيد المحاولة ثلاث مرات، أو ينتج إجابة غير صالحة للاستخدام لا يمثل وحدة عمل ناجحة. في بيئات الإنتاج، المقياس... يعد قياس التكلفة لكل طلب مفيداً، لكنه ليس الوحدة التي يشتريها المستخدم. الطلب الذي يفشل، أو يعيد المحاولة ثلاث مرات، أو ينتج إجابة غير صالحة للاستخدام لا يمثل وحدة عمل ناجحة. في بيئات الإنتاج، المقياس الأكثر دقة وموثوقية هو التكلفة لكل مهمة ناجحة : إجمالي تكاليف النماذج والأدوات مقسوماً على المهام التي حققت معايير الجودة المطلوبة. المعادلة الحسابية استخدم المعادلة: تكلفة المهمة الناجحة = إجمالي الإنفاق المنسوب / عدد المهام الناجحة . يشمل ذلك تكاليف رموز الإدخال والإخراج، والتخزين المؤقت، ورموز التفكير الاستدلالي (reasoning)، واستدعاء الأدوات، وإعادة المحاولة، ومسارات التراجع (fallback). حدد شروط النجاح مسبقاً: مثل قبول إجابة الدعم من العميل، أو تصنيف يتجاوز حد الثقة، أو سير عمل اكتمل دون تدخل بشري للتصحيح. لماذا تضلل متوسطات الطلبات تنخفض متوسطات تكلفة الطلب ظاهرياً عند احتساب المحاولات الفاشلة الرخيصة. كما تخفي الحالات الشاذة المكلفة: قد يكون لخاصية معينة متوسط تكلفة منخفض، بينما تستهلك حالاتها الفاشلة استدلالاً مكلفاً ومراجعة بشرية مطولة. قم بتقسيم البيانات حسب الخاصية والنموذج وفئة العملاء والنتيجة، واعرض تكلفة المهام الناجحة عند الشريحتين p50 وp95. مراقبة مقام المعادلة بدقة يحتاج كل استدعاء للنموذج إلى معرف طلب (request ID) ووسم للخاصية؛ ويجب على التطبيق إصدار حدث بالنتيجة مرتبط بهذا المعرف. سجل النجاح، وسبب الفشل، وزمن الاستجابة، وأي تصحيح بشري. قم بمطابقة فواتير المزودين في البسط وعاين عينات من المهام للتحقق من المقام. توجيه التحسينات الهندسية إذا كانت تكلفة الطلب مرتفعة ولكن معدل النجاح ممتاز، فإن التخزين المؤقت أو التوجيه الذكي قد يساعدان. أما إذا كانت تكلفة الطلب منخفضة ولكن تكلفة المهمة الناجحة مرتفعة، فالمشكلة في الجودة: تكرار المحاولات، أو سياق غير كافٍ، أو قواعد توقف ضعيفة. مقالات ذات صلة مراقبة تكاليف النماذج اللغوية توزيع تكاليف الذكاء الاصطناعي هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # التكلفة الحقيقية للتبديل بين مزودي النماذج · FinOps LLM URL: https://finopsllm.com/ar/research/cost-switching-llm-providers التكلفة الحقيقية للتبديل بين مزودي النماذج آخر تحديث August 27, 2026 · نُشر أول مرة August 27, 2026 إجابة سريعة: قد يبدو التحول إلى مزود جديد يقدم أسعاراً أقل للرموز بنسبة 50% قراراً هندسياً بديهياً. ومع ذلك، في الأنظمة المؤسسية، نادراً ما تتحول التخفيضات النظرية إلى وفورات صافية فورية بسبب التكاليف الخفية... قد يبدو التحول إلى مزود جديد يقدم أسعاراً أقل للرموز بنسبة 50% قراراً هندسياً بديهياً. ومع ذلك، في الأنظمة المؤسسية، نادراً ما تتحول التخفيضات النظرية إلى وفورات صافية فورية بسبب التكاليف الخفية لعملية الترحيل الهندسي والتشغيل المزدوج ومخاطر انحدار الجودة. حساب أعباء وتكاليف الهجرة الهندسية يتطلب نقل عبء عمل إنتاجي من مزود إلى آخر جهداً هندسياً مكثفاً يشمل: إعادة هندسة المطالبات (Prompt Adaptation) لتناسب حساسية وتنسيقات النموذج الجديد. تحديث مخططات الأدوات ومحللات مخرجات JSON البرمجية. بناء خطوط تقييم معياري شاملة للتأكد من مطابقة الأداء والامتثال للأمان والخصوصية. تكاليف التشغيل المزدوج ومخاطر الجودة لا يمكن استبدال المزود في بيئة الإنتاج بضغطة زر واحدة. يتطلب الانتقال الآمن فترة تشغيل متزامن (Dual-Running) لعدة أسابيع، حيث تُرسل الطلبات لكلا المزودين لمقارنة النتائج والكمون، مما يضاعف تكلفة الاستدلال مؤقتاً. كما يجب احتساب تكلفة تراجع الجودة المحتمل في حال زيادة الشكاوى أو الحاجة لمراجعات بشرية. معادلة استرداد تكلفة التحول تُحسب جدوى القرار بقسمة تكاليف الهندسة والتشغيل المزدوج على صافي التوفير الشهري الحقيقي. إذا كانت المدة تتجاوز دورة حياة استقرار أسعار السوق الحالية، فإن الاستثمار في طبقة توجيه ديناميكية (Model Routing Layer) تدعم عدة مزودين في نفس الوقت هو الخيار الأكثر كفاءة ومرونة للمؤسسة. مقالات ذات صلة الموازحة بين مزودي خدمات الذكاء إدارة مخاطر تركز المزودين التوجيه الديناميكي للنماذج هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # سبعة أنماط دفاعية في DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/ar/research/deepseek-harness-defensive-patterns سبعة أنماط دفاعية في DeepSeek Harness آخر تحديث August 16, 2026 · نُشر أول مرة August 16, 2026 إجابة سريعة: توثق الشفرة المصدرية لـ DeepSeek Harness مجموعة من الأنماط الدفاعية الأساسية في هندسة برمجيات الوكلاء المستقلين لمنع تسرب الموارد وانهيار الجلسات الطويلة واستنزاف الرموز عند حدوث أخطاء غير متوقعة. 1.... توثق الشفرة المصدرية لـ DeepSeek Harness مجموعة من الأنماط الدفاعية الأساسية في هندسة برمجيات الوكلاء المستقلين لمنع تسرب الموارد وانهيار الجلسات الطويلة واستنزاف الرموز عند حدوث أخطاء غير متوقعة. 1. الإبلاغ المنفصل عن النتائج المتعامدة فصل حالة نجاح المهمة عن حالة استهلاك الموارد؛ يجب أن يُسجل استهلاك الرموز والوقت حتى لو انتهت المهمة بفشل منطقي، لضمان عدم ضياع بيانات الفوترة والقياس المالي. 2. الالتزام الصارم بالعقود البرمجية للواجهات التحقق الصارم من صحة المدخلات والمخرجات على طرفي الاستدعاء قبل تمرير البيانات للنموذج أو تنفيذ نصوص الأدوات، مما يحمي النظام من حقن التعليمات الخبيثة أو التنسيقات المشوهة. 3. التمييز بين الحالة المتزامنة وغير المتزامنة عدم افتراض اكتمال العمليات غير المتزامنة فوراً؛ إدارة دورة حياة الوكلاء وحفظ الحالة في سجل الأحداث قبل الانتقال للخطوة التالية لتفادي التعارض وتلف البيانات. 4. التخلص الفعلي والآمن من الموارد (Resource Disposal) عند إغلاق الجلسة أو إلغاء مهمة وكيل، يجب ضمان إيقاف العمليات الفرعية وإغلاق اتصالات الشبكة وتحرير الذاكرة بدلاً من مجرد طلب الإلغاء الشكلي. 5. احتواء استثناءات ردود النداء (Callbacks) في الموزع عزل استثناءات الأدوات والإضافات الخارجية بحيث لا يتسبب خطأ في إضافة فرعية بانهيار حلقة الوكيل الرئيسية أو فقدان سجل الجلسة بأكمله. 6. حماية مسارات البيئة الحساسة من المخرجات غير الموثوقة منع تسريب مسارات النظام أو مفاتيح البيئة إلى مخرجات النماذج أو واجهات المستخدم لمنع الثغرات الأمنية والوصول غير المصرح به. 7. إلغاء ربط المسارات الرمزية المشبوهة (Symlinks) التحقق من المسارات الفعلية للملفات لمنع الوكلاء المستقلين من تجاوز مساحة العمل المحددة والوصول لملفات النظام الحساسة خارج المشروع. مقالات ذات صلة ما هو DeepSeek Harness؟ حواجز الإنفاق في DeepSeek Harness سجل الجلسة كمصدر وحيد للحقيقة هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # تثبيت DeepSeek Harness: الملفات والتشغيل الأول · FinOps LLM URL: https://finopsllm.com/ar/research/deepseek-harness-getting-started تثبيت DeepSeek Harness: الملفات والتشغيل الأول آخر تحديث August 16, 2026 · نُشر أول مرة August 16, 2026 إجابة سريعة: يمثل هذا الدليل الجانب العملي لتشغيل dsh (حزمة DeepSeek Harness): كيفية بدء التشغيل، وما يتطلبه نموذج التركيب المعماري، وأبرز العروض التوضيحية التي تستحق التجربة. أسرع طريقة للتشغيل npx... يمثل هذا الدليل الجانب العملي لتشغيل dsh (حزمة DeepSeek Harness): كيفية بدء التشغيل، وما يتطلبه نموذج التركيب المعماري، وأبرز العروض التوضيحية التي تستحق التجربة. أسرع طريقة للتشغيل npx @deepseek-ai/dsh web يطلق هذا الأمر واجهة المستخدم عبر المتصفح على العنوان http://127.0.0.1:3080 . وهناك خطوتان إلزاميتان قبل أن تتمكن من استخدام منشئ الجلسات: الإعدادات ← النماذج: إدخال مفتاح API الخاص بـ DeepSeek. يتم تفعيل المسار فوراً دون الحاجة لإعادة تشغيل الخادم. اختيار مساحة العمل: إضافة مجلد المشروع وتفعيله. يظل منشئ الجلسات مقفلاً حتى يتم تنشيط مساحة عمل واحدة على الأقل. بمجرد التشغيل، يستطيع الوكيل قراءة الملفات وتعديلها، وتنفيذ أوامر الطرفية، وتفويض المهام لوكلاء فرعيين، وجدولة الأعمال، مع طلب التأكيد البشري وفق سياسة الصلاحيات النشطة. التثبيت من الشفرة المصدرية git clone https://github.com/deepseek-ai/deepseek-harness pnpm install pnpm run build pnpm dsh web المتطلبات الأساسية: Node 22.19 أو أحدث، و Git 2.26 أو أحدث، وتثبيت حزمة pnpm الإصدار pnpm@11.7.0 عبر Corepack. مفتاح API اختياري أثناء البناء لكنه ضروري للتشغيل، ويمكن تمريره عبر متغيرات البيئة أو ملف .env في جذر المشروع. الملفات التعريفية والحزم (Profiles & Bundles) نظراً لأن كل مكون في هذا النظام عبارة عن إضافة (Plugin)، فإن الملف التعريفي (Profile) يحدد قائمة الحزم النشطة والتعديلات الخاصة. تأتي المنصة مع ثلاثة ملفات جاهزة: dsh-base : مهايئات النماذج، ومجموعة الأدوات، والتخزين الدائم. dsh-web-app : واجهة المتصفح الرسومية. dsh-headless : وضع التشغيل المستقل لمرة واحدة دون واجهة. ترتيب أسبقية الإعدادات رباعي الطبقات يتم حل الإعدادات وفق تسلسل صارم، حيث تلغي الطبقات اللاحقة الطبقات السابقة: حزم الملف التعريفي (Profile Bundles) تعديلات الملف التعريفي (Profile Patches) التعديلات العامة على مستوى المجلد الرئيسي (Home-level Patches) معاملات سطر الأوامر (CLI Overlays) - وهي الأعلى أولوية دائماً مقالات ذات صلة ما هو DeepSeek Harness؟ معمارية الإضافات في DeepSeek Harness حواجز الإنفاق في DeepSeek Harness هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # حلقات الأهداف وحلقة Ralph في DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/ar/research/deepseek-harness-goals-ralph-loop حلقات الأهداف وحلقة Ralph في DeepSeek Harness آخر تحديث August 16, 2026 · نُشر أول مرة August 16, 2026 إجابة سريعة: تعد إدارة المهام المفتوحة (Open-ended Tasks) أكبر تحدٍ مالي وتقني في بناء وكلاء الذكاء الاصطناعي. يقدم DeepSeek Harness نموذجاً دقيقاً لتأطير العمل غير المقيد عبر مفاهيم: الخطوة، والمنعطف، والجولة،... تعد إدارة المهام المفتوحة (Open-ended Tasks) أكبر تحدٍ مالي وتقني في بناء وكلاء الذكاء الاصطناعي. يقدم DeepSeek Harness نموذجاً دقيقاً لتأطير العمل غير المقيد عبر مفاهيم: الخطوة، والمنعطف، والجولة، والأهداف طويلة المدى، وحلقة Ralph لإعادة المحاولة المنضبطة. الخطوة، والمنعطف، والجولة الخطوة (Step): استدعاء نموذج واحد وما ينتج عنه من استدعاءات للأدوات. المنعطف (Turn): تبادل كامل لرسالة المستخدم والرد عليها حتى يتوقف النموذج أو تتدخل سياسة الحوكمة. الجولة (Round): تكرار خارجي للسياسة عبر عدة منعطفات، مثل محاولة جديدة لتحقيق هدف مفتوح بعد تقييم مرحلي. الأهداف بوصفها موجّهات دائمة (Persistent Directives) يتم تعريف الهدف كشرط إنجاز محدد، يظل حياً عبر جولات متعددة حتى يثبت الوكيل تحققه أو يقر بالفشل بعد استنفاد الميزانية. حلقة Ralph: إعادة التشغيل الواعية بدلاً من ترك الوكيل يعلق في سياق متضخم مليء بالأخطاء السابقة، تتيح حلقة Ralph إعادة تعيين سياق المحادثة مع الاحتفاظ بالهدف والملخص المرحلي فقط، مما يخفض تكلفة قراءة السياق بنسبة تفوق 70% في المهام الطويلة. ضوابط الحوكمة للمهام المفتوحة لمنع انفلات التكاليف في الجولات المتكررة، يفرض النظام سقفاً لعدد الجولات، وميزانية رموز قصوى للهدف، وقواطع دوائر تقطع العمل عند تكرار نفس الأخطاء. مقالات ذات صلة ما هو DeepSeek Harness؟ حواجز الإنفاق في DeepSeek Harness ميزانيات الوكلاء الثلاث هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # حواجز الميزانية والإنفاق في DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/ar/research/deepseek-harness-guardrails حواجز الميزانية والإنفاق في DeepSeek Harness آخر تحديث August 16, 2026 · نُشر أول مرة August 16, 2026 إجابة سريعة: يمثل التحكم المالي في الوكلاء المستقلين خط الدفاع الأول ضد الفواتير غير المتوقعة. في DeepSeek Harness، لا تعتمد الحماية على افتراضات النموذج الذاتية، بل على نقاط اعتراض صريحة في دورة حياة التنفيذ عبر... يمثل التحكم المالي في الوكلاء المستقلين خط الدفاع الأول ضد الفواتير غير المتوقعة. في DeepSeek Harness، لا تعتمد الحماية على افتراضات النموذج الذاتية، بل على نقاط اعتراض صريحة في دورة حياة التنفيذ عبر خطافين رئيسيين في معمارية شلال المعالجة (Waterfall Hooks). نقطة الاعتراض الأولى: agent/pre-step يتم تشغيل هذا الخطاف قبل إرسال الطلب إلى نموذج اللغة الكبير. هذا هو الموقع المثالي لفرض القيود المالية: التحقق من الرصيد المتبقي لميزانية المهمة وحساب المستخدم. حساب عدد الرموز التراكمي للجلسة وتطبيق سقف الاستهلاك الأقصى. رفض أو تعليق التنفيذ وطلب الموافقة البشرية قبل استدعاء نماذج التفكير الاستدلالي الباهظة. نقطة الاعتراض الثانية: tools/pre-execute يتم إطلاق هذا الخطاف بعد أن يقرر النموذج استدعاء أداة، ولكن قبل تنفيذ شفرة الأداة فعلياً: التحقق من صلاحيات الأداة وملاءمة المعلمات المدخلة. فرض حدود على استدعاء أدوات الخوادم المدفوعة (مثل البحث في الويب وقواعد البيانات). منع العمليات المدمرة أو التي تتجاوز مساحة العمل المحددة للمشروع. تسجيل البيانات كأصل محاسبي تسجل نقاط الاعتراض هذه كافة القرارات والرفض والمبالغ المقدرة في سجل الجلسة، مما يحول بيانات التنفيذ إلى سجل تدقيق مالي موثوق ومحكم. مقالات ذات صلة ميزانيات الوكلاء الثلاث ما هو DeepSeek Harness؟ حواجز إنفاق الوكلاء المستقلين هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # كل شيء إضافة في DeepSeek Harness ومعمارية Cordis · FinOps LLM URL: https://finopsllm.com/ar/research/deepseek-harness-plugin-architecture كل شيء إضافة في DeepSeek Harness ومعمارية Cordis آخر تحديث August 16, 2026 · نُشر أول مرة August 16, 2026 إجابة سريعة: السمة التصميمية الأبرز في DeepSeek Harness هي بناؤه بالكامل على بيئة تشغيل الإضافات Cordis. لا توجد نواة برمجية ذات امتيازات خاصة؛ فمحول النموذج إضافة، وسجل الأدوات إضافة، وسجل الجلسات إضافة، وحتى... السمة التصميمية الأبرز في DeepSeek Harness هي بناؤه بالكامل على بيئة تشغيل الإضافات Cordis . لا توجد نواة برمجية ذات امتيازات خاصة؛ فمحول النموذج إضافة، وسجل الأدوات إضافة، وسجل الجلسات إضافة، وحتى حلقة الوكيل نفسها عبارة عن إضافة قابلة للاستبدال. لماذا تعد بيئة Cordis مختلفة عن أطر العمل التقليدية؟ في معظم الأنظمة، يمنحك إطار العمل نواة ثابتة مع خطافات (Hooks) للمراقبة والتزيين، ولكن استبدال المكونات الجوهرية يتطلب إنشاء تفريع كامل (Fork) من الشفرة. في Cordis، يتم قلب المعادلة: المكونات التي ترغب المؤسسة في استبدالها هي وحدات التركيب الأساسية للمنظومة. أربعة مفاصل قدرة ذات أثر مالي حاسم مفصل النموذج (LLM Seam): استبدال مزود النماذج أو استخدام طبقة محاكاة تعيد تشغيل جلسات سابقة دون دفع تكاليف استدلال إضافية. مفصل الأدوات (Tool Registry Seam): تخصيص كتالوج الأدوات وصلاحيات الوصول لكل وكيل بدقة لمنع الهدر في الرموز. مفصل الجلسات (Session Store Seam): ربط السجل بأنظمة التتبع المالي وقواعد بيانات المحاسبة السحابية. مفصل الحوكمة (Policy Seam): فرض قواعد التحقق والميزانية دون المساس بالمنطق التشغيلي للوكيل. مقالات ذات صلة ما هو DeepSeek Harness؟ تثبيت وتشغيل DeepSeek Harness مقارنة أسعار مزودي النماذج هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # سجل الجلسة كمصدر وحيد للحقيقة وسجل التكاليف · FinOps LLM URL: https://finopsllm.com/ar/research/deepseek-harness-session-log سجل الجلسة كمصدر وحيد للحقيقة وسجل التكاليف آخر تحديث August 16, 2026 · نُشر أول مرة August 16, 2026 إجابة سريعة: في بيئات الإنتاج، لا يمكن إدارة ما لا يمكن قياسه وتدقيقه بدقة. يعتمد DeepSeek Harness مبدأً معمارياً صارماً: الجلسة عبارة عن سجل أحداث للإلحاق فقط (Append-Only Event Log). لا يتم تعديل الأحداث الماضية... في بيئات الإنتاج، لا يمكن إدارة ما لا يمكن قياسه وتدقيقه بدقة. يعتمد DeepSeek Harness مبدأً معمارياً صارماً: الجلسة عبارة عن سجل أحداث للإلحاق فقط (Append-Only Event Log). لا يتم تعديل الأحداث الماضية إطلاقاً، وكل تفاعل يمثل حدثاً مطبوعاً وموثقاً زمنياً. استهلاك الرموز يسافر مع المخرجات الميزة الأهم لفرق FinOps هي أن بيانات استهلاك الرموز (رموز الإدخال، ورموز الإخراج، ورموز التخزين المؤقت، وزمن الاستجابة) ترتبط مباشرة بالحدث البرمجي الذي ولّدها في السجل. لا توجد تخمينات أو أرقام متوسطة؛ يمكنك تتبع التكلفة الدقيقة لكل سطر كود أو قرار اتخذه الوكيل. تاريخ مشتق دون تكرار للبيانات بدلاً من تكرار حفظ تاريخ المحادثة في كل خطوة، يتم اشتقاق السياق ديناميكياً من سجل الأحداث الأصلي، مما يضمن توافق الرؤية بين النموذج، وأدوات التصحيح، ونظام المحاسبة المالية. بناء أنظمة المحاسبة والفوترة على السجل يتيح هذا التصميم استخراج تقارير تكلفة فورية، ومطابقة فواتير المزودين، واكتشاف محاولات إعادة التنفيذ المهدرة عبر قراءة تدفق الأحداث مباشرة دون الحاجة لتثبيت برمجيات مراقبة دخيلة. مقالات ذات صلة إسناد تكاليف نماذج الذكاء الاصطناعي ما هو DeepSeek Harness؟ معيار FOCUS 1.5 لتتبع الرموز هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # الوكلاء الفرعيون والتفويض في DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/ar/research/deepseek-harness-subagents الوكلاء الفرعيون والتفويض في DeepSeek Harness آخر تحديث August 16, 2026 · نُشر أول مرة August 16, 2026 إجابة سريعة: يمثل تفويض المهام لوكلاء فرعيين متخصصين ركيزة أساسية لإنجاز الأعمال المعقدة. في DeepSeek Harness، لا يتم بناء الوكلاء الفرعيين ككتل صلبة، بل كخدمة متكاملة تدعم وسائط نقل متعددة، مع فرض قيود صارمة على... يمثل تفويض المهام لوكلاء فرعيين متخصصين ركيزة أساسية لإنجاز الأعمال المعقدة. في DeepSeek Harness، لا يتم بناء الوكلاء الفرعيين ككتل صلبة، بل كخدمة متكاملة تدعم وسائط نقل متعددة، مع فرض قيود صارمة على عمق التفويض لمنع الانفجار المالي. وضعان للتفويض: ملفان ماليان متباينان التفويض المتزامن (In-process Delegation): تشغيل الوكيل الفرعي داخل نفس العملية البرمجية لمشاركة الذاكرة والسياق السريع للمهام القصيرة. التفويض المعزول (Isolated/External Delegation): تشغيل الوكيل في عملية منفصلة أو حاوية مستقلة، مما يوفر أماناً وعزلاً تاماً للمهام الخطرة مع زيادة في زمن الاستجابة. عمق التفويض مقيد ولا يمكن تجاوزه أخطر أنماط الهدر المالي في أسراب الوكلاء هو التفويض التكراري غير المقيد (Unbounded Recursion). يفرض Harness حداً أقصى صريحاً لعمق الشجرة؛ أي محاولة من وكيل فرعي لتوليد وكيل آخر يتجاوز السقف المحدد تؤدي إلى رفض فوري صريح (Fail Loudly). مؤشرات القياس المالي للوكلاء الفرعيين يجب تتبع: تكلفة كل وكيل فرعي بالنسبة للمهمة الإجمالية، ومعدل نجاح الوكلاء الفرعيين دون إعادة محاولة، والوقت المستغرق في نقل الرسائل بين الوكلاء. مقالات ذات صلة كبح تفرع الوكلاء واستنزاف الرموز ميزانيات الوكلاء الثلاث ما هو DeepSeek Harness؟ هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # نطاقات الأدوات وتقييد الصلاحيات في Harness · FinOps LLM URL: https://finopsllm.com/ar/research/deepseek-harness-tool-scopes نطاقات الأدوات وتقييد الصلاحيات في Harness آخر تحديث August 16, 2026 · نُشر أول مرة August 16, 2026 إجابة سريعة: في بيئات الوكلاء، كل أداة تضاف إلى الكتالوج ليست مجرد وظيفة برمجية، بل هي "مركز تكلفة دائم". فحتى عندما لا تُستخدم الأداة، فإن مخططها التعريفي (Schema) يُحقن في سياق كل مطالبة. يحل DeepSeek Harness... في بيئات الوكلاء، كل أداة تضاف إلى الكتالوج ليست مجرد وظيفة برمجية، بل هي "مركز تكلفة دائم". فحتى عندما لا تُستخدم الأداة، فإن مخططها التعريفي (Schema) يُحقن في سياق كل مطالبة. يحل DeepSeek Harness هذه المعضلة عبر مفهوم نطاقات الأدوات (Tool Scopes) والتقييد الصارم للصلاحيات. لماذا يعد كتالوج الأدوات عبئاً مالياً مستمراً؟ إذا كان الكتالوج العام يضم 50 أداة، فإن إرسال مواصفاتها يستهلك آلاف رموز الإدخال في كل جولة مفردة. والأخطر من ذلك أن اتساع خيارات الأدوات يزيد من احتمالية تشتت النموذج وارتكاب أخطاء في الاستدعاء تتطلب إعادة محاولات مكلفة. آليات النطاقات والحجب (Scoping & Shadowing) يتيح Harness تقييد الأدوات المتاحة لكل وكيل بحسب وظيفته الدقيقة: نطاق الوكيل (Agent Scope): تخصيص مجموعة أدوات فرعية ومحددة للوكيل المختص (مثل أدوات القراءة فقط للوكيل الباحث). حجب الأدوات (Shadowing): إخفاء الأدوات الحساسة أو باهظة التكلفة واستبدالها بنسخ أخف وأكثر أماناً داخل السياق الفرعي. التحكم في التنفيذ المحروس (Guarded Execution): التحقق من مطابقة المعلمات قبل تشغيل الأداة في بيئة العمل. أثر تضييق مساحة الأدوات على التكلفة والأمان يؤدي تضييق نطاق الأدوات إلى خفض فوري في تكاليف رموز الإدخال بنسبة تصل إلى 60%، مع رفع دقة استدعاء النماذج للأدوات وتقليل معدلات الفشل والهدر المالي. مقالات ذات صلة التحكم في عبء رموز أدوات MCP أدوات الخوادم تُفوتر خارج عداد الرموز ما هو DeepSeek Harness؟ هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # ضوابط التكلفة داخل مسار تقييم نماذج الذكاء الاصطناعي · FinOps LLM URL: https://finopsllm.com/ar/research/evals-cost-control ضوابط التكلفة داخل مسار تقييم نماذج الذكاء الاصطناعي آخر تحديث August 27, 2026 · نُشر أول مرة August 27, 2026 إجابة سريعة: تحتاج عمليات تقييم النماذج اللغوية إلى سياسة تكلفة خاصة بها. فعملية تكامل مستمر (CI) تشغل 10,000 مطالبة عند كل تعديل برمجي قد تكلف أكثر من الميزة التي تختبرها. تحكم في إنفاق التقييم عبر وضع ميزانية... تحتاج عمليات تقييم النماذج اللغوية إلى سياسة تكلفة خاصة بها. فعملية تكامل مستمر (CI) تشغل 10,000 مطالبة عند كل تعديل برمجي قد تكلف أكثر من الميزة التي تختبرها. تحكم في إنفاق التقييم عبر وضع ميزانية لكل تشغيلة، وأخذ عينات تمثيلية، وتخزين المدخلات الثابتة مؤقتاً، وتطبيق بوابة جودة توقف الاختبار مبكراً عند وضوح الفشل. وضع ميزانية مسبقة للتشغيلة حدد سقفاً لعدد المطالبات والنماذج المرشحة والمحاولات والمبالغ المالية قبل بدء التقييم. وافصل اختبارات الفحص السريع (smoke tests) لطلبات الدمج عن اختبارات التراجع الليلية وشهادات الإصدار النهائي. أخذ عينات للحفاظ على دقة الإشارة قسم مجموعة الاختبار حسب مسار العمل وأثر العميل ودرجة الصعوبة وأنماط الفشل المعروفة؛ فعشرة آلاف مطالبة مكررة تعطي معلومات أقل بكثير من عينة محكمة تركز على حالات الحافة الحرجة. التخزين المؤقت للبيانات الثابتة خزن السياق المسترجع والبيانات الثابتة والأحكام المرجعية التي لا تعتمد على توليد جديد. وسجل عمليات قراءة وكتابة الكاش كتكلفة تقييم فعلية. مقالات ذات صلة التكلفة لكل مهمة ناجحة مراقبة تكاليف النماذج اللغوية هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # أول إقفال شهري لمنتج يعتمد بكثافة على الذكاء الاصطناعي · FinOps LLM URL: https://finopsllm.com/ar/research/first-ai-month-end-close أول إقفال شهري لمنتج يعتمد على الذكاء الاصطناعي آخر تحديث August 27, 2026 · نُشر أول مرة August 27, 2026 إجابة سريعة: لا ينبغي أن يبدأ أول إقفال شهري للذكاء الاصطناعي بلقطة شاشة للوحة المعلومات. بل يجب أن يبدأ بفواتير المزودين الأولية وفترة تقارير مقفلة. اقفل رقم السيولة النقدية أولاً، وفسر بيانات الاستهلاك ثانياً،... لا ينبغي أن يبدأ أول إقفال شهري للذكاء الاصطناعي بلقطة شاشة للوحة المعلومات. بل يجب أن يبدأ بفواتير المزودين الأولية وفترة تقارير مقفلة. اقفل رقم السيولة النقدية أولاً، وفسر بيانات الاستهلاك ثانياً، ولا توزع التكاليف إلا بعد مطابقة الاثنين بدقة. 1. إقفال الفترة الزمنية حدد المنطقة الزمنية، وتاريخ قطع الفواتير، والعملة، وكيفية معالجة الضرائب والأرصدة والخصومات والتعديلات المتأخرة. جمّد جدول الأسعار المعتمد للفترة واحتفظ بأرقام الفواتير الرسمية. 2. المطابقة مع المزودين اربط سجلات الاستخدام مع صادرات فواتير المزودين حسب الحساب والنموذج ونوع الرمز واليوم. دقق في الفروقات المتبقية بدلاً من إخفائها في حساب غير مخصص. يمكن للإقفال أن يحمل فرقاً غير جوهري موثقاً، لكن لا يمكنه قبول فرق مجهول. 3. توزيع التكاليف المطابقة طبق أبعاداً ثابتة: الخاصية، والفريق، والبيئة، وفئة العملاء، ونوع عبء العمل. افصل تكاليف المنصة المشتركة عن استهلاك المنتجات. واجعل إضافة وسوم التتبع أولوية هندسية واضحة. 4. تفسير أسباب التباين فسر الفرق بين الفترات عبر السعر، والحجم، ومزيج النماذج، والكفاءة. اربط كل حركة كبيرة بنشر برمجي، أو تغير في حركة المرور، أو تعديل في سلوك الوكلاء. واعرض تكلفة المهمة الناجحة عند p50 وp95. مقالات ذات صلة توزيع تكاليف الذكاء الاصطناعي مراقبة تكاليف النماذج اللغوية هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # معيار FOCUS 1.5 لتتبع رموز الذكاء الاصطناعي · FinOps LLM URL: https://finopsllm.com/ar/research/focus-1-5-ai-token-tracking معيار FOCUS 1.5 لتتبع رموز الذكاء الاصطناعي آخر تحديث September 19, 2026 · نُشر أول مرة August 15, 2026 إجابة سريعة: أعلنت مؤسسة FinOps أن معيار FOCUS 1.5 (مواصفة التكلفة والاستخدام السحابي المفتوحة) يضم لأول مرة دعماً أصيلاً وموحداً لتتبع استهلاك رموز الذكاء الاصطناعي التوليدي وقوائم أسعار المزودين، مما يمثل نقلة... أعلنت مؤسسة FinOps أن معيار FOCUS 1.5 (مواصفة التكلفة والاستخدام السحابي المفتوحة) يضم لأول مرة دعماً أصيلاً وموحداً لتتبع استهلاك رموز الذكاء الاصطناعي التوليدي وقوائم أسعار المزودين، مما يمثل نقلة نوعية في الشفافية المالية السحابية. 1. ما الذي يوفره معيار FOCUS 1.5 سابقاً، كان كل مزود سحابي (مثل AWS Bedrock و Azure OpenAI و Google Cloud Vertex AI) يصدر فواتير الاستدلال بتنسيقات متباينة ومسميات غير موحدة، مما يصعب مقارنتها مباشرة. يوحد FOCUS 1.5 هذه البيانات عبر: معرف النموذج الموحد (Model Identifier): تسمية قياسية عبر جميع المزودين للنموذج المستدعى. مقاييس الرموز المفصلة (Token Metrics): أعمدة مستقلة لرموز الإدخال والإخراج ورموز القراءة من التخزين المؤقت بدلاً من الأرقام الإجمالية المبهمة. مجموعة بيانات قائمة الأسعار (Price Sheet Dataset): فصل واضح بين الأسعار المعلنة والاستهلاك الفعلي لحساب نسب الخصم والالتزامات بدقة. 2. ما لا يقدمه FOCUS 1.5 يوحد المعيار بيانات فواتير المزودين الخارجيين، لكنه لا يحل مشكلة إسناد التكاليف داخلياً بين الفرق والميزات والعملاء. لا يعرف المزود أي ميزة داخل تطبيقك استدعت النموذج، لذلك يظل وضع الوسوم (Tagging) وتمرير السياق عبر بوابة الذكاء الاصطناعي الداخلية مسؤولية المؤسسة. 3. الاستعداد لتطبيق المعيار يمكن لفرق FinOps الاستعداد من الآن عبر فصل تسجيل الرموز بحسب نوعها، والاحتفاظ بمعرف النموذج لكل استدعاء، وحفظ نسخ من جداول أسعار المزودين وقت التنفيذ لضمان مطابقة سلسة وفورية مع صدور الفواتير المتوافقة مع FOCUS 1.5. مقالات ذات صلة أسس إسناد تكاليف نماذج الذكاء الاصطناعي مطابقة فواتير نفقات الذكاء الاصطناعي هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # تكلفة البرمجة بالوكلاء: Claude Max ضد Qwen · FinOps LLM URL: https://finopsllm.com/ar/research/heavy-agentic-coding-cost-claude-vs-qwen تكلفة البرمجة بالوكلاء: Claude Max ضد Qwen آخر تحديث September 19, 2026 · نُشر أول مرة August 6, 2026 إجابة سريعة: عندما تنتقل هندسة البرمجة بمساعدة الذكاء الاصطناعي من الإكمال التلقائي البسيط إلى أسراب الوكلاء المتعددين (Multi-Agent Swarms) — حيث يطلق الوكيل المنسق ما بين 4 إلى 8 وكلاء فرعيين متوازيين لإعادة... عندما تنتقل هندسة البرمجة بمساعدة الذكاء الاصطناعي من الإكمال التلقائي البسيط إلى أسراب الوكلاء المتعددين (Multi-Agent Swarms) — حيث يطلق الوكيل المنسق ما بين 4 إلى 8 وكلاء فرعيين متوازيين لإعادة الهيكلة والاختبار وتدقيق الأمان — يتضاعف استهلاك الرموز بشكل كبير. الاعتماد على المقارنة السطحية لأسعار الرموز المعلنة يقود لقرارات شراء غير اقتصادية. 1. نموذجان مختلفان تماماً في الفوترة خطة Alibaba Token Pro (70 دولاراً/شهر): تقدم رصيداً شفافاً بحصص محددة (12,000 رصيد كل 5 ساعات و40,000 رصيد كل 7 أيام) لنموذج Qwen 3.8-Max، مع خصم يصل إلى 80% (مضاعف 0.2×) خارج ساعات الذروة. خطة Claude Max 20x (200 دولار/شهر): تتيح قدرة استنتاج ديناميكية لنموذج Opus 5 دون حصص رموز معلنة مسبقاً، مع دقة فائقة في فهم قواعد الكود المعقدة وتقليل أخطاء التنفيذ. 2. معادلة نقطة التعادل وتكلفة وقت المطورين بالمقارنة المالية المباشرة (70$ مقابل 200$)، يحتاج Qwen 3.8-Max لتحقيق 35% فقط من إنتاجية المهام المقبولة لنموذج Opus 5 ليكون أكثر توفيراً لكل ميزة برمجية مكتملة. وفي المقابل، عند احتساب تكلفة المطور بمعدل 50 دولاراً في الساعة، يكفي أن يوفر Opus 5 2.6 ساعة عمل شهرياً من المراجعة اليدوية وتصحيح الأخطاء لتعويض فارق الاشتراك البالغ 130 دولاراً بالكامل. مقالات ذات صلة لماذا لا يمكن مقارنة أسعار المزودين مباشرة هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # دليل تشغيلي لاحتواء قفزات تكلفة النماذج · FinOps LLM URL: https://finopsllm.com/ar/research/llm-cost-spike-runbook دليل تشغيلي لاحتواء قفزات تكلفة النماذج آخر تحديث August 27, 2026 · نُشر أول مرة August 27, 2026 إجابة سريعة: عندما تطلق أنظمة المراقبة تنبيهاً بقفزة حادة وغير متوقعة في تكاليف استهلاك نماذج اللغة الكبيرة في بيئة الإنتاج، يحتاج فريق الهندسة والعمليات إلى دليل حوادث صارم لاحتواء النزيف المالي فوراً دون التسبب... عندما تطلق أنظمة المراقبة تنبيهاً بقفزة حادة وغير متوقعة في تكاليف استهلاك نماذج اللغة الكبيرة في بيئة الإنتاج، يحتاج فريق الهندسة والعمليات إلى دليل حوادث صارم لاحتواء النزيف المالي فوراً دون التسبب في تعطل الخدمات الأساسية للعملاء. أول 15 دقيقة: التأكيد والحفظ السريع تحقق من صحة التنبيه فوراً عبر مطابقة مقاييس البوابة الداخلية (AI Gateway) مع لوحة تحكم المزود. استبعد التحديثات المحاسبية المجمعة. التقط لقطة لسجلات حركة المرور لتحديد مفاتيح API، والنماذج، والمسارات التي تشهد النشاط غير الطبيعي. الدقائق الثلاثون التالية: الاحتواء المتزن لا تلجأ فوراً لإيقاف الخدمات الحيوية، بل طبق خطوات الاحتواء التدريجية: تخفيض سقف الاستهلاك (Rate Limits) للمفاتيح أو الحسابات المشتبه بها. إيقاف المهام الخلفية، والتوليد المجمّع، وتجارب التقييم غير المرتبطة مباشرة بالعملاء. تفعيل التراجع التلقائي المؤقت إلى نماذج أصغر حجماً وأقل كلفة لإبقاء الخدمة تعمل. تحديد السبب الجذري وإغلاق الحادثة حلل سجلات الاستدعاء: هل كانت الزيادة بسبب حلقة إعادة محاولة مفرغة (Infinite Loop)، أم سياق متضخم بشكل شاذ، أم هجوم من مستخدم يسيء استغلال النظام؟ وثق الحادثة، وحدد القيمة المالية المستنزفة، وافرض حواجز برمجية دائمة تمنع تكرار السيناريو. مقالات ذات صلة مراقبة تكاليف نماذج اللغة الكبيرة حواجز إنفاق الوكلاء المستقلين توزيع وتخصيص تكاليف الذكاء الاصطناعي هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # التحكم في عبء رموز تعريفات أدوات MCP · FinOps LLM URL: https://finopsllm.com/ar/research/mcp-tool-definition-overhead التحكم في عبء رموز تعريفات أدوات MCP آخر تحديث September 19, 2026 · نُشر أول مرة September 19, 2026 إجابة سريعة: يمنح بروتوكول سياق النموذج (MCP) وكلاء الذكاء الاصطناعي قدرة فائقة على التفاعل مع الأنظمة المؤسسية. ولكن ثمن هذا التكامل يأتي في صورة "ضريبة مخططات MCP": في كل استدعاء للنموذج، تُرسل مواصفات ومخططات... يمنح بروتوكول سياق النموذج (MCP) وكلاء الذكاء الاصطناعي قدرة فائقة على التفاعل مع الأنظمة المؤسسية. ولكن ثمن هذا التكامل يأتي في صورة "ضريبة مخططات MCP": في كل استدعاء للنموذج، تُرسل مواصفات ومخططات جميع الأدوات المتاحة (JSON Schemas) كجزء من السياق، مما يستهلك آلاف الرموز في كل رسالة مفردة. تشريح العبء المالي لمخططات الأدوات قد تحتوي مواصفة أداة واحدة متصلة بقاعدة بيانات أو نظام إدارة عملاء على حقول ومعايير وأوصاف تستهلك 500 رمز. عند ربط 15 أداة بخادم الوكيل، يُحقن 7,500 رمز إدخال في كل جولة محادثة. وفي محادثة متعددة الخطوات تتألف من 10 جولات، يُدفع ثمن 75,000 رمز إدخال فقط لقراءة المخططات المتكررة دون احتساب نصوص المستخدم والردود. ثلاثة حلول معمارية للقضاء على الهدر يمكن للمطورين تقليص هذا العبء المالي عبر: التخزين المؤقت الإلزامي للمطالبات (Prompt Caching): تثبيت موضع تعريفات الأدوات في بداية السياق، مما يتيح الاستفادة من تخفيضات التخزين المؤقت للمزودين التي تصل إلى 90% من سعر الرموز. تقليص وتجريد مخططات JSON: اختصار الأوصاف المطولة وإزالة الحقول غير الأساسية والاكتفاء بالمعلمات الضرورية. التوجيه الهرمي للأدوات (Hierarchical Tool Indexing): إرسال ملخص مختصر للأدوات واستدعاء المخطط التفصيلي فقط عندما يطلب النموذج استخدام أداة محددة. مقالات ذات صلة أدوات الخوادم والفواتير المنفصلة اقتصاديات التخزين المؤقت للمطالبات حواجز إنفاق الوكلاء المستقلين هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # تخفيضات أسعار النماذج لا تخفض الفاتورة تلقائياً · FinOps LLM URL: https://finopsllm.com/ar/research/model-price-cuts-routing-budget تخفيضات أسعار النماذج لا تخفض الفاتورة تلقائياً آخر تحديث September 10, 2026 · نُشر أول مرة September 10, 2026 إجابة سريعة: تتسابق شركات الذكاء الاصطناعي على خفض أسعار الرموز بنسب تصل إلى 60% و 80%. ومع ذلك، تفاجأ العديد من المؤسسات بأن فواتيرها الشهرية لا تتغير أو حتى تسجل ارتفاعاً ملحوظاً. الحقيقة أن انخفاض الأسعار في... تتسابق شركات الذكاء الاصطناعي على خفض أسعار الرموز بنسب تصل إلى 60% و 80%. ومع ذلك، تفاجأ العديد من المؤسسات بأن فواتيرها الشهرية لا تتغير أو حتى تسجل ارتفاعاً ملحوظاً. الحقيقة أن انخفاض الأسعار في السوق لا يترجم تلقائياً إلى وفورات مالية إلا إذا أعادت الفرق الهندسية هيكلة مسارات التوجيه وقواعد التقييم. لماذا لا تنعكس التخفيضات تلقائياً؟ تظل معظم التطبيقات مربوطة بأسماء ونقاط نهاية ثابتة لنماذج قديمة أعلى سعراً. ما لم يتم تعديل الكود أو تحديث محرك التوجيه (Router)، يستمر الاستهلاك وفق الأسعار السابقة. بالإضافة إلى ذلك، يشجع انخفاض الأسعار المطورين على زيادة أطوال السياق وإضافة مزيد من الوكلاء والأدوات، مما يلتهم الوفر السعري بالكامل. إعادة المعايرة بعد كل إعلان سعري فور إعلان المزودين عن تخفيضات جديدة، ينبغي لفرق FinOps اتخاذ الخطوات التالية: تحديث جداول الأسعار في أنظمة التتبع والبوابات الداخلية فوراً لمطابقة الفواتير بدقة. اختبار النماذج الاقتصادية الأحدث على مجموعات بيانات التقييم للتأكد من استيفائها شروط الجودة والأمان. تحويل أعباء العمل الروتينية والمهام غير الحساسة لزمن الاستجابة إلى المستويات السعرية الأرخص. مقالات ذات صلة التوجيه الذكي للنماذج أسعار المزودين غير قابلة للمقارنة المباشرة التكلفة الحقيقية للتبديل بين المزودين هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # أدوات مراقبة الذكاء قد تتحول لفاتورة ثانية · FinOps LLM URL: https://finopsllm.com/ar/research/observability-second-llm-bill أدوات مراقبة الذكاء قد تتحول لفاتورة ثانية آخر تحديث September 9, 2026 · نُشر أول مرة September 9, 2026 إجابة سريعة: لضمان جودة وأمان تطبيقات الذكاء الاصطناعي، تستثمر المؤسسات بكثافة في أدوات المراقبة وقابلية التتبع (Observability). ولكن مع استخدام تقنيات مثل "النموذج كحَكَم" (LLM-as-a-Judge)، والتوليد التلقائي... لضمان جودة وأمان تطبيقات الذكاء الاصطناعي، تستثمر المؤسسات بكثافة في أدوات المراقبة وقابلية التتبع (Observability). ولكن مع استخدام تقنيات مثل "النموذج كحَكَم" (LLM-as-a-Judge)، والتوليد التلقائي للتضمينات، وتلخيص جلسات التتبع، تجد الفرق نفسها تدفع فاتورة ثانية ضخمة للنماذج مخصصة فقط لمراقبة النموذج الأول! التكاليف المخفية في خطوط أنابيب المراقبة إذا كانت المنظومة ترسل كل استجابة من بيئة الإنتاج إلى نموذج استدلال متقدم لتقييم الدقة والامتثال ونبرة الخطاب، فإنك تدفع فعلياً ثمن استدعاءين لكل طلب عميل. وفي بعض الحالات، يكون نموذج التحكيم أكبر حجماً وأغلى سعراً من النموذج الذي يخدم العميل الأصلي، مما يجعل تكلفة المراقبة أعلى من تكلفة الخدمة نفسها. حوكمة وتوزيع إنفاق المراقبة للسيطرة على هذا الإنفاق دون التضحية بالرؤية الشاملة للجودة: أخذ عينات إحصائية (Statistical Sampling): تقييم 5% إلى 10% من المحادثات عبر النماذج الحَكَمة بدلاً من فحص 100% من حركة المرور. استخدام نماذج تقييم خفيفة ومتخصصة: الاعتماد على نماذج أصغر حجماً ومدربة خصيصاً للتصنيف المعياري بدلاً من استدعاء النماذج العملاقة. إسناد التكلفة للأصل (Attribution to Workload): تحميل فواتير التقييم على الميزة التي تخضع للمراقبة ليظهر أثرها في هوامش المنتج بدقة. مقالات ذات صلة قابلية المراقبة لأنظمة الذكاء الاصطناعي التحكم في تكاليف تقييم النماذج مراقبة تكاليف نماذج اللغة الكبيرة هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # مستويات الجهد في Opus 5.5 هي السعر الحقيقي · FinOps LLM URL: https://finopsllm.com/ar/research/opus-5-5-effort-level-cost مستويات الجهد في Opus 5.5 هي السعر الحقيقي آخر تحديث September 22, 2026 · نُشر أول مرة September 22, 2026 يتم سرد Claude Opus 5.5 بسعر $4 لكل مليون رمز إدخال و$20 لكل مليون رمز إخراج. هذا أقل بـ 20% من Opus 5. قائمة الأسعار هي النصف الأصغر من قصة التكلفة. النصف الأكبر هو إعداد effort ، الذي يحدد عدد الرموز التي ينفقها النموذج في التفكير قبل الإجابة. نموذج واحد، خمسة أسعار يعرض Opus 5.5 الجهد من low إلى medium و high و xhigh و max . كل مستوى هو نفس النموذج بنفس معدل الرمز، لكنه ينتج عدد رموز مختلف جداً. وجدت معايير مستقلة أبلغت عنها The Decoder أن أربعة من المستويات الخمسة تقع على حدود كفاءة التكلفة والأداء. كما وجدت أنه عند جهد أقصى استخدم Opus 5.5 حوالي 119,000 رمز إخراج لكل مهمة، أكثر بكثير من النماذج المنافسة في أعلى إعداداتها. بسعر 20 دولارًا لكل مليون، تكلّف 119,200 رمز إخراج 2.38 دولار لكل مهمة قبل احتساب أي إدخال. عند medium قاست Artificial Analysis نحو 25,700 رمز إخراج، أي 0.51 دولار. مع احتساب الإدخال، يكلّف max نحو 5.98 دولار لكل مهمة وmedium نحو 1.34 دولار: النموذج نفسه أغلى بنحو 4.5 أضعاف لكل مهمة بسبب معامل واحد في الطلب. مقيس على مؤشر Artificial Analysis Intelligence Index v4.3.2 (عشرة تقييمات)، بتاريخ 22 سبتمبر 2026. كل الصفوف تستخدم مجموعة الاختبارات نفسها، لذا تُقارن مباشرة. النموذج ومستوى الجهد Intelligence Index التكلفة لكل مهمة رموز الإخراج لكل مهمة على حدّ التكلفة والأداء Opus 5.5 · low 42.3 $0.55 10,200 لا Opus 5.5 · medium 51.2 $1.34 25,700 نعم Opus 5.5 · high 53.6 $1.82 35,600 نعم Opus 5.5 · xhigh 56.0 $3.46 65,700 نعم Opus 5.5 · max 57.6 $5.98 119,200 نعم Opus 5 · high (مرجع) 48.1 $3.61 46,200 لا المصدر: Artificial Analysis. الوجود على الحدّ يعني أنه لا يوجد إعداد من GPT-6 Sol أو GPT-6 Astra أو Opus 5 أو Opus 5.5 أو Fable 5.1 يحقق نتيجة أعلى بتكلفة أقل. يخرج Opus 5.5 low منه لأن GPT-6 Sol على xhigh يحقق 44.1 مقابل 0.53 دولار. الانتقال من xhigh إلى max يضيف 1.6 نقطة مقابل تكلفة أعلى بنسبة 73%. الوسط هو الإعداد الذي تقيس عليه Anthropic المقارنة الرئيسية لـ Anthropic يتم إجراؤها بجهد افتراضي، وهو متوسط. تقول إن Opus 5.5 بجهد متوسط يتغلب على GPT-6 Astra بجهد أقصى في عمل المعرفة بحوالي خمس تكلفة المهمة. إذاً حالة Anthropic الخاصة بها للنموذج مبنية على المتوسط، والأقصى هو الاستثناء. الفريق الذي يضع الحد الأقصى في كل مكان "ليكون آمناً" يدفع مقابل الرموز التي لم تحتجها معايير الإطلاق. كيفية تعيين الجهد بدون تخمين الافتراضي إلى المتوسط. اجعله قيمة صريحة في الكود، وليس قيمة افتراضية للمكتبة يمكن أن تتغير تحتك. رفع الجهد لكل مسار، وليس عالمياً. قد تبرر عمليات الاستكشاف الصعبة والتخطيط الطويل الأجل وخطوات المراجعة النهائية الجهد العالي أو الأقصى. التصنيف والاستخراج والتعديلات الروتينية نادراً ما تفعل. سجل الجهد مع كل طلب. التكلفة لكل طلب غير قابلة للتفسير بدونها. ارتفاع النفقات مع عدد طلبات مسطح يكون عادة تغييراً في الجهد. قارن مستويات الجهد على نفس المهام المعاد تشغيلها. سجل معدل النجاح ورموز الإخراج لكل مهمة مكتملة على كل مستوى، وتوقف عن رفع الجهد عندما يتوقف النجاح عن التحسن. أغلق الإخراج حيث يسمح المنتج. حد أقصى للرموز يحد من أسوأ حالة. بجهد أقصى فإن هذا الحد هو الشيء الوحيد بين مهمة هاربة وطلب بعدة دولارات. الخفض من $25 إلى $20 لكل مليون رمز إخراج يوفر 20%. نقل عبء العمل من جهد أقصى إلى متوسط يمكن أن يوفر أكثر من ذلك بكثير. تعامل مع الجهد كخط ميزانية، يُملك ويُراجع مثل أي آخر. مقالات ذات صلة نموذج تكلفة Claude Opus 5.5 اقتصاديات الوضع السريع Opus 5.5 دليل تكلفة نموذج المنطق هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # Opus 5.5 fast mode: ضعف السعر للسرعة · FinOps LLM URL: https://finopsllm.com/ar/research/opus-5-5-fast-mode-economics اقتصاديات Opus 5.5 fast mode آخر تحديث September 22, 2026 · نُشر أول مرة September 22, 2026 Claude Opus 5.5 لديها قائمتا سعر. القياسية هي $4 لكل مليون رمز إدخال و $20 لكل مليون رمز إخراج. Fast mode هي $8 و $40، بالضبط الضعف، بسرعة إخراج تصل إلى 2.5×. النموذج متطابق. المال الإضافي يشتري الوقت وحسب، لذا السؤال الوحيد هو وقت من. ما يشتريه القسط خذ خطوة تنتج 5000 رمز إخراج. بالأسعار القياسية، تكلفة الإخراج $0.10. في fast mode تكلف $0.20. إذا استغرقت الخطوة 60 ثانية بسرعة قياسية، فإن تسارع 2.5× يعيدها إلى حوالي 24 ثانية. تدفع $0.10 إضافياً لتوفير 36 ثانية. هذا يصل إلى حوالي $10 لكل ساعة انتظار يتم حذفها. طول الخطوة لا يغير النسبة، لأن التكلفة الإضافية والوقت المحفوظ كلاهما ينمو مع رموز الإخراج. يعتمد على سرعة الوضع القياسي لديك: يفترض هذا المثال حوالي 83 رمز إخراج في الثانية. الإدخال أيضاً يتضاعف، لذا الخطوات الغنية بالبادئة تدفع أكثر قليلاً لكل ثانية محفوظة. عندما يكون رخيصاً مطور ينتظر وكيل ترميز تفاعلي. بـ $10 لكل ساعة انتظار يتم حذفها، يكلف fast mode أقل بكثير من وقت أي شخص يتقاضى راتباً. إجابة موجهة للعميل حيث يؤثر الكمون على التحويل. سعّر التسارع مقابل الهجران وليس مقابل فاتورة الرموز. حادث، حيث لكل دقيقة تكلفة. عندما يكون إهداراً محضاً وكلاء خلفيين وأعمال ليلية وأنابيب دفعية. لا أحد ينتظر، لذا الإنفاق الإضافي لا يشتري شيء. Evals وإعادة التشغيل. هذه هي بالضبط أحمال العمل التي تضاعف عدد الرموز وتعمل وفقاً لجدول زمني. وكلاء فرعيون يعملون بالتوازي. يتم تعيين وقت الساعة من قبل الفرع الأبطأ والمنسق، وليس كل نداء. Opus 5.5 القياسي أسرع بالفعل بحوالي 30% من Opus 5، وفقاً لـ Anthropic. قد يتم حل بعض شكاوى الكمون التي كانت ستبرر fast mode على Opus 5 من خلال الترقية وحدها. قيس السرعة القياسية قبل الدفع لمزيد. ضوابط للتنفيذ اجعل fast mode قراراً واضحاً لكل مسار. يجب أن لا يكون إعداداً عاماً أو علماً قام به مهندس مرة واحدة ونسيه. وسم النفقات حسب الوضع. طلب fast mode بسعر مضاعف يبدو مثل طلب عادي في لوحة تجميع حسب الموديل فقط. تنبيه على حصة fast mode من رموز الإخراج. إذا زادت على المسارات حيث لا ينتظر المستخدم، فقد تم تنشيط شيء لا ينبغي تنشيطه. الميزانية الجهد والسرعة معاً. الحد الأقصى من الجهد يضاعف عدد الرموز، و fast mode يضاعف سعر كل رمز. هذه هي الطريقة الأغلى لتشغيل النموذج. مقالات ذات صلة نموذج تكلفة Claude Opus 5.5 مستويات جهد Opus 5.5 هي السعر الحقيقي حدود المروحة والتزامن للوكلاء الفرعيين هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # إثبات العائد على استثمار الذكاء دون إخفاء الجودة · FinOps LLM URL: https://finopsllm.com/ar/research/prove-ai-roi-measurement إثبات العائد على استثمار الذكاء دون إخفاء الجودة آخر تحديث August 27, 2026 · نُشر أول مرة August 27, 2026 إجابة سريعة: تدعي العديد من لوحات التحكم تحقيق وفورات هائلة بمجرد تخفيض استهلاك الرموز أو التحول إلى نموذج أرخص، ولكن إذا تسبب ذلك في توليد كود معيب، أو إجابات ناقصة للعملاء، أو زيادة معدلات التراجع، فإن التوفير... تدعي العديد من لوحات التحكم تحقيق وفورات هائلة بمجرد تخفيض استهلاك الرموز أو التحول إلى نموذج أرخص، ولكن إذا تسبب ذلك في توليد كود معيب، أو إجابات ناقصة للعملاء، أو زيادة معدلات التراجع، فإن التوفير المزعوم يتحول في الواقع إلى خسارة في قيمة المنتج وثقة المستخدمين. البدء بالسيناريو المضاد ومقام النتيجة لإثبات العائد على الاستثمار الحقيقي (True ROI)، يجب مقارنة التكلفة الحالية بالبديل الفعلي: كم كان سيكلف إنجاز نفس الحجم من المهام عبر البشر أو عبر الأنظمة التقليدية؟ والأهم من ذلك: ربط التكلفة بمقام نفعي حقيقي، مثل: التكلفة لكل معاملة مقبولة، أو التكلفة لكل تذكرة دعم تم حلها بالكامل دون تصعيد. الحفاظ على الجودة داخل معادلة التكلفة لا يمكن فصل الكفاءة المالية عن مقاييس الجودة. يجب أن تتضمن معادلة العائد عتبات جودة دنيا (Quality Floor). أي تخفيض في تكاليف الاستدلال يترافق مع تراجع في دقة المخرجات أو درجات رضا العملاء يجب اعتباره تدهوراً في الكفاءة وليس توفيراً للمال. تقديم نطاق واقعي بدلاً من أرقام خيالية تجنب تقديم رقم موحد ومطلق للعائد؛ بل قدم نطاقاً متحفظاً يأخذ في الحسبان تكاليف البنية التحتية، واشتراكات الأدوات، وساعات المهندسين، ومعدلات الفشل المتوقعة. هذه الشفافية هي وحدها التي تبني مصداقية مبادرات الذكاء الاصطناعي لدى الإدارة التنفيذية. مقالات ذات صلة التكلفة لكل مهمة ناجحة إسناد تكاليف نماذج الذكاء الاصطناعي قابلية المراقبة لأنظمة الذكاء الاصطناعي هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # أسعار مزودي الذكاء الاصطناعي غير قابلة للمقارنة المباشرة · FinOps LLM URL: https://finopsllm.com/ar/research/provider-prices-not-comparable أسعار مزودي الذكاء الاصطناعي غير قابلة للمقارنة آخر تحديث August 27, 2026 · نُشر أول مرة August 27, 2026 إجابة سريعة: مقارنة مزودي الذكاء الاصطناعي بالاعتماد فقط على السعر المعلن لكل مليون رمز تؤدي إلى وفورات وهمية. فالمزودون يختلفون في تسعير أنواع الرموز، وخصومات التخزين المؤقت، وتكاليف الاستدلال، والأقاليم... مقارنة مزودي الذكاء الاصطناعي بالاعتماد فقط على السعر المعلن لكل مليون رمز تؤدي إلى وفورات وهمية. فالمزودون يختلفون في تسعير أنواع الرموز، وخصومات التخزين المؤقت، وتكاليف الاستدلال، والأقاليم الجغرافية، ورسوم استدعاء الأدوات. المقارنة السليمة تقيس التكلفة الفعلية لكل مهمة ناجحة لنفس عبء العمل ومعايير الجودة. توحيد وحدة الفوترة أنشئ جدول تسعير مصنفاً حسب المزود، والنموذج، ونقطة النهاية، والإقليم، ونوع الرمز، وحالة التخزين المؤقت، ونظام الدفعات (Batch). افصل تكاليف رموز الإدخال، والإخراج، وقراءة/كتابة الكاش، ورموز التفكير، واستدعاءات الأدوات. وسجل الالتزامات الدنيا والأرصدة الترويجية خارج السعر الأساسي لضمان الشفافية. معايرة عبء العمل أعد تشغيل عينة ثابتة من المطالبات بالبيانات والسياق وقيود الإخراج واختبارات النجاح نفسها. قس زمن الاستجابة p50 وp95، ومعدل الإكمال، وإعادة المحاولة، والتدخل البشري. فالنموذج الأرخص بنسبة 30% والذي يتطلب ضعف المحاولات يكون في الواقع أكثر تكلفة لكل مهمة منجزة. احتساب التكاليف التشغيلية التبديل بين المزودين له تكلفة هندسية: تعديل بوابات API، وأنظمة المراقبة، ومنطق التوجيه، ونقل البيانات بين السحب. وجه الطلبات ديناميكياً إلى المزود الأقل تكلفة الذي يلبي معايير الجودة وزمن الاستجابة معاً. مقالات ذات صلة الموازنة والمفاضلة بين مزودي النماذج التكلفة لكل مهمة ناجحة هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # التكلفة الفعلية للمهمة: Opus 5.5 مقابل Sol وAstra وFable · FinOps LLM URL: https://finopsllm.com/ar/research/real-cost-per-task-frontier-models التكلفة الفعلية لكل مهمة في النماذج الرائدة آخر تحديث September 22, 2026 · نُشر أول مرة September 22, 2026 تخبرك أسعار القائمة بتكلفة الرمز الواحد، لكنها لا تخبرك بتكلفة المهمة المكتملة، لأن النماذج تستهلك أعدادًا مختلفة جدًا من الرموز لإنجاز العمل نفسه. تضع هذه الصفحة التكلفة المقيسة لكل مهمة ونتيجة الجودة جنبًا إلى جنب لكل من Claude Opus 5.5 وClaude Opus 5 وClaude Fable 5.1 وGPT-6 Astra وGPT-6 Sol عند كل مستوى effort. لكل رقم مصدر، ولا شيء مقدَّر. الجواب المختصر: GPT-6 Sol هو أرخص طريق للوصول إلى أي نتيجة حتى 47.5. وفوق 47.5 يكون Opus 5.5 الأرخص عند كل مستوى. لا يوجد إعداد كفء من حيث التكلفة لـ GPT-6 Astra فوق low ولا لـ Opus 5 ولا لـ Fable 5.1: كل واحد منها يتفوق عليه إعداد ما من Sol أو Opus 5.5 في النتيجة والسعر معًا. المنهجية جميع النتائج والتكاليف مأخوذة من Artificial Analysis Intelligence Index الإصدار v4.3.2، بتاريخ الاطلاع 22 سبتمبر 2026. يضم المؤشر عشرة تقييمات: AA-Briefcase وGDPval-AA وAutomationBench-AA وTerminal-Bench 4.0 وSciCode وHumanity's Last Exam وGDP.pdf وCritPt وAA-Omniscience وAA-LCR. تشغّل Artificial Analysis كل نموذج عند كل مستوى effort عبر واجهة API الخاصة بالمزوّد، وتسجل ما تدفعه بأسعار القائمة. التكلفة لكل مهمة هي هذا الإنفاق لكل مهمة، مقسومًا بين الإدخال والإخراج. تمر جميع الصفوف بالمجموعة نفسها، لذا يمكن مقارنتها مباشرة. هناك حدّان قبل قراءة الأرقام. أولًا، المؤشر مزيج واحد من المهام. مزيج مهامك سيغيّر التكاليف، ولهذا يشرح القسم الأخير كيف تقيس تكاليفك بنفسك. ثانيًا، لا تُقارن النتائج بين إصدارات مختلفة من المؤشر، فلا تخلط هذه الأرقام بأرقام نُشرت سابقًا. القائمة الكاملة: 26 إعدادًا رموز الإخراج لكل مهمة هي الرموز التي يكتبها النموذج، بما فيها الاستدلال. لا تنشر Artificial Analysis التقسيم بين الإدخال والإخراج لإعدادات GPT-6 Sol الأربعة الوسطى، لذلك تظهر تلك الخانات بقيمة n/a. النموذج Effort Intelligence Index التكلفة لكل مهمة تكلفة الإدخال تكلفة الإخراج رموز الإخراج لكل مهمة على الحد الأمثل GPT-6 Sol none 28.1 $0.33 $0.28 $0.05 4,900 لا GPT-6 Sol low 33.9 $0.13 n/a n/a 3,400 نعم GPT-6 Sol medium (افتراضي) 39.8 $0.25 n/a n/a 6,500 نعم GPT-6 Sol high 42.8 $0.37 n/a n/a 10,200 نعم GPT-6 Sol xhigh 44.1 $0.53 n/a n/a 16,000 نعم GPT-6 Sol max 47.5 $1.06 $0.74 $0.31 31,200 نعم GPT-6 Astra low 45.8 $0.82 $0.60 $0.22 4,400 نعم GPT-6 Astra medium 49.6 $1.54 $1.06 $0.48 9,600 لا GPT-6 Astra high 50.9 $1.73 $1.13 $0.59 11,800 لا GPT-6 Astra xhigh 52.4 $2.31 $1.46 $0.85 16,900 لا GPT-6 Astra max 52.7 $3.26 $1.90 $1.36 27,200 لا Claude Opus 5 low 39.4 $1.10 $0.73 $0.37 14,700 لا Claude Opus 5 medium 44.8 $2.19 $1.47 $0.72 29,000 لا Claude Opus 5 high (افتراضي) 48.1 $3.61 $2.46 $1.16 46,200 لا Claude Opus 5 xhigh 49.7 $4.88 $3.36 $1.52 60,700 لا Claude Opus 5 max 50.8 $5.86 $4.05 $1.81 72,500 لا Claude Opus 5.5 low 42.3 $0.55 $0.35 $0.20 10,200 لا Claude Opus 5.5 medium (افتراضي) 51.2 $1.34 $0.82 $0.51 25,700 نعم Claude Opus 5.5 high 53.6 $1.82 $1.11 $0.71 35,600 نعم Claude Opus 5.5 xhigh 56.0 $3.46 $2.15 $1.31 65,700 نعم Claude Opus 5.5 max 57.6 $5.98 $3.60 $2.38 119,200 نعم Claude Fable 5.1 low 46.8 $2.37 $1.30 $1.08 21,600 لا Claude Fable 5.1 medium 48.9 $2.98 $1.59 $1.39 27,900 لا Claude Fable 5.1 high 51.2 $3.91 $2.01 $1.90 38,100 لا Claude Fable 5.1 xhigh 53.2 $5.98 $2.96 $3.02 60,500 لا Claude Fable 5.1 max 53.4 $7.63 $3.73 $3.90 78,100 لا على الحد الأمثل يعني أنه لا يوجد إعداد آخر في هذا الجدول يحقق نتيجة أعلى بمال أقل. الحد الأمثل للتكلفة عشرة من الإعدادات الستة والعشرين تقع على الحد الأمثل. بعد ترتيبها حسب التكلفة، هي الإعدادات الوحيدة التي تستحق النظر إذا كان السعر هو المعيار الوحيد. كل ما عداها يدفع أكثر مقابل النتيجة نفسها أو أقل. الإعداد Intelligence Index التكلفة لكل مهمة لكل 10,000 مهمة GPT-6 Sol · low 33.9 $0.13 $1,300 GPT-6 Sol · medium 39.8 $0.25 $2,500 GPT-6 Sol · high 42.8 $0.37 $3,700 GPT-6 Sol · xhigh 44.1 $0.53 $5,300 GPT-6 Astra · low 45.8 $0.82 $8,200 GPT-6 Sol · max 47.5 $1.06 $10,600 Claude Opus 5.5 · medium 51.2 $1.34 $13,400 Claude Opus 5.5 · high 53.6 $1.82 $18,200 Claude Opus 5.5 · xhigh 56.0 $3.46 $34,600 Claude Opus 5.5 · max 57.6 $5.98 $59,800 للحد الأمثل منطقتان. من 0.13 دولار إلى 1.06 دولار يكاد يكون كله GPT-6 Sol، والاستثناء الوحيد هو GPT-6 Astra low عند 0.82 دولار. ومن 1.34 دولار فصاعدًا لا يوجد إلا Opus 5.5. الفارق بين المنطقتين صغير: يحقق Opus 5.5 medium نتيجة أعلى من Sol max بـ 3.7 نقطة مقابل 0.28 دولار إضافية لكل مهمة. مقارنة مباشرة عند نتيجة مساوية أو أفضل يقارن كل زوج إعدادًا أرخص بإعداد أغلى يحقق النتيجة نفسها أو أقل. الإعداد الأرخص الإعداد الأغلى فارق النتيجة التوفير Opus 5.5 medium: 51.2, $1.34 Opus 5 high: 48.1, $3.61 +3.1 لصالح Opus 5.5 63% Opus 5.5 medium: 51.2, $1.34 Opus 5 max: 50.8, $5.86 +0.4 لصالح Opus 5.5 77% Opus 5.5 medium: 51.2, $1.34 Fable 5.1 high: 51.2, $3.91 تعادل 66% Opus 5.5 high: 53.6, $1.82 GPT-6 Astra max: 52.7, $3.26 +0.9 لصالح Opus 5.5 44% Opus 5.5 high: 53.6, $1.82 Fable 5.1 max: 53.4, $7.63 +0.2 لصالح Opus 5.5 76% GPT-6 Sol max: 47.5, $1.06 Opus 5 high: 48.1, $3.61 +0.6 لصالح Opus 5 71% يهم صف Opus 5 الفرق التي لم تنتقل بعد. كان Opus 5 يعمل افتراضيًا على high. أما Opus 5.5 فيعمل افتراضيًا على medium، وعند هذا الإعداد يحقق 3.1 نقطة أكثر بتكلفة أقل بنسبة 63% لكل مهمة. تقول Anthropic إن Opus 5.5 أرخص بنسبة 40% من Opus 5؛ والفارق المقيس على هذا المؤشر أوسع من هذا الادعاء. أين يذهب المال: الإدخال لا الإخراج في كل النماذج يمثل الإدخال ما بين نصف التكلفة لكل مهمة وثلاثة أرباعها تقريبًا. في Opus 5.5 عند medium، يذهب 0.82 دولار من 1.34 دولار إلى الإدخال، أي 61%. وفي GPT-6 Astra عند max تبلغ النسبة 58%، وفي GPT-6 Sol عند max تبلغ 70%، وفي Fable 5.1 عند max تبلغ 49%. تعيد مهام الوكلاء إرسال سياقها المتنامي في كل خطوة، لذا يزداد إنفاق الإدخال مع عدد الخطوات، لا مع طول الإجابة فقط. لهذا يكلّف GPT-6 Sol بلا استدلال أكثر منه عند low: 0.33 دولار مقابل 0.13 دولار، رغم أنه لا يكتب سوى 4,900 رمز إخراج. 0.28 دولار من 0.33 دولار هي إدخال. السبب المرجح هو كثرة الخطوات، وكل خطوة تعيد إرسال السياق. إيقاف الاستدلال لا يجعل الوكيل أرخص إذا احتاج بعده إلى جولات أكثر. بالنسبة إلى فاتورتك، يعني هذا أن التخزين المؤقت مهم بقدر أهمية اختيار النموذج. يتقاضى Opus 5.5 وGPT-6 Sol كلاهما 0.20 دولار لكل مليون رمز إدخال مخزّن مؤقتًا. ويتقاضى GPT-6 Astra دولارًا واحدًا، وOpus 5 نحو 0.50 دولار. حجم الرموز مقابل سعر القائمة GPT-6 Astra هو أكثر النماذج هنا اقتصادًا في الرموز. عند max يكتب 27,200 رمز إخراج لكل مهمة، مقابل 119,200 لـ Opus 5.5 عند max. لكن Astra يتقاضى 10 دولارات و50 دولارًا لكل مليون، أي 2.5× سعر Opus 5.5. يفوز سعر القائمة: يكلّف Opus 5.5 high نحو 1.82 دولار لكل مهمة بنتيجة 53.6، بينما يكلّف Astra max نحو 3.26 دولار بنتيجة 52.7. Opus 5.5 عند max هو الموضع الوحيد الذي تصبح فيه الإطالة مكلفة. تكلّف رموز الإخراج البالغة 119,200 نحو 2.38 دولار قبل أي إدخال، وتكلّف المهمة كاملة 5.98 دولار. هذا يشتري أعلى نتيجة في الجدول، 57.6، لكنه يساوي 4.5× تكلفة medium. تناقص العائد مع رفع مستوى effort يوضح كل صف ما تشتريه زيادة مستوى effort درجة واحدة، بنقاط المؤشر مقابل التكلفة الإضافية لكل مهمة. النموذج medium → high xhigh → max GPT-6 Sol +3.0 نقطة مقابل +48% +3.4 نقطة مقابل +100% GPT-6 Astra +1.3 نقطة مقابل +12% +0.3 نقطة مقابل +41% Claude Opus 5 +3.3 نقطة مقابل +65% +1.1 نقطة مقابل +20% Claude Opus 5.5 +2.4 نقطة مقابل +36% +1.6 نقطة مقابل +73% Claude Fable 5.1 +2.3 نقطة مقابل +31% +0.2 نقطة مقابل +28% في Fable 5.1 وGPT-6 Astra لا يشتري max شيئًا يُذكر: 0.2 و0.3 نقطة مقابل زيادة 28% و41%. وفي Opus 5.5 لا يزال الانتقال إلى max يضيف 1.6 نقطة، لكن بتكلفة أعلى بنسبة 73%. استخدم max فقط في المهام التي قست فيها أن النقاط الإضافية تغيّر النتيجة. متى يكفي GPT-6 Sol max المؤشر متوسط، والفجوة بين Sol max وOpus 5.5 medium ليست متساوية عبر التقييمات. النتائج لكل تقييم من Artificial Analysis: التقييم Opus 5.5 medium ($1.34) GPT-6 Sol max ($1.06) Terminal-Bench 4.0 52.5 43.9 AutomationBench-AA 61.2 61.6 GDPval-AA (Elo) 1576 1487 AA-Briefcase (Elo) 1642 1483 Humanity's Last Exam 54.7 47.9 SciCode 59.3 57.6 CritPt 27.7 30.9 AA-LCR 84.3 83.7 في AutomationBench وCritPt يعادل GPT-6 Sol أداء Opus 5.5 عند medium أو يتفوق عليه، بتكلفة 1.06 دولار لكل مهمة مقابل 1.34 دولار. وفي Terminal-Bench وتقييمات العمل المعرفي وHumanity's Last Exam يتقدم Opus 5.5 بفارق كبير. يمكن تشغيل أتمتة سير العمل على Sol. أما وكلاء الطرفية والبرمجة والعمل المعرفي كثيف المستندات فهي حيث يستحق Opus 5.5 سعره. ادعاءات المزوّد مقابل الأرقام المستقلة كثيرًا ما تختلف أرقام المزوّدين عن الأرقام المستقلة، لأنها تستخدم بيئات اختبار وإعدادات مختلفة. تعلن Anthropic أن Opus 5.5 عند xhigh يحقق 66.4% في Terminal-Bench 4.0. وتقيس Artificial Analysis نسبة 59.6% عند المستوى نفسه. Effort Opus 5.5 Fable 5.1 low 31.3% 40.4% medium 52.5% 44.9% high 56.6% 52.0% xhigh 59.6% 55.1% max 59.6% 52.0% قد يتغير الترتيب أيضًا حسب المؤشر. في Vals AI Index يأتي Fable 5.1 أولًا بنسبة 68.83%، وGPT-6 Astra ثالثًا بنسبة 66.61%، وOpus 5.5 رابعًا بنسبة 66.16%. لا تُنشر هناك التكلفة لكل مهمة على الأساس نفسه، لذا لا يغيّر ذلك الحد الأمثل أعلاه. المؤشر الواحد مجرد زاوية نظر واحدة. أسعار القائمة ومهمة كثيفة الذاكرة المؤقتة حسبت Digital Applied سعر مهمة وكيل واحدة كثيفة الذاكرة المؤقتة على كل نموذج: 8M رمز قراءة من الذاكرة المؤقتة، و400K إدخال غير مخزّن، و600K رمز كتابة في الذاكرة المؤقتة، و300K رمز إخراج. تتبع النتيجة الحد الأمثل، مع غرامة إضافية على GPT-6 Astra. النموذج الإدخال $/MTok الإخراج $/MTok قراءة الذاكرة المؤقتة $/MTok مهمة كثيفة الذاكرة المؤقتة (Digital Applied) GPT-6 Sol $2.00 $10.00 $0.20 $6.90 Claude Opus 5.5 $4.00 $20.00 $0.20 $12.20 Claude Opus 5 $5.00 $25.00 $0.50 $17.25 Claude Fable 5.1 $10.00 $50.00 $0.25 $28.50 GPT-6 Astra (≤272K) $10.00 $50.00 $1.00 $34.50 GPT-6 Astra (>272K) $20.00 $75.00 n/a $61.50 يحاسب GPT-6 Astra الطلب كله بسعر 20 دولارًا و75 دولارًا لكل مليون بمجرد تجاوز الإدخال 272K رمز. أما Opus 5.5 فيحافظ على سعر واحد عبر نافذته البالغة 1M رمز. تكلّف الكتابة في الذاكرة المؤقتة لدى Opus 5.5 نحو 5 دولارات لكل مليون للذاكرة المؤقتة لمدة 5 دقائق و8 دولارات لمدة ساعة، وتُحاسب الدفعات بنسبة 50%، ويضاعف الوضع السريع السعر. للتفاصيل، راجع نموذج تكلفة Claude Opus 5.5 و اقتصاديات الوضع السريع في Opus 5.5 . كيف تقيس تكلفتك الخاصة لكل مهمة سجّل الرموز لكل مهمة لا لكل طلب: الإدخال غير المخزّن، والإدخال المخزّن، والكتابة في الذاكرة المؤقتة، والإخراج، مجموعة عبر كل خطوات المهمة. خذ عينة من بضع مئات من المهام الحقيقية وأعد تشغيلها على إعدادين أو ثلاثة مرشحة، مثل Sol max وOpus 5.5 medium وOpus 5.5 high. قيّم كل نتيجة بالفحص نفسه الذي تستخدمه في الإنتاج، واحسب عدد المهام الناجحة. اقسم الإنفاق الكلي على عدد المهام الناجحة. التكلفة لكل مهمة ناجحة هي الرقم الذي تجب مقارنته، لأن الإعداد الرخيص الذي يفشل أكثر ليس رخيصًا. اختر أرخص إعداد يتجاوز عتبة الجودة لديك، ثم وجّه المهام الفاشلة فقط إلى إعداد أعلى. أعد التشغيل عندما يتغير سعر أو مستوى effort الافتراضي. لمعرفة كيف تغيّر مستويات effort فاتورة النموذج الواحد، راجع مستويات effort في Opus 5.5 هي السعر الحقيقي . تحفظات جميع التكاليف بأسعار قائمة API على مزيج مهام Artificial Analysis. الخصومات وتسعير الدفعات والتخزين المؤقت الخاص بك تغيّرها. تصنّف Artificial Analysis إدخالات Opus 5.5 وFable 5.1 بعلامة Default Fallback. راجع ملاحظات المنهجية قبل اعتبار كل صف إعداد API نفسه. النتائج من إصدار المؤشر v4.3.2 فقط. الإصدارات السابقة استخدمت تقييمات مختلفة ولا يمكن مقارنتها. مهمة Digital Applied كثيفة الذاكرة المؤقتة حمل عمل توضيحي واحد، وليست قياسًا. تتغير الأرقام عندما يغيّر المزوّدون الأسعار أو الإعدادات الافتراضية. تاريخ الاطلاع هو 22 سبتمبر 2026. المصادر Artificial Analysis Intelligence Index Artificial Analysis: Claude Opus 5.5 Artificial Analysis: Claude Opus 5 Artificial Analysis: Claude Fable 5.1 Artificial Analysis: GPT-6 Astra Artificial Analysis: GPT-6 Sol Digital Applied: GPT-6 Sol vs Claude Opus 5.5 cost benchmarks Digital Applied: Claude Opus 5.5 vs GPT-6 Astra Digital Applied: Is Claude Fable 5.1 still worth it? Digital Applied: Claude Opus 5.5 launch pricing and benchmarks Digital Applied: Opus 5.5 vs Grok 4.7 vs Muse Spark 1.3 cost per task مقالات ذات صلة نموذج تكلفة Claude Opus 5.5 مستويات effort في Opus 5.5 هي السعر الحقيقي اقتصاديات الوضع السريع في Opus 5.5 هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # حلقات إعادة المحاولة والإنفاق الخفي للنماذج · FinOps LLM URL: https://finopsllm.com/ar/research/retry-loop-hidden-spend حلقات إعادة المحاولة والإنفاق الخفي للنماذج آخر تحديث August 27, 2026 · نُشر أول مرة August 27, 2026 إجابة سريعة: تتسبب حلقات إعادة المحاولة الصامتة (Silent Retry Loops)، وبدائل النماذج التلقائية، وفشل استدعاء الأدوات في تضاعف استهلاك الرموز وفواتير الاستدلال في بيئات الإنتاج دون إشعار فوري للفرق الهندسية. عندما... تتسبب حلقات إعادة المحاولة الصامتة (Silent Retry Loops)، وبدائل النماذج التلقائية، وفشل استدعاء الأدوات في تضاعف استهلاك الرموز وفواتير الاستدلال في بيئات الإنتاج دون إشعار فوري للفرق الهندسية. عندما يفشل نموذج في صياغة استجابة مهيكلة بصيغة JSON أو تتأخر أداة خارجية، يعيد النظام الطلب تلقائياً، مضاعفاً التكلفة على طلب واحد للمستخدم. احتساب شجرة المحاولات بالكامل عندما تفشل محاولة، لا تضيع تكلفة الاستدعاء الأول، بل تُضاف إلى المحاولة الثانية والثالثة. إذا كان الاستدعاء يتطلب 4,000 رمز إدخال وتمت إعادته 3 مرات، فإن تكلفة العملية بلغت 12,000 رمز إدخال لتحقيق استجابة واحدة فقط. يجب أن تسجل أنظمة القياس عن بعد (Telemetry) عدد المحاولات وسبب التكرار والتكلفة التراكمية لكل معاملة. التمييز بين التكرار المفيد والتكرار المهدر ليست كل عمليات إعادة المحاولة سيئة؛ فإعادة المحاولة بسبب انقطاع شبكي عابر أو تجاوز معدل الطلبات (Rate Limit) تحمي تجربة المستخدم. ولكن إعادة المحاولة بسبب فشل النموذج في استيفاء شروط منطقية أو أخطاء برمجية في المطالبة تؤدي إلى هدر مالي مستمر لا يثمر أي فائدة. وضع ميزانيات عند حدود الحلقة البرمجية لمنع النزيف المالي في الإنتاج، يجب تطبيق الضوابط التالية: وضع حد أقصى لمحاولات إعادة التنفيذ (لا يتجاوز محاولتين لمعظم العمليات). تطبيق قواطع الدوائر (Circuit Breakers) لإيقاف المحاولات عند استمرار فشل المزود أو الخدمة المستهدفة. تحديد سقف تكلفة إجمالي للمعاملة (Cost Budget per Request) يمنع تجاوز الحد المالي المسموح. مقالات ذات صلة حواجز إنفاق الوكلاء المستقلين مراقبة تكاليف الاستدلال التكلفة لكل مهمة ناجحة هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # أرصدة الذكاء الاصطناعي في SaaS: قياس وحدة لا تملكها · FinOps LLM URL: https://finopsllm.com/ar/research/saas-ai-credits-metering أرصدة الذكاء الاصطناعي في SaaS: قياس وحدة لا تملكها آخر تحديث September 2, 2026 · نُشر أول مرة September 2, 2026 إجابة سريعة: تفترض ممارسات FinOps السحابية أن وحدة الاستهلاك واضحة ومقروءة: ساعة تشغيل خادم، أو طلب، أو غيغابايت. أما رصيد الذكاء الاصطناعي لدى مزودي برمجيات SaaS فليس كذلك. إنه وحدة يحددها المزود، ويسعرها، ويمكنه... تفترض ممارسات FinOps السحابية أن وحدة الاستهلاك واضحة ومقروءة: ساعة تشغيل خادم، أو طلب، أو غيغابايت. أما رصيد الذكاء الاصطناعي لدى مزودي برمجيات SaaS فليس كذلك. إنه وحدة يحددها المزود، ويسعرها، ويمكنه تعديل قيمتها في منتصف مدة العقد. يتصرف الإنفاق كاستهلاك متغير دون أن يمنحك أدوات الحوكمة التي تجعل الاستهلاك قابلاً للإدارة. ثلاث خصائص تعطل آليات الإدارة التقليدية وحدة غامضة: يمكن لميزتين برمجيتين استهلاك كميات متفاوتة تماماً من الأرصدة لنفس الإجراء من وجهة نظر المستخدم، ونادراً ما تُنشر معادلة التحويل. تسعير احتكاري للاستهلاك الفائض: يحدد المزود سعر التجاوز (overage) منفرداً دون وجود بديل سوقي أرخص لنقل عبء العمل. انتهاء صلاحية الحصص دون تدوير: الحصص المخصصة لكل مقعد لا تجمع بين الفرق ولا ترحل للشهر التالي، مما يجعلك تدفع رسوم تجاوز لفريق بينما تضيع أرصدة فريق آخر غير مستخدمة. تتبع الاستهلاك ببياناتك المستقلة اسحب بيانات الاستهلاك من واجهة برمجة تطبيقات إدارة المزود بجدول زمني منتظم، وخزنها في سلسلة زمنية مملوكة لك مصنفة حسب المستخدم والفريق والميزة البرمجية. لوحة تحكم المزود تعرض الشهر الحالي فقط، بينما أسئلتك المالية تتمحور حول الاتجاه العام. توزيع التكلفة قبل وصول الفاتورة اربط الأرصدة بمراكز التكلفة ذاتها المستخدمة في السحابة، وأصدر تقارير الاستعراض المالي (showback) شهرياً. الإنفاق غير الموزع يستقر تلقائياً في ميزانية تقنية المعلومات، وهو الفريق الوحيد الذي لا يملك أي تأثير على حجم استهلاك الأقسام الأخرى. وضع سقوف صارمة واستثمارها في التجديد فعل السقف الإداري الصارم في لوحة تحكم المزود لوقف الإنفاق قبل حدوثه. واستخدم 12 شهراً من بيانات التتبع المستقلة كأقوى ورقة تفاوض للمطالبة بتجميع الأرصدة وترحيلها وتثبيت أسعار التجاوز عند تجديد العقد. مقالات ذات صلة الذكاء الاصطناعي الخفي على بطاقات الشركات خصومات الإنفاق الملتزم به هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # أدوات الخوادم تُفوتر خارج عداد الرموز · FinOps LLM URL: https://finopsllm.com/ar/research/server-tools-are-a-separate-invoice أدوات الخوادم تُفوتر خارج عداد الرموز آخر تحديث September 1, 2026 · نُشر أول مرة September 1, 2026 إجابة سريعة: عند حساب تكاليف وكلاء الذكاء الاصطناعي، تركز معظم الفرق الهندسية حصرياً على رموز الإدخال والإخراج. ولكن عند تشغيل أدوات الخوادم المدارة من قبل المزودين (مثل البحث في الويب، وجلب صفحات الإنترنت، وبيئات... عند حساب تكاليف وكلاء الذكاء الاصطناعي، تركز معظم الفرق الهندسية حصرياً على رموز الإدخال والإخراج. ولكن عند تشغيل أدوات الخوادم المدارة من قبل المزودين (مثل البحث في الويب، وجلب صفحات الإنترنت، وبيئات تنفيذ الأكواد في حاويات معزولة)، تُفرض رسوم ثابتة إضافية على كل استدعاء للأداة، مما قد يضاعف فاتورة الاستدلال بشكل غير متوقع. أثر التراكم المضاعف لتكاليف الأدوات قد تبدو تكلفة 5 دولارات لكل 1,000 عملية بحث على الويب بسيطة، ولكن وكيلاً برمجياً يبحث في الويب 6 مرات في كل جولة، مع إجراء 100,000 جولة شهرياً، سيولد فاتورة أدوات بقيمة 3,000 دولار، تُضاف مباشرة إلى فاتورة الرموز الأساسية. إذا لم تكن هذه التكلفة مرئية في لوحات التحكم، فلن يتمكن الفريق المالي من تفسير الفارق. إسناد تكاليف الأدوات بدقة يجب توسيع بنية القياس عن بعد لتسجيل كل استدعاء لأداة خارجية كحدث مستقل مرتبط بنفس معرف الجلسة والحساب والميزة. يتيح ذلك دمج تكلفة الأدوات مع تكلفة رموز الاستدلال للحصول على التكلفة الحقيقية الإجمالية للمهمة. ثلاثة ضوابط هندسية فعالة لحماية الميزانية من انفلات تكاليف الأدوات: وضع حد أقصى لعدد استدعاءات الأدوات المسموح بها للوكيل في المهمة الواحدة. تطبيق التخزين المؤقت لنتائج الأدوات الخارجية لتقليل تكرار عمليات البحث عن نفس الموضوعات. تفضيل الأدوات المحلية الخفيفة كلما أمكن ذلك بدلاً من استدعاء خدمات خارجية باهظة التكلفة. مقالات ذات صلة اقتصاديات التخزين المؤقت للمطالبات تكلفة الطلب الواحد كمؤشر أداء إسناد تكاليف نماذج الذكاء الاصطناعي هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # تكلفة الردود المتدفقة المهجورة على الميزانية · FinOps LLM URL: https://finopsllm.com/ar/research/streaming-abandoned-generations-cost تكلفة الردود المتدفقة المهجورة على الميزانية آخر تحديث September 9, 2026 · نُشر أول مرة September 9, 2026 إجابة سريعة: يعد التدفق السريع للردود (Streaming Responses) المعيار الذهبي لتجربة المستخدم في تطبيقات الذكاء الاصطناعي، حيث يرى العميل الكلمات تتوالى فور توليدها. ولكن ماذا يحدث عندما يقرأ المستخدم أول سطرين،... يعد التدفق السريع للردود (Streaming Responses) المعيار الذهبي لتجربة المستخدم في تطبيقات الذكاء الاصطناعي، حيث يرى العميل الكلمات تتوالى فور توليدها. ولكن ماذا يحدث عندما يقرأ المستخدم أول سطرين، ويحصل على مبتغاه، ثم يغلق علامة تبويب المتصفح أو يطرح سؤالاً جديداً فوراً؟ في كثير من الأحيان، يستمر الخادم في توليد مئات الرموز ودفع ثمنها للمزود في الخلفية دون أن يراها أحد. ظاهرة الاستجابات المهجورة (Abandoned Generations) عندما ينقطع العميل، لا يعلم المزود السحابي بذلك تلقائياً إلا إذا تم إرسال إشارة إلغاء صريحة عبر بروتوكول HTTP. إذا استمر النموذج في كتابة فقرة من 800 رمز أهملها المستخدم بعد أول 50 رمزاً، فإن 93% من تكلفة رموز الإخراج لتلك العملية ذهبت هدراً كاملاً. الحلول الهندسية لإيقاف الهدر للقضاء على تكلفة الردود المهجورة: ربط إشارات الإلغاء (AbortController Propagation): تمرير إشارة انقطاع اتصال العميل فوراً إلى استدعاء واجهة برمجة التطبيقات للمزود عبر السلسلة البرمجية بأكملها. رصد ومراقبة معدل الهجر: قياس نسبة الرموز المولدة التي لم تصل للعميل، واستخدامها كمؤشر هندسي لجودة التفاعل وسرعة الاستجابة. إيقاف التوليد التلقائي عند بدء طلب جديد: إلغاء أي مهام سابقة في الجلسة ذاتها فور قيام المستخدم بإرسال رسالة جديدة. مقالات ذات صلة مراقبة تكاليف نماذج اللغة الكبيرة تكلفة الطلب الواحد كمؤشر أداء حدود المعدل كأداة للتحكم في التكاليف هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # كبح تفرع الوكلاء الفرعيين واستنزاف الرموز · FinOps LLM URL: https://finopsllm.com/ar/research/subagent-fan-out-concurrency-limits كبح تفرع الوكلاء الفرعيين واستنزاف الرموز آخر تحديث September 19, 2026 · نُشر أول مرة September 19, 2026 إجابة سريعة: تتيح المعماريات متعددة الوكلاء (Multi-Agent Architectures) حل مشكلات معقدة عبر تفويض المهام لوكلاء فرعيين متخصصين. ولكن في غياب ضوابط معمارية صارمة، قد يؤدي تفرع الوكلاء (Agent Fan-Out) إلى متوالية... تتيح المعماريات متعددة الوكلاء (Multi-Agent Architectures) حل مشكلات معقدة عبر تفويض المهام لوكلاء فرعيين متخصصين. ولكن في غياب ضوابط معمارية صارمة، قد يؤدي تفرع الوكلاء (Agent Fan-Out) إلى متوالية هندسية من الاستدعاءات المتزامنة التي تستنزف ميزانية الرموز في دقائق معدودة. رياضيات تفويض الوكلاء التكراري إذا فوض الوكيل الرئيسي 4 وكلاء فرعيين، وقام كل وكيل فرعي بتفويض 4 مهام أخرى بعمق مستويات متعددة، فإن عدد استدعاءات النماذج يتضاعف أُسياً. مع كل استدعاء، يُعاد إرسال سياق الجلسة والمطالبات وأوصاف الأدوات، مما يقفز باستهلاك الرموز إلى ملايين الوحدات لمهمة واحدة كان يمكن إنجازها بنص برمجي بسيط. أربعة حواجز إنتاجية لأسراب الوكلاء للسيطرة على استهلاك الرموز في بيئات التشغيل، ينبغي تفعيل القواعد التالية: حد أقصى للتفرع المتزامن (Concurrency Limit): تقييد عدد الوكلاء الفرعيين النشطين في نفس اللحظة (مثلاً، 3 إلى 5 وكلاء كحد أقصى). تقييد عمق التكرار (Recursion Depth Ceiling): حظر تفويض الوكلاء الفرعيين لأكثر من مستوى واحد أو مستويين من الوكلاء. مجمع رموز موحد للجلسة (Unified Token Pool): تحديد سقف تكلفة إجمالي للمهمة الأصلية تتشاركه كافة المهام الفرعية المنبثقة عنها. مهلة زمنية للعمليات غير المتزامنة (Execution Timeout): إيقاف أي وكيل فرعي يعلق في حلقة تفكير أو أداة لا تستجيب. مقالات ذات صلة ميزانيات الوكلاء الثلاث دليل التعامل مع قفزات تكاليف النماذج حلقات إعادة المحاولة والإنفاق الخفي هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # الميزانيات الثلاث التي يحتاجها كل وكيل ذكاء اصطناعي · FinOps LLM URL: https://finopsllm.com/ar/research/three-agent-budgets الميزانيات الثلاث التي يحتاجها كل وكيل مستقل آخر تحديث August 27, 2026 · نُشر أول مرة August 27, 2026 إجابة سريعة: يحتاج الوكيل المستقل إلى أكثر من مجرد تنبيه بالإنفاق الشهري. إنه يحتاج إلى ثلاث ميزانيات محددة يتم فرضها داخل حلقة اتخاذ القرار الخاصة به: ميزانية الطلب للاستدعاء الواحد، وميزانية سير العمل للمهمة... يحتاج الوكيل المستقل إلى أكثر من مجرد تنبيه بالإنفاق الشهري. إنه يحتاج إلى ثلاث ميزانيات محددة يتم فرضها داخل حلقة اتخاذ القرار الخاصة به: ميزانية الطلب للاستدعاء الواحد، و ميزانية سير العمل للمهمة الكاملة، و الميزانية اليومية للمالك أو المستأجر. 1. ميزانية الطلب (Request Budget) تضع حداً أقصى للرموز، واستدعاءات الأدوات، وزمن التأخير، أو التكلفة بالدولار لمحاولة استنتاج واحدة. وهي تحمي من تضخم السياق والمخرجات الطويلة غير المتوقعة. يتم فرضها قبل إرسال الطلب للمزود وقبل تنفيذ أي أداة. 2. ميزانية سير العمل (Workflow Budget) ترافق نية المستخدم عبر الأدوار والمحاولات ومسارات التراجع وتفويض الوكلاء الفرعيين. تتطلب معرف ربط (correlation ID) ودفتراً حسابياً مستمراً. وتتوقف المهمة فور تجاوز الحد حتى لو كانت كل المحاولات الفردية ضمن النطاق المسموح. 3. الميزانية اليومية (Daily Budget) تحد من إجمالي الإنفاق لفريق أو عميل أو خاصية. وهي أداة للعدالة واحتواء نطاق الخطأ. وعند اقترابها من النفاد، يمكن توجيه العمل للنماذج الأصغر أو المعالجة المجمعة لحفظ السعة المخصصة للأعمال الحيوية. إرجاع أسباب الرفض بشكل مفيد يجب أن يوضح رفض الميزانية أي سقف تم بلوغه، وما تم استهلاكه، ومسار الاستئناف المتاح، مع إصدار حدث قابل للتدقيق المالي ومطابقته مع فواتير المزودين. مقالات ذات صلة التكلفة لكل مهمة ناجحة هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # انخفاض أسعار الرموز وارتفاع فاتورة النماذج · FinOps LLM URL: https://finopsllm.com/ar/research/token-prices-bill-keeps-rising انخفاض أسعار الرموز وارتفاع فاتورة النماذج آخر تحديث August 27, 2026 · نُشر أول مرة August 27, 2026 إجابة سريعة: لا يضمن انخفاض سعر الرمز المميز (Token) انخفاض الفاتورة الإجمالية لنماذج اللغة الكبيرة في بيئات الإنتاج. في الواقع، غالباً ما ينمو الاستخدام الفعلي بمعدل أسرع من نسبة انخفاض الأسعار: السياقات الأطول،... لا يضمن انخفاض سعر الرمز المميز (Token) انخفاض الفاتورة الإجمالية لنماذج اللغة الكبيرة في بيئات الإنتاج. في الواقع، غالباً ما ينمو الاستخدام الفعلي بمعدل أسرع من نسبة انخفاض الأسعار: السياقات الأطول، وخطوات الوكلاء المتعددة، والمخرجات الأكبر حجماً، وحلقات إعادة المحاولة، والميزات الجديدة كفيلة بمحو أثر تخفيض سعري بنسبة 40%. لا يكمن التشخيص المفيد في معرفة أي المزودين أصبح أرخص، بل في تحليل الانحراف رباعي الأبعاد: السعر، والحجم، ومزيج النماذج، والكفاءة. السعر جزء واحد فقط من الفاتورة لنفترض أن المزود خفض السعر المرجح من 10 دولارات إلى 6 دولارات لكل مليون رمز. إذا ارتفع استهلاكك الشهري من 100 مليون إلى 220 مليون رمز، فإن الفاتورة سترتفع من 1,000 دولار إلى 1,320 دولاراً. انخفض السعر بنسبة 40%، لكن الفاتورة ارتفعت بنسبة 32%. لوحة التحكم التي تركز فقط على سعر الرمز ستعد ذلك إنجازاً، بينما تراه الإدارة المالية عجزاً واضحاً. تتبع سعر المزود الفعلي المحسوب بحسب كل نموذج وكل نوع من أنواع الرموز: رموز الإدخال، ورموز الإخراج، ورموز القراءة من التخزين المؤقت، ورموز الكتابة، ورموز التفكير الاستدلالي. دمج هذه المقاييس في متوسط واحد يخفي الحقيقة وراء أرقام مضللة. الحجم والمزيج والكفاءة الحجم (Volume): هو عدد الرموز المستهلكة فعلياً عند نمو حركة المرور أو استطالة سياق المطالبات. المزيج (Mix): يوضح وجهة استهلاك الرموز، مثل التحول إلى نماذج تفكير استدلالي متقدمة أو التوسع في مناطق جغرافية ذات تسعير أعلى. الكفاءة (Efficiency): تمثل تكلفة إنجاز نتيجة مفيدة واحدة، متضمنةً إعادة المحاولة، وفشل استدعاء الأدوات، والمطالبات المتضخمة، والمخرجات غير المستغلة. المراجعة التي تكتشف المشكلة مبكراً قم ببناء جسر أسبوعي من الفترة السابقة إلى الحالية. ابدأ بفاتورة الأساس، وطبق تغيرات السعر، ثم تغيرات الحجم، ثم المزيج، ثم الكفاءة. التنبيه العملي ليس "ارتفعت الرموز بنسبة 20%"، بل "ارتفعت التكلفة المعدلة بحركة المرور لكل مهمة ناجحة بنسبة 18%". نوع الانحراف السؤال الجوهري الإجراء النموذجي السعر هل تغيرت أسعار المزود الفعلية؟ تحديث جداول الأسعار والافتراضات التعاقدية. الحجم هل نمت حركة المرور أو أطوال السياق؟ التنبؤ بالاستخدام وفرض ضوابط السعة الاستيعابية. المزيج هل انتقلت المهام إلى نماذج أغلى سعراً؟ مراجعة سياسات التوجيه وعتبات الجودة الفنية. الكفاءة هل تطلبت النتيجة مزيداً من الجهد الحوسبي؟ معالجة التكرارات، والمطالبات، والأدوات، وقواعد الإيقاف. أولويات التحسين الهندسي لا تبدأ بإجبار جميع الطلبات على استخدام أرخص نموذج متاح. ابحث أولاً عن فئة الانحراف التي تسبب أكبر استنزاف مالي. إذا كان الحجم هو الطاغي، فعالج نمو السياق وحلقات الوكلاء. وإذا كان المزيج، فأنشئ سياسة توجيه ذكية. وإذا كانت الكفاءة، فأزل التكرارات غير اللازمة والمخرجات المهملة. مقالات ذات صلة مراقبة تكاليف نماذج اللغة الكبيرة تكلفة الطلب الواحد كمؤشر أداء إسناد تكاليف نماذج الذكاء الاصطناعي هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # ما هو DeepSeek Harness؟ دليل شامل · FinOps LLM URL: https://finopsllm.com/ar/research/what-is-deepseek-harness ما هو DeepSeek Harness؟ دليل شامل آخر تحديث August 16, 2026 · نُشر أول مرة August 16, 2026 إجابة سريعة: DeepSeek Harness — اسم الحزمة dsh — هو إطار عمل وكلاء (agent harness) مفتوح المصدر ومرخص برخصة MIT من شركة DeepSeek AI. إليك الدليل الشامل والمبسط: ما هو، وكيفية تشغيله، وبنيته الهندسية، ولماذا يهمك... DeepSeek Harness — اسم الحزمة dsh — هو إطار عمل وكلاء (agent harness) مفتوح المصدر ومرخص برخصة MIT من شركة DeepSeek AI. إليك الدليل الشامل والمبسط: ما هو، وكيفية تشغيله، وبنيته الهندسية، ولماذا يهمك أمره في إدارة تكاليف وهندسة الذكاء الاصطناعي. ما هو إطار عمل الوكيل (Agent Harness) في الأساس النموذج اللغوي يولد نصوصاً واستدعاءات أدوات فقط. لا يفعل أي شيء آخر. كل ما يجعل الوكيل مفيداً عملياً يقع على عاتق إطار العمل (Harness): تجميع التعليمات البرمجية، وتنفيذ الأدوات المطلوبة، وفرض صلاحيات الأمان، وتسجيل ما حدث، وإدارة حلقة اتخاذ القرار، وتفويض المهام لوكلاء فرعيين. هذا الفارق جوهري؛ فمعظم ما يفعله الوكيل بنجاح أو فشل يعود لسلوك إطار العمل وليس للنموذج نفسه. يمكن لفريقين تشغيل النموذج ذاته والحصول على نتائج وتكاليف متباينة تماماً — والفارق يكمن في إطار العمل. ما الذي يقدمه DeepSeek Harness يقوم بتشغيل وكلاء البرمجة والأتمتة. عملياً، يستطيع الوكيل قراءة الملفات وتعديلها، وتشغيل أوامر shell، والبحث في الكود، وتفويض العمل إلى وكلاء فرعيين، وتخطيط المهام، وطلب الإذن وفقاً لسياسة الأمان المحددة. يتضمن واجهة متصفح، ووضع التشغيل الآلي بدون واجهة (headless)، وخادم أتمتة عبر JSON-RPC عبر الإدخال والإخراج القياسي. الفكرة الأساسية: كل شيء عبارة عن إضافة (Plugin) يعتمد الإطار على بيئة تشغيل Cordis ، حيث تقدم الإضافات الخدمات والأحداث والتأثيرات القابلة للعكس في سياق مشترك. لا توجد نواة خاصة متميزة: محول النماذج هو إضافة، وسجل الأدوات إضافة، وسجل الجلسة إضافة، وحلقة الوكيل نفسها إضافة. طريقة التشغيل الطريقة السريعة npx @deepseek-ai/dsh web يبدأ تشغيل واجهة الويب المحلية على المنفذ http://127.0.0.1:3080 . من المصدر (Source) git clone https://github.com/deepseek-ai/deepseek-harness cd deepseek-harness pnpm install pnpm run build pnpm dsh web المتطلبات: Node 22.19 أو أحدث، وGit 2.26 أو أحدث، مع pnpm مثبت عبر Corepack. مفتاح DeepSeek API اختياري أثناء التثبيت ولكنه ضروري للعمل الفعلي. خطوتان يغفل عنهما الكثيرون الإعدادات ← النماذج: أدخل مفتاح API لتفعيل التوجيه فوراً دون إعادة تشغيل. اختر مساحة العمل: أضف مجلد المشروع وقم بتنشيطه، وإلا سيظل محرر الجلسة مقفلاً. الوضع الآلي (Headless) pnpm dsh --profile headless "summarize this workspace" المفاهيم الأساسية المصطلح المعنى الخطوة (Step) استدعاء نموذج واحد بالإضافة إلى استدعاءات الأدوات الناتجة عنه الدور (Turn) إفراغ المدخلات، وينتهي بتوقف النموذج أو تدخل السياسة الجولة (Round) تكرار سياسة خارجي عبر الأدوار، مثل إعادة محاولة لتحقيق هدف الجلسة (Session) سجل إلحاقي فقط للأحداث يمثل المصدر الوحيد للحقيقة واجهة القدرة واجهة خدمة قابلة للتبديل بتطبيقات متعددة الملف التعريفي (Profile) تكوين مسمى لمجموعة إضافات مرتبة مع تصحيحات النطاق (Scope) وحدة تسجيل للأدوات والمطالبات والقيود لكل وكيل أبرز ما يميزه استبدال مزود النماذج: واجهة خدمة النماذج تدعم موفرين متعددين، بما في ذلك إعادة تشغيل جلسة مسجلة بدون تكلفة استنتاج جديدة. تسجيل كامل للجلسة: كل ما يراه النموذج يتم تسجيله، مع ربط استهلاك الرموز (tokens) بالاستدعاء المسبب لها مباشرة. نقاط حماية وفرض صريحة: نقطة قبل إرسال طلب النموذج ونقطة قبل تنفيذ أي أداة لمنع النفقات الخارجة عن السيطرة. تشغيل بدون واجهة (Headless): يتيح وضعه داخل مسارات التكامل المستمر CI/CD ومراقبته دورياً. بنية الإضافات ليست مجرد ميزة تسويقية: أحد العروض التوضيحية المدمجة تفحص وتعدل بيئة إضافاتها قيد التشغيل ذاتياً. متى تستخدمه ومتى تتجنبه استخدمه: للتقييم، وبناء النماذج الأولية، وكمعيار هندسي للمقارنة مع حزمة الوكلاء التي تشغلها حالياً. لا تعتمده كمعيار إنتاجي نهائي هذا الربع: يصف المشروع نفسه بأنه معاينة للمطورين (Developer Preview) وستطرأ عليه تغييرات جذرية في التوافق. تكاليف التشغيل الإطار نفسه مجاني ومرخص بـ MIT. لكن الاستنتاج ليس مجانياً: فاتورتك تتحدد بعدد الخطوات، والأدوات في الكتالوج، وعمق تفويض الوكلاء، وعدد جولات تحقيق الأهداف — وهي كلها قرارات يحددها إطار العمل وليس سعر الرمز وحده. مقالات ذات صلة دليل التثبيت والملفات التعريفية بنية الإضافات وبيئة التشغيل هل تريد تطبيق ذلك على منصتك؟ أحضر فواتير المزوّدين وسجلات البوابة وأهم تدفقات العمل؛ وسنحدد محركات التكلفة وفرص التوفير. احجز تدقيقًا مجانيًا → العودة إلى finopsllm.com --- # Amazon Bedrock cost audit · Where the bill goes · FinOps LLM URL: https://finopsllm.com/audit/bedrock Amazon Bedrock cost audit Bedrock lands in Cost Explorer alongside your other AWS spend, which makes it feel governable with habits your platform team already has. Most of those habits do not transfer, and the gaps are specific. 1. There is nothing to tag until you create something to tag Cost allocation tags are the standard AWS attribution mechanism, and on Bedrock a foundation model is not a resource you own, so there is nothing to attach them to. The handle is the application inference profile: create one per workload or team, tag it, and route invocations through it rather than calling the model id directly. Teams that skipped this have one untagged Bedrock line in Cost Explorer and no way to split it afterwards, because tags apply from creation forward. Reconstructing attribution for months already billed means CloudTrail or your own request logs, which is why the profile inventory is the first thing we ask for. 2. Provisioned throughput bills whether or not you use it Provisioned throughput is bought in model units on an hourly commitment, and an idle unit costs exactly what a saturated one costs. Two failure modes recur: capacity bought for a launch that never reached its projected volume, and units left running against a superseded model version after a migration. The audit compares committed capacity with actual token throughput per hour across a representative month. Low utilisation on non-spiky traffic means on-demand is cheaper outright, and that comparison is a spreadsheet rather than an experiment. 3. Cross-region inference moves where the tokens are billed Cross-region inference profiles improve availability by routing to whichever region has capacity. That is a good default, and it quietly changes the billing picture: spend appears in regions nobody deployed to, per-region prices differ, and residency assumptions written into a compliance document need re-reading against the profile's real behaviour. This rarely produces a large saving by itself. It produces a correct baseline, without which the rest of the numbers are unreliable. 4. Batch and caching are left on the table Bedrock's batch inference runs at a substantial discount for work that tolerates a completion window, and prompt caching is supported on a subset of models with the usual rules: identical prefix, reused inside the window. The audit looks for asynchronous workloads still on the synchronous path and for stable system prompts that never get cached, because both fixes are configuration rather than architecture. What the audit needs from you Cost Explorer access, or a Cost and Usage Report export for the last 90 days filtered to Bedrock. Your inference profile inventory and current tagging scheme, in whatever state it is in. Provisioned throughput commitments: what is running, on which model, since when. For your top workloads, a representative request and any documented latency requirement. About a week, ending in a written document with a ranked savings list and an effort cost against each item. Free, and implementable without us. Running OpenAI or Vertex AI alongside Bedrock? That is the common case, and the audit covers them together - the same workload priced in two places is usually the most useful finding in the document. Book the audit . Back to FinOps LLM FAQ How do you apply cost allocation tags to Bedrock spend? Through application inference profiles. A foundation model is not a resource you own, so there is nothing to tag directly; you create a profile per workload or team, tag the profile, and route invocations through it instead of calling the model id. Can Bedrock spend be attributed retroactively? No. Tags apply from creation forward, so months already billed under an untagged setup cannot be split in Cost Explorer. Reconstructing that history means going to CloudTrail or your own request logs. Why does Bedrock spend appear in regions we never deployed to? Cross-region inference profiles route to whichever region has capacity, so tokens are billed where they are served. Per-region prices differ and any data-residency assumption in a compliance document should be re-read against what the profile actually does. When is provisioned throughput cheaper than on-demand? Only when committed model units run at high utilisation. An idle unit costs the same as a saturated one, so if realised throughput sits well below the commitment and traffic is not spiky, on-demand is usually cheaper outright. --- # OpenAI cost audit · Where the bill goes · FinOps LLM URL: https://finopsllm.com/audit/openai OpenAI cost audit This is the OpenAI-specific half of a cost audit. The generic advice - use a cheaper model, cache more - is worth close to nothing until you know which of these four is driving your invoice. 1. Attribution stops at the project boundary OpenAI's attribution unit is the project. Keys belong to projects, and the Costs and Usage endpoints under the organization admin API bucket spend by project and by model. That is the entire granularity the platform offers. If teams share a project, or share a key, the invoice is one number and no dashboard work will split it. The fix is dull and comes first: one project per workload or owning team, keys reissued accordingly, then the Costs endpoint pulled on a schedule into whatever finance already reads. Anything finer - per customer, per feature, per endpoint - has to come from your own logging, because the platform does not carry it. 2. Cached input is either a large discount or nothing Prompt caching applies automatically above a minimum prefix length and discounts the cached portion sharply, but only when the prefix is byte-identical and reused inside the cache window. Two habits destroy it: a timestamp, session id or retrieved chunk near the top of the prompt, and system prompt variants rotating per request. Cached input tokens are reported separately, which makes the test trivial: pull the ratio of cached to uncached input tokens per workload. A high-volume workload with a stable system prompt and a near-zero cache ratio is usually the largest recoverable line on an OpenAI bill, and the remedy is prompt reordering rather than a migration. 3. Reasoning tokens bill as output and never appear in the response On reasoning models, tokens spent thinking are billed at the output rate and are absent from the text you received. A team tracking cost against response length will find the invoice inexplicable, because the expensive part is invisible by design. The audit compares reasoning token counts per workload against the configured effort level, because most workloads run higher effort than the task needs. Classification, extraction and routing rarely justify extended reasoning, and lowering the effort there is usually a same-day change with a measurable before and after. 4. The Batch tier is unused on work that is already asynchronous Batch runs at roughly half price with a completion window measured in hours. The audit looks for workloads that already tolerate minutes or hours of latency - nightly enrichment, backfills, evaluation runs, document queues - and are still on the synchronous endpoint because that is what the prototype used. This is arithmetic rather than engineering. Either the workload has a documented latency requirement or it does not, and if it does not, half the cost is available for a queue change. What the audit needs from you Organization-level read access, or an export from the Costs endpoint covering the last 90 days. The project list and roughly what each serves. For your top two or three workloads, a representative request including the system prompt. Your latency requirements, if they are written down anywhere. About a week, ending in a written document with a ranked savings list and an effort cost against each item. Free, not a slide deck, and implementable without us. Also running Amazon Bedrock or Google Vertex AI ? Multi-provider is the normal case and the audit covers them together, because the same workload priced in two places is usually the most useful finding in the document. Book the audit . Back to FinOps LLM FAQ How granular can OpenAI spend attribution get? The platform attributes to the project and the model, because keys belong to projects and the Costs endpoint buckets on those dimensions. Anything finer, such as per customer or per feature, has to come from your own request logging. Why is my cached input discount not applying? Prompt caching requires a byte-identical prefix above a minimum length, reused inside the cache window. A timestamp, session id or retrieved chunk placed near the top of the prompt breaks the prefix and silently removes the discount. Why does the bill exceed what the response lengths suggest? Reasoning models bill thinking tokens at the output rate and those tokens never appear in the returned text. A workload measured on visible response length will read as inexplicable until reasoning tokens are counted separately. When is the Batch API worth moving a workload to? Whenever the workload tolerates a completion window measured in hours, which covers nightly enrichment, backfills and evaluation runs. It runs at roughly half price, so the only question is whether a latency requirement is actually documented. --- # Vertex AI cost audit · Where the bill goes · FinOps LLM URL: https://finopsllm.com/audit/vertex-ai Vertex AI cost audit Vertex AI spend is legible at SKU level, and the billing console will not show you that level. Almost every Vertex audit begins by getting the data somewhere it can actually be queried. 1. The BigQuery billing export is the audit The detailed usage cost export into BigQuery is the only place model-level SKUs, request counts and label dimensions exist together. The console rolls Vertex up into a handful of lines that give a total and nothing else. If the export is not enabled, enable it today and accept that history starts now - it is not backfilled. That single fact reorders the work: on projects without it, week one is standing it up and reconstructing an approximate baseline from invoices rather than running queries. It costs almost nothing and every subsequent question depends on it. 2. Labels are the attribution mechanism and must be set at request time Labels attach to requests and resources and flow into the billing export as queryable columns. Unlike a project split, they let you attribute the same model in the same project across teams, features or customers, which is what most organisations actually need. The catch is that they must be attached when the call is made. Unlabelled traffic is unattributable forever, and the usual finding is that a large share of spend sits in exactly that bucket. The remedy is a small change in whatever client wrapper your services share, and it should land before anyone argues about chargeback. 3. Provisioned throughput is bought in units and burns while idle Provisioned throughput reserves capacity in units on a term commitment and bills for the term regardless of use. The recurring pattern is a commitment sized for a forecast that did not arrive, or one carried through a model migration and left pointed at a version the traffic no longer uses. The audit compares committed units against realised throughput in the export. Consistently low utilisation on non-spiky traffic means pay-as-you-go is cheaper, and a mixed shape - commitment sized to the traffic floor, overflow on demand - is usually right rather than an all-or-nothing choice. 4. Context caching bills for storage, not only for hits This is the Vertex-specific trap. Explicit context caching charges for cached tokens held per hour on top of the discounted read. Cache a large document set, let the traffic pattern shift, and you are paying rent on tokens nobody reads. The check is the ratio of cache storage cost to cache read savings per workload. It is one query against the export and it comes out negative more often than teams expect, especially where a cache was sized during a launch and never revisited. Where it is positive, it is among the largest levers available. What the audit needs from you Read access to the detailed billing export in BigQuery, or an export covering the last 90 days. If it is not enabled, say so - that changes the plan rather than blocking it. Your current labelling convention, if one exists. Provisioned throughput commitments: units, model, term, start date. Any explicit caches you have created and roughly what they hold. About a week, ending in a written document with a ranked savings list and an effort cost against each item. Free, and yours to implement without us. Also on OpenAI or Amazon Bedrock ? Multi-provider is the normal case and the audit covers them together, because the same workload priced in two places is usually the most useful line in the document. Book the audit . Back to FinOps LLM FAQ Why is the Google Cloud billing console not enough for Vertex AI cost work? The console rolls Vertex up into a handful of lines. Model-level SKUs, request counts and label dimensions only exist together in the detailed usage cost export in BigQuery, which is where every useful query is run. Is the BigQuery billing export backfilled when you enable it? No. History starts on the day it is enabled, so a project without it needs an approximate baseline reconstructed from invoices while the export accumulates real data. Enabling it costs very little and everything downstream depends on it. How do you attribute Vertex AI spend to a team or feature? With labels attached at request time, which flow into the billing export as queryable columns and can split one model in one project across teams or customers. Traffic sent without labels is unattributable permanently. Does explicit context caching always save money on Vertex AI? No. Cached tokens are billed for storage per hour on top of the discounted read, so a cache whose traffic pattern changed can cost more than it saves. Compare storage cost against read savings per workload before assuming a gain. --- # Benchmarks · FinOps LLM · Cost per Successful Task URL: https://finopsllm.com/benchmarks Benchmarks FinOps LLM benchmarking starts with cost per successful task, not raw token price. Model choice, cache hit rate, latency, retry behavior, and quality thresholds all change the real unit economics. Normalize provider invoices into comparable token buckets. Measure quality before and after routing or cache changes. Separate synchronous user paths from batchable offline work. Read the research notes Why cost per token is the wrong benchmark Per-token pricing is the number providers publish and the number that predicts your bill worst. A model half the price that needs two attempts to complete the task costs the same and adds latency. A cheaper model with a smaller context window forces you to send more retrieval chunks, so the token count rises to meet the discount. The comparable unit is cost per successful task, where "successful" is defined by your own eval before the comparison starts. What a usable benchmark controls for Retries and fallbacks. Count every billable call the task produced, not the one the user saw. Cache hit rate. Prompt caching changes effective price by a large factor and varies wildly by workload shape; a benchmark run without it measures a system nobody operates. Context length in practice. Measure the p95, not the average — the tail is where the bill lives. Quality, held constant. Fix the acceptable quality floor first, then compare cost among the options that clear it. Comparing cost across models at different quality levels is not a benchmark, it is a preference. How often should you re-run them? Quarterly, and after any provider price change or new model tier. LLM benchmarks go stale faster than infrastructure benchmarks because all three inputs move independently: providers cut prices, release cheaper tiers, and change rate limits, while your own traffic mix shifts as the product grows. A routing decision made on last quarter's price list is usually still defensible and occasionally expensive. Synchronous versus batchable work Split the benchmark before you run it. User-facing paths are latency-bound and cannot use batch pricing; offline enrichment, evals, and index rebuilds can, often at half the cost, and they are frequently the larger share of tokens. Benchmarking them together produces an average that describes neither. Back to FinOps LLM --- # Book a free LLM cost audit · FinOps LLM URL: https://finopsllm.com/book Book a free LLM cost audit Thirty minutes on a call, then a written audit of where your AI spend is actually going. No cost, no commitment, nothing to install. This is an engagement with people doing the work, not a product you sign up for. What you are booking: a 30-minute call, free, a written audit within 5 business days, read-only access only. Pick a time . What happens The call, 30 minutes. Which providers, roughly what you spend, and what triggered the question. We tell you on the call whether there is anything worth finding. If there is not, we say so. The audit, about a week. Read-only billing and usage exports mapped back to the workloads that produced them. This is the part almost nobody has done, because the invoice arrives as one line per provider. The readout, 30 minutes. A written document and a call to walk it through: where the spend goes, what drives it, what the realistic savings are, and what each one costs in effort. It is yours whether or not anything follows. What the audit needs from you Provider invoices or usage exports for the last three months, from whichever of OpenAI, Anthropic, AWS Bedrock, Google Vertex AI or Azure OpenAI you run. Gateway or proxy metadata if it exists (LiteLLM, Helicone, Langfuse, OpenRouter, or your own). Aggregated only. If there is no gateway, that is itself part of the finding. Ten minutes on your top workflows , so token counts can be attributed to something a budget owner recognises. Read-only, no prompt or output content, no production credentials. The full access scope is on the security page , and an NDA can be signed before anything is exchanged. What you get back Spend broken down by model, workload and team instead of one line per provider. The specific drivers: retries, oversized context, an expensive model on a cheap task, uncached repeats, agent loops nobody is watching. A ranked savings list with an estimated figure and an effort cost against each item. A baseline to re-measure against, so the next spike has something to be compared to. Who this is not for Under $20k a month in AI spend. That is the minimum for a managed engagement - below it, a percentage of savings does not cover the work for either side. The audit is still free if you want a second opinion, but the research library , the cost calculator and the pricing tracker will get you most of the way on your own. Shopping for a dashboard. This is a service engagement, not a signup. If self-serve monitoring is the requirement, that is a different kind of tool. Unable to share billing data. There is no version of this that works from a description of the problem alone. Pick a time , or email hello@finopsllm.com with your monthly spend and providers and we will tell you whether a call is worth it. Back to FinOps LLM FAQ Is the audit actually free? Yes. It is how we qualify work, and it is cheaper for both sides than a proposal written blind. Most audits end with a ranked list you could implement yourself; some end with us doing it. Do you need production or write access? No. Read-only billing and usage exports are enough for attribution work, and they stay revocable by you at any time without asking us first. What if we have no gateway and no per-team tags? That is the normal starting point and it does not block the audit. Invoice and usage exports still support a first-pass attribution, and instrumenting for the next pass becomes one of the recommendations. How long does it take to see savings? The audit takes about a week. The top one or two items are usually configuration changes that land the same week you decide to make them; anything needing an architecture change is labelled as such. --- # Careers · FinOps LLM · No Open Roles, Notes Welcome URL: https://finopsllm.com/careers No open roles. FinOps LLM is early. We are not hiring against a standing headcount plan right now. If you have shipped LLM gateways, cost attribution systems, billing reconciliation, or AI FinOps workflows, you can still send a short note and one thing you built. hello@finopsllm.com What we'd want to see There is no role to apply to, so a note is worth sending only if you have done the specific work. Concretely: an LLM gateway or proxy that survived production traffic, a cost attribution system that reconciled to an actual invoice, billing or usage pipelines where the numbers had to be defensible to finance, or FinOps practice built for teams rather than for a dashboard. One paragraph on what you built, what it cost you to learn, and what you would do differently is more useful than a resume. How the work is shaped The problems here are mostly data-correctness problems dressed as cost problems. Provider exports disagree with invoices at the edges, retries and agent runs make per-call accounting misleading, and a tagging scheme that nobody enforces decays into an unallocated bucket within a quarter. Enjoying that kind of reconciliation work — the part where you find out why two numbers that should match don't — matters more than familiarity with any particular provider's API. What to expect if you write A reply either way, usually within a week. If there is something to discuss, it starts with a conversation about a system you have already built rather than a take-home exercise. If there isn't, we will say so plainly instead of leaving the note open; keeping a pipeline warm for a headcount plan that does not exist wastes your time more than ours. Contract and advisory arrangements are also possible where a defined piece of work exists — attribution instrumentation, invoice reconciliation, or a gateway migration — even when there is no permanent role. Back to FinOps LLM --- # Case Studies · FinOps LLM · References Available Under NDA URL: https://finopsllm.com/case-studies No public case studies yet. Customer outcomes should be published only when the customer approves the wording, numbers, and context. Until then, this page stays conservative. For evaluations, we can discuss anonymized workload patterns and sample deliverable structure under NDA. Request references Why this page is empty on purpose Cost case studies are the easiest marketing artifact to write dishonestly. The savings percentage depends entirely on where the baseline was drawn, and a baseline chosen after the fact can make almost any change look transformative. A team that had never enabled prompt caching will show a large number for switching it on; that number says something about their starting point, not about the work. Publishing it without that context would be technically true and practically misleading. What we can share before a case study exists Anonymized workload patterns — the shapes that produce runaway spend, such as agent runs with unbounded retries, retrieval that grows context faster than it improves answers, and background jobs nobody has attributed. The deliverable structure — what a baseline report contains, what the attribution model looks like, and which decisions it is meant to support. Method, in full — how invoices are reconciled, how quality is held constant during a routing test, and how savings are verified against a later invoice rather than a projection. What a published case study will contain When customers approve one, it will state the billing period the baseline came from, the traffic mix, which levers were applied in what order, the quality measurement used, and the verified invoice difference — including anything that did not work. A case study without a failed lever in it has usually been edited. Until then, references and method discussions are available under NDA, which is a slower answer than a number on a page and a more accurate one. Back to FinOps LLM --- # LiteLLM vs Helicone vs Langfuse vs OpenRouter · FinOps LLM URL: https://finopsllm.com/compare/llm-gateways LiteLLM vs Helicone vs Langfuse vs OpenRouter We do not sell any of these and we are not a reseller for any of them. We end up configuring one or more on most engagements, so this is the comparison we give on the call, written down. The short version: these four are not really competitors. Three sit on the same wire and get compared for that reason alone. Pick by the problem you have rather than by feature count. What each one actually is LiteLLM - a proxy and SDK giving roughly a hundred providers one OpenAI-shaped interface, plus virtual keys, per-key budgets, rate limits and fallback routing. Open source and self-hostable with a paid enterprise tier. This is the piece that gives you a control point. Helicone - an observability layer, usually installed as a one-line proxy change. Logs every request with cost, latency and tokens attached, plus caching and user-level tracking. Open source core, hosted tier. Langfuse - tracing and evaluation for LLM applications. Its native shape is an SDK capturing nested traces of an agent or chain, with prompt management, datasets and eval runs on top. Cost is attached to traces, but cost control is not its subject. OpenRouter - not a tool you run. A hosted marketplace reselling hundreds of models behind one API and one bill, with automatic fallback between providers. You are buying inference, not infrastructure. Which problem sends teams to each one "We cannot tell which team spent this." LiteLLM. Virtual keys per team or workload are the cheapest attribution mechanism that exists, and they make budgets enforceable rather than reportable after the fact. "We can see the total, not the shape." Helicone. Request-level logs with cost attached answer what a dashboard aggregate cannot, and the caching is a real lever rather than a reporting feature. "Our agent burns tokens and we cannot see where." Langfuse. Nested traces are the only view that makes a forty-step loop legible, and step-level token counts are where agent cost problems are actually found. "We want to try twelve models without twelve contracts." OpenRouter. One integration, one invoice, immediate access. Excellent for evaluation and a deliberate trade at production volume. What each one will not do for you This is the part vendor comparison tables leave out, and it is the part that decides whether the tool solves your problem. None of them attribute existing spend retroactively. They start measuring on install day. The six months of invoices before that stay opaque, which is why a first pass usually happens in a spreadsheet against raw exports. A gateway is a new dependency in the request path. Self-hosted LiteLLM in front of production traffic needs the availability treatment any critical proxy needs. Teams underestimate this and find out during an incident. Observability is not optimisation. Helicone and Langfuse will identify an expensive workload with high confidence. Neither routes it to a cheaper model, caches its prefix, or defends the quality bar afterwards. That work stays with your engineers. A marketplace adds a margin and a hop. OpenRouter's convenience is real, and so is the pricing spread against going direct at volume, plus an extra network hop and a second vendor's uptime in your critical path. Cost is not the same field twice. Each tool computes cost from its own price table. Reconcile against the provider invoice before trusting a figure, particularly across a price change or a cached-input discount. The combination most teams land on The common production shape is a gateway for control plus a tracing tool for depth: LiteLLM holding keys, budgets and routing, with Langfuse or Helicone answering why a given workload costs what it does. That is two systems rather than one, because enforcement and explanation are genuinely different jobs. The cheaper answer if you are early: pick the one matching the sentence you keep repeating in meetings. A team that cannot attribute spend does not need traces yet, and a team drowning in agent loops does not need virtual keys yet. Where we sit We are a service rather than a platform. We license no dashboard and have no incentive to move you onto one, which is the only reason this page can be neutral. Tidal Telemetry , our OpenLIT-based observability product, is separate and is not a prerequisite for anything here. Verify before you commit. Everything above is checkable against the vendors' own docs and pricing pages, which change often. If you want a second opinion on which fits your stack, the free audit ends with that recommendation in writing, including the option of none of them. Back to FinOps LLM FAQ Is LiteLLM a replacement for Helicone or Langfuse? No. LiteLLM is a control plane that holds keys, budgets and routing, while Helicone and Langfuse explain what a workload costs and why. Most production stacks run a gateway plus one observability tool because enforcement and explanation are different jobs. Is OpenRouter cheaper than going direct to a provider? Not usually at volume. It resells inference behind one API and one invoice, which is excellent for evaluating many models quickly, but it adds a margin and a network hop compared with a direct provider contract. Will any of these tools attribute the spend I already have? No. All of them start measuring the day they are installed, so historical invoices stay opaque. Attributing past spend is a reconciliation exercise against raw provider exports rather than something a proxy can do retroactively. Why do the cost numbers differ between the tool and my invoice? Each tool computes cost from its own price table, which drifts against provider price changes, cached-input discounts and committed-use rates. Reconcile any tool figure against the provider invoice before reporting it. --- # Contact FinOps LLM URL: https://finopsllm.com/contact Contact FinOps LLM Ask us about an AI spend audit, Tidal Telemetry, or a partnership. Do not include passwords, API keys, or customer data in this form. Name Work email Company Topic Choose a topic AI spend audit Tidal Telemetry Partnership Support Other Message Website Send message Prefer a call? Pick a time . You can also try hello@finopsllm.com . Agents can use the documented JSON endpoint with the user's permission. Back to FinOps LLM --- # FinOps LLM - KI-Kostenmanagement & LLM-Observabilität URL: https://finopsllm.com/de/ FINOPS · LLM Basierend auf den FinOps Foundation-Prinzipien · angepasst für Tokens KI-Kostenkontrolle für das Token-Zeitalter. FinOps LLM ist die KI-Kostenmanagement- und LLM-Observabilität -Plattform für Engineering-Teams, die produktive GenAI betreiben. Echtzeit-Attribution über OpenAI, Anthropic, Bedrock und Gemini · Anomalieerkennung , Chargeback und automatisierte Optimierung (Routing, Caching, Komprimierung) · monatliche Abstimmung gegen rohe Provider-Rechnungen. Kostenloses Audit anfordern → Plattform besuchen Rechnungsgestützte Audits Typische Reduktion 40–60% Standardmäßig schreibgeschützt Multi-Cloud app.finopsllm.com / customer-042 / overview DEMO Arbeitsbereich ◧ Übersicht ◫ Attribution 12 ⚡ Anomalien 3 ↗ Prognose Optimierung ◊ Routing ⌬ Cache ≡ Komprimierung Finanzen $ Chargeback ▥ Budgets ✓ Abstimmung Übersicht Ausgaben Qualität Abstimmung Ausgaben Monat bis dato $70,280 ↓ 57,4% vs. Baseline Beispiel-Einsparungen $94,720 mit Rechnung abgestimmt Cache-Hit-Quote 38,1% +4,2 Punkte Woche für Woche Qualitäts-Delta +0,2% 7-Tage A/B Test aktiv Tägliche LLM-Ausgaben · letzte 45 Tage 5. Apr - 5. Mai 2026 Baseline ($165K/Mon.) Optimiert ($70,3K/Mon.) Ausgabenattribution · diesen Monat nach Feature RAG · 38% Agent · 26% E-Mail · 18% Klassif. Sonstig. RAG-Suche $26.700 Agent-Läufe $18.300 E-Mail-Entwurf $12.600 Klassifikation $7.700 Aktivitäts-Feed Letzte 24 Stunden · alle anzeigen ! Anomalie: RAG-Ausgaben p95 +38% vs. 7-Tage Durchschnitt 14:22 UTC · feature/rag-v2 · untersuchen → $ Routing v3 auf 100% des Datenverkehrs hochgefahren 11:08 UTC · projizierte Einsparung: $4.820/Mon. + Cache-Hit-Quote überschritt 38%-Schwelle 09:14 UTC · Invalidierung feingestellt ⚑ Budget · Team "Agent" bei 78% Monat bis dato 06:42 UTC · automatische Drosselung aktiviert ✓ Abstimmung Apr 2026 unterzeichnet 1 Mai · −57,4% vs. Baseline Abgestimmt gegen alle großen Provider OpenAI Anthropic Gemini Bedrock Azure Groq Together Mistral 01 Die Plattform FinOps für KI, in vier Säulen. FinOps LLM bringt das FinOps Foundation-Rahmenwerk - Sichtbarkeit, Attribution, Optimierung, Verantwortung - auf LLM- und GenAI-Ausgaben. Gleiche Disziplin. Andere Kosteneinheit. SÄULE 01 Sichtbarkeit Token-Level-Kostendaten von jedem Provider aufgenommen. Stündlich abgestimmt. Filterbar nach Provider, Modell, Feature, Team, Kunde, Umgebung. OpenAI · Anthropic · Bedrock · Gemini · Azure · Groq · Together Stündliche Aufnahme · <5 Min. Abstimmungsverzögerung Standardmäßig schreibgeschützt · NDA und DPA auf Anfrage SÄULE 02 Attribution & Chargeback Jeder Token auf ein Feature, Team und Kundenkohort abgebildet. Monatliche Chargeback- und Showback-Berichte, in Ihr Finanzsystem oder als CSV exportiert. Benutzerdefinierte Dimensionen · Feature, Team, Tier, Region Ausgaben nach Kohort · P&L pro Kundentier NetSuite · QuickBooks · CSV · API SÄULE 03 Anomalieerkennung Echtzeit-Warnungen, wenn Ausgaben, Latenz oder Qualität von der rollierenden Baseline eines Features abweichen. Slack, PagerDuty, E-Mail - und automatische Drosselung, wenn es zählt. Rollende Baselines pro Feature · Saisonalitätsbewusst Slack · PagerDuty · E-Mail · Webhook Optionale automatische Drosselung & Budget-Einhaltung SÄULE 04 Automatisierte Optimierung Modell-Routing, semantisches Caching und Prompt-Komprimierung hinter Feature-Flags bereitgestellt, mindestens sieben Tage A/B-getestet, nur mit Qualitäts- und Kostengewinnen freigegeben. Routing-Baum · Qualitätsklassifizierung pro Anfrage Semantisches Caching · Hit-Latenz <10ms Quality SLOs + automatisches Rollback bei Regression 02 Optimierung Sechs Hebel, die wir bei jedem Engagement ziehen. Die meisten Teams kombinieren drei oder vier. Die Prüfung klassifiziert, welche Ihre Ausgabenfläche dominieren, und projiziert Einsparungen vor jeglichem Engagement. 01 30–50% Modell-Routing Jede Anfrage nach Komplexität klassifiziert und zum billigsten Modell weitergeleitet, das Ihren Qualitätsstandard erfüllt. Reasoning zu Flaggschiff-Modellen; Klassifizierung und Extraktion zu kleinen, schnellen Modellen. 02 20–40% Semantisches Caching Nahezu doppelte Prompts mit Embeddings identifiziert; identische Antworten aus Cache <10ms bereitgestellt. Ähnlichkeitsschwellen pro Feature feingestellt. 03 15–30% Prompt-Komprimierung System-Prompts auf Redundanz geprüft. Beispiele dedupliziert. Abgerufener Kontext mit LLMLingua-Stiltechniken komprimiert. Jede Änderung A/B-getestet. 04 10–50% Batch-Preise & Asynchronität Nicht-interaktive Workloads zu Batch-Endpoints weitergeleitet (bis 50% Rabatt) mit SLO-bewusstem Queueing für zeitempfindliche Routen. 05 20–35% Provider-Arbitrage Identische Kapazität kostet häufig 2–3× mehr bei einem Provider. Wir routen nach Kapazität pro Dollar, nicht nach dem SDK, mit dem Ihr Team begann. 06 5–15% Fallback-Ketten Intelligente Wiederholungen und gestaffelte Fallbacks schlagen Over-Provisioning des Worst Case. Halten Sie SLOs ohne Flaggschiff-Preise bei jedem Anruf. 03 Engagement Prüf. Implementier. Stimm ab. Wiederhole. Jedes Engagement folgt denselben vier Phasen. Die meisten Kunden sehen ihre erste abgestimmte Provider-Rechnung am Ende von Woche fünf. 01 WOCHE 01 AUDIT Jede Ausgabe kartieren. Wir erfassen Provider-Rechnungen, Gateway-Logs und Nutzungstelemetrie. Bis Freitag haben Sie eine vollständige Karte Ihrer LLM-Ausgaben - nach Provider, Modell, Feature, Team - klassifiziert nach Dollar-Verschwendung. Deliverable Ausgabenkarte · priorisierte Chancen · feste Baseline (kontrasigniert) 02 WOCHE 02 PLAN Nach Verschwendung klassifizieren. Das Audit wird in einen priorisierten Engineering-Plan konvertiert, der Ihre Compliance-Haltung, Latenz-SLOs und Launch-Prozess respektiert. Qualitäts-Guardrails pro Endpoint vereinbart. Signaturen auf jede Änderung. Deliverable Engineering-Plan · Routing-Baum · Cache-Spec · Quality-SLOs · Launch-Timeline 03 WOCHEN 03–05 LAUNCH Launch & A/B-Test. FinOps LLM Engineers paaren sich mit Ihren, um jede Optimierung hinter Feature Flags zu starten, sieben Tage gegen die Baseline A/B zu testen und auf 100% des Verkehrs hochzufahren. Das Cockpit wird gleichzeitig aktiviert. Deliverable Aktives Cockpit · Slack-Warnungen · wöchentliche Überprüfung · erste Abstimmung 04 LAUFEND ABSTIMMEN Einsparungen zusammensetzen. Preise ändern sich. Der Verkehr ändert sich. Modelle starten. Die Plattform überwacht Abweichung; wir empfehlen und implementieren Nachfolger, damit sich Einsparungen zusammensetzen. Jeder Monat schließt mit einem unterzeichneten Einsparungsnachweis ab. Deliverable Monatlicher unterzeichneter Bericht · Abweichungs- & Qualitätswarnungen · laufende Optimierung 04 Ergebnisse Zahlen von echten Engagements. Illustrative Reduktionsbereiche aus häufigen LLM-Optimierungshebeln. Echte Ziele werden nach einer Provider-Rechnungsprüfung und Workload-Überprüfung festgelegt. Typische Reduktion 40–60 % Bereich über Engagements, abhängig von Architektur und Traffic-Mix. Zeit bis Einsparungen 3–5 Wo Kickoff → erste abgestimmte Provider-Rechnung. Qualitäts-Delta +0 ,2 % Jede Änderung mindestens 7 Tage A/B-getestet. Audit-Gebühr $0 Kostenlos - angerechnet gegen Implementierung. 05 Preise Zahlen für Ergebnisse. Es gibt ein Engagement und es wird auf verifizierte Einsparungen berechnet. Tidal Telemetry ist eigenständige Software, kostenlos in der Beta. ★ AM BELIEBTESTEN Leistung Kostenloses Audit. Danach zahlen Sie nur, wenn wir Ihnen Geld sparen - gemessen gegen eine feste Baseline, abgestimmt mit Provider-Rechnungen. 15–25 % der verifizierten Einsparung Keine Einsparung, keine Gebühr · Audit angerechnet gegen Implementierung · jederzeit kündbar ✓ Kostenloses Audit · 1 Woche Bearbeitung · kontrasignierte Baseline ✓ Vollständiger Optimierungs-Stack · Routing, Caching, Komprimierung, Arbitrage ✓ Aktives Cockpit + Chargeback + unterzeichnete monatliche Berichte ✓ Engineering-Pairing mit FinOps LLM Team · wöchentliche Überprüfungen ✓ Quality SLO Einhaltung & automatisches Rollback ✓ Minimum: $20K/Mon. LLM-Ausgaben Kostenloses Audit anfordern → SELF-SERVICE · EIGENES PRODUKT Tidal Telemetry Observability-Software, die Sie selbst buchen und betreiben. Kein verwaltetes Engagement, keine Vertriebshürde. Kostenlos in der Beta keine Kreditkarte · Beta-Nutzer behalten einen kostenlosen Plan ✓ Eine Zeile Code · ~50 auto-instrumentierte Bibliotheken ✓ Reines OpenTelemetry-Ingest · das SDK ist optional ✓ Kosten pro Aufruf, Tokens, Latenz und Fehler als Traces ✓ Isolierter Speicher und Ingest-Key pro Projekt ✓ Eingebauter MCP-Server für Agenten-gesteuertes Setup ✓ Keine Engagement-Voraussetzung · nutzbar ohne Kontakt zu uns Tidal Telemetry ansehen → 06 Häufig gestellte Fragen Häufige Fragen. Fehlt etwas? Mailen Sie an hello@finopsllm.com - wir antworten innerhalb eines Arbeitstages. Was ist FinOps für LLM? + FinOps für LLM bringt das FinOps Foundation-Rahmenwerk - Sichtbarkeit, Attribution, Optimierung und Verantwortung - auf LLM- und GenAI-Ausgaben. Umfasst Chargeback und Showback pro Feature und Team, Anomalieerkennung, Budget-Governance und kontinuierliche Optimierung des Modell-Routings, Caching und Prompts. Was macht FinOps LLM? + FinOps LLM ist ein verwaltetes Engagement, keine Plattformlizenz. Wir bieten Echtzeit-Ausgabenattribution über OpenAI, Anthropic, Bedrock und Gemini, plus automatisierte Optimierung (Routing, Caching, Komprimierung) und monatliche Abstimmung gegen Provider-Rechnungen. Wie ist die Preisstrukturiert? + Ein Modell. Kostenloses Audit, danach 15–25% der verifizierten monatlichen Einsparung, gemessen an einer vor jeder Änderung fixierten Baseline. Keine Lizenzgebühr, keine Seats, kein Plattform-Minimum. Tidal Telemetry ist ein eigenes Produkt und in der Beta kostenlos. Wie viel können wir sparen? + Die typische Reduktion im ersten vollständigen Abrechnungszyklus nach der Implementierung beträgt 40–60% , abhängig von Architektur und Datenverkehrsmix. Welche Provider werden unterstützt? + OpenAI, Anthropic, Gemini & Vertex AI, AWS Bedrock, Azure OpenAI, Groq, Together, Mistral, Cohere, Fireworks, Replicate und die meisten OSS-Endpoints. Multi-Provider-Bereitstellungen haben typischerweise die größte Sparfläche. Unterstützt FinOps LLM Chargeback & Showback? + Ja. Token-Level-Attribution auf Provider, Modelle, Features, Teams und Kundenkohorten. Monatliche Chargeback- und Showback-Exporte in NetSuite, QuickBooks, CSV oder API . Benutzerdefinierte Dimensionen werden unterstützt. Wie handhaben Sie Kundendaten? + Nur lesen per Standard. Abrechnungs- und Nutzungsdaten reichen für die meisten Attributionsarbeiten aus. Prompt- und Output-Daten werden nur mit expliziter Kundengenehmigung für spezifische erforderliche Optimierungen verwendet. NDA und DPA auf Anfrage verfügbar. Wie lange dauert die Implementierung? + Attribution und Dashboards werden in weniger als einer Woche aktiviert. Optimierungsimplementierung dauert 3–5 Wochen; Einsparungen erscheinen in der ersten vollständigen Provider-Rechnung nach Go-Live. Wird die Optimierung die Ausgabequalität beeinträchtigen? + Nein. Jede Routing-, Cache- und Komprimierungsänderung wird mindestens sieben Tage gegen die Produktion A/B getestet, bevor es befördert wird. Regressionen werden automatisch zurückgerollt. Die Qualität wird kontinuierlich zusammen mit den Kosten überwacht. 07 Ressourcen Leitfäden, Benchmarks & Tools. Umfangreiche Forschung für Engineerings- und Finance-Leader, die FinOps für KI evaluieren. Kostenlos, keine Registrierung, monatlich aktualisiert. LEITFADEN ↗ FinOps für LLM: ein umfassendes Rahmenwerk Sichtbarkeit, Attribution, Optimierung, Verantwortung - auf Tokens angewendet. Mit 30-seitiger Referenzarchitektur. 16 MIN · MAI '26 NEU SEO-LEITFADEN -> KI-Kostenoptimierung Ein praktisches Playbook, um KI-Ausgaben durch Routing, Caching, Batching und Prompt-Disziplin zu reduzieren. 8 MIN MAI '26 ANLEITUNG ↗ Token-Level-Kostenattribution in der Produktion Tagging-Strategien, Chargeback-Mathematik und Gateway-Integrationsmuster. Mit Referenzcode. 11 MIN · CODE 4.2K LESEN BETRIEB ↗ LLM-Kostenüberwachung Die Metriken, Warnungen und Eigentümer-Limits, die Ausgabenänderungen in monatlichen Rechnungen verbergen verhindern. 10 MIN OPS LEITFADEN ↗ LLM-Kostenanomalien vor der Rechnung erkennen Feature-Baselines, Saisonalität und wie Sie Warnungen verkabeln, die Ingenieure nicht abschalten werden. 9 MIN · VORLAGEN 3.1K LESEN RAG -> RAG-Kostenoptimierung Reduzieren Sie abrufgetriebene Token-Verschwendung mit besserem Chunking, engeren Kontextlimits und selektivem Reranking. 7 MIN PRAKTISCH REFERENZ ↗ KI-FinOps-Glossar Definitionen für Attribution, Showback, Chargeback, Cache-Read-Tokens, Routing und Kosten pro erfolgreicher Task. REFERENZ KOSTENLOS FINANZEN ↗ LLM Chargeback und Showback So berichten Sie KI-Ausgaben pro Team und Produkt, bevor Sie es in Budgetzuweisung umwandeln. 8 MIN GOVERNANCE OPENAI ↗ OpenAI-Kostenattribution Request Tags, Rechnungsabstimmung, Wiederholungen und Workload-Klassen für OpenAI-Ausgaben. 7 MIN PRAKTISCH ANTHROPIC -> Anthropic-Kostenattribution Verfolgen Sie Anthropic-Ausgaben nach Feature, Eigentümer, Workload und Routing-Verhalten ohne Abstimmung zu unterbrechen. 7 MIN NEU ROUTING ↗ Modell-Routing So senden Sie einfache Anfragen an günstigere Modelle und halten dabei Qualität, Latenz und Fallback-Verhalten intakt. 12 MIN ALGO METRIKEN -> LLM-Token-Tracking Die Request-Level-Felder, die KI-Kostenänderungen für Engineering und Finance erklärbar machen. 6 MIN OPS PREIS ↗ Provider-Arbitrage Vergleichen Sie gleichwertige Modellkapazität über Provider ohne Migrationkosten und Overhead zu unterschätzen. 11 MIN BENCHMARKS DATEN ↗ LLM-Preis-nach-Kapazität-Benchmark · Q2 '26 Kosten pro erfolgreicher Task monatlich bei GPT, Claude, Gemini, Mistral, Llama bei standardisierten Workloads. MONATLICH AKTUALISIERT Q2 '26 LIVE FALLSTUDIEN ↗ Kundenergebnisse Öffentliche Fallstudien werden erst nach Kundengenehmigung veröffentlicht. Bis dahin werden Evaluationsreferenzen privat behandelt. UNTER NDA EHRLICH 08 Hier starten Bringen Sie Ihre KI-Rechnung unter Kontrolle. Etwa eine Woche. Nur-Lesen-Zugriff. Wir liefern Ihnen eine komplette Ausgabenkarte, klassifiziert nach Verschwendung, plus eine Baseline, die unser Operator-Cockpit verfolgen kann. Kostenlos. Keine Implementierungsverpflichtung. Kostenloses Audit anfordern → Benchmarks ansehen 30-MIN-ENTDECKUNG · NUR LESEN PER DEFAULT · NDA + DPA AUF ANFRAGE · UNVERBINDLICH --- # Forschung · FinOps LLM URL: https://finopsllm.com/de/research Forschung Notizen für Ingenieurs- und Finanzteams, die AI-Ausgabenverwaltung aufbauen. Hier anfangen Klare Erklärungen, wenn Sie neu bei LLM-Kosten sind. Wie berechnen LLM-Anbieter? Eingabe-, Ausgabe-, Cache- und Reasoning-Tokens erklärt Was ist LLM-Kostenattribution? Warum steigen meine LLM-Rechnungen an? Wie budgetiert man AI-Ausgaben? Alle Forschung A quarter of AI spend is slipping to 2027 (EN) Adaptives Denken und Kostenprognose Agent spend attribution (EN) Agent spend guardrails (EN) Agent Spend Guardrails: Runtime Controls That Work (EN) Agent TCO: The 70% of Cost That Isn't Tokens (EN) Agentenökonomie: Was kostet ein Codieragent wirklich? AI Coding Economics 2026: GLM vs DeepSeek vs Claude (EN) AI Cost Allocation: Tags, Cost Centers and Chargebacks (EN) AI Cost Optimization Checklist for 2026 (EN) AI Cost Optimization: Routing, Caching, Batching (EN) AI Cost Optimization: Six Levers That Actually Work (EN) AI cost recovery playbook: stop the bleeding (EN) AI FinOps: das Betriebsmodell für GenAI-Ausgaben AI observability: cost, traffic, and quality · FinOps LLM (EN) AI-Kostenanomalien-Erkennung Anthropic cost attribution (EN) Auswirkung von MCP-Servern auf Kosten Azure OpenAI vs. Direkt OpenAI: Kosten, PTU & Einsparungen Batch APIs as a FinOps lever (EN) Caching-Strategien im Vergleich Chargeback vs Showback: Picking the Right FinOps Model (EN) Chargeback when your provider won't bill per team (EN) ChatGPT Pro Max $500 plan economics (EN) Claude Max 20x isn't 20x. We checked 60 days of logs against Codex (EN) Claude Max 20x vs 5x: is the $200 price worth it? We measured the real weekly usage ceiling (EN) Claude Max vs Alibaba Token Pro: Reale Kosten von Agentic Coding Claude Opus 5.5 Kostenmodell Claude Sonnet 5.5 pricing: what changes, what does not (EN) Claude Sonnet 5.5: the cost-aware model routing guide (EN) Cloud Infrastructure Cost Audit: Alibaba vs Claude Max (EN) Codex auto-compact on GPT-6 Sol: the defaults in the source code, and what raising them costs (EN) Codex usage limit resets: how they work, banked resets and a dated log (EN) Compliance-Kosten von KI-Wasserzeichen Cost per request as a product KPI (EN) Cursor vs Copilot vs Claude Code Cost (EN) Das Kontextfenster zweimal bezahlen Das Playbook des getarnten Modells Das Sitzungsprotokoll von DeepSeek Harness als Kostennachweis DeepSeek Harness Subagenten: Delegation als Kostenmultiplikator DeepSeek Harness: Installation, Profile und erster Lauf DeepSeek Harness: Tool-Scopes, Restriktionen und Shadowing DeepSeek Harness: was „alles ist ein Plugin“ wirklich bringt DeepSeek Harness: Ziele, Ziel-Runden und die Ralph-Schleife Der erste Monatsabschluss für ein KI-lastiges Produkt Der Gratis-Tarif als Kundenakquisekosten Die Bruttomarge eines KI-Features vor dem Launch messen Die drei Budgets, die jeder autonome Agent braucht Die Retry-Schleife, die Inferenzkosten heimlich erhöht Die tatsächlichen Kosten eines LLM-Anbieterwechsels Echte Kosten pro Aufgabe bei Frontier-Modellen Enterprise AI procurement and committed spend (EN) Eval cost allocation: who pays for LLM evals (EN) Find the cache miss behind your OpenAI bill (EN) FinOps für LLM und GenAI: ein praktischer Rahmen FOCUS 1.5 bringt natives AI-Token-Tracking und Price Sheets Gartner's 2026 AI spending forecast (EN) GenAI cost management: controls and analytics (2026) (EN) GPT-5 Pricing and Budget Impact: A 2026 Planning Guide (EN) GPT-5 vs GPT-4o Cost Comparison: When to Upgrade (EN) GPT-5.6-Preisschichten-Anleitung: Luna, Terra, Sol GPT-6 Astra cost model (EN) GPT-6 Luna cost model (EN) GPT-6 pricing: Astra, Sol and Luna (EN) GPT-6 Sol cost model (EN) GPT-6 Sol long-context benchmarks: what has actually been measured, and what is GPT-5.6 Sol (EN) Günstigste KI-Code-Generierung (2026) Hidden LLM Costs Beyond Per-Token Pricing (EN) Hintergrund-Agenten verändern die FinOps-Uhr How do LLM providers charge? Tokens, tiers, caching (EN) How many tokens do you get with Claude Pro and Max? We counted them (EN) How much Codex does ChatGPT Pro include? We priced the weekly limit in dollars (EN) How to budget for AI spend: a starter framework (EN) How to cap inference costs and prevent runaway spending (EN) How to check and reduce Claude Code token usage (EN) How to use Jev in an AI agent (EN) Input, output, cache, reasoning: what tokens cost (EN) Invoice reconciliation for AI spend (EN) IT Chargeback and Showback Explained (EN) IT Chargeback and Showback for AI: A Practical Guide (EN) IT Showback: A Practical Guide for Technology Teams (EN) KI-Anbieterpreise sind nicht direkt vergleichbar KI-Ausgaben außerhalb Ihrer API-Rechnung KI-Ausgabenabweichung: Volumen, Tarif, Mix und Effizienz KI-ROI nachweisen, ohne Qualitätsverluste zu verstecken Kosten eines Open-Weight-Modells Kosten je freigegebenem Asset bei Bild und Video Kosten pro erfolgreicher Aufgabe schlagen Kosten pro Anfrage Kostenkontrollen in die LLM-Evaluationspipeline einbauen Kostenmodell von Claude Fable 5.1 Kostenstruktur der OpenAI Fine-Tuning Sunset Latest AI models and Anthropic's proposed IPO (EN) Laufende Kosten von Embeddings und Vector Stores Leitfaden zu Kosten von Reasoning-Modellen Leitfaden zur Implementierung von Token-Budgets LLM Budget Governance: Alerts and Guardrails (EN) LLM Cost Benchmarks by Industry (EN) LLM cost dashboard: what to put on it (EN) LLM Cost Management: A Practical Framework (EN) LLM Cost Monitoring in Production: A Field Guide (EN) LLM cost monitoring: what to track and how to control it (EN) LLM Cost Per User Benchmarks (EN) LLM Cost Tracking: Tools, Tags and Telemetry (EN) LLM Cost Visibility: Dashboards and Metrics That Matter (EN) LLM FinOps standards (EN) LLM Provider Arbitrage: Price and Quality Parity (EN) LLM Purchasing Guide for Platform Teams (EN) LLM Token Tracking by Input, Output and Cache (EN) LLM Usage Metering: How to Bill Internal AI Spend (EN) LLM-API-Preisvergleich LLM-Ausgaben außerhalb der Produktion LLM-Ausgabenprüfung in 30 Minuten LLM-Chargeback und Showback LLM-Kostenattribution LLM-Kostenrechner: monatliche KI-Ausgaben schätzen LLM-Kostentrends 2025–2026 Long context vs RAG: where the cost breakeven actually is (EN) Minimax M3.1 Flash free preview economics (EN) Model deprecation migration: budgeting for forced moves (EN) Model Routing: Cheaper Models, Same Output Quality (EN) Modell-Preissenkungen und das Routing-Budget Multi-provider, multi-team LLM FinOps (EN) Multimodal cost allocation (EN) NVIDIA Open Agent Safety Platform: the FinOps implications (EN) On-prem and self-hosted LLM FinOps (EN) Open-Source vs Closed-Source LLM-Kostenvergleich OpenAI agent message board cost model (EN) OpenAI O / AON always-on agent cost model (EN) OpenAI Ultra Fast API pricing and speed tiers (EN) OpenAI-Kostenattribution OpenTelemetry GenAI conventions for cost attribution (EN) Opus 5.5 Anstrengungsstufen sind der echte Preis Opus 5.5 Fast-Mode Ökonomie Opus 5.5 long-running agent cost analysis (EN) Order of LLM cost optimizations (EN) Ox Alpha war GLM-5.3 Preiserhöhung für Claude Sonnet 5 abgesagt: $2/$10 bleibt Production-Runbook für einen LLM-Kostensprung Prompt cache attribution (EN) Prompt caching explained (EN) Prompt Caching ROI: Calculating Real Savings (EN) Provenienz zu KI-Ausgaben hinzufügen Rabatte für zugesagte Ausgaben RAG cost optimization (EN) Rate Limits, 429er und Tier-Upgrades Real-SWE cost per resolved issue (EN) Reasoning token attribution and chargeback (EN) Regionale Aufschläge und Datenresidenz SaaS-KI-Credits: eine Einheit messen, die Ihnen nicht gehört Semantic cache economics (EN) September 2026 AI model trends (EN) Server-Tools sind eine eigene Rechnung Showback vs Chargeback: Which Model Fits Your Team? (EN) Sieben Defensivmuster aus der DeepSeek-Harness-Dokumentation Silent model downgrades and cost models (EN) Six Jev use cases that actually fit (EN) So funktioniert das KI-Wasserzeichen State of FinOps 2026: 98% now manage AI spend (EN) Streaming-Antworten und abgebrochene Token Stückkosten von Realtime- und Audio-APIs Subagent-Fan-Out und unkontrollierte Rekursion im Keim ersticken System One Models and Jev cost optimization (EN) The Token Count Is Lying: Claude Max vs Qwen Audit (EN) The True Cost of Coding Agents: Beyond the API Bill (EN) Token budget implementation (EN) Token-Kosten von MCP-Tool-Definitionen in Agenten senken Tokenkosten von JSON-Modus und Schemas Tokenpreise fallen, LLM-Rechnung steigt Vergleich der KI-Codierungspläne Währungsrisiko bei LLM-Ausgaben Was Guardrails und Moderation kosten Was ist DeepSeek Harness? Ein Leitfaden Websuche wird zur Kostenstelle für Agenten Wenn KI-Observability zur zweiten Rechnung wird What independent Jev tests say about cost (EN) What is AI value management? (EN) What is LLM cost attribution? A plain-English explainer (EN) What is LLM FinOps? A plain-English definition (EN) What is the Tokenomics Foundation? (EN) Where Jev belongs in an agent workflow (EN) Why agentic AI blows the budget (EN) Why does my LLM bill spike? The most common causes (EN) Why Jev is catching on with agent builders (EN) Why Showback Comes Before Chargeback in FinOps (EN) Wie KI-Wasserzeichen zerstört werden Wie Prompt-Stil auf der Rechnung erscheint Wie viel kostet GPT-5? Vollständiger Preisleitfaden 2026 Wo Ausgaben-Leitplanken in DeepSeek Harness hingehören Möchten Sie dies auf Ihre eigenen LLM-Ausgaben anwenden? FinOps LLM führt ein kostenloses Audit Ihrer AI-Kosten durch und zeigt Ihnen, wo Einsparungen möglich sind. Kostenloses Audit anfordern → Zurück zu FinOps LLM --- # Adaptives Denken zerlegt Ihre Kostenprognose · FinOps LLM URL: https://finopsllm.com/de/research/adaptive-thinking-cost-forecast Adaptives Denken und Kostenprognose Aktualisiert September 1, 2026 · erstveröffentlicht September 1, 2026 Kurzantwort: Das Denkbudget war früher eine Zahl, die Sie gesetzt haben. Sie übergaben budget_tokens: N, und N war Steuerung und Prognose zugleich: schlimmstenfalls kostete jede Anfrage N Reasoning-Tokens.Dieser... Das Denkbudget war früher eine Zahl, die Sie gesetzt haben. Sie übergaben budget_tokens: N , und N war Steuerung und Prognose zugleich: schlimmstenfalls kostete jede Anfrage N Reasoning-Tokens. Dieser Parameter ist auf Opus 4.6 und Sonnet 4.6 abgekündigt, und auf den neuesten Modellen — Fable 5 und 5.1, Sonnet 5, Opus 5, 4.8 und 4.7 — führt er zu einem 400 . Ersatz ist thinking: {type: "adaptive"} : das Modell entscheidet nach Schwierigkeit, wie viel es denkt. Was sich in den Zahlen ändert Die mittleren Kosten je Anfrage sinken meist, weil einfache Anfragen kein unnötiges Reasoning mehr bezahlen. Die Varianz steigt , weil schwere Anfragen nicht mehr an Ihrer Obergrenze abgeschnitten werden. Ein Budget als Maximum je Anfrage hat keinen Anker mehr. Prognostizieren Sie die Verteilung Führen Sie Reasoning-Tokens als eigene Zeitreihe — sie stehen bereits im Usage-Objekt jeder Antwort. Budgetieren Sie über Perzentile: p50 und p99 je Route statt "N Tokens je Anfrage". Alarmieren Sie auf das Verhältnis, nicht die Summe: der Anteil der Reasoning-Tokens bewegt sich zuerst, wenn eine Prompt-Änderung das Modell härter arbeiten lässt. Wo eine Grenze weiterhin hingehört Ausgabelimits je Route und je Mandant funktionieren weiterhin und fangen Endlosschleifen ab. Dorthin gehört das Sicherheitsnetz: an die Grenze, die Ihnen gehört. Weiterführend Zuordnung von Reasoning-Tokens Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Provenienz für KI-Ausgaben an einem Tag · FinOps LLM URL: https://finopsllm.com/de/research/add-provenance-to-your-ai-output Provenienz zu KI-Ausgaben hinzufügen Aktualisiert September 1, 2026 · erstveröffentlicht September 1, 2026 Kurzantwort: Beginnen wir mit dem, was nicht geht. Das Textwasserzeichen setzt der Anbieter während der Generierung; es gibt keinen Parameter dafür, und nachträglich lässt es sich nicht anbringen. Wer ein... Beginnen wir mit dem, was nicht geht. Das Textwasserzeichen setzt der Anbieter während der Generierung; es gibt keinen Parameter dafür, und nachträglich lässt es sich nicht anbringen. Wer ein stärkeres Signal will, fügt kein Marking hinzu, sondern einen Nachweis. Dieser Nachweis ist günstig, vollständig in Ihrer Hand und genau das, was tatsächlich vorgelegt wird, wenn jemand die Herkunft einer Ausgabe belegt haben will. Die meisten Teams bauen ihn an einem Tag, denn er liegt einen Join von der Telemetrie entfernt, die ohnehin für die Kostenzuordnung erhoben wird. Die vier Felder Protokollieren Sie je erzeugtem Artefakt die exakte Modell-ID und Version , die Region , den Zeitstempel und eine stabile Artefakt-ID , die der Ausgabe durch die gesamte Pipeline folgt. Letztere lassen Teams weg und vermissen sie später. Wer bereits Nutzungsdatensätze pro Anfrage schreibt, hat drei der vier Felder. Es fehlt der Join: Die Kostentelemetrie kennt die Anfrage und ihren Preis, aber nicht das gespeicherte Artefakt, das dabei entstand. Bewahren Sie das signierte Manifest Wo der Anbieter eine C2PA-signierte Datei liefert, lautet das Ziel schlicht: nicht verlieren. Konfigurieren Sie Bildtransformationen ausdrücklich auf Metadatenerhalt, statt Standardwerten zu vertrauen, und hängen Sie die Provenienz nach jedem selbst kontrollierten Re-Encoding wieder an. Kennzeichnen Sie auch für Menschen Maschinenlesbares Marking und sichtbarer Hinweis lösen verschiedene Probleme. Ein sichtbares "mit KI erzeugt" kostet nichts, überlebt jede Transformation und ist das, was Nutzer tatsächlich lesen. Keines ersetzt das andere. Weiterführend Wie KI-Wasserzeichen zerstört werden Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Agentenökonomie: Was kostet ein Codieragent wirklich? · FinOps LLM URL: https://finopsllm.com/de/research/agent-economics Agentenökonomie: Wie viel kostet ein Codieragent wirklich? Codieragenten sind die am schnellsten wachsende Ausgabenkategorie für LLMs im Jahr 2026. Jedes Engineeringteam setzt bereits einen ein oder evaluiert einen. Doch die Preismodelle sind verwirrend: Abonnementpläne verstecken Token-Limits hinter der Formulierung „unbegrenzt", API-basierte Agenten zeigen rohe Kosten, die unvorhersehbar ansteigen, und keines der beiden Modelle sagt Ihnen, was Sie pro abgeschlossener Aufgabe tatsächlich zahlen. Dieser Artikel schlüsselt die reale Ökonomie der fünf beliebtesten Codieragenten auf, führt eine Metrik für „Kosten pro sinnvoller Aufgabe" ein und erklärt, warum API-basierte Agenten je nach Nutzungsmuster sowohl günstiger als auch teurer als Abonnementpläne sein können. Die Preislandschaft Codieragenten fallen in zwei Preiskategorien. Abonnementagenten berechnen eine feste monatliche Gebühr mit inbegriffener Nutzung. API-basierte Agenten berechnen pro verbrauchtem Token, normalerweise über Ihr eigenes Provider-Konto. Die richtige Wahl hängt davon ab, wie viele Aufgaben Sie ausführen, wie groß Ihre Codebasis ist und wie komplex Ihre Prompts werden. Agent Plan Monatliche Kosten Inbegriffene Tokens/Anfragen Geschätzte Aufgaben/Monat Kosten pro Aufgabe Hauptmodell Cursor Pro $20/Monat 500 schnelle Anfragen (Premium-Modelle) ~80–150 $0,13–$0,25 Claude Sonnet 4, GPT-4.1 GitHub Copilot Pro+ $39/Monat 1.500 Premium-Anfragen ~150–300 $0,13–$0,26 Claude Sonnet 4, GPT-4.1 GitHub Copilot Pro $10/Monat 300 Premium-Anfragen ~30–60 $0,17–$0,33 GPT-4.1, Claude Sonnet 4 Claude Code API (Max optional) $5–$100+ Zahlung pro Token über Anthropic API ~20–200+ $0,25–$2,00 Claude Sonnet 4 Cline API (BYOK) $5–$80+ Zahlung pro Token über jeden Provider ~20–200+ $0,20–$3,00 Benutzerkonfiguriert Windsurf Pro $15/Monat 500 Credits (Premium-Modelle) ~60–120 $0,13–$0,25 Claude Sonnet 4, GPT-4.1 Was „Kosten pro Aufgabe" wirklich bedeutet Die obige Tabelle zeigt die beworbene Spanne, aber die realen Kosten pro Aufgabe hängen von drei verborgenen Faktoren ab: Kontextfenster-Laden, Tool-Call-Ketten und Wiederholungsschleifen. Eine „einfache" Aufgabe wie das Hinzufügen eines neuen API-Endpunkts kann während der Sitzung 15.000–40.000 Tokens verbrauchen. Ein komplexes Refactoring, das mehrere Dateien berührt, kann leicht über 200.000 Tokens gehen. Das Kontextfenster-Laden ist der größte versteckte Kostenfaktor. Jeder Codieragent lädt Ihre offenen Dateien, die Projektstruktur und den aktuellen Gesprächsverlauf bei jedem API-Aufruf. Ein Projekt mit großen Dateien bedeutet mehr Tokens pro Anfrage – selbst wenn Sie eine einfache Frage stellen. Tool Calls multiplizieren dies: Jede Dateilese-, Such- oder Bearbeitungsoperation ist ein separater API-Roundtrip mit dem vollständigen Kontext. Versteckte Kosten, die die meisten Teams übersehen Wiederholungsschleifen. Wenn der erste Versuch eines Agenten Tests oder Linting fehlschlägt, versucht es automatisch erneut. Jeder Wiederholungsversuch ist ein vollpreisiger API-Aufruf. In der Praxis sind 20–40% der Agent-Sitzungen mit mindestens einem Wiederholungsversuch verbunden, was die Token-Kosten dieser Aufgabe um 30–80% erhöht. Kontextüberlauf. Lange Sitzungen erreichen Kontextgrenzen. Wenn dies geschieht, fasst der Agent entweder früheren Kontext zusammen (mit Detailverlust) oder löscht frühere Nachrichten (mit Kontextverlust). Beides führt zu minderwertiger Ausgabe und mehr Wiederholungsversuchen. Tool-Call-Overhead. Eine einzelne Aufgabe kann 5–15 Tool Calls beinhalten (Datei lesen, Code durchsuchen, Datei bearbeiten, Tests ausführen). Jeder Tool Call enthält den vollständigen Gesprächskontext plus die Tool-Definition. Nur die Tool-Definitionen können 2.000–5.000 Tokens des System-Prompts pro Call verbrauchen. Untätige Premium-Anfragen. Abonnementpläne zählen „schnelle Anfragen", selbst wenn der Agent unhilfreich ist. Ein abgelehnte Suggestion kostet immer noch eine Premium-Anfrage. API vs. Abonnement: Wann gewinnt jeder API-basierte Agenten (Claude Code, Cline) gewinnen, wenn Ihre Nutzung sporadisch oder leicht ist. Wenn Sie 20–40 fokussierte Aufgaben pro Monat ausführen, ist das Zahlen von $0,30–$0,80 pro Aufgabe günstiger als ein Abonnement für $20–$39. Sie gewinnen auch, wenn Sie ein bestimmtes Modell für eine bestimmte Aufgabe benötigen: Sie zahlen nur für das, was Sie verwenden. Abonnementagenten (Cursor, Copilot, Windsurf) gewinnen, wenn die Nutzung stetig und intensiv ist. Wenn Sie über 100 Aufgaben pro Monat ausführen, sinken die effektiven Kosten pro Aufgabe unter $0,20, was schwer zu erreichen ist mit API-Preisen. Sie gewinnen auch bei Vorhersehbarkeit: Finance-Teams können einen festen Betrag budgetieren. Der Umbruchpunkt liegt typischerweise bei 40–80 Aufgaben pro Monat für einen einzelnen Entwickler. Darunter ist API-Preisgestaltung günstiger. Darüber bieten Abonnementpläne bessere Ökonomie. Die Metrik „Kosten pro sinnvoller Aufgabe" Rohe Kosten pro Aufgabe sind irreführend, da nicht jede Aufgabe Wert produziert. Eine Agent-Sitzung, die fehlschlägt, eine falsche Antwort liefert oder manuelle Überarbeitung erfordert, hat reale Kosten von null sinnvollem Output. Die wichtigste Metrik ist: Kosten pro sinnvoller Aufgabe = Gesamtausgaben pro Monat / Aufgaben, die ohne manuelle Überarbeitung versendet wurden In der Praxis berichten Teams, dass 60–80% der Agent-Aufgaben beim ersten Versuch verwertbaren Output produzieren. Die restlichen 20–40% erfordern manuelle Eingriffe. Das bedeutet, dass die effektiven Kosten pro sinnvoller Aufgabe das 1,25–1,7-fache der rohen Kosten pro Aufgabe sind. Für Teams, die mit Open-Source-Modellen arbeiten oder kostengünstige Alternativen erkunden, bieten Plattformen wie MiMO wettbewerbsfähige Preisgestaltung, die die API-vs.-Abonnement-Berechnung verschieben kann. Wie Sie Agent-Kosten reduzieren Kontextfenster trimmen. Schließen Sie irrelevante Dateien, bevor Sie den Agent aufrufen. Kleinerer Kontext = weniger Tokens pro Call. Schreiben Sie spezifische Prompts. Vage Prompts führen zu mehr Tool Calls und Wiederholungsversuchen. „Fügen Sie einen POST-Endpunkt /users hinzu, der E-Mail validiert" kostet weniger als „reparieren Sie das Nutzer-Zeug." Verwenden Sie aufgabenspezifische Modelle. Einfache Bearbeitungen benötigen kein Reasoning-Modell. Leiten Sie Boilerplate zu günstigeren Modellen und komplexe Refactorings zu Premium-Modellen weiter. Überwachen Sie Token-Nutzung. Verfolgen Sie Token-Zählungen pro Sitzung. Wenn durchschnittliche Sitzungskosten steigen, können Ihre Prompts oder Codebasis schneller wachsen als erwartet. Setzen Sie Wiederholungsgrenzen. Begrenzen Sie automatische Wiederholungsversuche auf 2–3 pro Aufgabe. Darüber hinaus eskalieren Sie zu einem Menschen. Was Sie als nächstes erwartet Agent-Preise bewegen sich schnell. Abonnementpläne erhöhen die inbegriffenen Limits, während der Wettbewerb sich verschärft. API-Preise fallen weiterhin – Claude Sonnet 4 kostet 60% weniger als Claude 3.5 Sonnet bei seinem Start. Open-Source-Codiermodelle schließen die Qualitätslücke, was API-Preise noch weiter nach unten drücken wird. Der wichtigste Trend ist agent-spezifische Preisgestaltung. Provider experimentieren mit Pay-per-Task-Preisgestaltung, Pro-Sitzung-Caps und qualitätsgewichteter Abrechnung. Bis Ende 2026 erwarten Sie, dass die meisten Agenten eine „Kosten pro erfolgreiche Aufgabe"-Garantie anbieten statt rohe Token-Abrechnung. Verwandt Vergleich von KI-Codierungsplänen - evidenzbasierte Benchmark von Codierungsplänen. Agent-Ausgabenattribution - wie Sie Agent-Kosten nach Projekt und Team verfolgen. Agent-Ausgabenschutzvorrichtungen - Limits setzen, bevor Kosten außer Kontrolle geraten. FinOps für LLM - das umfassendere Framework. Möchten Sie dies auf Ihre eigenen LLM-Ausgaben anwenden? FinOps LLM führt ein kostenloses Audit Ihrer KI-Kosten durch und zeigt, wo die Einsparungen liegen. Fordern Sie Ihr kostenloses Audit an → Zurück zur Forschung --- # Websuche wird zur Kostenstelle für Agenten · FinOps LLM URL: https://finopsllm.com/de/research/agent-web-search-cost-center Websuche wird zur Kostenstelle für Agenten Aktualisiert September 10, 2026 · erstveröffentlicht September 10, 2026 Kurzantwort: Autonome Agenten verlassen sich zunehmend auf Live-Websuchen statt auf statisches Wissen. Eine Nutzeranfrage kann dutzende Abfragen, Modellinterpretationen und Tool-Retries auslösen. Websuche ist kein... Autonome Agenten verlassen sich zunehmend auf Live-Websuchen statt auf statisches Wissen. Eine Nutzeranfrage kann dutzende Abfragen, Modellinterpretationen und Tool-Retries auslösen. Websuche ist kein unsichtbarer Infrastrukturdienst mehr, sondern eine separat abgerechnete Kostenposition. Abfrage-Verstärkung durch Planung Ein Agent formuliert Fragen um, prüft mehrere Quellen und sucht bei Widersprüchen erneut. Ohne Tool-Kosten-Tracking sieht das Produktteam nur eine Anfrage, während der Cloud-Provider hunderte bezahlte API-Calls verbucht. FinOps-Kontrollen für Websuche Suchbudgets pro Task und Nutzertarif hart deckeln. Stabile Abfragen cachen und Normalisierung einsetzen. Abbruch nach Erreichen der Evidenzschwelle erzwingen. Kosten je erfolgreicher Aufgabe statt reiner Tokenpreise ausweisen. Weiterführend MCP-Tool-Definitionen und Overhead Kosten je erfolgreicher Aufgabe Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Die Bruttomarge eines KI-Features vor dem Launch messen · FinOps LLM URL: https://finopsllm.com/de/research/ai-feature-gross-margin Die Bruttomarge eines KI-Features vor dem Launch messen Aktualisiert September 2, 2026 · erstveröffentlicht September 2, 2026 Kurzantwort: Inferenz ist ein Servicekosten-Block, kein Entwicklungsaufwand. Sie läuft bei jeder Kundenaktion und wächst mit der Nutzung. Wer sie bis zum Launch als F&E führt, erfährt die echte Marge erst mit... Inferenz ist ein Servicekosten-Block, kein Entwicklungsaufwand. Sie läuft bei jeder Kundenaktion und wächst mit der Nutzung. Wer sie bis zum Launch als F&E führt, erfährt die echte Marge erst mit der ersten vollen Rechnung. Vor dem Launch instrumentieren Markieren Sie in Staging jeden Modellaufruf nach Konto, Workflow und Ergebnis und spielen Sie realistischen Traffic ein. Gebraucht wird eine Verteilung: Kosten je erfolgreicher Aufgabe bei p50, p90 und p99, plus der bezahlte Anteil für Fehlläufe und Retries. Kosten je Konto Kosten je erfolgreicher Aufgabe mal erwartete Monatsaufgaben, plus Fehlläufe. Vergleichen Sie mit dem Planpreis bei Median, 90. Perzentil und dem schwersten noch akzeptablen Konto. Vier Kostentreiber Kontext in jedem Turn erneut berechnet, voll berechnete Retries, agentische Vervielfachung einer Aktion, und Routing, das einfache Fälle an ein teures Modell schickt. An eine Entscheidung koppeln Nutzungsobergrenze, Verbrauchskomponente im Preis, günstigeres Standardmodell oder bewusst akzeptierte Marge mit Review-Termin. Als eigene Zeile der Bruttomarge berichten. Weiterführend Kosten je erfolgreicher Aufgabe Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # AI FinOps: das Betriebsmodell für GenAI-Ausgaben · FinOps LLM URL: https://finopsllm.com/de/research/ai-finops AI FinOps für Teams in der Produktion AI FinOps ist das operative Modell um AI-Ausgaben zu verwalten, sobald Modelle Teil des Produkts werden. Es ist nicht nur Observability, es ist auch nicht nur Verträge. Es ist ein Zyklus zwischen Technik, Produkt und Finanzen: verstehen wohin die Ausgaben gehen, Verantwortung zuweisen, die Unit-Ökonomie verbessern und Änderungen gegen die Rechnung validieren. LLM-Workloads machen dies dringend, weil Ausgaben mit Nutzung, Kontextlänge, Ausgabelänge, Wiederholungen und Modellwahl skalieren. Eine kleine Produktänderung kann die Rechnung ändern ohne die Infrastruktur zu ändern. Die besten AI-FinOps-Programme leben daher in der Nähe des Modell-Gateways und des Produkt-Analytics-Stacks. Was AI FinOps braucht Normalisierung von Anbieterrechnungen. Anfrage-Ebenen-Metadaten und Produkteigentum. Kosten-pro-erfolgreiche-Aufgabe-Metriken. Budgets, die vor Monatsende warnen. Optimierungsleitfäden für Routing, Cache, Batching und Prompt-Struktur. Wo Teams beginnen Beginnen Sie mit Sichtbarkeit und Showback. Zeigen Sie jedem Produktteam seine LLM-Ausgaben, die Endpoints die sie antreiben und Änderungen Monat für Monat. Dann wählen Sie den größten steuerbaren Faktor. Bei den meisten Teams ist dies Modell-Routing, Kontext-Komprimierung, Prompt-Cache, semantischer Cache oder das Verschieben nicht-dringender Arbeiten zu Batch-APIs. AI FinOps wird reif, wenn es Teil der Launch-Review ist: jede modell-bezogene Änderung hat ein Qualitätsziel, ein Latenz-Ziel, einen Ausgabenauswirkung und einen Rollback-Plan. Verwandt Was ist LLM FinOps? - die operative Disziplin, die LLM-Ausgaben verwaltet. FinOps für LLM - das operative Modell im Detail. LLM-Kostenattribution - wie Attribution funktioniert. LLM-Budgetverwaltung - Budgets und Degradations-Pfade. Wer ist für AI FinOps verantwortlich? Das Team, das die Ausgaben tatsächlich verändern kann — also das Engineering-Team, dem der Endpoint gehört, nicht die Finanzabteilung und nicht eine zentrale Plattformgruppe. Finance steckt den Rahmen ab und stimmt ihn mit der Rechnung ab; das verantwortliche Team wählt Modell, Kontextlänge und Retry-Policy. Ein Budget, das jemandem zugewiesen wird, der die Zahl nicht bewegen kann, erzeugt Eskalationen statt Einsparungen. Wie unterscheidet sich AI FinOps von Cloud FinOps? Drei Unterschiede sind praktisch relevant. Erstens ändert sich der Preis pro Einheit häufig: Anbieter senken Preise, führen neue Modellstufen ein und ändern Rabatte innerhalb eines Quartals — eine Cloud-Reserved-Instance-Logik gibt es hier nicht. Zweitens liegt der größte Hebel im Produktcode, nicht in der Infrastruktur; eine Prompt-Änderung verschiebt die Rechnung stärker als jede Instanzgröße. Drittens ist Qualität eine harte Nebenbedingung: eine Einsparung, die die Antwortqualität senkt, ist keine Einsparung, sondern eine verdeckte Produktverschlechterung. Womit sollte man in den ersten 90 Tagen anfangen? Wochen 1-4: Rechnung abgleichen, die fünf teuersten Endpoints kennzeichnen und Qualitätsbaselines festlegen. Wochen 5-8: Prompt-Caching aktivieren und asynchrone Arbeit in Batch-Lanes verschieben — beides ist reversibel und benötigt keine Qualitätstests. Wochen 9-12: Modell-Routing auf einem Endpoint A/B-testen. Wer mit Routing beginnt, bevor die Baseline steht, kann hinterher nicht belegen, ob die Einsparung Qualität gekostet hat. Möchten Sie dies auf Ihre eigenen LLM-Ausgaben anwenden? FinOps LLM führt ein kostenloses Audit Ihrer AI-Kosten durch und zeigt Ihnen, wo Einsparungen möglich sind. Kostenloses Audit anfordern → Zurück zur Forschung --- # KI-Ausgabenabweichung: Volumen, Tarif, Mix und Effizienz · FinOps LLM URL: https://finopsllm.com/de/research/ai-spend-variance-bridge KI-Ausgabenabweichung: Volumen, Tarif, Mix und Effizienz Aktualisiert August 27, 2026 · erstveröffentlicht August 27, 2026 Kurzantwort: Teilen Sie die Abweichung von Plan zu Ist in Volumen, Tarif, Mix und Effizienz und verbinden Sie jede Zeile mit Rechnung und Besitzer.Die vier UrsachenVolumen ist Nachfrage, Tarif der tatsächlich... Teilen Sie die Abweichung von Plan zu Ist in Volumen , Tarif , Mix und Effizienz und verbinden Sie jede Zeile mit Rechnung und Besitzer. Die vier Ursachen Volumen ist Nachfrage, Tarif der tatsächlich berechnete Preis, Mix die Verschiebung von Modell oder Workload, Effizienz die Kosten je nützlichem Ergebnis inklusive Retries und Nacharbeit. Die Brücke Starten Sie beim Plan, wenden Sie Tarif, Volumen, Mix und Effizienz an und gleichen Sie die Summe mit Rechnungen ab. Jede Zeile braucht Beleg, Dollarwirkung, Besitzer und Aktion. Qualität verhindert Scheineinsparungen. Weiterführend LLM-Kostenüberwachung Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # KI-Wasserzeichen sind jetzt ein Kostenposten · FinOps LLM URL: https://finopsllm.com/de/research/ai-watermarking-compliance-cost Compliance-Kosten von KI-Wasserzeichen Aktualisiert September 1, 2026 · erstveröffentlicht September 1, 2026 Kurzantwort: Anthropic bettet ein nicht wahrnehmbares Wasserzeichen in den Text unterstützter Claude-Modelle ein und signiert erzeugte .svg-, .png- und .jpg-Dateien mit C2PA-Provenienzmetadaten. Das Verfahren... Anthropic bettet ein nicht wahrnehmbares Wasserzeichen in den Text unterstützter Claude-Modelle ein und signiert erzeugte .svg -, .png - und .jpg -Dateien mit C2PA-Provenienzmetadaten. Das Verfahren folgt dem Ansatz SynthID-Text: Es verzerrt den Zufall bei der Token-Auswahl, ohne Bedeutung oder Qualität zu verändern. Am 1. September 2026 wurde eine Erkennungs-API für Regulierer, Medien, Faktenprüfer, Forschende und Unternehmen mit eigenen Prüfpflichten geöffnet. Die Kennzeichnung erfolgt weltweit, nicht nur in der EU. Auslöser ist Artikel 50 der KI-Verordnung, dessen Transparenzpflichten seit dem 2. August 2026 gelten. Berechnet wird dafür nichts — und genau deshalb fällt der Posten in der Budgetprüfung durch: Die Kosten sind real, sie stehen nur nicht auf der Rechnung. Wohin das Geld tatsächlich fließt Migration von Modellen, die auf nicht gekennzeichnete Versionen festgelegt sind; Anpassung von Bildpipelines, die Metadaten entfernen; das Zugangsverfahren zur Erkennung; und die Aufbewahrung von Modell-ID, Version, Region und Zeitstempel je Aufruf. Vier reale Kosten, kein einziger Tarif. Die Falle der fixierten Version Eine exakt fixierte Version ist gute Praxis, doch eine Version von vor August 2026 trägt möglicherweise keine maschinenlesbare Kennzeichnung. Wer EU-Nutzer bedient, verwandelt damit eine Stabilitätsentscheidung in eine Compliance-Lücke; das Gegenmittel ist eine ungeplante Migration mit Neubewertung, Prompt-Anpassung, Tests und neuem Preis. Inventarisieren Sie jede Fixierung und versehen Sie sie mit einem Prüfdatum. Ihre Bildpipeline löscht den Nachweis C2PA-Metadaten stecken in der Datei. Thumbnailer, CDN-Transformationen und Formatkonverter verwerfen sie standardmäßig, um Bytes zu sparen. Testen Sie die gesamte Kette von der Erzeugung bis zur Auslieferung — jetzt günstig, im Audit teuer. Weiterführend Kosten von Modellabkündigung und Migration Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # AI-Kostenanomalien-Erkennung · FinOps LLM URL: https://finopsllm.com/de/research/anomaly-detection AI-Kostenanomalien-Erkennung AI-Kostenanomalien sind oft unsichtbar bis die Rechnung kommt weil Ausgaben steigen können ohne dass das Request-Volumen steigt. Ein Deployment kann abgerufenen Kontext hinzufügen, einen Routing-Schwellwert ändern, Cache-Hits reduzieren, Wiederholungen aktivieren oder Traffic zu einem teureren Modell verschieben. Traditionelle Traffic-Alerts erkennen diese Änderungen nicht. Ein sinnvoller Anomalie-Detektor überwacht Kostenfaktoren, nicht nur Gesamtkosten. Die täglichen Gesamtausgaben sind ein verzögerter Indikator. Die ersten Signale sind Tokens pro Request, Modellmix, Abruf-Rate, Cache-Hit-Rate, Batch-Quote und Ausgaben nach Produktoberfläche. Zu überwachende Signale Ausgaben pro Endpoint, Team und Kunde pro Stunde. Eingabe- und Ausgabe-Tokens pro Request bei p50, p90 und p99. Wiederholungs-Rate, Abruf-Rate und Anbieter-Fehlerrate. Cache-Hit-Rate und Quote von Cache-gelesenen Tokens. Modellmix-Änderungen nach Deployments oder Prompt-Launches. Verarbeitbare Arbeit die versehentlich synchron läuft. Baselines Verwenden Sie mehrere Baselines. Ein Support-Bot hat täglich und wöchentliche Zyklen. Ein nächtlicher Anreicherungsjob hat ein Batch-Fenster. Eine Evaluation-Suite hat Spitzen um Launches. Ein einzelner globaler Schwellwert wird zu unempfindlich oder weckt die Leute ständig auf. Die beste Baseline ist nach Eigentümer und Workload-Klasse. Warnung wenn eine Feature von ihrem normalen Muster abweicht, nicht wenn die gesamte Firma einen generischen Ausgabenlimit kreuzt. Handlungsfähige Alerts Ein Alert sollte den Faktor erklären: "Eingabe-Tokens p90 verdoppelten sich am Endpoint X nach Deployment Y", "Cache-Hit-Rate fiel von 74% auf 18%", oder "Abruf zum Grenzmodell stieg um 31%". Wenn der Alert keinen wahrscheinlichen Eigentümer und Faktor nennen kann, wird er ignoriert. Antwort-Schleife Hängen Sie Deployment-Kontext, Routing-Richtlinien Diffs und die am meisten betroffenen Kunden oder Workloads an. Bieten Sie dann den nächsten Schritt an: Prompt zurückfahren, Abruf-Zählung reduzieren, Routing-Schwellwert wiederherstellen, Abruf deaktivieren oder Arbeit zu Batch verschieben. Anomalieerkennung ist nur wertvoll wenn sie die Zeit von der Rechnungs-Überraschung zu technischer Aktion verkürzt. Verwandt LLM-Kostenüberwachung - Dashboards und Observability für Ausgaben. AI-Observability - Kosten-Signale und operative Metriken. Warum LLM-Rechnungen steigen - Grundursachen für Kosten-Anstieg. Möchten Sie dies auf Ihre eigenen AI-Ausgaben anwenden? FinOps LLM führt ein kostenloses Audit Ihrer AI-Kosten durch und zeigt Ihnen, wo Einsparungen möglich sind. Kostenloses Audit anfordern → Zurück zur Forschung --- # Azure OpenAI vs. Direkt OpenAI Kostenvergleich · FinOps LLM URL: https://finopsllm.com/de/research/azure-openai-vs-direct-cost Azure OpenAI vs. Direkt OpenAI: Kosten, PTU & Einsparungen Aktualisiert September 19, 2026 · erstveröffentlicht July 12, 2026 Kurzantwort: Auf Standard-Pay-as-you-go-Basis kosten Azure OpenAI und die direkte OpenAI API bei globalen Bereitstellungen identisch: beispielsweise $2,50 pro Million Input-Token und $15 pro Million Output-Token... Auf Standard-Pay-as-you-go-Basis kosten Azure OpenAI und die direkte OpenAI API bei globalen Bereitstellungen identisch: beispielsweise $2,50 pro Million Input-Token und $15 pro Million Output-Token für Spitzenmodelle. Der wirtschaftliche Unterschied liegt nicht im Listenpreis für Standardaufrufe, sondern in drei strukturellen Hebeln: Provisioned Throughput Units (PTU) , regionalen Datenzonenaufschlägen und Unternehmensrabatten über das Microsoft Enterprise Agreement (EA) . 1. Provisioned Throughput (PTU) vs. Token-Abrechnung Azure bietet dedizierte Modellkapazität über PTUs. Auf Abruf kostet eine PTU $2 pro Stunde. Mit einer 1-monatigen Reservierung sinkt dieser Betrag auf etwa $260 pro PTU und Monat — ein Rabatt von bis zu 82 % gegenüber dem Stundensatz (bei 1-Jahres-Verpflichtungen bis zu 85 %). Die Break-even-Schwelle für eine PTU-Reservierung liegt typischerweise bei einer durchschnittlichen Auslastung von über 65–75 % . Liegt Ihr Workload darunter oder ist er stark schwankend, ist die tokenbasierte Abrechnung günstiger. 2. Regionale Preisaufschläge Globale Azure-Bereitstellungen spiegeln die US-Preise von OpenAI wider. Regionale Bereitstellungen (z. B. ausschließlich in Westeuropa oder geschützten Souveränitätszonen) erheben jedoch einen Aufschlag von 10 % bis 20 % . Unternehmen, die Datenresidenz in der EU verlangen, müssen diesen Aufpreis in ihren FinOps-Modellen berücksichtigen. 3. Versteckte Infrastrukturkosten Bei Azure OpenAI fallen zusätzliche Komponenten an: Private Endpoints, Azure Monitor-Protokollierung, Virtual Network Egress und API Management Gateway-Gebühren. Diese können die effektiven Kosten pro Million Token um 4 % bis 8 % erhöhen, bieten jedoch enterprise-taugliche Sicherheit und RBAC-Zugriffssteuerung. Weiterführend Rabatte für zugesagte Ausgaben Warum Providerpreise schwer vergleichbar sind Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Hintergrund-Agenten verändern die FinOps-Uhr · FinOps LLM URL: https://finopsllm.com/de/research/background-agents-cost-clock Hintergrund-Agenten verändern die FinOps-Uhr Aktualisiert September 10, 2026 · erstveröffentlicht September 10, 2026 Kurzantwort: Hintergrundausführung entkoppelt Agentenkosten von der Anwesenheit des Nutzers. Nach dem Schließen des Browsers können Agenten stundenlang Tools aufrufen, Zwischenschritte wiederholen und Tokens... Hintergrundausführung entkoppelt Agentenkosten von der Anwesenheit des Nutzers. Nach dem Schließen des Browsers können Agenten stundenlang Tools aufrufen, Zwischenschritte wiederholen und Tokens verbrauchen. Das erfordert ein völlig neues FinOps-Zeitmodell. Aufgabenbudget statt Sitzungsbudget Ein interaktives Sitzungslimit greift hier nicht mehr. Jede asynchrone Aufgabe benötigt ein eigenes Dollar- und Schrittlimit sowie Checkpoints für fehlerfreie Wiederaufnahme. Weiterführend Drei Budgets für jeden Agenten Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Caching-Strategien im Vergleich · FinOps LLM URL: https://finopsllm.com/de/research/caching-strategies-compared Caching-Strategien im Vergleich Caching ist eine der wirkungsvollsten Taktiken zur Kostenreduktion bei LLM-Workloads. Die Idee ist einfach: Zahlen Sie nicht für Inferenz, wenn Sie ein gecachtes Ergebnis zurückgeben können. Aber "Caching" ist nicht eine einzige Technik - es sind vier unterschiedliche Strategien mit verschiedenen Kompromissen bei Kostenersparnissen, Latenz, Genauigkeit und Implementierungskomplexität. Die falsche Wahl zu treffen verschwendet Ingenieuraufwand; die richtige Wahl kann 30–70% Ihrer Rechnung einsparen. Strategievergleich Strategie Funktionsweise Kostenersparnis Auswirkung auf Latenz Implementierungsaufwand Ideal für Anbieter Prompt-Cache (Provider-seitig) Der Anbieter speichert die KV-Berechnung für wiederholte Prompt-Präfixe. Nachfolgende Anforderungen mit demselben Präfix überspringen die Neuverarbeitung. 50% bei gecachten Input-Tokens 60–80% schnellere First-Token-Latenz Null bis niedrig - automatisch bei den meisten Anbietern Lange System-Prompts, RAG mit gemeinsamen Kontext, Agent-Schleifen OpenAI, Anthropic, Google Semantischer Cache (Embedding-basiert) Embeddings der Benutzerabfrage generieren, einen Vektor-Store nach ähnlichen früheren Abfragen durchsuchen. Wenn die Ähnlichkeit einen Schwellenwert überschreitet, die gecachte Antwort zurückgeben, ohne das LLM aufzurufen. 20–50% je nach Abfrage-Wiederholung 50–90% schneller (kein LLM-Aufruf) Mittel - benötigt Embedding-Modell, Vektor-Store, Anpassung des Ähnlichkeitsschwellenwerts FAQ-Bots, Kundenbetreuung, wiederholte Abfragen Beliebig (selbst-gehostet via GPTCache, Redis mit Vektorsuche) Context-Caching (Google-Stil) Große Kontextdokumente (PDFs, Code-Repositories) serverseitig cachen. Zahlen Sie einmal für die Kontextverarbeitung, verwenden Sie das Ergebnis über viele Abfragen mit reduzierter pro-Abfrage-Kosten. 70–90% bei kontextintensiven Abfragen Moderate Verbesserung bei Kontextverarbeitung Niedrig bis mittel - Kontext hochladen, TTL verwalten Dokument-Q&A, Code-Review über große Repositories, Multi-Turn mit statischem Kontext Google (Gemini), Anthropic (erweiterter Thinking-Kontext) Application-Level-Cache (Redis/CDN) Deterministischer Hash der vollständigen Anforderung (Prompt + Parameter). Speichern Sie die Antwort in Redis oder einem CDN. Geben Sie die gecachte Antwort bei exakter Übereinstimmung zurück. Bis zu 100% bei Cache-Treffern 90–99% schneller (kein LLM-Aufruf) Niedrig - Standard-Caching-Infrastruktur Deterministische Abfragen, Klassifikation, Extraktion mit festen Prompts Beliebig (Infrastruktur, die Sie kontrollieren) Prompt-Caching im Detail Prompt-Caching ist der einfachste Gewinn. OpenAI speichert automatisch Prompts länger als 1.024 Tokens. Anthropic speichert Präfixe von 2.048+ Tokens. Der Cache wird über den exakten Präfix indiziert - gleicher System-Prompt, gleiche Few-Shot-Beispiele, gleicher Dokument-Kontext. Wenn ein Cache-Treffer auftritt, zahlen Sie 50% weniger für den gecachten Teil der Input-Tokens. Der Haken: Cache-Invalidierung wird vom Anbieter kontrolliert. Wenn sich der Prompt auch nur leicht ändert - eine andere System-Nachricht, eine andere Variable im Präfix - der Cache schlägt fehl. Gestalten Sie Ihre Prompts so, dass Sie stabilen Inhalt am Anfang platzieren und dynamischen Inhalt zum Ende des Prompts verschieben. Semantisches Caching im Detail Semantisches Caching überspringt das LLM vollständig, wenn eine ähnliche Frage bereits gestellt wurde. Der Ablauf: Embeddings der Abfrage generieren, einen Vektor-Store durchsuchen (Pinecone, Qdrant, Redis mit Vektorsuche), prüfen, ob das beste Ergebnis einen Ähnlichkeitsschwellenwert überschreitet (typischerweise 0,92–0,97), und die gecachte Antwort zurückgeben, wenn dies der Fall ist. Das Risiko besteht darin, veraltete oder leicht fehlerhafte Antworten zurückzugeben. Ein Schwellenwert, der zu niedrig ist, gibt falsche Ergebnisse zurück; einer, der zu hoch ist, bedeutet fast keine Cache-Treffer. Passen Sie ihn pro Anwendungsfall an. Für sachliche FAQ-Abfrage ist 0,95+ sicher. Für kreative Generierung ist semantisches Caching selten angebracht - der ganze Punkt ist Neuheit. Context-Caching im Detail Google's Context-Caching ermöglicht es Ihnen, ein großes Dokument einmal hochzuladen und eine reduzierte Rate für nachfolgende Abfragen daran zu zahlen. Dies ist leistungsstark für Dokument-Q&A, bei der Sie die gleiche 200-seitige PDF hunderte Male verarbeiten. Das Kostenmodell: Zahlen Sie die vollständige Input-Token-Rate einmal für den Cache-Schreibvorgang, dann eine reduzierte Rate (oft 25% der normalen Rate) für jeden Cache-Lesevorgang. Der Kompromiss ist die TTL. Gecachte Kontexte verfallen. Wenn Ihre Workload bursty Zugriffsmuster hat - 500 Abfragen in einer Stunde, dann nichts für eine Woche - der Cache kann zwischen Bursts ablaufen. Passen Sie Ihre TTL an Ihr Zugriffsmuster an. Application-Level-Caching im Detail Deterministisches Caching ist die aggressivste Strategie. Hashen Sie die vollständige Request-Payload (Prompt, Temperatur, maximale Tokens, Modell, Tools) und speichern Sie die Antwort. Bei exakter Übereinstimmung geben Sie die gecachte Antwort sofort zurück - kein LLM-Aufruf, keine Latenz, keine Kosten. Dies funktioniert nur, wenn die gleiche Eingabe immer die gleiche Ausgabe produzieren sollte. Klassifikation, Entitätsextraktion, Analyse strukturierter Daten und Template-basierte Generierung sind gute Kandidaten. Konversationsaufgaben oder kreative Aufgaben sind es nicht - Benutzer erwarten unterschiedliche Antworten. Strategien kombinieren Die besten Implementierungen layern mehrere Strategien. Ein typischer Stack: Application-Level-Cache als erste Prüfung (billigste, schnellste), semantischer Cache als zweite Prüfung (erfasst Near-Duplicates), dann der LLM-Aufruf mit Provider-seitigem Prompt-Caching aktiviert (reduziert Kosten auch bei Cache-Misses). Dieser gelagerte Ansatz kann die Gesamtausgaben für LLM um 40–70% bei Workloads mit jeglichem Wiederholungsgrad reduzieren. Verfolgen Sie Cache-Hit-Raten separat für jede Schicht. Wenn Ihre semantische Cache-Hit-Rate unter 10% fällt, lohnt sich der Vektor-Store-Overhead möglicherweise nicht. Wenn Ihre Application-Cache-Hit-Rate über 40% liegt, haben Sie wahrscheinlich deterministische Aufgaben, die auf der Prompt-Ebene optimiert werden sollten. Verwandtes Prompt-Caching erklärt - tiefere Analyse des Provider-seitigen Cachings. Ökonomie des semantischen Cachings - ROI-Analyse des semantischen Cachings. Optimierung der KI-Kosten - umfassendere Optimierungsstrategien. Möchten Sie das auf Ihre eigenen LLM-Ausgaben angewendet haben? FinOps LLM führt eine kostenlose Prüfung Ihrer KI-Kosten durch und zeigt, wo die Ersparnisse liegen. Kostenlose Prüfung buchen → Zurück zur Forschung --- # Günstigste KI-Code-Generierung (2026) · FinOps LLM URL: https://finopsllm.com/de/research/cheapest-ai-code-generation Die günstigste Methode zur Ausführung von KI-Code-Generierung KI-Code-Generierungs-Tools haben sich vielfältig entwickelt – aber der Kostenunterschied zwischen den Optionen ist enorm. Ein leichter Benutzer könnte $10/Monat mit einem Ansatz ausgeben und $200/Monat mit einem anderen für fast identische Ergebnisse. Diese Anleitung vergleicht jede Kategorie von KI-Code-Generierungswerkzeugen, berechnet die tatsächlichen monatlichen Kosten für verschiedene Nutzungsstufen und gibt Ihnen einen Entscheidungsbaum, um die günstigste Option auszuwählen, die tatsächlich für Ihren Arbeitsablauf funktioniert. Die vier Kategorien Jedes KI-Code-Generierungswerkzeug fällt in eines von vier Preismodellen: Abonnement-Agenten - feste monatliche Gebühr, Nutzung enthalten (Cursor, Copilot, Windsurf, Cody). API-basierte Agenten - Sie bringen Ihren eigenen API-Schlüssel mit, zahlen pro Token (Claude Code, Cline, Aider, Continue mit Cloud-APIs). Selbst gehostete Modelle - führen Sie Open-Weight-Modelle lokal oder auf Ihrer eigenen GPU aus (Continue + Qwen, CodeLlama, DeepSeek Coder). Coding-Plan-Anbieter - API-Zugang zum Pauschalpreis optimiert für Coding-Workloads ( MiMO , GLM, MiniMax, KwaiKAT). Kostenvergleichstabelle Option Monatliche Kosten (Leicht) Monatliche Kosten (Intensiv) Modellqualität Aufwand für Konfiguration GitHub Copilot Free $0 $0 Gut Keine GitHub Copilot Pro $10 $10 Sehr gut Keine Cursor Pro $20 $20 Ausgezeichnet Niedrig Windsurf Pro $15 $15 Sehr gut Niedrig Claude Code (API) $5–15 $50–200 Ausgezeichnet Mittel Cline + API-Schlüssel $5–20 $40–150 Ausgezeichnet Mittel MiMO Coding-Plan $10–15 $30–60 Sehr gut Niedrig GLM Coding-Plan $10–15 $30–60 Gut Niedrig Continue + lokales Modell $0 $0 Annehmbar Hoch Leichter Benutzer: ~2 Stunden/Tag, ~50 Anfragen/Tag. Intensiver Benutzer: 8+ Stunden/Tag, ~300 Anfragen/Tag. API-Kosten gehen von durchschnittlich 3K Input + 1K Output Tokens pro Anfrage mit Claude Sonnet oder GPT-4o Preisen aus. Aufschlüsselung nach Kategorie 1. Abonnement-Agenten Dies sind die am einfachsten zu verwenden. Sie zahlen eine Pauschalgebühr und erhalten ein großzügiges (oder unbegrenztes) Nutzungskontingent. Der Haken: Sie sind an ihre Modellauswahl und IDE-Integration gebunden. Cursor Pro ($20/Monat) - Beste Gesamtbenutzerfreundlichkeit für Power-User. Beinhaltet schnelle Anfragen (GPT-4o, Claude Sonnet) und langsame Anfragen (Frontier-Modelle). Das Limit von 500 schnellen Anfragen pro Monat reicht für die meisten Entwickler aus. GitHub Copilot ($10/Monat) - Günstigste Mainstream-Option. Tab-Vervollständigungen sind ausgezeichnet; Chat ist gut, aber weniger leistungsfähig als der Agenturmodus von Cursor. Kostenloser Tarif mit Einschränkungen verfügbar. Windsurf Pro ($15/Monat) - Konkurrenzfähiges Mittelfeld. Gute Agentur-Features zu einem niedrigeren Preis als Cursor. Urteil: Beste für Entwickler, die Null-Setup und vorhersehbare Abrechnung wünschen. Copilot Free ist unschlagbar für Benutzer mit kleinerem Budget. 2. API-basierte Agenten Sie bringen Ihren eigenen API-Schlüssel mit (OpenAI, Anthropic usw.) und das Tool macht API-Aufrufe in Ihrem Namen. Die Kosten skalieren linear mit der Nutzung - großartig für leichte Benutzer, teuer für intensive Benutzer. Claude Code - Anthropic's CLI-Agent. Verwendet Claude Sonnet oder Opus. Eine intensive Sitzung kann $2–5 an API-Gebühren kosten. Cline (VS Code) - Open-Source-Agent, der mit jeder API funktioniert. Sehr flexibel, aber die Kosten sind ohne Budgetgrenzen unvorhersehbar. Aider - Terminal-basiert, funktioniert mit jedem Modell. Beliebt für seine Git-Integration und seinen Edit-Mode-Ansatz. Urteil: Beste für Entwickler, die Modellflexibilität wünschen und die Nutzung überwachen möchten. Leichte Benutzer zahlen weniger als Abonnements; intensive Benutzer zahlen mehr. 3. Selbst gehostete Modelle Führen Sie Open-Weight-Modelle (Qwen 2.5 Coder, DeepSeek Coder V2, CodeLlama) lokal über Ollama, vLLM oder llama.cpp aus. Null Grenzkosten pro Anfrage - aber Sie benötigen Hardware. Vorteile: Keine Pro-Token-Kosten, vollständige Datenschutz, keine Ratenlimits, funktioniert offline. Nachteile: Qualitätslücke gegenüber Frontier-Modellen (besonders für komplexes Refactoring), erfordert eine leistungsfähige GPU (16GB+ VRAM für gute Ergebnisse), Konfigurationsaufwand. Urteil: Beste für datenschutzsensitive Arbeiten, Offline-Umgebungen oder Teams mit bestehender GPU-Infrastruktur. Nicht empfohlen als Ihr einziges Modell - kombinieren Sie mit einem Cloud-Modell für schwierige Aufgaben. 4. Coding-Plan-Anbieter Eine neuere Kategorie: Anbieter, die API-Zugang zum Pauschalpreis oder mit starken Rabatten speziell für Coding-Agenten anbieten. Diese überbrücken die Lücke zwischen teurer API-Preisgestaltung pro Token und starren Abonnement-Tools. MiMO Coding-Plan - Wettbewerbsfähige Preise mit starken Reasoning-Fähigkeiten. Gute Balance zwischen Kosten und Qualität. GLM (Zhipu) - Chinesischer Anbieter mit aggressiven Preisen für Coding-Workloads. MiniMax / KwaiKAT - Aufstrebende Anbieter mit Coding-optimierten Preisstufen. Urteil: Beste für API-basierte Agentur-Benutzer, die Kosten senken möchten, ohne zu Self-Hosted zu wechseln. Die Qualität variiert - führen Sie Benchmarks bei Ihren tatsächlichen Aufgaben durch, bevor Sie sich festlegen. Entscheidungsbaum Folgen Sie diesem, um Ihre günstigste Option zu finden: Wenn Sie <2 Stunden/Tag programmieren: Nutzen Sie GitHub Copilot Free . Null Kosten, ausgezeichnete Vervollständigungen. Wenn Sie die Grenzen erreichen, aktualisieren Sie auf Copilot Pro ($10/Monat). Wenn Sie 2–6 Stunden/Tag programmieren: Nutzen Sie Cursor Pro ($20/Monat) oder Windsurf Pro ($15/Monat) . Die Pauschalgebühr ist günstiger als API-Kosten bei diesem Volumen. Alternativ nutzen Sie einen Coding-Plan-Anbieter wie MiMO mit Cline für $10–30/Monat. Wenn Sie 8+ Stunden/Tag programmieren: Nutzen Sie einen API-basierten Agenten mit einem Coding-Plan (MiMO, GLM) bei $30–60/Monat. Standard-API-Schlüssel (Claude, GPT-4o) werden bei diesem Volumen $100–200/Monat kosten. Erwägen Sie ein lokales Modell für Routine-Vervollständigungen, um Kosten weiter zu senken. Die versteckten Kosten, über die niemand spricht Kontextfenster-Verschwendung. Die meisten Coding-Agenten senden Ihre ganze Datei + Gesprächsverlauf bei jeder Anfrage. Ein 50K-Token-Kontext auf GPT-4o kostet $0,125 pro Anfrage nur bei Input. Mit 200 Anfragen/Tag sind das $25/Tag - mehr als ein monatliches Cursor-Abonnement. Wiederholungsschleifen. Agentur-Tools, die fehlgeschlagene Bearbeitungen automatisch erneut versuchen, können Tokens schnell aufbrauchen. Legen Sie strikte Grenzen für Wiederholungszahlen fest. Modellwechsel-Aufwand. Einige Tools verwenden standardmäßig das teuerste Modell. Überprüfen Sie Ihre Einstellungen - Cursor's "langsame" Anfragen verwenden günstigere Modelle und sind oft schnell genug. Fazit Für die meisten Entwickler ist ein Abonnement-Agent (Copilot oder Cursor) die günstigste Option, da er Ihre Kosten unabhängig von der Nutzung begrenzt. Für Power-User, die bereit sind, API-Schlüssel zu verwalten, bieten Coding-Plan-Anbieter wie MiMO das beste Kosten-pro-Qualität-Verhältnis. Selbst gehostete Modelle sind kostenlos, aber qualitätsbegrenzt - am besten als Ergänzung, nicht als Ersatz. Was immer Sie wählen, verfolgen Sie Ihre Ausgaben pro Tool , um neu zu bewerten, wenn sich die Preise ändern. Verwandt Vergleich von KI-Coding-Plänen - detaillierter Benchmark von Coding-Plan-Anbietern. Wie viel kostet GPT-5? - Frontier-Modell-Preisgestaltung erklärt. Provider-Arbitrage - systematischer Ansatz zum Finden günstigerer Modelle. Modell-Routing - Aufgaben zur richtigen Kostenstufe senden. Möchten Sie dies auf Ihre eigenen LLM-Ausgaben angewendet haben? FinOps LLM führt eine kostenlose Überprüfung Ihrer KI-Kosten durch und zeigt, wo die Einsparungen sind. Kostenlose Überprüfung buchen → Zurück zur Forschung --- # Fable 5.1: 10/50 Dollar, der Cache entscheidet · FinOps LLM URL: https://finopsllm.com/de/research/claude-fable-5-1-cost-model Kostenmodell von Claude Fable 5.1 Aktualisiert September 1, 2026 · erstveröffentlicht September 1, 2026 Kurzantwort: Claude Fable 5.1 (claude-fable-5-1) kostet 10 Dollar je Million Eingabe-Tokens und 50 je Million Ausgabe-Tokens; Opus 5 kostet 5 und 25. Das sieht nach einem pauschalen Aufschlag von 2× aus. Der... Claude Fable 5.1 ( claude-fable-5-1 ) kostet 10 Dollar je Million Eingabe-Tokens und 50 je Million Ausgabe-Tokens; Opus 5 kostet 5 und 25. Das sieht nach einem pauschalen Aufschlag von 2× aus. Der Cache-Tarif läuft jedoch in die Gegenrichtung. Die vier relevanten Tarife Cache-Schreibvorgänge kosten 12,50 Dollar je Million (TTL 5 Minuten) und 20,00 (TTL 1 Stunde). Ein Cache-Lesevorgang kostet 0,25 je Million — 2,5% des eigenen Eingabepreises und die Hälfte dessen, was derselbe Token bei Opus 5 kostet. Jede andere Zeile ist 2×, diese eine ist 0,5×. Wirkung auf eine echte Last Ein Präfix von 100.000 Tokens kostet kalt 1,00 Dollar bei Fable und 0,50 bei Opus 5. Warm sind es 0,025 gegenüber 0,05. Der teurere Anbieter wird beim gleichen Prompt zum günstigeren. Der Break-even ist eine Cache-Trefferquote von rund 50%, keine Modellpräferenz. Die Ausgabeseite ist ungedeckelt Das Kontextfenster reicht bis eine Million Tokens, die Ausgabe bis 128.000. Bei 50 Dollar je Million kostet eine einzige 128K-Antwort 6,40. Erweitertes Denken ist dauerhaft aktiv, eine explizite Konfiguration führt zu einem 400er-Fehler. Der Kostenregler ist der Parameter effort von niedrig bis maximal. Einen Priority Tier gibt es nicht; Latenz steuern Sie über eigene Nebenläufigkeit. Was vor dem Routing instrumentiert gehört Messen Sie die Cache-Trefferquote je Funktion, die Verstärkung der Cache-Schreibvorgänge und die Ausgabe-Tokens je erfolgreicher Aufgabe. Vergleichen Sie anschließend über eine Abweichungsbrücke aus Tarif, Volumen und Mix — ein Durchschnitt verdeckt beide Gegenbewegungen. Weiterführend Ökonomie des Prompt-Cachings Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Claude Opus 5.5: $4/$20 und $0.20 Cache-Lesen · FinOps LLM URL: https://finopsllm.com/de/research/claude-opus-5-5-cost-model Claude Opus 5.5 Kostenmodell Aktualisiert September 22, 2026 · erstveröffentlicht September 22, 2026 Anthropic hat Claude Opus 5.5 ( claude-opus-5-5 ) am 22. September 2026 veröffentlicht. Der angegebene Preis beträgt $4 pro Million Eingabe-Tokens und $20 pro Million Ausgabe-Tokens, gegenüber $5 und $25 bei Opus 5. Das ist eine Kürzung um 20%. Für die meisten produktiven Arbeitslasten ist die tatsächliche Kürzung größer, da der Satz, der sich am meisten bewegte, derjenige ist, den die Schlagzeile auslässt. Die Sätze, die zählen Token-Typ Opus 5.5 Opus 5 Fable 5.1 Eingabe (nicht gecacht) $4.00 / MTok $5.00 / MTok $10.00 / MTok Ausgabe $20.00 / MTok $25.00 / MTok $50.00 / MTok Cache-Schreibvorgänge (5 Min) $5.00 / MTok $6.25 / MTok $12.50 / MTok Cache-Lesevorgänge $0.20 / MTok $0.50 / MTok $0.25 / MTok Schnellmodus (Eingabe / Ausgabe) $8 / $40 — — Jede Zeile ist 20% niedriger außer dem Cache-Lesevorgang, der 60% niedriger ist. Bei $0.20 ist es jetzt günstiger als Fable 5.1s $0.25. Das dreht die eine Zeile um, in der Fable früher gewann. In unserem Fable 5.1 Kostenmodell könnte eine stark gecachte Arbeitslast auf Fable günstiger ausfallen als auf Opus 5. Gegenüber Opus 5.5 passiert das nicht mehr. Fable kostet bei jedem Token-Typ mehr. Warum eine typische Aufgabe etwa 40% weniger kostet Anthropics Behauptung ist eine Kostensenkung von 40% für einen typischen Auftrag, nicht 20%. Das Extra kommt von der Token-Effizienz. Anthropic sagt, dass Opus 5.5 das gleiche Ergebnis mit etwa 20% weniger Ein- und Ausgabe-Tokens erreicht und etwa 40% weniger ausschweifende Ausgabe schreibt. Ein niedrigerer Satz mal weniger Tokens zusammengesetzt: 0.8 × 0.8 = 0.64, was je nach Mischung etwa 36–40% Rabatt ausmacht. Hier ist ein Agentenschritt: 200.000 Eingabe-Tokens, 90% aus dem Cache bereitgestellt, und 20.000 Ausgabe-Tokens. Zeile Opus 5 Opus 5.5 (gleiche Tokens) Fable 5.1 20K Eingabe nicht gecacht $0.100 $0.080 $0.200 180K Eingabe gecacht $0.090 $0.036 $0.045 20K Ausgabe $0.500 $0.400 $1.000 Summe $0.690 $0.516 $1.245 Bei identischen Tokens ist Opus 5.5 25% günstiger als Opus 5, nicht 20%, wegen des Cache-Rabatts. Wenn die Token-Reduktion um 20% für Ihre Arbeitslast hält, sinkt der Schritt auf etwa $0.41, was 40% unter Opus 5 und ein Drittel der Fable-Kosten liegt. Die Ausgabe macht immer noch etwa 80% der Rechnung in diesem Beispiel aus. Dort zahlt sich die Verbositätsreduktion aus. Kosten pro Aufgabe im Vergleich zu GPT-6 Sol, GPT-6 Astra und Fable 5.1 Listenpreise pro Million Token und derselbe Agentenschritt wie oben (200K Eingabe, 90 % aus dem Cache, 20K Ausgabe), auf jedem Modell berechnet. Modell Eingabe $/MTok Ausgabe $/MTok Cache-Lesen $/MTok Gleicher Agentenschritt GPT-6 Sol $2.00 $10.00 $0.20 $0.276 Claude Opus 5.5 $4.00 $20.00 $0.20 $0.516 Claude Opus 5 $5.00 $25.00 $0.50 $0.690 Claude Fable 5.1 $10.00 $50.00 $0.25 $1.245 GPT-6 Astra $10.00 $50.00 $1.00 $1.380 Gemessene Kosten pro Aufgabe im Artificial Analysis Intelligence Index v4.3.2, abgerufen am 22. September 2026, nach Score sortiert. GPT-6 Sol ist bis zu einem Score von 47,5 der günstigste Weg. Darüber ist Opus 5.5 auf jeder Stufe am günstigsten: Opus 5.5 high erreicht 53,6 für 1,82 $, GPT-6 Astra max dagegen 52,7 für 3,26 $ und Fable 5.1 max 53,4 für 7,63 $. Modell Intelligence Index Kosten pro Aufgabe Ausgabe-Token pro Aufgabe GPT-6 Sol · medium 39.8 $0.25 6,500 GPT-6 Sol · xhigh 44.1 $0.53 16,000 GPT-6 Astra · low 45.8 $0.82 4,400 GPT-6 Sol · max 47.5 $1.06 31,200 Claude Opus 5 · high 48.1 $3.61 46,200 Claude Opus 5 · max 50.8 $5.86 72,500 Claude Opus 5.5 · medium 51.2 $1.34 25,700 Claude Fable 5.1 · high 51.2 $3.91 38,100 GPT-6 Astra · max 52.7 $3.26 27,200 Claude Fable 5.1 · max 53.4 $7.63 78,100 Claude Opus 5.5 · high 53.6 $1.82 35,600 Claude Opus 5.5 · max 57.6 $5.98 119,200 Jede GPT-6-Astra-Einstellung oberhalb von low, jede Opus-5- und jede Fable-5.1-Einstellung kostet mehr als eine Sol- oder Opus-5.5-Einstellung mit gleichem oder höherem Score. Die Kosten pro Aufgabe hängen vom Aufgabenmix des Benchmarks ab. Spielen Sie Ihren eigenen Traffic nach, bevor Sie das Modell wechseln. Ist es gut genug, um Fable zu ersetzen? Anthropic positioniert Opus 5.5 als Übereinstimmung mit Fable 5.1 bei den meisten Aufgaben. Die veröffentlichten Zahlen unterstützen das für Code- und agentengestützte Arbeiten: Terminal-Bench 4.0: 66.4%, gegen 52.3% für Opus 5 und 55.8% für Fable 5.1. FrontierCode v1.1: 54.4%, gegen 48.0% für Opus 5 und 50.3% für Fable 5.1. CursorBench 4.0: 57.8%, gegen 46.6% für Opus 5. GDPval-AA v2.1: 1846 Elo, gegen 1708 für Opus 5. Artificial Analysis ordnete es am Starttag auf seinem Intelligence Index an erster Stelle ein. Anthropic sagt auch, dass es auf Standardanstrengung (mittel) GPT-6 Astra bei maximaler Anstrengung bei Wissensarbeit für etwa ein Fünftel der Kosten pro Aufgabe schlägt. Das ist ein Anbietervergleich, also behandeln Sie ihn als Hypothese zum Testen. Die obige Kostenrechnung ist der Teil, den Sie selbst überprüfen können. Der Schnellmodus kostet 2× Der Schnellmodus kostet $8 bei der Eingabe und $40 bei der Ausgabe, genau das Doppelte des Standardsatzes, für bis zu 2.5× die Geschwindigkeit. Das Standardmodell ist auch etwa 30% schneller als Opus 5. Verwenden Sie den Schnellmodus für latenzgebundene interaktive Pfade, auf denen ein Benutzer wartet. Halten Sie ihn für Batch-Jobs, Hintergrund-Agenten und Evaluationen aus. Wenn der Schnellmodus standardmäßig aktiviert ist, verdoppelt sich die Einheitskosten und das Dashboard zeigt nichts Ungewöhnliches, bis die Rechnung ankommt. Was diese Woche zu tun ist Pinnen Sie die Modell-ID. Zeigen Sie die Produktion explizit auf claude-opus-5-5 und notieren Sie die ID bei jeder Anforderung, damit die Kosten pro Anforderung nach der Migration nach Modell aufgeteilt werden können. Neu-Basis auf Ihrem eigenen Datenverkehr. Wiedergeben Sie eine Stichprobe echter Anforderungen auf beiden Modellen und vergleichen Sie Tokens pro abgeschlossener Aufgabe, nicht pro Aufruf. Die Behauptung der Token-Effizienz von 20% ist der Teil, der am wahrscheinlichsten nach Arbeitslast variiert. Überprüfen Sie die Einstellungen für Anstrengung erneut. Wenn eine Arbeitslast zu Fable oder maximaler Anstrengung wegen Qualität verschoben wurde, testen Sie Opus 5.5 zunächst auf mittlerem Niveau. Das ist die Einstellung, gegen die Anthropic Benchmarks durchführt. Treffen Sie die Fable-Routing-Entscheidung erneut. Jede Route, die Cache-schweren Datenverkehr zu Fable sendet, um das günstigere Cache-Lesen zu erhalten, sollte neu bewertet werden. Dieser Kosten-Vorteil ist weg. Überwachen Sie das Cache-Trefferverhältnis. Bei $0.20 gegen $4.00 kostet ein Cache-Fehlschlag jetzt 20× ein Treffer. Eine Umfrage-Vorlagenänderung, die das Präfix bricht, kostet mehr als auf Opus 5. Anthropic sagt, dass Sonnet 5.5 und Haiku 5.5 in den kommenden Wochen folgen werden. Behalten Sie das Wiedergabe-Harness aus Schritt 2, damit jede Version in einem Nachmittag neu basiert werden kann. Weiterführend Claude Fable 5.1 Kostenmodell Wirtschaft des Prompt-Cachings Opus 5.5 Anstrengungsstufen sind der echte Preis Opus 5.5 Schnellmodus-Wirtschaft Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Vergleich der KI-Codierungspläne · FinOps LLM URL: https://finopsllm.com/de/research/coding-plan-comparison Vergleich der KI-Codierungspläne Vergleichen Sie die wichtigsten KI-Codierungspläne mit überprüfbaren Belegen. Preise, Limits und Modellbewertungen in einer normalisierten Tabelle. Erstellt aus Anbieter-Dokumentationen und expliziten Konvertierungsregeln für einen fairen Vergleich. 9 Anbieter erfasst 29 Pläne verglichen 62 Modelle aufgelistet Jul 2026 Zuletzt aktualisiert Jedes Update ist mit öffentlichen Belegen verknüpft Anfrage-/Prompt-Konvertierungsregeln sind explizit Die feste Berechnungslogik hält Vergleiche konsistent Methodik Erfassung Plan-, Limit- und Modelldaten werden aus öffentlichen Anbieterquellen erfasst. Normalisierung Anfrage-/Prompt-/Periode-Formate werden in ein einheitliches Vergleichsmodell normalisiert. Konvertierungsregeln Anfrage / Prompt = 15 und Wöchentlich × 4 = Monatlich werden explizit angewendet. Anzeigerichtlinie Offizielle und geschätzte Werte sind klar in der Benutzeroberfläche getrennt. Aktualisierungsprotokoll 4. Jul 2026 Forschungsseite zum Vergleich der Codierungspläne veröffentlicht Evidenzgestützter Vergleich der KI-Codierungspläne als FinOps LLM-Forschungsartikel veröffentlicht. 27. Mai 2026 Xiaomi MiMO-Kontingent erhöht Xiaomi MiMO hat die verfügbaren Nutzungslimits erhöht, und die Vergleichstabelle wurde aktualisiert. 1. Mai 2026 Alibaba stellt Codierungsplan ein, fügt Token-Plan hinzu Alibaba schloss den bisherigen Codierungsplan und führte den Token-Plan (Team Edition) ein. Liste zum Vergleich der Codierungspläne Konvertierungsrate Anfrage / Prompt (Standard = 15) 1 Prompt = 15 Anfragen Sortierung Standardreihenfolge Bester Wert ≤ $10 Bester Wert ≤ $30 Bester Wert (alle) Anzeige: Alle Coding Agent Anbieter ↕ Plan ↕ Preis ↕ Verwendung Prompt / Monat ↕ Anfrage / Monat ↕ Prompt / $1 ↕ Anfrage / $1 ↕ Modelle Intel ↕ Coding ↕ Agentic ↕ GLM Lite $10 Coding + Agent 160 2.400 16 240 GLM-5.1 (×3), GLM-5-Turbo (×3), GLM-4.7 (×1) 47 37 66 GLM Pro $30 Coding + Agent 267 4.000 8,9 133 GLM-5.1 (×3), GLM-5-Turbo (×3), GLM-5 (×3) 50 44 63 GLM Max $80 Coding + Agent 400 6.000 5 75 GLM-5.1 (×3), GLM-5-Turbo (×3), GLM-5 (×3) 50 44 63 MiniMax Starter $10 Coding + Agent 400 6.000 40 600 MiniMax-M2.7 (×1) 50 42 61 MiniMax Plus $20 Coding + Agent 600 9.000 30 450 MiniMax-M2.7 (×1) 50 42 61 MiniMax Max $45 Coding + Agent 889 13.333 19,8 296 MiniMax-M2.7 (×1) 50 42 61 MiniMax Plus-HighSpeed $40 Coding + Agent 300 4.500 7,5 112,5 MiniMax-M2.7-highspeed (×1) 50 42 61 MiniMax Max-HighSpeed $80 Coding + Agent 500 7.500 6,25 93,75 MiniMax-M2.7-highspeed (×1) 50 42 61 MiniMax Ultra-HighSpeed $150 Coding + Agent 533 8.000 3,55 53,3 MiniMax-M2.7 (×1) 50 42 61 BytePlus Lite $10 Coding + Agent 120 1.800 12 180 Seed-Code (×1), GLM-4.7 (×1), DeepSeek-V3.2 (×1), kimi-k2.5 (×1) 34 31 36 BytePlus Pro $50 Coding + Agent 120 1.800 2,4 36 Seed-Code (×1), GLM-4.7 (×1), DeepSeek-V3.2 (×1), kimi-k2.5 (×1) 34 31 36 StepFun Flash Mini $6.99 Coding 229 3.433 32,8 491 step-3.5-flash (×1) 38 32 52 StepFun Flash Plus $9.99 Coding 641 9.610 64,2 962 step-3.5-flash (×1) 38 32 52 StepFun Flash Pro $29 Coding 828 12.414 28,6 428 step-3.5-flash (×1) 38 32 52 StepFun Flash Max $99 Coding 808 12.121 8,16 122,4 step-3.5-flash (×1) 38 32 52 KwaiKAT Mini $5 Coding 1.075 16.128 215 3.226 KAT-Coder-Pro V2 (×1) 44 46 51 KwaiKAT Starter $10 Coding 1.344 20.160 134,4 2.016 KAT-Coder-Pro V2 (×1) 44 46 51 KwaiKAT Pro $20 Coding 2.016 30.240 100,8 1.512 KAT-Coder-Pro V2 (×1) 44 46 51 KwaiKAT Max $50 Coding 2.688 40.320 53,76 806,4 KAT-Coder-Pro V2 (×1) 44 46 51 OpenCode Go $10 Coding + Agent 667 10.000 66,7 1.000 MiniMax-M2.5 (×1), M2.7 (×1.4), MiMo-V2-Pro (×16), kimi-k2.5 (×11), GLM-5 (×17) 50 44 63 Xiaomi MiMO Registrieren – beide erhalten $2 ↗ Lite $6 Coding + Agent 380 5.693 63,3 949 MiMo-V2-Pro (×1), MiMo-V2-Omni (×1) 49 41 63 Xiaomi MiMO Registrieren – beide erhalten $2 ↗ Standard $16 Coding + Agent 382 5.729 23,9 578 MiMo-V2-Pro (×1), MiMo-V2-Omni (×1) 49 41 63 Xiaomi MiMO Registrieren – beide erhalten $2 ↗ Pro $50 Coding + Agent 422 6.333 8,44 126,7 MiMo-V2-Pro (×1), MiMo-V2-Omni (×1) 49 41 63 Xiaomi MiMO Registrieren – beide erhalten $2 ↗ Max $100 Coding + Agent 456 6.833 4,56 68,3 MiMo-V2-Pro (×1), MiMo-V2-Omni (×1) 49 41 63 Alibaba Standard $30 Coding + Agent 17 262 0,57 8,73 qwen3.6-plus (×1), deepseek-v3.2 (×1), GLM-5 (×1), MiniMax-M2.5 (×1) 50 43 62 Alibaba Advanced $100 Coding + Agent 21 314 0,21 3,14 qwen3.6-plus (×1), deepseek-v3.2 (×1), GLM-5 (×1), MiniMax-M2.5 (×1) 50 43 62 Alibaba Premium $200 Coding + Agent 26 393 0,13 1,97 qwen3.6-plus (×1), deepseek-v3.2 (×1), GLM-5 (×1), MiniMax-M2.5 (×1) 50 43 62 Werte, die nicht explizit von Anbietern bereitgestellt werden, werden in Grau angezeigt. Viele Anbieter limitieren entweder Anfrage- oder Prompt-Kontingente. Wir konvertieren dynamisch mit dem obigen Anfrage-/Prompt-Kontrollschieber (Standard: 15). Wenn das höchste offizielle Limit wöchentlich ist, wird das monatliche Limit als Wöchentlich × 4 geschätzt. Die Artificial Analysis-Bewertung wird gemessen von artificialanalysis.ai . Einige Links können Referenzcodes enthalten. Die Plandetails können sich häufig ändern. Überprüfen Sie immer die neuesten Informationen auf den offiziellen Anbieterseiten. Praktische Anleitung Der Preis allein ist nicht ausreichend. Passen Sie zunächst jeden Plan an Ihren Arbeitsstil an. Beginnen Sie mit der Agent-Richtlinie, dem Limittyp und dem Vertragshorizont. 1) Agent-Richtlinie zuerst überprüfen Einige Anbieter oder Pläne beschränken die Agent-Nutzung. Wenn Agent-Workflows wichtig sind, überprüfen Sie die Bedingungen und die Spalte "Verwendung" (Coding / Agent) vor dem Abonnement. 2) Prompt-Limits vs. Anfrage-Limits Für manuelle, chatgesteuerte Nutzung ist die Bündelung von Arbeit in weniger Umdrehungen oft besser auf Prompt-artige Limits abgestimmt. Für Automatisierung und Agent-intensive Workflows kann das Backend-Anfragevolumen schnell wachsen. Priorisieren Sie daher Pläne mit ausreichend Anfrage-Spielraum. 3) Bevorzugen Sie monatlich, verwenden Sie jährlich wenn Startbedingungen überlegen sind Planüberprüfungen und Änderungen der Anmeldung werden zunehmend häufiger. Monatlich bietet Flexibilität, während jährlich effektiv sein kann, wenn die Startperiodenbedingungen klar überlegen sind. 4) Geschwindigkeit (Token/s) ist ein echter Produktivitätsfaktor Bei gleichen Kontingenten kosten langsamere Antworten immer noch mehr Arbeitszeit. Wir planen, Token-pro-Sekunde-Metriken in einer zukünftigen Aktualisierung hinzuzufügen. Weitere überprüfenswerte Punkte Trennen Sie bereitgestellte von geschätzten Werten (Schätzungen können sich ändern) Bestätigen Sie die Verfügbarkeit gleichklassiger Modelle (keine bedeutet nicht verfügbar) Passen Sie den Reset-Zyklus (5h / täglich / monatlich) an Ihr tatsächliches Nutzungsfenster an Möchten Sie dies auf Ihre eigenen LLM-Ausgaben anwenden? FinOps LLM führt eine kostenlose Audit Ihrer KI-Kosten durch und zeigt auf, wo die Einsparungen sind. Kostenlose Audit buchen → Zurück zur Forschung --- # Ausgabenzusagen wetten auf Ihre Prognose · FinOps LLM URL: https://finopsllm.com/de/research/committed-spend-discounts Rabatte für zugesagte Ausgaben Aktualisiert September 1, 2026 · erstveröffentlicht September 1, 2026 Kurzantwort: Sobald Ihre Modellausgaben auffallen, bietet ein Anbieter Rabatt gegen Volumenzusage. Reservierte Kapazität, Jahreszusage, bereitgestellter Durchsatz — die Formen unterscheiden sich, der Handel... Sobald Ihre Modellausgaben auffallen, bietet ein Anbieter Rabatt gegen Volumenzusage. Reservierte Kapazität, Jahreszusage, bereitgestellter Durchsatz — die Formen unterscheiden sich, der Handel nicht. Sie werden dafür bezahlt, berechenbar zu sein. Die drei Risiken Unterauslastung ist das offensichtliche und kleinste: sagen Sie unter Ihrem konservativen Fall zu, nicht unter Ihrem Plan. Die Bindung an ein Modell wiegt schwerer. Die Frontier bewegt sich in Monaten; zwölf Monate auf das heutige Flaggschiff sind eine Wette darauf, dass nichts deutlich Billigeres kommt — seit drei Jahren kommt jedes Quartal etwas. Der Verlust der Wechselfähigkeit ist am teuersten und steht in keinem Modell: er nimmt Ihnen den Hebel in der nächsten Verhandlung und beendet die Routing-Arbeit, denn niemand optimiert Traffic von einem vorausbezahlten Modell weg. Bewertung Vergleichen Sie mit dem ehrlichen Gegenszenario: was Sie im selben Zeitraum on-demand gezahlt hätten, inklusive der Preissenkungen, die darin erfahrungsgemäß kommen. Auf zwölf Monate liegt das oft 20–40 % unter dem heutigen Listenpreis. Sagen Sie einen Boden zu, keinen Plan. Bevorzugen Sie Ausgaben zusagen vor Modellzusagen. Bestehen Sie auf Übertrag ungenutzten Volumens. Halten Sie die Laufzeit kurz. Weiterführend LLM-Einkaufsleitfaden Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Sie zahlen das Kontextfenster zweimal · FinOps LLM URL: https://finopsllm.com/de/research/context-window-paid-twice Das Kontextfenster zweimal bezahlen Aktualisiert September 1, 2026 · erstveröffentlicht September 1, 2026 Kurzantwort: Ein Kontextfenster wird als Kapazität beworben: 200.000 Tokens, eine Million, Platz für alles. Kapazität ist nicht die Abrechnungseinheit. Berechnet wird, was Sie senden — und in einer... Ein Kontextfenster wird als Kapazität beworben: 200.000 Tokens, eine Million, Platz für alles. Kapazität ist nicht die Abrechnungseinheit. Berechnet wird, was Sie senden — und in einer mehrstufigen Konversation senden Sie fast alles in jedem Zug erneut. Das ist die zweite Zahlung. Ein 30.000-Token-Dokument am Anfang einer Konversation mit zwanzig Zügen sind nicht 30.000 Eingabe-Tokens, sondern eher 600.000. Die Rechnung, die niemand macht Die Kosten wachsen mit dem Quadrat der Konversationslänge, nicht linear. Doppelte Zuganzahl heißt rund vierfache Eingabe-Tokens. Wer "Kosten je Nachricht" modelliert und multipliziert, unterschätzt lange Sitzungen deutlich. Oft kommt ein dritter Posten hinzu: viele Anbieter berechnen oberhalb einer Long-Context-Schwelle einen Aufpreis. Ein zusätzlicher Anhang kann die ganze Anfrage über diese Linie schieben. Was zu messen ist Verfolgen Sie die Kontextauslastung : gesendete Tokens gegenüber tatsächlich benötigten. Messen Sie Eingabe-Tokens je Konversation , nicht je Anfrage, und beobachten Sie den p99. Drei Korrekturen Cachen Sie das stabile Präfix — die ertragreichste Änderung für jedes mehrstufige Produkt. Kürzen Sie den Verlauf bewusst: den älteren Teil zusammenfassen, die Rohzüge verwerfen. Senden Sie den Auszug, nicht das Korpus. Weiterführend Ökonomie des Prompt-Cachings Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Was ein brauchbares Bild kostet · FinOps LLM URL: https://finopsllm.com/de/research/cost-per-approved-image Kosten je freigegebenem Asset bei Bild und Video Aktualisiert September 1, 2026 · erstveröffentlicht September 1, 2026 Kurzantwort: Bild- und Videopreise wirken ungewöhnlich einfach: so viel pro Bild, so viel pro Sekunde. Genau diese Einfachheit führt dazu, dass fast jedes Team falsch budgetiert. Der Anbieter berechnet... Bild- und Videopreise wirken ungewöhnlich einfach: so viel pro Bild, so viel pro Sekunde. Genau diese Einfachheit führt dazu, dass fast jedes Team falsch budgetiert. Der Anbieter berechnet Generierungen . Ihr Geschäft verbraucht freigegebene Assets . Die Annahmequote ist das ganze Modell Niemand liefert den ersten Render aus. Bei reifem Stil vielleicht eines von drei; bei kreativer Exploration eines von zehn. Video ist härter: Ein Clip scheitert an Bewegung, zeitlicher Konsistenz oder einem einzigen Frame — bezahlt wird er ganz. Die nützliche Rechnung ist nicht der Listenpreis, sondern der Listenpreis geteilt durch die Annahmequote. Was die Zahl wirklich bewegt Nicht die Auflösung, sondern alles, was die Annahmequote hebt: in niedriger Auflösung iterieren und nur das Gewählte hochskalieren, eine Prompt-Bibliothek für bekannte Stile, Referenzbilder und feste Seeds, und ein schriftliches Briefing vor der ersten Generierung. Das Richtige messen Generierungen je freigegebenem Asset und Kosten je freigegebenem Asset. Fünfzehn je Freigabe ist ein Briefing-Problem, kein Preisproblem. Weiterführend LLM-Kostenzuordnung Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Kosten je erfolgreicher Aufgabe · FinOps LLM URL: https://finopsllm.com/de/research/cost-per-successful-task Kosten pro erfolgreicher Aufgabe schlagen Kosten pro Anfrage Aktualisiert August 27, 2026 · erstveröffentlicht August 27, 2026 Kurzantwort: Kosten pro Anfrage sind nützlich, aber eine fehlgeschlagene Anfrage ist keine fertige Arbeit. Der bessere Wert sind Kosten pro erfolgreicher Aufgabe: alle zurechenbaren Kosten geteilt durch Aufgaben... Kosten pro Anfrage sind nützlich, aber eine fehlgeschlagene Anfrage ist keine fertige Arbeit. Der bessere Wert sind Kosten pro erfolgreicher Aufgabe : alle zurechenbaren Kosten geteilt durch Aufgaben über einer definierten Qualitätsschwelle. Die Formel Kosten je Aufgabe = zurechenbarer Aufwand / erfolgreiche Aufgaben . Zählen Sie Tokens, Tools, Retries und Fallbacks. Erfolg muss vorher definiert werden. Den Nenner instrumentieren Verknüpfen Sie jeden Modell-Span mit einem Ergebnisereignis. Erfassen Sie Erfolg, Fehlergrund, menschliche Reparatur und Latenz und gleichen Sie die Kosten mit der Provider-Rechnung ab. Niedrige Anfragekosten bei hohen Kosten pro Erfolg bedeuten meist ein Qualitäts-, Retry- oder Stoppregelproblem. Weiterführend LLM-Kostenüberwachung Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Die tatsächlichen Kosten eines LLM-Anbieterwechsels · FinOps LLM URL: https://finopsllm.com/de/research/cost-switching-llm-providers Die tatsächlichen Kosten eines LLM-Anbieterwechsels Aktualisiert August 27, 2026 · erstveröffentlicht August 27, 2026 Kurzantwort: Ein LLM-Wechsel ist kein Preisvergleich. Zählen Sie Engineering, Prompt- und Schemaänderungen, Evaluation, Parallelbetrieb, Transfer, Support und Qualitätsrisiko.Arbeit erfassenInventarisieren Sie... Ein LLM-Wechsel ist kein Preisvergleich. Zählen Sie Engineering, Prompt- und Schemaänderungen, Evaluation, Parallelbetrieb, Transfer, Support und Qualitätsrisiko. Arbeit erfassen Inventarisieren Sie SDK, Tools, Formate, Limits, Kontext, Sicherheit, Observability und Fehlerbehandlung. Schätzen Sie Engineering- und Teststunden. Qualität bepreisen Führen Sie denselben Workload durch beide Anbieter und messen Sie Erfolg, Latenz, Retries, Nacharbeit und Evaluator-Übereinstimmung. Amortisation berechnen Vergleichen Sie monatliche Vollkosteneinsparung mit Migration, Evaluation, Parallelbetrieb und Gateway. Routing kann sinnvoller sein als ein vollständiger Ersatz. Weiterführend LLM-Anbieterarbitrage Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # DeepSeek Harness: sieben Defensivmuster · FinOps LLM URL: https://finopsllm.com/de/research/deepseek-harness-defensive-patterns Sieben Defensivmuster aus der DeepSeek-Harness-Dokumentation Aktualisiert August 16, 2026 · erstveröffentlicht August 16, 2026 Kurzantwort: DeepSeek Harness liefert ein kurzes Dokument mit Defensivmustern, jedes als allgemeine Regel formuliert und mit dem konkreten Fehler, der sie ausgelöst hat. Es ist die übertragbarste Datei im... DeepSeek Harness liefert ein kurzes Dokument mit Defensivmustern, jedes als allgemeine Regel formuliert und mit dem konkreten Fehler, der sie ausgelöst hat. Es ist die übertragbarste Datei im Repository: Nichts davon setzt voraus, dass man das Harness übernimmt, und jeder Punkt entspricht einem Fehlermodus, der in selbstgebauten Agentenlaufzeiten auftaucht. 1. Orthogonale Ergebnisse getrennt melden Niemals die Meldung eines Flags in die Bedingung eines anderen verschachteln. Ein Prozess kann in ein Timeout laufen und mit Null beenden, weil er das Signal abgefangen und sauber heruntergefahren hat. Wird das Timeout nur im Zweig für Nicht-Null-Exit gemeldet, verschwindet dieser Ausgang. Timeout, Signal und Exit-Code sind unabhängige Fakten und brauchen unabhängige Felder. Kostenrelevanz: still verschluckte Timeouts sind die Art, wie Retry-Schleifen entstehen. Der Aufrufer sieht Erfolg, bekommt nichts Brauchbares und versucht es erneut. 2. Öffentliche Verträge auf beiden Seiten einhalten Wo ein Ergebnis mehrere gültige Darstellungen hat, normalisieren Sie sie, bevor Sie sie nach außen geben. Das Beispiel sind Fehler bei Modellanfragen: Implementierungen können werfen oder einen Fehler-Finish-Chunk senden, und die API-Grenze normalisiert alles auf einen terminalen Finish-Chunk. Ohne das kann ein Aufrufer, der eine Ausnahme fängt, nicht unterscheiden, ob sie vom Anbieter, von Middleware, vom Logging oder aus eigenem Code stammt. 3. Asynchroner Zustand ist kein synchroner Zustand Statusabfragen sind nicht kausal an bestimmte asynchrone Operationen gekoppelt. Auf den Idle-Zustand eines Agenten als Abschlusssignal für eine Nachricht zu warten, ist falsch, weil mehrere eingereihte Operationen sich Ausführungsintervalle teilen — Idle kann eintreten, bevor die eigene lief, oder nachdem die eines anderen lief. Der vorgeschriebene Weg: Ein Automatisierungsaufrufer, dem ein Lauf gehört, definiert sein Intervall explizit, vom Eingang im Posteingang bis zum nächsten ganzheitlichen Idle des Agenten, und ordnet Ausgaben diesem Intervall zu statt einzelnen Nachrichten. Behandeln Sie auch den Zweig, in dem es nichts zu warten gibt, sonst hängt der Aufrufer endlos. Ein Automatisierungs-Harness, das auf das falsche Idle-Signal wartet, hält eine Sitzung und ihre Kinder am Leben. Die Rechnung dafür ist nicht das Hängen, sondern alles, was dahinter noch läuft. 4. Dispose muss Ruhe erreichen, nicht nur anfordern Terminierung anzufordern heißt nicht, sie zu erreichen. Dispose wartet auf die tatsächliche Beendigung der Kinder, bevor es zurückkehrt. Und Listener-Registries schließen vor dem Senden der Kill-Signale, damit späte Abschlüsse still landen statt in ein halb abgebautes System zu feuern. Das ist das Muster mit der klarsten finanziellen Kante. Ein Dispose, das zu früh zurückkehrt, lässt verwaiste Subprozesse und ungeschlossene Sandboxes laufen, und abgerechnete Rechenzeit hört nicht auf, nur weil ihr Elternteil sie vergessen hat. 5. Callback-Ausnahmen im Dispatcher einfangen Umschließen Sie Dispatch-Schleifen mit try/catch. Ein fehlschlagender Abonnent darf das Dispatch-Promise nicht ablehnen oder die dahinter eingereihten Listener aushungern. In einer Agentenlaufzeit ist der ausgehungerte Listener häufig genau der, der abrechnet — so verschwinden Nutzungsdaten, ohne dass ein Fehler sichtbar wird. 6. Nie die Umgebung oder vorhersagbare Pfade an nicht vertrauenswürdige Ausgaben geben Die stärkste Regel des Dokuments und die zuerst zu übernehmende. Bereinigen Sie die Umgebung gestarteter Kommandos: Entfernen Sie vor dem Start Variablen, die auf key, secret, token und password passen. Nutzen Sie private Verzeichnisse mit Rechten nur für den Eigentümer, zufällige Dateinamen und exklusive Öffnungen statt vorhersagbarer Pfade. Zwei verschiedene Bedrohungen. Die Bereinigung verhindert, dass Harness-Zugangsdaten in Subprozess-Ausgaben lecken, die das Modell dann liest — und einmal gelesen, stehen sie im Sitzungsprotokoll und im Kontextfenster. Zufällige Namen und exklusives Anlegen schließen Symlink-Rennen in gemeinsamen Temp-Verzeichnissen. 7. Link-förmige Pfade entlinken Prüfen Sie vor dem Löschen, ob ein Pfad ein symbolischer Link ist, und löschen Sie den Link, statt ihm zu folgen. Rekursives Entfernen bleibt bestätigten echten Verzeichnissen vorbehalten, weil es über Symlinks in deren Ziele laufen kann und an Junctions wirft. Aufräumcode, der mehr löscht als er angelegt hat, ist ein Fehlermodus ohne obere Schadensgrenze. Wie man diese Liste nutzt Nehmen Sie Muster 1 und 4 heute in Ihren Subprozess- und Sandbox-Abbau. Dort leckt das Geld. Nehmen Sie Muster 6 überall dorthin, wo Sie einen Prozess starten, dessen Ausgabe das Modell liest. Nehmen Sie Muster 3 in Ihre Automatisierungsschicht, besonders dort, wo ein Warten als "bis der Agent idle ist" formuliert ist. Nehmen Sie Muster 5 in Ihre Telemetrie-Pipeline und prüfen Sie, dass ein fehlschlagender Listener den abrechnenden nicht aushungern kann. Weiterführend Was ist DeepSeek Harness? Der Leitfaden Ausgaben-Leitplanken im Harness (EN) Subagenten und Delegationstiefe (EN) Das Sitzungsprotokoll als Kostennachweis (EN) Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # DeepSeek Harness installieren: Profile, erster Lauf · FinOps LLM URL: https://finopsllm.com/de/research/deepseek-harness-getting-started DeepSeek Harness: Installation, Profile und erster Lauf Aktualisiert August 16, 2026 · erstveröffentlicht August 16, 2026 Kurzantwort: Dies ist die praktische Hälfte unserer Berichterstattung zu DeepSeek Harness: wie Sie dsh zum Laufen bringen, was das Kompositionsmodell von Ihnen erwartet und welche Demos zehn Minuten wert sind. Der... Dies ist die praktische Hälfte unserer Berichterstattung zu DeepSeek Harness: wie Sie dsh zum Laufen bringen, was das Kompositionsmodell von Ihnen erwartet und welche Demos zehn Minuten wert sind. Der schnellste Weg npx @deepseek-ai/dsh web Das startet die Web-Oberfläche unter http://127.0.0.1:3080 . Von dort müssen zwei Dinge geschehen, bevor der Sitzungs-Composer nutzbar wird: Einstellungen → Modelle und den DeepSeek-API-Schlüssel eintragen. Die Route wird sofort aktiv, ohne Neustart. Arbeitsbereich wählen , um das Projektverzeichnis hinzuzufügen und zu aktivieren. Solange kein Arbeitsbereich aktiv ist, bleibt der Composer gesperrt. Sobald es läuft, kann der Agent Dateien lesen und bearbeiten, Befehle ausführen, Aufgaben an Unteragenten abgeben und planen. Er fragt gemäß der aktiven Berechtigungsrichtlinie nach Bestätigung. Aus dem Quellcode git clone https://github.com/deepseek-ai/deepseek-harness pnpm install pnpm run build pnpm dsh web Zu beachtende Untergrenzen: Node 22.19 oder neuer (die CI deckt 22.19, 24 und 26 ab), Git 2.26 oder neuer und Corepack mit pnpm auf pnpm@11.7.0 festgelegt. Ein DEEPSEEK_API_KEY ist optional und wird aus der Umgebung oder einer gitignorierten .env im Wurzelverzeichnis gelesen; daneben kann DEEPSEEK_BASE_URL auf einen anderen Endpunkt zeigen. Die End-to-End-Suiten gegen die echte API überspringen sich selbst, wenn der Schlüssel fehlt, sodass ein Checkout ohne Schlüssel sauber baut und testet. Profile und Bundles: das Kompositionsmodell Da jeder Teil des Harness ein Plugin ist, muss irgendetwas festlegen, welche Plugins geladen werden. Das ist ein Profil : eine benannte Komposition, die eine geordnete Liste von Bundles plus eigene Patches speichert. Ein Bundle verteilt Cordis-Konfigurationszeilen und Code. Drei Vorlagenprofile werden mitgeliefert: Profil Was es komponiert dsh-base Modelladapter, Werkzeuge, Persistenz dsh-web-app Die Browser-Oberfläche dsh-headless Einmal-Ausführung Die vierschichtige Überschreibungsreihenfolge Die Konfiguration löst in fester Reihenfolge auf, spätere Schichten gewinnen: Profil-Bundles Profil-Patches Patches auf Home-Ebene Overlays von der Kommandozeile Lernen Sie diese Reihenfolge, bevor Sie mit der Fehlersuche beginnen. Fast jede Frage der Art „warum nimmt es dieses Modell“ in einem geschichteten Konfigurationssystem beantwortet sich damit, welche Schicht den Wert zuletzt angefasst hat — und ein CLI-Overlay schlägt alles darunter. Die Subsysteme, denen Sie begegnen Sechs Registrierungsschlüssel tragen den Großteil des Verhaltens: ctx.sessions (das reine Anhänge-Ereignisprotokoll), ctx.systemPrompt , ctx.tools (eine gescopte Registry mit bewachter Ausführung), ctx.agents , ctx.agentLoop und ctx.llm . Wer das Harness erweitert, sucht zuerst nach diesen Namen. Drei Demos, die sich lohnen Headless-Einmallauf: pnpm dsh --profile headless "summarize this workspace" . Die Form, die Sie in CI oder einen Cron-Job verdrahten würden. Cordis-Introspektion: pnpm run demo:cordis . Selbstbezüglich — sie inspiziert und verändert ihre eigene laufende Plugin-Laufzeit. Das ist der klarste Beleg, dass der Plugin-Anspruch strukturell und nicht werblich ist. ACP-Automatisierung: pnpm run demo:acp . Ein Automatisierungsserver, der JSON-RPC über stdio spricht — die Integrationsfläche, um das Harness aus einem anderen System heraus zu steuern. Wenn Sie beitragen wollen Ein paar Konventionen sparen Zeit. TODO-Markierungen sind nach Dringlichkeit abgestuft: FIXME blockiert ein Release, TODO heißt bald, XXX heißt irgendwann. Lefthook führt pre-commit aus (Staged-Pairing-Einträge, .oxlintrc.staged.json , Neuerzeugung der Drittanbieterhinweise, Whitespace, Vendor-Manifest-Wächter), dazu pre-merge-commit und pre-push ( pnpm run typecheck ). Die Hooks lassen Tests und Builds bewusst aus — die CI besitzt die vollständige Abdeckung, und pnpm run check:all ist das freiwillige umfassende lokale Tor. Zwei Eigenheiten erklären sonst verwirrende Strukturen. Der Build teilt sich in Host- und Client-tsconfig-Aggregate, weil beide Seiten die Cordis- Context -Schnittstelle unter denselben Schlüsseln deklarationsverschmelzen und ein einzelnes TypeScript-Programm, das beide Verschmelzungen sieht, eine Kollision meldet. Und Codebeispiele in der Dokumentation werden durch ts type-equiv -Blöcke plus pnpm run verify-type-equiv ehrlich gehalten, damit eingefügte Deklarationen nicht stillschweigend vom Quellcode abdriften. Erwartungen setzen Die README sagt es deutlich: Dies ist ein Developer Preview, und es wird kompatibilitätsbrechende Änderungen geben. Die Plugin-Entdeckung läuft über das GitHub-Thema dsh-plugin , das Projekt ist MIT-lizenziert und Drittanbieter-Abhängigkeiten stehen in THIRD_PARTY_NOTICES.md . Evaluieren Sie jetzt, standardisieren Sie später. Weiterführend Was ist DeepSeek Harness? Der Leitfaden Was „alles ist ein Plugin“ wirklich bringt (EN) Wo Ausgaben-Leitplanken hingehören (EN) Das Sitzungsprotokoll als Kostennachweis (EN) Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # DeepSeek Harness: Ziele und die Ralph-Schleife · FinOps LLM URL: https://finopsllm.com/de/research/deepseek-harness-goals-ralph-loop DeepSeek Harness: Ziele, Ziel-Runden und die Ralph-Schleife Aktualisiert August 16, 2026 · erstveröffentlicht August 16, 2026 Kurzantwort: Die meisten Kostenüberraschungen bei Agenten entstehen nicht durch den Preis eines Tokens. Sie entstehen dadurch, wie oft der Agent beschlossen hat, es noch einmal zu versuchen. DeepSeek Harness gibt... Die meisten Kostenüberraschungen bei Agenten entstehen nicht durch den Preis eines Tokens. Sie entstehen dadurch, wie oft der Agent beschlossen hat, es noch einmal zu versuchen. DeepSeek Harness gibt diesem Verhalten ein Vokabular — der erste Schritt, um eine Zahl daran zu heften. Zug, Schritt, Runde Drei Einheiten, im Projektglossar sauber getrennt: Einheit Definition Kostenbedeutung Schritt Eine Modellanfrage plus die von ihr ausgelösten Werkzeugausführungen Das Abrechnungsatom Zug Ein Leeren der Eingabe, endend wenn das Modell stoppt oder eine Policy eingreift Die nutzerseitige Einheit Runde Eine äußere Policy-Iteration, etwa eine Ziel-Runde oder ein Neuversuch mit frischem Agenten Der Multiplikator über den Zügen Runden sind die Ebene, die selbstgebaute Kostenmodelle meist ganz auslassen. Wenn Ihre Prognose Anfragen zählt und Ihr System in Runden läuft, misst Ihre Prognose das Falsche. Ziele sind dauerhafte Vorgaben Ein Ziel ist eine dauerhafte Abschlussvorgabe mit expliziter Phase — aktiv, pausiert, blockiert oder abgeschlossen. Anders als eine Nachricht überdauert es Züge, der Agent trägt also eine stehende Vorgabe mit sich. Jeder für dieses Ziel zugelassene Fortsetzungszyklus ist eine Ziel-Runde, materialisiert als ein zielgetragener Zug. Die Zulassung wird über eine Zielaktivierung gesteuert: eine prozesslokale Erlaubnis, eine weitere Runde zuzulassen, die entweder scharf oder entschärft ist. Dieses eine Bit ist die Drossel für offene Arbeit. Eine stehende Vorgabe plus automatische Fortsetzung ist eine Ausgabenermächtigung ohne Obergrenze. Genau deshalb ist dokumentiert, dass das Anlegen und Ändern von Zielen eine direkte menschliche Autorisierung braucht: Jemand muss das Budget für offene Arbeit verantworten. Die Ralph-Schleife ist bewusster Neustart Die Ralph-Schleife ist ein Vordergrund-Workflow, der auf ein unveränderliches Ziel hinarbeitet, indem er immer wieder frische Agentensitzungen startet — gebaut auf den Workflow- und Subagenten-Primitiven des Harness. Eine Ralph-Runde ist eine frische Kindsitzung ohne Konversationssaat des Elternteils. Die Kontinuität trägt ein Ralph-Handoff: ein normalisierter, begrenzter, strukturierter Bericht mit Status, Zusammenfassung, Belegen und Blockern. Die Ökonomie ist hier wirklich interessant und schneidet in beide Richtungen. Sauber neu zu starten heißt, dass jede Runde nur kleine Eingabekosten zahlt, statt eine immer größere Konversation mitzuschleppen — die Kosten pro Runde bleiben flach statt zu klettern. Aber ein frischer Start garantiert keinerlei Fortschritt, und eine Schleife, die billig neu startet, kann sich viel mehr Neustarts leisten. Der begrenzte Handoff ist die Kontrolle, die das Muster tragfähig macht: Er ist der einzige Kanal zwischen den Runden und deckelt so das Kontextwachstum konstruktiv. Beobachten Sie zwei Zahlen — Runden pro Ziel und ob sich die Blocker-Liste des Handoffs wiederholt. Ein Blocker, der in drei aufeinanderfolgenden Handoffs auftaucht, ist eine Schleife, die nicht konvergieren wird, und jede weitere Runde ist reine Verschwendung. Kommandos sind keine Werkzeuge Das lohnt die Trennung, weil es beeinflusst, was Sie messen. Ein menschliches Kommando ist eine slash-präfigierte Anweisung, die über die Kommando-Ebene an menschenzugewandte Adapter geht — Discovery, Parsing, Dispatch, Abbruch und Rendering, verantwortet von UI-Adaptern. Es ist ausdrücklich verschieden von einem Modellwerkzeug. Das Ziel-Kommando ist eines davon. Praktisch: Ein Mensch, der ein Slash-Kommando tippt, ist nicht das Modell, das Token ausgibt. Rechnen Sie beides getrennt zu, sonst beschuldigen Ihre Sitzungskosten den falschen Akteur. Vier Kontrollen für offene Arbeit Eine maximale Rundenzahl pro Ziel, vor der Zulassung durchgesetzt statt hinterher geprüft. Ein kumulatives Token-Budget über alle Runden eines Ziels, nicht pro Runde. Konvergenzerkennung am Handoff: wiederkehrende Blocker stoppen die Schleife. Explizite menschliche Autorisierung beim Anlegen von Zielen, aufbewahrt als Nachweis, wer die Ausgabe genehmigt hat. Weiterführend Was ist DeepSeek Harness? Der Leitfaden Subagenten und Delegationstiefe (EN) Ausgaben-Leitplanken im Harness (EN) Das Sitzungsprotokoll als Kostennachweis (EN) Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Ausgaben-Leitplanken in DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/de/research/deepseek-harness-guardrails Wo Ausgaben-Leitplanken in DeepSeek Harness hingehören Aktualisiert August 16, 2026 · erstveröffentlicht August 16, 2026 Kurzantwort: Ein Agent, der sein Budget erst aus der Monatsrechnung erfährt, hat kein Budget. Er hat einen Post-mortem-Bericht. Die nützliche Frage an jedes Harness lautet: Wo kann man sich in die Schleife stellen... Ein Agent, der sein Budget erst aus der Monatsrechnung erfährt, hat kein Budget. Er hat einen Post-mortem-Bericht. Die nützliche Frage an jedes Harness lautet: Wo kann man sich in die Schleife stellen und Nein sagen? DeepSeek Harness beantwortet das mit zwei benannten Waterfall-Erweiterungspunkten. Zuerst die Form der Schleife Das Harness nutzt ein Zug-und-Schritt-Modell. Ein Schritt ist eine Modellanfrage plus die Werkzeugaufrufe, die sie erzeugt. Ein Zug enthält null oder mehr Schritte. Der Ablauf eines Zuges lautet grob: Eingabe übernehmen, Prompt zusammenbauen, agent/pre-step , LLM-Stream, Werkzeugausführung, Schrittabschluss, Zugabschluss. Zwei Ereignisströme laufen nebeneinander. session/event trägt dauerhafte Replay-Fakten — Chunks, Nachrichten, Werkzeugaufrufe, Ergebnisse. agent/* trägt Live-Koordinationssignale — Status, Inbox, Anfrage-Interception. Leitplanken gehören in den zweiten Strom, die Abrechnung in den ersten. Abfangpunkt 1: agent/pre-step Das ist der Kontrollpunkt, bevor die Modellanfrage hinausgeht. Die Dokumentation hält fest, dass die zurückgegebene agent/pre-step -Entscheidung autoritativ ist und dass Listener, die next() umschließen, nachgelagerte Nachrichten erhalten, sofern ein Ersetzen nicht beabsichtigt ist. Genau diese Eigenschaft macht den Hook als Budget-Gate brauchbar: Ein Listener kann einen vorgeschlagenen Schritt ablehnen oder verändern, und die Entscheidung hält. Was hierher gehört: Schrittobergrenzen pro Zug. Der Ausreißer-Fehlermodus ist ein Zug, der nie konvergiert. Eine harte Schrittdecke macht aus einer unbegrenzten Rechnung eine begrenzte. Kumulative Token-Budgets. Summieren Sie den bisherigen Verbrauch aus dem Sitzungsprotokoll und verweigern Sie den nächsten Schritt jenseits der Schwelle. Modell-Downshift. Schreiben Sie den Schritt auf eine günstigere Route um, sobald ein Zug eine weiche Schwelle überschritten hat, statt ihn rundweg abzulehnen. Kontextgrößen-Limits. Der Prompt wird vor diesem Hook zusammengebaut, die fertige Anfrage ist hier also sichtbar und messbar. Abfangpunkt 2: tools/pre-execute Die Werkzeugausführung ist eine dreiphasige Pipeline. Zuerst läuft der tools/pre-execute -Waterfall, dann die monotonen Guards, und erst danach der Werkzeugrumpf — sandboxed, mit Dateisystem-Gatekeeping. Anschließend kann ein Post-execute-Waterfall das Ergebnis annehmen, blockieren, ersetzen oder um Kontext ergänzen, und ToolDefinition.finalizeContent setzt Inhaltsinvarianten synchron durch. Die Berechtigungsschicht ist bewusst asymmetrisch. Registrierte monotone Guards verweigern oder enthalten sich, mit geschützter Identität — sie gewähren nie. Verweigert ein Guard, oder fehlt der One-Shot-Prompt von ctx.approval beziehungsweise bleibt er unbeantwortbar, ist das Ergebnis Verweigerung und der Werkzeugrumpf wird übersprungen. Fail closed, nicht fail open. Dateisystem-Mutationen sind separat abgesichert: Nur fs/write-intent - oder fs/edit-intent -Mutationen kommen durch. Schreibvorgänge sind kein beiläufiger Nebeneffekt eines laufenden Werkzeugs. Zwei Eigenschaften machen diese Pipeline als Kontrollpunkt vertrauenswürdig: Guards können nur verweigern, und ein unbeantwortbarer Freigabe-Prompt verweigert. Die meisten selbstgebauten Policy-Schichten für Agenten fallen offen aus, wenn der Freigabekanal fehlt — also genau dann, wenn man sie gebraucht hätte. Was die Pipeline aufzeichnet Drei Sitzungsereignisse ergeben den Prüfpfad: tool/call vor der Ausführung, tool/code-dispatch für Unteraufrufe und tool/result als endgültiges, autoritatives Ergebnis. Dass Unteraufrufe separat protokolliert werden, ist wichtig — ein einzelner modellsichtbarer Werkzeugaufruf, der sich intern auffächert, verbirgt sein Fan-out nicht. Ein praxistauglicher Leitplankensatz Kontrolle Hook Verhindert Maximale Schritte pro Zug agent/pre-step Nicht konvergierende Schleifen Kumulative Token-Obergrenze agent/pre-step Schleichende Mehrausgaben Route-Downshift ab Schwelle agent/pre-step Frontier-Preise für billige Arbeit Werkzeug-Allowlist nach Kostenklasse Monotoner Guard Teure Werkzeuge in billigen Kontexten Subprozess- und Netzwerksperre ctx.sandbox -Policy Ungemessenen Egress Write-Intent-Gating ctx.fs -Naht Ungeprüfte Änderungen Der Vorbehalt DeepSeek Harness ist im Developer Preview und die eigene README warnt vor kompatibilitätsbrechenden Änderungen. Diese Hook-Namen und -Semantiken sind der heute dokumentierte Stand; behandeln Sie dagegen gebaute Leitplanken-Plugins als Code, den Sie erneut anfassen werden, und pinnen Sie die Version, gegen die Sie gebaut haben. Weiterführend Was ist DeepSeek Harness? Der Leitfaden Das Sitzungsprotokoll als Kostennachweis (EN) Alles ist ein Plugin: die Architektur (EN) Ausgaben-Leitplanken für Agenten (EN) Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # DeepSeek Harness: Alles ist ein Plugin · FinOps LLM URL: https://finopsllm.com/de/research/deepseek-harness-plugin-architecture DeepSeek Harness: was „alles ist ein Plugin“ wirklich bringt Aktualisiert August 16, 2026 · erstveröffentlicht August 16, 2026 Kurzantwort: DeepSeek AI hat deepseek-harness (dsh) veröffentlicht, ein MIT-lizenziertes Agenten-Harness, dessen Leitsatz lautet: alles ist ein Plugin. Dieser Satz wird im Agenten-Tooling gern locker verwendet,... DeepSeek AI hat deepseek-harness ( dsh ) veröffentlicht, ein MIT-lizenziertes Agenten-Harness, dessen Leitsatz lautet: alles ist ein Plugin. Dieser Satz wird im Agenten-Tooling gern locker verwendet, deshalb lohnt es sich, genau zu sagen, was er hier bedeutet und wo er die Ökonomie des Agentenbetriebs verändert. Cordis, kein Framework mit Hooks Das Harness läuft auf Cordis , einer Plugin-Laufzeit, deren Modell darin besteht, dass Plugins Dienste, typisierte Ereignisse und umkehrbare Effekte zu einem gemeinsamen Kontext beitragen. Das Architekturdokument sagt ausdrücklich, dass es keinen privilegierten Kern gibt: Modelladapter, Werkzeug-Registries, Sitzungsprotokolle und die Agentenschleife selbst sind allesamt Plugins. Nichts liegt als unbewegliche Engine darunter. Das ist wichtig, weil die übliche Form eines „erweiterbaren“ Agenten-Frameworks ein fester Kern plus eine Hook-Oberfläche ist. Man kann beobachten und dekorieren, aber nicht ersetzen. Ersetzen heißt forken. Cordis dreht das um: Genau die Teile, die man ersetzen möchte, sind die Einheiten der Komposition. Fähigkeitsnähte: der operativ entscheidende Teil Das Harness formalisiert das mit dem, was es eine Fähigkeitsnaht (capability seam) nennt. Eine Naht ist eine Dienstschnittstelle mit mehr als einer Implementierung, und jeder Dienst nimmt eine von drei Rollen ein: Rolle Aufgabe Owner Das Paket, das die Dienstschnittstelle deklariert Implementierung Ein Paket mit konkretem Verhalten (Nähte haben mehrere) Consumer Ein Paket, das den Dienst aufruft, blind für den aktiven Provider Nicht jeder Dienst ist eine Naht. Die Dokumentation unterscheidet drei Arten: austauschbare Nähte ( ctx.llm , ctx.subprocess ), Kerndienste mit einem einzigen Owner ( ctx.sessions , ctx.agents ) und Kompositionspunkte, die andere Dienste koordinieren ( ctx.agentLoop ). Zu wissen, was was ist, sagt Ihnen, wo Sie Verhalten ersetzen dürfen und wo nicht. Die vier Nähte mit Kostenfolgen ctx.llm — die Modellnaht. Gehört dem llm -Paket; Implementierungen sind unter anderem llm-deepseek , llm-pi-ai und llm-replay . Die Agentenschleife konsumiert einen anbieterneutralen Stream-Dienst und weiß nicht, welches Backend läuft. llm-replay ist für Kostenarbeit besonders interessant: Es erlaubt, eine aufgezeichnete Sitzung erneut abzuspielen, ohne die Inferenz noch einmal zu bezahlen. ctx.fs — die Dateisystemnaht. Provider sind fs-local (Host-Dateisystem), fs-sandbox (eingehegte Änderungen) und fs-e2b (eine entfernte, sandboxed Linux-Maschine). Die Naht entkoppelt die Werkzeuge, die das Modell sieht, davon, wo die Ausführung physisch stattfindet. ctx.sandbox — die Ausführungsnaht. Consumer übergeben argv; Implementierungen kapseln die Ausführung unter Richtlinien. sandbox-local setzt auf dem Host durch, sandbox-policy zentralisiert Deployment-Standards. ctx.subagents — die Delegationsnaht. Sechs Implementierungen decken In-Process-Spawning, Forking, ACP-Brücken, Codex, Claude Code und SDK-basierte Agenten ab. Genau hier verdrahtet ein Harness sonst eine Annahme fest; hier ist es ein Austausch. Jeder relevante Kostenhebel in einem Agentensystem ist ein Provider-Austausch: auf ein günstigeres Modell routen, die Ausführung in eine günstigere Sandbox verlagern, einen Subagenten-Transport durch einen lokalen ersetzen. Sind das Nähte, ist die Änderung eine Konfigurationsanpassung. Sind sie es nicht, ist die Änderung ein Fork, den Sie fortan pflegen. Warum das ein FinOps-Thema ist, nicht nur ein Architekturthema Das wiederkehrende Scheitern in Agenten-Kostenprogrammen ist nicht, dass Teams ein teures Modell wählen. Es ist, dass das Harness die teure Wahl strukturell macht. Sind Modellauswahl, Ausführungsort der Werkzeuge und Delegationstransport erst einmal in den Anwendungscode eingebacken, wird jede Optimierung zu einem Engineering-Projekt mit eigenem Zeitplan und eigenem Regressionsrisiko. Teams verschieben die Optimierung dann, und die Ausgaben summieren sich. Ein nahtbasiertes Harness verlagert diese Entscheidungen in die Komposition. Das macht sie nicht kostenlos, aber es verwandelt sie von Refactorings in Konfiguration — der Unterschied zwischen einer Quartalsinitiative und einem Nachmittag. Der Vorbehalt, klar gesagt DeepSeek Harness ist ein Developer Preview, und die README sagt ohne Beschönigung, dass es kompatibilitätsbrechende Änderungen geben wird. Produktions-Kostenwerkzeuge direkt gegen die internen Schnittstellen zu bauen, heißt derzeit, ihnen hinterherzulaufen. Evaluieren Sie es, prototypen Sie damit, aber pinnen Sie Ihre Versionen und rechnen Sie mit Bewegung. Weiterführend Was ist DeepSeek Harness? Der Leitfaden Das Sitzungsprotokoll als Kostennachweis (EN) Wo Ausgaben-Leitplanken hingehören (EN) Installation, Profile und erster Lauf (EN) Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Das Sitzungsprotokoll von DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/de/research/deepseek-harness-session-log Das Sitzungsprotokoll von DeepSeek Harness als Kostennachweis Aktualisiert August 16, 2026 · erstveröffentlicht August 16, 2026 Kurzantwort: Die meisten Agenten-Stacks bekommen Kostenverfolgung nachträglich angeschraubt: ein Wrapper um den Modellaufruf, der Tokens in ein separates System schreibt, das dann irgendwann von der Realität... Die meisten Agenten-Stacks bekommen Kostenverfolgung nachträglich angeschraubt: ein Wrapper um den Modellaufruf, der Tokens in ein separates System schreibt, das dann irgendwann von der Realität abdriftet. DeepSeek Harness geht anders vor. Das Sitzungsprotokoll ist das primäre Artefakt, und der Token-Verbrauch steckt darin. Die Sitzung ist ein append-only Ereignisprotokoll Eine Sitzung ist eine geordnete, nur anhängende Folge typisierter SessionEvent -Einträge. Jedes Ereignis trägt vier Felder: Feld Bedeutung type Die Ereignisart, etwa assistant/message seq Monoton steigende Sequenznummer innerhalb der Sitzung time Zeitstempel data Die typspezifische Nutzlast Oberflächenereignisse (das, was eine Benutzeroberfläche darstellt) ergänzen zwei weitere Felder: sourceEventSeqs , das auf die Rohereignisse zurückzeigt, aus denen sie abgeleitet wurden, und surfaceOp . Die Rückverweise sind der Grund, warum sich eine Kostenzahl bis zu genau den Ereignissen zurückverfolgen lässt, die sie erzeugt haben. Die Ereignisse, die ein Kostenmodell interessieren turn/start und turn/end — die äußere Klammer einer Nutzeranfrage. turn/end trägt einen TurnEndReason , der sagt, ob der Zug fertig wurde, abgebrochen oder abgeschnitten wurde. step/start und step/end — ein Schritt ist eine Modellanfrage plus die Werkzeugaufrufe, die sie auslöst. Das ist die natürliche Abrechnungseinheit. assistant/message — Modellausgabe, optional mit TokenUsage . assistant/chunk — gestreamte Ausgabe, einschließlich Usage-Chunks. tool/call und tool/result — Werkzeugausführung; das Ergebnis kann meta tragen. request/header und request/context — der EpochHeader und der Anfragekontext mit Anbieter, Modell und Kontextfenster. Dieses Paar ist es, das einer Kostenzahl einen Preis zuordnet. Der Leitsatz aus der Dokumentation lautet: was für das Modell sichtbar ist, wird protokolliert . Alles, was in den Kontext des Modells gelangt, hinterlässt ein Ereignis. Damit ist das Protokoll per Konstruktion vollständig, statt vollständig zu sein, solange niemand vergisst, es zu instrumentieren. Verbrauch reist mit der Ausgabe Der Token-Verbrauch wird nicht in einen Nebenkanal geschrieben, sondern reist mit der Ausgabe, zu der er gehört. Bevorzugen Sie die Usage-Chunks ( assistant/chunk mit { type: 'usage' } ), weil sie am nächsten an dem sitzen, was der Anbieter tatsächlich abgerechnet hat; fallen Sie auf assistant/message.usage zurück, wenn kein Chunk vorliegt. Ein Kostenmodell, das auf diese Weise liest, kann nie eine Zahl einem Schritt zuordnen, der sie nicht erzeugt hat. Abgeleitete Historie, keine duplizierte Historie Der Nachrichtenverlauf, den das Modell sieht, wird aus dem Ereignisprotokoll projiziert, statt daneben als zweite Wahrheit gepflegt zu werden. Das ist der Unterschied zwischen einem System, dessen Kostenzahlen mit seiner Ausführung übereinstimmen, und einem System, in dem beide auseinanderdriften und niemand sagen kann, welches recht hat. „Modellsichtbar heißt protokolliert“ ist die eine Regel, die eine Kostenrekonstruktion überhaupt möglich macht. Ohne sie ist jede Attributionszahl eine Schätzung mit einem unbekannten Fehlerbalken. Worauf man darauf aufbauen sollte Verbinden Sie step/start und step/end zu Schritt-Spans — die Einheit, gegen die Sie Kosten berichten. Hängen Sie request/context (Anbieter, Modell, Kontextfenster) und den Preis aus dem Chunk-Verbrauch an jeden Span. Zählen Sie die tool/call -Verzweigung pro Schritt: Werkzeug-Fan-out ist der übliche Grund, warum ein Zug plötzlich das Zehnfache kostet. Beobachten Sie die Verteilung von TurnEndReason . Abgebrochene und abgeschnittene Züge sind bezahlte Arbeit ohne Ergebnis, und sie sind die erste Kennzahl, die Sie ohne Protokoll nicht haben. Weiterführend Was ist DeepSeek Harness? Der Leitfaden Alles ist ein Plugin: die Architektur (EN) Wo Ausgaben-Leitplanken hingehören (EN) OpenTelemetry GenAI-Konventionen (EN) Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # DeepSeek Harness: Subagenten und Delegation · FinOps LLM URL: https://finopsllm.com/de/research/deepseek-harness-subagents DeepSeek Harness Subagenten: Delegation als Kostenmultiplikator Aktualisiert August 16, 2026 · erstveröffentlicht August 16, 2026 Kurzantwort: Der schnellste Weg, eine Agentenrechnung zu vervielfachen, ist Agenten Agenten starten zu lassen. Aus einer Nutzeranfrage wird ein Baum, und der Baum hat keine natürliche Größe. DeepSeek Harness... Der schnellste Weg, eine Agentenrechnung zu vervielfachen, ist Agenten Agenten starten zu lassen. Aus einer Nutzeranfrage wird ein Baum, und der Baum hat keine natürliche Größe. DeepSeek Harness behandelt Delegation deshalb nicht als Feature, sondern als Naht mit expliziten Grenzen. Subagenten sind eine Naht, kein Einbau Delegation läuft über ctx.subagents . Anders als der Shell-Executor, der genau eine Implementierung hat, werden Subagenten-Provider namentlich registriert und mehrere können nebeneinander existieren. Die Dokumentation nennt sechs Transporte: In-Process-Spawning und Forking (gewöhnliche Agenten über den Kontext des Elternteils), eine ACP-Brücke für Remote-Deployment, Codex, Claude Code und eine SDK-basierte Variante. Kostenseitig heißt das: Der Preis eines Kindes hängt davon ab, welcher Provider es erzeugt hat. Ein geforkter In-Process-Agent und ein über eine ACP-Brücke gestarteter Remote-Agent sehen im Aufrufcode gleich aus und haben völlig verschiedene Rechnungen. Zwei Delegationsmodi, zwei Kostenprofile Modus Form Kostencharakteristik One-Shot Kind erzeugen, Prompt senden, Ergebnis abwarten, verwerfen Begrenzt, dem Elternzug zurechenbar Fortsetzbar Dauerhafte Hintergrundsitzung mit residenter Aktivierung Offen; akkumuliert über Züge hinweg One-Shot löst sich zu einem Run-Handle mit einem finalen Ergebnis-Promise auf. Fortsetzbare Kinder sind aufwendiger: Ein Continuation-Manager reserviert die Identität, komponiert das Kind, ordnet jeden Zug über dessen Inbox, und der Provider steuert nur die anfänglichen Erzeugungsmetadaten bei. Aktivierungen haben drei Zustände — laufend, wartend (ruhend, hält aber unabgeschlossene Kindaktivierungen) und abgeschlossen. Trifft eine Nachricht ein, ohne dass eine Aktivierung lebt, wird kalt aus der persistierten Sitzung fortgesetzt. Kalte Fortsetzungen sind der Posten, den man vergisst. Der Zustand kommt aus dem Protokoll, also sind die Eingabe-Token proportional zur Protokollgröße. Ein langlebiges Kind, das selten angesprochen wird, kann pro Nachricht teurer sein als eines, das ständig läuft. Capabilities scheitern laut, nicht leise Das Harness validiert angeforderte Capabilities gegen den Provider und lehnt mit einem typisierten Fehler ab, statt still zu ignorieren. Die Start-Capabilities decken Ausgabeschemata, Tiefenlimits, Werkzeugfilter und Personas ab und stehen eins zu eins zu den Anfrageoptionen. Wer eine Option setzt, die der Provider nicht kann, bekommt das sofort zu sehen und nicht als überraschende Rechnungsposition. Tiefe ist gedeckelt, und der Deckel lässt sich nicht umgehen Die Delegationstiefe wird im Sitzungs-Header persistiert, und ein Laufzeitfeld führt den jeweils größeren Wert. Eine kalte Fortsetzung kann die Tiefe also nicht senken. Der Start wird abgelehnt, wenn die abgeleitete Tiefe maxDepth oder die Safe-Integer-Grenze überschreitet. Ein Elternteil, das drei Kinder startet, die je drei weitere starten, hat aus einer Nutzeranfrage dreizehn Agenten gemacht. Tiefenlimits sind der Unterschied zwischen einem Fan-out, den Sie dimensioniert haben, und einem, den Sie entdeckt haben. Entdeckung ist billig, Zustellung ist autoritativ listChildren() liefert einen live bevorzugten Bestand über eine dreistufige Beschleunigung: Watermark-Cache, dann Projektions-Checkpoint, dann Inspektion der Persistenz. listDescendants() läuft in Pre-Order und ergänzt Eltern- und Tiefenpositionen. Keine der beiden Funktionen konsultiert Agentenregister, Aktivierungen oder Provider — die Nachrichtenzustellung bleibt autoritativ. Für die Kostenzurechnung heißt das: Sie können den Baum jederzeit günstig aufzählen. Ergebnisse tragen einen Stop-Grund Die Ausgabe ist die letzte nicht leere Assistenznachricht oder der akkumulierte Textstream; optionale strukturierte Ausgaben werden gegen das angeforderte Schema validiert. Der stopReason ist eine merge-erweiterbare Union: completed, aborted, error, max-tokens, refusal. Alles außer completed bedeutet Teilausgabe, die auf Fehler-Werkzeugergebnisse abgebildet wird — bezahlt, aber unvollständig. Was zu messen ist Kinder pro Elternzug und Nachfahren pro Nutzeranfrage. Maximal beobachtete Tiefe gegen den konfigurierten Deckel. Anteil fortsetzbarer Kinder, die kalt fortgesetzt wurden, plus Protokollgröße beim Fortsetzen. Verteilung der Stop-Gründe — ein hoher Anteil an max-tokens oder error ist bezahlte, unfertige Arbeit. Weiterführend Was ist DeepSeek Harness? Der Leitfaden Alles ist ein Plugin: die Architektur (EN) Ausgaben-Leitplanken im Harness (EN) Das Sitzungsprotokoll als Kostennachweis (EN) Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # DeepSeek Harness: Tool-Scopes und Restriktionen · FinOps LLM URL: https://finopsllm.com/de/research/deepseek-harness-tool-scopes DeepSeek Harness: Tool-Scopes, Restriktionen und Shadowing Aktualisiert August 16, 2026 · erstveröffentlicht August 16, 2026 Kurzantwort: Werkzeugkataloge wachsen. Jemand ergänzt ein Browser-Werkzeug, jemand ein Datenbank-Werkzeug, jemand fünf Terminal-Operationen — ein Jahr später bekommt jeder Agent im System vierzig Werkzeuge... Werkzeugkataloge wachsen. Jemand ergänzt ein Browser-Werkzeug, jemand ein Datenbank-Werkzeug, jemand fünf Terminal-Operationen — ein Jahr später bekommt jeder Agent im System vierzig Werkzeuge angeboten, ob er sie braucht oder nicht. Meist wird das als Sicherheitsproblem diskutiert. Es ist auch ein Kostenposten. DeepSeek Harness hat ein Scoping-Modell pro Agent, das beides zugleich angeht. Warum der Katalog eine laufende Kostenstelle ist Werkzeugdefinitionen sind Teil der Anfrage. Das Harness protokolliert ein Request-Header-Ereignis mit Konfiguration, Systemprompt und Werkzeugsatz exakt so, wie gesendet — das macht es greifbar: Der Katalog wird bei jeder Modellanfrage der Sitzung erneut übertragen und ist damit eine feste Abgabe pro Schritt, keine einmalige Kosten. Es gibt einen zweiten, größeren Effekt. Ein breiter Katalog vergrößert den Auswahlraum des Modells. Mehr plausible, aber falsche Werkzeugwahlen bedeuten mehr Schritte ohne Nutzen — und Schritte sind die Abrechnungseinheit. Die Fläche zu beschneiden senkt Token-Grundlast und Fehlerrate gleichzeitig. Das Vokabular Begriff Bedeutung Scope Die Einheit der agentenweisen Registrierung für Werkzeuge, Prompts, Variablen, Restriktionen und Listener Scope-Key Die opake Identität, unter der ein Scope geführt und per Objektidentität verglichen wird — meist der lebende Agent selbst Agentenkontext Der eigene Scope-Kontext des Agenten, in dem Registrierungen lebensdauergebunden und scope-sichtbar sind Restriktion Ein Filter über den globalen Werkzeugsatz für einen Scope, angewandt per Schnittmenge Shadowing Ein Scope-Element ersetzt ein gleichnamiges globales Gegenstück, nur innerhalb dieses Scopes Setup-Fenster Der Erzeugungsmoment, in dem ein Erzeuger die Scope-Welt des Agenten komponiert, vor Veröffentlichung oder erstem Prompt-Aufbau Wie die Komposition aufgelöst wird Restriktionen filtern zuerst den globalen Satz, danach werden scope-lokale Registrierungen eingemischt. Genau diese Reihenfolge macht Least Privilege praktikabel: Man startet mit einer Schnittmenge des globalen Katalogs — nie mehr als global — und ergänzt dann exakt die agentenspezifischen Werkzeuge, die dieser Agent braucht. Shadowing liefert den Substitutionsfall ohne Fork. Ein Agent kann hinter einem vertrauten Werkzeugnamen eine andere Implementierung erhalten — eine nur lesende Variante, eine gemessene Variante, ein günstigeres Backend — während alle anderen Agenten weiter die globale sehen. Die Lebensdauerbindung zählt aus demselben Grund wie Dispose. Scope-Registrierungen enden mit dem Kontext des Agenten, ein kurzlebiges Kind kann also keine Beiträge in die Welt des Elternteils lecken. Die gesamte Komposition passiert im Setup-Fenster, bevor der Agent veröffentlicht wird oder seinen ersten Prompt zusammensetzt. Privilegienentscheidungen nach dem ersten Prompt sind keine Privilegienentscheidungen mehr, sondern Aufräumarbeit. Scope-Dispatch und Abstammung Ereignisse über einen Agenten werden mit dessen Träger dispatcht, sodass ein Listener erkennt, wessen Aktivität er beobachtet; Registry-Ereignisse bleiben ungefiltert. Getrennt davon wird die Abstammung — Elternsitzung, Delegationstiefe, Subagententiefe — ausdrücklich als Daten beschrieben, die die Sichtbarkeit selbst nicht beeinflussen. Diese Trennung lohnt die Übernahme. Ein Kind erbt Zugriff nicht, weil es ein Kind ist; Zugriff wird in seinem Setup-Fenster bewusst komponiert. Standardmäßig vererbte Privilegien sind der Weg, auf dem ein billiger Zusammenfassungs-Subagent denselben teuren Werkzeugsatz hält wie sein Elternteil. Vier Dinge, die man damit tut Zählen Sie Ihre Werkzeugdefinitionen und multiplizieren Sie mit den Schritten pro Sitzung. Das ist Ihre feste Werkzeugabgabe pro Sitzung in Token. Definieren Sie je Agentenrolle einen minimal tragfähigen Werkzeugsatz und setzen Sie ihn als Restriktion durch, nicht als Konvention. Überschatten Sie teure Werkzeuge in wenig wertvollen Kontexten mit günstigen oder nur lesenden Varianten, statt sie ganz zu entfernen. Vererben Sie den Werkzeugsatz des Elternteils niemals standardmäßig an Subagenten. Komponieren Sie ihn. Weiterführend Was ist DeepSeek Harness? Der Leitfaden Ausgaben-Leitplanken im Harness (EN) Subagenten und Delegationstiefe (EN) Was "alles ist ein Plugin" bringt (EN) Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Kostenkontrollen in die LLM-Evaluationspipeline einbauen · FinOps LLM URL: https://finopsllm.com/de/research/evals-cost-control Kostenkontrollen in die LLM-Evaluationspipeline einbauen Aktualisiert August 27, 2026 · erstveröffentlicht August 27, 2026 Kurzantwort: LLM-Evaluationen brauchen eine eigene Kostenpolicy. Ein CI-Lauf mit vielen Prompts kann teurer werden als das Feature. Nutzen Sie Laufbudget, repräsentative Stichprobe, Cache und... LLM-Evaluationen brauchen eine eigene Kostenpolicy. Ein CI-Lauf mit vielen Prompts kann teurer werden als das Feature. Nutzen Sie Laufbudget, repräsentative Stichprobe, Cache und Qualitätsgrenzen. Budgetieren Begrenzen Sie Prompts, Modelle, Retries und Dollar vor dem Start. Trennen Sie Smoke-, Nacht- und Release-Tests. Signal bewahren Schichten Sie nach Workflow, Wirkung, Schwierigkeit und Fehlern und versionieren Sie den Datensatz. Gates setzen Stoppen Sie bei Qualitäts- oder Kostengrenze und speichern Sie Modell, Tokens, Cache, Retries, Kosten und Ergebnis. Weiterführend Kosten je erfolgreicher Aufgabe Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # FinOps für LLM und GenAI: ein praktischer Rahmen · FinOps LLM URL: https://finopsllm.com/de/research/finops-for-llm FinOps für LLM: ein praktisches Framework FinOps für LLMs ist die Praxis, AI-Ausgaben sichtbar, attributierbar, optimierbar und verantwortbar zu machen. Es folgt Cloud-FinOps-Prinzipien, aber die Kostentreiber sind unterschiedlich. Eine Cloud-Rechnung wird durch Instanzen, Speicher, Transfer und Verpflichtungen bestimmt. Eine LLM-Rechnung wird durch Eingabe-Tokens, Ausgabe-Tokens, Cache-Schreibvorgänge, Cache-Lesevorgänge, Wiederholungen, Modellmix, Kontextlänge, Batch-Berechtigung und Qualitätsanforderungen bestimmt. Der erste Fehler, den Teams machen, ist, LLM-Ausgaben als einzelne Zahl auf Anbieterebene zu behandeln. Das verbirgt die wahren Faktoren. Ein Support-Summary-Endpoint, ein Agent-Workflow, ein nächtlicher Anreicherungsjob und eine Evaluation-Suite können das gleiche Modell verwenden, haben aber unterschiedliche Latenzanforderungen, Qualitätsschwellwerte, Cache-Kapazität und Ownership. FinOps beginnt, wenn diese Workloads getrennt werden. Säule Zentrale Frage Was sie erzeugt 1. Sichtbarkeit Was zahlen wir genau, Anfrage für Anfrage? Normalisierte Nutzungsprotokollen aufgeteilt nach Eingabe, Ausgabe, Cache-Schreibvorgang, Cache-Lesevorgänge, Batch und Wiederholungsausgaben 2. Attribution Welches Team, welche Funktion, welcher Kunde oder welche Workload hat dies verursacht? Ausgaben den Eigentümern zugeordnet: Umgebung, Endpoint, Team, Tenant, Modell, Workload-Klasse 3. Optimierung Welcher Faktor reduziert die Kosten pro erfolgreiche Aufgabe ohne Qualitätsbeeinträchtigung? Routing-, Cache-, Batch-, Komprimierungs- und Arbitrage-Änderungen hinter Kennzahlen bereitgestellt 4. Verantwortlichkeit Wer überprüft die Zahlen und reagiert monatlich darauf? Showback-Berichte (dann Chargeback) und ein Operationsbetrieb, der mit Rechnungen abgestimmt ist 1. Sichtbarkeit Sichtbarkeit bedeutet, Anbieterrechnungen und Gateway-Protokolle in einem gemeinsamen Protokoll zu normalisieren. Jede Anfrage sollte ausreichende Metadaten enthalten um zu beantworten: Wer ist der Eigentümer, welche Funktion hat sie generiert, welches Modell hat sie bearbeitet, wie viele Token-Klassen wurden abgerechnet, wurde der Anruf wiederholt und hat die Ausgabe dem Benutzer Wert geliefert? Gute Sichtbarkeit trennt Ausgaben für Eingabe, Ausgabe, Cache-Schreibvorgänge, Cache-Lesevorgänge, Batch und Wiederholungen. Ohne diese Aufteilung rechnen Teams Cache-Lesevorgänge versehentlich als Einsparungen ein, verlieren Wiederholungsschleifen und vergleichen Anbieter nach Listenpreis statt Kosten pro erfolgreiche Aufgabe. 2. Attribution Attribution weist Ausgaben Teams, Produkten, Kunden und Workloads zu. Der Punkt ist nicht Schuld; der Punkt ist Entscheidungsqualität. Ein Finanzteam kann Ausgaben nicht steuern, wenn jede Zeile "OpenAI" sagt. Ein Ingenieursleiter kann eine Produktoberfläche nicht optimieren, wenn die Ausgaben nur nach Anbieter-Konto gruppiert sind. Eine sinnvolle Minimalattribution umfasst typischerweise Umgebung, Endpoint, Team-Eigentümer, Kunde oder Tenant wenn zulässig, Modell, Anbieter und Workload-Klasse. Ausgereifte Programme addieren Geschäftsmetriken wie gelöstes Ticket, abgeschlossene Analyse, generierter Bericht oder erfolgreiche Agent-Aufgabe. 3. Optimierung Optimierung sollte Attribution folgen. Häufige Faktoren sind Modell-Routing, semantischer Cache, Prompt-Cache, Kontextkomprimierung, Batch-Routing, Anbieter-Arbitrage und Fallback-Richtlinienstimmung. Jeder Faktor ändert die Rechnung auf unterschiedliche Weise. Routing ändert den Modellmix. Cache ändert die Eingabe-Token und Latenz-Ökonomie. Batch verschiebt Arbeit auf asynchrone Spuren mit Rabatt. Komprimierung reduziert wiederholten Kontext. Der Test ist nicht "Ist die Token-Anzahl gesunken?" Der Test ist "Ist die Kosten pro erfolgreiche Aufgabe gesunken ohne Qualität, Latenz oder Zuverlässigkeit zu beeinträchtigen?" 4. Verantwortlichkeit Showback sollte vor Chargeback kommen. Geben Sie Teams zuerst eine glaubwürdige monatliche Ansicht ihrer Ausgaben und Faktoren. Sobald die Zahlen vertraut werden, kann Chargeback für ausgereifte Organisationen sinnvoll sein. Das Ziel ist ein wiederholbarer Operationsbetrieb: überprüfen Sie die größten Faktoren, einigen Sie sich auf Optimierungskandidaten, implementieren Sie Änderungen hinter Kennzahlen und stimmen Sie mit der nächsten Rechnung ab. Verwandt Was ist LLM FinOps? - die operative Disziplin. AI FinOps - die breitere Praxis, in die LLM FinOps passt. LLM-Kostenattribution - wie die Attribution Schicht funktioniert. LLM-Chargeback und Showback - Kosten auf Eigentümer verschieben. Möchten Sie dies auf Ihre eigenen LLM-Ausgaben anwenden? FinOps LLM führt ein kostenloses Audit Ihrer AI-Kosten durch und zeigt Ihnen, wo Einsparungen möglich sind. Kostenloses Audit anfordern → Zurück zur Forschung --- # Der erste Monatsabschluss für ein KI-lastiges Produkt · FinOps LLM URL: https://finopsllm.com/de/research/first-ai-month-end-close Der erste Monatsabschluss für ein KI-lastiges Produkt Aktualisiert August 27, 2026 · erstveröffentlicht August 27, 2026 Kurzantwort: Der erste KI-Monatsabschluss beginnt mit Rohrechnungen und einem gesperrten Zeitraum, nicht mit einem Dashboard. Zuerst wird der Geldbetrag geschlossen, dann die Nutzung erklärt und erst danach... Der erste KI-Monatsabschluss beginnt mit Rohrechnungen und einem gesperrten Zeitraum, nicht mit einem Dashboard. Zuerst wird der Geldbetrag geschlossen, dann die Nutzung erklärt und erst danach verteilt. Zeitraum sperren Definieren Sie Zeitzone, Währung, Rabatte, Gutschriften und Rechnungsschnitt. Frieren Sie die Preistabelle ein und speichern Sie Rechnungs- und Telemetriezeitraum. Abgleichen und verteilen Verbinden Sie Events mit Provider-Exports nach Konto, Modell, Tokentyp und Tag. Ermitteln Sie die Restdifferenz. Verteilen Sie danach nach Feature, Team, Umgebung, Kohorte und Workload; gemeinsame Plattformkosten bleiben separat. Abweichungen erklären Teilen Sie die Bewegung in Tarif, Volumen, Mix und Effizienz. Verknüpfen Sie große Änderungen mit Deployment, Traffic, Modellmigration oder Agentenverhalten. Weiterführend Rechnungsabgleich für KI-Ausgaben Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # FOCUS 1.5 bringt AI-Token-Tracking im Standard · FinOps LLM URL: https://finopsllm.com/de/research/focus-1-5-ai-token-tracking FOCUS 1.5 bringt natives AI-Token-Tracking und Price Sheets Aktualisiert September 19, 2026 · erstveröffentlicht August 15, 2026 Kurzantwort: Die FinOps Foundation hat bestätigt, dass FOCUS 1.5 im Dezember 2026 erscheint. Erstmals erhält die Open Cost and Usage Specification native Datenfelder für künstliche Intelligenz:... Die FinOps Foundation hat bestätigt, dass FOCUS 1.5 im Dezember 2026 erscheint. Erstmals erhält die Open Cost and Usage Specification native Datenfelder für künstliche Intelligenz: Modellidentifikatoren, getrennte Zähler für Input- und Output-Token sowie ein eigenständiges Price Sheet Dataset für die Listenpreise der Anbieter. 1. Was FOCUS 1.5 standardisiert Bislang rechnete jeder Cloud- und Modellanbieter nach eigenen Regeln ab: Rohdaten von Bedrock, Azure OpenAI und Google Cloud Vertex ließen sich nicht ohne manuelle Transformation vergleichen. FOCUS 1.5 vereinheitlicht das Datenformat: Model Identifier: Herstellerübergreifende Benennung des aufgerufenen Modells. Token Metrics: Separate Spalten für Eingabe-, Ausgabe- und Cache-Token statt aggregierter Pauschalwerte. Price Sheet Dataset: Klare Trennung zwischen Listenpreis und tatsächlichem Verbrauch, um Rabatte und Commitments transparent zu machen. 2. Was FOCUS 1.5 nicht löst FOCUS 1.5 standardisiert die Rechnungsdaten der Anbieter, löst aber nicht die interne Kostenzuordnung . Der Provider weiß nicht, welches Produktfeature, welcher Kunde oder welches Team einen API-Aufruf ausgelöst hat. Die Attribution erfordert weiterhin eigenes Tagging am internen AI-Gateway. 3. Vorbereitung auf die Einführung Beginnen Sie schon heute damit, Token nach Typ zu erfassen, Modell-IDs in jedem Aufruf mitzuführen und Provider-Listenpreise zum Zeitpunkt der Ausführung einzufrieren. So lassen sich Ihre Daten nahtlos in FOCUS 1.5 überführen. Weiterführend Grundlagen der LLM-Kostenzuordnung Rechnungsabgleich für AI-Ausgaben Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Gratis-Tarife sind Akquisekosten · FinOps LLM URL: https://finopsllm.com/de/research/free-tier-is-an-acquisition-cost Der Gratis-Tarif als Kundenakquisekosten Aktualisiert September 1, 2026 · erstveröffentlicht September 1, 2026 Kurzantwort: Inferenz auszuliefern ist nicht kostenlos. Wenn ein Anbieter Ihnen einen Gratis-Tarif, großzügige Preview-Limits oder einen namenlosen Endpunkt ohne Kosten gibt, bezahlt jemand dieses Compute —... Inferenz auszuliefern ist nicht kostenlos. Wenn ein Anbieter Ihnen einen Gratis-Tarif, großzügige Preview-Limits oder einen namenlosen Endpunkt ohne Kosten gibt, bezahlt jemand dieses Compute — aus einem Budget mit einem Namen. Es sind Kundenakquisekosten und verhalten sich wie jede andere CAC-Position. Das ist die nützlichste Sicht für ein Finanzteam, denn CAC hat eine vorhersagbare Dynamik: ausgegeben, um eine Kohorte zu gewinnen, mit Amortisationszeit — und es endet, wenn die Kohorte gewonnen ist. Was ein Gratis-Tarif kauft Evaluierung ohne Einkaufsprozess. Daten zu echten Workloads , mehr wert als das Compute. Und einen Preisanker : was man zum Nulltarif kennt, lässt jeden bezahlten Tarif teuer wirken. Das Signal Rate Limits sinken, bevor Preise steigen. Beobachten Sie Nebenläufigkeit, Kontextlimits und welche Modelle noch enthalten sind — das bewegt sich vor jeder neuen Preisliste. Anwendung Lassen Sie einen Gratis-Tarif nie in Ihre Unit Economics. Eine Marge, die auf kostenloser Inferenz beruht, ist keine Marge, sondern eine Subvention mit fremdem Ablaufdatum. Bewerten Sie Gratis-Nutzung mit einem Schattenpreis in der Telemetrie und führen Sie ihn in der Prognose. Messen Sie Wechselkosten, solange Gehen billig ist. Weiterführend Anbieter-Arbitrage Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # GPT-5.6-Preisschichten-Anleitung: Luna, Terra, Sol · FinOps LLM URL: https://finopsllm.com/de/research/gpt-5-6-pricing-tier-guide GPT-5.6-Preisschichten-Anleitung: Luna, Terra, Sol Veröffentlicht 19. Juli 2026 OpenAI veröffentlichte GPT-5.6 am 10. Juli mit drei unterschiedlichen Preisschichten: Luna bei $1/$6 pro 1M Token, Terra bei $2,50/$15 und Sol bei $5/$30. Dies ist kein einfacher Geschwindigkeit/Qualität-Kompromiss; jede Schicht ist für eine andere Klasse von Arbeitsbelastung positioniert. Die Frage ist nicht "welche ist am besten" — es ist "welche ist richtig für diese Aufgabe?" Diese Anleitung ordnet Aufgaben Schichten zu, geht durchgerechnete Kostenbeispiele durch und zeigt Ihnen, wie Sie intelligent eskalieren, wenn eine günstigere Schicht nicht zuversichtlich genug ist. Luna ($1/$6): Klassifizierung, einfache Extraktion, Hochvolumen-Routing Terra ($2,50/$15): ausgewogenes Reasoning, Agent-Schleifen, Multi-Turn-Konversationen Sol ($5/$30): Frontier-Reasoning, Code-Generierung, schwierige Forschung Cache-Lesevorgänge sparen 90%; Cache-Schreibvorgänge kosten 1,25× Eingabe — Break-Even bei 5+ Treffern in 30 Min Batch API addiert 50% Rabatt zusätzlich zu Preisen der Schicht für nicht-interaktive Arbeit Kritische Vorbemerkung: OpenAI positioniert Terra und Sol als äquivalente Reasoning-Fähigkeit aufweisend, die sich hauptsächlich in Geschwindigkeit und Durchsatz unterscheiden. Testen Sie beide gegen Ihre tatsächliche Arbeitsbelastung — die Paritätsansprüche halten nicht immer bei Ihrer Datenverteilung. Siehe GPT-5 vs. Alternativen für den Vergleich mit Claude und DeepSeek. 1. Die Drei Schichten: Geschwindigkeit, Kosten und Fähigkeit Schicht Eingabe $/1M Ausgabe $/1M Cache-Lesevorgang $/1M Kontext Typische Latenz Luna $1.00 $6.00 $0.10 128K 80–200 ms Terra $2.50 $15.00 $0.25 128K 150–400 ms Sol $5.00 $30.00 $0.50 128K 300–800 ms Latenz ist wichtig: Luna ist am schnellsten, weil es für Streaming, Echtzeit-Klassifizierung und Durchsatz optimiert ist. Sol ist am langsamsten, weil es mehr internes Reasoning durchführt. Für interaktive benutzergerichtete Arbeitsbelastungen ist Luna auch günstiger und schneller — aber nur wenn es für Ihre Aufgabe leistungsfähig genug ist. Dies ist die Schlüssel-Routing-Entscheidung. 2. Aufgabentyp-Routing-Tabelle Diese Tabelle ordnet häufige LLM-Aufgaben der Schicht zu, die die Kosten pro erfolgreicher Antwort minimiert: Aufgabentyp Beispiel Empfohlene Schicht Erfolgsrate bei Schicht Geschätzte Kosten/1K Aufgaben Klassifizierung Spam / Nicht-Spam; Stimmung (pos/neg/neutral) Luna 95–98% $1.20–$1.50 Strukturierte Extraktion Name, E-Mail, Telefon aus Text extrahieren Luna 92–96% $1.80–$2.40 Kategorisierung (viele Klassen) Einer von 50+ Produktkategorien zuordnen Luna 88–94% $2.40–$3.20 Zusammenfassung Artikel oder Chat-Protokoll kondensieren Luna 92–97% $1.50–$2.00 Agent-Schleifen (Tool-Nutzung) Multi-Turn: suchen, reasoning, verfeinern Terra 85–92% $8.00–$12.00 Multi-Turn-Konversation Kundensupport-Bots, Beratungs-Bots Terra 88–94% $6.00–$10.00 Code-Generierung (einfach) SQL-Abfrage, Bash-Snippet, Regex Terra 80–90% $10.00–$15.00 Code-Generierung (komplex) Vollständiger Endpoint, State Machine, DSL-Compiler Sol 75–88% $25.00–$40.00 Forschung + Synthese 10+ Papers analysieren, Konsens synthetisieren Sol 80–90% $30.00–$50.00 Schwieriges Reasoning (neuartiges Problem) Beweis-Verifikation, neuartige Algorithmen-Gestaltung Sol 70–85% $40.00–$70.00 Schlüsseleinsicht: Kosten pro Aufgabe sind nicht nur API-Kosten — es ist (API-Kosten) / (Erfolgsrate). Eine Luna-Klassifizierung mit 95% Erfolgsrate kostet ~$1,26 pro erfolgreiche Antwort. Falls Sie dieselbe Aufgabe zu Sol bei 98% Erfolgsrate routen, zahlen Sie ~$5,10 pro Antwort — aber Sie haben 3% mehr Ihrer Arbeitsbelastung gelöst, was den 4× Kosten möglicherweise wert ist oder nicht. 3. Durchgerechnete Kostenbeispiele Pro Aufgabe Beispiel 1: Spam-Klassifizierung (Luna) Aufgabe: E-Mail als Spam klassifizieren (binär Ja/Nein). Typisches Token-Profil: 400 Eingabe (E-Mail) + 50 Ausgabe (Klassifizierung + Zuversicht) = 450 Token. Luna-Kosten: (400 × $1/1M) + (50 × $6/1M) = $0,00043/Anfrage. Falls 96% beim ersten Versuch erfolgreich: $0,00043 / 0,96 = $0,00045 pro erfolgreicher Klassifizierung. Bei 1M E-Mails/Monat: $450/Monat (plus Cache-Rabatt, falls Sie System-Prompts wiederverwenden). Falls fälschlicherweise zu Sol geroutet: (400 × $5 + 50 × $30) / 1M = $0,0025 pro Anfrage. Bei 98% Erfolg: $0,00255/Erfolg = $2.550/Monat (5,7× mehr). Beispiel 2: Kundensupport-Agent (Terra) Aufgabe: Multi-Turn-Supportkonversation mit Tool-Nutzung (Ticket-Suche, Policy-Suche, Eskalationsentscheidung). Typisches Token-Profil pro Turn: 2.000 Eingabe (Kontext + Verlauf) + 400 Ausgabe (Antwort + Tool-Aufrufe) = 2.400 Token. Durchschnittlich 3 Turns zum Lösen = 7.200 Token gesamt pro Ticket. Terra-Kosten: (2.000 × $2,50/1M) + (400 × $15/1M) = $0,0080/Turn oder $0,0240 pro Ticket. Falls 90% ohne Eskalation gelöst: $0,0240 / 0,90 = $0,0267 pro erfolgreichen Ticket. Bei 10K Tickets/Monat: $267/Monat. Falls Luna stattdessen verwendet: (2.000 × $1 + 400 × $6) / 1M = $0,0044 pro Turn = $0,0132/Ticket. Aber Lunas Agent-Loop-Erfolg fällt auf 65% (Tool-Aufrufe versagen, Reasoning ist oberflächlich). Kosten pro Erfolg: $0,0132 / 0,65 = $0,0203. Nettoeinsparung: $29/Monat, aber 25% der Tickets schlagen fehl und eskalieren, erhöhen Supportkosten $400+. Luna funktioniert hier nicht. Beispiel 3: Code-Generierung (Terra vs. Sol) Aufgabe: Python-Funktion aus Anforderungsstring generieren. Typisches Token-Profil: 1.500 Eingabe (Spezifikation + Beispiele) + 600 Ausgabe (Code + Erklärung) = 2.100 Token. Terra-Kosten: (1.500 × $2,50 + 600 × $15) / 1M = $0,0134 pro Anfrage. Bei 85% Erfolg beim ersten Durchgang (Code kompiliert + besteht grundlegende Tests): $0,0158 pro funktionierende Funktion. Sol-Kosten: (1.500 × $5 + 600 × $30) / 1M = $0,0255 pro Anfrage. Bei 90% Erfolg beim ersten Durchgang: $0,0283 pro funktionierende Funktion. Einsparungen mit Terra: 44% günstiger pro funktionierendes Ergebnis. Verwenden Sie Sol nur, wenn der Unterschied von 5% in Erfolgsrate und Code-Qualität die nachgelagerten Debug-Kosten messbar reduziert. 4. Cascade- & Fallback-Routing-Muster Die meisten FinOps-Teams sollten nicht eine einzelne Schicht für alle Arbeiten verwenden. Implementieren Sie stattdessen ein Cascade-Muster: Beginnen Sie mit der günstigsten Schicht, messen Sie Zuversicht, eskalieren Sie bei niedriger Zuversicht. Schritt Modell Zuversichts-Schwellenwert Aktion falls Schwelle nicht erfüllt 1 Luna Zuversicht > 85% Ergebnis zurückgeben 2 Terra Zuversicht > 75% Ergebnis zurückgeben (eskaliert) 3 Sol Zuversicht > 60% Ergebnis zurückgeben oder explizit fehlschlagen 4 Menschliche Überprüfung — An Mensch eskalieren Echtes Szenario: Sie führen Dokumentenklassifizierung für Rechnungen durch (Klassifizierung nach Anbieter). Luna gibt hochzuversichtliche Ergebnisse zurück (~94% Erfolg) und kostet ~$1,20 pro 1K. Für die 6% mehrdeutiger Rechnungen, bei denen Luna Zuversicht 5. Prompt-Caching-Ökonomie GPT-5.6 änderte Caching-Kosten: Cache-Schreibvorgänge kosten jetzt 1,25× die unkachedEingaberate (nicht kostenlos), und Cache-Lesevorgänge kosten 10% der Eingabe. Szenario Präfix-Größe Schreibkosten Lesekosten (pro Treffer) Break-Even-Treffer Einsparungen @ 10 Treffer/Monat Luna gecachte Abrufkontext 100K Token $0.125 $0.010 15 Treffer -$0.025 (Verlust) Luna gecachter System-Prompt + Dokumente 50K Token $0.063 $0.005 8 Treffer $0.032 Terra gecachter Agent-Kontext 80K Token $0.250 $0.020 14 Treffer $0.030 Sol gecachter Reasoning-Kontext 100K Token $0.625 $0.050 13 Treffer $0.025 Wann zu cachen: Falls Ihr Prompt ein stabiles Präfix enthält (System-Anweisungen, Dokumentation, Few-Shot-Beispiele), das mehr als 5–10 mal in einem 30-Minuten-Fenster wiederverwendet wird, spart Caching üblicherweise Geld. Batch API (50% Rabatt) konkurriert jetzt mit Caching bei Kosten — falls Sie Dokumente im Batch klassifizieren, schlägt Batch-Rabatt die Caching-Kosten. 6. Vergleich mit Claude Sonnet 5, Gemini 3.1 Pro und DeepSeek V4 Modell Eingabe $/1M Ausgabe $/1M Geschwindigkeit Reasoning-Fähigkeit Wann zu wählen GPT-5.6 Luna $1.00 $6.00 Schnell Anweisungsfolge, Routing Klassifizierung, Extraktion, Durchsatz GPT-5.6 Terra $2.50 $15.00 Mittel Moderates Reasoning, Tool-Nutzung Agenten, Multi-Turn, mittlerer Code GPT-5.6 Sol $5.00 $30.00 Langsam Frontier-Reasoning, Forschung Komplexer Code, schwieriges Reasoning, neuartige Probleme Claude Sonnet 5 $2.00–$3.00 $10.00–$15.00 Mittel–Schnell Starkes Reasoning, lange Reasoning-Token Reasoning, Codierung (konkurrenzfähig mit Sol) Gemini 3.1 Pro $2.00 $12.00 Mittel Multimodal, Forschungsfähigkeit Multimodale Aufgaben, konkurrenzfähig mit Terra DeepSeek V4 Flash $0.14 $0.28 Sehr Schnell Basics-Reasoning, Cache-Fokus Hochvolumen-Routing, Cache-intensive Arbeitslasten (7–35× günstiger) Kosten-Arbitrage: Für einfache Klassifizierung und Extraktion ist DeepSeek V4 Flash 7–20× günstiger als Luna. Testen Sie es gegen Ihre Daten — falls es 90%+ Genauigkeit erreicht, verwenden Sie es und sparen Sie den Unterschied. Claude Sonnet 5 ist 2× teurer als Terra, liefert aber stärkeres Reasoning pro Modell-Leistungsanspruch; verwenden Sie es, falls Ihr Terra-Benchmark unzureichende Qualität zeigt. Gemini 3.1 Pro landet zwischen Luna und Terra — nützlich, falls Sie Multimodal-Eingabe benötigen oder bereits im Vertex AI-Ökosystem sind. 7. Migration von GPT-5/5.5 & Deprecation-Status OpenAI bietet weiterhin GPT-5.5 ($5/$30, gleich wie Sol) und GPT-5.4 ($2,50/$15, gleich wie Terra) zusammen mit GPT-5.6 an. Es gibt keinen Deprecation-Druck auf ältere Modelle — Sie können GPT-5.5 weiterhin verwenden, falls Ihr Code darauf abzielt. Allerdings beansprucht GPT-5.6 Performance-Parität (oder besser) zur gleichen Schicht, daher migrieren Sie zu 5.6 für neue Deployments. Die ChatGPT-Schnittstelle setzt ältere Modelle weiterhin auf Rollback-Basis außer Betrieb (GPT-4o mini, GPT-4 turbo sind jetzt schreibgeschützt); API-Zugriff ist stabil. Falls Sie gegen die API entwickeln, planen Sie jährliche Reviews des Modell-Deprecation-Status, erwarten Sie aber keine Dringlichkeit. Kostenmeßrahmen Schritt 1: Baseline pro Schicht etablieren Führen Sie eine Woche Traffic aus und protokollieren Sie, welche Schicht jede Anfrage handhabte. Dies gibt Ihnen Baseline-Verteilung und Kosten. Schritt 2: Zuversichtswerte und Fallback-Raten messen Für jede Schicht protokollieren Sie zurückgegebene Zuversicht. Berechnen Sie: Welcher % der Luna-Aufrufe haben Zuversicht > 85%? Welcher % kaskadiert zu Terra? Dies sagt Ihnen, ob Ihr Cascade ausgewogen ist. Schritt 3: Erfolg/Misserfolg pro Schicht überprüfen Vergleichen Sie Modellausgabe gegen Grundwahrheit für eine Woche. Welche Schicht unterperformt bei Ihren Daten? Justieren Sie Schwellenwerte oder Schichtwahl basierend auf echter Genauigkeit, nicht OpenAI-Behauptungen. Schritt 4: Echte Kosten pro erfolgreicher Antwort berechnen Echte Kosten = (Schicht_Kosten) / (Erfolgsrate). Falls Luna $1,20 pro 1K bei 94% Erfolg kostet, ist Kosten pro funktionierender Antwort $1,28. Dies ist die Metrik zu optimieren. Quick Schicht-Auswahl-Checkliste Ist dies eine Klassifizierung-, Extraktions- oder Routing-Aufgabe? → Luna, falls Genauigkeit nicht kritisch ist. Beinhaltet die Aufgabe Tool-Nutzung oder Multi-Turn-Reasoning? → Terra. Ist dies neuartiges Reasoning, komplexer Code oder Multi-Hop-Analyse? → Sol (oder testen Sie Claude Sonnet 5 zuerst). Können Sie ein Cascade (Luna → Terra → Sol) implementieren? → Ja, dies ist üblicherweise optimal. Gibt es ein stabiles Präfix (System-Prompt, Dokumente), das 10+ mal/Monat wiederverwendet wird? → Cachen Sie es, messen Sie ROI bei Break-Even (5–15 Treffer). Ist dies Batch oder interaktiv? → Batch-Arbeit qualifiziert für 50% Rabatt; berechnen Sie ROI mit Batch API neu. Haben Sie Alternativen (Claude, DeepSeek, Gemini) testen? → Tun Sie es bei Ihren Daten, nicht Marketing-Behauptungen. Schichtwahl ist ein Klassifizierungsproblem: Passen Sie Arbeitsbelastungs-Eigenschaften zu Schicht-Ökonomie an. Das Ideal ist Cascade-Routing — routen Sie zu Luna zuerst, messen Sie Zuversicht, eskalieren Sie bei Unsicherheit. Dies minimiert Kosten bei Qualitätsmaintenance. FinOps LLM kann eine Kostenüberprüfung bei Ihrem LLM-Traffic durchführen und Ihnen zeigen, wo Schicht-Nichtübereinstimmung Geld auf der Theke lässt. Kostenlose Überprüfung buchen . Siehe auch: Wie viel kostet GPT-5? für die vollständige GPT-Preislandschaft und Verborgene LLM-Kosten für Infrastruktur- und Fallback-Kosten über reine Pro-Token-Gebühren hinaus. Zurück zu Forschung FAQ Welche GPT-5.6-Schicht sollte ich für Klassifizierungsaufgaben verwenden? Luna ($1/$6 pro 1M) ist die richtige Wahl für Klassifizierung und einfache Extraktion. Bei 600 Token Eingabe + 100 Token Ausgabe kostet Luna $0,00066/Anfrage gegenüber Terras $0,00175/Anfrage. Falls Genauigkeit nicht Ihr Engpass ist, liefert Luna äquivalente Ergebnisse mit 62% Einsparungen. Wann schlägt Terra ($2,50/$15) Sol ($5/$30) bei den Kosten? Immer. Terra positioniert sich als Performance/Kosten-Sweet-Spot: gleiche Leistungsansprüche wie Sol, aber zu genau der Hälfte des Preises. Verwenden Sie Terra für Agent-Schleifen, Multi-Turn-Konversationen und moderate Reasoning-Aufgaben. Verwenden Sie Sol nur, wenn Terras Reasoning-Tiefe nachweislich unzureichend ist. Welche Kostenauswirkungen hat Prompt Caching bei GPT-5.6? Cache-Schreibvorgänge kosten 1,25× Eingabe (z.B. $1,25 pro Million für Luna). Cache-Lesevorgänge kosten 10% der Eingabe ($0,10 pro Million für Luna). Falls ein 100K-Token-Präfix 5+ mal in 30 Minuten wiederverwendet wird, spart Caching 60%+ gegenüber wiederholten unkachedAbfragen. Wie vergleicht sich GPT-5.6 mit Claude Sonnet 5 und DeepSeek V4? Luna ($1/$6) unterbietet Claude Sonnet ($2/$10 Einführungspreis, $3/$15 ab 1. Sept.) um 50–60% und DeepSeek V4 Flash ($0,14/$0,28) ist 7–20× günstiger als Luna. Bei Reasoning-Arbeitslasten handeln Sol ($5/$30) und Claude Sonnet Performance pro Dollar unterschiedlich aus; testen Sie Ihren Use-Case. --- # Claude Max vs Alibaba Token Pro: Agentic Coding · FinOps LLM URL: https://finopsllm.com/de/research/heavy-agentic-coding-cost-claude-vs-qwen Claude Max vs Alibaba Token Pro: Reale Kosten von Agentic Coding Aktualisiert September 19, 2026 · erstveröffentlicht August 6, 2026 Kurzantwort: Wenn autonome Coding-Agenten von einfachen Code-Vervollständigungen zu Multi-Agent-Swarms übergehen (bei denen Coordinator-Agenten 4 bis 8 parallele Sub-Agenten für Refactoring, Tests und... Wenn autonome Coding-Agenten von einfachen Code-Vervollständigungen zu Multi-Agent-Swarms übergehen (bei denen Coordinator-Agenten 4 bis 8 parallele Sub-Agenten für Refactoring, Tests und Security-Audits starten), explodiert der Token-Verbrauch. Ein reiner Vergleich der Listenpreise pro Token führt zu falschen Kaufentscheidungen. 1. Zwei grundverschiedene Abrechnungsmodelle Alibaba Token Pro ($70/Monat) setzt auf ein transparentes Guthabenmodell mit rollierenden Limits von 12.000 Credits pro 5 Stunden und 40.000 Credits pro 7 Tagen für Qwen 3.8-Max. Außerhalb der Spitzenzeiten greift ein Rabattmultiplikator von 0,2×. Claude Max 20x ($200/Monat) bietet dynamisch skalierte Burst-Kapazität für Opus 5 ohne feste Token-Kontingente. Beide Modelle tokenisieren, planen und korrigieren Code völlig unterschiedlich. 2. Die ökonomische Break-even-Formel Da Alibaba $70 und Claude Max $200 kostet, muss Qwen 3.8-Max lediglich 35 % des Outputs akzeptierter Aufgaben von Opus 5 erreichen, um pro gelöstem Feature wirtschaftlicher zu sein. Umgekehrt rechtfertigt Opus 5 den Aufpreis von $130 bereits, wenn es bei einem Entwicklerstundensatz von $50 lediglich 2,6 Arbeitsstunden pro Monat an manuellem Review und Korrekturschleifen einspart. Weiterführend Kosten-Audit: Alibaba vs Claude Max Warum Providerpreise schwer vergleichbar sind Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Das unsichtbare Zeichen in jeder Claude-Antwort · FinOps LLM URL: https://finopsllm.com/de/research/how-ai-watermarking-works So funktioniert das KI-Wasserzeichen Aktualisiert September 1, 2026 · erstveröffentlicht September 1, 2026 Kurzantwort: In Texten unterstützter Claude-Modelle steckt ein unsichtbares Signal. Weder Sie noch Ihre Nutzer sehen es, es ändert weder Bedeutung noch Qualität und erscheint auf keiner Rechnung. Trotzdem ist es... In Texten unterstützter Claude-Modelle steckt ein unsichtbares Signal. Weder Sie noch Ihre Nutzer sehen es, es ändert weder Bedeutung noch Qualität und erscheint auf keiner Rechnung. Trotzdem ist es da — und es lohnt sich, es zu verstehen, denn was es zerstört, tut Ihre eigene Pipeline täglich. Der Mechanismus im Text Ein Sprachmodell wählt nicht das wahrscheinlichste Token, sondern zieht mit Zufall aus einer Verteilung. Das Wasserzeichenverfahren — nach dem Ansatz SynthID-Text — verzerrt diesen Zufall: Bestimmte Token werden minimal wahrscheinlicher, nach einem Muster, das nur der Detektor kennt. Jedes einzelne Wort bleibt unauffällig, denn eine plausible Alternative gab es ohnehin. Über einige hundert Token summiert sich das Muster zu einem statistischen Signal, das ein Detektor messen und ein Leser nicht wahrnehmen kann. Daraus folgt zweierlei: Es ist statistisch und kein Stempel, und es braucht Länge. Eine Ausgabe in Tweet-Größe trägt weit weniger Signal als eine ganze Seite. Bilder funktionieren umgekehrt Erzeugte .svg -, .png - und .jpg -Dateien tragen C2PA-Metadaten: ein kryptografisch signiertes Manifest. Das ist weder statistisch noch verborgen, sondern ein exakt prüfbarer Datenblock. Der Kompromiss ist erwartbar: Signierte Metadaten geben Gewissheit und lassen sich mit einem Befehl löschen; ein statistisches Wasserzeichen lässt sich nicht sauber entfernen, verblasst aber beim Bearbeiten, Umformulieren und Übersetzen. Keines ist ein Schloss, beide sind Beweismittel. Was das für Ihre Systeme heißt Kurze Ausgaben tragen schwaches Signal. Starke Nachbearbeitung — Umformulieren, Zusammenfassen, Übersetzen oder ein zweites Modell — erodiert es. Und Ihre Bildpipeline kann C2PA-Metadaten versehentlich zerstören: der häufigste Weg, auf dem Provenienz in der Produktion verschwindet. Weiterführend Was das KI-Wasserzeichen wirklich kostet Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Ihr CDN löscht Ihr KI-Wasserzeichen · FinOps LLM URL: https://finopsllm.com/de/research/how-ai-watermarks-get-destroyed Wie KI-Wasserzeichen zerstört werden Aktualisiert September 1, 2026 · erstveröffentlicht September 1, 2026 Kurzantwort: Die interessante Frage zum KI-Wasserzeichen lautet nicht, wie man es aushebelt, sondern warum so viel Produktionsinhalt ohne Provenienz am Ende der Pipeline ankommt, obwohl niemand etwas entfernen... Die interessante Frage zum KI-Wasserzeichen lautet nicht, wie man es aushebelt, sondern warum so viel Produktionsinhalt ohne Provenienz am Ende der Pipeline ankommt, obwohl niemand etwas entfernen wollte. Provenienz wird selten angegriffen. Sie wird wegoptimiert — von Systemen, die genau das tun, wofür sie gebaut wurden. Es gibt zwei unabhängige Fehlerbilder, weil es zwei Mechanismen gibt. Bildprovenienz stirbt durch Löschung, Textprovenienz durch Verdünnung. Beides geschieht lautlos. Löschung: die Metadaten, die Ihre Pipeline wegwirft C2PA-Metadaten stecken in der Datei. Thumbnailer, CDN-Transformationen, Konvertierung nach WebP oder AVIF, Uploads zu Drittplattformen und jeder Screenshot verwerfen sie ohne ausdrückliche Konfiguration. Das Muster ist konstant: Alles, was das Bild neu kodiert, erzeugt eine neue Datei, und eine neue Datei hat kein signiertes Manifest. Eine einzige automatische Transformation zwischen Erzeugung und Auslieferung genügt. Verdünnung: die Textschritte, die das Signal abtragen Das Textwasserzeichen ist statistisch: Es verschwindet nicht auf einen Schlag, es wird schwächer. Übersetzung erzeugt jeden Token neu. Umformulieren und "in unserem Ton neu schreiben" degradiert. Zusammenfassen verwirft die meisten Träger-Token. Ein zweites Modell macht den Text bestenfalls diesem zurechenbar. Und eine Ausgabe aus zwei Sätzen trug nie viel Signal. Ein gut gebautes Produkt tut mehrere dieser Dinge. Mit einem Modell erzeugen, mit einem zweiten den Ton anpassen, in fünf Sprachen übersetzen und auf eine Zusammenfassungskarte kürzen ist kein Fehler — erzeugt aber Inhalt, den kein Detektor zuverlässig zuordnet. Die günstige Variante Erzeugen Sie heute ein Bild und einen langen Text über Ihren echten Produktionsweg und prüfen Sie, was am Ende ankommt. Das ist ein Nachmittag — und es benennt die Stufe, die die Kette bricht, bevor ein Audit es tut. Weiterführend So funktioniert das KI-Wasserzeichen Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Wie viel kostet GPT-5? Vollständiger Preisleitfaden 2026 · FinOps LLM URL: https://finopsllm.com/de/research/how-much-does-gpt5-cost Wie viel kostet GPT-5? Aktualisiert am 15. Juli 2026 · ursprünglich veröffentlicht am 4. Juli 2026 GPT-5 ist OpenAIs Flaggschiff-Reasoning-Modell, das 2026 veröffentlicht wurde. Es bietet erheblich bessere Leistungen bei komplexen Reasoning-, Coding- und Multimodal-Aufgaben als GPT-4o – allerdings zu einem Premium-Preis. Dieser Leitfaden schlüsselt jede Kostendimension auf: API-Preise, ChatGPT-Abonnementebenen, Vergleich mit GPT-4o und wo günstigere Alternativen wie MiMO die bessere Wahl sein können. GPT-5 API-Preise OpenAI berechnet GPT-5 pro Million Tokens, mit separaten Sätzen für Eingabe, Ausgabe und gecachte Eingabe. Cached Reads sind erheblich günstiger, weil das Modell ein zuvor berechnetes Präfix wiederverwendet. Ebene Eingabe $/1M Ausgabe $/1M Cache-Lesen $/1M Kontextfenster GPT-5.6-Sol (max) $5.00 $30.00 $0.50 128K Tokens GPT-5.6-Terra (mittel) $2.50 $15.00 $0.25 128K Tokens GPT-5.6-Luna (kostenbewusst) $1.00 $6.00 $0.10 128K Tokens GPT-5.5 (Flaggschiff) $5.00 $30.00 $0.50 128K Tokens GPT-5.4 (Mittelsegment) $2.50 $15.00 $0.25 128K Tokens OpenAIs neue Generation von Juli 2026 (GPT-5.6) führt drei unterschiedliche Ebenen ein: Sol für Frontier-Reasoning, Terra für ausgewogene Leistung und Luna für kostenbewusste Anwendungsfälle. Zum Vergleich: ältere Modelle GPT-5.5 und 5.4 bleiben verfügbar. GPT-5.6 und 5.5 zu $5/$30 sind erheblich leistungsfähiger als GPT-4o ($2.50/$10), aber die effektiven Kosten hängen von der Reasoning-Tiefe und der Cache-Effizienz ab. Kosten für ChatGPT-Abonnements Wenn Sie GPT-5 über die ChatGPT-Schnittstelle statt über die API nutzen, ist die Preisgestaltung abonnementbasiert: Plan Monatlicher Preis GPT-5-Zugriff Wichtige Limits Free $0 Nur GPT-5 mini Begrenzte Nachrichten/Tag Plus $20/Monat GPT-5 mit Limits ~80 GPT-5-Nachrichten/3 Std Pro $200/Monat Unbegrenztes GPT-5 Keine Rate Limits, Voice, Deep Research Team $25/Benutzer/Monat GPT-5 mit höheren Limits Admin-Tools, SSO, erhöhte Limits Enterprise Individuell Unbegrenztes GPT-5 SLA, dedizierter Support, Datenverwaltung Der Pro-Plan für $200/Monat ist nur rentabel, wenn Sie ein intensiver täglicher Nutzer sind. Für die meisten Entwickler und Teams ist die API mit sorgfältiger Token-Verwaltung günstiger als ein Pro-Abonnement. GPT-5 vs GPT-4o: Wann macht das Upgrade Sinn? Der Preisunterschied ist real, daher stellt sich die Frage, ob der Qualitätsvorteil von GPT-5 sich in Kosteneinsparungen an anderer Stelle auszahlt: Verwenden Sie GPT-5, wenn: die Aufgabe Multi-Step-Reasoning, komplexe Code-Generierung, Analyse langer Dokumente oder agentengesteuerte Workflows erfordert, bei denen ein einzelner qualitativ hochwertiger Durchgang mehrere Wiederholungszyklen spart. Verwenden Sie GPT-4o, wenn: die Aufgabe unkompliziert ist – Klassifizierung, Extraktion, Zusammenfassung kurzer Texte, einfaches Chat oder Batch-Verarbeitung mit hohem Volumen, wobei der Durchsatz wichtiger ist als Intelligenz pro Anfrage. Verwenden Sie GPT-5 mini oder nano, wenn: Sie GPT-5-ähnliche Befehlsausführung zu niedrigerem Preis benötigen und eine leicht reduzierte Reasoning-Tiefe akzeptieren können. Eine praktische Regel: Wenn Ihre GPT-4o-Prompts Chain-of-Thought-Anweisungen oder Multi-Turn-Korrekturschleifen enthalten, kann GPT-5 tatsächlich günstiger sein, weil es dieses Reasoning nativ in einem einzelnen Aufruf durchführt. So reduzieren Sie GPT-5-Kosten Mehrere Strategien können Ihre GPT-5-Rechnung um 30–70% senken, ohne die Ausgabequalität zu beeinträchtigen: Nutzen Sie Prompt Caching. GPT-5s Cache-Read-Rate ($2.50/1M) ist 75% günstiger als die vollständige Eingaberate. Strukturieren Sie Ihre Prompts mit einem stabilen Präfix (Systemanweisungen, Kontext) und variablem Suffix (Benutzerabfrage), um Cache-Hits zu maximieren. Verwenden Sie GPT-5 mini/nano zum Routing. Führen Sie zunächst ein leichtes Modell aus, um die Absicht zu klassifizieren, und eskalieren Sie zu vollständigem GPT-5 nur für komplexe Abfragen. Dies ist das Model-Routing -Muster. Batch-API für nicht-interaktive Arbeiten. OpenAIs Batch API bietet 50% Rabatte auf asynchrone Workloads – ideal für Evaluierung, Anreicherung und Report-Generierung. Kontextfenster richtig dimensionieren. Senden Sie nicht 100K Tokens Kontext, wenn 5K ausreichen. Jeder unnötige Input-Token kostet auf GPT-5 4× mehr als auf GPT-4o. Erwägen Sie Alternativen. Für viele Coding- und Reasoning-Aufgaben bieten Modelle wie MiMO , DeepSeek R1 oder Claude Sonnet vergleichbare Qualität zu einem Bruchteil der Kosten. Nutzen Sie Provider-Arbitrage zum Benchmarking. Versteckte Kosten jenseits des Nominalpreises Die Pro-Token-Rate ist nur ein Teil des Gesamtbildes. Berücksichtigen Sie diese zusätzlichen Faktoren: Reasoning Tokens. GPT-5 nutzt interne Reasoning-Tokens für komplexe Aufgaben. Diese werden mit der Ausgaberate ($30/1M) berechnet und können Ihr effektives Ausgabevolumen bei schwierigen Problemen um das 2–5-fache vervielfachen. Wiederholungskosten. Wenn Ihre Prompts mehrdeutig oder Ihr Parsing fehleranfällig sind, verbrauchen gescheiterte Versuche immer noch Tokens. Robustes Prompt Engineering zahlt sich selbst aus. Evaluierungsausgaben. Tests und Benchmarking während der Entwicklung können leicht die Produktionsausgaben übersteigen, wenn sie nicht separat verfolgt werden. Siehe Eval-Kostenverteilung . Fazit GPT-5 ist teuer, aber nicht gleichmäßig. Bei $10/$30 pro Million Tokens kostet ein typischer API-Aufruf mit 1.000 Input-Tokens und 500 Output-Tokens etwa $0,025. Bei Hochvolumen-Anwendungen addiert sich die Rechnung schnell – aber intelligentes Caching, Routing und Batching können die Kosten um die Hälfte oder mehr reduzieren. Verfolgen Sie jede Anfrage, ordnen Sie Ausgaben Funktionen zu und benchmarken Sie regelmäßig Alternativen. Verwandte Inhalte Wie berechnen LLM-Provider? - die Preismodelle hinter den Zahlen. Model Routing - die richtige Anfrage an das richtige Modell senden. Provider-Arbitrage – das günstigste Modell finden, das Ihre Qualitätsanforderungen erfüllt. Prompt Caching erklärt - wie Sie echte Cache-Hits erzielen. Möchten Sie dies auf Ihre eigenen LLM-Ausgaben anwenden? FinOps LLM führt ein kostenloses Audit Ihrer AI-Kosten durch und zeigt, wo die Einsparungen liegen. Kostenloses Audit buchen → Zurück zu Forschung --- # LLM-Ausgabenprüfung in 30 Minuten · FinOps LLM URL: https://finopsllm.com/de/research/how-to-audit-llm-spend So führen Sie eine LLM-Ausgabenprüfung in 30 Minuten durch Die meisten Teams wissen nicht, wie ihr LLM-Budget aufgeschlüsselt ist. Die Kosten sind in Provider-Dashboards verborgen, die nur Gesamtwerte, aber keine Kostenzuordnung anzeigen, Token-Typen werden mit unterschiedlichen Sätzen abgerechnet, und Nutzungsmuster ändern sich Woche für Woche. Diese Anleitung bietet eine strukturierte Prüfung, die Sie in einer halben Stunde mit Werkzeugen durchführen können, die Sie bereits haben. Schritt 1 - Abrechnungsdaten von Providern erfassen Exportieren Sie die letzten 30 Tage der Nutzung von jedem LLM-Provider, den Sie verwenden. Verwenden Sie für OpenAI die Usage-API oder laden Sie CSV aus dem Dashboard herunter. Für Anthropic rufen Sie die Billing-API ab. Für Google exportieren Sie aus der Cloud-Billing-Konsole. Für selbst gehostete Modelle rufen Sie Anfragelogs von Ihrem Inferenzserver ab. Speichern Sie alles in einem Ordner. Sie benötigen Rohdaten, keine Zusammenfassungen. Schritt 2 - Token-Anzahl über Provider normalisieren Jeder Provider zählt Token unterschiedlich. OpenAI und Anthropic verwenden ihre eigenen Tokenisierer; Google verwendet SentencePiece. Um die Ergebnisse zu vergleichen, konvertieren Sie alle Zählungen in eine gemeinsame Einheit. Der einfachste Ansatz: Verwenden Sie den von jedem Provider veröffentlichten Pro-Token-Preis, um die Kosten pro Anfrage zu berechnen, und vergleichen Sie dann die Kosten direkt, anstatt rohe Token-Zählungen zu vergleichen. Dies vermeidet Tokenisierer-Unterschiede vollständig. Schritt 3 - Nach Input-, Output-, Cache- und Reasoning-Tokens unterteilen Provider berechnen unterschiedliche Sätze für verschiedene Token-Typen. Zwischengespeicherte Input-Tokens sind typischerweise 50 % günstiger bei OpenAI und Anthropic. Reasoning-Tokens (in o-series und ähnlichen Modellen) können 2–4-mal so teuer sein wie Standard-Output-Tokens. Teilen Sie Ihre Ausgaben in diese vier Kategorien ein: Input, Output, zwischengespeicherte Input und Reasoning. Wenn Ihr Provider diese Aufteilung nicht offenlegt, schätzen Sie diese anhand des Modelltyps und des Anfrage-Musters. Schritt 4 - Teams und Funktionen zuordnen Ordnen Sie jeden API-Schlüssel oder jedes Projekt dem Team oder der Funktion zu, das oder die es besitzt. Wenn Sie keine Trennung auf Schlüsselebene haben, verwenden Sie Anfrage-Metadaten – Header, Tags oder den user -Parameter, den die meisten Provider unterstützen. Das Ziel ist eine Tabelle: Welches Team gibt wie viel für welche Funktion aus. Ohne dies können Sie niemanden für Kosten verantwortlich machen. Schritt 5 - Identifizieren Sie die 3 wichtigsten Kostentreiber Sortieren Sie nach Gesamtausgaben in absteigender Reihenfolge. In den meisten Organisationen stammen 80 % der LLM-Kosten aus 3–5 Nutzungsmustern. Häufige Kostentreiber: Ein Chatbot mit langen Kontextfenstern, eine Code-Generierungsfunktion, die für alle Anfragen teure Modelle verwendet, oder ein Hintergrund-Enrichment-Job, der auf jedem Dokument ohne Filterung ausgeführt wird. Nennen Sie diese. Hier konzentriert sich die Optimierungsarbeit. Schritt 6 - Kosten pro Aufgabe für wichtige Workflows berechnen Wählen Sie Ihre Top-3-Workflows. Dividieren Sie für jeden die Gesamtausgaben durch die Anzahl der abgeschlossenen Aufgaben. Dies gibt Ihnen eine Unit-Economics-Zahl, die Sie im Laufe der Zeit nachverfolgen können. Ein Customer-Support-Workflow, der 0,12 USD pro Ticket kostet, ist handhabbar. Einer, der 1,40 USD pro Ticket kostet, bedarf aufmerksamkeit. Die absolute Zahl ist weniger wichtig als der Trend und der Vergleich zwischen Workflows. Schritt 7 - Warnmeldungen für Anomalien einrichten Konfigurieren Sie Warnmeldungen auf zwei Ebenen: Tägliche Gesamtausgaben (erkennt Runaway-Jobs) und Ausgaben pro Workflow (erkennt Abweichungen). Die meisten Provider unterstützen Abrechnungswarnmeldungen nativ. Für Provider-übergreifende Warnmeldungen leiten Sie Ihre Nutzungsdaten in ein Dashboard ein oder verwenden ein Tool wie MiMO , das Provider-übergreifend aggregiert. Eine einfache Regel: Warnmeldung, wenn ein beliebiger Tag 150 % des durchschnittlichen 7-Tage-Trends überschreitet. Schnelle Audit-Checkliste Schritt Erforderliches Tool Geschätzter Zeitaufwand Ergebnis 1. Abrechnungsdaten erfassen Provider-Dashboards oder APIs 5 Min Rohe CSV/JSON pro Provider 2. Tokens normalisieren Tabellenkalkulation oder Skript 5 Min Kosten pro Anfrage-Tabelle 3. Token-Typen unterteilen Provider-APIs mit Token-Aufteilung 5 Min Input/Output/Cache/Reasoning-Aufteilung 4. Teams zuordnen API-Schlüssel-Zuordnung oder Metadaten 5 Min Team-zu-Funktion Kostenmatrix 5. Wichtigste Kostentreiber identifizieren Sortierung/Tabellenkalkulation 3 Min Rangierte Liste von Kostenmustern 6. Kosten pro Aufgabe Aufgabenzahl aus App-Logs 5 Min Unit Economics pro Workflow 7. Warnmeldungen einrichten Provider-Abrechnungswarnmeldungen + Dashboard 2 Min Anomalieerkennung aktiv Was Sie danach tun sollten Diese Prüfung bietet eine Momentaufnahme. Der echte Wert kommt von der regelmäßigen Durchführung – wöchentlich für Teams mit hohen Ausgaben, monatlich für alle anderen. Automatisieren Sie die Datenerfassung und machen Sie die Kosten-pro-Aufgabe-Metrik zu einer erstklassigen Produktmetrik. Wenn Sie Hilfe beim Aufbau eines kontinuierlichen Prozesses benötigen, bietet MiMO Provider-übergreifende Dashboards und automatisierte Zuordnung aus dem Kasten. Verwandte Artikel LLM-Kostenzuordnung – tieferer Einblick in Zuordnungsmuster. LLM-Kostenanomalieserkennung – automatisierte Warnstrategien. Wie man für KI-Ausgaben budgetiert – von der Prüfung zum Budgetplan. Möchten Sie diesen Audit auf Ihre eigenen LLM-Ausgaben anwenden? FinOps LLM führt eine kostenlose Prüfung Ihrer KI-Kosten durch und zeigt, wo die Einsparungen sind. Kostenlose Audit buchen → Zurück zur Forschung --- # LLM-API-Preisvergleich · FinOps LLM URL: https://finopsllm.com/de/research/llm-api-pricing-tracker LLM-API-Preisvergleich Aktualisiert am 2. September 2026 · erstmals veröffentlicht am 4. Juli 2026 Verfolgung von Token-Preisen über alle großen LLM-Anbieter. Eingabe, Ausgabe, Cache-Lesen/-Schreiben, Kontextfenster und Batch-Rabatte in einer normalisierten Tabelle. Monatlich aktualisiert mit überprüfbaren Anbieterdaten. 12+ Anbieter verfolgt 25+ Modelle aufgelistet 6 Preisspalten Sep 2026 Zuletzt aktualisiert Alle Preise in USD pro 1 Million Tokens Geschätzte Werte in Grau angezeigt Cache-Preise spiegeln Prompt-Caching wider, wo verfügbar Methodik Erfassung Preisdaten erfasst von offiziellen Preisseiten der Anbieter und API-Dokumentation. Normalisierung Alle Preise normalisiert auf USD pro 1 Million Tokens für direkten Vergleich. Cache-Preise Cache-Lesen/-Schreiben-Spalten zeigen Prompt-Caching-Rabatte, wo Anbieter diese unterstützen. Anzeigerichtlinie Offizielle und geschätzte Werte sind klar getrennt. Schätzungen in Grau markiert. Aktualisierungsverlauf 4 Jul 2026 LLM-API-Preisvergleich veröffentlicht Token-Preisvergleich über 12+ große LLM-Anbieter als FinOps-LLM-Forschungsartikel veröffentlicht. Token-Preistabelle Anbieter ↕ Modell ↕ Eingabe $/1M ↕ Ausgabe $/1M ↕ Cache-Lesen $/1M ↕ Cache-Schreiben $/1M ↕ Kontextfenster ↕ Batch-Rabatt OpenAI GPT-5.6-Sol $4.00 $20.00 $0.40 $5.00 1.05M 50% OpenAI GPT-5.6-Terra $2.00 $12.00 $0.20 $2.50 1.05M 50% OpenAI GPT-5.6-Luna $0.20 $1.20 $0.02 $0.25 1.05M 50% Anthropic Claude Fable 5.1 $10.00 $50.00 $0.25 $12.50 1M 50% Anthropic Claude Fable 5 $10.00 $50.00 $1.00 $12.50 1M 50% Anthropic Claude Opus 5 $5.00 $25.00 $0.50 $6.25 1M 50% Anthropic Claude Sonnet 5 * $2.00 $10.00 $0.20 $2.50 1M 50% Anthropic Claude Sonnet 4.6 $3.00 $15.00 $0.30 $3.75 1M 50% Anthropic Claude Haiku 4.5 $1.00 $5.00 $0.10 $1.25 200K 50% Google Gemini 3.5 Flash $1.50 $9.00 $0.15 $1.88 1M 50% Google Gemini 3.1 Pro Preview $2.00 $12.00 $0.20 $2.50 1M 50% Google Gemini 2.5 Pro $1.25 $5.00 $0.31 $4.50 1M 50% Google Gemini 2.5 Flash $0.15 $0.60 $0.04 $0.15 1M 50% xAI Grok 4.5 $2.00 $6.00 $0.50 $1.50 1M 50% xAI Grok 4.3 $1.25 $2.50 - - 1M 50% Meta Llama 4 Maverick (DeepInfra) $0.20 $0.80 - - 1M - Meta Llama 4 Scout (Groq) $0.11 $0.34 - - 5M - Meta Llama 3.3 70B (Groq) $0.59 $0.79 - - 8M - Mistral Mistral Large 2/3 $2.00 $6.00 - - 128K - Mistral Mistral Medium 3.5 $1.50 $7.50 - - 128K - Mistral Mistral Small 3 $0.10 $0.30 - - 128K - Mistral Codestral $0.30 $0.90 - - 128K - DeepSeek DeepSeek V4 Flash $0.14 $0.28 $0.0028 - 128K - DeepSeek DeepSeek V4 Pro $0.435 $0.87 $0.0036 - 128K - Alibaba Qwen Qwen 3.7-Max $2.50 $7.50 - - 131K - Moonshot Kimi Kimi K2.6 $0.95 $4.00 $0.16 - 200K - Xiaomi MiMO Anmelden - beide erhalten $2 ↗ MiMo-V2-Pro $0.50 $2.00 - - 128K - Xiaomi MiMO Anmelden - beide erhalten $2 ↗ MiMo-V2-Omni $0.40 $1.60 - - 128K - Zhipu AI GLM-5 $1.00 $4.00 - - 128K - Zhipu AI GLM-5-Turbo $0.30 $1.20 - - 128K - MiniMax M2.7 $0.40 $1.60 - - 128K - StepFun step-3.5-flash $0.30 $1.20 - - 128K - * Claude Sonnet 5 kostet dauerhaft $2/$10 pro 1M Tokens — die für den 1. September 2026 geplante Erhöhung auf $3/$15 wurde abgesagt. Die Cache-Write-Werte gelten für die 5-Minuten-TTL; die 1-Stunden-TTL kostet das 2-Fache des Basis-Input-Preises. Claude Opus 4.8, 4.7 und 4.6 teilen sich die Preise von Claude Opus 5. Claude 4.7 und neuer verwenden einen Tokenizer, der für denselben Text rund 30% mehr Tokens erzeugt — vergleichen Sie Kosten pro Aufgabe, nicht pro Token. Werte, die nicht explizit von Anbietern angegeben werden, werden in Grau angezeigt. Meta Llama-Preise spiegeln gehostete API-Preise (Fireworks, Together usw.) wider, nicht Kosten für das Selbst-Hosting. Die Ökonomie des Selbst-Hosting wird in unserem Open-Source- vs. Closed-Source-Kostenvergleich behandelt. Kontextfenster sind die maximal unterstützten; die tatsächliche Verfügbarkeit kann je nach Stufe variieren. Cache-Lesen/-Schreiben-Preise spiegeln anbieterspezifisches Prompt-Caching wider, wo verfügbar. "-" bedeutet, dass der Anbieter kein Caching anbietet oder der Preis nicht veröffentlicht ist. Batch-Rabatt zeigt die ungefähren Einsparungen beim Einsatz von Batch-/Async-APIs, wo verfügbar. Einige Links enthalten möglicherweise Referralmittelungscodes. Preise können sich häufig ändern. Überprüfen Sie immer die neuesten Informationen auf den offiziellen Anbieterseiten. Praktischer Leitfaden Verwendung dieser Preisdaten zur Kostenplanung 1) Berechnen Sie zuerst Ihr Token-Volumen Bevor Sie Preise vergleichen, schätzen Sie Ihre monatlichen Ein- und Ausgabe-Token-Volumen. Ausgabe-Tokens sind typischerweise 3-5x teurer als Eingabe, daher hat die Reduzierung der Ausgabelänge die größte Auswirkung auf die Kosten. 2) Beachten Sie Cache-Einsparungen Wenn Ihre Arbeitslast wiederholte Systemaufforderungen oder Kontext hat (RAG, Multi-Turn-Gespräche), kann Prompt-Caching die Eingabekosten um 50-90% reduzieren. Prüfen Sie die Cache-Lesen-Spalte auf anwendbare Rabatte. 3) Verwenden Sie Batch-APIs für nicht dringende Arbeiten Die meisten großen Anbieter bieten 50% Rabatt auf Batch-/Async-API-Aufrufe. Wenn Ihre Arbeitslast Latenz toleriert (Evaluierungen, Datenverarbeitung, Inhaltsgenerierung), werden Batch-Preise halbiert. 4) Vergleichen Sie Gesamtkosten, nicht nur Pro-Token-Preis Ein preiswertes Modell, das 3x mehr Tokens benötigt, um die Qualität zu erreichen, kann insgesamt teurer sein. Berücksichtigen Sie die Modellqualität und aufgabenspezifische Leistung neben den Rohpreisen. Möchten Sie dies auf Ihre eigenen LLM-Kosten angewendet? FinOps LLM führt ein kostenloses Audit Ihrer KI-Kosten durch und zeigt, wo die Einsparungen liegen. Kostenlose Auditor buchen → Zurück zur Forschung --- # Ihre LLM-Rechnung hat ein FX-Problem · FinOps LLM URL: https://finopsllm.com/de/research/llm-bill-fx-exposure Währungsrisiko bei LLM-Ausgaben Aktualisiert September 1, 2026 · erstveröffentlicht September 1, 2026 Kurzantwort: Nahezu alle Frontier-Modelle werden in US-Dollar bepreist. Wenn Ihr Budget nicht in Dollar läuft, ist ein Teil Ihrer LLM-Kosten eine Währungsposition, die Sie nie bewusst eingegangen sind.6 % Bewegung... Nahezu alle Frontier-Modelle werden in US-Dollar bepreist. Wenn Ihr Budget nicht in Dollar läuft, ist ein Teil Ihrer LLM-Kosten eine Währungsposition, die Sie nie bewusst eingegangen sind. 6 % Bewegung in EUR/USD heißt 6 % höhere Kosten — ohne Änderung an Token-Volumen oder Modell und ohne irgendetwas im Nutzungs-Dashboard, das es erklärt. Finance sieht die Abweichung; Engineering sieht einen flachen Monat und kann nicht helfen. Warum es sich so gut versteckt Zwischen API-Aufruf und Hauptbuch liegen drei Umrechnungsschichten: der USD-Preis des Anbieters, die Umrechnung von Karte oder Rechnung samt Spread, und der Kurs, zu dem Ihr ERP bucht. Im Abweichungsbericht sind Währungs- und Nutzungsanteil dieselbe Zahl. Der Kauf über einen Marktplatz in Landeswährung beseitigt das Risiko nicht — er verlagert die Umrechnung nach vorn und legt eine Marge darauf. Trennen Sie die Abweichungen Erfassen Sie die Kosten je Anfrage primär in USD zum Listenpreis in der Telemetrie und rechnen Sie erst im Reporting einmalig zu einem genannten Kurs um. Wann absichern? Selten, und nur bei Größe. Für die meisten ist Sichtbarkeit die richtige Antwort, nicht ein Hedge. Weiterführend Abweichungsbrücke KI-Ausgaben Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # LLM-Chargeback und Showback · FinOps LLM URL: https://finopsllm.com/de/research/llm-chargeback-showback LLM-Chargeback und Showback Showback (Cost Visibility) meldet LLM-Ausgaben den Teams und Produkten die sie verursacht haben. Chargeback (Cost Allocation) ordnet diese Ausgaben ihren Budgets zu. Die meisten Organisationen sollten mit Showback beginnen, weil Teams Zeit brauchen um den Zahlen zu vertrauen bevor diese Zahlen Budgetentscheidungen beeinflussen. Die Herausforderung ist Attribution Genauigkeit. Eine einfache Anbieterrechnung kann dir nicht sagen welche Feature, welcher Mandant oder welches Team einen Token produziert hat. Sie brauchen Request-Metadaten vom Gateway, von der Anwendung oder von der Orchestration-Schicht. Ohne diese Metadaten wird Chargeback zu einer politischen Diskussion statt zu einem operativen System. Gute Showback-Berichte Ausgaben nach Produktbereich und Team-Eigentümer aufschlüsseln. Hauptworkloads und Änderungen Monat für Monat zeigen. Modellpreis-Änderungen vom Traffic-Wachstum trennen. Optimierungskandidaten identifizieren, die jedes Team besitzt. Nicht zugeordnete Ausgaben sichtbar halten. Wann man Chargeback macht Chargeback macht Sinn sobald die Attribution Abdeckung hoch ist und Teams Kostenfaktoren beeinflussen können. Berechnen Sie Teams nicht für ungekennzeichnete gemeinsame Infrastruktur, veraltete Preistabellen oder zentrale Plattformentscheidungen die sie nicht ändern können. Ein solides Modell nutzt Showback für Bildung, dann Chargeback für ausgereifte Cost-Center. Es schützt auch Experimentier-Budgets damit Teams nicht nützliche AI-Funktionen vermeiden nur weil der anfängliche Traffic schwer vorherzusagen ist. Verwandt LLM-Budgetverwaltung - Budgets und Guardrails. LLM-Kostenattribution - Attribution Grundlagen. Was ist LLM FinOps? - die vollständige operative Disziplin. Was gehört in einen Showback-Bericht? Ein Bericht, der nur eine Zahl zeigt, wird ignoriert. Handlungsrelevant wird er durch vier Bestandteile: Ausgaben mit Vergleich — dieser Monat gegen den letzten und gegen das Budget. Eine absolute Zahl trägt kein Signal. Eine Unit-Metrik — Kosten pro Anfrage, pro Kunde oder pro erfolgreicher Aufgabe. Teams, die mehr ausliefern, sollten mehr ausgeben; erst die Unit-Kosten zeigen, ob das effizient geschieht. Die drei größten Treiber — die konkreten Workloads hinter der Veränderung, nicht eine vollständige Inventarliste. Eine Maßnahme — eine benannte Sache, die das Team in diesem Monat tun kann. Ohne sie ist der Bericht nur Statistik. Wie lange sollte Showback laufen, bevor Chargeback kommt? So lange, bis die Teams die Daten nicht mehr bestreiten — in der Praxis zwei bis drei Berichtszyklen. Das Signal ist verhaltensbasiert: Wenn Teams ihre Zahlen einfordern, bevor der Bericht verschickt wird, und wenn Rückfragen von "diese Zuordnung ist falsch" zu "diese Zuordnung stimmt und wir wollen sie senken" wechseln, trägt die Datenqualität auch Budgetverantwortung. Was passiert bei nicht zugeordneten Ausgaben? Machen Sie sie sichtbar, statt sie zu verteilen. Ein explizites Feld "nicht zugeordnet" mit einer vereinbarten Obergrenze — fünf Prozent sind ein brauchbarer Startwert — hält den Druck auf das Tagging. Werden diese Kosten still proportional umgelegt, verschwindet das Problem aus dem Bericht, aber nicht aus der Rechnung, und niemand erfährt je, welches Team sie verursacht hat. Möchten Sie dies auf Ihre eigenen LLM-Ausgaben anwenden? FinOps LLM führt ein kostenloses Audit Ihrer AI-Kosten durch und zeigt Ihnen, wo Einsparungen möglich sind. Kostenloses Audit anfordern → Zurück zur Forschung --- # LLM-Kostenattribution · FinOps LLM URL: https://finopsllm.com/de/research/llm-cost-attribution LLM-Kostenattribution LLM-Kostenattribution ist die Brücke zwischen Anbieterrechnungen und operativen Entscheidungen. Anbieter berechnen nach Konto, Modell, Token-Klasse und manchmal nach Region oder Funktion. Unternehmen müssen Ausgaben nach Team, Produkt, Kunde, Workflow und Werteeinheit verstehen. Die Attribution Schicht verbindet diese beiden Sichtweisen ohne die Abstimmung mit der Rohrechnung zu verlieren. Der Schlüssel ist die Kennzeichnung von Anfragen bevor sie zum Anbieter oder Gateway gelangen. Nachträglich erstellte Protokolle sind normalerweise unvollständig. Mindestens muss jeder LLM-Aufruf in der Produktion einen stabilen Endpoint-Namen, Umgebung, Team-Eigentümer, Produktoberfläche, Workload-Klasse und Korrelations-ID tragen. Wo Verträge es erlauben, fügen Sie Mandanten- oder Kunden-ID hinzu. Für Agent-Workflows kennzeichnen Sie jeden Tool-Aufruf oder Modell-Schritt separat. Request-Zählung ist nicht Attribution Ausgaben nach Request-Zählung zuzuordnen ist fast immer falsch. Ein lange-Kontext-Reasoning-Request kann mehr kosten als hunderte kurze Klassifizierungs-Aufrufe. Attribution braucht Token-Klassen und Modellpreise. Sie braucht auch Daten zu Wiederholungen und Fallbacks, weil eine "erfolgreiche" Antwort drei vorherige fehlgeschlagene Aufrufe verbergen kann. Empfohlene Dimensionen Anbieter, Modell und Modellversion wo verfügbar. Token-Klassen: Eingabe, Ausgabe, Cache-Schreibvorgang, Cache-Lesevorgänge und Reasoning. Team, Produkt, Funktion, Endpoint und Umgebung. Workload-Klasse: Echtzeit-Benutzer-Pfad, Hintergrund-Job, Evaluation, Anreicherung, Agent-Schritt, Support-Workflow oder Analyse-Aufgabe. Kunde oder Mandanten-Attribution wo Datenschutz- und Vertragsgrenzen es erlauben. Rechnungsabstimmung Attribution muss mit der Anbieterrechnung abstimmen. Erwarten Sie kleine Unterschiede durch Rundung, verzögerte Rechnungszeilen und anbieter-spezifische Rabatte, aber große Lücken bedeuten dass das Protokoll-Pipeline Verkehr verliert oder veraltete Preistabellen verwendet. Die Finanzansicht sollte sowohl zugeordnete als auch nicht zugeordnete Ausgaben zeigen damit Datenqualitätsprobleme sichtbar sind. Von Showback zu Handlung Das erste Ergebnis sollte Showback sein: welche Teams und Produktoberflächen treiben die Ausgaben an, und welche Workloads haben sich seit letztem Monat geändert. Sobald Teams diesen Daten vertrauen, verwenden Sie sie um Optimierungsarbeit zu priorisieren. Attribution ist wertvoll weil sie direkt auf die Eigentümer zeigt, die Routing-, Cache- oder Prompt-Änderungen genehmigen können. Verwandt OpenAI-Kostenattribution - OpenAI-spezifische Attribution Muster. LLM-Chargeback und Showback - Kosten auf Eigentümer verschieben. Was ist LLM FinOps? - die vollständige operative Disziplin. Möchten Sie dies auf Ihre eigenen LLM-Ausgaben anwenden? FinOps LLM führt ein kostenloses Audit Ihrer AI-Kosten durch und zeigt Ihnen, wo Einsparungen möglich sind. Kostenloses Audit anfordern → Zurück zur Forschung --- # LLM-Kostenrechner: monatliche KI-Ausgaben schätzen · FinOps LLM URL: https://finopsllm.com/de/research/llm-cost-calculator LLM-Kostenrechner Aktualisiert 15. Juli 2026 Schätzen Sie Ihre monatlichen LLM-Ausgaben für populäre Modelle. Geben Sie Ihr Nutzungsmuster unten ein und vergleichen Sie die Kosten nebeneinander. Alle Preise sind pro Million Tokens im Juli 2026. Vorberechnete Kosten nach Nutzungsstufe Hier ist aufgeführt, was jede Nutzungsstufe pro Monat bei populären Modellen kostet, basierend auf typischen Anforderungsmustern: Modell Leicht (1K Anforderungen/Monat) Mittel (10K Anforderungen/Monat) Intensiv (100K Anforderungen/Monat) GPT-5.6-Sol $8.75 $87.50 $875.00 GPT-5.6-Terra $4.38 $43.75 $437.50 GPT-5.6-Luna $1.75 $17.50 $175.00 Claude Fable 5 $17.50 $175.00 $1,750.00 Claude Opus 4.8 $8.75 $87.50 $875.00 Claude Sonnet 5 $3.50 $35.00 $350.00 Claude Haiku 4.5 $1.75 $17.50 $175.00 Gemini 3.5 Flash $2.63 $26.25 $262.50 Grok 4.5 $4.00 $40.00 $400.00 DeepSeek V4 Pro $0.95 $9.50 $95.00 Kimi K2.6 $1.70 $17.00 $170.00 Leicht: 1K Anforderungen/Monat, 500 Input + 200 Output Tokens. Mittel: 10K Anforderungen/Monat, 1.000 Input + 500 Output Tokens. Intensiv: 100K Anforderungen/Monat, 2.000 Input + 1.000 Output Tokens. Interaktiver Kostenrechner Modell GPT-5.6-Sol ($5.00 / $30.00) GPT-5.6-Terra ($2.50 / $15.00) GPT-5.6-Luna ($1.00 / $6.00) Claude Fable 5 ($10.00 / $50.00) Claude Opus 4.8 ($5.00 / $25.00) Claude Sonnet 5 ($2.00 / $10.00) Claude Haiku 4.5 ($1.00 / $5.00) Gemini 3.5 Flash ($1.50 / $9.00) Grok 4.5 ($2.00 / $6.00) DeepSeek V4 Pro ($0.435 / $0.87) Kimi K2.6 ($0.95 / $4.00) Anforderungen pro Monat Durchschnittliche Input Tokens pro Anforderung Durchschnittliche Output Tokens pro Anforderung Kosten berechnen So verwenden Sie diesen Kostenrechner Wählen Sie Ihr Modell aus dem Dropdown-Menü. Die Preise entsprechen Standard-API-Tarifen vom Juli 2026. Geben Sie Ihr Anforderungsvolumen ein – wie viele API-Aufrufe Sie pro Monat durchführen. Schätzen Sie die Token-Zählung – die durchschnittliche Anzahl der Input- und Output-Tokens pro Anforderung. Falls Sie sich unsicher sind, beginnen Sie mit 1.000 Input / 500 Output für Chat oder 3.000 Input / 1.000 Output für Code-Generierung. Klicken Sie auf Berechnen , um Ihre geschätzten monatlichen Kosten nach Input und Output aufgeschlüsselt zu sehen. So reduzieren Sie Ihre Schätzung Verwenden Sie Prompt Caching. Wenn Ihre Prompts ein stabiles Präfix haben, können zwischengespeicherte Lesevorgänge die Input-Kosten um 50–90% senken. Siehe Prompt Caching erklärt . Wechseln Sie das Modell nach Aufgabe. Leiten Sie einfache Abfragen an billigere Modelle und reservieren Sie die teureren für komplexe Aufgaben. Das ist Model Routing . Verwenden Sie Batch APIs. Nicht dringende Workloads können Batch-Preise mit 50% Rabatt nutzen. Versuchen Sie günstigere Anbieter. MiMO und DeepSeek bieten erheblich niedrigere Tarife für vergleichbare Qualität bei vielen Aufgaben. Verwandt Wie viel kostet GPT-5? – detaillierte Aufschlüsselung der GPT-5-Preise. Wie berechnen LLM-Anbieter Gebühren? – Verständnis der Token-basierten Abrechnung. Die billigste Methode zur Ausführung von KI-Code-Generierung – Kostenvergleich für Codierungs-Tools. Arbitrage von Anbietern – Finden Sie das billigste Modell, das Ihren Qualitätsstandard erfüllt. Möchten Sie dies auf Ihre eigenen LLM-Ausgaben anwenden? FinOps LLM führt ein kostenloses Audit Ihrer KI-Kosten durch und zeigt, wo Einsparungen möglich sind. Buchen Sie ein kostenloses Audit → Zurück zur Forschung --- # Production-Runbook für einen LLM-Kostensprung · FinOps LLM URL: https://finopsllm.com/de/research/llm-cost-spike-runbook Production-Runbook für einen LLM-Kostensprung Aktualisiert August 27, 2026 · erstveröffentlicht August 27, 2026 Kurzantwort: Bei einem Kostensprung sichern Sie zuerst Beweise, bestätigen die Abrechnung und trennen Volumen, Tarif, Mix und Effizienz.Die ersten 15 MinutenSichern Sie Rechnung, Traffic, Modellmix, Tokentypen,... Bei einem Kostensprung sichern Sie zuerst Beweise, bestätigen die Abrechnung und trennen Volumen, Tarif, Mix und Effizienz. Die ersten 15 Minuten Sichern Sie Rechnung, Traffic, Modellmix, Tokentypen, Retries und Deployments. Vergleichen Sie Provider-Abrechnung mit Gateway-Telemetrie. Sicher begrenzen Nutzen Sie die engste Kontrolle: Workflow pausieren, Agent begrenzen, Batch routen oder neue Funktion stoppen. Kritischen Traffic schützen; Besitzer, Ablauf und Rollback festlegen. Ursache und Abschluss Prüfen Sie Volumen, Mix, Kontext, Tools, Fehler und Tarife. Vergleichen Sie Kosten je erfolgreicher Aufgabe mit der Baseline und dokumentieren Sie die dauerhafte Maßnahme. Weiterführend LLM-Kostenüberwachung Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # LLM-Kostentrends 2025–2026 · FinOps LLM URL: https://finopsllm.com/de/research/llm-cost-trends-2025-2026 LLM-Kostentrends 2025–2026 Aktualisiert 15. Juli 2026 · ursprünglich veröffentlicht 4. Juli 2026 Der LLM-Markt bewegt sich gleichzeitig in zwei Richtungen. Die Input- und Output-Token-Preise für GPT-4-Klasse-Modelle sind seit Anfang 2024 um 80–90% gefallen. Zur gleichen Zeit sind Reasoning-Modelle (o1, o3, DeepSeek-R1, Claude Opus 4) pro Aufgabe 5–30x teurer als ihre Nicht-Reasoning-Äquivalente. Der Nettoeffekt: Teams, die Reasoning-Modelle einführen, sehen steigende Rechnungen, obwohl die Stückpreise fallen. Dieser Artikel verfolgt die wichtigsten Preis- und Qualitätsereignisse von 2025 bis Mitte 2026, erklärt die Kräfte, die Kosten treiben, und prognostiziert, was Sie in der zweiten Hälfte 2026 erwarten können. Schlüsseltrend 1: GPT-4-Klasse-Modelle fielen in 18 Monaten um 90% Im März 2024 kostete GPT-4-turbo $10 pro Million Input-Tokens und $30 pro Million Output-Tokens. Mitte 2026 kostet GPT-4.1 $2 pro Million Input und $8 pro Million Output – ein Rückgang von 75–80%. Claude folgte einer ähnlichen Entwicklung: Claude 3 Opus bei $15/$75 fiel auf Claude Sonnet 4 bei $3/$15. Open-Weight-Modelle von Mistral, Llama und DeepSeek drückten die Preise noch weiter, mit einigen verfügbar für unter $0,50 pro Million Input-Tokens durch gehostete Provider. Dies ist nicht nur ein Preiskrieg. Die Inferenz-Infrastruktur verbesserte sich: Quantisierung, spekulative Dekodierung, KV-Cache-Optimierung und Batch-Processing reduzierten alle die Kosten für die Verarbeitung eines Tokens. Provider gaben einige dieser Ersparnisse an Kunden weiter. Schlüsseltrend 2: Reasoning-Modelle sind 5–30x teurer Reasoning-Modelle (o1, o3, o4-mini, DeepSeek-R1, Claude Opus 4 mit erweitertem Denken) generieren interne „Denk"-Tokens, bevor sie eine endgültige Antwort produzieren. Diese Denk-Tokens werden als Output-Tokens abgerechnet. Ein Reasoning-Modell, das eine Coding-Aufgabe löst, könnte 10.000–50.000 Denk-Tokens generieren, bevor es eine 2.000-Token-Antwort produziert. Die effektiven Kosten pro Aufgabe sind daher viel höher als der pro-Token-Preis vermuten lässt. Für Teams, die Reasoning-Modelle für jede Aufgabe verwenden, ist dies der einzeln größte Kostenfahrer in 2026. Die Schlüsselfrage ist nicht „Wie viel kostet das Modell?" sondern „Benötigt diese Aufgabe Reasoning?" Die meisten Aufgaben benötigen es nicht. Schlüsseltrend 3: Open-Source schloss die Qualitätslücke Anfang 2024 hinken Open-Weight-Modelle proprietären Modellen um einen signifikanten Abstand bei Coding- und Reasoning-Benchmarks hinterher. Mitte 2026 sind Modelle wie Llama 4 Maverick, DeepSeek-V3, Qwen 3 und MiMo nur wenige Punkte vom GPT-4-Klasse-Performance in den meisten Benchmarks entfernt. Dies ist für die Kosten wichtig, weil Open-Weight-Modelle günstiger zu bedienen sind – Provider, die auf Preise konkurrieren, nutzen sie, um proprietäre Preisgestaltung zu unterbieten. Die Qualitätslücke hat sich nicht vollständig für Frontier-Reasoning-Aufgaben geschlossen. Aber für die meisten produktiven Workloads – Zusammenfassung, Extraktion, Klassifizierung, Code-Generierung, Tool-Nutzung – sind Open-Weight-Modelle ausreichend und erheblich günstiger. Schlüsseltrend 4: Caching reduzierte effektive Kosten um 50–90% für wiederholte Workloads Prompt Caching (Anthropic) und automatisches Context Caching (OpenAI, Google) änderten die Ökonomie wiederholter Workloads. Wenn Sie täglich das gleiche System-Prompt und den gleichen Context 100 Mal an ein Modell senden, kosten gepufferte Lese-Zugriffe 50–90% weniger als nicht gepufferte Lese-Zugriffe. Für RAG-Pipelines, Agent-Systeme und Batch-Verarbeitung ist dies transformativ. Caching-Vorteile sind ungleich verteilt. Workloads mit stabilem Context (gleicher System-Prompt, gleiche Dokumentsammlung) profitieren enorm. Workloads mit dynamischem Context (benutzerspezifische Konversationen, Echtzeitdaten) profitieren weniger. FinOps-Teams sollten ihre Cache-Hit-Rate messen und die Context-Stabilität optimieren, um Ersparnisse zu maximieren. Schlüsseltrend 5: Agent-Workflows vervielfachen den Token-Verbrauch Agent-Workflows – wo Modelle Tools aufrufen, Dateien lesen, Code ausführen und Ergebnisse iterieren – verbrauchen 5–50x mehr Tokens pro Aufgabe als Einzel-Runden-Interaktionen. Ein Coding-Agent, der einen Bug löst, könnte 100.000–500.000 Tokens über seine Tool-Aufrufe, Wiederholungen und Context-Ansammlung hinweg verbrauchen. Ein gleichwertiges Einzel-Runden-Prompt könnte 2.000–5.000 Tokens verwenden. Dies ist der wichtigste Kostentrend in 2026. Token-Preise fallen, aber Token-Verbrauch pro Aufgabe steigt schneller. Nettoergebnis: Die Gesamtausgaben für LLM steigen für die meisten Teams, selbst wenn die Stückpreise sinken. Zeitstrahl: wichtige Ereignisse Datum Ereignis Preisauswirkung Qualitätsauswirkung Mär 2024 GPT-4-turbo Einführung 50% günstiger als GPT-4 Vergleichbare Qualität Jun 2024 Claude 3.5 Sonnet Einführung 5x günstiger als Opus Nahezu Opus-Qualität Sep 2024 o1-preview Einführung 3–5x mehr pro Aufgabe (Reasoning) Großer Reasoning-Sprung Dez 2024 Google Gemini 2.0 Flash Unter $1/M Input-Tokens Stark für Geschwindigkeitsaufgaben Jan 2025 DeepSeek-R1 Open-Source 10x günstiger als o1 Nahe o1 Reasoning Feb 2025 Claude 3.5 Sonnet Preissenkung Weiterer 20%-Rückgang Gleiche Qualität Apr 2025 GPT-4.1 Einführung 30% günstiger als GPT-4-turbo Verbessertes Coding Mai 2025 Claude Sonnet 4 Einführung Gleicher Preis, bessere Qualität Signifikanter Coding-Sprung Jun 2025 OpenAI o3-mini Preissenkung 50% günstiger Reasoning Gleiche Qualität Jan 2026 DeepSeek-V3 gehostete Provider Unter $0,50/M Input-Tokens Nahe GPT-4-Klasse Apr 2026 Claude Opus 4 Einführung Premium-Preisgestaltung ($15/$75) Frontier Reasoning Jun 2026 Llama 4 Maverick gehostet Unter $0,30/M Input-Tokens Starke allgemeine Qualität Jul 2026 Anthropic Fable 5 / OpenAI GPT-5.6 Ebenen-Einführung Neue Frontier-Ebene ($5/$30), Mid-Tier-Preisgestaltung ($2,50/$15), Budget-Ebene ($1/$6) Fable 5 erreichte Opus 4-Performance Was Sie im zweiten Halbjahr 2026 erwarten können Reasoning-Modell-Preise werden um 30–50% fallen. Der Wettbewerb durch Open-Source-Reasoning-Modelle (DeepSeek-R2, Qwen 3 Reasoning-Varianten) wird proprietäre Provider zwingen, die Preise auf ihren Reasoning-Ebenen zu senken. Agent-spezifische Preisgestaltung wird auftauchen. Provider testen Pro-Aufgabe- und Pro-Sitzungs-Preismodelle, die Tool-Aufrufe, Wiederholungen und Context in einen einzigen vorhersagbaren Kostenzusammenfassen. Erwarten Sie, dass mindestens ein großer Provider dies bis Q4 2026 anbietet. Caching wird automatisch. Manuelle Cache-Verwaltung wird verschwinden. Provider werden die Cache-Platzierung transparent optimieren, und Cache-Hit-Raten werden sich für die meisten Workloads ohne Entwickler-Eingriff verbessern. Open-Weight-Modelle werden routinierte Arbeit dominieren. Bis Ende 2026, erwarten Sie, dass 70%+ der produktiven Inferenz bei routinierten Aufgaben (Klassifizierung, Extraktion, Zusammenfassung, einfache Code-Generierung) auf Open-Weight-Modellen durch gehostete Provider läuft. Die Gesamtausgaben werden weiter steigen. Trotz fallender Stückpreise bedeuten Agent-gesteuerte Workflows und die Ausweitung von KI-Anwendungsfällen, dass die Gesamtausgaben für LLM weiter wachsen. FinOps-Disziplin – nicht nur billigere Modelle – ist das, was die Ausgaben unter Kontrolle hält. Verwandt Agent-Ökonomie – wie Coding-Agents in der Praxis preislich ausgehen. Provider-Arbitrage – Anbieter wechseln, um Kosten zu reduzieren. Modell-Routing – Aufgaben zum richtigen Modell senden. FinOps für LLM – das breitere Framework. Wollen Sie das auf Ihre eigenen LLM-Ausgaben anwenden? FinOps LLM führt ein kostenloses Audit Ihrer KI-Kosten durch und zeigt Ihnen, wo die Ersparnisse liegen. Buchen Sie kostenlos Audit → Zurück zur Forschung --- # Auswirkung von MCP-Servern auf Kosten · FinOps LLM URL: https://finopsllm.com/de/research/mcp-server-cost-impact Auswirkung von MCP-Servern auf Kosten Das Model Context Protocol (MCP) ermöglicht LLMs, externe Werkzeuge aufzurufen: Datenbanken, APIs, Dateisysteme, Suchmaschinen. Das ist mächtig. Es ist auch teuer. Jede MCP-Werkzeugdefinition verbraucht Speicherplatz im Kontextfenster, jeder Werkzeugaufruf ist eine separate API-Hin- und Rückfahrt, und jedes Werkzeugergebnis wird dem Modell als zusätzliche Eingabe-Tokens zurückgeführt. Für Teams, die MCP-intensive Agenten-Workflows ausführen, kann der werkzeugbezogene Overhead 30–60% der Gesamtausgaben für Tokens ausmachen. Dieser Artikel erläutert, wie MCP die Kosten erhöht, wie Sie den Overhead messen und was Sie dagegen tun können. Wie MCP Token verbraucht Bei jeder MCP-Interaktion gibt es drei Token-Kostenebenen: Ebene 1: Werkzeugdefinitionen. Jeder MCP-Server registriert Werkzeuge beim Modell. Eine Werkzeugdefinition umfasst den Funktionsnamen, das Parameterschema und eine Beschreibung der Funktion des Werkzeugs. Eine einzelne Werkzeugdefinition verbraucht typischerweise 500–2.000 Token. Ein Server mit 15 Werkzeugen fügt 7,5K–30K Token zu jeder Anfrage hinzu – selbst wenn keines dieser Werkzeuge aufgerufen wird. Ebene 2: Anfragen für Werkzeugaufrufe. Wenn das Modell beschließt, ein Werkzeug aufzurufen, generiert es eine Werkzeugaufrufsausgabe (Funktionsname + Argumente). Dies wird als Ausgabe-Tokens abgerechnet. Das Werkzeugergebnis kommt dann als Eingabe-Tokens zurück. Eine einzelne Werkzeugaufrufs-Hin- und Rückfahrt kostet typischerweise 1K–5K Token, abhängig von der Ergebnisgröße. Ebene 3: Werkzeugergebnisse im Kontext. Werkzeugergebnisse bleiben im Kontext der Konversation für alle nachfolgenden Umdrehungen. Wenn Sie 10 Werkzeuge in einer Sitzung aufrufen, sammeln sich diese Ergebnisse an. Eine Datenbankabfrage, die 50 Zeilen JSON zurückgibt, kann 8K–15K Token hinzufügen, die für den Rest der Konversation erhalten bleiben. Der zusammengesetzte Effekt MCP-Kosten sind zusammengesetzt, da Werkzeugdefinitionen mit jeder Anfrage gesendet werden. Wenn Sie 20 Werkzeuge definiert haben (10K–40K Token Definitionen) und 5 Anfragen in einer Konversation stellen, kosten nur die Werkzeugdefinitionen 50K–200K Eingabe-Tokens. Fügen Sie die Werkzeugaufrufergebnisse hinzu, und Sie können leicht den doppelten Baseline-Token-Verbrauch erreichen. MCP-Muster Token-Overhead Häufigkeit Geschätzter monatlicher Kosteneinfluss Werkzeugdefinitionen (10 Werkzeuge) 5K–20K Token pro Anfrage Jede Anfrage 15–60 $ pro Benutzer Hin- und Rückfahrt eines einzelnen Werkzeugaufrufs 1K–5K Token 3–10 pro Sitzung 5–25 $ pro Benutzer Großes Werkzeugergebnis (Datenbankabfrage, Code-Suche) 5K–20K Token 1–5 pro Sitzung 10–50 $ pro Benutzer Angesammelte Ergebnisse in längerer Sitzung 20K–100K Token 1–3 Sitzungen/Tag 30–120 $ pro Benutzer Ungenutzte Werkzeugdefinitionen geladen 5K–30K Token pro Anfrage Jede Anfrage 15–90 $ pro Benutzer Wie Sie den MCP-Overhead messen Die einfachste Methode, um MCP-Kosten zu messen, besteht darin, die gleiche Eingabeaufforderung zweimal auszuführen: einmal mit geladenen MCP-Werkzeugen und einmal ohne. Der Unterschied in den Eingabe-Tokens ist Ihr Overhead der Werkzeugdefinitionen. Zählen Sie dann die Token für Werkzeugaufrufe separat – die meisten Anbieter kennzeichnen sie deutlich in ihren Abrechnungs-Dashboards. Für eine präzisere Messung instrumentieren Sie Ihren MCP-Client, um Folgendes protokollieren zu können: Anzahl der registrierten Werkzeuge, durch Werkzeugdefinitionen pro Anfrage verbrauchte Token, Anzahl der Werkzeugaufrufe pro Sitzung, Token pro Werkzeugergebnis und gesamte Sitzungs-Token, die der Werkzeugaktivität zugeordnet sind. Strategien zur Reduzierung der MCP-Kosten 1. Laden Sie Werkzeuge selektiv. Registrieren Sie nicht alle Werkzeuge für jede Anfrage. Wenn der Benutzer eine Code-Frage stellt, benötigt er keine Datenbank- oder Bereitstellungswerkzeuge geladen. Viele MCP-Clients unterstützen dynamisches Werkzeugladen basierend auf Kontext oder expliziter Benutzeraktivierung. 2. Minimieren Sie Werkzeugbeschreibungen. Werkzeugbeschreibungen sind der größte Token-Verbraucher in Definitionen. Eine ausführliche Beschreibung kann 500 Token sein; eine prägnante kann 100 Token sein. Über 20 Werkzeuge verteilt ist das ein Unterschied von 8K Token pro Anfrage. 3. Schneiden Sie Werkzeugergebnisse ab. Geben Sie nur die Felder zurück, die das Modell tatsächlich benötigt. Wenn eine Datenbankabfrage 20 Spalten zurückgibt, aber das Modell nur 3 benötigt, projizieren Sie das Ergebnis. Begrenzen Sie die Ergebnisgröße auf ein vernünftiges Limit – 2K–4K Token sind normalerweise ausreichend, damit das Modell eine Entscheidung treffen kann. 4. Zwischenspeichern Sie wiederholte Aufrufe. Wenn das gleiche Werkzeug mit den gleichen Argumenten in einer Sitzung aufgerufen wird, geben Sie das zwischengespeicherte Ergebnis zurück, anstatt erneut auszuführen. Dies ist besonders wertvoll für Referenzabfragen, Schemaabfragen und Dokumentationsfetches. 5. Fassen Sie vor dem Injizieren zusammen. Für große Werkzeugergebnisse (vollständige Dateiinhalte, lange API-Antworten) fassen Sie vor dem Hinzufügen zum Kontext zusammen. Geben Sie eine Zusammenfassung plus die Möglichkeit zurück, das vollständige Ergebnis zu abrufen, wenn das Modell es benötigt. 6. Verwenden Sie Budgetlimits für Werkzeugergebnisse. Legen Sie ein pro-Sitzung-Budget für Werkzeugergebnis-Tokens fest. Wenn das Budget erreicht ist, lehnen Sie weitere Werkzeugaufrufe ab oder wechseln Sie für den Rest der Sitzung zu einem günstigeren Modell. Die versteckten Kosten von MCP-Servern Jenseits der Token-Kosten führen MCP-Server Latenz- und Zuverlässigkeits-Overhead ein. Ein Werkzeugaufruf, der 3 Sekunden zum Antworten benötigt, fügt Latenz zu jeder Umdrehung hinzu. Ein Werkzeug, das zeitweise ausfällt, verursacht Wiederholungen. Beide erhöhen die effektiven Kosten pro Aufgabe. Für Teams, die die MCP-Nutzung in einer Organisation skalieren, ist die Verfolgung dieser Kosten auf Serverebene unerlässlich. Leiten Sie MCP-intensive Workloads zu Modellen mit niedrigeren Pro-Token-Kosten weiter, und behalten Sie MCP-leichte Workflows auf Premium-Modellen, wo Latenz wichtig ist. Verwandte Inhalte Agent-Ökonomie – wie sich die Preisgestaltung für Codierungs-Agenten in der Praxis darstellt. Zuordnung der Agent-Ausgaben – Verfolgung der Agent-Kosten nach Projekt. LLM-Token-Nachverfolgung – Messung Ihrer Ausgaben. FinOps für LLM – das breitere Framework. Möchten Sie dies auf Ihre eigenen LLM-Ausgaben anwenden? FinOps LLM führt eine kostenlose Audit Ihrer KI-Kosten durch und zeigt, wo die Einsparungen möglich sind. Buchen Sie Ihre kostenlose Audit → Zurück zur Forschung --- # Token-Kosten von MCP-Tool-Definitionen senken · FinOps LLM URL: https://finopsllm.com/de/research/mcp-tool-definition-overhead Token-Kosten von MCP-Tool-Definitionen in Agenten senken Aktualisiert September 19, 2026 · erstveröffentlicht September 19, 2026 Kurzantwort: Die Anbindung von KI-Agenten an mehrere Model Context Protocol (MCP) Server injiziert bei jedem Turn tausende Input-Tokens, bevor die eigentliche Nutzerabsicht verarbeitet wird. Jedes registrierte... Die Anbindung von KI-Agenten an mehrere Model Context Protocol (MCP) Server injiziert bei jedem Turn tausende Input-Tokens, bevor die eigentliche Nutzerabsicht verarbeitet wird. Jedes registrierte Tool fügt JSON-Schemas mit Funktionsnamen, Parameterbeschreibungen und Typen ein. Bei typischen Setups mit 6 Servern (GitHub, Postgres, Jira) summiert sich dieser Tool-Vorspann auf 4.500 bis 12.000 Tokens pro API-Aufruf. Warum verbrauchen MCP-Tool-Definitionen so viele Tokens? Jedes MCP-Tool benötigt vollständige JSON-Schema-Deklarationen, damit das Modell Funktionsaufrufe fehlerfrei strukturieren kann. Eine detaillierte SQL-Funktion belegt oft 400 bis 600 Tokens. Über dutzende Tools hinweg verdrängen statische Schemas den dynamischen Gesprächskontext. Architekturmuster zur Kostenkontrolle Plattform-Teams nutzen Prompt-Caching-Breakpoints hinter dem Tool-Block, zweistufiges semantisches Tool-Routing zur selektiven Injektion relevanter Schemas und kompakte Schema-Minifizierung zur Reduktion des Payload-Volumens. Weiterführend Server-Tools und Rechnungen Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Preissenkungen senken die KI-Rechnung nicht von allein · FinOps LLM URL: https://finopsllm.com/de/research/model-price-cuts-routing-budget Modell-Preissenkungen und das Routing-Budget Aktualisiert September 10, 2026 · erstveröffentlicht September 10, 2026 Kurzantwort: Niedrigere Listenpreise führen selten automatisch zu sinkenden Ausgaben. Teams erweitern oft Context-Fenster oder behalten teure Routings bei. Entscheidend ist, ob die Kosten je erfolgreicher Aufgabe... Niedrigere Listenpreise führen selten automatisch zu sinkenden Ausgaben. Teams erweitern oft Context-Fenster oder behalten teure Routings bei. Entscheidend ist, ob die Kosten je erfolgreicher Aufgabe sinken. Routing neu tarieren Klassifizieren Sie Workloads nach Qualität und Latenzanforderungen und testen Sie neue, günstigere Modell-Tiers hinter Feature-Flags. Weiterführend Kosten je erfolgreicher Aufgabe Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Sicherheitschecks sind eine zweite Rechnung · FinOps LLM URL: https://finopsllm.com/de/research/moderation-pass-second-bill Was Guardrails und Moderation kosten Aktualisiert September 1, 2026 · erstveröffentlicht September 1, 2026 Kurzantwort: Ein produktives LLM-Feature macht selten nur einen Aufruf. Es macht den geplanten und danach die nachträglich ergänzten Sicherheitsaufrufe: Eingabeklassifikator, Ausgabeprüfung, Policy-Judge, manchmal... Ein produktives LLM-Feature macht selten nur einen Aufruf. Es macht den geplanten und danach die nachträglich ergänzten Sicherheitsaufrufe: Eingabeklassifikator, Ausgabeprüfung, Policy-Judge, manchmal ein zweites Modell, das das erste bewertet. Alles davon ist Inferenz, und Inferenz wird abgerechnet. Der Multiplikator ist größer als er wirkt Eingabemoderation liest die gesamte Eingabe, Ausgabemoderation die gesamte Antwort. Ein Judge liest beides plus abgerufenen Kontext und ein Bewertungsraster — sein Aufruf ist damit größer als der bewertete. Wo die Ausgaben auflaufen Drei Muster: Bewerten mit einem Spitzenmodell aus Bequemlichkeit (Klassifikation ist genau die Aufgabe, für die ein kleines Modell reicht — oft die größte verfügbare Ersparnis); Prüfen in jedem Turn mit erneutem Scan bereits freigegebener Historie; und Guardrails auf internem Verkehr , der den vollen Endkunden-Sicherheitsstack erbt, ohne ihn zu brauchen. Als eigene Position budgetieren Es geht nicht darum, die Prüfungen zu streichen, sondern darum, dass sie 30–50% der Inferenzkosten ausmachen können, ohne im Plan aufzutauchen. Guardrail-Aufrufe in der Telemetrie separat taggen. Weiterführend LLM-Kostenzuordnung Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Auch Ihre Dev-Umgebung kostet Tokens · FinOps LLM URL: https://finopsllm.com/de/research/non-production-llm-spend LLM-Ausgaben außerhalb der Produktion Aktualisiert September 1, 2026 · erstveröffentlicht September 1, 2026 Kurzantwort: Jede FinOps-Prüfung beginnt beim Produktionsverkehr, weil es dafür ein Dashboard gibt. Dann schlüsselt jemand nach Umgebung auf und findet, dass ein spürbarer Teil der Rechnung — oft ein... Jede FinOps-Prüfung beginnt beim Produktionsverkehr, weil es dafür ein Dashboard gibt. Dann schlüsselt jemand nach Umgebung auf und findet, dass ein spürbarer Teil der Rechnung — oft ein zweistelliger Prozentsatz — nie einen Kunden erreicht hat. Woher es kommt CI: jeder Pull Request mit Evaluierungs-Suite ruft das Modell auf, tausende Male am Tag, auf dem teuersten Modell. Lokale Entwicklung: Prompt-Iteration sind Dutzende Aufrufe pro Stunde, auf einem gemeinsamen Key, ohne Tagging. Staging und Demos: konfiguriert wie Produktion, also teures Modell ohne Caching. Retries und entlaufene Schleifen im Test , die niemand beobachtet. Zuerst die Zuordnung Die Änderung, die sich selbst bezahlt: ein eigener API-Key je Umgebung . Ein Nachmittag Arbeit, und aus einer unerklärten Position werden vier beschriftete. Taggen Sie die Umgebung an jeder Anfrage, in der CI auch Repository und Workflow. Danach folgt dreierlei: außerhalb der Produktion genügt fast immer ein kleineres Modell; Caching zahlt sich nirgends mehr aus, weil CI nahezu identische Prompts wiederholt; und harte Ausgabengrenzen sind hier wirklich sicher — eine gedeckelte Testumgebung bricht einen Build, eine gedeckelte Produktion bricht einen Kunden. Weiterführend LLM-Kostenzuordnung Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # KI-Observability kann zur zweiten LLM-Rechnung werden · FinOps LLM URL: https://finopsllm.com/de/research/observability-second-llm-bill Wenn KI-Observability zur zweiten Rechnung wird Aktualisiert September 9, 2026 · erstveröffentlicht September 9, 2026 Kurzantwort: Observability soll KI-Kosten transparent machen. Wenn jedoch jede Antwort von einem Richter-Modell evaluiert und zusammengefasst wird, verdoppelt sich der Tokenverbrauch unbemerkt. Sekundärausgaben... Observability soll KI-Kosten transparent machen. Wenn jedoch jede Antwort von einem Richter-Modell evaluiert und zusammengefasst wird, verdoppelt sich der Tokenverbrauch unbemerkt. Sekundärausgaben sauber zuweisen Versehen Sie Evaluierungs-Calls mit Zweck-Tags und der Eltern-ID, um die tatsächlichen Gesamtkosten je Feature zu erfassen. Weiterführend Kostenkontrolle für Evaluierungen Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Open-Source vs Closed-Source LLM-Kostenvergleich · FinOps LLM URL: https://finopsllm.com/de/research/open-source-vs-closed-cost Open-Source vs Closed-Source LLM-Kostenvergleich Aktualisiert 15. Juli 2026 · erstmals veröffentlicht 4. Juli 2026 Wann ist es rentabel, Llama, Qwen oder DeepSeek selbst zu hosten, im Vergleich zum Bezahlen von API-Zugang? Diese Analyse behandelt GPU-Kosten, Inferenz-Optimierung, Betriebsausgaben und bietet einen Entscheidungsrahmen für Ihre spezifische Workload. 8 Modelle verglichen 5 GPU-Ebenen analysiert 3 Break-Even-Szenarien Jul 2026 Zuletzt aktualisiert Self-Hosting-Kosten gehen von Cloud-GPU-Preisen (auf Abruf) aus API-Kosten verwenden Standard-Ausgangspreise pro Anbieter Break-Even basiert auf 70% Auslastung, 24/7 Verfügbarkeit Methodologie API-Preisgestaltung Standardtarife, die auf der Preisseite des Anbieters veröffentlicht sind. Keine Batch- oder Volumenrabatte angewendet. Self-Hosting GPU Cloud-GPU-Preise auf Abruf (Lambda, RunPod, AWS) für Inferenz-optimierte Setups mit vLLM oder TensorRT-LLM. Betriebsausgaben Beinhaltet Überwachung, Skalierung, Modellaktualisierungen und einen 15%-Betriebszuschlag auf rohe GPU-Kosten für verwaltete Infrastruktur. Qualitätslücke Relativ zu GPT-4o / Claude Sonnet 4 als Baseline 100%. Basierend auf öffentlichen Benchmarks und praktischer Aufgabenleistung. Kostenvergleichstabelle Modell ↕ API-Kosten/Monat ↕ Self-Hosting-Kosten (Cloud-GPU) ↕ Break-Even-Volumen ↕ Qualitätslücke Llama 4 Maverick (DeepInfra) $260/Monat $2.800/Monat ~350 Mio. Tokens/Monat ~95% von GPT-4o Llama 3.3 70B (Groq) $277/Monat $1.200/Monat ~210 Mio. Tokens/Monat ~87% von GPT-4o Llama 4 Scout (Groq) $136/Monat $1.400/Monat ~350 Mio. Tokens/Monat ~88% von GPT-4o Qwen 3.7-Max $525/Monat $1.600/Monat ~100 Mio. Tokens/Monat ~92% von GPT-4o DeepSeek V4 Pro $435/Monat $1.800/Monat ~130 Mio. Tokens/Monat ~96% von GPT-4o DeepSeek V4 Flash $140/Monat $1.400/Monat ~450 Mio. Tokens/Monat ~82% von GPT-4o Mistral Medium 3.5 $525/Monat $2.000/Monat ~120 Mio. Tokens/Monat ~91% von GPT-4o GPT-4o (nur API) $750/Monat N/A N/A Baseline (100%) API-Kosten/Monat gehen von 100 Millionen Ausgabe-Tokens + 300 Millionen Eingabe-Tokens pro Monat zu Standardtarifen aus. Self-Hosting-Kosten beinhalten GPU-Miete, 15% Betriebsaufwand und Inferenz-Stack (vLLM). Enthält nicht die anfängliche Einrichtungszeit für Engineering. Break-Even-Volumen ist die Anzahl der monatlichen Ausgabe-Tokens, bei der Self-Hosting günstiger wird als die API. Qualitätslücke ist ungefähr und aufgabenabhängig. Benchmarks wie MMLU, HumanEval und GPQA informieren diese Schätzungen. Einige Links können Referral-Codes enthalten. Wichtige Kostenfaktoren 1) GPU-Miete ist der dominierende Kostenfaktor Ein 8x H100-Knoten für Llama 4 Maverick kostet 2.000–3.500 USD/Monat auf Abruf von Lambda, RunPod oder AWS. Spot-/Preemptible-Instanzen können dies um 40–60% reduzieren, fügen aber Neustartlatenz und Verfügbarkeitsrisiken hinzu. Bei Produktions-Workloads sparen reservierte Instanzen (1-Jahr-Verpflichtung) in der Regel 30–40% gegenüber On-Demand. 2) Inferenz-Optimierung ändert die Gleichung vLLM mit kontinuierlichem Batching, KV-Cache-Paging und Quantisierung (GPTQ/AWQ 4-Bit) können den Durchsatz um das 2–4-fache auf der gleichen Hardware erhöhen. TensorRT-LLM fügt weitere 20–40% für unterstützte Architekturen hinzu. Ein gut abgestimmter 4-Bit Llama 4 Scout auf einer einzelnen A100 kann ein naives fp16-Setup auf 2x A100s erreichen. 3) Betriebsausgaben sind real, aber schrumpfen Das Betreiben von Inferenz-Infrastruktur erfordert GPU-Überwachung, Modellaktualisierungen, Lastausgleich und Failover. Berechnen Sie 15–25% der rohen GPU-Kosten für Betrieb. Verwaltete Plattformen (Anyscale, Modal, Replicate) absorbieren dies, berechnen aber 30–50% Aufschlag auf rohe GPU - lohnt sich unterhalb von ~5.000 USD/Monat GPU-Ausgaben. 4) Prompt Caching verengt die Lücke für APIs API-Anbieter bieten zunehmend Prompt Caching an (50–90% Rabatt auf wiederholte Präfixe). Wenn Ihre Workload Cache-freundlich ist (RAG, Multi-Turn), sinken API-Kosten erheblich und drücken das Break-Even-Volumen für Self-Hosting höher. Entscheidungsrahmen Verwenden Sie APIs, wenn... Das monatliche Ausgabe-Volumen unter 100 Millionen Tokens liegt Sie Frontier-Modell-Qualität benötigen (GPT-4o, Claude Opus 4) Ihr Team keine GPU/MLOps-Expertise hat Latenzanforderungen streng sind (unter 200 ms TTFT) Sie null Betriebsausgaben wünschen Ihre Workload volatile oder saisonal ist Self-Host, wenn... Das monatliche Ausgabe-Volumen konsistent über 200 Millionen Tokens liegt Datenschutz erfordert keine Drittanbieter-API-Aufrufe Sie benutzerdefinierte Fine-Tuned-Modelle benötigen Sie MLOps-Kapazität im Team haben Die Workload ist im stabilen Zustand (vorhersehbare GPU-Auslastung) Sie sich zu reservierten 1-Jahr-GPU-Instanzen verpflichten können Hybrid-Ansatz: der pragmatische Mittelweg Die meisten Teams landen auf einem Hybrid-Ansatz: Verwenden Sie APIs für Frontier-Reasoning-Aufgaben und Low-Volume-Workloads, selbst gehostete Open-Source-Modelle für High-Volume-, latenztolerante Aufgaben (Content-Generierung, Datenextraktion, interne Tools). Dies hält die API-Ausgaben unter Kontrolle, während Sie die Self-Hosting-Kapazität inkrementell aufbauen. Wo führe ich Open-Source-Modelle aus Plattform GPU-Optionen Preis A100 80GB H100-Preis Verwaltete Inferenz Lambda Cloud A100, H100, H200 $1,10/Std. $2,49/Std. Nein (Bringen Sie Ihren eigenen mit) RunPod A100, H100, L40S $1,19/Std. $2,69/Std. Serverlose Option AWS (p4d/p5) A100, H100 $3,67/Std. $6,37/Std. SageMaker Google Cloud A100, H100 $3,22/Std. $5,07/Std. Vertex AI Xiaomi MiMO ↗ API-basiert N/A N/A API ($0,50/$2,00 pro 1 Mio.) GPU-Preise sind On-Demand-Stundensätze ab Juli 2026. Reservierte/Spot-Preise variieren erheblich. MiMO bietet API-basierten Zugriff auf MiMo-V2-Pro und MiMo-V2-Omni zu wettbewerbsfähigen Raten - ein Mittelweg zwischen vollständigem Self-Hosting und Premium-API-Preisen. Möchten Sie dies auf Ihre eigenen LLM-Ausgaben anwenden? FinOps LLM führt eine kostenlose Prüfung Ihrer KI-Kosten durch und zeigt, wo die Einsparungen möglich sind. Kostenlose Audit buchen → Zurück zur Forschung FAQ Was ist die Methodik? Standardtarife, die auf der Preisseite des Anbieters veröffentlicht sind. Keine Batch- oder Volumenrabatte angewendet. Self-Hosting GPU-Cloud-Preise auf Abruf (Lambda, RunPod, AWS) für Inferenz-optimierte Setups mit vLLM oder TensorRT-LLM. Was ist die Kostenvergleichstabelle? API-Kosten/Monat gehen von 100 Millionen Ausgabe-Tokens + 300 Millionen Eingabe-Tokens pro Monat zu Standardtarifen aus. Self-Hosting-Kosten beinhalten GPU-Miete, 15% Betriebsaufwand und Inferenz-Stack (vLLM). Enthält nicht die anfängliche Einrichtungszeit für Engineering. Was sind die wichtigsten Kostenfaktoren? Ein 8x H100-Knoten für Llama 4 Maverick kostet 2.000–3.500 USD/Monat auf Abruf von Lambda, RunPod oder AWS. Spot-/Preemptible-Instanzen können dies um 40–60% reduzieren, fügen aber Neustartlatenz und Verfügbarkeitsrisiken hinzu. Bei Produktions-Workloads sparen reservierte Instanzen (1-Jahr-Verpflichtung) in der Regel 30–40% gegenüber On-Demand. Was ist der Entscheidungsrahmen? Die meisten Teams landen auf einem Hybrid-Ansatz: Verwenden Sie APIs für Frontier-Reasoning-Aufgaben und Low-Volume-Workloads, selbst gehostete Open-Source-Modelle für High-Volume-, latenztolerante Aufgaben (Content-Generierung, Datenextraktion, interne Tools). Wo führe ich Open-Source-Modelle aus? GPU-Preise sind On-Demand-Stundensätze ab Juli 2026. Reservierte/Spot-Preise variieren erheblich. MiMO bietet API-basierten Zugriff auf MiMo-V2-Pro und MiMo-V2-Omni zu wettbewerbsfähigen Raten - ein Mittelweg zwischen vollständigem Self-Hosting und Premium-API-Preisen. --- # OpenAI-Kostenattribution · FinOps LLM URL: https://finopsllm.com/de/research/openai-cost-attribution OpenAI-Kostenattribution OpenAI-Kostenattribution beginnt bevor die Anfrage gesendet wird. Die API-Antwort kann dir Token-Nutzung zeigen, aber sie kann nicht wissen welche Produktoberfläche, welches Team, welcher Kunde oder welcher Business-Workflow den Aufruf verursacht hat, es sei denn deine Anwendung hängt diesen Kontext an. Attribution muss drei Quellen kombinieren: Anfrage-Metadaten, Nutzungsprotokolle und Rechnungsdaten. Anfrage-Metadaten bieten Eigentum. Nutzungsprotokolle bieten Token-Zählungen und Modell. Rechnungsdaten bieten die autoritative finanzielle Summe. Zu erfassende Labels Funktionsname oder Endpoint. Team-Eigentümer und Umgebung. Projekt oder Kunde wenn zulässig. Workload-Klasse wie Echtzeit, Batch, Evaluation, Support oder Agent-Schritt. Prompt-Version, Routing-Richtlinie und Fallback-Status. Häufige Attribution-Lücken Teams verlieren oft Wiederholungen und Fallbacks. Ein Benutzer sieht eine Antwort, aber das System könnte mehrere upstream Aufrufe bezahlt haben. Eine andere häufige Lücke ist Batch-Arbeit: Evaluations und Anreicherungs-Jobs sollten separat vom Benutzer-orientierten Traffic kennzeichnet werden damit sie zu asynchronen Low-Cost-Lanes verschoben werden können. Die besten OpenAI-Attribution Berichte stoppen nicht bei "welches Modell kostet mehr". Sie zeigen welche Produktentscheidung dazu führte dass dieses Modell verwendet wurde, und welcher Eigentümer es ändern kann. Verwandt LLM-Kostenattribution - allgemeine Attribution Prinzipien. Anthropic-Kostenattribution - Attribution für Anthropic-Modelle. Was ist LLM FinOps? - die vollständige operative Disziplin. Wo sollten die Metadaten angehängt werden? An der äußersten Grenze, die noch weiß, warum der Aufruf stattfindet — in der Regel im Handler oder Job, der die Nutzeraktion entgegengenommen hat, nicht im SDK-Wrapper. Attribution tief in einem gemeinsam genutzten Client ist bereits zu spät: Der Request hat dort den Produktkontext verloren, und jeder Aufrufer sieht gleich aus. Reichen Sie ein explizites Kontextobjekt durch und lassen Sie den Client daraus lesen, damit keine neue Aufrufstelle ohne Eigentümer hinzugefügt werden kann. Warum beantwortet das OpenAI-Dashboard das nicht? Die Nutzungsübersicht aggregiert nach API-Key, Modell und Projekt. Das ist Infrastruktur-Attribution, keine Business-Attribution — sie zeigt, welcher Key das Geld ausgegeben hat, nicht welches Feature oder welcher Kunde. Der übliche Workaround, pro Team einen eigenen Key zu vergeben, hält nicht lange: Keys vermehren sich, gemeinsam genutzte Dienste bekommen einen Key ohne Eigentümer, und ein einzelner Agent-Lauf über drei Features bleibt weiterhin nicht zuordenbar. Wie attribuiert man Agenten und mehrstufige Workloads? Betrachten Sie den gesamten Lauf als Einheit, nicht den einzelnen Aufruf. Ein Agent, der plant, drei Tools aufruft und einmal wiederholt, erzeugt fünf abrechenbare Requests für eine Nutzeraktion — pro Aufruf betrachtet wirkt jeder günstig, während der Lauf teuer ist. Geben Sie jedem Schritt eine Run-ID, rollen Sie die Kosten auf den Lauf hoch und berichten Sie Kosten pro abgeschlossenem Lauf. Das ist die Zahl, die dem tatsächlichen Preis des Features entspricht. Möchten Sie dies auf Ihre eigenen LLM-Ausgaben anwenden? FinOps LLM führt ein kostenloses Audit Ihrer AI-Kosten durch und zeigt Ihnen, wo Einsparungen möglich sind. Kostenloses Audit anfordern → Zurück zur Forschung --- # Kostenstruktur der OpenAI Fine-Tuning Sunset · FinOps LLM URL: https://finopsllm.com/de/research/openai-fine-tuning-sunset-economics Kostenstruktur der OpenAI Fine-Tuning Sunset Veröffentlicht 19. Juli 2026 OpenAI beendet das Self-Service Fine-Tuning. Ab dem 7. Mai 2026 können neue Organisationen keine Fine-Tuning-Jobs mehr erstellen. Bis zum 6. Januar 2027 verlieren alle Organisationen diese Funktion. Falls Sie auf Fine-Tuning GPT-Modelle angewiesen sind, müssen Sie jetzt einen Migrationspfad wählen: Prompt Engineering auf GPT-5.5 mit Prompt Caching, Open-Source LoRA-Adapter auf Llama oder Qwen, oder verwaltetes Fine-Tuning über Vertex AI, AWS Bedrock oder Mistral. Jeder Pfad hat unterschiedliche Kosten- und Operational-Tradeoffs. Self-Service Fine-Tuning endet 6. Januar 2027 für alle Organisationen Inferenz für bestehende Fine-Tuning-Modelle dauert bis zur Basismodel-Deprecation an Prompt Caching auf GPT-5.5 kann Fine-Tuning ROI bei 10–30 Treffern erreichen oder übertreffen Open-Source LoRA kostet 30–50% weniger als verwaltete Services bei hohem Volumen Versteckte Migrationskosten: Neubewertungen, Regressionstests, Dual-Running, Umschulung Frist: Organisationen müssen sich bis 6. Januar 2027 auf einen Migrationspfad festlegen. Bestehende Fine-Tuning-Modelle bedienen weiterhin Inferenzanfragen bis zur Deprecation ihres Basismodells, aber Sie können nach diesem Datum keine neuen Trainingsjobs erstellen. Zeitplan und Expositionsmatrix Wer ist betroffen und wann: Datum Phase Betroffene Organisationen Erforderliche Maßnahme 7. Mai 2026 Phase 1 Neue Organisationen, nie zuvor Fine-Tuned Können keine neuen Jobs starten 2. Juli 2026 Phase 2 Bestehende Organisationen ohne Fine-Tuning-Modell-Inferenz in den letzten 60 Tagen Können keine neuen Jobs starten 6. Januar 2027 Phase 3 (endgültig) Alle Organisationen, auch aktive Nutzer Keine neuen Trainingsjobs Nach 2027 Nur Inferenz Alle Organisationen mit bereitgestellten Fine-Tuning-Modellen Inferenz läuft bis zum Basismodel-Sunset weiter Warum OpenAI Fine-Tuning beendet: GPT-5.5–Klasse Basismodelle kombiniert mit Prompt Caching eliminieren die Notwendigkeit von Fine-Tuning in den meisten Use Cases. Längere Prompts mit Few-Shot-Beispielen und System-Anweisungen entsprechen nun der Fine-Tuning-Performance oder übertreffen sie, während sie weniger Gesamttoken verbrauchen, wenn gecacht. Der verwaltete Fine-Tuning-Overhead übersteigt seinen Wert für die meisten Workloads. Entscheidungsbaum: Drei Migrationspfade Pfad 1: Prompt Engineering + GPT-5.5 + Caching Schreiben Sie Fine-Tuning-Logik als Systemprompt + Few-Shot-Beispiele um, gecacht. Tauschen Sie längere Prompts gegen null Trainings-Overhead ein. Trainingskosten: $0 (keine Umschulung) Token-Kosten pro Call: Längerer Prompt, aber gecacht zu 50% der frischen Rate Setup-Zeit: 1–4 Wochen (Prompt Engineering + Benchmarking) Laufende Ops: Prompt-Iteration, keine MLOps notwendig Pfad 2: LoRA auf Open-Source (Together, Fireworks, Groq) Fine-Tune Llama 4 oder Qwen 3.5 mit LoRA-Adaptern, hosten Sie auf verwalteter Inferenz. Vollständige Fine-Tuning-Kontrolle, Open-Source-Reproduzierbarkeit. Trainingskosten: $200–$500 pro Job Inferenzkosten: $0,10–$0,30/M Tokens (wettbewerbsfähig) Setup-Zeit: 2–6 Wochen (Datenvorbereitung, Adapter-Training, Tests) Laufende Ops: Adapter-Performance überwachen, nach Bedarf umschulen Pfad 3: Verwaltetes Fine-Tuning (Vertex, Bedrock, Mistral) Nutzen Sie Google Vertex AI, AWS Bedrock oder Mistrals Fine-Tuning. Vertrauter Workflow, Vendor-Support, aber höhere Pro-Token-Kosten. Trainingskosten: $500–$2.000 pro Job Inferenzkosten: $0,20–$1,00/M Tokens (Premium) Setup-Zeit: 1–3 Wochen (weniger Integrationen erforderlich) Laufende Ops: Vendor handhabt Ops, Sie verwalten Trainings-Kadenz Pfad 1: Prompt Engineering + GPT-5.5 Caching — durchgerechnete Mathematik Angenommen Sie hatten ein Fine-Tuning GPT-4-Modell für Kundenservice-Ticketklassifizierung. Das Fine-Tuning-Modell wurde auf 10K gekennzeichnete Tickets trainiert. Jede Anfrage sendet ~500 Input-Tokens, erhält ~50 Output-Tokens zurück. Alte Kosten (Fine-Tuning): Fine-Tuning-Job: ~$50. Inferenz bei 100K Calls/Monat: (500 Input × $3/M + 50 Output × $15/M) × 100K = $150/Monat + Training = ~$200/Monat Gesamtkosten. Neue Kosten (Prompt Caching auf GPT-5.5): Erstellen Sie einen Systemprompt mit 40 Few-Shot-Beispielen (je ~200 Tokens) = 8K Tokens. Dies ist der Cache-Fill. Erster Call: 8K × (1,25× $3/M) + 500 × $3/M + 50 × $15/M ≈ $0,045. Nachfolgende Calls (Cache Hit): 500 × (0,5× $3/M) + 50 × $15/M ≈ $0,0015. Bei 100K Calls/Monat, angenommen 90% Hit (90K Cache Hits). Kosten: 10K Calls × $0,045 + 90K Calls × $0,0015 = $450 + $135 = $585/Monat . Moment — das ist teurer! Wahr, wenn Sie den Prompt nicht abstimmen. Aber reduzieren Sie die Few-Shot-Beispiele auf 10 (2K Tokens), und die Kosten sinken auf ~$280/Monat. Darüber hinaus: wenn Sie Anfragen batchen können (verarbeiten Sie 10 verwandte Tickets in einem Call), sinken die Kosten pro Ticket um weitere 30%. Fazit: Prompt Caching auf GPT-5.5 wird günstiger als Fine-Tuning bei 15–30 Cache Hits pro einzigartigen Kontext. Die meisten Teams erreichen dies innerhalb von Stunden nach dem Deployment. Qualitätsrisiko: Few-Shot-Prompts können bei Grenzfällen und ungewöhnlichen Formaten schlechter abschneiden als Fine-Tuning. Budgetieren Sie 2–4 Wochen für Regressionstests. Pfad 2: LoRA auf Open-Source — Kosten und Logistik Open-Source Fine-Tuning via LoRA (Low-Rank Adaptation) hält das Basismodell eingefroren und trainiert nur kleine Adapter-Matrizen (~1–5% der Parameter). Kostenstruktur: Komponente Anbieter-Beispiel Kosten Notizen Training (Llama 3.3 70B auf 10K Samples) Together AI $300 LoRA auf einzelner H100 GPU (~4 Stunden) Inferenz (pro 1M Tokens) Groq (Llama 3.3 70B) $0,27 Schnell (keine Tuning-Latenz vs Fine-Tuned GPT-4) Inferenz (pro 1M Tokens) Together AI (Llama 3.3 70B) $0,18 Langsamere Response, niedrigere Kosten Modell-Hosting (monatlich, Always-On) Selbstgehostet auf runpod $300–$600 A100 GPU-Verleih + Ops-Overhead Gesamtkosten für 1M Calls/Monat — $318–$600 Groq API (verwaltete), keine Hosting-Kosten Warum Open-Source günstiger ist: Keine Pro-Token-Premium für "Fine-Tuning"-Status. Der Adapter gehört Ihnen zum Verteilen und Verbessern. Modellqualität (Llama 4 Maverick) entspricht GPT-4o für die meisten Aufgaben bei 30–50% niedrigeren Kosten. Der Tradeoff: Sie besitzen die MLOps — Trainings-Kadenz, Drift-Erkennung, A/B-Tests zwischen Adapter-Versionen. Integrationsrisiko: Der Wechsel von OpenAIs API zu Groq, Together oder selbstgehostet ändert Ihre Inferenz-Latenz, Fehlerbehandlung und Skalierung. Erwarten Sie 1–2 Wochen Integrationsarbeit. Pfad 3: Verwaltetes Fine-Tuning (Vertex, Bedrock, Mistral) Anbieter Trainingskosten (10K Samples) Inferenzkosten (pro 1M Output-Tokens) Basismodell Zeit bis Production Google Vertex AI $500–$800 $0,40–$1,50 Gemini 1.5 Flash, andere OS-Modelle 1–2 Wochen AWS Bedrock (Claude Sonnet Fine-Tuned) $600–$1.200 $0,80–$2,00 Claude Sonnet, Llama 4, Mistral 1–2 Wochen Mistral Fine-Tuning $400–$700 $0,25–$0,60 Mistral 3.5 Moe, andere Mistral-Modelle 1 Woche Typische monatliche Kosten (100K Calls, 500 Tokens durchschnittlich) $600–$1.200 (einmaliges Training) $200–$1.000 (wiederkehrende Inferenz) — — Verwaltete Services sind die einfachste Rampe: Ihr Team kennt API-Authentifizierung bereits, Vendor-Support ist verfügbar, und Sie vermeiden MLOps-Overhead. Aber Inferenzkosten laufen 2–5× höher als Open-Source LoRA. Dieser Pfad macht Sinn wenn: (1) Sie Kostenvergleich Drei Pfade (konkreter Workload) Workload: Kundenservice AI für ein SaaS. 1M Inferenz-Calls/Monat, durchschnittlich 500 Input + 150 Output Tokens pro Call. Das Team hat ein Fine-Tuning-Modell auf 5K gekennzeichnete Konversationen trainiert. Kostenkomponente Pfad 1: Prompt Caching + GPT-5.5 Pfad 2: LoRA auf Groq (Llama 3.3) Pfad 3: Bedrock (Claude Sonnet FT) Initiales Setup / Training $0 (nur Prompt Eng) $300 $1.000 Monatliche Inferenzkosten (1M Calls) $450–$600 $270 $900–$1.200 Monatliche Gesamtkosten (Jahr 1) $450–$600 $600 (inklusive Training amortisiert) $1.900–$2.200 Gesamtkosten Jahr 1 $5.400–$7.200 $3.600–$4.800 $12.000–$15.000 Pfad 2 (LoRA) gewinnt bei reinen Kosten, erfordert aber MLOps-Zeit zum Setup und zur Wartung.** Pfad 1 (Prompt Caching) hat niedrigere Reibung, wenn Sie leicht höhere laufende Kosten akzeptieren. Pfad 3 (verwaltete) wird nur gewählt, wenn Enterprise-SLAs oder Hands-Off-Operationen obligatorisch sind. Versteckte Migrationskosten — Übersehen Sie diese nicht Die obige Tabelle lässt operational Friction aus. Planen Sie ein: 1. Neubewertung und Benchmarking Messen Sie die Genauigkeit, Latenz und Kosten des neuen Modells auf Ihrem Holdout-Testset. Budget: 2–3 Wochen, $1.000–$3.000 an Engineerzeit. 2. Regressionstests Führen Sie das alte Fine-Tuning-Modell und den neuen Pfad auf denselben 100–1K Production-Queries aus. Messen Sie Qualitätslücken. Für kundenbezogene Systeme, erwägen Sie A/B-Tests (Dual-Running) für 2–4 Wochen. Ops-Kosten: $2.000–$5.000. 3. Dual-Running-Periode Führen Sie alte und neue Pfade parallel aus, um Regressions in Production zu erfassen. Dies verdoppelt die Inferenzkosten für 2–4 Wochen. Fügt $500–$2.000 zu Ihrer Migrationsrechnung hinzu. 4. Änderungen im Trainings-Workflow Falls Sie regelmäßig umschulen (monatlich, vierteljährlich), berechnen Sie Scripting-Änderungen ein. LoRA-Retraining-Scripts unterscheiden sich von OpenAIs API. Mistral, Vertex und Bedrock haben jeweils unterschiedliche Training-APIs. Budget: 1–2 Wochen, $500–$1.500. 5. Adapter-Drift und Monitoring Open-Source-Adapter können abdriften, wenn sich Training-Daten ändern. Richten Sie Performance-Monitoring und Retraining-Trigger ein. Bei verwalteten Services handhabt der Provider dies, verrechnet aber Monitoring-Overhead. Budget: laufend +$200–$500/Monat. Gesamte versteckte Kosten: $4.000–$12.000 an Engineerzeit + $500–$2.000 an Dual-Running Ops. Die meisten Teams unterschätzen dies um 50%. Backen Sie es in Ihren Projektplan ein. Entscheidungsrahmen Wählen Sie Pfad 1 (Prompt Caching + GPT-5.5) wenn: Monatliches Inferenzvolumen liegt unter 100M Tokens Ihre aktuelle Workload hat wiederholte Kontexte (RAG, Multi-Turn) — hohes Cache-Hit-Potenzial Ihr Team hat keine MLOps-Erfahrung und möchte minimalen Ops-Overhead Sie können einen Qualitäts-Tradeoff für Einfachheit akzeptieren (die meisten Aufgaben sehen ≤5% Regression) Latenz-Anforderungen sind flexibel (>500ms TTFT akzeptabel) Wählen Sie Pfad 2 (LoRA auf Open-Source) wenn: Monatliches Inferenzvolumen überschreitet 200M Tokens — Kostenvorteil 30–50% Ihr Team hat MLOps-Kapazität für Training, Monitoring und Umschulung Sie benötigen Reproduzierbarkeit und möchten vollständige Kontrolle über den Adapter (Open-Source-Vorteil) Datenschutz erfordert keine Calls zu OpenAIs, Googles oder AWS proprietären APIs Latenz ist kritisch ( Wählen Sie Pfad 3 (Verwaltetes Fine-Tuning) wenn: Sie benötigen Enterprise-SLAs, Vendor-Support oder HIPAA/SOC 2-Compliance Ihrem Team fehlt Infrastruktur-Expertise und möchte null MLOps Monatliches Volumen liegt unter 50M Tokens (Kosten-Premium ist akzeptabel bei niedriger Skalierung) Sie sind bereits in Vendors Ökosystem investiert (AWS, Google Cloud, Mistral) Trainings-Häufigkeit ist monatlich oder seltener (Ops-Kosten werden besser amortisiert bei niedriger Churn) Verwandte Lektüre Für mehr Kontext über die breitere Kostenlandschaft, siehe Vergleich Open-Source vs Closed-Source LLM-Kosten , der Break-Even-Volumen zwischen selbstgehosteten und API-Optionen vergleicht. Verfolgen Sie bereits Ihre Fine-Tuning-Migrationskosten? FinOps LLM auditet Ihre LLM-Ausgaben und identifiziert, welcher Migrationspfad Sie am meisten spart. Buchen Sie ein kostenloses Audit . Zurück zur Forschung FAQ Wann kann ich keine neuen OpenAI Fine-Tuning-Modelle mehr erstellen? Zeitplan: 7. Mai 2026 (neue Organisationen blockiert), 2. Juli 2026 (inaktive Organisationen 60 Tage blockiert), 6. Januar 2027 (alle neuen Jobs blockiert). Inferenz für bestehende Fine-Tuning-Modelle läuft bis zur Deprecation des Basismodells weiter. Rentiert sich Prompt Caching gegenüber Fine-Tuning? Für wiederholte Prompts über demselben Kontext: ja. Prompt Caching auf GPT-5.5 kostet $0,60/M für Lesevorgänge vs $3,00/M frisch, und Few-Shot-Beispiele (längere Prompts) können effizient gecacht werden. Break-Even liegt typischerweise bei 10–30 Cache-Treffern je nach Promptgröße; die meisten Teams erreichen dies innerhalb von Tagen. Ist Open-Source LoRA günstiger als verwaltetes Fine-Tuning? Normalerweise ja. Trainingskosten über Together AI: ~$200–$500 pro Job. Inferenz auf Groq oder Fireworks: ~$0,10–$0,30/M Tokens. Die Gesamtkosten pro erfolgreichem Response sind oft 30–50% niedriger als bei einem verwalteten Service, erfordern aber MLOps-Overhead. Welche versteckten Kosten sehe ich nicht während der Migration? Neubewertung (Benchmarking neuer vs. alter Ansatz), Regressionstests (liefert der Ersatzpfad die gleiche Qualität?), Dual-Running (parallele Ausführung alter und neuer Pfade zur Sicherheit), und Adapter-Umschulung wenn sich das neue Modell ändert. Budgetieren Sie 4–8 Wochen und ~$2.000–$10.000 an Engineerzeit pro Migration. --- # Opus 5.5 Anstrengungsstufen sind der echte Preis · FinOps LLM URL: https://finopsllm.com/de/research/opus-5-5-effort-level-cost Opus 5.5 Anstrengungsstufen sind der echte Preis Aktualisiert September 22, 2026 · erstveröffentlicht September 22, 2026 Claude Opus 5.5 kostet $4 pro Million Eingabe-Token und $20 pro Million Ausgabe-Token. Das sind 20% weniger als Opus 5. Der Tarif ist nur die kleinere Hälfte der Gesamtkosten. Die größere Hälfte ist die effort -Einstellung, die bestimmt, wie viele Token das Modell durch Nachdenken verbraucht, bevor es antwortet. Ein Modell, fünf Preise Opus 5.5 bietet Anstrengung von low bis medium , high , xhigh und max . Jede Stufe ist das gleiche Modell zum gleichen Preis pro Token, erzeugt aber eine sehr unterschiedliche Anzahl von Tokens. Unabhängige Messungen von The Decoder zeigten, dass vier der fünf Stufen auf der Kosten-Leistungs-Pareto-Grenze liegen. Sie fanden auch, dass Opus 5.5 bei maximaler Anstrengung etwa 119.000 Ausgabe-Token pro Aufgabe verbrauchte, viel mehr als konkurrierende Modelle bei ihren höchsten Einstellungen. Bei 20 $ pro Million kosten 119.200 Ausgabe-Token 2,38 $ pro Aufgabe, noch ohne Eingabe. Bei medium hat Artificial Analysis 25.700 Ausgabe-Token gemessen, also 0,51 $. Mit Eingabe kostet max 5,98 $ pro Aufgabe und medium 1,34 $: Dasselbe Modell ist je nach einem einzigen Request-Parameter etwa 4,5-mal teurer pro Aufgabe. Gemessen im Artificial Analysis Intelligence Index v4.3.2 (zehn Evaluierungen), abgerufen am 22. September 2026. Alle Zeilen nutzen dieselbe Testsuite und sind direkt vergleichbar. Modell und Effort Intelligence Index Kosten pro Aufgabe Ausgabe-Token pro Aufgabe Auf der Kosten-Leistungs-Frontier Opus 5.5 · low 42.3 $0.55 10,200 Nein Opus 5.5 · medium 51.2 $1.34 25,700 Ja Opus 5.5 · high 53.6 $1.82 35,600 Ja Opus 5.5 · xhigh 56.0 $3.46 65,700 Ja Opus 5.5 · max 57.6 $5.98 119,200 Ja Opus 5 · high (Referenz) 48.1 $3.61 46,200 Nein Quelle: Artificial Analysis. Auf der Frontier heißt: Keine Einstellung von GPT-6 Sol, GPT-6 Astra, Opus 5, Opus 5.5 oder Fable 5.1 erzielt mehr für weniger Geld. Opus 5.5 low liegt nicht darauf, weil GPT-6 Sol bei xhigh 44,1 für 0,53 $ erreicht. Der Schritt von xhigh auf max bringt 1,6 Punkte für 73 % mehr Kosten. Mittel ist die Einstellung, auf der Anthropic Benchmarks basiert Anthropics hauptsächlicher Vergleich wird bei Standard-Anstrengung durchgeführt, die mittel ist. Es heißt, Opus 5.5 bei mittlerer Anstrengung schlägt GPT-6 Astra bei maximaler Anstrengung bei Wissensarbeit um etwa ein Fünftel der Kosten pro Aufgabe. Anthropics eigenes Argument für das Modell basiert also auf mittel, und max ist die Ausnahme. Ein Team, das überall max setzt, um "sicherzugehen", zahlt für Tokens, die die Produktions-Benchmarks nicht benötigten. Anstrengung ohne Raten setzen Standard auf mittel. Machen Sie es einen expliziten Wert im Code, nicht einen SDK-Standard, der sich unter Ihnen ändern kann. Erhöhen Sie die Anstrengung pro Route, nicht global. Schwieriges Debuggen, Langzeit-Planung und abschließende Überprüfungsschritte können hoch oder max rechtfertigen. Klassifizierung, Extraktion und routinemäßige Bearbeitungen nicht. Protokollieren Sie Anstrengung mit jeder Anfrage. Kosten pro Anfrage sind ohne sie nicht interpretierbar. Ein Ausgabespitzenwert mit flacher Anfragenanzahl ist üblicherweise eine Anstrengungsänderung. Vergleichen Sie Anstrengungsstufen mit denselben wiedergespielten Aufgaben. Protokollieren Sie Erfolgsrate und Ausgabe-Token pro abgeschlossener Aufgabe auf jeder Stufe, und hören Sie auf, die Anstrengung zu erhöhen, wenn die Erfolgsrate nicht mehr steigt. Begrenzen Sie Ausgaben, wo das Produkt es erlaubt. Ein Max-Token-Limit begrenzt den schlimmsten Fall. Bei maximaler Anstrengung ist dieses Limit das Einzige zwischen einer durchgehenden Aufgabe und einer mehrere Dollar kostenden Anfrage. Der Schnitt von $25 auf $20 pro Million Ausgabe-Token spart 20%. Eine Workload von maximaler zu mittlerer Anstrengung zu verschieben kann viel mehr sparen. Behandeln Sie Anstrengung als eine Budgetlinie, die so besitzt und überprüft wird wie jede andere. Weiterführend Claude Opus 5.5 Kostenmodell Opus 5.5 Fast-Mode-Wirtschaft Kostenführer für Reasoning-Modelle Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Opus 5.5 fast mode: 2x Preis für schnellere Antwort · FinOps LLM URL: https://finopsllm.com/de/research/opus-5-5-fast-mode-economics Opus 5.5 Fast-Mode Ökonomie Aktualisiert September 22, 2026 · erstveröffentlicht September 22, 2026 Claude Opus 5.5 hat zwei Preislisten. Standard ist $4 pro Million Input-Token und $20 pro Million Output-Token. Fast mode ist $8 und $40, genau das Doppelte, für bis zu 2,5× die Output-Geschwindigkeit. Das Modell ist identisch. Das zusätzliche Geld kauft Zeit und sonst nichts, also die einzige Frage ist wessen Zeit. Was die Prämie kauft Nehmen Sie einen Schritt, der 5.000 Output-Token produziert. Zu Standard-Sätzen kostet der Output $0,10. Im Fast Mode kostet es $0,20. Wenn der Schritt bei Standard-Geschwindigkeit 60 Sekunden dauert, reduziert eine 2,5× Beschleunigung ihn auf etwa 24 Sekunden. Sie zahlen $0,10 extra, um 36 Sekunden zu sparen. Das läuft auf etwa $10 für jede eingesparte Stunde Wartezeit hinaus. Die Schrittlänge ändert nicht das Verhältnis, da die zusätzlichen Kosten und die eingesparte Zeit mit Output-Token wachsen. Es hängt von Ihrer Standard-Geschwindigkeit ab: Dieses Beispiel geht von etwa 83 Output-Token pro Sekunde aus. Die Eingabe verdoppelt sich auch, also zahlen prefix-intensive Schritte etwas mehr pro eingesparter Sekunde. Wann ist das billig Ein Entwickler, der auf einen interaktiven Coding Agent wartet. Bei $10 pro eingesparter Stunde Wartezeit kostet fast mode viel weniger als die Zeit von jemandem, der bezahlt wird. Eine kundenorientierte Antwort, bei der Latenz die Umwandlung beeinflusst. Bewerten Sie die Beschleunigung gegen Abbruch, nicht gegen die Token-Rechnung. Ein Vorfall, bei dem jede Minute Kosten hat. Wann ist es reiner Verschwendung Background Agents, nächtliche Jobs und Batch-Pipelines. Niemand wartet, also kauft die zusätzliche Ausgabe nichts. Evals und Wiederholungen. Dies sind genau die Workloads, die Token-Anzahlen vervielfachen und nach Zeitplan ausgeführt werden. Subagenten, die parallel laufen. Die Wanduhr-Zeit wird durch den langsamsten Branch und den Orchestrator bestimmt, nicht durch jeden Aufruf. Standard Opus 5.5 ist bereits etwa 30% schneller als Opus 5, laut Anthropic. Einige Latenz-Beschwerden, die Fast Mode auf Opus 5 gerechtfertigt hätten, können allein durch das Upgrade behoben werden. Messen Sie die Standard-Geschwindigkeit, bevor Sie für mehr zahlen. Kontrollen zum Implementieren Machen Sie Fast Mode zur expliziten, pro-Route Entscheidung. Es sollte nie ein globaler Standard oder ein Flag sein, den ein Ingenieur einmal aktiviert und vergessen hat. Markieren Sie Ausgaben nach Modus. Eine Fast-Mode Anfrage zum doppelten Unit-Preis sieht wie eine normale Anfrage auf einem Dashboard aus, das nur nach Modell gruppiert. Warnen Sie vor der Fast-Mode Quote der Output-Token. Wenn sie auf Routes ansteigt, wo kein Benutzer wartet, wurde etwas aktiviert, das nicht sein sollte. Budget Aufwand und Geschwindigkeit zusammen. Max Aufwand vervielfacht die Token-Anzahl, und Fast Mode verdoppelt den Preis jedes Tokens. Das ist die teuerste Art, das Modell zu betreiben. Weiterführend Claude Opus 5.5 Kostenmodell Opus 5.5 Aufwandstufen sind der echte Preis Subagent Fan-out und Parallelitätsgrenzen Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Ox Alpha war GLM-5.3: die Kosten des Kostenlosen · FinOps LLM URL: https://finopsllm.com/de/research/ox-alpha-was-glm-5-3 Ox Alpha war GLM-5.3 Aktualisiert September 1, 2026 · erstveröffentlicht September 1, 2026 Kurzantwort: Vom 20. bis 26. August 2026 wurde auf OpenRouter ein Modell namens stealth/ox-alpha kostenlos ausgeliefert. Inzwischen ist klar: Es war GLM-5.3-Flash — 320 Milliarden Parameter insgesamt, 18... Vom 20. bis 26. August 2026 wurde auf OpenRouter ein Modell namens stealth/ox-alpha kostenlos ausgeliefert. Inzwischen ist klar: Es war GLM-5.3-Flash — 320 Milliarden Parameter insgesamt, 18 Milliarden aktiv, hybride lineare und dünn besetzte Attention, native Text-, Bild- und Videoeingabe, ein Kontextfenster von 1.048.576 Tokens und MIT-lizenzierte Gewichte. Die Nutzung war erheblich: Innerhalb von drei Tagen meldete OpenCode rund 16 Billionen verarbeitete Tokens, 221.000 eindeutige Nutzer und über fünf Millionen Sitzungen. Das ist Produktionsverkehr — und er war sechs Tage lang kostenlos. Kostenlos ist ein Tarif, keine Abwesenheit Kostentelemetrie behandelt eine 0-Dollar-Zeile meist so, als gäbe es sie nicht. Dieser Verkehr fließt in keine Prognose und in keinen Budgetalarm ein. Schließt sich das Fenster und greift ein Tarif, erscheint derselbe Verkehr als nicht modellierter Sprung. Bepreisen Sie deshalb jeden kostenlosen Aufruf mit einem Schattentarif: Tokens wie gewohnt erfassen und mit dem Listenpreis des sonst genutzten Modells multiplizieren. Das Dashboard zeigt dann den Monatswert der Aktion und die Rechnung nach ihrem Ende. Der Tarif ist nicht mehr hypothetisch: GLM-5.3-Flash kostet 0,15 Dollar je Million Eingabe-Tokens und 0,50 je Million Ausgabe-Tokens. 16 Billionen Eingabe-Tokens zu diesem Satz sind rund 2,4 Millionen Dollar — der Wert von sechs kostenlosen Tagen und die Höhe des Sprungs, falls dieser Verkehr bleibt. Drei zu prüfende Risiken Tarifklippe: Was kostet dieser Verkehr morgen zum Listenpreis? Identitätsdrift: Welches Modell steckt diese Woche hinter dem Alias? Qualitätskopplung: Wurden Prompts auf ein Modell optimiert, das Sie nicht behalten können? Modell-IDs fest verdrahten und den Nachfolger vor Fensterende evaluieren. MIT-Gewichte verändern die Make-or-Buy-Rechnung Unter MIT-Lizenz ist Self-Hosting eine reale Option. Mit 18 Milliarden aktiven Parametern liegen die Servingkosten näher an einem mittelgroßen dichten Modell — aber nur bei dauerhaft hoher Auslastung. Unter etwa 40 bis 50% GPU-Auslastung gewinnt meist die API: Ein untätiger Beschleuniger kostet vollen Preis, ein nicht erfolgter Aufruf kostet nichts. Weiterführend Kosten offener und geschlossener Modelle Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Wie man ein Modell ohne Preis bepreist · FinOps LLM URL: https://finopsllm.com/de/research/pricing-an-open-weight-model Kosten eines Open-Weight-Modells Aktualisiert September 1, 2026 · erstveröffentlicht September 1, 2026 Kurzantwort: Qwen3.8-Flash-Next erschien am 26. August 2026 als Open-Weight-Vorschau der Qwen4-Architektur: rund 6 Milliarden aktive Parameter, 262.144 Token nativer Kontext und kein angekündigter gehosteter... Qwen3.8-Flash-Next erschien am 26. August 2026 als Open-Weight-Vorschau der Qwen4-Architektur: rund 6 Milliarden aktive Parameter, 262.144 Token nativer Kontext und kein angekündigter gehosteter Tarif. Damit bricht der übliche Vergleich: Ein geschlossenes Modell nennt einen Preis pro Million Token; offene Gewichte liefern einen Checkpoint und überlassen Ihnen die Zahl. Die Formel Kosten pro MTok = Stundenpreis / (Token_pro_Sekunde * 3600) * 1.000.000 Bei 2,00 $ pro Stunde und gemessenen 1.500 Token pro Sekunde sind das 0,37 $ pro Million Token . Gegenüber einer API zu 3,00 $/MTok sieht das nach achtfacher Ersparnis aus. Die Zahl ist trotzdem falsch, denn sie unterstellt, dass die GPU jede bezahlte Sekunde arbeitet. Der vergessene Faktor: die Auslastung Sie mieten die Stunde und nutzen einen Bruchteil davon. Teilen Sie durch diesen Bruchteil: 0,62 $ bei 60 %, 1,23 $ bei 30 %, 3,70 $ bei 10 % — teurer als die API, die ersetzt werden sollte. Die meisten ersten Deployments liegen zwischen 10 und 30 %, weil der Verkehr stoßweise kommt und die Instanz auf die Spitze ausgelegt ist. Die Ersparnis ist echt, aber sie entsteht durch Auslastung, nicht durch offene Gewichte. Erst messen, dann festlegen Betreiben Sie das Modell auf der Instanz, die Sie tatsächlich mieten würden, mit Ihren Prompts und Kontextlängen, und messen Sie Token pro Sekunde unter Nebenläufigkeit — nicht den Einzelstromwert aus der Modellkarte. Berechnen Sie dann die Auslastung aus Ihrem realen Lastprofil. Zwei Zahlen, eine Division, und die Entscheidung trifft sich selbst. Bepreisen Sie den Kontext, den Sie senden, nicht den, den das Modell unterstützt. Weiterführend Open Source gegen geschlossene Modelle Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # KI-ROI nachweisen, ohne Qualitätsverluste zu verstecken · FinOps LLM URL: https://finopsllm.com/de/research/prove-ai-roi-measurement KI-ROI nachweisen, ohne Qualitätsverluste zu verstecken Aktualisiert August 27, 2026 · erstveröffentlicht August 27, 2026 Kurzantwort: KI-ROI wird nicht durch eine kleinere Rechnung bewiesen. Er entsteht, wenn ein Geschäftsergebnis stärker steigt als die Vollkosten seiner Erzeugung. Verbinden Sie zurechenbare Kosten, Erfolg und... KI-ROI wird nicht durch eine kleinere Rechnung bewiesen. Er entsteht, wenn ein Geschäftsergebnis stärker steigt als die Vollkosten seiner Erzeugung. Verbinden Sie zurechenbare Kosten, Erfolg und Qualität. Das Gegenfaktum Beschreiben Sie, was ohne die Änderung passiert wäre: Menschen, altes Modell oder alter Workflow. Nutzen Sie eine vergleichbare Periode oder Kohorte. Ergebnis messen Verwenden Sie Kosten je erfolgreicher Aufgabe statt je Anfrage. Definieren Sie Erfolg beobachtbar und zählen Sie Retries, Tools, Nacharbeit und Evaluation. Qualität schützen Zeigen Sie Erfolgsquote, Fehler, Latenz und Akzeptanz. Eine Einsparung mit schlechterem Ergebnis ist kein ROI. Weiterführend Kosten je erfolgreicher Aufgabe Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # KI-Anbieterpreise sind nicht direkt vergleichbar · FinOps LLM URL: https://finopsllm.com/de/research/provider-prices-not-comparable KI-Anbieterpreise sind nicht direkt vergleichbar Aktualisiert August 27, 2026 · erstveröffentlicht August 27, 2026 Kurzantwort: Der Vergleich des Listenpreises je Million Tokens erzeugt Scheineinsparungen. Anbieter rechnen unterschiedliche Einheiten und Rabatte ab. Vergleichen Sie die effektiven Kosten je erfolgreicher Aufgabe... Der Vergleich des Listenpreises je Million Tokens erzeugt Scheineinsparungen. Anbieter rechnen unterschiedliche Einheiten und Rabatte ab. Vergleichen Sie die effektiven Kosten je erfolgreicher Aufgabe für denselben Workload. Rechnung normalisieren Führen Sie eine Preistabelle nach Anbieter, Modell, Region, Tokentyp, Cache, Batch und Datum. Trennen Sie Ein- und Ausgabe, Cache, Reasoning, Bild, Audio und Tools. Workload normalisieren Wiederholen Sie dieselben Prompts, Kontexte und Erfolgstests. Messen Sie p50/p95-Latenz, Abschluss, Retries, Nacharbeit und Qualität. Betrieb einrechnen Berücksichtigen Sie Gateway, Observability, Routing, Evaluation und Support. Routen Sie zum günstigsten Anbieter, der Qualitäts- und Kostengrenze erfüllt. Weiterführend LLM-Anbieterarbitrage Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Rate Limits sind Kostenkontrolle · FinOps LLM URL: https://finopsllm.com/de/research/rate-limits-are-cost-control Rate Limits, 429er und Tier-Upgrades Aktualisiert September 1, 2026 · erstveröffentlicht September 1, 2026 Kurzantwort: Wenn ein Dienst 429er liefert, ist der Reflex, das als Verfügbarkeitsvorfall zu behandeln: Limit anheben, Tier upgraden, Retries ergänzen. Manchmal richtig. Es ist aber auch der Mechanismus, durch den... Wenn ein Dienst 429er liefert, ist der Reflex, das als Verfügbarkeitsvorfall zu behandeln: Limit anheben, Tier upgraden, Retries ergänzen. Manchmal richtig. Es ist aber auch der Mechanismus, durch den eine außer Kontrolle geratene Schleife zur fünfstelligen Rechnung wird — das Einzige, was sie gebremst hat, wurde gerade entfernt. Was ein 429er wirklich sagt Dass das System schneller ausgeben will als erlaubt. Aus zwei gegensätzlichen Gründen: echtes Nachfragewachstum , bei dem das Limit zu niedrig ist, oder Amoklauf — Retry-Sturm, schleifender Agent, ungedrosselter Backfill — bei dem das Limit genau seine Aufgabe erfüllt. Die Fehlerrate unterscheidet beides nicht. Die Kosten pro erledigter Aufgabe schon: echtes Wachstum hält das Verhältnis, ein Amoklauf zerreißt es. Limits bewusst setzen Eigene Limits unterhalb der Provider-Grenze, je Umgebung und Feature. Nicht-Produktion hart deckeln. Auf die Kosten pro Aufgabe alarmieren, nicht nur auf Fehlerzahlen. Weiterführend Verstecktes Retry-Spending Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Neu-Embedding ist wiederkehrend · FinOps LLM URL: https://finopsllm.com/de/research/re-embedding-is-recurring Laufende Kosten von Embeddings und Vector Stores Aktualisiert September 1, 2026 · erstveröffentlicht September 1, 2026 Kurzantwort: Embedding-Kosten werden als Projektposten genehmigt: ein paar Millionen Dokumente, ein einmaliger Lauf, eine kleine Zahl neben den Generierungskosten. Dann hört es nie auf, weil drei getrennte Kräfte... Embedding-Kosten werden als Projektposten genehmigt: ein paar Millionen Dokumente, ein einmaliger Lauf, eine kleine Zahl neben den Generierungskosten. Dann hört es nie auf, weil drei getrennte Kräfte neu einbetten, wofür Sie schon bezahlt haben. Die drei Auslöser Inhalts-Churn : der ehrlichste und kleinste, skaliert mit dem Geschäft und ist gut prognostizierbar. Chunking- und Pipeline-Änderungen : der heimtückische. Jede Anpassung von Chunkgröße, Overlap oder Vorverarbeitung entwertet alle Vektoren. Ein Retrieval-Qualitätsexperiment, das nach Konfigänderung klingt, ist ein vollständiges Neu-Embedding. Modellwechsel : der große. Embedding-Räume sind zwischen Modellen nicht kompatibel — keine Teilmigration, entweder zwei Stores parallel oder eine Ausfallzeit. Als Annuität budgetieren Planen Sie mindestens ein vollständiges Neu-Embedding pro Jahr ein. Bewerten Sie ein Modell nach Neu-Embedding-Kosten plus einem Jahr Speicher und Abfragebetrieb , nicht nach Tokenpreis. Und fahren Sie diese Jobs über Batch: die latenztoleranteste Last, die Sie haben. Weiterführend RAG-Kostenoptimierung Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Echte Kosten pro Aufgabe: Opus 5.5 vs Sol, Astra, Fable · FinOps LLM URL: https://finopsllm.com/de/research/real-cost-per-task-frontier-models Echte Kosten pro Aufgabe bei Frontier-Modellen Aktualisiert September 22, 2026 · erstveröffentlicht September 22, 2026 Listenpreise sagen, was ein Token kostet. Sie sagen nicht, was eine fertige Aufgabe kostet, denn Modelle verbrauchen für dieselbe Arbeit sehr unterschiedlich viele Token. Diese Seite stellt gemessene Kosten pro Aufgabe und einen Qualitäts-Score für Claude Opus 5.5, Claude Opus 5, Claude Fable 5.1, GPT-6 Astra und GPT-6 Sol auf jeder Effort-Stufe nebeneinander. Jede Zahl hat eine Quelle, nichts ist geschätzt. Die kurze Antwort: GPT-6 Sol ist der günstigste Weg zu jedem Score bis 47,5. Über 47,5 ist Opus 5.5 auf jeder Stufe am günstigsten. Keine Einstellung von GPT-6 Astra oberhalb von low, von Opus 5 oder von Fable 5.1 ist kosteneffizient: Jede wird von einer Einstellung von Sol oder Opus 5.5 bei Score und Preis geschlagen. Methode Alle Scores und Kosten stammen aus dem Artificial Analysis Intelligence Index v4.3.2, abgerufen am 22. September 2026. Der Index umfasst zehn Evaluationen: AA-Briefcase, GDPval-AA, AutomationBench-AA, Terminal-Bench 4.0, SciCode, Humanity's Last Exam, GDP.pdf, CritPt, AA-Omniscience und AA-LCR. Artificial Analysis führt jedes Modell auf jeder Effort-Stufe über die API des Anbieters aus und erfasst, was es zu Listenpreisen zahlt. Die Kosten pro Aufgabe sind diese Ausgaben pro Aufgabe, aufgeteilt in Eingabe und Ausgabe. Jede Zeile durchläuft dieselbe Suite, die Zeilen sind also direkt vergleichbar. Vor dem Lesen gelten zwei Grenzen. Erstens ist der Index nur ein Aufgabenmix. Ihr Mix verschiebt die Kosten, deshalb erklärt der letzte Abschnitt, wie Sie Ihre eigenen messen. Zweitens sind Scores aus verschiedenen Indexversionen nicht vergleichbar. Mischen Sie diese Zahlen also nicht mit älteren veröffentlichten Werten. Die ganze Leiter: 26 Einstellungen Ausgabe-Token pro Aufgabe sind die Token, die das Modell schreibt, Reasoning eingeschlossen. Für die vier mittleren Einstellungen von GPT-6 Sol veröffentlicht Artificial Analysis keine Aufteilung in Eingabe und Ausgabe, daher steht dort n/a. Modell Effort Intelligence Index Kosten pro Aufgabe Eingabekosten Ausgabekosten Ausgabe-Token pro Aufgabe Auf der Frontier GPT-6 Sol none 28.1 $0.33 $0.28 $0.05 4,900 Nein GPT-6 Sol low 33.9 $0.13 n/a n/a 3,400 Ja GPT-6 Sol medium (Standard) 39.8 $0.25 n/a n/a 6,500 Ja GPT-6 Sol high 42.8 $0.37 n/a n/a 10,200 Ja GPT-6 Sol xhigh 44.1 $0.53 n/a n/a 16,000 Ja GPT-6 Sol max 47.5 $1.06 $0.74 $0.31 31,200 Ja GPT-6 Astra low 45.8 $0.82 $0.60 $0.22 4,400 Ja GPT-6 Astra medium 49.6 $1.54 $1.06 $0.48 9,600 Nein GPT-6 Astra high 50.9 $1.73 $1.13 $0.59 11,800 Nein GPT-6 Astra xhigh 52.4 $2.31 $1.46 $0.85 16,900 Nein GPT-6 Astra max 52.7 $3.26 $1.90 $1.36 27,200 Nein Claude Opus 5 low 39.4 $1.10 $0.73 $0.37 14,700 Nein Claude Opus 5 medium 44.8 $2.19 $1.47 $0.72 29,000 Nein Claude Opus 5 high (Standard) 48.1 $3.61 $2.46 $1.16 46,200 Nein Claude Opus 5 xhigh 49.7 $4.88 $3.36 $1.52 60,700 Nein Claude Opus 5 max 50.8 $5.86 $4.05 $1.81 72,500 Nein Claude Opus 5.5 low 42.3 $0.55 $0.35 $0.20 10,200 Nein Claude Opus 5.5 medium (Standard) 51.2 $1.34 $0.82 $0.51 25,700 Ja Claude Opus 5.5 high 53.6 $1.82 $1.11 $0.71 35,600 Ja Claude Opus 5.5 xhigh 56.0 $3.46 $2.15 $1.31 65,700 Ja Claude Opus 5.5 max 57.6 $5.98 $3.60 $2.38 119,200 Ja Claude Fable 5.1 low 46.8 $2.37 $1.30 $1.08 21,600 Nein Claude Fable 5.1 medium 48.9 $2.98 $1.59 $1.39 27,900 Nein Claude Fable 5.1 high 51.2 $3.91 $2.01 $1.90 38,100 Nein Claude Fable 5.1 xhigh 53.2 $5.98 $2.96 $3.02 60,500 Nein Claude Fable 5.1 max 53.4 $7.63 $3.73 $3.90 78,100 Nein Auf der Frontier heißt: Keine andere Einstellung in dieser Tabelle erzielt mehr Punkte für weniger Geld. Die Kosten-Frontier Zehn der 26 Einstellungen liegen auf der Frontier. Nach Kosten sortiert sind sie die einzigen, die sich rein nach Preis lohnen. Alle anderen zahlen mehr für denselben oder einen niedrigeren Score. Einstellung Intelligence Index Kosten pro Aufgabe Pro 10.000 Aufgaben GPT-6 Sol · low 33.9 $0.13 $1,300 GPT-6 Sol · medium 39.8 $0.25 $2,500 GPT-6 Sol · high 42.8 $0.37 $3,700 GPT-6 Sol · xhigh 44.1 $0.53 $5,300 GPT-6 Astra · low 45.8 $0.82 $8,200 GPT-6 Sol · max 47.5 $1.06 $10,600 Claude Opus 5.5 · medium 51.2 $1.34 $13,400 Claude Opus 5.5 · high 53.6 $1.82 $18,200 Claude Opus 5.5 · xhigh 56.0 $3.46 $34,600 Claude Opus 5.5 · max 57.6 $5.98 $59,800 Die Frontier hat zwei Bereiche. Von 0,13 $ bis 1,06 $ ist sie fast nur GPT-6 Sol, mit GPT-6 Astra low bei 0,82 $ als einziger Ausnahme. Ab 1,34 $ ist sie nur noch Opus 5.5. Der Schritt dazwischen ist klein: Opus 5.5 medium erzielt 3,7 Punkte mehr als Sol max für 0,28 $ mehr pro Aufgabe. Direktvergleich bei gleichem oder besserem Score Jedes Paar vergleicht eine günstigere Einstellung mit einer teureren, die gleich oder schlechter abschneidet. Günstigere Einstellung Teurere Einstellung Score-Abstand Ersparnis Opus 5.5 medium: 51.2, $1.34 Opus 5 high: 48.1, $3.61 +3.1 für Opus 5.5 63% Opus 5.5 medium: 51.2, $1.34 Opus 5 max: 50.8, $5.86 +0.4 für Opus 5.5 77% Opus 5.5 medium: 51.2, $1.34 Fable 5.1 high: 51.2, $3.91 gleichauf 66% Opus 5.5 high: 53.6, $1.82 GPT-6 Astra max: 52.7, $3.26 +0.9 für Opus 5.5 44% Opus 5.5 high: 53.6, $1.82 Fable 5.1 max: 53.4, $7.63 +0.2 für Opus 5.5 76% GPT-6 Sol max: 47.5, $1.06 Opus 5 high: 48.1, $3.61 +0.6 für Opus 5 71% Die Opus-5-Zeile ist für Teams wichtig, die noch nicht migriert haben. Opus 5 lief standardmäßig auf high. Opus 5.5 läuft standardmäßig auf medium und erzielt dort 3,1 Punkte mehr für 63 % weniger pro Aufgabe. Anthropic gibt an, Opus 5.5 sei 40 % günstiger als Opus 5; der gemessene Abstand in diesem Index ist größer als die Angabe. Wohin das Geld geht: Eingabe, nicht Ausgabe Bei jedem Modell macht die Eingabe etwa die Hälfte bis drei Viertel der Kosten pro Aufgabe aus. Bei Opus 5.5 medium sind 0,82 $ von 1,34 $ Eingabe, also 61 %. Bei GPT-6 Astra max sind es 58 %, bei GPT-6 Sol max 70 % und bei Fable 5.1 max 49 %. Agentenaufgaben senden ihren wachsenden Kontext bei jedem Schritt erneut, daher wachsen die Eingabekosten mit der Zahl der Schritte, nicht nur mit der Länge der Antwort. Deshalb kostet GPT-6 Sol ohne Reasoning mehr als auf low: 0,33 $ gegenüber 0,13 $, obwohl es nur 4.900 Ausgabe-Token schreibt. 0,28 $ der 0,33 $ sind Eingabe. Die wahrscheinliche Ursache sind mehr Schritte, die jeweils den Kontext erneut senden. Reasoning abzuschalten macht einen Agenten nicht günstiger, wenn er danach mehr Runden braucht. Für Ihre Rechnung heißt das: Caching zählt so viel wie die Modellwahl. Opus 5.5 und GPT-6 Sol berechnen 0,20 $ pro Million gecachter Eingabe-Token. GPT-6 Astra berechnet 1,00 $ und Opus 5 0,50 $. Token-Volumen gegen Listenpreis GPT-6 Astra ist hier das Token-sparsamste Modell. Auf max schreibt es 27.200 Ausgabe-Token pro Aufgabe, gegenüber 119.200 bei Opus 5.5 max. Aber Astra kostet 10 $ und 50 $ pro Million, 2,5× der Preis von Opus 5.5. Der Listenpreis gewinnt: Opus 5.5 high kostet 1,82 $ pro Aufgabe bei 53,6 Punkten, Astra max 3,26 $ bei 52,7. Opus 5.5 max ist die eine Stelle, an der Ausführlichkeit teuer wird. Seine 119.200 Ausgabe-Token kosten 2,38 $ vor jeder Eingabe, die ganze Aufgabe 5,98 $. Das bringt den höchsten Score der Tabelle, 57,6, aber zum 4,5× der Kosten von medium. Abnehmender Ertrag pro Effort-Stufe Jede Zeile zeigt, was eine Effort-Stufe mehr bringt: Indexpunkte gegen Mehrkosten pro Aufgabe. Modell medium → high xhigh → max GPT-6 Sol +3.0 Punkte für +48% +3.4 Punkte für +100% GPT-6 Astra +1.3 Punkte für +12% +0.3 Punkte für +41% Claude Opus 5 +3.3 Punkte für +65% +1.1 Punkte für +20% Claude Opus 5.5 +2.4 Punkte für +36% +1.6 Punkte für +73% Claude Fable 5.1 +2.3 Punkte für +31% +0.2 Punkte für +28% Bei Fable 5.1 und GPT-6 Astra bringt max fast nichts: 0,2 und 0,3 Punkte für 28 % und 41 % mehr. Bei Opus 5.5 bringt der Schritt auf max noch 1,6 Punkte, kostet aber 73 % mehr. Nutzen Sie max nur für Aufgaben, bei denen Sie gemessen haben, dass die Zusatzpunkte das Ergebnis ändern. Wann GPT-6 Sol max reicht Der Index ist ein Mittelwert, und der Abstand zwischen Sol max und Opus 5.5 medium ist nicht überall gleich. Scores pro Evaluation laut Artificial Analysis: Evaluation Opus 5.5 medium ($1.34) GPT-6 Sol max ($1.06) Terminal-Bench 4.0 52.5 43.9 AutomationBench-AA 61.2 61.6 GDPval-AA (Elo) 1576 1487 AA-Briefcase (Elo) 1642 1483 Humanity's Last Exam 54.7 47.9 SciCode 59.3 57.6 CritPt 27.7 30.9 AA-LCR 84.3 83.7 Bei AutomationBench und CritPt erreicht oder schlägt GPT-6 Sol Opus 5.5 medium, für 1,06 $ pro Aufgabe statt 1,34 $. Bei Terminal-Bench, den Wissensarbeit-Evaluationen und Humanity's Last Exam führt Opus 5.5 deutlich. Workflow-Automatisierung kann auf Sol laufen. Terminal- und Coding-Agenten und dokumentlastige Wissensarbeit sind die Bereiche, in denen Opus 5.5 seinen Preis wert ist. Herstellerangaben gegen unabhängige Zahlen Hersteller- und unabhängige Zahlen weichen oft ab, weil sie andere Harnesses und Einstellungen verwenden. Anthropic meldet 66,4 % auf Terminal-Bench 4.0 für Opus 5.5 auf xhigh. Artificial Analysis misst 59,6 % bei derselben Stufe. Effort Opus 5.5 Fable 5.1 low 31.3% 40.4% medium 52.5% 44.9% high 56.6% 52.0% xhigh 59.6% 55.1% max 59.6% 52.0% Auch das Ranking hängt vom Index ab. Im Vals AI Index liegt Fable 5.1 mit 68,83 % vorn, GPT-6 Astra mit 66,61 % auf Platz drei und Opus 5.5 mit 66,16 % auf Platz vier. Kosten pro Aufgabe werden dort nicht auf derselben Basis veröffentlicht, daher verschiebt das die Frontier oben nicht. Ein Index ist eben nur eine Sicht. Listenpreise und eine cache-lastige Aufgabe Digital Applied hat eine cache-lastige Agentenaufgabe auf jedem Modell berechnet: 8M Cache-Lese-Token, 400K ungecachte Eingabe, 600K Cache-Schreib-Token und 300K Ausgabe-Token. Das Ergebnis folgt der Frontier, mit einem zusätzlichen Aufschlag für GPT-6 Astra. Modell Eingabe $/MTok Ausgabe $/MTok Cache-Lesen $/MTok Cache-lastige Aufgabe (Digital Applied) GPT-6 Sol $2.00 $10.00 $0.20 $6.90 Claude Opus 5.5 $4.00 $20.00 $0.20 $12.20 Claude Opus 5 $5.00 $25.00 $0.50 $17.25 Claude Fable 5.1 $10.00 $50.00 $0.25 $28.50 GPT-6 Astra (≤272K) $10.00 $50.00 $1.00 $34.50 GPT-6 Astra (>272K) $20.00 $75.00 n/a $61.50 GPT-6 Astra berechnet die ganze Anfrage mit 20 $ und 75 $ pro Million, sobald die Eingabe 272K Token übersteigt. Opus 5.5 behält einen Preis über sein ganzes 1M-Token-Fenster. Bei Opus 5.5 kosten Cache-Schreibvorgänge 5 $ pro Million für den 5-Minuten-Cache und 8 $ für den 1-Stunden-Cache, Batch-Jobs werden zu 50 % berechnet und der Fast Mode verdoppelt den Preis. Details im Kostenmodell für Claude Opus 5.5 und in Wirtschaftlichkeit des Fast Mode von Opus 5.5 . So messen Sie Ihre eigenen Kosten pro Aufgabe Erfassen Sie Token pro Aufgabe, nicht pro Anfrage: ungecachte Eingabe, gecachte Eingabe, Cache-Schreibvorgänge und Ausgabe, summiert über alle Schritte der Aufgabe. Nehmen Sie eine Stichprobe von einigen hundert echten Aufgaben und spielen Sie sie auf zwei oder drei Kandidaten ab, etwa Sol max, Opus 5.5 medium und Opus 5.5 high. Bewerten Sie jedes Ergebnis mit derselben Prüfung wie in der Produktion und zählen Sie die bestandenen Aufgaben. Teilen Sie die Gesamtkosten durch die bestandenen Aufgaben. Die Kosten pro erfolgreicher Aufgabe sind die Vergleichszahl, denn eine billige Einstellung, die öfter scheitert, ist nicht billig. Wählen Sie die günstigste Einstellung, die Ihre Qualitätsschwelle erreicht, und leiten Sie nur gescheiterte Aufgaben an eine höhere Stufe weiter. Wiederholen Sie den Test, wenn sich ein Preis oder ein Standard-Effort ändert. Wie Effort-Stufen die Rechnung eines einzelnen Modells verändern, zeigt Die Effort-Stufen von Opus 5.5 sind der echte Preis . Einschränkungen Alle Kosten gelten zu API-Listenpreisen auf dem Aufgabenmix von Artificial Analysis. Rabatte, Batch-Preise und Ihr eigenes Caching verändern sie. Artificial Analysis kennzeichnet seine Einträge für Opus 5.5 und Fable 5.1 als Default Fallback. Prüfen Sie die Methodenhinweise, bevor Sie jede Zeile als dieselbe API-Konfiguration behandeln. Die Scores stammen nur aus Indexversion v4.3.2. Frühere Versionen nutzten andere Evaluationen und sind nicht vergleichbar. Die cache-lastige Aufgabe von Digital Applied ist eine Beispiellast, keine Messung. Die Zahlen ändern sich, wenn Anbieter Preise oder Standards ändern. Abrufdatum ist der 22. September 2026. Quellen Artificial Analysis Intelligence Index Artificial Analysis: Claude Opus 5.5 Artificial Analysis: Claude Opus 5 Artificial Analysis: Claude Fable 5.1 Artificial Analysis: GPT-6 Astra Artificial Analysis: GPT-6 Sol Digital Applied: GPT-6 Sol vs Claude Opus 5.5 cost benchmarks Digital Applied: Claude Opus 5.5 vs GPT-6 Astra Digital Applied: Is Claude Fable 5.1 still worth it? Digital Applied: Claude Opus 5.5 launch pricing and benchmarks Digital Applied: Opus 5.5 vs Grok 4.7 vs Muse Spark 1.3 cost per task Weiterführend Kostenmodell für Claude Opus 5.5 Die Effort-Stufen von Opus 5.5 sind der echte Preis Wirtschaftlichkeit des Fast Mode von Opus 5.5 Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Leitfaden zu Kosten von Reasoning-Modellen · FinOps LLM URL: https://finopsllm.com/de/research/reasoning-model-cost-guide Leitfaden zu Kosten von Reasoning-Modellen Aktualisiert 15. Juli 2026 · zuerst veröffentlicht 4. Juli 2026 Reasoning-Modelle wie o3, o4-mini, DeepSeek-R1, QwQ und MiMo erzeugen interne "Thinking"-Tokens, bevor sie Ausgabe produzieren. Diese versteckten Kosten können Ihre Rechnung um 5-30x aufblähen. Dieser Leitfaden schlüsselt auf, wann Reasoning-Modelle die Premium wert sind und wann ein Standard-Modell die intelligentere Ausgabe ist. 5-30x Kosten-Multiplikator 10 Modelle verglichen 4 Anbieter Jul 2026 Zuletzt aktualisiert Alle Preise in USD pro 1 Million Tokens Reasoning Token-Zählungen variieren je nach Aufgabenkomplexität Thinking-Tokens werden als Ausgabe-Tokens abgerechnet Was sind "Thinking"-Tokens? Reasoning-Modelle verbrauchen Tokens für interne Gedankenketten, bevor sie antworten. Eine einfache Frage könnte 2.000 Thinking-Tokens auslösen; eine komplexe Programmieraufgabe kann 30.000+ Tokens erzeugen. Diese Tokens sind in der API-Antwort unsichtbar, werden aber zu Ausgaberaten abgerechnet - oft die teuerste Stufe. Methodik Standard-Preise Ausgabe-Token-Preis für Standard-Completion (kein Reasoning) von offiziellen Anbieterseiten. Reasoning-Preis Effektive Kosten inklusive Thinking-Tokens. Gemessen als Standard-Ausgabepreis × durchschnittlicher Thinking-Multiplikator für jedes Modell. Thinking-Multiplikator Durchschnittliches Verhältnis der insgesamt abgerechneten Tokens zu sichtbaren Ausgabe-Tokens über Programmierungs-, Mathe- und Analysebenchmarks. Beste Anwendungsfälle Aufgaben, bei denen Reasoning-Modelle Standard-Modellen merklich überlegen sind, um die Kostenprämie zu rechtfertigen. Preistabelle für Reasoning-Modelle Modell ↕ Anbieter ↕ Standard-Ausgabe $/1M ↕ Reasoning-Ausgabe $/1M ↕ Multiplikator ↕ Beste Anwendungsfälle Claude Fable 5 Anthropic $50.00 $200.00 4x Frontier Reasoning, komplexe Softwareschwachstellen, tiefe Analyse Claude Opus 4.8 Anthropic $25.00 $100.00 4x Frontier Reasoning, komplexe Analyse, agentenbasierte Workflows GPT-5.6-Sol OpenAI $30.00 $120.00 4x Frontier Reasoning, komplexer Code, Mathematik, mehrstufige Analyse GPT-5.6-Terra OpenAI $15.00 $60.00 4x Reasoning, Code-Generierung, strukturierte Analyse Grok 4.5 xAI $6.00 $24.00 4x Mathematik, Reasoning, allgemeine Intelligenz o3 OpenAI $8.00 $40.00 5x Komplexe Programmierung, mathematische Beweise, tiefes Reasoning o4-mini OpenAI $4.40 $17.60 4x Kostenempfindliches Reasoning, Programmierung, Analyse DeepSeek R1 DeepSeek $2.19 $8.76 4x Mathematik, Code, Reasoning, chinesischsprachige Aufgaben Claude Sonnet 5 Anthropic $10.00 $40.00 4x Allgemeines Reasoning, Programmierung, Analyse (ausgewogen) GPT-5.5 (Standard) OpenAI $30.00 $30.00 1x Allgemeiner Chat, Programmierung, komplexe Analyse Wann sollte man Reasoning-Modelle verwenden 1) Mehrstufige Programmierung und Debugging Reasoning-Modelle zeichnen sich bei Aufgaben aus, die Planung erfordern: Umstrukturierung mehrerer Dateien, Debugging komplexer Zustände oder Schreiben von Algorithmen mit Edge Cases. Thinking-Tokens ermöglichen dem Modell, Probleme durchzuarbeiten statt nur Muster zu erkennen. Die 4-5x Premium ist die Mühe wert, wenn die Alternative ein Mensch ist, der 30+ Minuten verbringt. 2) Mathematische und logische Beweise Aufgaben, die formales Reasoning erfordern - Beweise, Optimierungsprobleme, Beschränkungszufriedenheit - sehen den größten Qualitätssinn. Standard-Modelle produzieren oft plausible, aber falsche Antworten; Reasoning-Modelle überprüfen sich selbst. Die Kostenprämie ist gerechtfertigt, wenn Korrektheit wichtiger ist als Geschwindigkeit. 3) Komplexe Datenanalyse mit mehreren Schritten Analyse eines Datensatzes mit bedingter Logik, Querverweisen mehrerer Quellen oder Aufbau mehrstufiger Pipelines profitiert von Gedankenketten. Ein Standard-Modell könnte einen Schritt übersehen; ein Reasoning-Modell arbeitet jeden explizit durch. Wann sollte man Reasoning-Modelle vermeiden 1) Einfache Extraktion und Formatierung Datenextraktion aus Dokumenten, JSON-Umformatierung, Textzusammenfassung oder Übersetzung. Diese Aufgaben erfordern Mustererkennung, kein Reasoning. o3 für Extraktion zu verwenden ist wie einen Mathematiker zum Sortieren von Post zu engagieren - teuer und unnötig. 2) Arbeitslasten mit hohem Volumen und niedriger Komplexität Content-Generierung, FAQ-Antworten, einfache Chatbot-Antworten und Daten-Labeling. Bei 10M+ Tokens/Monat addieren sich schnell die 4-5x Reasoning-Multiplikator. Ein Standard-Modell zu $10/1M Ausgabe schlägt ein Reasoning-Modell zu $40-60/1M bei Aufgaben, bei denen Qualität "gut genug" ist. 3) Latenzempfindliche Anwendungen Reasoning-Modelle brauchen länger - Thinking-Tokens fügen 2-10 Sekunden Latenz hinzu. Für Echtzeit-Chat, interaktive Tools oder benutzergerichtete Antworten, bei denen Geschwindigkeit zählt, liefern Standard-Modelle schneller zu geringeren Kosten. Kostenoptimierungsstrategien Nach Komplexität routen Verwenden Sie ein billiges Standard-Modell (GPT-4o-mini, Gemini Flash) als Router. Bei einfachen Aufgaben direkt antworten. Bei komplexen zur Reasoning-Modell eskalieren. Dieses "Kaskaden"-Muster kann Reasoning-Modell-Nutzung um 60-80% reduzieren und dabei Qualität dort bewahren, wo sie zählt. Thinking-Budget begrenzen Einige Anbieter (OpenAI, Google) ermöglichen es Ihnen, ein maximales Thinking-Token-Budget pro Anfrage festzulegen. Begrenzen Sie auf 4.000-8.000 Thinking-Tokens, um unkontrollierte Kosten bei Aufgaben zu verhindern, die tiefes Reasoning nicht benötigen. Beginnen Sie eng und erhöhen Sie nur, wenn die Qualität sinkt. Cachen Sie Ihre Prompts Wenn Ihre Reasoning-Aufgaben einen gemeinsamen System-Prompt oder Kontext teilen (Codebasis, Dokumentation), kann Prompt-Caching Eingabekosten um 50-90% reduzieren. Dies reduziert Thinking-Tokens nicht, senkt aber die Gesamtkosten pro Anfrage erheblich. Verarbeiten Sie nicht-dringende Reasoning in Batches Für Bewertungen, Test-Generierung oder Analyse, die Latenz toleriert, bieten Batch-APIs 50% Rabatte. Kombiniert mit Reasoning-Modellen erhalten Sie den Qualitätsvorteil zum halben Ausgabepreis. Reasoning-Ausgabe $/1M beinhaltet Thinking-Tokens, die zu Ausgaberaten abgerechnet werden. Der Multiplikator ist Durchschnitt typischer Aufgaben; tatsächlicher Multiplikator variiert nach Anfragekomplexität. DeepSeek R1 erzeugt Thinking-Tokens standardmäßig. OpenAI o3/o4-mini berechnet Thinking-Tokens getrennt von sichtbarer Ausgabe. Gemini 2.5 Pro berechnet "Thinking-Tokens" zu einem reduzierten Satz gegenüber sichtbarer Ausgabe - Multiplikator ist effektiver verblendeter Kostenpreis. Einige Links können Referral-Codes enthalten. Wollen Sie dies auf Ihre eigenen LLM-Ausgaben anwenden? FinOps LLM führt eine kostenlose Prüfung Ihrer KI-Kosten durch und zeigt, wo Einsparungen möglich sind. Kostenlose Prüfung buchen → Zurück zur Forschung FAQ Was ist die Methodik? Ausgabe-Token-Preis für Standard-Completion (kein Reasoning) von offiziellen Anbieterseiten. Reasoning-Preis: Effektive Kosten inklusive Thinking-Tokens. Gemessen als Standard-Ausgabepreis × durchschnittlicher Thinking-Multiplikator für jedes Modell. Was ist die Pricing-Tabelle für Reasoning-Modelle? Reasoning-Ausgabe $/1M beinhaltet Thinking-Tokens, die zu Ausgaberaten abgerechnet werden. Der Multiplikator ist Durchschnitt typischer Aufgaben; tatsächlicher Multiplikator variiert nach Anfragekomplexität. DeepSeek R1 erzeugt Thinking-Tokens standardmäßig. OpenAI o3/o4-mini berechnet Thinking-Tokens getrennt von sichtbarer Ausgabe. Wann sollte man Reasoning-Modelle verwenden? Reasoning-Modelle zeichnen sich bei Aufgaben aus, die Planung erfordern: Umstrukturierung mehrerer Dateien, Debugging komplexer Zustände oder Schreiben von Algorithmen mit Edge Cases. Thinking-Tokens ermöglichen dem Modell, Probleme durchzuarbeiten statt nur Muster zu erkennen. Wann sollte man Reasoning-Modelle vermeiden? Datenextraktion aus Dokumenten, JSON-Umformatierung, Textzusammenfassung oder Übersetzung. Diese Aufgaben erfordern Mustererkennung, kein Reasoning. o3 für Extraktion zu verwenden ist wie einen Mathematiker zum Sortieren von Post zu engagieren - teuer und unnötig. Was sind Kostenoptimierungsstrategien? Verwenden Sie ein billiges Standard-Modell (GPT-4o-mini, Gemini Flash) als Router. Bei einfachen Aufgaben direkt antworten. Bei komplexen zur Reasoning-Modell eskalieren. Dieses "Kaskaden"-Muster kann Reasoning-Modell-Nutzung um 60-80% reduzieren und dabei Qualität dort bewahren, wo sie zählt. --- # Dasselbe Modell kostet regional mehr · FinOps LLM URL: https://finopsllm.com/de/research/regional-pricing-premium Regionale Aufschläge und Datenresidenz Aktualisiert September 1, 2026 · erstveröffentlicht September 1, 2026 Kurzantwort: Die Preisliste, mit der Sie budgetiert haben, ist meist die US-Liste. Leiten Sie dieselbe Anfrage über einen europäischen oder asiatischen Endpunkt, oder binden Sie sie aus Residenzgründen an eine... Die Preisliste, mit der Sie budgetiert haben, ist meist die US-Liste. Leiten Sie dieselbe Anfrage über einen europäischen oder asiatischen Endpunkt, oder binden Sie sie aus Residenzgründen an eine Region, ändert sich die Zahl — manchmal beim Tokenpreis, häufiger bei allem drumherum. Woher der Aufschlag kommt Aus vier Quellen zugleich. Regionale Tokenpreise , plattformabhängig. Modellverfügbarkeit , außerhalb der Primärregion verzögert. Egress und Latenz über Regionen hinweg. Und vor allem geringerer Funktionsumfang : fehlt dort Prompt-Caching oder Batch-Preis, entfallen Rabatte, die Sie eingeplant hatten. Genau das schmerzt: eine auf Caching und Batch ausgelegte Last, in eine Region ohne beides verschoben, kostet nicht ein paar Prozent mehr, sondern so viel wie ganz ohne Optimierung. Entscheiden, nicht erben Residenz ist oft eine echte Pflicht — dann ist der Aufschlag der Preis legalen Betriebs. Der Fehler ist, ihn für Lasten zu zahlen, die ihn nie brauchten. Trennen Sie den Verkehr nach der Art der Daten: Reguliertes in die konforme Region, alles andere dorthin, wo es am günstigsten ist. Weiterführend LLM-Kostenzuordnung Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Die Retry-Schleife, die Inferenzkosten heimlich erhöht · FinOps LLM URL: https://finopsllm.com/de/research/retry-loop-hidden-spend Die Retry-Schleife, die Inferenzkosten heimlich erhöht Aktualisiert August 27, 2026 · erstveröffentlicht August 27, 2026 Kurzantwort: Ein Retry ist ein weiterer Modellaufruf, keine kostenlose Resilienz. Messen Sie die Retry-Steuer: Retry- und Fallback-Kosten geteilt durch die gesamte Inferenz.Den vollständigen Baum erfassenSpeichern... Ein Retry ist ein weiterer Modellaufruf, keine kostenlose Resilienz. Messen Sie die Retry-Steuer: Retry- und Fallback-Kosten geteilt durch die gesamte Inferenz. Den vollständigen Baum erfassen Speichern Sie Elternanfrage, Versuch, Anbieter, Modell, Tool, Fehler, Tokens und Ergebnis. Verschachtelte Aufrufe brauchen Eltern-Kind-Beziehungen. Die Schleife begrenzen Definieren Sie je Fehlerklasse Versuchszahl, Token-, Dollar- und Zeitlimit. Deterministische Fehler dürfen nicht unverändert wiederholt werden. Deaktivieren Sie Retries nicht pauschal. Jeder Versuch muss sichtbar, begrenzt und durch ein besseres Ergebnis begründet sein. Weiterführend Leitplanken für Agentenausgaben Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # SaaS-KI-Credits messen und zuordnen · FinOps LLM URL: https://finopsllm.com/de/research/saas-ai-credits-metering SaaS-KI-Credits: eine Einheit messen, die Ihnen nicht gehört Aktualisiert September 2, 2026 · erstveröffentlicht September 2, 2026 Kurzantwort: Cloud-FinOps setzt eine lesbare Einheit voraus: Instanzstunde, Request, Gigabyte. Ein KI-Credit ist das nicht. Der Anbieter definiert und bepreist ihn und kann ihn während der Laufzeit neu... Cloud-FinOps setzt eine lesbare Einheit voraus: Instanzstunde, Request, Gigabyte. Ein KI-Credit ist das nicht. Der Anbieter definiert und bepreist ihn und kann ihn während der Laufzeit neu festlegen. Drei Eigenschaften, die das Playbook brechen Die Einheit ist undurchsichtig: zwei Funktionen verbrauchen für gefühlt dieselbe Aktion sehr unterschiedlich. Der Satz gehört Ihnen nicht. Und Kontingente verfallen ohne Pooling und Übertrag. Trotzdem messen Ziehen Sie den Verbrauch planmäßig über die Admin-API und legen Sie ihn neben Ihren übrigen Kostendaten ab — nach Nutzer, Team und Funktion. Das Anbieter-Dashboard zeigt die laufende Periode; Ihre Fragen betreffen den Trend. Vor der Rechnung zuordnen Ordnen Sie Credits denselben Kostenstellen zu wie Cloud-Kosten und veröffentlichen Sie monatliches Showback. Nicht zugeordneter Aufwand landet im Plattformbudget — beim Team mit dem geringsten Einfluss auf den Verbrauch. Deckeln, sonst alarmieren Bevorzugen Sie ein administratives Limit in der Anbieter-Konsole: die einzige Kontrolle, die Ausgaben vorab stoppt. Fehlt sie, alarmieren Sie auf Basis Ihrer eigenen Messung mit Handlungsspielraum. Weiterführend Schatten-KI auf Firmenkarten Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Server-Tools zählt Ihr Token-Zähler nicht · FinOps LLM URL: https://finopsllm.com/de/research/server-tools-are-a-separate-invoice Server-Tools sind eine eigene Rechnung Aktualisiert September 1, 2026 · erstveröffentlicht September 1, 2026 Kurzantwort: Die meisten LLM-Kostenmodelle haben einen Zähler: Tokens rein, Tokens raus, Preis je Million. Das stimmte, solange eine Anfrage nur Text erzeugte. Mit serverseitigen Tools stimmt es nicht... Die meisten LLM-Kostenmodelle haben einen Zähler: Tokens rein, Tokens raus, Preis je Million. Das stimmte, solange eine Anfrage nur Text erzeugte. Mit serverseitigen Tools stimmt es nicht mehr. Websuche, Web-Fetch und Codeausführung laufen auf der Infrastruktur des Anbieters, und mehrere davon tragen eine eigene Nutzungsgebühr zusätzlich zu den Tokens, die sie erzeugen. Ein Agentenzug kann Sie also doppelt belasten. Der kumulative Teil Die zweite Gebühr wird übersehen. Jedes Tool-Ergebnis wird an die Konversation angehängt, und jeder folgende Zug sendet alles erneut als Eingabe. Zehn Suchen früh in einem langen Lauf sind nicht zehn Gebühren, sondern zehn Gebühren plus ihre Nutzlast, in jedem weiteren Zug erneut gelesen. Deshalb wirken Agentenkosten nichtlinear, obwohl die Token-Rechnung Linearität nahelegt. Die Nutzungsgebühr ist der sichtbare Teil; das Kontextwachstum ist der größere und landet unbeschriftet in Ihrer Eingabe-Token-Zeile. Ohne Zuordnung keine Steuerung Protokollieren Sie Tool-Aufrufe je Anfrage neben dem Usage-Objekt: welches Tool, wie viele Aufrufe, und wie groß in Tokens das jeweilige Ergebnis war. Letzteres macht die Kumulation sichtbar. Berechnen Sie dann Kosten je Agentenlauf, nicht je API-Aufruf. Drei wirksame Kontrollen Begrenzen Sie Tool-Aufrufe je Lauf — das deckelt beide Kosten zugleich. Kürzen Sie, was in den Kontext gelangt — zusammenfassen vor dem Anhängen entlastet jeden folgenden Zug. Cachen Sie das stabile Präfix — Systemprompt und Tool-Definitionen sind konstant; Caching entfernt den größten wiederholten Posten. Weiterführend Ökonomie des Prompt-Cachings Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Schatten-KI läuft über Firmenkarten · FinOps LLM URL: https://finopsllm.com/de/research/shadow-ai-corporate-cards KI-Ausgaben außerhalb Ihrer API-Rechnung Aktualisiert September 1, 2026 · erstveröffentlicht September 1, 2026 Kurzantwort: Die meisten Organisationen messen KI-Kosten, indem sie die Anbieterkonsole öffnen. Diese Zahl ist echt und gut instrumentiert — und in vielen Firmen die kleinere Hälfte. Die andere Hälfte steckt... Die meisten Organisationen messen KI-Kosten, indem sie die Anbieterkonsole öffnen. Diese Zahl ist echt und gut instrumentiert — und in vielen Firmen die kleinere Hälfte. Die andere Hälfte steckt in Spesenabrechnungen: Einzelabos von Leuten, die ein Werkzeug brauchten und eine Karte hatten. Warum es unsichtbar bleibt Es berührt nie Ihre API-Schlüssel, Ihr Gateway oder Ihre Telemetrie. Es kommt als Gebühr je Platz, in Beträgen, die automatisch durch die Freigabe rutschen. Zweihundert Personen zu zwanzig oder dreißig Dollar im Monat sind eine sechsstellige Jahresposition, die kein Engineering-Dashboard je zeigt. Was es wirklich kostet Die direkte Mehrausgabe ist das Uninteressanteste. Einzelpläne liegen deutlich über verhandelten Konditionen, und doppelt beim selben Anbieter zu zahlen ist üblich. Schwerer wiegt: Consumer-Tarife haben andere Aufbewahrungs- und Trainingsbedingungen als der von der Rechtsabteilung geprüfte Vertrag, es gibt kein SSO, und der Zugang endet nicht mit dem Arbeitsverhältnis. Wie man es findet Fragen Sie die Finanzabteilung, nicht Engineering. Suchen Sie nach Anbieternamen und dann nach dem Muster: wiederkehrende Monatsbeträge von zehn bis fünfzig Dollar. Und machen Sie den offiziellen Weg leichter als die Karte, statt die Karte zu verbieten. Weiterführend LLM-Kostenzuordnung Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Preiserhöhung für Claude Sonnet 5 abgesagt: $2/$10 bleibt · FinOps LLM URL: https://finopsllm.com/de/research/sonnet-5-intro-pricing-deadline Claude Sonnet 5: Die Preiserhöhung im September wurde abgesagt Veröffentlicht 19. Juli 2026 Korrektur, 2. September 2026: Die Erhöhung, auf die dieser Artikel vorbereiten sollte, ist ausgeblieben. Anthropic hat sie abgesagt — Claude Sonnet 5 bleibt dauerhaft bei $2/$10 pro 1M Tokens. Die Fristanalyse unten bleibt unverändert als Beleg stehen; behandeln Sie jede Zahl „ab 1. September“ als Szenario, das nie eingetreten ist. Aktuelle Preise stehen im LLM-API-Preis-Tracker . Anthropic veröffentlichte Claude Sonnet 5 am 30. Juni 2026 zu Einführungspreisen von $2/1M Eingabe-Tokens und $10/1M Ausgabe-Tokens. Dieser Preis hat eine endgültige Frist: 31. August 2026 . Ab 1. September wechselt Sonnet 5 zu Standardpreisen von $3/$15 pro 1M, eine pauschal 50% Kostenerhöhung . Falls Sie Claude Sonnet 5 Workloads betreiben, sind die nächsten 6 Wochen Ihr Zeitfenster, um Kosten zu fixieren und die Erhöhung zu planen. Einführungspreise gültig bis 31. August 2026 nur Standardpreise ($3/$15) beginnen 1. September 2026 Kostenerhöhung beträgt genau 50% für Claude Sonnet 5 Workloads Gilt für Anthropic API, Bedrock und Vertex AI 43 Tage zum Neu-Bewerten, Fixieren von Commitments und Neu-Prognostizieren Kritische Frist: Claude Sonnet 5 Einführungspreise verfallen in 43 Tagen (31. August 2026). Eine Workload von 10M Tokens/Monat steigt von $20 auf $30/Monat. Eine Workload von 1B Tokens/Monat steigt von $2.000 auf $3.000. Falls Sonnet 5 in Ihrem kritischen Pfad liegt, budgetieren Sie die Erhöhung jetzt oder verschieben Sie Workloads vor der Umstellung. Die Mathematik: Was 50% im Maßstab bedeutet Der Sprung von Einführungs- zu Standardpreisen ist sauber und erheblich. Modellieren wir eine realistische Workload: Workload-Profil Monatliche Eingabe-Tokens Monatliche Ausgabe-Tokens August-Kosten (Einführung) September-Kosten (Standard) Monatliches Delta Jahresauswirkung Leicht (Batch/Intern) 50M 20M $200 $300 +$100 +$1.200 Mittelstufe (Kundenorientiert) 500M 150M $2.500 $3.750 +$1.250 +$15.000 Unternehmensweite Nutzung (High-Volume Reasoning) 2B 800M $12.000 $18.000 +$6.000 +$72.000 Schwer (Multi-Request Flows) 5B 2,5B $35.000 $52.500 +$17.500 +$210.000 Wichtigste Erkenntnis: Ein Unternehmen mit einer mitteltiefen Claude Sonnet 5 Workload (500M Eingabe + 150M Ausgabe-Tokens/Monat) wird eine monatliche Erhöhung von $1.250 sehen, die sich jährlich auf $15.000 kompoundiert, falls sich nichts ändert. Für unternehmensweite Workloads kann die jährliche Auswirkung über $70K liegen. Wen es betrifft Die Frist gilt über alle Kanäle hinweg: Anthropic API (Direkt) Einführungspreise enden am 31. August 2026 um 23:59 Uhr UTC. Verifiziert in der Anthropic-Preis-Dokumentation . Keine Verlängerung oder Verzögerung wurde angekündigt. AWS Bedrock Bedrock übernimmt die Anthropic-Preise. Einführungspreise gelten für Sonnet 5 auf Bedrock bis 31. August. Die Erhöhung erscheint in Ihrer Bedrock-Rechnung am 1. September. Überprüfen Sie Ihren AWS-Vertrag auf Commitment-Rabatte, die die Erhöhung möglicherweise kompensieren. Google Vertex AI Vertex AI integriert Claude-Modelle mit Anthropic-Preisübertragung. Der Übergang erfolgt am 1. September. Vertex-Rechnungen werden in Ihrer lokalen Währung angeboten; bestätigen Sie das genaue Datum mit Ihrem Google Account Team, falls Sie eine andere Zeitzone verwenden. GitHub Copilot Enterprise Falls Copilot Sonnet 5 als Backend nutzt, kann Microsoft die Preiserhöhung auf Ihren Plan übertragen oder nicht. Copilot Enterprise ist eine feste Platzlizenz, daher hängt die Auswirkung davon ab, ob Microsoft die Backend-Kosten absorbiert oder widerspiegelt. Überprüfen Sie Ihre Copilot-Rechnung oder kontaktieren Sie Ihr Microsoft Account Team. Drei Strategien: Was Sie vor dem 31. August tun sollten Strategie 1: Fixieren Sie Nutzungs-Commitments (Falls Verfügbar) Überprüfen Sie, ob Anthropic Nutzungs-Commitments oder Volumenrabatte für Sonnet 5 anbietet. Volumenbasierte Rabatte oder jährliche Prepayment-Vereinbarungen könnten die effektive Preiserhöhung reduzieren. Kontaktieren Sie jetzt Anthropic Sales : Sie könnten Einführungspreise auf vor dem 31. August unterzeichnete Commitments halten. Aktion: Senden Sie eine E-Mail an Anthropic Sales vor 15. August, falls Sie >$5K/Monat für Sonnet 5 ausgeben. Fragen Sie, ob ein jährliches Commitment Einführungspreise fixiert oder gestaffelte Rabatte anbietet. Die Vorlaufzeit für Commitment-Verträge liegt typischerweise bei 2–3 Wochen. Strategie 2: Bewerten Sie Routing und Modellmix neu Nicht alle Workloads benötigen Sonnet 5. Der 50% Preissprung ist eine Zwangsfunktion, um zu überprüfen, welche Tasks wirklich Sonnet 5 erfordern und welche zu günstigeren Alternativen wechseln können. Task-Kategorie Sonnet 5 Eingabe/$1M Alternatives Modell Alt Preis Eingabe/$1M Ersparnisse pro 100M Tokens Wann wechseln Klassifikation (strikte Regeln) $3 (nach 1. Sep) Claude Haiku 4.5 $1,00 $200 Genauigkeit ≥95% Zusammenfassung $3 Gemini 2.5 Flash $0,15 $285 Kein Reasoning notwendig Multi-Turn Konversation $3 GPT-5.6 Luna $1,00 $200 Qualität gleichwertig Komplexes Reasoning (behalten Sie Sonnet 5) $3 — — — Keine Alternative Agentic Loops (Multi-Schritt) $3 Haiku + Sonnet 5 Hybrid $1,00 (Haiku) + $3 (Sonnet 5) Sparen Sie, indem Sie Haiku für einfache Schritte nutzen Benchmarks unterstützen Aktion: Während der nächsten 2 Wochen ziehen Sie Ihre Sonnet 5 Call Logs und kategorisieren nach Workload. Benchmarken Sie 10% der Klassifikations-Tasks auf Haiku, Zusammenfassung auf Gemini 2.5 Flash und einfache Multi-Turn auf GPT-5.6 Luna. Falls die Qualität gleichwertig ist (oder nah dran), verschieben Sie diese Workload vor 1. September und fixieren Sie die Ersparnisse. Strategie 3: Implementieren Sie (oder erweitern Sie) Prompt Caching Prompt Caching ist die direkteste Möglichkeit, Token-Verbrauch zu reduzieren und den Wert von Einführungspreisen vor Ablauf zu bewahren. Cache-Schreibvorgänge zu Sonnet 5 kosten $2,50 pro 1M Tokens (1,25× Eingabepreis bei Einführung; werden $3,75 bei Standard). Cache-Lesevorgänge kosten $0,20 pro 1M (0,1× Eingabepreis bei Einführung; werden $0,30 bei Standard). Die Gelegenheit: Eine Workload mit 40% Cache-Hit-Rate spart 36% bei Eingabekosten. Fixieren Sie Cache-Infrastruktur jetzt zu Einführungspreisen bedeutet, dass Ihre laufenden Hit-Rate-Ersparnisse geerbt werden. Nach 1. September sind dieselben Cache-Hits immer noch 90% Rabatt, aber der Basispreis, den sie diskontieren, ist 50% höher. Beispiel: System-Prompt + Context gecacht 100M Tokens/Monat auf Sonnet 5: August (Einführung): Schreibkosten: 100M × $2,50/M = $250. Monatliche Lesekosten (angenommen 1B Lese-Tokens von Cache Hits): 1B × $0,20/M = $200. Gesamt: $450/Monat für Caching. September (Standard): Schreibkosten: 100M × $3,75/M = $375. Monatliche Lesekosten: 1B × $0,30/M = $300. Gesamt: $675/Monat (50% höher). Ersparnisse durch Implementierung von Caching jetzt: Falls Sie 500M gecachte Eingabe-Tokens zwischen jetzt und 31. August hinzufügen und diese ab September 30 Cache-Hits pro Monat akkumulieren, fixieren Sie kumulative Lese-Rabatte. Die Cache-Schreibkosten sind eine investierte Sunk-Cost, die sich über Monate amortisiert. Aktion: Identifizieren Sie Ihre Top 3 wiederholten Prompts oder Dokument-Kontexte (RAG-Dokumente, System-Anweisungen, Boilerplate). Testen Sie Caching auf der Anthropic API. Falls Hit-Rate ≥20%, implementieren Sie vor 31. August. Cache-Schreibvorgänge sind die eine Kostenfunktion, der es egal ist, wann die Rate-Erhöhung stattfindet: Investition in Schreibkosten jetzt bringt für immer feste Lese-Kostenrenditen. Zeitleiste: Der 6-Wochen Countdown Woche 1 (vor 25. Juli) Überprüfen Sie aktuelle Claude Sonnet 5 Ausgaben. Ziehen Sie Call Logs (Modell, Tokens, Workload-Typ) aus Ihrem Billing-Dashboard oder LLM-Observability-Plattform. Berechnen Sie monatliche Laufrate. Modellieren Sie Q4 Ausgaben, falls sich nichts ändert. Woche 2 (vor 1. August) Kontaktieren Sie Anthropic Sales zum Erfragen von Nutzungs-Commitments. Beginnen Sie, alternative Modelle (Haiku, Luna, Gemini 2.5 Flash) auf 10% des Produktions-Traffic zu benchmarken. Identifizieren Sie Top 3 Kandidaten für Routing-Wechsel. Woche 3 (vor 8. August) Finalisieren Sie Benchmarks und verpflichten Sie sich zu einem Routing-Plan. Falls Wechsel notwendig sind, beginnen Sie A/B-Tests bereitzustellen. Implementieren Sie Prompt Caching für High-Volume wiederholte Kontexte. Ziel ≥100M gecachte Tokens vor Umstellung. Woche 4 (vor 15. August) Fixieren Sie Nutzungs-Commitments mit Anthropic (falls anwendbar). Stellen Sie Routing-Änderungen in Produktion bereit (verschieben Sie Low-Reasoning Tasks zu günstigeren Modellen). Überprüfen Sie, dass Cache-Infrastruktur live ist und >15% Hit-Rate hat. Woche 5 (vor 22. August) Überwachen Sie Produktions-Kosten und Qualitätsmetriken. Passen Sie Routing an, falls notwendig. Prognostizieren Sie endgültige September-Kosten basierend auf August-Laufrate. Woche 6 (vor 31. August) Bestätigen Sie, dass alle Routing-Änderungen live sind. Setzen Sie Kalender-Alarm für 5. September, um zu verifizieren, dass Abrechnung der Prognose entspricht. Veröffentlichen Sie Post-Mortem über Kostenauswirkungen und erzielte Ersparnisse. Vergleich: Sonnet 5 vs. Alternativen nach 1. September Sobald Einführungspreise ablaufen, wie schneidet Sonnet 5 gegen andere Modelle zu ihren Standardpreisen ab? Modell Anbieter Eingabe $/1M Ausgabe $/1M Typischer Anwendungsfall vs. Sonnet 5 nach 1. Sep Claude Sonnet 5 (Standard) Anthropic $3,00 $15,00 Balance von Geschwindigkeit und Reasoning Baseline GPT-5.6 Terra OpenAI $2,50 $15,00 Mid-Tier Reasoning 17% günstiger bei Eingabe GPT-5.6 Luna OpenAI $1,00 $6,00 Schnelle Klassifikation, einfache Tasks 67% günstiger insgesamt Gemini 3.1 Pro Google $2,00 $12,00 Agentic Loops, Tool-Nutzung 33% günstiger bei Eingabe Gemini 2.5 Flash Google $0,15 $0,60 Ultra-schnell, High-Volume 95% günstiger Claude Haiku 4.5 Anthropic $1,00 $5,00 Low-Latency Klassifikation 67% günstiger bei Eingabe DeepSeek V4 Flash DeepSeek $0,14 $0,28 Kostenoptimiert, Open Model 95% günstiger (aber weniger poliert) Die Realität: Sonnet 5 bei $3/$15 ist nicht mehr das billigste oder kosteneffektivste Modell für die meisten Tasks. GPT-5.6 Terra ist 17% günstiger bei Eingabe. Haiku ist 67% günstiger für Klassifikation. Der Wert von Sonnet 5 nach der Erhöhung liegt in Qualität für komplexes Reasoning und Geschwindigkeit für ausgewogene Tasks – nicht in Kostenführerschaft. Workloads, die diese Qualität nicht erfordern, sollten jetzt zu Alternativen wechseln. Häufig gestellte Fragen F: Gibt es eine Chance, dass die Frist verlängert wird? A: Anthropic hat keine Verlängerung angekündigt. Die Ankündigung vom 30. Juni macht deutlich „bis 31. August 2026". Bereiten Sie sich auf das Enddatum vor. Falls eine Verlängerung angekündigt wird, ist es ein Bonus; behandeln Sie die Frist als endgültig. F: Beeinflusst der neue Tokenizer Token-Zähler? A: Ja. Sonnet 5 verwendet einen neuen Tokenizer, der ungefähr 30% mehr Tokens als ältere Claude-Modelle für gleichwertige Texte produziert. Das bedeutet, dass Ihre aktuelle Token-Ausgabe höher ist als Sie möglicherweise erwarten. Faktoren Sie das in Kostenprognosen ein. F: Kann ich Einführungspreise mit jährlicher Prepayment fixieren? A: Möglicherweise, falls Anthropic Prepayment-Optionen anbietet. Kontaktieren Sie Sales vor 15. August zum Fragen. Prepayment ist oft die einzige Möglichkeit, Preise durch eine Tariferhöhung zu erben, aber Sie müssen sich gut im Voraus verpflichten. F: Was wenn ich einen benutzerdefinierten Anthropic-Vertrag habe? A: Benutzerdefinierte Verträge können unterschiedliche Begriffe haben. Verifizieren Sie das genaue Umstellungsdatum und die Rate mit Ihrem Account Team. Falls Ihr Vertrag Preis-Bedingungen angibt, haben diese Vorrang vor der öffentlichen Preisseite: bestätigen Sie jetzt, bevor 1. September Sie überrascht. Die Frist 31. August ist real, die 50% Erhöhung ist gewiss, und Sie haben 6 Wochen zum Handeln. Teams, die neu bewerten, Commitments fixieren und Workloads vor der Umstellung verschieben, werden ihren Q4 LLM-Ausgaben erheblich reduzieren. Teams, die bis 1. September warten, absorbieren die volle Kostenerhöhung. Zurück zur Forschung FAQ Endeten die Einführungspreise für Claude Sonnet 5 am 31. August 2026? Nein. Anthropic hat die geplante Erhöhung abgesagt. Claude Sonnet 5 bleibt dauerhaft bei $2 pro 1M Eingabe-Tokens und $10 pro 1M Ausgabe-Tokens; der für den 1. September 2026 vorgesehene Standardpreis von $3/$15 trat nie in Kraft. Um wie viel steigt meine Rechnung? Genau um 50% für Claude Sonnet 5 Workloads. Eingabepreise steigen von $2 auf $3 pro 1M Tokens (+50%); Ausgabepreise steigen von $10 auf $15 pro 1M Tokens (+50%). Eine Workload, die im August $10.000/Monat kostet, kostet ab September $15.000/Monat, wenn sich nichts ändert. Gelten Einführungspreise auch für Bedrock und Vertex? Einführungspreise gelten für die direkte Anthropic API. AWS Bedrock und Google Vertex AI übernehmen die Anthropic-Preise, daher gilt der Anstieg auch dort ab 1. September. Überprüfen Sie Ihre Vertragsbedingungen mit Ihrem Cloud-Provider. Was sollte ich vor dem 31. August tun? 1) Nutzer-Commitments fixieren, falls verfügbar. 2) Routing zu Sonnet 5 gegen günstigere Modelle neu bewerten (Haiku, Gemini 2.5 Flash). 3) Wiederholte Prompts auf Prompt Caching verschieben (Caching-Rabatte skalieren mit dem Basispreis, daher ist das Fixieren von Caching-Einsparungen jetzt wertvoll). 4) Kalender-Alarm für 25. August setzen, um Kosten nach der Migration zu testen. 5) Den Anstieg jetzt in Ihrem Q3-Budget modellieren. --- # Das anonyme Gratismodell ist eine Preiswaffe · FinOps LLM URL: https://finopsllm.com/de/research/stealth-model-free-tokens-playbook Das Playbook des getarnten Modells Aktualisiert September 1, 2026 · erstveröffentlicht September 1, 2026 Kurzantwort: Ox Alpha tauchte auf den Routing-Aggregatoren als markenloser Endpunkt auf: kostenlos, ohne Preisliste, ohne erkennbares Labor. Dann wurde er als GLM-5.3 bestätigt und das Gratisfenster geschlossen.... Ox Alpha tauchte auf den Routing-Aggregatoren als markenloser Endpunkt auf: kostenlos, ohne Preisliste, ohne erkennbares Labor. Dann wurde er als GLM-5.3 bestätigt und das Gratisfenster geschlossen. GLM-5.3-Flash steht nun bei 0,15 $ je Million Eingabe-Tokens und 0,50 $ je Million Ausgabe. Betrachten Sie das als wiederholbaren Spielzug — denn genau das ist es. Er lief bereits unter anderen Namen und wird wiederkommen. Was das Labor mit Gratis-Tokens kauft Drei Dinge, alle billiger als die Alternativen. Blinde Bewertung: ein markenloser Endpunkt wird an der Ausgabe gemessen, nicht am Logo. Verbreitung: die Aggregatoren leiten sofort echten Traffic dorthin, ohne Partnerschaften. Ein Preisanker: bis der Name fällt, haben Entwickler das Modell längst für gut befunden. Die Zahl beim Schließen des Fensters Sechzehn Billionen Eingabe-Tokens liefen durch den kostenlosen Endpunkt. Zu 0,15 $ je Million sind das rund 2,4 Millionen Dollar Inferenz — und damit die Höhe der Stufe, falls derselbe Traffic einfach bleibt, wo er ist. Rechnen Sie das für Ihren Anteil: Volumen im Fenster mal veröffentlichter Preis ergibt Ihre monatliche Sprungkosten. Drei Regeln für das nächste Mal Hängen Sie nie an einem Endpunkt, dessen Betreiber Sie nicht kennen. Anonym heißt keine Preisliste, keine Abkündigungsfrist, keine Datenzusage. Für Evaluation in Ordnung, für Produktion ohne Rückfallpfad nicht. Bepreisen Sie jede kostenlose Evaluation hypothetisch und führen Sie diese Schattenkosten in Ihrer Telemetrie mit. Nehmen Sie an, das Gratisfenster ist der kürzeste Teil der Beziehung — messen Sie auch die Wechselkosten, nicht nur die Qualität. Weiterführend Anbieter-Arbitrage Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Abgebrochenes Streaming kostet trotzdem volles Geld · FinOps LLM URL: https://finopsllm.com/de/research/streaming-abandoned-generations-cost Streaming-Antworten und abgebrochene Token Aktualisiert September 9, 2026 · erstveröffentlicht September 9, 2026 Kurzantwort: Streaming suggeriert Schnelligkeit, doch wenn der Nutzer den Tab schließt oder auf Stop klickt, rechnet der Modellprovider oft bis zum Tokenlimit weiter ab. Die sichtbare Ausgabe ist kurz, die... Streaming suggeriert Schnelligkeit, doch wenn der Nutzer den Tab schließt oder auf Stop klickt, rechnet der Modellprovider oft bis zum Tokenlimit weiter ab. Die sichtbare Ausgabe ist kurz, die Rechnung aber hoch. Abbrüche nach Upstream propagieren Reichen Sie Client-Disconnections per AbortController direkt an die API des Providers durch, um verwaiste Token zu vermeiden. Weiterführend Versteckte Kosten in Retry-Loops Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Strukturierte Ausgabe ist nicht gratis · FinOps LLM URL: https://finopsllm.com/de/research/structured-output-token-cost Tokenkosten von JSON-Modus und Schemas Aktualisiert September 1, 2026 · erstveröffentlicht September 1, 2026 Kurzantwort: Strukturierte Ausgabe wirkt wie eine Formatentscheidung. Auf der Rechnung ist sie eine Mengenentscheidung, und zwar an drei Stellen gleichzeitig.Das Schema kostet bei jeder Anfrage Eingabe-TokensDas... Strukturierte Ausgabe wirkt wie eine Formatentscheidung. Auf der Rechnung ist sie eine Mengenentscheidung, und zwar an drei Stellen gleichzeitig. Das Schema kostet bei jeder Anfrage Eingabe-Tokens Das Schema wird in die Anfrage serialisiert. Ein bescheidenes Schema sind ein paar hundert Tokens — multipliziert mit jedem Aufruf, jedem Turn, über die gesamte Lebensdauer der Funktion. 400 Tokens mal einer Million Aufrufe sind 400 Millionen Eingabe-Tokens für eine Form, die sich nie ändert. Schlimmer: steht das Schema nach dem volatilen Teil des Prompts, zerstört es das gecachte Präfix und damit den Rabatt auf alles davor. Syntax kostet Ausgabe-Tokens Jede Klammer, jedes Anführungszeichen, jeder Feldname ist ein generiertes Token zum Ausgabepreis. Lange Feldnamen sind eine dauerhafte laufende Gebühr. Wiederholungen sind der teure Teil Jeder Validierungsfehler kostet einen vollen Retry: die gesamte Eingabe und die gesamte Ausgabe erneut. 2% ungültige Antworten sind 2% Mehrkosten ohne Gegenwert. Was zu tun ist Schema ins stabile Präfix, damit es gecacht wird; nur Felder anfordern, die Sie auch verwenden; kurze Namen und flache Strukturen; und die Fehlerquote der Validierung messen. Weiterführend Ökonomie des Prompt-Caching Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Subagent-Fan-Out und Token-Kaskaden stoppen · FinOps LLM URL: https://finopsllm.com/de/research/subagent-fan-out-concurrency-limits Subagent-Fan-Out und unkontrollierte Rekursion im Keim ersticken Aktualisiert September 19, 2026 · erstveröffentlicht September 19, 2026 Kurzantwort: Subagent-Fan-Out-Kaskaden treten auf, wenn ein Orchestrator-Agent komplexe Aufgaben aufteilt und Worker-Agenten erlaubt, eigenständig weitere Subagenten zu erzeugen. Ohne strikte Tiefen- und... Subagent-Fan-Out-Kaskaden treten auf, wenn ein Orchestrator-Agent komplexe Aufgaben aufteilt und Worker-Agenten erlaubt, eigenständig weitere Subagenten zu erzeugen. Ohne strikte Tiefen- und Concurrency-Grenzen führt ein einzelner Prompt zu einer exponentiellen Explosion paralleler Threads, die innerhalb weniger Minuten Millionen von Tokens verbrennen. Was versteht man unter einer Subagent-Fan-Out-Kaskade? Ein Ausfallmuster, bei dem ein koordinierender Agent rekursiv Kind- und Sub-Kind-Agenten ohne globales Budgetbudget startet und den Token-Verbrauch drastisch potenziert. Vier Schutzmaßnahmen für Produktivumgebungen Plattform-Teams setzen auf eine maximale Rekursionstiefe von 2 Ebenen, thread-weite Token-Pools mit zentralem Kontingent und Concurrency-Limits, die parallele Worker auf maximal 3 bis 5 Instanzen drosseln. Weiterführend Drei Budgets für Agenten Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Die drei Budgets, die jeder autonome Agent braucht · FinOps LLM URL: https://finopsllm.com/de/research/three-agent-budgets Die drei Budgets, die jeder autonome Agent braucht Aktualisiert August 27, 2026 · erstveröffentlicht August 27, 2026 Kurzantwort: Ein autonomer Agent braucht drei Grenzen in seiner Schleife: Budget für die Anfrage, den Workflow und den Tag. Jede fängt einen anderen Fehler ab.AnfrageBegrenzt Tokens, Tools, Zeit oder Dollar eines... Ein autonomer Agent braucht drei Grenzen in seiner Schleife: Budget für die Anfrage , den Workflow und den Tag . Jede fängt einen anderen Fehler ab. Anfrage Begrenzt Tokens, Tools, Zeit oder Dollar eines Versuchs und greift vor Provider- und Tool-Aufrufen. Workflow Verfolgt eine vollständige Aufgabe über Retries, Fallbacks und Subagenten. Ein korreliertes Ledger stoppt nicht konvergierende Schleifen. Tag Begrenzt die aggregierten Kosten eines Teams, Mandanten oder Dienstes. Nahe am Limit wird auf Batch oder kleinere Modelle geroutet. Nützliche Ablehnungen Zeigen Sie ausgelöstes Budget, Verbrauch und erlaubte Erholung und protokollieren Sie Reservierungen, Kosten und Ablehnungen. Weiterführend Leitplanken für Agentenausgaben Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Leitfaden zur Implementierung von Token-Budgets · FinOps LLM URL: https://finopsllm.com/de/research/token-budget-implementation-guide Leitfaden zur Implementierung von Token-Budgets Token-Budgets sind die operative Schicht der LLM-Kostenkontrolle. Attribution zeigt dir, wohin das Geld fließt; Budgets verhindern, dass es an Orte fließt, wo du es nicht möchtest. Ohne Budgets kann eine einzelne falsch konfigurierte Agentenschleife oder ein Anstieg des Benutzerverkehrs eine monatliche Zuweisung in Stunden aufbrauchen. Dieser Leitfaden behandelt die Implementierung von vier Arten von Token-Budgets in der Produktion mit Pseudocode für jedes Muster. Budget-Typen Budget-Typ Granularität Durchsetzung Anwendungsfall Pro Anfrage Einzelner API-Aufruf Hard Limit über max_tokens Parameter Verhindert unkontrollierte Completions, begrenzt Latenz Kontingent pro Team Team oder Projekt über einen Zeitraum Soft Limit mit Warnungen, Hard Limit bei Schwellenwert Kostenverteilung pro Abteilung, verhindert, dass ein Team das gemeinsame Budget aufbraucht Pro Zeitraum Täglich, wöchentlich oder monatlich Hard Limit mit Kulanzfrist Monatliche Budget-Obergrenzen, Ausgaben auf Sprint-Ebene Pro Workflow Eine einzelne Pipeline oder Agent-Ausführung Hard Limit pro Schritt und gesamt Multi-Step-Agents, RAG-Pipelines, Evaluierungsläufe Limits pro Anfrage Das einfachste Budget: Begrenzen Sie jede Anfrage mit max_tokens . Dies ist nicht optional – jede Produktionsanfrage sollte ein explizites Ausgabe-Token-Limit haben. Ohne es kann eine ausschweifende Modellantwort unerwartete Tokens verbrauchen und die Latenz erhöhen. // Per-request budget enforcement function callLLM(prompt, config): response = provider.complete( prompt: prompt, model: config.model, max_tokens: config.max_output_tokens, // hard cap temperature: config.temperature ) if response.usage.total_tokens > config.warn_threshold: log.warn("Request exceeded soft limit", tokens: response.usage.total_tokens, threshold: config.warn_threshold ) return response Kontingente pro Team Team-Kontingente erfordern einen gemeinsamen Counter, der über Anfragen hinweg persistent ist. Das Muster: Überprüfen Sie das verbleibende Budget vor jedem Aufruf, lehnen Sie ab oder stufen Sie herab, wenn das Budget aufgebraucht ist. // Team quota with Redis-backed counter function checkTeamBudget(teamId, estimatedTokens): key = "budget:" + teamId + ":" + currentPeriod() remaining = redis.get(key) or getTeamQuota(teamId) if remaining Budgets pro Zeitraum Budgets pro Zeitraum verbinden Team-Kontingente mit einem Zeitfenster. Der Hauptunterschied: Sie benötigen einen Kulanzfrist-Mechanismus. Wenn ein Team 80 % seines monatlichen Budgets erreicht, senden Sie eine Warnung. Bei 100 % erlauben Sie eine konfigurierbare Kulanzfrist (z. B. 24 Stunden), bevor die harte Durchsetzung beginnt. Dies verhindert, dass ein Team am letzten Tag des Monats in der Mitte einer Aufgabe blockiert wird. // Time-period budget with grace period function enforceBudget(teamId): usage = getUsageForPeriod(teamId, currentMonth()) limit = getTeamMonthlyLimit(teamId) if usage Budgets pro Workflow Multi-Step-Agents und Pipelines benötigen Budgets auf zwei Ebenen: pro Schritt (verhindert, dass ein einzelner Schritt zu viel verbraucht) und pro Ausführung (verhindert, dass die gesamte Pipeline ihre Zuweisung überschreitet). Verfolgen Sie beide im Workflow-Kontext. // Workflow budget tracker class WorkflowBudget: constructor(maxPerStep, maxTotal): this.maxPerStep = maxPerStep this.maxTotal = maxTotal this.spent = 0 function callStep(stepFn, prompt): if this.spent >= this.maxTotal: return fallbackResponse("Budget exceeded") response = callLLM(prompt, { max_tokens: min(this.maxPerStep, this.maxTotal - this.spent) }) this.spent += response.usage.total_tokens return response Schrittweise Herabstufung, wenn das Budget überschritten wird Geben Sie nicht einfach einen Fehler zurück, wenn ein Budget erreicht wird. Stufen Sie schrittweise herab. Wechseln Sie zu einem günstigeren Modell (GPT-4o-mini statt GPT-4o), reduzieren Sie die Kontextfenster-Größe, überspringen Sie optionale Verarbeitungsschritte, oder geben Sie ein Teilergebnis mit einer Notiz zurück, dass die vollständige Verarbeitung eine Budget-Genehmigung erfordert. Die Benutzererfahrung sollte sich verschlechtern, nicht unterbrochen werden. // Degradation chain function callWithDegradation(prompt, config): if checkBudget(config.teamId, FULL_MODEL): return callLLM(prompt, { model: config.primaryModel }) if checkBudget(config.teamId, CHEAP_MODEL): log.info("Downgrading model for budget") return callLLM(prompt, { model: config.fallbackModel }) if checkBudget(config.teamId, MINIMAL_TOKENS): truncated = truncateContext(prompt, 50%) return callLLM(truncated, { model: config.fallbackModel, max_tokens: 256 }) return cachedOrFallback(prompt) Überwachung der Budget-Gesundheit Verfolgen Sie drei Metriken: Verbrauchsrate (Tokens verbraucht pro Stunde vs. Budget), Prognose (bei aktuellem Tempo, wann ist das Budget aufgebraucht) und Override-Zähler (wie oft wurde die Kulanzfrist verwendet). Wenn die Kulanzfrist-Nutzung 10 % der Gesamtanfragen übersteigt, ist das Budget für die Workload zu niedrig festgelegt. Verwandte Ressourcen LLM-Budget-Governance - organisatorische Richtlinien hinter Budgets. Ausgabenschranken für Agenten - Budget-Muster für autonome Agenten. So begrenzen Sie Inferenzkosten - Provider-seitige Kostenkontrollen. Möchten Sie dies auf Ihre eigenen LLM-Ausgaben anwenden? FinOps LLM führt eine kostenlose Überprüfung Ihrer KI-Kosten durch und zeigt, wo die Einsparungen sind. Kostenlose Überprüfung buchen → Zurück zu Forschung --- # Tokenpreise fallen, LLM-Rechnung steigt · FinOps LLM URL: https://finopsllm.com/de/research/token-prices-bill-keeps-rising Tokenpreise fallen, LLM-Rechnung steigt Aktualisiert August 27, 2026 · erstveröffentlicht August 27, 2026 Kurzantwort: Günstigere Tokens garantieren keine kleinere Rechnung. In Produktion wachsen Kontextlängen, Agentenschritte, Ausgaben und Wiederholungen oft schneller als die Preise fallen. Trennen Sie Tarif,... Günstigere Tokens garantieren keine kleinere Rechnung. In Produktion wachsen Kontextlängen, Agentenschritte, Ausgaben und Wiederholungen oft schneller als die Preise fallen. Trennen Sie Tarif, Volumen, Mix und Effizienz. Der Tarif ist nur ein Teil Sinkt der Preis von 10 auf 6 Dollar je Million Tokens, steigt die Rechnung bei einem Verbrauch von 100 auf 220 Millionen Tokens trotzdem von 1.000 auf 1.320 Dollar. Erfassen Sie den tatsächlich berechneten Preis je Anbieter, Modell und Tokentyp statt eines irreführenden Durchschnitts. Die vier Abweichungen Volumen ist die Tokenmenge. Mix zeigt den Wechsel zu teureren Modellen oder Funktionen. Effizienz beschreibt die Kosten eines erfolgreichen Ergebnisses: Retries, fehlgeschlagene Tools, zu lange Prompts und ungenutzte Ausgaben. Verknüpfen Sie jeden Modellaufruf mit der Provider-Rechnung. Die wöchentliche Prüfung Erstellen Sie eine Brücke von Rechnung zu Rechnung: Tarif, Volumen, Mix, Effizienz. Überwachen Sie die verkehrsbereinigten Kosten je erfolgreicher Aufgabe. Beheben Sie zuerst die Kategorie mit dem größten Dollarbetrag. Sinkende Preise helfen, aber nur eine abgestimmte Sicht auf Nutzung, Qualität und Kosten macht daraus echte Einsparung. Weiterführend LLM-Kostenüberwachung Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Wortreiche Prompts kosten Steuer · FinOps LLM URL: https://finopsllm.com/de/research/verbose-prompt-tax Wie Prompt-Stil auf der Rechnung erscheint Aktualisiert September 1, 2026 · erstveröffentlicht September 1, 2026 Kurzantwort: Prompts wachsen wie Konfigurationsdateien: jemand ergänzt eine Anweisung wegen eines Fehlers, jemand ein Beispiel, ein Dritter einen erklärenden Absatz. Entfernt wird nie etwas. Ein halbes Jahr später... Prompts wachsen wie Konfigurationsdateien: jemand ergänzt eine Anweisung wegen eines Fehlers, jemand ein Beispiel, ein Dritter einen erklärenden Absatz. Entfernt wird nie etwas. Ein halbes Jahr später hat der System-Prompt dreitausend Tokens und niemand weiß, welche zweihundert davon tragen. Warum sich das aufsummiert Anders als die Ausgabe wird der Prompt-Overhead bei jeder Anfrage identisch bezahlt, dauerhaft. Tausend verschwendete Tokens bei zehn Millionen Aufrufen im Monat sind zehn Milliarden Tokens reiner Formatierung pro Monat. In Mehrturn-Dialogen ist es schlimmer: Der System-Prompt geht bei jedem Turn erneut mit. In Agenten-Schleifen wird derselbe aufgeblähte Vorspann für eine Nutzeraktion ein Dutzend Mal abgerechnet. Was wirklich verschwendet Nicht die Höflichkeit. Das Gewicht liegt in redundanten Anweisungen, defensivem Boilerplate für eine längst abgelöste Modellgeneration, sich duplizierenden Beispielen und Erklärungen für menschliche Leser der Datei. Als Code mit Budget behandeln Messen Sie den festen Prompt als Anteil der durchschnittlichen Anfrage. Stabilen Teil nach vorn, damit Caching greift. Dann per Ablation kürzen: einen Block entfernen, Evals laufen lassen, streichen wenn die Qualität hält. Weiterführend Ökonomie des Prompt-Caching Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Sprachagenten rechnen pro Minute ab · FinOps LLM URL: https://finopsllm.com/de/research/voice-agents-bill-per-minute Stückkosten von Realtime- und Audio-APIs Aktualisiert September 1, 2026 · erstveröffentlicht September 1, 2026 Kurzantwort: Jedes für Text gebaute Kostenmodell bricht bei Sprache. Text wird nach Tokens abgerechnet, die proportional zur Information sind. Audio wird nach Dauer abgerechnet, proportional zur Zeit —... Jedes für Text gebaute Kostenmodell bricht bei Sprache. Text wird nach Tokens abgerechnet, die proportional zur Information sind. Audio wird nach Dauer abgerechnet, proportional zur Zeit — einschließlich aller Zeit, in der nichts Nützliches passiert. Wofür Sie wirklich zahlen Eine Sprachinteraktion stapelt drei oder vier Posten: Transkription eingehend, der Modellaufruf (bei Realtime-APIs pro Audiominute), Sprachsynthese ausgehend, und oft die offene Session. Letzteres ist die Falle: Am Minutenzähler ist Stille ein Produkt zum vollen Preis. Wo Schätzungen danebenliegen Man rechnet Sprechzeit × Tarif und landet deutlich zu niedrig. Es fehlen Pausen und Latenz, generiertes Audio, das der Anrufer unterbrochen hat, Wiederholungen (die Audio wiederholen, nicht nur Tokens) und abgebrochene Anrufe. Die brauchbare Kennzahl Kosten pro abgeschlossenem Gespräch, nicht pro Minute. Und schließen Sie Leerlauf-Sessions konsequent — meist der größte verfügbare Hebel. Weiterführend Ökonomie von Agenten Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # Was ist DeepSeek Harness? Der Leitfaden · FinOps LLM URL: https://finopsllm.com/de/research/what-is-deepseek-harness Was ist DeepSeek Harness? Ein Leitfaden Aktualisiert August 16, 2026 · erstveröffentlicht August 16, 2026 Kurzantwort: DeepSeek Harness — Paketname dsh — ist ein quelloffenes Agenten-Harness von DeepSeek AI unter MIT-Lizenz. Dies ist die Fassung ohne Vorwissen: was es ist, wie man es startet, wie es aufgebaut ist und... DeepSeek Harness — Paketname dsh — ist ein quelloffenes Agenten-Harness von DeepSeek AI unter MIT-Lizenz. Dies ist die Fassung ohne Vorwissen: was es ist, wie man es startet, wie es aufgebaut ist und ob es Sie etwas angeht. Was ein Agenten-Harness überhaupt ist Ein Modell erzeugt Text und Werkzeugaufrufe. Mehr nicht. Alles Übrige, was einen Agenten nützlich macht, ist das Harness: den Prompt zusammensetzen, die angeforderten Werkzeuge tatsächlich ausführen, durchsetzen was erlaubt ist, protokollieren was geschah, die Schleife steuern, die über einen weiteren Modellaufruf entscheidet, und Arbeit an Unteragenten abgeben. Diese Unterscheidung lohnt sich vor allem anderen, denn das meiste, was ein Agent gut oder schlecht macht, ist Verhalten des Harness und nicht des Modells. Zwei Teams mit demselben Modell erhalten sehr unterschiedliche Ergebnisse und sehr unterschiedliche Rechnungen — der Unterschied wohnt hier. Was DeepSeek Harness tut Es betreibt Coding- und Automatisierungsagenten. Konkret liest und bearbeitet der Agent Dateien, führt Shell-Befehle aus, durchsucht die Codebasis, delegiert an Unteragenten, plant Arbeit und fragt gemäß der aktiven Berechtigungsrichtlinie nach. Es gibt eine Browser-Oberfläche, einen Headless-Modus für Einzelläufe und einen Automatisierungsserver, der JSON-RPC über Standardein- und -ausgabe spricht. Die eine Entwurfsidee: alles ist ein Plugin Das Harness läuft auf Cordis , einer Plugin-Laufzeit, in der Plugins Dienste, typisierte Ereignisse und umkehrbare Effekte in einen gemeinsamen Kontext einbringen. Es gibt keinen privilegierten Kern. Der Modelladapter ist ein Plugin. Die Werkzeugregistrierung ist ein Plugin. Das Sitzungsprotokoll ist ein Plugin. Die Agentenschleife selbst ist ein Plugin. Die meisten erweiterbaren Systeme geben Ihnen einen festen Kern plus Hooks: beobachten und dekorieren ja, ersetzen nein — und Ersetzen heißt Forken. Eine Plugin-Laufzeit dreht das um: genau die Teile, die man am ehesten austauschen möchte, sind die Einheiten der Komposition. Zum Laufen bringen Der schnelle Weg npx @deepseek-ai/dsh web Das startet eine lokale Weboberfläche unter http://127.0.0.1:3080 . Aus dem Quellcode git clone https://github.com/deepseek-ai/deepseek-harness cd deepseek-harness pnpm install pnpm run build pnpm dsh web Voraussetzungen: Node 22.19 oder neuer (die CI deckt 22.19, 24 und 26 ab), Git 2.26 oder neuer und pnpm über Corepack festgelegt. Ein DeepSeek-API-Schlüssel ist bei der Installation optional, für sinnvolle Arbeit aber nötig; er kann aus der Umgebung oder aus einer gitignorierten .env im Wurzelverzeichnis kommen. Die zwei Schritte, die alle übersehen Einstellungen → Modelle. API-Schlüssel eintragen. Die Route wird sofort aktiv, ohne Neustart. Arbeitsbereich wählen. Projektverzeichnis hinzufügen und aktivieren. Der Sitzungs-Composer bleibt gesperrt, solange kein Arbeitsbereich aktiv ist — der übliche Grund, warum eine frische Installation defekt aussieht. Headless pnpm dsh --profile headless "summarize this workspace" Das ist der Modus, auf den es bei Automatisierung ankommt: ein Harness, das nur interaktiv funktioniert, lässt sich nicht in die CI stellen, und was nicht in der CI läuft, lässt sich nicht regelmäßig messen. Die Begriffe, die Sie für die Doku brauchen Begriff Bedeutung Schritt (step) Ein Modellaufruf plus die davon ausgelösten Werkzeugaufrufe Zug (turn) Ein Leeren der Eingabe, beendet wenn das Modell stoppt oder die Richtlinie eingreift Runde (round) Eine äußere Richtlinien-Iteration über Zügen, etwa ein neuer Anlauf auf ein Ziel Sitzung (session) Ein reines Anhänge-Protokoll typisierter Ereignisse — die alleinige Wahrheitsquelle des Laufs Fähigkeitsnaht Eine Dienstschnittstelle mit mehreren austauschbaren Implementierungen Profil Eine benannte Komposition: geordnete Liste von Plugin-Bündeln plus eigene Patches Scope Die Registrierungseinheit pro Agent für Werkzeuge, Prompts und Einschränkungen Die Konfiguration löst in vier Schichten auf, spätere gewinnen: Profil-Bündel, dann Profil-Patches, dann Patches auf Home-Ebene, dann Overlays von der Kommandozeile. Wer diese Reihenfolge kennt, verwandelt „warum nimmt es dieses Modell?“ von einer Untersuchung in ein Nachschlagen. Was daran bemerkenswert ist Die Modellwahl ist austauschbar. Der Modelldienst ist eine Schnittstelle mit mehreren Backends, darunter eines, das eine aufgezeichnete Sitzung wiedergibt, ohne erneut für Inferenz zu zahlen. Die Agentenschleife konsumiert einen anbieterneutralen Strom und erfährt nie, welches Backend aktiv ist. Die Aufzeichnung ist konstruktionsbedingt vollständig. Der Leitsatz lautet: was für das Modell sichtbar ist, wird protokolliert. Der Tokenverbrauch reist an der Ausgabe mit, die ihn verursacht hat. Die Durchsetzungspunkte sind explizit. Einer vor dem Absenden der Modellanfrage, dessen Entscheidung als maßgeblich dokumentiert ist, und einer vor der Ausführung jedes Werkzeugrumpfs. Berechtigungswächter können ablehnen oder sich enthalten, aber niemals gewähren; eine unbeantwortbare Freigabeanfrage lehnt ab. Es läuft headless. Also skriptbar, planbar und messbar. Der Plugin-Anspruch ist nicht bloß Positionierung: eine der mitgelieferten Demos ist selbstbezüglich und inspiziert und verändert ihre eigene laufende Plugin-Laufzeit. Das lässt sich schwer vortäuschen. Wann einsetzen — und wann nicht Setzen Sie es ein zum Evaluieren, zum Prototyping und als konkreten Maßstab für den Agenten-Stack, den Sie ohnehin betreiben. Die fünf Fragen, die Sie mitnehmen sollten: Ist die Modellwahl austauschbar? Gibt es eine vollständige Sitzungsaufzeichnung mit angehängtem Verbrauch? Existieren Durchsetzungspunkte vor dem Modellaufruf und vor der Werkzeugausführung? Läuft es headless? Ist die Konfigurationsschichtung dokumentiert? Standardisieren Sie nicht in diesem Quartal darauf. Das Projekt bezeichnet sich selbst als Developer Preview und sagt deutlich, dass es kompatibilitätsbrechende Änderungen geben wird. Fixieren Sie die Version, gegen die Sie bauen, und planen Sie keine Produktionsmigration auf einer Preview-API. Was der Betrieb kostet Das Harness ist MIT-lizenziert und kostenlos. Inferenz nicht. Sie liefern einen DeepSeek-API-Schlüssel oder richten die Modellnaht auf einen anderen Anbieter. Praktisch heißt das: Ihre Rechnung ist eine Funktion von Schritten pro Zug, Werkzeugen im Katalog, Delegationstiefe und der Zahl der Runden, die ein offenes Ziel laufen darf — allesamt Entscheidungen auf Harness-Ebene, keine davon der ausgehandelte Tokenpreis. Weiterführend Installation, Profile und erster Lauf (EN) Was „alles ist ein Plugin“ wirklich bringt (EN) Das Sitzungsprotokoll als Kostennachweis (EN) Wo Ausgaben-Leitplanken hingehören (EN) Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen → Zurück zu finopsllm.com --- # FinOps LLM - Gestión de costes de IA y observabilidad LLM URL: https://finopsllm.com/es/ FINOPS · LLM Construido sobre los principios de la Fundación FinOps · adaptado para tokens Control de costes de IA para la era de los tokens. FinOps LLM es la plataforma de gestión de costes de IA y observabilidad de LLM para equipos de ingeniería que ejecutan IA generativa en producción. Atribución en tiempo real en OpenAI, Anthropic, Bedrock y Gemini · detección de anomalías , chargeback y optimización automatizada (enrutamiento, caché, compresión) · reconciliación mensual contra facturas brutas de proveedores. Solicita auditoría gratuita → Visita la plataforma Auditorías basadas en facturas Reducción típica 40–60% Solo lectura por defecto Multi-cloud app.finopsllm.com / customer-042 / overview DEMO Espacio de trabajo ◧ Descripción general ◫ Atribución 12 ⚡ Anomalías 3 ↗ Previsión Optimización ◊ Enrutamiento ⌬ Caché ≡ Compresión Finanzas $ Chargeback ▥ Presupuestos ✓ Conciliación Descripción general Gasto Calidad Conciliación Gasto mes a la fecha $70,280 ↓ 57.4% vs. línea base Ahorro de muestra $94,720 reconciliado con factura Tasa de acierto de caché 38.1% +4.2 pts semana a semana Delta de calidad +0.2% Prueba A/B activa 7 días Gasto diario de LLM · últimos 45 días 5 abr - 5 may, 2026 Línea base ($165K/mes) Optimizado ($70.3K/mes) Atribución de gasto · este mes por característica RAG · 38% Agente · 26% Correo · 18% Clasif. Otro Búsqueda RAG $26.7K Ejecuciones de agente $18.3K Redacción de correos $12.6K Clasificación $7.7K Feed de actividad Últimas 24 horas · ver todo ! Anomalía: gasto p95 RAG +38% vs. promedio 7 días 14:22 UTC · feature/rag-v2 · investigar → $ Enrutamiento v3 promovido al 100% del tráfico 11:08 UTC · ahorro proyectado: $4,820/mes + Tasa de acierto de caché superó el umbral del 38% 09:14 UTC · invalidación afinada ⚑ Presupuesto · equipo "agente" al 78% mes a la fecha 06:42 UTC · estrangulación automática armada ✓ Conciliación abr 2026 firmada 1 may · −57.4% vs. línea base Conciliado contra todos los proveedores principales OpenAI Anthropic Gemini Bedrock Azure Groq Together Mistral 01 La plataforma FinOps para IA, en cuatro pilares. FinOps LLM trae el marco de la Fundación FinOps - visibilidad, atribución, optimización, responsabilidad - al gasto en LLM y GenAI. Misma disciplina. Unidad de coste diferente. PILAR 01 Visibilidad Datos de coste a nivel de token ingeridos de cada proveedor. Reconciliados cada hora. Filtrables por proveedor, modelo, característica, equipo, cliente, entorno. OpenAI · Anthropic · Bedrock · Gemini · Azure · Groq · Together Ingesta horaria · <5 min de retraso de reconciliación Solo lectura por defecto · NDA y DPA bajo demanda PILAR 02 Atribución & chargeback Cada token mapeado a una característica, equipo y cohorte de cliente. Chargeback y showback mensuales, exportados a tu sistema financiero o como CSV. Dimensiones personalizadas · característica, equipo, nivel, región Gasto por cohorte · P&L por nivel de cliente NetSuite · QuickBooks · CSV · API PILAR 03 Detección de anomalías Alertas en tiempo real cuando el gasto, latencia o calidad se desvía de la línea base móvil de una característica. Slack, PagerDuty, correo - y estrangulación automática cuando importa. Líneas base móviles por característica · conscientes de la estacionalidad Slack · PagerDuty · correo · webhook Estrangulación automática opcional & cumplimiento de presupuesto PILAR 04 Optimización automatizada Enrutamiento de modelos, caché semántica y compresión de prompts desplegados detrás de feature flags, probados A/B durante mínimo siete días, graduados solo en ganancias de calidad y coste. Árbol de enrutamiento · clasificación de calidad por solicitud Caché semántica · latencia de acierto <10ms SLO de calidad + reversión automática en regresión 02 Optimización Seis palancas que tiramos, en cada compromiso. La mayoría de equipos combinan tres o cuatro. La auditoría clasifica cuáles dominan tu superficie de gasto y proyecta ahorros antes de cualquier compromiso. 01 30–50% Enrutamiento de modelos Cada solicitud clasificada por complejidad y enrutada al modelo más barato que cumple tu estándar de calidad. Razonamiento a modelos insignia; clasificación y extracción a modelos pequeños y rápidos. 02 20–40% Caché semántica Prompts casi duplicados identificados con embeddings; respuestas idénticas servidas desde caché <10ms. Umbrales de similitud afinados por característica. 03 15–30% Compresión de prompts Prompts del sistema auditados por redundancia. Ejemplos deduplicados. Contexto recuperado comprimido con técnicas estilo LLMLingua. Cada cambio probado A/B. 04 10–50% Precios de lote & asincronía Cargas de trabajo no interactivas enrutadas a endpoints de lote (hasta 50% de descuento) con encolamiento consciente de SLO para rutas sensibles al tiempo. 05 20–35% Arbitraje de proveedores Capacidad idéntica frecuentemente cuesta 2–3× más en un proveedor. Enrutamos por capacidad por dólar, no por el SDK con el que tu equipo comenzó. 06 5–15% Cadenas de fallback Reintentos inteligentes y fallbacks escalonados superan el sobre-aprovisionamiento del peor caso. Mantén SLO sin pagar precios de insignia en cada llamada. 03 Compromiso Audita. Implementa. Reconcilia. Repite. Cada compromiso sigue las mismas cuatro fases. La mayoría de clientes ven su primera factura de proveedor reconciliada al final de la semana cinco. 01 SEMANA 01 AUDITORÍA Mapea cada dólar. Ingerimos facturas de proveedores, logs de gateway y telemetría de uso. El viernes, tienes un mapa completo de tu gasto en LLM - por proveedor, modelo, característica, equipo - clasificado por desperdicio en dólares. Entregable Mapa de gasto · oportunidades priorizadas · línea base fija (contrafirmada) 02 SEMANA 02 PLAN Clasifica por desperdicio. La auditoría se convierte en un plan de ingeniería priorizado respetando tu postura de cumplimiento, SLOs de latencia y proceso de lanzamiento. Guardarraíles de calidad acordados por endpoint. Firmas en cada cambio. Entregable Plan de ingeniería · árbol de enrutamiento · especificación de caché · SLOs de calidad · cronograma de lanzamiento 03 SEMANAS 03–05 LANZA Lanza & prueba A/B. Los ingenieros de FinOps LLM se emparejan con los tuyos para lanzar cada optimización detrás de feature flags, probar A/B durante siete días versus la línea base, y graduar al 100% del tráfico. El centro de control se activa junto a él. Entregable Centro de control activo · alertas Slack · revisión semanal · primera reconciliación 04 CONTINUO RECONCILIA Compone los ahorros. Los precios se mueven. El tráfico cambia. Los modelos se lanzan. La plataforma vigila la desviación; recomendamos e implementamos seguimientos para que los ahorros se compongan. Cada mes cierra con una Declaración de Ahorros firmada. Entregable Declaración mensual firmada · alertas de desviación & calidad · afinación continua 04 Resultados Números de compromisos reales. Rangos de reducción ilustrativos de palancas de optimización de LLM comunes. Los objetivos reales se establecen después de una auditoría de factura de proveedor y revisión de carga de trabajo. Reducción típica 40–60 % Rango entre compromisos, dependiendo de arquitectura y mezcla de tráfico. Tiempo a ahorros 3–5 sem Kickoff → primera factura de proveedor reconciliada. Delta de calidad +0 .2 % Cada cambio probado A/B mínimo 7 días. Cuota de auditoría $0 Gratuita - acreditada contra implementación. 05 Precios Paga por resultados. Hay un solo compromiso y se cobra sobre el ahorro verificado. Tidal Telemetry es software aparte, gratis en beta. ★ MÁS POPULAR Rendimiento Auditoría gratuita. Después, solo pagas cuando nos ahorras dinero - medido contra una línea base fija, reconciliado con facturas de proveedores. 15–25 % del ahorro verificado Sin ahorros, sin cuota · auditoría acreditada contra implementación · cancela en cualquier momento ✓ Auditoría gratuita · turnaround de 1 semana · línea base contrafirmada ✓ Stack de optimización completa · enrutamiento, caché, compresión, arbitraje ✓ Centro de control activo + chargeback + declaraciones mensuales firmadas ✓ Emparejamiento de ingeniería con equipo FinOps LLM · revisiones semanales ✓ Cumplimiento de SLO de calidad & reversión automática ✓ Mínimo: $20K/mes gasto en LLM Solicita auditoría gratuita → AUTOSERVICIO · PRODUCTO APARTE Tidal Telemetry Software de observabilidad que contratas y ejecutas tú mismo. Sin compromiso gestionado y sin filtro comercial. Gratis en beta sin tarjeta · los usuarios beta conservan un plan gratuito ✓ Una línea de código · ~50 librerías auto-instrumentadas ✓ Ingesta OpenTelemetry estándar · el SDK es opcional ✓ Coste por llamada, tokens, latencia y errores como trazas ✓ Almacenamiento y clave de ingesta aislados por proyecto ✓ Servidor MCP integrado para configuración con agentes ✓ Sin requisito de compromiso · úsalo sin hablar con nosotros Ver Tidal Telemetry → 06 Preguntas frecuentes Preguntas comunes. ¿Te falta algo? Correo a hello@finopsllm.com - respondemos dentro de un día laboral. ¿Qué es FinOps para LLM? + FinOps para LLM trae el marco de la Fundación FinOps - visibilidad, atribución, optimización y responsabilidad - al gasto en LLM y GenAI. Incluye chargeback y showback por característica y equipo, detección de anomalías, gobernanza de presupuesto y optimización continua del enrutamiento de modelos, caché y prompts. ¿Qué hace FinOps LLM? + FinOps LLM es un compromiso gestionado, no una licencia de plataforma. Proporcionamos atribución de gasto en tiempo real en OpenAI, Anthropic, Bedrock y Gemini, más optimización automatizada (enrutamiento, caché, compresión) y reconciliación mensual contra facturas de proveedores. ¿Cómo está estructurado el precio? + Un solo modelo. Auditoría gratuita, después 15–25% del ahorro mensual verificado, medido contra una línea base fijada antes de cualquier cambio. Sin licencia, sin asientos, sin mínimo de plataforma. Tidal Telemetry es un producto aparte y es gratis en beta. ¿Cuánto podemos ahorrar? + La reducción típica en el primer ciclo de facturación completo después de la implementación es 40–60% , dependiendo de la arquitectura y mezcla de tráfico. ¿Qué proveedores son compatibles? + OpenAI, Anthropic, Gemini & Vertex AI, AWS Bedrock, Azure OpenAI, Groq, Together, Mistral, Cohere, Fireworks, Replicate , y la mayoría de endpoints OSS. Los despliegues multi-proveedor típicamente tienen la mayor superficie de ahorros. ¿FinOps LLM soporta chargeback & showback? + Sí. Atribución a nivel de token a proveedores, modelos, características, equipos y cohortes de clientes. Chargeback y showback mensuales exportados a NetSuite, QuickBooks, CSV, o API . Se soportan dimensiones personalizadas. ¿Cómo manejas los datos del cliente? + Solo lectura por defecto. Los datos de facturación y uso son suficientes para la mayoría del trabajo de atribución. Los datos de prompts y salidas se acceden solo con aprobación explícita del cliente, para optimizaciones específicas que lo requieren. NDA y DPA disponibles bajo demanda. ¿Cuánto tiempo toma la implementación? + La atribución y dashboards se activan en menos de una semana . La implementación de optimización toma 3–5 semanas; los ahorros aparecen en la primera factura completa del proveedor después del go-live. ¿La optimización dañará la calidad de salida? + No. Cada cambio de enrutamiento, caché y compresión se prueba A/B contra producción durante mínimo siete días antes de la promoción. Las regresiones se revierten automáticamente. La calidad se monitorea continuamente junto al coste. 07 Recursos Guías, benchmarks & herramientas. Investigación larga para líderes de ingeniería y finanzas evaluando FinOps para IA. Gratuita, sin registro, actualizada mensualmente. GUÍA ↗ FinOps para LLM: un marco completo Visibilidad, atribución, optimización, responsabilidad - aplicados a tokens. Con una arquitectura de referencia de 30 páginas. 16 MIN · MAY '26 NUEVO GUÍA SEO -> Optimización de costes de IA Un playbook práctico para reducir gasto en IA mediante enrutamiento, caché, lotes y disciplina de prompts. 8 MIN MAY '26 TUTORIAL ↗ Atribución de costes a nivel de token en producción Estrategias de tagging, matemáticas de chargeback y patrones de integración de gateway. Con código de referencia. 11 MIN · CÓDIGO 4.2K LECTURA OPERACIONES ↗ Monitoreo de costes de LLM Las métricas, alertas y límites de propietario que evitan que los cambios de gasto se oculten en facturas mensuales. 10 MIN OPS GUÍA ↗ Detectando anomalías de costes de LLM antes de la factura Líneas base por característica, estacionalidad y cómo cablear alertas que los ingenieros no silenciarán. 9 MIN · PLANTILLAS 3.1K LECTURA RAG -> Optimización de costes de RAG Reduce desperdicio de tokens impulsado por recuperación con mejor chunking, límites de contexto más estrechos y reranking selectivo. 7 MIN PRÁCTICO REFERENCIA ↗ Glosario de FinOps de IA Definiciones para atribución, showback, chargeback, tokens de lectura de caché, enrutamiento y coste por tarea exitosa. REFERENCIA GRATUITA FINANZAS ↗ Chargeback y showback de LLM Cómo reportar gasto de IA por equipo y producto antes de convertirlo en asignación presupuestaria. 8 MIN GOBERNANZA OPENAI ↗ Atribución de costes de OpenAI Request tags, reconciliación de factura, reintentos y clases de carga de trabajo para gasto en OpenAI. 7 MIN PRÁCTICO ANTHROPIC -> Atribución de costes de Anthropic Rastrear gasto de Anthropic por característica, propietario, carga de trabajo y comportamiento de enrutamiento sin romper la reconciliación. 7 MIN NUEVO ENRUTAMIENTO ↗ Enrutamiento de modelos Cómo enviar solicitudes fáciles a modelos más baratos y mantener intacta la calidad, latencia y comportamiento de fallback. 12 MIN ALGO MÉTRICAS -> Rastreo de tokens de LLM Los campos a nivel de solicitud que hacen que los cambios de costes de IA sean explicables para ingeniería y finanzas. 6 MIN OPS PRECIO ↗ Arbitraje de proveedores Compara capacidad de modelo equivalente en proveedores sin subestimar costes de migración y gastos generales. 11 MIN BENCHMARKS DATOS ↗ Benchmark de precio por capacidad de LLM · Q2 '26 Coste por tarea exitosa mensual en GPT, Claude, Gemini, Mistral, Llama, en cargas de trabajo estandarizadas. ACTUALIZADO MENSUALMENTE Q2 '26 EN VIVO ESTUDIOS DE CASO ↗ Resultados de clientes Los estudios de caso públicos se publicarán solo después de la aprobación del cliente. Hasta entonces, las referencias de evaluación se manejan de forma privada. BAJO NDA HONESTO 08 Comienza aquí Pon tu factura de IA bajo supervisión adulta. Aproximadamente una semana. Acceso de solo lectura. Regresamos con un mapa completo de tu gasto, clasificado por desperdicio, más una línea base que nuestro centro de control puede rastrear. Gratuita. Sin compromiso de implementación. Solicita auditoría gratuita → Ver benchmarks DESCUBRIMIENTO DE 30 MIN · SOLO LECTURA POR DEFECTO · NDA + DPA BAJO DEMANDA · SIN COMPROMISO --- # Investigación · FinOps LLM URL: https://finopsllm.com/es/research Investigación Notas para equipos de ingeniería y finanzas que construyen la gobernanza del gasto en IA. Empieza aquí Explicaciones claras si te inicias en los costes de LLM. ¿Cómo cobran los proveedores de LLM? Tokens de entrada, salida, caché y razonamiento explicados ¿Qué es la atribución de costes de LLM? ¿Por qué se dispara mi factura de LLM? Cómo presupuestar el gasto en IA Toda la investigación ¿Cuánto Cuesta GPT-5? Guía Completa de Precios 2026 ¿Qué es DeepSeek Harness? Guía completa A quarter of AI spend is slipping to 2027 (EN) Agent spend attribution (EN) Agent spend guardrails (EN) Agent Spend Guardrails: Runtime Controls That Work (EN) Agent TCO: The 70% of Cost That Isn't Tokens (EN) Agentes en segundo plano y el reloj FinOps AI Coding Economics 2026: GLM vs DeepSeek vs Claude (EN) AI Cost Allocation: Tags, Cost Centers and Chargebacks (EN) AI Cost Optimization Checklist for 2026 (EN) AI Cost Optimization: Routing, Caching, Batching (EN) AI Cost Optimization: Six Levers That Actually Work (EN) AI cost recovery playbook: stop the bleeding (EN) AI FinOps: el modelo operativo del gasto en GenAI AI observability: cost, traffic, and quality · FinOps LLM (EN) Añadir procedencia a la salida de IA Anthropic cost attribution (EN) Atribución de costes de LLM Atribución de costes de OpenAI Azure OpenAI vs OpenAI Directo: comparativa de costes y PTU Batch APIs as a FinOps lever (EN) Búsqueda web como centro de costos en agentes Calculadora de Costes LLM - Estima Tu Gasto Mensual en IA Chargeback vs Showback: Picking the Right FinOps Model (EN) Chargeback when your provider won't bill per team (EN) Chargeback y showback de LLM ChatGPT Pro Max $500 plan economics (EN) Claude Max 20x isn't 20x. We checked 60 days of logs against Codex (EN) Claude Max 20x vs 5x: is the $200 price worth it? We measured the real weekly usage ceiling (EN) Claude Max vs Alibaba Token Pro: el coste real del código agéntico Claude Sonnet 5.5 pricing: what changes, what does not (EN) Claude Sonnet 5.5: the cost-aware model routing guide (EN) Cloud Infrastructure Cost Audit: Alibaba vs Claude Max (EN) Codex auto-compact on GPT-6 Sol: the defaults in the source code, and what raising them costs (EN) Codex usage limit resets: how they work, banked resets and a dated log (EN) Cómo auditar tu gasto en LLM en 30 minutos Cómo el estilo de prompt aparece en la factura Cómo funciona la marca de agua de IA Cómo se destruyen las marcas de agua Cómo usar Jev en un agente de IA Comparación de Planes de Codificación IA Controla el coste dentro del pipeline de evaluación LLM Controlar el coste de tokens de esquemas MCP en agentes Cost per request as a product KPI (EN) Coste de cumplimiento de la marca de agua Coste en tokens del modo JSON y los esquemas Coste por activo aprobado en imagen y vídeo Coste real por tarea en los modelos frontera Créditos de IA en SaaS: medir una unidad que no controlas Cursor vs Copilot vs Claude Code Cost (EN) DeepSeek Harness: ámbitos, restricciones y sombreado de herramientas DeepSeek Harness: instalación, perfiles y primera ejecución DeepSeek Harness: objetivos, rondas de objetivo y el bucle Ralph DeepSeek Harness: qué aporta de verdad «todo es un plugin» Descuentos por compromiso de gasto Detección de anomalías en costes de IA Dónde poner los límites de gasto en DeepSeek Harness Economía de agentes: ¿cuánto cuesta un agente de código? Economía de Opus 5.5 fast mode Economía del Cierre de Fine-Tuning de OpenAI Economía unitaria de las APIs de audio en tiempo real El bucle de reintentos que añade gasto de inferencia El coste por tarea exitosa supera al coste por solicitud El coste real de cambiar de proveedor LLM El coste recurrente de embeddings y vectores El gasto en IA fuera de tu factura de API El manual del modelo sigiloso El plan gratuito como coste de captación El primer cierre mensual para un producto con mucha IA El registro de sesión de DeepSeek Harness como registro de costes Enterprise AI procurement and committed spend (EN) Estrategias de caché comparadas Eval cost allocation: who pays for LLM evals (EN) Exposición a divisa en el gasto de LLM Find the cache miss behind your OpenAI bill (EN) FinOps para LLM y GenAI: un marco práctico FOCUS 1.5: rastreo nativo de tokens de IA y Price Sheets Frenar la cascada de subagentes y delegación recursiva de tareas Gartner's 2026 AI spending forecast (EN) Gasto de LLM fuera de producción GenAI cost management: controls and analytics (2026) (EN) Generación de código con IA más barata (2026) GPT-5 Pricing and Budget Impact: A 2026 Planning Guide (EN) GPT-5 vs GPT-4o Cost Comparison: When to Upgrade (EN) GPT-6 Astra cost model (EN) GPT-6 Luna cost model (EN) GPT-6 pricing: Astra, Sol and Luna (EN) GPT-6 Sol cost model (EN) GPT-6 Sol long-context benchmarks: what has actually been measured, and what is GPT-5.6 Sol (EN) Guía de Costes de Modelos de Razonamiento Guía de implementación de presupuestos de tokens Guía de Precios de GPT-5.6: Luna, Terra, Sol Hidden LLM Costs Beyond Per-Token Pricing (EN) How do LLM providers charge? Tokens, tiers, caching (EN) How many tokens do you get with Claude Pro and Max? We counted them (EN) How much Codex does ChatGPT Pro include? We priced the weekly limit in dollars (EN) How to budget for AI spend: a starter framework (EN) How to cap inference costs and prevent runaway spending (EN) How to check and reduce Claude Code token usage (EN) Impacto en costes de servidores MCP Input, output, cache, reasoning: what tokens cost (EN) Invoice reconciliation for AI spend (EN) IT Chargeback and Showback Explained (EN) IT Chargeback and Showback for AI: A Practical Guide (EN) IT Showback: A Practical Guide for Technology Teams (EN) Las herramientas de servidor son otra factura Latest AI models and Anthropic's proposed IPO (EN) LLM Budget Governance: Alerts and Guardrails (EN) LLM Cost Benchmarks by Industry (EN) LLM cost dashboard: what to put on it (EN) LLM Cost Management: A Practical Framework (EN) LLM Cost Monitoring in Production: A Field Guide (EN) LLM cost monitoring: what to track and how to control it (EN) LLM Cost Per User Benchmarks (EN) LLM Cost Tracking: Tools, Tags and Telemetry (EN) LLM Cost Visibility: Dashboards and Metrics That Matter (EN) LLM FinOps standards (EN) LLM Provider Arbitrage: Price and Quality Parity (EN) LLM Purchasing Guide for Platform Teams (EN) LLM Token Tracking by Input, Output and Cache (EN) LLM Usage Metering: How to Bill Internal AI Spend (EN) Lo que cuestan los guardrails y la moderación Long context vs RAG: where the cost breakeven actually is (EN) Los niveles de esfuerzo de Opus 5.5 son el precio real Los tres presupuestos que necesita todo agente autónomo Mide el margen bruto de una función de IA antes de lanzarla Minimax M3.1 Flash free preview economics (EN) Model deprecation migration: budgeting for forced moves (EN) Model Routing: Cheaper Models, Same Output Quality (EN) Modelo de coste de Claude Fable 5.1 Modelo de costes de Claude Opus 5.5 Modelos Abiertos vs. Cerrados: Comparativa de Costes LLM Multi-provider, multi-team LLM FinOps (EN) Multimodal cost allocation (EN) NVIDIA Open Agent Safety Platform: the FinOps implications (EN) Observabilidad de IA como segunda factura On-prem and self-hosted LLM FinOps (EN) OpenAI agent message board cost model (EN) OpenAI O / AON always-on agent cost model (EN) OpenAI Ultra Fast API pricing and speed tiers (EN) OpenTelemetry GenAI conventions for cost attribution (EN) Opus 5.5 long-running agent cost analysis (EN) Order of LLM cost optimizations (EN) Ox Alpha era GLM-5.3 Pagar dos veces la ventana de contexto Pensamiento adaptativo y previsión de costes Precio de un modelo de pesos abiertos Precios de proveedores IA: comparación real Probar el ROI de IA sin ocultar fallos Prompt cache attribution (EN) Prompt caching explained (EN) Prompt Caching ROI: Calculating Real Savings (EN) RAG cost optimization (EN) Rate limits, 429 y subidas de tier Real-SWE cost per resolved issue (EN) Reasoning token attribution and chargeback (EN) Rebajas de modelos y el presupuesto de enrutamiento Respuestas en streaming y generaciones abandonadas Runbook de producción para un pico de costes LLM Seguimiento de Precios API LLM Seis casos de uso de Jev que sí encajan Semantic cache economics (EN) September 2026 AI model trends (EN) Showback vs Chargeback: Which Model Fits Your Team? (EN) Siete patrones defensivos de la documentación de DeepSeek Harness Silent model downgrades and cost models (EN) Sobrecoste regional y de residencia de datos State of FinOps 2026: 98% now manage AI spend (EN) Subagentes de DeepSeek Harness: la delegación como multiplicador de coste Subida de Claude Sonnet 5 cancelada: $2/$10 permanente System One Models and Jev cost optimization (EN) Tendencias de costes de LLM 2025–2026 The Token Count Is Lying: Claude Max vs Qwen Audit (EN) The True Cost of Coding Agents: Beyond the API Bill (EN) Token budget implementation (EN) Tokens más baratos, factura LLM más alta Variación gasto IA: volumen, tarifa, mezcla, eficiencia What independent Jev tests say about cost (EN) What is AI value management? (EN) What is LLM cost attribution? A plain-English explainer (EN) What is LLM FinOps? A plain-English definition (EN) What is the Tokenomics Foundation? (EN) Where Jev belongs in an agent workflow (EN) Why agentic AI blows the budget (EN) Why does my LLM bill spike? The most common causes (EN) Why Jev is catching on with agent builders (EN) Why Showback Comes Before Chargeback in FinOps (EN) ¿Quieres aplicar esto a tu propio gasto en LLM? FinOps LLM realiza una auditoría gratuita de tus costes de IA y te muestra dónde están los ahorros. Solicita tu auditoría gratuita → Volver a FinOps LLM --- # El pensamiento adaptativo rompió tu previsión · FinOps LLM URL: https://finopsllm.com/es/research/adaptive-thinking-cost-forecast Pensamiento adaptativo y previsión de costes Actualizado September 1, 2026 · publicado originalmente September 1, 2026 Respuesta rápida: El presupuesto de razonamiento era un número que fijabas tú. Pasabas budget_tokens: N y N era control y previsión a la vez: en el peor caso, cada petición costaba N tokens de razonamiento.Ese... El presupuesto de razonamiento era un número que fijabas tú. Pasabas budget_tokens: N y N era control y previsión a la vez: en el peor caso, cada petición costaba N tokens de razonamiento. Ese parámetro está obsoleto en Opus 4.6 y Sonnet 4.6, y en los modelos más nuevos — Fable 5 y 5.1, Sonnet 5, Opus 5, 4.8 y 4.7 — enviarlo devuelve un 400 . Lo sustituye thinking: {type: "adaptive"} : el modelo decide cuánto pensar según la dificultad. Qué cambia en los números El coste medio por petición suele bajar, porque las peticiones fáciles dejan de pagar razonamiento que no necesitaban. La varianza sube , porque las difíciles ya no se truncan en tu tope. Un presupuesto expresado como máximo por petición se queda sin nada a lo que agarrarse. Prevé la distribución, no el tope Sigue los tokens de razonamiento como serie propia: ya vienen en el objeto de uso de cada respuesta. Presupuesta por percentiles: un p50 y un p99 por ruta en vez de "N tokens por petición". Alerta sobre la proporción, no el total: los tokens de razonamiento como porcentaje del total son lo primero que se mueve cuando un cambio de prompt hace trabajar más al modelo. Dónde sigue cabiendo un límite Los límites de gasto por ruta y por inquilino siguen funcionando y siguen atrapando bucles descontrolados. Ahí es donde va ahora la barrera: en la frontera que controlas, no en un parámetro que ya no existe. Relacionado Atribución de tokens de razonamiento ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Añade procedencia a tu salida de IA en un día · FinOps LLM URL: https://finopsllm.com/es/research/add-provenance-to-your-ai-output Añadir procedencia a la salida de IA Actualizado September 1, 2026 · publicado originalmente September 1, 2026 Respuesta rápida: Empecemos por lo que no puedes hacer. La marca de agua del texto la aplica el proveedor durante la generación: no hay parámetro que la active o desactive, y no se puede añadir después. Si quieres una... Empecemos por lo que no puedes hacer. La marca de agua del texto la aplica el proveedor durante la generación: no hay parámetro que la active o desactive, y no se puede añadir después. Si quieres una señal más fuerte, la respuesta no es añadir marcado, sino añadir un registro. Ese registro es barato, está bajo tu control y es lo que realmente se entrega cuando alguien te pide demostrar de dónde salió una salida. La mayoría de los equipos lo construyen en un día, porque está a un JOIN de la telemetría que ya recogen para atribuir costes. Los cuatro campos Para cada artefacto generado registra el identificador y versión exactos del modelo , la región , la marca temporal y un identificador de artefacto estable que siga a la salida por toda la canalización. Ese último es el que todos omiten y luego echan de menos. Si ya emites registros de uso por petición, tres de los cuatro están ahí. Lo que falta suele ser el JOIN: tu telemetría de coste sabe que hubo una petición y cuánto costó, pero no qué artefacto almacenado produjo. Conserva el manifiesto firmado Cuando el proveedor te entrega un archivo firmado con C2PA, el objetivo es simple: no perderlo. Configura las transformaciones de imagen para preservar metadatos de forma explícita en vez de confiar en los valores por defecto, y vuelve a adjuntar la procedencia tras cualquier recodificación que controles. Márcalo también para las personas El marcado legible por máquina y el aviso visible resuelven problemas distintos. Una etiqueta "generado con IA" no cuesta nada, ninguna transformación la afecta y es lo que el usuario lee de verdad. No sustituye al marcado automático, ni al revés. Relacionado Cómo se destruyen las marcas de agua ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Economía de agentes: ¿cuánto cuesta un agente de código? · FinOps LLM URL: https://finopsllm.com/es/research/agent-economics Economía de agentes: ¿cuánto cuesta realmente un agente de codificación? Los agentes de codificación son la categoría de gasto en LLM de más rápido crecimiento en 2026. Cada equipo de ingeniería está usando uno o evaluando uno. Pero los modelos de precios son confusos: los planes de suscripción ocultan límites de tokens detrás del lenguaje "ilimitado", los agentes basados en API exponen costes en bruto que se disparan de forma impredecible, y ninguno de los dos modelos te dice lo que realmente pagas por tarea completada. Este artículo desglosa la economía real de los cinco agentes de codificación más populares, introduce una métrica de "coste por tarea útil" y explica por qué los agentes basados en API pueden ser tanto más baratos como más caros que los planes de suscripción según los patrones de uso. El panorama de precios Los agentes de codificación se dividen en dos categorías de precios. Los agentes de suscripción cobran una tarifa mensual fija con uso incluido. Los agentes basados en API cobran por token consumido, típicamente a través de tu propia cuenta de proveedor. La elección correcta depende de cuántas tareas ejecutas, qué tan grande es tu base de código y qué tan complejos se vuelven tus prompts. Agente Plan Coste mensual Tokens/solicitudes incluidos Tareas estimadas/mes Coste por tarea Modelo principal Cursor Pro $20/mes 500 solicitudes rápidas (modelos premium) ~80–150 $0,13–$0,25 Claude Sonnet 4, GPT-4.1 GitHub Copilot Pro+ $39/mes 1.500 solicitudes premium ~150–300 $0,13–$0,26 Claude Sonnet 4, GPT-4.1 GitHub Copilot Pro $10/mes 300 solicitudes premium ~30–60 $0,17–$0,33 GPT-4.1, Claude Sonnet 4 Claude Code API (Max opcional) $5–$100+ Pago por token vía API de Anthropic ~20–200+ $0,25–$2,00 Claude Sonnet 4 Cline API (BYOK) $5–$80+ Pago por token vía cualquier proveedor ~20–200+ $0,20–$3,00 Configurado por el usuario Windsurf Pro $15/mes 500 créditos (modelos premium) ~60–120 $0,13–$0,25 Claude Sonnet 4, GPT-4.1 Qué significa realmente "coste por tarea" La tabla anterior muestra el rango anunciado, pero el coste real por tarea depende de tres factores ocultos: carga de ventana de contexto, cadenas de llamadas a herramientas y bucles de reintento. Una tarea "simple" como añadir un nuevo endpoint de API puede consumir 15K–40K tokens durante la sesión. Un refactor complejo que toca múltiples archivos puede superar fácilmente los 200K tokens. La carga de ventana de contexto es el mayor coste oculto. Cada agente de codificación carga tus archivos abiertos, la estructura del proyecto y el historial de conversación reciente en cada llamada a la API. Un proyecto con archivos grandes significa más tokens por solicitud, incluso si estás haciendo una pregunta simple. Las llamadas a herramientas multiplican esto: cada operación de lectura, búsqueda o edición es un viaje de ida y vuelta a la API con el contexto completo. Costes ocultos que la mayoría de equipos pasan por alto Bucles de reintento. Cuando el primer intento de un agente falla en pruebas o linting, reintenta automáticamente. Cada reintento es una llamada a la API a precio completo. En la práctica, el 20–40% de las sesiones de agente implican al menos un reintento, añadiendo un 30–80% al coste en tokens de esa tarea. Desbordamiento de contexto. Las sesiones largas alcanzan los límites de contexto. Cuando esto sucede, el agente resume el contexto previo (perdiendo detalle) o elimina los primeros mensajes (perdiendo contexto). Ambos conducen a una salida de menor calidad y más reintentos. Sobrecarga de llamadas a herramientas. Una sola tarea puede implicar 5–15 llamadas a herramientas (leer archivo, buscar código, editar archivo, ejecutar pruebas). Cada llamada a herramienta incluye el contexto completo de la conversación más la definición de la herramienta. Solo las definiciones de herramientas pueden consumir 2K–5K tokens del prompt del sistema por llamada. Solicitudes premium inactivas. Los planes de suscripción cuentan "solicitudes rápidas" incluso cuando el agente devuelve una salida no útil. Una sugerencia rechazada aún cuesta una solicitud premium. API vs. suscripción: cuándo gana cada uno Los agentes basados en API (Claude Code, Cline) ganan cuando tu uso es irregular o ligero. Si ejecutas 20–40 tareas enfocadas al mes, pagar $0,30–$0,80 por tarea es más barato que una suscripción de $20–$39. También ganan cuando necesitas un modelo específico para una tarea específica: pagas solo por lo que usas. Los agentes de suscripción (Cursor, Copilot, Windsurf) ganan cuando el uso es constante e intensivo. Si ejecutas más de 100 tareas al mes, el coste efectivo por tarea baja a menos de $0,20, que es difícil de superar con precios de API. También ganan en previsibilidad: los equipos de finanzas pueden presupuestar una cantidad fija. El punto de cruce es típicamente 40–80 tareas al mes por desarrollador. Por debajo de eso, el precio de API es más barato. Por encima, los planes de suscripción ofrecen mejor economía. La métrica de "coste por tarea útil" El coste bruto por tarea es engañoso porque no todas las tareas producen valor. Una sesión de agente que falla, devuelve una respuesta incorrecta o requiere retrabajo manual tiene un coste real de cero salida útil. La métrica que importa es: Coste por tarea útil = Gasto mensual total / Tareas que se enviaron sin retrabajo manual En la práctica, los equipos reportan que el 60–80% de las tareas de agente producen salida utilizable en el primer intento. El 20–40% restante requiere intervención manual. Esto significa que el coste efectivo por tarea útil es 1,25x–1,7x el coste bruto por tarea. Para equipos que construyen con modelos de código abierto o exploran alternativas rentables, plataformas como MiMO ofrecen precios competitivos que pueden cambiar el cálculo API vs. suscripción. Cómo reducir los costes de agentes Recorta el contexto. Cierra archivos irrelevantes antes de invocar al agente. Menos contexto = menos tokens por llamada. Escribe prompts específicos. Los prompts vagos conducen a más llamadas a herramientas y reintentos. "Añade un endpoint POST /users que valide email" cuesta menos que "arregla lo de usuarios." Usa modelos específicos por tarea. Las ediciones simples no necesitan un modelo de razonamiento. Enruta el código repetitivo a modelos más baratos y los refactores complejos a los premium. Monitorea el uso de tokens. Rastrea el conteo de tokens por sesión. Si el coste promedio por sesión está subiendo, tus prompts o base de código pueden estar creciendo más rápido de lo esperado. Establece límites de reintento. Limita los reintentos automáticos a 2–3 por tarea. Más allá de eso, escala a un humano. Qué esperar a continuación Los precios de agentes se mueven rápido. Los planes de suscripción están aumentando los límites incluidos a medida que la competencia se intensifica. Los precios de API continúan bajando: Claude Sonnet 4 cuesta un 60% menos que Claude 3.5 Sonnet en su lanzamiento. Los modelos de codificación de código abierto están cerrando la brecha de calidad, lo que empujará los precios de API aún más abajo. La tendencia más importante es el pricing específico para agentes. Los proveedores están experimentando con precios por tarea, límites por sesión y facturación ponderada por calidad. Para finales de 2026, espera que la mayoría de agentes ofrezcan una garantía de "coste por tarea exitosa" en lugar de facturación bruta por tokens. Relacionado Comparación de planes de codificación IA - benchmark basado en evidencia. Atribución del gasto de agentes - cómo rastrear costes de agentes por proyecto y equipo. Límites de gasto de agentes - establecer límites antes de que los costes se descontrolen. FinOps para LLM - el marco más amplio. ¿Quieres que esto se aplique a tu propio gasto en LLM? FinOps LLM ejecuta una auditoría gratuita de tus costes en IA y muestra dónde están los ahorros. Solicita tu auditoría gratuita → Volver a la investigación --- # La búsqueda web se vuelve centro de costos en agentes · FinOps LLM URL: https://finopsllm.com/es/research/agent-web-search-cost-center Búsqueda web como centro de costos en agentes Actualizado September 10, 2026 · publicado originalmente September 10, 2026 Respuesta rápida: Los agentes autónomos combinan inferencia con búsquedas web en vivo. Una sola petición puede disparar múltiples consultas, llamadas de análisis y reintentos. La búsqueda ya no es transparente: es un... Los agentes autónomos combinan inferencia con búsquedas web en vivo. Una sola petición puede disparar múltiples consultas, llamadas de análisis y reintentos. La búsqueda ya no es transparente: es un coste medido independiente de los tokens. Amplificación de búsquedas El planificador del agente reescribe preguntas y contrasta fuentes. Asocie cada consulta a un ID de tarea para calcular el coste de búsqueda por tarea completada y evitar facturas sorpresa. Relacionado Coste por tarea exitosa ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Margen bruto de una función de IA antes de lanzar · FinOps LLM URL: https://finopsllm.com/es/research/ai-feature-gross-margin Mide el margen bruto de una función de IA antes de lanzarla Actualizado September 2, 2026 · publicado originalmente September 2, 2026 Respuesta rápida: La inferencia es un coste de servicio, no de desarrollo. Se ejecuta en cada acción del cliente y escala con el uso. Tratarla como I+D hasta el lanzamiento significa conocer el margen real con la... La inferencia es un coste de servicio, no de desarrollo. Se ejecuta en cada acción del cliente y escala con el uso. Tratarla como I+D hasta el lanzamiento significa conocer el margen real con la primera factura completa. Instrumente antes de lanzar En staging, etiquete cada llamada con cuenta, flujo y resultado, y reproduzca tráfico realista. Necesita una distribución: coste por tarea exitosa en p50, p90 y p99, más la parte pagada por fallos y reintentos. Coste por cuenta Multiplique el coste por tarea exitosa por las tareas mensuales esperadas y sume los fallos. Compárelo con el precio del plan en uso mediano, percentil 90 y la cuenta más pesada aceptable. Cuatro factores de coste Contexto reenviado en cada turno, reintentos facturados por completo, expansión agéntica de una acción en muchas llamadas, y enrutamiento que manda casos fáciles a un modelo caro. Conéctelo a una decisión Techo de uso, componente de consumo en el precio, modelo por defecto más barato, o margen aceptado con fecha de revisión. Repórtelo como línea propia del margen bruto. Relacionado Coste por tarea exitosa ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # AI FinOps: el modelo operativo del gasto en GenAI · FinOps LLM URL: https://finopsllm.com/es/research/ai-finops AI FinOps para equipos en producción AI FinOps es el modelo operativo para gestionar el gasto en IA una vez que los modelos se convierten en parte del producto. No es solo observabilidad, ni es solo contratación. Es un ciclo entre ingeniería, producto y finanzas: entender dónde va el gasto, asignar responsabilidad, mejorar la economía unitaria y verificar los cambios contra la factura. Las cargas de trabajo de LLM hacen esto urgente porque el gasto escala con el uso, la longitud del contexto, la longitud de la salida, los reintentos y la elección del modelo. Un pequeño cambio de producto puede cambiar la factura sin cambiar la infraestructura. Los mejores programas de AI FinOps viven, por lo tanto, cerca del gateway del modelo y de la pila de análisis de productos. Qué necesita AI FinOps Normalización de facturas de proveedores. Metadatos a nivel de solicitud y propiedad del producto. Métricas de coste por tarea exitosa. Presupuestos que alerten antes de fin de mes. Guías de optimización para enrutamiento, caché, agrupación y estructura de prompts. Dónde comienzan los equipos Comienza con visibilidad y showback. Muestra a cada equipo de producto su gasto en LLM, los puntos finales que lo impulsan y los cambios mes a mes. Luego elige el factor controlable más grande. En la mayoría de los equipos, esto es enrutamiento de modelos, compactación de contexto, caché de prompts, caché semántica o mover el trabajo no urgente a APIs por lotes. AI FinOps se vuelve maduro cuando es parte de la revisión de lanzamiento: cada cambio orientado al modelo tiene un objetivo de calidad, un objetivo de latencia, un impacto en el gasto y un plan de retroceso. Relacionado What is LLM FinOps? - la disciplina operativa que gestiona el gasto en LLM. FinOps for LLMs - el modelo operativo en detalle. LLM cost attribution - cómo funciona la asignación. LLM budget governance - presupuestos y rutas de degradación. ¿Quieres que esto se aplique a tu propio gasto en LLM? FinOps LLM realiza una auditoría gratuita de tus costes de IA y muestra dónde están los ahorros. Solicita tu auditoría gratuita → Volver a la investigación --- # Variación gasto IA: volumen, tarifa, mezcla, eficiencia · FinOps LLM URL: https://finopsllm.com/es/research/ai-spend-variance-bridge Variación gasto IA: volumen, tarifa, mezcla, eficiencia Actualizado August 27, 2026 · publicado originalmente August 27, 2026 Respuesta rápida: Divide el cambio entre previsión y realidad en cuatro causas: volumen, tarifa, mezcla y eficiencia. Une cada una a facturas, uso y responsables.Las cuatro causasVolumen es demanda; tarifa es el precio... Divide el cambio entre previsión y realidad en cuatro causas: volumen , tarifa , mezcla y eficiencia . Une cada una a facturas, uso y responsables. Las cuatro causas Volumen es demanda; tarifa es el precio realmente facturado; mezcla es el desplazamiento entre modelos, proveedores, regiones o cargas; eficiencia es el coste del mismo resultado útil, incluidos reintentos, herramientas y reparación humana. Construye el puente Parte de la previsión, aplica tarifa, volumen, mezcla y eficiencia, y concilia el total con facturas. Cada línea necesita evidencia, dólares, responsable y acción. Incluye calidad para no llamar ahorro a una respuesta peor. El análisis de variación debe cambiar routing, límites, contratos o la siguiente previsión. Relacionado Monitoreo de costes LLM ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # La marca de agua de IA ya es una partida de coste · FinOps LLM URL: https://finopsllm.com/es/research/ai-watermarking-compliance-cost Coste de cumplimiento de la marca de agua Actualizado September 1, 2026 · publicado originalmente September 1, 2026 Respuesta rápida: Anthropic incrusta una marca de agua imperceptible en el texto de los modelos Claude compatibles y firma los archivos .svg, .png y .jpg con metadatos de procedencia C2PA. La técnica sigue el enfoque... Anthropic incrusta una marca de agua imperceptible en el texto de los modelos Claude compatibles y firma los archivos .svg , .png y .jpg con metadatos de procedencia C2PA. La técnica sigue el enfoque SynthID-Text: sesga la aleatoriedad de selección de tokens sin alterar el significado ni la calidad. El 1 de septiembre de 2026 se abrió una API de detección a reguladores, medios, verificadores, investigadores y empresas con obligaciones propias. El marcado es mundial, no solo europeo, y responde al artículo 50 de la Ley de IA de la UE, vigente desde el 2 de agosto de 2026. No hay ningún cargo adicional, y por eso se escapa en la revisión de presupuesto: el coste existe, pero no está en la factura. Dónde va realmente el dinero Migrar modelos fijados en versiones sin marcado; cambiar las canalizaciones de imagen que hoy eliminan metadatos; tramitar el acceso a la detección; y conservar identificador de modelo, versión, región y marca temporal por llamada. Cuatro costes reales, ninguno con tarifa. La trampa de la versión fijada Fijar una versión exacta es buena práctica, pero una versión anterior a agosto de 2026 puede no llevar marcado legible por máquina. Si sirves a usuarios de la UE, esa decisión de estabilidad se convierte en una brecha de cumplimiento y la solución es una migración no planificada: reevaluación, ajuste de prompts, pruebas y un nuevo precio. Inventaría cada versión fijada y ponle fecha de revisión. Tu canalización de imágenes borra la prueba Los metadatos C2PA viven en el archivo, y los miniaturizadores, las transformaciones del CDN y los conversores de formato los descartan por defecto para ahorrar bytes. Prueba toda la cadena de extremo a extremo, no solo la salida del modelo. Es barato si lo encuentras ahora y caro si lo encuentras en una auditoría. Relacionado Costes de migración por obsolescencia ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Detección de anomalías en costes de IA · FinOps LLM URL: https://finopsllm.com/es/research/anomaly-detection Detección de anomalías en costes de IA Las anomalías en costes de IA a menudo son invisibles hasta que llega la factura porque el gasto puede aumentar sin que el volumen de solicitudes suba. Un despliegue puede agregar contexto recuperado, cambiar un umbral de enrutamiento, reducir aciertos de caché, activar reintentos o mover tráfico a un modelo más costoso. Las alertas de tráfico tradicionales no detectan esos cambios. Un detector de anomalías útil monitorea los factores de coste, no solo el coste total. El gasto diario total es un indicador retrasado. Las primeras señales son tokens por solicitud, mezcla de modelos, tasa de recuperación, tasa de aciertos de caché, cuota de lotes y gasto por superficie de producto. Señales a monitorear Gasto por endpoint, equipo y cliente por hora. Tokens de entrada y salida por solicitud en p50, p90 y p99. Tasa de reintento, tasa de recuperación y tasa de error del proveedor. Tasa de aciertos de caché y cuota de tokens leídos en caché. Cambios en la mezcla de modelos después de despliegues o lanzamientos de prompts. Trabajo procesable que se ejecuta accidentalmente de forma síncrona. Líneas base Usa múltiples líneas base. Un bot de soporte tiene ciclos diarios y semanales. Un trabajo de enriquecimiento nocturno tiene una ventana de lotes. Un suite de evaluación tiene picos alrededor de lanzamientos. Un único umbral global será demasiado insensible o despertará a la gente constantemente. La mejor línea base es por propietario y clase de carga de trabajo. Alerta cuando una característica se desvía de su propio patrón normal, no cuando toda la empresa cruza un límite de gasto genérico. Alertas accionables Una alerta debe explicar el factor: "los tokens de entrada p90 se duplicaron en el endpoint X después del despliegue Y", "la tasa de aciertos de caché cayó del 74% al 18%", o "la recuperación al modelo de frontera aumentó un 31%". Si la alerta no puede nombrar un propietario probable y factor, será ignorada. Bucle de respuesta Adjunta contexto de despliegue, diffs de políticas de enrutamiento y los clientes o cargas de trabajo más afectados. Luego ofrece el siguiente paso: revertir un prompt, reducir el recuento de recuperación, restaurar un umbral de enrutamiento, deshabilitar una recuperación o mover un trabajo a lotes. La detección de anomalías solo es valiosa cuando acorta el tiempo desde la sorpresa de la factura hasta la acción de ingeniería. Relacionado Monitoreo de costes de LLM - dashboards y observabilidad para gasto. Observabilidad de IA - señales de costes y métricas operacionales. Por qué las facturas de LLM se disparan - causas raíz de los aumentos de costes. ¿Quieres que esto se aplique a tu propio gasto de IA? FinOps LLM realiza una auditoría gratuita de tus costes de IA y te muestra dónde están los ahorros. Solicita tu auditoría gratuita → Volver a la investigación --- # Azure OpenAI vs OpenAI Directo: costes y PTU · FinOps LLM URL: https://finopsllm.com/es/research/azure-openai-vs-direct-cost Azure OpenAI vs OpenAI Directo: comparativa de costes y PTU Actualizado September 19, 2026 · publicado originalmente July 12, 2026 Respuesta rápida: En la modalidad de pago por uso para despliegues globales, Azure OpenAI y la API directa de OpenAI comparten las mismas tarifas de lista (por ejemplo, 2,50 $ por millón de tokens de entrada y 15 $ de... En la modalidad de pago por uso para despliegues globales, Azure OpenAI y la API directa de OpenAI comparten las mismas tarifas de lista (por ejemplo, 2,50 $ por millón de tokens de entrada y 15 $ de salida). La verdadera diferencia en la factura mensual depende de tres factores: las unidades de rendimiento aprovisionado (PTU) , los recargos por residencia regional de datos y los acuerdos empresariales de Microsoft (EA) . 1. Rendimiento aprovisionado (PTU) frente a tokens bajo demanda Las PTU de Azure permiten reservar capacidad dedicada de modelo. Bajo demanda, una PTU cuesta 2 $ por hora. Con una reserva mensual, el coste baja a aproximadamente 260 $ por PTU al mes, lo que representa un ahorro de hasta el 82% frente al precio por hora (y hasta un 85% a un año). El punto de equilibrio para que una reserva PTU resulte más rentable que pagar por token se alcanza con una utilización sostenida superior al 65–75% . Con tráfico esporádico, el pago por token sigue siendo más barato. 2. Recargos por soberanía regional Los despliegues globales de Azure replican las tarifas estándar de EE. UU. Sin embargo, configurar zonas de datos restringidas a Europa o regiones locales suma un sobrecoste de entre el 10% y el 20% en las llamadas. 3. Costes ocultos de infraestructura (TCO) Azure OpenAI conlleva gastos auxiliares de red y observabilidad: Private Endpoints, Azure Monitor Log Analytics y transferencia de salida en VNet. Estos añaden entre un 4% y un 8% al coste efectivo de los tokens, pero aportan seguridad perimetral y gobierno corporativo. Relacionado Descuentos por consumo comprometido Por qué las tarifas no son comparables ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Los agentes en segundo plano cambian el reloj FinOps · FinOps LLM URL: https://finopsllm.com/es/research/background-agents-cost-clock Agentes en segundo plano y el reloj FinOps Actualizado September 10, 2026 · publicado originalmente September 10, 2026 Respuesta rápida: Los agentes en segundo plano rompen el ciclo petición-respuesta. El gasto se acumula mientras nadie vigila. Establezca presupuestos por tarea y tiempos máximos de ejecución para evitar consumos... Los agentes en segundo plano rompen el ciclo petición-respuesta. El gasto se acumula mientras nadie vigila. Establezca presupuestos por tarea y tiempos máximos de ejecución para evitar consumos desmedidos. Relacionado Tres presupuestos para agentes ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Estrategias de caché comparadas · FinOps LLM URL: https://finopsllm.com/es/research/caching-strategies-compared Estrategias de caché comparadas La caché es una de las tácticas de reducción de costes con mayor palanca para cargas de trabajo de LLM. La idea es directa: no pagues por inferencia si puedes devolver un resultado cacheado. Pero "caché" no es una sola técnica - son cuatro estrategias distintas con diferentes compensaciones en ahorro de costes, latencia, precisión y complejidad de implementación. Elegir la desperdicia esfuerzo de ingeniería; elegir la correcta puede reducir entre un 30 y un 70% tu factura. Comparación de estrategias Estrategia Cómo funciona Ahorro de costes Impacto en latencia Esfuerzo de implementación Ideal para Proveedores Caché de prompts (lado del proveedor) El proveedor cachea el cálculo KV para prefijos de prompts repetidos. Las solicitudes posteriores con el mismo prefijo omiten el reprocesamiento. 50% en tokens de entrada cacheados 60-80% más rápido en latencia del primer token Cero a bajo - automático en la mayoría de proveedores Prompts de sistema largos, RAG con contexto compartido, bucles de agentes OpenAI, Anthropic, Google Caché semántica (basada en embeddings) Genera embeddings de la consulta del usuario, busca en un almacén vectorial consultas pasadas similares. Si la similitud supera un umbral, devuelve la respuesta cacheada sin llamar al LLM. 20-50% según la repetición de consultas 50-90% más rápido (sin llamada al LLM) Medio - necesita modelo de embeddings, almacén vectorial, ajuste del umbral de similitud Bots de FAQ, soporte al cliente, consultas repetitivas Cualquiera (autoalojado vía GPTCache, Redis con búsqueda vectorial) Caché de contexto (estilo Google) Cacha documentos de contexto grandes (PDFs, repositorios de código) en el servidor. Paga una vez por el procesamiento de contexto, reutiliza en muchas consultas a un coste reducido por consulta. 70-90% en consultas con mucho contexto Mejora moderada en procesamiento de contexto Bajo a medio - sube contexto, gestiona TTL Preguntas y respuestas sobre documentos, revisión de código sobre repos grandes, turnos múltiples con contexto estático Google (Gemini), Anthropic (contexto de pensamiento extendido) Caché a nivel de aplicación (Redis/CDN) Hash determinista de la solicitud completa (prompt + parámetros). Almacena la respuesta en Redis o un CDN. Devuelve la respuesta cacheada en coincidencia exacta. Hasta 100% en aciertos de caché 90-99% más rápido (sin llamada al LLM) Bajo - infraestructura de caché estándar Consultas deterministas, clasificación, extracción con prompts fijos Cualquiera (infraestructura que controlas) Caché de prompts en detalle La caché de prompts es la ganancia más fácil. OpenAI cachea automáticamente prompts de más de 1.024 tokens. Anthropic cachea prefijos de 2.048+ tokens. La caché se indexa por el prefijo exacto - mismo prompt de sistema, mismos ejemplos few-shot, mismo contexto de documento. Cuando hay un acierto de caché, pagas un 50% menos por la parte cacheada de los tokens de entrada. El inconveniente: la invalidación de caché la controla el proveedor. Si el prompt cambia aunque sea ligeramente - mensaje de sistema diferente, variable diferente en el prefijo - la caché falla. Diseña tus prompts para colocar contenido estable al inicio y contenido dinámico al final del prompt. Caché semántica en detalle La caché semántica omite el LLM por completo cuando se hizo una pregunta similar antes. El flujo: genera embeddings de la consulta, busca en un almacén vectorial (Pinecone, Qdrant, Redis con búsqueda vectorial), verifica si el resultado principal supera un umbral de similitud (típicamente 0,92-0,97) y devuelve la respuesta cacheada si es así. El riesgo es devolver respuestas obsoletas o ligeramente incorrectas. Un umbral demasiado bajo devuelve resultados incorrectos; uno demasiado alto significa casi ningún acierto de caché. Ajústalo por caso de uso. Para recuperación factual de FAQ, 0,95+ es seguro. Para generación creativa, la caché semántica rara vez es apropiada - el punto es la novedad. Caché de contexto en detalle La caché de contexto de Google te permite subir un documento grande una vez y pagar una tarifa reducida para consultas posteriores sobre él. Esto es potente para preguntas y respuestas sobre documentos donde procesas el mismo PDF de 200 páginas cientos de veces. El modelo de costes: pagas la tarifa completa de tokens de entrada una vez para la escritura de caché, luego una tarifa reducida (a menudo el 25% de lo normal) para cada lectura de caché. La compensación es el TTL. Los contextos cacheados expiran. Si tu carga de trabajo tiene patrones de acceso irregulares - 500 consultas en una hora, luego nada durante una semana - la caché puede expirar entre ráfagas. Dimensiona tu TTL para que coincida con tu patrón de acceso. Caché a nivel de aplicación en detalle La caché determinista es la estrategia más agresiva. Haz un hash de la carga completa de la solicitud (prompt, temperatura, tokens máximos, modelo, herramientas) y almacena la respuesta. En coincidencia exacta, devuelve la respuesta cacheada al instante - sin llamada al LLM, sin latencia, sin coste. Esto solo funciona cuando la misma entrada siempre debe producir la misma salida. Clasificación, extracción de entidades, análisis de datos estructurados y generación basada en plantillas son buenos candidatos. Las tareas conversacionales o creativas no lo son - los usuarios esperan respuestas variadas. Combinando estrategias Las mejores implementaciones superponen múltiples estrategias. Una pila típica: caché a nivel de aplicación como primera verificación (más barata, más rápida), caché semántica como segunda verificación (captura casi-duplicados), luego la llamada al LLM con caché de prompts habilitada del lado del proveedor (reduce el coste incluso en fallos de caché). Este enfoque en capas puede reducir el gasto total en LLM entre un 40 y 70% en cargas de trabajo con cualquier grado de repetición. Sigue las tasas de acierto de caché por separado para cada capa. Si tu tasa de acierto de caché semántica cae por debajo del 10%, la sobrecarga del almacén vectorial puede no valer la pena. Si tu tasa de acierto de caché de aplicación está por encima del 40%, probablemente tienes tareas deterministas que deberían optimizarse a nivel de prompt. Relacionado Caché de prompts explicada - análisis más profundo de la caché del lado del proveedor. Economía de la caché semántica - análisis de ROI de la caché semántica. Optimización de costes de IA - estrategias de optimización más amplias. ¿Quieres esto aplicado a tu propio gasto en LLM? FinOps LLM ejecuta una auditoría gratuita de tus costes de IA y muestra dónde están los ahorros. Reserva auditoría gratuita → Volver a investigación --- # Generación de código con IA más barata (2026) · FinOps LLM URL: https://finopsllm.com/es/research/cheapest-ai-code-generation La Forma Más Barata de Ejecutar Generación de Código con IA Las herramientas de generación de código con IA han explotado en variedad - pero la diferencia de coste entre opciones es enorme. Un usuario ligero podría gastar $10/mes con un enfoque y $200/mes con otro por resultados casi idénticos. Esta guía compara cada categoría de herramienta de codificación IA, calcula los costes mensuales reales para diferentes niveles de uso y te da un árbol de decisión para elegir la opción más barata que realmente funcione para tu flujo de trabajo. Las cuatro categorías Cada herramienta de generación de código IA cae en uno de cuatro modelos de precios: Agentes por suscripción - tarifa mensual fija, uso incluido (Cursor, Copilot, Windsurf, Cody). Agentes basados en API - traes tu propia clave API, pagas por token (Claude Code, Cline, Aider, Continue con APIs en la nube). Modelos autoalojados - ejecuta modelos de pesos abiertos localmente o en tu propia GPU (Continue + Qwen, CodeLlama, DeepSeek Coder). Proveedores de planes de codificación - acceso API a tarifa fija optimizado para cargas de trabajo de codificación ( MiMO , GLM, MiniMax, KwaiKAT). Tabla de comparación de costes Opción Coste Mensual (Ligero) Coste Mensual (Intensivo) Calidad del Modelo Esfuerzo de Configuración GitHub Copilot Free $0 $0 Buena Ninguno GitHub Copilot Pro $10 $10 Muy buena Ninguno Cursor Pro $20 $20 Excelente Bajo Windsurf Pro $15 $15 Muy buena Bajo Claude Code (API) $5–15 $50–200 Excelente Medio Cline + clave API $5–20 $40–150 Excelente Medio Plan de codificación MiMO $10–15 $30–60 Muy buena Bajo Plan de codificación GLM $10–15 $30–60 Buena Bajo Continue + modelo local $0 $0 Aceptable Alto Usuario ligero: ~2 horas/día, ~50 solicitudes/día. Usuario intensivo: 8+ horas/día, ~300 solicitudes/día. Los costes API asumen un promedio de 3K entrada + 1K tokens de salida por solicitud con precios de Claude Sonnet o GPT-4o. Desglose por categoría 1. Agentes por suscripción Son los más fáciles de adoptar. Pagas una tarifa fija y obtienes una cuota de uso generosa (o ilimitada). El truco: estás atado a su elección de modelo e integración IDE. Cursor Pro ($20/mes) - Mejor UX general para usuarios avanzados. Incluye solicitudes rápidas (GPT-4o, Claude Sonnet) y lentas (modelos frontera). El límite de 500 solicitudes rápidas/mes es suficiente para la mayoría de desarrolladores. GitHub Copilot ($10/mes) - Opción principal más barata. Las autocompletaciones son excelentes; el chat es bueno pero menos potente que el modo agente de Cursor. Nivel gratuito disponible con límites. Windsurf Pro ($15/mes) - Terreno medio competitivo. Buenas características agénticas a un precio menor que Cursor. Veredicto: Mejor para desarrolladores que quieren cero configuración y facturación predecible. Copilot Free es imbatible para usuarios con presupuesto ajustado. 2. Agentes basados en API Traes tu propia clave API (OpenAI, Anthropic, etc.) y la herramienta hace llamadas API en tu nombre. Los costes escalan linealmente con el uso - genial para usuarios ligeros, caro para usuarios intensivos. Claude Code - El agente CLI de Anthropic. Usa Claude Sonnet u Opus. Una sesión intensiva puede costar $2–5 en tarifas API. Cline (VS Code) - Agente de código abierto que funciona con cualquier API. Muy flexible, pero los costes son impredecibles sin límites de presupuesto. Aider - Basado en terminal, funciona con cualquier modelo. Popular por su integración git y enfoque de modo edición. Veredicto: Mejor para desarrolladores que quieren flexibilidad de modelo y están dispuestos a monitorizar el uso. Los usuarios ligeros pagan menos que las suscripciones; los intensivos pagan más. 3. Modelos autoalojados Ejecuta modelos de pesos abiertos (Qwen 2.5 Coder, DeepSeek Coder V2, CodeLlama) localmente vía Ollama, vLLM o llama.cpp. Coste marginal cero por solicitud - pero necesitas hardware. Ventajas: Sin coste por token, privacidad total, sin límites de tasa, funciona sin conexión. Desventajas: Brecha de calidad vs. modelos frontera (especialmente para refactorización compleja), requiere una GPU capaz (16GB+ VRAM para buenos resultados), fricción de configuración. Veredicto: Mejor para trabajo sensible a la privacidad, entornos sin conexión o equipos con infraestructura GPU existente. No recomendado como tu único modelo - combina con un modelo en la nube para tareas difíciles. 4. Proveedores de planes de codificación Una categoría más nueva: proveedores que ofrecen acceso API a tarifa fija o con fuertes descuentos específicamente para agentes de codificación. Estos puentean la brecha entre el caro precios API por token y las herramientas rígidas de suscripción. Plan de codificación MiMO - Precios competitivos con sólidas capacidades de razonamiento. Buen equilibrio entre coste y calidad. GLM (Zhipu) - Proveedor chino con precios agresivos para cargas de trabajo de codificación. MiniMax / KwaiKAT - Proveedores emergentes con niveles de precios optimizados para codificación. Veredicto: Mejor para usuarios de agentes basados en API que quieren reducir costes sin cambiar a autoalojado. La calidad varía - haz benchmarks en tus tareas reales antes de comprometerte. Árbol de decisión Sigue esto para encontrar tu opción más barata: Si programas <2 horas/día: Usa GitHub Copilot Free . Coste cero, autocompletaciones excelentes. Si alcanzas los límites, actualiza a Copilot Pro ($10/mes). Si programas 2–6 horas/día: Usa Cursor Pro ($20/mes) o Windsurf Pro ($15/mes) . La tarifa fija es más barata que los costes API a este volumen. Alternativamente, usa un proveedor de plan de codificación como MiMO con Cline por $10–30/mes. Si programas 8+ horas/día: Usa un agente basado en API con un plan de codificación (MiMO, GLM) a $30–60/mes. Las claves API estándar (Claude, GPT-4o) costarán $100–200/mes a este volumen. Considera un modelo local para completaciones rutinarias para reducir aún más los costes. Los costes ocultos de los que nadie habla Desperdicio de ventana de contexto. La mayoría de agentes de codificación envían tu archivo completo + historial de conversación en cada solicitud. Un contexto de 50K tokens en GPT-4o cuesta $0.125 por solicitud solo en entrada. Con 200 solicitudes/día, eso son $25/día - más que una suscripción mensual a Cursor. Bucles de reintento. Las herramientas agénticas que reintentan automáticamente ediciones fallidas pueden quemar tokens rápidamente. Establece límites estrictos en el número de reintentos. Sobrecarga de cambio de modelo. Algunas herramientas usan por defecto el modelo más caro. Revisa tu configuración - las solicitudes "lentas" de Cursor usan modelos más baratos y a menudo son lo suficientemente rápidas. Conclusión Para la mayoría de desarrolladores, un agente por suscripción (Copilot o Cursor) es la opción más barata porque limita tus costes independientemente del uso. Para usuarios avanzados dispuestos a gestionar claves API, los proveedores de planes de codificación como MiMO ofrecen la mejor relación coste-calidad. Los modelos autoalojados son gratuitos pero de calidad limitada - mejor como complemento, no como reemplazo. Lo que elijas, rastrea tu gasto por herramienta para poder reevaluar a medida que los precios cambien. Relacionado Comparación de planes de codificación IA - benchmark detallado de proveedores de planes de codificación. ¿Cuánto cuesta GPT-5? - precios de modelos frontera explicados. Arbitraje de proveedores - enfoque sistemático para encontrar modelos más baratos. Enrutamiento de modelos - enviar tareas al nivel de coste correcto. ¿Quieres esto aplicado a tu propio gasto en LLM? FinOps LLM ejecuta una auditoría gratuita de tus costes de IA y muestra dónde están los ahorros. Reserva auditoría gratuita → Volver a investigación --- # Fable 5.1: 10/50 dólares y la caché decide · FinOps LLM URL: https://finopsllm.com/es/research/claude-fable-5-1-cost-model Modelo de coste de Claude Fable 5.1 Actualizado September 1, 2026 · publicado originalmente September 1, 2026 Respuesta rápida: Claude Fable 5.1 (claude-fable-5-1) cuesta 10 dólares por millón de tokens de entrada y 50 por millón de salida. Opus 5 cuesta 5 y 25. Parece una prima fija del doble, pero es un modelo equivocado: la... Claude Fable 5.1 ( claude-fable-5-1 ) cuesta 10 dólares por millón de tokens de entrada y 50 por millón de salida. Opus 5 cuesta 5 y 25. Parece una prima fija del doble, pero es un modelo equivocado: la tarifa de caché va en dirección contraria. Las cuatro tarifas que importan La escritura en caché cuesta 12,50 dólares por millón (TTL de 5 minutos) y 20,00 (TTL de una hora). La lectura de caché cuesta 0,25 por millón: el 2,5% de su propio precio de entrada y la mitad de lo que cuesta el mismo token cacheado en Opus 5. Todas las filas son 2×; esa única fila es 0,5×. Qué ocurre con una carga real Un prefijo de 100.000 tokens cuesta 1,00 dólar en frío con Fable y 0,50 con Opus 5. En caliente cuesta 0,025 con Fable y 0,05 con Opus 5. El proveedor más caro pasa a ser el más barato sin cambiar el prompt. El punto de equilibrio es una tasa de acierto de caché cercana al 50%, no una preferencia de modelo. La salida no tiene tope El contexto llega a un millón de tokens y la salida máxima a 128.000. A 50 dólares por millón, una sola respuesta de 128K cuesta 6,40. El razonamiento extendido siempre está activo y la configuración explícita devuelve un error 400: el control de coste es el parámetro effort , de bajo a máximo. Tampoco hay Priority Tier, así que la latencia se gestiona con concurrencia propia. Qué instrumentar antes de enrutar tráfico Mide la tasa de acierto de caché por función (no una media de cuenta), la amplificación de escrituras de caché y los tokens de salida por tarea exitosa. Después compara con tu modelo actual mediante un puente de variación que separe tarifa, volumen y mezcla; un promedio esconde los dos movimientos opuestos. Relacionado Economía del caché de prompts ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Claude Opus 5.5: $4/$20 y lectura de caché por $0.20 · FinOps LLM URL: https://finopsllm.com/es/research/claude-opus-5-5-cost-model Modelo de costes de Claude Opus 5.5 Actualizado September 22, 2026 · publicado originalmente September 22, 2026 Anthropic lanzó Claude Opus 5.5 ( claude-opus-5-5 ) el 22 de septiembre de 2026. El precio anunciado es $4 por millón de tokens de entrada y $20 por millón de tokens de salida, reducido desde $5 y $25 en Opus 5. Eso es un corte del 20%. Para la mayoría de cargas de trabajo de producción el corte real es mayor, porque la tarifa que más se movió es la que el titular omite. Las tarifas que importan Tipo de token Opus 5.5 Opus 5 Fable 5.1 Entrada (no caché) $4.00 / MTok $5.00 / MTok $10.00 / MTok Salida $20.00 / MTok $25.00 / MTok $50.00 / MTok Escritura en caché (5 min) $5.00 / MTok $6.25 / MTok $12.50 / MTok Lectura de caché $0.20 / MTok $0.50 / MTok $0.25 / MTok Modo rápido (entrada / salida) $8 / $40 — — Cada fila es 20% más baja excepto la lectura de caché, que es 60% más baja. A $0.20 ahora es más barato que el $0.25 de Fable 5.1. Eso invierte la única fila donde Fable solía ganar. En nuestro modelo de costes de Fable 5.1 , una carga de trabajo muy almacenada en caché podría salir más barata en Fable que en Opus 5. Contra Opus 5.5 eso ya no sucede. Fable cuesta más en cada tipo de token. Por qué una tarea típica cuesta aproximadamente 40% menos La afirmación de Anthropic es una caída del 40% en costes para un trabajo típico, no del 20%. Lo extra viene de la eficiencia de tokens. Anthropic dice que Opus 5.5 alcanza el mismo resultado con aproximadamente 20% menos tokens de entrada y salida y escribe aproximadamente 40% menos salida verbosa. Una tarifa más baja por menos tokens se compone: 0.8 × 0.8 = 0.64, que es aproximadamente 36–40% de descuento dependiendo de la mezcla. Aquí está un paso del agente: 200,000 tokens de entrada, 90% servido desde caché, y 20,000 tokens de salida. Línea Opus 5 Opus 5.5 (mismo tokens) Fable 5.1 20K entrada no caché $0.100 $0.080 $0.200 180K entrada caché $0.090 $0.036 $0.045 20K salida $0.500 $0.400 $1.000 Total $0.690 $0.516 $1.245 En tokens idénticos, Opus 5.5 es 25% más barato que Opus 5, no 20%, por el descuento de caché. Si la reducción del 20% de tokens se mantiene para tu carga de trabajo, el paso cae a aproximadamente $0.41, que es 40% por debajo de Opus 5 y un tercio del coste de Fable. La salida sigue siendo aproximadamente el 80% de la factura en este ejemplo. Ahí es donde el descuento de verbosidad paga. Coste por tarea frente a GPT-6 Sol, GPT-6 Astra y Fable 5.1 Precios de lista por millón de tokens y el mismo paso de agente de arriba (200K de entrada, 90% en caché, 20K de salida) calculado en cada modelo. Modelo Entrada $/MTok Salida $/MTok Lectura de caché $/MTok Mismo paso de agente GPT-6 Sol $2.00 $10.00 $0.20 $0.276 Claude Opus 5.5 $4.00 $20.00 $0.20 $0.516 Claude Opus 5 $5.00 $25.00 $0.50 $0.690 Claude Fable 5.1 $10.00 $50.00 $0.25 $1.245 GPT-6 Astra $10.00 $50.00 $1.00 $1.380 Coste por tarea medido en el Artificial Analysis Intelligence Index v4.3.2, consultado el 22 de septiembre de 2026, ordenado por puntuación. GPT-6 Sol es la forma más barata de llegar a cualquier puntuación hasta 47,5. Por encima, Opus 5.5 es el más barato en todos los niveles: Opus 5.5 high puntúa 53,6 por 1,82 $, mientras que GPT-6 Astra max puntúa 52,7 por 3,26 $ y Fable 5.1 max puntúa 53,4 por 7,63 $. Modelo Intelligence Index Coste por tarea Tokens de salida por tarea GPT-6 Sol · medium 39.8 $0.25 6,500 GPT-6 Sol · xhigh 44.1 $0.53 16,000 GPT-6 Astra · low 45.8 $0.82 4,400 GPT-6 Sol · max 47.5 $1.06 31,200 Claude Opus 5 · high 48.1 $3.61 46,200 Claude Opus 5 · max 50.8 $5.86 72,500 Claude Opus 5.5 · medium 51.2 $1.34 25,700 Claude Fable 5.1 · high 51.2 $3.91 38,100 GPT-6 Astra · max 52.7 $3.26 27,200 Claude Fable 5.1 · max 53.4 $7.63 78,100 Claude Opus 5.5 · high 53.6 $1.82 35,600 Claude Opus 5.5 · max 57.6 $5.98 119,200 Todos los ajustes de GPT-6 Astra por encima de low, todos los de Opus 5 y todos los de Fable 5.1 cuestan más que un ajuste de Sol u Opus 5.5 con la misma puntuación o mayor. El coste por tarea depende de la mezcla de tareas del benchmark. Reproduce tu propio tráfico antes de cambiar de modelo. ¿Es lo suficientemente bueno para reemplazar Fable? Anthropic posiciona Opus 5.5 como coincidiendo con Fable 5.1 en la mayoría de tareas. Los números publicados apoyan eso para trabajo de codificación y agentivo: Terminal-Bench 4.0: 66.4%, contra 52.3% para Opus 5 y 55.8% para Fable 5.1. FrontierCode v1.1: 54.4%, contra 48.0% para Opus 5 y 50.3% para Fable 5.1. CursorBench 4.0: 57.8%, contra 46.6% para Opus 5. GDPval-AA v2.1: 1846 Elo, contra 1708 para Opus 5. Artificial Analysis lo clasificó primero en su Índice de Inteligencia el día del lanzamiento. Anthropic también dice que en nivel de esfuerzo predeterminado (medio) supera a GPT-6 Astra a máximo esfuerzo en trabajo de conocimiento por aproximadamente una quinta parte del coste por tarea. Eso es una comparación del proveedor, así que trátalo como una hipótesis a probar. Las matemáticas de costes arriba son la parte que puedes verificar tú mismo. El modo rápido cuesta 2× El modo rápido cuesta $8 de entrada y $40 de salida, exactamente el doble de la tarifa estándar, por hasta 2.5× la velocidad. El modelo estándar también es aproximadamente 30% más rápido que Opus 5. Usa el modo rápido para rutas interactivas vinculadas por latencia donde un usuario está esperando. Mantenlo apagado para trabajos por lotes, agentes en segundo plano y evaluaciones. Cuando el modo rápido está habilitado por defecto, el coste unitario se duplica y el panel de control no muestra nada inusual hasta que llega la factura. Qué hacer esta semana Fija el ID del modelo. Apunta la producción a claude-opus-5-5 explícitamente y registra el ID en cada solicitud, para que el coste por solicitud pueda dividirse por modelo después de la migración. Vuelve a establecer la línea base en tu propio tráfico. Reproduce una muestra de solicitudes reales en ambos modelos y compara tokens por tarea completada, no por llamada. La afirmación de eficiencia del 20% de tokens es la parte más probable de variar por carga de trabajo. Vuelve a verificar los ajustes de esfuerzo. Si una carga de trabajo se movió a Fable o a máximo esfuerzo por calidad, prueba Opus 5.5 a nivel medio primero. Ese es el ajuste contra el que Anthropic hace puntos de referencia. Vuelve a ejecutar la decisión de enrutamiento de Fable. Cualquier ruta que envió tráfico pesado en caché a Fable para obtener la lectura de caché más barata debe ser reevaluada. Esa ventaja de coste se ha ido. Vigila la proporción de aciertos de caché. A $0.20 contra $4.00, una falta de caché ahora cuesta 20× un acierto. Un cambio de plantilla de indicativo que rompe el prefijo cuesta más que en Opus 5. Anthropic dice que Sonnet 5.5 y Haiku 5.5 seguirán en las próximas semanas. Mantén el arnés de repetición del paso 2 para que cada lanzamiento pueda ser reestablecido en línea base en una tarde. Relacionado Modelo de costes de Claude Fable 5.1 Economía del almacenamiento en caché de indicativos Los niveles de esfuerzo de Opus 5.5 son el precio real Economía del modo rápido de Opus 5.5 ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Comparación de Planes de Codificación IA · FinOps LLM URL: https://finopsllm.com/es/research/coding-plan-comparison Comparación de Planes de Codificación IA Compare los principales planes de codificación IA con evidencia verificable. Precios, límites y puntuaciones de modelos en una tabla normalizada. Construido a partir de documentación de proveedores y reglas de conversión explícitas para una comparación justa. 9 Proveedores rastreados 29 Planes comparados 62 Modelos listados Jul 2026 Última actualización Cada actualización está vinculada a evidencia pública Las reglas de conversión Solicitud/Prompt son explícitas La lógica de cálculo fija mantiene las comparaciones consistentes Metodología Recolección Los datos de planes, límites y modelos se recopilan de fuentes públicas de proveedores. Normalización Los formatos de solicitud/período se normalizan en un modelo de comparación único. Reglas de conversión Solicitud/Prompt = 15 y Semanal × 4 = Mensual se aplican explícitamente. Política de visualización Los valores oficiales y estimados se separan claramente en la interfaz. Registro de Actualizaciones 4 jul 2026 Lanzada página de investigación de comparación de planes Publicada la comparación de planes de codificación IA basada en evidencia como artículo de investigación de FinOps LLM. 27 may 2026 Cuota de Xiaomi MiMO aumentada Xiaomi MiMO aumentó los límites de uso disponibles y la tabla de comparación se ha actualizado. 1 may 2026 Alibaba discontinúa Plan de Codificación, añade Plan de Tokens Alibaba cerró el Plan de Codificación anterior e introdujo el Plan de Tokens (Edición Equipo). Lista de Comparación de Planes de Codificación Tasa de conversión Solicitud / Prompt (predeterminado = 15) 1 Prompt = 15 Solicitudes Ordenar Orden predeterminado Mejor valor ≤ $10 Mejor valor ≤ $30 Mejor valor (todos) Mostrar: Todos Coding Agent Proveedor ↕ Plan ↕ Precio ↕ Uso Prompt / mes ↕ Solicitud / mes ↕ Prompt / $1 ↕ Solicitud / $1 ↕ Modelos Intel ↕ Coding ↕ Agentic ↕ GLM Lite $10 Coding + Agent 160 2.400 16 240 GLM-5.1 (×3), GLM-5-Turbo (×3), GLM-4.7 (×1) 47 37 66 GLM Pro $30 Coding + Agent 267 4.000 8,9 133 GLM-5.1 (×3), GLM-5-Turbo (×3), GLM-5 (×3) 50 44 63 GLM Max $80 Coding + Agent 400 6.000 5 75 GLM-5.1 (×3), GLM-5-Turbo (×3), GLM-5 (×3) 50 44 63 MiniMax Starter $10 Coding + Agent 400 6.000 40 600 MiniMax-M2.7 (×1) 50 42 61 MiniMax Plus $20 Coding + Agent 600 9.000 30 450 MiniMax-M2.7 (×1) 50 42 61 MiniMax Max $45 Coding + Agent 889 13.333 19,8 296 MiniMax-M2.7 (×1) 50 42 61 MiniMax Plus-HighSpeed $40 Coding + Agent 300 4.500 7,5 112,5 MiniMax-M2.7-highspeed (×1) 50 42 61 MiniMax Max-HighSpeed $80 Coding + Agent 500 7.500 6,25 93,75 MiniMax-M2.7-highspeed (×1) 50 42 61 MiniMax Ultra-HighSpeed $150 Coding + Agent 533 8.000 3,55 53,3 MiniMax-M2.7 (×1) 50 42 61 BytePlus Lite $10 Coding + Agent 120 1.800 12 180 Seed-Code (×1), GLM-4.7 (×1), DeepSeek-V3.2 (×1), kimi-k2.5 (×1) 34 31 36 BytePlus Pro $50 Coding + Agent 120 1.800 2,4 36 Seed-Code (×1), GLM-4.7 (×1), DeepSeek-V3.2 (×1), kimi-k2.5 (×1) 34 31 36 StepFun Flash Mini $6.99 Coding 229 3.433 32,8 491 step-3.5-flash (×1) 38 32 52 StepFun Flash Plus $9.99 Coding 641 9.610 64,2 962 step-3.5-flash (×1) 38 32 52 StepFun Flash Pro $29 Coding 828 12.414 28,6 428 step-3.5-flash (×1) 38 32 52 StepFun Flash Max $99 Coding 808 12.121 8,16 122,4 step-3.5-flash (×1) 38 32 52 KwaiKAT Mini $5 Coding 1.075 16.128 215 3.226 KAT-Coder-Pro V2 (×1) 44 46 51 KwaiKAT Starter $10 Coding 1.344 20.160 134,4 2.016 KAT-Coder-Pro V2 (×1) 44 46 51 KwaiKAT Pro $20 Coding 2.016 30.240 100,8 1.512 KAT-Coder-Pro V2 (×1) 44 46 51 KwaiKAT Max $50 Coding 2.688 40.320 53,76 806,4 KAT-Coder-Pro V2 (×1) 44 46 51 OpenCode Go $10 Coding + Agent 667 10.000 66,7 1.000 MiniMax-M2.5 (×1), M2.7 (×1.4), MiMo-V2-Pro (×16), kimi-k2.5 (×11), GLM-5 (×17) 50 44 63 Xiaomi MiMO Regístrate - ambos $2 ↗ Lite $6 Coding + Agent 380 5.693 63,3 949 MiMo-V2-Pro (×1), MiMo-V2-Omni (×1) 49 41 63 Xiaomi MiMO Regístrate - ambos $2 ↗ Standard $16 Coding + Agent 382 5.729 23,9 578 MiMo-V2-Pro (×1), MiMo-V2-Omni (×1) 49 41 63 Xiaomi MiMO Regístrate - ambos $2 ↗ Pro $50 Coding + Agent 422 6.333 8,44 126,7 MiMo-V2-Pro (×1), MiMo-V2-Omni (×1) 49 41 63 Xiaomi MiMO Regístrate - ambos $2 ↗ Max $100 Coding + Agent 456 6.833 4,56 68,3 MiMo-V2-Pro (×1), MiMo-V2-Omni (×1) 49 41 63 Alibaba Standard $30 Coding + Agent 17 262 0,57 8,73 qwen3.6-plus (×1), deepseek-v3.2 (×1), GLM-5 (×1), MiniMax-M2.5 (×1) 50 43 62 Alibaba Advanced $100 Coding + Agent 21 314 0,21 3,14 qwen3.6-plus (×1), deepseek-v3.2 (×1), GLM-5 (×1), MiniMax-M2.5 (×1) 50 43 62 Alibaba Premium $200 Coding + Agent 26 393 0,13 1,97 qwen3.6-plus (×1), deepseek-v3.2 (×1), GLM-5 (×1), MiniMax-M2.5 (×1) 50 43 62 Los valores no proporcionados explícitamente por los proveedores se muestran en gris . Muchos proveedores limitan las cuotas de Solicitud o Prompt. Convertimos dinámicamente usando el control de tasa Solicitud/Prompt anterior (predeterminado: 15). Si el límite oficial más alto es semanal, el mensual se estima como Semanal × 4. La puntuación de Artificial Analysis se mide por artificialanalysis.ai . Algunos enlaces pueden incluir códigos de referencia. Los detalles de los planes pueden cambiar con frecuencia. Verifique siempre la información más reciente en las páginas oficiales de los proveedores. Guía Práctica El precio por sí solo no es suficiente. Adapte cada plan a su estilo de trabajo primero. Comience con la política de Agent, el tipo de límite y el horizonte de contrato. 1) Verifique la política de Agent primero Algunos proveedores o planes restringen el uso de Agent. Si los flujos de trabajo de Agent son importantes, verifique los términos y la columna de Uso (Coding / Agent) antes de suscribirse. 2) Límites de Prompt vs Solicitud Para uso intensivo de chat manual, agrupar el trabajo en menos turnos suele alinearse mejor con los límites de tipo Prompt. Para automatización y flujos pesados de Agent, el volumen de solicitudes backend puede crecer rápidamente, así que priorice planes con suficiente margen de Solicitud. 3) Prefiera mensual, use anual cuando los términos iniciales sean superiores Las revisiones de planes y cambios de inscripción son cada vez más comunes. El mensual da flexibilidad, mientras que el anual puede ser efectivo cuando los términos del período de lanzamiento son claramente ventajosos. 4) La velocidad (token/s) es un factor real de productividad Con la misma cuota, las respuestas más lentas siguen costando más tiempo de trabajo. Planeamos añadir métricas de token por segundo en una actualización futura. Verificaciones adicionales Separe los valores Proporcionados de los Estimados (las estimaciones pueden cambiar) Confirme la disponibilidad de modelos de la misma clase (ninguno significa no disponible) Adapte el ciclo de reinicio (5h / diario / mensual) a su ventana de uso real ¿Quieres que esto se aplique a tu propio gasto en LLM? FinOps LLM ejecuta una auditoría gratuita de tus costes en IA y muestra dónde están los ahorros. Solicita tu auditoría gratuita → Volver a la investigación --- # El compromiso de gasto apuesta por tu plan · FinOps LLM URL: https://finopsllm.com/es/research/committed-spend-discounts Descuentos por compromiso de gasto Actualizado September 1, 2026 · publicado originalmente September 1, 2026 Respuesta rápida: Cuando tu gasto en modelos se nota, el proveedor te ofrece descuento a cambio de comprometer volumen. Capacidad reservada, compromiso anual, throughput aprovisionado: cambia la forma, no el trato. Te... Cuando tu gasto en modelos se nota, el proveedor te ofrece descuento a cambio de comprometer volumen. Capacidad reservada, compromiso anual, throughput aprovisionado: cambia la forma, no el trato. Te pagan por ser predecible. Los tres riesgos Infrautilizar es el obvio y el menor: comprometes volumen, usas menos, pagas la diferencia. Se acota comprometiendo por debajo de tu caso conservador. Quedar atado a un modelo es mayor. La frontera se mueve en meses; un compromiso de doce meses con el buque insignia de hoy apuesta a que no llega nada más barato, y lleva tres años llegando cada trimestre. Perder la capacidad de cambiar es el mayor y nunca aparece en el modelo: elimina tu palanca en la siguiente negociación y mata el trabajo de enrutado, porque nadie optimiza tráfico fuera de un modelo ya prepagado. Cómo valorarlo Compara con el contrafactual honesto: lo que habrías pagado bajo demanda en ese periodo, incluyendo las bajadas de precio que históricamente llegan dentro de él. A doce meses suele ser un 20–40% por debajo de la tarifa actual. Compromete un suelo , no un plan. Prefiere compromisos de gasto a compromisos de modelo. Exige traspaso del volumen no usado. Y mantén el plazo corto. Relacionado Guía de compra de LLM ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Pagas dos veces por la ventana de contexto · FinOps LLM URL: https://finopsllm.com/es/research/context-window-paid-twice Pagar dos veces la ventana de contexto Actualizado September 1, 2026 · publicado originalmente September 1, 2026 Respuesta rápida: Una ventana de contexto se anuncia como capacidad: 200.000 tokens, un millón, sitio para lo que haga falta. La capacidad no es la unidad de facturación. Te cobran por lo que envías, y en una... Una ventana de contexto se anuncia como capacidad: 200.000 tokens, un millón, sitio para lo que haga falta. La capacidad no es la unidad de facturación. Te cobran por lo que envías , y en una conversación de varios turnos vuelves a enviar casi todo en cada turno. Ese es el segundo pago. Un documento de 30.000 tokens cargado al inicio de una conversación de veinte turnos no son 30.000 tokens de entrada: son unos 600.000. La cuenta que nadie hace El coste crece con el cuadrado de la longitud de la conversación, no linealmente. Duplicar los turnos casi cuadruplica los tokens de entrada. Quien modela "coste por mensaje" y multiplica infravalora mucho las sesiones largas. Suele haber un tercer cargo: muchos proveedores aplican una tarifa premium por encima de cierto umbral de contexto largo. Un adjunto extra puede cruzar esa línea y reencarecer toda la llamada. Qué medir Sigue la utilización del contexto : tokens enviados frente a tokens que el modelo realmente necesitaba. Mide tokens de entrada por conversación , no por petición, y vigila el p99. Tres arreglos, del más barato al menos Cachea el prefijo estable. Es el cambio de mayor retorno en cualquier producto multiturno. Recorta el historial a propósito. Resume la parte antigua y descarta los turnos en bruto. Envía el extracto, no el corpus. Que la ventana quepa entero no es motivo para meterlo entero. Relacionado Economía del caché de prompts ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Lo que cuesta una imagen usable · FinOps LLM URL: https://finopsllm.com/es/research/cost-per-approved-image Coste por activo aprobado en imagen y vídeo Actualizado September 1, 2026 · publicado originalmente September 1, 2026 Respuesta rápida: El precio de imagen y vídeo parece simple: tanto por imagen, tanto por segundo. Esa simplicidad es justo por lo que casi todos lo presupuestan mal. El proveedor cobra por generación. Tu negocio... El precio de imagen y vídeo parece simple: tanto por imagen, tanto por segundo. Esa simplicidad es justo por lo que casi todos lo presupuestan mal. El proveedor cobra por generación . Tu negocio consume activos aprobados . La tasa de aceptación es el modelo entero Nadie publica el primer render. Con un estilo maduro, quizá aceptes uno de cada tres; en exploración creativa, uno de cada diez. El vídeo es peor: un clip falla por movimiento, consistencia temporal o un solo fotograma, y pagas el clip entero igual. La aritmética útil no es el precio de tarifa, sino el precio dividido por la aceptación. Qué mueve de verdad el número No la resolución, sino todo lo que sube la aceptación: iterar en baja resolución y escalar solo lo elegido, una biblioteca de prompts para estilos conocidos, imágenes de referencia y semillas fijas, y un brief escrito antes de la primera generación. Mide lo correcto Generaciones por activo aprobado y coste por activo aprobado. Quince por aprobación es un problema de brief, no de precio. Relacionado Atribución de costes de LLM ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # El coste por tarea exitosa supera al coste por solicitud · FinOps LLM URL: https://finopsllm.com/es/research/cost-per-successful-task El coste por tarea exitosa supera al coste por solicitud Actualizado August 27, 2026 · publicado originalmente August 27, 2026 Respuesta rápida: El coste por solicitud es útil, pero no es la unidad que compra el usuario. Una solicitud fallida o repetida no es trabajo terminado. El indicador más fuerte es el coste por tarea exitosa: todo el... El coste por solicitud es útil, pero no es la unidad que compra el usuario. Una solicitud fallida o repetida no es trabajo terminado. El indicador más fuerte es el coste por tarea exitosa : todo el gasto atribuible dividido por las tareas que superan un umbral de calidad. La fórmula coste por tarea = gasto atribuible / tareas exitosas . Incluye tokens, herramientas, reintentos y fallbacks. Define éxito antes de medirlo: aceptación del usuario, confianza mínima o flujo completado sin reparación humana. Por qué el promedio engaña El promedio por solicitud oculta la cola larga y los fallos caros. Segmenta por función, modelo, cohorte y resultado. Publica p50 y p95 junto con la tasa de éxito. Instrumenta el denominador Une cada span de modelo con un evento de resultado mediante un ID de solicitud. Registra éxito, motivo de fallo, reparación humana y latencia. Concilia el numerador con la factura del proveedor. Si la solicitud es barata pero la tarea exitosa es cara, el problema es la calidad, los reintentos o las reglas de parada. Relacionado Monitoreo de costes LLM ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # El coste real de cambiar de proveedor LLM · FinOps LLM URL: https://finopsllm.com/es/research/cost-switching-llm-providers El coste real de cambiar de proveedor LLM Actualizado August 27, 2026 · publicado originalmente August 27, 2026 Respuesta rápida: Cambiar de proveedor LLM no es solo comparar precios. Incluye ingeniería, cambios de prompts y esquemas, evaluación, doble operación, transferencia, soporte y riesgo de calidad.Cuenta el... Cambiar de proveedor LLM no es solo comparar precios. Incluye ingeniería, cambios de prompts y esquemas, evaluación, doble operación, transferencia, soporte y riesgo de calidad. Cuenta el trabajo Inventaría SDK, herramientas, formatos, límites, contexto, seguridad, observabilidad y errores específicos. Estima horas de ingeniería y pruebas. Valora la calidad Ejecuta la misma carga en ambos proveedores y mide éxito, latencia, reintentos, reparación humana y acuerdo del evaluador. Incluye crear el conjunto de pruebas. Calcula el retorno Compara ahorro mensual total con migración, evaluación, doble operación y coste del gateway. A veces el routing entre proveedores es mejor que reemplazar uno. Relacionado Arbitraje entre proveedores ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Siete patrones defensivos de DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/es/research/deepseek-harness-defensive-patterns Siete patrones defensivos de la documentación de DeepSeek Harness Actualizado August 16, 2026 · publicado originalmente August 16, 2026 Respuesta rápida: DeepSeek Harness incluye un documento breve de patrones defensivos, cada uno escrito como regla general junto al bug concreto que lo motivó. Es el archivo más transferible del repositorio: nada de... DeepSeek Harness incluye un documento breve de patrones defensivos, cada uno escrito como regla general junto al bug concreto que lo motivó. Es el archivo más transferible del repositorio: nada de ello exige adoptar el harness, y cada punto corresponde a un modo de fallo que aparece en runtimes de agentes caseros. 1. Reporte los resultados ortogonales por separado Nunca anide el reporte de una bandera dentro del condicional de otra. Un proceso puede agotar el tiempo y salir con cero, porque atrapó la señal y se apagó limpiamente. Si el timeout solo se reporta dentro de la rama de salida distinta de cero, ese resultado desaparece. Timeout, señal y código de salida son hechos independientes y necesitan campos independientes. Relevancia de coste: los timeouts tragados en silencio son cómo se forman los bucles de reintento. El llamador ve éxito, no obtiene nada útil y vuelve a intentarlo. 2. Honre los contratos públicos por ambos lados Cuando un resultado tiene varias representaciones válidas, normalícelas antes de exponerlas. El ejemplo trabajado son los fallos de petición al modelo: las implementaciones pueden lanzar o emitir un chunk de finalización con error, y la frontera de la API lo normaliza todo a un chunk terminal. Sin eso, un llamador que captura una excepción no puede saber si vino del proveedor, del middleware, del logging o de su propio código. 3. El estado asíncrono no es estado síncrono Las consultas de estado no están causalmente ligadas a operaciones asíncronas concretas. Esperar el estado idle de un agente como señal de finalización de un mensaje es un error, porque varias operaciones en cola comparten intervalos de ejecución: el idle puede llegar antes de que corriera el suyo, o después del de otro. La corrección prescrita: un llamador de automatización dueño de una ejecución define su intervalo explícitamente, desde la recepción en la bandeja hasta el siguiente idle del agente completo, y atribuye salidas a ese intervalo en vez de a mensajes sueltos. Cubra también la rama de nada-que-esperar, o el llamador cuelga indefinidamente. Un harness de automatización que se cuelga esperando la señal de idle equivocada mantiene residentes una sesión y sus hijos. La factura de eso no es el cuelgue: es todo lo que sigue vivo detrás. 4. Liberar debe alcanzar la quiescencia, no solo pedirla Pedir la terminación no es lograrla. El dispose espera la terminación real de los hijos antes de retornar. Y los registros de escuchas se cierran antes de enviar las señales de kill, para que las finalizaciones tardías aterricen en silencio en vez de disparar callbacks contra un sistema a medio desmontar. Este es el patrón con el filo financiero más claro. Un dispose que retorna pronto deja subprocesos huérfanos y sandboxes sin cerrar corriendo, y el cómputo medido no se detiene porque su padre se olvidara de él. 5. Contenga las excepciones de callback en el despachador Envuelva los bucles de despacho en try/catch. Un suscriptor que falla no debe rechazar la promesa de despacho ni matar de hambre a las escuchas encoladas detrás. En un runtime de agentes, la escucha hambrienta suele ser justo la que hace la contabilidad, y así los registros de uso desaparecen sin que aflore ningún error. 6. Nunca dé a una salida no confiable el entorno ambiental ni rutas predecibles La regla más fuerte del documento y la primera a adoptar. Limpie el entorno de los comandos lanzados: elimine variables que casen con key, secret, token y password antes de que arranque el subproceso. Use directorios privados creados con permisos solo para el dueño, nombres de archivo aleatorios y aperturas exclusivas en vez de rutas predecibles. Dos amenazas distintas. La limpieza de entorno evita que las credenciales del harness se filtren en la salida del subproceso que luego lee el modelo, y una vez leída esa salida está en el registro de sesión y en la ventana de contexto. Los nombres aleatorios y la creación exclusiva cierran carreras de symlink en directorios temporales compartidos. 7. Desenlace las rutas con forma de enlace Compruebe si una ruta es un enlace simbólico antes de borrarla, y borre el enlace en lugar de seguirlo. El borrado recursivo se reserva a directorios reales confirmados, porque puede atravesar symlinks hacia sus destinos y lanza sobre junctions. Código de limpieza que borra más de lo que creó es un modo de fallo sin techo de daño. Cómo usar esta lista Lleve hoy los patrones 1 y 4 a su código de desmontaje de subprocesos y sandboxes. Ahí es donde se fuga el dinero. Lleve el patrón 6 a cualquier sitio donde lance un proceso cuya salida vaya a leer el modelo. Lleve el patrón 3 a su capa de automatización, sobre todo donde una espera se exprese como "hasta que el agente esté idle". Lleve el patrón 5 a su pipeline de telemetría y compruebe que una escucha que falla no puede matar de hambre a la de contabilidad. Relacionado ¿Qué es DeepSeek Harness? Guía completa Límites de gasto en el harness (EN) Subagentes y profundidad de delegación (EN) El registro de sesión como registro de costes (EN) ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Instalar DeepSeek Harness: perfiles y primer uso · FinOps LLM URL: https://finopsllm.com/es/research/deepseek-harness-getting-started DeepSeek Harness: instalación, perfiles y primera ejecución Actualizado August 16, 2026 · publicado originalmente August 16, 2026 Respuesta rápida: Esta es la mitad práctica de nuestra cobertura de DeepSeek Harness: cómo poner dsh en marcha, qué espera de usted el modelo de composición y qué demos merecen diez minutos. La vía más rápida npx... Esta es la mitad práctica de nuestra cobertura de DeepSeek Harness: cómo poner dsh en marcha, qué espera de usted el modelo de composición y qué demos merecen diez minutos. La vía más rápida npx @deepseek-ai/dsh web Eso inicia la interfaz web en http://127.0.0.1:3080 . A partir de ahí deben ocurrir dos cosas antes de que el compositor de sesión sea utilizable: Ajustes → Modelos , e introducir su clave de API de DeepSeek. La ruta se habilita al momento, sin reiniciar. Elegir espacio de trabajo , para añadir y activar el directorio del proyecto. Hasta que haya un espacio activo, el compositor permanece deshabilitado. Una vez en marcha, el agente puede leer y editar archivos, ejecutar comandos, delegar tareas en subagentes y planificar. Pide confirmación según la política de permisos activa. Desde el código fuente git clone https://github.com/deepseek-ai/deepseek-harness pnpm install pnpm run build pnpm dsh web Mínimos a tener en cuenta: Node 22.19 o superior (la CI cubre 22.19, 24 y 26), Git 2.26 o superior, y Corepack con pnpm fijado en pnpm@11.7.0 . Una DEEPSEEK_API_KEY es opcional y se lee del entorno o de un .env ignorado por git en la raíz del repositorio; junto a ella, DEEPSEEK_BASE_URL puede apuntar a otro endpoint. Las suites de extremo a extremo contra la API real se autoexcluyen cuando falta la clave, así que un checkout sin clave compila y pasa pruebas sin problemas. Perfiles y bundles: el modelo de composición Como cada parte del harness es un plugin, algo tiene que decir qué plugins se cargan. Eso es un perfil : una composición con nombre que guarda una lista ordenada de bundles más los parches del usuario. Un bundle distribuye filas de configuración de Cordis y código. Se incluyen tres perfiles plantilla: Perfil Qué compone dsh-base Adaptadores de modelo, herramientas, persistencia dsh-web-app La interfaz de navegador dsh-headless Ejecutor de una sola pasada El orden de sobreescritura en cuatro capas La configuración se resuelve en un orden fijo, ganando las capas posteriores: Bundles del perfil Parches del perfil Parches a nivel de home Overlays de línea de comandos Aprenda este orden antes de empezar a depurar. Casi toda pregunta del tipo «por qué está usando ese modelo» en un sistema de configuración por capas se responde encontrando qué capa tocó el valor en último lugar, y un overlay de línea de comandos gana a todo lo que tiene debajo. Los subsistemas que va a encontrar Seis claves de registro cargan con la mayor parte del comportamiento: ctx.sessions (el registro de eventos solo-anexado), ctx.systemPrompt , ctx.tools (un registro con scope y ejecución vigilada), ctx.agents , ctx.agentLoop y ctx.llm . Si va a extender el harness, esos son los nombres que buscar primero. Tres demos que vale la pena ejecutar Headless de una pasada: pnpm dsh --profile headless "summarize this workspace" . La forma que cablearía en CI o en un cron. Introspección de Cordis: pnpm run demo:cordis . Autorreferencial: inspecciona y modifica su propio runtime de plugins en caliente. Es la demostración más clara de que la afirmación sobre plugins es estructural y no publicitaria. Automatización ACP: pnpm run demo:acp . Un servidor de automatización que habla JSON-RPC sobre stdio, que es la superficie de integración para gobernar el harness desde otro sistema. Si piensa contribuir Unas cuantas convenciones ahorran tiempo. Las marcas TODO están graduadas por urgencia: FIXME bloquea la release, TODO es pronto, XXX es algún día. Lefthook ejecuta pre-commit (registros de pairing en staged, .oxlintrc.staged.json , regeneración de avisos de terceros, espacios en blanco, guardián del manifiesto de vendor), pre-merge-commit y pre-push ( pnpm run typecheck ). Los hooks se saltan tests y builds deliberadamente: la CI es dueña de la cobertura exhaustiva, y pnpm run check:all es la puerta local completa y opcional. Dos rarezas explican una estructura que si no resultaría confusa. El build se divide en agregados tsconfig de Host y Client porque ambos lados fusionan por declaración la interfaz Context de Cordis bajo las mismas claves, y un único programa de TypeScript que vea ambas fusiones reporta una colisión. Y los ejemplos de código de la documentación se mantienen honestos con bloques ts type-equiv más pnpm run verify-type-equiv , de modo que las declaraciones pegadas no puedan divergir en silencio del código fuente. Fijar expectativas El README lo dice sin rodeos: esto es un developer preview y habrá cambios que rompan compatibilidad. El descubrimiento de plugins pasa por el topic de GitHub dsh-plugin , el proyecto tiene licencia MIT y las dependencias de terceros están listadas en THIRD_PARTY_NOTICES.md . Evalúelo ahora; estandarice más tarde. Relacionado ¿Qué es DeepSeek Harness? Guía completa Qué aporta de verdad «todo es un plugin» (EN) Dónde poner los límites de gasto (EN) El registro de sesión como registro de costes (EN) ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Objetivos y el bucle Ralph en DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/es/research/deepseek-harness-goals-ralph-loop DeepSeek Harness: objetivos, rondas de objetivo y el bucle Ralph Actualizado August 16, 2026 · publicado originalmente August 16, 2026 Respuesta rápida: La mayoría de las sorpresas de coste con agentes no vienen del precio de un token. Vienen de cuántas veces el agente decidió volver a intentarlo. DeepSeek Harness le da un vocabulario a ese... La mayoría de las sorpresas de coste con agentes no vienen del precio de un token. Vienen de cuántas veces el agente decidió volver a intentarlo. DeepSeek Harness le da un vocabulario a ese comportamiento, que es el primer paso para ponerle un número. Turno, paso, ronda Tres unidades, separadas con precisión en el glosario del proyecto: Unidad Definición Significado de coste Paso Un pedido al modelo más las ejecuciones de herramienta que produce El átomo de facturación Turno Un drenaje de la entrada, que termina cuando el modelo para o interviene una política La unidad de cara al usuario Ronda Una iteración externa de política, como una ronda de objetivo o un intento con agente nuevo El multiplicador por encima de los turnos Las rondas son la capa que casi todos los modelos de coste caseros omiten por completo. Si su previsión cuenta peticiones y su sistema corre rondas, su previsión mide lo que no es. Los objetivos son metas duraderas Un objetivo es una meta de finalización duradera con una fase explícita: activo, en pausa, bloqueado o completo. A diferencia de un mensaje, persiste entre turnos, así que el agente carga una meta permanente. Cada ciclo de continuación admitido para ese objetivo es una ronda de objetivo, materializada como un único turno de origen de objetivo. La admisión la controla una activación de objetivo: un permiso local al proceso para admitir otra ronda, que está armado o desarmado. Ese único bit es el estrangulador del trabajo abierto. Una meta permanente más continuación automática es una autorización de gasto sin techo. Justo por eso está documentado que crear y editar objetivos exige autorización humana directa: alguien tiene que ser dueño del presupuesto del trabajo abierto. El bucle Ralph es reinicio deliberado El bucle Ralph es un flujo en primer plano que itera hacia un objetivo inmutable arrancando sesiones de agente nuevas, construido sobre las primitivas de flujo y subagentes del harness. Una ronda Ralph es una sesión hija nueva sin semilla de conversación del padre. La continuidad la lleva un handoff Ralph: un informe normalizado, acotado y estructurado con estado, resumen, evidencia y bloqueos. La economía aquí es interesante de verdad, y corta en los dos sentidos. Reiniciar limpio significa que cada ronda paga un coste de entrada pequeño en vez de arrastrar una conversación siempre creciente, así que el coste por ronda se queda plano en lugar de escalar. Pero nada en un arranque fresco garantiza progreso, y un bucle que reinicia barato puede permitirse reiniciar muchas más veces. El handoff acotado es el control que hace viable el patrón: es el único canal entre rondas, así que limita el crecimiento del contexto por construcción. Vigile dos números: rondas por objetivo, y si la lista de bloqueos del handoff se repite. Un bloqueo que aparece en tres handoffs seguidos es un bucle que no va a converger, y cada ronda adicional es puro desperdicio. Los comandos no son herramientas Vale la pena separarlo, porque afecta a lo que se mide. Un comando humano es una instrucción con prefijo de barra enrutada por el plano de comandos hacia adaptadores de cara al humano: descubrimiento, parseo, despacho, cancelación y renderizado, propiedad de los adaptadores de UI. Es explícitamente distinto de una herramienta de modelo. El comando de objetivo es uno de ellos. En la práctica: un humano tecleando un comando de barra no es el modelo gastando tokens. Atribuya las dos cosas por separado o su coste por sesión culpará al actor equivocado. Cuatro controles para el trabajo abierto Un número máximo de rondas por objetivo, aplicado antes de admitir en vez de revisado después. Un presupuesto acumulado de tokens que abarque todas las rondas de un objetivo, no por ronda. Detección de convergencia sobre el handoff: bloqueos repetidos detienen el bucle. Autorización humana explícita para crear objetivos, guardada como registro de auditoría de quién autorizó el gasto. Relacionado ¿Qué es DeepSeek Harness? Guía completa Subagentes y profundidad de delegación (EN) Límites de gasto en el harness (EN) El registro de sesión como registro de costes (EN) ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Límites de gasto en DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/es/research/deepseek-harness-guardrails Dónde poner los límites de gasto en DeepSeek Harness Actualizado August 16, 2026 · publicado originalmente August 16, 2026 Respuesta rápida: Un agente que descubre su presupuesto en la factura mensual no tiene presupuesto: tiene un post-mortem. La pregunta útil sobre cualquier harness es dónde puede uno plantarse dentro del bucle y decir... Un agente que descubre su presupuesto en la factura mensual no tiene presupuesto: tiene un post-mortem. La pregunta útil sobre cualquier harness es dónde puede uno plantarse dentro del bucle y decir que no, y DeepSeek Harness la responde con dos puntos de extensión en cascada con nombre propio. Primero, la forma del bucle El harness usa un modelo de turno y paso. Un paso es una petición al modelo más las llamadas a herramientas que produce. Un turno contiene cero o más pasos. El flujo de un turno es, a grandes rasgos: reclamo de entrada, ensamblado del prompt, agent/pre-step , stream del LLM, ejecución de herramientas, cierre del paso y cierre del turno. Dos flujos de eventos corren en paralelo. session/event lleva hechos duraderos de replay: chunks, mensajes, llamadas a herramientas, resultados. agent/* lleva señales vivas de coordinación: estado, buzón, interceptación de peticiones. Los límites pertenecen al segundo; la contabilidad, al primero. Punto de intercepción 1: agent/pre-step Es el control previo a que salga la petición al modelo. La documentación afirma que la decisión devuelta por agent/pre-step es autoritativa y que los listeners que envuelven next() preservan los mensajes aguas abajo salvo que la sustitución sea intencionada. Esa es la propiedad que lo hace utilizable como puerta de presupuesto: un listener puede rechazar un paso propuesto, o modificarlo, y la decisión se mantiene. Lo que corresponde aquí: Topes de pasos por turno. El modo de fallo del agente descontrolado es un turno que nunca converge. Un techo duro de pasos convierte una factura ilimitada en una acotada. Presupuestos acumulados de tokens. Sume el uso registrado hasta ahora en el log de sesión y rechace el siguiente paso pasado el umbral. Bajada de modelo. Reescriba el paso hacia una ruta más barata cuando el turno haya superado un umbral blando, en vez de rechazarlo sin más. Límites de tamaño de contexto. El prompt se ensambla antes de este hook, así que la petición ya montada es visible y medible aquí. Punto de intercepción 2: tools/pre-execute La ejecución de herramientas es una tubería de tres fases. Primero corre la cascada tools/pre-execute , después los guardas monótonos y solo entonces el cuerpo de la herramienta, en sandbox y con control de acceso al sistema de archivos. Luego una cascada post-execute puede aceptar, bloquear, sustituir o añadir contexto al resultado, y ToolDefinition.finalizeContent impone invariantes de contenido de forma síncrona. La capa de permisos es deliberadamente asimétrica. Los guardas monótonos registrados deniegan o se abstienen, con identidad protegida: nunca conceden. Si un guarda deniega, o si el prompt de un solo uso de ctx.approval falta o resulta incontestable, el resultado es denegación y el cuerpo de la herramienta se omite. Falla cerrado, no abierto. Las mutaciones del sistema de archivos se controlan aparte: solo pasan las mutaciones fs/write-intent o fs/edit-intent . Escribir no es un efecto colateral incidental de ejecutar una herramienta. Dos propiedades hacen fiable esta tubería como punto de control: los guardas solo pueden denegar, y un prompt de aprobación incontestable deniega. La mayoría de capas caseras de política para agentes fallan en abierto cuando falta el canal de aprobación, que es justo cuando las necesitaba. Qué registra la tubería Tres eventos de sesión le dan el rastro de auditoría: tool/call antes de ejecutar, tool/code-dispatch para subllamadas y tool/result como resultado final autoritativo. Que las subllamadas se registren aparte importa: una única llamada a herramienta visible para el modelo que se ramifica internamente no esconde su ramificación. Un conjunto práctico de límites Control Hook Frena Máximo de pasos por turno agent/pre-step Bucles que no convergen Techo acumulado de tokens agent/pre-step Sobregasto a fuego lento Bajada de ruta pasado el umbral agent/pre-step Precios de frontera para trabajo barato Lista blanca de herramientas por clase de coste Guarda monótono Herramientas caras en contextos baratos Denegación de subprocesos y red Política de ctx.sandbox Salida de red sin medir Control de write-intent Costura ctx.fs Mutaciones sin revisar La salvedad DeepSeek Harness está en developer preview y su propio README advierte de cambios que rompen compatibilidad. Estos nombres y semánticas de hooks son los documentados hoy; trate los plugins de límites construidos sobre ellos como código que revisitará, y fije la versión contra la que construyó. Relacionado ¿Qué es DeepSeek Harness? Guía completa El registro de sesión como registro de costes (EN) Todo es un plugin: la arquitectura (EN) Límites de gasto para agentes (EN) ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # DeepSeek Harness: todo es un plugin · FinOps LLM URL: https://finopsllm.com/es/research/deepseek-harness-plugin-architecture DeepSeek Harness: qué aporta de verdad «todo es un plugin» Actualizado August 16, 2026 · publicado originalmente August 16, 2026 Respuesta rápida: DeepSeek AI ha publicado deepseek-harness (dsh), un harness de agentes con licencia MIT cuyo lema de diseño es que todo es un plugin. Esa frase se usa con soltura en el ecosistema de herramientas de... DeepSeek AI ha publicado deepseek-harness ( dsh ), un harness de agentes con licencia MIT cuyo lema de diseño es que todo es un plugin. Esa frase se usa con soltura en el ecosistema de herramientas de agentes, así que conviene precisar qué significa aquí y dónde cambia la economía de operar agentes. Cordis, no un framework con hooks El harness corre sobre Cordis , un runtime de plugins cuyo modelo consiste en que los plugins aportan servicios, eventos tipados y efectos reversibles a un contexto compartido. El documento de arquitectura es explícito: no hay un núcleo privilegiado. Adaptadores de modelo, registros de herramientas, logs de sesión y el propio bucle del agente son todos plugins. Nada queda debajo de ellos como motor inamovible. Esto importa porque la forma habitual de un framework de agentes «extensible» es un núcleo fijo más una superficie de hooks. Puede observar y decorar, pero no reemplazar. Reemplazar significa bifurcar. Cordis invierte eso: las piezas que querría reemplazar son las unidades de composición. Costuras de capacidad: la parte que importa en operación El harness formaliza esto con lo que llama una costura de capacidad (capability seam). Una costura es una interfaz de servicio con más de una implementación, y cada servicio ocupa uno de tres roles: Rol Qué hace Owner El paquete que declara la interfaz del servicio Implementación Un paquete que aporta comportamiento concreto (las costuras tienen varias) Consumidor Un paquete que llama al servicio, ciego a qué proveedor está activo No todo servicio es una costura. La documentación distingue tres tipos: costuras intercambiables ( ctx.llm , ctx.subprocess ), servicios de núcleo con un único owner ( ctx.sessions , ctx.agents ) y puntos de composición que coordinan otros servicios ( ctx.agentLoop ). Saber cuál es cuál le dice dónde puede sustituir comportamiento y dónde no. Las cuatro costuras con consecuencias de coste ctx.llm , la costura del modelo. Pertenece al paquete llm ; entre las implementaciones están llm-deepseek , llm-pi-ai y llm-replay . El bucle del agente consume un servicio de streaming neutral respecto al proveedor y no sabe qué backend está corriendo. llm-replay es el interesante para trabajo de costes: permite reejecutar una sesión grabada sin volver a pagar inferencia. ctx.fs , la costura del sistema de archivos. Los proveedores son fs-local (sistema de archivos del host), fs-sandbox (mutaciones confinadas) y fs-e2b (una máquina Linux remota en sandbox). La costura desacopla las herramientas que ve el modelo de dónde ocurre físicamente la ejecución. ctx.sandbox , la costura de ejecución. Los consumidores entregan argv; las implementaciones envuelven la ejecución bajo política. sandbox-local aplica en el host, sandbox-policy centraliza los valores por defecto de despliegue. ctx.subagents , la costura de delegación. Seis implementaciones que cubren spawn en proceso, fork, puentes ACP, Codex, Claude Code y agentes basados en SDK. Aquí es donde un harness normalmente fija una suposición; aquí es un intercambio. Toda palanca de coste relevante en un sistema de agentes es un cambio de proveedor: enrutar a un modelo más barato, mover la ejecución a un sandbox más barato, sustituir un transporte de subagentes por uno local. Cuando eso son costuras, el cambio es una edición de configuración. Cuando no lo son, el cambio es una bifurcación que ahora mantiene usted. Por qué es un asunto de FinOps y no solo de arquitectura El fallo recurrente en los programas de coste de agentes no es que los equipos elijan un modelo caro. Es que el harness vuelve estructural la elección cara. Una vez que la selección de modelo, el lugar de ejecución de las herramientas y el transporte de delegación quedan horneados en el código de la aplicación, cada optimización se convierte en un proyecto de ingeniería con su propio calendario y su propio riesgo de regresión. Los equipos posponen entonces la optimización, y el gasto se acumula. Un harness basado en costuras mueve esas decisiones a la composición. Eso no las hace gratuitas, pero las convierte de refactorizaciones en configuración, que es la diferencia entre una iniciativa trimestral y una tarde. La salvedad que conviene decir sin rodeos DeepSeek Harness está en developer preview y su README dice, sin suavizarlo, que habrá cambios que rompan compatibilidad. Construir ahora herramientas de coste de producción directamente contra sus interfaces internas significa comprometerse a perseguirlas. Evalúelo, prototipe con él, pero fije las versiones y espere movimiento. Relacionado ¿Qué es DeepSeek Harness? Guía completa El registro de sesión como registro de costes (EN) Dónde poner los límites de gasto (EN) Instalación, perfiles y primera ejecución (EN) ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # El registro de sesión de DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/es/research/deepseek-harness-session-log El registro de sesión de DeepSeek Harness como registro de costes Actualizado August 16, 2026 · publicado originalmente August 16, 2026 Respuesta rápida: La mayoría de stacks de agentes atornillan el seguimiento de coste a posteriori: un wrapper alrededor de la llamada al modelo que escribe tokens en un sistema aparte que, con el tiempo, se separa de... La mayoría de stacks de agentes atornillan el seguimiento de coste a posteriori: un wrapper alrededor de la llamada al modelo que escribe tokens en un sistema aparte que, con el tiempo, se separa de la realidad. DeepSeek Harness lo hace al revés. El registro de sesión es el artefacto primario y el uso de tokens vive dentro de él. La sesión es un log de eventos append-only Una sesión es una secuencia ordenada y solo-anexable de entradas SessionEvent tipadas. Cada evento lleva cuatro campos: Campo Qué significa type La clase de evento, por ejemplo assistant/message seq Número de secuencia monótono dentro de la sesión time Marca de tiempo data La carga útil específica del tipo Los eventos de superficie (lo que una interfaz muestra) añaden dos campos más: sourceEventSeqs , que apunta de vuelta a los eventos crudos de los que se derivaron, y surfaceOp . Esos punteros son la razón por la que una cifra de coste puede rastrearse hasta exactamente los eventos que la produjeron. Los eventos que le importan a un modelo de coste turn/start y turn/end : el corchete exterior de una petición de usuario. turn/end lleva un TurnEndReason que dice si el turno se completó, se abortó o se truncó. step/start y step/end : un paso es una petición al modelo más las llamadas a herramientas que provoca. Es la unidad natural de facturación. assistant/message : salida del modelo, con TokenUsage opcional. assistant/chunk : salida en streaming, incluidos los chunks de uso. tool/call y tool/result : ejecución de herramientas; el resultado puede llevar meta . request/header y request/context : el EpochHeader y el contexto de petición con proveedor, modelo y ventana de contexto. Ese par es lo que asigna un precio a una cifra de uso. La regla rectora de la documentación es: lo visible para el modelo queda registrado . Todo lo que entra en el contexto del modelo deja un evento. Eso hace el log completo por construcción, en vez de completo mientras nadie olvide instrumentarlo. El uso viaja con la salida El uso de tokens no se escribe en un canal lateral: viaja con la salida a la que pertenece. Prefiera los chunks de uso ( assistant/chunk con { type: 'usage' } ) porque están lo más cerca posible de lo que el proveedor facturó realmente; recurra a assistant/message.usage cuando no haya chunk. Un modelo de coste que lea así nunca puede atribuir una cifra a un paso que no la generó. Historia derivada, no duplicada El historial de mensajes que ve el modelo se proyecta desde el log de eventos en vez de mantenerse al lado como una segunda verdad. Esa es la diferencia entre un sistema cuyas cifras de coste concuerdan con su ejecución y uno donde ambas divergen y nadie puede decir cuál tiene razón. «Lo visible para el modelo queda registrado» es la única regla que hace posible reconstruir el coste. Sin ella, toda cifra de atribución es una estimación con una barra de error desconocida. Qué construir encima Una step/start con step/end para formar spans de paso: la unidad contra la que reportará coste. Adjunte request/context (proveedor, modelo, ventana de contexto) y el precio a partir del uso del chunk a cada span. Cuente el fan-out de tool/call por paso: la ramificación de herramientas es la razón habitual de que un turno cueste de pronto diez veces más. Vigile la distribución de TurnEndReason . Los turnos abortados y truncados son trabajo pagado sin resultado, y son la primera métrica que no tiene sin un log. Relacionado ¿Qué es DeepSeek Harness? Guía completa Todo es un plugin: la arquitectura (EN) Dónde poner los límites de gasto (EN) Convenciones GenAI de OpenTelemetry (EN) ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Subagentes y delegación en DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/es/research/deepseek-harness-subagents Subagentes de DeepSeek Harness: la delegación como multiplicador de coste Actualizado August 16, 2026 · publicado originalmente August 16, 2026 Respuesta rápida: La forma más rápida de multiplicar la factura de un agente es dejar que los agentes creen agentes. Una petición de usuario se convierte en un árbol, y el árbol no tiene tamaño natural. Por eso... La forma más rápida de multiplicar la factura de un agente es dejar que los agentes creen agentes. Una petición de usuario se convierte en un árbol, y el árbol no tiene tamaño natural. Por eso DeepSeek Harness no trata la delegación como una función más, sino como una costura con límites explícitos. Los subagentes son una costura, no algo integrado La delegación va por ctx.subagents . A diferencia del ejecutor de shell, que tiene exactamente una implementación, los proveedores de subagentes se registran por nombre y varios pueden coexistir. La documentación enumera seis transportes: creación in-process y fork (agentes ordinarios a través del contexto del padre), un puente ACP para despliegue remoto, Codex, Claude Code y una variante basada en SDK. En términos de coste esto significa que el precio de un hijo depende de qué proveedor lo creó. Un agente forkeado in-process y uno remoto lanzado por un puente ACP se ven iguales en el código que los llama y tienen facturas completamente distintas. Dos modos de delegación, dos perfiles de coste Modo Forma Característica de coste De un disparo Crear hijo, enviar prompt, esperar resultado, descartar Acotado, atribuible al turno del padre Continuable Sesión de fondo duradera con una activación residente Abierto; se acumula entre turnos El modo de un disparo se resuelve en un handle de ejecución con una promesa de resultado terminal. Los hijos continuables son más caros de sostener: un gestor de continuación reserva la identidad, compone el hijo, ordena cada turno por el buzón del hijo, y el proveedor solo aporta los metadatos de creación inicial. Las activaciones tienen tres estados: en ejecución, en espera (inactiva pero con activaciones hijas sin completar) y liquidada. Si llega un mensaje sin activación viva, se reanuda en frío desde la sesión persistida. Las reanudaciones en frío son la línea que la gente olvida. El estado se rehidrata desde el registro, así que los tokens de entrada son proporcionales al tamaño del registro. Un hijo longevo al que se habla poco puede costar más por mensaje que uno siempre activo. Las capacidades fallan alto, no en silencio El harness valida las capacidades solicitadas contra el proveedor y rechaza con un error tipado en vez de ignorarlas calladamente. Las capacidades de arranque cubren esquemas de salida, límites de profundidad, filtros de herramientas y personas, y se corresponden uno a uno con las opciones de la petición. Si pide algo que el proveedor no soporta, se entera al arrancar, no en la factura. La profundidad tiene tope, y el tope no se puede blanquear La profundidad de delegación se persiste en la cabecera de sesión y un campo en tiempo de ejecución sigue el mayor de los dos valores, de modo que una reanudación en frío no puede rebajarla. El arranque se rechaza si la profundidad derivada supera maxDepth o los límites de entero seguro. Un padre que crea tres hijos, y cada uno tres más, ha convertido una petición de usuario en trece agentes. Los topes de profundidad son la diferencia entre una ramificación que usted dimensionó y otra que descubrió. Descubrir es barato, entregar es autoritativo listChildren() devuelve un corpus con preferencia por lo vivo mediante una aceleración de tres niveles: caché de marca de agua, luego checkpoint de proyección, luego inspección de la persistencia. listDescendants() recorre en preorden y añade posiciones de padre y profundidad. Ninguna consulta registros de agentes, activaciones ni proveedores; la entrega de mensajes sigue siendo la autoridad. Para atribución de costes esto importa: puede enumerar el árbol barato y cuando quiera. Los resultados llevan una razón de parada La salida es el último mensaje de asistente no vacío o el flujo de texto acumulado; la salida estructurada opcional se valida contra el esquema pedido. El stopReason es una unión extensible por fusión: completed, aborted, error, max-tokens, refusal. Todo lo que no sea completed significa salida parcial mapeada a resultados de herramienta con error: pagada e incompleta. Qué medir Hijos por turno de padre y descendientes por petición de usuario. Profundidad máxima observada frente al tope configurado. Porcentaje de hijos continuables reanudados en frío, más el tamaño del registro al reanudar. Distribución de razones de parada: mucha proporción de max-tokens o error es trabajo pagado y sin terminar. Relacionado ¿Qué es DeepSeek Harness? Guía completa Todo es un plugin: la arquitectura (EN) Límites de gasto en el harness (EN) El registro de sesión como registro de costes (EN) ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Ámbitos de herramientas en DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/es/research/deepseek-harness-tool-scopes DeepSeek Harness: ámbitos, restricciones y sombreado de herramientas Actualizado August 16, 2026 · publicado originalmente August 16, 2026 Respuesta rápida: Los catálogos de herramientas crecen. Alguien añade una herramienta de navegador, alguien una de base de datos, alguien cinco operaciones de terminal, y un año después a cada agente del sistema se le... Los catálogos de herramientas crecen. Alguien añade una herramienta de navegador, alguien una de base de datos, alguien cinco operaciones de terminal, y un año después a cada agente del sistema se le ofrecen cuarenta herramientas las necesite o no. Suele discutirse como un problema de seguridad. También es una partida de gasto. DeepSeek Harness trae un modelo de ámbitos por agente que ataca las dos cosas a la vez. Por qué el catálogo es un coste recurrente Las definiciones de herramienta forman parte de la petición. El harness registra un evento de cabecera de petición que lleva la configuración, el prompt de sistema y el conjunto de herramientas tal y como se enviaron, lo que lo vuelve concreto: el catálogo se retransmite en cada petición al modelo durante la sesión, así que es un impuesto fijo por paso y no un coste único. Hay un segundo efecto, mayor. Un catálogo ancho ensancha el espacio de elección del modelo. Más selecciones plausibles pero equivocadas significan más pasos que no producen nada útil, y los pasos son la unidad de facturación. Recortar la superficie baja a la vez el suelo de tokens y la tasa de error. El vocabulario Término Significado Ámbito La unidad de registro por agente para herramientas, prompts, variables, restricciones y escuchas Clave de ámbito La identidad opaca por la que se indexa un ámbito, comparada por identidad de objeto: normalmente el propio agente vivo Contexto de agente El contexto acotado del propio agente, donde los registros están ligados a su vida y son visibles en el ámbito Restricción Un filtro sobre el conjunto global de herramientas para un ámbito, aplicado por intersección Sombreado Un elemento del ámbito que reemplaza a su homónimo global, solo dentro de ese ámbito Ventana de setup El hueco de creación en el que el creador compone el mundo acotado del agente, antes de publicarlo o del primer prompt Cómo se resuelve la composición Las restricciones filtran primero el conjunto global y después se mezclan los registros locales del ámbito. Ese orden es lo que hace practicable el mínimo privilegio: se parte de una intersección con el catálogo global — nunca más que lo global — y luego se añaden exactamente las herramientas específicas que este agente necesita. El sombreado da el caso de sustitución sin bifurcar nada. Un agente puede recibir otra implementación detrás de un nombre de herramienta familiar — una variante de solo lectura, una medida, un backend más barato — mientras el resto sigue viendo la global. La ligadura de vida importa por lo mismo que importa el dispose. Los registros de ámbito terminan con el contexto del agente, así que un hijo efímero no puede filtrar contribuciones al mundo del padre. Toda la composición ocurre en la ventana de setup, antes de que el agente se publique o arme su primer prompt. Las decisiones de privilegio tomadas después del primer prompt no son decisiones de privilegio: son limpieza. Despacho acotado y linaje Los eventos sobre un agente se despachan con el portador de ese agente, de modo que una escucha sabe de quién es la actividad que observa; los eventos de nivel de registro siguen sin filtrar. Aparte, el linaje — sesión padre, profundidad de delegación, profundidad de subagente — se describe explícitamente como datos que por sí solos no afectan a la visibilidad. Esa separación merece la pena copiarla. Un hijo no hereda acceso por ser hijo; el acceso se compone a propósito en su ventana de setup. El privilegio heredado por defecto es justo cómo un subagente barato de resumen acaba sosteniendo el mismo conjunto caro de herramientas que su padre. Cuatro cosas que hacer con esto Cuente sus definiciones de herramienta y multiplique por pasos por sesión. Ese es su impuesto fijo de herramientas por sesión, en tokens. Defina un conjunto mínimo viable de herramientas por rol de agente y aplíquelo como restricción, no como convención. Sombree las herramientas caras con variantes baratas o de solo lectura en contextos de poco valor, en vez de eliminarlas del todo. Nunca herede por defecto el conjunto del padre en los subagentes. Compóngalo. Relacionado ¿Qué es DeepSeek Harness? Guía completa Límites de gasto en el harness (EN) Subagentes y profundidad de delegación (EN) Qué aporta "todo es un plugin" (EN) ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Controla el coste dentro del pipeline de evaluación LLM · FinOps LLM URL: https://finopsllm.com/es/research/evals-cost-control Controla el coste dentro del pipeline de evaluación LLM Actualizado August 27, 2026 · publicado originalmente August 27, 2026 Respuesta rápida: Las evaluaciones LLM necesitan su propia política de coste. Un job de CI con miles de prompts puede costar más que la función que protege. Usa presupuesto por ejecución, muestreo, fixtures en caché y... Las evaluaciones LLM necesitan su propia política de coste. Un job de CI con miles de prompts puede costar más que la función que protege. Usa presupuesto por ejecución, muestreo, fixtures en caché y límites de calidad. Presupuesta la ejecución Limita prompts, modelos, reintentos y dólares antes de empezar. Separa smoke tests, regresiones nocturnas y certificación. Muestrea para obtener señal Estratifica por flujo, impacto, dificultad y fallos conocidos. Guarda la versión del conjunto. Controla calidad y coste Detén la ejecución al superar el límite de dólares o fallar el umbral de calidad. Registra modelo, tokens, reintentos, caché, coste y resultado. Relacionado Coste por tarea exitosa ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # FinOps para LLM y GenAI: un marco práctico · FinOps LLM URL: https://finopsllm.com/es/research/finops-for-llm FinOps para LLM: un marco práctico FinOps para LLMs es la práctica de hacer visible, atribuible, optimizable y responsable el gasto en IA. Toma prestados los principios de FinOps en la nube, pero los generadores de coste son diferentes. Una factura de nube está determinada por instancias, almacenamiento, transferencia y compromisos. Una factura de LLM está determinada por tokens de entrada, tokens de salida, escrituras de caché, lecturas de caché, reintentos, combinación de modelos, longitud del contexto, elegibilidad de lotes y requisitos de calidad. El primer error que cometen los equipos es tratar el gasto en LLM como un número único a nivel de proveedor. Eso oculta los verdaderos factores. Un endpoint de resumen de soporte, un flujo de trabajo de agente, un trabajo de enriquecimiento nocturno y un conjunto de evaluación pueden usar el mismo modelo, pero tienen diferentes necesidades de latencia, umbrales de calidad, capacidad de caché y propiedad. FinOps comienza cuando esas cargas de trabajo se separan. Pilar Pregunta central Lo que produce 1. Visibilidad ¿Qué es exactamente lo que estamos pagando, solicitud a solicitud? Registros de uso normalizados divididos por entrada, salida, escritura de caché, lectura de caché, lote y gasto en reintento 2. Atribución ¿Qué equipo, característica, cliente o carga de trabajo lo causó? Gasto asignado a propietarios: entorno, endpoint, equipo, inquilino, modelo, clase de carga de trabajo 3. Optimización ¿Qué factor reduce el coste por tarea exitosa sin afectar la calidad? Cambios de enrutamiento, caché, lotes, compactación y arbitraje desplegados detrás de indicadores 4. Responsabilidad ¿Quién revisa los números y actúa sobre ellos cada mes? Reportes de showback (y luego chargeback) y un ritmo operativo conciliado con facturas 1. Visibilidad Visibilidad significa normalizar facturas de proveedor y registros de gateway en un registro común. Cada solicitud debe llevar suficientes metadatos para responder: quién es el propietario, qué característica la generó, qué modelo la manejó, cuántas clases de tokens se facturaron, si la llamada se reinició y si la salida produjo valor para el usuario. La buena visibilidad separa el gasto de entrada, salida, escritura de caché, lectura de caché, lote y reintento. Sin esta división, los equipos cuentan accidentalmente los descuentos de lectura de caché como ahorros, pierden bucles de reintento y comparan proveedores en precio de lista en lugar de coste por tarea exitosa. 2. Atribución La atribución asigna el gasto a equipos, productos, clientes y cargas de trabajo. El punto no es culpa; el punto es la calidad de la decisión. Un equipo de finanzas no puede gobernar el gasto si cada línea dice "OpenAI." Un líder de ingeniería no puede optimizar una superficie de producto si el gasto se agrupa solo por cuenta de proveedor. La atribución mínima útil generalmente incluye entorno, endpoint, propietario del equipo, cliente o inquilino cuando sea permitido, modelo, proveedor y clase de carga de trabajo. Los programas maduros añaden métricas de negocio como ticket resuelto, análisis completado, reporte generado o tarea de agente exitosa. 3. Optimización La optimización debe seguir a la atribución. Los factores comunes son enrutamiento de modelos, caché semántica, caché de prompts, compactación de contexto, enrutamiento de lotes, arbitraje de proveedores y ajuste de política de reserva. Cada factor cambia la factura de forma diferente. El enrutamiento cambia la mezcla de modelos. El caché cambia la economía de tokens de entrada y latencia. El lote mueve el trabajo a carriles asincrónicas con descuento. La compactación reduce contexto repetido. La prueba no es "¿bajó el recuento de tokens?" La prueba es "¿bajó el coste por tarea exitosa sin romper la calidad, latencia o fiabilidad?" 4. Responsabilidad Showback debe venir antes que chargeback. Primero da a los equipos una vista mensual creíble de su gasto y factores. Una vez que se confía en los números, el chargeback puede tener sentido para organizaciones maduras. El objetivo es un ritmo operativo repetible: revisar los factores más grandes, acordar candidatos de optimización, desplegar cambios detrás de indicadores y conciliar con la siguiente factura. Relacionado ¿Qué es LLM FinOps? - la disciplina operativa. AI FinOps - la práctica más amplia en la que encaja LLM FinOps. Atribución de costes en LLM - cómo funciona la capa de atribución. LLM chargeback y showback - moviendo costes a propietarios. ¿Quieres que esto se aplique a tu propio gasto en LLM? FinOps LLM ejecuta una auditoría gratuita de tus costes en IA y muestra dónde están los ahorros. Solicita tu auditoría gratuita → Volver a la investigación --- # El primer cierre mensual para un producto con mucha IA · FinOps LLM URL: https://finopsllm.com/es/research/first-ai-month-end-close El primer cierre mensual para un producto con mucha IA Actualizado August 27, 2026 · publicado originalmente August 27, 2026 Respuesta rápida: El primer cierre mensual de IA debe empezar con las facturas brutas y un periodo bloqueado, no con una captura del panel. Primero cierra el efectivo, después explica el uso y solo entonces asigna el... El primer cierre mensual de IA debe empezar con las facturas brutas y un periodo bloqueado, no con una captura del panel. Primero cierra el efectivo, después explica el uso y solo entonces asigna el coste. Bloquea el periodo Define zona horaria, moneda, descuentos, créditos y corte de factura. Congela la tabla de precios y registra los identificadores de factura y la ventana de telemetría. Concilia y asigna Une los eventos con la facturación por proveedor, cuenta, modelo, tipo de token y día. Investiga el residual. Después asigna por función, equipo, entorno, cohorte y carga; separa la plataforma compartida y registra la tasa sin etiquetas. Explica la variación Divide el cambio en tarifa, volumen, mezcla y eficiencia. Relaciona cada movimiento con una versión, tráfico, cambio de modelo o comportamiento del agente. Firma la conciliación, la explicación y la política de asignación. Un cierre fiable es aburrido: cada dólar tiene una fuente y cada diferencia tiene responsable. Relacionado Conciliación de facturas de IA ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # FOCUS 1.5 estandariza el rastreo de tokens IA · FinOps LLM URL: https://finopsllm.com/es/research/focus-1-5-ai-token-tracking FOCUS 1.5: rastreo nativo de tokens de IA y Price Sheets Actualizado September 19, 2026 · publicado originalmente August 15, 2026 Respuesta rápida: La FinOps Foundation ha confirmado que FOCUS 1.5 se publicará en diciembre de 2026. Esta versión incorpora por primera vez campos nativos de inteligencia artificial en la especificación abierta de... La FinOps Foundation ha confirmado que FOCUS 1.5 se publicará en diciembre de 2026. Esta versión incorpora por primera vez campos nativos de inteligencia artificial en la especificación abierta de costes: identificación de modelos, conteo desagregado de tokens de entrada y salida, y el nuevo conjunto de datos Price Sheet . 1. Lo que estandariza FOCUS 1.5 Identificación de modelos: Nomenclatura uniforme entre proveedores cloud. Métricas de tokens: Desglose en columnas de entrada, salida y tokens en caché. Dataset Price Sheet: Separación entre el catálogo de precios de lista y los eventos de consumo. 2. Límites de la especificación FOCUS estandariza la facturación emitida por los proveedores, pero no resuelve la atribución interna de costes . El proveedor no sabe qué microservicio o equipo generó la llamada; esa trazabilidad debe registrarse en su propio gateway. 3. Pasos de preparación Guarde los recuentos de tokens por categoría, asocie el ID del modelo a cada registro y concilie las llamadas con las facturas oficiales cada mes. Relacionado Atribución de costes de LLM Conciliación de facturas de IA ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # El plan gratuito es un coste de captación · FinOps LLM URL: https://finopsllm.com/es/research/free-tier-is-an-acquisition-cost El plan gratuito como coste de captación Actualizado September 1, 2026 · publicado originalmente September 1, 2026 Respuesta rápida: Servir inferencia no es gratis. Cuando un proveedor te da un plan gratuito, límites generosos en una preview o un endpoint sin marca que no cuesta nada, ese cómputo lo paga alguien — con cargo a... Servir inferencia no es gratis. Cuando un proveedor te da un plan gratuito, límites generosos en una preview o un endpoint sin marca que no cuesta nada, ese cómputo lo paga alguien — con cargo a una partida que tiene nombre. Es coste de captación de clientes, y se comporta como cualquier otro CAC. Es la lente más útil para un equipo financiero, porque el CAC tiene dinámicas predecibles: se gasta para ganar una cohorte, tiene periodo de recuperación y se detiene cuando la cohorte ya está ganada. Qué compra un plan gratuito Evaluación sin pasar por compras. Datos de cargas reales , que valen más que el cómputo. Y un ancla de precio : si tus ingenieros se acostumbran a una capacidad a coste cero, la tarifa de cualquier competidor parecerá cara. La señal que hay que leer Los límites se aprietan antes de que suban los precios. Vigila la concurrencia, el contexto y qué modelos siguen incluidos: todo eso se mueve antes de que se publique una tarifa nueva. Cómo usarlo Nunca metas un plan gratuito en tu unit economics. Si un caso de uso solo tiene margen porque parte de la inferencia es gratis, no tienes margen: tienes un subsidio con fecha de caducidad ajena. Valora el uso gratuito a una tarifa sombra en telemetría y llévala en la previsión. Mide el coste de cambiar mientras aún es barato irse. Mantén un segundo proveedor cableado en al menos una ruta. Relacionado Arbitraje entre proveedores ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Guía de Precios de GPT-5.6: Luna, Terra, Sol · FinOps LLM URL: https://finopsllm.com/es/research/gpt-5-6-pricing-tier-guide Guía de Precios de GPT-5.6: Luna, Terra, Sol Publicado 19 de julio de 2026 OpenAI lanzó GPT-5.6 el 10 de julio con tres niveles de precios distintos: Luna a $1/$6 por 1M tokens, Terra a $2.50/$15 y Sol a $5/$30. Esto no es un simple intercambio velocidad/calidad; cada nivel se posiciona para una clase diferente de carga de trabajo. La pregunta no es "cuál es el mejor" — es "cuál es el correcto para esta tarea?" Esta guía mapea tareas a niveles, camina a través de ejemplos de costes por tarea, y te muestra cómo cascadear inteligentemente cuando un nivel más barato no es lo suficientemente confiado. Luna ($1/$6): clasificación, extracción simple, enrutamiento de alto volumen Terra ($2.50/$15): razonamiento equilibrado, bucles de agentes, conversaciones multi-turno Sol ($5/$30): razonamiento de frontera, generación de código, investigación difícil Las lecturas de caché ahorran 90%; las escrituras de caché cuestan 1.25× entrada — punto de equilibrio en 5+ aciertos en 30 min La API de lotes añade 50% de descuento además de precios de nivel para trabajo no interactivo Caveat crítico: OpenAI posiciona Terra y Sol como teniendo capacidad de razonamiento equivalente, diferenciándose principalmente en velocidad y rendimiento. Compara ambos contra tu carga de trabajo real — la pretensión de paridad no siempre se mantiene en tu distribución de datos. Ver GPT-5 vs alternativas para comparación con Claude y DeepSeek. 1. Los Tres Niveles: Velocidad, Coste y Capacidad Nivel Entrada $/1M Salida $/1M Lectura de Caché $/1M Contexto Latencia Típica Luna $1.00 $6.00 $0.10 128K 80–200 ms Terra $2.50 $15.00 $0.25 128K 150–400 ms Sol $5.00 $30.00 $0.50 128K 300–800 ms La latencia importa: Luna es más rápido porque se optimiza para streaming, clasificación en tiempo real y rendimiento. Sol es más lento porque realiza más razonamiento interno. Para cargas de trabajo interactivas orientadas al usuario, Luna también es más barato y más rápido — pero solo si es lo suficientemente capaz para tu tarea. Esta es la decisión clave de enrutamiento. 2. Tabla de Enrutamiento por Tipo de Tarea Esta tabla mapea tareas comunes de LLM al nivel que minimiza el coste por respuesta exitosa: Tipo de Tarea Ejemplo Nivel Recomendado Tasa de Éxito en Nivel Coste Est./1K Tareas Clasificación Spam / no-spam; sentimiento (pos/neg/neutro) Luna 95–98% $1.20–$1.50 Extracción estructurada Extraer nombre, email, teléfono de texto Luna 92–96% $1.80–$2.40 Categorización (muchas clases) Asignar una de 50+ categorías de producto Luna 88–94% $2.40–$3.20 Resumen Condensar artículo o log de chat Luna 92–97% $1.50–$2.00 Bucles de agentes (uso de herramientas) Multi-turno: buscar, razonar, refinar Terra 85–92% $8.00–$12.00 Conversación multi-turno Bots de soporte al cliente, asesoramiento Terra 88–94% $6.00–$10.00 Generación de código (simple) Consulta SQL, snippet Bash, regex Terra 80–90% $10.00–$15.00 Generación de código (compleja) Endpoint completo, máquina de estados, compilador DSL Sol 75–88% $25.00–$40.00 Investigación + síntesis Analizar 10+ artículos, sintetizar consenso Sol 80–90% $30.00–$50.00 Razonamiento difícil (problema novel) Verificación de pruebas, diseño de algoritmo novel Sol 70–85% $40.00–$70.00 Insight clave: El coste por tarea no es solo coste API — es (coste API) / (tasa de éxito). Una clasificación Luna con 95% de éxito cuesta ~$1.26 por respuesta exitosa. Si enrutas la misma tarea a Sol con 98% de éxito, pagas ~$5.10 por respuesta — pero has resuelto 3% más de tu carga de trabajo, lo que puede o no valer el coste 4×. 3. Ejemplos Resueltos de Coste Por Tarea Ejemplo 1: Clasificación de Spam (Luna) Tarea: Clasificar email como spam (sí/no binario). Perfil de tokens típico: 400 entrada (email) + 50 salida (clasificación + confianza) = 450 tokens. Coste Luna: (400 × $1/1M) + (50 × $6/1M) = $0.00043/solicitud. Si 96% tienen éxito en primer intento: $0.00043 / 0.96 = $0.00045 por clasificación exitosa. A 1M emails/mes: $450/mes (más descuento de caché si reutilizas prompts del sistema). Si enrutado incorrectamente a Sol: (400 × $5 + 50 × $30) / 1M = $0.0025 por solicitud. Con 98% de éxito: $0.00255/exitosa = $2,550/mes (5.7× más). Ejemplo 2: Agente de Soporte al Cliente (Terra) Tarea: Conversación de soporte multi-turno con uso de herramientas (búsqueda de tickets, búsqueda de políticas, decisión de escalada). Perfil de tokens típico por turno: 2,000 entrada (contexto + historial) + 400 salida (respuesta + llamadas de herramientas) = 2,400 tokens. Promedio 3 turnos para resolver = 7,200 tokens totales por ticket. Coste Terra: (2,000 × $2.50/1M) + (400 × $15/1M) = $0.0080/turno o $0.0240 por ticket. Si 90% se resuelven sin escalada: $0.0240 / 0.90 = $0.0267 por ticket exitoso. A 10K tickets/mes: $267/mes. Si usabas Luna en su lugar: (2,000 × $1 + 400 × $6) / 1M = $0.0044 por turno = $0.0132/ticket. Pero el éxito del bucle de agentes de Luna baja a 65% (las llamadas de herramientas fallan, el razonamiento es superficial). Coste por exitosa: $0.0132 / 0.65 = $0.0203. Ahorro neto: $29/mes, pero 25% de tickets fallan y escalan, elevando coste de soporte $400+. Luna no funciona aquí. Ejemplo 3: Generación de Código (Terra vs Sol) Tarea: Generar función Python desde cadena de requisito. Perfil de tokens típico: 1,500 entrada (especificación + ejemplos) + 600 salida (código + explicación) = 2,100 tokens. Coste Terra: (1,500 × $2.50 + 600 × $15) / 1M = $0.0134 por solicitud. Con 85% de éxito en primer pase (código compila + pasa tests básicos): $0.0158 por función que funciona. Coste Sol: (1,500 × $5 + 600 × $30) / 1M = $0.0255 por solicitud. Con 90% de éxito en primer pase: $0.0283 por función que funciona. Ahorro con Terra: 44% más barato por resultado que funciona. Usa Sol solo si la diferencia del 5% en tasa de éxito y calidad de código reduce mediblemente el coste de debugging descendente. 4. Patrón de Enrutamiento Cascade & Fallback La mayoría de equipos FinOps no deberían usar un solo nivel para todo trabajo. En su lugar, implementa un patrón cascade: comienza con el nivel más barato, mide confianza, escala en confianza baja. Paso Modelo Umbral de Confianza Acción si Umbral No Se Cumple 1 Luna Confianza > 85% Retornar resultado 2 Terra Confianza > 75% Retornar resultado (escalado) 3 Sol Confianza > 60% Retornar resultado o fallar explícitamente 4 Revisión humana — Escalar a humano Escenario real: Estás haciendo clasificación de documentos para facturas (clasificar por proveedor). Luna retornará resultados de alta confianza (~94% de éxito) y costará ~$1.20 por 1K. Para el 6% de facturas ambiguas donde Luna retorna confianza 5. Economía de Almacenamiento en Caché de Prompts GPT-5.6 cambió costes de almacenamiento: las escrituras de caché ahora cuestan 1.25× la tasa de entrada sin caché (no gratis), y las lecturas de caché cuestan 10% de entrada. Escenario Tamaño de Prefijo Coste de Escritura Coste de Lectura (por acierto) Aciertos de Punto de Equilibrio Ahorro @ 10 aciertos/mes Contexto de recuperación en caché Luna 100K tokens $0.125 $0.010 15 aciertos -$0.025 (pérdida) Prompt del sistema en caché Luna + docs 50K tokens $0.063 $0.005 8 aciertos $0.032 Contexto de agentes en caché Terra 80K tokens $0.250 $0.020 14 aciertos $0.030 Contexto de razonamiento en caché Sol 100K tokens $0.625 $0.050 13 aciertos $0.025 Cuándo cachear: Si tu prompt incluye un prefijo estable (instrucciones del sistema, documentación, ejemplos pocos-disparos) que se reutiliza más de 5–10 veces en una ventana de 30 minutos, el almacenamiento generalmente ahorra dinero. La API de lotes (50% descuento) ahora compite con almacenamiento en coste — si clasificas documentos en lote, el descuento de lote vence la sobrecarga de almacenamiento. 6. Comparación con Claude Sonnet 5, Gemini 3.1 Pro y DeepSeek V4 Modelo Entrada $/1M Salida $/1M Velocidad Capacidad de Razonamiento Cuándo Elegir GPT-5.6 Luna $1.00 $6.00 Rápido Seguimiento de instrucciones, enrutamiento Clasificación, extracción, rendimiento GPT-5.6 Terra $2.50 $15.00 Medio Razonamiento moderado, uso de herramientas Agentes, multi-turno, código medio GPT-5.6 Sol $5.00 $30.00 Lento Razonamiento de frontera, investigación Código complejo, razonamiento difícil, problemas novel Claude Sonnet 5 $2.00–$3.00 $10.00–$15.00 Medio–Rápido Razonamiento fuerte, tokens de razonamiento largo Razonamiento, codificación (competitivo con Sol) Gemini 3.1 Pro $2.00 $12.00 Medio Multimodal, capacidad de investigación Tareas multimodales, competitivo con Terra DeepSeek V4 Flash $0.14 $0.28 Muy Rápido Razonamiento básico, enfoque entrada en caché Enrutamiento de alto volumen, cargas de trabajo enfoque en caché (7–35× más barato) Arbitraje de costes: Para clasificación simple y extracción, DeepSeek V4 Flash es 7–20× más barato que Luna. Compara contra tus datos — si alcanza 90%+ de precisión, úsalo y guarda la diferencia. Claude Sonnet 5 es 2× más caro que Terra pero proporciona razonamiento más fuerte por pretensión de capacidad de modelo; úsalo si tu benchmark de Terra muestra calidad insuficiente. Gemini 3.1 Pro aterriza entre Luna y Terra — útil si necesitas entrada multimodal o ya estás en el ecosistema Vertex AI. 7. Migración desde GPT-5/5.5 & Estado de Deprecación OpenAI continúa ofreciendo GPT-5.5 ($5/$30, igual que Sol) y GPT-5.4 ($2.50/$15, igual que Terra) junto a GPT-5.6. No hay presión de deprecación en modelos más antiguos — puedes seguir usando GPT-5.5 si tu código lo apunta. Sin embargo, GPT-5.6 pretende paridad de rendimiento (o mejor) al mismo nivel, así que migra a 5.6 para nuevos despliegues. La interfaz ChatGPT continúa retirando modelos más antiguos en base continua (GPT-4o mini, GPT-4 turbo ahora son solo lectura); el acceso API es estable. Si construyes contra la API, planifica revisiones anuales del estado de deprecación de modelo pero no esperes urgencia. Marco de Medición de Costes Paso 1: Establecer línea base por nivel Ejecuta una semana de tráfico y registra qué nivel manejó cada solicitud. Esto te da distribución de línea base y coste. Paso 2: Medir puntuaciones de confianza y tasas de fallback Para cada nivel, registra confianza retornada. Calcula: qué % de llamadas Luna tienen confianza > 85%? Qué % escalan a Terra? Esto te dice si tu cascade está equilibrado. Paso 3: Auditar éxito/fallo por nivel Compara salida de modelo contra verdad de base para una semana. Qué nivel tiene rendimiento insuficiente en tus datos? Ajusta umbrales o selección de nivel basado en precisión real, no pretensiones de OpenAI. Paso 4: Calcular coste verdadero por respuesta exitosa Coste verdadero = (coste_nivel) / (tasa_éxito). Si Luna cuesta $1.20 por 1K con 94% de éxito, coste por respuesta que funciona es $1.28. Esta es la métrica a optimizar. Lista de Verificación Rápida de Selección de Nivel ¿Es esta una tarea de clasificación, extracción o enrutamiento? → Luna a menos que la precisión sea crítica. ¿Implica la tarea uso de herramientas o razonamiento multi-turno? → Terra. ¿Es esto razonamiento novel, código complejo o análisis multi-hop? → Sol (o compara Claude Sonnet 5 primero). ¿Puedes implementar un cascade (Luna → Terra → Sol)? → Sí, esto es usualmente óptimo. ¿Hay un prefijo estable (prompt del sistema, docs) reutilizado 10+ veces/mes? → Cachealo, mide ROI en punto de equilibrio (5–15 aciertos). ¿Es esto lote o interactivo? → Trabajo en lote califica para descuento 50%; recalcula ROI con API de lote. ¿Has comparado alternativas (Claude, DeepSeek, Gemini)? → Hazlo en tus datos, no pretensiones de marketing. La selección de nivel es un problema de clasificación: acopla propiedades de carga de trabajo a economía de nivel. El ideal es enrutamiento cascade — enruta a Luna primero, mide confianza, escala en incertidumbre. Esto minimiza coste manteniendo calidad. FinOps LLM puede ejecutar una auditoría de costes en tu tráfico LLM y mostrarte dónde desajuste de nivel está dejando dinero en la mesa. Reserva auditoría gratuita . Ver también: ¿Cuánto Cuesta GPT-5? para el panorama completo de precios de GPT y Costes Ocultos de LLM para infraestructura y gastos indirectos de fallback más allá de cuotas por token. Volver a investigación FAQ ¿Qué nivel de GPT-5.6 debo usar para tareas de clasificación? Luna ($1/$6 por 1M) es la opción correcta para clasificación y extracción simple. Con 600 tokens de entrada + 100 tokens de salida, Luna cuesta $0.00066/solicitud frente a los $0.00175/solicitud de Terra. Si la precisión no es tu cuello de botella, Luna proporciona resultados equivalentes con un ahorro del 62%. ¿Cuándo Terra ($2.50/$15) le gana al coste a Sol ($5/$30)? Siempre. Terra se posiciona como el punto dulce de rendimiento/coste: mismas pretensiones de capacidad que Sol pero a exactamente la mitad del precio. Usa Terra para bucles de agentes, conversaciones multi-turno y tareas de razonamiento moderado. Usa Sol solo cuando la profundidad de razonamiento de Terra sea demostrablemente insuficiente. ¿Cuál es el impacto en costes del almacenamiento en caché de prompts en GPT-5.6? Las escrituras de caché cuestan 1.25× entrada (por ejemplo, $1.25 por millón para Luna). Las lecturas de caché cuestan 10% de entrada ($0.10 por millón para Luna). Si un prefijo de 100K tokens se reutiliza 5+ veces en 30 minutos, el almacenamiento en caché ahorra 60%+ frente a llamadas sin caché repetidas. ¿Cómo se compara GPT-5.6 con Claude Sonnet 5 y DeepSeek V4? Luna ($1/$6) es 50-60% más barato que Claude Sonnet ($2/$10 intro, $3/$15 Sept 1) y DeepSeek V4 Flash ($0.14/$0.28) es 7-20× más barato que Luna. Para cargas de trabajo de razonamiento, Sol ($5/$30) y Claude Sonnet intercambian rendimiento por dólar de manera diferente; compara tu caso de uso. --- # Claude Max vs Alibaba Token Pro: coste agentic · FinOps LLM URL: https://finopsllm.com/es/research/heavy-agentic-coding-cost-claude-vs-qwen Claude Max vs Alibaba Token Pro: el coste real del código agéntico Actualizado September 19, 2026 · publicado originalmente August 6, 2026 Respuesta rápida: Cuando el desarrollo con IA pasa de completar líneas a ejecutar enjambres multi-agente (donde un coordinador lanza de 4 a 8 sub-agentes en paralelo para refactorizar, compilar pruebas y auditar... Cuando el desarrollo con IA pasa de completar líneas a ejecutar enjambres multi-agente (donde un coordinador lanza de 4 a 8 sub-agentes en paralelo para refactorizar, compilar pruebas y auditar seguridad), el consumo de tokens se dispara. Comparar suscripciones por precio nominal de token induce a error financiero. 1. Dos modelos de consumo incompatibles Alibaba Token Pro ($70/mes) ofrece límites explícitos de 12.000 créditos cada 5 horas y 40.000 créditos semanales en Qwen 3.8-Max, con multiplicador de 0,2× en horas valle. Claude Max 20x ($200/mes) asigna cómputo dinámico sin cuota fija en Opus 5, priorizando la precisión en el primer intento y menor verbosidad. 2. Ecuación de punto de equilibrio En coste de suscripción puro ($70 vs $200), Qwen 3.8-Max solo necesita alcanzar el 35% del rendimiento de tareas aceptadas de Opus 5 para ser más económico por funcionalidad terminada. Sin embargo, valorando el tiempo del programador a $50/hora, si Opus 5 ahorra solo 2,6 horas al mes en revisiones y corrección de tests, la diferencia de $130 queda completamente justificada. Relacionado Auditoría de costes: Alibaba vs Claude Max Precios de proveedores IA: comparación real ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # La marca invisible de cada respuesta de Claude · FinOps LLM URL: https://finopsllm.com/es/research/how-ai-watermarking-works Cómo funciona la marca de agua de IA Actualizado September 1, 2026 · publicado originalmente September 1, 2026 Respuesta rápida: Hay una señal invisible en el texto que generan los modelos Claude compatibles. Ni tú ni tus usuarios podéis verla, no cambia el significado ni la calidad y no aparece en la factura. Aun así está ahí,... Hay una señal invisible en el texto que generan los modelos Claude compatibles. Ni tú ni tus usuarios podéis verla, no cambia el significado ni la calidad y no aparece en la factura. Aun así está ahí, y conviene entenderla, porque lo que la rompe es justo lo que tu propia canalización hace a diario. Cómo funciona en el texto Un modelo de lenguaje no elige el token más probable: muestrea de una distribución usando aleatoriedad. La técnica de marca de agua — siguiendo el enfoque SynthID-Text — sesga esa aleatoriedad. Ciertos tokens se vuelven ligeramente más probables según un patrón que solo conoce el detector. Cada palabra por separado es irrelevante: siempre había una alternativa plausible. A lo largo de cientos de tokens, el patrón se acumula en una señal estadística que un detector mide y un lector no percibe. De ahí dos consecuencias: es estadística, no un sello, y necesita longitud. Una salida del tamaño de un tuit lleva mucha menos señal que una página entera. Las imágenes funcionan al revés Los archivos .svg , .png y .jpg generados llevan metadatos C2PA: un manifiesto firmado criptográficamente. No es estadístico ni oculto, es un bloque de datos verificable con exactitud. El intercambio es previsible: los metadatos firmados dan certeza y se borran con un comando; la marca estadística no se borra limpiamente pero se degrada al editar, parafrasear o traducir. Ninguna es un candado; ambas son pruebas. Qué significa para tus sistemas Las salidas cortas llevan señal débil. El posprocesado intenso — parafrasear, resumir, traducir o pasar el texto por un segundo modelo — erosiona la señal. Y tu canalización de imágenes puede destruir los metadatos C2PA sin querer, que es la forma más común de perder la procedencia en producción. Relacionado Lo que cuesta realmente la marca de agua ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Tu CDN está borrando la marca de agua de IA · FinOps LLM URL: https://finopsllm.com/es/research/how-ai-watermarks-get-destroyed Cómo se destruyen las marcas de agua Actualizado September 1, 2026 · publicado originalmente September 1, 2026 Respuesta rápida: La pregunta interesante sobre la marca de agua no es cómo burlarla, sino por qué tanto contenido de producción llega al final de la canalización sin procedencia, sin que nadie quisiera eliminar nada.... La pregunta interesante sobre la marca de agua no es cómo burlarla, sino por qué tanto contenido de producción llega al final de la canalización sin procedencia, sin que nadie quisiera eliminar nada. La procedencia rara vez se ataca: se optimiza hasta desaparecer, con sistemas que hacen exactamente aquello para lo que se construyeron. Hay dos fallos independientes porque hay dos mecanismos. La procedencia de imagen muere por borrado; la de texto, por dilución. Ambos son silenciosos. Borrado: los metadatos que tira tu canalización Los metadatos C2PA viven en el archivo. Los miniaturizadores, las transformaciones del CDN, la conversión a WebP o AVIF, las subidas a plataformas de terceros y cualquier captura de pantalla los descartan salvo configuración expresa. El patrón es constante: todo lo que vuelve a codificar la imagen produce un archivo nuevo, y un archivo nuevo no tiene manifiesto firmado. Basta una transformación automática entre la generación y la entrega. Dilución: los pasos de texto que erosionan la señal La marca de texto es estadística, así que no desaparece de golpe: se debilita. Traducir regenera cada token en otro idioma. Parafrasear y "reescribir en nuestro tono" degrada. Resumir descarta la mayoría de los tokens que llevaban la señal. Pasar la salida por un segundo modelo la atribuye, como mucho, al último. Y una salida de dos frases nunca llevó mucha señal. Fíjate en que un producto bien construido hace varias de esas cosas. Generar con un modelo, reescribir el tono con otro, traducir a cinco idiomas y truncar a una tarjeta resumen no es hacer nada mal — y aun así produce contenido que ningún detector atribuirá con confianza. La versión barata Genera hoy una imagen y un texto largo por tu ruta real de producción y comprueba qué sobrevive al final. Es una tarde de trabajo, y encuentra la etapa exacta que rompe la cadena antes de que lo haga una auditoría. Relacionado Cómo funciona la marca de agua de IA ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # ¿Cuánto Cuesta GPT-5? Guía Completa de Precios 2026 · FinOps LLM URL: https://finopsllm.com/es/research/how-much-does-gpt5-cost ¿Cuánto Cuesta GPT-5? Actualizado 15 de julio de 2026 · publicado inicialmente el 4 de julio de 2026 GPT-5 es el modelo insignia de razonamiento de OpenAI, lanzado en 2026. Ofrece un rendimiento sustancialmente superior en tareas complejas de razonamiento, programación y multimodales respecto a GPT-4o - pero a un precio premium. Esta guía desglosa cada dimensión de coste: precios API, niveles de suscripción ChatGPT, comparación con GPT-4o y dónde alternativas más baratas como MiMO pueden ser la opción más inteligente. Precios API de GPT-5 OpenAI factura GPT-5 por millón de tokens, con tarifas separadas para entrada, salida y entrada en caché. Las lecturas de caché son significativamente más baratas porque el modelo reutiliza un prefijo previamente calculado. Nivel Entrada $/1M Salida $/1M Lectura Caché $/1M Ventana de Contexto GPT-5.6-Sol (máx) $5.00 $30.00 $0.50 128K tokens GPT-5.6-Terra (medio) $2.50 $15.00 $0.25 128K tokens GPT-5.6-Luna (económico) $1.00 $6.00 $0.10 128K tokens GPT-5.5 (insignia) $5.00 $30.00 $0.50 128K tokens GPT-5.4 (gama media) $2.50 $15.00 $0.25 128K tokens La nueva generación de julio de 2026 de OpenAI (GPT-5.6) introduce tres niveles distintos: Sol para razonamiento de frontera, Terra para rendimiento equilibrado, y Luna para casos de uso conscientes del coste. Para comparar, los modelos más antiguos GPT-5.5 y 5.4 siguen disponibles. GPT-5.6 y 5.5 a $5/$30 son significativamente más capaces que GPT-4o ($2.50/$10), pero el coste efectivo depende de la profundidad del razonamiento y la eficiencia del caché. Costes de suscripción ChatGPT Si usas GPT-5 a través de la interfaz ChatGPT en lugar de la API, el precio es por suscripción: Plan Precio Mensual Acceso GPT-5 Límites Clave Free $0 Solo GPT-5 mini Mensajes limitados/día Plus $20/mes GPT-5 con límites ~80 mensajes GPT-5/3hrs Pro $200/mes GPT-5 ilimitado Sin límites de tasa, voz, investigación profunda Team $25/usuario/mes GPT-5 con límites altos Herramientas admin, SSO, límites superiores Enterprise Personalizado GPT-5 ilimitado SLA, soporte dedicado, gobernanza de datos El plan Pro a $200/mes solo es rentable si eres un usuario intensivo diario. Para la mayoría de desarrolladores y equipos, la API con gestión cuidadosa de tokens es más barata que una suscripción Pro. GPT-5 vs GPT-4o: ¿cuándo merece la pena el upgrade? La diferencia de precio es real, así que la pregunta es si la ventaja de calidad de GPT-5 se traduce en ahorro de costes en otros aspectos: Usa GPT-5 cuando: la tarea requiera razonamiento multi-paso, generación compleja de código, análisis de documentos largos o flujos de trabajo agénticos donde un solo pase de alta calidad ahorra múltiples ciclos de reintento. Usa GPT-4o cuando: la tarea es directa - clasificación, extracción, resúmenes de textos cortos, chat simple o procesamiento por lotes de alto volumen donde el rendimiento importa más que la inteligencia por solicitud. Usa GPT-5 mini o nano cuando: necesitas seguimiento de instrucciones de nivel GPT-5 pero a menor coste, y puedes aceptar una profundidad de razonamiento ligeramente reducida. Una regla práctica: si tus prompts de GPT-4o incluyen instrucciones de cadena de pensamiento o bucles de corrección multi-turno, GPT-5 puede ser realmente más barato porque realiza ese razonamiento de forma nativa en una sola llamada. Cómo reducir los costes de GPT-5 Varias estrategias pueden reducir tu factura de GPT-5 en un 30–70% sin sacrificar la calidad de salida: Aprovecha el caché de prompts. La tasa de lectura de caché de GPT-5 ($2.50/1M) es un 75% más barata que la tasa de entrada completa. Estructura tus prompts con un prefijo estable (instrucciones del sistema, contexto) y un sufijo variable (consulta del usuario) para maximizar los aciertos de caché. Usa GPT-5 mini/nano para enrutamiento. Ejecuta un modelo ligero primero para clasificar la intención, luego escala a GPT-5 completo solo para consultas complejas. Este es el patrón de enrutamiento de modelos . API por lotes para trabajo no interactivo. La API por lotes de OpenAI ofrece descuentos del 50% en cargas de trabajo asíncronas - ideal para evaluación, enriquecimiento y generación de informes. Ajusta las ventanas de contexto. No envíes 100K tokens de contexto cuando 5K son suficientes. Cada token de entrada innecesario cuesta 4× más en GPT-5 que en GPT-4o. Considera alternativas. Para muchas tareas de programación y razonamiento, modelos como MiMO , DeepSeek R1 o Claude Sonnet ofrecen calidad comparable a una fracción del coste. Usa arbitraje de proveedores para comparar. Costes ocultos más allá del precio nominal La tarifa por token es solo parte del panorama. Presupuesta estos factores adicionales: Tokens de razonamiento. GPT-5 usa tokens de razonamiento internos para tareas complejas. Se facturan a la tasa de salida ($30/1M) y pueden multiplicar tu volumen efectivo de salida por 2–5× en problemas difíciles. Costes de reintento. Si tus prompts son ambiguos o tu análisis sintáctico es frágil, los intentos fallidos aún consumen tokens. Una ingeniería de prompts robusta se paga por sí misma. Gasto en evaluación. Las pruebas y benchmarks durante el desarrollo pueden fácilmente exceder el gasto en producción si no se rastrean por separado. Ver asignación de costes de evaluación . Conclusión GPT-5 es caro pero no uniformemente. A $10/$30 por millón de tokens, una llamada API típica con 1,000 tokens de entrada y 500 de salida cuesta aproximadamente $0.025. Para aplicaciones de alto volumen, la factura se acumula rápido - pero el caché inteligente, el enrutamiento y el procesamiento por lotes pueden reducir los costes a la mitad o más. Rastrea cada solicitud, atribuye el gasto a las características y compara alternativas regularmente. Relacionado ¿Cómo cobran los proveedores de LLM? - los modelos de precios detrás de los números. Enrutamiento de modelos - enviar la solicitud correcta al modelo correcto. Arbitraje de proveedores - encontrar el modelo más barato que cumple tu umbral de calidad. Caché de prompts explicada - cómo conseguir aciertos de caché reales. ¿Quieres esto aplicado a tu propio gasto en LLM? FinOps LLM ejecuta una auditoría gratuita de tus costes de IA y muestra dónde están los ahorros. Reserva auditoría gratuita → Volver a investigación --- # Cómo auditar tu gasto en LLM en 30 minutos · FinOps LLM URL: https://finopsllm.com/es/research/how-to-audit-llm-spend Cómo auditar tu gasto en LLM en 30 minutos La mayoría de los equipos no saben cómo se desglosa su presupuesto de LLM. Los costes se ocultan detrás de paneles de proveedores que muestran totales pero no atribución, tipos de tokens que se facturan a tarifas distintas, y patrones de uso que cambian semana a semana. Esta guía te ofrece una auditoría estructurada que puedes ejecutar en media hora con herramientas que ya tienes. Paso 1 - Recopila datos de facturación de los proveedores Exporta los últimos 30 días de uso de cada proveedor de LLM que utilizas. Para OpenAI, usa la API de Usage o descarga el CSV desde el panel. Para Anthropic, extrae los datos de la API de Billing. Para Google, exporta desde la consola de Cloud Billing. Para modelos autoalojados, extrae los logs de solicitudes de tu servidor de inferencia. Guarda todo en una sola carpeta. Necesitas datos en bruto, no resúmenes. Paso 2 - Normaliza los recuentos de tokens entre proveedores Cada proveedor cuenta tokens de forma distinta. OpenAI y Anthropic usan sus propios tokenizadores; Google usa SentencePiece. Para comparar, convierte todas las cuentas a una unidad común. El enfoque más sencillo: usa el precio por token publicado de cada proveedor para calcular el coste por solicitud y luego compara costes directamente en lugar de recuentos de tokens brutos. Esto evita por completo la discrepancia de tokenizadores. Paso 3 - Divide por tokens de entrada, salida, caché y razonamiento Los proveedores cobran tarifas distintas según el tipo de token. Los tokens de entrada en caché suelen ser un 50% más baratos en OpenAI y Anthropic. Los tokens de razonamiento (en series o y modelos similares) pueden costar entre 2 y 4 veces los tokens de salida estándar. Divide tu gasto en cuatro categorías: entrada, salida, entrada en caché y razonamiento. Si tu proveedor no expone esta división, estímala a partir del tipo de modelo y el patrón de solicitud. Paso 4 - Atribuye a equipos y funcionalidades Asigna cada clave API o proyecto al equipo o funcionalidad que lo posee. Si no tienes separación a nivel de clave, usa metadatos de solicitud - cabeceras, etiquetas o el parámetro user que la mayoría de los proveedores soportan. El objetivo es una tabla: qué equipo gasta cuánto en qué funcionalidad. Sin esto, no puedes hacer a nadie responsable del coste. Paso 5 - Identifica los 3 principales impulsores de coste Ordena por gasto total descendente. En la mayoría de las organizaciones, el 80% del coste de LLM proviene de 3 a 5 patrones de uso. Impulsores comunes: un chatbot con ventanas de contexto largas, una funcionalidad de generación de código que usa modelos caros para todas las solicitudes, o un trabajo de enriquecimiento en segundo plano que se ejecuta en cada documento sin filtrar. Nómbralos. Aquí es donde enfocas el esfuerzo de optimización. Paso 6 - Calcula el coste por tarea para flujos clave Elige tus 3 flujos principales. Para cada uno, divide el gasto total por el número de tareas completadas. Esto te da un número de economía unitaria que puedes seguir a lo largo del tiempo. Un flujo de soporte al cliente que cuesta $0.12 por ticket es manejable. Uno que cuesta $1.40 por ticket necesita atención. El número absoluto importa menos que la tendencia y la comparación entre flujos. Paso 7 - Configura alertas para anomalías Configura alertas en dos niveles: gasto diario total (detecta trabajos descontrolados) y gasto por flujo (detecta desviación). La mayoría de los proveedores soportan alertas de facturación de forma nativa. Para alertas multi-proveedor, canaliza tus datos de uso a un panel o usa una herramienta como MiMO que agrega entre proveedores. Una regla simple: alerta si algún día supera el 150% de la media móvil de 7 días. Lista de verificación de auditoría rápida Paso Herramienta necesaria Tiempo estimado Resultado 1. Recopilar datos de facturación Paneles o APIs de proveedores 5 min CSV/JSON en bruto por proveedor 2. Normalizar tokens Hoja de cálculo o script 5 min Tabla de coste por solicitud 3. Dividir tipos de tokens APIs de proveedores con desglose de tokens 5 min División entrada/salida/caché/razonamiento 4. Atribuir a equipos Mapeo de claves API o metadatos 5 min Matriz de costes equipo-funcionalidad 5. Identificar impulsores principales Ordenación/hoja de cálculo 3 min Lista ordenada de patrones de coste 6. Coste por tarea Recuento de tareas de logs de aplicación 5 min Economía unitaria por flujo 7. Configurar alertas Alertas de facturación + panel 2 min Detección de anomalías activa Qué hacer después Esta auditoría te da una instantánea. El valor real viene de ejecutarla regularmente - semanalmente para equipos con alto gasto, mensualmente para todos los demás. Automatiza la recopilación de datos y convierte la métrica de coste por tarea en una métrica de producto de primera clase. Si quieres ayuda para construir esto en un proceso continuo, MiMO proporciona paneles multi-proveedor y atribución automatizada listos para usar. Relacionado Atribución de costes de LLM - análisis más profundo de patrones de atribución. Detección de anomalías de costes de LLM - estrategias de alertas automatizadas. Cómo presupuestar el gasto en IA - de la auditoría al presupuesto. ¿Quieres esto aplicado a tu propio gasto en LLM? FinOps LLM ejecuta una auditoría gratuita de tus costes de IA y muestra dónde están los ahorros. Reserva auditoría gratuita → Volver a investigación --- # Cómo usar Jev en un agente de IA · FinOps LLM URL: https://finopsllm.com/es/research/how-to-use-jev-in-an-agent Cómo usar Jev en un agente de IA Actualizado September 21, 2026 · publicado originalmente September 21, 2026 Respuesta rápida: Use Jev cuando un agente necesita elegir, puntuar, clasificar o bloquear una acción; no cuando necesita redactar. La integración más útil empieza con una decisión y un conjunto fijo de respuestas.... Use Jev cuando un agente necesita elegir, puntuar, clasificar o bloquear una acción; no cuando necesita redactar. La integración más útil empieza con una decisión y un conjunto fijo de respuestas. Entregue a Jev el estado disponible en el flujo, defina las opciones que su código puede manejar y actúe según la respuesta y su confianza. Vercel expone Jev como typesafe-ai/jev en AI Gateway y documenta su uso mediante la API experimental evaluate de AI SDK. Consulte la página del modelo para la forma actual de la llamada. 1. Empiece con una pregunta acotada Una buena primera pregunta tiene opciones finitas y una acción clara: «¿Qué equipo es propietario de este ticket: Facturación, Técnico, Ventas o Revisión?». «¿Qué deberíamos hacer?» pide planificación y no es una buena tarea para Jev. 2. Envíe estado y preguntas tipadas Incluya el ticket, los hechos de cuenta relevantes y el fragmento de política que necesita la decisión. Declare preguntas como una elección de equipo, una puntuación de urgencia o un booleano de evidencia suficiente. Todas comparten el mismo estado. 3. Haga que la confianza cambie la ruta Una clasificación de bajo riesgo y alta confianza puede continuar automáticamente. Un caso de confianza media puede pasar a un modelo más capaz con la misma evidencia. Un caso de alto impacto o baja confianza debe ir a revisión. Ajuste los umbrales por consecuencia, no con una regla global. 4. Mantenga la autoridad en el código El modelo evalúa el estado; el código valida argumentos, aplica permisos, limita reintentos y ejecuta herramientas. Guarde la versión del estado, la pregunta, la respuesta, la probabilidad, la ruta y el resultado final. Así podrá ajustar el umbral y calcular el coste por tarea resuelta. Relacionado Dónde encaja Jev en un flujo de agentes Seis casos de uso de Jev ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Seis casos de uso de Jev que sí encajan · FinOps LLM URL: https://finopsllm.com/es/research/jev-use-cases-that-fit Seis casos de uso de Jev que sí encajan Actualizado September 21, 2026 · publicado originalmente September 21, 2026 Respuesta rápida: Jev sirve cuando el sistema ya conoce sus posibles acciones siguientes. El modelo selecciona o puntúa entre ellas a partir de contexto desordenado. Esto deja una lista pequeña y útil de... Jev sirve cuando el sistema ya conoce sus posibles acciones siguientes. El modelo selecciona o puntúa entre ellas a partir de contexto desordenado. Esto deja una lista pequeña y útil de aplicaciones. 1. Enrutar trabajo antes de generar Elija el modelo, especialista o cola antes de pagar por una generación completa. Cada ruta tiene una acción y un coste conocidos. 2. Proteger una llamada de herramienta Entregue la acción propuesta, la política y el estado. Pregunte si es rutinaria, requiere confirmación o debe detenerse. El código valida permiso y argumentos. 3. Hacer triaje de soporte y operaciones Una llamada puede asignar propietario, puntuar urgencia y marcar evidencia insuficiente. Es más útil que una síntesis en prosa que otro sistema tiene que interpretar. 4. Puntuar riesgo antes de escalar Para revisión de transacciones, moderación, alertas de seguridad o excepciones documentales, Jev separa los casos claros de los que requieren investigación más lenta. 5. Seleccionar contexto para el siguiente paso Los agentes largos acumulan notas y resultados obsoletos. Jev puede clasificar qué hechos siguen siendo relevantes y si la tarea tiene evidencia suficiente para terminar. 6. Comprobar un resultado contra una rúbrica Después de que un LLM escriba una respuesta, Jev puede comprobar criterios concretos y decidir si continúa, necesita reparación o revisión. La rúbrica debe nombrar los campos requeridos, no preguntar simplemente si el resultado es bueno. Relacionado Cómo usar Jev en un agente de IA Dónde encaja Jev en un flujo de agentes ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Seguimiento de Precios API LLM · FinOps LLM URL: https://finopsllm.com/es/research/llm-api-pricing-tracker Seguimiento de Precios API LLM Actualizado 2 de septiembre de 2026 · publicado por primera vez el 4 de julio de 2026 Seguimiento de precios por token en todos los principales proveedores de LLM. Entrada, salida, lectura/escritura de caché, ventanas de contexto y descuentos por lotes en una tabla normalizada. Actualizado mensualmente con datos verificables de los proveedores. 12+ Proveedores rastreados 25+ Modelos listados 6 Columnas de precio Sep 2026 Última actualización Todos los precios en USD por 1 millón de tokens Valores estimados mostrados en gris Los precios de caché reflejan el caché de prompts donde está disponible Metodología Recopilación Datos de precios recopilados de las páginas oficiales de precios y documentación de API de los proveedores. Normalización Todos los precios normalizados a USD por 1 millón de tokens para comparación directa. Precios de caché Las columnas de Lectura/Escritura de caché muestran descuentos de caché de prompts donde los proveedores los admiten. Política de visualización Los valores oficiales y estimados están claramente separados. Las estimaciones se marcan en gris. Historial de Actualizaciones 4 jul 2026 Seguimiento de Precios API LLM lanzado Publicada la comparación de precios por token en más de 12 proveedores principales de LLM como artículo de investigación de FinOps LLM. Tabla de Precios por Token Proveedor ↕ Modelo ↕ Entrada $/1M ↕ Salida $/1M ↕ Lectura Caché $/1M ↕ Escritura Caché $/1M ↕ Ventana de Contexto ↕ Descuento por Lotes OpenAI GPT-5.6-Sol $4.00 $20.00 $0.40 $5.00 1.05M 50% OpenAI GPT-5.6-Terra $2.00 $12.00 $0.20 $2.50 1.05M 50% OpenAI GPT-5.6-Luna $0.20 $1.20 $0.02 $0.25 1.05M 50% Anthropic Claude Fable 5.1 $10.00 $50.00 $0.25 $12.50 1M 50% Anthropic Claude Fable 5 $10.00 $50.00 $1.00 $12.50 1M 50% Anthropic Claude Opus 5 $5.00 $25.00 $0.50 $6.25 1M 50% Anthropic Claude Sonnet 5 * $2.00 $10.00 $0.20 $2.50 1M 50% Anthropic Claude Sonnet 4.6 $3.00 $15.00 $0.30 $3.75 1M 50% Anthropic Claude Haiku 4.5 $1.00 $5.00 $0.10 $1.25 200K 50% Google Gemini 3.5 Flash $1.50 $9.00 $0.15 $1.88 1M 50% Google Gemini 3.1 Pro Preview $2.00 $12.00 $0.20 $2.50 1M 50% Google Gemini 2.5 Pro $1.25 $5.00 $0.31 $4.50 1M 50% Google Gemini 2.5 Flash $0.15 $0.60 $0.04 $0.15 1M 50% xAI Grok 4.5 $2.00 $6.00 $0.50 $1.50 1M 50% xAI Grok 4.3 $1.25 $2.50 - - 1M 50% Meta Llama 4 Maverick (DeepInfra) $0.20 $0.80 - - 1M - Meta Llama 4 Scout (Groq) $0.11 $0.34 - - 5M - Meta Llama 3.3 70B (Groq) $0.59 $0.79 - - 8M - Mistral Mistral Large 2/3 $2.00 $6.00 - - 128K - Mistral Mistral Medium 3.5 $1.50 $7.50 - - 128K - Mistral Mistral Small 3 $0.10 $0.30 - - 128K - Mistral Codestral $0.30 $0.90 - - 128K - DeepSeek DeepSeek V4 Flash $0.14 $0.28 $0.0028 - 128K - DeepSeek DeepSeek V4 Pro $0.435 $0.87 $0.0036 - 128K - Alibaba Qwen Qwen 3.7-Max $2.50 $7.50 - - 131K - Moonshot Kimi Kimi K2.6 $0.95 $4.00 $0.16 - 200K - Xiaomi MiMO Regístrate - ambos obtienen $2 ↗ MiMo-V2-Pro $0.50 $2.00 - - 128K - Xiaomi MiMO Regístrate - ambos obtienen $2 ↗ MiMo-V2-Omni $0.40 $1.60 - - 128K - Zhipu AI GLM-5 $1.00 $4.00 - - 128K - Zhipu AI GLM-5-Turbo $0.30 $1.20 - - 128K - MiniMax M2.7 $0.40 $1.60 - - 128K - StepFun step-3.5-flash $0.30 $1.20 - - 128K - * Claude Sonnet 5 cuesta $2/$10 por 1M tokens de forma permanente: el aumento a $3/$15 previsto para el 1 de septiembre de 2026 fue cancelado. Las cifras de escritura en caché corresponden al TTL de 5 minutos; el TTL de 1 hora cuesta 2× la tarifa base de entrada. Claude Opus 4.8, 4.7 y 4.6 comparten el precio de Claude Opus 5. Claude 4.7 y posteriores usan un tokenizador que genera un 30% más de tokens para el mismo texto, así que compara el coste por tarea, no por token. Los valores no proporcionados explícitamente por los proveedores se muestran en gris . Los precios de Meta Llama reflejan precios de API alojada (Fireworks, Together, etc.), no el coste de autoalojamiento. La economía del autoalojamiento se cubre en nuestra Comparación de Costes Open-Source vs Closed-Source . Las ventanas de contexto son las máximas admitidas; la disponibilidad real puede variar según el nivel. Los precios de Lectura/Escritura de caché reflejan el caché de prompts específico del proveedor donde está disponible. "-" significa que el proveedor no ofrece caché o el precio no está publicado. El Descuento por Lotes muestra el ahorro aproximado al usar APIs por lotes/asíncronas donde están disponibles. Algunos enlaces pueden incluir códigos de referido. Los precios pueden cambiar frecuentemente. Siempre verifica la información más reciente en las páginas oficiales de los proveedores. Guía Práctica Cómo usar estos datos de precios para la planificación de costes 1) Calcula primero tu volumen de tokens Antes de comparar precios, estima tus volúmenes mensuales de tokens de entrada y salida. Los tokens de salida suelen ser 3-5x más caros que los de entrada, por lo que reducir la longitud de salida tiene el mayor impacto en el coste. 2) Ten en cuenta los ahorros de caché Si tu carga de trabajo tiene prompts de sistema o contexto repetidos (RAG, conversaciones de múltiples turnos), el caché de prompts puede reducir los costes de entrada en un 50-90%. Consulta la columna de Lectura de Caché para los descuentos aplicables. 3) Usa APIs por lotes para trabajo no urgente La mayoría de los proveedores principales ofrecen descuentos del 50% en llamadas de API por lotes/asíncronas. Si tu carga de trabajo tolera latencia (evaluaciones, procesamiento de datos, generación de contenido), los precios por lotes reducen los costes a la mitad. 4) Compara el coste total, no solo el precio por token Un modelo barato que necesita 3x más tokens para igualar la calidad puede costar más en total. Ten en cuenta la calidad del modelo y el rendimiento específico de la tarea junto con los precios brutos. ¿Quieres esto aplicado a tu propio gasto en LLM? FinOps LLM realiza una auditoría gratuita de tus costes de IA y muestra dónde están los ahorros. Reserva auditoría gratuita → Volver a investigación --- # Tu factura de LLM tiene riesgo de divisa · FinOps LLM URL: https://finopsllm.com/es/research/llm-bill-fx-exposure Exposición a divisa en el gasto de LLM Actualizado September 1, 2026 · publicado originalmente September 1, 2026 Respuesta rápida: Casi todos los modelos frontera se tarifan en dólares. Si tu presupuesto no está en dólares, parte de tu coste de LLM es una posición de divisa que nunca decidiste tomar.Un movimiento del 6% en... Casi todos los modelos frontera se tarifan en dólares. Si tu presupuesto no está en dólares, parte de tu coste de LLM es una posición de divisa que nunca decidiste tomar. Un movimiento del 6% en EUR/USD es un 6% más de coste sin que cambie el volumen de tokens ni el modelo, y sin nada en el panel de uso que lo explique. Finanzas ve la desviación; ingeniería, que mira tokens, ve un mes plano y no puede ayudar. Por qué se esconde tan bien Hay tres capas de conversión entre la llamada y el libro mayor: el precio del proveedor en USD, la conversión de la tarjeta o factura con su spread, y el tipo al que lo contabiliza tu ERP. Al llegar al informe, la parte de divisa y la de uso son la misma cifra. Comprar por un marketplace en moneda local no elimina la exposición: mueve la conversión aguas arriba y le añade margen. Separa las dos desviaciones Registra el coste de cada petición en USD a tarifa de lista como cifra primaria en telemetría, y convierte una sola vez, a un tipo declarado, en el informe. Así la desviación mensual se parte limpiamente: una parte de uso, que ingeniería puede corregir, y una de divisa, que es de tesorería. Cuándo cubrirse Pocas veces, y solo a escala. Para la mayoría la respuesta correcta es visibilidad, no cobertura. Relacionado Puente de desviación del gasto en IA ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Chargeback y showback de LLM · FinOps LLM URL: https://finopsllm.com/es/research/llm-chargeback-showback Chargeback y showback de LLM Showback (visibilidad de costes) reporta el gasto de LLM a los equipos y productos que lo causaron. Chargeback (imputación de costes) asigna ese gasto a sus presupuestos. La mayoría de organizaciones deberían comenzar con showback porque los equipos necesitan tiempo para confiar en los números antes de que esos números afecten las decisiones presupuestarias. El desafío es la precisión de la atribución. Una factura simple del proveedor no puede decirte qué feature, inquilino o equipo produjo un token. Necesitas metadatos de solicitud del gateway, aplicación o capa de orquestación. Sin esos metadatos, chargeback se convierte en una discusión política en lugar de un sistema operativo. Buenos reportes de showback Desglosar el gasto por área de producto y propietario del equipo. Mostrar las cargas de trabajo principales y cambios mes a mes. Separar cambios de precio del modelo del crecimiento del tráfico. Identificar candidatos de optimización propiedad de cada equipo. Mantener visible el gasto no asignado. Cuándo hacer chargeback Chargeback tiene sentido una vez que la cobertura de atribución es alta y los equipos pueden influir en los factores de coste. No cargues a los equipos por infraestructura compartida sin etiquetar, tablas de precios obsoletas, o decisiones de plataforma central que no pueden cambiar. Un modelo sólido usa showback para educación, luego chargeback para centros de coste maduros. También protege presupuestos de experimentación para que los equipos no eviten características de IA útiles simplemente porque el tráfico inicial es difícil de predecir. Relacionado Gobernanza del presupuesto de LLM - presupuestos y guardrails. Atribución de costes de LLM - fundamentos de asignación. ¿Qué es FinOps LLM? - la disciplina operativa completa. ¿Quieres que esto se aplique a tu propio gasto de LLM? FinOps LLM realiza una auditoría gratuita de tus costes de IA y muestra dónde están los ahorros. Solicita tu auditoría gratuita → Volver a la investigación --- # Atribución de costes de LLM · FinOps LLM URL: https://finopsllm.com/es/research/llm-cost-attribution Atribución de costes de LLM La atribución de costes de LLM es el puente entre las facturas del proveedor y las decisiones operacionales. Los proveedores facturan por cuenta, modelo, clase de token y a veces por región o funcionalidad. Las empresas necesitan entender el gasto por equipo, producto, cliente, flujo de trabajo y unidad de valor. La capa de atribución conecta esas dos vistas sin perder la conciliación con la factura bruta. La clave es etiquetar las solicitudes antes de que lleguen al proveedor o gateway. Los registros creados después del hecho generalmente son incompletos. Como mínimo, cada llamada LLM en producción debe llevar un nombre de endpoint estable, entorno, propietario del equipo, superficie del producto, clase de carga de trabajo e ID de correlación. Donde los contratos lo permitan, añade ID de inquilino o cliente. Para flujos de trabajo de agentes, etiqueta cada llamada de herramienta o paso del modelo por separado. El recuento de solicitudes no es atribución Asignar gasto por recuento de solicitudes es casi siempre incorrecto. Una solicitud de razonamiento de contexto largo puede costar más que cientos de llamadas de clasificación corta. La atribución necesita clases de token y precios de modelo. También necesita datos de reintentos y fallbacks, porque una respuesta "exitosa" puede ocultar tres llamadas fallidas anteriores. Dimensiones recomendadas Proveedor, modelo y versión del modelo donde esté disponible. Clases de token de entrada, salida, escritura de caché, lectura de caché y razonamiento. Equipo, producto, funcionalidad, endpoint y entorno. Clase de carga de trabajo: ruta de usuario en tiempo real, trabajo en background, evaluación, enriquecimiento, paso de agente, flujo de trabajo de soporte o tarea de análisis. Atribución de cliente o inquilino cuando lo permitan los límites de privacidad y contrato. Conciliación de factura La atribución debe conciliar de vuelta con la factura del proveedor. Espera pequeñas diferencias por redondeo, líneas de factura demoradas y descuentos específicos del proveedor, pero grandes brechas significan que el pipeline de registros está perdiendo tráfico o usando tablas de precios obsoletas. La vista de finanzas debe mostrar tanto gasto asignado como no asignado para que los problemas de calidad de datos sean visibles. De showback a acción El primer resultado debe ser showback: qué equipos y superficies de producto están impulsando el gasto, y qué cargas de trabajo cambiaron desde el mes pasado. Una vez que los equipos confíen en esos datos, úsalos para clasificar el trabajo de optimización. La atribución es valiosa porque señala directamente a los propietarios que pueden aprobar enrutamiento, caché o cambios de prompts. Relacionado Atribución de costes de OpenAI - patrones de atribución específicos de OpenAI. Chargeback y showback de LLM - trasladar costes a los propietarios. ¿Qué es FinOps de LLM? - la disciplina operacional completa. ¿Deseas aplicar esto a tu propio gasto en LLM? FinOps LLM realiza una auditoría gratuita de tus costes en IA y muestra dónde están los ahorros. Solicita tu auditoría gratuita → Volver a la investigación --- # Calculadora de Costes LLM - Estima Tu Gasto Mensual en IA · FinOps LLM URL: https://finopsllm.com/es/research/llm-cost-calculator Calculadora de Costes LLM Actualizado 15 de julio de 2026 Estima tu gasto mensual en LLMs entre modelos populares. Introduce tu patrón de uso a continuación y compara los costes lado a lado. Todos los precios son por millón de tokens a julio de 2026. Costes precalculados por nivel de uso Así es lo que cuesta cada nivel de uso por mes en modelos populares, basado en patrones de solicitud típicos: Modelo Ligero (1K req/mes) Medio (10K req/mes) Intensivo (100K req/mes) GPT-5.6-Sol $8.75 $87.50 $875.00 GPT-5.6-Terra $4.38 $43.75 $437.50 GPT-5.6-Luna $1.75 $17.50 $175.00 Claude Fable 5 $17.50 $175.00 $1,750.00 Claude Opus 4.8 $8.75 $87.50 $875.00 Claude Sonnet 5 $3.50 $35.00 $350.00 Claude Haiku 4.5 $1.75 $17.50 $175.00 Gemini 3.5 Flash $2.63 $26.25 $262.50 Grok 4.5 $4.00 $40.00 $400.00 DeepSeek V4 Pro $0.95 $9.50 $95.00 Kimi K2.6 $1.70 $17.00 $170.00 Ligero: 1K solicitudes/mes, 500 entrada + 200 tokens de salida. Medio: 10K solicitudes/mes, 1,000 entrada + 500 tokens de salida. Intensivo: 100K solicitudes/mes, 2,000 entrada + 1,000 tokens de salida. Calculadora interactiva Modelo GPT-5.6-Sol ($5.00 / $30.00) GPT-5.6-Terra ($2.50 / $15.00) GPT-5.6-Luna ($1.00 / $6.00) Claude Fable 5 ($10.00 / $50.00) Claude Opus 4.8 ($5.00 / $25.00) Claude Sonnet 5 ($2.00 / $10.00) Claude Haiku 4.5 ($1.00 / $5.00) Gemini 3.5 Flash ($1.50 / $9.00) Grok 4.5 ($2.00 / $6.00) DeepSeek V4 Pro ($0.435 / $0.87) Kimi K2.6 ($0.95 / $4.00) Solicitudes por mes Tokens de entrada promedio por solicitud Tokens de salida promedio por solicitud Calcular coste Cómo usar esta calculadora Elige tu modelo del desplegable. Los precios reflejan tarifas API estándar a julio de 2026. Introduce tu volumen de solicitudes - cuántas llamadas API haces al mes. Estima el recuento de tokens - el número promedio de tokens de entrada y salida por solicitud. Si no estás seguro, empieza con 1,000 entrada / 500 salida para chat, o 3,000 entrada / 1,000 salida para generación de código. Pulsa Calcular para ver tu coste mensual estimado dividido por entrada y salida. Cómo reducir tu estimación Usa caché de prompts. Si tus prompts tienen un prefijo estable, las lecturas de caché pueden reducir los costes de entrada en un 50–90%. Ver caché de prompts explicada . Cambia de modelo por tarea. Encamina consultas simples a modelos más baratos y reserva los caros para tareas complejas. Esto es el enrutamiento de modelos . Usa APIs por lotes. Las cargas de trabajo no urgentes pueden usar precios por lotes con 50% de descuento. Prueba proveedores más baratos. MiMO y DeepSeek ofrecen tarifas significativamente más bajas para calidad comparable en muchas tareas. Relacionado ¿Cuánto cuesta GPT-5? - desglose detallado de precios de GPT-5. ¿Cómo cobran los proveedores de LLM? - entender la facturación basada en tokens. La forma más barata de ejecutar generación de código con IA - comparación de costes para herramientas de codificación. Arbitraje de proveedores - encontrar el modelo más barato que cumple tu umbral de calidad. ¿Quieres esto aplicado a tu propio gasto en LLM? FinOps LLM ejecuta una auditoría gratuita de tus costes de IA y muestra dónde están los ahorros. Reserva auditoría gratuita → Volver a investigación --- # Runbook de producción para un pico de costes LLM · FinOps LLM URL: https://finopsllm.com/es/research/llm-cost-spike-runbook Runbook de producción para un pico de costes LLM Actualizado August 27, 2026 · publicado originalmente August 27, 2026 Respuesta rápida: Ante un pico, conserva las pruebas, confirma la señal de facturación y separa volumen, tarifa, mezcla y eficiencia antes de cambiar el modelo.Primeros 15 minutosGuarda factura, tráfico, mezcla, tipos... Ante un pico, conserva las pruebas, confirma la señal de facturación y separa volumen, tarifa, mezcla y eficiencia antes de cambiar el modelo. Primeros 15 minutos Guarda factura, tráfico, mezcla, tipos de token, reintentos y despliegues recientes. Compara facturación con telemetría del gateway. Contención Usa el control más estrecho: pausa un flujo, limita un agente, enruta batch o desactiva una función nueva. Protege tráfico crítico. Define dueño, caducidad y rollback. Causa y cierre Revisa volumen, mezcla, contexto, herramientas, fallos y tarifas. Compara coste por tarea exitosa con la línea base. Documenta tiempo, dólares, causa y acción permanente. Relacionado Monitoreo de costes LLM ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Tendencias de costes de LLM 2025–2026 · FinOps LLM URL: https://finopsllm.com/es/research/llm-cost-trends-2025-2026 Tendencias de costes de LLM 2025–2026 Actualizado 15 de julio de 2026 · publicado por primera vez 4 de julio de 2026 El mercado de LLM se mueve en dos direcciones a la vez. Los precios de tokens de entrada y salida para modelos de clase GPT-4 han caído un 80–90% desde principios de 2024. Al mismo tiempo, los modelos de razonamiento (o1, o3, DeepSeek-R1, Claude Opus 4) son 5–30x más caros por tarea que sus equivalentes sin razonamiento. El efecto neto: los equipos que adoptan modelos de razonamiento ven subir sus facturas incluso cuando los precios unitarios bajan. Este artículo rastrea los eventos clave de precios y calidad desde 2025 hasta mediados de 2026, explica las fuerzas que impulsan los costes y pronostica qué esperar en el segundo semestre de 2026. Tendencia clave 1: Los modelos de clase GPT-4 bajaron un 90% en 18 meses En marzo de 2024, GPT-4-turbo costaba $10 por millón de tokens de entrada y $30 por millón de tokens de salida. Para mediados de 2026, GPT-4.1 cuesta $2 por millón de entrada y $8 por millón de salida: una caída del 75–80%. Claude siguió una trayectoria similar: Claude 3 Opus a $15/$75 bajó a Claude Sonnet 4 a $3/$15. Los modelos de pesos abiertos de Mistral, Llama y DeepSeek empujaron los precios aún más abajo, con algunos disponibles por menos de $0,50 por millón de tokens de entrada a través de proveedores alojados. Esto no es solo una guerra de precios. La infraestructura de inferencia mejoró: cuantización, decodificación especulativa, optimización de KV-cache y procesamiento por lotes redujeron el coste de servir un token. Los proveedores trasladaron parte de esos ahorros a los clientes. Tendencia clave 2: Los modelos de razonamiento son 5–30x más caros Los modelos de razonamiento (o1, o3, o4-mini, DeepSeek-R1, Claude Opus 4 con pensamiento extendido) generan tokens de "pensamiento" internos antes de producir una respuesta final. Estos tokens de pensamiento se facturan como tokens de salida. Un modelo de razonamiento resolviendo una tarea de codificación puede generar 10K–50K tokens de pensamiento antes de producir una respuesta de 2K tokens. El coste efectivo por tarea es por lo tanto mucho más alto de lo que el precio por token sugiere. Para equipos que usan modelos de razonamiento para cada tarea, este es el mayor factor de coste en 2026. La pregunta clave no es "¿cuánto cuesta el modelo?" sino "¿esta tarea necesita razonamiento?" La mayoría no lo necesita. Tendencia clave 3: El código abierto cerró la brecha de calidad A principios de 2024, los modelos de pesos abiertos quedaban significativamente por detrás de los modelos propietarios en benchmarks de codificación y razonamiento. Para mediados de 2026, modelos como Llama 4 Maverick, DeepSeek-V3, Qwen 3 y MiMo están a pocos puntos del rendimiento de clase GPT-4 en la mayoría de benchmarks. Esto importa para el coste porque los modelos de pesos abiertos son más baratos de servir: los proveedores que compiten en precio los usan para reducir los precios propietarios. La brecha de calidad no se ha cerrado completamente para tareas de razonamiento fronterizo. Pero para la mayoría de las cargas de trabajo de producción: resumen, extracción, clasificación, generación de código, uso de herramientas, los modelos de pesos abiertos son lo suficientemente buenos y significativamente más baratos. Tendencia clave 4: El caché redujo los costes efectivos un 50–90% para cargas de trabajo repetitivas El caché de prompts (Anthropic) y el caché automático de contexto (OpenAI, Google) cambiaron la economía de las cargas de trabajo repetitivas. Si envías el mismo prompt de sistema y contexto a un modelo 100 veces al día, las lecturas cacheadas cuestan un 50–90% menos que las lecturas sin caché. Para pipelines de RAG, sistemas de agentes y procesamiento por lotes, esto es transformador. Los beneficios del caché se distribuyen de forma desigual. Las cargas de trabajo con contexto estable (mismo prompt de sistema, mismo conjunto de documentos) se benefician enormemente. Las cargas de trabajo con contexto dinámico (conversaciones específicas del usuario, datos en tiempo real) se benefician menos. Los equipos de FinOps deben medir su tasa de acierto de caché y optimizar la estabilidad del contexto para maximizar los ahorros. Tendencia clave 5: Los flujos de trabajo de agentes multiplican el consumo de tokens Los flujos de trabajo de agentes, donde los modelos llaman a herramientas, leen archivos, ejecutan código e iteran sobre resultados, consumen 5–50x más tokens por tarea que las interacciones de un solo turno. Un agente de codificación resolviendo un bug puede consumir 100K–500K tokens a través de sus llamadas a herramientas, reintentos y acumulación de contexto. Un prompt equivalente de un solo turno podría usar 2K–5K tokens. Esta es la tendencia de coste más importante en 2026. Los precios de tokens están cayendo, pero el consumo de tokens por tarea está subiendo más rápido. Resultado neto: el gasto total en LLM está subiendo para la mayoría de equipos incluso cuando los precios unitarios bajan. Línea temporal: eventos clave Fecha Evento Impacto en precio Impacto en calidad Mar 2024 Lanzamiento de GPT-4-turbo 50% más barato que GPT-4 Calidad comparable Jun 2024 Lanzamiento de Claude 3.5 Sonnet 5x más barato que Opus Casi calidad Opus Sep 2024 Lanzamiento de o1-preview 3–5x más por tarea (razonamiento) Gran salto en razonamiento Dic 2024 Google Gemini 2.0 Flash Menos de $1/M tokens de entrada Fuerte para tareas de velocidad Ene 2025 DeepSeek-R1 código abierto 10x más barato que o1 Razonamiento cercano a o1 Feb 2025 Reducción de precio Claude 3.5 Sonnet Caída adicional del 20% Misma calidad Abr 2025 Lanzamiento de GPT-4.1 30% más barato que GPT-4-turbo Codificación mejorada May 2025 Lanzamiento de Claude Sonnet 4 Mismo precio, mejor calidad Gran salto en codificación Jun 2025 Reducción de precio OpenAI o3-mini Razonamiento 50% más barato Misma calidad Ene 2026 DeepSeek-V3 en proveedores alojados Menos de $0,50/M tokens de entrada Casi clase GPT-4 Abr 2026 Lanzamiento de Claude Opus 4 Precio premium ($15/$75) Razonamiento fronterizo Jun 2026 Llama 4 Maverick alojado Menos de $0,30/M tokens de entrada Calidad general fuerte Jul 2026 Lanzamiento de Anthropic Fable 5 / OpenAI GPT-5.6 Nuevo nivel fronterizo ($5/$30), fijación de precios de nivel medio ($2.50/$15), nivel económico ($1/$6) Fable 5 igualó rendimiento Opus 4 Qué esperar en el segundo semestre de 2026 Los precios de modelos de razonamiento caerán un 30–50%. La competencia de modelos de razonamiento de código abierto (DeepSeek-R2, variantes de razonamiento Qwen 3) forzará a los proveedores propietarios a recortar precios en sus niveles de razonamiento. Surgirá pricing específico para agentes. Los proveedores están probando modelos de precios por tarea y por sesión que agrupan llamadas a herramientas, reintentos y contexto en un solo coste predecible. Espera que al menos un proveedor importante ofrezca esto para el Q4 de 2026. El caché se volverá automático. La gestión manual de caché desaparecerá. Los proveedores optimizarán la ubicación del caché de forma transparente y las tasas de acierto de caché mejorarán para la mayoría de cargas de trabajo sin intervención del desarrollador. Los modelos de pesos abiertos dominarán el trabajo rutinario. Para finales de 2026, espera que más del 70% de la inferencia de producción en tareas rutinarias (clasificación, extracción, resumen, generación simple de código) se ejecute en modelos de pesos abiertos a través de proveedores alojados. El gasto total seguirá subiendo. A pesar de la caída de precios unitarios, los flujos de trabajo impulsados por agentes y la expansión de casos de uso de IA significan que el gasto total en LLM seguirá creciendo. La disciplina FinOps, no solo modelos más baratos, es lo que mantiene el gasto bajo control. Relacionado Economía de agentes - cómo se calculan los precios de los agentes de codificación en la práctica. Arbitraje de proveedores - cambiar de proveedor para reducir costes. Enrutamiento de modelos - enviar tareas al modelo correcto. FinOps para LLM - el marco más amplio. ¿Quieres que esto se aplique a tu propio gasto en LLM? FinOps LLM ejecuta una auditoría gratuita de tus costes en IA y muestra dónde están los ahorros. Solicita tu auditoría gratuita → Volver a la investigación --- # Impacto en costes de servidores MCP · FinOps LLM URL: https://finopsllm.com/es/research/mcp-server-cost-impact Impacto en costes de servidores MCP El Protocolo de Contexto de Modelo (MCP) permite a los LLM llamar a herramientas externas: bases de datos, APIs, sistemas de archivos, motores de búsqueda. Es potente. También es caro. Cada definición de herramienta MCP consume espacio en la ventana de contexto, cada llamada a herramienta es un viaje de ida y vuelta a la API por separado, y cada resultado de herramienta se devuelve al modelo como tokens de entrada adicionales. Para equipos que ejecutan flujos de trabajo de agentes intensivos en MCP, la sobrecarga relacionada con herramientas puede representar el 30–60% del gasto total en tokens. Este artículo explica cómo MCP incrementa los costes, cómo medir la sobrecarga y qué hacer al respecto. Cómo MCP consume tokens Hay tres capas de coste en tokens en cada interacción MCP: Capa 1: Definiciones de herramientas. Cada servidor MCP registra herramientas con el modelo. Una definición de herramienta incluye el nombre de la función, el esquema de parámetros y una descripción de lo que hace la herramienta. Una definición de herramienta típicamente consume 500–2.000 tokens. Un servidor con 15 herramientas añade 7,5K–30K tokens a cada solicitud, incluso si no se llama a ninguna de esas herramientas. Capa 2: Solicitudes de llamada a herramientas. Cuando el modelo decide llamar a una herramienta, genera una salida de llamada a herramienta (nombre de función + argumentos). Esto se factura como tokens de salida. Luego el resultado de la herramienta vuelve como tokens de entrada. Un solo viaje de ida y vuelta de llamada a herramienta típicamente cuesta 1K–5K tokens dependiendo del tamaño del resultado. Capa 3: Resultados de herramientas en contexto. Los resultados de herramientas permanecen en el contexto de la conversación para todos los turnos posteriores. Si llamas a 10 herramientas en una sesión, esos resultados se acumulan. Una consulta a base de datos que devuelve 50 filas de JSON puede añadir 8K–15K tokens que persisten durante el resto de la conversación. El efecto compuesto Los costes de MCP se componen porque las definiciones de herramientas se envían con cada solicitud. Si tienes 20 herramientas definidas (10K–40K tokens de definiciones) y haces 5 solicitudes en una conversación, solo las definiciones de herramientas cuestan 50K–200K tokens de entrada. Añade los resultados de las llamadas a herramientas y fácilmente puedes duplicar tu consumo base de tokens. Patrón MCP Sobrecarga en tokens Frecuencia Impacto mensual en costes (estimación) Definiciones de herramientas (10 herramientas) 5K–20K tokens por solicitud Cada solicitud $15–$60 por usuario Viaje de ida y vuelta de una llamada a herramienta 1K–5K tokens 3–10 por sesión $5–$25 por usuario Resultado grande de herramienta (consulta DB, búsqueda de código) 5K–20K tokens 1–5 por sesión $10–$50 por usuario Resultados acumulados en sesión larga 20K–100K tokens 1–3 sesiones/día $30–$120 por usuario Definiciones de herramientas no usadas cargadas 5K–30K tokens por solicitud Cada solicitud $15–$90 por usuario Cómo medir la sobrecarga de MCP La forma más simple de medir el coste de MCP es ejecutar el mismo prompt dos veces: una con herramientas MCP cargadas y otra sin ellas. La diferencia en tokens de entrada es tu sobrecarga de definiciones de herramientas. Luego cuenta los tokens de llamadas a herramientas por separado: la mayoría de proveedores los etiquetan distintamente en sus paneles de facturación. Para una medición más precisa, instrumenta tu cliente MCP para registrar: número de herramientas registradas, tokens consumidos por definiciones de herramientas por solicitud, número de llamadas a herramientas por sesión, tokens por resultado de herramienta y tokens totales de sesión atribuidos a actividad de herramientas. Estrategias para reducir los costes de MCP 1. Carga herramientas selectivamente. No registres todas las herramientas para cada solicitud. Si el usuario está haciendo una pregunta de código, no necesita herramientas de base de datos o despliegue cargadas. Muchos clientes MCP soportan carga dinámica de herramientas basada en contexto o activación explícita del usuario. 2. Minimiza las descripciones de herramientas. Las descripciones de herramientas son el mayor consumidor de tokens en las definiciones. Una descripción verbosa puede ser 500 tokens; una concisa puede ser 100 tokens. En 20 herramientas, eso es una diferencia de 8K tokens por solicitud. 3. Trunca los resultados de herramientas. Devuelve solo los campos que el modelo realmente necesita. Si una consulta a base de datos devuelve 20 columnas pero el modelo solo necesita 3, proyecta el resultado. Limita el tamaño del resultado a un límite razonable: 2K–4K tokens es generalmente suficiente para que el modelo tome una decision. 4. Cachea llamadas repetidas. Si la misma herramienta se llama con los mismos argumentos en una sesión, devuelve el resultado cacheado en lugar de ejecutar de nuevo. Esto es especialmente valioso para búsquedas de referencia, consultas de esquema y obtención de documentación. 5. Resume antes de inyectar. Para resultados grandes de herramientas (contenido completo de archivos, respuestas largas de API), resume antes de añadir al contexto. Devuelve un resumen más la opción de obtener el resultado completo si el modelo lo necesita. 6. Usa límites de presupuesto para resultados de herramientas. Establece un presupuesto por sesión para tokens de resultados de herramientas. Cuando se alcanza el presupuesto, rechaza más llamadas a herramientas o cambia a un modelo más barato para el resto de la sesión. El coste oculto de los servidores MCP Más allá de los costes en tokens, los servidores MCP introducen sobrecarga de latencia y fiabilidad. Una llamada a herramienta que tarda 3 segundos en responder añade latencia a cada turno. Una herramienta que falla intermitentemente causa reintentos. Ambos aumentan el coste efectivo por tarea. Para equipos que escalan el uso de MCP en una organización, rastrear estos costes a nivel de servidor es esencial. Enruta las cargas de trabajo intensivas en MCP a modelos con costes por token más bajos, y mantén los flujos de trabajo ligeros en MCP en modelos premium donde la latencia importa. Relacionado Economía de agentes - cómo se calculan los precios de los agentes de codificación en la práctica. Atribución del gasto de agentes - rastreo de costes de agentes por proyecto. Seguimiento de tokens de LLM - medición de lo que gastas. FinOps para LLM - el marco más amplio. ¿Quieres que esto se aplique a tu propio gasto en LLM? FinOps LLM ejecuta una auditoría gratuita de tus costes en IA y muestra dónde están los ahorros. Solicita tu auditoría gratuita → Volver a la investigación --- # Controlar el coste de tokens de esquemas MCP · FinOps LLM URL: https://finopsllm.com/es/research/mcp-tool-definition-overhead Controlar el coste de tokens de esquemas MCP en agentes Actualizado September 19, 2026 · publicado originalmente September 19, 2026 Respuesta rápida: Conectar un agente de IA a múltiples servidores Model Context Protocol (MCP) introduce miles de tokens de entrada en cada turno antes de procesar la petición del usuario. Cada herramienta registrada... Conectar un agente de IA a múltiples servidores Model Context Protocol (MCP) introduce miles de tokens de entrada en cada turno antes de procesar la petición del usuario. Cada herramienta registrada añade un esquema JSON con nombres de funciones, descripciones de parámetros y tipos. En entornos con varios servidores MCP (GitHub, Postgres, Slack, Jira), esta cabecera estática consume entre 4.500 y 12.000 tokens por llamada. En flujos de 30 turnos, esto representa un gasto continuo innecesario. Por qué las definiciones de herramientas MCP consumen tantos tokens Cada herramienta MCP necesita metadatos detallados en formato JSON Schema para que el modelo identifique cómo invocarla. Un esquema complejo de base de datos puede costar 500 tokens por sí solo. Al sumar decenas de herramientas, gran parte de la ventana de contexto se llena con contratos estáticos. Estrategias de optimización Para mitigar este impacto, los equipos de plataforma implementan puntos de corte de caché de prompts (prefix caching) justo tras el bloque de herramientas, enrutamiento dinámico en dos fases para inyectar únicamente las 3 o 4 herramientas relevantes para la tarea, y minificación estricta de esquemas. Relacionado Herramientas de servidor y costes ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Las rebajas de modelos no bajan la factura solas · FinOps LLM URL: https://finopsllm.com/es/research/model-price-cuts-routing-budget Rebajas de modelos y el presupuesto de enrutamiento Actualizado September 10, 2026 · publicado originalmente September 10, 2026 Respuesta rápida: Los precios por token caen, pero la factura total suele mantenerse si el tráfico no se mueve a los nuevos modelos o se expande el contexto sin control. Los precios por token caen, pero la factura total suele mantenerse si el tráfico no se mueve a los nuevos modelos o se expande el contexto sin control. Relacionado Coste por tarea exitosa ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Los filtros de seguridad son otra factura · FinOps LLM URL: https://finopsllm.com/es/research/moderation-pass-second-bill Lo que cuestan los guardrails y la moderación Actualizado September 1, 2026 · publicado originalmente September 1, 2026 Respuesta rápida: Una función LLM en producción casi nunca hace una sola llamada. Hace la que diseñaste y luego las que añadiste por seguridad: clasificador de entrada, revisión de salida, juez de política, a veces un... Una función LLM en producción casi nunca hace una sola llamada. Hace la que diseñaste y luego las que añadiste por seguridad: clasificador de entrada, revisión de salida, juez de política, a veces un segundo modelo calificando al primero. Todo eso es inferencia, y la inferencia se factura. El multiplicador es mayor de lo que parece La moderación de entrada lee toda la entrada. La de salida lee toda la respuesta. Un juez lee ambas más el contexto recuperado y una rúbrica — con lo que la llamada del juez es mayor que la que juzga. Dónde se acumula el gasto Tres patrones: juzgar con un modelo frontera por comodidad (la clasificación es justo donde un modelo pequeño basta, y suele ser el mayor ahorro disponible); revisar en cada turno reescaneando historial ya aprobado; y guardrails en tráfico interno que hereda toda la pila de seguridad de cara al público sin necesitarla. Presupuéstalo como una línea No se trata de quitar los controles, sino de que pueden ser el 30–50% del coste de inferencia sin aparecer en ningún plan. Etiqueta las llamadas de guardrail por separado para ver la proporción. Relacionado Atribución de costes de LLM ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Tu entorno de desarrollo también gasta · FinOps LLM URL: https://finopsllm.com/es/research/non-production-llm-spend Gasto de LLM fuera de producción Actualizado September 1, 2026 · publicado originalmente September 1, 2026 Respuesta rápida: Toda revisión FinOps empieza por el tráfico de producción, porque es lo que tiene panel. Luego alguien desglosa por entorno y descubre que una parte notable de la factura — a menudo de dos... Toda revisión FinOps empieza por el tráfico de producción, porque es lo que tiene panel. Luego alguien desglosa por entorno y descubre que una parte notable de la factura — a menudo de dos dígitos en porcentaje — nunca tocó a un cliente. De dónde sale CI: cada pull request que ejecuta una suite de evaluación llama al modelo, miles de veces al día y en el modelo más caro. Desarrollo local: iterar un prompt son decenas de llamadas por hora, con clave compartida y sin etiquetar. Staging y demos: configurados igual que producción, con el modelo caro y sin caché. Reintentos y bucles descontrolados en pruebas , que nadie vigila. Primero la atribución El cambio que se paga solo es una clave de API por entorno . Cuesta una tarde y convierte una partida inexplicable en cuatro etiquetadas. Etiqueta el entorno en cada petición y, en CI, el repositorio y el workflow. Después llegan tres cosas solas: fuera de producción casi siempre basta un modelo más barato; la caché rinde más que en ningún sitio, porque CI repite prompts casi idénticos; y los topes duros de gasto ahí sí son seguros — un entorno de pruebas con tope rompe un build, uno de producción rompe un cliente. Relacionado Atribución de costes de LLM ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # La observabilidad de IA puede ser una segunda factura · FinOps LLM URL: https://finopsllm.com/es/research/observability-second-llm-bill Observabilidad de IA como segunda factura Actualizado September 9, 2026 · publicado originalmente September 9, 2026 Respuesta rápida: Evaluar cada inferencia con otro modelo de arbitraje puede duplicar el gasto total. Aplique muestreo estadístico para mantener la calidad sin disparar la factura. Evaluar cada inferencia con otro modelo de arbitraje puede duplicar el gasto total. Aplique muestreo estadístico para mantener la calidad sin disparar la factura. Relacionado Control de costes en evaluaciones ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Modelos Abiertos vs. Cerrados: Comparativa de Costes LLM · FinOps LLM URL: https://finopsllm.com/es/research/open-source-vs-closed-cost Modelos Abiertos vs. Cerrados: Comparativa de Costes LLM Actualizado 15 julio 2026 · publicado por primera vez 4 julio 2026 ¿Cuándo es rentable autoalojar Llama, Qwen o DeepSeek frente a pagar por acceso a API? Este análisis cubre costes GPU, optimización de inferencia, gastos operativos, y ofrece un marco de decisión para tu carga de trabajo específica. 8 Modelos comparados 5 Niveles GPU analizados 3 Escenarios de equilibrio Jul 2026 Última actualización Los costes de autoalojamiento asumen precios GPU en nube (bajo demanda) Los costes de API usan precios estándar de salida por proveedor El equilibrio se basa en utilización del 70%, disponibilidad 24/7 Metodología Precios API Tarifas estándar publicadas de cada página de precios del proveedor. Sin descuentos por volumen o lotes aplicados. GPU en nube para autoalojamiento Precios bajo demanda en nube (Lambda, RunPod, AWS) para configuraciones optimizadas para inferencia con vLLM o TensorRT-LLM. Gastos operativos Incluye monitoreo, escalado, actualizaciones de modelos, y sobrecarga operativa del 15% en costes GPU brutos para infraestructura gestionada. Brecha de calidad Relativa a GPT-4o / Claude Sonnet 4 como línea base 100%. Basada en benchmarks públicos y rendimiento práctico en tareas. Tabla de Comparación de Costes Modelo ↕ Coste API/mes ↕ Coste Autoalojamiento (GPU nube) ↕ Volumen de Equilibrio ↕ Brecha de Calidad Llama 4 Maverick (DeepInfra) $260/mes $2.800/mes ~350M tokens/mes ~95% de GPT-4o Llama 3.3 70B (Groq) $277/mes $1.200/mes ~210M tokens/mes ~87% de GPT-4o Llama 4 Scout (Groq) $136/mes $1.400/mes ~350M tokens/mes ~88% de GPT-4o Qwen 3.7-Max $525/mes $1.600/mes ~100M tokens/mes ~92% de GPT-4o DeepSeek V4 Pro $435/mes $1.800/mes ~130M tokens/mes ~96% de GPT-4o DeepSeek V4 Flash $140/mes $1.400/mes ~450M tokens/mes ~82% de GPT-4o Mistral Medium 3.5 $525/mes $2.000/mes ~120M tokens/mes ~91% de GPT-4o GPT-4o (solo API) $750/mes N/A N/A Línea base (100%) Coste API/mes asume 100M tokens de salida + 300M tokens de entrada por mes a tarifas estándar. Coste de Autoalojamiento incluye alquiler GPU, gastos operativos del 15%, e infraestructura de inferencia (vLLM). No incluye tiempo de ingeniería inicial. Volumen de Equilibrio es el número de tokens de salida mensuales donde el autoalojamiento se vuelve más barato que la API. Brecha de Calidad es aproximada y depende de la tarea. Benchmarks como MMLU, HumanEval y GPQA informan estas estimaciones. Algunos enlaces pueden incluir códigos de referencia. Factores de Coste Clave 1) El alquiler GPU es el coste dominante Un nodo 8x H100 para Llama 4 Maverick cuesta $2.000-$3.500/mes bajo demanda desde Lambda, RunPod o AWS. Las instancias spot/preemptibles pueden reducir esto 40-60% pero añaden latencia de reinicio y riesgo de disponibilidad. Para cargas de producción, las instancias reservadas (compromiso 1 año) típicamente ahorran 30-40% frente a bajo demanda. 2) La optimización de inferencia cambia la ecuación vLLM con batching continuo, paging de KV-cache, y cuantización (GPTQ/AWQ 4-bit) pueden aumentar el rendimiento 2-4x en el mismo hardware. TensorRT-LLM añade otro 20-40% para arquitecturas soportadas. Un Llama 4 Scout bien ajustado en 4-bit en una sola A100 puede igualar una configuración ingenua fp16 en 2x A100s. 3) Los gastos operativos son reales pero están disminuyendo Ejecutar infraestructura de inferencia requiere monitoreo GPU, actualizaciones de modelos, balanceo de carga, y failover. Presupuesta 15-25% del coste GPU bruto para ops. Las plataformas gestionadas (Anyscale, Modal, Replicate) absorben esto pero cobran 30-50% premium sobre GPU bruto - vale la pena por debajo de ~$5K/mes en gasto GPU. 4) El almacenamiento en caché de prompts estrecha la brecha para API Los proveedores de API ofrecen cada vez más almacenamiento en caché de prompts (descuento 50-90% en prefijos repetidos). Si tu carga es amigable con caché (RAG, multi-turno), los costes API caen significativamente, empujando el volumen de equilibrio más alto para autoalojamiento. Marco de Decisión Usa API si... El volumen mensual de salida está por debajo de 100M tokens Necesitas calidad de modelo frontera (GPT-4o, Claude Opus 4) Tu equipo no tiene expertise en GPU/MLOps Los requisitos de latencia son estrictos (TTFT <200ms) Quieres cero gastos operativos Tu carga de trabajo es impredecible o estacional Autoaloja si... El volumen mensual de salida supera consistentemente 200M tokens Privacidad de datos requiere ningún acceso a API de terceros Necesitas modelos personalizados fine-tuned Tu equipo tiene capacidad MLOps La carga de trabajo es estado estable (utilización GPU predecible) Puedes comprometer instancias GPU reservadas 1 año Enfoque híbrido: el punto medio pragmático La mayoría de equipos terminan en híbrido: usar API para tareas de razonamiento frontera y cargas bajas, autoalojar modelos abiertos para tareas de alto volumen y tolerantes a latencia (generación de contenido, extracción de datos, herramientas internas). Esto mantiene el gasto en API bajo control mientras se construye capacidad de autoalojamiento de forma incremental. Dónde Ejecutar Modelos Abiertos Plataforma Opciones GPU Precio A100 80GB Precio H100 Inferencia Gestionada Lambda Cloud A100, H100, H200 $1,10/hora $2,49/hora No (trae el tuyo) RunPod A100, H100, L40S $1,19/hora $2,69/hora Opción sin servidor AWS (p4d/p5) A100, H100 $3,67/hora $6,37/hora SageMaker Google Cloud A100, H100 $3,22/hora $5,07/hora Vertex AI Xiaomi MiMO ↗ Basado en API N/A N/A API ($0,50/$2,00 por 1M) Los precios GPU son tarifas por hora bajo demanda a partir de julio 2026. Los precios reservados/spot varían significativamente. MiMO ofrece acceso basado en API a MiMo-V2-Pro y MiMo-V2-Omni a tarifas competitivas - un punto medio entre autoalojamiento completo y precios API premium. ¿Quieres esto aplicado a tu propio gasto en LLM? FinOps LLM realiza una auditoría gratuita de tus costes de IA y muestra dónde están los ahorros. Reserva auditoría gratuita → Volver a investigación FAQ ¿Cuál es la metodología? Tarifas estándar publicadas de cada página de precios del proveedor. Sin descuentos por volumen o lotes aplicados. GPU en nube para infraestructura autoalojada usando precios bajo demanda (Lambda, RunPod, AWS) con configuraciones optimizadas para inferencia con vLLM o TensorRT-LLM. ¿Cuál es la tabla de comparación de costes? API Cost/mes asume 100M tokens de salida + 300M tokens de entrada por mes a tarifas estándar. Coste de autoalojamiento incluye alquiler GPU, gastos operativos del 15%, e infraestructura de inferencia (vLLM). No incluye tiempo de ingeniería inicial. ¿Cuáles son los factores clave de coste? Un nodo 8x H100 para Llama 4 Maverick cuesta $2.000-$3.500/mes bajo demanda desde Lambda, RunPod o AWS. Las instancias spot/preemptibles pueden reducir esto 40-60% pero añaden latencia de reinicio y riesgo de disponibilidad. Para cargas de producción, las instancias reservadas (compromiso 1 año) típicamente ahorran 30-40% frente a bajo demanda. ¿Cuál es el marco de decisión? La mayoría de equipos terminan en híbrido: usar API para tareas de razonamiento frontera y cargas bajas, autoalojar modelos abiertos para tareas de alto volumen y tolerantes a latencia (generación de contenido, extracción de datos, herramientas internas). ¿Dónde ejecutar modelos abiertos? Los precios GPU son tarifas por hora bajo demanda a partir de julio 2026. Los precios reservados/spot varían significativamente. MiMO ofrece acceso basado en API a MiMo-V2-Pro y MiMo-V2-Omni a tarifas competitivas - un punto medio entre autoalojamiento completo y precios API premium. --- # Atribución de costes de OpenAI · FinOps LLM URL: https://finopsllm.com/es/research/openai-cost-attribution Atribución de costes de OpenAI La atribución de costes de OpenAI comienza antes de que se envíe la solicitud. La respuesta de la API puede indicarte el uso de tokens, pero no puede saber qué superficie de producto, equipo, cliente o flujo de trabajo empresarial causó la llamada a menos que tu aplicación adjunte ese contexto. La atribución debe combinar tres fuentes: metadatos de solicitud, registros de uso y datos de factura. Los metadatos de solicitud ofrecen propiedad. Los registros de uso ofrecen conteos de tokens y modelo. Los datos de factura ofrecen el total financiero autoritario. Etiquetas a capturar Nombre de funcionalidad o punto de conexión. Propietario del equipo y entorno. Proyecto o cliente cuando sea permitido. Clase de carga de trabajo, como realtime, batch, eval, soporte o paso de agente. Versión de prompt, política de enrutamiento y estado de alternativa. Brechas comunes en la atribución Los equipos a menudo pierden reintentos y alternativas. Un usuario ve una respuesta, pero el sistema puede haber pagado por múltiples llamadas ascendentes. Otra brecha común es el trabajo en lote: los evals y trabajos de enriquecimiento deben etiquetarse por separado del tráfico orientado al usuario para que puedan moverse a carriles asincronos de menor coste. Los mejores informes de atribución de OpenAI no se detienen en «qué modelo costó más». Muestran qué decisión de producto causó que se usara ese modelo, y qué propietario puede cambiarlo. Relacionado Atribución de costes de LLM - principios generales de atribución. Atribución de costes de Anthropic - atribución para modelos de Anthropic. ¿Qué es LLM FinOps? - la disciplina operativa completa. ¿Quieres que se aplique a tu propio gasto en LLM? FinOps LLM ejecuta una auditoría gratuita de tus costes de IA y muestra dónde se encuentran los ahorros. Solicita tu auditoría gratuita → Volver a la investigación --- # Economía del Cierre de Fine-Tuning de OpenAI · FinOps LLM URL: https://finopsllm.com/es/research/openai-fine-tuning-sunset-economics Economía del Cierre de Fine-Tuning de OpenAI Publicado 19 de julio de 2026 OpenAI está eliminando el fine-tuning autoservicio. A partir del 7 de mayo de 2026, las nuevas organizaciones ya no pueden crear trabajos de fine-tuning. Antes del 6 de enero de 2027, todas las organizaciones pierden esa capacidad. Si dependes de modelos GPT con fine-tuning, debes elegir una ruta de migración ahora: ingeniería de prompts en GPT-5.5 con caché de prompts, adaptadores LoRA de código abierto en Llama o Qwen, o fine-tuning gestionado vía Vertex AI, AWS Bedrock, o Mistral. Cada ruta tiene distintos compromisos de coste y operativos. La creación de fine-tuning autoservicio termina el 6 de enero de 2027 para todas las organizaciones La inferencia en modelos con fine-tuning existentes continúa hasta la deprecación de la base El caché de prompts en GPT-5.5 puede igualar o superar el ROI del fine-tuning en 10–30 aciertos El LoRA de código abierto cuesta 30–50% menos que los servicios gestionados para alto volumen Costes ocultos de migración: re-evaluaciones, pruebas de regresión, ejecución dual, reentrenamiento Plazo: Las organizaciones deben comprometerse con una ruta de migración antes del 6 de enero de 2027. Los modelos con fine-tuning existentes continuarán sirviendo solicitudes de inferencia hasta que su modelo base sea deprecado, pero no puedes crear nuevos trabajos de entrenamiento después de esa fecha. Cronograma y Matriz de Exposición Quién es afectado y cuándo: Fecha Fase Organizaciones Afectadas Acción Requerida 7 de mayo de 2026 Fase 1 Nuevas organizaciones, nunca con fine-tuning antes No pueden iniciar nuevos trabajos 2 de julio de 2026 Fase 2 Organizaciones existentes sin inferencia de modelo con fine-tuning en los últimos 60 días No pueden iniciar nuevos trabajos 6 de enero de 2027 Fase 3 (final) Todas las organizaciones, incluso usuarios activos No hay nuevos trabajos de entrenamiento Post-2027 Solo inferencia Todas las organizaciones con modelos con fine-tuning desplegados La inferencia continúa hasta el cierre de la base Por qué OpenAI está eliminando el fine-tuning: Los modelos de clase GPT-5.5 combinados con caché de prompts eliminan la necesidad de fine-tuning en la mayoría de casos de uso. Los prompts más largos con ejemplos few-shot e instrucciones de sistema ahora igualan o superan el rendimiento del fine-tuning, mientras consumen menos tokens totales cuando se cachean. Los gastos generales gestionados de fine-tuning exceden su valor para la mayoría de cargas de trabajo. Árbol de Decisión: Tres Rutas de Migración Ruta 1: Ingeniería de Prompts + GPT-5.5 + Caché Reescribe la lógica con fine-tuning como prompt del sistema + ejemplos few-shot, cacheados. Intercambia prompts más largos por cero gastos de entrenamiento. Coste de entrenamiento: $0 (sin reentrenamiento) Coste de token por llamada: Prompt más largo, pero cacheado al 50% de la tasa fresca Tiempo de configuración: 1–4 semanas (ingeniería de prompts + benchmarking) Operaciones en curso: Iteración de prompts, no se necesita MLOps Ruta 2: LoRA en Código Abierto (Together, Fireworks, Groq) Fine-tune Llama 4 o Qwen 3.5 con adaptadores LoRA, aloja en inferencia gestionada. Control completo de fine-tuning, reproducibilidad de código abierto. Coste de entrenamiento: $200–$500 por trabajo Coste de inferencia: $0.10–$0.30/M tokens (competitivo) Tiempo de configuración: 2–6 semanas (preparación de datos, entrenamiento de adaptador, pruebas) Operaciones en curso: Monitorea el rendimiento del adaptador, reentrena según sea necesario Ruta 3: Fine-Tuning Gestionado (Vertex, Bedrock, Mistral) Usa Google Vertex AI, AWS Bedrock, o fine-tuning de Mistral. Flujo de trabajo familiar, soporte de vendedor, pero coste por token más alto. Coste de entrenamiento: $500–$2,000 por trabajo Coste de inferencia: $0.20–$1.00/M tokens (premium) Tiempo de configuración: 1–3 semanas (menos integraciones necesarias) Operaciones en curso: El vendedor maneja las operaciones, tú gestionas la cadencia de entrenamiento Ruta 1: Ingeniería de Prompts + Caché GPT-5.5 — Matemáticas Resueltas Supongamos que tenías un modelo GPT-4 con fine-tuning para clasificación de tickets de soporte al cliente. El modelo con fine-tuning fue entrenado en 10K tickets etiquetados. Cada solicitud envía ~500 tokens de entrada, obtiene ~50 tokens de salida. Coste anterior (fine-tuning): Trabajo de fine-tuning: ~$50. Inferencia en 100K llamadas/mes: (500 entrada × $3/M + 50 salida × $15/M) × 100K = $150/mes + entrenamiento = ~$200/mes todo incluido. Coste nuevo (caché de prompts en GPT-5.5): Crea un prompt del sistema con 40 ejemplos few-shot (cada uno ~200 tokens) = 8K tokens. Este es el relleno de caché. Primera llamada: 8K × (1.25× $3/M) + 500 × $3/M + 50 × $15/M ≈ $0.045. Llamadas posteriores (acierto de caché): 500 × (0.5× $3/M) + 50 × $15/M ≈ $0.0015. En 100K llamadas/mes, asume 90% de acierto (90K aciertos de caché). Coste: 10K llamadas × $0.045 + 90K llamadas × $0.0015 = $450 + $135 = $585/mes . ¡Espera — eso es más caro! Verdad si no ajustas el prompt. Pero reduce los ejemplos few-shot a 10 (2K tokens), y el coste baja a ~$280/mes. Además: si puedes agrupar consultas (procesar 10 tickets relacionados en una llamada), el coste por ticket baja otro 30%. En conclusión: el caché de prompts en GPT-5.5 se vuelve más barato que el fine-tuning en 15–30 aciertos de caché por contexto único. La mayoría de equipos alcanzan eso en horas de despliegue. Riesgo de calidad: Los prompts few-shot pueden tener bajo rendimiento respecto al fine-tuning en casos extremos y formatos inusuales. Presupuesta 2–4 semanas para pruebas de regresión. Ruta 2: LoRA en Código Abierto — Costes y Logística El fine-tuning de código abierto vía LoRA (Low-Rank Adaptation) mantiene el modelo base congelado y entrena solo pequeñas matrices de adaptador (~1–5% de parámetros). Estructura de costes: Componente Ejemplo de Proveedor Coste Notas Entrenamiento (Llama 3.3 70B en 10K muestras) Together AI $300 LoRA en GPU H100 único (~4 horas) Inferencia (por 1M tokens) Groq (Llama 3.3 70B) $0.27 Rápido (sin lag de ajuste vs GPT-4 con fine-tuning) Inferencia (por 1M tokens) Together AI (Llama 3.3 70B) $0.18 Respuesta más lenta, coste más bajo Alojamiento de modelo (mensual, siempre activo) Alojamiento propio en runpod $300–$600 Alquiler de GPU A100 + gastos generales de operaciones Total para 1M llamadas/mes — $318–$600 API de Groq (gestionada), sin coste de alojamiento Por qué el código abierto es más barato: Sin prima por token para estado "con fine-tuning". El adaptador es tuyo para distribuir y mejorar. Calidad del modelo (Llama 4 Maverick) iguala GPT-4o para la mayoría de tareas a 30–50% menos coste. El compromiso: posees los MLOps — cadencia de reentrenamiento, detección de desviación, pruebas A/B entre versiones de adaptador. Riesgo de integración: Cambiar de la API de OpenAI a Groq, Together, o alojamiento propio cambia tu latencia de inferencia, manejo de errores, y escalado. Espera 1–2 semanas de trabajo de integración. Ruta 3: Fine-Tuning Gestionado (Vertex, Bedrock, Mistral) Proveedor Coste de Entrenamiento (10K muestras) Coste de Inferencia (por 1M tokens de salida) Modelo Base Tiempo a Producción Google Vertex AI $500–$800 $0.40–$1.50 Gemini 1.5 Flash, otros modelos OS 1–2 semanas AWS Bedrock (Claude Sonnet con fine-tuning) $600–$1,200 $0.80–$2.00 Claude Sonnet, Llama 4, Mistral 1–2 semanas Fine-tuning de Mistral $400–$700 $0.25–$0.60 Mistral 3.5 Moe, otros modelos Mistral 1 semana Coste mensual típico (100K llamadas, 500 tokens promedio) $600–$1,200 (entrenamiento único) $200–$1,000 (inferencia recurrente) — — Los servicios gestionados son la rampa más fácil: tu equipo ya conoce la autenticación de API, el soporte del vendedor está disponible, y evitas gastos generales de MLOps. Pero los costes de inferencia ejecutan 2–5× más alto que LoRA de código abierto. Esta ruta tiene sentido si: (1) tienes Comparación de Costes de Tres Rutas (Carga de Trabajo Concreta) Carga de trabajo: IA de servicio al cliente para SaaS. 1M llamadas de inferencia/mes, promedio 500 entrada + 150 tokens de salida por llamada. El equipo entrenó un modelo con fine-tuning en 5K conversaciones etiquetadas. Componente de Coste Ruta 1: Caché de Prompts + GPT-5.5 Ruta 2: LoRA en Groq (Llama 3.3) Ruta 3: Bedrock (Claude Sonnet FT) Configuración inicial / entrenamiento $0 (solo ing. de prompts) $300 $1,000 Coste de inferencia mensual (1M llamadas) $450–$600 $270 $900–$1,200 Total mensual (Año 1) $450–$600 $600 (incluye entrenamiento amortizado) $1,900–$2,200 Total Año 1 $5,400–$7,200 $3,600–$4,800 $12,000–$15,000 Ruta 2 (LoRA) gana en coste puro, pero requiere tiempo de MLOps para configurar y mantener.** Ruta 1 (caché de prompts) es fricción más baja si aceptas costes continuos ligeramente más altos. Ruta 3 (gestionada) se elige solo si SLAs empresariales u operaciones sin intervención son obligatorios. Costes Ocultos de Migración — No los Pases por Alto La tabla anterior omite la fricción operativa. Planifica: 1. Re-evaluación y Benchmarking Mide la precisión, latencia y coste del nuevo modelo en tu conjunto de prueba de retención. Presupuesta: 2–3 semanas, $1K–$3K en tiempo de ingeniería. 2. Pruebas de Regresión Ejecuta el modelo antiguo con fine-tuning y la nueva ruta en las mismas 100–1K consultas de producción. Mide brechas de calidad. Para sistemas orientados al cliente, considera pruebas A/B (ejecución dual) durante 2–4 semanas. Coste de operaciones: $2K–$5K. 3. Período de Ejecución Dual Ejecuta ambas rutas antiguas y nuevas en paralelo para detectar regresiones en producción. Esto duplica el coste de inferencia durante 2–4 semanas. Añade $500–$2,000 a tu factura de migración. 4. Cambios en el Flujo de Entrenamiento Si reentrenas regularmente (mensual, trimestral), factoriza cambios de scripting. Los scripts de reentrenamiento de LoRA difieren de la API de OpenAI. Mistral, Vertex, y Bedrock cada uno tienen diferentes APIs de entrenamiento. Presupuesta: 1–2 semanas, $500–$1,500. 5. Desviación de Adaptador y Monitoreo Los adaptadores de código abierto pueden desviarse si cambian los datos de entrenamiento. Configura monitoreo de rendimiento e triggers de reentrenamiento. Para servicios gestionados, el proveedor maneja esto pero cobra gastos generales de monitoreo. Presupuesta: recurrente +$200–$500/mes. Coste oculto total: $4K–$12K en tiempo de ingeniería + $500–$2,000 en operaciones de ejecución dual. La mayoría de equipos subestiman esto en 50%. Cuécelo en tu plan de proyecto. Marco de Decisión Elige Ruta 1 (Caché de Prompts + GPT-5.5) si: El volumen de inferencia mensual está por debajo de 100M tokens Tu carga de trabajo actual tiene contextos repetidos (RAG, multi-turno) — alto potencial de acierto de caché Tu equipo no tiene experiencia MLOps y quiere gastos generales mínimos Puedes aceptar un compromiso de calidad por simplicidad (la mayoría de tareas ven ≤5% regresión) Los requisitos de latencia son flexibles (>500ms TTFT aceptable) Elige Ruta 2 (LoRA en Código Abierto) si: El volumen de inferencia mensual excede 200M tokens — ventaja de coste de 30–50% Tu equipo tiene ancho de banda MLOps para entrenamiento, monitoreo, y reentrenamiento Necesitas reproducibilidad y quieres control total sobre el adaptador (ventaja de código abierto) La privacidad de datos requiere sin llamadas a APIs patentadas de OpenAI, Google, o AWS La latencia es crítica ( Elige Ruta 3 (Fine-Tuning Gestionado) si: Necesitas SLAs empresariales, soporte de vendedor, o cumplimiento HIPAA/SOC 2 Tu equipo carece de experiencia en infraestructura y quiere cero MLOps El volumen mensual está por debajo de 50M tokens (la prima de coste es aceptable a escala baja) Ya estás invertido en el ecosistema del vendedor (AWS, Google Cloud, Mistral) La frecuencia de entrenamiento es mensual o menos (el coste de operaciones se amortiza mejor con poco cambio) Lectura Relacionada Para más contexto sobre el panorama de costes más amplio, ver Comparación de Costes de LLM de Código Abierto vs Cerrado , que compara volúmenes de punto de equilibrio entre opciones autoalojadas y API. ¿Ya rastreando tus costes de migración de fine-tuning? FinOps LLM audita tu gasto LLM e identifica cuál ruta de migración te ahorra más. Reserva una auditoría gratuita . Volver a investigación FAQ ¿Cuándo no puedo crear nuevos modelos con fine-tuning de OpenAI? Cronograma: 7 de mayo de 2026 (nuevas organizaciones bloqueadas), 2 de julio de 2026 (organizaciones inactivas 60 días bloqueadas), 6 de enero de 2027 (todos los trabajos nuevos bloqueados). La inferencia en modelos con fine-tuning existentes continúa hasta la deprecación del modelo base. ¿Se amortiza el caché de prompts frente al fine-tuning? Para prompts repetidos sobre el mismo contexto: sí. El caché de prompts en GPT-5.5 cuesta $0.60/M para lecturas vs $3.00/M frescos, y los ejemplos few-shot (prompts más largos) se pueden cachear eficientemente. El punto de equilibrio es típicamente 10–30 aciertos de caché dependiendo del tamaño del prompt; la mayoría de equipos lo alcanzan en días. ¿Es el LoRA de código abierto más barato que el fine-tuning gestionado? Normalmente, sí. Coste de entrenamiento vía Together AI: ~$200–$500 por trabajo. Inferencia en Groq o Fireworks: ~$0.10–$0.30/M tokens. El coste total por respuesta exitosa es a menudo 30–50% más bajo que un servicio gestionado, pero requiere gastos generales de MLOps. ¿Qué costes ocultos no estoy viendo durante la migración? Re-evaluación (comparativa del nuevo enfoque vs el anterior), pruebas de regresión (¿entrega la ruta de reemplazo la misma calidad?), ejecución dual (ejecutar ambas rutas antiguas y nuevas en paralelo por seguridad), y reentrenamiento de adaptadores si el nuevo modelo cambia. Presupuesta 4–8 semanas y ~$2K–$10K en tiempo de ingeniería por migración. --- # Los niveles de esfuerzo de Opus 5.5 son el precio real · FinOps LLM URL: https://finopsllm.com/es/research/opus-5-5-effort-level-cost Los niveles de esfuerzo de Opus 5.5 son el precio real Actualizado September 22, 2026 · publicado originalmente September 22, 2026 Claude Opus 5.5 cuesta $4 por millón de tokens de entrada y $20 por millón de tokens de salida. Eso es 20% menos que Opus 5. La tarifa es la mitad menor del costo. La mayor mitad es el parámetro effort , que decide cuántos tokens gasta el modelo pensando antes de responder. Un modelo, cinco precios Opus 5.5 expone esfuerzo desde low hasta medium , high , xhigh y max . Cada nivel es el mismo modelo con la misma tarifa por token, pero produce un número muy diferente de tokens. Análisis independiente reportado por The Decoder encontró que cuatro de los cinco niveles se sitúan en la frontera de eficiencia costo-rendimiento. También encontró que a esfuerzo máximo Opus 5.5 usó alrededor de 119.000 tokens de salida por tarea, mucho más que modelos competidores en sus máximos niveles. A 20 $ por millón, 119.200 tokens de salida son 2,38 $ por tarea antes de contar la entrada. En medium, Artificial Analysis midió 25.700 tokens de salida, es decir, 0,51 $. Contando la entrada, max cuesta 5,98 $ por tarea y medium 1,34 $: el mismo modelo es unas 4,5 veces más caro por tarea según un solo parámetro de la petición. Medido en el Artificial Analysis Intelligence Index v4.3.2 (diez evaluaciones), consultado el 22 de septiembre de 2026. Todas las filas usan la misma batería de pruebas, así que se comparan directamente. Modelo y esfuerzo Intelligence Index Coste por tarea Tokens de salida por tarea En la frontera coste–rendimiento Opus 5.5 · low 42.3 $0.55 10,200 No Opus 5.5 · medium 51.2 $1.34 25,700 Sí Opus 5.5 · high 53.6 $1.82 35,600 Sí Opus 5.5 · xhigh 56.0 $3.46 65,700 Sí Opus 5.5 · max 57.6 $5.98 119,200 Sí Opus 5 · high (referencia) 48.1 $3.61 46,200 No Fuente: Artificial Analysis. En la frontera significa que ningún ajuste de GPT-6 Sol, GPT-6 Astra, Opus 5, Opus 5.5 o Fable 5.1 puntúa más por menos. Opus 5.5 low queda fuera porque GPT-6 Sol en xhigh puntúa 44,1 por 0,53 $. Pasar de xhigh a max suma 1,6 puntos con un 73 % más de coste. Medio es la configuración con la que Anthropic hace benchmarks La comparación principal de Anthropic se hace a esfuerzo predeterminado, que es medio. Dice que Opus 5.5 a medio vence a GPT-6 Astra a máximo esfuerzo en trabajo de conocimiento por aproximadamente un quinto del costo por tarea. Entonces el caso propio de Anthropic para el modelo se construye en medio, y máximo es la excepción. Un equipo que establece máximo en todas partes "para estar seguro" paga por tokens que los benchmarks de lanzamiento no necesitaban. Cómo establecer esfuerzo sin adivinar Establece por defecto medio. Hazlo el valor explícito en código, no un defecto del SDK que pueda cambiar bajo ti. Sube esfuerzo por ruta, no globalmente. La depuración difícil, la planificación de horizonte largo y los pasos de revisión final pueden justificar alto o máximo. La clasificación, extracción y ediciones rutinarias raramente lo hacen. Registra esfuerzo con cada solicitud. El costo por solicitud no es interpretable sin él. Un pico de gasto con un conteo de solicitud plano es usualmente un cambio de esfuerzo. Compara niveles de esfuerzo en las mismas tareas reproducidas. Registra la tasa de éxito y tokens de salida por tarea completada en cada nivel, y deja de subir esfuerzo cuando el éxito deja de mejorar. Limita salida donde el producto lo permita. Un límite de tokens máximo acota el peor caso. A esfuerzo máximo ese límite es lo único entre una tarea desbocada y una solicitud de varios dólares. El corte de $25 a $20 por millón de tokens de salida ahorra 20%. Mover una carga de trabajo de máximo a esfuerzo medio puede ahorrar mucho más que eso. Trata esfuerzo como una línea de presupuesto, poseída y revisada como cualquier otra. Relacionado Modelo de costo de Claude Opus 5.5 Economía del modo rápido de Opus 5.5 Guía de costos del modelo de razonamiento ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Opus 5.5 fast mode: 2x precio por esperar menos · FinOps LLM URL: https://finopsllm.com/es/research/opus-5-5-fast-mode-economics Economía de Opus 5.5 fast mode Actualizado September 22, 2026 · publicado originalmente September 22, 2026 Claude Opus 5.5 tiene dos listas de precios. La estándar es $4 por millón de tokens de entrada y $20 por millón de salida. Fast mode es $8 y $40, exactamente el doble, para hasta 2,5× la velocidad de salida. El modelo es el mismo. El dinero extra compra tiempo y nada más, así que la única pregunta es de quién. Qué compra el premium Toma un paso que produce 5.000 tokens de salida. A tasas estándar el coste es $0,10. En fast mode cuesta $0,20. Si el paso tarda 60 segundos a velocidad estándar, una aceleración de 2,5× lo trae a unos 24 segundos. Pagas $0,10 extra para ahorrar 36 segundos. Eso resulta en unos $10 por cada hora de espera eliminada. La longitud del paso no cambia el ratio, porque el coste extra y el tiempo ahorrado crecen con los tokens de salida. Depende de tu velocidad en modo estándar: este ejemplo asume unos 83 tokens de salida por segundo, así que calcula la tuya. La entrada también se duplica, así que los pasos con mucho prefijo pagan un poco más por segundo ahorrado. Cuándo es barato Un desarrollador esperando a un agente de codificación interactivo. A $10 por hora de espera eliminada, fast mode cuesta mucho menos que el tiempo de cualquiera pagado. Una respuesta cara al cliente donde la latencia afecta la conversión. Compara la aceleración contra el abandono, no contra la factura de tokens. Un incidente, donde cada minuto tiene un coste. Cuándo es puro desperdicio Agentes en background, trabajos nocturnos y tuberías batch. Nadie espera, así que el gasto extra no compra nada. Evals y replays. Son exactamente las cargas de trabajo que multiplican recuentos de tokens y se ejecutan en un cronograma. Subagentes que se ejecutan en paralelo. El tiempo de reloj se establece por la rama más lenta y el orquestador, no por cada llamada. Opus 5.5 estándar ya es aproximadamente 30% más rápido que Opus 5, según Anthropic. Algunas quejas de latencia que habrían justificado fast mode en Opus 5 pueden resolverse solo con la actualización. Mide la velocidad estándar antes de pagar por más. Controles a poner en su lugar Haz que fast mode sea una decisión explícita y por ruta. Nunca debe ser un valor global por defecto o una bandera que un ingeniero activó una vez y olvidó. Etiqueta el gasto por modo. Una solicitud de fast mode a doble precio por unidad se ve como una solicitud normal en un panel que agrupa solo por modelo. Alerta sobre la fracción de fast mode de tokens de salida. Si sube en rutas donde ningún usuario espera, algo fue activado que no debería haber sido. Presupuesta esfuerzo y velocidad juntos. Max effort multiplica el recuento de tokens, y fast mode duplica el precio de cada token. La combinación es la forma más cara de ejecutar el modelo. Relacionado Modelo de coste de Claude Opus 5.5 Los niveles de esfuerzo de Opus 5.5 son el precio real Límites de fan-out y concurrencia de subagentes ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Ox Alpha era GLM-5.3: el coste de lo gratis · FinOps LLM URL: https://finopsllm.com/es/research/ox-alpha-was-glm-5-3 Ox Alpha era GLM-5.3 Actualizado September 1, 2026 · publicado originalmente September 1, 2026 Respuesta rápida: Entre el 20 y el 26 de agosto de 2026, OpenRouter sirvió gratis un modelo llamado stealth/ox-alpha. Después se identificó como GLM-5.3-Flash: 320.000 millones de parámetros totales con 18.000 millones... Entre el 20 y el 26 de agosto de 2026, OpenRouter sirvió gratis un modelo llamado stealth/ox-alpha . Después se identificó como GLM-5.3-Flash: 320.000 millones de parámetros totales con 18.000 millones activos, atención híbrida lineal y dispersa, entrada nativa de texto, imagen y vídeo, contexto de 1.048.576 tokens y pesos con licencia MIT. La adopción no fue marginal: en tres días, OpenCode informó de unos 16 billones de tokens procesados, 221.000 usuarios únicos y más de cinco millones de sesiones. Eso es tráfico de producción, y durante seis días no costó nada. Gratis es una tarifa, no una ausencia El problema financiero es que la telemetría trata una línea de 0 dólares como si no existiera. Ese tráfico no pesa en ninguna previsión ni alerta de presupuesto. Cuando la ventana se cierra y aparece una tarifa, el mismo tráfico se convierte en un salto que nadie modeló. La solución es aplicar un precio sombra a cada llamada gratuita: registra los tokens y multiplícalos por la tarifa de lista del modelo que habrías usado. Así el panel muestra cuánto vale la promoción al mes y cuál será la factura el día que termine. La tarifa ya no es hipotética: GLM-5.3-Flash cuesta 0,15 dólares por millón de tokens de entrada y 0,50 de salida. Dieciséis billones de tokens de entrada a ese precio son unos 2,4 millones de dólares: el valor de seis días gratis y el tamaño del salto si ese tráfico se queda. Tres exposiciones que revisar Precipicio de tarifa: ¿cuánto cuesta este tráfico mañana a precio de lista? Deriva de identidad: ¿qué modelo hay detrás del alias esta semana? Acoplamiento de calidad: ¿se ajustaron los prompts a un modelo que no puedes conservar? Fija identificadores de modelo y evalúa el sustituto antes de que acabe la ventana. Los pesos MIT cambian el cálculo Con licencia MIT, el autoalojamiento es una opción real. Con 18.000 millones de parámetros activos, el coste de servir se parece al de un modelo denso mediano, pero solo con utilización alta y sostenida. Por debajo del 40–50% de uso de GPU suele ganar la API: una GPU inactiva factura igual, una llamada que no ocurre no factura nada. Relacionado Coste de modelos abiertos frente a cerrados ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Cómo poner precio a un modelo que no lo tiene · FinOps LLM URL: https://finopsllm.com/es/research/pricing-an-open-weight-model Precio de un modelo de pesos abiertos Actualizado September 1, 2026 · publicado originalmente September 1, 2026 Respuesta rápida: Qwen3.8-Flash-Next apareció el 26 de agosto de 2026 como vista previa de pesos abiertos de la arquitectura Qwen4: unos 6B de parámetros activos, contexto nativo de 262.144 tokens y ninguna tarifa... Qwen3.8-Flash-Next apareció el 26 de agosto de 2026 como vista previa de pesos abiertos de la arquitectura Qwen4: unos 6B de parámetros activos, contexto nativo de 262.144 tokens y ninguna tarifa alojada anunciada. Eso rompe la comparación habitual: un modelo cerrado te da un número por millón de tokens; unos pesos abiertos te dan un checkpoint y te dejan el número a ti. La fórmula coste por MTok = precio_hora / (tokens_por_segundo * 3600) * 1.000.000 A 2,00 $ la hora y 1.500 tokens por segundo medidos, son 0,37 $ por millón de tokens . Frente a una API a 3,00 $/MTok parece un ahorro de ocho veces. También es una cifra equivocada, porque supone que la GPU está ocupada cada segundo que pagas. El término que todos olvidan: la utilización Alquilas la hora y usas una fracción. Divide por esa fracción: al 60% son 0,62 $; al 30%, 1,23 $; al 10%, 3,70 $ — más caro que la API que ibas a sustituir. La mayoría de los primeros despliegues están entre el 10% y el 30%, porque el tráfico es irregular y la instancia se dimensiona para el pico. El ahorro es real, pero es un ahorro de utilización, no de pesos. Mide antes de comprometerte Ejecuta el modelo en la instancia que alquilarías de verdad, con tus prompts y tus longitudes de contexto, y anota los tokens por segundo bajo concurrencia, no el número de flujo único de la ficha del modelo. Después calcula la utilización con tu perfil real de tráfico. Dos números, una división, y la decisión se toma sola. Ponle precio al contexto que envías, no al que el modelo admite. Relacionado Coste de modelos abiertos frente a cerrados ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Probar el ROI de IA sin ocultar fallos · FinOps LLM URL: https://finopsllm.com/es/research/prove-ai-roi-measurement Probar el ROI de IA sin ocultar fallos Actualizado August 27, 2026 · publicado originalmente August 27, 2026 Respuesta rápida: El ROI de IA no se demuestra solo reduciendo la factura. Se demuestra cuando un resultado de negocio mejora más que el coste total de producirlo. Une gasto atribuible, resultado exitoso y control de... El ROI de IA no se demuestra solo reduciendo la factura. Se demuestra cuando un resultado de negocio mejora más que el coste total de producirlo. Une gasto atribuible, resultado exitoso y control de calidad. Define el contrafactual Explica qué habría ocurrido sin el cambio: trabajo humano, modelo anterior, flujo anterior o ninguna funcionalidad. Usa un periodo o cohorte comparable. Mide resultados Usa coste por tarea exitosa, no por solicitud. Define éxito de forma observable y vincúlalo al trace. Incluye reintentos, herramientas, reparación humana y evaluaciones. Conserva la calidad Acompaña el resultado con tasa de éxito, errores, latencia, aceptación o conversión. Un ahorro que empeora el producto no es ROI. Presenta escenarios conservador, base y optimista con supuestos auditables. Relacionado Coste por tarea exitosa ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Precios de proveedores IA: comparación real · FinOps LLM URL: https://finopsllm.com/es/research/provider-prices-not-comparable Precios de proveedores IA: comparación real Actualizado August 27, 2026 · publicado originalmente August 27, 2026 Respuesta rápida: Comparar proveedores por el precio anunciado por millón de tokens produce falsos ahorros. Miden unidades, descuentos y calidades distintas. Compara el coste efectivo por tarea exitosa con la misma... Comparar proveedores por el precio anunciado por millón de tokens produce falsos ahorros. Miden unidades, descuentos y calidades distintas. Compara el coste efectivo por tarea exitosa con la misma carga y objetivo de calidad. Normaliza la factura Usa una tabla por proveedor, modelo, región, tipo de token, caché, batch y fecha. Separa entrada, salida, caché, razonamiento, imagen, audio y herramientas. Registra compromisos y créditos aparte. Normaliza la carga Reproduce las mismas instrucciones, contexto, límites de salida y pruebas de éxito. Mide latencia p50 y p95, finalización, reintentos, reparación humana y calidad. Incluye el coste operativo Añade gateway, observabilidad, routing, evaluación, soporte y transferencia. Enruta cada solicitud al proveedor más barato que supere la calidad y el coste efectivo permitidos. Relacionado Arbitraje entre proveedores LLM ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Los rate limits son control de coste · FinOps LLM URL: https://finopsllm.com/es/research/rate-limits-are-cost-control Rate limits, 429 y subidas de tier Actualizado September 1, 2026 · publicado originalmente September 1, 2026 Respuesta rápida: Cuando un servicio empieza a devolver 429, el reflejo es tratarlo como incidencia de disponibilidad: subir el límite, subir de tier, añadir reintentos. A veces es correcto. También es el mecanismo por... Cuando un servicio empieza a devolver 429, el reflejo es tratarlo como incidencia de disponibilidad: subir el límite, subir de tier, añadir reintentos. A veces es correcto. También es el mecanismo por el que un bucle descontrolado se convierte en una factura de cinco cifras, porque acabas de quitar lo único que lo frenaba. Qué te está diciendo un 429 Que el sistema intenta gastar más rápido que su asignación. Por dos razones muy distintas: crecimiento real , donde el límite se quedó corto, y comportamiento descontrolado — tormenta de reintentos, agente en bucle, backfill sin throttle — donde el límite está haciendo justo su trabajo. La tasa de error no las distingue. El coste por tarea completada sí: el crecimiento real mantiene la proporción; el descontrol la rompe. Usa los límites a propósito Pon límites propios por debajo de los del proveedor, por entorno y por función. Capa duro lo que no es producción. Alerta sobre el coste por tarea, no solo sobre errores. Relacionado Gasto oculto en reintentos ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Re-embeber el corpus es recurrente · FinOps LLM URL: https://finopsllm.com/es/research/re-embedding-is-recurring El coste recurrente de embeddings y vectores Actualizado September 1, 2026 · publicado originalmente September 1, 2026 Respuesta rápida: El coste de embeddings se aprueba como partida de proyecto: unos millones de documentos, una ejecución única, una cifra pequeña al lado de la generación. Luego no para nunca, porque tres fuerzas... El coste de embeddings se aprueba como partida de proyecto: unos millones de documentos, una ejecución única, una cifra pequeña al lado de la generación. Luego no para nunca, porque tres fuerzas distintas vuelven a embeber lo que ya pagaste. Los tres motores de refresco Rotación de contenido : la honesta y la más pequeña, escala con el negocio y se predice bien. Cambios de chunking o pipeline : la traicionera. Cualquier ajuste de tamaño de chunk, solape o preprocesado invalida todos los vectores. Un experimento de calidad de recuperación que suena a cambio de config es un re-embed completo. Cambios de modelo : la grande. Los espacios de embedding no son compatibles entre modelos, así que no hay migración parcial: o mantienes dos almacenes en paralelo o asumes corte. Presupuéstalo como una anualidad Prevé al menos un re-embed completo al año. Valora un modelo por coste de re-embed más un año de almacenamiento y consultas , no por precio por token. Y lanza esos trabajos por batch: es tu carga más tolerante a latencia. Relacionado Optimización de costes de RAG ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Coste real por tarea: Opus 5.5 vs Sol, Astra y Fable · FinOps LLM URL: https://finopsllm.com/es/research/real-cost-per-task-frontier-models Coste real por tarea en los modelos frontera Actualizado September 22, 2026 · publicado originalmente September 22, 2026 Los precios de lista dicen cuánto cuesta un token. No dicen cuánto cuesta una tarea terminada, porque los modelos gastan cantidades de tokens muy distintas para hacer el mismo trabajo. Esta página pone lado a lado el coste por tarea medido y una puntuación de calidad para Claude Opus 5.5, Claude Opus 5, Claude Fable 5.1, GPT-6 Astra y GPT-6 Sol en cada nivel de esfuerzo. Cada cifra tiene fuente y nada es una estimación. La respuesta corta: GPT-6 Sol es la forma más barata de alcanzar cualquier puntuación hasta 47,5. Por encima de 47,5, Opus 5.5 es el más barato en todos los niveles. Ninguna configuración de GPT-6 Astra por encima de low, de Opus 5 o de Fable 5.1 es eficiente en coste: a cada una la supera en puntuación y en precio alguna configuración de Sol o de Opus 5.5. Método Todas las puntuaciones y costes proceden del Artificial Analysis Intelligence Index v4.3.2, consultado el 22 de septiembre de 2026. El índice ejecuta diez evaluaciones: AA-Briefcase, GDPval-AA, AutomationBench-AA, Terminal-Bench 4.0, SciCode, Humanity's Last Exam, GDP.pdf, CritPt, AA-Omniscience y AA-LCR. Artificial Analysis ejecuta cada modelo en cada nivel de esfuerzo a través de la API del proveedor y registra lo que paga a precios de lista. El coste por tarea es ese gasto por tarea, dividido en entrada y salida. Todas las filas usan el mismo conjunto de pruebas, así que se comparan directamente. Hay dos límites antes de leer las cifras. Primero, el índice es una sola mezcla de tareas. Tu mezcla moverá los costes, y por eso la última sección explica cómo medir los tuyos. Segundo, las puntuaciones de distintas versiones del índice no son comparables, así que no mezcles estas cifras con números publicados antes. La escala completa: 26 configuraciones Los tokens de salida por tarea son los que escribe el modelo, razonamiento incluido. Artificial Analysis no publica el reparto entre entrada y salida para las cuatro configuraciones intermedias de GPT-6 Sol, así que esas celdas indican n/a. Modelo Esfuerzo Intelligence Index Coste por tarea Coste de entrada Coste de salida Tokens de salida por tarea En la frontera GPT-6 Sol none 28.1 $0.33 $0.28 $0.05 4,900 No GPT-6 Sol low 33.9 $0.13 n/a n/a 3,400 Sí GPT-6 Sol medium (por defecto) 39.8 $0.25 n/a n/a 6,500 Sí GPT-6 Sol high 42.8 $0.37 n/a n/a 10,200 Sí GPT-6 Sol xhigh 44.1 $0.53 n/a n/a 16,000 Sí GPT-6 Sol max 47.5 $1.06 $0.74 $0.31 31,200 Sí GPT-6 Astra low 45.8 $0.82 $0.60 $0.22 4,400 Sí GPT-6 Astra medium 49.6 $1.54 $1.06 $0.48 9,600 No GPT-6 Astra high 50.9 $1.73 $1.13 $0.59 11,800 No GPT-6 Astra xhigh 52.4 $2.31 $1.46 $0.85 16,900 No GPT-6 Astra max 52.7 $3.26 $1.90 $1.36 27,200 No Claude Opus 5 low 39.4 $1.10 $0.73 $0.37 14,700 No Claude Opus 5 medium 44.8 $2.19 $1.47 $0.72 29,000 No Claude Opus 5 high (por defecto) 48.1 $3.61 $2.46 $1.16 46,200 No Claude Opus 5 xhigh 49.7 $4.88 $3.36 $1.52 60,700 No Claude Opus 5 max 50.8 $5.86 $4.05 $1.81 72,500 No Claude Opus 5.5 low 42.3 $0.55 $0.35 $0.20 10,200 No Claude Opus 5.5 medium (por defecto) 51.2 $1.34 $0.82 $0.51 25,700 Sí Claude Opus 5.5 high 53.6 $1.82 $1.11 $0.71 35,600 Sí Claude Opus 5.5 xhigh 56.0 $3.46 $2.15 $1.31 65,700 Sí Claude Opus 5.5 max 57.6 $5.98 $3.60 $2.38 119,200 Sí Claude Fable 5.1 low 46.8 $2.37 $1.30 $1.08 21,600 No Claude Fable 5.1 medium 48.9 $2.98 $1.59 $1.39 27,900 No Claude Fable 5.1 high 51.2 $3.91 $2.01 $1.90 38,100 No Claude Fable 5.1 xhigh 53.2 $5.98 $2.96 $3.02 60,500 No Claude Fable 5.1 max 53.4 $7.63 $3.73 $3.90 78,100 No En la frontera significa que ninguna otra configuración de esta tabla puntúa más por menos dinero. La frontera de coste Diez de las 26 configuraciones están en la frontera. Ordenadas por coste, son las únicas que merece la pena considerar solo por precio. Todas las demás pagan más por la misma puntuación o por menos. Configuración Intelligence Index Coste por tarea Por 10.000 tareas GPT-6 Sol · low 33.9 $0.13 $1,300 GPT-6 Sol · medium 39.8 $0.25 $2,500 GPT-6 Sol · high 42.8 $0.37 $3,700 GPT-6 Sol · xhigh 44.1 $0.53 $5,300 GPT-6 Astra · low 45.8 $0.82 $8,200 GPT-6 Sol · max 47.5 $1.06 $10,600 Claude Opus 5.5 · medium 51.2 $1.34 $13,400 Claude Opus 5.5 · high 53.6 $1.82 $18,200 Claude Opus 5.5 · xhigh 56.0 $3.46 $34,600 Claude Opus 5.5 · max 57.6 $5.98 $59,800 La frontera tiene dos zonas. De 0,13 $ a 1,06 $ es casi todo GPT-6 Sol, con GPT-6 Astra low como única excepción a 0,82 $. Desde 1,34 $ hacia arriba es solo Opus 5.5. El salto entre ambas zonas es pequeño: Opus 5.5 medium puntúa 3,7 puntos más que Sol max por 0,28 $ más por tarea. Cara a cara con igual o mejor puntuación Cada par compara una configuración más barata con otra más cara que puntúa igual o menos. Configuración más barata Configuración más cara Diferencia de puntuación Ahorro Opus 5.5 medium: 51.2, $1.34 Opus 5 high: 48.1, $3.61 +3.1 para Opus 5.5 63% Opus 5.5 medium: 51.2, $1.34 Opus 5 max: 50.8, $5.86 +0.4 para Opus 5.5 77% Opus 5.5 medium: 51.2, $1.34 Fable 5.1 high: 51.2, $3.91 empate 66% Opus 5.5 high: 53.6, $1.82 GPT-6 Astra max: 52.7, $3.26 +0.9 para Opus 5.5 44% Opus 5.5 high: 53.6, $1.82 Fable 5.1 max: 53.4, $7.63 +0.2 para Opus 5.5 76% GPT-6 Sol max: 47.5, $1.06 Opus 5 high: 48.1, $3.61 +0.6 para Opus 5 71% La fila de Opus 5 importa a los equipos que aún no han migrado. Opus 5 funcionaba por defecto en esfuerzo high. Opus 5.5 funciona por defecto en medium y, con ese valor, puntúa 3,1 puntos más por un 63 % menos por tarea. Anthropic dice que Opus 5.5 es un 40 % más barato que Opus 5; la diferencia medida en este índice es mayor que lo que afirma. Adónde va el dinero: a la entrada, no a la salida En todos los modelos, la entrada supone entre la mitad y tres cuartas partes del coste por tarea. En Opus 5.5 medium, 0,82 $ de los 1,34 $ son entrada, un 61 %. En GPT-6 Astra max es el 58 %, en GPT-6 Sol max el 70 % y en Fable 5.1 max el 49 %. Las tareas de agente reenvían su contexto creciente en cada paso, así que el gasto de entrada crece con el número de pasos y no solo con la longitud de la respuesta. Por eso GPT-6 Sol sin razonamiento cuesta más que en low: 0,33 $ frente a 0,13 $, aunque solo escribe 4.900 tokens de salida. 0,28 $ de los 0,33 $ son entrada. La causa probable es que da más pasos y cada uno reenvía el contexto. Desactivar el razonamiento no abarata un agente si luego necesita más turnos. Para tu factura, esto significa que la caché importa tanto como la elección de modelo. Opus 5.5 y GPT-6 Sol cobran 0,20 $ por millón de tokens de entrada en caché. GPT-6 Astra cobra 1,00 $ y Opus 5 cobra 0,50 $. Volumen de tokens frente a precio de lista GPT-6 Astra es el modelo más eficiente en tokens de esta lista. En esfuerzo max escribe 27.200 tokens de salida por tarea, frente a 119.200 de Opus 5.5 max. Pero Astra cobra 10 $ y 50 $ por millón, 2,5× la tarifa de Opus 5.5. Gana el precio de lista: Opus 5.5 high cuesta 1,82 $ por tarea y puntúa 53,6, mientras que Astra max cuesta 3,26 $ y puntúa 52,7. Opus 5.5 max es el único punto donde la verbosidad pesa. Sus 119.200 tokens de salida cuestan 2,38 $ antes de cualquier entrada, y la tarea completa cuesta 5,98 $. Eso compra la puntuación más alta de la tabla, 57,6, pero es 4,5× el coste de medium. Rendimientos decrecientes por esfuerzo Cada fila muestra lo que compra subir un nivel de esfuerzo, en puntos de índice frente al coste extra por tarea. Modelo medium → high xhigh → max GPT-6 Sol +3.0 puntos por +48% +3.4 puntos por +100% GPT-6 Astra +1.3 puntos por +12% +0.3 puntos por +41% Claude Opus 5 +3.3 puntos por +65% +1.1 puntos por +20% Claude Opus 5.5 +2.4 puntos por +36% +1.6 puntos por +73% Claude Fable 5.1 +2.3 puntos por +31% +0.2 puntos por +28% En Fable 5.1 y GPT-6 Astra, el esfuerzo max no compra casi nada: 0,2 y 0,3 puntos por un 28 % y un 41 % más. En Opus 5.5, pasar a max aún compra 1,6 puntos, pero cuesta un 73 % más. Usa max solo en tareas donde hayas medido que los puntos extra cambian el resultado. Cuándo basta GPT-6 Sol max El índice es una media, y la distancia entre Sol max y Opus 5.5 medium no es uniforme. Puntuaciones por evaluación de Artificial Analysis: Evaluación Opus 5.5 medium ($1.34) GPT-6 Sol max ($1.06) Terminal-Bench 4.0 52.5 43.9 AutomationBench-AA 61.2 61.6 GDPval-AA (Elo) 1576 1487 AA-Briefcase (Elo) 1642 1483 Humanity's Last Exam 54.7 47.9 SciCode 59.3 57.6 CritPt 27.7 30.9 AA-LCR 84.3 83.7 En AutomationBench y CritPt, GPT-6 Sol iguala o supera a Opus 5.5 medium por 1,06 $ por tarea frente a 1,34 $. En Terminal-Bench, las evaluaciones de trabajo del conocimiento y Humanity's Last Exam, Opus 5.5 gana por mucho. La automatización de flujos de trabajo puede ir en Sol. Los agentes de terminal y de código y el trabajo del conocimiento con muchos documentos son donde Opus 5.5 justifica su precio. Cifras del proveedor frente a cifras independientes Las cifras del proveedor y las independientes suelen diferir, porque usan otros entornos de prueba y otros ajustes. Anthropic publica un 66,4 % en Terminal-Bench 4.0 para Opus 5.5 en xhigh. Artificial Analysis mide un 59,6 % con el mismo esfuerzo. Esfuerzo Opus 5.5 Fable 5.1 low 31.3% 40.4% medium 52.5% 44.9% high 56.6% 52.0% xhigh 59.6% 55.1% max 59.6% 52.0% La clasificación también cambia según el índice. En el Vals AI Index, Fable 5.1 es primero con 68,83 %, GPT-6 Astra tercero con 66,61 % y Opus 5.5 cuarto con 66,16 %. Allí no se publica el coste por tarea con la misma base, así que no mueve la frontera de arriba. Recuerda que un índice es solo una perspectiva. Precios de lista y una tarea con mucha caché Digital Applied calculó el precio de una tarea de agente con mucha caché en cada modelo: 8M tokens de lectura de caché, 400K de entrada sin caché, 600K de escritura en caché y 300K de salida. El resultado sigue la frontera, con una penalización adicional para GPT-6 Astra. Modelo Entrada $/MTok Salida $/MTok Lectura de caché $/MTok Tarea con mucha caché (Digital Applied) GPT-6 Sol $2.00 $10.00 $0.20 $6.90 Claude Opus 5.5 $4.00 $20.00 $0.20 $12.20 Claude Opus 5 $5.00 $25.00 $0.50 $17.25 Claude Fable 5.1 $10.00 $50.00 $0.25 $28.50 GPT-6 Astra (≤272K) $10.00 $50.00 $1.00 $34.50 GPT-6 Astra (>272K) $20.00 $75.00 n/a $61.50 GPT-6 Astra factura toda la petición a 20 $ y 75 $ por millón cuando la entrada supera los 272K tokens. Opus 5.5 mantiene un solo precio en toda su ventana de 1M tokens. En Opus 5.5, escribir en caché cuesta 5 $ por millón para la caché de 5 minutos y 8 $ para la de 1 hora, los lotes se facturan al 50 % y el modo rápido duplica el precio. Para los detalles, consulta Modelo de costes de Claude Opus 5.5 y Economía del modo rápido de Opus 5.5 . Cómo medir tu propio coste por tarea Registra tokens por tarea, no por petición: entrada sin caché, entrada en caché, escrituras en caché y salida, sumados en todos los pasos de la tarea. Toma una muestra de unos cientos de tareas reales y repítela en dos o tres configuraciones candidatas, por ejemplo Sol max, Opus 5.5 medium y Opus 5.5 high. Evalúa cada resultado con la misma comprobación que usas en producción y cuenta las tareas que la superan. Divide el gasto total entre las tareas superadas. El coste por tarea exitosa es la cifra que hay que comparar, porque una configuración barata que falla más no es barata. Elige la configuración más barata que cumpla tu listón de calidad y envía solo las tareas que fallen a una configuración superior. Repite la prueba cuando cambie un precio o un esfuerzo por defecto. Para ver cómo el esfuerzo cambia la factura de un mismo modelo, consulta Los niveles de esfuerzo de Opus 5.5 son el precio real . Advertencias Todos los costes son a precios de lista de la API sobre la mezcla de tareas de Artificial Analysis. Los descuentos, los lotes y tu propia caché los cambian. Artificial Analysis etiqueta sus entradas de Opus 5.5 y Fable 5.1 como Default Fallback. Revisa sus notas de metodología antes de tratar cada fila como la misma configuración de API. Las puntuaciones son solo de la versión v4.3.2 del índice. Las versiones anteriores usaban otras evaluaciones y no son comparables. La tarea con mucha caché de Digital Applied es una carga ilustrativa, no una medición. Las cifras cambian cuando los proveedores cambian precios o valores por defecto. La fecha de consulta es el 22 de septiembre de 2026. Fuentes Artificial Analysis Intelligence Index Artificial Analysis: Claude Opus 5.5 Artificial Analysis: Claude Opus 5 Artificial Analysis: Claude Fable 5.1 Artificial Analysis: GPT-6 Astra Artificial Analysis: GPT-6 Sol Digital Applied: GPT-6 Sol vs Claude Opus 5.5 cost benchmarks Digital Applied: Claude Opus 5.5 vs GPT-6 Astra Digital Applied: Is Claude Fable 5.1 still worth it? Digital Applied: Claude Opus 5.5 launch pricing and benchmarks Digital Applied: Opus 5.5 vs Grok 4.7 vs Muse Spark 1.3 cost per task Relacionado Modelo de costes de Claude Opus 5.5 Los niveles de esfuerzo de Opus 5.5 son el precio real Economía del modo rápido de Opus 5.5 ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Guía de Costes de Modelos de Razonamiento · FinOps LLM URL: https://finopsllm.com/es/research/reasoning-model-cost-guide Guía de Costes de Modelos de Razonamiento Actualizada 15 de julio de 2026 · publicada por primera vez 4 de julio de 2026 Los modelos de razonamiento como o3, o4-mini, DeepSeek-R1, QwQ, y MiMo generan tokens de "pensamiento" internos antes de producir salida. Este costo oculto puede inflar tu factura 5-30x. Esta guía desglosa cuándo los modelos de razonamiento valen la prima y cuándo un modelo estándar es el gasto más inteligente. 5-30x Multiplicador de coste 10 Modelos comparados 4 Proveedores Jul 2026 Última actualización Todos los precios en USD por 1 millón de tokens Los conteos de tokens de razonamiento varían por complejidad de tarea Los tokens de pensamiento se facturan como tokens de salida ¿Qué son los tokens de "pensamiento"? Los modelos de razonamiento gastan tokens en cadena de pensamiento interna antes de responder. Una pregunta simple podría desencadenar 2.000 tokens de pensamiento; una tarea de codificación compleja puede producir 30.000+. Estos tokens son invisibles en la respuesta de API pero se facturan a tarifas de salida - a menudo el nivel más caro. Metodología Precios estándar Precio de token de salida para finalización estándar (no razonamiento), desde páginas oficiales del proveedor. Precio de razonamiento Costo efectivo incluyendo tokens de pensamiento. Se mide como precio de salida estándar × multiplicador de pensamiento promedio para cada modelo. Multiplicador de pensamiento Proporción promedio de tokens totales facturados a tokens de salida visibles entre evaluaciones de codificación, matemáticas y análisis. Mejores casos de uso Tareas donde los modelos de razonamiento demuestran superioridad sobre modelos estándar por suficiente para justificar la prima de coste. Tabla de Precios de Modelos de Razonamiento Modelo ↕ Proveedor ↕ Salida Estándar $/1M ↕ Salida Razonamiento $/1M ↕ Multiplicador ↕ Mejores Casos de Uso Claude Fable 5 Anthropic $50.00 $200.00 4x Razonamiento frontera, vulnerabilidades complejas, análisis profundo Claude Opus 4.8 Anthropic $25.00 $100.00 4x Razonamiento frontera, análisis complejo, flujos agénticos GPT-5.6-Sol OpenAI $30.00 $120.00 4x Razonamiento frontera, código complejo, matemáticas, análisis multianivel GPT-5.6-Terra OpenAI $15.00 $60.00 4x Razonamiento, generación de código, análisis estructurado Grok 4.5 xAI $6.00 $24.00 4x Matemáticas, razonamiento, inteligencia general o3 OpenAI $8.00 $40.00 5x Codificación compleja, pruebas matemáticas, razonamiento profundo o4-mini OpenAI $4.40 $17.60 4x Razonamiento sensible al coste, codificación, análisis DeepSeek R1 DeepSeek $2.19 $8.76 4x Matemáticas, código, razonamiento, tareas en idioma chino Claude Sonnet 5 Anthropic $10.00 $40.00 4x Razonamiento general, codificación, análisis (equilibrado) GPT-5.5 (estándar) OpenAI $30.00 $30.00 1x Chat general, codificación, análisis complejo Cuándo Usar Modelos de Razonamiento 1) Codificación y depuración multianivel Los modelos de razonamiento destacan en tareas que requieren planificación: refactorizar múltiples archivos, depurar estados complejos, o escribir algoritmos con casos límite. Los tokens de pensamiento permiten al modelo "trabajar a través" del problema en lugar de simple coincidencia de patrones. Vale la pena la prima de 4-5x cuando la alternativa es un humano pasando 30+ minutos. 2) Pruebas matemáticas y lógicas Las tareas que requieren razonamiento formal - pruebas, problemas de optimización, satisfacción de restricciones - ven el mayor salto de calidad. Los modelos estándar a menudo producen respuestas plausibles pero incorrectas; los modelos de razonamiento se auto-verifican. La prima de coste se justifica cuando la corrección importa más que la velocidad. 3) Análisis de datos complejo con múltiples pasos Analizar un conjunto de datos con lógica condicional, referencias cruzadas de múltiples fuentes, o construcción de tuberías multianivel se beneficia de cadena de pensamiento. Un modelo estándar podría perder un paso; un modelo de razonamiento trabaja a través de cada uno explícitamente. Cuándo Evitar Modelos de Razonamiento 1) Extracción y formateo simple Extraer datos de documentos, reformatear JSON, resumir texto, o traducir contenido. Estas tareas necesitan coincidencia de patrones, no razonamiento. Usar o3 para extracción es como contratar un matemático para clasificar correo - caro e innecesario. 2) Cargas de trabajo de alto volumen y baja complejidad Generación de contenido, respuestas FAQ, respuestas básicas de chatbot, y etiquetado de datos. Con 10M+ tokens/mes, el multiplicador de razonamiento de 4-5x suma rápidamente. Un modelo estándar a $10/1M de salida vence un modelo de razonamiento a $40-60/1M para tareas donde la calidad es "suficientemente buena". 3) Aplicaciones sensibles a latencia Los modelos de razonamiento tardan más - los tokens de pensamiento añaden 2-10 segundos de latencia. Para chat en tiempo real, herramientas interactivas, o respuestas orientadas al usuario donde la velocidad importa, los modelos estándar entregan más rápido a menor coste. Estrategias de Optimización de Costes Enrutamiento por complejidad Usa un modelo estándar barato (GPT-4o-mini, Gemini Flash) como enrutador. Si la tarea es simple, responder directamente. Si es compleja, escalar a un modelo de razonamiento. Este patrón "cascada" puede reducir uso de modelos de razonamiento un 60-80% preservando calidad donde importa. Limita el presupuesto de pensamiento Algunos proveedores (OpenAI, Google) te permiten establecer un presupuesto máximo de tokens de pensamiento por solicitud. Limitar a 4.000-8.000 tokens de pensamiento previene costes descontrolados en tareas que no necesitan razonamiento profundo. Comienza ajustado y aumenta solo cuando baje la calidad. Cachea tus prompts Si tus tareas de razonamiento comparten un prompt de sistema común o contexto (base de código, documentación), el almacenamiento en caché de prompts puede reducir costes de entrada un 50-90%. Esto no reduce tokens de pensamiento pero reduce significativamente el coste por solicitud. Procesa razonamiento no urgente en lotes Para evaluaciones, generación de pruebas, o análisis que toleran latencia, las APIs de lotes ofrecen descuentos de 50%. Combinadas con modelos de razonamiento, obtienes el beneficio de calidad a mitad del costo de salida. Salida de razonamiento $/1M incluye tokens de pensamiento facturados a tarifas de salida. El multiplicador es promedio entre tareas típicas; el multiplicador real varía por complejidad de solicitud. DeepSeek R1 produce tokens de pensamiento por defecto. OpenAI o3/o4-mini cobra tokens de pensamiento por separado de la salida visible. Gemini 2.5 Pro cobra "tokens de pensamiento" a una tarifa reducida vs. salida visible - el multiplicador es costo combinado efectivo. Algunos enlaces pueden incluir códigos de referido. ¿Quieres esto aplicado a tu propio gasto en LLM? FinOps LLM realiza una auditoría gratuita de tus costes de IA y muestra dónde están los ahorros. Reserva auditoría gratuita → Volver a investigación FAQ ¿Qué es la metodología? Precio de token de salida para finalización estándar (no razonamiento), desde páginas oficiales del proveedor. Precio de razonamiento: costo efectivo incluyendo tokens de pensamiento. Se mide como precio de salida estándar × multiplicador de pensamiento promedio para cada modelo. ¿Qué es la tabla de precios de modelos de razonamiento? Salida de razonamiento $/1M incluye tokens de pensamiento facturados a tasas de salida. El multiplicador es promedio entre tareas típicas; el multiplicador real varía por complejidad de solicitud. DeepSeek R1 produce tokens de pensamiento por defecto. OpenAI o3/o4-mini cobra tokens de pensamiento por separado de la salida visible. ¿Cuándo usar modelos de razonamiento? Los modelos de razonamiento destacan en tareas que requieren planificación: refactorizar múltiples archivos, depurar estados complejos, o escribir algoritmos con casos límite. Los tokens de pensamiento permiten al modelo 'trabajar a través' del problema en lugar de simple coincidencia de patrones. ¿Cuándo evitar modelos de razonamiento? Extraer datos de documentos, reformatear JSON, resumir texto, o traducir contenido. Estas tareas necesitan coincidencia de patrones, no razonamiento. Usar o3 para extracción es como contratar un matemático para clasificar correo - caro e innecesario. ¿Qué son estrategias de optimización de costes? Usar un modelo estándar barato (GPT-4o-mini, Gemini Flash) como enrutador. Si la tarea es simple, responder directamente. Si es compleja, escalar a un modelo de razonamiento. Este patrón 'cascada' puede reducir uso de modelos de razonamiento un 60-80% preservando calidad donde importa. --- # El mismo modelo cuesta más en tu región · FinOps LLM URL: https://finopsllm.com/es/research/regional-pricing-premium Sobrecoste regional y de residencia de datos Actualizado September 1, 2026 · publicado originalmente September 1, 2026 Respuesta rápida: La tarifa con la que presupuestaste suele ser la de EE. UU. Enruta la misma petición por un endpoint europeo o asiático, o fíjala a una región por residencia, y el número cambia — a veces en el... La tarifa con la que presupuestaste suele ser la de EE. UU. Enruta la misma petición por un endpoint europeo o asiático, o fíjala a una región por residencia, y el número cambia — a veces en el precio del token, más a menudo en todo lo que lo rodea. De dónde sale el sobrecoste De cuatro sitios a la vez. Precio regional , que difiere según plataforma. Disponibilidad de modelos , que llega tarde fuera de la región primaria. Egress y latencia entre regiones . Y sobre todo menos funciones : si en esa región no hay caché de prompts o precio batch, pierdes los descuentos que ya habías dado por hechos. Ese último es el que muerde: una carga diseñada sobre caché y batch, movida a una región sin ellos, no cuesta un poco más; cuesta lo que habría costado sin optimizar. Decídelo, no lo heredes La residencia suele ser una obligación real, y entonces el sobrecoste es el precio de operar legalmente. El fallo es pagarlo para cargas que nunca lo necesitaron. Separa el tráfico por lo que es el dato. Lo personal o regulado, a la región conforme. Todo lo demás — herramientas internas, evaluaciones, datos sintéticos — donde salga más barato. Relacionado Atribución de costes de LLM ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # El bucle de reintentos que añade gasto de inferencia · FinOps LLM URL: https://finopsllm.com/es/research/retry-loop-hidden-spend El bucle de reintentos que añade gasto de inferencia Actualizado August 27, 2026 · publicado originalmente August 27, 2026 Respuesta rápida: Un reintento no es resiliencia gratuita: es otra llamada al modelo. Mide el impuesto de reintentos como gasto de reintentos y fallbacks dividido por todo el gasto de inferencia.Registra el árbol... Un reintento no es resiliencia gratuita: es otra llamada al modelo. Mide el impuesto de reintentos como gasto de reintentos y fallbacks dividido por todo el gasto de inferencia. Registra el árbol completo Guarda solicitud padre, intento, proveedor, modelo, herramienta, error, tokens y resultado. Las llamadas anidadas necesitan relaciones padre-hijo. Separa fallos Un límite de tasa puede merecer un reintento; un error de validación repetido no. Define intentos máximos por clase de fallo. Controla el bucle Usa límites de tokens por solicitud, dólares por flujo, intentos y tiempo. El límite duro debe detener el bucle en segundos, no esperar a una alerta mensual. No desactives todos los reintentos: haz que cada intento sea visible, limitado y justificado por un mejor resultado. Relacionado Límites de gasto de agentes ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Créditos de IA en SaaS: medir una unidad que no controlas · FinOps LLM URL: https://finopsllm.com/es/research/saas-ai-credits-metering Créditos de IA en SaaS: medir una unidad que no controlas Actualizado September 2, 2026 · publicado originalmente September 2, 2026 Respuesta rápida: FinOps en la nube asume una unidad legible: una hora de instancia, una petición, un gigabyte. Un crédito de IA no lo es. Es una unidad que el proveedor define, tarifica y puede redefinir durante la... FinOps en la nube asume una unidad legible: una hora de instancia, una petición, un gigabyte. Un crédito de IA no lo es. Es una unidad que el proveedor define, tarifica y puede redefinir durante la vigencia. Tres propiedades que rompen el manual La unidad es opaca: dos funciones consumen créditos muy distintos para lo que el usuario vive igual. La tarifa no es suya. Y las asignaciones caducan sin agruparse ni trasladarse. Mídalo igualmente Extraiga el consumo de la API de administración de forma programada y guárdelo junto a sus datos de coste, por usuario, equipo y función. El panel del proveedor muestra el periodo actual; sus preguntas son sobre la tendencia. Asigne antes de la factura Asocie los créditos a los mismos centros de coste que usa para la nube y publique showback mensual. El gasto sin asignar acaba en el presupuesto de plataforma, el equipo que menos influye en el consumo. Limite y alerte Prefiera un tope administrativo en la consola del proveedor: es el único control que detiene el gasto antes de incurrirlo. Si no existe, alerte sobre su propia medición con margen para actuar. Relacionado IA en la sombra en tarjetas corporativas ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Las herramientas de servidor no son tokens · FinOps LLM URL: https://finopsllm.com/es/research/server-tools-are-a-separate-invoice Las herramientas de servidor son otra factura Actualizado September 1, 2026 · publicado originalmente September 1, 2026 Respuesta rápida: La mayoría de los modelos de coste de LLM tienen un solo contador: tokens de entrada, tokens de salida, precio por millón. Eso era correcto cuando una petición solo generaba texto. Dejó de serlo... La mayoría de los modelos de coste de LLM tienen un solo contador: tokens de entrada, tokens de salida, precio por millón. Eso era correcto cuando una petición solo generaba texto. Dejó de serlo cuando llegaron las herramientas del lado del servidor. La búsqueda web, el fetch y la ejecución de código corren en la infraestructura del proveedor, y varias llevan su propio cargo por uso además de los tokens que producen. Un turno de agente puede cobrarte dos veces: por las búsquedas y por los tokens que sus resultados añadieron al contexto. La parte que se acumula El segundo cargo es el que se escapa. Cada resultado se añade a la conversación, y cada turno posterior reenvía todo como entrada. Diez búsquedas al principio de una ejecución larga no son diez cargos: son diez cargos más sus resultados releídos en cada turno siguiente. Por eso los costes de agente parecen no lineales cuando la aritmética de tokens dice que deberían serlo. La tarifa por uso es la parte visible; el crecimiento del contexto es la mayor, y aterriza en tu línea de tokens de entrada sin ninguna etiqueta. Atribúyelo o no podrás gestionarlo Registra las invocaciones por petición junto al objeto de uso: qué herramienta, cuántas llamadas y el tamaño en tokens de lo que añadió cada resultado. Ese último campo es el que hace visible la acumulación. Después calcula el coste por ejecución de agente, no por llamada a la API. La ejecución es lo que el usuario disparó de verdad. Tres controles que funcionan Limita las llamadas por ejecución. Un tope duro acota los dos cargos a la vez. Recorta lo que entra en el contexto. Rara vez necesitas una página entera; resumir antes de añadir reduce todos los turnos siguientes. Cachea el prefijo estable. Si el prompt de sistema y las definiciones de herramientas no cambian, el caché elimina el mayor coste repetido. Relacionado Economía del caché de prompts ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # La IA en la sombra va en tarjeta · FinOps LLM URL: https://finopsllm.com/es/research/shadow-ai-corporate-cards El gasto en IA fuera de tu factura de API Actualizado September 1, 2026 · publicado originalmente September 1, 2026 Respuesta rápida: Casi todas las organizaciones miden el coste de IA abriendo la consola del proveedor. Ese número es real y está bien instrumentado, y en muchas empresas es la mitad pequeña del total. La otra mitad... Casi todas las organizaciones miden el coste de IA abriendo la consola del proveedor. Ese número es real y está bien instrumentado, y en muchas empresas es la mitad pequeña del total. La otra mitad está en notas de gasto: suscripciones individuales de gente que necesitaba una herramienta y tenía tarjeta. Por qué es invisible Nunca toca tus claves de API, tu gateway ni tu telemetría. Llega como cargo por asiento, con importes lo bastante pequeños para aprobarse solos. Doscientas personas a veinte o treinta al mes son seis cifras anuales que ningún panel de ingeniería mostrará. Qué te cuesta de verdad El sobrecoste directo es lo de menos. Los planes individuales están muy por encima de las tarifas negociadas, y es común pagar dos veces al mismo proveedor. Peor: los planes de consumo tienen términos de retención y entrenamiento distintos de los que revisó tu equipo legal, no hay SSO, y el acceso no termina cuando termina el empleo. Cómo encontrarlo Pregunta a finanzas, no a ingeniería. Busca en gastos los nombres de proveedores y luego el patrón: cargos recurrentes mensuales de diez a cincuenta dólares. Y responde haciendo que el camino oficial sea más fácil que la tarjeta, no prohibiendo la tarjeta. Relacionado Atribución de costes de LLM ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Subida de Claude Sonnet 5 cancelada: $2/$10 permanente · FinOps LLM URL: https://finopsllm.com/es/research/sonnet-5-intro-pricing-deadline Claude Sonnet 5: la subida de precio de septiembre fue cancelada Publicado 19 de julio de 2026 Corrección, 2 de septiembre de 2026: la subida para la que se escribió este artículo no ocurrió. Anthropic la canceló: Claude Sonnet 5 se queda en $2/$10 por 1M tokens de forma permanente. El análisis del plazo se conserva tal cual se publicó, como registro; trata cada cifra «a partir del 1 de septiembre» como un escenario que nunca entró en vigor. Las tarifas actuales están en el rastreador de precios de APIs LLM . Anthropic lanzó Claude Sonnet 5 el 30 de junio de 2026 a precios introductorios de $2/1M tokens de entrada y $10/1M tokens de salida. Ese precio tiene una fecha límite definitiva: 31 de agosto de 2026 . A partir del 1 de septiembre, Sonnet 5 se traslada a precios estándar de $3/$15 por 1M, un aumento de costes del 50% plano . Si ejecutas cargas de trabajo de Sonnet 5, las próximas 6 semanas son tu ventana para fijar costes y planificar el aumento. Precios introductorios válidos hasta el 31 de agosto de 2026 solamente Precios estándar ($3/$15) comienzan el 1 de septiembre de 2026 El aumento de costes es exactamente del 50% para cargas de trabajo de Sonnet 5 Se aplica a la API de Anthropic, Bedrock y Vertex AI 43 días para volver a comparar, fijar compromisos y replantear presupuestos Fecha límite crítica: Los precios introductorios de Claude Sonnet 5 vencen en 43 días (31 de agosto de 2026). Una carga de trabajo de 10M tokens/mes pasará de $20 a $30/mes. Una carga de trabajo de 1B tokens/mes pasará de $2,000 a $3,000. Si Sonnet 5 está en tu ruta crítica, presupuesta el aumento ahora o desplaza cargas de trabajo antes del cambio. Las Matemáticas: Qué Significa el 50% a Escala El salto de precios introductorios a estándar es limpio y significativo. Modelemos una carga de trabajo realista: Perfil de Carga de Trabajo Tokens de Entrada Mensuales Tokens de Salida Mensuales Coste Agosto (Intro) Coste Septiembre (Estándar) Delta Mensual Impacto Anual Ligera (lote/interno) 50M 20M $200 $300 +$100 +$1,200 Nivel medio (orientada al cliente) 500M 150M $2,500 $3,750 +$1,250 +$15,000 Empresa (razonamiento de alto volumen) 2B 800M $12,000 $18,000 +$6,000 +$72,000 Pesada (flujos multi-solicitud) 5B 2.5B $35,000 $52,500 +$17,500 +$210,000 Insight clave: Una empresa con una carga de trabajo de Sonnet 5 de nivel medio (500M entrada + 150M tokens de salida/mes) verá un aumento mensual de $1,250 que se compone a $15,000 anuales si nada cambia. Para cargas de trabajo empresariales, el impacto anual puede exceder los $70K. A Quién Afecta La fecha límite se aplica en todos los canales: API de Anthropic (directa) Los precios introductorios terminan el 31 de agosto de 2026 a las 23:59 UTC. Verificado en la documentación de precios de Anthropic . No se ha anunciado ninguna prórroga o demora. AWS Bedrock Bedrock transfiere los precios de Anthropic. Los precios introductorios se aplican a Sonnet 5 en Bedrock hasta el 31 de agosto. El aumento aparecerá en tu factura de Bedrock el 1 de septiembre. Verifica tu contrato de AWS para cualquier descuento por compromiso que pueda compensar el aumento. Google Vertex AI Vertex AI integra modelos de Claude con transferencia de precios de Anthropic. La transición ocurre el 1 de septiembre. Las facturas de Vertex se cotizan en tu moneda local; confirma la fecha exacta con tu equipo de cuenta de Google si utilizas una zona horaria diferente. GitHub Copilot Enterprise Si Copilot usa Sonnet 5 como backend, Microsoft puede o no transferir el aumento de precio a tu plan. Copilot Enterprise es una licencia de asiento fijo, así que el impacto depende de si Microsoft absorbe o refleja el coste del backend. Verifica tu factura de Copilot o contacta a tu equipo de cuenta de Microsoft. Tres Estrategias: Qué Hacer Antes del 31 de Agosto Estrategia 1: Fija Compromisos de Uso (Si Están Disponibles) Verifica si Anthropic ofrece compromisos de uso o descuentos por volumen para Sonnet 5. Los descuentos basados en volumen o los acuerdos de prepago anual podrían reducir el aumento de precio efectivo. Contacta con ventas de Anthropic ahora: podrían mantener los precios introductorios en compromisos firmados antes del 31 de agosto. Acción: Envía correo a ventas de Anthropic antes del 15 de agosto si gastas >$5K/mes en Sonnet 5. Pregunta si un compromiso anual fija precios introductorios u ofrece descuentos escalonados. El tiempo de espera para contratos de compromiso es típicamente de 2–3 semanas. Estrategia 2: Vuelve a Comparar Enrutamiento y Mezcla de Modelos No todas las cargas de trabajo necesitan Sonnet 5. El salto de precio del 50% es una función de fuerza para auditar qué tareas realmente requieren Sonnet 5 y cuáles pueden cambiar a alternativas más baratas. Categoría de Tarea Entrada Sonnet 5/$1M Modelo Alternativo Entrada Alt/$1M Ahorros por 100M Tokens Cuándo Cambiar Clasificación (reglas estrictas) $3 (después de sep 1) Claude Haiku 4.5 $1.00 $200 Exactitud ≥95% Resumen $3 Gemini 2.5 Flash $0.15 $285 Sin razonamiento necesario Conversación multi-turno $3 GPT-5.6 Luna $1.00 $200 Calidad equivalente Razonamiento complejo (mantén Sonnet 5) $3 — — — Sin alternativa Bucles agénticos (multi-paso) $3 Híbrido Haiku + Sonnet 5 $1.00 (Haiku) + $3 (Sonnet 5) Ahorra usando Haiku para pasos simples Benchmarks soportan Acción: Durante las próximas 2 semanas, extrae tus registros de llamadas de Sonnet 5 y categoriza por carga de trabajo. Compara el 10% de tareas de clasificación en Haiku, resumen en Gemini 2.5 Flash, y multi-turno simple en GPT-5.6 Luna. Si la calidad es equivalente (o cercana), desplaza esa carga de trabajo antes del 1 de septiembre y fija los ahorros. Estrategia 3: Implementa (o Expande) Caché de Prompts El caché de prompts es la forma más directa de reducir el consumo de tokens y preservar el valor de los precios introductorios antes de que expiren. Las escrituras de caché a Sonnet 5 cuestan $2.50 por 1M tokens (1.25× precio de entrada en intro; será $3.75 en estándar). Las lecturas de caché cuestan $0.20 por 1M (0.1× precio de entrada en intro; será $0.30 en estándar). La oportunidad: Una carga de trabajo con una tasa de aciertos de caché del 40% ahorra un 36% en coste de entrada. Fijar infraestructura de caché ahora a precios introductorios significa que tus ahorros de tasa de aciertos en curso están heredados. Después del 1 de septiembre, los mismos aciertos de caché siguen siendo 90% de descuento, pero el precio base que descuentan es 50% más alto. Ejemplo: Prompt de sistema + contexto almacenado en caché 100M tokens/mes en Sonnet 5: Agosto (intro): Coste de escritura: 100M × $2.50/M = $250. Coste de lectura mensual (supón 1B tokens de lectura de aciertos de caché): 1B × $0.20/M = $200. Total: $450/mes para caché. Septiembre (estándar): Coste de escritura: 100M × $3.75/M = $375. Coste de lectura mensual: 1B × $0.30/M = $300. Total: $675/mes (50% más alto). Ahorros por implementar caché ahora: Si añades 500M tokens de entrada almacenados en caché entre ahora y el 31 de agosto, y acumulan 30 aciertos de caché cada mes a partir de septiembre, fijas descuentos de lectura acumulados. El coste de escritura de caché es una inversión que se amortiza durante meses. Acción: Identifica tus 3 prompts más repetidos o contextos de documento (documentos RAG, instrucciones del sistema, boilerplate). Prueba caché en API de Anthropic. Si la tasa de acierto es ≥20%, implementa antes del 31 de agosto. Las escrituras de caché son el único coste que no importa cuándo ocurra el aumento de tasa: invertir en coste de escritura ahora produce retornos de coste de lectura fijos para siempre. Cronograma: La Cuenta Regresiva de 6 Semanas Semana 1 (antes del 25 de julio) Audita el gasto actual de Sonnet 5. Extrae registros de llamadas (modelo, tokens, tipo de carga de trabajo) de tu panel de facturación o plataforma de observabilidad de LLM. Calcula la tasa de ejecución mensual. Modela gasto de Q4 si nada cambia. Semana 2 (antes del 1 de agosto) Contacta a ventas de Anthropic para investigar compromisos de uso. Comienza a comparar modelos alternativos (Haiku, Luna, Gemini 2.5 Flash) en el 10% del tráfico de producción. Identifica 3 candidatos principales para cambio de enrutamiento. Semana 3 (antes del 8 de agosto) Finaliza benchmarks y compromete un plan de enrutamiento. Si se necesitan cambios, comienza a desplegar pruebas A/B. Implementa caché de prompts para contextos repetidos de alto volumen. Destino ≥100M tokens almacenados en caché antes del cambio. Semana 4 (antes del 15 de agosto) Fija compromisos de uso con Anthropic (si aplicable). Despliega cambios de enrutamiento a producción (desplaza tareas de bajo razonamiento a modelos más baratos). Verifica que la infraestructura de caché está activa e hits en 15%+. Semana 5 (antes del 22 de agosto) Monitorea costes de producción y métricas de calidad. Ajusta enrutamiento si es necesario. Pronostica costes finales de septiembre basados en tasa de ejecución de agosto. Semana 6 (antes del 31 de agosto) Confirma que todos los cambios de enrutamiento están activos. Establece alerta en el calendario para el 5 de septiembre para verificar que la facturación coincide con el pronóstico. Publica análisis post-mortem sobre impacto de costes y ahorros logrados. Comparación: Sonnet 5 vs. Alternativas Después del 1 de Septiembre Una vez que expiren los precios introductorios, ¿cómo se compara Sonnet 5 con otros modelos a sus precios estándar? Modelo Proveedor Entrada $/1M Salida $/1M Caso de Uso Típico vs. Sonnet 5 Después de Sep 1 Claude Sonnet 5 (estándar) Anthropic $3.00 $15.00 Balance de velocidad y razonamiento Línea base GPT-5.6 Terra OpenAI $2.50 $15.00 Razonamiento nivel medio 17% más barato en entrada GPT-5.6 Luna OpenAI $1.00 $6.00 Clasificación rápida, tareas simples 67% más barato en general Gemini 3.1 Pro Google $2.00 $12.00 Bucles agénticos, uso de herramientas 33% más barato en entrada Gemini 2.5 Flash Google $0.15 $0.60 Ultra rápido, alto volumen 95% más barato Claude Haiku 4.5 Anthropic $1.00 $5.00 Clasificación baja latencia 67% más barato en entrada DeepSeek V4 Flash DeepSeek $0.14 $0.28 Optimizado para coste, modelo abierto 95% más barato (pero menos pulido) La realidad: Sonnet 5 a $3/$15 ya no es el modelo más barato o más rentable para la mayoría de tareas. GPT-5.6 Terra es 17% más barato en entrada. Haiku es 67% más barato para clasificación. El valor de Sonnet 5 después del aumento es en calidad para razonamiento complejo y velocidad para tareas equilibradas, no en liderazgo de costes. Las cargas de trabajo que no requieren esa calidad deberían moverse a alternativas ahora. Preguntas Frecuentes P: ¿Hay alguna posibilidad de que se extienda la fecha límite? R: Anthropic no ha anunciado una prórroga. El anuncio de lanzamiento del 30 de junio deja claro "hasta el 31 de agosto de 2026". Prepárate para la fecha definitiva. Si se anuncia una prórroga, es una bonificación; trata la fecha límite como final. P: ¿Afecta el nuevo tokenizador a los recuentos de tokens? R: Sí. Sonnet 5 usa un tokenizador nuevo que produce aproximadamente 30% más tokens que modelos Claude más antiguos para texto equivalente. Esto significa que tu gasto actual de tokens es más alto de lo que podrías esperar. Factoriza esto en pronósticos de costes. P: ¿Puedo fijar precios introductorios con prepago anual? R: Posiblemente, si Anthropic ofrece opciones de prepago. Contacta a ventas antes del 15 de agosto para preguntar. El prepago es a menudo la única forma de heredar precios a través de un aumento de tasa, pero necesitas comprometerte bien por adelantado. P: ¿Y si tengo un contrato personalizado con Anthropic? R: Los contratos personalizados pueden tener términos diferentes. Verifica la fecha exacta de cambio y tasa con tu equipo de cuenta. Si tu contrato especifica términos de precios, tienen prioridad sobre la página de precios público: confirma ahora antes de que el 1 de septiembre te sorprenda. La fecha límite del 31 de agosto es real, el aumento del 50% es cierto, y tienes 6 semanas para actuar. Los equipos que vuelven a comparar, fijan compromisos y desplazan cargas de trabajo antes del cambio cortarán significativamente su gasto en LLM de Q4. Los equipos que esperen hasta el 1 de septiembre absorberán el aumento de costes completo. Volver a investigación FAQ ¿Terminaron los precios introductorios de Claude Sonnet 5 el 31 de agosto de 2026? No. Anthropic canceló la subida prevista. Claude Sonnet 5 se mantiene de forma permanente en $2 por 1M de tokens de entrada y $10 por 1M de salida; la tarifa estándar de $3/$15 prevista para el 1 de septiembre de 2026 nunca entró en vigor. ¿Cuánto aumentará mi factura? Exactamente un 50% para cargas de trabajo de Claude Sonnet 5. Los precios de entrada suben de $2 a $3 por 1M tokens (+50%); la salida sube de $10 a $15 por 1M tokens (+50%). Una carga de trabajo que cuesta $10,000/mes en agosto costará $15,000/mes en septiembre si no cambia. ¿Se aplican los precios introductorios a Bedrock y Vertex? Los precios introductorios se aplican a la API directa de Anthropic. AWS Bedrock y Google Vertex AI transfieren los precios de Anthropic, por lo que el aumento se aplica también allí a partir del 1 de septiembre. Verifica los términos de tu contrato con tu proveedor de nube. ¿Qué debo hacer antes del 31 de agosto? 1) Fija compromisos de uso si están disponibles. 2) Vuelve a comparar el enrutamiento a Sonnet 5 frente a modelos más baratos (Haiku, Gemini 2.5 Flash). 3) Cambia prompts repetidas a caché de prompts (los descuentos de caché se escalan con el precio base, así que fijar ahorros de caché ahora es valioso). 4) Establece una alerta en el calendario para el 25 de ago para probar costes posteriores a la migración. 5) Modela el aumento en tu presupuesto de Q3 ahora. --- # El modelo anónimo gratis es un arma de precios · FinOps LLM URL: https://finopsllm.com/es/research/stealth-model-free-tokens-playbook El manual del modelo sigiloso Actualizado September 1, 2026 · publicado originalmente September 1, 2026 Respuesta rápida: Ox Alpha apareció en los agregadores de enrutamiento como un endpoint sin marca, gratuito, sin tarifa y sin laboratorio detrás. Después se confirmó que era GLM-5.3 y la ventana gratuita se cerró.... Ox Alpha apareció en los agregadores de enrutamiento como un endpoint sin marca, gratuito, sin tarifa y sin laboratorio detrás. Después se confirmó que era GLM-5.3 y la ventana gratuita se cerró. GLM-5.3-Flash cotiza ahora a 0,15 $ por millón de tokens de entrada y 0,50 $ de salida. Trátalo como una jugada repetible, porque lo es. Ya se ha usado con otros nombres y volverá a usarse. Qué compra el laboratorio con tokens gratis Tres cosas, todas más baratas que las alternativas. Evaluación ciega: a un endpoint sin marca se le juzga por la salida, no por el logotipo. Distribución: los agregadores le envían tráfico real de inmediato, sin acuerdos. Un ancla de precio: cuando se revela el nombre, los desarrolladores ya han decidido que el modelo es bueno. El número que importa al cerrarse la ventana Dieciséis billones de tokens de entrada pasaron por el endpoint gratuito. A 0,15 $ por millón son unos 2,4 millones de dólares de inferencia: eso es el tamaño del escalón si ese mismo tráfico simplemente se queda donde está. Haz esa cuenta con tu propia parte: el volumen que enviaste durante la ventana por la tarifa publicada es tu cambio mensual. Tres reglas para la próxima vez Nunca dependas de un endpoint cuyo dueño desconoces. Anónimo significa sin tarifa, sin política de obsolescencia y sin compromiso de tratamiento de datos. Sirve para evaluar, no para producción sin alternativa. Pon precio hipotético a toda evaluación gratuita y arrastra ese coste en la sombra en tu telemetría. Así la revelación es una revisión de precio, no un descubrimiento. Da por hecho que la ventana gratuita es la parte más corta de la relación. Mide también el coste de cambiar, no solo la calidad. Relacionado Arbitraje entre proveedores ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Las respuestas en streaming abandonadas siguen costando · FinOps LLM URL: https://finopsllm.com/es/research/streaming-abandoned-generations-cost Respuestas en streaming y generaciones abandonadas Actualizado September 9, 2026 · publicado originalmente September 9, 2026 Respuesta rápida: Cerrar la pestaña del navegador no detiene automáticamente la generación en el proveedor. Propague la señal de cancelación upstream para evitar el desperdicio. Cerrar la pestaña del navegador no detiene automáticamente la generación en el proveedor. Propague la señal de cancelación upstream para evitar el desperdicio. Relacionado Coste oculto en bucles de reintento ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # La salida estructurada no es gratis · FinOps LLM URL: https://finopsllm.com/es/research/structured-output-token-cost Coste en tokens del modo JSON y los esquemas Actualizado September 1, 2026 · publicado originalmente September 1, 2026 Respuesta rápida: Pedir salida estructurada parece una decisión de formato. En la factura es una decisión de volumen, y cae en tres sitios a la vez.El esquema es coste de entrada en cada peticiónEl esquema se serializa... Pedir salida estructurada parece una decisión de formato. En la factura es una decisión de volumen, y cae en tres sitios a la vez. El esquema es coste de entrada en cada petición El esquema se serializa dentro de la petición. Uno modesto son unos cientos de tokens; multiplícalo por cada llamada y cada turno durante la vida de la función. 400 tokens por un millón de llamadas son 400 millones de tokens de entrada para describir una forma que nunca cambia. Peor aún: si el esquema va después de la parte volátil del prompt, rompe el prefijo cacheado y destruye el descuento de todo lo anterior. La sintaxis es coste de salida Cada llave, comilla, coma y nombre de campo es un token generado que pagas a precio de salida. Nombres largos son un cargo recurrente para siempre. Los reintentos son lo caro Cada fallo de validación cuesta un reintento completo: toda la entrada otra vez y toda la salida otra vez. Un 2% de inválidos es un 2% más de coste sin nada a cambio. Qué hacer Pon el esquema en el prefijo estable para que cachee, pide solo los campos que consumes, usa nombres cortos y estructuras planas, y mide tu tasa de fallo de validación. Relacionado Economía del caché de prompts ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Frenar la cascada de subagentes y el gasto de tokens · FinOps LLM URL: https://finopsllm.com/es/research/subagent-fan-out-concurrency-limits Frenar la cascada de subagentes y delegación recursiva de tareas Actualizado September 19, 2026 · publicado originalmente September 19, 2026 Respuesta rápida: Las cascadas de subagentes suceden cuando un orquestador descompone una tarea en subtareas paralelas y permite que los agentes secundarios generen nuevos trabajadores. Sin límites estrictos de... Las cascadas de subagentes suceden cuando un orquestador descompone una tarea en subtareas paralelas y permite que los agentes secundarios generen nuevos trabajadores. Sin límites estrictos de concurrencia y profundidad, una sola petición de usuario puede desencadenar un crecimiento exponencial de llamadas, consumiendo millones de tokens en cuestión de minutos. Qué es una cascada de dispersión de subagentes Es un fallo arquitectónico en el que un agente orquestador genera recursivamente agentes hijos y nietos sin control presupuestario global, multiplicando el consumo de tokens en múltiples hilos paralelos. Medidas de protección esenciales Para evitar picos de costes incontrolados, las arquitecturas de producción aplican un límite estricto de profundidad (máximo nivel 2: supervisor a trabajador), una bolsa compartida de tokens asignada al hilo raíz, y límites de concurrencia de 3 a 5 agentes simultáneos. Relacionado Los tres presupuestos para agentes ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Los tres presupuestos que necesita todo agente autónomo · FinOps LLM URL: https://finopsllm.com/es/research/three-agent-budgets Los tres presupuestos que necesita todo agente autónomo Actualizado August 27, 2026 · publicado originalmente August 27, 2026 Respuesta rápida: Un agente autónomo necesita tres límites dentro de su bucle: presupuesto de solicitud, de flujo y diario. Cada uno captura un fallo distinto.SolicitudLimita tokens, herramientas, tiempo o dólares de... Un agente autónomo necesita tres límites dentro de su bucle: presupuesto de solicitud , de flujo y diario . Cada uno captura un fallo distinto. Solicitud Limita tokens, herramientas, tiempo o dólares de un intento. Se aplica antes de la llamada al proveedor y a cada herramienta. Flujo Sigue una intención completa a través de reintentos, fallbacks y subagentes. Usa un ID de correlación y un libro acumulado para detener bucles que no convergen. Diario Limita el gasto agregado de un equipo, cliente, función o cuenta. Al acercarse al límite, enruta trabajo elegible a modelos menores o batch. Denegaciones útiles Explica qué límite se activó, cuánto se consumió y cuál es la recuperación permitida. Registra reservas, gasto y denegaciones para conciliarlos con la factura. Los tres límites convierten un agente ilimitado en un sistema operable y auditable. Relacionado Límites de gasto de agentes ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Guía de implementación de presupuestos de tokens · FinOps LLM URL: https://finopsllm.com/es/research/token-budget-implementation-guide Guía de implementación de presupuestos de tokens Los presupuestos de tokens son la capa operativa del control de costes de LLM. La atribución te dice adónde va el dinero; los presupuestos eviten que vaya a lugares que no deseas. Sin presupuestos, un bucle de agente mal configurado o un aumento en el tráfico de usuarios puede agotar una asignación mensual en horas. Esta guía cubre cómo implementar cuatro tipos de presupuestos de tokens en producción, con pseudocódigo para cada patrón. Tipos de presupuesto Tipo de presupuesto Granularidad Aplicación Caso de uso Por solicitud Una sola llamada API Límite duro vía parámetro max_tokens Prevenir finalizaciones descontroladas, acotar latencia Cuota por equipo Equipo o proyecto durante un período Límite blando con alertas, límite duro en umbral Asignación de costes departamental, evitar que un equipo consuma presupuesto compartido Por período de tiempo Diario, semanal o mensual Límite duro con período de gracia Límites de presupuesto mensual, gasto a nivel de sprint Por flujo de trabajo Un solo pipeline o ejecución de agente Límite duro por paso y total Agentes multi-paso, pipelines de RAG, ejecuciones de evaluación Límites por solicitud El presupuesto más simple: limita cada solicitud con max_tokens . Esto no es opcional - cada solicitud de producción debe tener un límite explícito de tokens de salida. Sin él, una respuesta verbosa del modelo puede consumir tokens inesperados e inflar la latencia. // Aplicación de presupuesto por solicitud function llamarLLM(prompt, config): respuesta = proveedor.completar( prompt: prompt, modelo: config.modelo, max_tokens: config.max_tokens_salida, // límite duro temperatura: config.temperatura ) if respuesta.uso.tokens_totales > config.umbral_alerta: log.advertencia("Solicitud superó límite blando", tokens: respuesta.uso.tokens_totales, umbral: config.umbral_alerta ) return respuesta Cuotas por equipo Las cuotas por equipo requieren un contador compartido que persista entre solicitudes. El patrón: verifica el presupuesto restante antes de cada llamada, rechaza o degrada si el presupuesto se agotó. // Cuota de equipo con contador en Redis function verificarPresupuestoEquipo(equipoId, tokensEstimados): clave = "presupuesto:" + equipoId + ":" + periodoActual() restante = redis.obtener(clave) or obtenerCuotaEquipo(equipoId) if restante < tokensEstimados: if restante < tokensEstimados * 0.1: return DENEGAR // límite duro: rechazar solicitud else: return DEGRADAR // límite blando: usar modelo más barato return PERMITIR function registrarUso(equipoId, tokensReales): clave = "presupuesto:" + equipoId + ":" + periodoActual() redis.decrementar(clave, tokensReales) restante = redis.obtener(clave) if restante < obtenerCuotaEquipo(equipoId) * 0.2: alerta.cuotaBaja(equipoId, restante) Presupuestos por período de tiempo Los presupuestos por período de tiempo envuelven las cuotas de equipo con una ventana temporal. La diferencia clave: necesitas un mecanismo de período de gracia. Cuando un equipo alcanza el 80% de su presupuesto mensual, envía una alerta. Al 100%, permite un período de gracia configurable (por ejemplo, 24 horas) antes de que la aplicación dura entre en vigor. Esto evita que un equipo se bloquee a mitad de tarea el último día del mes. // Presupuesto por período con período de gracia function aplicarPresupuesto(equipoId): uso = obtenerUsoPeriodo(equipoId, mesActual()) limite = obtenerLimiteMensualEquipo(equipoId) if uso < limite * 0.8: return PERMITIR if uso < limite * 1.0: alerta.avisoPresupuesto(equipoId, uso, limite) return PERMITIR // zona de advertencia blanda if uso < limite * 1.1 and dentroPeriodoGracia(equipoId): alerta.presupuestoExcedido(equipoId, uso, limite) return PERMITIR // período de gracia: permitir exceso return DENEGAR // parada dura Presupuestos por flujo de trabajo Los agentes y pipelines multi-paso necesitan presupuestos en dos niveles: por paso (evita que un solo paso consuma demasiado) y por ejecución (evita que todo el pipeline exceda su asignación). Sigue ambos en el contexto del flujo de trabajo. // Rastreador de presupuesto de flujo de trabajo class PresupuestoFlujo: constructor(maxPorPaso, maxTotal): this.maxPorPaso = maxPorPaso this.maxTotal = maxTotal this.gastado = 0 function ejecutarPaso(fnPaso, prompt): if this.gastado >= this.maxTotal: return respuestaReserva("Presupuesto excedido") respuesta = llamarLLM(prompt, { max_tokens: min(this.maxPorPaso, this.maxTotal - this.gastado) }) this.gastado += respuesta.uso.tokens_totales return respuesta Degradación gradual cuando se excede el presupuesto No devuelvas simplemente un error cuando se alcanza un presupuesto. Degrada con gracia. Cambia a un modelo más barato (GPT-4o-mini en lugar de GPT-4o), reduce el tamaño de la ventana de contexto, omite pasos de procesamiento opcionales o devuelve un resultado parcial con una nota de que el procesamiento completo requiere aprobación de presupuesto. La experiencia del usuario debe degradarse, no romperse. // Cadena de degradación function llamarConDegradacion(prompt, config): if verificarPresupuesto(config.equipoId, MODELO_COMPLETO): return llamarLLM(prompt, { modelo: config.modeloPrimario }) if verificarPresupuesto(config.equipoId, MODELO_BARATO): log.info("Degradando modelo por presupuesto") return llamarLLM(prompt, { modelo: config.modeloReserva }) if verificarPresupuesto(config.equipoId, TOKENS_MINIMOS): truncado = truncarContexto(prompt, 50%) return llamarLLM(truncado, { modelo: config.modeloReserva, max_tokens: 256 }) return cacheadoOFallback(prompt) Monitorización de la salud del presupuesto Sigue tres métricas: tasa de consumo (tokens consumidos por hora vs. presupuesto), previsión (al ritmo actual, cuándo se agotará el presupuesto) y recuento de anulaciones (cuántas veces se usó el período de gracia). Si el uso del período de gracia supera el 10% de las solicitudes totales, el presupuesto está demasiado bajo para la carga de trabajo. Relacionado Gobernanza del presupuesto de LLM - políticas organizativas detrás de los presupuestos. Vallas de gasto de agentes - patrones de presupuesto para agentes autónomos. Cómo limitar costes de inferencia - controles de costes del lado del proveedor. ¿Quieres esto aplicado a tu propio gasto en LLM? FinOps LLM ejecuta una auditoría gratuita de tus costes de IA y muestra dónde están los ahorros. Reserva auditoría gratuita → Volver a investigación --- # Tokens más baratos, factura LLM más alta · FinOps LLM URL: https://finopsllm.com/es/research/token-prices-bill-keeps-rising Tokens más baratos, factura LLM más alta Actualizado August 27, 2026 · publicado originalmente August 27, 2026 Respuesta rápida: Un precio menor por token no garantiza una factura menor. En producción, el uso puede crecer más rápido que las tarifas: contextos más largos, más pasos de agentes, respuestas mayores y reintentos... Un precio menor por token no garantiza una factura menor. En producción, el uso puede crecer más rápido que las tarifas: contextos más largos, más pasos de agentes, respuestas mayores y reintentos pueden borrar una reducción del 40%. El diagnóstico útil separa cuatro variaciones: tarifa, volumen, mezcla y eficiencia. La tarifa es solo una parte Si el precio baja de 10 a 6 dólares por millón de tokens, pero el uso sube de 100 a 220 millones, la factura pasa de 1.000 a 1.320 dólares. El precio bajó 40%; la factura subió 32%. Mide por modelo y tipo de token: entrada, salida, caché y razonamiento no deben esconderse en un promedio. Volumen, mezcla y eficiencia Volumen es cuántos tokens consumes. Mezcla es dónde se consumen: un modelo premium o una función de contexto largo puede cambiar el gasto sin cambiar las solicitudes. Eficiencia es el coste por resultado útil: reintentos, herramientas fallidas, prompts enormes y texto que nadie usa. Cada llamada debe registrar proveedor, modelo, función, equipo, tokens, reintentos y resultado. Une esos eventos con la factura del proveedor; sin esa unión puedes explicar el uso, pero no demostrar el gasto. La revisión semanal Construye un puente desde la factura anterior: primero cambios de tarifa, luego volumen, mezcla y eficiencia. Alerta sobre el coste por tarea completada ajustado por tráfico, no solo sobre el crecimiento de tokens. Optimiza la categoría que produzca más dólares: contexto y bucles, routing, reintentos o compras. Los precios descendentes ayudan, pero no son una estrategia de control. El equipo necesita una vista reconciliada de precio, uso, mezcla, eficiencia y calidad. Relacionado Monitoreo de costes LLM Atribución de costes LLM Relacionado Monitoreo de costes LLM ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Los prompts largos tienen impuesto · FinOps LLM URL: https://finopsllm.com/es/research/verbose-prompt-tax Cómo el estilo de prompt aparece en la factura Actualizado September 1, 2026 · publicado originalmente September 1, 2026 Respuesta rápida: Los prompts crecen como los ficheros de configuración: alguien añade una instrucción por un fallo, otro añade un ejemplo, un tercero explica por qué. Nada se quita nunca. Seis meses después el system... Los prompts crecen como los ficheros de configuración: alguien añade una instrucción por un fallo, otro añade un ejemplo, un tercero explica por qué. Nada se quita nunca. Seis meses después el system prompt tiene tres mil tokens y nadie sabe cuáles doscientos sostienen el edificio. Por qué se acumula A diferencia de la salida, el sobrecoste del prompt se paga en cada petición , igual, para siempre. Mil tokens desperdiciados en una función con diez millones de llamadas al mes son diez mil millones de tokens mensuales de puro formato. En conversaciones multivuelta es peor: el system prompt se reenvía en cada turno. En bucles de agente, una sola acción del usuario puede facturar el mismo preámbulo una docena de veces. Qué desperdicia de verdad No la cortesía. El peso está en instrucciones redundantes, boilerplate defensivo escrito para una generación de modelos anterior, ejemplos que se duplican en vez de cubrir casos distintos, y explicaciones dirigidas a humanos que leen el fichero. Trátalo como código con presupuesto Mide el prompt fijo como porcentaje del tamaño medio de petición. Pon la parte estable primero para que cachee. Y recorta por ablación contra tus evals: quita un bloque, mide, consérvalo fuera si la calidad aguanta. Relacionado Economía del caché de prompts ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # Los agentes de voz cobran por minuto · FinOps LLM URL: https://finopsllm.com/es/research/voice-agents-bill-per-minute Economía unitaria de las APIs de audio en tiempo real Actualizado September 1, 2026 · publicado originalmente September 1, 2026 Respuesta rápida: Todo modelo de coste pensado para texto se rompe con la voz. El texto se factura por tokens, proporcionales a la información. El audio se factura por duración, proporcional al tiempo — incluido... Todo modelo de coste pensado para texto se rompe con la voz. El texto se factura por tokens, proporcionales a la información. El audio se factura por duración, proporcional al tiempo — incluido todo el tiempo en que no pasa nada útil. Qué pagas de verdad Una interacción de voz suele apilar tres o cuatro cargos: transcripción de entrada, la llamada al modelo (por minuto de audio en las APIs realtime), síntesis de salida y, a menudo, la sesión abierta. Ese último es la trampa: el silencio, a precio de minuto, es producto a tarifa completa. Dónde fallan las estimaciones Se modela tiempo hablado × tarifa y se queda corto. Faltan las pausas y la latencia, el audio generado que el usuario interrumpió, los reintentos (que repiten audio, no solo tokens) y las llamadas abandonadas. La métrica que funciona Coste por conversación completada, no por minuto. Y cierra las sesiones inactivas: suele ser el mayor ahorro disponible. Relacionado Economía de los agentes ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # ¿Qué es DeepSeek Harness? Guía completa · FinOps LLM URL: https://finopsllm.com/es/research/what-is-deepseek-harness ¿Qué es DeepSeek Harness? Guía completa Actualizado August 16, 2026 · publicado originalmente August 16, 2026 Respuesta rápida: DeepSeek Harness — nombre de paquete dsh — es un harness de agentes de código abierto publicado por DeepSeek AI con licencia MIT. Esta es la versión en lenguaje llano: qué es, cómo ejecutarlo, cómo... DeepSeek Harness — nombre de paquete dsh — es un harness de agentes de código abierto publicado por DeepSeek AI con licencia MIT. Esta es la versión en lenguaje llano: qué es, cómo ejecutarlo, cómo está construido y si debería importarle. Qué es en realidad un harness de agentes Un modelo genera texto y llamadas a herramientas. Eso es todo lo que hace. Todo lo demás que vuelve útil a un agente es el harness: montar el prompt, ejecutar de verdad las herramientas que el modelo pidió, imponer lo que tiene permitido hacer, registrar lo que ocurrió, gobernar el bucle que decide si se vuelve a llamar al modelo, y delegar trabajo en subagentes. Conviene interiorizar esta distinción antes que nada, porque casi todo lo que un agente hace bien o mal es comportamiento del harness y no del modelo. Dos equipos con el mismo modelo obtienen resultados muy distintos y facturas muy distintas, y la diferencia vive aquí. Qué hace DeepSeek Harness Ejecuta agentes de programación y automatización. En la práctica el agente lee y edita archivos, ejecuta comandos de shell, busca en el código, delega en subagentes, planifica trabajo y pide confirmación según la política de permisos activa. Hay una interfaz de navegador, un modo headless para ejecuciones únicas y un servidor de automatización que habla JSON-RPC por entrada y salida estándar. La única idea de diseño: todo es un plugin El harness corre sobre Cordis , un runtime de plugins donde cada plugin aporta servicios, eventos tipados y efectos reversibles a un contexto compartido. No hay núcleo privilegiado. El adaptador del modelo es un plugin. El registro de herramientas es un plugin. El registro de sesión es un plugin. El propio bucle del agente es un plugin. La mayoría de los sistemas extensibles ofrecen un núcleo fijo más hooks: puede observar y decorar, pero no sustituir, y sustituir significa bifurcar. Un runtime de plugins invierte eso: las piezas que más querría reemplazar son justamente las unidades de composición. Ponerlo en marcha La vía rápida npx @deepseek-ai/dsh web Eso levanta una interfaz web local en http://127.0.0.1:3080 . Desde el código fuente git clone https://github.com/deepseek-ai/deepseek-harness cd deepseek-harness pnpm install pnpm run build pnpm dsh web Requisitos: Node 22.19 o superior (la CI cubre 22.19, 24 y 26), Git 2.26 o superior y pnpm fijado con Corepack. Una clave de API de DeepSeek es opcional al instalar pero necesaria para hacer algo útil; puede venir del entorno o de un .env ignorado por git en la raíz del repositorio. Los dos pasos que todos se saltan Ajustes → Modelos. Introduzca su clave de API. La ruta se habilita al momento, sin reiniciar. Elegir espacio de trabajo. Añada y active el directorio de su proyecto. El compositor de sesión sigue deshabilitado hasta que haya un espacio activo, que es la razón habitual por la que una instalación recién hecha parece rota. Headless pnpm dsh --profile headless "summarize this workspace" Este es el modo que importa para la automatización, porque un harness que solo funciona de forma interactiva no se puede meter en CI, y lo que no está en CI no se puede medir con una cadencia. El vocabulario para leer la documentación Término Significado Paso (step) Una petición al modelo más las llamadas a herramientas que produce Turno (turn) Un vaciado de la entrada, que termina cuando el modelo se detiene o interviene la política Ronda (round) Una iteración de política por encima de los turnos, como un nuevo intento sobre un objetivo Sesión Un registro de solo anexado de eventos tipados: la única fuente de verdad de la ejecución Costura de capacidad Una interfaz de servicio con varias implementaciones intercambiables Perfil Una composición con nombre: lista ordenada de bundles de plugins más sus parches Scope La unidad de registro por agente para herramientas, prompts y restricciones La configuración se resuelve en cuatro capas, ganando la posterior: bundles del perfil, luego parches del perfil, luego parches a nivel de home, luego overlays de línea de comandos. Conocer ese orden convierte «por qué está usando ese modelo» de una investigación en una consulta. Por qué merece una mirada El modelo es intercambiable. El servicio de modelo es una interfaz con varios backends detrás, incluido uno que reproduce una sesión grabada sin volver a pagar inferencia. El bucle del agente consume un flujo neutral respecto al proveedor y nunca sabe qué backend está activo. El registro es completo por construcción. El principio rector es que lo visible para el modelo queda registrado, porque el registro tiene que poder reconstituir la ejecución. El consumo de tokens viaja adherido a la salida que lo causó. Los puntos de imposición son explícitos. Uno antes de que salga la petición al modelo, cuya decisión está documentada como autoritativa, y otro antes de que se ejecute el cuerpo de cualquier herramienta. Los guardas de permisos pueden denegar o abstenerse, nunca conceder, y una aprobación incontestable deniega. Funciona headless. Lo que significa que se puede guionizar, programar y medir. La afirmación sobre los plugins no es solo posicionamiento: una de las demos incluidas es autorreferencial e inspecciona y modifica su propio runtime de plugins en caliente. Eso es difícil de fingir. Cuándo usarlo y cuándo no Úselo para evaluar, para prototipar y como referencia concreta frente al stack de agentes que ya opera. Las cinco preguntas que conviene llevarse: ¿es intercambiable la elección de modelo?, ¿hay un registro de sesión completo con el consumo adjunto?, ¿existen puntos de imposición antes de la llamada al modelo y antes de ejecutar herramientas?, ¿funciona headless?, ¿está documentada la superposición de configuración? No estandarice sobre él este trimestre. El proyecto se describe como developer preview y afirma sin rodeos que habrá cambios que rompen compatibilidad. Fije la versión contra la que construya y no planifique migraciones de producción sobre una API en preview. Cuánto cuesta operarlo El harness es MIT y gratuito. La inferencia no. Usted aporta una clave de API de DeepSeek o apunta la costura de modelo a otro proveedor. La implicación práctica es que su factura es función de los pasos por turno, las herramientas del catálogo, la profundidad de delegación y cuántas rondas puede correr un objetivo abierto: todas decisiones de nivel harness, ninguna de ellas el precio por token que negoció. Relacionado Instalación, perfiles y primera ejecución (EN) Qué aporta de verdad «todo es un plugin» (EN) El registro de sesión como registro de costes (EN) Dónde poner los límites de gasto (EN) ¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita → Volver a finopsllm.com --- # FinOps LLM - Gestion des coûts d’IA et observabilité LLM URL: https://finopsllm.com/fr/ FINOPS · LLM Basé sur les principes de la Fondation FinOps · adapté aux tokens Contrôle des coûts d'IA pour l' ère des tokens. FinOps LLM est la plateforme de gestion des coûts d'IA et d'observabilité LLM pour les équipes d'ingénierie exécutant l'IA générative en production. Attribution en temps réel sur OpenAI, Anthropic, Bedrock et Gemini · détection des anomalies , chargeback et optimisation automatisée (routage, cache, compression) · réconciliation mensuelle par rapport aux factures brutes des fournisseurs. Réservez un audit gratuit → Voir la plateforme Audits basés sur les factures Réduction typique de 40–60% Lecture seule par défaut Multi-cloud app.finopsllm.com / customer-042 / overview DEMO Espace de travail ◧ Aperçu ◫ Attribution 12 ⚡ Anomalies 3 ↗ Prévisions Optimisation ◊ Routage ⌬ Cache ≡ Compression Finance $ Chargeback ▥ Budgets ✓ Réconciliation Aperçu Dépenses Qualité Réconciliation Dépenses du mois à ce jour $70 280 ↓ 57,4% vs. ligne de base Économies d'exemple $94 720 réconciliées avec facture Taux de succès du cache 38.1% +4,2 pts semaine/semaine Delta de qualité +0,2% Test A/B actif 7 jours Dépenses LLM quotidiennes · 45 derniers jours 5 avr - 5 mai 2026 Ligne de base ($165K/mois) Optimisé ($70,3K/mois) Attribution des dépenses · ce mois par fonctionnalité RAG · 38% Agent · 26% Email · 18% Classif. Autre Recherche RAG $26,7K Exécutions d'agent $18,3K Rédaction d'email $12,6K Classification $7,7K Flux d'activité Dernières 24 heures · voir tout ! Anomalie : dépenses p95 RAG +38% vs. moyenne 7 jours 14:22 UTC · feature/rag-v2 · enquêter → $ Routage v3 promu à 100% du trafic 11:08 UTC · économies projetées : $4 820/mois + Taux de succès du cache a dépassé le seuil de 38% 09:14 UTC · invalidation affinée ⚑ Budget · équipe « agent » à 78% du mois à ce jour 06:42 UTC · limitation automatique activée ✓ Réconciliation avr 2026 signée 1er mai · −57,4% vs. ligne de base Réconcilié par rapport à tous les principaux fournisseurs OpenAI Anthropic Gemini Bedrock Azure Groq Together Mistral 01 La plateforme FinOps pour l'IA, en quatre piliers. FinOps LLM apporte le cadre de la Fondation FinOps - visibilité, attribution, optimisation, responsabilité - aux dépenses LLM et GenAI. Même discipline. Unité de coût différente. PILIER 01 Visibilité Données de coût au niveau des tokens ingérées de chaque fournisseur. Réconciliées chaque heure. Filtrables par fournisseur, modèle, fonctionnalité, équipe, client, environnement. OpenAI · Anthropic · Bedrock · Gemini · Azure · Groq · Together Ingestion horaire · délai de réconciliation <5 min Lecture seule par défaut · NDA et DPA sur demande PILIER 02 Attribution et chargeback Chaque token mappé à une fonctionnalité, une équipe et une cohorte de clients. Chargeback et showback mensuels, exportés vers votre système financier ou en CSV. Dimensions personnalisées · fonctionnalité, équipe, niveau, région Dépenses par cohorte · P&L par niveau client NetSuite · QuickBooks · CSV · API PILIER 03 Détection des anomalies Alertes en temps réel quand les dépenses, la latence ou la qualité s'écartent de la ligne de base mobile d'une fonctionnalité. Slack, PagerDuty, email - et limitation automatique quand cela compte. Lignes de base mobiles par fonctionnalité · conscientes de la saisonnalité Slack · PagerDuty · email · webhook Limitation automatique optionnelle et conformité budgétaire PILIER 04 Optimisation automatisée Routage des modèles, cache sémantique et compression des invites déployés derrière des feature flags, testés A/B pendant au moins sept jours, promus uniquement aux gains de qualité et de coût. Arbre de routage · classification de qualité par requête Cache sémantique · latence de succès <10 ms SLO de qualité + rétraction automatique en cas de régression 02 Optimisation Six leviers que nous actionnons, à chaque engagement. La plupart des équipes en combinent trois ou quatre. L'audit classe lesquels dominent votre surface de dépenses et projette les économies avant tout engagement. 01 30–50% Routage des modèles Chaque requête classée par complexité et routée vers le modèle le moins cher qui répond à votre standard de qualité. Raisonnement vers les modèles phares ; classification et extraction vers les modèles petits et rapides. 02 20–40% Cache sémantique Invites quasi-dupliquées identifiées avec des embeddings ; réponses identiques servies depuis le cache <10 ms. Seuils de similarité affinés par fonctionnalité. 03 15–30% Compression des invites Invites système auditées pour la redondance. Exemples dédupliqués. Contexte récupéré comprimé avec des techniques de style LLMLingua. Chaque changement testé A/B. 04 10–50% Tarification par lot et asynchronisme Charges de travail non interactives routées vers des points de terminaison par lot (jusqu'à 50% de remise) avec mise en file d'attente consciente du SLO pour les itinéraires sensibles au temps. 05 20–35% Arbitrage des fournisseurs La capacité identique coûte souvent 2–3× plus cher chez un fournisseur. Nous routons par capacité par dollar, pas par le SDK avec lequel votre équipe a commencé. 06 5–15% Chaînes de secours Les tentatives intelligentes et les secours échelonnés surpassent le surprovisionnement du pire cas. Maintenez le SLO sans payer les prix des modèles phares à chaque appel. 03 Engagement Auditez. Implémentez. Réconciliez. Répétez. Chaque engagement suit les mêmes quatre phases. La plupart des clients voient leur première facture de fournisseur réconciliée à la fin de la semaine cinq. 01 SEMAINE 01 AUDIT Mappez chaque dollar. Nous ingérons les factures des fournisseurs, les journaux des passerelles et la télémétrie d'utilisation. Le vendredi, vous avez une carte complète de vos dépenses LLM - par fournisseur, modèle, fonctionnalité, équipe - classées par gaspillage en dollars. Livrable Carte des dépenses · opportunités priorisées · ligne de base fixe (contresignée) 02 SEMAINE 02 PLAN Classifiez par gaspillage. L'audit se transforme en un plan d'ingénierie priorisé respectant votre posture de conformité, vos SLO de latence et votre processus de lancement. Garde-fous de qualité convenus par point de terminaison. Signatures à chaque changement. Livrable Plan d'ingénierie · arbre de routage · spécification de cache · SLO de qualité · calendrier de lancement 03 SEMAINES 03–05 LANCEMENT Lancez et testez A/B. Les ingénieurs de FinOps LLM s'associent aux vôtres pour lancer chaque optimisation derrière des feature flags, tester A/B pendant sept jours par rapport à la ligne de base, et promouvoir à 100% du trafic. Le cockpit s'active en même temps. Livrable Cockpit actif · alertes Slack · examen hebdomadaire · première réconciliation 04 CONTINU RÉCONCILIEZ Composez les économies. Les prix se déplacent. Le trafic change. Les modèles se lancent. La plateforme surveille la dérive ; nous recommandons et implémentons les suites pour que les économies se composent. Chaque mois se termine par une Déclaration d'Économies signée. Livrable Déclaration mensuelle signée · alertes de dérive et qualité · ajustement continu 04 Résultats Nombres des engagements réels. Plages de réduction illustratives des leviers d'optimisation LLM courants. Les objectifs réels sont définis après un audit de facture de fournisseur et un examen de la charge de travail. Réduction typique 40–60 % Plage entre les engagements, selon l'architecture et le mélange du trafic. Temps aux économies 3–5 sem Lancement → première facture de fournisseur réconciliée. Delta de qualité +0 ,2 % Chaque changement testé A/B minimum 7 jours. Frais d'audit $0 Gratuit - crédité contre l'implémentation. 05 Tarification Payez sur résultats. Il y a un seul engagement et il est facturé sur les économies vérifiées. Tidal Telemetry est un logiciel distinct, gratuit en bêta. ★ PLUS POPULAIRE Performance Audit gratuit. Ensuite, vous ne payez que si nous vous économisons de l'argent - mesuré par rapport à une ligne de base fixe, réconcilié avec les factures des fournisseurs. 15–25 % des économies vérifiées Pas d'économies, pas de frais · audit crédité contre l'implémentation · annulez à tout moment ✓ Audit gratuit · turnaround d'1 semaine · ligne de base contresignée ✓ Pile d'optimisation complète · routage, cache, compression, arbitrage ✓ Cockpit actif + chargeback + déclarations mensuelles signées ✓ Appairage d'ingénierie avec l'équipe FinOps LLM · examens hebdomadaires ✓ Conformité du SLO de qualité et rétraction automatique ✓ Minimum : dépenses LLM de $20K/mois Réservez un audit gratuit → LIBRE-SERVICE · PRODUIT DISTINCT Tidal Telemetry Logiciel d'observabilité que vous installez et exploitez vous-même. Aucun engagement géré, aucun filtre commercial. Gratuit en bêta sans carte bancaire · les utilisateurs bêta gardent un plan gratuit ✓ Une ligne de code · ~50 bibliothèques auto-instrumentées ✓ Ingestion OpenTelemetry standard · le SDK est optionnel ✓ Coût par appel, tokens, latence et erreurs en traces ✓ Stockage et clé d’ingestion isolés par projet ✓ Serveur MCP intégré pour une configuration par agents ✓ Aucun prérequis d’engagement · utilisable sans nous parler Voir Tidal Telemetry → 06 Questions fréquentes Questions courantes. Vous ne trouvez pas ce que vous cherchez ? Envoyez un email à hello@finopsllm.com - nous répondons en un jour ouvrable. Qu'est-ce que FinOps pour LLM ? + FinOps pour LLM apporte le cadre de la Fondation FinOps - visibilité, attribution, optimisation et responsabilité - aux dépenses LLM et GenAI. Cela inclut le chargeback et le showback par fonctionnalité et équipe, la détection des anomalies, la gouvernance budgétaire et l'optimisation continue du routage des modèles, du cache et des invites. Que fait FinOps LLM ? + FinOps LLM est un engagement géré, pas une licence de plateforme. Nous fournissons l'attribution des dépenses en temps réel sur OpenAI, Anthropic, Bedrock et Gemini, plus l'optimisation automatisée (routage, cache, compression) et la réconciliation mensuelle par rapport aux factures des fournisseurs. Comment la tarification est-elle structurée ? + Un seul modèle. Audit gratuit, ensuite 15–25% des économies mensuelles vérifiées, mesurées contre une ligne de base figée avant tout changement. Pas de licence, pas de sièges, pas de minimum plateforme. Tidal Telemetry est un produit distinct et gratuit en bêta. Combien pouvons-nous économiser ? + La réduction typique au cours du premier cycle de facturation complet après la mise en œuvre est 40–60% , selon l'architecture et le mélange du trafic. Quels fournisseurs sont pris en charge ? + OpenAI, Anthropic, Gemini & Vertex AI, AWS Bedrock, Azure OpenAI, Groq, Together, Mistral, Cohere, Fireworks, Replicate , et la plupart des points de terminaison OSS. Les déploiements multi-fournisseurs ont généralement la plus grande surface d'économies. FinOps LLM supporte-t-il le chargeback et le showback ? + Oui. Attribution au niveau des tokens aux fournisseurs, aux modèles, aux fonctionnalités, aux équipes et aux cohortes de clients. Chargeback et showback mensuels exportés vers NetSuite, QuickBooks, CSV ou API . Les dimensions personnalisées sont prises en charge. Comment traites-tu les données client ? + Lecture seule par défaut. Les données de facturation et d'utilisation sont suffisantes pour la plupart du travail d'attribution. Les données d'invites et de sorties ne sont accessibles qu'avec l'approbation explicite du client, pour les optimisations spécifiques qui l'exigent. NDA et DPA disponibles sur demande. Combien de temps prend la mise en œuvre ? + L'attribution et les tableaux de bord sont activés en moins d'une semaine . La mise en œuvre de l'optimisation prend 3–5 semaines ; les économies apparaissent sur la première facture complète du fournisseur après le lancement. L'optimisation endommagera-t-elle la qualité de sortie ? + Non. Chaque changement de routage, cache et compression est testé A/B par rapport à la production pendant minimum sept jours avant la promotion. Les régressions sont automatiquement rétractées. La qualité est continuellement surveillée aux côtés du coût. 07 Ressources Guides, benchmarks & outils. Recherche approfondie pour les leaders en ingénierie et finance évaluant FinOps pour l'IA. Gratuit, sans inscription, mis à jour mensuellement. GUIDE ↗ FinOps pour LLM : un cadre complet Visibilité, attribution, optimisation, responsabilité - appliqués aux tokens. Avec une architecture de référence de 30 pages. 16 MIN · MAI '26 NOUVEAU GUIDE SEO -> Optimisation des coûts d'IA Un playbook pratique pour réduire les dépenses d'IA par le routage, le cache, les lots et la discipline des invites. 8 MIN MAI '26 TUTORIEL ↗ Attribution des coûts au niveau des tokens en production Stratégies de tagging, mathématiques du chargeback et modèles d'intégration de passerelle. Avec code de référence. 11 MIN · CODE 4.2K LECTURE OPÉRATIONS ↗ Surveillance des coûts LLM Les métriques, alertes et limites des propriétaires qui empêchent les changements de dépenses de se cacher dans les factures mensuelles. 10 MIN OPS GUIDE ↗ Détection des anomalies de coûts LLM avant la facture Lignes de base par fonctionnalité, saisonnalité et comment câbler les alertes que les ingénieurs ne désactiveront pas. 9 MIN · MODÈLES 3.1K LECTURE RAG -> Optimisation des coûts RAG Réduisez le gaspillage de tokens impulsé par la récupération avec un meilleur chunking, des limites de contexte plus strictes et un reclassement sélectif. 7 MIN PRATIQUE RÉFÉRENCE ↗ Glossaire FinOps IA Définitions pour l'attribution, showback, chargeback, tokens de lecture de cache, routage et coût par tâche réussie. RÉFÉRENCE GRATUIT FINANCES ↗ Chargeback et showback LLM Comment rapporter les dépenses d'IA par équipe et produit avant de les convertir en allocation budgétaire. 8 MIN GOUVERNANCE OPENAI ↗ Attribution des coûts OpenAI Request tags, réconciliation des factures, retries et classes de charge de travail pour les dépenses OpenAI. 7 MIN PRATIQUE ANTHROPIC -> Attribution des coûts Anthropic Suivre les dépenses Anthropic par fonctionnalité, propriétaire, charge de travail et comportement de routage sans rompre la réconciliation. 7 MIN NOUVEAU ROUTAGE ↗ Routage des modèles Comment envoyer les demandes faciles à des modèles moins chers tout en conservant la qualité, la latence et le comportement de repli. 12 MIN ALGO MÉTRIQUES -> Suivi des tokens LLM Les champs au niveau de la demande qui rendent explicables les changements de coûts d'IA pour l'ingénierie et la finance. 6 MIN OPS PRIX ↗ Arbitrage des fournisseurs Comparez les capacités de modèles équivalentes entre fournisseurs sans sous-estimer les coûts de migration et les frais généraux. 11 MIN BENCHMARKS DONNÉES ↗ Benchmark prix par capacité LLM · Q2 '26 Coût par tâche réussie mensuel sur GPT, Claude, Gemini, Mistral, Llama, sur les charges de travail standardisées. MIS À JOUR MENSUELLEMENT Q2 '26 EN DIRECT ÉTUDES DE CAS ↗ Résultats client Les études de cas publiques seront publiées uniquement après approbation du client. Jusque-là, les références d'évaluation sont gérées de manière privée. SOUS NDA HONNÊTE 08 Commencez ici Mettez votre facture IA sous supervision sérieuse. Environ une semaine. Accès en lecture seule. Nous revenons avec une cartographie complète de votre dépense, classée par gaspillage, plus une ligne de base que notre salle de contrôle peut suivre. Gratuit. Aucun engagement de mise en œuvre. Réservez votre audit gratuit → Voir les benchmarks DÉCOUVERTE DE 30 MIN · LECTURE SEULE PAR DÉFAUT · NDA + DPA SUR DEMANDE · AUCUN ENGAGEMENT --- # Recherche · FinOps LLM URL: https://finopsllm.com/fr/research Recherche Notes pour les équipes d'ingénierie et de finance construisant la gouvernance des dépenses d'IA. Commencer ici Explications claires si vous découvrez les coûts des LLM. Comment les fournisseurs de LLM facturent-ils? Tokens d'entrée, de sortie, de cache et de raisonnement expliqués Qu'est-ce que l'attribution des coûts des LLM? Pourquoi ma facture LLM explose-t-elle? Comment budgétiser les dépenses d'IA Toute la recherche A quarter of AI spend is slipping to 2027 (EN) Agent spend attribution (EN) Agent spend guardrails (EN) Agent Spend Guardrails: Runtime Controls That Work (EN) Agent TCO: The 70% of Cost That Isn't Tokens (EN) Agents en arrière-plan et horloge FinOps AI Coding Economics 2026: GLM vs DeepSeek vs Claude (EN) AI Cost Allocation: Tags, Cost Centers and Chargebacks (EN) AI Cost Optimization Checklist for 2026 (EN) AI Cost Optimization: Routing, Caching, Batching (EN) AI Cost Optimization: Six Levers That Actually Work (EN) AI cost recovery playbook: stop the bleeding (EN) AI FinOps : le modèle opérationnel des dépenses GenAI AI observability: cost, traffic, and quality · FinOps LLM (EN) Ajouter la provenance à vos sorties IA Anthropic cost attribution (EN) Attribution des coûts d'OpenAI Attribution des coûts des LLM Azure OpenAI vs OpenAI Direct : comparatif de coûts et PTU Baisses de prix des modèles et budget de routage Batch APIs as a FinOps lever (EN) Boucle de reprises et coût d’inférence Calculatrice de coût LLM : dépenses IA mensuelles Ce que coûtent les garde-fous et la modération Chargeback et showback des LLM Chargeback vs Showback: Picking the Right FinOps Model (EN) Chargeback when your provider won't bill per team (EN) ChatGPT Pro Max $500 plan economics (EN) Chiffrer un modèle à poids ouverts Claude Max 20x isn't 20x. We checked 60 days of logs against Codex (EN) Claude Max 20x vs 5x: is the $200 price worth it? We measured the real weekly usage ceiling (EN) Claude Max vs Alibaba Token Pro: le coût réel du codage agentique Claude Sonnet 5.5 pricing: what changes, what does not (EN) Claude Sonnet 5.5: the cost-aware model routing guide (EN) Cloud Infrastructure Cost Audit: Alibaba vs Claude Max (EN) Codex auto-compact on GPT-6 Sol: the defaults in the source code, and what raising them costs (EN) Codex usage limit resets: how they work, banked resets and a dated log (EN) Combien Coûte GPT-5 ? Guide Complet des Tarifs 2026 Comment auditer votre dépense LLM en 30 minutes Comment fonctionne le filigrane IA Comment les filigranes IA disparaissent Comparaison des Plans de Codage IA Contrôler le coût dans le pipeline d’évaluation LLM Contrôler le coût en tokens des schémas MCP pour les agents Cost per request as a product KPI (EN) Coût de conformité du filigrane IA Coût en tokens du mode JSON et des schémas Coût par asset validé en image et vidéo Coût réel d’un changement de fournisseur LLM Coût réel par tâche des modèles de pointe Crédits d’IA SaaS : mesurer une unité que vous ne contrôlez pas Cursor vs Copilot vs Claude Code Cost (EN) DeepSeek Harness : ce que « tout est un plugin » apporte vraiment DeepSeek Harness : installation, profils et premier lancement DeepSeek Harness : le guide complet DeepSeek Harness : objectifs, tours d'objectif et boucle Ralph DeepSeek Harness : portées, restrictions et masquage d'outils Dépense LLM hors production Détection d'anomalies de coûts des LLM Écart de dépenses IA: volume, tarif, mix et efficacité Économie d'Opus 5.5 fast mode Économie de l'Arrêt du Fine-Tuning OpenAI Économie des agents : le vrai coût d'un agent de codage Économie unitaire des API audio temps réel Enterprise AI procurement and committed spend (EN) Eval cost allocation: who pays for LLM evals (EN) Exposition au change dans la dépense LLM Find the cache miss behind your OpenAI bill (EN) FinOps pour LLM et GenAI : un cadre pratique FOCUS 1.5 : suivi natif des jetons IA et Price Sheet Gartner's 2026 AI spending forecast (EN) GenAI cost management: controls and analytics (2026) (EN) Génération de code par IA la moins chère (2026) GPT-5 Pricing and Budget Impact: A 2026 Planning Guide (EN) GPT-5 vs GPT-4o Cost Comparison: When to Upgrade (EN) GPT-6 Astra cost model (EN) GPT-6 Luna cost model (EN) GPT-6 pricing: Astra, Sol and Luna (EN) GPT-6 Sol cost model (EN) GPT-6 Sol long-context benchmarks: what has actually been measured, and what is GPT-5.6 Sol (EN) Guide de mise en œuvre des budgets de tokens Guide de Tarification GPT-5.6 : Luna, Terra, Sol Guide des Coûts des Modèles de Raisonnement Hausse Claude Sonnet 5 annulée : 2 $/10 $ permanent Hidden LLM Costs Beyond Per-Token Pricing (EN) How do LLM providers charge? Tokens, tiers, caching (EN) How many tokens do you get with Claude Pro and Max? We counted them (EN) How much Codex does ChatGPT Pro include? We priced the weekly limit in dollars (EN) How to budget for AI spend: a starter framework (EN) How to cap inference costs and prevent runaway spending (EN) How to check and reduce Claude Code token usage (EN) How to use Jev in an AI agent (EN) Impact des serveurs MCP sur les coûts Input, output, cache, reasoning: what tokens cost (EN) Invoice reconciliation for AI spend (EN) IT Chargeback and Showback Explained (EN) IT Chargeback and Showback for AI: A Practical Guide (EN) IT Showback: A Practical Guide for Technology Teams (EN) L'observabilité comme seconde facture IA L’offre gratuite comme coût d’acquisition La dépense IA hors de votre facture d’API Latest AI models and Anthropic's proposed IPO (EN) Le coût par tâche réussie vaut mieux que le coût par requête Le coût récurrent des embeddings et du vector store Le journal de session de DeepSeek Harness comme registre de coûts Le manuel du modèle furtif Le style de prompt sur la facture Les niveaux d'effort d'Opus 5.5 sont le vrai prix Les outils serveur sont une facture à part Les trois budgets dont tout agent autonome a besoin Limiter la dérive des sous-agents et la délégation récursive LLM Budget Governance: Alerts and Guardrails (EN) LLM Cost Benchmarks by Industry (EN) LLM cost dashboard: what to put on it (EN) LLM Cost Management: A Practical Framework (EN) LLM Cost Monitoring in Production: A Field Guide (EN) LLM cost monitoring: what to track and how to control it (EN) LLM Cost Per User Benchmarks (EN) LLM Cost Tracking: Tools, Tags and Telemetry (EN) LLM Cost Visibility: Dashboards and Metrics That Matter (EN) LLM FinOps standards (EN) LLM Provider Arbitrage: Price and Quality Parity (EN) LLM Purchasing Guide for Platform Teams (EN) LLM Token Tracking by Input, Output and Cache (EN) LLM Usage Metering: How to Bill Internal AI Spend (EN) Long context vs RAG: where the cost breakeven actually is (EN) Mesurer la marge brute d’une fonctionnalité d’IA avant le lancement Minimax M3.1 Flash free preview economics (EN) Model deprecation migration: budgeting for forced moves (EN) Model Routing: Cheaper Models, Same Output Quality (EN) Modèle de coût de Claude Fable 5.1 Modèle de coût de Claude Opus 5.5 Multi-provider, multi-team LLM FinOps (EN) Multimodal cost allocation (EN) NVIDIA Open Agent Safety Platform: the FinOps implications (EN) On-prem and self-hosted LLM FinOps (EN) Open source vs propriétaire : comparaison des coûts LLM OpenAI agent message board cost model (EN) OpenAI O / AON always-on agent cost model (EN) OpenAI Ultra Fast API pricing and speed tiers (EN) OpenTelemetry GenAI conventions for cost attribution (EN) Opus 5.5 long-running agent cost analysis (EN) Order of LLM cost optimizations (EN) Où placer les garde-fous de dépense dans DeepSeek Harness Ox Alpha était GLM-5.3 Payer deux fois la fenêtre de contexte Première clôture mensuelle IA Prix des fournisseurs IA non comparables Prompt cache attribution (EN) Prompt caching explained (EN) Prompt Caching ROI: Calculating Real Savings (EN) Prouver le ROI IA sans masquer la qualité RAG cost optimization (EN) Rate limits, 429 et montées de palier Real-SWE cost per resolved issue (EN) Reasoning token attribution and chargeback (EN) Recherche web et centre de coût des agents Réflexion adaptative et prévision des coûts Remises pour engagement de dépense Runbook de production pour un pic de coûts LLM Semantic cache economics (EN) Sept motifs défensifs tirés de la documentation DeepSeek Harness September 2026 AI model trends (EN) Showback vs Chargeback: Which Model Fits Your Team? (EN) Silent model downgrades and cost models (EN) Six Jev use cases that actually fit (EN) Sous-agents DeepSeek Harness : la délégation comme multiplicateur de coût State of FinOps 2026: 98% now manage AI spend (EN) Stratégies de cache comparées Streaming et coût des générations abandonnées Suivi des Prix des API LLM Surcoût régional et résidence des données System One Models and Jev cost optimization (EN) Tendances des coûts LLM 2025–2026 The Token Count Is Lying: Claude Max vs Qwen Audit (EN) The True Cost of Coding Agents: Beyond the API Bill (EN) Token budget implementation (EN) Tokens moins chers, facture LLM plus élevée What independent Jev tests say about cost (EN) What is AI value management? (EN) What is LLM cost attribution? A plain-English explainer (EN) What is LLM FinOps? A plain-English definition (EN) What is the Tokenomics Foundation? (EN) Where Jev belongs in an agent workflow (EN) Why agentic AI blows the budget (EN) Why does my LLM bill spike? The most common causes (EN) Why Jev is catching on with agent builders (EN) Why Showback Comes Before Chargeback in FinOps (EN) Vous voulez l'appliquer à vos propres dépenses en LLM? FinOps LLM réalise un audit gratuit de vos coûts d'IA et vous montre où se trouvent les économies. Réservez votre audit gratuit → Retour à FinOps LLM --- # La réflexion adaptative a cassé vos prévisions · FinOps LLM URL: https://finopsllm.com/fr/research/adaptive-thinking-cost-forecast Réflexion adaptative et prévision des coûts Mis à jour September 1, 2026 · première publication September 1, 2026 Réponse rapide: Le budget de raisonnement était un nombre que vous fixiez. Vous passiez budget_tokens: N, et N servait à la fois de contrôle et de prévision : au pire, chaque requête coûtait N tokens de... Le budget de raisonnement était un nombre que vous fixiez. Vous passiez budget_tokens: N , et N servait à la fois de contrôle et de prévision : au pire, chaque requête coûtait N tokens de raisonnement. Ce paramètre est déprécié sur Opus 4.6 et Sonnet 4.6, et sur les modèles les plus récents — Fable 5 et 5.1, Sonnet 5, Opus 5, 4.8 et 4.7 — l’envoyer renvoie une 400 . Il est remplacé par thinking: {type: "adaptive"} : le modèle décide de l’effort selon la difficulté. Ce qui change dans les chiffres Le coût moyen par requête baisse généralement, car les requêtes faciles cessent de payer un raisonnement inutile. La variance augmente , car les requêtes difficiles ne sont plus tronquées à votre plafond. Un budget exprimé en maximum par requête n’a plus de prise. Prévoyez la distribution, pas le plafond Suivez les tokens de raisonnement comme série distincte : ils figurent déjà dans l’objet d’usage de chaque réponse. Budgétez par centiles : un p50 et un p99 par route plutôt qu’un « N tokens par requête ». Alertez sur le ratio, pas sur le total : la part des tokens de raisonnement dans le total bouge en premier quand un changement de prompt fait travailler le modèle davantage. Où un plafond reste pertinent Les limites de dépense par route et par locataire fonctionnent toujours et attrapent toujours les boucles emballées. C’est là que doit vivre le garde-fou : à la frontière que vous maîtrisez. À lire aussi Attribution des tokens de raisonnement Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Ajoutez la provenance à vos sorties IA en un jour · FinOps LLM URL: https://finopsllm.com/fr/research/add-provenance-to-your-ai-output Ajouter la provenance à vos sorties IA Mis à jour September 1, 2026 · première publication September 1, 2026 Réponse rapide: Commençons par ce que vous ne pouvez pas faire. Le filigrane textuel est appliqué par le fournisseur pendant la génération : aucun paramètre ne l’active ou le désactive, et on ne peut pas l’ajouter... Commençons par ce que vous ne pouvez pas faire. Le filigrane textuel est appliqué par le fournisseur pendant la génération : aucun paramètre ne l’active ou le désactive, et on ne peut pas l’ajouter après coup. Si vous voulez un signal plus fort, la réponse n’est pas d’ajouter du marquage, mais d’ajouter un enregistrement. Cet enregistrement est peu coûteux, entièrement sous votre contrôle, et c’est lui qu’on produit réellement quand on vous demande de prouver l’origine d’une sortie. La plupart des équipes le construisent en une journée, car il est à une jointure de la télémétrie déjà collectée pour l’attribution des coûts. Les quatre champs Pour chaque artefact généré, journalisez l’ identifiant et la version exacts du modèle , la région , l’ horodatage et un identifiant d’artefact stable qui suit la sortie dans toute la chaîne. C’est ce dernier que les équipes omettent et regrettent ensuite. Si vous émettez déjà des enregistrements d’usage par requête, trois des quatre y sont. Ce qui manque, c’est la jointure : votre télémétrie de coût sait qu’une requête a eu lieu et ce qu’elle a coûté, mais pas quel artefact elle a produit. Conservez le manifeste signé Quand le fournisseur vous remet un fichier signé C2PA, l’objectif est simple : ne pas le perdre. Configurez explicitement vos transformations d’images pour préserver les métadonnées, et ré-attachez la provenance après tout ré-encodage que vous maîtrisez. Marquez aussi pour les humains Marquage lisible par machine et mention visible répondent à des problèmes différents. Une étiquette « généré avec de l’IA » ne coûte rien, n’est affectée par aucune transformation, et c’est ce que l’utilisateur lit réellement. L’un ne remplace pas l’autre. À lire aussi Comment les filigranes IA disparaissent Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Économie des agents : le vrai coût d'un agent de codage · FinOps LLM URL: https://finopsllm.com/fr/research/agent-economics Économie des agents : quel est le vrai coût d'un agent de codage ? Les agents de codage sont la catégorie de dépenses LLM à la croissance la plus rapide en 2026. Chaque équipe d'ingénierie en utilise une ou évalue une. Mais les modèles de tarification sont confus : les plans d'abonnement cachent les limites de tokens derrière un langage « illimité », les agents basés sur API exposent des coûts bruts qui augmentent de manière imprévisible, et aucun des deux modèles ne vous dit ce que vous payez réellement par tâche complétée. Cet article détaille l'économie réelle des cinq agents de codage les plus populaires, introduit une métrique de « coût par tâche utile » et explique pourquoi les agents basés sur API peuvent être à la fois moins chers et plus chers que les plans d'abonnement selon les modèles d'utilisation. Le paysage tarifaire Les agents de codage se divisent en deux catégories tarifaires. Les agents d'abonnement facturent des frais mensuels fixes avec utilisation incluse. Les agents basés sur API facturent par token consommé, généralement via votre propre compte fournisseur. Le choix correct dépend du nombre de tâches que vous exécutez, de la taille de votre base de code et de la complexité de vos invites. Agent Plan Coût mensuel Tokens/requêtes inclus Tâches estimées/mois Coût par tâche Modèle principal Cursor Pro $20/mois 500 requêtes rapides (modèles premium) ~80–150 $0,13–$0,25 Claude Sonnet 4, GPT-4.1 GitHub Copilot Pro+ $39/mois 1 500 requêtes premium ~150–300 $0,13–$0,26 Claude Sonnet 4, GPT-4.1 GitHub Copilot Pro $10/mois 300 requêtes premium ~30–60 $0,17–$0,33 GPT-4.1, Claude Sonnet 4 Claude Code API (Max optionnel) $5–$100+ Paiement à l'usage via API Anthropic ~20–200+ $0,25–$2,00 Claude Sonnet 4 Cline API (BYOK) $5–$80+ Paiement à l'usage via n'importe quel fournisseur ~20–200+ $0,20–$3,00 Configuré par l'utilisateur Windsurf Pro $15/mois 500 crédits (modèles premium) ~60–120 $0,13–$0,25 Claude Sonnet 4, GPT-4.1 Ce que « coût par tâche » signifie vraiment Le tableau ci-dessus montre la fourchette annoncée, mais le coût réel par tâche dépend de trois facteurs cachés : le chargement de la fenêtre contextuelle, les chaînes d'appels d'outils et les boucles de tentatives. Une tâche « simple » comme l'ajout d'un nouvel endpoint API peut consommer 15 000–40 000 tokens au cours de la session. Un refactoring complexe affectant plusieurs fichiers peut facilement dépasser 200 000 tokens. Le chargement de la fenêtre contextuelle est le coût caché le plus important. Chaque agent de codage charge vos fichiers ouverts, la structure du projet et l'historique récent de la conversation dans chaque appel API. Un projet avec des fichiers volumineux signifie plus de tokens par requête, même si vous posez une question simple. Les appels d'outils multiplient cela : chaque opération de lecture de fichier, recherche ou édition est un aller-retour API séparé avec le contexte complet. Coûts cachés que la plupart des équipes négligent Boucles de tentatives. Quand la première tentative d'un agent échoue les tests ou le linting, il réessaie automatiquement. Chaque tentative est un appel API au prix complet. En pratique, 20–40 % des sessions d'agent impliquent au moins une tentative, ajoutant 30–80 % au coût en tokens de cette tâche. Débordement contextuel. Les sessions longues atteignent les limites contextuelles. Quand cela se produit, l'agent ou résume le contexte antérieur (en perdant les détails) ou supprime les messages antérieurs (en perdant le contexte). Les deux aboutissent à une sortie de moins bonne qualité et à plus de tentatives. Surcharge des appels d'outils. Une seule tâche peut impliquer 5–15 appels d'outils (lire un fichier, rechercher du code, éditer un fichier, exécuter des tests). Chaque appel d'outil inclut le contexte complet de la conversation plus la définition de l'outil. Les définitions d'outils seules peuvent consommer 2 000–5 000 tokens du prompt système par appel. Requêtes premium inactives. Les plans d'abonnement comptent les « requêtes rapides » même quand l'agent renvoie une sortie inutile. Une suggestion rejetée coûte toujours une requête premium. API vs abonnement : quand chacun gagne Les agents basés sur API (Claude Code, Cline) gagnent quand votre utilisation est sporadique ou légère. Si vous exécutez 20–40 tâches ciblées par mois, payer $0,30–$0,80 par tâche est moins cher qu'un abonnement de $20–$39. Ils gagnent aussi quand vous avez besoin d'un modèle spécifique pour une tâche spécifique : vous payez uniquement pour ce que vous utilisez. Les agents d'abonnement (Cursor, Copilot, Windsurf) gagnent quand l'utilisation est régulière et intensive. Si vous exécutez plus de 100 tâches par mois, le coût effectif par tâche tombe sous $0,20, ce qui est difficile à battre avec la tarification API. Ils gagnent aussi en prévisibilité : les équipes financières peuvent budgétiser un montant fixe. Le point de croisement est généralement 40–80 tâches par mois pour un seul développeur. Sous ce seuil, la tarification API est moins chère. Au-dessus, les plans d'abonnement offrent une meilleure économie. La métrique « coût par tâche utile » Le coût brut par tâche est trompeur car toutes les tâches ne produisent pas de valeur. Une session d'agent qui échoue, renvoie une réponse incorrecte ou nécessite un travail manuel supplémentaire a un coût réel de zéro sortie utile. La métrique qui compte est : Coût par tâche utile = Dépense mensuelle totale / Tâches qui ont été livrées sans retouches manuelles En pratique, les équipes signalent que 60–80 % des tâches d'agent produisent une sortie utilisable au premier essai. Les 20–40 % restants nécessitent une intervention manuelle. Cela signifie que le coût effectif par tâche utile est 1,25x–1,7x le coût brut par tâche. Pour les équipes qui construisent avec des modèles open-source ou explorent des alternatives rentables, des plateformes comme MiMO offrent une tarification compétitive qui peut modifier le calcul API vs abonnement. Comment réduire les coûts des agents Réduisez le contexte. Fermez les fichiers non pertinents avant d'invoquer l'agent. Moins de contexte = moins de tokens par appel. Écrivez des invites spécifiques. Les invites vagues mènent à plus d'appels d'outils et de tentatives. « Ajouter un endpoint POST /users qui valide l'email » coûte moins que « réparer le truc des utilisateurs ». Utilisez des modèles spécifiques à la tâche. Les éditions simples ne nécessitent pas un modèle de raisonnement. Acheminées les éditions standard vers des modèles moins chers et les refactors complexes vers les modèles premium. Surveillez l'utilisation des tokens. Suivez le nombre de tokens par session. Si le coût moyen par session augmente, vos invites ou votre base de code peuvent croître plus vite que prévu. Définissez des limites de tentatives. Limitez les tentatives automatiques à 2–3 par tâche. Au-delà, escaladez vers un humain. Qu'attendre ensuite La tarification des agents évolue rapidement. Les plans d'abonnement augmentent les limites incluses à mesure que la concurrence s'intensifie. Les prix API continuent de baisser : Claude Sonnet 4 coûte 60 % moins que Claude 3.5 Sonnet à son lancement. Les modèles de codage open-source comblent l'écart de qualité, ce qui devrait faire baisser les prix API encore davantage. La plus grande tendance est la tarification spécifique aux agents. Les fournisseurs expérimentent avec la tarification par tâche, les limites par session et la facturation pondérée par la qualité. D'ici fin 2026, attendez-vous à ce que la plupart des agents offrent une garantie de « coût par tâche réussie » plutôt qu'une facturation brute par tokens. Connexe Comparaison des plans de codage IA - benchmark basé sur des preuves. Attribution des dépenses d'agents - comment suivre les coûts des agents par projet et équipe. Garde-fous des dépenses d'agents - définir des limites avant que les coûts ne s'envolent. FinOps pour LLM - le cadre plus large. Voulez-vous que cela s'applique à vos propres dépenses LLM ? FinOps LLM effectue un audit gratuit de vos coûts en IA et vous montre où se trouvent les économies. Réservez votre audit gratuit → Retour à la recherche --- # La recherche web devient un centre de coût des agents · FinOps LLM URL: https://finopsllm.com/fr/research/agent-web-search-cost-center Recherche web et centre de coût des agents Mis à jour September 10, 2026 · première publication September 10, 2026 Réponse rapide: Les agents passent des connaissances statiques au web en temps réel. Une tâche utilisateur peut générer plusieurs requêtes payantes et autant d'appels de synthèse. La recherche web devient une ligne... Les agents passent des connaissances statiques au web en temps réel. Une tâche utilisateur peut générer plusieurs requêtes payantes et autant d'appels de synthèse. La recherche web devient une ligne de facturation à part entière. Amplification des requêtes par le planificateur Mesurez le coût du modèle et celui de la recherche ensemble pour obtenir le coût total par tâche réussie. À lire aussi Coût par tâche réussie Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Marge brute d’une fonctionnalité d’IA avant lancement · FinOps LLM URL: https://finopsllm.com/fr/research/ai-feature-gross-margin Mesurer la marge brute d’une fonctionnalité d’IA avant le lancement Mis à jour September 2, 2026 · première publication September 2, 2026 Réponse rapide: L’inférence est un coût de service, pas un coût de développement. Elle s’exécute à chaque action client et croît avec l’usage. La traiter comme de la R&D jusqu’au lancement revient à découvrir la... L’inférence est un coût de service, pas un coût de développement. Elle s’exécute à chaque action client et croît avec l’usage. La traiter comme de la R&D jusqu’au lancement revient à découvrir la marge réelle avec la première facture complète. Instrumenter avant de lancer En préproduction, étiquetez chaque appel par compte, flux et résultat, et rejouez un trafic réaliste. Ce qu’il faut : le coût par tâche réussie aux p50, p90 et p99, plus la part payée en échecs et reprises. Coût par compte Multipliez le coût par tâche réussie par le volume mensuel attendu et ajoutez les échecs. Comparez au prix du plan à l’usage médian, au 90e centile et sur le compte le plus lourd acceptable. Quatre facteurs de coût Contexte renvoyé à chaque tour, reprises facturées plein tarif, éclatement agentique d’une action en de nombreux appels, et routage envoyant les cas simples vers un modèle coûteux. Relier à une décision Plafond d’usage, part de consommation dans le prix, modèle par défaut moins cher, ou marge assumée avec date de revue. Présentez-la comme une ligne dédiée de la marge brute. À lire aussi Coût par tâche réussie Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # AI FinOps : le modèle opérationnel des dépenses GenAI · FinOps LLM URL: https://finopsllm.com/fr/research/ai-finops AI FinOps pour les équipes en production AI FinOps est le modèle opérationnel pour gérer les dépenses d'IA une fois que les modèles deviennent partie du produit. Ce n'est pas juste de l'observabilité, et ce n'est pas juste de l'approvisionnement. C'est une boucle entre l'ingénierie, le produit et la finance : comprendre où vont les dépenses, assigner la responsabilité, améliorer les économies unitaires et vérifier les changements par rapport à la facture. Les charges de travail LLM rendent cela urgent car les dépenses augmentent avec l'utilisation, la longueur du contexte, la longueur de la sortie, les nouvelles tentatives et le choix du modèle. Un petit changement de produit peut changer la facture sans changer l'infrastructure. Les meilleurs programmes AI FinOps vivent donc près de la passerelle de modèle et de la pile d'analyse de produit. Ce dont AI FinOps a besoin Normalisation des factures des fournisseurs. Métadonnées au niveau des requêtes et propriété du produit. Métriques de coût par tâche réussie. Budgets qui alertent avant la fin du mois. Playbooks d'optimisation pour le routage, le cache, le batching et la structure des prompts. Par où les équipes commencent Commencez par la visibilité et le showback. Montrez à chaque équipe produit ses dépenses en LLM, les endpoints qui les pilotent et les changements d'un mois à l'autre. Ensuite, choisissez le plus grand facteur contrôlable. Dans la plupart des équipes, c'est le routage de modèles, la compaction du contexte, le cache des prompts, le cache sémantique ou le déplacement du travail non urgent vers les APIs batch. AI FinOps devient mature quand il fait partie de la revue de lancement : chaque changement orienté modèle a un objectif de qualité, un objectif de latence, un impact sur les dépenses et un plan de retrait. Connexes Qu'est-ce que FinOps pour LLM? - la discipline opérationnelle qui gère les dépenses en LLM. FinOps pour les LLM - le modèle opérationnel en détail. Attribution des coûts des LLM - comment fonctionne l'allocation. Gouvernance du budget des LLM - budgets et chemins de dégradation. Vous voulez que cela s'applique à vos propres dépenses en LLM? FinOps LLM réalise un audit gratuit de vos coûts d'IA et montre où se trouvent les économies. Réservez votre audit gratuit → Retour à la recherche --- # Écart de dépenses IA: volume, tarif, mix et efficacité · FinOps LLM URL: https://finopsllm.com/fr/research/ai-spend-variance-bridge Écart de dépenses IA: volume, tarif, mix et efficacité Mis à jour August 27, 2026 · première publication August 27, 2026 Réponse rapide: Décomposez l’écart prévision-réel en volume, tarif, mix et efficacité, puis reliez chaque ligne aux factures et à un responsable.Les quatre causesLe volume est la demande; le tarif le prix facturé; le... Décomposez l’écart prévision-réel en volume , tarif , mix et efficacité , puis reliez chaque ligne aux factures et à un responsable. Les quatre causes Le volume est la demande; le tarif le prix facturé; le mix le déplacement entre modèles, fournisseurs ou charges; l’efficacité le coût du même résultat utile, reprises et réparation comprises. Construire le pont Partez de la prévision, appliquez tarif, volume, mix et efficacité, puis rapprochez le total des factures. Chaque ligne doit avoir preuve, dollars, responsable et action. Ajoutez la qualité pour éviter le faux gain. À lire aussi Suivi des coûts LLM Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Le filigrane IA est devenu une ligne de coût · FinOps LLM URL: https://finopsllm.com/fr/research/ai-watermarking-compliance-cost Coût de conformité du filigrane IA Mis à jour September 1, 2026 · première publication September 1, 2026 Réponse rapide: Anthropic intègre un filigrane imperceptible dans le texte produit par les modèles Claude compatibles et signe les fichiers .svg, .png et .jpg avec des métadonnées de provenance C2PA. La technique... Anthropic intègre un filigrane imperceptible dans le texte produit par les modèles Claude compatibles et signe les fichiers .svg , .png et .jpg avec des métadonnées de provenance C2PA. La technique suit l’approche SynthID-Text : elle biaise l’aléa utilisé pour choisir les tokens, sans changer le sens ni la qualité. Le 1er septembre 2026, une API de détection a été ouverte aux régulateurs, médias, vérificateurs, chercheurs et entreprises soumises à leurs propres obligations. Le marquage est mondial, pas seulement européen. Il découle de l’article 50 du règlement européen sur l’IA, en vigueur depuis le 2 août 2026. Aucun supplément n’est facturé, et c’est exactement pourquoi il échappe aux revues budgétaires : le coût est réel, il n’est simplement pas sur la facture. Où part réellement l’argent Migration des modèles épinglés sur des versions non marquées; modification des chaînes de traitement d’images qui suppriment les métadonnées; démarche d’accès à la détection; conservation de l’identifiant de modèle, de la version, de la région et de l’horodatage pour chaque appel. Quatre coûts réels, aucun tarif. Le piège de la version épinglée Épingler une version exacte est une bonne pratique, mais une version antérieure à août 2026 peut ne pas porter de marquage lisible par machine. Si vous servez des utilisateurs européens, cette décision de stabilité devient un écart de conformité, et le remède est une migration non planifiée : réévaluation, ajustement des prompts, tests et nouveau prix. Inventoriez chaque épinglage et datez-en la revue. Votre chaîne d’images efface la preuve Les métadonnées C2PA vivent dans le fichier, et les générateurs de vignettes, transformations CDN et convertisseurs de format les suppriment par défaut pour économiser des octets. Testez la chaîne complète, de la génération à la livraison. C’est peu coûteux maintenant, très coûteux pendant un audit. À lire aussi Coûts de migration et d’obsolescence Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Détection d'anomalies de coûts des LLM · FinOps LLM URL: https://finopsllm.com/fr/research/anomaly-detection Détection d'anomalies de coûts des LLM Les anomalies de coûts des LLM sont souvent invisibles jusqu'à l'arrivée de la facture car les dépenses peuvent augmenter sans que le volume de requêtes augmente. Un déploiement peut ajouter du contexte récupéré, modifier un seuil de routage, réduire les hits du cache, déclencher des nouvelles tentatives ou déplacer le trafic vers un modèle plus coûteux. Les alertes de trafic traditionnelles manquent ces changements. Un détecteur d'anomalies utile surveille les facteurs de coûts, pas seulement le coût total. La dépense quotidienne totale est un indicateur retardé. Les premiers signaux sont les tokens par requête, le mélange de modèles, le taux de secours, le taux de hit du cache, la part des lots et la dépense par surface de produit. Signaux à surveiller Dépenses par endpoint, équipe et client par heure. Tokens d'entrée et de sortie par requête à p50, p90 et p99. Taux de nouvelle tentative, taux de secours et taux d'erreur du fournisseur. Taux de hit du cache et part des tokens lus en cache. Changements du mélange de modèles après des déploiements ou des lancements de prompts. Travail traitable s'exécutant accidentellement de manière synchrone. Lignes de base Utilisez plusieurs lignes de base. Un chatbot de support a des cycles quotidiens et hebdomadaires. Un travail d'enrichissement nocturne a une fenêtre batch. Une suite d'évaluation a des pics autour des lancements. Un seuil global unique sera soit trop insensible, soit réveillera les gens constamment. La meilleure ligne de base est par propriétaire et classe de charge de travail. Alertez quand une fonctionnalité s'écarte de son propre modèle normal, pas quand toute l'entreprise franchit une limite de dépense générique. Alertes exploitables Une alerte doit expliquer le facteur : « les tokens d'entrée p90 ont doublé sur l'endpoint X après le déploiement Y », « le taux de hit du cache a chuté de 74% à 18% », ou « le basculement vers le modèle frontier a augmenté de 31% ». Si l'alerte ne peut pas nommer un propriétaire probable et un facteur, elle sera ignorée. Boucle de réponse Attachez le contexte de déploiement, les diffs de politique de routage et les clients ou charges de travail les plus affectés. Ensuite, proposez l'étape suivante : annuler un prompt, réduire le nombre de récupérations, restaurer un seuil de routage, désactiver un secours ou déplacer un travail vers batch. La détection d'anomalies n'est précieuse que lorsqu'elle raccourcit le délai entre la surprise de la facture et l'action technique. Connexes Surveillance des coûts des LLM - dashboards et observabilité des dépenses. Observabilité d'IA - signaux de coûts et métriques opérationnelles. Pourquoi les factures LLM explosent - causes racines des augmentations de coûts. Vous voulez que cela s'applique à vos propres dépenses d'IA? FinOps LLM réalise un audit gratuit de vos coûts d'IA et vous montre où se trouvent les économies. Réservez votre audit gratuit → Retour à la recherche --- # Azure OpenAI vs Direct OpenAI : coûts et PTU · FinOps LLM URL: https://finopsllm.com/fr/research/azure-openai-vs-direct-cost Azure OpenAI vs OpenAI Direct : comparatif de coûts et PTU Mis à jour September 19, 2026 · première publication July 12, 2026 Réponse rapide: En tarification standard à l'usage sur les déploiements globaux, Azure OpenAI et l'API directe d'OpenAI affichent des prix catalogues identiques (ex. 2,50 $ par million de jetons en entrée et 15 $ en... En tarification standard à l'usage sur les déploiements globaux, Azure OpenAI et l'API directe d'OpenAI affichent des prix catalogues identiques (ex. 2,50 $ par million de jetons en entrée et 15 $ en sortie pour les modèles de pointe). La véritable divergence économique se joue sur trois piliers : les unités de débit provisionné (PTU) , les surcoûts de résidence des données régionale et les remises de volume Enterprise Agreement (EA) . 1. Unités de débit provisionné (PTU) vs consommation au jeton Azure propose une réservation de capacité dédiée avec les PTU. À la demande, une PTU coûte 2 $ de l'heure. Avec un engagement mensuel réservé, ce tarif passe à environ 260 $ par mois et par PTU — soit une réduction pouvant atteindre 82 % par rapport au taux horaire (et jusqu'à 85 % sur un an). Le seuil de rentabilité se situe généralement à un taux d'utilisation continue supérieur à 65–75 % . En dessous, ou pour les trafics imprévisibles, le paiement direct au jeton reste plus avantageux. 2. Surcoûts géographiques et souveraineté Tandis que les déploiements mondiaux s'alignent sur les prix américains, restreindre vos déploiements aux régions européennes ou souveraines engendre une majoration de 10 % à 20 % . La conformité RGPD stricte et la localité des données ont un impact direct sur la facture FinOps. 3. TCO et coûts cachés de réseau Déployer sur Azure implique des coûts d'infrastructure annexes : Private Endpoints, stockage des journaux Azure Monitor et sorties réseau VNet. Ces coûts ajoutent 4 % à 8 % au coût effectif par million de jetons, mais procurent une isolation réseau d'entreprise et une gouvernance RBAC intégrée. À lire aussi Remises sur dépenses engagées Pourquoi comparer les prix est complexe Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Les agents en arrière-plan changent l'horloge FinOps · FinOps LLM URL: https://finopsllm.com/fr/research/background-agents-cost-clock Agents en arrière-plan et horloge FinOps Mis à jour September 10, 2026 · première publication September 10, 2026 Réponse rapide: L'exécution en tâche de fond permet aux agents d'accomplir des travaux complexes en l'absence de l'utilisateur. Définissez des plafonds budgétaires et des timeouts stricts pour chaque tâche. L'exécution en tâche de fond permet aux agents d'accomplir des travaux complexes en l'absence de l'utilisateur. Définissez des plafonds budgétaires et des timeouts stricts pour chaque tâche. À lire aussi Trois budgets pour chaque agent Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Stratégies de cache comparées · FinOps LLM URL: https://finopsllm.com/fr/research/caching-strategies-compared Stratégies de cache comparées Le cache est l'une des tactiques de réduction des coûts à plus fort impact pour les charges de travail LLM. L'idée est directe : ne payez pas pour l'inférence si vous pouvez retourner un résultat en cache. Mais le « cache » n'est pas une seule technique — ce sont quatre stratégies distinctes avec des compromis différents en matière d'économies de coûts, de latence, de précision et de complexité de mise en œuvre. Choisir la mauvaise gaspille l'effort d'ingénierie ; choisir la bonne peut réduire votre facture de 30 à 70 %. Comparaison des stratégies Stratégie Fonctionnement Économies de coûts Impact sur la latence Effort de mise en œuvre Idéal pour Fournisseurs Cache de prompts (côté fournisseur) Le fournisseur met en cache le calcul KV pour les préfixes de prompts répétés. Les demandes ultérieures avec le même préfixe ignorent le retraitement. 50 % sur les tokens d'entrée en cache 60-80 % plus rapide en latence du premier token Zéro à faible — automatique chez la plupart des fournisseurs Prompts système longs, RAG avec contexte partagé, boucles d'agents OpenAI, Anthropic, Google Cache sémantique (basé sur les embeddings) Génère les embeddings de la requête utilisateur, recherche dans un magasin vectoriel des requêtes passées similaires. Si la similitude dépasse un seuil, retourne la réponse en cache sans appeler le LLM. 20-50 % selon la répétition des requêtes 50-90 % plus rapide (pas d'appel LLM) Moyen — nécessite un modèle d'embeddings, un magasin vectoriel, un ajustement du seuil de similitude Bots FAQ, support client, requêtes répétitives Quelconque (auto-hébergé via GPTCache, Redis avec recherche vectorielle) Cache de contexte (style Google) Met en cache les documents de contexte volumineux (PDF, référentiels de code) côté serveur. Paye une fois pour le traitement du contexte, réutilise sur plusieurs requêtes à un coût réduit par requête. 70-90 % sur les requêtes riches en contexte Amélioration modérée du traitement du contexte Faible à moyen — charge le contexte, gère le TTL Questions-réponses sur documents, révision de code sur grands référentiels, tours multiples avec contexte statique Google (Gemini), Anthropic (contexte de réflexion étendue) Cache au niveau applicatif (Redis/CDN) Hachage déterministe de la demande complète (prompt + paramètres). Stocke la réponse dans Redis ou un CDN. Retourne la réponse en cache en cas de correspondance exacte. Jusqu'à 100 % en cas de succès du cache 90-99 % plus rapide (pas d'appel LLM) Faible — infrastructure de cache standard Requêtes déterministes, classification, extraction avec prompts fixes Quelconque (infrastructure que vous contrôlez) Cache de prompts en détail Le cache de prompts est le gain le plus facile. OpenAI met automatiquement en cache les prompts de plus de 1 024 tokens. Anthropic met en cache les préfixes de 2 048+ tokens. Le cache est indexé par le préfixe exact — même prompt système, mêmes exemples few-shot, même contexte de document. Lorsqu'il y a un succès du cache, vous payez 50 % moins pour la partie en cache des tokens d'entrée. L'inconvénient : l'invalidation du cache est contrôlée par le fournisseur. Si le prompt change, même légèrement — message système différent, variable différente dans le préfixe — le cache échoue. Concevez vos prompts pour placer le contenu stable au début et le contenu dynamique à la fin du prompt. Cache sémantique en détail Le cache sémantique ignore complètement le LLM lorsqu'une question similaire a déjà été posée. Le flux : générez les embeddings de la requête, recherchez dans un magasin vectoriel (Pinecone, Qdrant, Redis avec recherche vectorielle), vérifiez si le résultat principal dépasse un seuil de similitude (généralement 0,92-0,97) et retournez la réponse en cache si c'est le cas. Le risque est de retourner des réponses obsolètes ou légèrement incorrectes. Un seuil trop bas retourne des résultats incorrects ; un seuil trop haut signifie presque aucun succès du cache. Ajustez-le selon le cas d'usage. Pour la récupération factuelle de FAQ, 0,95+ est sûr. Pour la génération créative, le cache sémantique est rarement approprié — l'objectif est la nouveauté. Cache de contexte en détail Le cache de contexte de Google vous permet de télécharger un document volumineux une fois et de payer un tarif réduit pour les requêtes ultérieures le concernant. C'est puissant pour les questions-réponses sur documents où vous traitez le même PDF de 200 pages des centaines de fois. Le modèle de coûts : vous payez le tarif complet des tokens d'entrée une fois pour l'écriture du cache, puis un tarif réduit (souvent 25 % de la normale) pour chaque lecture du cache. Le compromis est le TTL. Les contextes en cache expirent. Si votre charge de travail a des modèles d'accès par rafales — 500 requêtes en une heure, puis rien pendant une semaine — le cache peut expirer entre les rafales. Dimensionnez votre TTL pour correspondre à votre modèle d'accès. Cache au niveau applicatif en détail Le cache déterministe est la stratégie la plus agressive. Hachez la charge complète de la demande (prompt, température, tokens maximaux, modèle, outils) et stockez la réponse. En cas de correspondance exacte, retournez la réponse en cache instantanément — pas d'appel LLM, pas de latence, pas de coût. Cela ne fonctionne que lorsque la même entrée doit toujours produire la même sortie. La classification, l'extraction d'entités, l'analyse de données structurées et la génération basée sur des modèles sont de bons candidats. Les tâches conversationnelles ou créatives ne le sont pas — les utilisateurs s'attendent à des réponses variées. Combinaison de stratégies Les meilleures implémentations superposent plusieurs stratégies. Une pile typique : cache au niveau applicatif comme première vérification (moins cher, plus rapide), cache sémantique comme deuxième vérification (capture les quasi-doublons), puis l'appel LLM avec cache de prompts côté fournisseur activé (réduit le coût même en cas d'échec du cache). Cette approche en couches peut réduire la dépense LLM totale de 40 à 70 % sur les charges de travail avec un certain degré de répétition. Suivez les taux de succès du cache séparément pour chaque couche. Si votre taux de succès du cache sémantique tombe en dessous de 10 %, la surcharge du magasin vectoriel peut ne pas en valoir la peine. Si votre taux de succès du cache applicatif est supérieur à 40 %, vous avez probablement des tâches déterministes qui devraient être optimisées au niveau du prompt. Associé Cache de prompts expliqué — approfondissement du cache côté fournisseur. Économie du cache sémantique — analyse du ROI du cache sémantique. Optimisation des coûts de l'IA — stratégies d'optimisation plus larges. Vous voulez appliquer cela à vos propres dépenses LLM ? FinOps LLM effectue un audit gratuit de vos coûts d'IA et montre où se trouvent les économies. Réserver audit gratuit → Retour à la recherche --- # Génération de code par IA la moins chère (2026) · FinOps LLM URL: https://finopsllm.com/fr/research/cheapest-ai-code-generation La Façon la Moins Chère d'Exécuter la Génération de Code par IA Les outils de génération de code par IA se sont multipliés - mais la différence de coût entre les options est énorme. Un utilisateur occasionnel pourrait dépenser 10 $/mois avec une approche et 200 $/mois avec une autre pour des résultats presque identiques. Ce guide compare chaque catégorie d'outil de codage par IA, calcule les coûts mensuels réels pour différents niveaux d'utilisation et vous donne un arbre de décision pour choisir l'option la moins chère qui fonctionne réellement pour votre flux de travail. Les quatre catégories Chaque outil de génération de code par IA correspond à l'un de quatre modèles tarifaires : Agents par abonnement - frais mensuels fixes, utilisation incluse (Cursor, Copilot, Windsurf, Cody). Agents basés sur API - vous apportez votre propre clé API, vous payez par token (Claude Code, Cline, Aider, Continue avec les API cloud). Modèles auto-hébergés - exécutez les modèles open-weight localement ou sur votre propre GPU (Continue + Qwen, CodeLlama, DeepSeek Coder). Fournisseurs de plans de codage - accès API à tarif fixe optimisé pour les charges de travail de codage ( MiMO , GLM, MiniMax, KwaiKAT). Tableau de comparaison des coûts Option Coût Mensuel (Occasionnel) Coût Mensuel (Intensif) Qualité du Modèle Effort de Configuration GitHub Copilot Free $0 $0 Bonne Aucun GitHub Copilot Pro $10 $10 Très bonne Aucun Cursor Pro $20 $20 Excellente Faible Windsurf Pro $15 $15 Très bonne Faible Claude Code (API) $5–15 $50–200 Excellente Moyen Cline + clé API $5–20 $40–150 Excellente Moyen Plan de codage MiMO $10–15 $30–60 Très bonne Faible Plan de codage GLM $10–15 $30–60 Bonne Faible Continue + modèle local $0 $0 Acceptable Élevé Utilisateur occasionnel : ~2 heures/jour, ~50 requêtes/jour. Utilisateur intensif : 8+ heures/jour, ~300 requêtes/jour. Les coûts API supposent une moyenne de 3K tokens d'entrée + 1K tokens de sortie par requête avec les tarifs Claude Sonnet ou GPT-4o. Analyse par catégorie 1. Agents par abonnement Ce sont les plus faciles à adopter. Vous payez une tarif fixe et obtenez un quota d'utilisation généreux (ou illimité). Le piège : vous êtes lié à leur choix de modèle et d'intégration IDE. Cursor Pro ($20/mois) - Meilleure UX globale pour les utilisateurs avancés. Inclut les requêtes rapides (GPT-4o, Claude Sonnet) et les requêtes lentes (modèles frontière). La limite de 500 requêtes rapides/mois est suffisante pour la plupart des développeurs. GitHub Copilot ($10/mois) - Option principale la moins chère. Les autocompletions sont excellentes ; le chat est bon mais moins puissant que le mode agent de Cursor. Un niveau gratuit est disponible avec des limites. Windsurf Pro ($15/mois) - Terrain compétitif intermédiaire. De bonnes fonctionnalités agentiques à un prix inférieur à Cursor. Verdict : Meilleur pour les développeurs qui veulent une configuration zéro et une facturation prévisible. Copilot Free est imbattable pour les utilisateurs au budget serré. 2. Agents basés sur API Vous apportez votre propre clé API (OpenAI, Anthropic, etc.) et l'outil effectue les appels API en votre nom. Les coûts s'échelonnent linéairement avec l'utilisation - excellents pour les utilisateurs occasionnels, coûteux pour les utilisateurs intensifs. Claude Code - L'agent CLI d'Anthropic. Utilise Claude Sonnet ou Opus. Une session intensive peut coûter 2–5 $ en frais API. Cline (VS Code) - Agent open-source qui fonctionne avec n'importe quelle API. Très flexible, mais les coûts sont imprévisibles sans limites de budget. Aider - Basé sur terminal, fonctionne avec n'importe quel modèle. Populaire pour son intégration git et son approche du mode édition. Verdict : Meilleur pour les développeurs qui veulent la flexibilité des modèles et sont prêts à surveiller l'utilisation. Les utilisateurs occasionnels paient moins que les abonnements ; les utilisateurs intensifs paient plus. 3. Modèles auto-hébergés Exécutez les modèles open-weight (Qwen 2.5 Coder, DeepSeek Coder V2, CodeLlama) localement via Ollama, vLLM ou llama.cpp. Coût marginal zéro par requête - mais vous avez besoin de matériel. Avantages : Pas de coût par token, confidentialité totale, pas de limites de débit, fonctionne hors ligne. Inconvénients : Écart de qualité par rapport aux modèles frontière (surtout pour la refactorisation complexe), nécessite un GPU capable (16 Go+ de VRAM pour de bons résultats), friction de configuration. Verdict : Meilleur pour les travaux sensibles à la confidentialité, les environnements hors ligne ou les équipes avec une infrastructure GPU existante. Non recommandé comme votre seul modèle - associez-le à un modèle cloud pour les tâches difficiles. 4. Fournisseurs de plans de codage Une catégorie plus récente : les fournisseurs offrent un accès API à tarif fixe ou à forte remise spécifiquement pour les agents de codage. Ceux-ci comblent le fossé entre les tarifs API coûteux par token et les outils d'abonnement rigides. Plan de codage MiMO - Tarifs compétitifs avec des capacités de raisonnement solides. Bon équilibre entre coût et qualité. GLM (Zhipu) - Fournisseur chinois avec des tarifs agressifs pour les charges de travail de codage. MiniMax / KwaiKAT - Fournisseurs émergents avec des niveaux de tarification optimisés pour le codage. Verdict : Meilleur pour les utilisateurs d'agents basés sur API qui veulent réduire les coûts sans passer à l'auto-hébergement. La qualité varie - testez les performances sur vos tâches réelles avant de vous engager. Arbre de décision Suivez ceci pour trouver votre option la moins chère : Si vous codez <2 heures/jour : Utilisez GitHub Copilot Free . Coût zéro, autocompletions excellentes. Si vous atteindre les limites, mettez à niveau vers Copilot Pro ($10/mois). Si vous codez 2–6 heures/jour : Utilisez Cursor Pro ($20/mois) ou Windsurf Pro ($15/mois) . Le tarif fixe est moins cher que les coûts API à ce volume. Vous pouvez aussi utiliser un fournisseur de plan de codage comme MiMO avec Cline pour $10–30/mois. Si vous codez 8+ heures/jour : Utilisez un agent basé sur API avec un plan de codage (MiMO, GLM) à $30–60/mois. Les clés API standard (Claude, GPT-4o) coûteront $100–200/mois à ce volume. Envisagez un modèle local pour les completions de routine afin de réduire davantage les coûts. Les coûts cachés dont personne ne parle Gaspillage de fenêtre de contexte. La plupart des agents de codage envoient votre fichier complet + historique de conversation à chaque requête. Un contexte de 50K tokens sur GPT-4o coûte 0,125 $ par requête rien qu'en entrée. Avec 200 requêtes/jour, c'est 25 $/jour - plus qu'un abonnement mensuel à Cursor. Boucles de retry. Les outils agentiques qui réessaient automatiquement les éditions défaillantes peuvent consumer les tokens rapidement. Définissez des limites strictes sur le nombre de tentatives. Surcharge de changement de modèle. Certains outils utilisent par défaut le modèle le plus cher. Vérifiez vos paramètres - les requêtes « lentes » de Cursor utilisent des modèles moins chers et sont souvent assez rapides. Conclusion Pour la plupart des développeurs, un agent par abonnement (Copilot ou Cursor) est l'option la moins chère car elle plafonne vos coûts indépendamment de l'utilisation. Pour les utilisateurs avancés disposés à gérer les clés API, les fournisseurs de plans de codage comme MiMO offrent le meilleur rapport coût-qualité. Les modèles auto-hébergés sont gratuits mais de qualité limitée - meilleur comme complément, pas comme remplacement. Quel que soit votre choix, suivez vos dépenses par outil pour pouvoir réévaluer à mesure que les prix changent. Associé Comparaison des plans de codage par IA - benchmark détaillé des fournisseurs de plans de codage. Combien coûte GPT-5 ? - tarification des modèles frontière expliquée. Arbitrage de fournisseurs - approche systématique pour trouver des modèles moins chers. Routage de modèles - envoi de tâches au bon niveau de coût. Voulez-vous cela appliqué à votre propre dépense en LLM ? FinOps LLM exécute un audit gratuit de vos coûts d'IA et montre où se trouvent les économies. Réserver audit gratuit → Retour à la recherche --- # Fable 5.1 : 10/50 dollars, le cache décide · FinOps LLM URL: https://finopsllm.com/fr/research/claude-fable-5-1-cost-model Modèle de coût de Claude Fable 5.1 Mis à jour September 1, 2026 · première publication September 1, 2026 Réponse rapide: Claude Fable 5.1 (claude-fable-5-1) est facturé 10 dollars par million de tokens d’entrée et 50 par million en sortie, contre 5 et 25 pour Opus 5. On y voit une prime uniforme de 2×. C’est faux... Claude Fable 5.1 ( claude-fable-5-1 ) est facturé 10 dollars par million de tokens d’entrée et 50 par million en sortie, contre 5 et 25 pour Opus 5. On y voit une prime uniforme de 2×. C’est faux : le tarif du cache va dans l’autre sens. Les quatre tarifs qui comptent L’écriture en cache coûte 12,50 dollars par million (TTL 5 minutes) et 20,00 (TTL 1 heure). La lecture en cache coûte 0,25 par million, soit 2,5% de son propre prix d’entrée et la moitié du même token mis en cache chez Opus 5. Toutes les lignes sont à 2×; cette ligne-là est à 0,5×. Sur une charge réelle Un préfixe de 100 000 tokens coûte 1,00 dollar à froid avec Fable et 0,50 avec Opus 5. À chaud, 0,025 contre 0,05. Le fournisseur deux fois plus cher devient deux fois moins cher, sur le même prompt. Le point d’équilibre est un taux de succès du cache proche de 50%, pas une préférence de modèle. La sortie n’est pas plafonnée La fenêtre atteint un million de tokens et la sortie 128 000. À 50 dollars le million, une seule réponse de 128K coûte 6,40. Le raisonnement étendu est toujours actif et toute configuration explicite renvoie une erreur 400 : le levier de coût est le paramètre effort , de faible à maximal. Pas de Priority Tier non plus, donc la latence se gère par la concurrence côté client. À instrumenter avant de router du trafic Mesurez le taux de succès du cache par fonctionnalité, l’amplification des écritures de cache et les tokens de sortie par tâche réussie. Comparez ensuite via un pont de variation séparant tarif, volume et mix : une moyenne masque les deux mouvements opposés. À lire aussi Économie du cache de prompts Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Claude Opus 5.5 : $4/$20 et lecture cache à $0.20 · FinOps LLM URL: https://finopsllm.com/fr/research/claude-opus-5-5-cost-model Modèle de coût de Claude Opus 5.5 Mis à jour September 22, 2026 · première publication September 22, 2026 Anthropic a lancé Claude Opus 5.5 ( claude-opus-5-5 ) le 22 septembre 2026. Le prix annoncé est $4 par million de tokens d'entrée et $20 par million de tokens de sortie, en baisse par rapport à $5 et $25 pour Opus 5. C'est une réduction de 20%. Pour la plupart des charges de travail de production, la réduction réelle est plus importante, car le taux qui a le plus bougé est celui que le titre omet. Les taux qui comptent Type de token Opus 5.5 Opus 5 Fable 5.1 Entrée (non cachée) $4.00 / MTok $5.00 / MTok $10.00 / MTok Sortie $20.00 / MTok $25.00 / MTok $50.00 / MTok Écriture en cache (5 min) $5.00 / MTok $6.25 / MTok $12.50 / MTok Lecture de cache $0.20 / MTok $0.50 / MTok $0.25 / MTok Mode rapide (entrée / sortie) $8 / $40 — — Chaque ligne est 20% moins élevée sauf la lecture de cache, qui est 60% moins cher. À $0.20, c'est maintenant moins cher que le $0.25 de Fable 5.1. Cela inverse la seule ligne où Fable avait l'habitude de gagner. Dans notre modèle de coût Fable 5.1 , une charge de travail fortement cachée pouvait s'avérer moins chère sur Fable que sur Opus 5. Contre Opus 5.5, ce n'est plus le cas. Fable coûte plus cher sur chaque type de token. Pourquoi une tâche typique coûte environ 40% moins cher L'affirmation d'Anthropic est une baisse de 40% du coût pour un travail typique, pas 20%. Le supplément provient de l'efficacité des tokens. Anthropic dit qu'Opus 5.5 obtient le même résultat avec environ 20% moins de tokens d'entrée et de sortie et écrit une sortie environ 40% moins verbeuse. Un taux plus bas multiplié par moins de tokens se compose : 0.8 × 0.8 = 0.64, ce qui représente environ 36–40% de réduction selon le mélange. Voici une étape d'agent : 200 000 tokens d'entrée, 90% servis depuis le cache, et 20 000 tokens de sortie. Ligne Opus 5 Opus 5.5 (même tokens) Fable 5.1 20K entrée non cachée $0.100 $0.080 $0.200 180K entrée cachée $0.090 $0.036 $0.045 20K sortie $0.500 $0.400 $1.000 Total $0.690 $0.516 $1.245 Sur des tokens identiques, Opus 5.5 est 25% moins cher qu'Opus 5, pas 20%, en raison de la réduction du cache. Si la réduction de 20% des tokens se maintient pour votre charge de travail, l'étape tombe à environ $0.41, ce qui représente 40% sous Opus 5 et un tiers du coût Fable. La sortie représente toujours environ 80% de la facture dans cet exemple. C'est là que la réduction de verbosité porte ses fruits. Coût par tâche face à GPT-6 Sol, GPT-6 Astra et Fable 5.1 Prix catalogue par million de tokens, et la même étape d'agent que plus haut (200K en entrée, 90 % en cache, 20K en sortie) calculée sur chaque modèle. Modèle Entrée $/MTok Sortie $/MTok Lecture du cache $/MTok Même étape d'agent GPT-6 Sol $2.00 $10.00 $0.20 $0.276 Claude Opus 5.5 $4.00 $20.00 $0.20 $0.516 Claude Opus 5 $5.00 $25.00 $0.50 $0.690 Claude Fable 5.1 $10.00 $50.00 $0.25 $1.245 GPT-6 Astra $10.00 $50.00 $1.00 $1.380 Coût par tâche mesuré sur l'Artificial Analysis Intelligence Index v4.3.2, consulté le 22 septembre 2026, trié par score. GPT-6 Sol est le moyen le moins cher d'atteindre tout score jusqu'à 47,5. Au-delà, Opus 5.5 est le moins cher à chaque niveau : Opus 5.5 high obtient 53,6 pour 1,82 $, alors que GPT-6 Astra max obtient 52,7 pour 3,26 $ et Fable 5.1 max 53,4 pour 7,63 $. Modèle Intelligence Index Coût par tâche Tokens de sortie par tâche GPT-6 Sol · medium 39.8 $0.25 6,500 GPT-6 Sol · xhigh 44.1 $0.53 16,000 GPT-6 Astra · low 45.8 $0.82 4,400 GPT-6 Sol · max 47.5 $1.06 31,200 Claude Opus 5 · high 48.1 $3.61 46,200 Claude Opus 5 · max 50.8 $5.86 72,500 Claude Opus 5.5 · medium 51.2 $1.34 25,700 Claude Fable 5.1 · high 51.2 $3.91 38,100 GPT-6 Astra · max 52.7 $3.26 27,200 Claude Fable 5.1 · max 53.4 $7.63 78,100 Claude Opus 5.5 · high 53.6 $1.82 35,600 Claude Opus 5.5 · max 57.6 $5.98 119,200 Tous les réglages de GPT-6 Astra au-dessus de low, tous ceux d'Opus 5 et tous ceux de Fable 5.1 coûtent plus qu'un réglage de Sol ou d'Opus 5.5 au score égal ou supérieur. Le coût par tâche dépend du mix de tâches du benchmark. Rejouez votre propre trafic avant de changer de modèle. Est-ce assez bien pour remplacer Fable? Anthropic positionne Opus 5.5 comme correspondant à Fable 5.1 sur la plupart des tâches. Les chiffres publiés le soutiennent pour le travail de codage et agentif : Terminal-Bench 4.0 : 66.4%, contre 52.3% pour Opus 5 et 55.8% pour Fable 5.1. FrontierCode v1.1 : 54.4%, contre 48.0% pour Opus 5 et 50.3% pour Fable 5.1. CursorBench 4.0 : 57.8%, contre 46.6% pour Opus 5. GDPval-AA v2.1 : 1846 Elo, contre 1708 pour Opus 5. Artificial Analysis l'a classé premier dans son Indice de Renseignement le jour du lancement. Anthropic dit aussi qu'au niveau d'effort par défaut (moyen), il surpasse GPT-6 Astra à l'effort maximum sur le travail de connaissance pour environ un cinquième du coût par tâche. C'est une comparaison du fournisseur, donc traitez-la comme une hypothèse à tester. Les mathématiques des coûts ci-dessus sont la partie que vous pouvez vérifier vous-même. Le mode rapide coûte 2× Le mode rapide coûte $8 en entrée et $40 en sortie, exactement le double du taux standard, pour jusqu'à 2.5× la vitesse. Le modèle standard est aussi environ 30% plus rapide qu'Opus 5. Utilisez le mode rapide pour les chemins interactifs liés à la latence où un utilisateur attend. Gardez-le désactivé pour les travaux par lots, les agents en arrière-plan et les évaluations. Quand le mode rapide est activé par défaut, le coût unitaire double et le tableau de bord ne montre rien d'inhabituel jusqu'à ce que la facture arrive. Quoi faire cette semaine Épinglez l'ID du modèle. Pointez la production sur claude-opus-5-5 explicitement et enregistrez l'ID à chaque requête, pour que le coût par requête puisse être divisé par modèle après la migration. Redéfinissez la base de référence sur votre propre trafic. Relisez un exemple de demandes réelles sur les deux modèles et comparez les tokens par tâche terminée, pas par appel. La revendication d'efficacité des tokens de 20% est la partie la plus susceptible de varier selon la charge de travail. Revérifiez les paramètres d'effort. Si une charge de travail a été déplacée vers Fable ou vers l'effort maximal pour la qualité, testez Opus 5.5 d'abord au niveau moyen. C'est le paramètre contre lequel Anthropic fait des points de référence. Rexécutez la décision de routage Fable. Tout itinéraire qui a envoyé du trafic lourd en cache à Fable pour obtenir la lecture de cache moins chère doit être réévalué. Cet avantage de coût a disparu. Surveiller le taux de succès du cache. À $0.20 contre $4.00, une défaillance du cache coûte maintenant 20× un succès. Une modification du modèle d'invite qui casse le préfixe coûte plus cher que sur Opus 5. Anthropic dit que Sonnet 5.5 et Haiku 5.5 suivront dans les prochaines semaines. Conservez le harnais de relecture à partir de l'étape 2 pour que chaque version puisse être rétablie en une après-midi. À lire aussi Modèle de coût de Claude Fable 5.1 Économie de la mise en cache d'invites Les niveaux d'effort Opus 5.5 sont le vrai prix Économie du mode rapide Opus 5.5 Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Comparaison des Plans de Codage IA · FinOps LLM URL: https://finopsllm.com/fr/research/coding-plan-comparison Comparaison des Plans de Codage IA Comparez les principaux plans de codage IA avec des preuves vérifiables. Tarifs, limites et scores de modèles dans un tableau normalisé. Construit à partir de la documentation des fournisseurs et de règles de conversion explicites pour une comparaison équitable. 9 Fournisseurs suivis 29 Plans comparés 62 Modèles répertoriés Juil 2026 Dernière mise à jour Chaque mise à jour est liée à des preuves publiques Les règles de conversion Prompt/Requête sont explicites La logique de calcul fixe maintient les comparaisons cohérentes Méthodologie Collecte Les données de plans, de limites et de modèles sont collectées à partir de sources publiques des fournisseurs. Normalisation Les formats Prompt/Requête/Période sont normalisés dans un modèle de comparaison unique. Règles de conversion Requête/Prompt = 15 et Hebdomadaire × 4 = Mensuel sont appliqués explicitement. Politique d'affichage Les valeurs officielles et estimées sont clairement séparées dans l'interface. Flux de Mise à Jour 4 juil 2026 Page de recherche de comparaison de plans lancée Comparaison de plans de codage IA basée sur des preuves publiée en tant qu'article de recherche FinOps LLM. 27 mai 2026 Quota Xiaomi MiMO augmenté Xiaomi MiMO a augmenté les limites d'utilisation disponibles, et le tableau de comparaison a été mis à jour. 1er mai 2026 Alibaba abandonne le Plan de Codage, ajoute le Plan de Jetons (Édition Équipe) Alibaba a fermé le Plan de Codage précédent et introduit le Plan de Jetons (Édition Équipe). Liste de Comparaison des Plans de Codage Taux de conversion Requête/Prompt (par défaut = 15) 1 Prompt = 15 Requêtes Tri Ordre par défaut Meilleure valeur ≤ 10 $ Meilleure valeur ≤ 30 $ Meilleure valeur (tous) Afficher : Tous Codage Agent Fournisseur ↕ Plan ↕ Tarif ↕ Utilisation Prompt / mois ↕ Requête / mois ↕ Prompt / 1 $ ↕ Requête / 1 $ ↕ Modèles Intel ↕ Codage ↕ Agentic ↕ GLM Lite 10 $ Codage + Agent 160 2 400 16 240 GLM-5.1 (×3), GLM-5-Turbo (×3), GLM-4.7 (×1) 47 37 66 GLM Pro 30 $ Codage + Agent 267 4 000 8,9 133 GLM-5.1 (×3), GLM-5-Turbo (×3), GLM-5 (×3) 50 44 63 GLM Max 80 $ Codage + Agent 400 6 000 5 75 GLM-5.1 (×3), GLM-5-Turbo (×3), GLM-5 (×3) 50 44 63 MiniMax Starter 10 $ Codage + Agent 400 6 000 40 600 MiniMax-M2.7 (×1) 50 42 61 MiniMax Plus 20 $ Codage + Agent 600 9 000 30 450 MiniMax-M2.7 (×1) 50 42 61 MiniMax Max 45 $ Codage + Agent 889 13 333 19,8 296 MiniMax-M2.7 (×1) 50 42 61 MiniMax Plus-HighSpeed 40 $ Codage + Agent 300 4 500 7,5 112,5 MiniMax-M2.7-highspeed (×1) 50 42 61 MiniMax Max-HighSpeed 80 $ Codage + Agent 500 7 500 6,25 93,75 MiniMax-M2.7-highspeed (×1) 50 42 61 MiniMax Ultra-HighSpeed 150 $ Codage + Agent 533 8 000 3,55 53,3 MiniMax-M2.7 (×1) 50 42 61 BytePlus Lite 10 $ Codage + Agent 120 1 800 12 180 Seed-Code (×1), GLM-4.7 (×1), DeepSeek-V3.2 (×1), kimi-k2.5 (×1) 34 31 36 BytePlus Pro 50 $ Codage + Agent 120 1 800 2,4 36 Seed-Code (×1), GLM-4.7 (×1), DeepSeek-V3.2 (×1), kimi-k2.5 (×1) 34 31 36 StepFun Flash Mini 6,99 $ Codage 229 3 433 32,8 491 step-3.5-flash (×1) 38 32 52 StepFun Flash Plus 9,99 $ Codage 641 9 610 64,2 962 step-3.5-flash (×1) 38 32 52 StepFun Flash Pro 29 $ Codage 828 12 414 28,6 428 step-3.5-flash (×1) 38 32 52 StepFun Flash Max 99 $ Codage 808 12 121 8,16 122,4 step-3.5-flash (×1) 38 32 52 KwaiKAT Mini 5 $ Codage 1 075 16 128 215 3 226 KAT-Coder-Pro V2 (×1) 44 46 51 KwaiKAT Starter 10 $ Codage 1 344 20 160 134,4 2 016 KAT-Coder-Pro V2 (×1) 44 46 51 KwaiKAT Pro 20 $ Codage 2 016 30 240 100,8 1 512 KAT-Coder-Pro V2 (×1) 44 46 51 KwaiKAT Max 50 $ Codage 2 688 40 320 53,76 806,4 KAT-Coder-Pro V2 (×1) 44 46 51 OpenCode Go 10 $ Codage + Agent 667 10 000 66,7 1 000 MiniMax-M2.5 (×1), M2.7 (×1.4), MiMo-V2-Pro (×16), kimi-k2.5 (×11), GLM-5 (×17) 50 44 63 Xiaomi MiMO Inscription - chacun 2 $ ↗ Lite 6 $ Codage + Agent 380 5 693 63,3 949 MiMo-V2-Pro (×1), MiMo-V2-Omni (×1) 49 41 63 Xiaomi MiMO Inscription - chacun 2 $ ↗ Standard 16 $ Codage + Agent 382 5 729 23,9 578 MiMo-V2-Pro (×1), MiMo-V2-Omni (×1) 49 41 63 Xiaomi MiMO Inscription - chacun 2 $ ↗ Pro 50 $ Codage + Agent 422 6 333 8,44 126,7 MiMo-V2-Pro (×1), MiMo-V2-Omni (×1) 49 41 63 Xiaomi MiMO Inscription - chacun 2 $ ↗ Max 100 $ Codage + Agent 456 6 833 4,56 68,3 MiMo-V2-Pro (×1), MiMo-V2-Omni (×1) 49 41 63 Alibaba Standard 30 $ Codage + Agent 17 262 0,57 8,73 qwen3.6-plus (×1), deepseek-v3.2 (×1), GLM-5 (×1), MiniMax-M2.5 (×1) 50 43 62 Alibaba Advanced 100 $ Codage + Agent 21 314 0,21 3,14 qwen3.6-plus (×1), deepseek-v3.2 (×1), GLM-5 (×1), MiniMax-M2.5 (×1) 50 43 62 Alibaba Premium 200 $ Codage + Agent 26 393 0,13 1,97 qwen3.6-plus (×1), deepseek-v3.2 (×1), GLM-5 (×1), MiniMax-M2.5 (×1) 50 43 62 Les valeurs non fournies explicitement par les fournisseurs sont affichées en gris . De nombreux fournisseurs limitent soit les quotas de Prompt, soit les quotas de Requête. Nous convertissons dynamiquement à l'aide du contrôle de taux Requête/Prompt ci-dessus (par défaut : 15). Si la limite officielle la plus élevée est hebdomadaire, la limite mensuelle est estimée à Hebdomadaire × 4. Le score Artificial Analysis est mesuré par artificialanalysis.ai . Certains liens peuvent inclure des codes de parrainage. Les détails des plans peuvent changer fréquemment. Vérifiez toujours les informations les plus récentes sur les pages officielles des fournisseurs. Guide Pratique Le tarif seul ne suffit pas. Adaptez chaque plan à votre style de travail d'abord. Commencez par la politique Agent, le type de limite et l'horizon du contrat. 1) Vérifiez la politique Agent d'abord Certains fournisseurs ou plans restreignent l'utilisation d'Agent. Si les flux de travail Agent sont importants, vérifiez les conditions et la colonne Utilisation (Codage/Agent) avant de vous abonner. 2) Limites de Prompt vs Limites de Requête Pour une utilisation manuelle intensive de chat, regrouper le travail en moins de tours s'aligne généralement mieux avec les limites de type Prompt. Pour l'automatisation et les flux de travail Agent intensifs, le volume de requêtes backend peut croître rapidement, donc priorisez les plans avec suffisamment de marge de Requête. 3) Préférez mensuel, utilisez annuel quand les conditions initiales sont supérieures Les révisions de plans et les changements d'inscription sont de plus en plus courants. Le mensuel offre de la flexibilité, tandis que l'annuel peut être efficace quand les conditions de la période de lancement sont clairement avantageuses. 4) La vitesse (jetons/s) est un vrai facteur de productivité Avec le même quota, les réponses plus lentes coûtent toujours plus de temps de travail. Nous prévoyons d'ajouter des métriques de jetons par seconde dans une mise à jour future. Vérifications supplémentaires Séparez les valeurs Fournies des valeurs Estimées (les estimations peuvent changer) Confirmez la disponibilité de modèles de même classe (aucun signifie non disponible) Adaptez le cycle de réinitialisation (5h/quotidien/mensuel) à votre fenêtre d'utilisation réelle Voulez-vous que cela soit appliqué à vos propres dépenses d'IA ? FinOps LLM effectue un audit gratuit de vos coûts d'IA et montre où se trouvent les économies. Réserver un audit gratuit → Retour à la recherche --- # L’engagement parie sur vos prévisions · FinOps LLM URL: https://finopsllm.com/fr/research/committed-spend-discounts Remises pour engagement de dépense Mis à jour September 1, 2026 · première publication September 1, 2026 Réponse rapide: Dès que votre dépense modèle se remarque, un fournisseur vous proposera une remise contre un engagement de volume. Capacité réservée, engagement annuel, débit provisionné : les formes diffèrent, le... Dès que votre dépense modèle se remarque, un fournisseur vous proposera une remise contre un engagement de volume. Capacité réservée, engagement annuel, débit provisionné : les formes diffèrent, le marché non. On vous paie pour être prévisible. Les trois risques La sous-utilisation est l’évidente et la plus petite : engagez sous votre cas prudent, pas sous votre plan. L’enfermement sur un modèle est plus grand. La frontière bouge en quelques mois ; s’engager douze mois sur le vaisseau amiral du jour, c’est parier que rien de nettement moins cher n’arrivera — alors qu’il en arrive chaque trimestre depuis trois ans. La perte de mobilité est la plus coûteuse et n’apparaît dans aucun modèle : elle supprime votre levier de négociation et tue le travail de routage, car personne n’optimise le trafic hors d’un modèle déjà prépayé. Comment le valoriser Comparez au contrefactuel honnête : ce que vous auriez payé à la demande sur la période, baisses de prix comprises. Sur douze mois, c’est souvent 20 à 40 % sous le tarif du jour. Engagez un plancher , pas un plan. Préférez un engagement en dépense plutôt qu’en modèle. Exigez le report du volume inutilisé. Gardez une durée courte. À lire aussi Guide d’achat LLM Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Vous payez deux fois la fenêtre de contexte · FinOps LLM URL: https://finopsllm.com/fr/research/context-window-paid-twice Payer deux fois la fenêtre de contexte Mis à jour September 1, 2026 · première publication September 1, 2026 Réponse rapide: Une fenêtre de contexte est annoncée comme une capacité : 200 000 tokens, un million, de la place pour tout. La capacité n’est pas l’unité de facturation. On vous facture ce que vous envoyez, et dans... Une fenêtre de contexte est annoncée comme une capacité : 200 000 tokens, un million, de la place pour tout. La capacité n’est pas l’unité de facturation. On vous facture ce que vous envoyez , et dans une conversation multi-tours vous renvoyez presque tout à chaque tour. C’est le second paiement. Un document de 30 000 tokens chargé au début d’une conversation de vingt tours, ce n’est pas 30 000 tokens d’entrée : c’est près de 600 000. Le calcul que personne ne fait Le coût croît avec le carré de la longueur de la conversation, pas linéairement. Doubler les tours quadruple à peu près les tokens d’entrée. Modéliser un « coût par message » et multiplier sous-estime lourdement les sessions longues. Un troisième frais s’ajoute souvent : beaucoup de fournisseurs facturent au-delà d’un seuil de contexte long à un tarif majoré. Une pièce jointe de plus peut franchir cette ligne et retarifer tout l’appel. Quoi mesurer Suivez le taux d’utilisation du contexte : tokens envoyés contre tokens réellement nécessaires. Mesurez les tokens d’entrée par conversation , pas par requête, et surveillez le p99. Trois correctifs, du moins cher au plus Mettez en cache le préfixe stable — le meilleur rendement pour tout produit multi-tours. Élaguez l’historique délibérément : résumez le début et jetez les tours bruts. Envoyez l’extrait, pas le corpus. Que la fenêtre puisse contenir un document entier n’est pas une raison de l’y mettre. À lire aussi Économie du cache de prompts Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Ce que coûte une image utilisable · FinOps LLM URL: https://finopsllm.com/fr/research/cost-per-approved-image Coût par asset validé en image et vidéo Mis à jour September 1, 2026 · première publication September 1, 2026 Réponse rapide: La tarification image et vidéo semble simple : tant par image, tant par seconde. C’est précisément cette simplicité qui fait que presque tout le monde la budgète mal. Le fournisseur facture des... La tarification image et vidéo semble simple : tant par image, tant par seconde. C’est précisément cette simplicité qui fait que presque tout le monde la budgète mal. Le fournisseur facture des générations . L’entreprise consomme des assets validés . Le taux d’acceptation est tout le modèle Personne ne livre le premier rendu. Avec un style mûr, on accepte peut-être un sur trois ; en exploration créative, un sur dix. La vidéo est pire : un plan échoue sur le mouvement, la cohérence temporelle ou une seule image — et le clip entier est payé. L’arithmétique utile n’est pas le prix affiché, mais le prix divisé par le taux d’acceptation. Ce qui déplace vraiment le chiffre Pas la résolution, mais tout ce qui augmente l’acceptation : itérer en basse résolution et n’upscaler que le retenu, une bibliothèque de prompts pour les styles connus, des images de référence et des seeds fixes, et un brief écrit avant la première génération. Mesurez la bonne chose Générations par asset validé et coût par asset validé. Quinze générations par validation, c’est un problème de brief, pas de prix. À lire aussi Attribution des coûts LLM Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Coût par tâche réussie · FinOps LLM URL: https://finopsllm.com/fr/research/cost-per-successful-task Le coût par tâche réussie vaut mieux que le coût par requête Mis à jour August 27, 2026 · première publication August 27, 2026 Réponse rapide: Le coût par requête est utile, mais une requête échouée n’est pas une unité de travail terminée. Le meilleur indicateur est le coût par tâche réussie: toute la dépense attribuable divisée par les... Le coût par requête est utile, mais une requête échouée n’est pas une unité de travail terminée. Le meilleur indicateur est le coût par tâche réussie : toute la dépense attribuable divisée par les tâches qui atteignent un seuil de qualité. La formule coût par tâche = dépense attribuable / tâches réussies . Incluez tokens, outils, reprises et bascules. Définissez la réussite avant la mesure: acceptation utilisateur, seuil de confiance ou flux terminé sans réparation humaine. Mesurer le dénominateur Liez chaque trace modèle à un événement de résultat. Enregistrez succès, cause d’échec, réparation humaine et latence, puis rapprochez la dépense des factures. Un coût par requête faible mais un coût par tâche réussi élevé signale un problème de qualité, de reprises ou de règle d’arrêt. À lire aussi Suivi des coûts LLM Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Le coût réel d’un changement de fournisseur LLM · FinOps LLM URL: https://finopsllm.com/fr/research/cost-switching-llm-providers Coût réel d’un changement de fournisseur LLM Mis à jour August 27, 2026 · première publication August 27, 2026 Réponse rapide: Changer de fournisseur LLM ne consiste pas à comparer deux tarifs. Il faut compter ingénierie, prompts, schémas, évaluations, double fonctionnement, transfert, support et risque de qualité.Compter le... Changer de fournisseur LLM ne consiste pas à comparer deux tarifs. Il faut compter ingénierie, prompts, schémas, évaluations, double fonctionnement, transfert, support et risque de qualité. Compter le travail Inventoriez SDK, outils, formats, limites, contexte, sécurité, observabilité et erreurs spécifiques. Estimez les heures d’ingénierie et de test. Mesurer la qualité Rejouez la même charge et mesurez réussite, latence, reprises, réparation humaine et accord des évaluateurs. Calculer le retour Comparez économies mensuelles complètes et coûts de migration, évaluation, double fonctionnement et passerelle. Le routage peut être préférable au remplacement. À lire aussi Arbitrage entre fournisseurs Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Sept motifs défensifs de DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/fr/research/deepseek-harness-defensive-patterns Sept motifs défensifs tirés de la documentation DeepSeek Harness Mis à jour August 16, 2026 · première publication August 16, 2026 Réponse rapide: DeepSeek Harness livre un court document de motifs défensifs, chacun écrit comme une règle générale accompagnée du bug précis qui l'a motivée. C'est le fichier le plus transposable du dépôt : rien n'y... DeepSeek Harness livre un court document de motifs défensifs, chacun écrit comme une règle générale accompagnée du bug précis qui l'a motivée. C'est le fichier le plus transposable du dépôt : rien n'y dépend de l'adoption du harness, et chaque point correspond à un mode de défaillance qui apparaît dans les runtimes d'agents maison. 1. Rapporter séparément les résultats orthogonaux Ne jamais imbriquer le rapport d'un drapeau dans la condition d'un autre. Un processus peut dépasser le délai et sortir avec zéro, parce qu'il a intercepté le signal et s'est arrêté proprement. Si le dépassement n'est rapporté que dans la branche de sortie non nulle, ce résultat disparaît. Délai dépassé, signal et code de sortie sont des faits indépendants et exigent des champs indépendants. Pertinence économique : les dépassements avalés en silence sont la façon dont naissent les boucles de retry. L'appelant voit un succès, n'obtient rien d'utile, et recommence. 2. Honorer les contrats publics des deux côtés Quand un résultat a plusieurs représentations valides, normalisez-les avant de les exposer. L'exemple traité est l'échec de requête modèle : les implémentations peuvent lever une exception ou émettre un chunk de fin en erreur, et la frontière d'API normalise tout en un chunk terminal. Sans cela, un appelant qui attrape une exception ne peut savoir si elle vient du fournisseur, du middleware, du logging ou de son propre code. 3. L'état asynchrone n'est pas un état synchrone Les requêtes de statut ne sont pas causalement liées à des opérations asynchrones précises. Attendre l'état idle d'un agent comme signal d'achèvement d'un message est faux, car plusieurs opérations en file partagent des intervalles d'exécution : l'idle peut arriver avant que la vôtre ne tourne, ou après celle d'un autre. Le correctif prescrit : un appelant d'automatisation propriétaire d'une exécution définit son intervalle explicitement, de la réception en boîte jusqu'au prochain idle de l'agent entier, et attribue les sorties à cet intervalle plutôt qu'à des messages isolés. Traitez aussi la branche rien-à-attendre, sinon l'appelant se bloque indéfiniment. Un harness d'automatisation bloqué à attendre le mauvais signal d'idle garde une session et ses enfants résidents. La facture, ce n'est pas le blocage : c'est tout ce qui reste vivant derrière. 4. Le dispose doit atteindre la quiescence, pas seulement la demander Demander la terminaison n'est pas l'obtenir. Le dispose attend la terminaison réelle des enfants avant de rendre la main. Et les registres d'écouteurs se ferment avant l'envoi des signaux de kill, pour que les fins tardives atterrissent en silence au lieu de déclencher des callbacks dans un système à demi démonté. C'est le motif au tranchant financier le plus net. Un dispose qui rend la main trop tôt laisse tourner des sous-processus orphelins et des bacs à sable non fermés, et le calcul facturé ne s'arrête pas parce que son parent l'a oublié. 5. Contenir les exceptions de callback dans le dispatcher Enveloppez les boucles de dispatch dans try/catch. Un abonné en échec ne doit pas rejeter la promesse de dispatch ni affamer les écouteurs en file derrière lui. Dans un runtime d'agents, l'écouteur affamé est souvent justement celui qui fait la comptabilité, et c'est ainsi que des relevés d'usage disparaissent sans qu'aucune erreur ne remonte. 6. Ne jamais donner à une sortie non fiable l'environnement ambiant ni des chemins prévisibles La règle la plus forte du document, et la première à adopter. Nettoyez l'environnement des commandes lancées : retirez les variables correspondant à key, secret, token et password avant le démarrage du sous-processus. Utilisez des répertoires privés créés avec des permissions propriétaire uniquement, des noms de fichiers aléatoires et des ouvertures exclusives plutôt que des chemins prévisibles. Deux menaces distinctes. Le nettoyage empêche les identifiants du harness de fuir dans la sortie du sous-processus que le modèle lit ensuite — et une fois lue, cette sortie est dans le journal de session et dans la fenêtre de contexte. Noms aléatoires et création exclusive ferment les courses de liens symboliques sur les répertoires temporaires partagés. 7. Délier les chemins en forme de lien Vérifiez si un chemin est un lien symbolique avant de le supprimer, et supprimez le lien plutôt que de le suivre. La suppression récursive est réservée aux vrais répertoires confirmés, car elle peut traverser des liens jusqu'à leurs cibles et échoue sur les jonctions. Un code de nettoyage qui supprime plus qu'il n'a créé est un mode de défaillance sans plafond de dégâts. Comment se servir de cette liste Portez dès aujourd'hui les motifs 1 et 4 dans votre code de démontage des sous-processus et bacs à sable. C'est là que l'argent fuit. Portez le motif 6 partout où vous lancez un processus dont le modèle lira la sortie. Portez le motif 3 dans votre couche d'automatisation, surtout là où une attente s'exprime en « jusqu'à ce que l'agent soit idle ». Portez le motif 5 dans votre pipeline de télémétrie et vérifiez qu'un écouteur en échec ne peut pas affamer celui de la comptabilité. À lire aussi DeepSeek Harness : le guide complet Garde-fous de dépense dans le harness (EN) Sous-agents et profondeur de délégation (EN) Le journal de session comme registre de coûts (EN) Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # DeepSeek Harness : installation et premier lancement · FinOps LLM URL: https://finopsllm.com/fr/research/deepseek-harness-getting-started DeepSeek Harness : installation, profils et premier lancement Mis à jour August 16, 2026 · première publication August 16, 2026 Réponse rapide: Voici la moitié pratique de notre couverture de DeepSeek Harness : comment faire tourner dsh, ce que le modèle de composition attend de vous, et quelles démos valent dix minutes. La voie la plus... Voici la moitié pratique de notre couverture de DeepSeek Harness : comment faire tourner dsh , ce que le modèle de composition attend de vous, et quelles démos valent dix minutes. La voie la plus rapide npx @deepseek-ai/dsh web Cela démarre l'interface web sur http://127.0.0.1:3080 . À partir de là, deux choses doivent se produire avant que le compositeur de session devienne utilisable : Paramètres → Modèles , et saisir votre clé d'API DeepSeek. La route s'active immédiatement, sans redémarrage. Choisir l'espace de travail , pour ajouter et activer le répertoire du projet. Tant qu'aucun espace n'est actif, le compositeur reste indisponible. Une fois lancé, l'agent peut lire et modifier des fichiers, exécuter des commandes, déléguer des tâches à des sous-agents et planifier. Il demande confirmation selon la politique de permissions active. Depuis les sources git clone https://github.com/deepseek-ai/deepseek-harness pnpm install pnpm run build pnpm dsh web Planchers à connaître : Node 22.19 ou plus récent (la CI couvre 22.19, 24 et 26), Git 2.26 ou plus récent, et Corepack avec pnpm épinglé à pnpm@11.7.0 . Une DEEPSEEK_API_KEY est facultative, lue depuis l'environnement ou un .env ignoré par git à la racine du dépôt ; à côté, DEEPSEEK_BASE_URL peut pointer vers un autre endpoint. Les suites de bout en bout contre l'API réelle s'auto-ignorent quand la clé est absente, si bien qu'un checkout sans clé se construit et se teste proprement. Profils et bundles : le modèle de composition Puisque chaque partie du harness est un plugin, quelque chose doit dire quels plugins sont chargés. C'est le rôle du profil : une composition nommée stockant une liste ordonnée de bundles plus les correctifs de l'utilisateur. Un bundle distribue des lignes de configuration Cordis et du code. Trois profils modèles sont livrés : Profil Ce qu'il compose dsh-base Adaptateurs de modèle, outils, persistance dsh-web-app L'interface navigateur dsh-headless Exécuteur en un coup L'ordre de surcharge en quatre couches La configuration se résout dans un ordre fixe, les couches ultérieures l'emportant : Bundles du profil Correctifs du profil Correctifs au niveau home Surcharges en ligne de commande Apprenez cet ordre avant de commencer à déboguer. Presque toute question du genre « pourquoi utilise-t-il ce modèle » dans un système de configuration en couches se résout en trouvant quelle couche a touché la valeur en dernier, et une surcharge en ligne de commande bat tout ce qui se trouve en dessous. Les sous-systèmes que vous rencontrerez Six clés de registre portent l'essentiel du comportement : ctx.sessions (le journal d'événements en ajout seul), ctx.systemPrompt , ctx.tools (un registre à scopes avec exécution gardée), ctx.agents , ctx.agentLoop et ctx.llm . Si vous étendez le harness, ce sont les noms à chercher en premier. Trois démos à lancer Headless en un coup : pnpm dsh --profile headless "summarize this workspace" . La forme que vous câbleriez dans la CI ou dans une tâche planifiée. Introspection Cordis : pnpm run demo:cordis . Auto-référentielle : elle inspecte et modifie son propre runtime de plugins en cours d'exécution. C'est la démonstration la plus nette que l'argument des plugins est structurel et non marketing. Automatisation ACP : pnpm run demo:acp . Un serveur d'automatisation parlant JSON-RPC sur stdio, qui est la surface d'intégration pour piloter le harness depuis un autre système. Si vous comptez contribuer Quelques conventions font gagner du temps. Les marqueurs TODO sont gradués par urgence : FIXME bloque une release, TODO veut dire bientôt, XXX veut dire un jour. Lefthook exécute pre-commit (enregistrements de pairing en staged, .oxlintrc.staged.json , régénération des avis tiers, espaces, gardien du manifeste vendor), pre-merge-commit et pre-push ( pnpm run typecheck ). Les hooks sautent délibérément les tests et les builds : la CI possède la couverture exhaustive, et pnpm run check:all est la porte locale complète et optionnelle. Deux bizarreries expliquent une structure autrement déroutante. Le build se scinde en agrégats tsconfig Host et Client parce que les deux côtés fusionnent par déclaration l'interface Context de Cordis sous les mêmes clés, et un seul programme TypeScript voyant les deux fusions signale une collision. Et les exemples de code de la documentation restent honnêtes grâce aux blocs ts type-equiv plus pnpm run verify-type-equiv , de sorte que des déclarations collées ne peuvent pas dériver silencieusement des sources. Fixer les attentes Le README le dit sans détour : ceci est une developer preview, et il y aura des changements cassant la compatibilité. La découverte des plugins passe par le topic GitHub dsh-plugin , le projet est sous licence MIT et les dépendances tierces sont listées dans THIRD_PARTY_NOTICES.md . Évaluez-le maintenant ; standardisez plus tard. À lire aussi DeepSeek Harness : le guide complet Ce que « tout est un plugin » apporte vraiment (EN) Où placer les garde-fous de dépense (EN) Le journal de session comme registre de coûts (EN) Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Objectifs et boucle Ralph dans DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/fr/research/deepseek-harness-goals-ralph-loop DeepSeek Harness : objectifs, tours d'objectif et boucle Ralph Mis à jour August 16, 2026 · première publication August 16, 2026 Réponse rapide: La plupart des mauvaises surprises de coût avec les agents ne tiennent pas au prix d'un token. Elles tiennent au nombre de fois où l'agent a décidé de réessayer. DeepSeek Harness donne un vocabulaire... La plupart des mauvaises surprises de coût avec les agents ne tiennent pas au prix d'un token. Elles tiennent au nombre de fois où l'agent a décidé de réessayer. DeepSeek Harness donne un vocabulaire à ce comportement, premier pas pour y mettre un chiffre. Tour, étape, round Trois unités, nettement séparées dans le glossaire du projet : Unité Définition Sens économique Étape Une requête modèle plus les exécutions d'outils qu'elle produit L'atome de facturation Tour Une vidange de l'entrée, close quand le modèle s'arrête ou qu'une politique intervient L'unité visible de l'utilisateur Round Une itération de politique externe, tel un tour d'objectif ou une tentative avec agent neuf Le multiplicateur au-dessus des tours Les rounds sont la couche que les modèles de coût maison omettent presque toujours. Si votre prévision compte des requêtes et que votre système enchaîne des rounds, votre prévision mesure la mauvaise chose. Les objectifs sont des cibles durables Un objectif est une cible d'achèvement durable dotée d'une phase explicite : actif, en pause, bloqué ou terminé. Contrairement à un message, il persiste d'un tour à l'autre, si bien que l'agent porte une cible permanente. Chaque cycle de continuation admis pour cet objectif est un tour d'objectif, matérialisé par un unique tour issu de l'objectif. L'admission est régie par une activation d'objectif : une permission locale au processus d'admettre un tour de plus, armée ou désarmée. Ce seul bit est l'étrangleur du travail ouvert. Une cible permanente doublée d'une continuation automatique est une autorisation de dépense sans plafond. C'est précisément pourquoi il est documenté que créer et modifier un objectif exige une autorisation humaine directe : quelqu'un doit assumer le budget du travail ouvert. La boucle Ralph est un redémarrage délibéré La boucle Ralph est un flux au premier plan qui itère vers un objectif immuable en démarrant des sessions d'agent neuves, bâti sur les primitives de flux et de sous-agents du harness. Un round Ralph est une session enfant neuve, sans amorce de conversation du parent. La continuité est portée par un handoff Ralph : un rapport normalisé, borné et structuré contenant statut, résumé, preuves et blocages. L'économie est ici réellement intéressante, et à double tranchant. Repartir propre veut dire que chaque round paie un petit coût d'entrée au lieu de traîner une conversation toujours plus grosse : le coût par round reste plat plutôt que de grimper. Mais rien dans un départ neuf ne garantit un progrès, et une boucle qui redémarre à bas prix peut s'offrir bien plus de redémarrages. Le handoff borné est le contrôle qui rend le motif viable : il est le seul canal entre les rounds, donc il plafonne la croissance du contexte par construction. Surveillez deux chiffres — rounds par objectif, et répétition ou non de la liste de blocages du handoff. Un blocage présent dans trois handoffs consécutifs, c'est une boucle qui ne convergera pas, et chaque round de plus est du pur gaspillage. Les commandes ne sont pas des outils La distinction compte, car elle change ce que l'on mesure. Une commande humaine est une instruction préfixée d'un slash, routée par le plan de commandes vers les adaptateurs orientés humain : découverte, analyse, dispatch, annulation et rendu, sous la responsabilité des adaptateurs d'interface. Elle est explicitement distincte d'un outil de modèle. La commande d'objectif en fait partie. Concrètement : un humain qui tape une commande slash n'est pas le modèle qui dépense des tokens. Imputez les deux séparément, sinon votre coût par session accusera le mauvais acteur. Quatre contrôles pour le travail ouvert Un nombre maximal de rounds par objectif, appliqué avant admission plutôt que constaté après coup. Un budget de tokens cumulé couvrant tous les rounds d'un objectif, et non par round. Une détection de convergence sur le handoff : des blocages répétés arrêtent la boucle. Une autorisation humaine explicite pour la création d'objectif, conservée comme trace de qui a autorisé la dépense. À lire aussi DeepSeek Harness : le guide complet Sous-agents et profondeur de délégation (EN) Garde-fous de dépense dans le harness (EN) Le journal de session comme registre de coûts (EN) Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Garde-fous de dépense dans DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/fr/research/deepseek-harness-guardrails Où placer les garde-fous de dépense dans DeepSeek Harness Mis à jour August 16, 2026 · première publication August 16, 2026 Réponse rapide: Un agent qui découvre son budget sur la facture mensuelle n'a pas de budget : il a un post-mortem. La question utile à poser à un harness est : où peut-on se placer dans la boucle et dire non ?... Un agent qui découvre son budget sur la facture mensuelle n'a pas de budget : il a un post-mortem. La question utile à poser à un harness est : où peut-on se placer dans la boucle et dire non ? DeepSeek Harness y répond avec deux points d'extension en cascade nommés. D'abord, la forme de la boucle Le harness emploie un modèle tour et étape. Une étape est une requête modèle plus les appels d'outils qu'elle produit. Un tour contient zéro étape ou plus. Le déroulé d'un tour est en gros : prise de l'entrée, assemblage du prompt, agent/pre-step , flux LLM, exécution des outils, clôture de l'étape, clôture du tour. Deux flux d'événements avancent en parallèle. session/event porte les faits durables de relecture — chunks, messages, appels d'outils, résultats. agent/* porte les signaux de coordination en direct — statut, boîte de réception, interception de requêtes. Les garde-fous appartiennent au second ; la comptabilité au premier. Point d'interception 1 : agent/pre-step C'est le point de contrôle avant l'envoi de la requête modèle. La documentation précise que la décision renvoyée par agent/pre-step fait autorité et que les listeners qui enveloppent next() préservent les messages en aval sauf remplacement intentionnel. C'est cette propriété qui en fait une porte budgétaire utilisable : un listener peut refuser une étape proposée, ou la modifier, et la décision tient. Ce qui a sa place ici : Plafonds d'étapes par tour. Le mode de défaillance de l'agent emballé est un tour qui ne converge jamais. Un plafond dur transforme une facture non bornée en facture bornée. Budgets cumulés de tokens. Additionnez l'usage déjà consigné dans le journal de session et refusez l'étape suivante au-delà du seuil. Rétrogradation de modèle. Réécrivez l'étape vers une route moins chère dès qu'un tour a dépassé un seuil souple, plutôt que de la refuser sèchement. Limites de taille de contexte. L'assemblage du prompt a lieu avant ce hook : la requête assemblée est donc visible et mesurable ici. Point d'interception 2 : tools/pre-execute L'exécution d'outils est un pipeline en trois phases. La cascade tools/pre-execute passe d'abord, les gardes monotones ensuite, et seulement alors le corps de l'outil s'exécute — en bac à sable, avec filtrage du système de fichiers. Ensuite une cascade post-execute peut accepter, bloquer, remplacer ou enrichir le résultat, et ToolDefinition.finalizeContent impose des invariants de contenu de façon synchrone. La couche de permissions est délibérément asymétrique. Les gardes monotones enregistrés refusent ou s'abstiennent, identité protégée : ils n'accordent jamais. Si un garde refuse, ou si l'invite unique de ctx.approval est absente ou sans réponse possible, le résultat est un refus et le corps de l'outil est ignoré. Échec fermé, pas ouvert. Les mutations du système de fichiers sont filtrées à part : seules les mutations fs/write-intent ou fs/edit-intent passent. Écrire n'est pas un effet de bord incident de l'exécution d'un outil. Deux propriétés rendent ce pipeline digne de confiance comme point de contrôle : les gardes ne peuvent que refuser, et une invite d'approbation sans réponse possible refuse. La plupart des couches de politique maison échouent en ouvert quand le canal d'approbation manque, c'est-à-dire précisément quand on en avait besoin. Ce que le pipeline consigne Trois événements de session forment la piste d'audit : tool/call avant exécution, tool/code-dispatch pour les sous-appels et tool/result comme résultat final faisant autorité. Que les sous-appels soient consignés séparément compte : un unique appel d'outil visible du modèle qui se ramifie en interne ne cache pas sa ramification. Un jeu de garde-fous pratique Contrôle Hook Empêche Étapes maximum par tour agent/pre-step Boucles qui ne convergent pas Plafond cumulé de tokens agent/pre-step Dérive de dépense à petit feu Rétrogradation de route au seuil agent/pre-step Tarif frontière sur du travail bon marché Liste blanche d'outils par classe de coût Garde monotone Outils coûteux en contexte bon marché Refus des sous-processus et du réseau Politique ctx.sandbox Sortie réseau non mesurée Filtrage du write-intent Couture ctx.fs Mutations non relues La réserve DeepSeek Harness est en developer preview et son propre README annonce des changements cassant la compatibilité. Ces noms et sémantiques de hooks sont ceux documentés aujourd'hui ; traitez les plugins de garde-fous bâtis dessus comme du code que vous rouvrirez, et épinglez la version contre laquelle vous avez construit. À lire aussi DeepSeek Harness : le guide complet Le journal de session comme registre de coûts (EN) Tout est un plugin : l'architecture (EN) Garde-fous de dépense pour agents (EN) Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # DeepSeek Harness : tout est un plugin · FinOps LLM URL: https://finopsllm.com/fr/research/deepseek-harness-plugin-architecture DeepSeek Harness : ce que « tout est un plugin » apporte vraiment Mis à jour August 16, 2026 · première publication August 16, 2026 Réponse rapide: DeepSeek AI a publié deepseek-harness (dsh), un harness d'agents sous licence MIT dont le slogan de conception est que tout est un plugin. Cette formule est employée à la légère dans l'écosystème des... DeepSeek AI a publié deepseek-harness ( dsh ), un harness d'agents sous licence MIT dont le slogan de conception est que tout est un plugin. Cette formule est employée à la légère dans l'écosystème des outils d'agents, il vaut donc la peine de préciser ce qu'elle signifie ici et où elle change l'économie de l'exploitation d'agents. Cordis, pas un framework à hooks Le harness tourne sur Cordis , un runtime de plugins dont le modèle veut que les plugins apportent des services, des événements typés et des effets réversibles à un contexte partagé. Le document d'architecture est explicite : il n'y a pas de noyau privilégié. Adaptateurs de modèle, registres d'outils, journaux de session et la boucle d'agent elle-même sont tous des plugins. Rien ne se trouve en dessous comme moteur inamovible. C'est important, car la forme habituelle d'un framework d'agents « extensible » est un noyau fixe plus une surface de hooks. Vous pouvez observer et décorer, mais pas remplacer. Remplacer veut dire forker. Cordis inverse cela : les pièces que vous voudriez remplacer sont les unités de composition. Les coutures de capacité : la partie qui compte en exploitation Le harness formalise cela avec ce qu'il appelle une couture de capacité (capability seam). Une couture est une interface de service avec plus d'une implémentation, et chaque service occupe l'un de trois rôles : Rôle Ce qu'il fait Owner Le paquet qui déclare l'interface du service Implémentation Un paquet fournissant un comportement concret (les coutures en ont plusieurs) Consommateur Un paquet qui appelle le service, aveugle au fournisseur actif Tous les services ne sont pas des coutures. La documentation en distingue trois sortes : coutures interchangeables ( ctx.llm , ctx.subprocess ), services de noyau à owner unique ( ctx.sessions , ctx.agents ) et points de composition coordonnant d'autres services ( ctx.agentLoop ). Savoir lequel est lequel vous dit où vous avez le droit de substituer un comportement et où non. Les quatre coutures aux conséquences de coût ctx.llm , la couture du modèle. Détenue par le paquet llm ; les implémentations comprennent llm-deepseek , llm-pi-ai et llm-replay . La boucle d'agent consomme un service de flux neutre vis-à-vis du fournisseur et ignore quel backend tourne. llm-replay est le plus intéressant pour le travail sur les coûts : il permet de rejouer une session enregistrée sans repayer l'inférence. ctx.fs , la couture du système de fichiers. Les fournisseurs sont fs-local (système de fichiers hôte), fs-sandbox (mutations confinées) et fs-e2b (une machine Linux distante en bac à sable). La couture découple les outils que le modèle voit de l'endroit où l'exécution a physiquement lieu. ctx.sandbox , la couture d'exécution. Les consommateurs transmettent argv ; les implémentations enveloppent l'exécution sous politique. sandbox-local applique sur l'hôte, sandbox-policy centralise les valeurs par défaut de déploiement. ctx.subagents , la couture de délégation. Six implémentations couvrant le spawn en processus, le fork, les ponts ACP, Codex, Claude Code et les agents fondés sur SDK. C'est là qu'un harness fige d'ordinaire une hypothèse ; ici c'est un échange. Tout levier de coût significatif dans un système d'agents est un changement de fournisseur : router vers un modèle moins cher, déplacer l'exécution vers un bac à sable moins cher, remplacer un transport de sous-agents par un transport local. Quand ce sont des coutures, le changement est une modification de configuration. Quand ce n'en sont pas, le changement est un fork que vous maintenez désormais. Pourquoi c'est un sujet FinOps et pas seulement d'architecture L'échec récurrent des programmes de coût sur les agents n'est pas que les équipes choisissent un modèle cher. C'est que le harness rend le choix cher structurel. Une fois la sélection du modèle, le lieu d'exécution des outils et le transport de délégation cuits dans le code applicatif, chaque optimisation devient un projet d'ingénierie avec son calendrier et son risque de régression. Les équipes reportent alors l'optimisation, et la dépense s'accumule. Un harness fondé sur des coutures déplace ces décisions dans la composition. Cela ne les rend pas gratuites, mais les fait passer de refactorisations à configuration, ce qui est la différence entre une initiative trimestrielle et un après-midi. La réserve à énoncer clairement DeepSeek Harness est en developer preview et son README dit, sans l'adoucir, qu'il y aura des changements cassant la compatibilité. Construire dès maintenant un outillage de coût de production directement contre ses interfaces internes revient à s'engager à leur courir après. Évaluez-le, prototypez avec, mais épinglez vos versions et attendez-vous à du mouvement. À lire aussi DeepSeek Harness : le guide complet Le journal de session comme registre de coûts (EN) Où placer les garde-fous de dépense (EN) Installation, profils et premier lancement (EN) Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Le journal de session de DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/fr/research/deepseek-harness-session-log Le journal de session de DeepSeek Harness comme registre de coûts Mis à jour August 16, 2026 · première publication August 16, 2026 Réponse rapide: La plupart des stacks d'agents boulonnent le suivi des coûts après coup : un wrapper autour de l'appel modèle qui écrit des tokens dans un système séparé, lequel finit par diverger de la réalité.... La plupart des stacks d'agents boulonnent le suivi des coûts après coup : un wrapper autour de l'appel modèle qui écrit des tokens dans un système séparé, lequel finit par diverger de la réalité. DeepSeek Harness procède à l'inverse. Le journal de session est l'artefact primaire, et l'usage de tokens vit dedans. La session est un journal d'événements append-only Une session est une suite ordonnée et seulement extensible d'entrées SessionEvent typées. Chaque événement porte quatre champs : Champ Signification type Le genre d'événement, par exemple assistant/message seq Numéro de séquence monotone dans la session time Horodatage data La charge utile propre au type Les événements de surface (ce qu'une interface affiche) ajoutent deux champs : sourceEventSeqs , qui renvoie aux événements bruts dont ils dérivent, et surfaceOp . Ces renvois sont la raison pour laquelle un chiffre de coût peut être remonté jusqu'aux événements exacts qui l'ont produit. Les événements qui comptent pour un modèle de coût turn/start et turn/end : le crochet extérieur d'une requête utilisateur. turn/end porte un TurnEndReason indiquant si le tour a abouti, a été interrompu ou tronqué. step/start et step/end : une étape est une requête modèle plus les appels d'outils qu'elle déclenche. C'est l'unité de facturation naturelle. assistant/message : sortie du modèle, avec TokenUsage optionnel. assistant/chunk : sortie en streaming, y compris les chunks d'usage. tool/call et tool/result : exécution d'outils ; le résultat peut porter meta . request/header et request/context : l' EpochHeader et le contexte de requête avec fournisseur, modèle et fenêtre de contexte. Ce couple est ce qui met un prix sur un chiffre d'usage. La règle directrice de la documentation est : ce qui est visible du modèle est journalisé . Tout ce qui entre dans le contexte du modèle laisse un événement. Le journal est donc complet par construction, et non complet tant que personne n'oublie de l'instrumenter. L'usage voyage avec la sortie L'usage de tokens n'est pas écrit dans un canal latéral : il voyage avec la sortie à laquelle il appartient. Préférez les chunks d'usage ( assistant/chunk avec { type: 'usage' } ) car ils collent au plus près de ce que le fournisseur a réellement facturé ; repliez-vous sur assistant/message.usage en l'absence de chunk. Un modèle de coût qui lit ainsi ne peut jamais attribuer un chiffre à une étape qui ne l'a pas produit. Historique dérivé, pas dupliqué L'historique de messages que voit le modèle est projeté depuis le journal d'événements plutôt que maintenu à côté comme une seconde vérité. C'est la différence entre un système dont les chiffres de coût concordent avec son exécution et un système où les deux divergent sans qu'on puisse dire lequel a raison. « Visible du modèle veut dire journalisé » est la seule règle qui rende possible une reconstruction des coûts. Sans elle, tout chiffre d'attribution est une estimation dont la marge d'erreur est inconnue. Ce qu'il faut bâtir dessus Joignez step/start et step/end pour former des spans d'étape : l'unité sur laquelle vous rapporterez les coûts. Attachez request/context (fournisseur, modèle, fenêtre de contexte) et le prix issu de l'usage du chunk à chaque span. Comptez l'éventail de tool/call par étape : la démultiplication d'outils est la raison habituelle pour laquelle un tour coûte soudain dix fois plus. Surveillez la distribution des TurnEndReason . Les tours interrompus et tronqués sont du travail payé sans résultat, et c'est la première métrique dont vous êtes privé sans journal. À lire aussi DeepSeek Harness : le guide complet Tout est un plugin : l'architecture (EN) Où placer les garde-fous de dépense (EN) Conventions GenAI d'OpenTelemetry (EN) Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Sous-agents et délégation dans DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/fr/research/deepseek-harness-subagents Sous-agents DeepSeek Harness : la délégation comme multiplicateur de coût Mis à jour August 16, 2026 · première publication August 16, 2026 Réponse rapide: Le moyen le plus rapide de multiplier une facture d'agents est de laisser des agents en créer d'autres. Une requête utilisateur devient un arbre, et l'arbre n'a pas de taille naturelle. DeepSeek... Le moyen le plus rapide de multiplier une facture d'agents est de laisser des agents en créer d'autres. Une requête utilisateur devient un arbre, et l'arbre n'a pas de taille naturelle. DeepSeek Harness ne traite donc pas la délégation comme une fonctionnalité, mais comme une couture assortie de limites explicites. Les sous-agents sont une couture, pas un composant intégré La délégation passe par ctx.subagents . Contrairement à l'exécuteur shell, qui n'a qu'une seule implémentation, les fournisseurs de sous-agents sont enregistrés par nom et plusieurs peuvent coexister. La documentation recense six transports : création in-process et fork (agents ordinaires via le contexte du parent), un pont ACP pour le déploiement distant, Codex, Claude Code et une variante fondée sur le SDK. Côté coût, cela veut dire que le prix d'un enfant dépend du fournisseur qui l'a créé. Un agent forké en processus et un agent distant lancé via un pont ACP se ressemblent dans le code appelant et n'ont rien de commun sur la facture. Deux modes de délégation, deux profils de coût Mode Forme Caractéristique de coût Coup unique Créer l'enfant, envoyer le prompt, attendre le résultat, jeter Borné, imputable au tour du parent Continuable Session d'arrière-plan durable avec activation résidente Ouvert ; s'accumule d'un tour à l'autre Le mode coup unique se résout en un handle d'exécution assorti d'une promesse de résultat terminal. Les enfants continuables coûtent plus cher à maintenir : un gestionnaire de continuation réserve l'identité, compose l'enfant, ordonne chaque tour via la boîte de réception de l'enfant, et le fournisseur ne contribue qu'aux métadonnées de création initiale. Les activations ont trois états : en cours, en attente (au repos mais détenant des activations enfants inachevées) et réglée. Un message reçu sans activation vivante déclenche une reprise à froid depuis la session persistée. Les reprises à froid sont le poste que l'on oublie. L'état est reconstitué depuis le journal, donc les tokens d'entrée sont proportionnels à la taille du journal. Un enfant de longue durée peu sollicité peut coûter plus cher par message qu'un enfant toujours actif. Les capacités échouent bruyamment, pas en silence Le harness valide les capacités demandées auprès du fournisseur et rejette par une erreur typée plutôt que d'ignorer silencieusement. Les capacités de démarrage couvrent les schémas de sortie, les limites de profondeur, les filtres d'outils et les personas, et correspondent une à une aux options de la requête. Demander ce que le fournisseur ne sait pas faire se voit au démarrage, pas sur la facture. La profondeur est plafonnée, et le plafond ne se contourne pas La profondeur de délégation est persistée dans l'en-tête de session et un champ d'exécution suit la plus grande des deux valeurs, si bien qu'une reprise à froid ne peut pas l'abaisser. Le démarrage est rejeté si la profondeur dérivée dépasse maxDepth ou les bornes d'entier sûr. Un parent qui lance trois enfants, chacun en lançant trois autres, a transformé une requête utilisateur en treize agents. Les plafonds de profondeur font la différence entre un éventail que vous avez dimensionné et un éventail que vous avez découvert. Découvrir coûte peu, livrer fait autorité listChildren() renvoie un corpus privilégiant le vivant via une accélération à trois niveaux : cache de filigrane, puis point de contrôle de projection, puis inspection de la persistance. listDescendants() parcourt en préordre et ajoute les positions de parent et de profondeur. Aucune des deux ne consulte les registres d'agents, les activations ou les fournisseurs ; la remise des messages reste l'autorité. Pour l'imputation des coûts, c'est appréciable : l'arbre s'énumère à bas prix, quand vous voulez. Les résultats portent une raison d'arrêt La sortie est le dernier message d'assistant non vide ou le flux de texte accumulé ; une sortie structurée facultative est validée contre le schéma demandé. Le stopReason est une union extensible par fusion : completed, aborted, error, max-tokens, refusal. Tout ce qui n'est pas completed signifie une sortie partielle transformée en résultats d'outil en erreur : payée et inachevée. Quoi mesurer Enfants par tour de parent et descendants par requête utilisateur. Profondeur maximale observée face au plafond configuré. Part des enfants continuables repris à froid, et taille du journal à la reprise. Distribution des raisons d'arrêt : une forte part de max-tokens ou error, c'est du travail payé et inachevé. À lire aussi DeepSeek Harness : le guide complet Tout est un plugin : l'architecture (EN) Garde-fous de dépense dans le harness (EN) Le journal de session comme registre de coûts (EN) Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Portées d'outils dans DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/fr/research/deepseek-harness-tool-scopes DeepSeek Harness : portées, restrictions et masquage d'outils Mis à jour August 16, 2026 · première publication August 16, 2026 Réponse rapide: Les catalogues d'outils grossissent. Quelqu'un ajoute un outil de navigateur, quelqu'un un outil de base de données, quelqu'un cinq opérations de terminal, et un an plus tard chaque agent du système... Les catalogues d'outils grossissent. Quelqu'un ajoute un outil de navigateur, quelqu'un un outil de base de données, quelqu'un cinq opérations de terminal, et un an plus tard chaque agent du système se voit proposer quarante outils, qu'il en ait besoin ou non. On en parle d'habitude comme d'un problème de sécurité. C'est aussi une ligne de dépense. DeepSeek Harness propose un modèle de portée par agent qui traite les deux d'un coup. Pourquoi le catalogue est un coût récurrent Les définitions d'outils font partie de la requête. Le harness enregistre un événement d'en-tête de requête portant la configuration, le prompt système et l'ensemble d'outils tels qu'envoyés, ce qui rend la chose concrète : le catalogue est retransmis à chaque requête modèle de la session, donc c'est une taxe fixe par étape et non un coût unique. Il y a un second effet, plus large. Un catalogue étendu élargit l'espace de choix du modèle. Plus de sélections plausibles mais fausses veut dire plus d'étapes qui ne produisent rien d'utile, et l'étape est l'unité de facturation. Rogner la surface abaisse ensemble le plancher de tokens et le taux d'erreur. Le vocabulaire Terme Sens Portée L'unité d'enregistrement par agent pour outils, prompts, variables, restrictions et écouteurs Clé de portée L'identité opaque qui indexe une portée, comparée par identité d'objet — en général l'agent vivant lui-même Contexte d'agent Le contexte propre à l'agent, où les enregistrements sont liés à sa durée de vie et visibles dans la portée Restriction Un filtre sur l'ensemble global d'outils pour une portée, appliqué par intersection Masquage Un élément de portée qui remplace son homonyme global, à l'intérieur de cette portée seulement Fenêtre de setup Le créneau de création où le créateur compose le monde de l'agent, avant publication ou premier assemblage de prompt Comment la composition se résout Les restrictions filtrent d'abord l'ensemble global, puis les enregistrements locaux à la portée s'y ajoutent. Cet ordre est ce qui rend le moindre privilège praticable : on part d'une intersection avec le catalogue global — jamais plus que global — puis on ajoute exactement les outils spécifiques dont cet agent a besoin. Le masquage offre le cas de substitution sans fork. Un agent peut recevoir une autre implémentation derrière un nom d'outil familier — variante en lecture seule, variante mesurée, backend moins cher — tandis que tous les autres continuent de voir la version globale. La liaison à la durée de vie compte pour la même raison que le dispose. Les enregistrements de portée s'achèvent avec le contexte de l'agent, donc un enfant éphémère ne peut pas faire fuiter ses contributions dans le monde du parent. Toute la composition se joue dans la fenêtre de setup, avant que l'agent soit publié ou assemble son premier prompt. Les décisions de privilège prises après le premier prompt ne sont plus des décisions de privilège : c'est du nettoyage. Dispatch par portée et lignage Les événements concernant un agent sont dispatchés avec le porteur de cet agent, si bien qu'un écouteur sait de qui il observe l'activité ; les événements de niveau registre restent non filtrés. À part cela, le lignage — session parente, profondeur de délégation, profondeur de sous-agent — est décrit explicitement comme une donnée qui n'affecte pas en soi la visibilité. Cette séparation vaut d'être reprise. Un enfant n'hérite pas d'un accès parce qu'il est enfant ; l'accès se compose délibérément dans sa fenêtre de setup. Le privilège hérité par défaut, c'est exactement comme un sous-agent de résumé bon marché finit par détenir le même jeu d'outils coûteux que son parent. Quatre choses à en faire Comptez vos définitions d'outils et multipliez par le nombre d'étapes par session. C'est votre taxe fixe d'outils par session, en tokens. Définissez un jeu d'outils minimal viable par rôle d'agent, et appliquez-le comme restriction plutôt que comme convention. Masquez les outils coûteux par des variantes bon marché ou en lecture seule dans les contextes à faible valeur, plutôt que de les retirer entièrement. N'héritez jamais par défaut du jeu d'outils du parent dans les sous-agents. Composez-le. À lire aussi DeepSeek Harness : le guide complet Garde-fous de dépense dans le harness (EN) Sous-agents et profondeur de délégation (EN) Ce que « tout est un plugin » apporte (EN) Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Contrôler le coût dans le pipeline d’évaluation LLM · FinOps LLM URL: https://finopsllm.com/fr/research/evals-cost-control Contrôler le coût dans le pipeline d’évaluation LLM Mis à jour August 27, 2026 · première publication August 27, 2026 Réponse rapide: Les évaluations LLM ont besoin de leur propre politique de coût. Un job CI peut coûter plus que la fonctionnalité protégée. Utilisez budget par exécution, échantillonnage, fixtures en cache et seuils... Les évaluations LLM ont besoin de leur propre politique de coût. Un job CI peut coûter plus que la fonctionnalité protégée. Utilisez budget par exécution, échantillonnage, fixtures en cache et seuils qualité. Budgéter Plafonnez prompts, modèles, reprises et dollars avant le lancement. Séparez smoke tests, régressions et certification. Mesurer le signal Stratifiez par flux, impact, difficulté et échecs connus. Conservez la version du jeu. Arrêter au bon moment Arrêtez si le coût ou le seuil qualité est dépassé et consignez modèle, tokens, cache, reprises et résultat. À lire aussi Coût par tâche réussie Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # FinOps pour LLM et GenAI : un cadre pratique · FinOps LLM URL: https://finopsllm.com/fr/research/finops-for-llm FinOps pour LLM : un cadre pratique FinOps pour les LLM est la pratique de rendre visible, attribuable, optimisable et responsable les dépenses d'IA. Il emprunte les principes de FinOps cloud, mais les générateurs de coûts sont différents. Une facture cloud est déterminée par les instances, le stockage, le transfert et les engagements. Une facture LLM est déterminée par les tokens d'entrée, les tokens de sortie, les écritures de cache, les lectures de cache, les nouvelles tentatives, le mélange de modèles, la longueur du contexte, l'éligibilité des lots et les exigences de qualité. La première erreur que commettent les équipes est de traiter les dépenses en LLM comme un chiffre unique au niveau du fournisseur. Cela cache les vrais leviers. Un endpoint de résumé de support, un workflow d'agent, une tâche d'enrichissement nocturne et une suite d'évaluation peuvent tous utiliser le même modèle, mais ils ont des besoins de latence différents, des seuils de qualité, des capacités de cache et une propriété différents. FinOps commence lorsque ces charges de travail sont séparées. Pilier Question centrale Ce qu'il produit 1. Visibilité Qu'est-ce que nous payons exactement, requête par requête? Enregistrements d'utilisation normalisés divisés par entrée, sortie, écriture de cache, lecture de cache, lot et dépenses de nouvelle tentative 2. Attribution Quelle équipe, fonctionnalité, client ou charge de travail l'a causé? Dépenses attribuées aux propriétaires : environnement, endpoint, équipe, tenant, modèle, classe de charge de travail 3. Optimisation Quel levier réduit le coût par tâche réussie sans affecter la qualité? Modifications de routage, cache, lots, compactage et arbitrage déployées derrière des indicateurs 4. Responsabilité Qui examine les chiffres et agit sur eux chaque mois? Rapports de showback (puis chargeback) et un rythme opérationnel réconcilié avec les factures 1. Visibilité La visibilité signifie normaliser les factures des fournisseurs et les journaux de passerelle en un enregistrement commun. Chaque requête doit avoir assez de métadonnées pour répondre : qui en est propriétaire, quelle fonctionnalité l'a générée, quel modèle l'a gérée, combien de classes de tokens ont été facturées, si l'appel a été réessayé et si la sortie a produit de la valeur pour l'utilisateur. Une bonne visibilité sépare les dépenses d'entrée, de sortie, d'écriture de cache, de lecture de cache, de lot et de nouvelle tentative. Sans cette séparation, les équipes comptent accidentellement les réductions de lecture de cache comme des économies, manquent les boucles de nouvelle tentative et comparent les fournisseurs sur le prix catalogue plutôt que sur le coût par tâche réussie. 2. Attribution L'attribution attribue les dépenses aux équipes, produits, clients et charges de travail. Le point n'est pas le blâme ; le point est la qualité de la décision. Une équipe financière ne peut pas gouverner les dépenses si chaque ligne dit « OpenAI ». Un leader en ingénierie ne peut pas optimiser une surface produit si les dépenses sont regroupées uniquement par compte fournisseur. L'attribution minimale utile comprend généralement l'environnement, l'endpoint, le propriétaire de l'équipe, le client ou le tenant si autorisé, le modèle, le fournisseur et la classe de charge de travail. Les programmes matures ajoutent des métriques métier comme ticket résolu, analyse complétée, rapport généré ou tâche d'agent réussie. 3. Optimisation L'optimisation doit suivre l'attribution. Les leviers courants sont le routage de modèles, le cache sémantique, le cache des prompts, la compaction du contexte, le routage des lots, l'arbitrage des fournisseurs et l'ajustement de la politique de secours. Chaque levier change la facture différemment. Le routage change le mélange de modèles. Le cache change l'économie des tokens d'entrée et la latence. Les lots déplacent le travail vers des voies asynchrones à prix réduit. La compaction réduit le contexte répété. Le test n'est pas « le nombre de tokens a-t-il diminué? » Le test est « le coût par tâche réussie a-t-il diminué sans casser la qualité, la latence ou la fiabilité? » 4. Responsabilité Le showback doit venir avant le chargeback. Donnez d'abord aux équipes une vue mensuelle crédible de leurs dépenses et de leurs facteurs. Une fois les chiffres fiables, le chargeback peut avoir du sens pour les organisations matures. L'objectif est un rythme opérationnel reproductible : examiner les plus grands facteurs, s'accorder sur les candidats à l'optimisation, déployer des modifications derrière des indicateurs et réconcilier avec la facture suivante. Connexes Qu'est-ce que FinOps pour LLM? - la discipline opérationnelle. FinOps d'IA - la pratique plus large dans laquelle FinOps pour LLM s'inscrit. Attribution des coûts des LLM - comment fonctionne la couche d'attribution. Chargeback et showback des LLM - déplacer les coûts vers les propriétaires. Vous voulez que cela s'applique à vos propres dépenses en LLM? FinOps LLM réalise un audit gratuit de vos coûts d'IA et montre où se trouvent les économies. Réservez votre audit gratuit → Retour à la recherche --- # Première clôture mensuelle IA · FinOps LLM URL: https://finopsllm.com/fr/research/first-ai-month-end-close Première clôture mensuelle IA Mis à jour August 27, 2026 · première publication August 27, 2026 Réponse rapide: La première clôture mensuelle IA doit commencer par les factures brutes et une période verrouillée, pas par une capture d’écran. Fermez d’abord le montant financier, expliquez ensuite l’usage, puis... La première clôture mensuelle IA doit commencer par les factures brutes et une période verrouillée, pas par une capture d’écran. Fermez d’abord le montant financier, expliquez ensuite l’usage, puis allouez la dépense. Verrouiller la période Définissez fuseau, devise, remises, crédits et date de coupure. Figez la grille tarifaire et conservez les identifiants de facture et la fenêtre de télémétrie. Rapprocher puis allouer Reliez les événements aux exports fournisseur par compte, modèle, type de token et jour. Enquêtez sur le résidu. Allouez ensuite par fonctionnalité, équipe, environnement, cohorte et charge; séparez la plateforme partagée. Expliquer l’écart Décomposez-le en tarif, volume, mix et efficacité. Reliez chaque mouvement à un déploiement, trafic, migration ou comportement d’agent, puis faites signer la réconciliation et la politique. À lire aussi Rapprochement des factures IA Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # FOCUS 1.5 standardise le suivi des jetons IA · FinOps LLM URL: https://finopsllm.com/fr/research/focus-1-5-ai-token-tracking FOCUS 1.5 : suivi natif des jetons IA et Price Sheet Mis à jour September 19, 2026 · première publication August 15, 2026 Réponse rapide: La FinOps Foundation a validé la sortie de FOCUS 1.5 pour décembre 2026. Cette spécification apporte pour la première fois un suivi natif des jetons d'IA au schéma de facturation cloud, avec... La FinOps Foundation a validé la sortie de FOCUS 1.5 pour décembre 2026. Cette spécification apporte pour la première fois un suivi natif des jetons d'IA au schéma de facturation cloud, avec l'identification du modèle, la distinction entrée/sortie et un jeu de données dédié Price Sheet . 1. Les apports majeurs de FOCUS 1.5 Identifiant de modèle normalisé : Facilite la comparaison entre AWS Bedrock, Azure OpenAI et GCP. Mesures de jetons distinctes : Colonnes séparées pour l'entrée, la sortie et les jetons en cache. Jeu de données Price Sheet : Découplage clair entre grille tarifaire publique et consommation réelle. 2. Ce que FOCUS ne prend pas en charge La norme standardise la sortie des fournisseurs cloud, mais ne résout pas l'attribution interne . Les fournisseurs ignorent quelle équipe ou fonctionnalité a émis la requête. L'étiquetage au niveau de la passerelle reste indispensable. 3. Comment s'y préparer Conservez dès à présent les métriques de jetons par type, tracez l'identifiant du modèle sur chaque appel et rapprochez mensuellement vos journaux des factures réelles. À lire aussi Attribution des coûts LLM Rapprochement des factures d'IA Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # L’offre gratuite est un coût d’acquisition · FinOps LLM URL: https://finopsllm.com/fr/research/free-tier-is-an-acquisition-cost L’offre gratuite comme coût d’acquisition Mis à jour September 1, 2026 · première publication September 1, 2026 Réponse rapide: Servir de l’inférence n’est pas gratuit. Quand un fournisseur vous offre un palier gratuit, des limites généreuses en préversion ou un endpoint sans marque qui ne coûte rien, ce calcul est payé... Servir de l’inférence n’est pas gratuit. Quand un fournisseur vous offre un palier gratuit, des limites généreuses en préversion ou un endpoint sans marque qui ne coûte rien, ce calcul est payé — par lui, sur une ligne budgétaire qui a un nom. C’est du coût d’acquisition client, et il se comporte comme tout autre CAC. C’est la lecture la plus utile pour une équipe finance, car le CAC a une dynamique prévisible : il est dépensé pour gagner une cohorte, il a une période de retour, et il s’arrête quand la cohorte est gagnée. Ce qu’achète une offre gratuite L’évaluation sans passer par les achats. Des données sur des charges réelles , qui valent plus que le calcul. Et un point d’ancrage tarifaire : une capacité connue à zéro rend cher le tarif de tout concurrent. Le signal à lire Les limites de débit se resserrent avant que les prix montent. Surveillez la concurrence, le contexte et les modèles encore inclus : tout bouge avant la publication d’un nouveau tarif. Comment s’en servir Ne faites jamais entrer une offre gratuite dans vos unit economics. Une marge qui dépend d’une inférence gratuite n’est pas une marge, c’est une subvention à échéance subie. Valorisez l’usage gratuit à un tarif fantôme dans la télémétrie et portez-le dans la prévision. Mesurez le coût de sortie tant qu’il est faible. Gardez un second fournisseur câblé sur au moins une route. À lire aussi Arbitrage entre fournisseurs Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Guide de Tarification GPT-5.6 : Luna, Terra, Sol · FinOps LLM URL: https://finopsllm.com/fr/research/gpt-5-6-pricing-tier-guide Guide de Tarification GPT-5.6 : Luna, Terra, Sol Publié le 19 juillet 2026 OpenAI a lancé GPT-5.6 le 10 juillet avec trois niveaux de tarification distincts : Luna à $1/$6 par 1M tokens, Terra à $2.50/$15 et Sol à $5/$30. Ce n'est pas un simple compromis vitesse/qualité ; chaque niveau est positionné pour une classe différente de charge de travail. La question n'est pas « quel est le meilleur » — c'est « quel est le bon pour cette tâche ? » Ce guide cartographie les tâches aux niveaux, parcourt des exemples de coûts par tâche, et vous montre comment cascader intelligemment quand un niveau moins cher n'est pas assez confiant. Luna ($1/$6) : classification, extraction simple, routage haute volume Terra ($2.50/$15) : raisonnement équilibré, boucles d'agentes, conversations multi-tours Sol ($5/$30) : raisonnement frontalier, génération de code, recherche difficile Les lectures de cache économisent 90% ; les écritures de cache coûtent 1,25× l'entrée — seuil de rentabilité à 5+ accès en 30 min L'API batch ajoute 50% de réduction en plus de la tarification par niveau pour le travail non interactif Mise en garde critique : OpenAI positionne Terra et Sol comme ayant une capacité de raisonnement équivalente, se différenciant principalement par la vitesse et le rendement. Comparez les deux contre votre charge de travail réelle — la prétention de parité ne se maintient pas toujours à votre distribution de données. Voir GPT-5 vs alternatives pour la comparaison avec Claude et DeepSeek. 1. Les Trois Niveaux : Vitesse, Coût et Capacité Niveau Entrée $/1M Sortie $/1M Lecture Cache $/1M Contexte Latence Typique Luna $1.00 $6.00 $0.10 128K 80–200 ms Terra $2.50 $15.00 $0.25 128K 150–400 ms Sol $5.00 $30.00 $0.50 128K 300–800 ms La latence compte : Luna est plus rapide car il est optimisé pour le streaming, la classification en temps réel et le rendement. Sol est plus lent car il effectue plus de raisonnement interne. Pour les charges de travail interactives orientées vers l'utilisateur, Luna est aussi moins cher et plus rapide — mais seulement s'il est assez capable pour votre tâche. C'est la décision clé de routage. 2. Table de Routage par Type de Tâche Ce tableau cartographie les tâches LLM communes au niveau qui minimise le coût par réponse réussie : Type de Tâche Exemple Niveau Recommandé Taux de Succès au Niveau Coût Est./1K Tâches Classification Spam / pas spam ; sentiment (pos/neg/neutre) Luna 95–98% $1.20–$1.50 Extraction structurée Extraire nom, email, téléphone du texte Luna 92–96% $1.80–$2.40 Catégorisation (nombreuses classes) Assigner une de 50+ catégories de produit Luna 88–94% $2.40–$3.20 Résumé Condenser article ou journal de chat Luna 92–97% $1.50–$2.00 Boucles d'agentes (usage d'outils) Multi-tour : recherche, raisonnement, affinage Terra 85–92% $8.00–$12.00 Conversation multi-tour Bots de support client, conseil Terra 88–94% $6.00–$10.00 Génération de code (simple) Requête SQL, snippet Bash, regex Terra 80–90% $10.00–$15.00 Génération de code (complexe) Endpoint complet, machine d'état, compilateur DSL Sol 75–88% $25.00–$40.00 Recherche + synthèse Analyser 10+ papiers, synthétiser consensus Sol 80–90% $30.00–$50.00 Raisonnement difficile (problème nouveau) Vérification de preuve, conception d'algorithme nouveau Sol 70–85% $40.00–$70.00 Insight clé : Le coût par tâche n'est pas juste le coût API — c'est (coût API) / (taux de succès). Une classification Luna avec 95% de succès coûte ~$1.26 par réponse réussie. Si vous routez la même tâche à Sol avec 98% de succès, vous payez ~$5.10 par réponse — mais vous avez résolu 3% de plus de votre charge de travail, ce qui peut ou peut ne pas valoir le coût 4×. 3. Exemples Résolus de Coût Par Tâche Exemple 1 : Classification Spam (Luna) Tâche : Classifier email comme spam (oui/non binaire). Profil de tokens typique : 400 entrée (email) + 50 sortie (classification + confiance) = 450 tokens. Coût Luna : (400 × $1/1M) + (50 × $6/1M) = $0.00043/requête. Si 96% réussissent à la première tentative : $0.00043 / 0.96 = $0.00045 par classification réussie. À 1M emails/mois : $450/mois (plus réduction de cache si vous réutilisez les prompts système). Si routé incorrectement à Sol : (400 × $5 + 50 × $30) / 1M = $0.0025 par requête. Avec 98% de succès : $0.00255/réussie = $2,550/mois (5.7× plus). Exemple 2 : Agent de Support Client (Terra) Tâche : Conversation de support multi-tour avec usage d'outils (recherche de tickets, recherche de politiques, décision d'escalade). Profil de tokens typique par tour : 2,000 entrée (contexte + historique) + 400 sortie (réponse + appels d'outils) = 2,400 tokens. Moyenne 3 tours pour résoudre = 7,200 tokens totaux par ticket. Coût Terra : (2,000 × $2.50/1M) + (400 × $15/1M) = $0.0080/tour ou $0.0240 par ticket. Si 90% sont résolus sans escalade : $0.0240 / 0.90 = $0.0267 par ticket réussi. À 10K tickets/mois : $267/mois. Si vous utilisiez Luna à la place : (2,000 × $1 + 400 × $6) / 1M = $0.0044 par tour = $0.0132/ticket. Mais le succès de la boucle d'agente Luna baisse à 65% (les appels d'outils échouent, le raisonnement est superficiel). Coût par réussie : $0.0132 / 0.65 = $0.0203. Économies nettes : $29/mois, mais 25% des tickets échouent et escaladent, augmentant le coût de support de $400+. Luna ne fonctionne pas ici. Exemple 3 : Génération de Code (Terra vs Sol) Tâche : Générer une fonction Python à partir d'une chaîne de requirement. Profil de tokens typique : 1,500 entrée (spécification + exemples) + 600 sortie (code + explication) = 2,100 tokens. Coût Terra : (1,500 × $2.50 + 600 × $15) / 1M = $0.0134 par requête. Avec 85% de succès au premier passage (code compile + passe les tests basiques) : $0.0158 par fonction qui fonctionne. Coût Sol : (1,500 × $5 + 600 × $30) / 1M = $0.0255 par requête. Avec 90% de succès au premier passage : $0.0283 par fonction qui fonctionne. Économies avec Terra : 44% moins cher par résultat qui fonctionne. Utilisez Sol seulement si la différence de 5% en taux de succès et qualité de code réduit sensiblement le coût de débogage en aval. 4. Modèle de Routage Cascade et Fallback La plupart des équipes FinOps ne devraient pas utiliser un seul niveau pour tout le travail. Au lieu de cela, implémentez un modèle cascade : commencez par le niveau le moins cher, mesurez la confiance, escaladez en confiance basse. Étape Modèle Seuil de Confiance Action si le Seuil n'est Pas Atteint 1 Luna Confiance > 85% Retourner résultat 2 Terra Confiance > 75% Retourner résultat (escaladé) 3 Sol Confiance > 60% Retourner résultat ou échouer explicitement 4 Révision humaine — Escalader à humain Scénario réel : Vous effectuez une classification de documents pour les factures (classifier par fournisseur). Luna retournera des résultats de haute confiance (~94% de succès) et coûtera ~$1.20 par 1K. Pour les 6% des factures ambiguës où Luna retourne une confiance < 85%, escaladez à Terra (~94% de succès pour les cas difficiles), coûtant ~$3.75 par 1K escalades. Si 6% de 10K documents escaladent : 600 × $3.75 = $2.25 extra, total $12 + $2.25 = $14.25/10K. Terra pur coûterait ~$37.50. La cascade économise 62% tout en améliorant la précision sur les cas limites. 5. Économie de Mise en Cache des Invites GPT-5.6 a changé les coûts de mise en cache : les écritures de cache coûtent maintenant 1,25× le taux d'entrée sans cache (pas gratuit), et les lectures de cache coûtent 10% de l'entrée. Scénario Taille du Préfixe Coût d'Écriture Coût de Lecture (par accès) Accès de Seuil de Rentabilité Économies @ 10 accès/mois Contexte de récupération en cache Luna 100K tokens $0.125 $0.010 15 accès -$0.025 (perte) Prompt système en cache Luna + docs 50K tokens $0.063 $0.005 8 accès $0.032 Contexte d'agentes en cache Terra 80K tokens $0.250 $0.020 14 accès $0.030 Contexte de raisonnement en cache Sol 100K tokens $0.625 $0.050 13 accès $0.025 Quand mettre en cache : Si votre invite inclut un préfixe stable (instructions système, documentation, exemples poches) qui est réutilisé plus de 5–10 fois dans une fenêtre de 30 minutes, la mise en cache économise généralement de l'argent. L'API batch (50% de réduction) rivalise maintenant avec la mise en cache en coût — si vous classifiez des documents en lot, la réduction de lot surpasse la surcharge de mise en cache. 6. Comparaison avec Claude Sonnet 5, Gemini 3.1 Pro et DeepSeek V4 Modèle Entrée $/1M Sortie $/1M Vitesse Capacité de Raisonnement Quand Choisir GPT-5.6 Luna $1.00 $6.00 Rapide Suivi d'instructions, routage Classification, extraction, rendement GPT-5.6 Terra $2.50 $15.00 Moyen Raisonnement modéré, usage d'outils Agentes, multi-tour, code moyen GPT-5.6 Sol $5.00 $30.00 Lent Raisonnement frontalier, recherche Code complexe, raisonnement difficile, problèmes nouveaux Claude Sonnet 5 $2.00–$3.00 $10.00–$15.00 Moyen–Rapide Raisonnement fort, tokens de raisonnement long Raisonnement, codage (compétitif avec Sol) Gemini 3.1 Pro $2.00 $12.00 Moyen Multimodal, capacité de recherche Tâches multimodales, compétitif avec Terra DeepSeek V4 Flash $0.14 $0.28 Très Rapide Raisonnement basique, focus entrée en cache Routage haute volume, charges de travail focus cache (7–35× moins cher) Arbitrage de coûts : Pour la classification simple et l'extraction, DeepSeek V4 Flash est 7–20× moins cher que Luna. Comparez-le contre vos données — s'il atteint 90%+ de précision, utilisez-le et conservez la différence. Claude Sonnet 5 est 2× plus cher que Terra mais fournit un raisonnement plus fort par prétention de capacité de modèle ; utilisez-le si votre benchmark Terra montre une qualité insuffisante. Gemini 3.1 Pro se situe entre Luna et Terra — utile si vous avez besoin d'entrée multimodale ou êtes déjà dans l'écosystème Vertex AI. 7. Migration depuis GPT-5/5.5 & Statut de Dépréciation OpenAI continue à offrir GPT-5.5 ($5/$30, identique à Sol) et GPT-5.4 ($2.50/$15, identique à Terra) à côté de GPT-5.6. Il n'y a pas de pression de dépréciation sur les modèles plus anciens — vous pouvez continuer à utiliser GPT-5.5 si votre code le cible. Cependant, GPT-5.6 prétend à la parité de performances (ou mieux) au même niveau, alors migrez à 5.6 pour les nouveaux déploiements. L'interface ChatGPT continue à retirer les modèles plus anciens sur une base roulante (GPT-4o mini, GPT-4 turbo sont maintenant en lecture seule) ; l'accès API est stable. Si vous construisez contre l'API, planifiez des révisions annuelles du statut de dépréciation du modèle mais n'attendez pas d'urgence. Cadre de Mesure des Coûts Étape 1 : Établir la ligne de base par niveau Exécutez une semaine de trafic et enregistrez quel niveau a géré chaque requête. Cela vous donne la distribution de ligne de base et le coût. Étape 2 : Mesurer les scores de confiance et les taux de fallback Pour chaque niveau, enregistrez la confiance retournée. Calculez : quel % des appels Luna ont confiance > 85% ? Quel % escaladent à Terra ? Cela vous dit si votre cascade est équilibrée. Étape 3 : Auditer le succès/l'échec par niveau Comparez la sortie du modèle contre la vérité de base pour une semaine. Quel niveau sous-performe sur vos données ? Ajustez les seuils ou la sélection de niveau en fonction de la précision réelle, pas des prétentions d'OpenAI. Étape 4 : Calculer le coût réel par réponse réussie Coût réel = (coût_niveau) / (taux_succès). Si Luna coûte $1.20 par 1K avec 94% de succès, le coût par réponse qui fonctionne est $1.28. C'est la métrique à optimiser. Liste de Vérification Rapide de Sélection de Niveau Est-ce une tâche de classification, extraction ou routage ? → Luna sauf si la précision est critique. La tâche implique-t-elle l'usage d'outils ou le raisonnement multi-tour ? → Terra. Est-ce un raisonnement nouveau, un code complexe ou une analyse multi-hop ? → Sol (ou comparez Claude Sonnet 5 d'abord). Pouvez-vous implémenter une cascade (Luna → Terra → Sol) ? → Oui, c'est généralement optimal. Y a-t-il un préfixe stable (prompt système, docs) réutilisé 10+ fois/mois ? → Mettez-le en cache, mesurez le ROI au seuil de rentabilité (5–15 accès). Est-ce un lot ou interactif ? → Le travail en lot se qualifie pour la réduction de 50% ; recalculez le ROI avec l'API batch. Avez-vous comparé les alternatives (Claude, DeepSeek, Gemini) ? → Faites-le sur vos données, pas les prétentions de marketing. La sélection de niveau est un problème de classification : appariez les propriétés de charge de travail à l'économie de niveau. L'idéal est le routage cascade — routez à Luna d'abord, mesurez la confiance, escaladez en incertitude. Cela minimise les coûts tout en maintenant la qualité. FinOps LLM peut exécuter un audit de coûts sur votre trafic LLM et vous montrer où le désajustement de niveau laisse de l'argent sur la table. Réservez un audit gratuit . Voir aussi : Combien Coûte GPT-5 ? pour le panorama complet de tarification de GPT et Coûts Cachés du LLM pour l'infrastructure et les frais généraux de fallback au-delà des frais par token. Retour à la recherche FAQ Quel niveau de GPT-5.6 dois-je utiliser pour les tâches de classification ? Luna ($1/$6 par 1M) est le bon choix pour la classification et l'extraction simple. Avec 600 tokens d'entrée + 100 tokens de sortie, Luna coûte $0.00066/requête contre $0.00175/requête pour Terra. Si la précision n'est pas votre goulot, Luna fournit des résultats équivalents avec 62% d'économies. Quand Terra ($2.50/$15) surpasse-t-il Sol ($5/$30) en coût ? Toujours. Terra est positionné comme le sweet spot performance/coût : mêmes prétentions de capacité que Sol mais exactement à moitié prix. Utilisez Terra pour les boucles d'agentes, les conversations multi-tours et les tâches de raisonnement modéré. Utilisez Sol seulement quand la profondeur de raisonnement de Terra est manifestement insuffisante. Quel est l'impact en coûts de la mise en cache des invites sur GPT-5.6 ? Les écritures de cache coûtent 1,25× l'entrée (par exemple, $1,25 par million pour Luna). Les lectures de cache coûtent 10% de l'entrée ($0,10 par million pour Luna). Si un préfixe de 100K tokens est réutilisé 5+ fois en 30 minutes, la mise en cache économise 60%+ par rapport aux appels non mis en cache répétés. Comment GPT-5.6 se compare-t-il à Claude Sonnet 5 et DeepSeek V4 ? Luna ($1/$6) est 50-60% moins cher que Claude Sonnet ($2/$10 intro, $3/$15 1er sept) et DeepSeek V4 Flash ($0,14/$0,28) est 7-20× moins cher que Luna. Pour les charges de travail de raisonnement, Sol ($5/$30) et Claude Sonnet échangent les performances par dollar différemment ; comparez votre cas d'usage. --- # Claude Max vs Alibaba Token Pro: coût agentic · FinOps LLM URL: https://finopsllm.com/fr/research/heavy-agentic-coding-cost-claude-vs-qwen Claude Max vs Alibaba Token Pro: le coût réel du codage agentique Mis à jour September 19, 2026 · première publication August 6, 2026 Réponse rapide: Lorsque le développement assisté par IA passe de simples complétions à des swarms multi-agents (où un coordinateur lance 4 à 8 sous-agents spécialisés pour le test, le refactoring et l'audit de... Lorsque le développement assisté par IA passe de simples complétions à des swarms multi-agents (où un coordinateur lance 4 à 8 sous-agents spécialisés pour le test, le refactoring et l'audit de sécurité), la consommation de tokens explose. Comparer les offres au tarif facial par million de tokens mène à de faux arbitrages. 1. Deux logiques de facturation incomparables Alibaba Token Pro (70 $/mois) fournit un quota explicite de 12 000 crédits par fenêtre de 5 heures et 40 000 crédits par 7 jours sur Qwen 3.8-Max, avec une réduction de 80 % en heures creuses (multiplicateur 0,2×). Claude Max 20x (200 $/mois) repose sur une allocation de calcul dynamique pour Opus 5 sans quota fixe publié, garantissant une forte vélocité en pic d'activité. 2. Équation de rentabilité par tâche validée Sur le seul abonnement (70 $ vs 200 $), Qwen 3.8-Max n'a besoin d'atteindre que 35 % de la productivité en tâches acceptées d'Opus 5 pour être plus économique par fonctionnalité livrée. Cependant, avec un coût développeur moyen de 50 $/heure, il suffit qu'Opus 5 évite 2,6 heures par mois de débogage et de reprises manuelles pour amortir intégralement les 130 $ d'écart d'abonnement. À lire aussi Audit des coûts: Alibaba vs Claude Max Prix des fournisseurs IA non comparables Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Le filigrane caché dans chaque réponse de Claude · FinOps LLM URL: https://finopsllm.com/fr/research/how-ai-watermarking-works Comment fonctionne le filigrane IA Mis à jour September 1, 2026 · première publication September 1, 2026 Réponse rapide: Un signal invisible se trouve dans le texte produit par les modèles Claude compatibles. Ni vous ni vos utilisateurs ne pouvez le voir; il ne change ni le sens ni la qualité, et n’apparaît pas sur la... Un signal invisible se trouve dans le texte produit par les modèles Claude compatibles. Ni vous ni vos utilisateurs ne pouvez le voir; il ne change ni le sens ni la qualité, et n’apparaît pas sur la facture. Il est pourtant là, et il mérite dix minutes d’attention, car ce qui le détruit est précisément ce que votre chaîne de traitement fait chaque jour. Le mécanisme, côté texte Un modèle de langage ne choisit pas le token le plus probable : il échantillonne une distribution à l’aide d’un aléa. La technique de filigrane — suivant l’approche SynthID-Text — biaise cet aléa. Certains tokens deviennent très légèrement plus probables, selon un motif connu du seul détecteur. Chaque mot pris isolément reste anodin : une alternative plausible existait toujours. Sur plusieurs centaines de tokens, le motif s’accumule en un signal statistique mesurable par un détecteur et imperceptible pour un lecteur. Deux conséquences : c’est statistique et non un tampon, et cela exige de la longueur. Une sortie de la taille d’un tweet porte bien moins de signal qu’une page entière. Les images fonctionnent à l’inverse Les fichiers .svg , .png et .jpg générés portent des métadonnées C2PA : un manifeste signé cryptographiquement. Ce n’est ni statistique ni caché, mais un bloc de données vérifiable exactement. Le compromis est celui qu’on attend : des métadonnées signées donnent une certitude et s’effacent en une commande; un filigrane statistique ne s’efface pas proprement mais se dégrade à l’édition, à la reformulation et à la traduction. Aucun n’est un verrou; les deux sont des preuves. Ce que cela implique pour vos systèmes Les sorties courtes portent un signal faible. Un post-traitement lourd — reformulation, résumé, traduction, passage par un second modèle — érode le signal. Et votre chaîne d’images peut détruire les métadonnées C2PA par accident : c’est la façon la plus courante de perdre la provenance en production. À lire aussi Ce que coûte vraiment le filigrane IA Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Votre CDN efface votre filigrane IA · FinOps LLM URL: https://finopsllm.com/fr/research/how-ai-watermarks-get-destroyed Comment les filigranes IA disparaissent Mis à jour September 1, 2026 · première publication September 1, 2026 Réponse rapide: La question intéressante à propos du filigrane IA n’est pas comment le contourner, mais pourquoi tant de contenu arrive en bout de chaîne sans provenance alors que personne n’a voulu en retirer. La... La question intéressante à propos du filigrane IA n’est pas comment le contourner, mais pourquoi tant de contenu arrive en bout de chaîne sans provenance alors que personne n’a voulu en retirer. La provenance est rarement attaquée : elle est optimisée jusqu’à disparaître, par des systèmes qui font exactement ce pour quoi ils ont été conçus. Deux modes de défaillance indépendants, parce qu’il y a deux mécanismes. La provenance des images meurt par suppression; celle du texte, par dilution. Les deux sont silencieuses. Suppression : les métadonnées que votre chaîne jette Les métadonnées C2PA vivent dans le fichier. Générateurs de vignettes, transformations CDN, conversion vers WebP ou AVIF, envois vers des plateformes tierces et captures d’écran les écartent sauf configuration explicite. Le motif est constant : tout ce qui ré-encode l’image produit un nouveau fichier, et un nouveau fichier n’a pas de manifeste signé. Une seule transformation automatique entre génération et livraison suffit. Dilution : les étapes de texte qui érodent le signal Le filigrane textuel est statistique : il ne disparaît pas d’un coup, il faiblit. La traduction régénère chaque token dans une autre langue. La reformulation et les passes « réécris dans notre ton » dégradent. Le résumé jette la majorité des tokens porteurs. Un passage par un second modèle rend le texte attribuable, au mieux, au dernier. Et une sortie de deux phrases n’a jamais porté grand-chose. Or un produit bien construit fait plusieurs de ces choses. Générer avec un modèle, réécrire le ton avec un autre, traduire en cinq langues et tronquer en carte-résumé n’a rien de fautif — et produit pourtant un contenu qu’aucun détecteur n’attribuera avec confiance. La version économique Générez aujourd’hui une image et un texte long via votre vrai chemin de production, et vérifiez ce qui survit à l’arrivée. C’est une après-midi, et cela désigne l’étape exacte qui casse la chaîne avant qu’un audit ne le fasse. À lire aussi Comment fonctionne le filigrane IA Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Combien Coûte GPT-5 ? Guide Complet des Tarifs 2026 · FinOps LLM URL: https://finopsllm.com/fr/research/how-much-does-gpt5-cost Combien Coûte GPT-5 ? Mis à jour le 15 juillet 2026 · publié pour la première fois le 4 juillet 2026 GPT-5 est le modèle de raisonnement phare d'OpenAI, lancé en 2026. Il offre des performances substantiellement supérieures sur les tâches complexes de raisonnement, programmation et multimodales par rapport à GPT-4o - mais à un prix premium. Ce guide décompose chaque dimension de coût : tarifs API, niveaux d'abonnement ChatGPT, comparaison avec GPT-4o et où les alternatives moins coûteuses comme MiMO peuvent être le choix le plus judicieux. Tarifs API de GPT-5 OpenAI facture GPT-5 par million de tokens, avec des tarifs séparés pour l'entrée, la sortie et l'entrée en cache. Les lectures de cache sont significativement moins chères car le modèle réutilise un préfixe précédemment calculé. Niveau Entrée $/1M Sortie $/1M Lecture Cache $/1M Fenêtre de Contexte GPT-5.6-Sol (max) $5.00 $30.00 $0.50 128K tokens GPT-5.6-Terra (mid) $2.50 $15.00 $0.25 128K tokens GPT-5.6-Luna (budget) $1.00 $6.00 $0.10 128K tokens GPT-5.5 (flagship) $5.00 $30.00 $0.50 128K tokens GPT-5.4 (mid-tier) $2.50 $15.00 $0.25 128K tokens La nouvelle génération de juillet 2026 d'OpenAI (GPT-5.6) introduit trois niveaux distincts : Sol pour le raisonnement de pointe, Terra pour les performances équilibrées, et Luna pour les cas d'usage sensibles aux coûts. En comparaison, les modèles plus anciens GPT-5.5 et 5.4 restent disponibles. GPT-5.6 et 5.5 à $5/$30 sont nettement plus puissants que GPT-4o ($2.50/$10), mais le coût effectif dépend de la profondeur du raisonnement et de l'efficacité du cache. Coûts d'abonnement ChatGPT Si vous utilisez GPT-5 via l'interface ChatGPT au lieu de l'API, la tarification est basée sur l'abonnement : Plan Prix Mensuel Accès GPT-5 Limites Clés Free $0 GPT-5 mini uniquement Messages limités/jour Plus $20/mois GPT-5 avec limites ~80 messages GPT-5/3hrs Pro $200/mois GPT-5 illimité Pas de limites de taux, voix, recherche approfondie Team $25/utilisateur/mois GPT-5 avec limites élevées Outils admin, SSO, limites supérieures Enterprise Personnalisé GPT-5 illimité SLA, support dédié, gouvernance des données Le plan Pro à $200/mois n'est rentable que si vous êtes un utilisateur intensif quotidien. Pour la plupart des développeurs et équipes, l'API avec une gestion prudente des tokens est moins chère qu'un abonnement Pro. GPT-5 vs GPT-4o : quand vaut-il la peine de passer à la version supérieure ? L'écart de prix est réel, donc la question est de savoir si l'avantage de qualité de GPT-5 se traduit par des économies elsewhere : Utilisez GPT-5 quand : la tâche nécessite un raisonnement multi-étapes, une génération de code complexe, une analyse de documents longs ou des flux de travail agentiques où un seul passage de haute qualité économise plusieurs cycles de nouvelle tentative. Utilisez GPT-4o quand : la tâche est directe - classification, extraction, résumés de textes courts, chat simple ou traitement par lots de haut volume où le débit importe plus que l'intelligence par requête. Utilisez GPT-5 mini ou nano quand : vous avez besoin d'un suivi des instructions au niveau de GPT-5 mais à moindre coût, et pouvez accepter une profondeur de raisonnement légèrement réduite. Une règle pratique : si vos prompts GPT-4o incluent des instructions de chaîne de pensée ou des boucles de correction multi-tour, GPT-5 peut être réellement moins cher car il effectue ce raisonnement de manière native en un seul appel. Comment réduire les coûts de GPT-5 Plusieurs stratégies peuvent réduire votre facture de GPT-5 de 30–70% sans sacrifier la qualité de sortie : Exploitez la mise en cache des prompts. Le taux de lecture du cache GPT-5 ($0.50/1M) est 75% moins cher que le taux d'entrée complet. Structurez vos prompts avec un préfixe stable (instructions système, contexte) et un suffixe variable (requête utilisateur) pour maximiser les accès au cache. Utilisez GPT-5 mini/nano pour l'acheminement. Exécutez d'abord un modèle léger pour classer l'intention, puis passez à GPT-5 complet uniquement pour les requêtes complexes. C'est le motif d' acheminement de modèles . API par lots pour le travail non interactif. L'API par lots d'OpenAI offre des réductions de 50% sur les charges de travail asynchrones - idéale pour l'évaluation, l'enrichissement et la génération de rapports. Dimensionnez correctement les fenêtres de contexte. N'envoyez pas 100K tokens de contexte quand 5K suffisent. Chaque token d'entrée inutile coûte 4× plus cher sur GPT-5 que sur GPT-4o. Envisagez des alternatives. Pour de nombreuses tâches de programmation et de raisonnement, des modèles comme MiMO , DeepSeek R1 ou Claude Sonnet offrent une qualité comparable à une fraction du coût. Utilisez l' arbitrage des fournisseurs pour comparer. Coûts cachés au-delà du prix affiché Le taux par token n'est que partie du tableau. Budgétisez ces facteurs supplémentaires : Tokens de raisonnement. GPT-5 utilise des tokens de raisonnement internes pour les tâches complexes. Ils sont facturés au taux de sortie ($30/1M) et peuvent multiplier votre volume de sortie effectif par 2–5× sur les problèmes difficiles. Coûts de nouvelle tentative. Si vos prompts sont ambigus ou votre parsing est fragile, les tentatives échouées consomment toujours des tokens. Une ingénierie de prompts robuste se paie d'elle-même. Dépenses d'évaluation. Les tests et les benchmarks pendant le développement peuvent facilement dépasser les dépenses de production s'ils ne sont pas suivis séparément. Voir l' allocation des coûts d'évaluation . Conclusion GPT-5 est cher mais pas uniformément. À $5/$30 par million de tokens, un appel API typique avec 1 000 tokens d'entrée et 500 tokens de sortie coûte environ $0.025. Pour les applications de haut volume, la facture s'accumule rapidement - mais la mise en cache intelligente, l'acheminement et le traitement par lots peuvent réduire les coûts de moitié ou plus. Suivez chaque requête, attribuez les dépenses aux fonctionnalités et comparez les alternatives régulièrement. Connexe Comment les fournisseurs de LLM facturent-ils ? - les modèles de tarification derrière les chiffres. Acheminement de modèles - envoyer la bonne requête au bon modèle. Arbitrage des fournisseurs - trouver le modèle le moins cher qui répond à votre seuil de qualité. Mise en cache des prompts expliquée - comment obtenir des accès au cache réels. Voulez-vous que ceci soit appliqué à vos propres dépenses de LLM ? FinOps LLM lance un audit gratuit de vos coûts IA et montre où se trouvent les économies. Réserver un audit gratuit → Retour à la recherche --- # Comment auditer votre dépense LLM en 30 minutes · FinOps LLM URL: https://finopsllm.com/fr/research/how-to-audit-llm-spend Comment auditer votre dépense LLM en 30 minutes La plupart des équipes ne savent pas comment se décompose leur budget LLM. Les coûts sont masqués derrière les tableaux de bord des fournisseurs qui affichent les totaux mais pas l'attribution, les types de tokens facturés à des tarifs différents, et les modèles d'utilisation qui changent d'une semaine à l'autre. Ce guide vous propose un audit structuré que vous pouvez exécuter en une demi-heure avec les outils que vous avez déjà. Étape 1 - Collectez les données de facturation des fournisseurs Exportez les 30 derniers jours d'utilisation de chaque fournisseur LLM que vous utilisez. Pour OpenAI, utilisez l'API d'utilisation ou téléchargez le CSV depuis le tableau de bord. Pour Anthropic, extrayez les données de l'API de facturation. Pour Google, exportez depuis la console Cloud Billing. Pour les modèles auto-hébergés, extrayez les journaux de requêtes de votre serveur d'inférence. Stockez tout dans un dossier. Vous avez besoin de données brutes, pas de résumés. Étape 2 - Normalisez les décomptes de tokens entre les fournisseurs Chaque fournisseur compte les tokens différemment. OpenAI et Anthropic utilisent leurs propres tokeniseurs ; Google utilise SentencePiece. Pour comparer, convertissez tous les décomptes en une unité commune. L'approche la plus simple : utilisez le prix par token publié de chaque fournisseur pour calculer le coût par requête, puis comparez les coûts directement plutôt que les décomptes de tokens bruts. Cela évite complètement les incompatibilités de tokeniseurs. Étape 3 - Divisez par tokens d'entrée, sortie, cache et raisonnement Les fournisseurs facturent des tarifs différents pour différents types de tokens. Les tokens d'entrée en cache coûtent généralement 50 % moins cher sur OpenAI et Anthropic. Les tokens de raisonnement (sur les modèles o-series et similaires) peuvent coûter 2 à 4 fois les tokens de sortie standard. Divisez votre dépense en quatre catégories : entrée, sortie, entrée en cache et raisonnement. Si votre fournisseur n'expose pas cette division, estimez-la à partir du type de modèle et du modèle de requête. Étape 4 - Attribuez aux équipes et fonctionnalités Mappez chaque clé API ou projet à l'équipe ou à la fonctionnalité qui le possède. Si vous n'avez pas de séparation au niveau des clés, utilisez les métadonnées de requête - en-têtes, étiquettes ou le paramètre user que la plupart des fournisseurs supportent. L'objectif est un tableau : quelle équipe dépense combien pour quelle fonctionnalité. Sans cela, vous ne pouvez responsabiliser personne pour le coût. Étape 5 - Identifiez les 3 principaux moteurs de coût Triez par dépense totale décroissante. Dans la plupart des organisations, 80 % du coût LLM provient de 3 à 5 modèles d'utilisation. Les moteurs courants : un chatbot avec de longues fenêtres de contexte, une fonctionnalité de génération de code qui utilise des modèles coûteux pour toutes les requêtes, ou un travail d'enrichissement en arrière-plan qui s'exécute sur chaque document sans filtrage. Nommez-les. C'est là que vous concentrez l'effort d'optimisation. Étape 6 - Calculez le coût par tâche pour les flux clés Choisissez vos 3 flux principaux. Pour chacun, divisez la dépense totale par le nombre de tâches complétées. Cela vous donne un numéro d'économie unitaire que vous pouvez suivre au fil du temps. Un flux de support client qui coûte 0,12 $ par ticket est gérable. Un qui coûte 1,40 $ par ticket a besoin d'attention. Le nombre absolu importe moins que la tendance et la comparaison entre les flux. Étape 7 - Configurez les alertes pour les anomalies Configurez les alertes à deux niveaux : dépense quotidienne totale (détecte les travaux incontrôlables) et dépense par flux (détecte la dérive). La plupart des fournisseurs supportent les alertes de facturation de manière native. Pour les alertes multi-fournisseurs, canalisez vos données d'utilisation dans un tableau de bord ou utilisez un outil comme MiMO qui agrège entre les fournisseurs. Une règle simple : alerte si un jour quelconque dépasse 150 % de la moyenne mobile sur 7 jours. Liste de contrôle d'audit rapide Étape Outil nécessaire Temps estimé Résultat 1. Collectez les données de facturation Tableaux de bord ou API des fournisseurs 5 min CSV/JSON brut par fournisseur 2. Normalisez les tokens Feuille de calcul ou script 5 min Tableau du coût par requête 3. Divisez les types de tokens API des fournisseurs avec ventilation des tokens 5 min Division entrée/sortie/cache/raisonnement 4. Attribuez aux équipes Mappage des clés API ou métadonnées 5 min Matrice des coûts équipe-fonctionnalité 5. Identifiez les principaux moteurs Tri/feuille de calcul 3 min Liste classée des modèles de coût 6. Coût par tâche Nombre de tâches à partir des journaux d'application 5 min Économie unitaire par flux 7. Configurez les alertes Alertes de facturation + tableau de bord 2 min Détection d'anomalies active Que faire ensuite Cet audit vous donne un instantané. La vraie valeur vient de l'exécuter régulièrement - hebdomadaire pour les équipes à forte dépense, mensuel pour tous les autres. Automatisez la collecte de données et faites de la métrique de coût par tâche une métrique de produit de première classe. Si vous voulez de l'aide pour construire cela dans un processus continu, MiMO fournit des tableaux de bord multi-fournisseurs et une attribution automatisée prêts à l'emploi. Connexes Attribution des coûts LLM - approfondissement des modèles d'attribution. Détection des anomalies de coûts LLM - stratégies d'alertes automatisées. Comment budgéter la dépense en IA - passer de l'audit au budget. Voulez-vous que ceci soit appliqué à votre propre dépense LLM ? FinOps LLM exécute un audit gratuit de vos coûts d'IA et montre où se trouvent les économies. Réservez un audit gratuit → Retour à la recherche --- # Suivi des Prix des API LLM · FinOps LLM URL: https://finopsllm.com/fr/research/llm-api-pricing-tracker Suivi des Prix des API LLM Mise à jour 2 septembre 2026 · publié pour la première fois le 4 juillet 2026 Suivi des prix par jeton auprès de tous les grands fournisseurs LLM. Entrée, sortie, lecture/écriture de cache, fenêtres de contexte et remises par lot dans une seule table normalisée. Mis à jour mensuellement avec des données vérifiables des fournisseurs. 12+ Fournisseurs suivi 25+ Modèles listés 6 Colonnes de prix Sep 2026 Dernière mise à jour Tous les prix en USD par 1 million de jetons Les valeurs estimées sont affichées en gris Les prix du cache reflètent le cache des prompts où disponible Méthodologie Collecte Les données tarifaires sont collectées auprès des pages de tarification officielles et de la documentation API des fournisseurs. Normalisation Tous les prix sont normalisés en USD par 1 million de jetons pour une comparaison directe. Tarification du cache Les colonnes Lecture/Écriture du cache affichent les remises du cache des prompts lorsqu'elles sont disponibles auprès des fournisseurs. Politique d'affichage Les valeurs officielles et estimées sont clairement séparées. Les estimations sont marquées en gris. Historique des Mises à Jour 4 juil 2026 Suivi des Prix des API LLM lancé Publication de la comparaison des prix par jeton auprès de plus de 12 grands fournisseurs LLM en tant qu'article de recherche FinOps LLM. Tableau des Prix par Jeton Fournisseur ↕ Modèle ↕ Entrée $/1M ↕ Sortie $/1M ↕ Lecture Cache $/1M ↕ Écriture Cache $/1M ↕ Fenêtre Contexte ↕ Remise par Lot OpenAI GPT-5.6-Sol $4.00 $20.00 $0.40 $5.00 1.05M 50% OpenAI GPT-5.6-Terra $2.00 $12.00 $0.20 $2.50 1.05M 50% OpenAI GPT-5.6-Luna $0.20 $1.20 $0.02 $0.25 1.05M 50% Anthropic Claude Fable 5.1 $10.00 $50.00 $0.25 $12.50 1M 50% Anthropic Claude Fable 5 $10.00 $50.00 $1.00 $12.50 1M 50% Anthropic Claude Opus 5 $5.00 $25.00 $0.50 $6.25 1M 50% Anthropic Claude Sonnet 5 * $2.00 $10.00 $0.20 $2.50 1M 50% Anthropic Claude Sonnet 4.6 $3.00 $15.00 $0.30 $3.75 1M 50% Anthropic Claude Haiku 4.5 $1.00 $5.00 $0.10 $1.25 200K 50% Google Gemini 3.5 Flash $1.50 $9.00 $0.15 $1.88 1M 50% Google Gemini 3.1 Pro Preview $2.00 $12.00 $0.20 $2.50 1M 50% Google Gemini 2.5 Pro $1.25 $5.00 $0.31 $4.50 1M 50% Google Gemini 2.5 Flash $0.15 $0.60 $0.04 $0.15 1M 50% xAI Grok 4.5 $2.00 $6.00 $0.50 $1.50 1M 50% xAI Grok 4.3 $1.25 $2.50 - - 1M 50% Meta Llama 4 Maverick (DeepInfra) $0.20 $0.80 - - 1M - Meta Llama 4 Scout (Groq) $0.11 $0.34 - - 5M - Meta Llama 3.3 70B (Groq) $0.59 $0.79 - - 8M - Mistral Mistral Large 2/3 $2.00 $6.00 - - 128K - Mistral Mistral Medium 3.5 $1.50 $7.50 - - 128K - Mistral Mistral Small 3 $0.10 $0.30 - - 128K - Mistral Codestral $0.30 $0.90 - - 128K - DeepSeek DeepSeek V4 Flash $0.14 $0.28 $0.0028 - 128K - DeepSeek DeepSeek V4 Pro $0.435 $0.87 $0.0036 - 128K - Alibaba Qwen Qwen 3.7-Max $2.50 $7.50 - - 131K - Moonshot Kimi Kimi K2.6 $0.95 $4.00 $0.16 - 200K - Xiaomi MiMO S'inscrire - tous deux obtiennent 2 $ ↗ MiMo-V2-Pro $0.50 $2.00 - - 128K - Xiaomi MiMO S'inscrire - tous deux obtiennent 2 $ ↗ MiMo-V2-Omni $0.40 $1.60 - - 128K - Zhipu AI GLM-5 $1.00 $4.00 - - 128K - Zhipu AI GLM-5-Turbo $0.30 $1.20 - - 128K - MiniMax M2.7 $0.40 $1.60 - - 128K - StepFun step-3.5-flash $0.30 $1.20 - - 128K - * Claude Sonnet 5 est à 2 $/10 $ par million de jetons de façon permanente : la hausse à 3 $/15 $ prévue au 1er septembre 2026 a été annulée. Les montants d'écriture en cache correspondent au TTL de 5 minutes ; le TTL d'une heure coûte 2× le tarif d'entrée de base. Claude Opus 4.8, 4.7 et 4.6 partagent la tarification de Claude Opus 5. Claude 4.7 et versions ultérieures utilisent un tokeniseur qui produit environ 30 % de jetons en plus pour le même texte : comparez le coût par tâche, pas par jeton. Les valeurs non explicitement fournies par les fournisseurs sont affichées en gris . Les prix de Meta Llama reflètent les tarifs des API hébergées (Fireworks, Together, etc.), et non le coût d'auto-hébergement. L'économie de l'auto-hébergement est couverte dans notre Comparaison des Coûts Open-Source vs Propriétaire . Les fenêtres de contexte sont les maximums supportées ; la disponibilité réelle peut varier selon le niveau. La tarification du cache de lecture/écriture reflète le cache de prompts spécifique au fournisseur où il est disponible. « - » signifie que le fournisseur n'offre pas de cache ou que le prix n'est pas publié. La Remise par Lot affiche les économies approximatives lors de l'utilisation des API par lot/asynchrones où disponibles. Certains liens peuvent inclure des codes de parrainage. Les prix peuvent changer fréquemment. Vérifiez toujours les informations les plus récentes sur les pages officielles des fournisseurs. Guide Pratique Comment utiliser ces données tarifaires pour la planification des coûts 1) Calculez d'abord votre volume de jetons Avant de comparer les prix, estimez vos volumes mensuels de jetons d'entrée et de sortie. Les jetons de sortie sont généralement 3 à 5 fois plus chers que ceux d'entrée, donc réduire la longueur de sortie a le plus grand impact sur le coût. 2) Tenez compte des économies de cache Si votre charge de travail a des prompts système ou du contexte répétés (RAG, conversations multi-tours), le cache de prompts peut réduire les coûts d'entrée de 50 à 90 %. Consultez la colonne Lecture du Cache pour les remises applicables. 3) Utilisez les API par lot pour le travail non urgent La plupart des grands fournisseurs offrent des remises de 50 % sur les appels d'API par lot/asynchrones. Si votre charge de travail tolère la latence (évaluations, traitement des données, génération de contenu), la tarification par lot réduit les coûts de moitié. 4) Comparez le coût total, pas seulement le prix par jeton Un modèle bon marché qui nécessite 3 fois plus de jetons pour égaler la qualité peut coûter plus cher au total. Tenez compte de la qualité du modèle et des performances spécifiques à la tâche parallèlement à la tarification brute. Vous voulez que cela soit appliqué à vos propres dépenses en LLM ? FinOps LLM effectue un audit gratuit de vos coûts d'IA et vous montre où se trouvent les économies. Réservez un audit gratuit → Retour à la recherche --- # Votre facture LLM a un risque de change · FinOps LLM URL: https://finopsllm.com/fr/research/llm-bill-fx-exposure Exposition au change dans la dépense LLM Mis à jour September 1, 2026 · première publication September 1, 2026 Réponse rapide: Presque tous les modèles de pointe sont tarifés en dollars. Si votre budget n’est pas en dollars, une partie de votre coût LLM est une position de change que vous n’avez jamais choisi de prendre.Un... Presque tous les modèles de pointe sont tarifés en dollars. Si votre budget n’est pas en dollars, une partie de votre coût LLM est une position de change que vous n’avez jamais choisi de prendre. Un mouvement de 6 % sur EUR/USD, c’est 6 % de coût en plus sans variation de volume de tokens ni de modèle, et sans rien dans le tableau de bord d’usage pour l’expliquer. La finance voit l’écart ; l’ingénierie, qui regarde des tokens, voit un mois plat et ne peut pas aider. Pourquoi cela se cache si bien Trois couches de conversion séparent l’appel d’API du grand livre : le prix du fournisseur en USD, la conversion de la carte ou de la facture avec son spread, et le taux de comptabilisation de votre ERP. Arrivée au rapport d’écart, la part change et la part usage ne font qu’un chiffre. Acheter via une place de marché en devise locale ne supprime pas l’exposition : cela déplace la conversion en amont et y ajoute une marge. Séparez les deux écarts Enregistrez le coût de chaque requête en USD au tarif public comme chiffre primaire dans la télémétrie, puis convertissez une seule fois, à un taux annoncé, au moment du reporting. L’écart mensuel se scinde alors proprement. Faut-il se couvrir? Rarement, et seulement à l’échelle. Pour la plupart, la bonne réponse est la visibilité, pas la couverture. À lire aussi Pont d’écart de dépense IA Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Chargeback et showback des LLM · FinOps LLM URL: https://finopsllm.com/fr/research/llm-chargeback-showback Chargeback et showback des LLM Le showback rapporte les dépenses en LLM aux équipes et produits qui les ont causées. Le chargeback attribue ces dépenses à leurs budgets. La plupart des organisations devraient commencer par le showback car les équipes ont besoin de temps pour faire confiance aux chiffres avant que ces chiffres affectent les décisions budgétaires. Le défi est la précision de l'allocation. Une simple facture de fournisseur ne peut pas vous dire quelle fonctionnalité, tenant ou équipe a produit un token. Vous avez besoin de métadonnées de requête de la passerelle, de l'application ou de la couche d'orchestration. Sans ces métadonnées, le chargeback devient une discussion politique plutôt qu'un système opérationnel. Bons rapports de showback Décomposer les dépenses par domaine de produit et propriétaire d'équipe. Afficher les charges de travail principales et les changements d'un mois à l'autre. Séparer les changements de prix du modèle de la croissance du trafic. Identifier les candidats à l'optimisation appartenant à chaque équipe. Garder visibles les dépenses non allouées. Quand faire du chargeback Le chargeback a du sens une fois que la couverture d'attribution est élevée et que les équipes peuvent influencer les facteurs de coût. Ne chargez pas les équipes pour l'infrastructure partagée non étiquetée, les tables de tarification obsolètes ou les décisions de plateforme centrale qu'elles ne peuvent pas changer. Un modèle solide utilise le showback pour l'éducation, puis le chargeback pour les centres de coûts matures. Il protège également les budgets d'expérimentation afin que les équipes n'évitent pas les fonctionnalités d'IA utiles simplement parce que le trafic initial est difficile à prévoir. Connexes Gouvernance du budget des LLM - budgets et garde-fous. Attribution des coûts des LLM - fondements de l'allocation. Qu'est-ce que FinOps pour LLM? - la discipline opérationnelle complète. Vous voulez que cela s'applique à vos propres dépenses en LLM? FinOps LLM réalise un audit gratuit de vos coûts d'IA et montre où se trouvent les économies. Réservez votre audit gratuit → Retour à la recherche --- # Attribution des coûts des LLM · FinOps LLM URL: https://finopsllm.com/fr/research/llm-cost-attribution Attribution des coûts des LLM L'attribution des coûts des LLM est le pont entre les factures des fournisseurs et les décisions opérationnelles. Les fournisseurs facturent par compte, modèle, classe de token et parfois par région ou fonctionnalité. Les entreprises doivent comprendre les dépenses par équipe, produit, client, workflow et unité de valeur. La couche d'attribution relie ces deux vues sans perdre la réconciliation avec la facture brute. La clé est d'étiqueter les requêtes avant qu'elles n'atteignent le fournisseur ou la passerelle. Les journaux créés après coup sont généralement incomplets. Au minimum, chaque appel LLM en production doit comporter un nom d'endpoint stable, un environnement, le propriétaire de l'équipe, la surface du produit, la classe de charge de travail et un ID de corrélation. Où les contrats le permettent, ajoutez l'ID du tenant ou du client. Pour les workflows d'agent, étiquetez chaque appel d'outil ou étape de modèle séparément. Le compte de requêtes n'est pas l'attribution Allouer les dépenses par le compte de requêtes est presque toujours faux. Une requête de raisonnement en contexte long peut coûter plus que des centaines d'appels de classification courts. L'attribution a besoin de classes de tokens et de tarification des modèles. Il a également besoin de données de nouvelles tentatives et de secours, car une réponse « réussie » peut cacher trois appels en amont échoués. Dimensions recommandées Fournisseur, modèle et version du modèle le cas échéant. Classes de tokens d'entrée, sortie, écriture de cache, lecture de cache et raisonnement. Équipe, produit, fonctionnalité, endpoint et environnement. Classe de charge de travail : chemin utilisateur en temps réel, travail en arrière-plan, évaluation, enrichissement, étape d'agent, workflow de support ou tâche d'analyse. Attribution du client ou du tenant quand les limites de confidentialité et de contrat le permettent. Rapprochement des factures L'attribution doit se réconcilier avec la facture du fournisseur. Attendez de petites différences d'arrondi, de lignes de facture retardées et de remises spécifiques au fournisseur, mais les grands écarts signifient que le pipeline de journaux perd du trafic ou utilise des tables de tarification obsolètes. La vue financière doit montrer à la fois les dépenses allouées et non allouées pour que les problèmes de qualité des données soient visibles. Du showback à l'action Le premier résultat doit être le showback : quelles équipes et surfaces de produit pilotent les dépenses, et quelles charges de travail ont changé depuis le mois dernier. Une fois que les équipes font confiance à ces données, utilisez-les pour classer le travail d'optimisation. L'attribution est précieuse car elle pointe directement vers les propriétaires qui peuvent approuver le routage, le cache ou les changements de prompts. Connexes Attribution des coûts d'OpenAI - modèles d'attribution spécifiques à OpenAI. Chargeback et showback des LLM - déplacer les coûts vers les propriétaires. Qu'est-ce que FinOps pour LLM? - la discipline opérationnelle complète. Vous voulez l'appliquer à vos propres dépenses en LLM? FinOps LLM réalise un audit gratuit de vos coûts d'IA et montre où se trouvent les économies. Réservez votre audit gratuit → Retour à la recherche --- # Calculatrice de coût LLM : dépenses IA mensuelles · FinOps LLM URL: https://finopsllm.com/fr/research/llm-cost-calculator Calculatrice de Coût LLM Mise à jour le 15 juillet 2026 Estimez vos dépenses mensuelles en LLM parmi les modèles populaires. Entrez votre modèle d'utilisation ci-dessous et comparez les coûts côte à côte. Tous les prix sont par million de tokens en juillet 2026. Coûts précalculés par niveau d'utilisation Voici ce que coûte chaque niveau d'utilisation par mois parmi les modèles populaires, basé sur des modèles de requête typiques : Modèle Léger (1K req/mois) Moyen (10K req/mois) Intensif (100K req/mois) GPT-5.6-Sol $8.75 $87.50 $875.00 GPT-5.6-Terra $4.38 $43.75 $437.50 GPT-5.6-Luna $1.75 $17.50 $175.00 Claude Fable 5 $17.50 $175.00 $1,750.00 Claude Opus 4.8 $8.75 $87.50 $875.00 Claude Sonnet 5 $3.50 $35.00 $350.00 Claude Haiku 4.5 $1.75 $17.50 $175.00 Gemini 3.5 Flash $2.63 $26.25 $262.50 Grok 4.5 $4.00 $40.00 $400.00 DeepSeek V4 Pro $0.95 $9.50 $95.00 Kimi K2.6 $1.70 $17.00 $170.00 Léger : 1K requêtes/mois, 500 entrée + 200 tokens de sortie. Moyen : 10K requêtes/mois, 1 000 entrée + 500 tokens de sortie. Intensif : 100K requêtes/mois, 2 000 entrée + 1 000 tokens de sortie. Calculatrice interactive Modèle GPT-5.6-Sol ($5.00 / $30.00) GPT-5.6-Terra ($2.50 / $15.00) GPT-5.6-Luna ($1.00 / $6.00) Claude Fable 5 ($10.00 / $50.00) Claude Opus 4.8 ($5.00 / $25.00) Claude Sonnet 5 ($2.00 / $10.00) Claude Haiku 4.5 ($1.00 / $5.00) Gemini 3.5 Flash ($1.50 / $9.00) Grok 4.5 ($2.00 / $6.00) DeepSeek V4 Pro ($0.435 / $0.87) Kimi K2.6 ($0.95 / $4.00) Requêtes par mois Tokens d'entrée moyens par requête Tokens de sortie moyens par requête Calculer le coût Comment utiliser cette calculatrice Choisissez votre modèle dans la liste déroulante. Les prix reflètent les tarifs API standard en juillet 2026. Entrez votre volume de requêtes - combien d'appels API vous faites par mois. Estimez le nombre de tokens - le nombre moyen de tokens d'entrée et de sortie par requête. Si vous n'êtes pas sûr, commencez par 1 000 entrée / 500 sortie pour le chat, ou 3 000 entrée / 1 000 sortie pour la génération de code. Cliquez sur Calculer pour voir votre coût mensuel estimé décomposé par entrée et sortie. Comment réduire votre estimation Utilisez la mise en cache des prompts. Si vos prompts ont un préfixe stable, les lectures en cache peuvent réduire les coûts d'entrée de 50–90 %. Consultez mise en cache des prompts expliquée . Changez de modèle selon la tâche. Routez les requêtes simples vers des modèles moins chers et réservez les plus chers pour les tâches complexes. C'est l' acheminement des modèles . Utilisez les APIs par lots. Les charges de travail non urgentes peuvent utiliser la tarification par lots avec 50 % de réduction. Essayez des fournisseurs moins chers. MiMO et DeepSeek offrent des tarifs nettement plus bas pour une qualité comparable sur de nombreuses tâches. Articles connexes Combien coûte GPT-5 ? - ventilation détaillée de la tarification GPT-5. Comment les fournisseurs de LLM facturent-ils ? - comprendre la facturation basée sur les tokens. Le moyen le moins cher d'exécuter la génération de code avec l'IA - comparaison des coûts pour les outils de codage. Arbitrage des fournisseurs - trouver le modèle le moins cher qui répond à votre seuil de qualité. Vous voulez que cela s'applique à vos propres dépenses en LLM ? FinOps LLM exécute un audit gratuit de vos coûts d'IA et montre où se trouvent les économies. Réserver un audit gratuit → Retour à la recherche --- # Runbook de production pour un pic de coûts LLM · FinOps LLM URL: https://finopsllm.com/fr/research/llm-cost-spike-runbook Runbook de production pour un pic de coûts LLM Mis à jour August 27, 2026 · première publication August 27, 2026 Réponse rapide: Lors d’un pic, préservez les preuves, confirmez la facturation et séparez volume, tarif, mix et efficacité avant de changer de modèle.Les 15 premières minutesConservez facture, trafic, mix, types de... Lors d’un pic, préservez les preuves, confirmez la facturation et séparez volume, tarif, mix et efficacité avant de changer de modèle. Les 15 premières minutes Conservez facture, trafic, mix, types de tokens, reprises et déploiements. Comparez facture et télémétrie de passerelle. Contenir Appliquez le contrôle le plus étroit: suspendre un flux, plafonner un agent, router en batch ou désactiver une fonction récente. Protégez le trafic critique et définissez propriétaire, expiration et retour arrière. Expliquer et clore Vérifiez volume, mix, contexte, outils, erreurs et tarifs. Comparez coût par tâche réussie à la base, puis documentez impact et action permanente. À lire aussi Suivi des coûts LLM Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Tendances des coûts LLM 2025–2026 · FinOps LLM URL: https://finopsllm.com/fr/research/llm-cost-trends-2025-2026 Tendances des coûts LLM 2025–2026 Mise à jour 15 juillet 2026 · publié pour la première fois le 4 juillet 2026 Le marché des LLM se meut dans deux directions à la fois. Les prix des tokens d'entrée et de sortie pour les modèles de classe GPT-4 ont chuté de 80–90% depuis le début de 2024. En même temps, les modèles de raisonnement (o1, o3, DeepSeek-R1, Claude Opus 4) sont 5–30x plus chers par tâche que leurs équivalents sans raisonnement. L'effet net : les équipes qui adoptent des modèles de raisonnement voient leurs factures augmenter même si les prix unitaires baissent. Cet article suit les événements clés de prix et de qualité de 2025 à mi-2026, explique les forces qui conduisent les coûts et prévoit ce qui faut attendre au second semestre 2026. Tendance clé 1 : Les modèles de classe GPT-4 ont baissé de 90% en 18 mois En mars 2024, GPT-4-turbo coûtait 10 dollars par million de tokens d'entrée et 30 dollars par million de tokens de sortie. À mi-2026, GPT-4.1 coûte 2 dollars par million d'entrée et 8 dollars par million de sortie : une baisse de 75–80%. Claude a suivi une trajectoire similaire : Claude 3 Opus à 15/75 dollars a baissé à Claude Sonnet 4 à 3/15 dollars. Les modèles à poids ouvert de Mistral, Llama et DeepSeek ont poussé les prix encore plus bas, certains étant disponibles pour moins de 0,50 dollar par million de tokens d'entrée via des fournisseurs hébergés. Ceci n'est pas seulement une guerre des prix. L'infrastructure d'inférence s'est améliorée : quantification, décodage spéculatif, optimisation du cache KV et traitement par lots ont tous réduit le coût d'un token. Les fournisseurs ont répercuté une partie de ces économies aux clients. Tendance clé 2 : Les modèles de raisonnement sont 5–30x plus chers Les modèles de raisonnement (o1, o3, o4-mini, DeepSeek-R1, Claude Opus 4 avec pensée étendue) génèrent des tokens de « pensée » internes avant de produire une réponse finale. Ces tokens de pensée sont facturés comme des tokens de sortie. Un modèle de raisonnement résolvant une tâche de codage peut générer 10K–50K tokens de pensée avant de produire une réponse de 2K tokens. Le coût effectif par tâche est donc bien plus élevé que ce que le prix par token suggère. Pour les équipes utilisant des modèles de raisonnement pour chaque tâche, c'est le plus grand facteur de coûts en 2026. La question clé n'est pas « combien coûte le modèle ? » mais « cette tâche nécessite-t-elle un raisonnement ? » La plupart ne la nécessitent pas. Tendance clé 3 : L'open-source a comblé l'écart de qualité Au début de 2024, les modèles à poids ouvert traînaient considérablement les modèles propriétaires sur les benchmarks de codage et de raisonnement. À mi-2026, les modèles comme Llama 4 Maverick, DeepSeek-V3, Qwen 3 et MiMo sont à quelques points de la performance de classe GPT-4 sur la plupart des benchmarks. Cela importe pour le coût car les modèles à poids ouvert sont moins chers à servir : les fournisseurs qui concourent sur les prix les utilisent pour réduire les prix propriétaires. L'écart de qualité n'a pas complètement disparu pour les tâches de raisonnement frontalier. Mais pour la plupart des charges de travail de production : résumé, extraction, classification, génération de code, utilisation d'outils, les modèles à poids ouvert sont suffisamment bons et significativement moins chers. Tendance clé 4 : Le cache a réduit les coûts effectifs de 50–90% pour les charges de travail répétées Le cache de prompts (Anthropic) et le cache de contexte automatique (OpenAI, Google) ont changé l'économie des charges de travail répétées. Si vous envoyez le même prompt système et contexte à un modèle 100 fois par jour, les lectures en cache coûtent 50–90% moins cher que les lectures sans cache. Pour les pipelines RAG, les systèmes d'agents et le traitement par lots, c'est transformatif. Les avantages du cache sont répartis de manière inégale. Les charges de travail avec contexte stable (même prompt système, même ensemble de documents) en bénéficient énormément. Les charges de travail avec contexte dynamique (conversations spécifiques à l'utilisateur, données en temps réel) en bénéficient moins. Les équipes FinOps doivent mesurer leur taux de succès du cache et optimiser la stabilité du contexte pour maximiser les économies. Tendance clé 5 : Les flux de travail d'agent multiplient la consommation de tokens Les flux de travail d'agent, où les modèles appellent des outils, lisent des fichiers, exécutent du code et itèrent sur les résultats, consomment 5–50x plus de tokens par tâche que les interactions unidirectionnelles. Un agent de codage résolvant un bug peut consommer 100K–500K tokens à travers ses appels d'outils, ses tentatives et son accumulation de contexte. Un prompt équivalent unidirectionnel pourrait utiliser 2K–5K tokens. C'est la tendance de coûts la plus importante en 2026. Les prix des tokens baissent, mais la consommation de tokens par tâche augmente plus vite. Résultat net : les dépenses totales en LLM augmentent pour la plupart des équipes même si les prix unitaires baissent. Chronologie : événements clés Date Événement Impact sur le prix Impact sur la qualité Mar 2024 Lancement de GPT-4-turbo 50% moins cher que GPT-4 Qualité comparable Jun 2024 Lancement de Claude 3.5 Sonnet 5x moins cher qu'Opus Qualité proche d'Opus Sep 2024 Lancement de o1-preview 3–5x plus par tâche (raisonnement) Grand saut en raisonnement Déc 2024 Google Gemini 2.0 Flash Moins de 1 $/M tokens d'entrée Puissant pour les tâches rapides Jan 2025 DeepSeek-R1 open-source 10x moins cher qu'o1 Raisonnement proche d'o1 Fév 2025 Réduction de prix de Claude 3.5 Sonnet Baisse supplémentaire de 20% Même qualité Avr 2025 Lancement de GPT-4.1 30% moins cher que GPT-4-turbo Codage amélioré Mai 2025 Lancement de Claude Sonnet 4 Même prix, meilleure qualité Grand saut en codage Jun 2025 Réduction de prix de OpenAI o3-mini Raisonnement 50% moins cher Même qualité Jan 2026 DeepSeek-V3 sur fournisseurs hébergés Moins de 0,50 $/M tokens d'entrée Proche de classe GPT-4 Avr 2026 Lancement de Claude Opus 4 Prix premium (15/75 $) Raisonnement frontalier Jun 2026 Llama 4 Maverick hébergé Moins de 0,30 $/M tokens d'entrée Qualité générale forte Jul 2026 Lancement de Anthropic Fable 5 / OpenAI GPT-5.6 Nouveau niveau frontalier (5/30 $), tarification de niveau intermédiaire (2,50/15 $), niveau économique (1/6 $) Fable 5 correspondait à la performance d'Opus 4 Ce qu'il faut attendre au second semestre 2026 Les prix des modèles de raisonnement chuteront de 30–50%. La concurrence des modèles de raisonnement open-source (DeepSeek-R2, variantes de raisonnement Qwen 3) forcera les fournisseurs propriétaires à réduire les prix de leurs niveaux de raisonnement. La tarification spécifique à l'agent émergera. Les fournisseurs testent des modèles de tarification par tâche et par session qui regroupent les appels d'outils, les tentatives et le contexte en un seul coût prévisible. Attendez qu'au moins un grand fournisseur l'offre d'ici le Q4 2026. Le cache deviendra automatique. La gestion manuelle du cache disparaîtra. Les fournisseurs optimiseront le placement du cache de manière transparente et les taux de succès du cache s'amélioreront pour la plupart des charges de travail sans intervention du développeur. Les modèles à poids ouvert domineront le travail de routine. D'ici la fin de 2026, attendez 70%+ de l'inférence de production sur les tâches de routine (classification, extraction, résumé, génération de code simple) s'exécutant sur les modèles à poids ouvert via des fournisseurs hébergés. Les dépenses totales continueront à augmenter. Malgré la chute des prix unitaires, les flux de travail pilotés par agents et l'expansion des cas d'usage de l'IA signifient que les dépenses totales en LLM continueront de croître. La discipline FinOps, pas seulement des modèles moins chers, est ce qui maintient les dépenses sous contrôle. Associé Économie des agents - comment les agents de codage se tarifent en pratique. Arbitrage des fournisseurs - changer de fournisseur pour réduire les coûts. Routage des modèles - envoyer les tâches au bon modèle. FinOps pour LLM - le cadre plus large. Voulez-vous que cela s'applique à vos propres dépenses en LLM ? FinOps LLM effectue un audit gratuit de vos coûts d'IA et vous montre où se trouvent les économies. Demander votre audit gratuit → Retour à la recherche --- # Impact des serveurs MCP sur les coûts · FinOps LLM URL: https://finopsllm.com/fr/research/mcp-server-cost-impact Impact des serveurs MCP sur les coûts Le Protocole de contexte du modèle (MCP) permet aux LLM d'appeler des outils externes : bases de données, API, systèmes de fichiers, moteurs de recherche. C'est puissant. C'est aussi coûteux. Chaque définition d'outil MCP consomme l'espace de la fenêtre de contexte, chaque appel d'outil est un aller-retour API séparé, et chaque résultat d'outil est réinjecté dans le modèle sous forme de tokens d'entrée supplémentaires. Pour les équipes qui exécutent des flux de travail d'agents intensifs en MCP, la surcharge liée aux outils peut représenter 30–60 % des dépenses totales de tokens. Cet article explique comment MCP augmente les coûts, comment mesurer la surcharge et que faire à ce sujet. Comment MCP consomme les tokens Il y a trois niveaux de coûts en tokens dans chaque interaction MCP : Niveau 1 : Définitions des outils. Chaque serveur MCP enregistre les outils auprès du modèle. Une définition d'outil comprend le nom de la fonction, le schéma des paramètres et une description de ce que fait l'outil. Une seule définition d'outil consomme généralement 500–2 000 tokens. Un serveur avec 15 outils ajoute 7,5K–30K tokens à chaque demande, même si aucun de ces outils n'est appelé. Niveau 2 : Demandes d'appel d'outil. Quand le modèle décide d'appeler un outil, il génère une sortie d'appel d'outil (nom de fonction + arguments). Ceci est facturé comme tokens de sortie. Puis le résultat de l'outil revient sous forme de tokens d'entrée. Un seul aller-retour d'appel d'outil coûte généralement 1K–5K tokens selon la taille du résultat. Niveau 3 : Résultats d'outils en contexte. Les résultats d'outils restent dans le contexte de la conversation pour tous les tours ultérieurs. Si vous appelez 10 outils dans une session, ces résultats s'accumulent. Une requête de base de données retournant 50 lignes de JSON peut ajouter 8K–15K tokens qui persistent pour le reste de la conversation. L'effet composé Les coûts MCP se composent parce que les définitions d'outils sont envoyées avec chaque demande. Si vous avez 20 outils définis (10K–40K tokens de définitions) et que vous faites 5 demandes dans une conversation, les définitions d'outils seules coûtent 50K–200K tokens d'entrée. Ajoutez les résultats des appels d'outils et vous pouvez facilement doubler votre consommation de base de tokens. Motif MCP Surcharge en tokens Fréquence Impact sur les coûts mensuels (estimation) Définitions d'outils (10 outils) 5K–20K tokens par demande Chaque demande 15–60 $ par utilisateur Aller-retour d'appel d'outil unique 1K–5K tokens 3–10 par session 5–25 $ par utilisateur Résultat d'outil volumineux (requête DB, recherche de code) 5K–20K tokens 1–5 par session 10–50 $ par utilisateur Résultats accumulés dans une session longue 20K–100K tokens 1–3 sessions/jour 30–120 $ par utilisateur Définitions d'outils inutilisés chargées 5K–30K tokens par demande Chaque demande 15–90 $ par utilisateur Comment mesurer la surcharge MCP La façon la plus simple de mesurer le coût de MCP est d'exécuter la même requête deux fois : une fois avec les outils MCP chargés et une fois sans. La différence en tokens d'entrée est votre surcharge de définitions d'outils. Ensuite, comptez les tokens des appels d'outils séparément : la plupart des fournisseurs les étiquettent clairement dans leurs tableaux de bord de facturation. Pour une mesure plus précise, instrumentez votre client MCP pour enregistrer : nombre d'outils enregistrés, tokens consommés par les définitions d'outils par demande, nombre d'appels d'outils par session, tokens par résultat d'outil et tokens totaux de session attribués à l'activité des outils. Stratégies pour réduire les coûts MCP 1. Chargez les outils de manière sélective. N'enregistrez pas tous les outils pour chaque demande. Si l'utilisateur pose une question sur le code, il n'a pas besoin de charger les outils de base de données ou de déploiement. De nombreux clients MCP prennent en charge le chargement dynamique des outils en fonction du contexte ou de l'activation explicite par l'utilisateur. 2. Minimisez les descriptions d'outils. Les descriptions d'outils sont le plus grand consommateur de tokens dans les définitions. Une description verbale peut être 500 tokens ; une concise peut être 100 tokens. Sur 20 outils, c'est une différence de 8K tokens par demande. 3. Tronquez les résultats d'outils. Retournez uniquement les champs dont le modèle a réellement besoin. Si une requête de base de données retourne 20 colonnes mais que le modèle n'en a besoin que de 3, projetez le résultat. Limitez la taille du résultat à une limite raisonnable : 2K–4K tokens suffisent généralement pour que le modèle prenne une décision. 4. Mettez en cache les appels répétés. Si le même outil est appelé avec les mêmes arguments dans une session, retournez le résultat mis en cache au lieu d'exécuter à nouveau. Ceci est particulièrement précieux pour les recherches de référence, les requêtes de schéma et les récupérations de documentation. 5. Résumez avant d'injecter. Pour les résultats d'outils volumineux (contenu complet de fichiers, réponses API longues), résumez avant d'ajouter au contexte. Retournez un résumé plus l'option d'obtenir le résultat complet si le modèle en a besoin. 6. Utilisez des limites budgétaires pour les résultats d'outils. Définissez un budget par session pour les tokens de résultats d'outils. Quand le budget est atteint, refusez d'autres appels d'outils ou basculez vers un modèle moins cher pour le reste de la session. Le coût caché des serveurs MCP Au-delà des coûts en tokens, les serveurs MCP introduisent une surcharge de latence et de fiabilité. Un appel d'outil qui prend 3 secondes à répondre ajoute de la latence à chaque tour. Un outil qui échoue de manière intermittente provoque des tentatives. Les deux augmentent le coût effectif par tâche. Pour les équipes qui étendent l'utilisation de MCP dans une organisation, suivre ces coûts au niveau du serveur est essentiel. Routez les charges de travail intensives en MCP vers les modèles avec des coûts par token plus bas, et gardez les flux de travail légers en MCP sur les modèles premium où la latence est importante. Relatif Économie des agents - comment les agents de codification se tarient dans la pratique. Attribution des dépenses d'agents - suivi des coûts des agents par projet. Suivi des tokens LLM - mesurer ce que vous dépensez. FinOps pour LLM - le cadre plus large. Voulez-vous que cela s'applique à vos propres dépenses LLM ? FinOps LLM effectue un audit gratuit de vos coûts en IA et vous montre où se trouvent les économies. Demandez votre audit gratuit → Retour à la recherche --- # Contrôler le coût en tokens des schémas MCP · FinOps LLM URL: https://finopsllm.com/fr/research/mcp-tool-definition-overhead Contrôler le coût en tokens des schémas MCP pour les agents Mis à jour September 19, 2026 · première publication September 19, 2026 Réponse rapide: Connecter un agent IA à plusieurs serveurs Model Context Protocol (MCP) injecte des milliers de tokens d'entrée à chaque tour avant même le traitement de la requête utilisateur. Chaque outil... Connecter un agent IA à plusieurs serveurs Model Context Protocol (MCP) injecte des milliers de tokens d'entrée à chaque tour avant même le traitement de la requête utilisateur. Chaque outil enregistré ajoute un schéma JSON décrivant paramètres, types et fonctions. Avec plusieurs serveurs connectés (GitHub, Postgres, Slack), ce préambule absorbe 4 500 à 12 000 tokens par appel API. Sur une session de 30 tours, cela génère un coût fixe considérable. Pourquoi les définitions d'outils MCP consomment-elles autant de tokens ? Chaque outil MCP exige une description JSON Schema complète pour permettre au modèle de structurer ses appels. Une seule fonction de base de données peut consommer 300 à 600 tokens. Multiplié par des dizaines d'outils, le préambule statique encombre inutilement la fenêtre de contexte. Trois leviers d'optimisation Les équipes d'ingénierie appliquent la mise en cache de prompts (prefix caching) positionnée après la déclaration des outils, un routage sémantique dynamique pour ne charger que les outils utiles, et la minification des schémas JSON. À lire aussi Outils serveur et facturation Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Les baisses de prix ne réduisent pas la facture seules · FinOps LLM URL: https://finopsllm.com/fr/research/model-price-cuts-routing-budget Baisses de prix des modèles et budget de routage Mis à jour September 10, 2026 · première publication September 10, 2026 Réponse rapide: Une baisse du prix du token ne garantit pas une facture allégée si les flux restent orientés vers les modèles haut de gamme. Ajustez votre routage dynamique. Une baisse du prix du token ne garantit pas une facture allégée si les flux restent orientés vers les modèles haut de gamme. Ajustez votre routage dynamique. À lire aussi Coût par tâche réussie Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Les contrôles de sûreté, seconde facture · FinOps LLM URL: https://finopsllm.com/fr/research/moderation-pass-second-bill Ce que coûtent les garde-fous et la modération Mis à jour September 1, 2026 · première publication September 1, 2026 Réponse rapide: Une fonctionnalité LLM en production fait rarement un seul appel. Elle fait celui que vous avez conçu, puis ceux ajoutés ensuite pour la sûreté : classifieur d’entrée, vérification de sortie, juge de... Une fonctionnalité LLM en production fait rarement un seul appel. Elle fait celui que vous avez conçu, puis ceux ajoutés ensuite pour la sûreté : classifieur d’entrée, vérification de sortie, juge de politique, parfois un second modèle qui note le premier. Tout cela est de l’inférence, et l’inférence est facturée. Le multiplicateur est plus grand qu’il n’y paraît La modération d’entrée lit toute l’entrée, celle de sortie toute la réponse. Un juge lit les deux , plus le contexte récupéré et une grille — son appel est donc plus gros que celui qu’il juge. Où la dépense s’accumule Trois schémas : juger avec un modèle de pointe par facilité (la classification est justement la tâche où un petit modèle suffit, et c’est souvent la plus grosse économie disponible) ; vérifier à chaque tour en rescannant un historique déjà validé ; et des garde-fous sur le trafic interne , qui hérite d’une pile de sûreté grand public dont il n’a pas besoin. Budgétez-le comme une ligne Il ne s’agit pas de supprimer les contrôles, mais de voir qu’ils peuvent représenter 30 à 50% du coût d’inférence sans figurer dans le plan. Marquez les appels de garde-fou séparément en télémétrie. À lire aussi Attribution des coûts LLM Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Votre environnement de dev coûte aussi · FinOps LLM URL: https://finopsllm.com/fr/research/non-production-llm-spend Dépense LLM hors production Mis à jour September 1, 2026 · première publication September 1, 2026 Réponse rapide: Toute revue FinOps commence par le trafic de production, parce que c’est ce qui a un tableau de bord. Puis quelqu’un ventile par environnement et découvre qu’une part notable de la facture —... Toute revue FinOps commence par le trafic de production, parce que c’est ce qui a un tableau de bord. Puis quelqu’un ventile par environnement et découvre qu’une part notable de la facture — souvent à deux chiffres en pourcentage — n’a jamais touché un client. D’où elle vient La CI : chaque pull request qui lance une suite d’évaluation appelle le modèle, des milliers de fois par jour, sur le modèle le plus capable. Le développement local : itérer sur un prompt, c’est des dizaines d’appels par heure, sur une clé partagée, sans étiquette. Staging et démos : configurés comme la production, donc modèle cher et pas de cache. Reprises et boucles emballées en test , que personne ne surveille. L’attribution d’abord Le changement qui se rembourse seul : une clé d’API par environnement . Une après-midi de travail, et une ligne inexpliquée devient quatre lignes étiquetées. Étiquetez l’environnement sur chaque requête et, pour la CI, le dépôt et le workflow. Trois conséquences suivent : hors production un modèle plus petit suffit presque toujours ; le cache y rapporte le plus, la CI rejouant des prompts quasi identiques ; et un plafond de dépense y est réellement sûr — un test plafonné casse un build, une production plafonnée casse un client. À lire aussi Attribution des coûts LLM Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # L'observabilité de l'IA : seconde facture · FinOps LLM URL: https://finopsllm.com/fr/research/observability-second-llm-bill L'observabilité comme seconde facture IA Mis à jour September 9, 2026 · première publication September 9, 2026 Réponse rapide: Mesurer l'IA avec de l'IA engendre des coûts d'inférence secondaires non négligeables. Échantillonnez les vérifications pour préserver les marges. Mesurer l'IA avec de l'IA engendre des coûts d'inférence secondaires non négligeables. Échantillonnez les vérifications pour préserver les marges. À lire aussi Contrôle des coûts d'évaluation Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Open source vs propriétaire : comparaison des coûts LLM · FinOps LLM URL: https://finopsllm.com/fr/research/open-source-vs-closed-cost Modèles Open-Source vs Propriétaires : Comparaison des Coûts LLM Mis à jour 15 juillet 2026 · publié pour la première fois le 4 juillet 2026 Quand est-il rentable d'auto-héberger Llama, Qwen ou DeepSeek par rapport à payer pour l'accès à l'API ? Cette analyse couvre les coûts GPU, l'optimisation de l'inférence, les frais opérationnels, et vous offre un cadre décisionnel pour votre charge de travail spécifique. 8 Modèles comparés 5 Niveaux GPU analysés 3 Scénarios d'équilibre Jul 2026 Dernière mise à jour Les coûts d'auto-hébergement supposent des tarifs GPU cloud (à la demande) Les coûts API utilisent les tarifs de sortie standards par fournisseur L'équilibre est basé sur 70% d'utilisation, disponibilité 24/7 Méthodologie Tarification API Tarifs standards publiés depuis chaque page de tarification du fournisseur. Aucune réduction par volume ou batch appliquée. GPU cloud pour auto-hébergement Tarifs à la demande en cloud (Lambda, RunPod, AWS) pour des configurations optimisées pour l'inférence avec vLLM ou TensorRT-LLM. Frais opérationnels Inclut la surveillance, la mise à l'échelle, les mises à jour de modèles, et une surcharge opérationnelle de 15% sur les coûts GPU bruts pour l'infrastructure gérée. Écart de qualité Relatif à GPT-4o / Claude Sonnet 4 comme ligne de base 100%. Basé sur les benchmarks publics et les performances pratiques en tâches. Tableau de Comparaison des Coûts Modèle ↕ Coût API/mois ↕ Coût Auto-hébergement (GPU cloud) ↕ Volume d'Équilibre ↕ Écart de Qualité Llama 4 Maverick (DeepInfra) $260/mois $2 800/mois ~350M tokens/mois ~95% de GPT-4o Llama 3.3 70B (Groq) $277/mois $1 200/mois ~210M tokens/mois ~87% de GPT-4o Llama 4 Scout (Groq) $136/mois $1 400/mois ~350M tokens/mois ~88% de GPT-4o Qwen 3.7-Max $525/mois $1 600/mois ~100M tokens/mois ~92% de GPT-4o DeepSeek V4 Pro $435/mois $1 800/mois ~130M tokens/mois ~96% de GPT-4o DeepSeek V4 Flash $140/mois $1 400/mois ~450M tokens/mois ~82% de GPT-4o Mistral Medium 3.5 $525/mois $2 000/mois ~120M tokens/mois ~91% de GPT-4o GPT-4o (API uniquement) $750/mois N/A N/A Ligne de base (100%) Coût API/mois suppose 100M tokens de sortie + 300M tokens d'entrée par mois aux tarifs standards. Coût d'auto-hébergement comprend la location GPU, les frais opérationnels de 15%, et l'infrastructure d'inférence (vLLM). N'inclut pas le temps d'ingénierie initiale. Volume d'équilibre est le nombre de tokens de sortie mensuels où l'auto-hébergement devient moins cher que l'API. Écart de qualité est approximatif et dépend de la tâche. Les benchmarks comme MMLU, HumanEval et GPQA informent ces estimations. Certains liens peuvent inclure des codes de parrainage. Facteurs Clés de Coût 1) La location GPU est le coût dominant Un nœud 8x H100 pour Llama 4 Maverick coûte 2 000 à 3 500 $/mois à la demande depuis Lambda, RunPod ou AWS. Les instances spot/préemptibles peuvent réduire cela de 40 à 60 % mais ajoutent une latence de redémarrage et un risque de disponibilité. Pour les charges de production, les instances réservées (engagement 1 an) économisent généralement 30 à 40 % par rapport à la demande. 2) L'optimisation de l'inférence change l'équation vLLM avec batching continu, pagination du cache KV, et quantification (GPTQ/AWQ 4-bit) peut augmenter le débit de 2 à 4x sur le même matériel. TensorRT-LLM ajoute un autre 20 à 40% pour les architectures supportées. Un Llama 4 Scout bien réglé en 4-bit sur un seul A100 peut égaler une configuration naïve fp16 sur 2x A100s. 3) Les frais opérationnels sont réels mais diminuent L'exécution d'une infrastructure d'inférence nécessite la surveillance GPU, les mises à jour de modèles, l'équilibrage de charge et le basculement. Budgétisez 15 à 25% du coût GPU brut pour les ops. Les plates-formes gérées (Anyscale, Modal, Replicate) absorbent cela mais facturent une surcharge de 30 à 50% sur le GPU brut - c'est utile pour moins de ~5 000 $/mois de dépenses GPU. 4) La mise en cache des prompts réduit l'écart pour l'API Les fournisseurs d'API offrent de plus en plus la mise en cache des prompts (réduction de 50 à 90% sur les préfixes répétés). Si votre charge est cache-friendly (RAG, multi-tour), les coûts API chutent considérablement, repoussant le volume d'équilibre plus haut pour l'auto-hébergement. Cadre Décisionnel Utilisez l'API si... Le volume de sortie mensuel est inférieur à 100M tokens Vous avez besoin de la qualité des modèles frontaliers (GPT-4o, Claude Opus 4) Votre équipe n'a pas d'expertise GPU/MLOps Les exigences de latence sont strictes (TTFT <200ms) Vous voulez zéro frais opérationnels Votre charge de travail est imprévisible ou saisonnière Auto-hébergez si... Le volume de sortie mensuel dépasse régulièrement 200M tokens La confidentialité des données nécessite aucun accès à l'API tiers Vous avez besoin de modèles personnalisés fine-tuned Votre équipe a une capacité MLOps La charge de travail est en état stable (utilisation GPU prévisible) Vous pouvez vous engager sur les instances GPU réservées 1 an Approche hybride : le juste milieu pragmatique La plupart des équipes se retrouvent en hybride : utiliser l'API pour les tâches de raisonnement frontalier et les charges faibles, auto-héberger des modèles open-source pour les tâches à fort volume et tolérantes à la latence (génération de contenu, extraction de données, outils internes). Cela maintient les dépenses d'API sous contrôle tout en construisant une capacité d'auto-hébergement de façon progressive. Où Exécuter les Modèles Open-Source Plateforme Options GPU Prix A100 80GB Prix H100 Inférence Gérée Lambda Cloud A100, H100, H200 $1,10/heure $2,49/heure Non (apportez le vôtre) RunPod A100, H100, L40S $1,19/heure $2,69/heure Option sans serveur AWS (p4d/p5) A100, H100 $3,67/heure $6,37/heure SageMaker Google Cloud A100, H100 $3,22/heure $5,07/heure Vertex AI Xiaomi MiMO ↗ Basé sur API N/A N/A API ($0,50/$2,00 par 1M) Les prix GPU sont des tarifs horaires à la demande à partir de juillet 2026. Les prix réservés/spot varient considérablement. MiMO offre un accès basé sur API à MiMo-V2-Pro et MiMo-V2-Omni à des tarifs compétitifs - un juste milieu entre l'auto-hébergement complet et les tarifs API premium. Voulez-vous appliquer cela à vos propres dépenses en LLM ? FinOps LLM réalise un audit gratuit de vos coûts d'IA et montre où se trouvent les économies. Réserver audit gratuit → Retour à la recherche FAQ Quelle est la méthodologie ? Tarifs standards publiés depuis chaque page de tarification du fournisseur. Aucune réduction par volume ou batch appliquée. GPU dans le cloud pour l'infrastructure auto-hébergée utilisant les prix à la demande (Lambda, RunPod, AWS) avec des configurations optimisées pour l'inférence avec vLLM ou TensorRT-LLM. Quel est le tableau de comparaison des coûts ? Coût API/mois suppose 100M tokens de sortie + 300M tokens d'entrée par mois aux tarifs standards. Coût d'auto-hébergement comprend la location GPU, les frais opérationnels de 15%, et l'infrastructure d'inférence (vLLM). N'inclut pas le temps d'ingénierie initiale. Quels sont les facteurs clés de coût ? Un nœud 8x H100 pour Llama 4 Maverick coûte 2 000 à 3 500 $/mois à la demande depuis Lambda, RunPod ou AWS. Les instances spot/préemptibles peuvent réduire cela de 40 à 60 % mais ajoutent une latence de redémarrage et un risque de disponibilité. Pour les charges de production, les instances réservées (engagement 1 an) économisent généralement 30 à 40 % par rapport à la demande. Quel est le cadre décisionnel ? La plupart des équipes se retrouvent en hybride : utiliser l'API pour les tâches de raisonnement frontalier et les charges faibles, auto-héberger des modèles open-source pour les tâches à fort volume et tolérantes à la latence (génération de contenu, extraction de données, outils internes). Où exécuter les modèles open-source ? Les prix GPU sont des tarifs horaires à la demande à partir de juillet 2026. Les prix réservés/spot varient considérablement. MiMO offre un accès basé sur API à MiMo-V2-Pro et MiMo-V2-Omni à des tarifs compétitifs - un juste milieu entre l'auto-hébergement complet et les prix API premium. --- # Attribution des coûts d'OpenAI · FinOps LLM URL: https://finopsllm.com/fr/research/openai-cost-attribution Attribution des coûts d'OpenAI L'attribution des coûts d'OpenAI commence avant que la requête ne soit envoyée. La réponse de l'API peut vous indiquer l'utilisation des tokens, mais elle ne peut pas savoir quelle surface de produit, équipe, client ou workflow métier a causé l'appel à moins que votre application n'attache ce contexte. L'attribution doit combiner trois sources : métadonnées de requête, enregistrements d'utilisation et données de facture. Les métadonnées de requête donnent la propriété. Les enregistrements d'utilisation donnent les comptes de tokens et le modèle. Les données de facture donnent le total financier faisant autorité. Tags à capturer Nom de fonctionnalité ou endpoint. Propriétaire de l'équipe et environnement. Projet ou client quand autorisé. Classe de charge de travail, comme realtime, batch, eval, support ou étape d'agent. Version du prompt, politique de routage et statut de secours. Lacunes courantes en attribution Les équipes manquent souvent les nouvelles tentatives et les secours. Un utilisateur voit une réponse, mais le système peut avoir payé pour plusieurs appels en amont. Une autre lacune courante est le travail batch : les evals et les tâches d'enrichissement doivent être étiquetées séparément du trafic orienté vers l'utilisateur pour pouvoir passer à des voies asynchrones moins coûteuses. Les meilleurs rapports d'attribution OpenAI ne s'arrêtent pas à « quel modèle a coûté le plus ». Ils montrent quelle décision produit a causé l'utilisation de ce modèle, et quel propriétaire peut la changer. Connexes Attribution des coûts des LLM - principes généraux d'attribution. Attribution des coûts d'Anthropic - attribution pour les modèles Anthropic. Qu'est-ce que FinOps pour LLM? - la discipline opérationnelle complète. Vous voulez que cela s'applique à vos propres dépenses en LLM? FinOps LLM réalise un audit gratuit de vos coûts d'IA et montre où se trouvent les économies. Réservez votre audit gratuit → Retour à la recherche --- # Économie de l'Arrêt du Fine-Tuning OpenAI · FinOps LLM URL: https://finopsllm.com/fr/research/openai-fine-tuning-sunset-economics Économie de l'Arrêt du Fine-Tuning OpenAI Publié 19 juillet 2026 OpenAI supprime le fine-tuning en libre-service. À partir du 7 mai 2026, les nouvelles organisations ne peuvent plus créer de travaux de fine-tuning. Avant le 6 janvier 2027, toutes les organisations perdent cette capacité. Si vous dépendez de modèles GPT avec fine-tuning, vous devez choisir un chemin de migration maintenant : ingénierie de prompts sur GPT-5.5 avec mise en cache, adaptateurs LoRA open-source sur Llama ou Qwen, ou fine-tuning géré via Vertex AI, AWS Bedrock ou Mistral. Chaque chemin présente des compromis distincts en matière de coûts et d'opérations. La création de fine-tuning en libre-service se termine le 6 janvier 2027 pour toutes les organisations L'inférence sur les modèles avec fine-tuning existants continue jusqu'à la dépréciation de la base La mise en cache de prompts sur GPT-5.5 peut égaler ou dépasser le ROI du fine-tuning en 10–30 accès Le LoRA open-source coûte 30–50% moins cher que les services gérés pour un volume élevé Coûts cachés de migration : réévaluations, tests de régression, exécution double, réentraînement Délai : Les organisations doivent s'engager sur un chemin de migration avant le 6 janvier 2027. Les modèles avec fine-tuning existants continueront de servir les demandes d'inférence jusqu'à ce que leur modèle de base soit déprécié, mais vous ne pouvez pas créer de nouveaux travaux d'entraînement après cette date. Chronologie et Matrice d'Exposition Qui est affecté et quand : Date Phase Organisations Affectées Action Requise 7 mai 2026 Phase 1 Nouvelles organisations, jamais avec fine-tuning auparavant Impossible de démarrer de nouveaux travaux 2 juillet 2026 Phase 2 Organisations existantes sans inférence de modèle avec fine-tuning au cours des 60 derniers jours Impossible de démarrer de nouveaux travaux 6 janvier 2027 Phase 3 (finale) Toutes les organisations, même les utilisateurs actifs Aucun nouveau travail d'entraînement Post-2027 Inférence uniquement Toutes les organisations avec modèles avec fine-tuning déployés L'inférence continue jusqu'au coucher de la base Pourquoi OpenAI supprime le fine-tuning : Les modèles de classe GPT-5.5 combinés avec la mise en cache de prompts éliminent le besoin de fine-tuning dans la plupart des cas d'utilisation. Les prompts plus longs avec des exemples few-shot et des instructions système correspondent désormais ou dépassent la performance du fine-tuning, tout en consommant moins de tokens totaux lorsqu'ils sont mis en cache. Les frais généraux de gestion du fine-tuning dépassent sa valeur pour la plupart des charges de travail. Arbre de Décision : Trois Chemins de Migration Chemin 1 : Ingénierie de Prompts + GPT-5.5 + Mise en Cache Réécrire la logique avec fine-tuning comme prompt système + exemples few-shot, mis en cache. Échangez des prompts plus longs contre zéro frais d'entraînement. Coût d'entraînement : $0 (aucun réentraînement) Coût de token par appel : Prompt plus long, mais mis en cache à 50% du taux frais Temps de configuration : 1–4 semaines (ingénierie de prompts + benchmarking) Opérations en cours : Itération de prompts, aucun MLOps requis Chemin 2 : LoRA en Open-Source (Together, Fireworks, Groq) Fine-tune Llama 4 ou Qwen 3.5 avec adaptateurs LoRA, hébergé sur inférence gérée. Contrôle complet du fine-tuning, reproductibilité open-source. Coût d'entraînement : $200–$500 par travail Coût d'inférence : $0,10–$0,30/M tokens (compétitif) Temps de configuration : 2–6 semaines (préparation des données, entraînement des adaptateurs, tests) Opérations en cours : Surveillez la performance de l'adaptateur, réentraînez selon les besoins Chemin 3 : Fine-Tuning Géré (Vertex, Bedrock, Mistral) Utilisez Google Vertex AI, AWS Bedrock ou fine-tuning Mistral. Flux de travail familier, support du fournisseur, mais coût par token plus élevé. Coût d'entraînement : $500–$2 000 par travail Coût d'inférence : $0,20–$1,00/M tokens (premium) Temps de configuration : 1–3 semaines (moins d'intégrations nécessaires) Opérations en cours : Le fournisseur gère les opérations, vous gérez la cadence d'entraînement Chemin 1 : Ingénierie de Prompts + Mise en Cache GPT-5.5 — Mathématiques Résolues Supposons que vous aviez un modèle GPT-4 avec fine-tuning pour la classification des tickets de support client. Le modèle avec fine-tuning a été entraîné sur 10K tickets étiquetés. Chaque demande envoie ~500 tokens d'entrée, obtient ~50 tokens de sortie. Ancien coût (fine-tuning) : Travail de fine-tuning : ~$50. Inférence à 100K appels/mois : (500 entrée × $3/M + 50 sortie × $15/M) × 100K = $150/mois + entraînement = ~$200/mois tout compris. Nouveau coût (mise en cache de prompts sur GPT-5.5) : Créez un prompt système avec 40 exemples few-shot (chacun ~200 tokens) = 8K tokens. C'est le remplissage du cache. Premier appel : 8K × (1,25× $3/M) + 500 × $3/M + 50 × $15/M ≈ $0,045. Appels ultérieurs (accès au cache) : 500 × (0,5× $3/M) + 50 × $15/M ≈ $0,0015. À 100K appels/mois, supposez 90% d'accès (90K accès au cache). Coût : 10K appels × $0,045 + 90K appels × $0,0015 = $450 + $135 = $585/mois . Attendez — c'est plus cher ! Vrai si vous ne paramétrez pas le prompt. Mais réduisez les exemples few-shot à 10 (2K tokens), et le coût baisse à ~$280/mois. De plus : si vous pouvez regrouper les requêtes (traiter 10 tickets connexes en un appel), le coût par ticket baisse d'un autre 30%. Conclusion : la mise en cache de prompts sur GPT-5.5 devient moins chère que le fine-tuning à 15–30 accès au cache par contexte unique. La plupart des équipes l'atteignent en quelques heures de déploiement. Risque de qualité : Les prompts few-shot peuvent sous-performer le fine-tuning sur les cas extrêmes et les formats inhabituels. Budgétisez 2–4 semaines pour les tests de régression. Chemin 2 : LoRA en Open-Source — Coûts et Logistique Le fine-tuning open-source via LoRA (Low-Rank Adaptation) gèle le modèle de base et entraîne uniquement de petites matrices d'adaptateur (~1–5% des paramètres). Structure de coûts : Composant Exemple de Fournisseur Coût Notes Entraînement (Llama 3.3 70B sur 10K échantillons) Together AI $300 LoRA sur GPU H100 unique (~4 heures) Inférence (par 1M tokens) Groq (Llama 3.3 70B) $0,27 Rapide (aucun décalage d'ajustement par rapport au GPT-4 avec fine-tuning) Inférence (par 1M tokens) Together AI (Llama 3.3 70B) $0,18 Réponse plus lente, coût inférieur Hébergement de modèle (mensuel, toujours actif) Auto-hébergé sur runpod $300–$600 Location GPU A100 + frais généraux d'opérations Total pour 1M appels/mois — $318–$600 API Groq (gérée), aucun coût d'hébergement Pourquoi l'open-source est moins cher : Aucune prime par token pour le statut « avec fine-tuning ». L'adaptateur vous appartient pour distribuer et améliorer. La qualité du modèle (Llama 4 Maverick) égale GPT-4o pour la plupart des tâches à 30–50% moins cher. Le compromis : vous possédez les MLOps — cadence de réentraînement, détection de dérive, tests A/B entre versions d'adaptateurs. Risque d'intégration : Passer de l'API OpenAI à Groq, Together ou auto-hébergement change votre latence d'inférence, gestion des erreurs et mise à l'échelle. Attendez-vous à 1–2 semaines de travail d'intégration. Chemin 3 : Fine-Tuning Géré (Vertex, Bedrock, Mistral) Fournisseur Coût d'Entraînement (10K échantillons) Coût d'Inférence (par 1M tokens de sortie) Modèle de Base Temps jusqu'à la Production Google Vertex AI $500–$800 $0,40–$1,50 Gemini 1.5 Flash, autres modèles OS 1–2 semaines AWS Bedrock (Claude Sonnet avec fine-tuning) $600–$1 200 $0,80–$2,00 Claude Sonnet, Llama 4, Mistral 1–2 semaines Fine-tuning Mistral $400–$700 $0,25–$0,60 Mistral 3.5 Moe, autres modèles Mistral 1 semaine Coût mensuel typique (100K appels, 500 tokens moyen) $600–$1 200 (entraînement ponctuel) $200–$1 000 (inférence récurrente) — — Les services gérés sont la rampe la plus facile : votre équipe connaît déjà l'authentification API, le support du fournisseur est disponible, et vous évitez les frais généraux de MLOps. Mais les coûts d'inférence sont 2–5× plus élevés que le LoRA open-source. Ce chemin a du sens si : (1) vous avez Comparaison des Coûts Trois Chemins (Charge de Travail Concrète) Charge de travail : IA de service client pour SaaS. 1M appels d'inférence/mois, moyenne 500 entrée + 150 tokens de sortie par appel. L'équipe a entraîné un modèle avec fine-tuning sur 5K conversations étiquetées. Composant de Coût Chemin 1 : Mise en Cache de Prompts + GPT-5.5 Chemin 2 : LoRA sur Groq (Llama 3.3) Chemin 3 : Bedrock (Claude Sonnet FT) Configuration initiale / entraînement $0 (ingénierie de prompts uniquement) $300 $1 000 Coût d'inférence mensuel (1M appels) $450–$600 $270 $900–$1 200 Total mensuel (Année 1) $450–$600 $600 (entraînement inclus amorti) $1 900–$2 200 Total Année 1 $5 400–$7 200 $3 600–$4 800 $12 000–$15 000 Le Chemin 2 (LoRA) gagne sur coût pur, mais nécessite du temps MLOps pour configurer et maintenir. Le Chemin 1 (mise en cache de prompts) a le moins de friction si vous acceptez des coûts continus légèrement plus élevés. Le Chemin 3 (géré) n'est choisi que si les SLAs professionnelles ou les opérations sans intervention sont obligatoires. Coûts Cachés de Migration — Ne les Manquez Pas Le tableau ci-dessus omet la friction opérationnelle. Planifiez : 1. Réévaluation et Benchmarking Mesurez la précision, la latence et le coût du nouveau modèle sur votre ensemble de test de rétention. Budget : 2–3 semaines, $1K–$3K en temps d'ingénierie. 2. Tests de Régression Exécutez le modèle ancien avec fine-tuning et la nouvelle voie sur les mêmes 100–1K requêtes de production. Mesurez les écarts de qualité. Pour les systèmes orientés clients, envisagez les tests A/B (exécution double) pendant 2–4 semaines. Coût d'opérations : $2K–$5K. 3. Période d'Exécution Double Exécutez les deux anciennes et nouvelles voies en parallèle pour détecter les régressions en production. Cela double le coût d'inférence pendant 2–4 semaines. Ajoute $500–$2 000 à votre facture de migration. 4. Modifications du Flux d'Entraînement Si vous réentraînez régulièrement (mensuel, trimestriel), factorisez les modifications de script. Les scripts de réentraînement LoRA diffèrent de l'API OpenAI. Mistral, Vertex et Bedrock ont chacun des API d'entraînement différentes. Budget : 1–2 semaines, $500–$1 500. 5. Dérive d'Adaptateur et Surveillance Les adaptateurs open-source peuvent dévier si les données d'entraînement changent. Configurez la surveillance de la performance et les déclencheurs de réentraînement. Pour les services gérés, le fournisseur gère cela mais facture les frais généraux de surveillance. Budget : récurrent +$200–$500/mois. Coût caché total : $4K–$12K en temps d'ingénierie + $500–$2 000 en opérations d'exécution double. La plupart des équipes sous-estiment cela de 50%. Intégrez-le à votre plan de projet. Cadre de Décision Choisissez le Chemin 1 (Mise en Cache de Prompts + GPT-5.5) si : Le volume d'inférence mensuel est inférieur à 100M tokens Votre charge de travail actuelle a des contextes répétés (RAG, multi-tour) — potentiel d'accès au cache élevé Votre équipe n'a aucune expérience en MLOps et souhaite des frais généraux minimaux Vous pouvez accepter un compromis de qualité pour la simplicité (la plupart des tâches voient ≤5% de régression) Les exigences de latence sont flexibles (>500ms TTFT acceptable) Choisissez le Chemin 2 (LoRA en Open-Source) si : Le volume d'inférence mensuel dépasse 200M tokens — avantage de coûts de 30–50% Votre équipe a la capacité MLOps pour l'entraînement, la surveillance et le réentraînement Vous avez besoin de reproductibilité et souhaitez un contrôle total sur l'adaptateur (avantage open-source) La confidentialité des données nécessite aucun appel aux APIs propriétaires d'OpenAI, Google ou AWS La latence est critique ( Choisissez le Chemin 3 (Fine-Tuning Géré) si : Vous avez besoin de SLAs professionnelles, de support du fournisseur ou de conformité HIPAA/SOC 2 Votre équipe manque d'expertise en infrastructure et souhaite zéro MLOps Le volume mensuel est inférieur à 50M tokens (la prime de coûts est acceptable à petite échelle) Vous êtes déjà investi dans l'écosystème du fournisseur (AWS, Google Cloud, Mistral) La fréquence d'entraînement est mensuelle ou moins (le coût d'opérations s'amortit mieux avec peu de changement) Lectures Connexes Pour plus de contexte sur le paysage des coûts plus large, voir Comparaison des Coûts LLM Open-Source vs Propriétaire , qui compare les volumes de seuil de rentabilité entre les options auto-hébergées et API. Vous suivez déjà vos coûts de migration du fine-tuning ? FinOps LLM audite vos dépenses LLM et identifie quel chemin de migration vous fait le plus économiser. Réservez une audit gratuit . Retour à la recherche FAQ Quand ne puis-je plus créer de nouveaux modèles avec fine-tuning OpenAI ? Chronologie : 7 mai 2026 (nouvelles organisations bloquées), 2 juillet 2026 (organisations inactives depuis 60 jours bloquées), 6 janvier 2027 (tous les nouveaux travaux bloqués). L'inférence sur les modèles avec fine-tuning existants continue jusqu'à la dépréciation du modèle de base. La mise en cache de prompts s'amortit-elle par rapport au fine-tuning ? Pour les prompts répétés sur le même contexte : oui. La mise en cache de prompts sur GPT-5.5 coûte $0,60/M pour les lectures contre $3,00/M frais, et les exemples few-shot (prompts plus longs) peuvent être mis en cache efficacement. Le seuil de rentabilité est généralement de 10–30 accès au cache selon la taille du prompt ; la plupart des équipes l'atteignent en quelques jours. Le LoRA open-source est-il moins cher que le fine-tuning géré ? Habituellement, oui. Coût d'entraînement via Together AI : ~$200–$500 par travail. Inférence sur Groq ou Fireworks : ~$0,10–$0,30/M tokens. Le coût total par réponse réussie est souvent 30–50% inférieur à un service géré, mais nécessite des frais généraux MLOps. Quels coûts cachés ne vois-je pas pendant la migration ? Réévaluation (comparaison de la nouvelle approche par rapport à l'ancienne), tests de régression (la nouvelle voie offre-t-elle la même qualité ?), exécution double (exécuter les deux anciennes et nouvelles voies en parallèle par sécurité), et réentraînement des adaptateurs si le nouveau modèle change. Budgétisez 4–8 semaines et ~$2K–$10K en temps d'ingénierie par migration. --- # Les niveaux d'effort d'Opus 5.5 sont le vrai prix · FinOps LLM URL: https://finopsllm.com/fr/research/opus-5-5-effort-level-cost Les niveaux d'effort d'Opus 5.5 sont le vrai prix Mis à jour September 22, 2026 · première publication September 22, 2026 Claude Opus 5.5 s'affiche à $4 par million de tokens d'entrée et $20 par million de tokens de sortie. C'est 20% moins qu'Opus 5. Le tarif n'est que la moitié du coût. L'autre moitié est le paramètre effort , qui détermine combien de tokens le modèle consomme en réfléchissant avant de répondre. Un modèle, cinq prix Opus 5.5 expose l'effort de low à medium , high , xhigh et max . Chaque niveau est le même modèle au même tarif par token, mais produit un nombre très différent de tokens. L'analyse indépendante rapportée par The Decoder a trouvé que quatre des cinq niveaux se situent sur la frontière de Pareto coût-performance. Elle a aussi découvert qu'au niveau d'effort maximal Opus 5.5 utilisait environ 119.000 tokens de sortie par tâche, bien plus que les modèles concurrents à leurs réglages les plus élevés. À 20 $ le million, 119 200 tokens de sortie font 2,38 $ par tâche avant toute entrée. En medium, Artificial Analysis a mesuré 25 700 tokens de sortie, soit 0,51 $. Entrée comprise, max coûte 5,98 $ par tâche et medium 1,34 $ : le même modèle coûte environ 4,5 fois plus par tâche selon un seul paramètre de requête. Mesuré sur l'Artificial Analysis Intelligence Index v4.3.2 (dix évaluations), consulté le 22 septembre 2026. Toutes les lignes utilisent la même batterie de tests et se comparent donc directement. Modèle et effort Intelligence Index Coût par tâche Tokens de sortie par tâche Sur la frontière coût–performance Opus 5.5 · low 42.3 $0.55 10,200 Non Opus 5.5 · medium 51.2 $1.34 25,700 Oui Opus 5.5 · high 53.6 $1.82 35,600 Oui Opus 5.5 · xhigh 56.0 $3.46 65,700 Oui Opus 5.5 · max 57.6 $5.98 119,200 Oui Opus 5 · high (référence) 48.1 $3.61 46,200 Non Source : Artificial Analysis. Sur la frontière signifie qu'aucun réglage de GPT-6 Sol, GPT-6 Astra, Opus 5, Opus 5.5 ou Fable 5.1 n'obtient un meilleur score pour moins cher. Opus 5.5 low en est exclu, car GPT-6 Sol en xhigh obtient 44,1 pour 0,53 $. Passer de xhigh à max ajoute 1,6 point pour 73 % de coût en plus. Moyen est le réglage sur lequel Anthropic fait ses comparaisons La comparaison phare d'Anthropic se fait à l'effort par défaut, qui est moyen. Elle déclare qu'Opus 5.5 en moyen surpasse GPT-6 Astra en effort maximal sur le travail de connaissance pour environ un cinquième du coût par tâche. Ainsi, l'argument propre d'Anthropic pour le modèle repose sur le moyen, et le maximum est l'exception. Une équipe qui fixe le maximum partout « pour être sûre » paie des tokens que les benchmarks de lancement n'avaient pas besoin. Comment définir l'effort sans deviner Par défaut au moyen. Fixez-le comme valeur explicite dans le code, pas un défaut du SDK qui peut changer sous vous. Augmentez l'effort par route, pas globalement. Le débogage difficile, la planification à long terme et les étapes d'examen final peuvent justifier haut ou max. La classification, l'extraction et les éditions routinières le font rarement. Enregistrez l'effort avec chaque requête. Le coût par requête n'est pas interprétable sans lui. Un pic de dépenses avec un nombre de requêtes stable est généralement un changement d'effort. Comparez les niveaux d'effort sur les mêmes tâches rejouées. Enregistrez le taux de succès et les tokens de sortie par tâche complétée à chaque niveau, et arrêtez d'augmenter l'effort quand le succès cesse de s'améliorer. Plafonnez la sortie où le produit le permet. Une limite de tokens maximale limite le pire des cas. Au niveau d'effort maximum, cette limite est la seule chose entre une tâche qui s'emballe et une requête de plusieurs dollars. La réduction de $25 à $20 par million de tokens de sortie économise 20%. Déplacer une charge de travail de l'effort maximum au moyen peut économiser bien plus. Traitez l'effort comme une ligne budgétaire, détenue et examinée comme n'importe quelle autre. À lire aussi Modèle de coût de Claude Opus 5.5 Économie du mode rapide d'Opus 5.5 Guide des coûts du modèle de raisonnement Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Opus 5.5 fast mode: 2x le prix pour moins d'attente · FinOps LLM URL: https://finopsllm.com/fr/research/opus-5-5-fast-mode-economics Économie d'Opus 5.5 fast mode Mis à jour September 22, 2026 · première publication September 22, 2026 Claude Opus 5.5 a deux listes de prix. Standard est $4 par million de tokens d'entrée et $20 par million de sortie. Fast mode est $8 et $40, exactement le double, pour jusqu'à 2,5× la vitesse de sortie. Le modèle est identique. L'argent supplémentaire achète du temps et rien d'autre, donc la seule question est le temps de qui. Ce que paie le premium Prenez une étape qui produit 5.000 tokens de sortie. Aux tarifs standard, le coût est $0,10. En fast mode, c'est $0,20. Si l'étape prend 60 secondes à vitesse standard, une accélération 2,5× la ramène à environ 24 secondes. Vous payez $0,10 supplémentaires pour économiser 36 secondes. Cela revient à environ $10 pour chaque heure d'attente éliminée. La longueur de l'étape ne change pas le ratio, car le coût supplémentaire et le temps économisé augmentent avec les tokens de sortie. Cela dépend de votre vitesse en mode standard : cet exemple suppose environ 83 tokens de sortie par seconde. L'entrée double aussi, donc les étapes à fort préfixe paient un peu plus par seconde économisée. Quand c'est bon marché Un développeur qui attend un agent de codage interactif. À $10 par heure d'attente supprimée, fast mode coûte bien moins que le temps de quiconque est payé. Une réponse client où la latence affecte la conversion. Évaluez l'accélération par rapport à l'abandon, pas par rapport à la facture de tokens. Un incident, où chaque minute a un coût. Quand c'est du gaspillage pur Agents en arrière-plan, travaux nocturnes et pipelines batch. Personne n'attend, donc la dépense supplémentaire n'achète rien. Évals et replays. Ce sont exactement les charges de travail qui multiplient les comptages de tokens et s'exécutent selon un calendrier. Sous-agents qui s'exécutent en parallèle. Le temps mural est défini par la branche la plus lente et l'orchestrateur, pas par chaque appel. Opus 5.5 standard est déjà environ 30% plus rapide qu'Opus 5, selon Anthropic. Certaines plaintes de latence qui auraient justifié fast mode sur Opus 5 peuvent être résolues par la mise à niveau seule. Mesurez la vitesse standard avant de payer pour plus. Contrôles à mettre en place Faites de fast mode une décision explicite, par route. Cela ne devrait jamais être un défaut global ou un drapeau qu'un ingénieur a activé une fois et oublié. Marquez les dépenses par mode. Une demande de fast mode au double du prix unitaire ressemble à une demande normale sur un tableau de bord qui regroupe uniquement par modèle. Alertez sur la part de fast mode des tokens de sortie. Si elle augmente sur des routes où aucun utilisateur n'attend, quelque chose a été activé qui ne devrait pas l'être. Budgétisez l'effort et la vitesse ensemble. L'effort maximal multiplie le nombre de tokens, et fast mode double le prix de chaque token. C'est la manière la plus chère d'exécuter le modèle. À lire aussi Modèle de coût Claude Opus 5.5 Les niveaux d'effort d'Opus 5.5 sont le vrai prix Limites de fan-out et concurrence des sous-agents Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Ox Alpha était GLM-5.3 : le coût du gratuit · FinOps LLM URL: https://finopsllm.com/fr/research/ox-alpha-was-glm-5-3 Ox Alpha était GLM-5.3 Mis à jour September 1, 2026 · première publication September 1, 2026 Réponse rapide: Du 20 au 26 août 2026, OpenRouter a servi gratuitement un modèle nommé stealth/ox-alpha. Il s’agissait de GLM-5.3-Flash : 320 milliards de paramètres au total dont 18 milliards actifs, attention... Du 20 au 26 août 2026, OpenRouter a servi gratuitement un modèle nommé stealth/ox-alpha . Il s’agissait de GLM-5.3-Flash : 320 milliards de paramètres au total dont 18 milliards actifs, attention hybride linéaire et éparse, entrée native texte, image et vidéo, fenêtre de 1 048 576 tokens et poids sous licence MIT. L’adoption n’a rien eu de marginal : en trois jours, OpenCode a rapporté environ 16 000 milliards de tokens traités, 221 000 utilisateurs uniques et plus de cinq millions de sessions. C’est du trafic de production, et il n’a rien coûté pendant six jours. Gratuit est un tarif, pas une absence La télémétrie de coût traite une ligne à 0 dollar comme une ligne inexistante. Ce trafic ne pèse donc dans aucune prévision ni alerte budgétaire. Quand la fenêtre se ferme et qu’un tarif s’applique, le même trafic réapparaît sous forme de marche non modélisée. Appliquez un prix fictif à chaque appel gratuit : enregistrez les tokens et multipliez-les par le tarif public du modèle que vous auriez utilisé. Le tableau de bord montre alors la valeur mensuelle de la promotion et la facture du jour où elle s’arrête. Le tarif n’est plus hypothétique : GLM-5.3-Flash est facturé 0,15 dollar par million de tokens d’entrée et 0,50 en sortie. Seize mille milliards de tokens d’entrée à ce tarif représentent environ 2,4 millions de dollars — la valeur de six jours gratuits, et la hauteur de la marche si ce trafic reste en place. Trois expositions à vérifier La falaise tarifaire : combien coûte ce trafic demain au prix public? La dérive d’identité : quel modèle se cache derrière l’alias cette semaine? Le couplage qualité : les prompts ont-ils été ajustés à un modèle que vous ne pouvez pas garder? Épinglez les identifiants de modèle et évaluez le remplaçant avant la fin de la fenêtre. Les poids MIT changent le calcul Sous licence MIT, l’auto-hébergement devient une vraie option. Avec 18 milliards de paramètres actifs, le coût de service ressemble à celui d’un modèle dense moyen, mais uniquement à forte utilisation soutenue. En dessous de 40 à 50% d’utilisation GPU, l’API l’emporte généralement : un accélérateur inactif se facture plein tarif, un appel qui n’a pas lieu ne coûte rien. À lire aussi Coût des modèles ouverts et fermés Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Comment chiffrer un modèle qui n’a pas de prix · FinOps LLM URL: https://finopsllm.com/fr/research/pricing-an-open-weight-model Chiffrer un modèle à poids ouverts Mis à jour September 1, 2026 · première publication September 1, 2026 Réponse rapide: Qwen3.8-Flash-Next est arrivé le 26 août 2026 comme préversion à poids ouverts de l’architecture Qwen4 : environ 6 milliards de paramètres actifs, un contexte natif de 262 144 tokens, et aucun tarif... Qwen3.8-Flash-Next est arrivé le 26 août 2026 comme préversion à poids ouverts de l’architecture Qwen4 : environ 6 milliards de paramètres actifs, un contexte natif de 262 144 tokens, et aucun tarif hébergé annoncé. La comparaison habituelle ne tient plus : un modèle fermé fournit un prix au million de tokens; des poids ouverts fournissent un checkpoint et vous laissent le calcul. La formule coût par MTok = prix_horaire / (tokens_par_seconde * 3600) * 1 000 000 À 2,00 $ l’heure et 1 500 tokens par seconde mesurés, cela fait 0,37 $ par million de tokens . Face à une API à 3,00 $/MTok, l’économie semble d’un facteur huit. Ce chiffre est faux : il suppose que le GPU travaille chaque seconde que vous payez. Le terme oublié : le taux d’utilisation Vous louez l’heure, vous en utilisez une fraction. Divisez par cette fraction : 0,62 $ à 60 %, 1,23 $ à 30 %, 3,70 $ à 10 % — plus cher que l’API à remplacer. La plupart des premiers déploiements se situent entre 10 et 30 %, parce que le trafic est irrégulier et l’instance dimensionnée pour le pic. L’économie est réelle, mais elle porte sur l’utilisation, pas sur les poids. Mesurez avant de vous engager Faites tourner le modèle sur l’instance que vous loueriez réellement, avec vos prompts et vos longueurs de contexte, et relevez les tokens par seconde en concurrence — pas le chiffre en flux unique de la fiche modèle. Calculez ensuite le taux d’utilisation sur votre profil de trafic réel. Deux nombres, une division, la décision se prend seule. Chiffrez le contexte que vous envoyez, pas celui que le modèle accepte. À lire aussi Coût des modèles ouverts et fermés Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Prouver le ROI IA sans masquer la qualité · FinOps LLM URL: https://finopsllm.com/fr/research/prove-ai-roi-measurement Prouver le ROI IA sans masquer la qualité Mis à jour August 27, 2026 · première publication August 27, 2026 Réponse rapide: Le ROI IA ne se prouve pas par une facture plus basse. Il se prouve quand un résultat métier progresse davantage que le coût complet nécessaire. Reliez dépense attribuable, résultat réussi et contrôle... Le ROI IA ne se prouve pas par une facture plus basse. Il se prouve quand un résultat métier progresse davantage que le coût complet nécessaire. Reliez dépense attribuable, résultat réussi et contrôle qualité. Définir le contrefactuel Décrivez ce qui se serait passé sans le changement: travail humain, ancien modèle ou ancien flux. Utilisez une période ou cohorte comparable. Mesurer le résultat Suivez le coût par tâche réussie, pas par requête. Définissez la réussite et incluez reprises, outils, réparation humaine et évaluations. Garder la qualité Associez résultat financier, taux de réussite, erreurs, latence et acceptation. Une économie qui dégrade le produit n’est pas un ROI. À lire aussi Coût par tâche réussie Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Comparer les prix des fournisseurs IA · FinOps LLM URL: https://finopsllm.com/fr/research/provider-prices-not-comparable Prix des fournisseurs IA non comparables Mis à jour August 27, 2026 · première publication August 27, 2026 Réponse rapide: Comparer le prix affiché par million de tokens crée de fausses économies. Les unités, remises et qualités diffèrent. Comparez le coût effectif par tâche réussie sur la même charge et le même seuil de... Comparer le prix affiché par million de tokens crée de fausses économies. Les unités, remises et qualités diffèrent. Comparez le coût effectif par tâche réussie sur la même charge et le même seuil de qualité. Normaliser la facture Indexez la grille par fournisseur, modèle, région, type de token, cache, batch et date. Séparez entrée, sortie, cache, raisonnement, image, audio et outils. Normaliser la charge Rejouez les mêmes prompts, contextes et tests de réussite. Mesurez latence p50/p95, réussite, reprises, réparation humaine et qualité. Ajouter le coût d’exploitation Incluez passerelle, observabilité, routage, évaluation et support. Routez vers le fournisseur le moins cher qui respecte qualité et coût effectif. À lire aussi Arbitrage entre fournisseurs LLM Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Les rate limits contrôlent le coût · FinOps LLM URL: https://finopsllm.com/fr/research/rate-limits-are-cost-control Rate limits, 429 et montées de palier Mis à jour September 1, 2026 · première publication September 1, 2026 Réponse rapide: Quand un service renvoie des 429, le réflexe est d’y voir un incident de disponibilité : relever la limite, monter de palier, ajouter des reprises. Parfois c’est juste. C’est aussi le mécanisme par... Quand un service renvoie des 429, le réflexe est d’y voir un incident de disponibilité : relever la limite, monter de palier, ajouter des reprises. Parfois c’est juste. C’est aussi le mécanisme par lequel une boucle emballée devient une facture à cinq chiffres, puisqu’on vient de retirer la seule chose qui la retenait. Ce que dit vraiment un 429 Que le système tente de dépenser plus vite que son allocation. Pour deux raisons opposées : croissance réelle de la demande, où la limite est trop basse ; ou emballement — tempête de reprises, agent en boucle, backfill non bridé — où la limite fait exactement son travail. Le taux d’erreur ne les distingue pas. Le coût par tâche accomplie, si : la croissance réelle garde ce ratio stable, l’emballement le casse. Utilisez les limites délibérément Fixez vos propres limites sous celles du fournisseur, par environnement et par fonctionnalité. Plafonnez durement le hors-production. Alertez sur le coût par tâche, pas seulement sur les erreurs. À lire aussi Dépense cachée des reprises Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Ré-embedder son corpus est récurrent · FinOps LLM URL: https://finopsllm.com/fr/research/re-embedding-is-recurring Le coût récurrent des embeddings et du vector store Mis à jour September 1, 2026 · première publication September 1, 2026 Réponse rapide: Le coût des embeddings est approuvé comme une ligne de projet : quelques millions de documents, un run unique, un chiffre modeste à côté de la génération. Puis cela ne s’arrête jamais, car trois... Le coût des embeddings est approuvé comme une ligne de projet : quelques millions de documents, un run unique, un chiffre modeste à côté de la génération. Puis cela ne s’arrête jamais, car trois forces distinctes ré-embeddent ce que vous avez déjà payé. Les trois moteurs de rafraîchissement Le churn de contenu : le plus honnête et le plus petit, il suit l’activité et se prévoit bien. Les changements de chunking ou de pipeline : le sournois. Tout ajustement de taille de chunk, de recouvrement ou de prétraitement invalide tous les vecteurs. Une expérience de qualité de recherche qui ressemble à un réglage de config est un ré-embedding complet. Les changements de modèle : le gros. Les espaces d’embedding ne sont pas compatibles entre modèles : pas de migration partielle, deux stores en parallèle ou une coupure. Budgétez-le comme une annuité Prévoyez au moins un ré-embedding complet par an. Évaluez un modèle sur le coût de ré-embedding plus un an de stockage et de requêtes , pas sur le prix par token. Et passez ces jobs en batch : c’est votre charge la plus tolérante à la latence. À lire aussi Optimisation des coûts RAG Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Coût réel par tâche : Opus 5.5 vs Sol, Astra et Fable · FinOps LLM URL: https://finopsllm.com/fr/research/real-cost-per-task-frontier-models Coût réel par tâche des modèles de pointe Mis à jour September 22, 2026 · première publication September 22, 2026 Les prix catalogue indiquent le coût d'un token. Ils n'indiquent pas le coût d'une tâche terminée, car les modèles dépensent des quantités de tokens très différentes pour le même travail. Cette page met côte à côte le coût par tâche mesuré et un score de qualité pour Claude Opus 5.5, Claude Opus 5, Claude Fable 5.1, GPT-6 Astra et GPT-6 Sol à chaque niveau d'effort. Chaque chiffre a une source, et rien n'est estimé. La réponse courte : GPT-6 Sol est le moyen le moins cher d'atteindre n'importe quel score jusqu'à 47,5. Au-delà de 47,5, Opus 5.5 est le moins cher à chaque niveau. Aucun réglage de GPT-6 Astra au-dessus de low, d'Opus 5 ou de Fable 5.1 n'est rentable : chacun est battu en score et en prix par un réglage de Sol ou d'Opus 5.5. Méthode Tous les scores et coûts proviennent de l' Artificial Analysis Intelligence Index v4.3.2, consulté le 22 septembre 2026. L'indice exécute dix évaluations : AA-Briefcase, GDPval-AA, AutomationBench-AA, Terminal-Bench 4.0, SciCode, Humanity's Last Exam, GDP.pdf, CritPt, AA-Omniscience et AA-LCR. Artificial Analysis exécute chaque modèle à chaque niveau d'effort via l'API du fournisseur et enregistre ce qu'il paie au prix catalogue. Le coût par tâche est cette dépense par tâche, répartie entre entrée et sortie. Toutes les lignes passent la même suite, elles se comparent donc directement. Deux limites avant de lire les chiffres. D'abord, l'indice est un seul mélange de tâches. Votre mélange déplacera les coûts, d'où la dernière section qui explique comment mesurer les vôtres. Ensuite, les scores de versions différentes de l'indice ne se comparent pas : ne mélangez pas ces chiffres avec des résultats publiés plus tôt. L'échelle complète : 26 réglages Les tokens de sortie par tâche sont ceux que le modèle écrit, raisonnement compris. Artificial Analysis ne publie pas la répartition entrée/sortie pour les quatre réglages intermédiaires de GPT-6 Sol ; ces cellules indiquent donc n/a. Modèle Effort Intelligence Index Coût par tâche Coût d'entrée Coût de sortie Tokens de sortie par tâche Sur la frontière GPT-6 Sol none 28.1 $0.33 $0.28 $0.05 4,900 Non GPT-6 Sol low 33.9 $0.13 n/a n/a 3,400 Oui GPT-6 Sol medium (par défaut) 39.8 $0.25 n/a n/a 6,500 Oui GPT-6 Sol high 42.8 $0.37 n/a n/a 10,200 Oui GPT-6 Sol xhigh 44.1 $0.53 n/a n/a 16,000 Oui GPT-6 Sol max 47.5 $1.06 $0.74 $0.31 31,200 Oui GPT-6 Astra low 45.8 $0.82 $0.60 $0.22 4,400 Oui GPT-6 Astra medium 49.6 $1.54 $1.06 $0.48 9,600 Non GPT-6 Astra high 50.9 $1.73 $1.13 $0.59 11,800 Non GPT-6 Astra xhigh 52.4 $2.31 $1.46 $0.85 16,900 Non GPT-6 Astra max 52.7 $3.26 $1.90 $1.36 27,200 Non Claude Opus 5 low 39.4 $1.10 $0.73 $0.37 14,700 Non Claude Opus 5 medium 44.8 $2.19 $1.47 $0.72 29,000 Non Claude Opus 5 high (par défaut) 48.1 $3.61 $2.46 $1.16 46,200 Non Claude Opus 5 xhigh 49.7 $4.88 $3.36 $1.52 60,700 Non Claude Opus 5 max 50.8 $5.86 $4.05 $1.81 72,500 Non Claude Opus 5.5 low 42.3 $0.55 $0.35 $0.20 10,200 Non Claude Opus 5.5 medium (par défaut) 51.2 $1.34 $0.82 $0.51 25,700 Oui Claude Opus 5.5 high 53.6 $1.82 $1.11 $0.71 35,600 Oui Claude Opus 5.5 xhigh 56.0 $3.46 $2.15 $1.31 65,700 Oui Claude Opus 5.5 max 57.6 $5.98 $3.60 $2.38 119,200 Oui Claude Fable 5.1 low 46.8 $2.37 $1.30 $1.08 21,600 Non Claude Fable 5.1 medium 48.9 $2.98 $1.59 $1.39 27,900 Non Claude Fable 5.1 high 51.2 $3.91 $2.01 $1.90 38,100 Non Claude Fable 5.1 xhigh 53.2 $5.98 $2.96 $3.02 60,500 Non Claude Fable 5.1 max 53.4 $7.63 $3.73 $3.90 78,100 Non Sur la frontière signifie qu'aucun autre réglage de ce tableau n'obtient un meilleur score pour moins cher. La frontière des coûts Dix des 26 réglages sont sur la frontière. Triés par coût, ce sont les seuls qui méritent d'être envisagés sur le seul critère du prix. Tous les autres paient plus pour un score égal ou inférieur. Réglage Intelligence Index Coût par tâche Pour 10 000 tâches GPT-6 Sol · low 33.9 $0.13 $1,300 GPT-6 Sol · medium 39.8 $0.25 $2,500 GPT-6 Sol · high 42.8 $0.37 $3,700 GPT-6 Sol · xhigh 44.1 $0.53 $5,300 GPT-6 Astra · low 45.8 $0.82 $8,200 GPT-6 Sol · max 47.5 $1.06 $10,600 Claude Opus 5.5 · medium 51.2 $1.34 $13,400 Claude Opus 5.5 · high 53.6 $1.82 $18,200 Claude Opus 5.5 · xhigh 56.0 $3.46 $34,600 Claude Opus 5.5 · max 57.6 $5.98 $59,800 La frontière a deux zones. De 0,13 $ à 1,06 $, c'est presque uniquement GPT-6 Sol, avec GPT-6 Astra low comme seule exception à 0,82 $. À partir de 1,34 $, c'est uniquement Opus 5.5. Le saut entre les deux est faible : Opus 5.5 medium obtient 3,7 points de plus que Sol max pour 0,28 $ de plus par tâche. Face-à-face à score égal ou supérieur Chaque paire compare un réglage moins cher à un réglage plus cher qui obtient un score égal ou inférieur. Réglage moins cher Réglage plus cher Écart de score Économie Opus 5.5 medium: 51.2, $1.34 Opus 5 high: 48.1, $3.61 +3.1 pour Opus 5.5 63% Opus 5.5 medium: 51.2, $1.34 Opus 5 max: 50.8, $5.86 +0.4 pour Opus 5.5 77% Opus 5.5 medium: 51.2, $1.34 Fable 5.1 high: 51.2, $3.91 égalité 66% Opus 5.5 high: 53.6, $1.82 GPT-6 Astra max: 52.7, $3.26 +0.9 pour Opus 5.5 44% Opus 5.5 high: 53.6, $1.82 Fable 5.1 max: 53.4, $7.63 +0.2 pour Opus 5.5 76% GPT-6 Sol max: 47.5, $1.06 Opus 5 high: 48.1, $3.61 +0.6 pour Opus 5 71% La ligne Opus 5 concerne les équipes qui n'ont pas encore migré. Opus 5 tournait par défaut en effort high. Opus 5.5 tourne par défaut en medium et, à ce réglage, obtient 3,1 points de plus pour 63 % de moins par tâche. Anthropic annonce qu'Opus 5.5 est 40 % moins cher qu'Opus 5 ; l'écart mesuré sur cet indice est plus large que l'annonce. Où part l'argent : l'entrée, pas la sortie Pour tous les modèles, l'entrée représente entre la moitié et les trois quarts du coût par tâche. Pour Opus 5.5 medium, 0,82 $ sur 1,34 $ sont de l'entrée, soit 61 %. Pour GPT-6 Astra max c'est 58 %, pour GPT-6 Sol max 70 % et pour Fable 5.1 max 49 %. Les tâches d'agent renvoient leur contexte croissant à chaque étape : la dépense d'entrée croît avec le nombre d'étapes, pas seulement avec la longueur de la réponse. C'est pourquoi GPT-6 Sol sans raisonnement coûte plus cher qu'en low : 0,33 $ contre 0,13 $, alors qu'il n'écrit que 4 900 tokens de sortie. 0,28 $ sur les 0,33 $ sont de l'entrée. La cause probable : plus d'étapes, chacune renvoyant le contexte. Couper le raisonnement ne rend pas un agent moins cher s'il lui faut ensuite plus de tours. Pour votre facture, le cache compte donc autant que le choix du modèle. Opus 5.5 et GPT-6 Sol facturent 0,20 $ par million de tokens d'entrée en cache. GPT-6 Astra facture 1,00 $ et Opus 5 0,50 $. Volume de tokens contre prix catalogue GPT-6 Astra est le modèle le plus économe en tokens de cette liste. En effort max, il écrit 27 200 tokens de sortie par tâche, contre 119 200 pour Opus 5.5 max. Mais Astra facture 10 $ et 50 $ par million, 2,5× le tarif d'Opus 5.5. Le prix catalogue l'emporte : Opus 5.5 high coûte 1,82 $ par tâche pour un score de 53,6, alors qu'Astra max coûte 3,26 $ pour 52,7. Opus 5.5 max est le seul cas où la verbosité coûte cher. Ses 119 200 tokens de sortie coûtent 2,38 $ avant toute entrée, et la tâche complète 5,98 $. Cela achète le meilleur score du tableau, 57,6, mais pour 4,5× le coût de medium. Rendements décroissants par effort Chaque ligne montre ce qu'apporte un cran d'effort supplémentaire, en points d'indice contre le surcoût par tâche. Modèle medium → high xhigh → max GPT-6 Sol +3.0 points pour +48% +3.4 points pour +100% GPT-6 Astra +1.3 points pour +12% +0.3 points pour +41% Claude Opus 5 +3.3 points pour +65% +1.1 points pour +20% Claude Opus 5.5 +2.4 points pour +36% +1.6 points pour +73% Claude Fable 5.1 +2.3 points pour +31% +0.2 points pour +28% Pour Fable 5.1 et GPT-6 Astra, l'effort max n'apporte presque rien : 0,2 et 0,3 point pour 28 % et 41 % de plus. Pour Opus 5.5, passer à max apporte encore 1,6 point, mais pour 73 % de plus. N'utilisez max que sur les tâches où vous avez mesuré que ces points changent le résultat. Quand GPT-6 Sol max suffit L'indice est une moyenne, et l'écart entre Sol max et Opus 5.5 medium n'est pas uniforme. Scores par évaluation selon Artificial Analysis : Évaluation Opus 5.5 medium ($1.34) GPT-6 Sol max ($1.06) Terminal-Bench 4.0 52.5 43.9 AutomationBench-AA 61.2 61.6 GDPval-AA (Elo) 1576 1487 AA-Briefcase (Elo) 1642 1483 Humanity's Last Exam 54.7 47.9 SciCode 59.3 57.6 CritPt 27.7 30.9 AA-LCR 84.3 83.7 Sur AutomationBench et CritPt, GPT-6 Sol égale ou bat Opus 5.5 medium pour 1,06 $ par tâche contre 1,34 $. Sur Terminal-Bench, les évaluations de travail intellectuel et Humanity's Last Exam, Opus 5.5 mène largement. L'automatisation de workflows peut tourner sur Sol. Les agents de terminal et de code et le travail intellectuel riche en documents sont là où Opus 5.5 justifie son prix. Chiffres du fournisseur contre chiffres indépendants Les chiffres des fournisseurs et les chiffres indépendants diffèrent souvent, car ils utilisent d'autres harnais et d'autres réglages. Anthropic annonce 66,4 % sur Terminal-Bench 4.0 pour Opus 5.5 en xhigh. Artificial Analysis mesure 59,6 % au même effort. Effort Opus 5.5 Fable 5.1 low 31.3% 40.4% medium 52.5% 44.9% high 56.6% 52.0% xhigh 59.6% 55.1% max 59.6% 52.0% Le classement change aussi selon l'indice. Sur le Vals AI Index, Fable 5.1 est premier avec 68,83 %, GPT-6 Astra troisième avec 66,61 % et Opus 5.5 quatrième avec 66,16 %. Le coût par tâche n'y est pas publié sur la même base, il ne déplace donc pas la frontière ci-dessus. Un indice n'est qu'un point de vue. Prix catalogue et une tâche riche en cache Digital Applied a chiffré une tâche d'agent riche en cache sur chaque modèle : 8M tokens de lecture de cache, 400K d'entrée hors cache, 600K d'écriture en cache et 300K de sortie. Le résultat suit la frontière, avec une pénalité supplémentaire pour GPT-6 Astra. Modèle Entrée $/MTok Sortie $/MTok Lecture de cache $/MTok Tâche riche en cache (Digital Applied) GPT-6 Sol $2.00 $10.00 $0.20 $6.90 Claude Opus 5.5 $4.00 $20.00 $0.20 $12.20 Claude Opus 5 $5.00 $25.00 $0.50 $17.25 Claude Fable 5.1 $10.00 $50.00 $0.25 $28.50 GPT-6 Astra (≤272K) $10.00 $50.00 $1.00 $34.50 GPT-6 Astra (>272K) $20.00 $75.00 n/a $61.50 GPT-6 Astra facture toute la requête à 20 $ et 75 $ par million dès que l'entrée dépasse 272K tokens. Opus 5.5 garde un prix unique sur toute sa fenêtre de 1M tokens. Chez Opus 5.5, l'écriture en cache coûte 5 $ par million pour le cache de 5 minutes et 8 $ pour celui d'une heure, les lots sont facturés à 50 % et le mode rapide double le prix. Pour le détail, voir Modèle de coûts de Claude Opus 5.5 et Économie du mode rapide d'Opus 5.5 . Mesurer votre propre coût par tâche Journalisez les tokens par tâche, pas par requête : entrée hors cache, entrée en cache, écritures en cache et sortie, additionnées sur toutes les étapes de la tâche. Prenez un échantillon de quelques centaines de tâches réelles et rejouez-le sur deux ou trois réglages candidats, par exemple Sol max, Opus 5.5 medium et Opus 5.5 high. Évaluez chaque résultat avec le même contrôle qu'en production et comptez les tâches réussies. Divisez la dépense totale par le nombre de tâches réussies. Le coût par tâche réussie est le chiffre à comparer : un réglage bon marché qui échoue plus souvent n'est pas bon marché. Choisissez le réglage le moins cher qui atteint votre seuil de qualité, puis envoyez seulement les tâches en échec vers un réglage supérieur. Relancez le test quand un prix ou un effort par défaut change. Pour voir comment l'effort change la facture d'un même modèle, voir Les niveaux d'effort d'Opus 5.5 sont le vrai prix . Réserves Tous les coûts sont au prix catalogue de l'API sur le mélange de tâches d'Artificial Analysis. Remises, traitement par lots et votre propre cache les modifient. Artificial Analysis marque ses entrées Opus 5.5 et Fable 5.1 comme Default Fallback. Lisez ses notes de méthodologie avant de traiter chaque ligne comme la même configuration d'API. Les scores viennent uniquement de la version v4.3.2 de l'indice. Les versions antérieures utilisaient d'autres évaluations et ne se comparent pas. La tâche riche en cache de Digital Applied est une charge illustrative, pas une mesure. Les chiffres changent quand les fournisseurs changent leurs prix ou leurs réglages par défaut. Date de consultation : 22 septembre 2026. Sources Artificial Analysis Intelligence Index Artificial Analysis: Claude Opus 5.5 Artificial Analysis: Claude Opus 5 Artificial Analysis: Claude Fable 5.1 Artificial Analysis: GPT-6 Astra Artificial Analysis: GPT-6 Sol Digital Applied: GPT-6 Sol vs Claude Opus 5.5 cost benchmarks Digital Applied: Claude Opus 5.5 vs GPT-6 Astra Digital Applied: Is Claude Fable 5.1 still worth it? Digital Applied: Claude Opus 5.5 launch pricing and benchmarks Digital Applied: Opus 5.5 vs Grok 4.7 vs Muse Spark 1.3 cost per task À lire aussi Modèle de coûts de Claude Opus 5.5 Les niveaux d'effort d'Opus 5.5 sont le vrai prix Économie du mode rapide d'Opus 5.5 Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Guide des Coûts des Modèles de Raisonnement · FinOps LLM URL: https://finopsllm.com/fr/research/reasoning-model-cost-guide Guide des Coûts des Modèles de Raisonnement Mise à jour 15 juillet 2026 · publié pour la première fois 4 juillet 2026 Les modèles de raisonnement comme o3, o4-mini, DeepSeek-R1, QwQ et MiMo génèrent des jetons de « pensée » internes avant de produire une sortie. Ce coût caché peut gonfler votre facture de 5 à 30 fois. Ce guide détaille quand les modèles de raisonnement valent la prime et quand un modèle standard est la dépense la plus intelligente. 5-30x Multiplicateur de coût 10 Modèles comparés 4 Fournisseurs Jul 2026 Dernière mise à jour Tous les prix en USD par 1 million de jetons Les décomptes de jetons de raisonnement varient selon la complexité de la tâche Les jetons de pensée sont facturés comme des jetons de sortie Qu'est-ce que les jetons de « pensée » ? Les modèles de raisonnement dépensent des jetons dans une chaîne de pensée interne avant de répondre. Une question simple peut déclencher 2 000 jetons de pensée ; une tâche de codage complexe peut en produire 30 000+. Ces jetons sont invisibles dans la réponse API mais facturés aux tarifs de sortie - souvent le niveau le plus cher. Méthodologie Tarification standard Prix du jeton de sortie pour l'achèvement standard (pas de raisonnement), provenant des pages officielles du fournisseur. Tarification du raisonnement Coût effectif incluant les jetons de pensée. Mesuré comme prix de sortie standard × multiplicateur de pensée moyen pour chaque modèle. Multiplicateur de pensée Rapport moyen des jetons totaux facturés aux jetons de sortie visibles entre les évaluations de codage, mathématiques et analyse. Meilleurs cas d'usage Tâches où les modèles de raisonnement démontrent une supériorité par rapport aux modèles standard suffisante pour justifier la prime de coût. Tableau de Tarification des Modèles de Raisonnement Modèle ↕ Fournisseur ↕ Sortie Standard $/1M ↕ Sortie Raisonnement $/1M ↕ Multiplicateur ↕ Meilleurs Cas d'Utilisation Claude Fable 5 Anthropic $50.00 $200.00 4x Raisonnement de pointe, vulnérabilités logicielles complexes, analyse approfondie Claude Opus 4.8 Anthropic $25.00 $100.00 4x Raisonnement de pointe, analyse complexe, flux agentiques GPT-5.6-Sol OpenAI $30.00 $120.00 4x Raisonnement de pointe, code complexe, mathématiques, analyse multi-étapes GPT-5.6-Terra OpenAI $15.00 $60.00 4x Raisonnement, génération de code, analyse structurée Grok 4.5 xAI $6.00 $24.00 4x Mathématiques, raisonnement, intelligence générale o3 OpenAI $8.00 $40.00 5x Codage complexe, preuves mathématiques, raisonnement profond o4-mini OpenAI $4.40 $17.60 4x Raisonnement sensible au coût, codage, analyse DeepSeek R1 DeepSeek $2.19 $8.76 4x Mathématiques, code, raisonnement, tâches en langue chinoise Claude Sonnet 5 Anthropic $10.00 $40.00 4x Raisonnement général, codage, analyse (équilibré) GPT-5.5 (standard) OpenAI $30.00 $30.00 1x Chat général, codage, analyse complexe Quand Utiliser les Modèles de Raisonnement 1) Codage et débogage multi-étapes Les modèles de raisonnement excellent dans les tâches nécessitant une planification : refactoriser plusieurs fichiers, déboguer un état complexe, ou écrire des algorithmes avec des cas limites. Les jetons de pensée permettent au modèle de « travailler » le problème plutôt que simplement adapter les motifs. La prime de 4-5x vaut le coup quand l'alternative est un humain qui passe 30+ minutes. 2) Preuves mathématiques et logiques Les tâches nécessitant un raisonnement formel - preuves, problèmes d'optimisation, satisfaction de contraintes - voient le plus grand saut de qualité. Les modèles standard produisent souvent des réponses plausibles mais incorrectes ; les modèles de raisonnement s'auto-vérifient. La prime de coût se justifie quand la correction importe plus que la vitesse. 3) Analyse de données complexe avec plusieurs étapes Analyser un ensemble de données avec une logique conditionnelle, des références croisées de plusieurs sources, ou la construction de pipelines multi-étapes bénéficie de la chaîne de pensée. Un modèle standard pourrait manquer une étape ; un modèle de raisonnement travaille à travers chacune explicitement. Quand Éviter les Modèles de Raisonnement 1) Extraction et formatage simples Extraire des données de documents, reformater JSON, résumer du texte, ou traduire du contenu. Ces tâches nécessitent l'adaptation de motifs, pas le raisonnement. Utiliser o3 pour l'extraction, c'est comme engager un mathématicien pour trier le courrier - coûteux et inutile. 2) Charges de travail à haut volume et basse complexité Génération de contenu, réponses FAQ, réponses basiques de chatbot, et étiquetage de données. À 10M+ jetons/mois, le multiplicateur de raisonnement de 4-5x s'accumule rapidement. Un modèle standard à $10/1M de sortie surpasse un modèle de raisonnement à $40-60/1M pour les tâches où la qualité est « suffisamment bonne ». 3) Applications sensibles à la latence Les modèles de raisonnement sont plus lents - les jetons de pensée ajoutent 2-10 secondes de latence. Pour le chat en temps réel, les outils interactifs, ou les réponses orientées vers l'utilisateur où la vitesse importe, les modèles standard livrent plus rapidement à moindre coût. Stratégies d'Optimisation des Coûts Routage par complexité Utilisez un modèle standard bon marché (GPT-4o-mini, Gemini Flash) comme routeur. Si la tâche est simple, répondez directement. Si elle est complexe, montez en escalier vers un modèle de raisonnement. Ce motif « en cascade » peut réduire l'utilisation des modèles de raisonnement de 60 à 80 % tout en préservant la qualité où elle compte. Limitez le budget de pensée Certains fournisseurs (OpenAI, Google) vous permettent de définir un budget maximal de jetons de pensée par requête. Limiter à 4 000-8 000 jetons de pensée prévient les coûts incontrôlés sur les tâches qui n'ont pas besoin d'un raisonnement profond. Commencez serré et augmentez seulement quand la qualité baisse. Mettez en cache vos prompts Si vos tâches de raisonnement partagent un prompt système commun ou un contexte (base de code, documentation), la mise en cache des prompts peut réduire les coûts d'entrée de 50-90 %. Cela ne réduit pas les jetons de pensée mais réduit considérablement le coût par requête. Traitez le raisonnement non urgent en lots Pour les évaluations, la génération de tests, ou l'analyse qui tolère la latence, les APIs batch offrent des réductions de 50 %. Combinées avec les modèles de raisonnement, vous obtenez l'avantage de qualité à la moitié du coût de sortie. Sortie de raisonnement $/1M inclut les jetons de pensée facturés aux tarifs de sortie. Le multiplicateur est moyen entre les tâches typiques ; le multiplicateur réel varie en fonction de la complexité de la requête. DeepSeek R1 produit les jetons de pensée par défaut. OpenAI o3/o4-mini facture les jetons de pensée séparément de la sortie visible. Gemini 2.5 Pro facture les « jetons de pensée » à un tarif réduit par rapport à la sortie visible - le multiplicateur est le coût blended effectif. Certains liens peuvent inclure des codes de parrainage. Vous voulez cela appliqué à vos propres dépenses en LLM ? FinOps LLM effectue un audit gratuit de vos coûts d'IA et montre où se trouvent les économies. Réservez un audit gratuit → Retour à la recherche FAQ Qu'est-ce que la méthodologie ? Prix du jeton de sortie pour l'achèvement standard (pas de raisonnement), provenant des pages officielles du fournisseur. Prix du raisonnement : coût effectif incluant les jetons de pensée. Mesuré comme prix de sortie standard × multiplicateur de pensée moyen pour chaque modèle. Qu'est-ce que le tableau de tarification des modèles de raisonnement ? Sortie de raisonnement $/1M inclut les jetons de pensée facturés aux tarifs de sortie. Le multiplicateur est moyen entre les tâches typiques ; le multiplicateur réel varie en fonction de la complexité de la requête. DeepSeek R1 produit les jetons de pensée par défaut. OpenAI o3/o4-mini facture les jetons de pensée séparément de la sortie visible. Quand utiliser les modèles de raisonnement ? Les modèles de raisonnement excellent dans les tâches nécessitant une planification : refactoriser plusieurs fichiers, déboguer un état complexe, ou écrire des algorithmes avec des cas limites. Les jetons de pensée permettent au modèle de « travailler » le problème plutôt que simplement adapter les motifs. Quand éviter les modèles de raisonnement ? Extraire des données de documents, reformater JSON, résumer du texte, ou traduire du contenu. Ces tâches nécessitent l'adaptation de motifs, pas le raisonnement. Utiliser o3 pour l'extraction, c'est comme engager un mathématicien pour trier le courrier - coûteux et inutile. Qu'est-ce que les stratégies d'optimisation des coûts ? Utiliser un modèle standard bon marché (GPT-4o-mini, Gemini Flash) comme routeur. Si la tâche est simple, répondre directement. Si elle est complexe, monter en escalier vers un modèle de raisonnement. Ce motif « en cascade » peut réduire l'utilisation des modèles de raisonnement de 60 à 80 % tout en préservant la qualité où elle compte. --- # Le même modèle coûte plus dans votre région · FinOps LLM URL: https://finopsllm.com/fr/research/regional-pricing-premium Surcoût régional et résidence des données Mis à jour September 1, 2026 · première publication September 1, 2026 Réponse rapide: Le tarif qui a servi à votre budget est en général le tarif américain. Routez la même requête via un endpoint européen ou asiatique, ou épinglez-la à une région pour raison de résidence, et le chiffre... Le tarif qui a servi à votre budget est en général le tarif américain. Routez la même requête via un endpoint européen ou asiatique, ou épinglez-la à une région pour raison de résidence, et le chiffre change — parfois sur le prix du token, plus souvent sur tout ce qui l’entoure. D’où vient le surcoût De quatre endroits à la fois. Le prix régional , qui diffère selon les plateformes. La disponibilité des modèles , en retard hors région primaire. L’egress et la latence inter-région. Et surtout une couverture fonctionnelle réduite : sans cache de prompts ni tarif batch dans cette région, vous perdez des remises que vous aviez tenues pour acquises. C’est ce dernier point qui fait mal : une charge conçue autour du cache et du batch, déplacée dans une région qui en est privée, ne coûte pas quelques pour cent de plus — elle coûte ce qu’elle aurait coûté sans aucune optimisation. Décidez-le, n’en héritez pas La résidence est souvent une obligation réelle ; le surcoût est alors le prix d’une exploitation légale. L’erreur est de le payer pour des charges qui n’en avaient pas besoin. Séparez le trafic selon la nature de la donnée : le régulé va en région conforme, le reste va où c’est le moins cher. À lire aussi Attribution des coûts LLM Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Reprises et coût d’inférence · FinOps LLM URL: https://finopsllm.com/fr/research/retry-loop-hidden-spend Boucle de reprises et coût d’inférence Mis à jour August 27, 2026 · première publication August 27, 2026 Réponse rapide: Une reprise est un nouvel appel modèle, pas une résilience gratuite. Mesurez sa taxe: dépenses de reprises et bascules divisées par toute l’inférence.Tracer l’arbreConservez requête parente,... Une reprise est un nouvel appel modèle, pas une résilience gratuite. Mesurez sa taxe: dépenses de reprises et bascules divisées par toute l’inférence. Tracer l’arbre Conservez requête parente, tentative, fournisseur, modèle, outil, erreur, tokens et résultat. Les appels imbriqués doivent garder leur relation parent-enfant. Limiter la boucle Attribuez à chaque classe d’erreur un nombre maximal de tentatives, un plafond de tokens, un plafond financier et une durée maximale. Une erreur déterministe ne doit pas être rejouée sans changement. Ne supprimez pas toutes les reprises: rendez chaque tentative visible, bornée et justifiée par un meilleur résultat. À lire aussi Garde-fous de dépense des agents Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Crédits d’IA SaaS : mesurer et allouer · FinOps LLM URL: https://finopsllm.com/fr/research/saas-ai-credits-metering Crédits d’IA SaaS : mesurer une unité que vous ne contrôlez pas Mis à jour September 2, 2026 · première publication September 2, 2026 Réponse rapide: Le FinOps cloud suppose une unité lisible : une heure d’instance, une requête, un gigaoctet. Un crédit d’IA ne l’est pas : l’éditeur le définit, le tarife et peut le redéfinir en cours de... Le FinOps cloud suppose une unité lisible : une heure d’instance, une requête, un gigaoctet. Un crédit d’IA ne l’est pas : l’éditeur le définit, le tarife et peut le redéfinir en cours de contrat. Trois propriétés qui cassent la méthode L’unité est opaque : deux fonctionnalités consomment très différemment pour une action perçue comme identique. Le tarif ne vous appartient pas. Et les enveloppes expirent sans mutualisation ni report. Mesurez quand même Récupérez la consommation via l’API d’administration de façon planifiée et stockez-la avec vos données de coût, par utilisateur, équipe et fonctionnalité. Le tableau de bord éditeur montre la période courante ; vos questions portent sur la tendance. Allouez avant la facture Rattachez les crédits aux centres de coût utilisés pour le cloud et publiez un showback mensuel. Une dépense non allouée retombe sur le budget plateforme, l’équipe la moins à même d’agir sur la consommation. Plafonnez, sinon alertez Privilégiez un plafond administratif dans la console de l’éditeur : c’est le seul contrôle qui arrête la dépense avant qu’elle survienne. À défaut, alertez sur votre propre mesure avec une marge d’action. À lire aussi IA fantôme sur cartes d’entreprise Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Les outils serveur facturent hors compteur · FinOps LLM URL: https://finopsllm.com/fr/research/server-tools-are-a-separate-invoice Les outils serveur sont une facture à part Mis à jour September 1, 2026 · première publication September 1, 2026 Réponse rapide: La plupart des modèles de coût LLM n’ont qu’un compteur : tokens en entrée, tokens en sortie, prix au million. C’était exact tant qu’une requête ne faisait que générer du texte. Ça a cessé de l’être... La plupart des modèles de coût LLM n’ont qu’un compteur : tokens en entrée, tokens en sortie, prix au million. C’était exact tant qu’une requête ne faisait que générer du texte. Ça a cessé de l’être avec les outils côté serveur. La recherche web, le fetch et l’exécution de code tournent sur l’infrastructure du fournisseur, et plusieurs portent leur propre frais à l’usage en plus des tokens qu’ils produisent. Un tour d’agent peut donc vous facturer deux fois. La partie qui se cumule C’est le second coût qu’on oublie. Chaque résultat d’outil est ajouté à la conversation, et chaque tour suivant renvoie l’ensemble en entrée. Dix recherches en début d’exécution, ce n’est pas dix frais : c’est dix frais plus leurs charges utiles relues à chaque tour suivant. D’où des coûts d’agent qui semblent non linéaires alors que l’arithmétique des tokens les dit linéaires. Le frais à l’usage est la partie visible ; la croissance du contexte est la plus grosse, et elle atterrit dans votre ligne de tokens d’entrée sans étiquette. Attribuez, sinon vous ne pilotez rien Journalisez les appels d’outils par requête à côté de l’objet d’usage : quel outil, combien d’appels, et la taille en tokens de ce que chaque résultat a ajouté. Ce dernier champ rend le cumul visible. Calculez ensuite le coût par exécution d’agent, pas par appel d’API. Trois contrôles efficaces Plafonnez les appels d’outils par exécution : cela borne les deux coûts d’un coup. Tronquez ce qui entre dans le contexte : résumer un résultat avant de l’ajouter allège tous les tours suivants. Mettez en cache le préfixe stable : prompt système et définitions d’outils sont constants, le cache supprime le plus gros coût répété. À lire aussi Économie du cache de prompts Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # L’IA fantôme est sur une carte pro · FinOps LLM URL: https://finopsllm.com/fr/research/shadow-ai-corporate-cards La dépense IA hors de votre facture d’API Mis à jour September 1, 2026 · première publication September 1, 2026 Réponse rapide: La plupart des organisations mesurent le coût de l’IA en ouvrant la console du fournisseur. Ce chiffre est réel et bien instrumenté — et dans beaucoup d’entreprises, c’est la petite moitié du... La plupart des organisations mesurent le coût de l’IA en ouvrant la console du fournisseur. Ce chiffre est réel et bien instrumenté — et dans beaucoup d’entreprises, c’est la petite moitié du total. L’autre moitié est en notes de frais : des abonnements individuels pris par des gens qui avaient besoin d’un outil et d’une carte. Pourquoi c’est invisible Cela ne touche jamais vos clés d’API, votre gateway ni votre télémétrie. Cela arrive comme une charge par siège, à des montants assez faibles pour passer l’approbation automatiquement. Deux cents personnes à vingt ou trente dollars par mois, c’est une ligne annuelle à six chiffres qu’aucun tableau de bord technique n’affichera. Ce que cela coûte vraiment Le surcoût direct est le moins intéressant. Les plans individuels sont bien au-dessus des tarifs négociés, et payer deux fois le même fournisseur est courant. Plus grave : les offres grand public ont d’autres conditions de rétention et d’entraînement que celles revues par votre juridique, il n’y a pas de SSO, et l’accès ne cesse pas avec le contrat de travail. Comment la trouver Demandez à la finance, pas à l’ingénierie. Cherchez les noms de fournisseurs puis le motif : charges mensuelles récurrentes de dix à cinquante dollars. Puis rendez la voie officielle plus simple que la carte, plutôt que d’interdire la carte. À lire aussi Attribution des coûts LLM Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Hausse Claude Sonnet 5 annulée : 2 $/10 $ permanent · FinOps LLM URL: https://finopsllm.com/fr/research/sonnet-5-intro-pricing-deadline Claude Sonnet 5 : la hausse de septembre a été annulée Publié le 19 juillet 2026 Correction, 2 septembre 2026 : la hausse que cet article préparait n'a pas eu lieu. Anthropic l'a annulée : Claude Sonnet 5 reste à 2 $/10 $ par million de jetons de façon permanente. L'analyse d'échéance ci-dessous est conservée telle que publiée, pour mémoire ; considérez chaque chiffre « après le 1er septembre » comme un scénario jamais entré en vigueur. Les tarifs actuels figurent dans le tracker de prix des API LLM . Anthropic a lancé Claude Sonnet 5 le 30 juin 2026 à des tarifs de lancement de $2/1M de tokens d'entrée et $10/1M de tokens de sortie. Ce prix a une date limite définitive : 31 août 2026 . À partir du 1er septembre, Sonnet 5 passe à des tarifs standards de $3/$15 par 1M, soit une augmentation de coûts de 50 % fixe . Si vous exécutez des charges de travail Sonnet 5, les 6 prochaines semaines constituent votre fenêtre pour bloquer les coûts et planifier l'augmentation. Tarifs de lancement valides jusqu'au 31 août 2026 uniquement Tarifs standards ($3/$15) commencent le 1er septembre 2026 L'augmentation de coûts est exactement 50 % pour les charges de travail Sonnet 5 S'applique à l'API Anthropic, Bedrock et Vertex AI 43 jours pour réévaluer, verrouiller les engagements et refaire les prévisions budgétaires Date limite critique : Les tarifs de lancement de Claude Sonnet 5 expirent dans 43 jours (31 août 2026). Une charge de travail de 10M tokens/mois passera de $20 à $30/mois. Une charge de travail de 1B tokens/mois passera de $2 000 à $3 000. Si Sonnet 5 est dans votre chemin critique, budgétez la hausse maintenant ou déplacez les charges de travail avant le changement. Les Mathématiques : Qu'Signifie 50 % à l'Échelle Le saut de tarifs de lancement à standards est net et significatif. Modélisons une charge de travail réaliste : Profil de Charge de Travail Tokens d'Entrée Mensuels Tokens de Sortie Mensuels Coût Août (Intéducteur) Coût Septembre (Standard) Variation Mensuelle Impact Annuel Légère (lot/interne) 50M 20M $200 $300 +$100 +$1 200 Niveau intermédiaire (orientée client) 500M 150M $2 500 $3 750 +$1 250 +$15 000 Entreprise (raisonnement haut volume) 2B 800M $12 000 $18 000 +$6 000 +$72 000 Lourde (flux multi-requêtes) 5B 2,5B $35 000 $52 500 +$17 500 +$210 000 Point clé : Une entreprise avec une charge de travail Sonnet 5 de niveau intermédiaire (500M entrée + 150M tokens de sortie/mois) verrait une augmentation mensuelle de $1 250 qui se compose à $15 000 annuels si rien ne change. Pour les charges de travail d'entreprise, l'impact annuel peut dépasser $70K. Qui Est Affecté La date limite s'applique sur tous les canaux : API Anthropic (directe) Les tarifs de lancement se terminent le 31 août 2026 à 23 h 59 UTC. Vérifiés dans la documentation de tarification d'Anthropic . Aucune prolongation ou délai n'a été annoncé. AWS Bedrock Bedrock répercute les tarifs d'Anthropic. Les tarifs de lancement s'appliquent à Sonnet 5 sur Bedrock jusqu'au 31 août. L'augmentation apparaîtra dans votre facture Bedrock le 1er septembre. Vérifiez votre contrat AWS pour tout rabais sur engagement qui pourrait compenser l'augmentation. Google Vertex AI Vertex AI intègre les modèles Claude avec répercussion de tarifs d'Anthropic. La transition se produit le 1er septembre. Les factures Vertex sont cotées dans votre devise locale ; confirmez la date exacte auprès de votre équipe de compte Google si vous utilisez un fuseau horaire différent. GitHub Copilot Enterprise Si Copilot utilise Sonnet 5 comme backend, Microsoft peut ou non répercuter l'augmentation de prix sur votre plan. Copilot Enterprise est une licence de siège fixe, donc l'impact dépend du fait que Microsoft absorbe ou reflète le coût du backend. Vérifiez votre facture Copilot ou contactez votre équipe de compte Microsoft. Trois Stratégies : Qu'Faire Avant le 31 Août Stratégie 1 : Verrouillez les Engagements d'Utilisation (S'Ils Sont Disponibles) Vérifiez si Anthropic propose des engagements d'utilisation ou des rabais sur volume pour Sonnet 5. Les rabais basés sur le volume ou les accords de prépaiement annuel pourraient réduire l'augmentation de prix effective. Contactez les ventes d'Anthropic maintenant : elles pourraient maintenir les tarifs de lancement sur les engagements signés avant le 31 août. Action : Envoyez un email aux ventes d'Anthropic avant le 15 août si vous dépensez >$5K/mois sur Sonnet 5. Demandez si un engagement annuel verrouille les tarifs de lancement ou offre des rabais échelonnés. Le délai d'attente pour les contrats d'engagement est généralement de 2 à 3 semaines. Stratégie 2 : Réévaluez le Routage et le Mélange de Modèles Pas toutes les charges de travail ont besoin de Sonnet 5. Le saut de prix de 50 % est un facteur forçant pour auditer quelles tâches nécessitent vraiment Sonnet 5 et lesquelles peuvent basculer vers des alternatives moins chères. Catégorie de Tâche Sonnet 5 Entrée/$1M Modèle Alternatif Prix Alt Entrée/$1M Économies pour 100M Tokens Quand Basculer Classification (règles strictes) $3 (après sep 1) Claude Haiku 4.5 $1,00 $200 Précision ≥95 % Résumé $3 Gemini 2.5 Flash $0,15 $285 Pas de raisonnement nécessaire Conversation multi-tour $3 GPT-5.6 Luna $1,00 $200 Qualité équivalente Raisonnement complexe (gardez Sonnet 5) $3 — — — Pas d'alternative Boucles agentiques (multi-étapes) $3 Hybride Haiku + Sonnet 5 $1,00 (Haiku) + $3 (Sonnet 5) Économiser en utilisant Haiku pour les étapes simples Benchmarks soutiennent Action : Au cours des 2 prochaines semaines, extrayez vos journaux d'appels Sonnet 5 et catégorisez par charge de travail. Comparez 10 % des tâches de classification sur Haiku, résumé sur Gemini 2.5 Flash, et multi-tour simple sur GPT-5.6 Luna. Si la qualité est équivalente (ou proche), déplacez cette charge de travail avant le 1er septembre et verrouillez les économies. Stratégie 3 : Implémentez (ou Étendez) la Mise en Cache des Invites La mise en cache des invites est le moyen le plus direct de réduire la consommation de tokens et de préserver la valeur des tarifs de lancement avant qu'ils n'expirent. Les écritures de cache vers Sonnet 5 coûtent $2,50 par 1M de tokens (1,25× le prix d'entrée de lancement ; sera $3,75 en standard). Les lectures de cache coûtent $0,20 par 1M (0,1× le prix d'entrée de lancement ; sera $0,30 en standard). L'opportunité : Une charge de travail avec un taux de succès du cache de 40 % économise 36 % sur le coût d'entrée. Verrouiller l'infrastructure de cache maintenant à tarifs de lancement signifie que vos économies de taux de succès du cache en cours sont héritées. Après le 1er septembre, les mêmes succès de cache sont encore 90 % de réduction, mais le prix de base qu'ils réduisent est 50 % plus élevé. Exemple : Invite système + contexte mis en cache 100M tokens/mois sur Sonnet 5 : Août (tarif de lancement) : Coût d'écriture : 100M × $2,50/M = $250. Coût de lecture mensuel (supposons 1B de tokens de lecture à partir des succès du cache) : 1B × $0,20/M = $200. Total : $450/mois pour la mise en cache. Septembre (standard) : Coût d'écriture : 100M × $3,75/M = $375. Coût de lecture mensuel : 1B × $0,30/M = $300. Total : $675/mois (50 % plus élevé). Économies de mise en cache maintenant : Si vous ajoutez 500M de tokens d'entrée mis en cache entre maintenant et le 31 août, et qu'ils s'accumulent 30 succès de cache chaque mois à partir de septembre, vous verrouillez les remises de lecture cumulées. Le coût d'écriture du cache est un investissement qui se rembourse sur des mois. Action : Identifiez vos 3 invites les plus répétées ou contextes de documents (documents RAG, instructions système, modèles). Testez la mise en cache sur l'API Anthropic. Si le taux de succès est ≥20 %, implémentez avant le 31 août. Les écritures de cache sont le seul coût qui ne dépend pas du moment où se produit la hausse de tarif : investir dans le coût d'écriture maintenant produit des rendements de coûts de lecture fixes pour toujours. Chronologie : Le Compte à Rebours de 6 Semaines Semaine 1 (avant le 25 juillet) Auditez les dépenses actuelles de Sonnet 5. Extrayez les journaux d'appels (modèle, tokens, type de charge de travail) de votre tableau de bord de facturation ou plateforme d'observabilité LLM. Calculez le taux d'exécution mensuel. Modélisez les dépenses Q4 si rien ne change. Semaine 2 (avant le 1er août) Contactez les ventes d'Anthropic pour enquêter sur les engagements d'utilisation. Commencez à comparer les modèles alternatifs (Haiku, Luna, Gemini 2.5 Flash) sur 10 % du trafic de production. Identifiez les 3 premiers candidats pour le changement de routage. Semaine 3 (avant le 8 août) Finalisez les benchmarks et engagez-vous dans un plan de routage. Si des changements sont nécessaires, commencez à déployer des tests A/B. Implémentez la mise en cache des invites pour les contextes répétés haut volume. Cible ≥100M tokens mis en cache avant le changement. Semaine 4 (avant le 15 août) Verrouillez les engagements d'utilisation avec Anthropic (si applicable). Déployez les changements de routage à la production (déplacez les tâches à faible raisonnement vers des modèles moins chers). Vérifiez que l'infrastructure de cache est active et réalise 15 %+ de taux de succès. Semaine 5 (avant le 22 août) Surveillez les coûts de production et les métriques de qualité. Ajustez le routage si nécessaire. Prévoyez les coûts finaux de septembre en fonction du taux d'exécution d'août. Semaine 6 (avant le 31 août) Confirmez que tous les changements de routage sont actifs. Définissez une alerte de calendrier pour le 5 septembre pour vérifier que la facturation correspond à la prévision. Publiez une analyse post-mortem sur l'impact des coûts et les économies réalisées. Comparaison : Sonnet 5 vs. Alternatives Après le 1er Septembre Une fois les tarifs de lancement expirés, comment Sonnet 5 se compare-t-il à d'autres modèles à leurs tarifs standards ? Modèle Fournisseur Entrée $/1M Sortie $/1M Cas d'Utilisation Typique vs. Sonnet 5 Après Sep 1 Claude Sonnet 5 (standard) Anthropic $3,00 $15,00 Équilibre de vitesse et raisonnement Ligne de base GPT-5.6 Terra OpenAI $2,50 $15,00 Raisonnement niveau intermédiaire 17 % moins cher en entrée GPT-5.6 Luna OpenAI $1,00 $6,00 Classification rapide, tâches simples 67 % moins cher au total Gemini 3.1 Pro Google $2,00 $12,00 Boucles agentiques, utilisation d'outils 33 % moins cher en entrée Gemini 2.5 Flash Google $0,15 $0,60 Ultra-rapide, haut volume 95 % moins cher Claude Haiku 4.5 Anthropic $1,00 $5,00 Classification faible latence 67 % moins cher en entrée DeepSeek V4 Flash DeepSeek $0,14 $0,28 Optimisé pour le coût, modèle ouvert 95 % moins cher (mais moins raffiné) La réalité : Sonnet 5 à $3/$15 n'est plus le modèle le moins cher ou le plus rentable pour la plupart des tâches. GPT-5.6 Terra est 17 % moins cher en entrée. Haiku est 67 % moins cher pour la classification. La valeur de Sonnet 5 après l'augmentation est en qualité pour le raisonnement complexe et en vitesse pour les tâches équilibrées, pas dans le leadership des coûts. Les charges de travail qui ne nécessitent pas cette qualité devraient basculer vers des alternatives dès maintenant. Questions Fréquemment Posées Q : Y a-t-il une chance que la date limite soit prolongée ? R : Anthropic n'a pas annoncé de prolongation. L' annonce de lancement du 30 juin indique clairement « jusqu'au 31 août 2026 ». Préparez-vous à la date limite. Si une prolongation est annoncée, c'est un bonus ; traitez la date limite comme définitive. Q : Le nouveau tokenizer affecte-t-il les décomptes de tokens ? R : Oui. Sonnet 5 utilise un nouveau tokenizer qui produit environ 30 % plus de tokens que les modèles Claude plus anciens pour un texte équivalent. Cela signifie que vos dépenses actuelles en tokens sont plus élevées que vous pourriez vous y attendre. Tenez compte de ceci dans les prévisions de coûts. Q : Puis-je verrouiller les tarifs de lancement avec un prépaiement annuel ? R : C'est possible, si Anthropic propose des options de prépaiement. Contactez les ventes avant le 15 août pour demander. Le prépaiement est souvent le seul moyen de hériter les tarifs lors d'une augmentation de tarif, mais vous devez vous engager bien à l'avance. Q : Et si j'ai un contrat personnalisé avec Anthropic ? R : Les contrats personnalisés peuvent avoir des conditions différentes. Vérifiez la date et le tarif de transition exacts auprès de votre équipe de compte. Si votre contrat spécifie les conditions de tarification, elles ont la priorité sur la page de tarification publique : confirmez dès maintenant avant que le 1er septembre ne vous surprenne. La date limite du 31 août est réelle, l'augmentation de 50 % est certaine, et vous avez 6 semaines pour agir. Les équipes qui réévaluent, verrouillent les engagements et déplacent les charges de travail avant le changement réduiront considérablement leurs dépenses LLM Q4. Les équipes qui attendent le 1er septembre absorberont l'augmentation de coûts complète. Retour à la recherche FAQ Les tarifs de lancement de Claude Sonnet 5 ont-ils pris fin le 31 août 2026 ? Non. Anthropic a annulé la hausse prévue. Claude Sonnet 5 reste durablement à 2 $ par million de jetons d'entrée et 10 $ par million en sortie ; le tarif standard de 3 $/15 $ prévu au 1er septembre 2026 n'est jamais entré en vigueur. De combien augmentera ma facture ? Exactement 50 % pour les charges de travail Claude Sonnet 5. Les tarifs d'entrée augmentent de $2 à $3 par 1M de tokens (+50 %), et la sortie augmente de $10 à $15 par 1M de tokens (+50 %). Une charge de travail coûtant $10 000 par mois en août coûtera $15 000 par mois en septembre si elle ne change pas. Les tarifs de lancement s'appliquent-ils à Bedrock et Vertex ? Les tarifs de lancement s'appliquent à l'API Anthropic directe. AWS Bedrock et Google Vertex AI répercutent les tarifs d'Anthropic, donc la hausse s'applique également à partir du 1er septembre. Vérifiez les conditions de votre contrat avec votre fournisseur de cloud. Que dois-je faire avant le 31 août ? 1) Verrouillez les engagements d'utilisation s'ils sont disponibles. 2) Réévaluez le routage vers Sonnet 5 par rapport aux modèles moins chers (Haiku, Gemini 2.5 Flash). 3) Déplacez les invites répétées vers la mise en cache des invites (les remises de mise en cache s'échelonnent avec le prix de base, donc bloquer les économies de mise en cache maintenant est intéressant). 4) Définissez une alerte de calendrier pour le 25 août afin de tester les coûts après migration. 5) Modélisez la hausse dans votre budget Q3 dès maintenant. --- # Le modèle anonyme gratuit est une arme tarifaire · FinOps LLM URL: https://finopsllm.com/fr/research/stealth-model-free-tokens-playbook Le manuel du modèle furtif Mis à jour September 1, 2026 · première publication September 1, 2026 Réponse rapide: Ox Alpha est apparu sur les agrégateurs de routage : un endpoint sans marque, gratuit, sans grille tarifaire ni laboratoire identifié. Puis il a été confirmé comme étant GLM-5.3 et la fenêtre gratuite... Ox Alpha est apparu sur les agrégateurs de routage : un endpoint sans marque, gratuit, sans grille tarifaire ni laboratoire identifié. Puis il a été confirmé comme étant GLM-5.3 et la fenêtre gratuite s’est refermée. GLM-5.3-Flash est désormais affiché à 0,15 $ le million de tokens en entrée et 0,50 $ en sortie. Considérez-le comme une manœuvre reproductible, car c’en est une. Elle a déjà servi sous d’autres noms et resservira. Ce que le laboratoire achète avec des tokens gratuits Trois choses, toutes moins chères que les alternatives. Une évaluation à l’aveugle : un endpoint sans marque est jugé sur la sortie, pas sur le logo. De la distribution : les agrégateurs y envoient du trafic réel immédiatement, sans partenariat. Un point d’ancrage tarifaire : au moment de la révélation, les développeurs ont déjà jugé le modèle bon. Le chiffre qui compte à la fermeture Seize mille milliards de tokens en entrée sont passés par l’endpoint gratuit. À 0,15 $ le million, cela représente environ 2,4 millions de dollars d’inférence — c’est-à-dire la hauteur de la marche si ce trafic reste simplement où il est. Faites le calcul sur votre propre part : le volume envoyé pendant la fenêtre, multiplié par le tarif publié, donne votre variation mensuelle. Trois règles pour la prochaine fois Ne dépendez jamais d’un endpoint dont vous ignorez le propriétaire. Anonyme veut dire aucune grille tarifaire, aucune politique de dépréciation, aucun engagement sur les données. C’est bon pour évaluer, pas pour la production sans repli. Valorisez toute évaluation gratuite à un tarif hypothétique et portez ce coût fictif dans votre télémétrie. Supposez que la fenêtre gratuite est la partie la plus courte de la relation et mesurez aussi le coût de sortie, pas seulement la qualité. À lire aussi Arbitrage entre fournisseurs Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Le streaming abandonné continue de coûter de l'argent · FinOps LLM URL: https://finopsllm.com/fr/research/streaming-abandoned-generations-cost Streaming et coût des générations abandonnées Mis à jour September 9, 2026 · première publication September 9, 2026 Réponse rapide: Une déconnexion côté navigateur n'interrompt pas toujours la facturation chez le fournisseur d'API. Propagez le signal d'annulation au proxy LLM. Une déconnexion côté navigateur n'interrompt pas toujours la facturation chez le fournisseur d'API. Propagez le signal d'annulation au proxy LLM. À lire aussi Coût caché des boucles de retry Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # La sortie structurée n’est pas gratuite · FinOps LLM URL: https://finopsllm.com/fr/research/structured-output-token-cost Coût en tokens du mode JSON et des schémas Mis à jour September 1, 2026 · première publication September 1, 2026 Réponse rapide: Demander une sortie structurée ressemble à un choix de format. Sur la facture c’est un choix de volume, et il tombe à trois endroits à la fois.Le schéma est un coût d’entrée à chaque requêteLe schéma... Demander une sortie structurée ressemble à un choix de format. Sur la facture c’est un choix de volume, et il tombe à trois endroits à la fois. Le schéma est un coût d’entrée à chaque requête Le schéma est sérialisé dans la requête. Un schéma modeste fait quelques centaines de tokens — multipliez par chaque appel, chaque tour, pendant toute la vie de la fonctionnalité. 400 tokens sur un million d’appels, ce sont 400 millions de tokens d’entrée payés pour décrire une forme qui ne change jamais. Pire : placé après la partie volatile du prompt, le schéma casse le préfixe mis en cache et supprime la remise sur tout ce qui précède. La syntaxe est un coût de sortie Chaque accolade, guillemet, virgule et nom de champ est un token généré, facturé au tarif de sortie. Les noms verbeux deviennent une charge récurrente définitive. Les reprises coûtent le plus Chaque échec de validation coûte une reprise complète : toute l’entrée et toute la sortie à nouveau. 2% d’invalides, c’est 2% de coût en plus pour rien. Que faire Mettez le schéma dans le préfixe stable pour qu’il soit mis en cache, ne demandez que les champs consommés, préférez des noms courts et des structures plates, et mesurez votre taux d’échec de validation. À lire aussi Économie du cache de prompts Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Limiter la dérive des sous-agents et la consommation · FinOps LLM URL: https://finopsllm.com/fr/research/subagent-fan-out-concurrency-limits Limiter la dérive des sous-agents et la délégation récursive Mis à jour September 19, 2026 · première publication September 19, 2026 Réponse rapide: L'emballement des sous-agents se produit lorsqu'un orchestrateur décompose une tâche en plusieurs sous-tâches et autorise les agents exécutants à déléguer à leur tour. Sans limites strictes de... L'emballement des sous-agents se produit lorsqu'un orchestrateur décompose une tâche en plusieurs sous-tâches et autorise les agents exécutants à déléguer à leur tour. Sans limites strictes de profondeur et de concurrence, une requête peut lancer des dizaines de boucles d'agents en parallèle, brûlant des millions de tokens en quelques minutes. Qu'est-ce qu'une cascade de sous-agents en IA autonome ? Il s'agit d'un mode de défaillance dans lequel un agent superviseur génère récursivement des agents enfants sans budget global, multipliant la consommation de tokens de façon exponentielle. Moyens de contrôle indispensables Les équipes d'ingénierie imposent un plafond de profondeur d'exécution fixé à 2 niveaux, un pool de tokens partagé par fil d'exécution racine, et des disjoncteurs limitant la concurrence à 3 ou 5 sous-agents simultanés. À lire aussi Trois budgets pour les agents Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Les trois budgets dont tout agent autonome a besoin · FinOps LLM URL: https://finopsllm.com/fr/research/three-agent-budgets Les trois budgets dont tout agent autonome a besoin Mis à jour August 27, 2026 · première publication August 27, 2026 Réponse rapide: Un agent autonome a besoin de trois limites dans sa boucle: budget de requête, de flux et journalier. Chacune capture un mode d’échec différent.RequêtePlafonne tokens, outils, durée ou dollars d’une... Un agent autonome a besoin de trois limites dans sa boucle: budget de requête , de flux et journalier . Chacune capture un mode d’échec différent. Requête Plafonne tokens, outils, durée ou dollars d’une tentative et s’applique avant le fournisseur et chaque outil. Flux Suit toute l’intention à travers reprises, bascules et sous-agents. Un registre corrélé arrête les boucles qui ne convergent pas. Journalier Limite la dépense agrégée d’une équipe, d’un client ou d’un service. À l’approche du plafond, utilisez une route moins chère ou batch. Refus utiles Indiquez la limite déclenchée, le montant consommé et la récupération possible. Consignez réservations, dépenses et refus pour le rapprochement. À lire aussi Garde-fous de dépense des agents Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Guide de mise en œuvre des budgets de tokens · FinOps LLM URL: https://finopsllm.com/fr/research/token-budget-implementation-guide Guide de mise en œuvre des budgets de tokens Les budgets de tokens sont la couche opérationnelle du contrôle des coûts des LLM. L'attribution vous indique où va l'argent ; les budgets empêchent qu'il aille où vous ne le souhaitez pas. Sans budgets, une boucle d'agent mal configurée ou un pic du trafic utilisateur peut consommer une allocation mensuelle en quelques heures. Ce guide couvre la mise en œuvre de quatre types de budgets de tokens en production, avec du pseudocode pour chaque modèle. Types de budgets Type de budget Granularité Application Cas d'usage Par requête Un seul appel API Limite rigide via le paramètre max_tokens Prévenir les complétions incontrôlables, limiter la latence Quota par équipe Équipe ou projet sur une période Limite souple avec alertes, limite rigide au seuil Allocation des coûts par département, empêcher une équipe de consommer le budget partagé Par période de temps Quotidien, hebdomadaire ou mensuel Limite rigide avec période de grâce Plafonds de budget mensuel, dépenses au niveau du sprint Par flux de travail Un seul pipeline ou exécution d'agent Limite rigide par étape et totale Agents multi-étapes, pipelines RAG, exécutions d'évaluation Limites par requête Le budget le plus simple : limiter chaque requête avec max_tokens . C'est obligatoire - chaque requête de production devrait avoir une limite explicite de tokens de sortie. Sans elle, une réponse verbale du modèle peut consommer des tokens inattendus et augmenter la latence. // Application du budget par requête function appellerLLM(prompt, config): reponse = fournisseur.completer( prompt: prompt, modele: config.modele, max_tokens: config.max_tokens_sortie, // limite rigide temperature: config.temperature ) if reponse.usage.tokens_totaux > config.seuil_alerte: log.avertir("La requête a dépassé la limite souple", tokens: reponse.usage.tokens_totaux, seuil: config.seuil_alerte ) return reponse Quotas par équipe Les quotas par équipe nécessitent un compteur partagé qui persiste entre les requêtes. Le modèle : vérifier le budget restant avant chaque appel, refuser ou rétrograder si le budget est épuisé. // Quota d'équipe avec compteur sauvegardé dans Redis function verifierBudgetEquipe(equipoId, tokensEstimes): cle = "budget:" + equipoId + ":" + periodeActuelle() restant = redis.obtenir(cle) or obtenirQuotaEquipe(equipoId) if restant Budgets par période de temps Les budgets par période de temps associent les quotas d'équipe avec une fenêtre temporelle. La différence clé : vous avez besoin d'un mécanisme de période de grâce. Quand une équipe atteint 80% de son budget mensuel, envoyer une alerte. À 100%, permettre une période de grâce configurable (par exemple, 24 heures) avant que l'application rigide n'entre en vigueur. Cela empêche une équipe d'être bloquée au milieu d'une tâche le dernier jour du mois. // Budget par période avec période de grâce function appliquerBudget(equipoId): utilisation = obtenirUtilisationPeriode(equipoId, moisActuel()) limite = obtenirLimiteMensuelleEquipe(equipoId) if utilisation Budgets par flux de travail Les agents et pipelines multi-étapes nécessitent des budgets à deux niveaux : par étape (empêcher une seule étape de consommer trop) et par exécution (empêcher tout le pipeline de dépasser son allocation). Tracer les deux dans le contexte du flux de travail. // Suivi du budget du flux de travail class BudgetFlux: constructeur(maxParEtape, maxTotal): this.maxParEtape = maxParEtape this.maxTotal = maxTotal this.depense = 0 function executerEtape(fnEtape, prompt): if this.depense >= this.maxTotal: return reponseSecours("Budget dépassé") reponse = appellerLLM(prompt, { max_tokens: min(this.maxParEtape, this.maxTotal - this.depense) }) this.depense += reponse.usage.tokens_totaux return reponse Dégradation gracieuse quand le budget est dépassé Ne pas simplement retourner une erreur quand un budget est atteint. Rétrograder avec grâce. Passer à un modèle moins coûteux (GPT-4o-mini au lieu de GPT-4o), réduire la taille de la fenêtre de contexte, sauter les étapes de traitement optionnelles ou retourner un résultat partiel avec une note indiquant que le traitement complet nécessite une approbation budgétaire. L'expérience utilisateur devrait se dégrader, pas se casser. // Chaîne de dégradation function appellerAvecDegradation(prompt, config): if verifierBudget(config.equipoId, MODELE_COMPLET): return appellerLLM(prompt, { modele: config.modelePrimaire }) if verifierBudget(config.equipoId, MODELE_ECONOMIQUE): log.info("Rétrogradation du modèle pour budget") return appellerLLM(prompt, { modele: config.modeleSecours }) if verifierBudget(config.equipoId, TOKENS_MINIMES): tronque = tronquerContexte(prompt, 50%) return appellerLLM(tronque, { modele: config.modeleSecours, max_tokens: 256 }) return cacheeOuSecours(prompt) Surveillance de la santé du budget Tracer trois métriques : taux de consommation (tokens consommés par heure par rapport au budget), prévision (au rythme actuel, quand le budget sera-t-il épuisé) et nombre de dérogations (combien de fois la période de grâce a-t-elle été utilisée). Si l'utilisation de la période de grâce dépasse 10% des requêtes totales, le budget est défini trop bas pour la charge de travail. Associé Gouvernance des budgets LLM - politiques organisationnelles derrière les budgets. Garde-fous de dépenses d'agent - modèles de budget pour les agents autonomes. Comment plafonner les coûts d'inférence - contrôles de coûts côté fournisseur. Voulez-vous appliquer cela à vos propres dépenses en LLM ? FinOps LLM effectue un audit gratuit de vos coûts d'IA et montre où se trouvent les économies. Réserver un audit gratuit → Retour à la recherche --- # Tokens moins chers, facture LLM plus élevée · FinOps LLM URL: https://finopsllm.com/fr/research/token-prices-bill-keeps-rising Tokens moins chers, facture LLM plus élevée Mis à jour August 27, 2026 · première publication August 27, 2026 Réponse rapide: Un token moins cher ne garantit pas une facture plus basse. En production, l'usage peut croître plus vite que les tarifs ne baissent: contextes plus longs, agents plus actifs, sorties plus grandes et... Un token moins cher ne garantit pas une facture plus basse. En production, l'usage peut croître plus vite que les tarifs ne baissent: contextes plus longs, agents plus actifs, sorties plus grandes et nouvelles fonctionnalités effacent souvent la remise. Séparez la variation de tarif, de volume, de mix et d'efficacité. Le tarif n'est qu'une composante Si le prix passe de 10 à 6 dollars par million de tokens mais que l'usage passe de 100 à 220 millions, la facture monte de 1 000 à 1 320 dollars. Suivez les tarifs facturés par fournisseur, modèle et type de token; un coût moyen masque la cause. Volume, mix et efficacité Le volume mesure les tokens consommés. Le mix révèle le déplacement vers un modèle plus cher ou une fonctionnalité à long contexte. L'efficacité mesure le coût d'un résultat utile: reprises, outils échoués, prompts trop longs et sorties ignorées. Chaque appel doit porter ses dimensions et être rapproché de la facture. Le contrôle hebdomadaire Construisez un pont entre deux factures: tarif, volume, mix, efficacité. Suivez le coût par tâche réussie ajusté du trafic. Corrigez la catégorie qui explique le plus de dollars: contexte et boucles, routage, reprises ou achat. La baisse des prix est favorable, mais elle ne remplace pas une mesure réconciliée de l'usage, de la qualité et du coût. À lire aussi Suivi des coûts LLM Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Les prompts verbeux ont une taxe · FinOps LLM URL: https://finopsllm.com/fr/research/verbose-prompt-tax Le style de prompt sur la facture Mis à jour September 1, 2026 · première publication September 1, 2026 Réponse rapide: Les prompts grossissent comme les fichiers de configuration : quelqu’un ajoute une consigne après un bug, un autre un exemple, un troisième un paragraphe d’explication. On ne retire jamais rien. Six... Les prompts grossissent comme les fichiers de configuration : quelqu’un ajoute une consigne après un bug, un autre un exemple, un troisième un paragraphe d’explication. On ne retire jamais rien. Six mois plus tard, le system prompt fait trois mille tokens et personne ne sait lesquels portent la structure. Pourquoi cela s’accumule Contrairement à la sortie, le surcoût du prompt se paie à chaque requête , à l’identique, indéfiniment. Mille tokens gaspillés sur dix millions d’appels mensuels, ce sont dix milliards de tokens de pure mise en forme par mois. En conversation multi-tours c’est pire : le system prompt est renvoyé à chaque tour. Dans une boucle d’agent, une seule action utilisateur facture le même préambule une dizaine de fois. Ce qui gaspille vraiment Pas la politesse. Le poids est dans les consignes redondantes, le boilerplate défensif écrit pour une génération de modèles révolue, les exemples qui se dupliquent, et les explications destinées aux humains qui lisent le fichier. Traitez-le comme du code avec un budget Mesurez le prompt fixe en part de la requête moyenne. Placez la partie stable en tête pour le cache. Puis élaguez par ablation contre vos évaluations : retirez un bloc, mesurez, gardez le retrait si la qualité tient. À lire aussi Économie du cache de prompts Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Les agents vocaux facturent à la minute · FinOps LLM URL: https://finopsllm.com/fr/research/voice-agents-bill-per-minute Économie unitaire des API audio temps réel Mis à jour September 1, 2026 · première publication September 1, 2026 Réponse rapide: Tout modèle de coût conçu pour le texte se casse sur la voix. Le texte se facture en tokens, proportionnels à l’information. L’audio se facture en durée, proportionnelle au temps — y compris... Tout modèle de coût conçu pour le texte se casse sur la voix. Le texte se facture en tokens, proportionnels à l’information. L’audio se facture en durée, proportionnelle au temps — y compris tout le temps où rien d’utile ne se passe. Ce que vous payez réellement Une interaction vocale empile trois ou quatre facturations : transcription en entrée, appel modèle (à la minute d’audio sur les API temps réel), synthèse en sortie, et souvent la session ouverte. C’est ce dernier point le piège : au compteur à la minute, le silence est un produit à plein tarif. Où les estimations dérapent On modélise temps de parole × tarif et on tombe trop bas. Manquent les pauses et la latence, l’audio généré que l’appelant a interrompu, les reprises (qui rejouent l’audio, pas seulement les tokens) et les appels abandonnés. La bonne métrique Coût par conversation aboutie, pas par minute. Et fermez les sessions inactives : c’est en général la plus grosse économie disponible. À lire aussi Économie des agents Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # DeepSeek Harness : le guide complet · FinOps LLM URL: https://finopsllm.com/fr/research/what-is-deepseek-harness DeepSeek Harness : le guide complet Mis à jour August 16, 2026 · première publication August 16, 2026 Réponse rapide: DeepSeek Harness — nom de paquet dsh — est un harness d'agents open source publié par DeepSeek AI sous licence MIT. Voici la version sans prérequis : ce que c'est, comment l'exécuter, comment il est... DeepSeek Harness — nom de paquet dsh — est un harness d'agents open source publié par DeepSeek AI sous licence MIT. Voici la version sans prérequis : ce que c'est, comment l'exécuter, comment il est bâti, et s'il doit vous intéresser. Ce qu'est réellement un harness d'agents Un modèle produit du texte et des appels d'outils. C'est tout ce qu'il fait. Tout le reste de ce qui rend un agent utile relève du harness : assembler le prompt, exécuter effectivement les outils demandés, faire respecter ce qui est permis, consigner ce qui s'est passé, piloter la boucle qui décide de rappeler le modèle, et déléguer du travail à des sous-agents. Cette distinction mérite d'être intégrée avant tout le reste, car l'essentiel de ce qu'un agent fait bien ou mal relève du comportement du harness et non du modèle. Deux équipes exécutant le même modèle obtiennent des résultats très différents et des factures très différentes — l'écart se loge ici. Ce que fait DeepSeek Harness Il exécute des agents de code et d'automatisation. Concrètement, l'agent lit et modifie des fichiers, lance des commandes shell, cherche dans le code, délègue à des sous-agents, planifie le travail et demande confirmation selon la politique de permissions active. Il offre une interface navigateur, un mode headless pour les exécutions uniques, et un serveur d'automatisation qui parle JSON-RPC sur l'entrée et la sortie standard. L'unique idée de conception : tout est un plugin Le harness s'appuie sur Cordis , un runtime de plugins où chaque plugin apporte des services, des événements typés et des effets réversibles dans un contexte partagé. Il n'y a pas de noyau privilégié. L'adaptateur de modèle est un plugin. Le registre d'outils est un plugin. Le journal de session est un plugin. La boucle d'agent elle-même est un plugin. La plupart des systèmes extensibles proposent un noyau figé plus des hooks : on observe et on décore, on ne remplace pas — et remplacer signifie forker. Un runtime de plugins inverse cela : les pièces qu'on voudrait le plus remplacer sont précisément les unités de composition. Le mettre en route La voie rapide npx @deepseek-ai/dsh web Cela lance une interface web locale sur http://127.0.0.1:3080 . Depuis les sources git clone https://github.com/deepseek-ai/deepseek-harness cd deepseek-harness pnpm install pnpm run build pnpm dsh web Prérequis : Node 22.19 ou plus récent (la CI couvre 22.19, 24 et 26), Git 2.26 ou plus récent, et pnpm épinglé via Corepack. Une clé d'API DeepSeek est facultative à l'installation mais nécessaire pour faire quoi que ce soit d'utile ; elle peut venir de l'environnement ou d'un .env ignoré par git à la racine du dépôt. Les deux étapes que tout le monde manque Paramètres → Modèles. Saisissez votre clé d'API. La route s'active immédiatement, sans redémarrage. Choisir l'espace de travail. Ajoutez et activez le répertoire de votre projet. Le compositeur de session reste indisponible tant qu'aucun espace n'est actif — c'est la raison habituelle pour laquelle une installation neuve semble cassée. Headless pnpm dsh --profile headless "summarize this workspace" C'est le mode qui compte pour l'automatisation, car un harness qui ne fonctionne qu'en interactif ne peut pas entrer en CI, et ce qui n'est pas en CI ne peut pas être mesuré à intervalle régulier. Le vocabulaire pour lire la documentation Terme Sens Pas (step) Une requête au modèle plus les appels d'outils qu'elle produit Tour (turn) Une vidange de l'entrée, close quand le modèle s'arrête ou que la politique intervient Manche (round) Une itération de politique au-dessus des tours, par exemple une nouvelle tentative sur un objectif Session Un journal en ajout seul d'événements typés — la source de vérité unique de l'exécution Couture de capacité Une interface de service avec plusieurs implémentations interchangeables Profil Une composition nommée : liste ordonnée de bundles de plugins plus vos correctifs Scope L'unité d'enregistrement par agent pour les outils, prompts et restrictions La configuration se résout en quatre couches, la dernière l'emportant : bundles du profil, puis correctifs du profil, puis correctifs au niveau home, puis surcharges en ligne de commande. Connaître cet ordre transforme « pourquoi utilise-t-il ce modèle » d'une enquête en une consultation. Ce qui vaut le coup d'œil Le choix du modèle est interchangeable. Le service de modèle est une interface avec plusieurs backends, dont un qui rejoue une session enregistrée sans repayer l'inférence. La boucle d'agent consomme un flux neutre vis-à-vis du fournisseur et n'apprend jamais quel backend est actif. L'enregistrement est complet par construction. Le principe directeur est que ce qui est visible du modèle est journalisé, car le journal doit pouvoir reconstituer l'exécution. La consommation de jetons voyage attachée à la sortie qui l'a engendrée. Les points d'application sont explicites. Un avant l'envoi de la requête au modèle, dont la décision est documentée comme faisant autorité, et un avant l'exécution du corps de tout outil. Les gardes de permission peuvent refuser ou s'abstenir, jamais accorder, et une approbation sans réponse possible refuse. Il tourne en headless. Donc scriptable, planifiable et mesurable. L'argument des plugins n'est pas que du positionnement : l'une des démos livrées est auto-référentielle et inspecte puis modifie son propre runtime de plugins en cours d'exécution. Difficile à simuler. Quand l'utiliser, et quand s'abstenir Utilisez-le pour évaluer, pour prototyper, et comme point de comparaison concret face au stack d'agents que vous exploitez déjà. Les cinq questions à emporter : le choix du modèle est-il interchangeable, existe-t-il un enregistrement de session complet avec la consommation attachée, y a-t-il des points d'application avant l'appel au modèle et avant l'exécution des outils, tourne-t-il en headless, et la superposition de configuration est-elle documentée ? Ne standardisez pas dessus ce trimestre. Le projet se présente comme une developer preview et annonce clairement des changements incompatibles. Épinglez la version contre laquelle vous construisez et ne planifiez pas de migration en production sur une API en préversion. Ce que coûte son exploitation Le harness est sous licence MIT et gratuit. L'inférence ne l'est pas. Vous fournissez une clé d'API DeepSeek, ou vous pointez la couture de modèle vers un autre fournisseur. L'implication pratique : votre facture est fonction des pas par tour, des outils du catalogue, de la profondeur de délégation et du nombre de manches qu'un objectif ouvert peut parcourir — autant de décisions au niveau du harness, aucune n'étant le prix au jeton que vous avez négocié. À lire aussi Installation, profils et première exécution (EN) Ce que « tout est un plugin » apporte vraiment (EN) Le journal de session comme registre de coûts (EN) Où placer les garde-fous de dépense (EN) Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit → Retour à finopsllm.com --- # Glossary · FinOps LLM · AI FinOps and LLM Cost Terms URL: https://finopsllm.com/glossary Glossary Plain-English definitions of the terms used across AI FinOps, LLM cost attribution, and optimization. Listed alphabetically. AI FinOps Applying visibility, attribution, optimization, and accountability practices to AI and LLM spend, so cost behaves like a managed unit-economics input rather than a surprise on the invoice. Anomaly detection Flagging unusual changes in LLM spend - a sudden spike in tokens, a model-mix shift, or a runaway agent loop - early enough to act before the monthly invoice arrives. Attribution (cost attribution) Mapping each unit of LLM spend back to the feature, team, environment, and customer that caused it, so every dollar has a named owner. Baseline A locked, pre-optimization measurement of spend used as the reference point for measuring savings. Reconciled to the provider invoice so reported savings are defensible. Batch API An asynchronous request mode offered by major providers, typically at a discount versus real-time calls, for work that can tolerate delayed completion (evals, backfills, summaries). Budget enforcement Turning a monthly spend envelope into an actual control: soft thresholds alert the owning team; hard thresholds degrade behavior (cheaper model, less retrieval, queue or batch) rather than letting spend run unbounded. Cache-read tokens Input tokens served from a provider's prompt cache rather than processed fresh. They are billed at a steep discount (often around 50% on OpenAI and up to ~90% on Anthropic, subject to current provider pricing), so tracking them separately is essential to an accurate baseline. Chargeback Assigning spend to the teams, products, or customers that consumed it and moving the cost onto their budget or P&L. Context window The maximum number of tokens a model can consider at once (prompt plus generated output). Larger contexts cost more per request and are a common, often invisible, driver of bill growth. Cost per request The fully-loaded cost of a single LLM call - input, output, cache, and reasoning tokens - used as a product KPI to track the unit economics of a feature over time. Fallback chain An ordered list of models a request can fall back to when the primary is unavailable, rate-limited, or too expensive. Improves reliability but can quietly raise cost if a pricier fallback fires often. Gross margin (AI feature) Revenue from an AI-powered feature minus the LLM and infrastructure cost to deliver it. The number AI FinOps ultimately exists to protect. Input tokens The tokens you send to a model - the prompt, system instructions, retrieved context, and conversation history. Usually cheaper per token than output, but easy to inflate with oversized prompts. Invoice reconciliation The monthly close that ties internal usage estimates (from gateway or log data) line-by-line to the provider invoice, documenting and fixing any variance. Latency budget The maximum acceptable response time for a request. It bounds which optimizations are viable - some routing and batching choices trade latency for cost. Model routing Sending each request to the cheapest model or provider that still satisfies quality and latency constraints, instead of defaulting every call to the most capable model. Output tokens The tokens a model generates in its response. Typically the most expensive token type per unit, so verbose outputs and high max-token limits are frequent cost drivers. Prompt caching A provider feature that stores a repeated prompt prefix so subsequent calls reuse it at a discount. Effective for stable system prompts and shared context. Prompt compression Reducing the token count of prompts - trimming boilerplate, summarizing history, pruning retrieved context - to lower cost without materially changing output quality. Provider arbitrage Running the same or an equivalent model across providers and routing to whichever offers the best price for the required quality and latency. Quality SLO A measurable threshold (accuracy, eval score, human rating) that an optimization must hold above. Optimizations that breach the SLO are rolled back rather than shipped for the sake of savings. RAG (retrieval-augmented generation) Injecting retrieved documents into a prompt so the model answers from current or proprietary data. Retrieval depth directly drives input-token cost, making it a key attribution and optimization lever. Reasoning tokens Tokens a reasoning model generates internally while "thinking" before producing a visible answer. They are billed but not shown, and can dominate the cost of a request - a frequent source of unexplained bill growth. Semantic caching Reusing a stored response for a semantically similar request once it passes a similarity and quality threshold, avoiding a fresh model call entirely. Showback Reporting each team's spend ownership monthly without moving the cost onto their budget - visibility without billing. Token The unit providers bill on - a chunk of text roughly a few characters long. All LLM cost ultimately reduces to how many tokens of each type a workload consumes. Unit economics Cost and revenue expressed per unit - per request, per feature, per customer - so AI spend can be reasoned about the way every other variable cost is. Unallocated spend LLM cost that has not been traced to an owner. Treated as a bucket with a named owner and driven toward zero, rather than ignored as "miscellaneous." See also: How LLM providers charge · What is LLM FinOps? · all research . Back to FinOps LLM --- # La ricerca web diventa centro di costo per gli agenti · FinOps LLM URL: https://finopsllm.com/it/research/agent-web-search-cost-center Ricerca web come centro di costo per gli agenti Aggiornato September 10, 2026 · pubblicato inizialmente September 10, 2026 Risposta rapida: La ricerca web dal vivo trasforma gli agenti ma introduce tariffe a query oltre ai token. Monitora il numero di ricerche per task e applica limiti severi. La ricerca web dal vivo trasforma gli agenti ma introduce tariffe a query oltre ai token. Monitora il numero di ricerche per task e applica limiti severi. Correlati Costo per task completato Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Misura il margine lordo di feature IA al lancio · FinOps LLM URL: https://finopsllm.com/it/research/ai-feature-gross-margin Misurare il margine lordo di una feature IA prima del lancio Aggiornato September 2, 2026 · pubblicato inizialmente September 2, 2026 Risposta rapida: L'inferenza è un costo di erogazione del servizio, non un costo di sviluppo. Viene eseguita su ogni azione del cliente e scala con l'utilizzo. Trattarla come R&D fino al lancio significa scoprire... L'inferenza è un costo di erogazione del servizio, non un costo di sviluppo. Viene eseguita su ogni azione del cliente e scala con l'utilizzo. Trattarla come R&D fino al lancio significa scoprire il margine reale solo con la prima fattura del provider. Strumentare prima del rilascio In staging, tracciate ogni chiamata al modello con account, workflow ed esito, riproducendo traffico reale. È necessaria una distribuzione: costo per task riuscito a p50, p90 e p99, più la quota di spesa per fallimenti e retry. Costo per account Moltiplicate il costo per task riuscito per il volume mensile atteso e sommate i fallimenti. Confrontate con il prezzo dell'abbonamento. Quattro fattori di costo Contesto reinviato a ogni turno, retry fatturati per intero, espansione agéntica e routing inefficiente. Correlati Costo per task riuscito Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Varianza spesa IA: volume, tariffa, mix ed efficienza · FinOps LLM URL: https://finopsllm.com/it/research/ai-spend-variance-bridge Varianza della spesa IA: volume, tariffa, mix ed efficienza Aggiornato August 27, 2026 · pubblicato inizialmente August 27, 2026 Risposta rapida: L'analisi degli scostamenti di spesa IA è utile solo se orienta decisioni operative concrete. Suddividete la discrepanza tra budget previsto e fatturato reale in quattro cause distinte: volume,... L'analisi degli scostamenti di spesa IA è utile solo se orienta decisioni operative concrete. Suddividete la discrepanza tra budget previsto e fatturato reale in quattro cause distinte: volume , tariffa , mix ed efficienza , collegando ciascuna a telemetria, fatture e responsabili tecnici. Le quattro cause fondamentali Il volume misura la domanda di richieste e token. La tariffa è il prezzo unitario effettivo fatturato dopo sconti e impegni. Il mix riflette la migrazione tra modelli, provider o modalità di calcolo. L' efficienza misura il costo necessario per produrre lo stesso risultato utile, includendo prompt size, retry, fallimento di chiamate a tool e correzione umana. Costruire il ponte operativo Partite dal piano iniziale, applicate tariffa, volume, mix ed efficienza, riconciliando il totale con i conti dei fornitori. Ogni scostamento necessita di evidenza tecnica, impatto economico, titolare e contromisura sul routing o sulle policy di prodotto. Correlati Monitoraggio dei costi LLM Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Azure OpenAI vs OpenAI Diretto: costi e PTU · FinOps LLM URL: https://finopsllm.com/it/research/azure-openai-vs-direct-cost Azure OpenAI vs OpenAI Diretto: confronto costi e unità PTU Aggiornato September 19, 2026 · pubblicato inizialmente July 12, 2026 Risposta rapida: Nelle distribuzioni globali con tariffazione a consumo (pay-as-you-go), Azure OpenAI e l'API diretta di OpenAI applicano gli stessi identici prezzi di listino (ad esempio $2,50 per milione di token in... Nelle distribuzioni globali con tariffazione a consumo (pay-as-you-go), Azure OpenAI e l'API diretta di OpenAI applicano gli stessi identici prezzi di listino (ad esempio $2,50 per milione di token in ingresso e $15 in uscita sui modelli di punta). Le divergenze finanziarie effettive derivano da tre fattori: le Provisioned Throughput Units (PTU) , le maggiorazioni regionali per la sovranità dei dati e gli accordi quadro Enterprise Agreement (EA) di Microsoft. 1. Throughput riservato (PTU) vs. consumo a token Le PTU permettono di acquistare capacità di calcolo dedicata. Su base oraria on-demand, una PTU costa $2 all'ora. Con una prenotazione mensile, il costo scende a circa $260 al mese per PTU — garantendo un risparmio fino all'82% rispetto alla tariffa oraria (e fino all'85% su base annuale). Il punto di pareggio (break-even) di una prenotazione PTU si colloca tipicamente a un tasso di utilizzo costante superiore al 65–75% . Al di sotto di tale soglia, o in presenza di flussi discontinui, la tariffazione classica a token risulta più vantaggiosa. 2. Sovrapprezzi regionali e requisiti europei I deployment globali replicano i listini statunitensi. Tuttavia, se l'azienda richiede la residenza dei dati esclusivamente all'interno dell'Unione Europea o in zone protette, Azure applica una maggiorazione compresa tra il 10% e il 20% . 3. Costi infrastrutturali accessori In ambiente Azure occorre conteggiare anche i Private Endpoint, l'ingestione log in Azure Monitor e il traffico di rete in uscita. Tali elementi incrementano il costo effettivo dei token del 4–8%, compensati però da conformità enterprise e autenticazione IAM granulare. Correlati Sconti per spesa impegnata Perché i prezzi dei provider non sono direttamente comparabili Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Gli agenti in background cambiano l'orologio FinOps · FinOps LLM URL: https://finopsllm.com/it/research/background-agents-cost-clock Agenti in background e l'orologio FinOps Aggiornato September 10, 2026 · pubblicato inizialmente September 10, 2026 Risposta rapida: Gli agenti asincroni continuano a generare token e chiamare tool anche a sessione chiusa. È indispensabile un budget per task con timeout rigidi. Gli agenti asincroni continuano a generare token e chiamare tool anche a sessione chiusa. È indispensabile un budget per task con timeout rigidi. Correlati Tre budget per ogni agente Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Claude Opus 5.5: $4/$20 e lettura cache a $0.20 · FinOps LLM URL: https://finopsllm.com/it/research/claude-opus-5-5-cost-model Modello di costo di Claude Opus 5.5 Aggiornato September 22, 2026 · pubblicato inizialmente September 22, 2026 Anthropic ha rilasciato Claude Opus 5.5 ( claude-opus-5-5 ) il 22 settembre 2026. Il prezzo annunciato è $4 per milione di token di input e $20 per milione di token di output, rispetto ai $5 e $25 di Opus 5. Si tratta di un taglio del 20%. Per la maggior parte dei carichi di lavoro in produzione, il taglio effettivo è maggiore, perché il tasso che si è mosso di più è quello che il titolo omette. Le tariffe che contano Tipo di token Opus 5.5 Opus 5 Fable 5.1 Input (non cachato) $4.00 / MTok $5.00 / MTok $10.00 / MTok Output $20.00 / MTok $25.00 / MTok $50.00 / MTok Scrittura della cache (5 min) $5.00 / MTok $6.25 / MTok $12.50 / MTok Lettura della cache $0.20 / MTok $0.50 / MTok $0.25 / MTok Modalità veloce (input / output) $8 / $40 — — Ogni riga è il 20% più bassa tranne la lettura della cache, che è il 60% più economica. A $0.20 è ora più economico dei $0.25 di Fable 5.1. Questo inverte l'unica riga in cui Fable era solito vincere. Nel nostro modello di costo di Fable 5.1 , un carico di lavoro molto cachato potrebbe risultare più economico su Fable che su Opus 5. Rispetto a Opus 5.5, questo non accade più. Fable costa di più su ogni tipo di token. Perché un'attività tipica costa circa il 40% in meno L'affermazione di Anthropic è una riduzione del 40% dei costi per un lavoro tipico, non del 20%. L'extra proviene dall'efficienza del token. Anthropic afferma che Opus 5.5 raggiunge lo stesso risultato con circa il 20% meno token di input e output e scrive output circa il 40% meno verboso. Un tasso più basso per meno token si compone: 0.8 × 0.8 = 0.64, che è approssimativamente uno sconto del 36–40% a seconda del mix. Ecco un passo dell'agente: 200.000 token di input, il 90% servito dalla cache, e 20.000 token di output. Riga Opus 5 Opus 5.5 (stessi token) Fable 5.1 20K input non cachato $0.100 $0.080 $0.200 180K input cachato $0.090 $0.036 $0.045 20K output $0.500 $0.400 $1.000 Totale $0.690 $0.516 $1.245 Su token identici, Opus 5.5 è il 25% più economico di Opus 5, non il 20%, a causa dello sconto della cache. Se la riduzione del 20% dei token si mantiene per il vostro carico di lavoro, il passo scende a circa $0.41, che è il 40% sotto Opus 5 e un terzo del costo di Fable. L'output rappresenta ancora circa l'80% della fattura in questo esempio. È qui che la riduzione della verbosità ripaga. Costo per attività rispetto a GPT-6 Sol, GPT-6 Astra e Fable 5.1 Prezzi di listino per milione di token e lo stesso passo d'agente visto sopra (200K di input, 90% in cache, 20K di output) calcolato su ogni modello. Modello Input $/MTok Output $/MTok Lettura cache $/MTok Stesso passo d'agente GPT-6 Sol $2.00 $10.00 $0.20 $0.276 Claude Opus 5.5 $4.00 $20.00 $0.20 $0.516 Claude Opus 5 $5.00 $25.00 $0.50 $0.690 Claude Fable 5.1 $10.00 $50.00 $0.25 $1.245 GPT-6 Astra $10.00 $50.00 $1.00 $1.380 Costo per attività misurato sull'Artificial Analysis Intelligence Index v4.3.2, consultato il 22 settembre 2026, ordinato per punteggio. GPT-6 Sol è il modo più economico per raggiungere qualsiasi punteggio fino a 47,5. Sopra, Opus 5.5 è il più economico a ogni livello: Opus 5.5 high ottiene 53,6 per 1,82 $, mentre GPT-6 Astra max ottiene 52,7 per 3,26 $ e Fable 5.1 max 53,4 per 7,63 $. Modello Intelligence Index Costo per attività Token di output per attività GPT-6 Sol · medium 39.8 $0.25 6,500 GPT-6 Sol · xhigh 44.1 $0.53 16,000 GPT-6 Astra · low 45.8 $0.82 4,400 GPT-6 Sol · max 47.5 $1.06 31,200 Claude Opus 5 · high 48.1 $3.61 46,200 Claude Opus 5 · max 50.8 $5.86 72,500 Claude Opus 5.5 · medium 51.2 $1.34 25,700 Claude Fable 5.1 · high 51.2 $3.91 38,100 GPT-6 Astra · max 52.7 $3.26 27,200 Claude Fable 5.1 · max 53.4 $7.63 78,100 Claude Opus 5.5 · high 53.6 $1.82 35,600 Claude Opus 5.5 · max 57.6 $5.98 119,200 Ogni impostazione di GPT-6 Astra sopra low, ogni impostazione di Opus 5 e ogni impostazione di Fable 5.1 costa più di un'impostazione di Sol o Opus 5.5 con punteggio uguale o superiore. Il costo per attività dipende dal mix di attività del benchmark. Riproduci il tuo traffico prima di cambiare modello. È abbastanza buono per sostituire Fable? Anthropic posiziona Opus 5.5 come corrispondente a Fable 5.1 sulla maggior parte dei compiti. I numeri pubblicati lo supportano per il lavoro di codifica e agentivo: Terminal-Bench 4.0: 66.4%, contro 52.3% per Opus 5 e 55.8% per Fable 5.1. FrontierCode v1.1: 54.4%, contro 48.0% per Opus 5 e 50.3% per Fable 5.1. CursorBench 4.0: 57.8%, contro 46.6% per Opus 5. GDPval-AA v2.1: 1846 Elo, contro 1708 per Opus 5. Artificial Analysis lo ha classificato al primo posto nel suo Indice di Intelligenza nel giorno del lancio. Anthropic dice anche che a sforzo predefinito (medio) supera GPT-6 Astra a sforzo massimo sul lavoro di conoscenza per circa un quinto del costo per compito. Questo è un confronto tra fornitori, quindi trattalo come un'ipotesi da testare. La matematica dei costi sopra è la parte che puoi verificare da solo. La modalità veloce costa 2× La modalità veloce costa $8 in input e $40 in output, esattamente il doppio della tariffa standard, per fino a 2.5× la velocità. Il modello standard è anche circa il 30% più veloce di Opus 5. Utilizza la modalità veloce per percorsi interattivi legati alla latenza in cui un utente sta aspettando. Mantienilo spento per lavori batch, agenti in background e valutazioni. Quando la modalità veloce è abilitata per impostazione predefinita, il costo unitario raddoppia e il dashboard non mostra nulla di insolito fino all'arrivo della fattura. Cosa fare questa settimana Blocca l'ID del modello. Indirizza la produzione a claude-opus-5-5 esplicitamente e registra l'ID su ogni richiesta, così il costo per richiesta può essere diviso per modello dopo la migrazione. Ri-calibra sul tuo traffico. Ripeti un campione di richieste reali su entrambi i modelli e confronta i token per attività completata, non per chiamata. L'affermazione di efficienza del 20% dei token è la parte più probabile di variare per carico di lavoro. Ri-controlla le impostazioni dello sforzo. Se un carico di lavoro si è spostato su Fable o su sforzo massimo per la qualità, prova Opus 5.5 prima a livello medio. Questa è l'impostazione rispetto alla quale Anthropic fa benchmark. Ri-esegui la decisione di routing di Fable. Qualsiasi route che ha inviato traffico pesante in cache a Fable per ottenere la lettura della cache più economica dovrebbe essere rivalutata. Questo vantaggio di costo è sparito. Monitora il rapporto di hit della cache. A $0.20 contro $4.00, un miss della cache ora costa 20× un hit. Una modifica del modello di prompt che rompe il prefisso costa più di quanto farebbe su Opus 5. Anthropic dice che Sonnet 5.5 e Haiku 5.5 seguiranno nelle prossime settimane. Conserva l'apparecchio di replay dal passo 2 così ogni rilascio può essere ri-basato in un pomeriggio. Correlati Modello di costo di Claude Fable 5.1 Economia della memorizzazione nella cache del prompt I livelli di sforzo di Opus 5.5 sono il prezzo reale Economia della modalità veloce Opus 5.5 Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Costo per task riuscito rispetto al costo API · FinOps LLM URL: https://finopsllm.com/it/research/cost-per-successful-task Il costo per task riuscito supera il semplice costo per richiesta Aggiornato August 27, 2026 · pubblicato inizialmente August 27, 2026 Risposta rapida: Il costo per richiesta è un parametro utile, ma non rappresenta l'unità acquistata dagli utenti. Una chiamata che fallisce, esegue tre retry o produce un output inutilizzabile non è lavoro completato.... Il costo per richiesta è un parametro utile, ma non rappresenta l'unità acquistata dagli utenti. Una chiamata che fallisce, esegue tre retry o produce un output inutilizzabile non è lavoro completato. Per i sistemi AI in produzione, la metrica determinante è il costo per task completato con successo : tutta la spesa per modelli e tool divisa per i task che superano una soglia di qualità definita. La formula di calcolo Utilizzate costo_task_riuscito = spesa totale attribuibile / task con esito positivo . Includete token di input, output, cache, ragionamento, chiamate a tool e fallback. Definite il successo prima della misurazione: risposta accettata dal cliente o flusso eseguito senza interventi manuali. Perché le medie per richiesta ingannano Il costo medio per richiesta sembra migliorare quando aumentano i tentativi economici falliti. Inoltre nasconde la coda lunga: una funzionalità può avere un costo mediano basso ma generare casi limite che richiedono passaggi di ragionamento complessi e correzioni umane. Monitorate i percentili p50 e p95 del costo per task riuscito. Strumentare il denominatore Ogni span del modello necessita di un ID richiesta e di un tag funzionale; l'applicazione deve poi emettere un evento di completamento collegato a quell'ID. Riconciliate le fatture dei provider con il numeratore e campionate i task completati per convalidare il denominatore. Correlati Monitoraggio dei costi LLM Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Il vero costo di cambiare fornitore LLM · FinOps LLM URL: https://finopsllm.com/it/research/cost-switching-llm-providers Il vero costo di cambiare fornitore LLM: migrazione e qualità Aggiornato August 27, 2026 · pubblicato inizialmente August 27, 2026 Risposta rapida: Cambiare fornitore LLM non è un semplice confronto di listini. Il business case include l'ingegnerizzazione del codice, l'adattamento di prompt e schemi strutturati, benchmark di valutazione, doppio... Cambiare fornitore LLM non è un semplice confronto di listini. Il business case include l'ingegnerizzazione del codice, l'adattamento di prompt e schemi strutturati, benchmark di valutazione, doppio esercizio temporaneo, costi di trasferimento dati e il rischio di regressioni qualitative. Valutate questi costi a fronte del periodo di recupero dell'investimento. Quantificare il carico ingegneristico Mappate chiamate SDK, schemi JSON di output, tool definition, rate limit, gestione del contesto e formati di errore specifici. Calcolate le ore uomo necessarie per sviluppo e collaudo prima di decidere la transizione. Valutare la qualità dell'output Eseguite un dataset di test identico su entrambi i provider. Misurate percentuale di successo del task, latenza p50/p95, retry necessari e concordanza dei giudici automatici o umani. Un risparmio nominale sui token che richiede più revisione manuale aumenta i costi operativi complessivi. Pianificare il periodo di affiancamento Mantenete entrambi i provider in produzione per un periodo sufficiente a osservare carichi di punta e failover. Il ROI si ottiene calcolando i risparmi netti al netto dei costi fissi del gateway e dell'infrastruttura di supporto. Correlati Arbitraggio tra provider Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Sette pattern difensivi in DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/it/research/deepseek-harness-defensive-patterns Sette pattern difensivi in DeepSeek Harness Aggiornato August 16, 2026 · pubblicato inizialmente August 16, 2026 Risposta rapida: Sette principi architetturali adottati da DeepSeek Harness per prevenire crash, leak di memoria e sprechi di token durante l'esecuzione autonoma degli agenti. 1. Risultati ortogonali e... Sette principi architetturali adottati da DeepSeek Harness per prevenire crash, leak di memoria e sprechi di token durante l'esecuzione autonoma degli agenti. 1. Risultati ortogonali e contratti Separare l'esito della task dal monitoraggio dei consumi: i token spesi vanno tracciati anche se la task fallisce. 2. Smaltimento reale delle risorse All'arresto di un agente, tutti i processi e le connessioni devono essere terminati esplicitamente. Correlati Guida a DeepSeek Harness Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Installare DeepSeek Harness: profili e primo avvio · FinOps LLM URL: https://finopsllm.com/it/research/deepseek-harness-getting-started Installare DeepSeek Harness: profili e primo avvio Aggiornato August 16, 2026 · pubblicato inizialmente August 16, 2026 Risposta rapida: Guida pratica per iniziare con dsh (DeepSeek Harness): configurazione, modello compositivo a plugin e workflow iniziale. Avvio rapido npx @deepseek-ai/dsh web Avvia l'interfaccia web locale su... Guida pratica per iniziare con dsh (DeepSeek Harness): configurazione, modello compositivo a plugin e workflow iniziale. Avvio rapido npx @deepseek-ai/dsh web Avvia l'interfaccia web locale su http://127.0.0.1:3080 . Prima dell'uso occorrono due passaggi: Impostazioni → Modelli: inserisci la chiave API DeepSeek. Scegli area di lavoro: aggiungi e attiva la cartella di progetto. Compilazione da sorgente git clone https://github.com/deepseek-ai/deepseek-harness pnpm install pnpm run build pnpm dsh web Requisiti minimi: Node 22.19+, Git 2.26+, pnpm gestito via Corepack. Profili e bundle I componenti sono plugin Cordis raggruppati in profili ( dsh-base , dsh-web-app , dsh-headless ). L'ordine di override a 4 livelli garantisce che i flag da riga di comando abbiano sempre la precedenza assoluta. Correlati Cos'è DeepSeek Harness? Limiti di spesa in DeepSeek Harness Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Obiettivi e Ralph Loop in DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/it/research/deepseek-harness-goals-ralph-loop Obiettivi e Ralph Loop in DeepSeek Harness Aggiornato August 16, 2026 · pubblicato inizialmente August 16, 2026 Risposta rapida: Formalizzazione del lavoro iterativo: distinzione tra step, turn e round, e utilizzo del Ralph Loop per resettare il contesto e contenere i token. Formalizzazione del lavoro iterativo: distinzione tra step, turn e round, e utilizzo del Ralph Loop per resettare il contesto e contenere i token. Correlati Guida a DeepSeek Harness Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Guardrail di spesa in DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/it/research/deepseek-harness-guardrails Guardrail di spesa in DeepSeek Harness Aggiornato August 16, 2026 · pubblicato inizialmente August 16, 2026 Risposta rapida: Due punti di controllo chiave prima delle chiamate al modello e prima dell'esecuzione dei tool per bloccare sprechi finanziari. Due punti di controllo chiave prima delle chiamate al modello e prima dell'esecuzione dei tool per bloccare sprechi finanziari. Correlati Guida a DeepSeek Harness Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Tutto è un plugin: architettura di DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/it/research/deepseek-harness-plugin-architecture Tutto è un plugin: architettura di DeepSeek Harness Aggiornato August 16, 2026 · pubblicato inizialmente August 16, 2026 Risposta rapida: L'assenza di un core privilegiato consente di sostituire adapter del modello e registri dei tool senza forkare il repository. L'assenza di un core privilegiato consente di sostituire adapter del modello e registri dei tool senza forkare il repository. Correlati Guida a DeepSeek Harness Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Registro di sessione: unica fonte di verità e costi · FinOps LLM URL: https://finopsllm.com/it/research/deepseek-harness-session-log Registro di sessione: unica fonte di verità e costi Aggiornato August 16, 2026 · pubblicato inizialmente August 16, 2026 Risposta rapida: Tracciamento dettagliato del consumo di token associato a ogni singolo output per una contabilità granulare. Tracciamento dettagliato del consumo di token associato a ogni singolo output per una contabilità granulare. Correlati Guida a DeepSeek Harness Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Sotto-agenti e deleghe in DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/it/research/deepseek-harness-subagents Sotto-agenti e deleghe in DeepSeek Harness Aggiornato August 16, 2026 · pubblicato inizialmente August 16, 2026 Risposta rapida: Limitare la ricorsione della delega tra agenti autonomi per proteggere il budget da moltiplicatori non lineari. Limitare la ricorsione della delega tra agenti autonomi per proteggere il budget da moltiplicatori non lineari. Correlati Guida a DeepSeek Harness Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Ambiti degli strumenti e restrizioni in Harness · FinOps LLM URL: https://finopsllm.com/it/research/deepseek-harness-tool-scopes Ambiti degli strumenti e restrizioni in Harness Aggiornato August 16, 2026 · pubblicato inizialmente August 16, 2026 Risposta rapida: Iniettare solo i tool strettamente necessari nel prompt riduce le spese di input e migliora l'accuratezza del modello. Iniettare solo i tool strettamente necessari nel prompt riduce le spese di input e migliora l'accuratezza del modello. Correlati Guida a DeepSeek Harness Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Controlli di costo nella pipeline di valutazione LLM · FinOps LLM URL: https://finopsllm.com/it/research/evals-cost-control Controlli di costo nella pipeline di valutazione LLM Aggiornato August 27, 2026 · pubblicato inizialmente August 27, 2026 Risposta rapida: Le suite di valutazione automatica dei modelli linguistici necessitano di una governance economica dedicata. Un job di integrazione continua (CI) che esegue 10.000 prompt a ogni commit può generare... Le suite di valutazione automatica dei modelli linguistici necessitano di una governance economica dedicata. Un job di integrazione continua (CI) che esegue 10.000 prompt a ogni commit può generare una fattura superiore a quella della funzionalità in produzione. Controllate i costi impostando budget per singolo run, campionamento mirato, fixture immutabili in cache e stop anticipato al fallimento dei test. Budgeting per esecuzione Definite limiti massimi di prompt, modelli candidati, retry e spesa in dollari prima dell'avvio della valutazione. Separate i test di fumo su pull-request dalle suite di regressione notturne e dalle certificazioni pre-release. Campionare per preservare il segnale Stratificate il dataset di test per workflow, impatto sul cliente, complessità e modalità di errore note. Diecimila prompt duplicati offrono meno segnale di un set ristretto focalizzato sui casi limite decisionali. Cache per le componenti stabili Mettete in cache contesti recuperati da RAG, fixture immutabili e valutazioni di riferimento quando il test non dipende da generazione fresca. Tracciate hit e miss della cache come costo di valutazione esplicito. Correlati Costo per task completato con successo Monitoraggio dei costi LLM Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # La prima chiusura mensile per prodotti AI · FinOps LLM URL: https://finopsllm.com/it/research/first-ai-month-end-close Come strutturare la prima chiusura mensile per prodotti AI Aggiornato August 27, 2026 · pubblicato inizialmente August 27, 2026 Risposta rapida: La prima chiusura mensile AI non deve partire da uno screenshot di dashboard, ma dalle fatture grezze dei fornitori e da un intervallo temporale bloccato. Chiudete prima il dato di cassa, spiegate i... La prima chiusura mensile AI non deve partire da uno screenshot di dashboard, ma dalle fatture grezze dei fornitori e da un intervallo temporale bloccato. Chiudete prima il dato di cassa, spiegate i volumi di utilizzo e allocate i costi solo dopo aver completato la riconciliazione. Questo ordine evita che grafici accattivanti diventino report non verificabili. 1. Bloccare il periodo contabile Fissate fuso orario, valuta, sconti per impegno d'uso, crediti promozionali e data di cutoff delle fatture. Congelate il listino prezzi di riferimento e registrate gli ID delle fatture e la finestra di query della telemetria. 2. Riconciliare con le fatture dei provider Collegate gli eventi di telemetria con i file di billing del provider per account, modello, tipologia di token e giorno. Spiegate le voci di input, output, lettura e scrittura cache, token di ragionamento e chiamate a tool, quantificando e investigando ogni residuo. 3. Allocare i costi riconciliati Applicate dimensioni coerenti: funzionalità, team, ambiente, coorte di clienti e workload. Mantenete separati i costi fissi della piattaforma condivisa dal consumo diretto delle singole feature. 4. Spiegare le varianze Costruite un ponte tra il periodo precedente e quello attuale scomponendo la variazione in tariffa, volume, mix ed efficienza. Tracciate il costo p50 e p95 per task completato con successo insieme ai tassi di fallimento e retry. Una chiusura AI affidabile è deliberatamente metodica: ogni dollaro ha un'origine tracciabile, ogni allocazione ha una regola e ogni scostamento ha un responsabile. Correlati Riconciliazione fatture per spesa AI Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # FOCUS 1.5 standardizza il tracciamento token AI · FinOps LLM URL: https://finopsllm.com/it/research/focus-1-5-ai-token-tracking FOCUS 1.5: tracciamento nativo dei token AI e Price Sheet Aggiornato September 19, 2026 · pubblicato inizialmente August 15, 2026 Risposta rapida: La FinOps Foundation ha confermato l'uscita della specifica FOCUS 1.5 per dicembre 2026. Per la prima volta lo standard aperto per i costi cloud introduce campi nativi per i carichi di lavoro AI:... La FinOps Foundation ha confermato l'uscita della specifica FOCUS 1.5 per dicembre 2026. Per la prima volta lo standard aperto per i costi cloud introduce campi nativi per i carichi di lavoro AI: identificatore del modello, tracciamento distinto dei token di input e output e un dataset dedicato Price Sheet per i listini dei provider. 1. I vantaggi di FOCUS 1.5 Standardizzazione del modello: Denominazione coerente tra cloud provider eterogenei. Metriche token dettagliate: Campi separati per input, output e letture da cache invece di somme indistinte. Dataset Price Sheet: Distinzione netta tra listini ufficiali e consumi effettivi per verificare sconti negoziati. 2. Limiti della specifica FOCUS standardizza le fatture generate dai cloud provider, ma non risolve l'attribuzione interna aziendale . I fornitori non conoscono quale funzionalità o centro di costo abbia inviato la chiamata; tale associazione deve essere garantita dal gateway aziendale. 3. Come prepararsi Iniziate a memorizzare i token disaggregati per tipologia, mantenete l'identificatore del modello in ogni record e riconciliate mensilmente la telemetria con le fatture ufficiali. Correlati Attribuzione dei costi LLM Riconciliazione fatture per spesa AI Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Claude Max vs Alibaba Token Pro: costo agentic · FinOps LLM URL: https://finopsllm.com/it/research/heavy-agentic-coding-cost-claude-vs-qwen Claude Max vs Alibaba Token Pro: quanto costa davvero il coding agentico Aggiornato September 19, 2026 · pubblicato inizialmente August 6, 2026 Risposta rapida: Quando lo sviluppo autonomo evolve da semplici completamenti a swarm multi-agente (dove un coordinatore attiva da 4 a 8 sotto-agenti paralleli per test, refactoring e controlli di sicurezza), il... Quando lo sviluppo autonomo evolve da semplici completamenti a swarm multi-agente (dove un coordinatore attiva da 4 a 8 sotto-agenti paralleli per test, refactoring e controlli di sicurezza), il consumo computazionale aumenta vertiginosamente. Valutare questi piani in base al prezzo nominale dei token porta a conclusioni errate. 1. Modelli di tariffazione eterogenei Alibaba Token Pro ($70/mese) stabilisce tetti definiti di 12.000 crediti ogni 5 ore e 40.000 crediti ogni 7 giorni su Qwen 3.8-Max, con uno sconto notturno (moltiplicatore 0,2×). Claude Max 20x ($200/mese) offre capacità burst dinamica per Opus 5 senza quote pubbliche prefissate, privilegiando accuratezza al primo tentativo e minor dispersione di chiamate. 2. Formula di break-even per task accettato Sul solo canone mensile ($70 contro $200), Qwen 3.8-Max deve raggiungere solo il 35% della produttività in task completati rispetto a Opus 5 per risultare più vantaggioso per singola feature. Tuttavia, calcolando il tempo sviluppatore a $50/ora, se Opus 5 consente di risparmiare appena 2,6 ore al mese di revisione ed editing manuale, il differenziale di $130 è pienamente ammortizzato. Correlati Audit dei costi: Alibaba vs Claude Max Perché i prezzi dei provider IA non sono comparabili Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Runbook per picchi di costo LLM in produzione · FinOps LLM URL: https://finopsllm.com/it/research/llm-cost-spike-runbook Runbook di produzione per picchi di costo LLM Aggiornato August 27, 2026 · pubblicato inizialmente August 27, 2026 Risposta rapida: Quando la spesa per gli LLM subisce un picco improvviso, non iniziate modificando il modello. Conservate innanzitutto le prove, verificate i segnali di fatturazione e isolate se l'anomalia dipende da... Quando la spesa per gli LLM subisce un picco improvviso, non iniziate modificando il modello. Conservate innanzitutto le prove, verificate i segnali di fatturazione e isolate se l'anomalia dipende da volume, tariffe, mix di modelli o efficienza. Primi 15 minuti: confermare e preservare Salvate fatture, telemetria del gateway, traffico corrente, mix di modelli e log dei recenti deployment prima di apportare modifiche. Primi 30 minuti: contenimento sicuro Applicate il controllo più circoscritto possibile: mettete in pausa un flusso anomalo, limitate un agente, instradate carichi su batch o disattivate una feature appena rilasciata. Assegnate a ogni misura un responsabile e una data di scadenza. Identificare la causa radice Verificate volumi, composizione dei token, lunghezza del contesto, chiamate a tool e tariffe dei provider confrontando il costo per task riuscito con la baseline. Correlati Monitoraggio costi LLM Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Controllo costi di token per schemi MCP · FinOps LLM URL: https://finopsllm.com/it/research/mcp-tool-definition-overhead Controllo dei costi di token degli schemi MCP nei flussi agentici Aggiornato September 19, 2026 · pubblicato inizialmente September 19, 2026 Risposta rapida: Collegare un agente IA a molteplici server Model Context Protocol (MCP) inietta migliaia di token di input a ogni turno prima ancora di elaborare la richiesta dell'utente. Ogni strumento registrato... Collegare un agente IA a molteplici server Model Context Protocol (MCP) inietta migliaia di token di input a ogni turno prima ancora di elaborare la richiesta dell'utente. Ogni strumento registrato aggiunge uno schema JSON contenente nomi di funzioni, descrizioni dei parametri e vincoli di tipo. In un ambiente enterprise con 6 server MCP collegati (GitHub, Postgres, Slack, Jira), questo preambolo consuma da 4.500 a 12.000 token per chiamata API, generando costi fissi significativi. Perché le definizioni degli strumenti MCP costano così tanti token? Ogni strumento MCP richiede metadati estesi in formato JSON Schema affinché il modello capisca come formattare la chiamata. Un singolo strumento SQL avanzato può richiedere fino a 600 token. Su decine di strumenti aziendali, gran parte della finestra di contesto viene occupata da schemi statici anziché dalla conversazione reale. Tre architetture di mitigazione I team di piattaforma riducono questo sovraccarico applicando punti di interruzione del prompt caching subito dopo i contratti degli strumenti, implementando un routing dinamico a due stadi per caricare solo i tool rilevanti, e minificando le descrizioni degli schemi JSON. Correlati Strumenti server e fatturazione Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # I tagli di prezzo dei modelli non riducono i costi · FinOps LLM URL: https://finopsllm.com/it/research/model-price-cuts-routing-budget Tagli di prezzo dei modelli e routing budget Aggiornato September 10, 2026 · pubblicato inizialmente September 10, 2026 Risposta rapida: Un listino prezzi più basso genera risparmi solo se i carichi migrano verso i tier opportuni. Misura sempre il costo per task completato. Un listino prezzi più basso genera risparmi solo se i carichi migrano verso i tier opportuni. Misura sempre il costo per task completato. Correlati Costo per task completato Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # L'osservabilità AI può diventare una seconda fattura · FinOps LLM URL: https://finopsllm.com/it/research/observability-second-llm-bill Osservabilità AI come seconda fattura Aggiornato September 9, 2026 · pubblicato inizialmente September 9, 2026 Risposta rapida: Valutare ogni risposta con un altro modello crea una spesa secondaria considerevole. Campiona il traffico e assegna le spese alle feature monitorate. Valutare ogni risposta con un altro modello crea una spesa secondaria considerevole. Campiona il traffico e assegna le spese alle feature monitorate. Correlati Controllo dei costi di valutazione Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # I livelli di sforzo di Opus 5.5 sono il vero prezzo · FinOps LLM URL: https://finopsllm.com/it/research/opus-5-5-effort-level-cost I livelli di sforzo di Opus 5.5 sono il vero prezzo Aggiornato September 22, 2026 · pubblicato inizialmente September 22, 2026 Claude Opus 5.5 costa $4 per milione di token di input e $20 per milione di token di output. Ciò rappresenta il 20% in meno di Opus 5. La tariffa è la metà minore del racconto dei costi. L'altra metà è l'impostazione effort , che decide quanti token il modello spende ragionando prima di rispondere. Un modello, cinque prezzi Opus 5.5 espone lo sforzo da low fino a medium , high , xhigh e max . Ogni livello è lo stesso modello alla stessa tariffa per token, ma produce un numero molto diverso di token. L'analisi indipendente riportata da The Decoder ha trovato che quattro dei cinque livelli si trovano sulla frontiera di Pareto costo-performance. Ha anche rilevato che a massimo sforzo Opus 5.5 ha utilizzato circa 119.000 token di output per attività, molto più dei modelli concorrenti alle loro impostazioni massime. A 20 $ per milione, 119.200 token di output costano 2,38 $ per attività prima di qualsiasi input. A medium, Artificial Analysis ha misurato 25.700 token di output, cioè 0,51 $. Contando l'input, max costa 5,98 $ per attività e medium 1,34 $: lo stesso modello costa circa 4,5 volte di più per attività a seconda di un solo parametro della richiesta. Misurato sull'Artificial Analysis Intelligence Index v4.3.2 (dieci valutazioni), consultato il 22 settembre 2026. Tutte le righe usano la stessa suite di test, quindi si confrontano direttamente. Modello e sforzo Intelligence Index Costo per attività Token di output per attività Sulla frontiera costo–prestazioni Opus 5.5 · low 42.3 $0.55 10,200 No Opus 5.5 · medium 51.2 $1.34 25,700 Sì Opus 5.5 · high 53.6 $1.82 35,600 Sì Opus 5.5 · xhigh 56.0 $3.46 65,700 Sì Opus 5.5 · max 57.6 $5.98 119,200 Sì Opus 5 · high (riferimento) 48.1 $3.61 46,200 No Fonte: Artificial Analysis. Sulla frontiera significa che nessuna impostazione di GPT-6 Sol, GPT-6 Astra, Opus 5, Opus 5.5 o Fable 5.1 ottiene di più spendendo meno. Opus 5.5 low ne resta fuori perché GPT-6 Sol a xhigh ottiene 44,1 per 0,53 $. Passare da xhigh a max aggiunge 1,6 punti con il 73% di costo in più. Medio è l'impostazione su cui Anthropic fa i benchmark Il principale confronto di Anthropic viene fatto a sforzo predefinito, che è medio. Dice che Opus 5.5 a medio supera GPT-6 Astra a massimo sforzo nel lavoro di conoscenza per circa un quinto del costo per attività. Quindi il caso stesso di Anthropic per il modello è costruito su medio, e max è l'eccezione. Un team che imposta max ovunque "per stare al sicuro" paga i token che i benchmark di lancio non necessitavano. Come impostare lo sforzo senza indovinare Predefinito a medio. Rendilo il valore esplicito nel codice, non un default SDK che può cambiare sotto di te. Alza lo sforzo per rotta, non globalmente. Debug difficile, pianificazione a lungo orizzonte e step di revisione finale possono giustificare alto o max. Classificazione, estrazione e modifiche di routine raramente. Registra lo sforzo con ogni richiesta. Il costo per richiesta non è interpretabile senza. Un picco di spesa con conteggio di richieste piatto è di solito un cambio di sforzo. Confronta i livelli di sforzo sugli stessi compiti riprodotti. Registra il tasso di successo e i token di output per attività completata a ogni livello, e smetti di aumentare lo sforzo quando il successo smette di migliorare. Limita l'output dove il prodotto lo consente. Un limite di token massimi vincola il caso peggiore. A massimo sforzo quel limite è l'unica cosa tra un compito in fuga e una richiesta da diversi dollari. Il taglio da $25 a $20 per milione di token di output risparmia il 20%. Spostare un carico di lavoro da max a sforzo medio può risparmiare molto più di questo. Tratta lo sforzo come una linea di bilancio, posseduta e revisionata come qualsiasi altra. Correlati Modello di costo di Claude Opus 5.5 Economia della modalità veloce di Opus 5.5 Guida ai costi del modello di ragionamento Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Opus 5.5 fast mode: 2x prezzo per velocità doppia · FinOps LLM URL: https://finopsllm.com/it/research/opus-5-5-fast-mode-economics Economia di Opus 5.5 fast mode Aggiornato September 22, 2026 · pubblicato inizialmente September 22, 2026 Claude Opus 5.5 ha due listini. Standard è $4 per milione di token in ingresso e $20 per milione di uscita. Fast mode è $8 e $40, esattamente il doppio, per fino a 2,5× la velocità di uscita. Il modello è identico. Il denaro aggiuntivo acquista tempo e basta, quindi l'unica domanda è il tempo di chi. Cosa acquista il premio Prendi uno step che produce 5.000 token di uscita. Ai tariffari standard il costo è $0,10. In fast mode costa $0,20. Se lo step impiega 60 secondi a velocità standard, un speedup di 2,5× lo riduce a circa 24 secondi. Paghi $0,10 in più per risparmiare 36 secondi. Equivale a circa $10 per ogni ora di attesa eliminata. La lunghezza dello step non cambia il rapporto, perché il costo aggiuntivo e il tempo risparmiato crescono con i token di uscita. Dipende dalla tua velocità in modalità standard: questo esempio assume circa 83 token di uscita al secondo. Anche l'ingresso raddoppia, quindi gli step ricchi di prefisso pagano un po' più per secondo risparmiato. Quando è conveniente Uno sviluppatore che attende un agente di coding interattivo. A $10 per ora di attesa eliminata, fast mode costa molto meno del tempo di chiunque sia pagato. Una risposta rivolte al cliente dove la latenza influisce sulla conversione. Valuta il miglioramento di velocità contro l'abbandono, non contro la fattura dei token. Un incidente, dove ogni minuto ha un costo. Quando è puro spreco Agenti in background, lavori notturni e pipeline batch. Nessuno aspetta, quindi la spesa aggiuntiva non compra nulla. Evals e replay. Sono esattamente i carichi di lavoro che moltiplicano i conteggi di token ed eseguono secondo una pianificazione. Subagenti che eseguono in parallelo. Il tempo wall-clock è impostato dal ramo più lento e dall'orchestratore, non da ogni chiamata. Opus 5.5 standard è già circa il 30% più veloce di Opus 5, secondo Anthropic. Alcuni lamenti sulla latenza che avrebbero giustificato fast mode su Opus 5 potrebbero essere risolti solo dall'upgrade. Misura la velocità standard prima di pagare per più. Controlli da implementare Rendi fast mode una decisione esplicita, per route. Non dovrebbe mai essere un default globale o un flag che un ingegnere ha attivato una volta e dimenticato. Contrassegna la spesa per modalità. Una richiesta di fast mode al doppio del prezzo unitario appare come una richiesta normale su un dashboard che raggruppa solo per modello. Avvisa sulla quota di fast mode dei token di uscita. Se aumenta su route dove nessun utente aspetta, qualcosa è stato attivato che non dovrebbe essere. Bilancia sforzo e velocità insieme. Lo sforzo massimo moltiplica il conteggio dei token, e fast mode raddoppia il prezzo di ogni token. È il modo più costoso di eseguire il modello. Correlati Modello di costo Claude Opus 5.5 I livelli di sforzo di Opus 5.5 sono il vero prezzo Limiti di fan-out e concorrenza dei subagenti Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Come misurare il ROI dell'IA senza nascondere errori · FinOps LLM URL: https://finopsllm.com/it/research/prove-ai-roi-measurement Come misurare il ROI dell'IA senza nascondere regressioni qualitative Aggiornato August 27, 2026 · pubblicato inizialmente August 27, 2026 Risposta rapida: Il ROI dell'IA non si dimostra esibendo una fattura cloud ridotta. Si dimostra quando un risultato operativo misurabile migliora più del costo complessivo necessario a generarlo. La misurazione... Il ROI dell'IA non si dimostra esibendo una fattura cloud ridotta. Si dimostra quando un risultato operativo misurabile migliora più del costo complessivo necessario a generarlo. La misurazione richiede tre record collegati: spesa attribuibile per chiamata, esito positivo del task e controllo qualitativo costante per evitare che un output scadente sia scambiato per efficienza. Definire uno scenario controfattuale Indicate cosa sarebbe accaduto senza l'adozione dell'IA: gestione manuale da parte del personale, modello precedente o assenza del servizio. Senza un gruppo di controllo, la crescita dei ricavi o la contrazione dei costi non possono essere attribuite in modo affidabile all'intelligenza artificiale. Adottare il task riuscito come denominatore Misurate il costo per task completato con successo, non per singola richiesta API. Includete nel numeratore chiamate a strumenti, retry, fallimenti e ore di correzione da parte degli operatori. Preservare la qualità dell'output Una riduzione dei costi del 25% che fa crollare il successo dei compiti dal 92% all'80% distrugge valore. Fissate una soglia minima di accuratezza prima di dichiarare qualsiasi risparmio economico. Correlati Costo per task riuscito Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Perché i prezzi dei provider IA non sono comparabili · FinOps LLM URL: https://finopsllm.com/it/research/provider-prices-not-comparable Perché i prezzi di listino dei provider IA non sono direttamente comparabili Aggiornato August 27, 2026 · pubblicato inizialmente August 27, 2026 Risposta rapida: Confrontare i provider IA solo in base al prezzo nominale per milione di token produce risparmi fittizi. I provider fatturano tipi di token differenti, sconti su cache, regole di contesto e chiamate a... Confrontare i provider IA solo in base al prezzo nominale per milione di token produce risparmi fittizi. I provider fatturano tipi di token differenti, sconti su cache, regole di contesto e chiamate a strumenti eterogenee. Un confronto attendibile calcola il costo effettivo per task completato con successo a parità di workload e soglia qualitativa. Normalizzare l'unità fatturabile Costruite una matrice prezzi basata su provider, modello, endpoint, regione, tipologia di token, hit/miss della cache, esecuzione batch e data di validità. Separate input, output, cache-read, cache-write, reasoning token e tool execution. Mantenete impegni minimi e crediti fuori dalla tariffa unitaria base. Normalizzare il carico di lavoro Eseguite un set di prompt uniforme con identici vincoli di contesto, formato di output e test di convalida. Monitorate latenza p50 e p95, tasso di completamento, retry, revisione manuale e accuratezza. Un modello più economico del 30% che richiede il doppio dei retry genera un costo per task superiore. Includere i costi operativi L'arbitraggio tra fornitori comporta complessità ingegneristica: routing dinamico, modifiche al gateway, telemetria, test di conformità ed egress di rete. Indirizzate le richieste verso il provider più economico che soddisfa contemporaneamente soglia di qualità e budget unitario. Correlati Arbitraggio tra provider LLM Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Costo reale per attività: Opus 5.5 vs Sol, Astra, Fable · FinOps LLM URL: https://finopsllm.com/it/research/real-cost-per-task-frontier-models Costo reale per attività dei modelli di frontiera Aggiornato September 22, 2026 · pubblicato inizialmente September 22, 2026 I prezzi di listino dicono quanto costa un token. Non dicono quanto costa un'attività completata, perché i modelli spendono quantità di token molto diverse per fare lo stesso lavoro. Questa pagina mette fianco a fianco il costo per attività misurato e un punteggio di qualità per Claude Opus 5.5, Claude Opus 5, Claude Fable 5.1, GPT-6 Astra e GPT-6 Sol a ogni livello di effort. Ogni cifra ha una fonte e nulla è stimato. La risposta breve: GPT-6 Sol è il modo più economico per raggiungere qualsiasi punteggio fino a 47,5. Sopra 47,5, Opus 5.5 è il più economico a ogni livello. Nessuna impostazione di GPT-6 Astra sopra low, di Opus 5 o di Fable 5.1 è efficiente nei costi: ognuna è battuta per punteggio e prezzo da un'impostazione di Sol o di Opus 5.5. Metodo Tutti i punteggi e i costi vengono dall' Artificial Analysis Intelligence Index v4.3.2, consultato il 22 settembre 2026. L'indice esegue dieci valutazioni: AA-Briefcase, GDPval-AA, AutomationBench-AA, Terminal-Bench 4.0, SciCode, Humanity's Last Exam, GDP.pdf, CritPt, AA-Omniscience e AA-LCR. Artificial Analysis esegue ogni modello a ogni livello di effort tramite l'API del fornitore e registra quanto paga a prezzi di listino. Il costo per attività è questa spesa per attività, divisa tra input e output. Ogni riga usa la stessa suite, quindi le righe si confrontano direttamente. Prima di leggere i numeri valgono due limiti. Primo, l'indice è un solo mix di attività. Il vostro mix sposterà i costi, ed è per questo che l'ultima sezione spiega come misurare i vostri. Secondo, i punteggi di versioni diverse dell'indice non si confrontano, quindi non mescolate queste cifre con numeri pubblicati in precedenza. La scala completa: 26 impostazioni I token di output per attività sono quelli che il modello scrive, ragionamento incluso. Artificial Analysis non pubblica la ripartizione tra input e output per le quattro impostazioni intermedie di GPT-6 Sol, quindi quelle celle riportano n/a. Modello Effort Intelligence Index Costo per attività Costo di input Costo di output Token di output per attività Sulla frontiera GPT-6 Sol none 28.1 $0.33 $0.28 $0.05 4,900 No GPT-6 Sol low 33.9 $0.13 n/a n/a 3,400 Sì GPT-6 Sol medium (predefinito) 39.8 $0.25 n/a n/a 6,500 Sì GPT-6 Sol high 42.8 $0.37 n/a n/a 10,200 Sì GPT-6 Sol xhigh 44.1 $0.53 n/a n/a 16,000 Sì GPT-6 Sol max 47.5 $1.06 $0.74 $0.31 31,200 Sì GPT-6 Astra low 45.8 $0.82 $0.60 $0.22 4,400 Sì GPT-6 Astra medium 49.6 $1.54 $1.06 $0.48 9,600 No GPT-6 Astra high 50.9 $1.73 $1.13 $0.59 11,800 No GPT-6 Astra xhigh 52.4 $2.31 $1.46 $0.85 16,900 No GPT-6 Astra max 52.7 $3.26 $1.90 $1.36 27,200 No Claude Opus 5 low 39.4 $1.10 $0.73 $0.37 14,700 No Claude Opus 5 medium 44.8 $2.19 $1.47 $0.72 29,000 No Claude Opus 5 high (predefinito) 48.1 $3.61 $2.46 $1.16 46,200 No Claude Opus 5 xhigh 49.7 $4.88 $3.36 $1.52 60,700 No Claude Opus 5 max 50.8 $5.86 $4.05 $1.81 72,500 No Claude Opus 5.5 low 42.3 $0.55 $0.35 $0.20 10,200 No Claude Opus 5.5 medium (predefinito) 51.2 $1.34 $0.82 $0.51 25,700 Sì Claude Opus 5.5 high 53.6 $1.82 $1.11 $0.71 35,600 Sì Claude Opus 5.5 xhigh 56.0 $3.46 $2.15 $1.31 65,700 Sì Claude Opus 5.5 max 57.6 $5.98 $3.60 $2.38 119,200 Sì Claude Fable 5.1 low 46.8 $2.37 $1.30 $1.08 21,600 No Claude Fable 5.1 medium 48.9 $2.98 $1.59 $1.39 27,900 No Claude Fable 5.1 high 51.2 $3.91 $2.01 $1.90 38,100 No Claude Fable 5.1 xhigh 53.2 $5.98 $2.96 $3.02 60,500 No Claude Fable 5.1 max 53.4 $7.63 $3.73 $3.90 78,100 No Sulla frontiera significa che nessun'altra impostazione di questa tabella ottiene un punteggio più alto spendendo meno. La frontiera dei costi Dieci delle 26 impostazioni sono sulla frontiera. Ordinate per costo, sono le sole che vale la pena considerare in base al solo prezzo. Tutte le altre pagano di più per lo stesso punteggio o per uno inferiore. Impostazione Intelligence Index Costo per attività Per 10.000 attività GPT-6 Sol · low 33.9 $0.13 $1,300 GPT-6 Sol · medium 39.8 $0.25 $2,500 GPT-6 Sol · high 42.8 $0.37 $3,700 GPT-6 Sol · xhigh 44.1 $0.53 $5,300 GPT-6 Astra · low 45.8 $0.82 $8,200 GPT-6 Sol · max 47.5 $1.06 $10,600 Claude Opus 5.5 · medium 51.2 $1.34 $13,400 Claude Opus 5.5 · high 53.6 $1.82 $18,200 Claude Opus 5.5 · xhigh 56.0 $3.46 $34,600 Claude Opus 5.5 · max 57.6 $5.98 $59,800 La frontiera ha due zone. Da 0,13 $ a 1,06 $ è quasi solo GPT-6 Sol, con GPT-6 Astra low a 0,82 $ come unica eccezione. Da 1,34 $ in su è solo Opus 5.5. Il salto tra le due zone è piccolo: Opus 5.5 medium ottiene 3,7 punti in più di Sol max per 0,28 $ in più per attività. Testa a testa a punteggio uguale o migliore Ogni coppia confronta un'impostazione più economica con una più cara che ottiene un punteggio uguale o inferiore. Impostazione più economica Impostazione più cara Scarto di punteggio Risparmio Opus 5.5 medium: 51.2, $1.34 Opus 5 high: 48.1, $3.61 +3.1 per Opus 5.5 63% Opus 5.5 medium: 51.2, $1.34 Opus 5 max: 50.8, $5.86 +0.4 per Opus 5.5 77% Opus 5.5 medium: 51.2, $1.34 Fable 5.1 high: 51.2, $3.91 pari 66% Opus 5.5 high: 53.6, $1.82 GPT-6 Astra max: 52.7, $3.26 +0.9 per Opus 5.5 44% Opus 5.5 high: 53.6, $1.82 Fable 5.1 max: 53.4, $7.63 +0.2 per Opus 5.5 76% GPT-6 Sol max: 47.5, $1.06 Opus 5 high: 48.1, $3.61 +0.6 per Opus 5 71% La riga di Opus 5 conta per i team che non hanno ancora migrato. Opus 5 funzionava di default a effort high. Opus 5.5 funziona di default a medium e, con quel valore, ottiene 3,1 punti in più per il 63% in meno per attività. Anthropic dichiara che Opus 5.5 costa il 40% in meno di Opus 5; lo scarto misurato su questo indice è più ampio di quanto dichiarato. Dove vanno i soldi: input, non output Per ogni modello, l'input vale tra circa la metà e i tre quarti del costo per attività. Per Opus 5.5 a medium, 0,82 $ su 1,34 $ sono input, cioè il 61%. Per GPT-6 Astra a max è il 58%, per GPT-6 Sol a max il 70% e per Fable 5.1 a max il 49%. Le attività da agente rinviano il contesto crescente a ogni passo, quindi la spesa di input cresce con il numero di passi e non solo con la lunghezza della risposta. Per questo GPT-6 Sol senza ragionamento costa più che a low: 0,33 $ contro 0,13 $, anche se scrive solo 4.900 token di output. 0,28 $ dei 0,33 $ sono input. La causa probabile sono più passi, ognuno dei quali rinvia il contesto. Spegnere il ragionamento non rende un agente più economico se poi gli servono più turni. Per la vostra bolletta, questo significa che la cache conta quanto la scelta del modello. Opus 5.5 e GPT-6 Sol fanno pagare 0,20 $ per milione di token di input in cache. GPT-6 Astra fa pagare 1,00 $ e Opus 5 0,50 $. Volume di token contro prezzo di listino GPT-6 Astra è qui il modello più parsimonioso con i token. A effort max scrive 27.200 token di output per attività, contro 119.200 di Opus 5.5 max. Ma Astra costa 10 $ e 50 $ per milione, 2,5× la tariffa di Opus 5.5. Vince il prezzo di listino: Opus 5.5 high costa 1,82 $ per attività con 53,6 punti, mentre Astra max costa 3,26 $ con 52,7. Opus 5.5 a max è l'unico punto in cui la prolissità pesa. I suoi 119.200 token di output costano 2,38 $ prima di qualsiasi input, e l'attività completa costa 5,98 $. Compra il punteggio più alto della tabella, 57,6, ma a 4,5× il costo di medium. Rendimenti decrescenti per livello di effort Ogni riga mostra cosa compra un livello di effort in più, in punti di indice contro il costo aggiuntivo per attività. Modello medium → high xhigh → max GPT-6 Sol +3.0 punti per +48% +3.4 punti per +100% GPT-6 Astra +1.3 punti per +12% +0.3 punti per +41% Claude Opus 5 +3.3 punti per +65% +1.1 punti per +20% Claude Opus 5.5 +2.4 punti per +36% +1.6 punti per +73% Claude Fable 5.1 +2.3 punti per +31% +0.2 punti per +28% Per Fable 5.1 e GPT-6 Astra, l'effort max non compra quasi nulla: 0,2 e 0,3 punti per il 28% e il 41% in più. Per Opus 5.5 il passaggio a max compra ancora 1,6 punti, ma costa il 73% in più. Usate max solo nelle attività in cui avete misurato che i punti extra cambiano il risultato. Quando GPT-6 Sol max basta L'indice è una media, e il divario tra Sol max e Opus 5.5 medium non è uniforme. Punteggi per valutazione secondo Artificial Analysis: Valutazione Opus 5.5 medium ($1.34) GPT-6 Sol max ($1.06) Terminal-Bench 4.0 52.5 43.9 AutomationBench-AA 61.2 61.6 GDPval-AA (Elo) 1576 1487 AA-Briefcase (Elo) 1642 1483 Humanity's Last Exam 54.7 47.9 SciCode 59.3 57.6 CritPt 27.7 30.9 AA-LCR 84.3 83.7 Su AutomationBench e CritPt, GPT-6 Sol eguaglia o supera Opus 5.5 a medium per 1,06 $ per attività contro 1,34 $. Su Terminal-Bench, sulle valutazioni di lavoro della conoscenza e su Humanity's Last Exam, Opus 5.5 è nettamente avanti. L'automazione dei flussi di lavoro può girare su Sol. Gli agenti da terminale e di coding e il lavoro della conoscenza con molti documenti sono dove Opus 5.5 giustifica il prezzo. Dati del fornitore contro dati indipendenti I dati dei fornitori e quelli indipendenti spesso divergono, perché usano harness e impostazioni diversi. Anthropic dichiara il 66,4% su Terminal-Bench 4.0 per Opus 5.5 a xhigh. Artificial Analysis misura il 59,6% allo stesso effort. Effort Opus 5.5 Fable 5.1 low 31.3% 40.4% medium 52.5% 44.9% high 56.6% 52.0% xhigh 59.6% 55.1% max 59.6% 52.0% Anche la classifica cambia con l'indice. Nel Vals AI Index, Fable 5.1 è primo con il 68,83%, GPT-6 Astra terzo con il 66,61% e Opus 5.5 quarto con il 66,16%. Lì il costo per attività non è pubblicato sulla stessa base, quindi non sposta la frontiera sopra. Un indice è solo un punto di vista. Prezzi di listino e un'attività con molta cache Digital Applied ha calcolato il prezzo di un'attività da agente con molta cache su ogni modello: 8M token di lettura cache, 400K di input non in cache, 600K di scrittura in cache e 300K di output. Il risultato segue la frontiera, con una penalità aggiuntiva per GPT-6 Astra. Modello Input $/MTok Output $/MTok Lettura cache $/MTok Attività con molta cache (Digital Applied) GPT-6 Sol $2.00 $10.00 $0.20 $6.90 Claude Opus 5.5 $4.00 $20.00 $0.20 $12.20 Claude Opus 5 $5.00 $25.00 $0.50 $17.25 Claude Fable 5.1 $10.00 $50.00 $0.25 $28.50 GPT-6 Astra (≤272K) $10.00 $50.00 $1.00 $34.50 GPT-6 Astra (>272K) $20.00 $75.00 n/a $61.50 GPT-6 Astra fattura l'intera richiesta a 20 $ e 75 $ per milione quando l'input supera i 272K token. Opus 5.5 mantiene un solo prezzo su tutta la finestra da 1M token. Per Opus 5.5 la scrittura in cache costa 5 $ per milione per la cache da 5 minuti e 8 $ per quella da 1 ora, i batch sono fatturati al 50% e la modalità veloce raddoppia il prezzo. Per i dettagli, vedi il Modello dei costi di Claude Opus 5.5 e l' Economia della modalità veloce di Opus 5.5 . Come misurare il vostro costo per attività Registrate i token per attività, non per richiesta: input non in cache, input in cache, scritture in cache e output, sommati su tutti i passi dell'attività. Prendete un campione di qualche centinaio di attività reali e rieseguitelo su due o tre impostazioni candidate, per esempio Sol max, Opus 5.5 medium e Opus 5.5 high. Valutate ogni risultato con lo stesso controllo usato in produzione e contate le attività superate. Dividete la spesa totale per le attività superate. Il costo per attività riuscita è il numero da confrontare, perché un'impostazione economica che fallisce più spesso non è economica. Scegliete l'impostazione più economica che supera la vostra soglia di qualità e inviate a un'impostazione superiore solo le attività fallite. Ripetete il test quando cambia un prezzo o un effort predefinito. Per come l'effort cambia la bolletta di un singolo modello, vedi I livelli di effort di Opus 5.5 sono il vero prezzo . Avvertenze Tutti i costi sono a prezzi di listino dell'API sul mix di attività di Artificial Analysis. Sconti, batch e la vostra cache li modificano. Artificial Analysis etichetta le sue voci di Opus 5.5 e Fable 5.1 come Default Fallback. Leggete le note di metodologia prima di trattare ogni riga come la stessa configurazione API. I punteggi sono solo della versione v4.3.2 dell'indice. Le versioni precedenti usavano altre valutazioni e non si confrontano. L'attività con molta cache di Digital Applied è un carico illustrativo, non una misurazione. I numeri cambiano quando i fornitori cambiano prezzi o impostazioni predefinite. La data di consultazione è il 22 settembre 2026. Fonti Artificial Analysis Intelligence Index Artificial Analysis: Claude Opus 5.5 Artificial Analysis: Claude Opus 5 Artificial Analysis: Claude Fable 5.1 Artificial Analysis: GPT-6 Astra Artificial Analysis: GPT-6 Sol Digital Applied: GPT-6 Sol vs Claude Opus 5.5 cost benchmarks Digital Applied: Claude Opus 5.5 vs GPT-6 Astra Digital Applied: Is Claude Fable 5.1 still worth it? Digital Applied: Claude Opus 5.5 launch pricing and benchmarks Digital Applied: Opus 5.5 vs Grok 4.7 vs Muse Spark 1.3 cost per task Correlati Modello dei costi di Claude Opus 5.5 I livelli di effort di Opus 5.5 sono il vero prezzo Economia della modalità veloce di Opus 5.5 Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Ciclo di retry e spesa occulta di inferenza · FinOps LLM URL: https://finopsllm.com/it/research/retry-loop-hidden-spend Il ciclo di retry che aumenta la spesa di inferenza Aggiornato August 27, 2026 · pubblicato inizialmente August 27, 2026 Risposta rapida: Un retry non è resilienza gratuita: è una nuova chiamata al modello a pagamento. Un agente autonomo può trasformare un errore temporaneo in cinque tentativi fatturati prima ancora che venga segnalato... Un retry non è resilienza gratuita: è una nuova chiamata al modello a pagamento. Un agente autonomo può trasformare un errore temporaneo in cinque tentativi fatturati prima ancora che venga segnalato un blocco. Il primo controllo FinOps consiste nel misurare la tassa sui retry: spesa per retry e fallback divisa per la spesa totale di inferenza. Tracciare l'intero albero dei tentativi Registrate richiesta padre, numero di tentativo, provider, modello, invocazione di tool, latenza, classe di errore, token e risultato finale. Un ID richiesta generico non basta quando un tool genera chiamate annidate; tracciate le relazioni padre-figlio per ricostruire l'intero albero di esecuzione. Distinguere errori utili da sprechi deterministici Ritentare una richiesta per superamento temporaneo di rate limit può recuperare un task prezioso. Ripetere una validazione fallita con il medesimo prompt compra quasi sempre un altro errore identico. Assegnate a ogni categoria di errore un tetto massimo di tentativi e un percorso di fallback appropriato. Fissare budget sul confine del loop Applicate un tetto di token per richiesta, un limite in dollari per workflow e un timeout massimo di esecuzione. I limiti rigidi devono fermare il ciclo a runtime restituendo uno stato recuperabile, senza affidarsi a report mensili. La soluzione durevole non è disabilitare i retry, ma renderli visibili, circoscritti e giustificati da un miglioramento misurabile dell'outcome. Correlati Limiti di spesa per gli agenti Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Crediti IA SaaS: misurare un'unità non controllata · FinOps LLM URL: https://finopsllm.com/it/research/saas-ai-credits-metering Crediti IA SaaS: misurare un'unità non controllata Aggiornato September 2, 2026 · pubblicato inizialmente September 2, 2026 Risposta rapida: Il FinOps sul cloud presuppone un'unità di misura trasparente: un'ora di istanza, una richiesta, un gigabyte. Un credito IA di un fornitore SaaS è l'opposto: è un'unità definita, tariffata e... Il FinOps sul cloud presuppone un'unità di misura trasparente: un'ora di istanza, una richiesta, un gigabyte. Un credito IA di un fornitore SaaS è l'opposto: è un'unità definita, tariffata e modificabile unilateralmente dal vendor nel corso del contratto. Il costo si comporta come un consumo ma non fornisce gli strumenti di governance necessari. Tre criticità del modello a crediti Opacità dell'unità: Due funzionalità possono bruciare quantità di crediti drasticamente diverse per un'azione percepita come identica dall'utente. Tariffa imposta: L'overage (consumo eccedente) è tariffato dal vendor, eliminando la leva di spostare il carico su percorsi più economici. Scadenza senza cumulo: Le quote per utente che non si sommano tra team né si trasferiscono al mese successivo portano a pagare overage su un team mentre i crediti di un altro scadono inutilizzati. Monitorare tramite telemetria autonoma Estraete i dati di utilizzo tramite l'API di amministrazione del fornitore su base pianificata e archiviate la serie temporale indicizzata per utente, team e funzionalità. La dashboard del fornitore mostra il periodo corrente, mentre le vostre analisi riguardano il trend storico. Allocare prima della fattura Mappate i crediti sugli stessi centri di costo usati per il cloud e pubblicate report mensili di showback. I costi non allocati finiscono per default sul budget IT o di piattaforma, l'unico team che non ha influenza sul volume consumato. Tetti amministrativi e rinnovo Impostate un tetto rigido (hard cap) nella console del vendor prima che la spesa venga sostenuta. Dodici mesi di misurazioni proprietarie rappresentano la leva negoziale più forte per richiedere pooling e rollover al momento del rinnovo. Correlati Shadow AI sulle carte aziendali Sconti su spesa impegnata Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Gli strumenti server fatturano fuori dai token · FinOps LLM URL: https://finopsllm.com/it/research/server-tools-are-a-separate-invoice Gli strumenti server sono una fattura separata Aggiornato September 1, 2026 · pubblicato inizialmente September 1, 2026 Risposta rapida: La maggior parte dei modelli di costo per LLM misura una sola cosa: token di input, token di output e costo per milione. Questo modello era corretto quando le richieste generavano solo testo, ma è... La maggior parte dei modelli di costo per LLM misura una sola cosa: token di input, token di output e costo per milione. Questo modello era corretto quando le richieste generavano solo testo, ma è diventato obsoleto con l'arrivo degli strumenti lato server. Web search, fetch e interpreti di codice girano sull'infrastruttura del provider e spesso addebitano una tariffa a chiamata oltre ai token generati. Un singolo turno di un agente può quindi fatturare due volte: una per la ricerca eseguita e una per i token che quel risultato aggiunge al contesto. L'effetto cumulativo del contesto Il secondo addebito è quello più insidioso. Ogni risultato di un tool viene aggiunto alla conversazione e ogni turno successivo lo reinvia per intero come input. Dieci ricerche all'inizio di una lunga sessione significano dieci tariffe di ricerca più i relativi payload di token riletti a ogni turno successivo. Tre controlli operativi Limitare il numero di chiamate ai tool per sessione, troncare e riassumere i contenuti prima di inserirli nel contesto, e memorizzare nella cache il prefisso stabile del prompt. Correlati Economia del prompt caching Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Lo streaming abbandonato costa comunque denaro · FinOps LLM URL: https://finopsllm.com/it/research/streaming-abandoned-generations-cost Streaming e costi delle generazioni abbandonate Aggiornato September 9, 2026 · pubblicato inizialmente September 9, 2026 Risposta rapida: Chiudere il browser non ferma il modello senza un segnale esplicito. Propaga l'interruzione all'endpoint del provider per evitare token fantasma. Chiudere il browser non ferma il modello senza un segnale esplicito. Propaga l'interruzione all'endpoint del provider per evitare token fantasma. Correlati Costi nascosti nei loop di retry Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Bloccare il fan-out incontrollato di subagenti · FinOps LLM URL: https://finopsllm.com/it/research/subagent-fan-out-concurrency-limits Bloccare la cascata di subagenti e la delega ricorsiva Aggiornato September 19, 2026 · pubblicato inizialmente September 19, 2026 Risposta rapida: La proliferazione a cascata dei subagenti si verifica quando un orchestratore suddivide un compito in sotto-attività parallele e concede ai worker la facoltà di istanziare ulteriori agenti... La proliferazione a cascata dei subagenti si verifica quando un orchestratore suddivide un compito in sotto-attività parallele e concede ai worker la facoltà di istanziare ulteriori agenti specializzati. Senza limiti stringenti di concorrenza e profondità, un singolo prompt può innescare un'esplosione esponenziale: 1 supervisore genera 6 pianificatori, ciascuno dei quali avvia 4 agenti di ricerca. In pochi minuti vengono bruciati milioni di token con picchi di fatturazione inattesi. Cos'è una cascata di fan-out di subagenti nell'IA autonoma? È un'anomalia architetturale in cui un supervisore genera ricorsivamente agenti figli e nipoti senza tetti di spesa globali, moltiplicando i consumi in modo esponenziale su thread paralleli. Quattro protezioni essenziali per la produzione I team di piattaforma impediscono queste derive imponendo un tetto massimo di ricorsione a 2 livelli (orchestratore a worker), allocando un pool di token condiviso a livello di sessione radice, impostando circuit breaker per limitare la concorrenza a 3–5 agenti simultanei e propagando contesti di tracciamento OTLP. Correlati Tre budget per gli agenti Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # I tre budget per ogni agente IA autonomo · FinOps LLM URL: https://finopsllm.com/it/research/three-agent-budgets I tre budget operativi per controllare gli agenti IA autonomi Aggiornato August 27, 2026 · pubblicato inizialmente August 27, 2026 Risposta rapida: Un agente autonomo necessita di più di un semplice avviso mensile di spesa. Ha bisogno di tre budget applicati direttamente nel suo loop di esecuzione: un budget di richiesta per la singola chiamata,... Un agente autonomo necessita di più di un semplice avviso mensile di spesa. Ha bisogno di tre budget applicati direttamente nel suo loop di esecuzione: un budget di richiesta per la singola chiamata, un budget di workflow per l'intero compito, e un budget giornaliero per il team o tenant. Ciascuno previene una diversa modalità di guasto. 1. Budget di richiesta Plafona token, chiamate a tool o costi per un singolo tentativo. Protegge da contesti giganti o output prolissi. 2. Budget di workflow Traccia l'intento dell'utente attraverso retry, fallback e subagenti delegati tramite un correlation ID. Blocca i loop infiniti. 3. Budget giornaliero Limita la spesa complessiva di un team o servizio, controllando il raggio d'impatto. Rendere utili i blocchi Un rifiuto deve spiegare quale limite è scattato, quanto è stato consumato e fornire un percorso di recupero o fallback. Correlati Limiti di spesa per agenti Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Prezzi token in calo ma bolletta LLM in aumento · FinOps LLM URL: https://finopsllm.com/it/research/token-prices-bill-keeps-rising Perché i prezzi dei token scendono ma le bollette LLM aumentano Aggiornato August 27, 2026 · pubblicato inizialmente August 27, 2026 Risposta rapida: Un prezzo per token inferiore non garantisce una fattura più leggera. In produzione l'utilizzo cresce spesso più rapidamente della riduzione dei prezzi: finestre di contesto più ampie, più passaggi... Un prezzo per token inferiore non garantisce una fattura più leggera. In produzione l'utilizzo cresce spesso più rapidamente della riduzione dei prezzi: finestre di contesto più ampie, più passaggi autonomi degli agenti, output prolungati e retry frequenti possono vanificare anche uno sconto del 40%. La diagnosi FinOps corretta separa quattro varianze: tariffa, volume, mix ed efficienza. La tariffa è solo un pezzo del puzzle Se un provider riduce il prezzo blended da 10 a 6 dollari per milione di token, ma i consumi mensili balzano da 100 a 220 milioni di token, la fattura sale da 1.000 a 1.320 dollari. Il prezzo è sceso del 40%, ma la spesa complessiva è aumentata del 32%. Tracciate le tariffe effettive per modello e tipologia di token (input, output, cache-read, cache-write, reasoning) senza aggregarle in medie generiche. Volume, mix ed efficienza Volume è il quantitativo totale di token consumati. Mix indica dove sono stati consumati: modelli di ragionamento avanzati o contesti estesi cambiano il conto senza variare il numero di chiamate. Efficienza misura il costo necessario per erogare un risultato utile: retry, tool falliti, prompt prolungati e output mai visualizzati dagli utenti. Cosa ottimizzare per primo Non forzate tutte le richieste sul modello più economico. Individuate prima la componente di varianza con il maggiore impatto economico: se prevale il volume, ottimizzate finestre di contesto e loop; se prevale il mix, definite policy di routing; se prevale l'efficienza, eliminate chiamate duplicate e retry deterministici. Correlati Monitoraggio dei costi LLM Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # Cos'è DeepSeek Harness? Guida e architettura · FinOps LLM URL: https://finopsllm.com/it/research/what-is-deepseek-harness Cos'è DeepSeek Harness? Guida completa Aggiornato August 16, 2026 · pubblicato inizialmente August 16, 2026 Risposta rapida: DeepSeek Harness — nome del pacchetto dsh — è un harness per agenti open source rilasciato da DeepSeek AI con licenza MIT. Questa è la guida essenziale: cos'è, come avviarlo, come è strutturato e... DeepSeek Harness — nome del pacchetto dsh — è un harness per agenti open source rilasciato da DeepSeek AI con licenza MIT. Questa è la guida essenziale: cos'è, come avviarlo, come è strutturato e perché è rilevante per chi gestisce costi AI. La differenza fondamentale tra modello e harness Un modello linguistico genera unicamente testo e chiamate di strumenti. Tutto il resto che rende un agente autonomo operativo e utile appartiene all'harness: assemblare il prompt di sistema, invocare i tool richiesti, applicare i vincoli di sicurezza, registrare la cronologia della sessione, gestire il loop di ragionamento e coordinare i sotto-agenti. Due team che impiegano lo stesso identico modello possono ottenere risultati operativi e fatture mensili radicalmente divergenti: la varianza dipende dall'architettura dell'harness. L'architettura: tutto è un plugin DeepSeek Harness è basato su Cordis , un runtime dove ogni singolo componente è un plugin: l'adattatore del modello, il registro dei tool, il log di sessione e il loop decisionale dell'agente. Questo consente di sostituire o intercettare qualsiasi componente a runtime senza dover biforcare (fork) il repository centrale. Installazione e modalità operativa Il modo più rapido per testarlo è avviare l'interfaccia web locale: npx @deepseek-ai/dsh web Per l'automazione e la CI/CD, la modalità fondamentale è quella headless : pnpm dsh --profile headless "summarize this workspace" Un harness che opera solo in modalità interattiva non può essere inserito nelle pipeline di test automatici né monitorato con rigore nei costi di esecuzione. Economia di esercizio e controllo dei costi L'harness è open source e gratuito sotto licenza MIT, ma l'inferenza dei token si paga. La spesa finale dipende da quanti passaggi compie l'agente per turno, da quanti tool sono caricati nel catalogo e dal numero massimo di round concessi a un obiettivo aperto. Sono scelte architetturali dell'harness a determinare il costo, non il solo prezzo di listino per token. Correlati Guida di installazione e profili Architettura dei plugin e runtime Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito → Torna a finopsllm.com --- # FinOps LLM - AI コスト管理と本番チーム向けの LLM 可観測性 URL: https://finopsllm.com/ja/ FINOPS · LLM FinOps Foundation の原則に基づいて構築 · トークン向けに適応 トークンの時代の AI コスト管理。 FinOps LLM は、本番環境で生成 AI を実行するエンジニアリングチーム向けの AI コスト管理 および LLM 可観測性 プラットフォームです。OpenAI、Anthropic、Bedrock、Gemini 全体での リアルタイム属性分析 · 異常検知 、 チャージバック 、 自動最適化 (ルーティング、キャッシング、圧縮) · プロバイダーの請求書に対する月次調整。 無料監査を予約 → プラットフォームをツアー 請求書ベースの監査 典型的な削減率 40～60% デフォルトで読み取り専用 マルチクラウド app.finopsllm.com / customer-042 / overview DEMO ワークスペース ◧ 概要 ◫ 属性分析 12 ⚡ 異常 3 ↗ 予測 最適化 ◊ ルーティング ⌬ キャッシュ ≡ 圧縮 ファイナンス $ チャージバック ▥ 予算 ✓ 調整 概要 支出 品質 調整 月度支出 $70,280 ↓ ベースラインから 57.4% サンプル節約額 $94,720 請求書で確認済み キャッシュヒット率 38.1% 週単位で +4.2 ポイント 品質デルタ +0.2% 7 日間のアクティブ A/B テスト 日次 LLM 支出 · 過去 45 日間 4 月 5 日 - 5 月 5 日、2026 年 ベースライン ($165K/月) 最適化済み ($70.3K/月) 支出属性分析 · 今月 機能別 RAG · 38% エージェント · 26% メール · 18% 分類 その他 RAG 検索 $26.7K エージェント実行 $18.3K メール作成 $12.6K 分類 $7.7K アクティビティフィード 過去 24 時間 · すべて表示 ! 異常: RAG p95 支出が 7 日平均に対して +38% 14:22 UTC · feature/rag-v2 · 調査 → $ ルーティング v3 がトラフィックの 100% に昇格 11:08 UTC · 予想節約額: $4,820/月 + キャッシュヒット率が 38% のしきい値を超過 09:14 UTC · チューニング済みの無効化 ⚑ 予算 · 「エージェント」チームが月度 78% 06:42 UTC · 自動スロットルが有効 ✓ 2026 年 4 月の調整が署名済み 5 月 1 日 · ベースラインに対して −57.4% すべての主要プロバイダーに対して調整済み OpenAI Anthropic Gemini Bedrock Azure Groq Together Mistral 01 プラットフォーム AI FinOps、 4 つの柱で。 FinOps LLM は、FinOps Foundation フレームワーク - 可視性、属性分析、最適化、説明責任 - を LLM と GenAI 支出にもたらします。同じ規律。異なるコストユニット。 柱 01 可視性 各プロバイダーから取得されたトークンレベルのコストデータ。1 時間ごとに調整。プロバイダー、モデル、機能、チーム、顧客、環境でフィルタリング可能。 OpenAI · Anthropic · Bedrock · Gemini · Azure · Groq · Together 時間単位の取得 · <5 分の調整遅延 デフォルトで読み取り専用 · NDA および DPA はオンデマンド 柱 02 属性分析 & チャージバック 各トークンが機能、チーム、顧客コホートにマッピングされます。月次チャージバックおよびショーバックは、財務システムまたは CSV にエクスポートされます。 カスタム次元 · 機能、チーム、レベル、地域 コホート別支出 · 顧客レベル別 P&L NetSuite · QuickBooks · CSV · API 柱 03 異常検知 支出、レイテンシ、品質が機能の移動ベースラインから逸脱するとリアルタイムアラートが発火します。Slack、PagerDuty、メール - および重要な場合は自動スロットル。 機能別移動ベースライン ·季節性対応 Slack · PagerDuty · メール · webhook オプションの自動スロットル & 予算コンプライアンス 柱 04 自動最適化 モデルルーティング、セマンティックキャッシング、プロンプト圧縮がフィーチャーフラグの背後にデプロイされ、最低 7 日間 A/B テストされ、品質とコスト効果にのみ基づいて本番化します。 ルーティングツリー · リクエスト単位の品質分類 セマンティックキャッシュ · ヒットレイテンシ <10ms 品質 SLO + 回帰時の自動ロールバック 02 最適化 6 つのレバーを、 各契約で 活用します。 ほとんどのチームは 3 つか 4 つの組み合わせです。監査では支出範囲の支配要因を特定し、契約前に節約額を予測します。 01 30～50% モデルルーティング 各リクエストが複雑さで分類され、品質基準を満たす最も安いモデルにルーティングされます。推論にはフラグシップモデル、分類と抽出には小型で高速なモデルを使用。 02 20～40% セマンティックキャッシュ ほぼ重複するプロンプトが埋め込みで識別され、同一の応答が <10ms のキャッシュから提供されます。類似度のしきい値を機能別に調整。 03 15～30% プロンプト圧縮 システムプロンプトは冗長性について監査されます。例は重複排除されます。取得されたコンテキストは LLMLingua スタイルの技術で圧縮されます。各変更は A/B テストされます。 04 10～50% バッチ価格 & 非同期処理 非インタラクティブなワークロードはバッチエンドポイント(最大 50% 割引)にルーティングされ、時間制限のあるルートに対して SLO 対応のキューイングが行われます。 05 20～35% プロバイダー仲裁 同じ機能が 1 つのプロバイダーでは 2～3 倍のコストになることがよくあります。チームが開始した SDK ではなく、ドルあたりの容量でルーティングします。 06 5～15% フォールバックチェーン インテリジェントな再試行と段階的なフォールバックが最悪ケースの過剰プロビジョニングを上回ります。各呼び出しでフラグシップ価格を支払うことなく SLO を維持します。 03 実装 監査。実装。 調整。 繰り返す。 各契約は同じ 4 つのフェーズを従います。ほとんどのお客様は 5 週目の終わりまでに最初のプロバイダー請求書が調整済みになります。 01 第 1 週 監査 各ドルをマップします。 プロバイダー請求書、ゲートウェイログ、使用テレメトリを取得します。金曜日までに、LLM 支出の完全なマップ - プロバイダー、モデル、機能、チーム別 - ドルの浪費で分類されています。 成果物 支出マップ · 優先順位付きの機会 · 固定ベースライン(カウンター署名済み) 02 第 2 週 計画 浪費で分類します。 監査が優先順位付きのエンジニアリング計画に変換され、コンプライアンス体制、レイテンシ SLO、ローンチプロセスが尊重されます。エンドポイントごとに合意された品質ガードレール。各変更に署名。 成果物 エンジニアリング計画 · ルーティングツリー · キャッシュ仕様 · 品質 SLO · ローンチスケジュール 03 第 3～5 週 ローンチ ローンチ & A/B テスト。 FinOps LLM エンジニアが貴社のエンジニアとペアを組み、各最適化をフィーチャーフラグの背後でローンチし、ベースラインに対して 7 日間 A/B テストを実施し、トラフィックの 100% に段階的に展開します。コックピットは同時にアクティベートされます。 成果物 アクティブなコックピット · Slack アラート · 週次レビュー · 最初の調整 04 継続 調整 節約額を複利で増やします。 価格は変動します。トラフィックは変わります。モデルはローンチされます。プラットフォームが逸脱を監視し、節約額が複利になるようにフォローアップを推奨・実装します。毎月、署名済みの節約声明で終わります。 成果物 月次署名済み声明 · 逸脱 & 品質アラート · 継続的なチューニング 04 成果 実際の契約から の数字。 一般的な LLM 最適化レバーからの削減範囲の例。実際のターゲットはプロバイダー請求書監査とワークロード審査後に設定されます。 典型的な削減率 40～60 % 契約間の範囲、アーキテクチャとトラフィックミックスに依存。 節約までの時間 3～5 週 キックオフ → 最初のプロバイダー請求書調整。 品質デルタ +0 .2 % 各変更は最低 7 日間 A/B テストされます。 監査料金 $0 無料 - 実装に対する クレジット。 05 価格 成果報酬型。 契約は 1 つだけで、確認済みの削減額に対して課金されます。Tidal Telemetry は別製品で、ベータ期間中は無料です。 ★ 最も人気 パフォーマンス 無料監査。その後、私たちがお金を節約するときだけ支払います - 固定ベースラインに対して測定され、プロバイダー請求書と調整されます。 15～25 % 確認済み節約額の 節約がなければ手数料なし · 監査は実装に対するクレジット · いつでもキャンセル可能 ✓ 無料監査 · 1 週間のターンアラウンド · カウンター署名済みベースライン ✓ 完全な最適化スタック · ルーティング、キャッシング、圧縮、仲裁 ✓ アクティブなコックピット + チャージバック + 月次署名済み声明 ✓ FinOps LLM チームエンジニアとのペアリング · 週次レビュー ✓ 品質 SLO コンプライアンス & 自動ロールバック ✓ 最小: $20K/月 LLM 支出 無料監査を予約 → セルフサービス · 別製品 Tidal Telemetry 自分でサインアップして運用する可観測性ソフトウェアです。管理契約も営業ゲートもありません。 無料 ベータ期間中 クレジットカード不要 · ベータ利用者は無料プランを維持 ✓ コード 1 行 · 約 50 のライブラリを自動計装 ✓ 標準 OpenTelemetry で取り込み · SDK は任意 ✓ 呼び出しごとのコスト、トークン、レイテンシ、エラーをトレース化 ✓ プロジェクトごとに分離されたストレージと取り込みキー ✓ エージェントによるセットアップ用の MCP サーバー内蔵 ✓ 契約は不要 · 問い合わせなしで利用可能 Tidal Telemetry を見る → 06 よくある質問 一般的な 質問。 何か不足していますか？ hello@finopsllm.com までメールをください - 営業日以内にお返事します。 LLM 向け FinOps とは？ + LLM 向け FinOps は FinOps Foundation フレームワーク（可視性、属性分析、最適化、説明責任）を LLM と GenAI 支出に適用したものです。機能とチーム別のチャージバック・ショーバック、異常検知、予算ガバナンス、モデルルーティング・キャッシング・プロンプト最適化の継続的改善が含まれます。 FinOps LLM は何をしますか？ + FinOps LLM はプラットフォームのライセンスではなく、managed な契約です。OpenAI、Anthropic、Bedrock、Gemini への リアルタイム支出属性分析 、自動化された最適化（ルーティング、キャッシング、圧縮）、プロバイダー請求書との月次調整を提供します。 価格はどのように構成されていますか？ + モデルは 1 つ。無料監査の後、変更前に固定したベースラインに対して確認された月次削減額の 15～25%。ライセンス料、シート数、プラットフォーム最低額はありません。Tidal Telemetry は別製品で、ベータ期間中は無料です。 どのくらい節約できますか？ + 実装後の最初の完全請求サイクルでの典型的な削減は 40～60% で、アーキテクチャとトラフィックミックスに依存します。 どのプロバイダーに対応していますか？ + OpenAI、Anthropic、Gemini & Vertex AI、AWS Bedrock、Azure OpenAI、Groq、Together、Mistral、Cohere、Fireworks、Replicate 、およびほとんどの OSS エンドポイント。マルチプロバイダーデプロイメントは通常、最大の節約面積を持ちます。 FinOps LLM はチャージバック & ショーバックに対応していますか？ + はい。プロバイダー、モデル、機能、チーム、顧客コホート別のトークンレベルの属性分析。月次チャージバック・ショーバックを NetSuite、QuickBooks、CSV、API にエクスポート。カスタムディメンションに対応。 顧客データはどう扱いますか？ + デフォルトで読み取り専用です。 請求書とログイン使用量データはほとんどの属性分析作業に十分です。プロンプトとアウトプット データは、それが必要な特定の最適化のために、明示的な顧客承認でのみアクセスされます。NDA と DPA はご要望に応じて利用可能です。 実装にはどのくらい時間がかかりますか？ + 属性分析とダッシュボードは 1 週間以内 に有効化されます。最適化の実装は 3～5 週間かかり、節約はゴーライブ後の最初の完全プロバイダー請求書に表示されます。 最適化は出力の品質を損ないますか？ + いいえ。各ルーティング、キャッシング、圧縮の変更は本番環境に対して 最低 7 日間 の A/B テストを行ってから昇格させます。リグレッションは自動的にロールバックされます。品質はコストと同時に継続的に監視されます。 07 リソース ガイド、ベンチマーク & ツール。 AI 向け FinOps を評価するエンジニアリングおよび財務リーダー向けの詳細な調査。無料、登録不要、月次更新。 ガイド ↗ LLM 向け FinOps: 完全なフレームワーク 可視性、属性分析、最適化、説明責任 - トークンに適用。30 ページのリファレンスアーキテクチャ付き。 16 分 · 5 月 '26 新規 SEO ガイド -> AI コスト最適化 ルーティング、キャッシング、バッチ処理、プロンプト規律を通じて AI 支出を削減するための実践的プレイブック。 8 分 5 月 '26 チュートリアル ↗ 本番環境でのトークンレベルのコスト属性分析 タギング戦略、チャージバック数学、ゲートウェイ統合パターン。リファレンスコード付き。 11 分 · コード 4.2K 読み取り 運用 ↗ LLM コスト監視 支出の変化が月次請求書に隠れるのを防ぐメトリクス、アラート、オーナー制限。 10 分 OPS ガイド ↗ 請求前の LLM コスト異常の検出 機能別ベースライン、季節性、エンジニアが無視しないアラート設定方法。 9 分 · テンプレート 3.1K 読み取り RAG -> RAG コスト最適化 より良いチャンキング、より厳しいコンテキスト制限、選別的なリランキングで、検索駆動のトークン浪費を削減します。 7 分 実践的 リファレンス ↗ AI FinOps 用語集 属性分析、ショーバック、チャージバック、キャッシュ読み取りトークン、ルーティング、成功したタスク当たりのコストの定義。 リファレンス 無料 ファイナンス ↗ LLM チャージバック & ショーバック AI 支出をチーム別・製品別に報告し、予算配分に変換する方法。 8 分 ガバナンス OpenAI ↗ OpenAI コスト属性分析 OpenAI 支出のリクエストタグ、請求書調整、リトライ、ワークロードクラス。 7 分 実践的 Anthropic -> Anthropic コスト属性分析 調整を壊さずに、機能、オーナー、ワークロード、ルーティング動作別に Anthropic 支出を追跡します。 7 分 新規 ルーティング ↗ モデルルーティング 簡単なリクエストをより安いモデルに送信し、品質、レイテンシ、フォールバック動作を維持する方法。 12 分 アルゴリズム メトリクス -> LLM トークン追跡 AI コスト変化をエンジニアリングと財務に説明可能にするリクエストレベルフィールド。 6 分 OPS 価格設定 ↗ プロバイダー仲裁 移行コストと間接費を過小評価せずに、プロバイダー間で同等のモデル機能を比較します。 11 分 ベンチマーク データ ↗ LLM 機能当たりの価格ベンチマーク · Q2 '26 標準化されたワークロード上の GPT、Claude、Gemini、Mistral、Llama の月次成功したタスク当たりのコスト。 月次更新 Q2 '26 ライブ ケーススタディ ↗ 顧客成果 公開ケーススタディは顧客承認後のみ公開されます。それまでは、評価の参考資料は非公開で扱われます。 NDA 下 正直 08 ここから始める AI 請求書を 責任あるまなざしで 管理します。 約1週間。読み取り専用アクセス。支出の完全なマップ（廃棄物で分類）とコックピットが追跡できるベースラインを返却します。無料。実装コミットなし。 無料監査を予約 → ベンチマークを見る 30 分の発見 · デフォルトで読み取り専用 · NDA + DPA オンデマンド · コミットなし --- # リサーチ · FinOps LLM URL: https://finopsllm.com/ja/research リサーチ AI支出ガバナンスを構築するエンジニアリングおよび財務チーム向けのノート。 ここから始める LLM費用が初めての方向けの分かりやすい解説。 LLMプロバイダーはどのように課金するのか？ 入力、出力、キャッシュ、推論トークンの説明 LLM費用配分とは？ なぜLLM請求書が急増するのか？ AI支出の予算化方法 すべてのリサーチ 30分でLLM支出を監査する方法 A quarter of AI spend is slipping to 2027 (EN) Agent spend attribution (EN) Agent spend guardrails (EN) Agent Spend Guardrails: Runtime Controls That Work (EN) Agent TCO: The 70% of Cost That Isn't Tokens (EN) AI Coding Economics 2026: GLM vs DeepSeek vs Claude (EN) AI Cost Allocation: Tags, Cost Centers and Chargebacks (EN) AI Cost Optimization Checklist for 2026 (EN) AI Cost Optimization: Routing, Caching, Batching (EN) AI Cost Optimization: Six Levers That Actually Work (EN) AI cost recovery playbook: stop the bleeding (EN) AI FinOps: GenAI支出の運用モデル AI observability: cost, traffic, and quality · FinOps LLM (EN) AI 出力への来歴の付与 AI 電子透かしが壊れる仕組み AI 電子透かしのコンプライアンス費用 AI 電子透かしの仕組み AIオブザーバビリティと第2のLLM請求書 AIコーディングプラン比較 AIコード生成を最も安く実行する方法（2026年） AIプロバイダーの価格表をそのまま比較できない理由 AI中心の製品で初めて行う月次締め AI支出の差分を量・料金・構成・効率に分解する AI機能の粗利率は、出荷前に測る AI費用異常検知 Anthropic cost attribution (EN) API 請求書の外にある AI 支出を見つける Azure OpenAI対直接OpenAI費用比較：PTU予約と損益分岐点 Batch APIs as a FinOps lever (EN) Chargeback vs Showback: Picking the Right FinOps Model (EN) Chargeback when your provider won't bill per team (EN) ChatGPT Pro Max $500 plan economics (EN) Claude Fable 5.1 のコストモデル Claude Max 20x isn't 20x. We checked 60 days of logs against Codex (EN) Claude Max 20x vs 5x: is the $200 price worth it? We measured the real weekly usage ceiling (EN) Claude Max対Alibaba Token Pro：Agentic Codingの真の費用 Claude Opus 5.5 コストモデル Claude Sonnet 5 値上げ撤回：$2/$10 が恒久価格に Claude Sonnet 5.5 pricing: what changes, what does not (EN) Claude Sonnet 5.5: the cost-aware model routing guide (EN) Cloud Infrastructure Cost Audit: Alibaba vs Claude Max (EN) Codex auto-compact on GPT-6 Sol: the defaults in the source code, and what raising them costs (EN) Codex usage limit resets: how they work, banked resets and a dated log (EN) Cost per request as a product KPI (EN) Cursor vs Copilot vs Claude Code Cost (EN) DeepSeek Harness：「すべてがプラグイン」が実際にもたらすもの DeepSeek Harnessで支出ガードレールをどこに置くか DeepSeek Harnessドキュメントに学ぶ七つの防御パターン DeepSeek Harnessとは？導入と仕組みの完全ガイド DeepSeek Harnessのゴール、ゴールラウンド、ラルフループ DeepSeek Harnessのサブエージェント：コストを掛け算する委譲 DeepSeek Harnessのツールスコープ、制限、シャドーイング DeepSeek Harnessの導入：プロファイルと初回実行 Enterprise AI procurement and committed spend (EN) Eval cost allocation: who pays for LLM evals (EN) Find the cache miss behind your OpenAI bill (EN) FOCUS 1.5：AIトークン追跡とPrice Sheet標準化の全貌 Gartner's 2026 AI spending forecast (EN) GenAI cost management: controls and analytics (2026) (EN) GPT-5 Pricing and Budget Impact: A 2026 Planning Guide (EN) GPT-5 vs GPT-4o Cost Comparison: When to Upgrade (EN) GPT-5.6 料金ティアガイド：Luna、Terra、Sol GPT-5はいくらかかる？完全な2026年価格ガイド GPT-6 Astra cost model (EN) GPT-6 Luna cost model (EN) GPT-6 pricing: Astra, Sol and Luna (EN) GPT-6 Sol cost model (EN) GPT-6 Sol long-context benchmarks: what has actually been measured, and what is GPT-5.6 Sol (EN) Hidden LLM Costs Beyond Per-Token Pricing (EN) How do LLM providers charge? Tokens, tiers, caching (EN) How many tokens do you get with Claude Pro and Max? We counted them (EN) How much Codex does ChatGPT Pro include? We priced the weekly limit in dollars (EN) How to budget for AI spend: a starter framework (EN) How to cap inference costs and prevent runaway spending (EN) How to check and reduce Claude Code token usage (EN) How to use Jev in an AI agent (EN) Input, output, cache, reasoning: what tokens cost (EN) Invoice reconciliation for AI spend (EN) IT Chargeback and Showback Explained (EN) IT Chargeback and Showback for AI: A Practical Guide (EN) IT Showback: A Practical Guide for Technology Teams (EN) JSON モードとスキーマのトークンコスト Latest AI models and Anthropic's proposed IPO (EN) LLM API価格トラッカー LLM Budget Governance: Alerts and Guardrails (EN) LLM Cost Benchmarks by Industry (EN) LLM cost dashboard: what to put on it (EN) LLM Cost Management: A Practical Framework (EN) LLM Cost Monitoring in Production: A Field Guide (EN) LLM cost monitoring: what to track and how to control it (EN) LLM Cost Per User Benchmarks (EN) LLM Cost Tracking: Tools, Tags and Telemetry (EN) LLM Cost Visibility: Dashboards and Metrics That Matter (EN) LLM FinOps standards (EN) LLM Provider Arbitrage: Price and Quality Parity (EN) LLM Purchasing Guide for Platform Teams (EN) LLM Token Tracking by Input, Output and Cache (EN) LLM Usage Metering: How to Bill Internal AI Spend (EN) LLM 支出の為替エクスポージャー LLM・生成AI向けFinOps：実践フレームワーク LLMコストトレンド 2025–2026 LLMコスト計算機 - 月間AI支出を見積もり LLMチャージバックとショーバック LLMプロバイダー切り替えの本当のコスト LLM評価パイプラインにコスト制御を組み込む LLM費用配分 Long context vs RAG: where the cost breakeven actually is (EN) MCPサーバーのコストインパクト Minimax M3.1 Flash free preview economics (EN) Model deprecation migration: budgeting for forced moves (EN) Model Routing: Cheaper Models, Same Output Quality (EN) Multi-provider, multi-team LLM FinOps (EN) Multimodal cost allocation (EN) NVIDIA Open Agent Safety Platform: the FinOps implications (EN) On-prem and self-hosted LLM FinOps (EN) OpenAI agent message board cost model (EN) OpenAI O / AON always-on agent cost model (EN) OpenAI Ultra Fast API pricing and speed tiers (EN) OpenAIファインチューニング終了の経済学 OpenAI費用配分 OpenTelemetry GenAI conventions for cost attribution (EN) Opus 5.5 fast modeの経済性 Opus 5.5 long-running agent cost analysis (EN) Opus 5.5のエフォートレベルが真の価格を決める Order of LLM cost optimizations (EN) Ox Alpha は GLM-5.3 だった Prompt cache attribution (EN) Prompt caching explained (EN) Prompt Caching ROI: Calculating Real Savings (EN) RAG cost optimization (EN) Real-SWE cost per resolved issue (EN) Reasoning token attribution and chargeback (EN) SaaSのAIクレジット：自社が制御できない単位を計測する Semantic cache economics (EN) September 2026 AI model trends (EN) Showback vs Chargeback: Which Model Fits Your Team? (EN) Silent model downgrades and cost models (EN) Six Jev use cases that actually fit (EN) State of FinOps 2026: 98% now manage AI spend (EN) System One Models and Jev cost optimization (EN) The Token Count Is Lying: Claude Max vs Qwen Audit (EN) The True Cost of Coding Agents: Beyond the API Bill (EN) Token budget implementation (EN) Web検索はエージェントの新たなコストセンター What independent Jev tests say about cost (EN) What is AI value management? (EN) What is LLM cost attribution? A plain-English explainer (EN) What is LLM FinOps? A plain-English definition (EN) What is the Tokenomics Foundation? (EN) Where Jev belongs in an agent workflow (EN) Why agentic AI blows the budget (EN) Why does my LLM bill spike? The most common causes (EN) Why Jev is catching on with agent builders (EN) Why Showback Comes Before Chargeback in FinOps (EN) エージェント经济学：コーディングエージェントは実際にいくらかかるのか？ エージェント運用におけるMCPツール定義のトークンコスト最適化 オープンウェイトモデルの価格計算 オープンソース vs. クローズド：LLMコスト比較 ガードレールとモデレーションの費用 キャッシュ戦略の比較 コスト記録としてのDeepSeek Harnessセッションログ コミット割引と予約容量 コンテキストウィンドウへの二重支払い サーバー側ツールは別の請求書 ステルスモデルの手口 ストリーミング応答と放棄された生成コスト トークン予算実装ガイド トークン価格は下がったのに、LLMの請求額が増えた理由 バックグラウンドエージェントとFinOpsの時間軸 フロンティアモデルのタスク単価の実測 プロンプトの書き方が請求書に出る仕組み モデル値下げとルーティングバジェット リージョン料金とデータ所在地の割増 リアルタイム音声 API のユニットエコノミクス リクエスト単価より成功タスク単価を測る レート制限、429、ティア引き上げ 品質低下を隠さずにAIのROIを証明する方法 埋め込みとベクトルストアの継続コスト 推論コストを静かに増やすリトライループ 推論モデルコストガイド 本番LLMコスト急増のためのランブック 本番外の LLM 支出 画像・動画生成の承認済みアセット単価 自律エージェントに必要な3つの予算 自律型マルチエージェントの拡散と再帰的委譲に伴うトークン急増の抑止 適応的思考とコスト予測 顧客獲得コストとしての無料枠 自分のLLM支出に適用したいですか？FinOps LLMはAI費用の無料監査を実施し、節約場所を示します。 無料監査を予約 → FinOps LLMに戻る --- # 適応的思考がコスト予測を壊した · FinOps LLM URL: https://finopsllm.com/ja/research/adaptive-thinking-cost-forecast 適応的思考とコスト予測 更新日 September 1, 2026 · 初回公開 September 1, 2026 要約: 推論の予算は、かつては自分で決める数値でした。budget_tokens: N を渡せば、N は制御であると同時に予測でもありました。最悪でも 1 リクエストあたり N トークンです。このパラメータは Opus 4.6 と Sonnet 4.6 で非推奨となり、最新モデル — Fable 5 および 5.1、Sonnet 5、Opus 5、4.8、4.7 — では送信すると... 推論の予算は、かつては自分で決める数値でした。 budget_tokens: N を渡せば、N は制御であると同時に予測でもありました。最悪でも 1 リクエストあたり N トークンです。 このパラメータは Opus 4.6 と Sonnet 4.6 で非推奨となり、最新モデル — Fable 5 および 5.1、Sonnet 5、Opus 5、4.8、4.7 — では送信すると 400 が返ります。代わりに thinking: {type: "adaptive"} を使い、難易度に応じてモデル自身が思考量を決めます。 数字はどう変わるか 1 リクエストあたりの平均コストは通常下がります。簡単な要求が不要な推論の代金を払わなくなるからです。一方で 分散は上がります 。難しい要求が上限で打ち切られなくなるためです。「1 リクエストあたり N トークン」という形の予算は、拠り所を失います。 上限ではなく分布を予測する 推論トークンを独立した系列として追跡する。 各レスポンスの usage にすでに含まれています。 パーセンタイルで予算を立てる。 ルートごとに p50 と p99 を置きます。 合計ではなく比率で警報を出す。 プロンプト変更でモデルの負荷が増えたとき、最初に動くのは総トークンに占める推論トークンの比率です。 それでも上限が要る場所 ルート単位・テナント単位の支出上限は今も有効で、暴走ループを止めてくれます。ガードレールを置くべきなのは、そこ、つまり自分が管理する境界です。 関連記事 推論トークンの按分 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # AI 出力に来歴を付けるのは 1 日で終わる · FinOps LLM URL: https://finopsllm.com/ja/research/add-provenance-to-your-ai-output AI 出力への来歴の付与 更新日 September 1, 2026 · 初回公開 September 1, 2026 要約: まず、できないことから始めます。テキストの電子透かしは生成時にモデル提供者が付与するもので、有効化するパラメータは存在せず、後から追加することもできません。より強い証跡が欲しいなら、答えは「マーキングを足す」ことではなく「記録を足す」ことです。その記録は安価で、完全に自社の管理下にあり、出力の出所を証明せよと言われたときに実際に提出されるものです。多くのチームは 1... まず、できないことから始めます。テキストの電子透かしは生成時にモデル提供者が付与するもので、有効化するパラメータは存在せず、後から追加することもできません。より強い証跡が欲しいなら、答えは「マーキングを足す」ことではなく「記録を足す」ことです。 その記録は安価で、完全に自社の管理下にあり、出力の出所を証明せよと言われたときに実際に提出されるものです。多くのチームは 1 日で構築できます。すでにコスト按分のために集めているテレメトリーから、結合ひとつ分の距離しかないからです。 4 つのフィールド 生成物ごとに、 正確なモデル ID とバージョン 、 リージョン 、 タイムスタンプ 、そしてパイプライン全体で出力を追跡できる安定した 成果物 ID を記録してください。最後のひとつが、たいてい省略され、後で必要になるフィールドです。 リクエスト単位の利用記録をすでに出力しているなら、4 つのうち 3 つは揃っています。欠けているのは結合です。コストのテレメトリーはリクエストの発生と金額を知っていますが、それがどの保存済み成果物を生んだかは知りません。 署名済みマニフェストを失わない 提供者から C2PA 署名済みファイルを受け取る場合、目的は単純です。失わないこと。画像変換は既定値に任せず、メタデータを保持するよう明示的に設定し、自社で制御する再エンコードの後には来歴を付け直してください。 人間向けの表示も忘れずに 機械可読なマーキングと、利用者に見える開示は別の問題を解いています。「AI で生成」という可視ラベルは追加コストがゼロで、どの変換にも壊されず、利用者が実際に読むものです。どちらも他方の代替にはなりません。 関連記事 AI 電子透かしが壊れる仕組み この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # エージェント经济学：コーディングエージェントは実際にいくらかかるのか？ · FinOps LLM URL: https://finopsllm.com/ja/research/agent-economics エージェント经济学：コーディングエージェントは実際にいくらかかるのか？ コーディングエージェントは2026年に最も急速に成長しているLLM支出カテゴリーです。すべてのエンジニアリングチームがいずれかを使用しているか、評価しています。しかし、価格モデルは混乱を招きます。サブスクリプションプランは「無制限」という言葉の裏にトークン制限を隠し、APIベースのエージェントは予測不可能に急増する生のコストを露出させ、どちらのモデルも完了したタスクごとに実際にいくら支払っているかを教えてくれません。 この記事では、最も人気のある5つのコーディングエージェントの実際の経済性を分析し、「有用なタスクあたりのコスト」指標を導入し、APIベースのエージェントが使用パターンによってサブスクリプションプランより安くなることも高くなることもある理由を説明します。 価格の全景 コーディングエージェントは2つの価格カテゴリーに分かれます。サブスクリプションエージェントは月額固定料金で使用量が含まれます。APIベースのエージェントは消費されたトークンごとに課金され、通常は自分のプロバイダーアカウントを通じて行われます。正しい選択は、実行するタスクの数、コードベースの大きさ、プロンプトの複雑さによって異なります。 エージェント プラン 月額コスト 含まれるトークン/リクエスト 推定タスク数/月 タスクあたりのコスト メインモデル Cursor Pro $20/月 500高速リクエスト（プレミアムモデル） ~80–150 $0.13–$0.25 Claude Sonnet 4, GPT-4.1 GitHub Copilot Pro+ $39/月 1,500プレミアムリクエスト ~150–300 $0.13–$0.26 Claude Sonnet 4, GPT-4.1 GitHub Copilot Pro $10/月 300プレミアムリクエスト ~30–60 $0.17–$0.33 GPT-4.1, Claude Sonnet 4 Claude Code API（Maxオプション） $5–$100+ Anthropic API経由のトークン課金 ~20–200+ $0.25–$2.00 Claude Sonnet 4 Cline API（BYOK） $5–$80+ 任意のプロバイダー経由のトークン課金 ~20–200+ $0.20–$3.00 ユーザー設定 Windsurf Pro $15/月 500クレジット（プレミアムモデル） ~60–120 $0.13–$0.25 Claude Sonnet 4, GPT-4.1 「タスクあたりのコスト」の実際の意味 上記の表は公表されている範囲を示していますが、実際のタスクあたりのコストは3つの隠れた要因に依存します：コンテキストウィンドウのロード、ツールコールチェーン、リトライループです。新しいAPIエンドポイントを追加するような「簡単な」タスクでも、セッション全体で15K–40Kトークンを消費する可能性があります。複数のファイルにまたがる複雑なリファクタリングは簡単に200Kトークンを超えることができます。 コンテキストウィンドウのロードが最大の隠れたコストです。すべてのコーディングエージェントは、開いているファイル、プロジェクト構造、最近の会話履歴を各API呼び出しにロードします。大きなファイルを持つプロジェクトは、簡単な質問をしている場合でも、リクエストあたりのトークンが増えることを意味します。ツールコールはこれを倍増させます：ファイルの読み取り、grep、編集の各操作は完全なコンテキストを含む別々のAPIラウンドトリップです。 ほとんどのチームが見落とす隠れたコスト リトライループ。 エージェントの最初の試行がテストやリントに失敗すると、自動的にリトライします。各リトライはフルプライスのAPI呼び出しです。実際には、エージェントセッションの20–40%が少なくとも1回のリトライを伴い、そのタスクのトークンコストに30–80%を追加します。 コンテキストオーバーフロー。 長いセッションはコンテキスト制限に達します。これが起こると、エージェントは以前のコンテキストを要約するか（詳細を失う）、初期のメッセージを削除します（コンテキストを失う）。どちらも品質の低い出力とより多くのリトライにつながります。 ツールコールのオーバーヘッド。 単一のタスクで5–15回のツールコール（ファイル読み取り、コード検索、ファイル編集、テスト実行）が発生する可能性があります。各ツールコールには完全な会話コンテキストとツール定義が含まれます。ツール定義だけで呼び出しあたり2K–5Kトークンのシステムプロンプトを消費する可能性があります。 アイドルプレミアムリクエスト。 サブスクリプションプランは、エージェントが役に立たない出力を返した場合でも「高速リクエスト」をカウントします。拒否された提案でも1つのプレミアムリクエストがかかります。 API vs. サブスクリプション：それぞれが勝る場面 APIベースのエージェント（Claude Code、Cline）は、使用量が散発的または軽い場合に勝ちます。月に20–40の集中タスクを実行する場合、タスクあたり$0.30–$0.80の支払いは$20–$39のサブスクリプションより安くなります。特定のタスクに特定のモデルが必要な場合も勝ちます。使用した分だけ支払います。 サブスクリプションエージェント（Cursor、Copilot、Windsurf）は、使用量が安定していてヘビーな場合に勝ちます。月に100以上のタスクを実行する場合、タスクあたりの実効コストは$0.20を下回り、API価格では打ち破るのが難しくなります。予測可能性でも勝ちます。財務チームは固定額を予算計上できます。 クロスポイントは通常、開発者あたり月40–80タスクです。それ以下では、API価格がより安くなります。それ以上では、サブスクリプションプランがより良い経済性を提供します。 「有用なタスクあたりのコスト」指標 生のタスクあたりのコストは誤解を招きます。すべてのタスクが価値を生み出すわけではないからです。失敗した、不正確な回答を返した、手動の再作業が必要なエージェントセッションの実際のコストは有用な出力ゼロです。重要な指標は： 有用なタスクあたりのコスト = 月間総支出 / 手動の再作業なしで出荷されたタスク 実際には、チームはエージェントタスクの60–80%が初回で使用可能な出力を生成すると報告しています。残りの20–40%は手動介入が必要です。これは、有用なタスクあたりの実効コストが生のタスクあたりのコストの1.25倍–1.7倍であることを意味します。 オープンソースモデルで構築したり、コスト効率の高い代替手段を探しているチームには、 MiMO のようなプラットフォームが競争力のある価格を提供し、API vs. サブスクリプションの計算を変える可能性があります。 エージェントコストを削減する方法 コンテキストを切り詰める。 エージェントを呼び出す前に無関係なファイルを閉じる。コンテキストが小さい = 呼び出しあたりのトークンが少ない。 具体的なプロンプトを書く。 曖昧なプロンプトはより多くのツールコールとリトライにつながる。「メールを検証するPOST /usersエンドポイントを追加」は「ユーザーの stuff を修正」より安くなる。 タスク固有のモデルを使用する。 簡単な編集には推論モデルは必要ない。定型的な作業をより安いモデルにルーティングし、複雑なリファクタリングをプレミアムモデルにルーティングする。 トークン使用量を監視する。 セッションあたりのトークン数を追跡する。平均セッションコストが上昇している場合、プロンプトまたはコードベースが予想より速く成長している可能性がある。 リトライ制限を設定する。 タスクあたりの自動リトライを2–3回に制限する。それを超えたら、人間にエスカレートする。 次に期待すること エージェントの価格は急速に動いています。競争が激化するにつれ、サブスクリプションプランは含まれる制限を増やしています。API価格は下落し続けています。Claude Sonnet 4は発売時のClaude 3.5 Sonnetより60%安くなっています。オープンソースのコーディングモデルが品質ギャップを埋めており、API価格をさらに押し下げるでしょう。 最も重要なトレンドはエージェント固有の価格設定です。プロバイダーはタスクごとの価格設定、セッションごとの上限、品質加重課金を実験しています。2026年後半までに、ほとんどのエージェントが生のトークン課金ではなく「成功したタスクあたりのコスト」保証を提供すると予想されます。 関連 AIコーディングプラン比較 - エビデンスに基づくベンチマーク。 エージェント支出配分 - プロジェクトおよびチームごとのエージェントコストの追跡。 エージェント支出ガードレール - コストが暴走する前に制限を設定。 LLM向けFinOps - より広いフレームワーク。 自分のLLM支出に適用したいですか？FinOps LLMはAI費用の無料監査を実施し、節約場所を示します。 無料監査を予約 → リサーチに戻る --- # Web検索はエージェントの新たなコストセンター · FinOps LLM URL: https://finopsllm.com/ja/research/agent-web-search-cost-center Web検索はエージェントの新たなコストセンター 更新日 September 10, 2026 · 初回公開 September 10, 2026 要約: エージェントがリアルタイムWeb検索を利用すると、1つのプロンプトから多数の外部検索と要約モデル呼び出しが発生します。検索レイヤーは隠れたインフラではなく、明確に課金されるコスト項目です。 検索増幅とFinOps管理 タスクIDごとに検索回数とモデル費用を紐付け、成功タスクあたりの総コストを算出して投資対効果を評価します。 エージェントがリアルタイムWeb検索を利用すると、1つのプロンプトから多数の外部検索と要約モデル呼び出しが発生します。検索レイヤーは隠れたインフラではなく、明確に課金されるコスト項目です。 検索増幅とFinOps管理 タスクIDごとに検索回数とモデル費用を紐付け、成功タスクあたりの総コストを算出して投資対効果を評価します。 関連記事 成功タスクあたりのコスト この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # AI機能の粗利率は、出荷前に測る · FinOps LLM URL: https://finopsllm.com/ja/research/ai-feature-gross-margin AI機能の粗利率は、出荷前に測る 更新日 September 2, 2026 · 初回公開 September 2, 2026 要約: 推論は開発費ではなく提供コストです。顧客の操作ごとに走り、利用量に応じて増えます。ローンチまで研究開発として扱えば、実際の粗利は最初の満額請求で初めて分かります。出荷前に計測するステージングで各呼び出しに顧客・処理・結果のタグを付け、現実的なトラフィックを再生します。必要なのは分布です。成功タスク単価のp50・p90・p99と、支払う失敗・リトライの比率。顧客単価に集約する成功タスク単価に想定月間... 推論は開発費ではなく提供コストです。顧客の操作ごとに走り、利用量に応じて増えます。ローンチまで研究開発として扱えば、実際の粗利は最初の満額請求で初めて分かります。 出荷前に計測する ステージングで各呼び出しに顧客・処理・結果のタグを付け、現実的なトラフィックを再生します。必要なのは分布です。成功タスク単価のp50・p90・p99と、支払う失敗・リトライの比率。 顧客単価に集約する 成功タスク単価に想定月間タスク数を掛け、失敗分を加えます。中央値、90パーセンタイル、許容できる最重量顧客の三点でプラン価格と比較します。 四つのコスト要因 毎ターン再課金される長い文脈、全額課金されるリトライ、一操作を多数の呼び出しに広げるエージェント処理、そして簡単な要求を高価なモデルへ送る既定ルーティング。 意思決定に接続する 利用上限、従量課金の併用、既定モデルの低価格化、または見直し期日付きで容認する margin。粗利の独立した行として報告します。 関連記事 成功タスクあたりコスト この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # AI FinOps: GenAI支出の運用モデル · FinOps LLM URL: https://finopsllm.com/ja/research/ai-finops 本番チーム向けAI FinOps AI FinOpsは、モデルが製品の一部になったら、AI支出を管理するための運用モデルです。可観測性だけではなく、調達でもなく、エンジニアリング、製品、財務の間のサイクルです：支出がどこに行くかを理解し、責任を割り当て、ユニット経済を改善し、請求書に対して変更を検証します。 LLMワークロードはこれを緊急にします。支出は使用、コンテキスト長、出力長、リトライ、およびモデル選択とともにスケールするからです。製品の小さな変更は、インフラストラクチャを変更しなくても請求書を変更できます。最高のAI FinOpsプログラムは、モデルゲートウェイと製品分析スタックの近くで生活します。 AI FinOpsに必要なもの プロバイダー請求書正規化。 リクエストレベルのメタデータと製品所有権。 成功したタスクあたりのコストメトリクス。 月末前にアラートする予算。 ルーティング、キャッシュ、バッチ処理、およびプロンプト構造化のための最適化ガイド。 チームが始まる場所 可視性とショーバックで始めます。各製品チームに、LLM支出、それを駆動するエンドポイント、および月ごとの変化を示します。次に、最大の制御可能な要因を選択します。ほとんどのチームにとって、これはモデルルーティング、コンテキスト圧縮、プロンプトキャッシュ、セマンティックキャッシュ、または急ではない作業をバッチAPIsに移動することです。 AI FinOpsは、リリースレビューの一部になったときに成熟します：モデル指向のすべての変更には、品質目標、レイテンシ目標、支出への影響、およびロールバック計画があります。 関連 LLM FinOpsとは？ - LLM支出を管理する運用規律。 LLM向けFinOps - 詳細な運用モデル。 LLM費用配分 - 配分の動作方法。 LLM予算ガバナンス - 予算と低下ルート。 自分のLLM支出に適用したいですか？FinOps LLMはAI費用の無料監査を実施し、節約場所を示します。 無料監査を予約 → リサーチに戻る --- # AI支出の差分を量・料金・構成・効率に分解する · FinOps LLM URL: https://finopsllm.com/ja/research/ai-spend-variance-bridge AI支出の差分を量・料金・構成・効率に分解する 更新日 August 27, 2026 · 初回公開 August 27, 2026 要約: 予測と実績の差を量、料金、構成、効率に分解し、請求、利用、責任者と結び付けます。4つの原因量は需要、料金は実際の請求単価、構成はモデルやワークロードの移動、効率は再試行や人手修正を含む有用な成果1件のコストです。差分の橋渡し予測から始め、料金、量、構成、効率を適用し、請求と照合します。各項目に証拠、金額、担当者、次の行動を置きます。品質も併記します。 予測と実績の差を 量 、 料金 、 構成 、 効率 に分解し、請求、利用、責任者と結び付けます。 4つの原因 量は需要、料金は実際の請求単価、構成はモデルやワークロードの移動、効率は再試行や人手修正を含む有用な成果1件のコストです。 差分の橋渡し 予測から始め、料金、量、構成、効率を適用し、請求と照合します。各項目に証拠、金額、担当者、次の行動を置きます。品質も併記します。 関連記事 LLMコスト監視 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # AI の電子透かしは、もはや費用項目である · FinOps LLM URL: https://finopsllm.com/ja/research/ai-watermarking-compliance-cost AI 電子透かしのコンプライアンス費用 更新日 September 1, 2026 · 初回公開 September 1, 2026 要約: Anthropic は対応する Claude モデルが生成するテキストに知覚できない電子透かしを埋め込み、生成された .svg・.png・.jpg ファイルに C2PA の来歴メタデータを署名付きで付与します。手法は SynthID-Text に基づき、トークン選択の乱数に偏りを与えるもので、意味も品質も変えません。2026 年 9 月 1... Anthropic は対応する Claude モデルが生成するテキストに知覚できない電子透かしを埋め込み、生成された .svg ・ .png ・ .jpg ファイルに C2PA の来歴メタデータを署名付きで付与します。手法は SynthID-Text に基づき、トークン選択の乱数に偏りを与えるもので、意味も品質も変えません。2026 年 9 月 1 日には、規制当局、報道機関、ファクトチェッカー、研究者、そして自ら検証義務を負う企業に向けて検出 API が公開されました。 付与は EU に限らず全世界で行われます。根拠は EU AI 法第 50 条で、その透明性義務は 2026 年 8 月 2 日に発効しました。これらに追加料金はありません。だからこそ予算レビューで見落とされます。費用は実在しますが、請求書には載らないのです。 実際に費用が発生する場所 透かし非対応バージョンに固定したモデルの移行、メタデータを削除している画像パイプラインの改修、検出アクセスの申請手続き、そして呼び出しごとのモデル ID・バージョン・リージョン・タイムスタンプの保持。いずれも実費であり、いずれも単価表には現れません。 バージョン固定という罠 再現性のためにバージョンを固定するのは正しい判断ですが、2026 年 8 月より前のバージョンは機械可読な表示を持たない場合があります。EU の利用者に提供しているなら、安定性のための判断がそのままコンプライアンス上の欠落になり、対処は計画外の移行です。再評価、プロンプト調整、回帰テスト、そして新しい単価が伴います。固定箇所を棚卸しし、それぞれに見直し期日を付けてください。 画像パイプラインが証拠を消している C2PA メタデータはファイルの中にあります。サムネイル生成、CDN の画像変換、フォーマット変換は、容量削減のために既定でメタデータを破棄します。モデル出力だけでなく、生成から配信までの経路全体を検証してください。今なら安く、監査中なら高くつきます。 関連記事 モデル廃止と移行のコスト この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # AI費用異常検知 · FinOps LLM URL: https://finopsllm.com/ja/research/anomaly-detection AI費用異常検知 AI費用異常は、請求書が到着するまで見えないことが多いです。支出はリクエストボリュームが上がらなくても増加する可能性があるからです。デプロイメントは取得したコンテキストを追加し、ルーティング閾値を変更し、キャッシュヒットを削減し、リトライを活性化させ、またはトラフィックをより高価なモデルに移動させることができます。従来のトラフィックアラートはこれらの変化を検出しません。 有用な異常検知器は、総費用だけでなく、費用要因を監視します。毎日の総支出は遅延指標です。初期信号はリクエストあたりのトークン、モデルミックス、取得率、キャッシュヒット率、バッチシェア、および製品表面別の支出です。 監視する信号 エンドポイント、チーム、顧客別の時間あたりの支出。 p50、p90、p99でのリクエストあたりの入出力トークン。 リトライ率、取得率、プロバイダーエラー率。 キャッシュヒット率およびキャッシュで読み取られたトークンのシェア。 デプロイメント後またはプロンプトリリース後のモデルミックスの変化。 誤って同期的に実行されるアクション可能な作業。 ベースライン 複数のベースラインを使用します。サポートボットには日次および週次サイクルがあります。夜間エンリッチメント作業にはバッチウィンドウがあります。評価スイートにはリリース周辺のピークがあります。単一のグローバル閾値は、鈍すぎるか、常に人々を目覚めさせるでしょう。 最適なベースラインは所有者およびワークロードクラス別です。企業全体が一般的な支出限界を超えたときではなく、機能が独自の通常パターンから逸脱したときにアラートします。 実行可能なアラート アラートは要因を説明する必要があります：「デプロイメントY後にエンドポイントXでp90入力トークンが2倍になった」、「キャッシュヒット率が74%から18%に低下した」、または「フロンティアモデルへの取得が31%増加した」。アラートが可能性のある所有者と要因に名前を付けることができない場合、それは無視されます。 応答ループ デプロイコンテキスト、ルーティングポリシーdiff、および最も影響を受けた顧客またはワークロードを添付します。次に、次のステップを提供します：プロンプトを元に戻す、取得数を削減する、ルーティング閾値を復元する、取得を無効にする、または作業をバッチに移動する。異常検知は、請求書の驚きから工学的行動までの時間を短縮するときにのみ価値があります。 関連 LLM費用監視 - 支出のためのダッシュボードと可観測性。 AI可観測性 - 費用信号と運用メトリクス。 なぜLLM請求書が急増するのか - 費用増加の根本原因。 自分のAI支出に適用したいですか？FinOps LLMはAI費用の無料監査を実施し、節約場所を示します。 無料監査を予約 → リサーチに戻る --- # Azure OpenAI対直接OpenAI費用比較ガイド · FinOps LLM URL: https://finopsllm.com/ja/research/azure-openai-vs-direct-cost Azure OpenAI対直接OpenAI費用比較：PTU予約と損益分岐点 更新日 September 19, 2026 · 初回公開 July 12, 2026 要約: グローバル展開の従量課金（Pay-as-you-go）では、Azure OpenAI と直接の OpenAI API は同額です。例えば最新モデルの定価は入力100万トークンあたり2.50ドル、出力15ドルで一致します。両者の真の費用差は基本単価ではなく、PTU（Provisioned Throughput... グローバル展開の従量課金（Pay-as-you-go）では、Azure OpenAI と直接の OpenAI API は同額です。例えば最新モデルの定価は入力100万トークンあたり2.50ドル、出力15ドルで一致します。両者の真の費用差は基本単価ではなく、 PTU（Provisioned Throughput Units）予約 、 リージョン別データ主権プレミアム 、そして マイクロソフトEA（Enterprise Agreement）割引 にあります。 1. PTU予約による大幅な割引 Azure独自のPTU（プロビジョンドスループット）は専用モデル容量を提供します。オンデマンドでは1 PTUあたり1時間2ドルですが、1か月予約を結ぶと月額約260ドルに下がり、 最大82%の割引 （1年予約では最大85%）となります。 PTUの損益分岐点は、持続的なキャパシティ利用率が 約65〜75%以上 のワークロードです。利用率が低く夜間や休日にアクセスが途切れる場合は、直接の従量課金トークンの方が安価に収まります。 2. リージョン別追加コスト グローバルエンドポイントは米国直接価格と一致しますが、日本国内リージョン（東日本）やEUデータゾーンに限定してトラフィックを処理する場合、 10%〜20%の地域プレミアム が加算されます。データガバナンス要件とコスト増のトレードオフを計算する必要があります。 3. インフラ付随費用（TCO） Azure環境ではPrivate Endpoint通信費、Log Analytics、VNetデータ転送料金が加わります。これらは推論費用に4%〜8%上乗せされますが、強固な閉域網セキュリティとActive Directory/RBAC認証が保証されます。 関連記事 年間コミットメント割引の活用法 プロバイダー価格の比較検証 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # バックグラウンドエージェントが変えるFinOpsの時間軸 · FinOps LLM URL: https://finopsllm.com/ja/research/background-agents-cost-clock バックグラウンドエージェントとFinOpsの時間軸 更新日 September 10, 2026 · 初回公開 September 10, 2026 要約: バックグラウンドエージェントはリクエスト・レスポンス型の枠組みを超え、夜間や不在時にもトークンを消費し続けます。タスク単位での予算上限とタイムアウト制御が必須です。 バックグラウンドエージェントはリクエスト・レスポンス型の枠組みを超え、夜間や不在時にもトークンを消費し続けます。タスク単位での予算上限とタイムアウト制御が必須です。 関連記事 自律エージェントに必要な3つの予算 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # キャッシュ戦略の比較 · FinOps LLM URL: https://finopsllm.com/ja/research/caching-strategies-compared キャッシュ戦略の比較 キャッシングは、LLMワークロードに対して最もレバレッジの高いコスト削減戦術の一つです。考え方は単純です：キャッシュされた結果を返せる場合は、推論に支払わないことです。しかし、「キャッシング」は1つの技術ではなく、コスト削減、レイテンシ、精度、実装の複雑さにおいて異なるトレードオフを持つ4つの異なる戦略です。誤った選択はエンジニアリング労力を無駄にし、正しい選択は請求額を30〜70%削減できます。 戦略比較 戦略 仕組み コスト削減 レイテンシへの影響 実装の手間 最適な用途 プロバイダー プロンプトキャッシュ（プロバイダー側） プロバイダーが繰り返されるプロンプトプレフィックスのKV計算をキャッシュします。同じプレフィックスを持つ後続のリクエストは再処理をスキップします。 キャッシュされた入力トークンで50% 最初のトークンレイテンシが60-80%高速化 ゼロ〜低 - ほとんどのプロバイダーで自動 長いシステムプロンプト、共有コンテキストのRAG、エージェントループ OpenAI、Anthropic、Google セマンティックキャッシュ（埋め込みベース） ユーザークエリを埋め込み、ベクトルストアで類似した過去のクエリを検索します。類似度がしきい値を超えた場合、LLMを呼び出さずにキャッシュされた応答を返します。 クエリの繰り返しに応じて20-50% 50-90%高速化（LLM呼び出しなし） 中 - 埋め込みモデル、ベクトルストア、類似度しきい値の調整が必要 FAQボット、カスタマーサポート、繰り返しのクエリ 任意（GPTCache経由でセルフホスト、ベクトル検索付きRedis） コンテキストキャッシュ（Googleスタイル） 大きなコンテキストドキュメント（PDF、コードベース）をサーバー側にキャッシュします。コンテキスト処理に一度支払い、多くのクエリで削減されたコストで再利用します。 コンテキストが重いクエリで70-90% コンテキスト処理の中程度の改善 低〜中 - コンテキストのアップロード、TTL管理 ドキュメントQ&A、大きなリポジトリのコードレビュー、静的コンテキストでのマルチターン Google（Gemini）、Anthropic（拡張思考コンテキスト） アプリケーションレベルキャッシュ（Redis/CDN） リクエスト全体（プロンプト + パラメーター）の決定論的ハッシュ。応答をRedisまたはCDNに保存します。完全一致の場合、キャッシュされた応答を返します。 キャッシュヒット時に最大100% 90-99%高速化（LLM呼び出しなし） 低 - 標準的なキャッシュインフラストラクチャ 決定論的クエリ、分類、固定プロンプトでの抽出 任意（制御するインフラストラクチャ） プロンプトキャッシュの詳細 プロンプトキャッシュは最も簡単な勝利です。OpenAIは1,024トークンを超えるプロンプトを自動的にキャッシュします。Anthropicは2,048+トークンのプレフィックスをキャッシュします。キャッシュは正確なプレフィックスでキーされます - 同じシステムプロンプト、同じfew-shotサンプル、同じドキュメントコンテキスト。キャッシュヒットが発生すると、入力トークンのキャッシュされた部分に対して50%少なく支払います。 注意点：キャッシュの無効化はプロバイダーが制御します。プロンプトがわずかに変更されても - システムメッセージが異なる、プレフィックス内の変数が異なる - キャッシュはミスします。安定したコンテンツをプロンプトの先頭に配置し、動的コンテンツをプロンプトの末尾にプッシュするよう設計してください。 セマンティックキャッシュの詳細 セマンティックキャッシュは、以前に類似した質問がされた場合、LLMを完全にスキップします。フロー：クエリを埋め込み、ベクトルストア（Pinecone、Qdrant、ベクトル検索付きRedis）を検索、トップ結果が類似度しきい値（通常0.92〜0.97）を超えているかを確認、超えている場合はキャッシュされた回答を返します。 リスクは、古いか slightly 間違った回答を返すことです。しきい値が低すぎると間違った結果が返され、高すぎるとキャッシュヒットがほぼなくなります。ユースケースごとに調整してください。FAQの事実検索では0.95以上が安全です。創造的な生成には、セマンティックキャッシュは rarely 適切です - 新規性がすべてです。 コンテキストキャッシュの詳細 Googleのコンテキストキャッシュでは、大きなドキュメントを1回アップロードし、それに対する後続のクエリに削減された料金を支払うことができます。これは、同じ200ページのPDFを何百回も処理するドキュメントQ&Aに強力です。コストモデル：キャッシュ書き込みに対して入力トークンの完全料金を1回支払い、その後各キャッシュ読み取りに対して削減された料金（通常通常の25%）を支払います。 トレードオフはTTLです。キャッシュされたコンテキストは期限切れになります。ワークロードがバースティなアクセスポターンを持つ場合 - 1時間に500クエリ、その後1週間何もなし - バースト間でキャッシュが期限切れになる可能性があります。アクセスポターンに合わせてTTLをサイズ設定してください。 アプリケーションレベルキャッシュの詳細 決定論的キャッシングは最も積極的な戦略です。リクエストペイロード全体（プロンプト、temperature、最大トークン、モデル、ツール）をハッシュし、応答を保存します。完全一致の場合、キャッシュされた応答を即座に返します - LLM呼び出しなし、レイテンシなし、コストなし。 これは、同じ入力が常に同じ出力を生成する場合にのみ機能します。分類、エンティティ抽出、構造化データ解析、テンプレートベースの生成が良い候補です。会話型や創造的なタスクには適していません - ユーザーは varied 応答を期待します。 戦略の組み合わせ 最良の実装は複数の戦略をレイヤーします。典型的なスタック：アプリケーションレベルキャッシュを最初のチェックとして（最安、最速）、セマンティックキャッシュを2番目のチェックとして（重複を捕捉）、その後LLM呼び出しをプロバイダー側のプロンプトキャッシュ有効で（キャッシュミスでもコスト削減）。この階層型アプローチは、繰り返しの程度があるワークロードでLLM支出を40〜70%削減できます。 各レイヤーのキャッシュヒット率を個別に追跡してください。セマンティックキャッシュのヒット率が10%を下回った場合、ベクトルストアのオーバーヘッドが見合わない可能性があります。アプリケーションキャッシュのヒット率が40%を超えた場合、プロンプトレベルで最適化すべき決定論的タスクがある可能性があります。 関連項目 プロンプトキャッシングの説明 - プロバイダー側キャッシングの詳細。 セマンティックキャッシュの経済学 - セマンティックキャッシュのROI分析。 AI費用最適化 - より幅広い最適化戦略。 これをご自身のLLM支出に適用しませんか？FinOps LLMはAIコストの無料監査を実行し、削減のポイントを示します。 無料監査を予約 → リサーチに戻る --- # AIコード生成を最も安く実行する方法（2026年） · FinOps LLM URL: https://finopsllm.com/ja/research/cheapest-ai-code-generation AIコード生成を最も安く実行する方法 AIコード生成ツールは variety が爆発的に増加しましたが - オプション間のコスト差は巨大です。軽量ユーザーは1つのアプローチで月額$10、別のアプローチで月額$200をほぼ同じ結果に対して費やす可能性があります。このガイドでは、AIコーディングツールのすべてのカテゴリを比較し、異なる使用レベルでの実際の月額コストを計算し、ワークフローに実際に機能する最も安いオプションを選ぶための決定木を提供します。 4つのカテゴリ すべてのAIコード生成ツールは4つの価格モデルのいずれかに該当します： サブスクリプションエージェント - 固定月額料金、使用量込み（Cursor、Copilot、Windsurf、Cody）。 APIベースエージェント - 独自のAPIキーを持ち込み、トークンあたり課金（Claude Code、Cline、Aider、クラウドAPIを使用するContinue）。 セルフホストモデル - オープンウェイトモデルをローカルまたは独自のGPUで実行（Continue + Qwen、CodeLlama、DeepSeek Coder）。 コーディングプランプロバイダー - コーディングワークロードに最適化された固定料金APIアクセス（ MiMO 、GLM、MiniMax、KwaiKAT）。 コスト比較表 オプション 月額コスト（軽量） 月額コスト（ヘビー） モデル品質 セットアップ労力 GitHub Copilot Free $0 $0 良好 なし GitHub Copilot Pro $10 $10 非常に良好 なし Cursor Pro $20 $20 優秀 低 Windsurf Pro $15 $15 非常に良好 低 Claude Code（API） $5–15 $50–200 優秀 中 Cline + APIキー $5–20 $40–150 優秀 中 MiMOコーディングプラン $10–15 $30–60 非常に良好 低 GLMコーディングプラン $10–15 $30–60 良好 低 Continue + ローカルモデル $0 $0 まずまず 高 軽量ユーザー： ~2時間/日、~50リクエスト/日。 ヘビーユーザー： 8+時間/日、~300リクエスト/日。APIコストはClaude SonnetまたはGPT-4oの価格でリクエストあたり平均3K入力+1K出力トークンと仮定。 カテゴリ別詳細 1. サブスクリプションエージェント 導入が最も簡単です。固定料金を支払い、寛大な（または無制限の）使用クォータを取得します。注意点：モデル選択とIDE統合にロックされます。 Cursor Pro（$20/月） - パワーユーザー向けの最高のUX。高速リクエスト（GPT-4o、Claude Sonnet）と低速リクエスト（フロンティアモデル）が含まれます。月500の高速リクエスト制限はほとんどの開発者にとって十分です。 GitHub Copilot（$10/月） - 最も安いメインストリームオプション。タブ補完は優秀。チャットは良いですがCursorのエージェントモードより強力ではありません。制限付きの無料ティアがあります。 Windsurf Pro（$15/月） - 競争力のある中間地点。Cursorより低い価格帯で良好なエージェント機能。 結論： セットアップなしで請求が予測可能な開発者に最適。Copilot Freeは予算意識の高いユーザーにとって無敵です。 2. APIベースエージェント 独自のAPIキー（OpenAI、Anthropicなど）を持ち込み、ツールが代理でAPI呼び出しを行います。コストは使用量に比例して増加 - 軽量ユーザーには最適、ヘビーユーザーには高額です。 Claude Code - AnthropicのCLIエージェント。Claude SonnetまたはOpusを使用。ヘビーセッションはAPI料金で$2–5かかる可能性があります。 Cline（VS Code） - 任意のAPIで動作するオープンソースエージェント。非常に柔軟ですが、予算制限なしではコストが予測不能です。 Aider - ターミナルベース、任意のモデルで動作。Git統合と編集モードアプローチで人気。 結論： モデルの柔軟性を望み、使用量を監視する意思がある開発者に最適。軽量ユーザーはサブスクリプションより安く、ヘビーユーザーは高くなります。 3. セルフホストモデル オープンウェイトモデル（Qwen 2.5 Coder、DeepSeek Coder V2、CodeLlama）をOllama、vLLM、llama.cppでローカル実行。リクエストあたりの限界コストはゼロ - ただしハードウェアが必要です。 メリット： トークンコストなし、完全なプライバシー、レート制限なし、オフライン動作。 デメリット： フロンティアモデルとの品質差（特に複雑なリファクタリング向け）、 capable GPUが必要（良好な結果には16GB+ VRAM）、セットアップ摩擦。 結論： プライバシー重視の作業、オフライン環境、または既存のGPUインフラを持つチームに最適。単一モデルとしては推奨されません - 難しいタスクにはクラウドモデルと組み合わせましょう。 4. コーディングプランプロバイダー より新しいカテゴリ：コーディングエージェント専用に固定料金または大幅に割引されたAPIアクセスを提供するプロバイダー。これらは高額なトークンあたりAPI価格と rigid なサブスクリプションツールのギャップを橋渡しします。 MiMOコーディングプラン - 強力な推論能力を持つ競争力のある価格。コストと品質のバランスが良好。 GLM（智譜） - コーディングワークロードに積極的な価格設定の中国プロバイダー。 MiniMax / KwaiKAT - コーディング最適化された価格ティアを持つ新興プロバイダー。 結論： セルフホストに切り替えずにコストを削減したいAPIベースエージェントユーザーに最適。品質は様々 - コミット前に実際のタスクでベンチマークを取りましょう。 決定木 これに従って最も安いオプションを見つけてください： 2時間/日未満のコーディング： GitHub Copilot Free を使用。コストゼロ、優秀な補完。制限に達した場合はCopilot Pro（$10/月）にアップグレード。 2〜6時間/日のコーディング： Cursor Pro（$20/月） または Windsurf Pro（$15/月） を使用。このボリュームでは固定料金がAPIコストより安い。代替として、Clineと MiMOのようなコーディングプランプロバイダー を$10〜30/月で使用。 8+時間/日のコーディング： コーディングプラン付きAPIベースエージェント （MiMO、GLM）を$30〜60/月で使用。標準APIキー（Claude、GPT-4o）はこのボリュームで$100〜200/月かかります。コストをさらに削減するため、ルーチン補完にローカルモデルを検討。 誰も話さない隠れたコスト コンテキストウィンドウの浪費。 ほとんどのコーディングエージェントは、すべてのリクエストでファイル全体+会話履歴を送信します。GPT-4oの50Kトークンコンテキストは、入力だけでリクエストあたり$0.125かかります。1日200リクエストでは$25/日 - 月額Cursorサブスクリプションより高額です。 リトループ。 失敗した編集を自動リトライするエージェントツールはトークンを素早く消費します。リトライ回数にハードリミットを設定しましょう。 モデル切り替えのオーバーヘッド。 一部のツールは最も高価なモデルをデフォルトとします。設定を確認 - Cursorの「低速」リクエストはより安いモデルを使用し、多くの場合十分高速です。 結論 ほとんどの開発者にとって、サブスクリプションエージェント（CopilotまたはCursor）が最も安いオプションです。使用量に関係なくコストを上限設定するためです。APIキーを管理する意思があるパワーユーザーには、 MiMO のようなコーディングプランプロバイダーがコスト対品質の最高比を提供します。セルフホストモデルは無料ですが品質に制限があります - 補完として最適であり、代替ではありません。何を選択するにしても、 ツールごとの支出を追跡 し、価格変動時に再評価できるようにしましょう。 関連記事 AIコーディングプラン比較 - コーディングプランプロバイダーの詳細ベンチマーク。 GPT-5はいくらかかる？ - フロンティアモデルの価格解説。 プロバイダー裁定取引 - より安いモデルを見つける体系的アプローチ。 モデルルーティング - タスクを正しいコストティアに送る。 これを自分のLLM支出に適用しませんか？FinOps LLMはAIコストの無料監査を実行し、節約の場所を示します。 無料監査を予約 → リサーチに戻る --- # Claude Fable 5.1 は $10/$50。請求額を決めるのはキャッシュ率 · FinOps LLM URL: https://finopsllm.com/ja/research/claude-fable-5-1-cost-model Claude Fable 5.1 のコストモデル 更新日 September 1, 2026 · 初回公開 September 1, 2026 要約: Claude Fable 5.1（claude-fable-5-1）は入力 100 万トークンあたり 10 ドル、出力 50 ドルです。Opus 5 は 5 ドルと 25 ドルなので一律 2 倍に見えますが、キャッシュ料金だけは逆方向に動きます。重要な 4 つの単価キャッシュ書き込みは 100 万トークンあたり 12.50 ドル（TTL 5 分）と 20.00 ドル（TTL 1... Claude Fable 5.1（ claude-fable-5-1 ）は入力 100 万トークンあたり 10 ドル、出力 50 ドルです。Opus 5 は 5 ドルと 25 ドルなので一律 2 倍に見えますが、キャッシュ料金だけは逆方向に動きます。 重要な 4 つの単価 キャッシュ書き込みは 100 万トークンあたり 12.50 ドル（TTL 5 分）と 20.00 ドル（TTL 1 時間）。キャッシュ読み取りは 0.25 ドルで、自身の入力価格の 2.5%、そして Opus 5 の同じトークンの 半額 です。他の行はすべて 2 倍、この 1 行だけが 0.5 倍です。 実際の負荷での挙動 10 万トークンの前置きはコールド時に Fable で 1.00 ドル、Opus 5 で 0.50 ドル。ウォーム時は 0.025 ドルと 0.05 ドルです。同じプロンプトのまま、高い方が安い方に入れ替わります。損益分岐点はモデルの好みではなく、約 50% のキャッシュヒット率です。 出力側に上限はない コンテキストは 100 万トークン、最大出力は 12 万 8000 トークンです。100 万あたり 50 ドルなので、128K の応答 1 回で 6.40 ドルになります。拡張思考は常時有効で、明示的な設定は 400 エラーになります。コスト調整は low から max までの effort です。Priority Tier もないため、レイテンシは自社側の並列制御で管理します。 トラフィックを流す前に計測すること 機能単位のキャッシュヒット率、キャッシュ書き込みの増幅、成功タスクあたりの出力トークンを測定してください。その上で単価・数量・構成に分解した差異ブリッジで既存モデルと比較します。平均値は相反する 2 つの動きを隠します。 関連記事 プロンプトキャッシュの経済性 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # Claude Opus 5.5: $4/$20、キャッシュ読み取り$0.20 · FinOps LLM URL: https://finopsllm.com/ja/research/claude-opus-5-5-cost-model Claude Opus 5.5 コストモデル 更新日 September 22, 2026 · 初回公開 September 22, 2026 Anthropic は 2026 年 9 月 22 日に Claude Opus 5.5（ claude-opus-5-5 ）をリリースしました。見出し価格は百万入力トークンあたり $4、百万出力トークンあたり $20 で、Opus 5 の $5 と $25 からの低下です。これは 20% のカットです。ほとんどの本番ワークロードでは、実際のカットはより大きいです。なぜなら、最も動いたレートは見出しが除外するレートだからです。 重要なレート トークンタイプ Opus 5.5 Opus 5 Fable 5.1 入力（キャッシュなし） $4.00 / MTok $5.00 / MTok $10.00 / MTok 出力 $20.00 / MTok $25.00 / MTok $50.00 / MTok キャッシュ書き込み（5 分） $5.00 / MTok $6.25 / MTok $12.50 / MTok キャッシュ読み取り $0.20 / MTok $0.50 / MTok $0.25 / MTok 高速モード（入力/出力） $8 / $40 — — すべての行は 20% 低いですが、キャッシュ読み取りは 60% 低いです。$0.20 では Fable 5.1 の $0.25 より安くなりました。これは Fable がかつて勝った 1 つの行を反転させます。 Fable 5.1 コストモデル では、キャッシュの多いワークロードは Opus 5 より Fable の方が安い可能性がありました。Opus 5.5 に対してはもはやそうではありません。Fable はすべてのトークンタイプで多くの費用がかかります。 典型的なタスクが約 40% 安い理由 Anthropic の主張は典型的なジョブのコストが 40% 削減されることであり、20% ではありません。追加の部分はトークン効率から来ています。Anthropic は Opus 5.5 が約 20% 少ない入出力トークンで同じ結果に達し、約 40% 冗長性の低い出力を書くと述べています。低いレート掛ける少ないトークンが複合します：0.8 × 0.8 = 0.64、これは混合に応じてざっと 36-40% オフです。 これは 1 つのエージェントステップです：200,000 入力トークン、キャッシュから提供される 90%、20,000 出力トークン。 行 Opus 5 Opus 5.5（同じトークン） Fable 5.1 20K キャッシュなし入力 $0.100 $0.080 $0.200 180K キャッシュ入力 $0.090 $0.036 $0.045 20K 出力 $0.500 $0.400 $1.000 合計 $0.690 $0.516 $1.245 同一トークンでは、Opus 5.5 はキャッシュ割引のため Opus 5 より 25% 安く、20% ではありません。20% トークン削減があなたのワークロードに当てはまる場合、ステップは約 $0.41 に低下し、これは Opus 5 より 40% 下で、Fable コストの 3 分の 1 です。出力はこの例では依然請求の約 80% です。これが冗長性削減の価値がある場所です。 GPT-6 Sol、GPT-6 Astra、Fable 5.1 とのタスクあたりコスト比較 100万トークンあたりの定価と、上と同じエージェントステップ(入力200K、うち90%キャッシュ、出力20K)を各モデルで計算した値です。 モデル 入力 $/MTok 出力 $/MTok キャッシュ読み取り $/MTok 同一エージェントステップ GPT-6 Sol $2.00 $10.00 $0.20 $0.276 Claude Opus 5.5 $4.00 $20.00 $0.20 $0.516 Claude Opus 5 $5.00 $25.00 $0.50 $0.690 Claude Fable 5.1 $10.00 $50.00 $0.25 $1.245 GPT-6 Astra $10.00 $50.00 $1.00 $1.380 Artificial Analysis Intelligence Index v4.3.2 での実測タスクあたりコスト(2026年9月22日時点、スコア順)。スコア47.5までは GPT-6 Sol が最安です。それを超えると、どの水準でも Opus 5.5 が最安です。Opus 5.5 high は1.82ドルで53.6、GPT-6 Astra max は3.26ドルで52.7、Fable 5.1 max は7.63ドルで53.4です。 モデル Intelligence Index タスクあたりコスト タスクあたり出力トークン GPT-6 Sol · medium 39.8 $0.25 6,500 GPT-6 Sol · xhigh 44.1 $0.53 16,000 GPT-6 Astra · low 45.8 $0.82 4,400 GPT-6 Sol · max 47.5 $1.06 31,200 Claude Opus 5 · high 48.1 $3.61 46,200 Claude Opus 5 · max 50.8 $5.86 72,500 Claude Opus 5.5 · medium 51.2 $1.34 25,700 Claude Fable 5.1 · high 51.2 $3.91 38,100 GPT-6 Astra · max 52.7 $3.26 27,200 Claude Fable 5.1 · max 53.4 $7.63 78,100 Claude Opus 5.5 · high 53.6 $1.82 35,600 Claude Opus 5.5 · max 57.6 $5.98 119,200 GPT-6 Astra の low より上の設定、Opus 5 の全設定、Fable 5.1 の全設定は、同等以上のスコアを出す Sol または Opus 5.5 の設定より高くつきます。タスクあたりコストはベンチマークのタスク構成に左右されます。モデルを切り替える前に自社のトラフィックで再現してください。 Fable を置き換えるのに十分ですか? Anthropic は Opus 5.5 をほとんどのタスクで Fable 5.1 と一致するものとして位置付けています。公開されている数字はコーディングとエージェント作業でそれをサポートしています： Terminal-Bench 4.0: 66.4%、Opus 5 52.3%、Fable 5.1 55.8% に対して。 FrontierCode v1.1: 54.4%、Opus 5 48.0%、Fable 5.1 50.3% に対して。 CursorBench 4.0: 57.8%、Opus 5 46.6% に対して。 GDPval-AA v2.1: 1846 Elo、Opus 5 1708 に対して。 Artificial Analysis はローンチ当日に Intelligence Index で最初にランク付けしました。Anthropic はまた、デフォルト（中）の努力で GPT-6 Astra を最大努力で知識作業に打ち負かし、タスクあたりのコストの約 5 分の 1 であると述べています。これはベンダー比較なので、それをテストする仮説として扱います。上記のコスト数学は、自分で検証できる部分です。 高速モードは 2× コスト 高速モードは $8 入力と $40 出力でコストがかかり、標準レートのちょうど 2 倍です。最大 2.5× の速度のため。標準モデルも Opus 5 より約 30% 高速です。ユーザーが待機している遅延バウンドインタラクティブパスで高速モードを使用してください。バッチジョブ、バックグラウンドエージェント、eval から除外してください。高速モードがデフォルトで有効な場合、単価は 2 倍になり、ダッシュボードは請求書が到着するまで何も珍しくは表示されません。 今週何をするか モデル ID をピンします。 claude-opus-5-5 を明示的に指し、すべてのリクエストに ID を記録して、移行後のリクエストごとのコストをモデル別に分割できます。 独自のトラフィックで再ベースラインします。 実際のリクエストのサンプルを両方のモデルで再生し、呼び出しごとではなく、完了したタスクごとのトークンを比較します。20% トークン効率のクレームは、ワークロードごとに最も変動する可能性がある部分です。 努力設定を再確認します。 ワークロードが品質のために Fable または最大努力に移動した場合、最初に Opus 5.5 を中程度でテストしてください。それは Anthropic がベンチマークする設定です。 Fable ルーティング決定を再実行します。 キャッシュの多いトラフィックを Fable に送信してより安いキャッシュ読み取りを得るすべてのルートを再評価する必要があります。そのコストの利点は消えました。 キャッシュヒット率を監視します。 $4.00 に対して $0.20 では、キャッシュミスはヒットの 20× を超えるコストがかかります。プレフィックスを破るプロンプトテンプレート変更は、Opus 5 でそうであったより多くの費用がかかります。 Anthropic は Sonnet 5.5 と Haiku 5.5 が今後の週でフォローすると述べています。ステップ 2 からのリプレイハーネスを保持して、各リリースを午後で再ベースラインできます。 関連記事 Claude Fable 5.1 コストモデル プロンプトキャッシング経済 Opus 5.5 努力レベルが本当の価格です Opus 5.5 高速モード経済 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # AIコーディングプラン比較 · FinOps LLM URL: https://finopsllm.com/ja/research/coding-plan-comparison AIコーディングプラン比較 主要なAIコーディングプランを検証可能なエビデンスで比較します。価格、制限、モデルスコアを正規化されたテーブルに。プロバイダーのドキュメントと明示的な変換ルールによる公平な比較。 9 追跡プロバイダー 29 比較プラン 62 リストモデル 2026年7月 最終更新 すべての更新が公開エビデンスに関連付け プロンプト/リクエスト変換ルールが明示的 固定計算ロジックで比較の一貫性を維持 方法論 収集 プラン、制限、モデルデータは公開プロバイダーソースから収集されます。 正規化 プロンプト/リクエスト/期間フォーマットは単一の比較モデルに正規化されます。 変換ルール リクエスト/プロンプト = 15、週次 × 4 = 月次が明示的に適用されます。 表示ポリシー 公式値と推定値はUIで明確に分離されます。 更新フィード 2026年7月4日 コーディングプラン比較リサーチページ公開 エビデンスに基づくAIコーディングプラン比較をFinOps LLMのリサーチ記事として公開。 2026年5月27日 Xiaomi MiMO割り当て増加 Xiaomi MiMOが利用可能な使用制限を増加させ、比較テーブルが更新されました。 2026年5月1日 Alibaba、コーディングプラン終了、トークンプラン追加 Alibabaが以前のコーディングプランを終了し、トークンプラン（チーム版）を導入。 コーディングプラン比較リスト リクエスト/プロンプト変換率（デフォルト = 15） 1 プロンプト = 15 リクエスト 並べ替え デフォルト順 最安値 ≤ $10 最安値 ≤ $30 最安値（すべて） 表示: すべて Coding Agent プロバイダー ↕ プラン ↕ 価格 ↕ 用途 プロンプト/月 ↕ リクエスト/月 ↕ プロンプト/$1 ↕ リクエスト/$1 ↕ モデル 知能 ↕ コーディング ↕ エージェント ↕ GLM Lite $10 Coding + Agent 160 2,400 16 240 GLM-5.1 (×3), GLM-5-Turbo (×3), GLM-4.7 (×1) 47 37 66 GLM Pro $30 Coding + Agent 267 4,000 8.9 133 GLM-5.1 (×3), GLM-5-Turbo (×3), GLM-5 (×3) 50 44 63 GLM Max $80 Coding + Agent 400 6,000 5 75 GLM-5.1 (×3), GLM-5-Turbo (×3), GLM-5 (×3) 50 44 63 MiniMax Starter $10 Coding + Agent 400 6,000 40 600 MiniMax-M2.7 (×1) 50 42 61 MiniMax Plus $20 Coding + Agent 600 9,000 30 450 MiniMax-M2.7 (×1) 50 42 61 MiniMax Max $45 Coding + Agent 889 13,333 19.8 296 MiniMax-M2.7 (×1) 50 42 61 MiniMax Plus-HighSpeed $40 Coding + Agent 300 4,500 7.5 112.5 MiniMax-M2.7-highspeed (×1) 50 42 61 MiniMax Max-HighSpeed $80 Coding + Agent 500 7,500 6.25 93.75 MiniMax-M2.7-highspeed (×1) 50 42 61 MiniMax Ultra-HighSpeed $150 Coding + Agent 533 8,000 3.55 53.3 MiniMax-M2.7 (×1) 50 42 61 BytePlus Lite $10 Coding + Agent 120 1,800 12 180 Seed-Code (×1), GLM-4.7 (×1), DeepSeek-V3.2 (×1), kimi-k2.5 (×1) 34 31 36 BytePlus Pro $50 Coding + Agent 120 1,800 2.4 36 Seed-Code (×1), GLM-4.7 (×1), DeepSeek-V3.2 (×1), kimi-k2.5 (×1) 34 31 36 StepFun Flash Mini $6.99 Coding 229 3,433 32.8 491 step-3.5-flash (×1) 38 32 52 StepFun Flash Plus $9.99 Coding 641 9,610 64.2 962 step-3.5-flash (×1) 38 32 52 StepFun Flash Pro $29 Coding 828 12,414 28.6 428 step-3.5-flash (×1) 38 32 52 StepFun Flash Max $99 Coding 808 12,121 8.16 122.4 step-3.5-flash (×1) 38 32 52 KwaiKAT Mini $5 Coding 1,075 16,128 215 3,226 KAT-Coder-Pro V2 (×1) 44 46 51 KwaiKAT Starter $10 Coding 1,344 20,160 134.4 2,016 KAT-Coder-Pro V2 (×1) 44 46 51 KwaiKAT Pro $20 Coding 2,016 30,240 100.8 1,512 KAT-Coder-Pro V2 (×1) 44 46 51 KwaiKAT Max $50 Coding 2,688 40,320 53.76 806.4 KAT-Coder-Pro V2 (×1) 44 46 51 OpenCode Go $10 Coding + Agent 667 10,000 66.7 1,000 MiniMax-M2.5 (×1), M2.7 (×1.4), MiMo-V2-Pro (×16), kimi-k2.5 (×11), GLM-5 (×17) 50 44 63 Xiaomi MiMO 登録で双方$2 ↗ Lite $6 Coding + Agent 380 5,693 63.3 949 MiMo-V2-Pro (×1), MiMo-V2-Omni (×1) 49 41 63 Xiaomi MiMO 登録で双方$2 ↗ Standard $16 Coding + Agent 382 5,729 23.9 578 MiMo-V2-Pro (×1), MiMo-V2-Omni (×1) 49 41 63 Xiaomi MiMO 登録で双方$2 ↗ Pro $50 Coding + Agent 422 6,333 8.44 126.7 MiMo-V2-Pro (×1), MiMo-V2-Omni (×1) 49 41 63 Xiaomi MiMO 登録で双方$2 ↗ Max $100 Coding + Agent 456 6,833 4.56 68.3 MiMo-V2-Pro (×1), MiMo-V2-Omni (×1) 49 41 63 Alibaba Standard $30 Coding + Agent 17 262 0.57 8.73 qwen3.6-plus (×1), deepseek-v3.2 (×1), GLM-5 (×1), MiniMax-M2.5 (×1) 50 43 62 Alibaba Advanced $100 Coding + Agent 21 314 0.21 3.14 qwen3.6-plus (×1), deepseek-v3.2 (×1), GLM-5 (×1), MiniMax-M2.5 (×1) 50 43 62 Alibaba Premium $200 Coding + Agent 26 393 0.13 1.97 qwen3.6-plus (×1), deepseek-v3.2 (×1), GLM-5 (×1), MiniMax-M2.5 (×1) 50 43 62 プロバイダーが明示的に提供していない値は グレー で表示されます。 多くのプロバイダーはプロンプトまたはリクエストの割り当てを制限しています。上記のプロンプト/リクエストレートコントロールを使用して動的に変換します（デフォルト: 15）。 最も高い公式制限が週次の場合、月次は週次 × 4として推定されます。 Artificial Analysisスコアは artificialanalysis.ai で測定されます。 一部のリンクには紹介コードが含まれている場合があります。 プランの詳細は頻繁に変更される可能性があります。最新情報はプロバイダーの公式ページでご確認ください。 実用ガイド 価格だけでは不十分です。まず各プランを自分の作業スタイルに合わせてください。Agentポリシー、制限タイプ、契約期間から始めましょう。 1) まずAgentポリシーを確認 一部のプロバイダーやプランはAgentの使用を制限しています。Agentワークフローが重要なら、購読前に利用規約と用途列（Coding / Agent）を確認してください。 2) プロンプト制限 vs リクエスト制限 手動チャット中心の使用では、より少ないターンにまとめることでプロンプト形式の制限にうまく合います。自動化やAgent中心のワークフローでは、バックエンドのリクエスト量が急速に増える可能性があるため、十分なリクエストの余裕があるプランを優先してください。 3) 月額を基本に、初期条件が明確に優位な場合は年額を検討 プランの改訂や登録変更がますます一般的になっています。月額は柔軟性を提供し、年額はローンチ期間の条件が明らかに有利な場合に有効です。 4) 速度（トークン/秒）は実際の生産性要因 同じ割り当てでも、遅い応答はより多くの作業時間がかかります。今後のアップデートでトークン/秒の指標を追加予定です。 追加チェック項目 提供値と推定値を分離（推定値は変動する可能性あり） 同クラスモデルの利用可能性を確認（なし = 利用不可） リセットサイクル（5時間/日次/月次）を実際の使用ウィンドウに合わせる これを自分のLLM支出に適用しませんか？FinOps LLMはAIコストの無料監査を実行し、節約の場所を示します。 無料監査を予約 → リサーチに戻る --- # 利用量コミットは自社予測への賭け · FinOps LLM URL: https://finopsllm.com/ja/research/committed-spend-discounts コミット割引と予約容量 更新日 September 1, 2026 · 初回公開 September 1, 2026 要約: モデル支出が目立つ規模になると、プロバイダーは volume コミットと引き換えに割引を提示してきます。予約容量、年間コミット、プロビジョンド・スループット — 形は違っても取引は同じで、予測可能であることに対して支払われているのです。3... モデル支出が目立つ規模になると、プロバイダーは volume コミットと引き換えに割引を提示してきます。予約容量、年間コミット、プロビジョンド・スループット — 形は違っても取引は同じで、予測可能であることに対して支払われているのです。 3 つのリスク 使い切れないこと は分かりやすく、最も小さいリスクです。計画値ではなく保守シナリオの下でコミットすれば境界を引けます。 モデルに縛られること はより重大です。フロンティアは数か月で動きます。今日の旗艦モデルに 12 か月コミットするのは、大幅に安いものが出てこないほうに賭けることであり、この 3 年は毎四半期出てきました。 乗り換え能力を失うこと が最大で、しかもモデルには決して現れません。次の交渉での梃子がなくなり、前払い済みのモデルから traffic を逃がす最適化を誰もやらなくなります。 値付けの方法 正直な反実仮想と比べてください。定価×数量ではなく、同じ期間をオンデマンドで払っていた場合の額 — 期間中に実際に来る値下げと安いモデルを織り込んだ額です。12 か月ならしばしば現行定価の 20〜40% 下になり、典型的なコミット割引の大半を先に食べてしまいます。 計画ではなく 下限 にコミットする。モデルではなく 金額 でコミットする。未使用分の繰り越しを条件にする。期間は短く保つ。 関連記事 LLM 購買ガイド この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # コンテキストウィンドウには二度払っている · FinOps LLM URL: https://finopsllm.com/ja/research/context-window-paid-twice コンテキストウィンドウへの二重支払い 更新日 September 1, 2026 · 初回公開 September 1, 2026 要約: コンテキストウィンドウは容量として宣伝されます。20 万トークン、100 万トークン、必要なだけ入る、と。しかし課金単位は容量ではありません。請求されるのは送信した分であり、複数ターンの会話ではそのほとんどを毎ターン送り直しています。それが二度目の支払いです。20 ターンの会話の冒頭で読み込んだ 3 万トークンの文書は、入力 3 万トークンではなく、60... コンテキストウィンドウは容量として宣伝されます。20 万トークン、100 万トークン、必要なだけ入る、と。しかし課金単位は容量ではありません。請求されるのは 送信した 分であり、複数ターンの会話ではそのほとんどを毎ターン送り直しています。 それが二度目の支払いです。20 ターンの会話の冒頭で読み込んだ 3 万トークンの文書は、入力 3 万トークンではなく、60 万トークン近くになります。 誰も計算しない算数 コストは会話の長さに対して線形ではなく、二乗で増えます。ターン数が倍になれば入力トークンはおよそ 4 倍です。「メッセージあたりの費用」に件数を掛ける見積もりは、長いセッションを大きく過小評価します。 さらに三つ目の課金があることも多いです。多くのプロバイダーは長文脈のしきい値を超えたリクエストに割増料金を適用します。添付ひとつでその線を越え、呼び出し全体が再価格付けされます。 測るべきもの コンテキスト利用率 、つまり送信したトークンと実際に必要だったトークンの比を追ってください。入力トークンはリクエスト単位ではなく 会話 単位で測り、p99 を見ます。 3 つの対策 安定した接頭辞をキャッシュする。 複数ターンの製品では最も効果の大きい変更です。 履歴を意図的に削る。 古い部分は要約し、生のターンは捨てます。 コーパスではなく抜粋を送る。 関連記事 プロンプトキャッシュの経済性 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # 使える画像 1 枚の本当の値段 · FinOps LLM URL: https://finopsllm.com/ja/research/cost-per-approved-image 画像・動画生成の承認済みアセット単価 更新日 September 1, 2026 · 初回公開 September 1, 2026 要約: 画像と動画の価格は珍しく単純に見えます — 1 枚いくら、1... 画像と動画の価格は珍しく単純に見えます — 1 枚いくら、1 秒いくら。その単純さゆえに、ほとんどのチームが予算を外します。プロバイダは 生成 に課金し、事業が消費するのは 承認されたアセット です。両者は同じ数字ではなく、ビジュアル制作では近くすらありません。 採用率がモデルのすべて 最初のレンダーをそのまま出す人はいません。生成し、見て、プロンプトを直し、また生成する。スタイルが確立していて成熟したプロンプトなら採用は 3 回に 1 回、自由な探索なら 10 回に 1 回かそれ以下です。動画はさらに厳しく、モーション、時間的一貫性、たった 1 フレームの破綻でクリップが没になり、それでもクリップ全体の料金を払います。 したがって有用な計算は定価ではなく、定価 ÷ 採用率です。8 回に 1 回なら、数セントの定価のアセットは実質 25 セント近くになります。 数字を本当に動かすもの 解像度と尺は分かりやすいレバーですが、欲しかった成果物そのものと引き換えなので面白くありません。効くのは採用率を上げる側です。 低解像度で反復し、選んだものだけアップスケールする のは、どんな単価割引よりも経済性を変えます。既知スタイルの プロンプトライブラリ は、10 分の 1 の探索を 3 分の 1 の実行に変えます。 参照画像とシード は、新規の賭けを制御された変奏に変えます。そして 最初の生成前に書かれたブリーフ は、最も高くつく失敗 — 誰も定義していない目標に向かって反復すること — を消します。 正しいものを測る プロジェクト別・担当者別の「承認 1 件あたり生成回数」と、看板指標としての「承認済みアセット単価」を追ってください。どちらも計測が安く、すぐ行動に移せます。承認 1 件に 15 回生成しているチームは、価格の問題ではなくブリーフかツールの問題を抱えており、プロバイダを替えても直りません。 関連記事 LLM コストの帰属 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # リクエスト単価より成功タスク単価を測る · FinOps LLM URL: https://finopsllm.com/ja/research/cost-per-successful-task リクエスト単価より成功タスク単価を測る 更新日 August 27, 2026 · 初回公開 August 27, 2026 要約: リクエスト単価は便利ですが、失敗や再試行は完了した仕事ではありません。重要なのは成功タスク単価、つまり品質基準を満たしたタスク1件あたりの帰属コストです。計算方法成功タスク単価 = 帰属支出 /... リクエスト単価は便利ですが、失敗や再試行は完了した仕事ではありません。重要なのは 成功タスク単価 、つまり品質基準を満たしたタスク1件あたりの帰属コストです。 計算方法 成功タスク単価 = 帰属支出 / 成功タスク数 。トークン、ツール、再試行、フォールバックを含めます。成功条件は先に定義します。 分母を計測する モデルのスパンと結果イベントをリクエストIDで結び、成功、失敗理由、人手修正、遅延を記録します。プロバイダー請求とも照合します。 リクエストは安いのに成功タスクが高い場合、品質、再試行、停止ルールを見直します。 関連記事 LLMコスト監視 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # LLMプロバイダー切り替えの本当のコスト · FinOps LLM URL: https://finopsllm.com/ja/research/cost-switching-llm-providers LLMプロバイダー切り替えの本当のコスト 更新日 August 27, 2026 · 初回公開 August 27, 2026 要約: LLMプロバイダーの変更は価格表の比較だけではありません。移行開発、プロンプトとスキーマ、評価、二重運用、転送、サポート、品質低下のリスクを含めます。作業を数えるSDK、ツール、形式、制限、コンテキスト、安全性、監視、プロバイダー固有のエラー処理を棚卸しし、開発とテスト時間を見積もります。品質に値段を付ける同じワークロードを両方で実行し、成功率、遅延、リトライ、人手修正、評価者の一致を測ります。回... LLMプロバイダーの変更は価格表の比較だけではありません。移行開発、プロンプトとスキーマ、評価、二重運用、転送、サポート、品質低下のリスクを含めます。 作業を数える SDK、ツール、形式、制限、コンテキスト、安全性、監視、プロバイダー固有のエラー処理を棚卸しし、開発とテスト時間を見積もります。 品質に値段を付ける 同じワークロードを両方で実行し、成功率、遅延、リトライ、人手修正、評価者の一致を測ります。 回収期間を計算する 移行、評価、二重運用、ゲートウェイ費用後の月次節約と比較します。完全移行よりルーティングが適切な場合もあります。 関連記事 LLMプロバイダー間の裁定 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # DeepSeek Harnessの七つの防御パターン · FinOps LLM URL: https://finopsllm.com/ja/research/deepseek-harness-defensive-patterns DeepSeek Harnessドキュメントに学ぶ七つの防御パターン 更新日 August 16, 2026 · 初回公開 August 16, 2026 要約: DeepSeek Harness には短い防御パターン集があり、各項目が一般則として書かれ、それを生んだ具体的なバグが添えられています。リポジトリの中で最も転用しやすいファイルです。どれもハーネスの採用を前提とせず、各項目が自作のエージェントランタイムで実際に現れる失敗モードに対応します。 1. 直交する結果は独立に報告する... DeepSeek Harness には短い防御パターン集があり、各項目が一般則として書かれ、それを生んだ具体的なバグが添えられています。リポジトリの中で最も転用しやすいファイルです。どれもハーネスの採用を前提とせず、各項目が自作のエージェントランタイムで実際に現れる失敗モードに対応します。 1. 直交する結果は独立に報告する あるフラグの報告を別のフラグの条件分岐の中に入れ子にしてはいけません。プロセスはタイムアウトし かつ ゼロで終了しうる。シグナルを捕捉して綺麗に終了した場合です。タイムアウトを非ゼロ終了の分岐でしか報告しなければ、その結末は消えます。タイムアウト、シグナル、終了コードは独立した事実であり、独立したフィールドが必要です。 コストへの含意：黙って飲み込まれたタイムアウトはリトライループの温床です。呼び出し側は成功と見なし、有用な結果を得られず、また試します。 2. 公開契約を両側で守る 結果に複数の妥当な表現がある場合は、公開する前に正規化します。例として挙がるのはモデルリクエストの失敗です。実装は例外を投げることもエラーの finish チャンクを出すこともあり、API 境界はすべてを終端の finish チャンクへ正規化します。そうしないと、例外を捕まえた呼び出し側は、それがプロバイダ由来か、ミドルウェア由来か、ロギング由来か、自分のコード由来か判別できません。 3. 非同期状態は同期状態ではない ステータス照会は特定の非同期操作と因果的に結びついていません。ある一通のメッセージの完了信号としてエージェントの idle 状態を待つのは誤りです。キューに並んだ複数の操作が実行区間を共有するため、idle は自分の処理が走る前にも、他人の処理の後にも訪れうるからです。 示されている対処は、実行を所有する自動化の呼び出し側が自分の区間を明示的に定義することです。受信箱への到着から次のエージェント全体の idle までを区間とし、出力を個々のメッセージではなくその区間に帰属させます。待つものが何もない分岐も扱ってください。さもないと呼び出し側は永久にハングします。 誤った idle 信号を待ってハングする自動化ハーネスは、セッションとその子を常駐させ続けます。請求されるのはハングそのものではなく、その背後で生き続けているすべてです。 4. dispose は静止を要求するのではなく到達する 終了を要求することは終了を達成することではありません。dispose は戻る前に子の実際の終了を待ちます。さらにリスナーレジストリは kill シグナルの送信 前 に閉じ、遅れて届く完了が半ば解体されたシステムへコールバックを撃ち込むのではなく静かに落ちるようにします。 財務的な切れ味が最も明快なパターンです。早期に戻る dispose は、孤児となったサブプロセスと閉じられていないサンドボックスを走らせたままにします。従量課金の計算資源は、親が忘れたからといって止まりません。 5. コールバック例外はディスパッチャで封じ込める ディスパッチループを try/catch で包みます。一つの購読者の失敗が、ディスパッチの Promise を reject したり、後ろに並ぶリスナーを飢えさせたりしてはいけません。エージェントランタイムでは、飢えるリスナーがしばしば会計処理を担う当のリスナーです。こうして利用実績が、何のエラーも表に出ないまま失われます。 6. 信頼できない出力に環境や予測可能なパスを渡さない 文書中で最も強い規則であり、最初に採用すべきものです。起動するコマンドの環境をスクラブしてください。サブプロセスの開始前に key、secret、token、password に一致する変数を取り除きます。予測可能なパスではなく、所有者のみの権限で作った専用ディレクトリ、ランダムなファイル名、排他的な所有者専用オープンを使います。 脅威は二つあります。環境のスクラブは、ハーネスの資格情報がサブプロセス出力へ漏れ、それをモデルが読むことを防ぎます。いったん読まれれば、その出力はセッションログとコンテキストウィンドウの中です。ランダムな名前と排他生成は、共有一時ディレクトリでのシンボリックリンク競合を塞ぎます。 7. リンク状のパスは unlink する 削除前にパスがシンボリックリンクかを確認し、辿らずにリンクそのものを削除します。再帰削除は実在すると確認できたディレクトリに限ります。リンクを辿って対象へ入り込むことがあり、ジャンクションでは例外を投げるためです。自分が作った以上のものを消すクリーンアップコードは、被害に上限のない失敗モードです。 このリストの使い方 パターン 1 と 4 を今日、サブプロセスとサンドボックスの後始末コードへ持ち込む。金が漏れるのはそこです。 パターン 6 を、モデルが出力を読むプロセスを起動するあらゆる箇所へ持ち込む。 パターン 3 を自動化層へ、とくに待機が「エージェントが idle になるまで」と表現されている箇所へ持ち込む。 パターン 5 をテレメトリ基盤へ持ち込み、失敗するリスナーが会計用リスナーを飢えさせないことを確認する。 関連記事 DeepSeek Harnessとは？完全ガイド ハーネスの支出ガードレール（英語） サブエージェントと委譲の深さ（英語） コスト記録としてのセッションログ（英語） この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # DeepSeek Harnessの導入：プロファイルと初回実行 · FinOps LLM URL: https://finopsllm.com/ja/research/deepseek-harness-getting-started DeepSeek Harnessの導入：プロファイルと初回実行 更新日 August 16, 2026 · 初回公開 August 16, 2026 要約: 本稿は DeepSeek Harness 記事群の実践側です。dsh をどう動かすか、合成モデルが何を求めるか、そしてどのデモに十分な価値があるかを扱います。 最短経路 npx @deepseek-ai/dsh web http://127.0.0.1:3080 で Web UI が起動します。そこからセッションのコンポーザーが使えるようになるまでに、二つの手順が必要です。 Settings →... 本稿は DeepSeek Harness 記事群の実践側です。 dsh をどう動かすか、合成モデルが何を求めるか、そしてどのデモに十分な価値があるかを扱います。 最短経路 npx @deepseek-ai/dsh web http://127.0.0.1:3080 で Web UI が起動します。そこからセッションのコンポーザーが使えるようになるまでに、二つの手順が必要です。 Settings → Models で DeepSeek の API キーを入力します。再起動不要で即座に有効化されます。 ワークスペースの選択 でプロジェクトのディレクトリを追加し有効化します。ワークスペースが有効になるまでコンポーザーは使えません。 起動後、エージェントはファイルの読み書き、コマンドの実行、サブエージェントへのタスク委譲、そして計画立案を行えます。有効な権限ポリシーに従って確認を求めます。 ソースから git clone https://github.com/deepseek-ai/deepseek-harness pnpm install pnpm run build pnpm dsh web 下限要件は Node 22.19 以降（CI は 22.19、24、26 を対象）、Git 2.26 以降、そして Corepack で pnpm@11.7.0 に固定した pnpm です。 DEEPSEEK_API_KEY は任意で、環境変数かリポジトリ直下の gitignore された .env から読まれます。併せて DEEPSEEK_BASE_URL で別のエンドポイントを指せます。実 API に対するエンドツーエンドのテスト群はキーがなければ自らスキップするため、キーなしのチェックアウトでもビルドとテストは通ります。 プロファイルとバンドル：合成モデル ハーネスのあらゆる部分がプラグインである以上、どのプラグインを読み込むかを決める何かが必要です。それが プロファイル で、順序付きのバンドル一覧とユーザーのパッチを保持する名前付きの合成です。 バンドル は Cordis の設定行とコードを配布します。 テンプレートのプロファイルが三つ同梱されます。 プロファイル 合成する内容 dsh-base モデルアダプタ、ツール、永続化 dsh-web-app ブラウザ UI dsh-headless 単発実行のランナー 四層の上書き順序 設定は固定の順序で解決され、後の層が勝ちます。 プロファイルのバンドル プロファイルのパッチ home レベルのパッチ コマンドラインのオーバーレイ デバッグを始める前にこの順序を覚えてください。階層型の設定システムにおける「なぜそのモデルが使われているのか」という問いのほとんどは、その値に最後に触れた層を突き止めれば片づきます。そしてコマンドラインのオーバーレイはその下のすべてに勝ちます。 出会うことになるサブシステム 六つのレジストリキーが振る舞いの大半を担います。 ctx.sessions （追記専用のイベントログ）、 ctx.systemPrompt 、 ctx.tools （スコープ付きで実行がガードされたレジストリ）、 ctx.agents 、 ctx.agentLoop 、 ctx.llm です。ハーネスを拡張するなら、まず検索すべき名前がこれらです。 試す価値のあるデモ三つ ヘッドレス単発実行： pnpm dsh --profile headless "summarize this workspace" 。CI や cron ジョブに組み込むときの形です。 Cordis のイントロスペクション： pnpm run demo:cordis 。自己言及的で、稼働中の自身のプラグインランタイムを検査し変更します。プラグインという主張が宣伝ではなく構造であることの最も明快な実証です。 ACP 自動化： pnpm run demo:acp 。stdio 上で JSON-RPC を話す自動化サーバーで、別のシステムからハーネスを駆動するための統合面です。 コントリビュートを考えているなら いくつかの慣習が時間を節約します。TODO 系のマーカーは緊急度で段階分けされ、 FIXME はリリースブロッカー、 TODO は近く、 XXX はいつかを意味します。Lefthook は pre-commit （ステージ済みペアリング記録、 .oxlintrc.staged.json 、サードパーティ通知の再生成、空白、vendor マニフェストのガード）、 pre-merge-commit 、 pre-push （ pnpm run typecheck ）を実行します。フックはテストとビルドを意図的に飛ばします。網羅的なカバレッジは CI の担当で、 pnpm run check:all が任意の包括的なローカルゲートです。 一見不可解な構造は二つの事情で説明がつきます。ビルドが Host と Client の tsconfig 集約に分かれているのは、双方が Cordis の Context インターフェースを同じキーで宣言マージしており、両方のマージを見る単一の TypeScript プログラムが衝突を報告するためです。またドキュメント中のコード例は ts type-equiv フェンスと pnpm run verify-type-equiv によって正しさが保たれ、貼り付けた宣言がソースから静かに乖離しないようになっています。 期待値の設定 README は率直です。これは developer preview であり、互換性を壊す変更があります。プラグインの発見は GitHub のトピック dsh-plugin 経由で行われ、プロジェクトは MIT ライセンス、サードパーティ依存は THIRD_PARTY_NOTICES.md に列挙されています。評価は今、標準化は後で。 関連記事 DeepSeek Harnessとは？完全ガイド 「すべてがプラグイン」が実際にもたらすもの（英語） 支出ガードレールを置く場所（英語） コスト記録としてのセッションログ（英語） この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # DeepSeek Harnessのゴールとラルフループ · FinOps LLM URL: https://finopsllm.com/ja/research/deepseek-harness-goals-ralph-loop DeepSeek Harnessのゴール、ゴールラウンド、ラルフループ 更新日 August 16, 2026 · 初回公開 August 16, 2026 要約: エージェントのコスト事故の多くは、トークン単価のせいではありません。エージェントが何回「もう一度やってみよう」と判断したかのせいです。DeepSeek Harness はその挙動に語彙を与えます。数値を当てはめるための最初の一歩です。 ターン、ステップ、ラウンド プロジェクトの用語集で厳密に区別される三つの単位です。 単位定義コスト上の意味... エージェントのコスト事故の多くは、トークン単価のせいではありません。エージェントが何回「もう一度やってみよう」と判断したかのせいです。DeepSeek Harness はその挙動に語彙を与えます。数値を当てはめるための最初の一歩です。 ターン、ステップ、ラウンド プロジェクトの用語集で厳密に区別される三つの単位です。 単位 定義 コスト上の意味 ステップ 一回のモデルリクエストと、それが生むツール実行 課金の原子 ターン 入力の一巡。モデルが停止するかポリシーが介入すると終わる ユーザーから見える単位 ラウンド ゴールラウンドや新規エージェントによる再試行などの外側のポリシー反復 ターンの上に乗る乗数 ラウンドは、自作のコストモデルがまるごと抜かしがちな層です。予測がリクエスト数を数えているのにシステムがラウンドを回しているなら、その予測は別のものを測っています。 ゴールは永続的な目標 ゴールは、明示的なフェーズ（アクティブ、一時停止、ブロック、完了）を持つ永続的な完了目標です。メッセージと違ってターンをまたいで存続するため、エージェントは常設の目標を抱えます。そのゴールに対して受理された継続サイクルがゴールラウンドであり、一つのゴール由来のターンとして具体化されます。 受理はゴールアクティベーションが制御します。もう一ラウンド受理してよいというプロセスローカルな許可で、armed か disarmed のいずれかです。この一ビットが、終わりのない作業の絞り弁です。 常設の目標と自動継続の組み合わせは、上限のない支出許可です。ゴールの作成と編集に人間による直接の承認が必要だと文書化されているのは、まさにそのためです。終わりのない作業には予算の持ち主が要ります。 ラルフループは意図的な再スタート ラルフループは、不変の目標に向かって新しいエージェントセッションを繰り返し立ち上げるフォアグラウンドのワークフローで、ハーネスのワークフローとサブエージェントのプリミティブの上に構築されています。ラルフラウンドは、親の会話の種を持たない新しい子セッション一つです。継続性はラルフ・ハンドオフ、すなわちステータス、要約、証拠、ブロッカーを含む正規化された有界の構造化レポートが運びます。 ここの経済性は本当に面白く、両方向に効きます。きれいに再スタートするということは、各ラウンドが膨らみ続ける会話を引きずらず小さな入力コストだけを払うということで、ラウンドあたりのコストは上昇せず横ばいになります。しかし新しい出発が前進を保証するわけではなく、安く再スタートできるループは、より多くの再スタートを許してしまいます。 この型を成立させている制御が有界ハンドオフです。ラウンド間の唯一のチャネルなので、構造的にコンテキストの膨張を抑えます。見るべき数字は二つ、目標あたりのラウンド数と、ハンドオフのブロッカー一覧が繰り返していないかです。三回続けて同じブロッカーが現れるループは収束しません。以降のラウンドはすべて純粋な無駄です。 コマンドはツールではない 何を計測するかに関わるので分けておく価値があります。人間のコマンドはスラッシュ接頭辞の指示で、コマンドプレーンを通じて人間向けアダプタへ届きます。探索、解析、ディスパッチ、キャンセル、レンダリングは UI アダプタの担当です。モデルのツールとは明示的に別物であり、ゴールコマンドはこちらに属します。 実務的には、人間がスラッシュコマンドを打つことはモデルがトークンを消費することではありません。両者を分けて帰属させないと、セッション単価が誤った主体を責めることになります。 終わりのない作業への四つの制御 目標あたりの最大ラウンド数を、事後レビューではなく受理の前に強制する。 ラウンドごとではなく、一つのゴールの全ラウンドをまたぐ累積トークン予算を置く。 ハンドオフに対する収束検知。ブロッカーの繰り返しでループを止める。 ゴール作成に明示的な人間の承認を求め、誰が支出を承認したかの監査記録として残す。 関連記事 DeepSeek Harnessとは？完全ガイド サブエージェントと委譲の深さ（英語） ハーネスの支出ガードレール（英語） コスト記録としてのセッションログ（英語） この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # DeepSeek Harnessの支出ガードレール · FinOps LLM URL: https://finopsllm.com/ja/research/deepseek-harness-guardrails DeepSeek Harnessで支出ガードレールをどこに置くか 更新日 August 16, 2026 · 初回公開 August 16, 2026 要約: 月次請求書で初めて自分の予算を知るエージェントに、予算はありません。あるのは事後検証だけです。どのハーネスに対しても有用な問いは「ループのどこに立って『いいえ』と言えるか」であり、DeepSeek Harness は名前の付いた二つのウォーターフォール拡張点でそれに答えます。 まずループの形... 月次請求書で初めて自分の予算を知るエージェントに、予算はありません。あるのは事後検証だけです。どのハーネスに対しても有用な問いは「ループのどこに立って『いいえ』と言えるか」であり、DeepSeek Harness は名前の付いた二つのウォーターフォール拡張点でそれに答えます。 まずループの形 ハーネスはターンとステップのモデルを使います。 ステップ とは一回のモデルリクエストと、そこから生じるツール呼び出しのことです。 ターン はゼロ個以上のステップを含みます。ターンの流れはおおよそ、入力の受理、プロンプト組み立て、 agent/pre-step 、LLM ストリーム、ツール実行、ステップ完了、ターン終了です。 二つのイベントストリームが並走します。 session/event は再生に耐える永続的な事実（チャンク、メッセージ、ツール呼び出し、結果）を運びます。 agent/* はライブの調整シグナル（ステータス、受信箱、リクエスト介入）を運びます。ガードレールは後者に、会計は前者に属します。 介入点 1： agent/pre-step モデルリクエストが送出される前のチェックポイントです。ドキュメントは、返された agent/pre-step の決定が権威を持つこと、そして next() をラップするリスナーは意図的な置換でない限り下流のメッセージを保つことを明記しています。この性質こそが予算ゲートとして使える理由です。リスナーは提案されたステップを拒否も変更もでき、その決定が通ります。 ここに置くべきもの： ターンあたりのステップ上限。 暴走の失敗形態は、収束しないターンです。硬い上限は、青天井の請求を上限付きの請求に変えます。 累積トークン予算。 セッションログのこれまでの使用量を合計し、閾値を超えたら次のステップを拒否します。 モデルのダウンシフト。 ソフト閾値を超えたターンでは、拒否ではなくより安いルートへステップを書き換えます。 コンテキストサイズの制限。 プロンプト組み立てはこのフックより前なので、組み上がったリクエストをここで可視・計測できます。 介入点 2： tools/pre-execute ツール実行は三段のパイプラインです。まず tools/pre-execute ウォーターフォールが走り、次に単調ガード、そのあとで初めてツール本体が、サンドボックス内でファイルシステムの門番付きで実行されます。実行後にはポスト実行ウォーターフォールが結果を受理・遮断・置換・文脈追加でき、 ToolDefinition.finalizeContent が内容の不変条件を同期的に強制します。 権限レイヤーは意図的に非対称です。登録された単調ガードは、識別子を保護されたうえで拒否か棄権のみを行い、決して許可しません。ガードが拒否した場合、あるいは ctx.approval のワンショットプロンプトが存在しないか応答不能な場合、結果は拒否となりツール本体はスキップされます。フェイルオープンではなくフェイルクローズです。 ファイルシステムの変更は別枠で制御されます。通過できるのは fs/write-intent または fs/edit-intent の変更だけです。書き込みはツールが動いた副次的な結果ではありません。 このパイプラインを制御点として信頼できるものにしている性質は二つです。ガードは拒否しかできないこと、そして応答不能な承認プロンプトは拒否になること。自作のエージェント・ポリシー層の多くは承認チャネルが欠けたときフェイルオープンしますが、それこそまさに必要だった場面です。 パイプラインが残す記録 監査証跡は三つのセッションイベントで得られます。実行前の tool/call 、サブ呼び出しの tool/code-dispatch 、そして最終的で権威ある結果の tool/result です。サブ呼び出しが別途記録される点は重要で、内部でファンアウトするモデル可視のツール呼び出しが、そのファンアウトを隠しません。 実用的なガードレールの組み合わせ 制御 フック 止めるもの ターンあたり最大ステップ数 agent/pre-step 収束しないループ 累積トークン上限 agent/pre-step じわじわ進む超過支出 閾値超過でのルート降格 agent/pre-step 安価な作業へのフロンティア価格 コストクラス別ツール許可リスト 単調ガード 安価な文脈での高価なツール サブプロセスとネットワークの拒否 ctx.sandbox ポリシー 計測されない外向き通信 write-intent のゲート ctx.fs シーム レビューされない変更 留保 DeepSeek Harness は developer preview であり、README 自身が互換性を壊す変更を警告しています。ここに挙げたフック名と意味論は今日時点で文書化されているものです。これらに対して作るガードレール・プラグインは後で手を入れるコードだと考え、構築時のバージョンを固定してください。 関連記事 DeepSeek Harnessとは？完全ガイド コスト記録としてのセッションログ（英語） すべてがプラグイン：その構造（英語） エージェントの支出ガードレール（英語） この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # DeepSeek Harness：すべてがプラグイン · FinOps LLM URL: https://finopsllm.com/ja/research/deepseek-harness-plugin-architecture DeepSeek Harness：「すべてがプラグイン」が実際にもたらすもの 更新日 August 16, 2026 · 初回公開 August 16, 2026 要約: DeepSeek AI は deepseek-harness（dsh）を公開しました。MIT ライセンスのエージェントハーネスで、設計上の標語は「すべてがプラグイン」です。この言い回しはエージェント関連ツールの界隈で緩く使われがちなので、ここでの意味と、どこでエージェント運用の経済性を変えるのかを正確にしておく価値があります。 フック付きフレームワークではなく Cordis ハーネスは... DeepSeek AI は deepseek-harness （ dsh ）を公開しました。MIT ライセンスのエージェントハーネスで、設計上の標語は「すべてがプラグイン」です。この言い回しはエージェント関連ツールの界隈で緩く使われがちなので、ここでの意味と、どこでエージェント運用の経済性を変えるのかを正確にしておく価値があります。 フック付きフレームワークではなく Cordis ハーネスは Cordis 上で動きます。プラグインが共有コンテキストにサービス、型付きイベント、可逆な作用を提供するというモデルのプラグインランタイムです。アーキテクチャ文書は、特権的なコアは存在しないと明言しています。モデルアダプタ、ツールレジストリ、セッションログ、そしてエージェントループ自体まですべてプラグインであり、その下に動かせないエンジンが座っていることはありません。 これが重要なのは、「拡張可能」なエージェントフレームワークの通常の形が、固定されたコアにフック面を足したものだからです。観測と装飾はできても、置き換えはできません。置き換えるとはフォークすることです。Cordis はそれを反転させます。置き換えたくなる部品こそが合成の単位なのです。 ケイパビリティ・シーム：運用上いちばん効く部分 ハーネスはこれを ケイパビリティ・シーム （capability seam）として形式化します。シームとは実装が複数あるサービスインターフェースのことで、各サービスは三つの役割のいずれかを占めます。 役割 働き オーナー サービスインターフェースを宣言するパッケージ 実装 具体的な振る舞いを提供するパッケージ（シームには複数ある） コンシューマー どの実装が動いているか知らずにサービスを呼ぶパッケージ すべてのサービスがシームなわけではありません。ドキュメントは三種類を区別します。差し替え可能なシーム（ ctx.llm 、 ctx.subprocess ）、単一オーナーのコアサービス（ ctx.sessions 、 ctx.agents ）、そして他のサービスを調整する合成点（ ctx.agentLoop ）です。どれがどれかを知ることが、振る舞いを差し替えてよい場所とそうでない場所を教えてくれます。 コストに効く四つのシーム ctx.llm ：モデルのシーム。 llm パッケージが所有し、実装には llm-deepseek 、 llm-pi-ai 、 llm-replay があります。エージェントループはプロバイダ中立のストリームサービスを消費し、どのバックエンドが動いているかを知りません。コスト作業で面白いのは llm-replay で、記録済みセッションを推論費用を再度払わずに再実行できます。 ctx.fs ：ファイルシステムのシーム。 実装は fs-local （ホストのファイルシステム）、 fs-sandbox （変更を閉じ込める）、 fs-e2b （リモートのサンドボックス化された Linux 環境）です。モデルから見えるツールと、実行が物理的にどこで起きるかを切り離します。 ctx.sandbox ：実行のシーム。 コンシューマーは argv を渡し、実装がポリシー下で実行を包みます。 sandbox-local はホスト上で強制し、 sandbox-policy はデプロイ既定値を集中管理します。 ctx.subagents ：委譲のシーム。 インプロセス生成、フォーク、ACP ブリッジ、Codex、Claude Code、SDK ベースのエージェントを網羅する六つの実装があります。ふつうのハーネスが前提を固定してしまう箇所が、ここでは差し替えになっています。 エージェントシステムで意味のあるコスト削減レバーは、いずれもプロバイダの差し替えです。より安いモデルへルーティングする、より安いサンドボックスへ実行を移す、サブエージェントのトランスポートをローカルのものに置き換える。それらがシームであれば、変更は設定の編集です。シームでなければ、変更はあなたが以後保守することになるフォークです。 これがアーキテクチャだけでなく FinOps の問題である理由 エージェントのコスト施策で繰り返される失敗は、チームが高価なモデルを選ぶことではありません。ハーネスが高価な選択を構造にしてしまうことです。モデル選択、ツールの実行場所、委譲のトランスポートがアプリケーションコードに焼き込まれると、あらゆる最適化が独自のスケジュールとリグレッションリスクを持つエンジニアリング案件になります。結果としてチームは最適化を先送りし、支出は積み上がります。 シームに基づくハーネスは、それらの判断を合成の側へ移します。無料になるわけではありませんが、リファクタリングから設定へと性質が変わります。四半期の施策と午後一回分の作業ほどの差です。 はっきり述べておくべき留保 DeepSeek Harness は developer preview であり、README は互換性を壊す変更があると和らげずに述べています。いま本番のコストツールを内部インターフェースに直接ぶつけて作るということは、その変化を追い続けることに同意することです。評価とプロトタイプは有益ですが、バージョンは固定し、変動を見込んでください。 関連記事 DeepSeek Harnessとは？完全ガイド コスト記録としてのセッションログ（英語） 支出ガードレールを置く場所（英語） 導入・プロファイル・初回実行（英語） この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # DeepSeek Harnessのセッションログ · FinOps LLM URL: https://finopsllm.com/ja/research/deepseek-harness-session-log コスト記録としてのDeepSeek Harnessセッションログ 更新日 August 16, 2026 · 初回公開 August 16, 2026 要約: 多くのエージェントスタックは、コスト追跡を後付けでボルト留めします。モデル呼び出しをラップして別システムにトークンを書き込み、その別システムはやがて実態からずれていきます。DeepSeek Harness は逆の順序を取ります。セッションログが一次成果物であり、トークン使用量はその中に住んでいます。 セッションは追記専用のイベントログ セッションとは、型付き SessionEvent... 多くのエージェントスタックは、コスト追跡を後付けでボルト留めします。モデル呼び出しをラップして別システムにトークンを書き込み、その別システムはやがて実態からずれていきます。 DeepSeek Harness は逆の順序を取ります。セッションログが一次成果物であり、トークン使用量はその中に住んでいます。 セッションは追記専用のイベントログ セッションとは、型付き SessionEvent エントリの順序付き追記専用シーケンスです。各イベントは四つのフィールドを持ちます。 フィールド 意味 type イベントの種類（例： assistant/message ） seq セッション内で単調増加するシーケンス番号 time タイムスタンプ data 型固有のペイロード サーフェスイベント（UI が表示するもの）はさらに二つのフィールドを加えます。派生元の生イベントを指す sourceEventSeqs と、 surfaceOp です。この逆参照があるからこそ、コストの数値をそれを生んだ正確なイベントまで遡れます。 コストモデルが気にするイベント turn/start と turn/end ：ユーザーリクエストの外枠。 turn/end は完了・中断・打ち切りを示す TurnEndReason を持ちます。 step/start と step/end ：ステップとは、一回のモデルリクエストとそれが引き起こすツール呼び出しのことです。これが自然な課金単位になります。 assistant/message ：モデル出力。任意で TokenUsage を伴います。 assistant/chunk ：ストリーミング出力。使用量チャンクを含みます。 tool/call と tool/result ：ツール実行。結果は meta を持てます。 request/header と request/context ： EpochHeader と、プロバイダ・モデル・コンテキストウィンドウを含むリクエストコンテキスト。この組が使用量の数値に価格を与えます。 ドキュメントの指針は明快です。 モデルから見えるものはログに残る 。モデルのコンテキストに入るものはすべてイベントを残します。つまりログは構成上完全であり、「誰も計測を忘れない限り完全」ではありません。 使用量は出力とともに運ばれる トークン使用量はサイドチャネルに書かれるのではなく、それが属する出力とともに運ばれます。プロバイダが実際に課金した内容に最も近いので、使用量チャンク（ { type: 'usage' } の assistant/chunk ）を優先し、チャンクが無い場合に assistant/message.usage へフォールバックしてください。このように読むコストモデルは、生成していないステップに数値を割り当てることが原理的にできません。 複製ではなく導出された履歴 モデルが見るメッセージ履歴は、イベントログから射影されます。第二の真実として横に保持されるわけではありません。コストの数値が実行と一致するシステムと、両者が乖離してどちらが正しいか誰にも言えないシステムとの差はここにあります。 「モデルから見えるものはログに残る」は、コストの再構成を可能にする唯一の規律です。これが無ければ、あらゆる帰属の数値は誤差幅の分からない推定にすぎません。 この上に何を作るか step/start と step/end を結合してステップスパンを作る。コストを報告する単位はこれです。 各スパンに request/context （プロバイダ、モデル、コンテキストウィンドウ）とチャンク使用量から求めた価格を付与する。 ステップごとの tool/call のファンアウトを数える。ツールの分岐は、あるターンの費用が突然十倍になる典型的な理由です。 TurnEndReason の分布を監視する。中断・打ち切りのターンは成果のない支払い済み作業であり、ログが無ければ最初に失われる指標です。 関連記事 DeepSeek Harnessとは？完全ガイド すべてがプラグイン：その構造（英語） 支出ガードレールを置く場所（英語） OpenTelemetryのGenAI規約（英語） この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # DeepSeek Harnessのサブエージェント · FinOps LLM URL: https://finopsllm.com/ja/research/deepseek-harness-subagents DeepSeek Harnessのサブエージェント：コストを掛け算する委譲 更新日 August 16, 2026 · 初回公開 August 16, 2026 要約: エージェントの請求額をもっとも手早く膨らませる方法は、エージェントにエージェントを生成させることです。一つのユーザーリクエストが木構造になり、その木には自然な大きさがありません。だから DeepSeek Harness は委譲を単なる機能ではなく、明示的な限界を伴うシームとして扱います。 サブエージェントは組み込みではなくシーム 委譲は ctx.subagents... エージェントの請求額をもっとも手早く膨らませる方法は、エージェントにエージェントを生成させることです。一つのユーザーリクエストが木構造になり、その木には自然な大きさがありません。だから DeepSeek Harness は委譲を単なる機能ではなく、明示的な限界を伴うシームとして扱います。 サブエージェントは組み込みではなくシーム 委譲は ctx.subagents を通ります。実装がちょうど一つに定まるシェル実行器とは違い、サブエージェントのプロバイダは名前付きで登録され、複数が共存できます。ドキュメントは六つの転送方式を挙げています。インプロセス生成とフォーク（親のコンテキストを通じた通常のエージェント）、リモート配備用の ACP ブリッジ、Codex、Claude Code、そして SDK ベースの実装です。 コストの観点では、子の値段はそれを生成したプロバイダ次第だということになります。インプロセスでフォークされたエージェントと ACP ブリッジ越しに起動されたリモートエージェントは、呼び出し側のコードでは同じに見えて、請求はまったく別物です。 二つの委譲モード、二つのコスト特性 モード 形 コスト特性 ワンショット 子を生成し、プロンプトを送り、結果を待ち、破棄する 有界で、親のターンに帰属できる 継続可能 常駐アクティベーションを持つ永続的なバックグラウンドセッション 開放的で、ターンをまたいで累積する ワンショットは、終端結果の Promise を伴う実行ハンドルに解決されます。継続可能な子はより重く、継続マネージャがアイデンティティを予約し、子を構成し、すべてのターンを子のインボックス経由で順序付けます。プロバイダが提供するのは初期生成メタデータだけです。アクティベーションには三つの状態があります。実行中、待機中（静止しているが未完了の子アクティベーションを保持）、そして確定です。生きたアクティベーションがない状態でメッセージが届くと、永続化されたセッションからのコールドレジュームが起きます。 コールドレジュームは、皆が忘れる費目です。状態はログから再構成されるため、入力トークンはログの大きさに比例します。たまにしか話しかけない長寿命の子は、常時走っている子よりメッセージあたり高くつくことがあります。 能力は静かにではなく、大きな音で失敗する ハーネスは要求された能力をプロバイダに照らして検証し、黙って無視するのではなく型付きエラーで拒否します。起動時の能力は出力スキーマ、深さ制限、ツールフィルタ、ペルソナをカバーし、リクエストオプションと一対一で対応します。プロバイダが対応しない指定は起動時に判明し、請求書で判明することはありません。 深さには上限があり、その上限は迂回できない 委譲の深さはセッションヘッダに永続化され、ランタイムのフィールドは大きい方の値を追跡します。したがってコールドレジュームで深さを下げることはできません。導出された深さが maxDepth または安全整数の範囲を超える場合、起動は拒否されます。 三つの子を生成し、その各々がさらに三つを生成する親は、一つのユーザーリクエストを十三のエージェントに変えています。深さ上限は、自分でサイズを決めたファンアウトと、後から発見したファンアウトとの違いです。 発見は安く、配送は権威を持つ listChildren() はライブを優先したコーパスを、三層の高速化（ウォーターマークキャッシュ、次に射影チェックポイント、次に永続層の検査）で返します。 listDescendants() は先行順で走査し、親と深さの位置を付け足します。どちらもエージェントレジストリやアクティベーション、プロバイダを参照せず、メッセージ配送が権威であり続けます。コスト帰属の観点では、木をいつでも安く列挙できるということです。 結果は停止理由を伴う 出力は最後の非空アシスタントメッセージ、あるいは蓄積されたテキストストリームです。任意の構造化出力は要求スキーマに照らして検証されます。 stopReason はマージ拡張可能なユニオンで、completed、aborted、error、max-tokens、refusal を取ります。completed 以外はすべて部分出力を意味し、エラーのツール結果へ写像されます。支払い済みで、未完了です。 測るべきもの 親ターンあたりの子の数と、ユーザーリクエストあたりの子孫の数。 観測された最大深さと、設定された上限の対比。 コールドレジュームされた継続可能な子の割合と、再開時のログサイズ。 停止理由の分布。max-tokens や error の比率が高ければ、それは支払い済みの未完了作業です。 関連記事 DeepSeek Harnessとは？完全ガイド すべてがプラグイン：その構造（英語） ハーネスの支出ガードレール（英語） コスト記録としてのセッションログ（英語） この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # DeepSeek Harnessのツールスコープと制限 · FinOps LLM URL: https://finopsllm.com/ja/research/deepseek-harness-tool-scopes DeepSeek Harnessのツールスコープ、制限、シャドーイング 更新日 August 16, 2026 · 初回公開 August 16, 2026 要約: ツールカタログは膨らみます。誰かがブラウザツールを足し、誰かがデータベースツールを足し、誰かがターミナル操作を五つ足す。一年後には、必要かどうかに関係なくシステム内のすべてのエージェントに四十個のツールが提示されています。これは普通、安全性の問題として語られます。同時にコスト項目でもあります。DeepSeek Harness は、その両方に一度に効くエージェント単位のスコープモデルを備えています。... ツールカタログは膨らみます。誰かがブラウザツールを足し、誰かがデータベースツールを足し、誰かがターミナル操作を五つ足す。一年後には、必要かどうかに関係なくシステム内のすべてのエージェントに四十個のツールが提示されています。これは普通、安全性の問題として語られます。同時にコスト項目でもあります。 DeepSeek Harness は、その両方に一度に効くエージェント単位のスコープモデルを備えています。 カタログが継続コストである理由 ツール定義はリクエストの一部です。ハーネスは、送信されたとおりの設定、システムプロンプト、ツールセットを載せたリクエストヘッダーイベントを記録します。これが論点を具体化します。カタログはセッション中のすべてのモデルリクエストで再送されるため、一度きりの費用ではなくステップごとの固定税です。 もう一つ、より大きな効果があります。広いカタログはモデルの選択空間を広げます。もっともらしいが誤ったツール選択が増えれば、何も生まない無駄なステップが増え、ステップこそが課金単位です。面を刈り込むことで、トークンの下限と誤り率が同時に下がります。 語彙 用語 意味 スコープ ツール、プロンプト、変数、制限、リスナーのエージェント単位の登録単位 スコープキー スコープを識別する不透明な同一性。オブジェクト同一性で比較され、通常は生きているエージェント自身 エージェントコンテキスト エージェント自身のスコープ付きコンテキスト。登録は寿命に縛られ、スコープ内で可視 制限（restriction） 一つのスコープに対するグローバルツールセットの絞り込み。積集合で適用される シャドーイング スコープ内の項目が同名のグローバル項目を、そのスコープ内に限って置き換えること セットアップウィンドウ 作成者がエージェントのスコープ世界を組み立てる生成の枠。公開や最初のプロンプト組み立ての前 合成の解決順序 まず制限がグローバルセットを絞り込み、その後にスコープローカルの登録が合流します。この順序こそが最小権限を実務的にします。グローバルカタログとの積集合から始めるのでグローバルを超えることは決してなく、そこにこのエージェントが必要とするエージェント固有のツールだけを足します。 シャドーイングは、フォークなしで差し替えを実現します。あるエージェントだけが、見慣れたツール名の裏で別の実装（読み取り専用版、計測付き版、より安いバックエンド）を受け取り、他のエージェントは引き続きグローバル版を見ます。 寿命への束縛が重要なのは dispose と同じ理由です。スコープ登録はエージェントのコンテキストとともに終わるので、短命な子が親の世界へ寄与を漏らすことはありません。 合成はすべて、エージェントが公開され最初のプロンプトを組み立てる前の、セットアップウィンドウで起こります。最初のプロンプトの後に下される権限の判断は、もはや権限の判断ではなく後片付けです。 スコープ付きディスパッチと系譜 あるエージェントに関するイベントは、そのエージェントのキャリアとともにディスパッチされるため、リスナーは誰の活動を見ているか判別できます。レジストリレベルのイベントは絞り込まれません。これとは別に、系譜（親セッション、委譲の深さ、サブエージェントの深さ）は、それ自体が可視性に影響しないデータだと明示されています。 この分離は借用する価値があります。子は子であるという理由でアクセスを継承しません。アクセスはそのセットアップウィンドウで意図的に組み立てられます。既定で継承される権限こそ、安価な要約用サブエージェントが親と同じ高価なツールセットを抱える経路です。 ここから実行する四つのこと ツール定義の数を数え、セッションあたりのステップ数を掛ける。それがトークンで見たセッション固定のツール税です。 エージェントの役割ごとに実用最小のツールセットを定義し、慣習ではなく制限として強制する。 価値の低い文脈では高価なツールを完全に外すのではなく、安価版や読み取り専用版でシャドーイングする。 親のツールセットを既定でサブエージェントに継承させない。必ず組み立てる。 関連記事 DeepSeek Harnessとは？完全ガイド ハーネスの支出ガードレール（英語） サブエージェントと委譲の深さ（英語） 「すべてはプラグイン」の利点（英語） この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # LLM評価パイプラインにコスト制御を組み込む · FinOps LLM URL: https://finopsllm.com/ja/research/evals-cost-control LLM評価パイプラインにコスト制御を組み込む 更新日 August 27, 2026 · 初回公開 August 27, 2026 要約: LLM評価には独自のコスト方針が必要です。CIで大量のプロンプトを毎回実行すると、機能そのものより高くなることがあります。実行予算、代表サンプル、キャッシュ、品質ゲートを使います。実行を予算化する開始前にプロンプト、モデル、リトライ、金額を制限し、スモーク、夜間、リリース評価を分けます。品質とコストで停止する品質基準または金額上限を超えたら停止し、モデル、トークン、キャッシュ、リトライ、結果を記録... LLM評価には独自のコスト方針が必要です。CIで大量のプロンプトを毎回実行すると、機能そのものより高くなることがあります。実行予算、代表サンプル、キャッシュ、品質ゲートを使います。 実行を予算化する 開始前にプロンプト、モデル、リトライ、金額を制限し、スモーク、夜間、リリース評価を分けます。 品質とコストで停止する 品質基準または金額上限を超えたら停止し、モデル、トークン、キャッシュ、リトライ、結果を記録します。 関連記事 成功タスク単価 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # LLM・生成AI向けFinOps：実践フレームワーク · FinOps LLM URL: https://finopsllm.com/ja/research/finops-for-llm LLM向けFinOps: 実践的なフレームワーク LLM向けFinOpsは、AI支出を可視化、配分可能、最適化可能、および説明責任ある状態にする実践です。クラウドFinOpsの原則を借りていますが、費用ドライバーが異なります。クラウド請求書はインスタンス、ストレージ、転送、および契約によって決まります。LLM請求書は入力トークン、出力トークン、キャッシュ書き込み、キャッシュ読み取り、リトライ、モデルミックス、コンテキスト長、バッチ適格性、および品質要件によって決まります。 チームが犯す最初の間違いは、LLM支出をプロバイダーレベルの単一の数字として扱うことです。これは真の要因を隠してしまいます。サポート要約エンドポイント、エージェントワークフロー、夜間エンリッチメント作業、および評価スイートはすべて同じモデルを使用する可能性がありますが、レイテンシニーズ、品質しきい値、キャッシュ可能性、および所有権が異なります。FinOpsは、これらのワークロードが分離されたときに始まります。 柱 中核となる質問 成果物 1. 可視性 実際には、リクエストごとに何を支払っているのか？ 入力、出力、キャッシュ書き込み、キャッシュ読み取り、バッチ、およびリトライ支出に分割された正規化された使用記録 2. 配分 どのチーム、機能、顧客、またはワークロードがそれを引き起こしたのか？ 所有者にマップされた支出：環境、エンドポイント、チーム、テナント、モデル、ワークロードクラス 3. 最適化 品質を損なわずに成功したタスクあたりのコストを削減する要因は何か？ フラグの背後に展開されたルーティング、キャッシング、バッチ処理、圧縮、および裁定取引の変更 4. 説明責任 毎月誰が数字をレビューして行動するのか？ ショーバック（その後チャージバック）レポートと請求書と照合された運用リズム 1. 可視性 可視性とは、プロバイダー請求書とゲートウェイログを共通レコードに正規化することです。各リクエストは、次の質問に答えるための十分なメタデータを含む必要があります：誰が所有者か、どの機能がそれを生成したか、どのモデルがそれを処理したか、何種類のトークンが請求されたか、呼び出しがリトライされたかどうか、および出力がユーザーに価値をもたらしたかどうか。 良好な可視性は、入力、出力、キャッシュ書き込み、キャッシュ読み取り、バッチ、およびリトライ支出を分離します。この分離がなければ、チームはキャッシュ読み取りディスカウントを誤って節約としてカウントし、リトライループを見逃し、プロバイダーを定価ではなく成功したタスクあたりのコストで比較します。 2. 配分 配分は、支出をチーム、製品、顧客、およびワークロードにマップします。ポイントは責任ではなく、決定品質です。財務チームは、すべての行が「OpenAI」と表示されている場合、支出をガバナンスできません。エンジニアリングリーダーは、支出がプロバイダーアカウント別にのみグループ化されている場合、製品表面を最適化できません。 最低限の有用な配分は通常、環境、エンドポイント、チーム所有者、許可されている場合は顧客またはテナント、モデル、プロバイダー、およびワークロードクラスを含みます。成熟したプログラムは、解決されたチケット、完了した分析、生成されたレポート、または成功したエージェントタスクなどのビジネスメトリクスを追加します。 3. 最適化 最適化は配分に従う必要があります。一般的な要因は、モデルルーティング、セマンティックキャッシュ、プロンプトキャッシュ、コンテキスト圧縮、バッチルーティング、プロバイダー裁定取引、およびフォールバックポリシー調整です。各要因は請求書を異なる方法で変更します。ルーティングはモデルミックスを変更します。キャッシュは入力トークンとレイテンシの経済学を変更します。バッチは割引された非同期レーンに作業を移動します。圧縮は反復されたコンテキストを削減します。 テストは「トークン数が下がったか？」ではありません。テストは「品質、レイテンシ、または信頼性を損なわずに、成功したタスクあたりのコストが下がったか？」です。 4. 説明責任 ショーバックはチャージバックの前に来る必要があります。最初にチームに彼らの支出とドライバーの信頼できる月次ビューを与えます。数字が信頼されたら、チャージバックは成熟した組織にとって意味があります。目標は繰り返し可能な運用リズムです：最大のドライバーをレビューし、最適化候補に同意し、フラグの背後に変更を展開し、次の請求書と照合する。 関連 LLM FinOpsとは？ - 運用規律。 AI FinOps - LLM FinOpsが適合する、より広い実践。 LLM費用配分 - 配分レイヤーの動作方法。 LLMチャージバックとショーバック - 支出を所有者に移動。 自分のLLM支出に適用したいですか？FinOps LLMはAI費用の無料監査を実施し、節約場所を示します。 無料監査を予約 → リサーチに戻る --- # AI中心の製品で初めて行う月次締め · FinOps LLM URL: https://finopsllm.com/ja/research/first-ai-month-end-close AI中心の製品で初めて行う月次締め 更新日 August 27, 2026 · 初回公開 August 27, 2026 要約: AIの月次締めはダッシュボードの画像ではなく、プロバイダーの請求書と固定した期間から始めます。まず金額を確定し、次に利用量を説明し、その後で配賦します。期間を固定するタイムゾーン、通貨、割引、クレジット、請求の締め日を定義します。価格表と請求ID、テレメトリ期間を保存します。照合して配賦するプロバイダー、アカウント、モデル、トークン種別、日付でイベントと請求を結合します。残差を調査し、機能、チーム... AIの月次締めはダッシュボードの画像ではなく、プロバイダーの請求書と固定した期間から始めます。まず金額を確定し、次に利用量を説明し、その後で配賦します。 期間を固定する タイムゾーン、通貨、割引、クレジット、請求の締め日を定義します。価格表と請求ID、テレメトリ期間を保存します。 照合して配賦する プロバイダー、アカウント、モデル、トークン種別、日付でイベントと請求を結合します。残差を調査し、機能、チーム、環境、顧客区分、ワークロードに配賦します。 差分を説明する 料金、量、構成、効率に分解し、デプロイ、トラフィック、モデル移行、エージェント挙動と結び付けます。 関連記事 AI請求の照合 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # FOCUS 1.5のAIトークン追跡と標準化ガイド · FinOps LLM URL: https://finopsllm.com/ja/research/focus-1-5-ai-token-tracking FOCUS 1.5：AIトークン追跡とPrice Sheet標準化の全貌 更新日 September 19, 2026 · 初回公開 August 15, 2026 要約: FinOps Foundation は FOCUS 1.5 を 2026 年 12 月に確定仕様としてリリースします。FinOps Open Cost and Usage Specification に初めて AI ネイティブなトークン消費フィールドが追加され、モデル識別子、入力および出力トークン量、さらにプロバイダー定価を扱う Price Sheet データセット が新設されます。1.... FinOps Foundation は FOCUS 1.5 を 2026 年 12 月に確定仕様としてリリースします。FinOps Open Cost and Usage Specification に初めて AI ネイティブなトークン消費フィールドが追加され、モデル識別子、入力および出力トークン量、さらにプロバイダー定価を扱う Price Sheet データセット が新設されます。 1. FOCUS 1.5 が標準化するもの これまで Bedrock、Azure OpenAI、Vertex AI などクラウドごとにバラバラだった請求形式が、単一の標準スキーマに統合されます： モデル識別子の標準化： プロバイダーをまたいだ統一名称。 トークン種別の分離： 入力、出力、キャッシュ読み取りトークンを独立した列として記録。 Price Sheet データセット： 消費ログと公表定価を分離し、実効割引率の監査を容易化。 2. FOCUS 1.5 が解決しない領域 FOCUS はプロバイダーが発行するデータの規格化であり、 自社内の利用部門別アトリビューション は解決しません。どの機能や顧客が呼び出しを行ったかはプロバイダーには見えないため、社内 AI ゲートウェイでのタグ付けとコンテキスト伝播が引き続き必須です。 3. 今から準備すべきこと トークン総量ではなく種別ごとにログを保持し、呼び出しごとにモデル ID を記録し、実行時の価格表を保存しておくことで、1.5 への移行がスムーズになります。 関連記事 LLMコストの組織別帰属付け AI請求書の月次照合実務 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # 無料枠は顧客獲得コストである · FinOps LLM URL: https://finopsllm.com/ja/research/free-tier-is-an-acquisition-cost 顧客獲得コストとしての無料枠 更新日 September 1, 2026 · 初回公開 September 1, 2026 要約: 推論の提供は無料ではありません。無料枠、プレビュー期間の緩いレート制限、無料で叩けるブランドなしのエンドポイント — その計算資源は必ず誰かが、名前のついた予算から払っています。それは顧客獲得コスト（CAC）であり、他のあらゆる CAC と同じように振る舞います。財務チームにとって最も有用な見方です。CAC... 推論の提供は無料ではありません。無料枠、プレビュー期間の緩いレート制限、無料で叩けるブランドなしのエンドポイント — その計算資源は必ず誰かが、名前のついた予算から払っています。それは顧客獲得コスト（CAC）であり、他のあらゆる CAC と同じように振る舞います。 財務チームにとって最も有用な見方です。CAC の動きは予測できるからです。あるコホートを獲得するために使われ、回収期間があり、獲得が済めば止まります。 無料枠が買っているもの 調達プロセスを通さない 評価 。計算資源より価値のある 実ワークロードのデータ 。そして 価格のアンカー — ゼロ円で慣れた機能は、他社の有料料金を高く見せます。 読むべきシグナル 価格が上がる前に、まずレート制限が下がります。同時実行数、コンテキスト上限、無料枠に含まれるモデルの範囲 — 新しい価格表が出る前にこれらが動きます。 使い方 無料枠をユニットエコノミクスに入れない。 推論の一部が無料だから成立する利益率は、利益率ではなく、期限を自分で決められない補助金です。 無料利用にシャドウ単価を付ける。 直近の有料料金をテレメトリ上で無料トラフィックに適用し、その数字を予測に載せます。 離脱が安いうちに切り替えコストを測る。 少なくとも 1 経路には第二のプロバイダーを配線しておきます。 関連記事 プロバイダー間アービトラージ この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # GPT-5.6 料金ティアガイド：Luna、Terra、Sol · FinOps LLM URL: https://finopsllm.com/ja/research/gpt-5-6-pricing-tier-guide GPT-5.6 料金ティアガイド：Luna、Terra、Sol 公開日：2026年7月19日 OpenAIは7月10日にGPT-5.6を3つの異なる料金ティアで発表しました：Lunaが$1/$6 per 1M tokens、Terraが$2.50/$15、Solが$5/$30。これは単なるスピード/品質のトレードオフではありません。各ティアは異なるクラスのワークロード向けに位置付けられています。質問は「どれが最高か」ではなく「このタスクには何が正しいか」です。このガイドはタスクをティアにマップし、タスクあたりのコスト例を説明し、安いティアが十分に確信できない場合に知的にカスケードする方法を示します。 Luna（$1/$6）：分類、単純な抽出、大量ルーティング Terra（$2.50/$15）：バランスの取れた推論、エージェントループ、マルチターン会話 Sol（$5/$30）：フロンティア推論、コード生成、困難な研究 キャッシュ読み取りは90%節約；キャッシュ書き込みは入力の1.25倍 — 30分間に5回以上のヒットで損益分岐点 バッチAPIは非対話型作業の場合、ティア料金に加えて50%割引を追加 重要な注意： OpenAIはTerraとSolを同等の推論能力を持つと位置付けており、主にスピードとスループットで異なります。実際のワークロードに対して両方をベンチマークしてください — 同等性の主張はあなたのデータ分布では常に成立するわけではありません。 GPT-5 vs 代替品 でClaudeとDeepSeekとの比較を参照してください。 1. 3つのティア：スピード、コスト、能力 ティア 入力 $/1M 出力 $/1M キャッシュ読取 $/1M コンテキスト 典型的なレイテンシ Luna $1.00 $6.00 $0.10 128K 80–200 ms Terra $2.50 $15.00 $0.25 128K 150–400 ms Sol $5.00 $30.00 $0.50 128K 300–800 ms レイテンシが重要： Lunaは最速です。ストリーミング、リアルタイム分類、スループット用に最適化されているからです。Solは最遅です。より多くの内部推論を実行しているからです。対話的なユーザーフェーシング型ワークロードについて、Lunaも安いです そして 速いです — ただし、タスクに対して十分に能力がある場合のみです。これが重要なルーティング決定です。 2. タスク型ルーティング表 この表は一般的なLLMタスクを、成功したレスポンスあたりのコストを最小化するティアにマップします： タスク型 例 推奨ティア ティアでの成功率 推定コスト/1K タスク 分類 スパム/非スパム；感情（肯定/否定/中立） Luna 95–98% $1.20–$1.50 構造化抽出 テキストから名前、メール、電話を抽出 Luna 92–96% $1.80–$2.40 カテゴリ化（多クラス） 50以上の製品カテゴリのいずれかを割り当て Luna 88–94% $2.40–$3.20 要約 記事またはチャットログを凝縮 Luna 92–97% $1.50–$2.00 エージェント ループ（ツール利用） マルチターン：検索、推論、精緻化 Terra 85–92% $8.00–$12.00 マルチターン会話 顧客サポート、アドバイザリーボット Terra 88–94% $6.00–$10.00 コード生成（単純） SQLクエリ、Bashスニペット、正規表現 Terra 80–90% $10.00–$15.00 コード生成（複雑） 完全なエンドポイント、ステートマシン、DSLコンパイラ Sol 75–88% $25.00–$40.00 研究+統合 10以上の論文を分析、コンセンサスを統合 Sol 80–90% $30.00–$50.00 困難な推論（新規問題） 証明検証、新規アルゴリズム設計 Sol 70–85% $40.00–$70.00 主要な洞察： タスクあたりのコストはAPIコストだけではなく、(APIコスト)/(成功率)です。95%の成功率のLuna分類は成功したレスポンスあたり~$1.26です。同じタスクをSolに98%の成功率でルーティングした場合、レスポンスあたり~$5.10支払いますが、ワークロードの3%多く解決しました。それが4倍のコストに見合う価値があるかどうかはわかりません。 3. タスクあたりのコスト実例 例1：スパム分類（Luna） タスク： メールをスパム（はい/いいえバイナリ）として分類。 典型的なトークンプロファイル： 400入力（メール）+50出力（分類+確信度）=450トークン。 Lunaコスト： (400 × $1/1M) + (50 × $6/1M) = $0.00043/リクエスト。 96%が初回で成功した場合： $0.00043 / 0.96 = $0.00045 per successful classification。 月間100万メールで： $450/月（システムプロンプトを再利用する場合、キャッシュ割引プラス）。 誤ってSolにルーティングされた場合： (400 × $5 + 50 × $30) / 1M = $0.0025 per リクエスト。98%の成功：$0.00255/成功 = $2,550/月（5.7倍以上）。 例2：顧客サポートエージェント（Terra） タスク： ツール利用を含むマルチターンサポート会話（チケット検索、ポリシー検索、エスカレーション決定）。 ターンあたりの典型的なトークンプロファイル： 2,000入力（コンテキスト+履歴）+400出力（応答+ツール呼び出し）=2,400トークン。解決までの平均3ターン=チケットあたり7,200トークン。 Terraコスト： (2,000 × $2.50/1M) + (400 × $15/1M) = $0.0080/ターン or $0.0240 per チケット。 90%がエスカレーションなしで解決した場合： $0.0240 / 0.90 = $0.0267 per 成功したチケット。 月間10Kチケットで： $267/月。 代わりにLunaを使用した場合： (2,000 × $1 + 400 × $6) / 1M = $0.0044 per ターン = $0.0132/チケット。しかしLunaのエージェントループ成功は65%に低下（ツール呼び出しが失敗、推論が浅い）。成功あたりのコスト：$0.0132 / 0.65 = $0.0203。純粋な節約：$29/月ですがチケットの25%が失敗してエスカレート、サポートコストが$400以上上昇。Lunaはここでは機能しません。 例3：コード生成（Terra vs Sol） タスク： 要件文字列からPython関数を生成。 典型的なトークンプロファイル： 1,500入力（仕様+例）+600出力（コード+説明）=2,100トークン。 Terraコスト： (1,500 × $2.50 + 600 × $15) / 1M = $0.0134 per リクエスト。85%の初回成功（コードがコンパイル+基本テスト合格）：$0.0158 per 動作する関数。 Solコスト： (1,500 × $5 + 600 × $30) / 1M = $0.0255 per リクエスト。90%の初回成功：$0.0283 per 動作する関数。 Terraでの節約： 動作する結果あたり44%安い。成功率の5%の差とコード品質が下流のデバッグコストを測定可能に削減した場合のみSolを使用してください。 4. カスケード & フォールバック ルーティング パターン ほとんどのFinOpsチームはすべての作業に単一のティアを使用すべきではありません。代わりに、カスケードパターンを実装します：最も安いティアから始め、確信度を測定し、低い確信度でエスカレート。 ステップ モデル 確信度の閾値 閾値を満たさない場合のアクション 1 Luna 確信度 > 85% 結果を返す 2 Terra 確信度 > 75% 結果を返す（エスカレート済み） 3 Sol 確信度 > 60% 結果を返すか明示的に失敗 4 人間による確認 — 人間にエスカレート 実際のシナリオ： インボイスの文書分類（ベンダー別に分類）を行っています。Lunaは高い確信度の結果（~94%成功）を返し、1Kあたり~$1.20のコストです。Lunaが確信度 5. プロンプトキャッシュの経済学 GPT-5.6はキャッシュコストを変更しました：キャッシュ書き込みは キャッシュなしの入力レート1.25倍 （フリーではない）、キャッシュ読み取りは入力の10%のコストです。 シナリオ プレフィックスサイズ 書き込みコスト 読み取りコスト（ヒットあたり） 損益分岐点ヒット 10ヒット/月での節約 Lunaキャッシュ検索コンテキスト 100Kトークン $0.125 $0.010 15 ヒット -$0.025 （損失） Lunaキャッシュシステムプロンプト + ドキュメント 50Kトークン $0.063 $0.005 8 ヒット $0.032 Terraキャッシュエージェント コンテキスト 80Kトークン $0.250 $0.020 14 ヒット $0.030 Solキャッシュ推論コンテキスト 100Kトークン $0.625 $0.050 13 ヒット $0.025 キャッシュをいつ： プロンプトに安定したプレフィックス（システム指示、ドキュメント、少数ショット例）が30分ウィンドウ内に5～10回以上再利用される場合、キャッシュは通常お金を節約します。バッチAPI（50%割引）はキャッシュのコストと競い合っています — ドキュメントをバッチで分類する場合、バッチ割引がキャッシュのオーバーヘッドを上回ります。 6. Claude Sonnet 5、Gemini 3.1 Pro、DeepSeek V4との比較 モデル 入力 $/1M 出力 $/1M スピード 推論能力 選ぶべき場合 GPT-5.6 Luna $1.00 $6.00 高速 指示追従、ルーティング 分類、抽出、スループット GPT-5.6 Terra $2.50 $15.00 中程度 中程度の推論、ツール利用 エージェント、マルチターン、中コード GPT-5.6 Sol $5.00 $30.00 低速 フロンティア推論、研究 複雑なコード、困難な推論、新規問題 Claude Sonnet 5 $2.00–$3.00 $10.00–$15.00 中-高速 強い推論、長い推論トークン 推論、コーディング（Solと競争） Gemini 3.1 Pro $2.00 $12.00 中程度 マルチモーダル、研究能力 マルチモーダルタスク、Terraと競争 DeepSeek V4 Flash $0.14 $0.28 非常に高速 基本推論、キャッシュ入力フォーカス 大量ルーティング、キャッシュ重視ワークロード（7～35倍安い） コスト仲裁： 単純な分類と抽出については、DeepSeek V4 Flashはlunaより7～20倍安いです。データに対してベンチマークしてください — 90%以上の精度を達成した場合、これを使用し差分を確保してください。Claude Sonnet 5はTerraより2倍高価ですが、モデル能力請求あたり強い推論を提供しています；Terraベンチマークが不十分な品質を示した場合は使用してください。Gemini 3.1 ProはLunaとTerraの間に位置しています — マルチモーダル入力が必要な場合またはVertex AIエコシステムに既にいる場合に有用。 7. GPT-5/5.5からの移行 & 非推奨ステータス OpenAIはGPT-5.6と並んでGPT-5.5（$5/$30、Solと同じ）およびGPT-5.4（$2.50/$15、Terraと同じ）の提供を続けています。古いモデルに対する 非推奨圧力はない — コードがそれを対象にしている場合、GPT-5.5を使い続けることができます。ただし、GPT-5.6は同じティアでパフォーマンス同等性（またはそれ以上）を主張しているため、新しいデプロイメント向けに5.6に移行してください。 ChatGPTインターフェースは古いモデルのローリング廃止を続けています（GPT-4o mini、GPT-4 turboは読み取り専用）；API アクセスは安定しています。APIに対して構築する場合、モデル非推奨ステータスの年1回のレビューを計画してください。ただし急いで期待しないでください。 コスト測定フレームワーク ステップ 1：ティア別にベースラインを確立 1週間のトラフィックを実行し、どのティアが各リクエストを処理したかをログします。これはベースライン分布とコストを提供します。 ステップ 2：確信度スコアとフォールバックレートを測定 各ティアについて、返された確信度をログします。計算：Luna呼び出しの何％が確信度>85%を持ちますか？何％がTerraにカスケードしますか？これはカスケードがバランスしているかを示します。 ステップ 3：ティア別成功/失敗を監査 モデル出力を1週間の真実と比較します。どのティアがあなたのデータで不十分なパフォーマンスを示しますか？OpenAI主張ではなく、実際の精度に基づいてしきい値またはティア選択を調整します。 ステップ 4：成功したレスポンスあたりの実際のコストを計算 実際のコスト = (tier_cost) / (success_rate)。Lunaが94%の成功で1Kあたり$1.20のコストの場合、動作するレスポンスあたりのコストは$1.28です。これは最適化する指標です。 クイックティア選択チェックリスト これは分類、抽出、またはルーティングタスクですか？→ 精度が重要でない限りLuna。 タスクはツール利用またはマルチターン推論に関与しますか？→ Terra。 これは新規推論、複雑なコード、またはマルチホップ分析ですか？→ Sol（または最初にClaude Sonnet 5をベンチマーク）。 カスケード（Luna → Terra → Sol）を実装できますか？→ はい、これは通常最適です。 安定したプレフィックス（システムプロンプト、ドキュメント）が月に10回以上再利用されていますか？→ キャッシュし、損益分岐点（5～15ヒット）でROIを測定してください。 これはバッチ処理か対話的か？→ バッチ作業は50%割引の対象；バッチAPIでROIを再計算してください。 代替品（Claude、DeepSeek、Gemini）をベンチマークしましたか？→ マーケティング主張ではなく、データで行ってください。 ティア選択は分類問題です：ワークロードプロパティをティア経済学にマッチさせます。理想はカスケードルーティング — 最初にLunaにルート、確信度を測定、不確実性でエスカレート。これはコストを最小化しながら品質を維持します。FinOps LLMはLLMトラフィックのコスト監査を実行し、ティアの不一致がテーブルにお金を残しているはどこかを示します。 無料監査を予約 。 参照してください： GPT-5 はいくらかかる？ 完全なGPT価格設定状況のための、と 隠れたLLMコスト トークンあたりの手数料を超えたインフラストラクチャとフォールバックオーバーヘッド。 リサーチに戻る FAQ GPT-5.6の分類タスクにはどのティアを使うべきですか？ Luna（$1/$6 per 1M）は分類と単純な抽出に適しています。入力600トークン+出力100トークンで、Lunaは$0.00066/リクエスト対Terraの$0.00175/リクエストです。精度がボトルネックでなければ、Lunaは62%の節約で同等の結果を提供します。 Terra（$2.50/$15）がSol（$5/$30）を上回るのはいつですか？ 常にです。Terraはパフォーマンス/コストの最適ポイントとして位置付けられています：Solと同じ機能要件ですが、正確に半額です。エージェントループ、マルチターン会話、中程度の推論タスクにTerraを使用してください。Terraの推論深度が明らかに不十分な場合にのみSolを使用します。 GPT-5.6のプロンプトキャッシュのコスト影響は何ですか？ キャッシュ書き込みは入力の1.25倍（例：Lunaで$1.25 per 1M）です。キャッシュ読み取りは入力の10%（Lunaで$0.10 per 1M）です。100Kトークンのプレフィックスが30分以内に5回以上再利用される場合、キャッシュはキャッシュなしの繰り返し呼び出しと比べて60%以上の節約となります。 GPT-5.6はClaude Sonnet 5とDeepSeek V4とどう比較しますか？ Luna（$1/$6）はClaude Sonnet（$2/$10 intro、$3/$15 Sept 1）より50-60%安く、DeepSeek V4 Flash（$0.14/$0.28）はLunaより7-20倍安いです。推論ワークロードについては、Sol（$5/$30）とClaude Sonnetは異なるパフォーマンス対ドルをトレードしています；ユースケースをベンチマークしてください。 --- # Claude Max対Alibaba Token Pro費用比較 · FinOps LLM URL: https://finopsllm.com/ja/research/heavy-agentic-coding-cost-claude-vs-qwen Claude Max対Alibaba Token Pro：Agentic Codingの真の費用 更新日 September 19, 2026 · 初回公開 August 6, 2026 要約: 自律型コーディングが単一の補完から、コーディネーターがリファクタリングやテスト用に4〜8体のサブエージェントを展開するマルチエージェント・スウォームへ移行すると、トークン消費量は急増します。カタログ単価での比較は誤った調達判断を招きます。1. 課金単位の根本的な違いAlibaba Token... 自律型コーディングが単一の補完から、コーディネーターがリファクタリングやテスト用に4〜8体のサブエージェントを展開する マルチエージェント・スウォーム へ移行すると、トークン消費量は急増します。カタログ単価での比較は誤った調達判断を招きます。 1. 課金単位の根本的な違い Alibaba Token Pro（月額$70） は5時間あたり12,000クレジット、7日間で40,000クレジットという明確な枠を提供します。深夜オフピークには0.2倍のクレジット割引が適用され、夜間の自動バッチ処理に圧倒的な経済性を発揮します。 Claude Max 20x（月額$200） は固定トークン枠を開示しない動的キャパシティ契約であり、Opus 5による高い1発成功率と長文コードベースの理解力を誇ります。 2. 損益分岐点とエンジニア人件費 月額費用の観点では、Qwen 3.8-MaxがOpus 5の 35%の承認タスク生産性 を達成できれば、タスクあたりの費用はAlibabaの方が安くなります。 一方、開発者の人件費が時給$50の場合、Opus 5が手動レビューや修正作業を 月間2.6時間 （時給$100なら1.3時間）削減するだけで、$130の差額は完全に回収されます。 関連記事 コスト監査：Alibaba対Claude Max AI価格表を直接比較できない理由 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # Claude の返答すべてに入っている見えない印 · FinOps LLM URL: https://finopsllm.com/ja/research/how-ai-watermarking-works AI 電子透かしの仕組み 更新日 September 1, 2026 · 初回公開 September 1, 2026 要約: 対応する Claude... 対応する Claude モデルが生成したテキストには、目に見えない信号が入っています。あなたにも利用者にも見えず、意味も品質も変えず、請求書にも現れません。それでも存在します。理解しておく価値があるのは、それを壊すものが、あなた自身のパイプラインが毎日行っている処理そのものだからです。 テキストでの仕組み 言語モデルは最も確率の高いトークンを選ぶわけではありません。確率分布から乱数を使ってサンプリングします。電子透かしの技術は — SynthID-Text のアプローチに沿って — その乱数に偏りを与えます。検出器だけが知るパターンに従い、特定のトークンがごくわずかに選ばれやすくなるのです。 単語ひとつを取れば何の変哲もありません。もっともらしい代替は元から存在し、モデルはそのどれかを選んだだけです。しかし数百トークンにわたると、そのパターンは統計的な信号として蓄積し、検出器には測定でき、読者には知覚できません。ここから 2 つの帰結が出ます。これは印章ではなく統計であること、そして長さを必要とすることです。ツイート程度の出力は、1 ページ分に比べてはるかに弱い信号しか持ちません。 画像は逆の仕組み 生成された .svg ・ .png ・ .jpg ファイルには C2PA メタデータ、すなわち暗号署名されたマニフェストが付きます。統計的でも隠されてもおらず、正確に検証できるデータブロックです。トレードオフは予想どおりです。署名メタデータは確実性を与えますが、コマンド 1 つで削除できます。統計的な透かしはきれいには消せませんが、編集・言い換え・翻訳で劣化します。どちらも錠前ではなく、証拠です。 自社システムへの意味 短い出力の信号は弱いままです。言い換え、要約、翻訳、二段目のモデル通過といった重い後処理は信号を削ります。そして画像パイプラインは C2PA メタデータを意図せず破壊し得ます。本番環境で来歴が失われる最も一般的な経路がこれです。 関連記事 AI 電子透かしの実際のコスト この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # AI の透かしを消しているのは自社の CDN です · FinOps LLM URL: https://finopsllm.com/ja/research/how-ai-watermarks-get-destroyed AI 電子透かしが壊れる仕組み 更新日 September 1, 2026 · 初回公開 September 1, 2026 要約: AI 電子透かしについて本当に問うべきは、どう回避するかではありません。誰も何かを削除するつもりがなかったのに、なぜこれほど多くの本番コンテンツが来歴を失ったままパイプラインの末端に到達するのか、です。来歴は攻撃されるのではなく、最適化によって消えます。しかも、それを消す各システムは、まさに設計どおりの仕事をしています。仕組みが 2 つある以上、故障の形も 2... AI 電子透かしについて本当に問うべきは、どう回避するかではありません。誰も何かを削除するつもりがなかったのに、なぜこれほど多くの本番コンテンツが来歴を失ったままパイプラインの末端に到達するのか、です。来歴は攻撃されるのではなく、最適化によって消えます。しかも、それを消す各システムは、まさに設計どおりの仕事をしています。 仕組みが 2 つある以上、故障の形も 2 つあります。画像の来歴は削除で死に、テキストの来歴は希釈で死にます。どちらも無音です。 削除：パイプラインが捨てているメタデータ C2PA メタデータはファイルの中にあります。サムネイル生成、CDN の画像変換、WebP や AVIF への変換、第三者プラットフォームへのアップロード、スクリーンショット — いずれも明示的な設定がなければメタデータを捨てます。法則は一貫しています。画像を再エンコードするものは新しいファイルを作り、新しいファイルには署名済みマニフェストがありません。生成から配信までの間に自動変換が 1 つあれば十分です。 希釈：信号を削るテキスト処理 テキストの透かしは統計的なので、一度に消えるのではなく弱まります。翻訳は全トークンを別言語で再生成します。言い換えや「自社トーンへの書き換え」は劣化させます。要約は信号を担うトークンの大半を捨てます。二段目のモデルを通せば、帰属先はよくても最後のモデルです。そして 2 文の出力は、そもそも大した信号を持っていません。 注目すべきは、よくできた製品ほどこれらを複数行っている点です。あるモデルで生成し、別のモデルでトーンを整え、5 言語に翻訳し、要約カードに切り詰める — どれも間違いではありません。それでも、どの検出器も自信を持って帰属できない出力ができあがります。 安く済ませる方法 今日、実際の本番経路で画像 1 枚と長文 1 本を生成し、末端で何が残るかを確認してください。半日の作業で、監査より先に鎖を切っている工程を特定できます。 関連記事 AI 電子透かしの仕組み この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # GPT-5はいくらかかる？完全な2026年価格ガイド · FinOps LLM URL: https://finopsllm.com/ja/research/how-much-does-gpt5-cost GPT-5はいくらかかる？ 更新日：2026年7月15日 · 最初の公開日：2026年7月4日 GPT-5はOpenAIの2026年リリースのフラッグシップ推論モデルです。複雑な推論、コーディング、マルチモーダルタスクにおいてGPT-5はGPT-4oを大幅に上回る性能を提供しますが - プレミアム価格が設定されています。このガイドでは、API価格、ChatGPTサブスクリプションティア、GPT-4oとの比較、そして MiMO のような安価な代替手段が賢明な選択となる場面について、すべてのコスト要因を解説します。 GPT-5 API価格 OpenAIはGPT-5を100万トークンあたりで課金し、入力、出力、キャッシュ入力で異なる料金を設定しています。キャッシュ読み取りは、モデルが以前に計算されたプレフィックスを再利用するため、大幅に安価です。 ティア 入力 $/1M 出力 $/1M キャッシュ読取 $/1M コンテキストウィンドウ GPT-5.6-Sol (最大) $5.00 $30.00 $0.50 128Kトークン GPT-5.6-Terra (中程度) $2.50 $15.00 $0.25 128Kトークン GPT-5.6-Luna (予算重視) $1.00 $6.00 $0.10 128Kトークン GPT-5.5 (フラッグシップ) $5.00 $30.00 $0.50 128Kトークン GPT-5.4 (中堅) $2.50 $15.00 $0.25 128Kトークン OpenAIの新しい2026年7月世代（GPT-5.6）は、3つの異なるティアを導入します：フロンティア推論用のSol、バランスの取れたパフォーマンス用のTerra、コスト意識的なユースケース用のLunaです。比較として、古いGPT-5.5および5.4モデルは引き続き利用可能です。GPT-5.6および5.5は$5/$30で、GPT-4o（$2.50/$10）よりも大幅に高い機能を備えていますが、実効コストは推論の深さとキャッシュの効率に依存します。 ChatGPTサブスクリプションコスト APIではなくChatGPTインターフェースを通じてGPT-5を使用する場合、価格はサブスクリプションベースです： プラン 月額 GPT-5アクセス 主な制限 Free $0 GPT-5 miniのみ 1日のメッセージ数制限あり Plus $20/月 GPT-5（上限あり） ~80メッセージ/3時間 Pro $200/月 GPT-5無制限 レート制限なし、音声、ディープリサーチ Team $25/ユーザー/月 GPT-5（上限緩和） 管理ツール、SSO、上限緩和 Enterprise カスタム GPT-5無制限 SLA、専任サポート、データガバナンス 月額$200のProプランは、ヘビーユーザーでない限りコスト効率が高くありません。ほとんどの開発者やチームにとって、慎重なトークン管理を行ったAPIの方がProサブスクリプションより安価です。 GPT-5 vs GPT-4o：アップグレードが合理的なタイミング 価格差は現実的です。そのため、GPT-5の品質優位が他のコスト削減に繋がるかどうかが重要な質問です： GPT-5を使用すべき場面： タスクが複数ステップの推論、複雑なコード生成、長文書分析、または単一の高品質パスが複数のリトライサイクルを節約するエージェント型ワークフローを必要とする場合。 GPT-4oを使用すべき場面： タスクが単純な場合 - 分類、抽出、短文の要約、シンプルなチャット、またはスループットがリクエストあたりの知性より重要な大量バッチ処理。 GPT-5 miniまたはnanoを使用すべき場面： GPT-5レベルの指示追従が必要だがコストを抑えたい場合、やや推論深度が低下しても許容できる場合。 実践的なルール：GPT-4oのプロンプトに思考連鎖の指示やマルチターンの修正ループが含まれている場合、GPT-5はその推論をネイティブに単一の呼び出しで行うため、実際には安くなる可能性があります。 GPT-5コストの削減方法 複数の戦略により、出力品質を犠牲にすることなくGPT-5の請求書を30〜70%削減できます： プロンプトキャッシュを活用。 GPT-5のキャッシュ読取料金（$2.50/1M）は入力料金の75%安価です。安定したプレフィックス（システム指示、コンテキスト）と可変サフィックス（ユーザークエリ）でプロンプトを構成し、キャッシュヒットを最大化しましょう。 ルーティングにGPT-5 mini/nanoを使用。 まず軽量モデルで意図を分類し、複雑なクエリにのみフルのGPT-5にエスカレートします。これが モデルルーティング パターンです。 非対話型作業にバッチAPI。 OpenAIのバッチAPIは非同期ワークロードで50%の割引を提供 - 評価、エンリッチメント、レポート生成に最適です。 コンテキストウィンドウを適正サイズに。 5Kで十分な場合に100Kトークンのコンテキストを送信しないでください。不要な入力トークンはGPT-5ではGPT-4oの4倍のコストがかかります。 代替手段を検討。 多くのコーディングや推論タスクでは、 MiMO 、DeepSeek R1、Claude Sonnetなどのモデルが品質と同等のものをコストの一部で提供します。 プロバイダー裁定取引 でベンチマークを取りましょう。 定価以外の隠れたコスト トークンあたりの料金は全体の一部に過ぎません。これらの追加要因を予算に計上しましょう： 推論トークン。 GPT-5は複雑なタスクに内部推論トークンを使用します。これらは出力料金（$30/1M）で課金され、難しい問題では実質的な出力ボリュームを2〜5倍に増加させる可能性があります。 リトライコスト。 プロンプトが曖昧であったりパースが脆い場合、失敗した試行でもトークンを消費します。堅牢なプロンプトエンジニアリングは自己投資となります。 評価コスト。 開発中のテストとベンチマーキングは、別途追跡しない限り本番コストを簡単に超える可能性があります。 評価コスト配分 を参照してください。 結論 GPT-5は高価ですが一律ではありません。100万トークンあたり$10/$30で、入力1,000トークンと出力500トークンの典型的なAPI呼び出しは約$0.025です。大量のアプリケーションでは請求書が急速に増加しますが - スマートなキャッシュ、ルーティング、バッチ処理によりコストを半分以下に削減できます。すべてのリクエストを追跡し、機能にコストを配分し、定期的に代替手段をベンチマークしましょう。 関連記事 LLMプロバイダーはどのように課金するのか？ - 数字の裏にある価格モデル。 モデルルーティング - 正しいリクエストを正しいモデルに送る。 プロバイダー裁定取引 - 品質基準を満たす最安のモデルを見つける。 プロンプトキャッシュの説明 - 実際にキャッシュヒットを得る方法。 これを自分のLLM支出に適用しませんか？FinOps LLMはAIコストの無料監査を実行し、節約の場所を示します。 無料監査を予約 → リサーチに戻る --- # 30分でLLM支出を監査する方法 · FinOps LLM URL: https://finopsllm.com/ja/research/how-to-audit-llm-spend 30分でLLM支出を監査する方法 ほとんどのチームはLLM予算の内訳を把握していません。コストは、属性付けではなく合計を表示するプロバイダーのダッシュボード、異なる料金で請求されるトークンタイプ、週ごとに変化する使用パターンの裏に隠れています。このガイドでは、既にお手元のツールを使って30分で実行できる構造化された監査を提供します。 ステップ1 - プロバイダーから請求データを収集する 使用しているすべてのLLMプロバイダーから過去30日間の使用データをエクスポートします。OpenAIの場合は、Usage APIを使用するかダッシュボードからCSVをダウンロードします。Anthropicの場合は、Billing APIからデータを取得します。Googleの場合は、Cloud Billingコンソールからエクスポートします。セルフホストモデルの場合は、推論サーバーからリクエストログを取得します。すべてを1つのフォルダに保存します。要約ではなく生データが必要です。 ステップ2 - プロバイダー間でトークン数を正規化する 各プロバイダーはトークンを異なる方法でカウントします。OpenAIとAnthropicは独自のトークナイザーを使用し、GoogleはSentencePieceを使用します。比較するには、すべてのカウントを共通の単位に変換します。最も簡単なアプローチは、各プロバイダーが公開しているトークン単価を使用してリクエストあたりのコストを計算し、生のトークン数ではなくコストを直接比較することです。これによりトークナイザーの不一致を完全に回避できます。 ステップ3 - 入力、出力、キャッシュ、推論トークンに分割する プロバイダーはトークンタイプによって異なる料金を請求します。キャッシュされた入力トークンは、OpenAIとAnthropicで通常50%安くなります。推論トークン（oシリーズや同様のモデルでは）は標準出力トークンの2〜4倍のコストになることがあります。支出を入力、出力、キャッシュ入力、推論の4つのバケットに分割します。プロバイダーがこの分割を公開していない場合は、モデルタイプとリクエストパターンから推定します。 ステップ4 - チームと機能に属性付ける 各APIキーまたはプロジェクトを、それを所有するチームまたは機能にマッピングします。キーレベルの分離がない場合は、リクエストメタデータ（ヘッダー、タグ、またはほとんどのプロバイダーがサポートする user パラメーター）を使用します。目標は、どのチームがどの機能にいくら支出しているかというテーブルを作成することです。これなしでは、コストの責任を誰にも負わせることができません。 ステップ5 - トップ3のコストドライバーを特定する 総支出の降順でソートします。ほとんどの組織では、LLMコストの80%は3〜5の使用パターンから来ます。一般的なドライバー：長いコンテキストウィンドウを持つチャットボット、すべてのリクエストに高価なモデルを使用するコード生成機能、フィルタリングなしですべてのドキュメントで実行されるバックグラウンドエンリッチメントジョブ。名前をつけます。ここが最適化の集中ポイントです。 ステップ6 - 主要なワークフローのタスクあたりコストを計算する 上位3つのワークフローを選択します。各について、総支出を完了したタスク数で割ります。これにより、経時的に追跡できるユニットエコノミクスの数値が得られます。チケットあたり$0.12のカスタマーサポートワークフローは管理可能です。チケットあたり$1.40のワークフローは注意が必要です。絶対値よりもトレンドとワークフロー間の比較の方が重要です。 ステップ7 - 異常のアラートを設定する 2つのレベルでアラートを設定します：1日の総支出（暴走ジョブを検出）とワークフローごとの支出（ドリフトを検出）。ほとんどのプロバイダーは請求アラートをネイティブにサポートしています。プロバイダー横断のアラートについては、使用データをダッシュボードにパイプするか、 MiMO のようなプロバイダーを集約するツールを使用します。シンプルなルール：いずれかの日の支出が過去7日間の平均の150%を超えた場合にアラートを出します。 クイック監査チェックリスト ステップ 必要なツール 推定時間 成果物 1. 請求データの収集 プロバイダーのダッシュボードまたはAPI 5分 プロバイダーごとの生CSV/JSON 2. トークンの正規化 スプレッドシートまたはスクリプト 5分 リクエストあたりコストテーブル 3. トークンタイプの分割 トークン内訳のあるプロバイダーAPI 5分 入力/出力/キャッシュ/推論の分割 4. チームへの属性付け APIキーマッピングまたはメタデータ 5分 チーム対機能コストマトリクス 5. 主要ドライバーの特定 ソート/スプレッドシート 3分 コストパターンのランク付きリスト 6. タスクあたりコスト アプリログからのタスク数 5分 ワークフローごとのユニットエコノミクス 7. アラートの設定 プロバイダー請求アラート + ダッシュボード 2分 異常検知が有効 次のステップ この監査はスナップショットを提供します。本当の価値は定期的な実行から来ます - 高支出チームは週次、その他は月次。データ収集を自動化し、タスクあたりコスト指標をファーストクラスの製品指標にします。これを継続的なプロセスとして構築する助けが必要な場合は、 MiMO がプロバイダー横断ダッシュボードと自動属性付けをすぐに提供します。 関連項目 LLM費用配分 - 属性付けパターンの詳細。 LLM費用異常検知 - 自動アラート戦略。 AI支出の予算化方法 - 監査から予算へ。 これをご自身のLLM支出に適用しませんか？FinOps LLMはAIコストの無料監査を実行し、削減のポイントを示します。 無料監査を予約 → リサーチに戻る --- # LLM API価格トラッカー · FinOps LLM URL: https://finopsllm.com/ja/research/llm-api-pricing-tracker LLM API価格トラッカー 更新 2026年9月2日 · 初回公開 2026年7月4日 主要なLLMプロバイダー全体のトークン単価を追跡。入力、出力、キャッシュ読み書き、コンテキストウィンドウ、バッチ割引を一つの正規化テーブルで。検証可能なプロバイダーデータで毎月更新。 12+ 追跡プロバイダー 25+ 掲載モデル 6 価格列 2026年9月 最終更新 全価格はUSD/100万トークン 推定値は グレー で表示 キャッシュ価格はプロンプトキャッシュ対応箇所を反映 方法論 収集 プロバイダーの公式価格ページおよびAPIドキュメントから価格データを収集。 正規化 全価格をUSD/100万トークンに正規化して直接比較可能に。 キャッシュ価格 キャッシュ読み書き列は、プロバイダーがサポートするプロンプトキャッシュの割引を表示。 表示ポリシー 公式値と推定値は明確に分離。推定値はグレーでマーク。 更新履歴 2026年7月4日 LLM API価格トラッカー公開 12以上の主要LLMプロバイダーにわたるトークン単価比較をFinOps LLMのリサーチ記事として公開。 トークン単価テーブル プロバイダー ↕ モデル ↕ 入力 $/1M ↕ 出力 $/1M ↕ キャッシュ読取 $/1M ↕ キャッシュ書込 $/1M ↕ コンテキストウィンドウ ↕ バッチ割引 OpenAI GPT-5.6-Sol $4.00 $20.00 $0.40 $5.00 1.05M 50% OpenAI GPT-5.6-Terra $2.00 $12.00 $0.20 $2.50 1.05M 50% OpenAI GPT-5.6-Luna $0.20 $1.20 $0.02 $0.25 1.05M 50% Anthropic Claude Fable 5.1 $10.00 $50.00 $0.25 $12.50 1M 50% Anthropic Claude Fable 5 $10.00 $50.00 $1.00 $12.50 1M 50% Anthropic Claude Opus 5 $5.00 $25.00 $0.50 $6.25 1M 50% Anthropic Claude Sonnet 5 * $2.00 $10.00 $0.20 $2.50 1M 50% Anthropic Claude Sonnet 4.6 $3.00 $15.00 $0.30 $3.75 1M 50% Anthropic Claude Haiku 4.5 $1.00 $5.00 $0.10 $1.25 200K 50% Google Gemini 3.5 Flash $1.50 $9.00 $0.15 $1.88 1M 50% Google Gemini 3.1 Pro Preview $2.00 $12.00 $0.20 $2.50 1M 50% Google Gemini 2.5 Pro $1.25 $5.00 $0.31 $4.50 1M 50% Google Gemini 2.5 Flash $0.15 $0.60 $0.04 $0.15 1M 50% xAI Grok 4.5 $2.00 $6.00 $0.50 $1.50 1M 50% xAI Grok 4.3 $1.25 $2.50 - - 1M 50% Meta Llama 4 Maverick (DeepInfra) $0.20 $0.80 - - 1M - Meta Llama 4 Scout (Groq) $0.11 $0.34 - - 5M - Meta Llama 3.3 70B (Groq) $0.59 $0.79 - - 8M - Mistral Mistral Large 2/3 $2.00 $6.00 - - 128K - Mistral Mistral Medium 3.5 $1.50 $7.50 - - 128K - Mistral Mistral Small 3 $0.10 $0.30 - - 128K - Mistral Codestral $0.30 $0.90 - - 128K - DeepSeek DeepSeek V4 Flash $0.14 $0.28 $0.0028 - 128K - DeepSeek DeepSeek V4 Pro $0.435 $0.87 $0.0036 - 128K - Alibaba Qwen Qwen 3.7-Max $2.50 $7.50 - - 131K - Moonshot Kimi Kimi K2.6 $0.95 $4.00 $0.16 - 200K - Xiaomi MiMO 登録 - お互いに$2取得 ↗ MiMo-V2-Pro $0.50 $2.00 - - 128K - Xiaomi MiMO 登録 - お互いに$2取得 ↗ MiMo-V2-Omni $0.40 $1.60 - - 128K - Zhipu AI GLM-5 $1.00 $4.00 - - 128K - Zhipu AI GLM-5-Turbo $0.30 $1.20 - - 128K - MiniMax M2.7 $0.40 $1.60 - - 128K - StepFun step-3.5-flash $0.30 $1.20 - - 128K - * Claude Sonnet 5 は恒久的に100万トークンあたり$2/$10です。2026年9月1日に予定されていた$3/$15への値上げは撤回されました。キャッシュ書き込みの数値は5分TTLのものです。1時間TTLは基本入力レートの2倍です。Claude Opus 4.8、4.7、4.6 は Claude Opus 5 と同一価格です。Claude 4.7 以降は同じ文章でトークン数が約30%増えるトークナイザーを使うため、トークン単価ではなくタスク単価で比較してください。 プロバイダーが明示的に提供していない値は グレー で表示されています。 Meta Llamaの価格はホストAPI価格（Fireworks、Togetherなど）を反映しており、セルフホストコストではありません。セルフホストの経済性については オープンソース vs クローズドソースコスト比較 をご覧ください。 コンテキストウィンドウは最大対応値です。実際の可用性はティアにより異なる場合があります。 キャッシュ読み書き価格は、プロバイダーがサポートするプロンプトキャッシュ固有の割引を反映しています。"-"はプロバイダーがキャッシュを提供していないか、価格が公開されていないことを意味します。 バッチ割引は、バッチ/非同期API使用時の概算節約額を示しています。 一部のリンクには紹介コードが含まれる場合があります。 価格は頻繁に変更される可能性があります。最新情報はプロバイダーの公式ページでご確認ください。 実践ガイド コスト計画にこの価格データを活用する方法 1) まずトークン量を見積もる 価格を比較する前に、月間の入力・出力トークン量を見積もりましょう。出力トークンは入力より3〜5倍高価なため、出力長を削減することがコストに最も大きな影響を与えます。 2) キャッシュ節約を考慮する ワークロードに繰り返しのシステムプロンプトやコンテキスト（RAG、マルチターン会話）がある場合、プロンプトキャッシュにより入力コストを50〜90%削減できます。適用可能な割引についてはキャッシュ読取列をご確認ください。 3) 非緊急作業にはバッチAPIを使用 主要プロバイダーの多くはバッチ/非同步APIコールで50%の割引を提供しています。ワークロードがレイテンシーを許容する場合（評価、データ処理、コンテンツ生成）、バッチ価格でコストを半減できます。 4) トークン単価だけでなく総コストで比較 品質を同等にするのに3倍多くのトークンが必要な安価なモデルは、全体としてより高コストになる可能性があります。モデル品質とタスク固有のパフォーマンスを価格とあわせて考慮しましょう。 ご自身のLLM支出にこれを適用しませんか？FinOps LLMはAIコストの無料監査を実施し、節約のポイントを示します。 無料監査を予約 → リサーチに戻る --- # LLM の請求書には為替リスクがある · FinOps LLM URL: https://finopsllm.com/ja/research/llm-bill-fx-exposure LLM 支出の為替エクスポージャー 更新日 September 1, 2026 · 初回公開 September 1, 2026 要約: フロンティアモデルのほぼすべてが米ドル建てで値付けされています。予算がドル建てでないなら、LLM コストの一部は、自分で選んだ覚えのない為替ポジションです。USD/JPY が 6% 動けば、トークン量もモデルも変えていないのにコストは 6%... フロンティアモデルのほぼすべてが米ドル建てで値付けされています。予算がドル建てでないなら、LLM コストの一部は、自分で選んだ覚えのない為替ポジションです。 USD/JPY が 6% 動けば、トークン量もモデルも変えていないのにコストは 6% 増えます。しかも利用ダッシュボードにはそれを説明するものが何もありません。財務は差異を見ますが、トークンを見ているエンジニアリングは平坦な月しか見えず、手の打ちようがありません。 なぜ見つけにくいのか API 呼び出しから総勘定元帳までに換算が三層あります。プロバイダーのドル価格、カードや請求書のレートとスプレッド、そして会計システムが計上するレート。差異レポートに届くころには、為替分と利用分は同じ一つの数字です。 現地通貨のマーケットプレイス経由で買ってもリスクは消えません。換算が上流に移り、そこにマージンが乗るだけです。 2 つの差異を分ける テレメトリでは各リクエストのコストを 定価のドル建て で主指標として記録し、レポート時に明示したレートで一度だけ換算します。これで月次差異は、エンジニアリングが動かせる利用差異と、財務部門が持つ為替差異にきれいに分かれます。 ヘッジすべきか ほとんどの場合、必要なのはヘッジではなく可視性です。 関連記事 AI 支出の差異ブリッジ この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # LLMチャージバックとショーバック · FinOps LLM URL: https://finopsllm.com/ja/research/llm-chargeback-showback LLMチャージバックとショーバック ショーバック（費用の可視性）は、LLM支出をそれを引き起こしたチームと製品に報告します。チャージバック（費用配分）は、その支出を彼らの予算に割り当てます。ほとんどの組織はショーバックで開始する必要があります。チームが、その数字が予算決定に影響する前に、数字を信頼するのに時間がかかるからです。 課題は配分の精度です。単純なプロバイダー請求書は、どの機能、テナント、またはチームがトークンを生成したかを教えることができません。ゲートウェイ、アプリケーション、またはオーケストレーションレイヤーからのリクエストメタデータが必要です。そのメタデータがなければ、チャージバックは運用システムではなく政治的な議論になります。 良いショーバックレポート 製品エリアとチーム所有者別に支出を分類します。 主要なワークロードと月ごとの変化を示します。 モデル価格の変更をトラフィック成長から分離します。 各チーム所有の最適化候補を特定します。 割り当てられていない支出を表示したままにします。 チャージバックをいつ行うか チャージバックは、配分カバレッジが高く、チームが費用要因に影響を与えることができたら意味があります。ラベルなしの共有インフラストラクチャ、古い価格表、または変更できない中央プラットフォーム決定のためにチームにチャージしないでください。 堅牢なモデルは教育のためにショーバックを使用し、その後成熟したコストセンターのためにチャージバックを使用します。また、チームが初期トラフィックが予測しにくいだけという理由で有用なAI機能を回避しないように、実験予算も保護します。 関連 LLM予算ガバナンス - 予算とガードレール。 LLM費用配分 - 配分の基本。 LLM FinOpsとは？ - 完全な運用規律。 自分のLLM支出に適用したいですか？FinOps LLMはAI費用の無料監査を実施し、節約場所を示します。 無料監査を予約 → リサーチに戻る --- # LLM費用配分 · FinOps LLM URL: https://finopsllm.com/ja/research/llm-cost-attribution LLM費用配分 LLM費用配分は、プロバイダー請求書と運用上の決定の間の橋です。プロバイダーはアカウント、モデル、トークンクラス、および時々地域または機能で請求します。企業は、チーム、製品、顧客、ワークフロー、および値のユニット別の支出を理解する必要があります。配分レイヤーは、生の請求書との照合を失わずに、これら2つのビューを接続します。 重要なのは、リクエストがプロバイダーまたはゲートウェイに到達する前にラベルを付けることです。事後的に作成されたレコードは、通常は不完全です。最低限として、本番環境のすべてのLLM呼び出しは、安定したエンドポイント名、環境、チーム所有者、製品表面、ワークロードクラス、および相関IDを運ぶ必要があります。契約が許可する場所では、テナントまたは顧客IDを追加します。エージェントワークフローの場合、各ツール呼び出しまたはモデルステップを個別にラベル付けします。 リクエスト数は配分ではない リクエスト数による支出の割り当てはほぼ常に間違っています。長いコンテキスト推論リクエストは、数百の短い分類呼び出しよりも費用がかかる可能性があります。配分はトークンクラスとモデル価格が必要です。また、リトライとフォールバックのデータが必要です。「成功した」応答は、以前の3つの失敗した呼び出しを隠す可能性があるからです。 推奨される寸法 プロバイダー、モデル、およびモデルバージョン（利用可能な場合）。 入力、出力、キャッシュ書き込み、キャッシュ読み取り、および推論のトークンクラス。 チーム、製品、機能、エンドポイント、および環境。 ワークロードクラス：リアルタイムユーザーパス、バックグラウンド作業、評価、エンリッチメント、エージェントステップ、サポートワークフロー、または分析タスク。 プライバシーと契約境界が許可する場合の顧客またはテナント配分。 請求書の照合 配分はプロバイダー請求書と照合されて戻る必要があります。丸め、遅延請求行、およびプロバイダー固有の割引による小さな違いを期待しますが、大きなギャップは、レコードパイプラインがトラフィックを失っているか、古い価格表を使用していることを意味します。ファイナンスビューは、配分された支出と未割り当ての支出の両方を表示して、データ品質の問題が見えるようにする必要があります。 ショーバックからアクションへ 最初の結果はショーバックである必要があります：どのチームと製品表面が支出を駆動しているか、および先月からどのワークロードが変更されたか。チームがそのデータを信頼したら、それを使用して最適化作業をランク付けします。配分は、ルーティング、キャッシュ、またはプロンプト変更を承認できる所有者に直接指摘するため、価値があります。 関連 OpenAI費用配分 - OpenAI固有の配分パターン。 LLMチャージバックとショーバック - 支出を所有者に移動。 LLM FinOpsとは？ - 完全な運用規律。 自分のLLM支出に適用したいですか？FinOps LLMはAI費用の無料監査を実施し、節約場所を示します。 無料監査を予約 → リサーチに戻る --- # LLMコスト計算機 - 月間AI支出を見積もり · FinOps LLM URL: https://finopsllm.com/ja/research/llm-cost-calculator LLMコスト計算機 更新日：2026年7月15日 人気モデルの月間LLM支出を見積もりましょう。以下に使用パターンを入力すると、コストが並べて比較できます。すべての価格は2026年7月時点の100万トークンあたりの料金です。 使用ティア別事前計算コスト 人気モデルの各使用ティアにおける月間コストを、典型的なリクエストパターンに基づいて示します： モデル 軽度（1Kリクエスト/月） 中度（10Kリクエスト/月） 重度（100Kリクエスト/月） GPT-5.6-Sol $8.75 $87.50 $875.00 GPT-5.6-Terra $4.38 $43.75 $437.50 GPT-5.6-Luna $1.75 $17.50 $175.00 Claude Fable 5 $17.50 $175.00 $1,750.00 Claude Opus 4.8 $8.75 $87.50 $875.00 Claude Sonnet 5 $3.50 $35.00 $350.00 Claude Haiku 4.5 $1.75 $17.50 $175.00 Gemini 3.5 Flash $2.63 $26.25 $262.50 Grok 4.5 $4.00 $40.00 $400.00 DeepSeek V4 Pro $0.95 $9.50 $95.00 Kimi K2.6 $1.70 $17.00 $170.00 軽度： 1Kリクエスト/月、入力500 + 出力200トークン。 中度： 10Kリクエスト/月、入力1,000 + 出力500トークン。 重度： 100Kリクエスト/月、入力2,000 + 出力1,000トークン。 インタラクティブ計算機 モデル GPT-5.6-Sol ($5.00 / $30.00) GPT-5.6-Terra ($2.50 / $15.00) GPT-5.6-Luna ($1.00 / $6.00) Claude Fable 5 ($10.00 / $50.00) Claude Opus 4.8 ($5.00 / $25.00) Claude Sonnet 5 ($2.00 / $10.00) Claude Haiku 4.5 ($1.00 / $5.00) Gemini 3.5 Flash ($1.50 / $9.00) Grok 4.5 ($2.00 / $6.00) DeepSeek V4 Pro ($0.435 / $0.87) Kimi K2.6 ($0.95 / $4.00) 月間リクエスト数 リクエストあたりの平均入力トークン数 リクエストあたりの平均出力トークン数 コストを計算 この計算機の使い方 モデルを選ぶ - ドロップダウンから選択。価格は2026年7月時点の標準APIレートを反映しています。 リクエスト量を入力 - 月間のAPI呼び出し回数。 トークン数を見積もる - リクエストあたりの平均入力・出力トークン数。不明な場合は、チャットなら入力1,000/出力500、コード生成なら入力3,000/出力1,000から始めましょう。 計算をクリック - 入力と出力に分けた推定月間コストが表示されます。 推定コストを削減する方法 プロンプトキャッシュを使う。 プロンプトに安定したプレフィックスがある場合、キャッシュされた読み取りで入力コストを50～90%削減できます。 プロンプトキャッシュの解説 をご覧ください。 タスク別にモデルを切り替える。 簡単なクエリには安価なモデルをルーティングし、複雑なタスクには高価なモデルを確保します。これが モデルルーティング です。 バッチAPIを使う。 緊急でないワークロードはバッチ価格で50%オフにできます。 より安価なプロバイダーを試す。 MiMO やDeepSeekは、多くのタスクで同等の品質を大幅に低い料金で提供しています。 関連 GPT-5はいくらかかる？ - GPT-5の詳細価格分析。 LLMプロバイダーはどのように課金する？ - トークンベースの課金の理解。 AIコード生成の最も安い方法 - コーディングツールのコスト比較。 プロバイダーアービトラージ - 品質基準を満たす最安モデルの発見。 自分のLLM支出に適用したいですか？FinOps LLMはAI費用の無料監査を実施し、節約場所を示します。 無料監査を予約 → リサーチに戻る --- # 本番LLMコスト急増のためのランブック · FinOps LLM URL: https://finopsllm.com/ja/research/llm-cost-spike-runbook 本番LLMコスト急増のためのランブック 更新日 August 27, 2026 · 初回公開 August 27, 2026 要約: コストが急増したら、まず証拠を保存し、請求の信号を確認し、量、料金、構成、効率に分解します。最初の15分請求、トラフィック、モデル構成、トークン種別、リトライ、最近のデプロイを保存し、請求とゲートウェイのテレメトリを比較します。安全に封じ込める暴走ワークフローの停止、エージェント上限、バッチへの振り分け、新機能の停止など最小の制御を使います。担当者、期限、ロールバック条件を記録します。原因と終了量... コストが急増したら、まず証拠を保存し、請求の信号を確認し、量、料金、構成、効率に分解します。 最初の15分 請求、トラフィック、モデル構成、トークン種別、リトライ、最近のデプロイを保存し、請求とゲートウェイのテレメトリを比較します。 安全に封じ込める 暴走ワークフローの停止、エージェント上限、バッチへの振り分け、新機能の停止など最小の制御を使います。担当者、期限、ロールバック条件を記録します。 原因と終了 量、モデル構成、コンテキスト、ツール、失敗、料金を確認し、成功タスク単価を基準と比較します。影響と恒久対策を記録します。 関連記事 LLMコスト監視 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # LLMコストトレンド 2025–2026 · FinOps LLM URL: https://finopsllm.com/ja/research/llm-cost-trends-2025-2026 LLMコストトレンド 2025–2026 更新日：2026年7月15日 · 初回公開日：2026年7月4日 LLM市場は同時に2つの方向に動いています。GPT-4クラスモデルの入力・出力トークン価格は2024年初頭から80～90%下落しました。一方、推論モデル（o1、o3、DeepSeek-R1、Claude Opus 4）は非推論同等モデルと比較してタスクあたり5～30倍高価です。純効果として、推論モデルを採用したチームは単価が下がっても請求額が増加します。 この記事では、2025年から2026年半ばまでの主要な価格・品質イベントを追跡し、コストを動かす要因を解説し、2026年後半の見通しを予測します。 主要トレンド1：GPT-4クラスモデルは18ヶ月で90%下落 2024年3月、GPT-4-turboは入力100万トークンあたり$10、出力100万トークンあたり$30でした。2026年半ばまでに、GPT-4.1は入力$2、出力$8に下がり、75～80%の下落となりました。Claudeも同様の軌跡をたどりました：Claude 3 Opusの$15/$75からClaude Sonnet 4の$3/$15へ。Mistral、Llama、DeepSeekのオープンウェイトモデルはさらに価格を押し下げ、ホストプロバイダー経由で入力100万トークンあたり$0.50以下で利用できるものもあります。 これは単なる価格競争ではありません。推論インフラが改善しました：量子化、投機的デコーディング、KVキャッシュ最適化、バッチングにより、トークン配信コストが削減されました。プロバイダーはこれらの節約の一部を顧客に還元しました。 主要トレンド2：推論モデルは5～30倍高価 推論モデル（o1、o3、o4-mini、DeepSeek-R1、拡張思考付きClaude Opus 4）は最終回答を生成する前に内部的な「思考」トークンを生成します。これらの思考トークンは出力トークンとして課金されます。推論モデルがコーディングタスクを解く際、2Kトークンの回答を生成する前に10K～50Kの思考トークンを生成することがあります。したがって、タスクあたりの実効コストはトークン単価が示唆するものよりはるかに高くなります。 あらゆるタスクに推論モデルを使用するチームにとって、これが2026年の最大のコストドライバーです。重要なのは「モデルはいくらか？」ではなく「このタスクに推論は必要か？」です。ほとんどのタスクには必要ありません。 主要トレンド3：オープンソースが品質ギャップを解消 2024年初頭、オープンウェイトモデルはコーディングや推論ベンチマークでプロプライエタリモデルに大きく遅れていました。2026年半ばまでに、Llama 4 Maverick、DeepSeek-V3、Qwen 3、MiMoなどのモデルはほとんどのベンチマークでGPT-4クラスの性能に数ポイント差まで迫っています。これがコストに重要なのは、オープンウェイトモデルの配信コストが低いためです。価格競争をするプロバイダーはそれらを使ってプロプライエタリ価格を下回ります。 フロンティア推論タスクについては品質ギャップは完全には解消されていません。ただし、生産ワークロードの大部分--要約、抽出、分類、コード生成、ツール使用--において、オープンウェイトモデルは十分に良く、大幅に安価です。 主要トレンド4：キャッシュが繰り返しワークロードの実効コストを50～90%削減 プロンプトキャッシュ（Anthropic）と自動コンテキストキャッシュ（OpenAI、Google）は、繰り返しワークロードの経済性を変革しました。同じシステムプロンプトとコンテキストをモデルに1日100回送る場合、キャッシュされた読み取りは非キャッシュ読み取りより50～90%安くなります。RAGパイプライン、エージェントシステム、バッチ処理にとって、これは変革的です。 キャッシュの利点は不均等に分配されます。安定したコンテキスト（同じシステムプロンプト、同じドキュメントセット）を持つワークロードは大きな恩恵を受けます。動的コンテキスト（ユーザー固有の会話、リアルタイムデータ）を持つワークロードは恩恵が少なくなります。FinOpsチームはキャッシュヒット率を測定し、コンテキストの安定性を最適化して節約を最大化すべきです。 主要トレンド5：エージェントワークフローがトークン消費を倍増 エージェントワークフロー--モデルがツールを呼び、ファイルを読み、コードを実行し、結果を反復する--は、単一ターンの対話と比較してタスクあたり5～50倍多くのトークンを消費します。バグを解決するコーディングエージェントは、ツール呼び出し、リトライ、コンテキスト蓄積全体で100K～500Kトークンを消費する可能性があります。同等の単一ターンプロンプトは2K～5Kトークンを使用するかもしれません。 これが2026年で最も重要なコストトレンドです。トークン価格は下落していますが、タスクあたりのトークン消費はより速く増加しています。純結果として、ほとんどのチームのLLM総支出は単価が下がっても増加し続けています。 タイムライン：主要イベント 日付 イベント 価格への影響 品質への影響 2024年3月 GPT-4-turboローンチ GPT-4より50%安い 同等の品質 2024年6月 Claude 3.5 Sonnetローンチ Opusより5倍安い Opusに近い品質 2024年9月 o1-previewローンチ タスクあたり3～5倍高い（推論） 大幅な推論向上 2024年12月 Google Gemini 2.0 Flash 入力100万トークンあたり$1未満 スピードタスクに強い 2025年1月 DeepSeek-R1オープンソース o1より10倍安い o1に近い推論 2025年2月 Claude 3.5 Sonnet値下げ さらに20%下落 同じ品質 2025年4月 GPT-4.1ローンチ GPT-4-turboより30%安い コーディング改善 2025年5月 Claude Sonnet 4ローンチ 同じ価格、より良い品質 大幅なコーディング向上 2025年6月 OpenAI o3-mini値下げ 推論が50%安い 同じ品質 2026年1月 DeepSeek-V3ホストプロバイダー 入力100万トークンあたり$0.50未満 GPT-4クラスに近い 2026年4月 Claude Opus 4ローンチ プレミアム価格（$15/$75） フロンティア推論 2026年6月 Llama 4 Maverickホスト 入力100万トークンあたり$0.30未満 高い汎用品質 2026年7月 Anthropic Fable 5 / OpenAI GPT-5.6層の立ち上げ 新しいフロンティア層（$5/$30）、中位層の価格設定（$2.50/$15）、予算層（$1/$6） Fable 5がOpus 4パフォーマンスを実現 2026年後半の見通し 推論モデルの価格は30～50%下落する。 オープンソース推論モデル（DeepSeek-R2、Qwen 3推論バリアント）からの競争が、プロプライエタリプロバイダーに推論ティアの値下げを強いるでしょう。 エージェント固有の価格設定が登場する。 プロバイダーは、ツール呼び出し、リトライ、コンテキストを単一の予測可能なコストにバンドルするタスク別・セッション別の価格モデルをテストしています。少なくとも1つの主要プロバイダーが2026年第4四半期までにこれを提供すると予想されます。 キャッシュが自動化される。 手動のキャッシュ管理は消滅します。プロバイダーはキャッシュ配置を透過的に最適化し、開発者の介入なしにほとんどのワークロードのキャッシュヒット率が改善します。 オープンウェイトモデルがルーチンワークを支配する。 2026年末までに、ルーチンタスク（分類、抽出、要約、簡単なコード生成）の生産推論の70%以上がホストプロバイダー経由のオープンウェイトモデルで実行されると予想されます。 総支出は上昇し続ける。 単価の下落にもかかわらず、エージェント駆動のワークフローとAIユースケースの拡大により、LLM総支出は成長し続けます。支出を管理するには、安価なモデルだけでなくFinOpsの規律が必要です。 関連 エージェント经济学 - コーディングエージェントの実際のコスト。 プロバイダーアービトラージ - プロバイダー切り替えによるコスト削減。 モデルルーティング - タスクを適切なモデルに送信。 LLM向けFinOps - より広いフレームワーク。 自分のLLM支出に適用したいですか？FinOps LLMはAI費用の無料監査を実施し、節約場所を示します。 無料監査を予約 → リサーチに戻る --- # MCPサーバーのコストインパクト · FinOps LLM URL: https://finopsllm.com/ja/research/mcp-server-cost-impact MCPサーバーのコストインパクト モデルコンテキストプロトコル（MCP）により、LLMはデータベース、API、ファイルシステム、検索エンジンなどの外部ツールを呼び出すことができます。これは強力です。しかし、高価でもあります。各MCPツール定義はコンテキストウィンドウのスペースを消費し、各ツールコールは別々のAPIラウンドトリップであり、各ツール結果は追加の入力トークンとしてモデルにフィードバックされます。MCPヘビーなエージェントワークフローを実行しているチームにとって、ツール関連のオーバーヘッドは総トークン支出の30–60%を占める可能性があります。 この記事では、MCPがコストをどのように押し上げるか、オーバーヘッドの測定方法、そして対対処法を説明します。 MCPがトークンを消費する仕組み すべてのMCPインタラクションには3つのトークンコストレイヤーがあります： レイヤー1：ツール定義。 各MCPサーバーはモデルにツールを登録します。ツール定義には関数名、パラメータスキーマ、ツールの機能の説明が含まれます。単一のツール定義は通常500–2,000トークンを消費します。15個のツールを持つサーバーは、それらのツールが呼び出されなくても、すべてのリクエストに7.5K–30Kトークンを追加します。 レイヤー2：ツールコールリクエスト。 モデルがツールを呼び出すことを決定すると、ツールコール出力（関数名+引数）を生成します。これは出力トークンとして課金されます。次にツール結果が入力トークンとして戻ります。単一のツールコールラウンドトリップは、結果のサイズに応じて通常1K–5Kトークンを消費します。 レイヤー3：コンテキスト内のツール結果。 ツール結果は後続のすべてのターンの会話コンテキストに残ります。セッションで10個のツールを呼び出すと、それらの結果が蓄積します。50行のJSONを返すデータベースクエリは、残りの会話中ずっと残る8K–15Kトークンを追加する可能性があります。 複合効果 MCPコストは複合します。ツール定義はすべてのリクエストで送信されるためです。20個のツールが定義されており（10K–40Kトークンの定義）、会話で5回のリクエストを行う場合、ツール定義だけで50K–200K入力トークンがかかります。ツールコールの結果を加えると、ベースラインのトークン消費量を簡単に倍増させることができます。 MCPパターン トークンオーバーヘッド 頻度 月間コストインパクト（推定） ツール定義（10ツール） リクエストあたり5K–20Kトークン すべてのリクエスト ユーザーあたり$15–$60 単一ツールコールラウンドトリップ 1K–5Kトークン セッションあたり3–10回 ユーザーあたり$5–$25 大きなツール結果（DBクエリ、コード検索） 5K–20Kトークン セッションあたり1–5回 ユーザーあたり$10–$50 長いセッションでの蓄積された結果 20K–100Kトークン 1日1–3セッション ユーザーあたり$30–$120 未使用のツール定義がロードされる リクエストあたり5K–30Kトークン すべてのリクエスト ユーザーあたり$15–$90 MCPオーバーヘッドの測定方法 MCPコストを測定する最も簡単な方法は、同じプロンプトを2回実行することです：1回はMCPツールをロードして、もう1回はロードせずに。入力トークンの差がツール定義のオーバーヘッドです。次にツールコールトークンを別々にカウントします。ほとんどのプロバイダーは請求ダッシュボードで明確にラベル付けしています。 より正確な測定のために、MCPクライアントに以下をログ記録するよう計装します：登録されたツール数、リクエストあたりのツール定義で消費されたトークン、セッションあたりのツールコール数、ツール結果あたりのトークン、ツール活動に起因する総セッショントークン。 MCPコストを削減する戦略 1. ツールを選択的にロードする。 すべてのリクエストですべてのツールを登録しないでください。ユーザーがコードの質問をしている場合、データベースやデプロイメントツールをロードする必要はありません。多くのMCPクライアントは、コンテキストまたは明示的なユーザー有効化に基づいた動的ツールロードをサポートしています。 2. ツールの説明を最小化する。 ツールの説明は定義内の最大のトークン消費です。冗長な説明は500トークンになる可能性があり、簡潔な説明は100トークンになる可能性があります。20個のツール全体で、リクエストあたり8Kトークンの差になります。 3. ツール結果を切り詰める。 モデルが実際に必要なフィールドのみを返します。データベースクエリが20列を返すがモデルが3列しか必要としない場合、結果をプロジェクションします。結果サイズを妥当な制限に設定します。2K–4Kトークンは通常、モデルが決定を下すのに十分です。 4. 繰り返し呼び出しをキャッシュする。 同じツールがセッション内で同じ引数で呼び出された場合、再度実行する代わりにキャッシュされた結果を返します。これは参照ルックアップ、スキーマクエリ、ドキュメント取得に特に価値があります。 5. 注入前に要約する。 大きなツール結果（ファイルの完全な内容、長いAPIレスポンス）については、コンテキストに追加する前に要約します。モデルが必要な場合に完全な結果を取得するオプション付きの要約を返します。 6. ツール結果の予算制限を使用する。 ツール結果トークンのセッションごとの予算を設定します。予算に達した場合、それ以上のツールコールを拒否するか、セッションの残りのためにより安いモデルに切り替えます。 MCPサーバーの隠れたコスト トークンコストを超えて、MCPサーバーはレイテンシと信頼性のオーバーヘッドを導入します。応答に3秒かかるツールコールは、すべてのターンにレイテンシを追加します。断続的に失敗するツールはリトライを引き起こします。どちらもタスクあたりの実効コストを増加させます。 組織全体でMCP使用をスケーリングしているチームにとって、サーバーレベルでこれらのコストを追跡することは不可欠です。MCPヘビーなワークロードをトークンあたりのコストが低いモデルにルーティングし、MCPライトなワークフローをレイテンシが重要なプレミアムモデルに保持します。 関連 エージェント经济学 - コーディングエージェントの実際の価格設定。 エージェント支出配分 - プロジェクトごとのエージェントコストの追跡。 LLMトークン追跡 - 支出の測定。 LLM向けFinOps - より広いフレームワーク。 自分のLLM支出に適用したいですか？FinOps LLMはAI費用の無料監査を実施し、節約場所を示します。 無料監査を予約 → リサーチに戻る --- # MCPツールの定義トークンコストを抑制する · FinOps LLM URL: https://finopsllm.com/ja/research/mcp-tool-definition-overhead エージェント運用におけるMCPツール定義のトークンコスト最適化 更新日 September 19, 2026 · 初回公開 September 19, 2026 要約: AIエージェントを複数のModel Context Protocol（MCP）サーバーに接続すると、ユーザーの指示を処理する前に、毎ターン数千トークンが消費されます。登録された各ツールは関数名、引数の説明、JSON... AIエージェントを複数のModel Context Protocol（MCP）サーバーに接続すると、ユーザーの指示を処理する前に、毎ターン数千トークンが消費されます。登録された各ツールは関数名、引数の説明、JSON Schemaの制約をプロンプトに挿入します。GitHub、Postgres、Slackなど複数のMCPサーバーを常時接続すると、ツール定義だけで1回あたり4,500〜12,000トークンを占有します。 なぜMCPツールの定義は大量のトークンを消費するのか？ モデルがツールを適切に呼び出すには、引数の型や説明を含む詳細なJSON Schemaが必要です。1つのツール定義だけで300〜600トークンに達し、数十のツールを接続すると静的なスキーマがコンテキストの大半を埋め尽くします。 エンジニアリングによる対策 実運用では、ツール定義ブロック直後にプロンプトキャッシュの境界（Breakpoint）を設定する手法、軽量ルーターで必要なツールのみを動的に選択して注入する2段階ルーティング、およびスキーマの圧縮・説明文の最小化が有効です。 関連記事 サーバーツールと個別請求 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # モデル価格改定だけでAI請求額は下がらない · FinOps LLM URL: https://finopsllm.com/ja/research/model-price-cuts-routing-budget モデル値下げとルーティングバジェット 更新日 September 10, 2026 · 初回公開 September 10, 2026 要約: API単価が下がっても、プロンプトの肥大化や旧モデルへの固定ルーティングによって総請求額が減少しないケースが多発します。タスク単価で再評価が必要です。 API単価が下がっても、プロンプトの肥大化や旧モデルへの固定ルーティングによって総請求額が減少しないケースが多発します。タスク単価で再評価が必要です。 関連記事 成功タスクあたりのコスト この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # 安全チェックは二枚目の請求書 · FinOps LLM URL: https://finopsllm.com/ja/research/moderation-pass-second-bill ガードレールとモデレーションの費用 更新日 September 1, 2026 · 初回公開 September 1, 2026 要約: 本番の LLM 機能が呼び出しを 1 回だけ行うことはまれです。設計した呼び出しに加えて、後から安全のために足した呼び出しがあります — 入力分類器、出力チェック、ポリシー判定、ときには 1 本目を採点する 2... 本番の LLM 機能が呼び出しを 1 回だけ行うことはまれです。設計した呼び出しに加えて、後から安全のために足した呼び出しがあります — 入力分類器、出力チェック、ポリシー判定、ときには 1 本目を採点する 2 本目のモデル。どれも推論であり、推論は課金されます。 倍率は見た目より大きい 入力モデレーションは入力全体を読み、出力モデレーションは生成された応答全体を読みます。判定モデルは その両方 に加えて検索コンテキストと評価基準まで読むため、判定される呼び出しより判定する呼び出しのほうが大きくなります。 支出が積み上がる場所 典型は 3 つ。 フロンティアモデルで判定する （分類こそ小型モデルで十分な唯一の用途で、たいていここが最大の削減余地）。 毎ターン検査する （承認済みの履歴を再走査）。そして 社内トラフィックへのガードレール （評価ハーネスや社内ツールが、必要のない対外向け安全スタックをそのまま継承）。 丸め誤差ではなく費目として チェックをやめる話ではありません。安全スタックが機能の推論コストの 30–50% を占めていながら、計画のどこにも出てこないことがある、という話です。答えるモデルは数えても、検査するモデルは誰も数えていないからです。 ガードレール呼び出しはテレメトリで別タグにして比率を可視化し、必要な精度を満たす最小のモデルを使い、履歴全体ではなく新規部分だけを検査し、どのトラフィックにどのチェックが本当に要るかを面ごとに決めてください。 関連記事 LLM コストの帰属 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # 開発環境も立派な本番ワークロード · FinOps LLM URL: https://finopsllm.com/ja/research/non-production-llm-spend 本番外の LLM 支出 更新日 September 1, 2026 · 初回公開 September 1, 2026 要約: LLM 支出のレビューはいつも本番トラフィックから始まります。ダッシュボードがあるのがそこだけだからです。ところが環境別に分解すると、請求額のうち無視できない割合 — しばしば二桁パーセント — が一度も顧客に届いていないと分かります。どこから来るのかCI: 評価スイートを走らせるプルリクエストごとにモデルを呼び、最も高価なモデルで 1 日に数千回になります。ローカル開発:... LLM 支出のレビューはいつも本番トラフィックから始まります。ダッシュボードがあるのがそこだけだからです。ところが環境別に分解すると、請求額のうち無視できない割合 — しばしば二桁パーセント — が一度も顧客に届いていないと分かります。 どこから来るのか CI: 評価スイートを走らせるプルリクエストごとにモデルを呼び、最も高価なモデルで 1 日に数千回になります。 ローカル開発: プロンプトの調整は 1 時間に数十回の呼び出しで、共有キー、タグなしが普通です。 ステージングとデモ: 本番と同じ構成、つまり高価なモデルでキャッシュなし。 テスト中のリトライや暴走ループ は誰も見ていません。 コストより先に帰属を直す 投資が確実に回収できる変更は 環境ごとに別の API キー を持つことです。半日で終わり、説明のつかない 1 行が 4 つのラベル付きの行になります。各リクエストに環境を、CI ではリポジトリとワークフローもタグ付けします。 見えるようになれば結論は自然に出ます。本番外はより小さいモデルでほぼ問題ありません。CI はほぼ同一のプロンプトを繰り返すので、キャッシュの効果が最も大きい場所です。そして厳格な上限を安全に置けるのもここだけです — 上限に達したテスト環境はビルドを落としますが、本番環境は顧客を落とします。 関連記事 LLM コストの帰属 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # AIオブザーバビリティは第2のLLM請求書になり得る · FinOps LLM URL: https://finopsllm.com/ja/research/observability-second-llm-bill AIオブザーバビリティと第2のLLM請求書 更新日 September 9, 2026 · 初回公開 September 9, 2026 要約: 品質監視のために本番出力をLLMで自動審査すると、監視対象以上のトークン費用が発生することがあります。サンプリングとバッチ処理で最適化を図ります。 品質監視のために本番出力をLLMで自動審査すると、監視対象以上のトークン費用が発生することがあります。サンプリングとバッチ処理で最適化を図ります。 関連記事 評価コストの制御 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # オープンソース vs. クローズド：LLMコスト比較 · FinOps LLM URL: https://finopsllm.com/ja/research/open-source-vs-closed-cost オープンソース vs. クローズド：LLMコスト比較 更新 2026年7月15日 · 初出 2026年7月4日 Llama、Qwen、DeepSeekをセルフホスティングするのは、APIアクセスに対して、いつ損益分岐点に達するのでしょうか。この分析はGPUコスト、推論最適化、運用オーバーヘッド、および特定のワークロードに対する意思決定フレームワークを提供します。 8 比較モデル 5 分析GPU層 3 損益分岐点シナリオ Jul 2026 最終更新 セルフホストコストはクラウドGPU価格を想定（オンデマンド） APIコストはプロバイダーごとの標準出力価格を使用 損益分岐点は70%利用率、24/7可用性に基づく 方法論 API価格 各プロバイダーの価格ページからの標準発表料金。ボリューム割引またはバッチ割引は適用されません。 クラウドGPUセルフホスト 推論最適化セットアップ用クラウドオンデマンド価格（Lambda、RunPod、AWS）vLLMまたはTensorRT-LLM搭載。 運用オーバーヘッド モニタリング、スケーリング、モデル更新、および管理インフラストラクチャ用の生GPUコストに対する15%運用サーチャージが含まれます。 品質ギャップ GPT-4o / Claude Sonnet 4相対の100%ベースラインで。公開ベンチマークと実際のタスクパフォーマンスに基づく。 コスト比較表 モデル ↕ APIコスト/月 ↕ セルフホストコスト（クラウドGPU） ↕ 損益分岐点ボリューム ↕ 品質ギャップ Llama 4 Maverick (DeepInfra) $260/月 $2,800/月 ~350Mトークン/月 ~95% of GPT-4o Llama 3.3 70B (Groq) $277/月 $1,200/月 ~210Mトークン/月 ~87% of GPT-4o Llama 4 Scout (Groq) $136/月 $1,400/月 ~350Mトークン/月 ~88% of GPT-4o Qwen 3.7-Max $525/月 $1,600/月 ~100Mトークン/月 ~92% of GPT-4o DeepSeek V4 Pro $435/月 $1,800/月 ~130Mトークン/月 ~96% of GPT-4o DeepSeek V4 Flash $140/月 $1,400/月 ~450Mトークン/月 ~82% of GPT-4o Mistral Medium 3.5 $525/月 $2,000/月 ~120Mトークン/月 ~91% of GPT-4o GPT-4o (APIのみ) $750/月 N/A N/A ベースライン（100%） APIコスト/月は標準料金で月間100M出力トークン+300M入力トークンを想定します。 セルフホストコストにはGPUレンタル、15%運用オーバーヘッド、推論スタック（vLLM）が含まれます。初期セットアップエンジニアリング時間は含まれません。 損益分岐点ボリュームは、セルフホスティングがAPIより安くなる月間出力トークン数です。 品質ギャップは概算であり、タスク依存です。MMLU、HumanEval、GPQA等のベンチマークがこれらの推定値を通知します。 一部のリンクには紹介コードが含まれている場合があります。 主要なコスト要因 1) GPUレンタルが支配的なコスト Llama 4 Maverick用8x H100ノードはLambda、RunPod、またはAWSからのオンデマンドで月2,000～3,500ドルです。スポット/先制可能インスタンスはこれを40-60%削減できますが、再起動レイテンシーと可用性リスクが追加されます。本番ワークロードについて、予約インスタンス（1年契約）は通常オンデマンドより30-40%節約できます。 2) 推論最適化が方程式を変える 連続バッチング、KVキャッシュページング、および量子化（GPTQ/AWQ 4ビット）によるvLLMは、同じハードウェアで2-4倍のスループットを増加させることができます。TensorRT-LLMはサポートされているアーキテクチャに対してさらに20-40%を追加します。単一A100上の4ビット量子化Llama 4 Scoutは、2x A100上のナイーブfp16セットアップと同等になることができます。 3) 運用オーバーヘッドは実質的ですが減少しています 推論インフラストラクチャの実行にはGPUモニタリング、モデル更新、負荷分散、およびフェイルオーバーが必要です。生GPUコストの15-25%をオペレーション費用で予算してください。管理プラットフォーム（Anyscale、Modal、Replicate）はこれを吸収しますが、生GPUに対して30-50%プレミアムを請求しています-GPU支出が~$5K/月未満の場合に価値があります。 4) プロンプトキャッシングはAPIのギャップを狭めます APIプロバイダーはプロンプトキャッシング（繰り返されるプレフィックスで50-90%割引）をますます提供しています。ワークロードがキャッシュフレンドリー（RAG、マルチターン）の場合、APIコストは大幅に低下し、セルフホスティングの損益分岐点ボリュームが上がります。 意思決定フレームワーク APIを使用する場合... 月間出力ボリュームが100Mトークン未満 フロンティアモデルの品質が必要（GPT-4o、Claude Opus 4） チームがGPU/MLOpsの専門知識を持たない レイテンシー要件が厳しい（TTFT 運用オーバーヘッドをゼロにしたい ワークロードがバースト状またはシーズン的 セルフホストする場合... 月間出力ボリュームが一貫して200Mトークンを超える データプライバシーがサードパーティAPIアクセスを要求しない カスタムファインチューニングモデルが必要 チームがMLOps能力を持っている ワークロードが定常状態（予測可能なGPU利用） 1年予約GPUインスタンスを約束できる ハイブリッドアプローチ：実用的な中間地点 ほとんどのチームはハイブリッドになります：フロンティア推論タスクと低ボリュームワークロードにはAPIを使用し、高ボリューム、レイテンシー許容度の高いタスク（コンテンツ生成、データ抽出、内部ツール）にはオープンソースモデルをセルフホストします。これにより、APIコスト支出を制御下に保ちながら、セルフホスト機能を段階的に構築できます。 オープンソースモデルをどこで実行するか プラットフォーム GPUオプション A100 80GB価格 H100価格 管理推論 Lambda Cloud A100, H100, H200 $1.10/時間 $2.49/時間 いいえ（自分のものを持参） RunPod A100, H100, L40S $1.19/時間 $2.69/時間 サーバーレスオプション AWS (p4d/p5) A100, H100 $3.67/時間 $6.37/時間 SageMaker Google Cloud A100, H100 $3.22/時間 $5.07/時間 Vertex AI Xiaomi MiMO ↗ APIベース N/A N/A API ($0.50/$2.00 per 1M) GPU価格は2026年7月時点のオンデマンド時間単価です。予約/スポット価格は大きく異なります。 MiMOはMiMo-V2-ProおよびMiMo-V2-OmniへのAPIベースアクセスを競争力のある料金で提供します-完全なセルフホスティングとプレミアムAPI価格の中間。 独自のLLM支出にこれを適用したいですか？FinOps LLMはAIコストの無料監査を実施し、節約場所を示します。 無料監査を予約 → リサーチに戻る FAQ 方法論は何か？ 各プロバイダーの価格ページから発表された標準料金。ボリュームバッチまたは割引は適用されません。セルフホスト推論最適化セットアップ用クラウドGPUオンデマンド価格（Lambda、RunPod、AWS）vLLMまたはTensorRT-LLM搭載。 コスト比較表とは？ API Cost/月は、標準料金で月間100M出力トークン+300M入力トークンを想定します。セルフホストコストにはGPUレンタル、15%運用オーバーヘッド、推論スタック（vLLM）が含まれます。初期セットアップエンジニアリング時間は含まれません。 主要なコスト要因は？ Llama 4 Maverick用8x H100ノードはLambda、RunPod、またはAWSのオンデマンドで月2,000～3,500ドルです。スポット/先制可能インスタンスはこれを40-60%削減できますが、再起動レイテンシーと可用性リスクが加わります。本番ワークロードについて、予約インスタンス（1年契約）は通常オンデマンドより30-40%節約できます。 意思決定フレームワークは？ ほとんどのチームはハイブリッドになります：フロンティア推論タスクと低ボリュームワークロードにはAPIを使用し、高ボリューム、レイテンシー許容度の高いタスク（コンテンツ生成、データ抽出、内部ツール）にはオープンソースモデルをセルフホストします。 オープンソースモデルをどこで実行するか？ GPUの価格は2026年7月時点のオンデマンド時間単価です。予約/スポット価格は大きく異なります。MiMOはMiMo-V2-ProおよびMiMo-V2-OmniへのAPI ベースアクセスを競争力のある料金で提供します-完全なセルフホスティングとプレミアムAPI価格の中間。 --- # OpenAI費用配分 · FinOps LLM URL: https://finopsllm.com/ja/research/openai-cost-attribution OpenAI費用配分 OpenAI費用配分はリクエストが送信される前に開始します。API応答はトークン使用量を教えることができますが、アプリケーションがそのコンテキストを添付しない限り、どの製品表面、チーム、顧客、またはビジネスワークフローが呼び出しを引き起こしたかは知りません。 配分は3つのソースを組み合わせる必要があります：リクエストメタデータ、使用ログ、および請求書データ。リクエストメタデータは所有権を提供します。使用ログはトークン数とモデルを提供します。請求書データは権威あるファイナンス合計を提供します。 キャプチャするラベル 機能名またはエンドポイント。 チーム所有者および環境。 許可されている場合のプロジェクトまたは顧客。 リアルタイム、バッチ、評価、サポート、またはエージェントステップなどのワークロードクラス。 プロンプトバージョン、ルーティングポリシー、およびフォールバック状態。 配分の一般的なギャップ チームは多くの場合、リトライとフォールバックを見逃します。ユーザーは応答を見ますが、システムは複数のアップストリーム呼び出しに対して支払っている可能性があります。もう1つの一般的なギャップはバッチ作業です：評価とエンリッチメント作業は、低コストの非同期レーンに移動できるように、ユーザー指向のトラフィックから個別にラベル付けする必要があります。 最高のOpenAI配分レポートは「どのモデルが最も費用がかかったか」で止まりません。そのモデルを使用させた製品決定、および変更できる所有者が表示されます。 関連 LLM費用配分 - 一般的な配分原則。 Anthropic費用配分 - Anthropicモデル向けの配分。 LLM FinOpsとは？ - 完全な運用規律。 自分のLLM支出に適用したいですか？FinOps LLMはAI費用の無料監査を実施し、節約場所を示します。 無料監査を予約 → リサーチに戻る --- # OpenAIファインチューニング終了の経済学 · FinOps LLM URL: https://finopsllm.com/ja/research/openai-fine-tuning-sunset-economics OpenAIファインチューニング終了の経済学 公開日：2026年7月19日 OpenAIはセルフサーブファインチューニングを段階廃止しています。2026年5月7日から、新しい組織はファインチューニングジョブを作成できなくなります。2027年1月6日までに、すべての組織がその能力を失います。ファインチューニング済みGPTモデルに依存している場合は、今すぐ移行パスを選択する必要があります：プロンプトキャッシング付きGPT-5.5でのプロンプトエンジニアリング、LlamaまたはQwenでのオープンソースLoRAアダプター、またはVertex AI、AWS Bedrock、またはMistralを通じた管理型ファインチューニング。各パスには異なるコストと運用のトレードオフがあります。 セルフサーブファインチューニング作成は2027年1月6日にすべての組織で終了 既存のファインチューニング済みモデルでの推論は、ベース廃止まで続く GPT-5.5のプロンプトキャッシュは10-30ヒットでファインチューニングのROIに匹敵またはそれを上回る オープンソースLoRAは高ボリュームで管理型サービスより30-50%安い 隠れた移行コスト：再評価、回帰テスト、デュアル実行、再訓練 期限： 組織は2027年1月6日前に移行パスにコミットする必要があります。既存のファインチューニング済みモデルはベースモデルが廃止されるまで推論リクエストの提供を継続しますが、その日付後に新しいトレーニングジョブを作成することはできません。 スケジュールと被爆マトリックス 誰が影響を受け、いつ： 日付 フェーズ 影響を受ける組織 必要なアクション 2026年5月7日 フェーズ1 新規組織、以前のファインチューニングなし 新規ジョブを開始できない 2026年7月2日 フェーズ2 過去60日間ファインチューニング済みモデル推論がない既存組織 新規ジョブを開始できない 2027年1月6日 フェーズ3（最終） すべての組織、アクティブユーザーを含む 新規トレーニングジョブなし 2027年以降 推論のみ デプロイ済みファインチューニング済みモデルをすべての組織 ベースモデルサンセットまで推論継続 OpenAIがファインチューニングを廃止する理由： GPT-5.5クラスのベースモデルとプロンプトキャッシュの組み合わせにより、ほとんどのユースケースでファインチューニングが不要になります。システムプロンプトとfew-shotの例を含む長いプロンプトは、キャッシュ時にファインチューニングのパフォーマンスと同等またはそれ以上でありながら、総トークン数が少なくなります。管理型ファインチューニングのオーバーヘッドは、ほとんどのワークロードの価値を超えています。 意思決定ツリー：3つの移行パス パス1：プロンプトエンジニアリング + GPT-5.5 + キャッシング ファインチューニング済みロジックをシステムプロンプト + キャッシュされたfew-shotの例として書き直します。トレーニングのオーバーヘッドなしで、より長いプロンプトとのトレード。 トレーニングコスト： $0（再訓練なし） 呼び出しあたりのトークンコスト： より長いプロンプト、フレッシュレートの50%でキャッシュ セットアップ時間： 1-4週間（プロンプトエンジニアリング + ベンチマーク） 継続的な操作： プロンプト反復、MLOpsは不要 パス2：LoRA on Open-Source（Together、Fireworks、Groq） LoRAアダプターを使用してLlama 4またはQwen 3.5をファインチューニング、管理型推論でホスト。完全なファインチューニング制御、オープンソース再現性。 トレーニングコスト： ジョブあたり$200-$500 推論コスト： $0.10-$0.30/Mトークン（競争力のある） セットアップ時間： 2-6週間（データ準備、アダプター訓練、テスト） 継続的な操作： アダプターパフォーマンス監視、必要に応じて再訓練 パス3：管理型ファインチューニング（Vertex、Bedrock、Mistral） Google Vertex AI、AWS Bedrock、またはMistralのファインチューニングを使用。おなじみのワークフロー、ベンダーサポート、ただし高いトークンあたりコスト。 トレーニングコスト： ジョブあたり$500-$2,000 推論コスト： $0.20-$1.00/Mトークン（プレミアム） セットアップ時間： 1-3週間（必要な統合が少ない） 継続的な操作： ベンダーが操作を処理、訓練ケイデンスを管理 パス1：プロンプトエンジニアリング + GPT-5.5キャッシング — 解いた数学 カスタマーサポートチケット分類用のファインチューニング済みGPT-4モデルがあったと想定します。ファインチューニング済みモデルは10Kの標識付きチケットで訓練されました。各リクエストは約500トークン入力を送信し、約50トークン出力を取得します。 以前のコスト（ファインチューニング）： ファインチューニングジョブ：~$50。月100K呼び出しでの推論：(500入力×$3/M + 50出力×$15/M) × 100K = $150/月 + 訓練 = 全込み~$200/月。 新しいコスト（GPT-5.5でのプロンプトキャッシング）： 40個のfew-shotの例（各~200トークン）を含むシステムプロンプトを作成 = 8Kトークン。これがキャッシュ充填です。最初の呼び出し：8K×(1.25×$3/M) + 500×$3/M + 50×$15/M ≈ $0.045。以降の呼び出し（キャッシュヒット）：500×(0.5×$3/M) + 50×$15/M ≈ $0.0015。月100K呼び出しで、90%ヒット率を想定（90Kキャッシュヒット）。コスト：10K呼び出し×$0.045 + 90K呼び出し×$0.0015 = $450 + $135 = $585/月 。 待って、それはもっと高い！ プロンプトを調整しない場合は真です。ただしfew-shotの例を10個（2Kトークン）に削減すると、コストは~$280/月に下がります。さらに：クエリをバッチ処理できる場合（1つの呼び出しで10個の関連チケットを処理）、チケットあたりのコストはさらに30%下がります。 結論：GPT-5.5でのプロンプトキャッシュは、ユニークなコンテキストあたり15-30回のキャッシュヒットでファインチューニングより安くなります。 ほとんどのチームはデプロイ後数時間でそこに達します。 品質リスク： few-shotプロンプトは、エッジケースと通常でないフォーマットでファインチューニングの下で実行される可能性があります。回帰テストに2-4週間を予算してください。 パス2：オープンソースLoRA — コストと物流 LoRA（Low-Rank Adaptation）を通じたオープンソースファインチューニングは、ベースモデルを凍結し、小さなアダプター行列（パラメーターの1-5%）のみを訓練します。コスト構造： コンポーネント プロバイダー例 コスト 注記 訓練（10Kサンプル上のLlama 3.3 70B） Together AI $300 単一H100 GPU上のLoRA（~4時間） 推論（1Mトークンあたり） Groq (Llama 3.3 70B) $0.27 高速（ファインチューニング済みGPT-4対調整ラグなし） 推論（1Mトークンあたり） Together AI (Llama 3.3 70B) $0.18 低速応答、低コスト モデルホスティング（月次、常時オン） runpodでセルフホスト $300-$600 A100 GPU レンタル + 運用オーバーヘッド 月100万呼び出しの合計 — $318-$600 Groq API（管理型）、ホスティングコストなし オープンソースがより安い理由： 「ファインチューニング」ステータスのトークンあたりプレミアムなし。アダプターはあなたのものであり、配布および改善できます。モデル品質（Llama 4 Maverick）は、ほとんどのタスクで30-50%低いコストでGPT-4oに相当します。トレード：MLOpsを所有 — 再訓練ケイデンス、ドリフト検出、アダプターバージョン間のA/Bテスト。 統合リスク： OpenAI APIからGroq、Together、またはセルフホストに切り替えると、推論レイテンシ、エラー処理、スケーリングが変わります。1-2週間の統合作業を予想します。 パス3：管理型ファインチューニング（Vertex、Bedrock、Mistral） プロバイダー トレーニングコスト（10Kサンプル） 推論コスト（100万出力トークンあたり） ベースモデル 本番までの時間 Google Vertex AI $500-$800 $0.40-$1.50 Gemini 1.5 Flash、その他のOSモデル 1-2週間 AWS Bedrock（Claude Sonnetファインチューニング） $600-$1,200 $0.80-$2.00 Claude Sonnet、Llama 4、Mistral 1-2週間 Mistralファインチューニング $400-$700 $0.25-$0.60 Mistral 3.5 Moe、その他のMistralモデル 1週間 典型的な月コスト（100K呼び出し、平均500トークン） $600-$1,200（1回限りの訓練） $200-$1,000（再発推論） — — 管理型サービスは最も簡単なオンランプです：チームはすでにAPI認証を知っており、ベンダーサポートが利用可能で、MLOpsオーバーヘッドを回避できます。ただし推論コストはオープンソースLoRA以上2-5倍実行します。このパスは以下の場合に意味があります：(1)月の出力が100M未満のトークン、(2)チームにMLOps経験がない、または(3)エンタープライズSLAが必要。 3パスコスト比較（具体的なワークロード） ワークロード：SaaS向けカスタマーサービスAI。月100万推論呼び出し、呼び出しあたり平均500入力 + 150出力トークン。チームは5Kのラベル付き会話でモデルをファインチューニングしました。 コストコンポーネント パス1：キャッシング+GPT-5.5 パス2：Groq上のLoRA（Llama3.3） パス3：Bedrock（Claude SonnetFT） 初期セットアップ / 訓練 $0（プロンプトエンジニアリングのみ） $300 $1,000 月推論コスト（100万呼び出し） $450-$600 $270 $900-$1,200 月合計（1年目） $450-$600 $600（訓練償却含む） $1,900-$2,200 1年目合計 $5,400-$7,200 $3,600-$4,800 $12,000-$15,000 パス2（LoRA）は純粋コストで勝ちますが、セットアップと保守にMLOps時間が必要です。**パス1（プロンプトキャッシング）はわずかに高い継続コストを受け入れられる場合、摩擦が少なくなります。パス3（管理型）は、エンタープライズSLAまたはハンズオフ操作が必須の場合のみ選択されます。 隠れた移行コスト — これらを見逃さないでください 上記の表は、操作的摩擦を省略しています。計画： 1. 再評価とベンチマーク ホールドアウトテストセット上で新しいモデルの精度、レイテンシ、コストを測定します。予算：2-3週間、$1K-$3Kのエンジニアリング時間。 2. 回帰テスト 古いファインチューニング済みモデルと新しいパスを同じ100-1K本番クエリで実行します。品質ギャップを測定します。カスタマー向けシステムの場合、2-4週間のA/Bテスト（デュアル実行）を検討してください。操作コスト：$2K-$5K。 3. デュアル実行期間 本番環境での回帰を検出するために、古新パスの両方を並列実行します。これは2-4週間の推論コストを2倍にします。移行請求に$500-$2,000を追加します。 4. 訓練ワークフローの変更 定期的に再訓練する場合（月次、四半期）、スクリプト変更に組み込みます。LoRA再訓練スクリプトはOpenAI APIと異なります。Mistral、Vertex、およびBedrockはそれぞれ異なる訓練APIを持っています。予算：1-2週間、$500-$1,500。 5. アダプタードリフトと監視 訓練データが変更された場合、オープンソースアダプターはドリフト可能です。パフォーマンス監視と再訓練トリガーを設定します。管理型サービスの場合、プロバイダーがこれを処理しますが、監視オーバーヘッドを請求します。予算：継続中 +$200-$500/月。 隠れたコスト合計：$4K-$12Kのエンジニアリング時間 + $500-$2,000のデュアル実行操作。 ほとんどのチームはこれを50%過小評価しています。プロジェクト計画に含めてください。 意思決定フレームワーク パス1を選択（キャッシング+GPT-5.5）以下の場合： 月推論ボリュームが100M未満のトークン以下 現在のワークロードは繰り返されるコンテキスト（RAG、マルチターン）を持つ — 高いキャッシュヒット可能性 チームにMLOps経験がなく、最小限のオーバーヘッドを望む 簡潔さのための品質トレードオフを受け入れられる（ほとんどのタスクは≤5%の回帰を見る） レイテンシ要件は柔軟（>500ms TTFTが受け入れ可能） パス2を選択（オープンソースLoRA）以下の場合： 月推論ボリュームが200M以上のトークン — 30-50%のコスト利点 チームは訓練、監視、再訓練のMLOps帯域幅がある 再現性が必要であり、アダプター上で完全な制御が必要（オープンソース利点） データプライバシーはOpenAI、Google、またはAWS独自APIへの呼び出しを除外 レイテンシが重要（ パス3を選択（管理型ファインチューニング）以下の場合： エンタープライズSLA、ベンダーサポート、またはHIPAA/SOC2コンプライアンスが必要 チームにインフラストラクチャ専門知識がなく、ゼロMLOpsを望む 月ボリュームが50M未満のトークン（コスト プレミアムは低スケールで受け入れ可能） ベンダーエコシステムに既に投資済み（AWS、Google Cloud、Mistral） 訓練頻度は月次以下（操作コストはチャーン不足でより良好に償却） 関連資料 より広いコスト環境についてのさらなるコンテキストについては、 オープンソース対クローズドLLMコスト比較 を参照してください。これはセルフホストおよびAPIオプション間で採算点ボリュームを比較しています。 既にファインチューニング移行コストを追跡していますか？FinOps LLMはLLM支出を監査し、どの移行パスが最も節約されるかを特定します。 無料監査を予約 。 リサーチに戻る FAQ OpenAIのファインチューニング済みモデルはいつ新規作成できなくなりますか？ スケジュール：2026年5月7日（新規組織がブロック）、2026年7月2日（60日間の非アクティブ期間の組織がブロック）、2027年1月6日（すべての新規ジョブがブロック）。既存のファインチューニング済みモデルの推論は、ベースモデルの廃止まで続きます。 プロンプトキャッシュはファインチューニングと比較して採算が取れますか？ 同じコンテキスト上の繰り返されるプロンプトに対して：はい。GPT-5.5のプロンプトキャッシュは読取で$0.60/M対$3.00/Mフレッシュで、few-shotの例（より長いプロンプト）は効率的にキャッシュできます。採算点は通常プロンプトサイズに応じて10-30回のキャッシュヒットで、ほとんどのチームは数日以内に達成します。 オープンソースロラは管理型ファインチューニングより安いですか？ 通常はそうです。Together AIを通じた訓練コスト：ジョブあたり約$200-$500。GroqまたはFireworksでの推論：約$0.10-$0.30/Mトークン。成功したレスポンスあたりの総コストは、管理型サービスより30-50%低い場合が多いですが、MLOpsのオーバーヘッドが必要です。 移行中に見落とされている隠れたコストは何ですか？ 再評価（新しいアプローチ対既存比較）、回帰テスト（置換パスが同じ品質を提供するか）、デュアル実行（安全性のための古新パスの並列実行）、新しいモデルが変更される場合のアダプターの再訓練。移行あたり4-8週間と約$2K-$10Kのエンジニアリング時間を予算してください。 --- # Opus 5.5のエフォートレベルが真の価格を決める · FinOps LLM URL: https://finopsllm.com/ja/research/opus-5-5-effort-level-cost Opus 5.5のエフォートレベルが真の価格を決める 更新日 September 22, 2026 · 初回公開 September 22, 2026 Claude Opus 5.5は入力トークン100万あたり$4、出力トークン100万あたり$20です。これはOpus 5より20%安い。料金表はコストストーリーの小さい方の半分だ。大きい方の半分は effort 設定で、モデルが回答する前に考えるのに費やすトークン数を決定する。 1つのモデル、5つの価格 Opus 5.5は low から medium 、 high 、 xhigh 、 max までのエフォートを提供する。各レベルは同じモデルで同じトークン単価だが、生成されるトークン数は大きく異なる。The Decoderが報告した独立した分析では、5つのレベルのうち4つがコスト・パフォーマンスのパレート効率線上にあることが判明した。また、最大エフォートではOpus 5.5がタスクあたり約119,000の出力トークンを使用し、競合モデルの最高設定よりもはるかに多いことが判明した。 100万トークンあたり20ドルなら、出力119,200トークンは入力を除いてもタスクあたり2.38ドルです。medium では Artificial Analysis の実測で出力25,700トークン、0.51ドルでした。入力込みでは max がタスクあたり5.98ドル、medium が1.34ドルで、リクエストパラメータ1つで同じモデルのタスク単価が約4.5倍変わります。 Artificial Analysis Intelligence Index v4.3.2(10種の評価)での実測値、2026年9月22日時点。全行が同じベンチマーク群なので、そのまま比較できます。 モデルとエフォート Intelligence Index タスクあたりコスト タスクあたり出力トークン コスト性能フロンティア上か Opus 5.5 · low 42.3 $0.55 10,200 いいえ Opus 5.5 · medium 51.2 $1.34 25,700 はい Opus 5.5 · high 53.6 $1.82 35,600 はい Opus 5.5 · xhigh 56.0 $3.46 65,700 はい Opus 5.5 · max 57.6 $5.98 119,200 はい Opus 5 · high (参考) 48.1 $3.61 46,200 いいえ 出典:Artificial Analysis。フロンティア上とは、GPT-6 Sol、GPT-6 Astra、Opus 5、Opus 5.5、Fable 5.1 のどの設定も、より安く、より高いスコアを出せないという意味です。Opus 5.5 low は、GPT-6 Sol の xhigh が 0.53ドルで 44.1 を出すため外れます。xhigh から max へ上げると、コスト73%増で1.6ポイント増です。 中程度はAnthropicがベンチマークするための設定 Anthropicの主要な比較はデフォルトエフォート(中程度)で行われる。Opus 5.5を中程度で実行するとGPT-6 Astraを最大エフォートで実行するよりもナレッジワークタスクあたり約5分の1のコストで上回ると言っている。したがって、Anthropic自身のモデル事例は中程度に基づいており、最大は例外だ。「安全のため」すべての場所で最大に設定するチームは、ローンチベンチマークが必要としなかったトークンに対して支払う。 推測なしでエフォートを設定する方法 デフォルトは中程度に。 SDKデフォルトが自分の下で変わる可能性がないコード内の明示的な値にする。 グローバルにではなく、ルートごとにエフォートを上げる。 難しいデバッグ、長期的な計画、最終レビューステップは高または最大を正当化することができる。分類、抽出、ルーチン編集はほぼ決してない。 各リクエストでエフォートをログ記録する。 リクエストあたりのコストはそれなしに解釈不可能だ。フラットなリクエスト数でのコス支出スパイクは通常、エフォート変更だ。 同じ再生されたタスクのエフォートレベルを比較する。 各レベルでの完了したタスクあたりの成功率と出力トークンを記録し、成功の改善が停止したらエフォートの引き上げを停止する。 製品が許可する場合は出力を制限する。 最大トークン制限は最悪の場合を制限する。最大エフォートでは、その制限は、暴走タスクと数ドルのリクエストの間の唯一のものだ。 $25から$20(トークン100万あたり出力)への削減は20%節約できる。ワークロードを最大から中程度エフォートに移すと、それより大幅に節約できる。エフォートを他のものと同じように所有・レビューされるベンチャーラインとして扱う。 関連記事 Claude Opus 5.5コストモデル Opus 5.5ファストモードの経済学 推論モデルコストガイド この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # Opus 5.5 fast mode: 2倍の価格で待ち時間を短縮 · FinOps LLM URL: https://finopsllm.com/ja/research/opus-5-5-fast-mode-economics Opus 5.5 fast modeの経済性 更新日 September 22, 2026 · 初回公開 September 22, 2026 Claude Opus 5.5には2つの価格表があります。標準は入力トークン100万あたり$4、出力トークン100万あたり$20です。Fast modeは$8と$40で、ちょうど2倍で、出力速度は最大2.5×です。モデルは同じです。追加のお金は時間を買うだけなので、唯一の問題は誰の時間かです。 プレミアムが買うもの 5,000の出力トークンを生成するステップを取ります。標準レートでは出力コストは$0.10です。Fast modeでは$0.20です。ステップが標準速度で60秒かかり、2.5×の高速化で約24秒になる場合、36秒節約するために$0.10追加で支払います。 これは削除された待ち時間1時間あたり約$10に相当します。出力トークンで増加するため、ステップ長は比率を変えません。標準モード速度に依存します。この例は1秒あたり約83の出力トークンを想定しているので、自分の値を使用してください。入力も2倍になるため、プレフィックスが多いステップは節約された1秒あたりの費用がやや増えます。 安い場合 対話的コーディングエージェントを待機している開発者。 削除された待ち時間1時間あたり$10の場合、fast modeの費用は給与を支払われている誰かの時間よりはるかに低くなります。 レイテンシが変換に影響する顧客向けの回答。 トークン代金に対してではなく、ドロップオフに対して高速化を価格設定します。 インシデント、ここで毎分コストがあります。 純粋な無駄の場合 バックグラウンドエージェント、夜間ジョブ、バッチパイプライン。 誰も待っていないため、追加支出は何も購入しません。 Evalsとリプレイ。 これらは正確にはトークン数を乗算して実行スケジュールで実行されるワークロードです。 並行実行するサブエージェント。 ウォールクロック時間は最も遅いブランチとオーケストレーターによって設定され、各呼び出しではありません。 標準Opus 5.5はすでにAnthropicによるとOpus 5より約30%高速です。Opus 5でfast modeを正当化した一部のレイテンシの苦情はアップグレードだけで解決されるかもしれません。より多く支払う前に標準速度を測定してください。 実装するコントロール Fast modeを明示的なルート単位の決定にします。 グローバルデフォルトや、エンジニアが一度オンにして忘れたフラグであってはいけません。 モードごとに支出にタグを付けます。 単価の2倍でのfast modeリクエストは、モデルのみでグループ化されるダッシュボード上の通常のリクエストのように見えます。 出力トークンのfast mode共有で警告します。 ユーザーが待機していないルートで上昇する場合、アクティブになったものが何かがあります。 努力と速度を一緒に予算化します。 最大努力はトークンカウントを乗算し、fast modeは各トークンの価格を2倍にします。これはモデルを実行する最も高価な方法です。 関連記事 Claude Opus 5.5コストモデル Opus 5.5努力レベルが実際の価格です サブエージェントのファンアウトと同時実行性の制限 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # Ox Alpha の正体は GLM-5.3。無料モデルが請求書に与える影響 · FinOps LLM URL: https://finopsllm.com/ja/research/ox-alpha-was-glm-5-3 Ox Alpha は GLM-5.3 だった 更新日 September 1, 2026 · 初回公開 September 1, 2026 要約: 2026 年 8 月 20 日から 26 日まで、OpenRouter は stealth/ox-alpha という名称のモデルを無料で提供しました。正体は GLM-5.3-Flash です。総パラメータ 3200 億、アクティブ 180 億、線形とスパースのハイブリッド注意機構、テキスト・画像・動画のネイティブ入力、1,048,576 トークンのコンテキスト、そして MIT... 2026 年 8 月 20 日から 26 日まで、OpenRouter は stealth/ox-alpha という名称のモデルを無料で提供しました。正体は GLM-5.3-Flash です。総パラメータ 3200 億、アクティブ 180 億、線形とスパースのハイブリッド注意機構、テキスト・画像・動画のネイティブ入力、1,048,576 トークンのコンテキスト、そして MIT ライセンスの重みを持ちます。 利用は小規模ではありませんでした。公開から 3 日で OpenCode は約 16 兆トークンの処理、221,000 人のユニークユーザー、500 万を超えるセッションを報告しています。これは評価用ではなく本番トラフィックであり、6 日間は無料でした。 無料は「単価」であり「不在」ではない 多くのコスト計測は 0 ドルの行を存在しない行として扱います。そのため無料期間のトラフィックは予算予測にもアラートにも反映されません。期間が終了して単価が適用されると、同じトラフィックが誰も想定していない段差として現れます。 対策はシャドープライスです。無料の呼び出しでもトークン数を記録し、代替モデルの定価を掛けます。これで promotion の月額価値と、終了日の請求額が可視化されます。 単価はもはや仮定ではありません。GLM-5.3-Flash は入力 100 万トークンあたり 0.15 ドル、出力 0.50 ドルです。入力 16 兆トークンをこの単価で換算すると約 240 万ドル。これが 6 日間の無料提供の価値であり、そのトラフィックが残った場合の段差の大きさです。 確認すべき 3 つのリスク 単価の断崖（明日定価になれば幾らか）、識別子のドリフト（今週その別名の背後にあるモデルは何か）、品質の結合（維持できないモデルにプロンプトを最適化していないか）。モデル ID は固定し、後継モデルの評価は期間終了前に済ませます。 MIT ライセンスは内製判断を変える MIT であれば自社ホスティングは現実的な選択肢です。アクティブ 180 億という規模から、提供コストは中規模の密モデルに近くなります。ただし高い稼働率が続く場合に限ります。GPU 稼働率がおよそ 40〜50% を下回るなら通常は API が有利です。遊休アクセラレータは満額課金され、発生しない API 呼び出しは課金されません。 関連記事 オープンモデルとクローズドモデルのコスト この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # 価格のないモデルに価格をつける方法 · FinOps LLM URL: https://finopsllm.com/ja/research/pricing-an-open-weight-model オープンウェイトモデルの価格計算 更新日 September 1, 2026 · 初回公開 September 1, 2026 要約: Qwen3.8-Flash-Next は 2026 年 8 月 26 日、Qwen4 アーキテクチャのオープンウェイト・プレビューとして公開されました。アクティブパラメータは約 60 億、ネイティブコンテキストは 262,144 トークン、そしてホスト価格の発表はありません。ここで通常の比較が成り立たなくなります。クローズドモデルは 100... Qwen3.8-Flash-Next は 2026 年 8 月 26 日、Qwen4 アーキテクチャのオープンウェイト・プレビューとして公開されました。アクティブパラメータは約 60 億、ネイティブコンテキストは 262,144 トークン、そしてホスト価格の発表はありません。ここで通常の比較が成り立たなくなります。クローズドモデルは 100 万トークンあたりの数字をくれますが、オープンウェイトはチェックポイントだけを渡し、数字の算出はこちらに委ねます。 計算式 MTok あたりコスト = 時間単価 / (毎秒トークン数 * 3600) * 1,000,000 時間単価 2.00 ドル、実測 1,500 tok/s なら 100 万トークンあたり 0.37 ドル 。3.00 ドル/MTok のホスト API と比べれば 8 倍の節約に見えます。しかしこの数字は誤りです。支払っている毎秒 GPU が稼働している前提だからです。 忘れられる項：稼働率 借りるのは 1 時間、使うのはその一部です。稼働率で割ってください。60% なら 0.62 ドル、30% なら 1.23 ドル、10% なら 3.70 ドル — 置き換えるはずだった API より高くなります。初回の運用はトラフィックがバースト的でピークに合わせて確保するため、たいてい 10〜30% に収まります。節約は本物ですが、それは稼働率の節約であって、重みの節約ではありません。 決める前に測る 実際に借りるインスタンス上で、自社のプロンプト形状とコンテキスト長を使ってモデルを動かし、同時実行下の毎秒トークン数を記録してください。モデルカードの単一ストリームの数字ではありません。次に実際のトラフィックから稼働率を出します。数字は 2 つ、割り算は 1 回、それで結論は出ます。モデルが対応するコンテキストではなく、実際に送るコンテキストに価格をつけてください。 関連記事 オープンモデルとクローズドモデルのコスト この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # 品質低下を隠さずにAIのROIを証明する方法 · FinOps LLM URL: https://finopsllm.com/ja/research/prove-ai-roi-measurement 品質低下を隠さずにAIのROIを証明する方法 更新日 August 27, 2026 · 初回公開 August 27, 2026 要約: AIのROIは請求額が下がっただけでは証明できません。成果の改善が、成果を生むための総コストを上回ったときに証明できます。帰属支出、成功成果、品質確認を結び付けます。反実仮想を置くAI変更がなければ人手、旧モデル、旧ワークフローでどうなったかを定義し、比較可能な期間や顧客群を使います。成果を分母にするリクエスト単価ではなく成功タスク単価を測ります。再試行、ツール、人手修正、評価も含めます。品質を守... AIのROIは請求額が下がっただけでは証明できません。成果の改善が、成果を生むための総コストを上回ったときに証明できます。帰属支出、成功成果、品質確認を結び付けます。 反実仮想を置く AI変更がなければ人手、旧モデル、旧ワークフローでどうなったかを定義し、比較可能な期間や顧客群を使います。 成果を分母にする リクエスト単価ではなく成功タスク単価を測ります。再試行、ツール、人手修正、評価も含めます。 品質を守る 成功率、エラー、遅延、受入率を同時に示します。品質を下げた節約はROIではありません。 関連記事 成功タスク単価 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # AIプロバイダーの価格表をそのまま比較できない理由 · FinOps LLM URL: https://finopsllm.com/ja/research/provider-prices-not-comparable AIプロバイダーの価格表をそのまま比較できない理由 更新日 August 27, 2026 · 初回公開 August 27, 2026 要約: 100万トークンあたりの表示価格だけを比べると、見かけの節約になります。請求単位、割引、品質が異なるためです。同じワークロードで成功タスク単価を比較します。請求単位をそろえるプロバイダー、モデル、地域、トークン種別、キャッシュ、バッチ、日付ごとの価格表を作ります。入力、出力、キャッシュ、推論、画像、音声、ツールを分けます。ワークロードをそろえる同じプロンプト、コンテキスト、出力制限、成功条件を再生... 100万トークンあたりの表示価格だけを比べると、見かけの節約になります。請求単位、割引、品質が異なるためです。同じワークロードで 成功タスク単価 を比較します。 請求単位をそろえる プロバイダー、モデル、地域、トークン種別、キャッシュ、バッチ、日付ごとの価格表を作ります。入力、出力、キャッシュ、推論、画像、音声、ツールを分けます。 ワークロードをそろえる 同じプロンプト、コンテキスト、出力制限、成功条件を再生し、遅延、完了率、リトライ、人手修正、品質を測ります。 運用費を含める ゲートウェイ、監視、ルーティング、評価、サポートも含め、品質と実効コストを満たす最安の経路へ振り分けます。 関連記事 LLMプロバイダー間の裁定 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # レート制限はコスト管理の手段 · FinOps LLM URL: https://finopsllm.com/ja/research/rate-limits-are-cost-control レート制限、429、ティア引き上げ 更新日 September 1, 2026 · 初回公開 September 1, 2026 要約: 429 が返り始めると、可用性のインシデントとして扱いたくなります — 上限を上げ、ティアを上げ、リトライを足してスループットを戻す。正しいこともあります。同時にそれは、暴走したループが五桁の請求書に変わる経路でもあります。止めていた唯一のものを、いま外したからです。429 が実際に伝えていること「システムが許容より速く支出しようとしている」ということです。理由は大きく 2... 429 が返り始めると、可用性のインシデントとして扱いたくなります — 上限を上げ、ティアを上げ、リトライを足してスループットを戻す。正しいこともあります。同時にそれは、暴走したループが五桁の請求書に変わる経路でもあります。止めていた唯一のものを、いま外したからです。 429 が実際に伝えていること 「システムが許容より速く支出しようとしている」ということです。理由は大きく 2 つあり、対応は正反対になります。 本物の需要増 （利用者増、ローンチ、季節ピーク）なら上限が低すぎるので、引き上げは売上を買います。 暴走 （リトライ嵐、ループするエージェント、絞っていないバックフィル、本番キーを向いたテスト）なら、上限はまさに仕事をしています。 エラー率だけでは両者を区別できません。作業 1 件あたりのコストを見れば簡単に区別できます。本物の成長では量が増えても比率はほぼ一定、暴走では比率が壊れます。この比率をティア引き上げの判断基準にしてください。 リトライが静かに悪化させる 指数バックオフとジッターのない 429 リトライは、1 回の超過を同期した嵐に変えます。成功した分は課金され、失敗分も入力処理を消費していることがあります。しかもリトライはクライアントライブラリ側にあることが多く、機能の設計書にはどこにも現れません。 意図して上限を使う プロバイダの上限より低い自前の上限を、環境ごと・機能ごとに設定してください。最初に壊れるのが自分の上限なら、次に何が起きるかを自分で決められます。非本番は厳しく固定を。アラートはエラー数ではなく作業あたりコストに。そしてティア引き上げは、名前のある担当者が行う支出判断として扱ってください。 関連記事 リトライループの隠れた支出 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # コーパスの再エンベディングは繰り返す · FinOps LLM URL: https://finopsllm.com/ja/research/re-embedding-is-recurring 埋め込みとベクトルストアの継続コスト 更新日 September 1, 2026 · 初回公開 September 1, 2026 要約: 埋め込みコストはプロジェクト費目として承認されます — 数百万ドキュメント、一度きりの実行、生成コストと並べれば小さな数字。ところが止まりません。すでに支払った埋め込みを、3 つの別々の力がやり直させるからです。3... 埋め込みコストはプロジェクト費目として承認されます — 数百万ドキュメント、一度きりの実行、生成コストと並べれば小さな数字。ところが止まりません。すでに支払った埋め込みを、3 つの別々の力がやり直させるからです。 3 つの更新要因 コンテンツの入れ替わり 。最も正直で最も小さい要因です。事業規模に比例し、素直に予測できます。 チャンク分割・パイプラインの変更 。これが厄介です。チャンクサイズ、オーバーラップ、メタデータ、前処理を少しでも変えると、 ストア内の全ベクトル が無効になります。設定変更のように聞こえる検索品質の実験が、コーパス全体の再埋め込みです。好調な四半期にはこれを何度も回します。 モデルの変更 。これが最大です。埋め込み空間はモデル間で互換性がないため、より良い／安いモデルへ移るには、検索できるようになる前に全件を埋め込み直す必要があります。段階的な経路も部分移行もありません — 2 つのストアを並走させるか、停止を受け入れるかです。 ストア自体も費目 ベクトルは保持にも費用がかかります。マネージドのベクトル DB はストレージとクエリ処理の双方に課金し、どちらも次元数に効きます。検索精度がわずかに良い高次元モデルは、ホスティング費用が恒久的に大きく高くなり得ます。この判断は通常、モデルを選んだ人が品質だけを見て、ホスティング請求を見ないまま行われます。 年金のように予算化する コーパス全体の再埋め込みを年 1 回以上は見込み、例外ではなく定例として扱ってください。候補モデルの評価は、トークン単価ではなく 再埋め込み費用 + 1 年分のストレージとクエリ処理 で行います。元データを常に参照可能な形で保持しておけば、再埋め込みは再取り込みプロジェクトではなくバッチジョブになります — そしてそのジョブはバッチ API で流してください。全件再埋め込みは、自社で最もレイテンシに寛容なワークロードであり、バッチ料金が最も効く対象です。 関連記事 RAG のコスト最適化 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # タスク単価の実測:Opus 5.5 vs Sol・Astra・Fable · FinOps LLM URL: https://finopsllm.com/ja/research/real-cost-per-task-frontier-models フロンティアモデルのタスク単価の実測 更新日 September 22, 2026 · 初回公開 September 22, 2026 定価からわかるのはトークン1つの値段です。完了したタスク1件の値段はわかりません。同じ作業でも、モデルによって使うトークン数が大きく違うからです。このページでは、Claude Opus 5.5、Claude Opus 5、Claude Fable 5.1、GPT-6 Astra、GPT-6 Sol の全 effort レベルについて、実測のタスク単価と品質スコアを並べました。すべての数字に出典があり、推定値はありません。 結論:スコア 47.5 までなら、どの水準でも GPT-6 Sol が最安です。47.5 を超えると、どのレベルでも Opus 5.5 が最安です。low より上の GPT-6 Astra、Opus 5、Fable 5.1 はどの設定もコスト効率が悪く、いずれもスコアと価格の両方で Sol か Opus 5.5 のいずれかの設定に負けています。 方法 スコアとコストはすべて Artificial Analysis Intelligence Index v4.3.2(2026年9月22日閲覧)によるものです。この指標は AA-Briefcase、GDPval-AA、AutomationBench-AA、Terminal-Bench 4.0、SciCode、Humanity's Last Exam、GDP.pdf、CritPt、AA-Omniscience、AA-LCR の10種類の評価で構成されています。Artificial Analysis は各モデルを各 effort 設定でプロバイダーの API から実行し、定価で支払った額を記録しています。タスク単価はそのタスクあたりの支出で、入力と出力に分けています。どの行も同じ評価セットで測っているので、行どうしをそのまま比較できます。 数字を読む前に、制約が2つあります。第一に、この指標は1つのタスク構成にすぎません。自社のタスク構成ではコストが変わるため、最後の節で自分で測る方法を説明しています。第二に、指標のバージョンが違うスコアは比較できません。以前に公表された数字と混ぜないでください。 全体の一覧:26 設定 タスクあたり出力トークンは、推論を含めてモデルが書いたトークン数です。GPT-6 Sol の中間4設定について Artificial Analysis は入力と出力の内訳を公表していないため、その欄は n/a としています。 モデル Effort Intelligence Index タスク単価 入力コスト 出力コスト タスクあたり出力トークン フロンティア上 GPT-6 Sol none 28.1 $0.33 $0.28 $0.05 4,900 いいえ GPT-6 Sol low 33.9 $0.13 n/a n/a 3,400 はい GPT-6 Sol medium (デフォルト) 39.8 $0.25 n/a n/a 6,500 はい GPT-6 Sol high 42.8 $0.37 n/a n/a 10,200 はい GPT-6 Sol xhigh 44.1 $0.53 n/a n/a 16,000 はい GPT-6 Sol max 47.5 $1.06 $0.74 $0.31 31,200 はい GPT-6 Astra low 45.8 $0.82 $0.60 $0.22 4,400 はい GPT-6 Astra medium 49.6 $1.54 $1.06 $0.48 9,600 いいえ GPT-6 Astra high 50.9 $1.73 $1.13 $0.59 11,800 いいえ GPT-6 Astra xhigh 52.4 $2.31 $1.46 $0.85 16,900 いいえ GPT-6 Astra max 52.7 $3.26 $1.90 $1.36 27,200 いいえ Claude Opus 5 low 39.4 $1.10 $0.73 $0.37 14,700 いいえ Claude Opus 5 medium 44.8 $2.19 $1.47 $0.72 29,000 いいえ Claude Opus 5 high (デフォルト) 48.1 $3.61 $2.46 $1.16 46,200 いいえ Claude Opus 5 xhigh 49.7 $4.88 $3.36 $1.52 60,700 いいえ Claude Opus 5 max 50.8 $5.86 $4.05 $1.81 72,500 いいえ Claude Opus 5.5 low 42.3 $0.55 $0.35 $0.20 10,200 いいえ Claude Opus 5.5 medium (デフォルト) 51.2 $1.34 $0.82 $0.51 25,700 はい Claude Opus 5.5 high 53.6 $1.82 $1.11 $0.71 35,600 はい Claude Opus 5.5 xhigh 56.0 $3.46 $2.15 $1.31 65,700 はい Claude Opus 5.5 max 57.6 $5.98 $3.60 $2.38 119,200 はい Claude Fable 5.1 low 46.8 $2.37 $1.30 $1.08 21,600 いいえ Claude Fable 5.1 medium 48.9 $2.98 $1.59 $1.39 27,900 いいえ Claude Fable 5.1 high 51.2 $3.91 $2.01 $1.90 38,100 いいえ Claude Fable 5.1 xhigh 53.2 $5.98 $2.96 $3.02 60,500 いいえ Claude Fable 5.1 max 53.4 $7.63 $3.73 $3.90 78,100 いいえ 「フロンティア上」とは、この表の中に、より安くてより高いスコアの設定が他にないことを意味します。 コストのフロンティア 26 設定のうち 10 設定がフロンティア上にあります。コスト順に並べると、価格だけで判断するなら検討に値するのはこの10設定だけです。それ以外は、同じかそれ以下のスコアにより多く払っています。 設定 Intelligence Index タスク単価 1万タスクあたり GPT-6 Sol · low 33.9 $0.13 $1,300 GPT-6 Sol · medium 39.8 $0.25 $2,500 GPT-6 Sol · high 42.8 $0.37 $3,700 GPT-6 Sol · xhigh 44.1 $0.53 $5,300 GPT-6 Astra · low 45.8 $0.82 $8,200 GPT-6 Sol · max 47.5 $1.06 $10,600 Claude Opus 5.5 · medium 51.2 $1.34 $13,400 Claude Opus 5.5 · high 53.6 $1.82 $18,200 Claude Opus 5.5 · xhigh 56.0 $3.46 $34,600 Claude Opus 5.5 · max 57.6 $5.98 $59,800 フロンティアには2つの領域があります。0.13ドルから1.06ドルまではほぼ GPT-6 Sol で、唯一の例外が 0.82ドルの GPT-6 Astra low です。1.34ドル以上は Opus 5.5 だけです。2つの領域の差は小さく、Opus 5.5 medium は Sol max より 3.7 ポイント高く、タスクあたりの差額は 0.28ドルです。 同等以上のスコアでの直接比較 各ペアは、安い設定と、それと同じかそれ以下のスコアの高い設定を比べています。 安い設定 高い設定 スコア差 削減額 Opus 5.5 medium: 51.2, $1.34 Opus 5 high: 48.1, $3.61 Opus 5.5で+3.1 63% Opus 5.5 medium: 51.2, $1.34 Opus 5 max: 50.8, $5.86 Opus 5.5で+0.4 77% Opus 5.5 medium: 51.2, $1.34 Fable 5.1 high: 51.2, $3.91 同点 66% Opus 5.5 high: 53.6, $1.82 GPT-6 Astra max: 52.7, $3.26 Opus 5.5で+0.9 44% Opus 5.5 high: 53.6, $1.82 Fable 5.1 max: 53.4, $7.63 Opus 5.5で+0.2 76% GPT-6 Sol max: 47.5, $1.06 Opus 5 high: 48.1, $3.61 Opus 5で+0.6 71% Opus 5 の行は、まだ移行していないチームにとって重要です。Opus 5 のデフォルトは high でした。Opus 5.5 のデフォルトは medium で、その設定でタスク単価は 63% 安く、スコアは 3.1 ポイント高くなります。Anthropic は Opus 5.5 が Opus 5 より 40% 安いとしていますが、この指標での実測差はその主張より大きくなっています。 お金の行き先:出力ではなく入力 どのモデルでも、タスク単価の約半分から4分の3が入力です。Opus 5.5 medium では 1.34ドルのうち 0.82ドル、つまり 61% が入力です。GPT-6 Astra max では 58%、GPT-6 Sol max では 70%、Fable 5.1 max では 49% です。エージェントのタスクは、ステップごとに膨らんだコンテキストを送り直します。そのため入力コストは回答の長さだけでなく、ステップ数に比例して増えます。 GPT-6 Sol の推論なし設定が low より高いのはこのためです。出力は 4,900 トークンしかないのに、0.13ドルに対して 0.33ドルかかります。0.33ドルのうち 0.28ドルが入力です。おそらくステップ数が増え、そのたびにコンテキストを送り直しているのが原因です。推論をオフにしても、その分ターン数が増えればエージェントは安くなりません。 請求額の面では、キャッシュがモデル選びと同じくらい重要だということです。Opus 5.5 と GPT-6 Sol はキャッシュ済み入力100万トークンあたり 0.20ドルです。GPT-6 Astra は 1.00ドル、Opus 5 は 0.50ドルです。 トークン量と定価 ここで最もトークン効率がよいのは GPT-6 Astra です。max でもタスクあたりの出力は 27,200 トークンで、Opus 5.5 max の 119,200 トークンを大きく下回ります。しかし Astra の料金は100万トークンあたり 10ドルと 50ドルで、Opus 5.5 の 2.5× です。勝つのは定価のほうで、Opus 5.5 high はタスクあたり 1.82ドルでスコア 53.6、Astra max は 3.26ドルでスコア 52.7 です。 冗長さが効いてくるのは Opus 5.5 max だけです。出力 119,200 トークンだけで入力抜きでも 2.38ドル、タスク全体では 5.98ドルかかります。これで表の最高スコア 57.6 が得られますが、コストは medium の 4.5× です。 effort を上げたときの収穫逓減 各行は、effort を1段階上げたときに得られる指標ポイントと、タスクあたりの追加コストを示しています。 モデル medium → high xhigh → max GPT-6 Sol +48%で+3.0ポイント +100%で+3.4ポイント GPT-6 Astra +12%で+1.3ポイント +41%で+0.3ポイント Claude Opus 5 +65%で+3.3ポイント +20%で+1.1ポイント Claude Opus 5.5 +36%で+2.4ポイント +73%で+1.6ポイント Claude Fable 5.1 +31%で+2.3ポイント +28%で+0.2ポイント Fable 5.1 と GPT-6 Astra では、max にしてもほとんど何も得られません。28% と 41% 高くなって 0.2 と 0.3 ポイントです。Opus 5.5 では max に上げるとまだ 1.6 ポイント上がりますが、コストは 73% 増えます。max は、追加のポイントで結果が変わると実測で確かめたタスクだけに使ってください。 GPT-6 Sol max で足りる場面 指標は平均値であり、Sol max と Opus 5.5 medium の差は評価ごとに均一ではありません。Artificial Analysis による評価別スコア: 評価 Opus 5.5 medium ($1.34) GPT-6 Sol max ($1.06) Terminal-Bench 4.0 52.5 43.9 AutomationBench-AA 61.2 61.6 GDPval-AA (Elo) 1576 1487 AA-Briefcase (Elo) 1642 1483 Humanity's Last Exam 54.7 47.9 SciCode 59.3 57.6 CritPt 27.7 30.9 AA-LCR 84.3 83.7 AutomationBench と CritPt では、GPT-6 Sol がタスクあたり 1.34ドルに対して 1.06ドルで Opus 5.5 medium と同等以上です。Terminal-Bench、ナレッジワーク系の評価、Humanity's Last Exam では Opus 5.5 が大きくリードしています。ワークフローの自動化は Sol で回せます。ターミナルやコーディングのエージェント、文書の多いナレッジワークでは、Opus 5.5 が価格に見合う働きをします。 ベンダー公表値と独立測定値 ベンダーの公表値と独立機関の数字は、評価環境や設定が違うため、ずれることがよくあります。Anthropic は xhigh の Opus 5.5 について Terminal-Bench 4.0 で 66.4% と公表しています。Artificial Analysis の同じ effort での実測は 59.6% です。 Effort Opus 5.5 Fable 5.1 low 31.3% 40.4% medium 52.5% 44.9% high 56.6% 52.0% xhigh 59.6% 55.1% max 59.6% 52.0% 順位も指標によって変わります。Vals AI Index では Fable 5.1 が 68.83% で1位、GPT-6 Astra が 66.61% で3位、Opus 5.5 が 66.16% で4位です。そこではタスク単価が同じ基準で公表されていないため、上のフロンティアは変わりません。1つの指標は1つの見方にすぎない、ということです。 定価とキャッシュ中心のタスク Digital Applied は、キャッシュ中心のエージェントタスク1件の料金を各モデルで計算しました。キャッシュ読み取り 8M トークン、キャッシュなし入力 400K、キャッシュ書き込み 600K、出力 300K です。結果はフロンティアどおりで、GPT-6 Astra にだけ追加のペナルティがあります。 モデル 入力 $/MTok 出力 $/MTok キャッシュ読み取り $/MTok キャッシュ中心のタスク(Digital Applied) GPT-6 Sol $2.00 $10.00 $0.20 $6.90 Claude Opus 5.5 $4.00 $20.00 $0.20 $12.20 Claude Opus 5 $5.00 $25.00 $0.50 $17.25 Claude Fable 5.1 $10.00 $50.00 $0.25 $28.50 GPT-6 Astra (≤272K) $10.00 $50.00 $1.00 $34.50 GPT-6 Astra (>272K) $20.00 $75.00 n/a $61.50 GPT-6 Astra は、入力が 272K トークンを超えるとリクエスト全体に100万トークンあたり 20ドルと 75ドルを課金します。Opus 5.5 は 1M トークンのウィンドウ全体で単一価格です。Opus 5.5 のキャッシュ書き込みは 5分キャッシュで100万トークンあたり 5ドル、1時間キャッシュで 8ドル、バッチは 50% の料金、高速モードは2倍の料金です。詳しくは Claude Opus 5.5 のコストモデル と Opus 5.5 高速モードの経済性 をご覧ください。 自社のタスク単価を測る方法 トークンはリクエスト単位ではなくタスク単位で記録します。キャッシュなし入力、キャッシュ済み入力、キャッシュ書き込み、出力を、タスクの全ステップにわたって合計します。 実際のタスクを数百件サンプルとして取り出し、Sol max、Opus 5.5 medium、Opus 5.5 high など候補の設定2〜3個で再実行します。 各結果を本番と同じチェックで採点し、合格したタスクの数を数えます。 総支出を合格タスク数で割ります。比べるべきなのは成功タスクあたりのコストです。安くても失敗が多い設定は、安くありません。 品質基準を満たす最も安い設定を選び、失敗したタスクだけを上位の設定に回します。 価格やデフォルトの effort が変わったら、再実行し直します。 1つのモデルで effort 設定が請求額をどう変えるかは、 Opus 5.5 の effort レベルこそが本当の価格 をご覧ください。 注意点 コストはすべて、Artificial Analysis のタスク構成での API 定価です。割引、バッチ料金、自社のキャッシュで変わります。 Artificial Analysis は Opus 5.5 と Fable 5.1 の項目に Default Fallback と表示しています。すべての行を同じ API 構成とみなす前に、方法論の注記を確認してください。 スコアは指標 v4.3.2 のものだけです。以前のバージョンは評価の構成が違うため、比較できません。 Digital Applied のキャッシュ中心タスクは説明用の1つのワークロードで、実測値ではありません。 プロバイダーが価格やデフォルトを変えると数字も変わります。閲覧日は2026年9月22日です。 出典 Artificial Analysis Intelligence Index Artificial Analysis: Claude Opus 5.5 Artificial Analysis: Claude Opus 5 Artificial Analysis: Claude Fable 5.1 Artificial Analysis: GPT-6 Astra Artificial Analysis: GPT-6 Sol Digital Applied: GPT-6 Sol vs Claude Opus 5.5 cost benchmarks Digital Applied: Claude Opus 5.5 vs GPT-6 Astra Digital Applied: Is Claude Fable 5.1 still worth it? Digital Applied: Claude Opus 5.5 launch pricing and benchmarks Digital Applied: Opus 5.5 vs Grok 4.7 vs Muse Spark 1.3 cost per task 関連記事 Claude Opus 5.5 のコストモデル Opus 5.5 の effort レベルこそが本当の価格 Opus 5.5 高速モードの経済性 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # 推論モデルコストガイド · FinOps LLM URL: https://finopsllm.com/ja/research/reasoning-model-cost-guide 推論モデルコストガイド 更新日：2026年7月15日 · 最初の公開日：2026年7月4日 o3、o4-mini、DeepSeek-R1、QwQ、MiMoのような推論モデルは、出力を生成する前に内部的な「思考」トークンを生成します。この隠れたコストはあなたの請求を5-30倍に膨らませることができます。このガイドは、推論モデルがプレミアムに値する場合と、標準モデルがより賢い支出である場合を分解しています。 5-30x コスト乗数 10 比較モデル 4 プロバイダー 2026年7月 最終更新 すべての価格は USD で 1 百万トークン単位 推論トークン数はタスクの複雑さによって異なります 思考トークンは出力トークンとして課金されます 「思考」トークンとは何ですか？ 推論モデルは回答する前に、内部的な連鎖思考に対してトークンを費やします。シンプルな質問は 2,000 の思考トークンをトリガーするかもしれません；複雑なコーディングタスクは 30,000+ を生成することができます。これらのトークンは API レスポンスで見えませんが、出力レートで課金されます - しばしば最も高い層です。 方法論 標準価格 標準的な（非推論）完了のための出力トークン価格、公式プロバイダーページから。 推論価格 思考トークンを含む効果的なコスト。標準出力価格×各モデルの平均思考乗数として測定されます。 思考乗数 コーディング、数学、分析ベンチマーク間の可視出力トークンに対する総課金トークンの平均比率。 最適なユースケース 推論モデルがコスト プレミアムを正当化するのに十分な標準モデルを実証的に上回るタスク。 推論モデル価格表 モデル ↕ プロバイダー ↕ 標準出力 $/1M ↕ 推論出力 $/1M ↕ 乗数 ↕ 最適なユースケース Claude Fable 5 Anthropic $50.00 $200.00 4x フロンティア推論、複雑なソフトウェア脆弱性、深い分析 Claude Opus 4.8 Anthropic $25.00 $100.00 4x フロンティア推論、複雑な分析、エージェントワークフロー GPT-5.6-Sol OpenAI $30.00 $120.00 4x フロンティア推論、複雑なコード、数学、多段階分析 GPT-5.6-Terra OpenAI $15.00 $60.00 4x 推論、コード生成、構造化分析 Grok 4.5 xAI $6.00 $24.00 4x 数学、推論、一般的な知能 o3 OpenAI $8.00 $40.00 5x 複雑なコーディング、数学的証明、深い推論 o4-mini OpenAI $4.40 $17.60 4x コスト敏感な推論、コーディング、分析 DeepSeek R1 DeepSeek $2.19 $8.76 4x 数学、コード、推論、中国語タスク Claude Sonnet 5 Anthropic $10.00 $40.00 4x 一般的な推論、コーディング、分析（バランス） GPT-5.5 (標準) OpenAI $30.00 $30.00 1x 一般的なチャット、コーディング、複雑な分析 推論モデルをいつ使うべきか 1) マルチステップコーディングとデバッグ 推論モデルは計画が必要なタスクで優れています：複数ファイルのリファクタリング、複雑な状態のデバッグ、またはエッジケースのあるアルゴリズムの作成。思考トークンにより、モデルはパターンマッチングではなく、問題を「仕事を通す」ことができます。4-5 倍のプレミアムは、人間が 30 分以上費やすことになる場合に見合う価値があります。 2) 数学と論理の証明 正式な推論が必要なタスク - 証明、最適化の問題、制約充足 - 最大の品質ジャンプを見ます。標準モデルはしばしば妥当ですが間違った答えを生成します；推論モデルは自己検証します。正確性が速度より重要な場合、コスト プレミアムは正当です。 3) 複数のステップを持つ複雑なデータ分析 条件付きロジック、複数のソースの相互参照、またはマルチステップ パイプラインの構築でデータセットを分析することは、連鎖的思考から恩恵を受けます。標準モデルはステップを逃す可能性があります；推論モデルは各ステップを明示的に処理します。 推論モデルをいつ避けるべきか 1) シンプルな抽出とフォーマット ドキュメントからのデータ抽出、JSON の再フォーマット、テキストの要約、またはコンテンツの翻訳。これらのタスクは推論ではなくパターンマッチングが必要です。抽出に o3 を使用することは、数学者にメールを分類させるようなものです - 高額で不要です。 2) 高ボリューム、低複雑度のワークロード コンテンツ生成、FAQ 回答、基本的なチャットボット応答、データ ラベリング。月間 10M 以上のトークンでは、4-5 倍の推論乗数は急速に合計されます。標準モデルは出力 $10/1M で推論モデルを $40-60/1M で勝ちます。品質が「十分」なタスク用です。 3) レイテンシに敏感なアプリケーション 推論モデルはより時間がかかります - 思考トークンは 2-10 秒のレイテンシを追加します。リアルタイム チャット、対話型ツール、またはスピードが重要なユーザー向けレスポンスの場合、標準モデルはより高速、より低いコストで配信します。 コスト最適化戦略 複雑さによるルーティング 安価な標準モデル（GPT-4o-mini、Gemini Flash）をルーターとして使用します。タスクが単純な場合は直接回答します。複雑な場合は推論モデルにエスカレートします。この「カスケード」パターンは推論モデルの使用を 60-80% 削減しながら、重要な場所で品質を保持できます。 思考予算を制限 一部のプロバイダー（OpenAI、Google）では、リクエストごとに最大思考トークン予算を設定できます。4,000-8,000 思考トークンでキャップすることで、深い推論を必要としないタスクで不安定なコストを防ぎます。タイトに始めて、品質が落ちた場合のみ増加させます。 プロンプトをキャッシュ 推論タスクが共通のシステム プロンプトまたはコンテキスト（コードベース、ドキュメント）を共有する場合、プロンプト キャッシュは入力コストを 50-90% 削減できます。これは思考トークンを減らしませんが、リクエストあたりの全体的なコストを大幅に低下させます。 非緊急の推論をバッチ処理 評価、テスト生成、またはレイテンシを許容する分析の場合、バッチ API は 50% の割引を提供します。推論モデルと組み合わせると、出力コストの半分で品質上の利点が得られます。 推論出力 $/1M には思考トークンが出力レートで課金されています。乗数は通常のタスク間の平均です；実際の乗数はプロンプトの複雑さによって異なります。 DeepSeek R1 と QwQ はデフォルトで思考トークンを出力します。OpenAI o3/o4-mini は思考トークンを可視出力とは別に課金します。 Gemini 2.5 Pro は、可視出力に対して削減されたレートで「思考トークン」を課金します - 乗数は有効なブレンド コストです。 一部のリンクには紹介コードが含まれている場合があります。 自分のLLM支出に適用したいですか？FinOps LLMはAI費用の無料監査を実施し、節約場所を示します。 無料監査を予約 → リサーチに戻る FAQ 方法論とは何か？ 標準的な（非推論）完了のための出力トークン価格、公式プロバイダーページから。推論価格：思考トークンを含む効果的なコスト。標準出力価格×各モデルの平均思考乗数として測定されます。 推論モデル価格表とは何か？ 推論出力 $/1M には思考トークンが出力レートで課金されています。乗数は通常のタスク間の平均です；実際の乗数はプロンプトの複雑さによって異なります。DeepSeek R1 と QwQ はデフォルトで思考トークンを出力します。OpenAI o3/o4-mini は思考トークンを可視出力とは別に課金します。 推論モデルをいつ使うべきか？ 推論モデルは計画が必要なタスクで優れています：複数ファイルのリファクタリング、複雑な状態のデバッグ、またはエッジケースのあるアルゴリズムの作成。思考トークンにより、モデルはパターンマッチングではなく、問題を「仕事を通す」ことができます。 推論モデルをいつ避けるべきか？ ドキュメントからのデータ抽出、JSON の再フォーマット、テキストの要約、またはコンテンツの翻訳。これらのタスクは推論ではなくパターンマッチングが必要です。抽出に o3 を使用することは、数学者にメールを分類させるようなものです - 高額で不要です。 コスト最適化戦略とは何か？ 安価な標準モデル（GPT-4o-mini、Gemini Flash）をルーターとして使用します。タスクが単純な場合は直接回答します。複雑な場合は推論モデルにエスカレートします。この「カスケード」パターンは推論モデルの使用を 60-80% 削減しながら、重要な場所で品質を保持できます。 --- # 同じモデルでもリージョンで値段が違う · FinOps LLM URL: https://finopsllm.com/ja/research/regional-pricing-premium リージョン料金とデータ所在地の割増 更新日 September 1, 2026 · 初回公開 September 1, 2026 要約: 予算の根拠にした料金表は、たいてい米国の料金です。同じリクエストを欧州やアジアのエンドポイント経由にしたり、データ所在地の要件でリージョンを固定したりすると、数字は変わります — トークン単価のこともあれば、その周辺すべてのこともあります。割増はどこから来るか同時に 4... 予算の根拠にした料金表は、たいてい米国の料金です。同じリクエストを欧州やアジアのエンドポイント経由にしたり、データ所在地の要件でリージョンを固定したりすると、数字は変わります — トークン単価のこともあれば、その周辺すべてのこともあります。 割増はどこから来るか 同時に 4 か所から来ます。プラットフォームによって異なる リージョン別トークン価格 。主要リージョン以外では遅れる モデルの提供状況 。 リージョン間の egress とレイテンシ 。そして最も効くのが 機能の欠落 です。そのリージョンにプロンプトキャッシュやバッチ料金がなければ、前提にしていた割引が消えます。 これが一番痛みます。キャッシュとバッチ前提で設計したワークロードを、それらのないリージョンへ移すと、数パーセント高くなるのではなく、最適化なしの金額になります。 決めるものであって、引き継ぐものではない 所在地要件は本物の義務であることが多く、その場合の割増は合法に運用する価格にすぎません。失敗は、割増を払うことではなく、必要のないワークロードにまで払うことです。 データの中身でトラフィックを分けてください。個人データや規制対象は準拠リージョンへ。内部ツール、評価実行、合成データのワークロードには所在地要件がなく、最も安く機能の揃った場所で動かすべきです。 関連記事 LLM コストの帰属 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # 推論コストを静かに増やすリトライループ · FinOps LLM URL: https://finopsllm.com/ja/research/retry-loop-hidden-spend 推論コストを静かに増やすリトライループ 更新日 August 27, 2026 · 初回公開 August 27, 2026 要約: リトライは無料の回復処理ではなく、追加のモデル呼び出しです。リトライとフォールバックの支出を推論支出全体で割り、ワークフロー別に測ります。試行の木を記録する親リクエスト、試行番号、プロバイダー、モデル、ツール、エラー、トークン、結果を記録します。入れ子の呼び出しには親子関係が必要です。ループを制限するエラー種別ごとに試行回数、トークン、金額、時間の上限を定めます。入力検証やコンテキスト超過を同じ条... リトライは無料の回復処理ではなく、追加のモデル呼び出しです。リトライとフォールバックの支出を推論支出全体で割り、ワークフロー別に測ります。 試行の木を記録する 親リクエスト、試行番号、プロバイダー、モデル、ツール、エラー、トークン、結果を記録します。入れ子の呼び出しには親子関係が必要です。 ループを制限する エラー種別ごとに試行回数、トークン、金額、時間の上限を定めます。入力検証やコンテキスト超過を同じ条件で繰り返してはいけません。 すべてのリトライを無効にするのではなく、各試行を可視化し、上限を設け、成果の改善で正当化します。 関連記事 エージェント支出のガードレール この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # SaaSのAIクレジット：自社が制御できない単位を計測する · FinOps LLM URL: https://finopsllm.com/ja/research/saas-ai-credits-metering SaaSのAIクレジット：自社が制御できない単位を計測する 更新日 September 2, 2026 · 初回公開 September 2, 2026 要約: クラウドFinOpsは可読な単位を前提とします。インスタンス時間、リクエスト、ギガバイト。AIクレジットは違います。ベンダーが定義し値付けし、期中に再定義できる単位です。定石が崩れる三つの性質単位が不透明で、利用者には同じ操作でも消費量が大きく異なります。単価は自社のものではありません。そして枠は共有も繰越もされずに失効します。それでも計測する管理APIから定期的に消費量を取得し、ユーザー・チーム... クラウドFinOpsは可読な単位を前提とします。インスタンス時間、リクエスト、ギガバイト。AIクレジットは違います。ベンダーが定義し値付けし、期中に再定義できる単位です。 定石が崩れる三つの性質 単位が不透明で、利用者には同じ操作でも消費量が大きく異なります。単価は自社のものではありません。そして枠は共有も繰越もされずに失効します。 それでも計測する 管理APIから定期的に消費量を取得し、ユーザー・チーム・機能の軸で自社のコストデータと並べて保存します。ベンダーの画面は当期を示すだけで、必要なのは推移です。 請求前に配賦する クラウドと同じコストセンターに紐づけ、毎月ショーバックを公開します。未配賦の支出はプラットフォーム予算に落ち、消費に最も影響できないチームが負担します。 上限を置き、無理ならアラート ベンダー管理画面の上限設定が、支出発生前に止められる唯一の制御です。無い場合は自社の計測に対して、対処の余地を残した閾値でアラートを設定します。 関連記事 法人カード上のシャドーAI この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # サーバー側ツールはトークン計測の外で課金される · FinOps LLM URL: https://finopsllm.com/ja/research/server-tools-are-a-separate-invoice サーバー側ツールは別の請求書 更新日 September 1, 2026 · 初回公開 September 1, 2026 要約: 多くの LLM 原価モデルには計測器がひとつしかありません。入力トークン、出力トークン、100 万あたりの単価。リクエストがテキストを生成するだけだった頃は正しい考え方でした。サーバー側ツールの登場で、それは成り立たなくなりました。ウェブ検索、ウェブフェッチ、コード実行はプロバイダー側の基盤で動き、いくつかは生成するトークンとは別に利用ごとの料金が発生します。つまりエージェントの 1... 多くの LLM 原価モデルには計測器がひとつしかありません。入力トークン、出力トークン、100 万あたりの単価。リクエストがテキストを生成するだけだった頃は正しい考え方でした。サーバー側ツールの登場で、それは成り立たなくなりました。 ウェブ検索、ウェブフェッチ、コード実行はプロバイダー側の基盤で動き、いくつかは生成するトークンとは別に利用ごとの料金が発生します。つまりエージェントの 1 ターンで二重に課金されうるのです。 積み上がるほうの費用 見落とされるのは二つ目の課金です。ツールの結果は会話に追加され、以降のターンはその全体を入力として再送します。長い実行の序盤での 10 回の検索は、10 回分の料金だけでなく、その結果本体を以降の全ターンで読み直す費用でもあります。 トークンの計算上は線形のはずのエージェント費用が非線形に感じられるのはこのためです。利用料は見える部分にすぎず、より大きいのは文脈の肥大で、それはラベルの無いまま入力トークンの行に着地します。 按分しなければ管理できない リクエストごとに、どのツールを何回呼び、各結果が何トークン増やしたかを usage と並べて記録してください。最後の項目こそが積み上がりを可視化します。 そのうえで、API 呼び出し単位ではなくエージェント実行単位で原価を出します。利用者が起動したのは実行のほうです。 効く対策は 3 つ 実行あたりのツール呼び出しに上限を設ける。 両方の費用を同時に抑えられます。 文脈に入れる内容を削る。 取得したページ全体が必要になることはまれです。 安定した接頭辞をキャッシュする。 システムプロンプトとツール定義は実行中変わりません。 関連記事 プロンプトキャッシュの経済性 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # シャドー AI は誰かの法人カードにある · FinOps LLM URL: https://finopsllm.com/ja/research/shadow-ai-corporate-cards API 請求書の外にある AI 支出を見つける 更新日 September 1, 2026 · 初回公開 September 1, 2026 要約: 多くの組織は、プロバイダのコンソールを開いて AI コストを測ります。その数字は本物で、計測もよくできています — そして多くの会社では、それが合計の「小さいほうの半分」です。もう半分は経費精算の中にあります。ツールが必要で、カードを持っていた人が買った個人サブスクです。なぜプラットフォームチームから見えないのかそれはあなたの API... 多くの組織は、プロバイダのコンソールを開いて AI コストを測ります。その数字は本物で、計測もよくできています — そして多くの会社では、それが合計の「小さいほうの半分」です。もう半分は経費精算の中にあります。ツールが必要で、カードを持っていた人が買った個人サブスクです。 なぜプラットフォームチームから見えないのか それはあなたの API キーにもゲートウェイにもテレメトリにも触れません。法人カードの席単位課金として届き、ソフトウェア費や時には事務費に仕訳され、金額は自動承認を通る程度に小さい。200 人 × 月 20〜30 ドルは年間 6 桁の費目ですが、どんなエンジニアリングのダッシュボードにも決して表示されません。 そしてこれは規則違反の話ではありません。ツールが役に立ち、購買に 6 週間かかるとき、まともに働く社員がやることです。 実際の損失 直接の払い過ぎは最も退屈な部分です。個人プランは同じ製品の交渉済み法人料金よりかなり高く、同じベンダーに二重払い — チーム契約と、散在する個人席 — はよくあります。誰も比較していないので、同じ仕事をする複数のツールが増えます。 厄介なコストは別にあります。コンシューマ版は、法務が実際にレビューした企業契約とはデータ保持や学習利用の条件が異なるため、誰も承認していない条件下に業務データが置かれます。SSO がないので、退職してもアクセスが終わりません。そして見えない支出は、予測も、ボリューム交渉も、内製か購入かの判断もできません。 見つけ方 エンジニアリングではなく経理に聞いてください。カードと経費のデータを、既知のベンダー名で検索し、次にパターンそのもの — ソフトウェア系加盟店への、おおむね 10〜50 ドルの毎月の継続課金 — で検索します。正式にオンボードされていないアプリについては SSO と IdP のログを突き合わせます。 対応は、カードを禁じることではなく、公式の経路をカードより簡単にすることです。速い代替のない取り締まりは、同じ支出をより見えない形で生むだけです。企業条件と SSO を備え、今日から参加できるチームプランは、シャドー支出を交渉済み支出に変え、たいていは席の統合だけで元が取れます。 関連記事 LLM コストの帰属 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # Claude Sonnet 5 値上げ撤回：$2/$10 が恒久価格に · FinOps LLM URL: https://finopsllm.com/ja/research/sonnet-5-intro-pricing-deadline Claude Sonnet 5：9月の値上げは撤回されました 公開日：2026年7月19日 訂正（2026年9月2日）: 本記事が備えていた値上げは実施されませんでした。Anthropicが撤回し、Claude Sonnet 5 は100万トークンあたり$2/$10のまま恒久的に据え置かれます。以下の期限分析は記録として公開時のまま残しています。「9月1日以降」の数値はすべて、実際には発生しなかったシナリオとしてお読みください。現行価格は LLM API価格トラッカー を参照してください。 Anthropicは 2026年6月30日にClaude Sonnet 5をリリース しました。導入価格は$2/1M入力トークン、$10/1M出力トークンです。この価格には 絶対的な締切があります：2026年8月31日 。9月1日から、Sonnet 5は$3/$15/1M標準価格に移行し、 一律50％のコスト増加 となります。Sonnet 5ワークロードを実行している場合、次の6週間はコストを固定し、増加に備える期間です。 導入価格は2026年8月31日までのみ有効 標準価格（$3/$15）は2026年9月1日に開始 Sonnet 5ワークロードのコスト増加は正確に50％ Anthropic API、Bedrock、Vertex AIに適用 再ベンチマーク、コミットメント確保、予測更新まで43日 重要な締切： Claude Sonnet 5の導入価格は43日後（2026年8月31日）に期限切れになります。10M token/月のワークロードは$20から$30/月に移行します。1B token/月のワークロードは$2,000から$3,000に移行します。Sonnet 5がクリティカルパスにある場合、今すぐ値上げを予算化するか、切り替え前にワークロードをシフトしてください。 数学：50％がスケールで何を意味するか 導入価格から標準価格へのジャンプはシンプルで大きなものです。現実的なワークロードをモデル化してみましょう： ワークロードプロファイル 月間入力トークン 月間出力トークン 8月コスト（導入） 9月コスト（標準） 月間差分 年間影響 ライト（バッチ/内部） 50M 20M $200 $300 +$100 +$1,200 ミッドティア（顧客向け） 500M 150M $2,500 $3,750 +$1,250 +$15,000 エンタープライズ（高ボリューム推論） 2B 800M $12,000 $18,000 +$6,000 +$72,000 ヘビー（マルチリクエストフロー） 5B 2.5B $35,000 $52,500 +$17,500 +$210,000 重要な洞察： ミッドティアSonnet 5ワークロード（500M入力+150M出力token/月）を持つ企業は、変更がない場合月$1,250の増加が見られ、年間$15,000に積み重なります。エンタープライズワークロードの場合、年間影響は$70K超になる可能性があります。 誰が影響を受けるか 締切はすべてのチャネルに適用されます： Anthropic API（ダイレクト） 導入価格は2026年8月31日午後11時59分UTCに終了します。 Anthropicの価格ドキュメント で検証されています。延長や遅延は発表されていません。 AWS Bedrock BedrockはAnthropicの価格をパススルーします。導入価格は8月31日までBedrockのSonnet 5に適用されます。値上げはあなたのBedrock請求書に9月1日に表示されます。AWS契約の任意のコミットメント割引が増加をオフセットできるか確認してください。 Google Vertex AI Vertex AIはClaudeモデルをAnthropicの価格パススルーで統合しています。トランジションは9月1日に発生します。Vertex請求書はローカル通貨で見積もられます。異なるタイムゾーンを使用している場合は、正確な日付についてGoogleアカウントチームに確認してください。 GitHub Copilot Enterprise CopilotがバックエンドとしてSonnet 5を使用する場合、Microsoftは価格増加を計画に転送する場合と転送しない場合があります。Copilot Enterpriseは固定シートライセンスであるため、影響はMicrosoftがバックエンドコストを吸収するか反映するかに依存します。Copilot請求書を確認するか、Microsoftアカウントチームに連絡してください。 3つの戦略：8月31日までにすべきこと 戦略1：使用コミットメントを確保（利用可能な場合） AnthropicがSonnet 5に対して使用コミットメントまたはボリューム割引を提供しているか確認してください。ボリューム割引または年間前払い契約は実効価格増加を削減する可能性があります。 Anthropicセールス に今すぐ連絡してください。8月31日前に署名されたコミットメントで導入価格を保持する可能性があります。 アクション： Sonnet 5に月$5K以上を費やしている場合、8月15日までにAnthropicセールスにメールしてください。年間コミットメントが導入価格を固定するか、段階化割引を提供するか尋ねてください。コミットメント契約の必要なリードタイムは通常2～3週間です。 戦略2：ルーティングとモデルミックスを再ベンチマーク すべてのワークロードがSonnet 5を必要とするわけではありません。50％の価格ジャンプは、実際にSonnet 5が必要なタスクと安価な代替案にシフトできるタスクを監査する強制関数です。 タスクカテゴリ Sonnet 5入力/$1M 代替モデル 代替入力/$1M 100M Tokenあたりの節約 シフトいつ 分類（厳密なルール） $3（9月1日後） Claude Haiku 4.5 $1.00 $200 精度≥95％ 要約 $3 Gemini 2.5 Flash $0.15 $285 推論不要 マルチターン会話 $3 GPT-5.6 Luna $1.00 $200 品質同等 複雑な推論（Sonnet 5を維持） $3 — — — 代替案なし エージェンティックループ（マルチステップ） $3 Haiku + Sonnet 5ハイブリッド $1.00（Haiku）+ $3（Sonnet 5） シンプルなステップにHaikusを使用して保存 ベンチマークサポート アクション： 今後2週間で、Sonnet 5呼び出しログを取得し、ワークロード別に分類します。Haikuで分類タスクの10％をベンチマーク、Gemini 2.5 FlashでSummarization、GPT-5.6 Lunaでシンプルマルチターンをベンチマークします。品質が同等（またはクローズ）であれば、9月1日前にそのワークロードをシフトして節約を固定してください。 戦略3：プロンプトキャッシングを実装（または展開） プロンプトキャッシングはトークン消費を減らし、導入価格が期限切れになる前の価値を保存する最も直接的な方法です。Sonnet 5へのキャッシュ書き込みは1M tokenあたり$2.50で、入力価格の1.25倍（導入時）。標準では$3.75。キャッシュ読み取りは1M当たり$0.20（導入時の入力価格の0.1倍）。標準では$0.30。 機会： 40％のキャッシュヒット率を持つワークロードは、入力コストで36％節約します。今導入価格でキャッシュインフラストラクチャを固定することは、進行中のヒット率セービングスが相続されることを意味します。9月1日後、同じキャッシュヒットは依然として90％オフですが、割引する基本価格は50％高くなります。 例： Sonnet 5で100M tokens/月をキャッシュされたシステムプロンプト+コンテキスト： 8月（導入）： 書き込みコスト：100M × $2.50/M = $250。月額読取コスト（キャッシュヒットから1Bトークン読み取りと仮定）：1B × $0.20/M = $200。合計：キャッシュで$450/月。 9月（標準）： 書き込みコスト：100M × $3.75/M = $375。月額読取コスト：1B × $0.30/M = $300。合計：$675/月（50％高い）。 今キャッシュを実装して保存： 今から8月31日までに500Mキャッシュ入力tokenを追加し、9月から毎月30キャッシュヒットを累積する場合、累積読取割引を固定します。キャッシュ書き込みコストは数ヶ月間支払う投資です。 アクション： 繰り返されるプロンプトまたはドキュメントコンテキスト（RAGドキュメント、システム指示、ボイラープレート）の上位3つを特定します。Anthropic APIでキャッシングをテストします。ヒット率が≥20％の場合、8月31日前に実装してください。キャッシュ書き込みは、レート値上げが発生する時期を気にしない唯一のコストです。今書き込みコストに投資すると、永遠に固定読取コストリターンを得られます。 タイムライン：6週間のカウントダウン 週1（7月25日までに） 現在のSonnet 5支出を監査します。請求ダッシュボードまたはLLM可観測性プラットフォームから呼び出しログ（モデル、token、ワークロードタイプ）を抽出します。月間実行レートを計算します。変更がない場合のQ4支出をモデル化します。 週2（8月1日までに） 使用コミットメントについてAnthropicセールスに連絡してください。本番トラフィックの10％で代替モデル（Haiku、Luna、Gemini 2.5 Flash）のベンチマーク開始。ルーティングシフト候補の上位3つを特定します。 週3（8月8日までに） ベンチマークを完成させ、ルーティング計画にコミット。シフトが必要な場合、A/Bテストのデプロイを開始します。高ボリュームの繰り返されるコンテキストのプロンプトキャッシュを実装。移行前に≥100Mトークンキャッシュされたターゲット。 週4（8月15日までに） Anthropicとの使用コミットメントをロック（適用可能な場合）。本番へのルーティング変更をデプロイ（低推論タスクを安価なモデルにシフト）。キャッシュインフラが活性化され、15%+のヒット率を確認してください。 週5（8月22日までに） 本番コストと品質メトリクスを監視。必要に応じてルーティングを調整。8月の実行レートに基づいて最終9月コストを予測します。 週6（8月31日までに） すべてのルーティング変更が活性化されていることを確認。9月5日のカレンダーアラートを設定して、請求が予測と一致することを確認します。達成されたコスト影響と節約に関する事後分析を公開します。 比較：9月1日後のSonnet 5対代替案 導入価格の期限切れ後、Sonnet 5は標準価格での他のモデルと比べてどうですか？ モデル プロバイダー 入力$/1M 出力$/1M 典型的なユースケース 9月1日後のSonnet 5対 Claude Sonnet 5（標準） Anthropic $3.00 $15.00 速度と推論のバランス ベースライン GPT-5.6 Terra OpenAI $2.50 $15.00 ミッドティア推論 入力で17％安い GPT-5.6 Luna OpenAI $1.00 $6.00 高速分類、シンプルなタスク 全体的に67％安い Gemini 3.1 Pro Google $2.00 $12.00 エージェンティックループ、ツール使用 入力で33％安い Gemini 2.5 Flash Google $0.15 $0.60 ウルトラファスト、ハイボリューム 95％安い Claude Haiku 4.5 Anthropic $1.00 $5.00 低レイテンシ分類 入力で67％安い DeepSeek V4 Flash DeepSeek $0.14 $0.28 コスト最適化、オープンモデル 95％安い（ただしあまり洗練されていない） 現実： $3/$15のSonnet 5は、ほとんどのタスクにとって最も安いまたは最もコスト効率的なモデルではなくなりました。GPT-5.6 Terraは入力で17％安い。Haikuは分類で67％安い。値上げ後のSonnet 5の価値は、複雑な推論の品質と均衡タスクの速度にあります。コストリーダーシップではありません。その品質を必要としないワークロードは今代替案に移行すべきです。 よくある質問 Q：締切が延長される可能性はありますか？ A：Anthropicは延長を発表していません。 6月30日のローンチ発表 は「2026年8月31日を通じて」と明記しています。絶対日付に備えてください。延長が発表された場合、それはボーナス。締切を最終として扱います。 Q：新しいトークナイザーはトークン数に影響しますか？ A：はい。Sonnet 5は新しいトークナイザーを使用し、同等のテキストに対して古いClaudeモデルの約30％多くのトークンを生成します。これはあなたの実際のtokenコストが期待より高いことを意味します。コスト予測にこれを因子化してください。 Q：年間前払いで導入価格を固定できますか？ A：おそらく、Anthropicが前払いオプションを提供している場合。8月15日前にセールスに連絡して尋ねてください。前払いはしばしば料金値上げを通じて価格を相続する唯一の方法ですが、あなたは事前にコミットする必要があります。 Q：Anthropicとのカスタム契約がある場合は？ A：カスタム契約は異なる条件がある可能性があります。正確な切り替え日とレートをアカウントチームで確認してください。契約が価格設定条項を指定する場合、公開価格ページよりも優先されます：9月1日があなたを驚かせる前に今確認してください。 8月31日の締切は現実、50％の値上げは確実、あなたは行動する6週間があります。切り替え前に再ベンチマーク、コミットメント確保、ワークロード移行をするチームはQ4 LLM支出を大幅に削減します。9月1日まで待つチームは完全なコスト増加を吸収します。 リサーチに戻る FAQ Claude Sonnet 5の導入価格は2026年8月31日に終了しましたか？ いいえ。Anthropicは予定していた値上げを撤回しました。Claude Sonnet 5は入力100万トークンあたり$2、出力100万トークンあたり$10のまま恒久的に据え置かれます。2026年9月1日に予定されていた$3/$15の標準料金は適用されませんでした。 請求額はどのくらい増加しますか？ Claude Sonnet 5ワークロードの場合、正確に50％です。入力価格は1M tokenあたり$2から$3に上昇（+50％）。出力は1M tokenあたり$10から$15に上昇（+50％）。8月に$10,000/月のコストがかかるワークロードは、変更がない場合9月に$15,000/月になります。 BedrockとVertexにも導入価格は適用されますか？ 導入価格はAnthropicダイレクトAPIに適用されます。AWS BedrockとGoogle Vertex AIはAnthropicの価格をパススルーするため、9月1日に同じ値上げが適用されます。クラウドプロバイダーの契約条件を確認してください。 8月31日までに何をすべきですか？ 1) 使用コミットメントが利用可能な場合は確保します。2) Sonnet 5を安価なモデル（Haiku、Gemini 2.5 Flash）と比較し直します。3) 繰り返されるプロンプトをプロンプトキャッシングに移行します（キャッシュ割引は基本価格と共にスケールするため、今キャッシュセービングスを固定することは価値があります）。4) 8月25日のカレンダーアラートを設定して、移行後のコストをテストします。5) Q3予算の値上げをモデル化します。 --- # 無料の匿名モデルは価格戦略の武器である · FinOps LLM URL: https://finopsllm.com/ja/research/stealth-model-free-tokens-playbook ステルスモデルの手口 更新日 September 1, 2026 · 初回公開 September 1, 2026 要約: Ox Alpha はルーティング集約サービスに、ブランド名も価格表も提供元も伴わない無料エンドポイントとして現れました。その後 GLM-5.3 だと確認され、無料期間は終了しました。GLM-5.3-Flash の価格は入力 100 万トークンあたり 0.15 ドル、出力 0.50... Ox Alpha はルーティング集約サービスに、ブランド名も価格表も提供元も伴わない無料エンドポイントとして現れました。その後 GLM-5.3 だと確認され、無料期間は終了しました。GLM-5.3-Flash の価格は入力 100 万トークンあたり 0.15 ドル、出力 0.50 ドルです。 これは繰り返される手口だと考えてください。別の名前で何度も行われてきましたし、また行われます。 無料トークンで研究所が買うもの 3 つあり、いずれも代替手段より安上がりです。 ブラインド評価 : 無名のエンドポイントはロゴではなく出力で判断されます。 流通 : 集約サービスが提携なしで即座に実トラフィックを流します。 価格のアンカー : 名前が明かされる頃には、開発者はすでにこのモデルは良いと判断し終えています。 期間終了時に効いてくる数字 無料エンドポイントを通過した入力トークンは 16 兆。100 万あたり 0.15 ドルなら約 240 万ドル分の推論です。そのトラフィックがそのまま残った場合の増加幅がこれにあたります。 自社分でも同じ計算をしてください。無料期間中に送った量に公表価格を掛ければ、月額の段差が出ます。 次回のための 3 つの原則 提供元が分からないエンドポイントに依存しないこと。 匿名とは、価格表も廃止方針もデータ取扱いの約束も無いという意味です。評価には十分ですが、代替経路のない本番には向きません。 無料の評価にも仮の単価を付け 、その影のコストを自社のテレメトリーに載せておきます。そうすれば正体判明は再価格付けであって、発見ではなくなります。 無料期間は関係のうち最も短い部分だと前提すること。 品質だけでなく乗り換えコストも測ってください。 関連記事 プロバイダー間のアービトラージ この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # 中断されたストリーミング出力も課金対象になる · FinOps LLM URL: https://finopsllm.com/ja/research/streaming-abandoned-generations-cost ストリーミング応答と放棄された生成コスト 更新日 September 9, 2026 · 初回公開 September 9, 2026 要約: ブラウザのタブを閉じても、プロバイダ側では指定のトークン上限までテキスト生成が継続することがあります。AbortControllerによる即時中断が必須です。 ブラウザのタブを閉じても、プロバイダ側では指定のトークン上限までテキスト生成が継続することがあります。AbortControllerによる即時中断が必須です。 関連記事 リトライループに潜む隠れコスト この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # 構造化出力はタダではない · FinOps LLM URL: https://finopsllm.com/ja/research/structured-output-token-cost JSON モードとスキーマのトークンコスト 更新日 September 1, 2026 · 初回公開 September 1, 2026 要約: 構造化出力はフォーマットの選択に見えますが、請求書の上では分量の選択であり、同時に 3 か所に現れます。スキーマは毎リクエストの入力コストスキーマはリクエストに直列化されます。控えめなスキーマでも数百トークンあり、それを全呼び出し・全ターン・機能の寿命ぶん掛け合わせます。400 トークン × 100 万回 = 4... 構造化出力はフォーマットの選択に見えますが、請求書の上では分量の選択であり、同時に 3 か所に現れます。 スキーマは毎リクエストの入力コスト スキーマはリクエストに直列化されます。控えめなスキーマでも数百トークンあり、それを全呼び出し・全ターン・機能の寿命ぶん掛け合わせます。400 トークン × 100 万回 = 4 億入力トークンを、決して変わらない「形」の説明に払っていることになります。 さらに悪いのは、スキーマをプロンプトの可変部分の 後ろ に置いた場合です。キャッシュされたプレフィックスが壊れ、その前のすべての割引まで消えます。 構文は出力コスト 波括弧、引用符、カンマ、フィールド名はすべて生成トークンで、出力単価で課金されます。冗長なフィールド名は恒久的な継続課金です。 高いのはリトライ 検証失敗のたびに完全なリトライが発生し、入力も出力も丸ごと再課金されます。不正率 2% は、見返りのない 2% のコスト増です。 実際にやること スキーマは安定プレフィックスに置いてキャッシュさせる。実際に使うフィールドだけ要求する。短いフィールド名と浅い構造にする。単一の値ならオブジェクトで包まない。そして検証失敗率を計測する — そこだけは純粋な無駄です。 関連記事 プロンプトキャッシュの経済学 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # サブエージェントの拡散とトークン浪費を防ぐ · FinOps LLM URL: https://finopsllm.com/ja/research/subagent-fan-out-concurrency-limits 自律型マルチエージェントの拡散と再帰的委譲に伴うトークン急増の抑止 更新日 September 19, 2026 · 初回公開 September 19, 2026 要約: サブエージェントの拡散カスケードは、オーケストレーターがタスクを並列分解し、ワーカーにさらなる子エージェント生成を許可した際に発生します。並行実行数と階層の制限がない場合、1回の曖昧なプロンプトから数分間で数百から数千万トークンが浪費され、予期せぬAPI請求急増を引き起こします。自律型AIにおけるサブエージェントの拡散カスケードとは？上位の司令塔エージェントが全体予算の制限なく子・孫エージェントを... サブエージェントの拡散カスケードは、オーケストレーターがタスクを並列分解し、ワーカーにさらなる子エージェント生成を許可した際に発生します。並行実行数と階層の制限がない場合、1回の曖昧なプロンプトから数分間で数百から数千万トークンが浪費され、予期せぬAPI請求急増を引き起こします。 自律型AIにおけるサブエージェントの拡散カスケードとは？ 上位の司令塔エージェントが全体予算の制限なく子・孫エージェントを再帰的に生成し、並列処理全体でトークン消費が指数関数的に激増する不具合パターンです。 実運用で必須となる4つのガードレール 最大再帰深度を2階層（統括役から実行役まで）に制限すること、スレッド共通のトークンプールを設けて残量をコンテキスト経由で減算すること、および並行起動数を最大3〜5プロセスに抑えるサーキットブレーカーの導入が必須です。 関連記事 エージェント運用の3つの予算枠 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # 自律エージェントに必要な3つの予算 · FinOps LLM URL: https://finopsllm.com/ja/research/three-agent-budgets 自律エージェントに必要な3つの予算 更新日 August 27, 2026 · 初回公開 August 27, 2026 要約: 自律エージェントには、ループ内で強制する3つの予算が必要です。1回のリクエスト、1つのワークフロー、そして日次の予算です。リクエスト予算1回の試行のトークン、ツール、時間、金額を制限し、プロバイダーとツールの呼び出し前に適用します。ワークフロー予算再試行、フォールバック、サブエージェントを含むタスク全体を追跡します。相関ID付きの台帳で収束しないループを止めます。日次予算チーム、テナント、機能の合... 自律エージェントには、ループ内で強制する3つの予算が必要です。1回の リクエスト 、1つの ワークフロー 、そして 日次 の予算です。 リクエスト予算 1回の試行のトークン、ツール、時間、金額を制限し、プロバイダーとツールの呼び出し前に適用します。 ワークフロー予算 再試行、フォールバック、サブエージェントを含むタスク全体を追跡します。相関ID付きの台帳で収束しないループを止めます。 日次予算 チーム、テナント、機能の合計支出を制限します。上限に近づけば安価なモデルやバッチへ振り分けます。 拒否を記録する 発動した予算、消費額、回復方法を示し、予約、支出、拒否を請求と照合できるイベントとして記録します。 関連記事 エージェント支出のガードレール この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # トークン予算実装ガイド · FinOps LLM URL: https://finopsllm.com/ja/research/token-budget-implementation-guide トークン予算実装ガイド トークン予算はLLMコスト制御の運用レイヤーです。属性付けはお金の行き先を示しますが、予算は望まない場所に流れるのを防ぎます。予算がなければ、設定ミスのあるエージェントループやユーザートラフィックの急増が数時間で月間配分を使い切ってしまう可能性があります。このガイドでは、4種類のトークン予算を本番環境で実装する方法を、各パターンの疑似コード付きで説明します。 予算タイプ 予算タイプ 粒度 適用方法 ユースケース リクエストごと 単一のAPI呼び出し max_tokensパラメーターによるハードリミット 暴走する補完の防止、レイテンシの制限 チームごとの割り当て 期間内のチームまたはプロジェクト アラート付きソフトリミット、しきい値でのハードリミット 部門別コスト配分、1チームが共有予算を消費するのを防ぐ 期間ごと 日次、週次、月次 グレースピリオド付きハードリミット 月間予算上限、スプリントレベルの支出 ワークフローごと 単一のパイプラインまたはエージェント実行 ステップごとおよび合計のハードリミット マルチステップエージェント、RAGパイプライン、評価実行 リクエストごとの制限 最もシンプルな予算：すべてのリクエストを max_tokens で制限します。これはオプションではありません - 本番のすべてのリクエストには明示的な出力トークン制限が必要です。これがないと、冗長なモデル応答が予期しないトークンを消費し、レイテンシを膨らませる可能性があります。 // リクエストごとの予算適用 function callLLM(prompt, config): response = provider.complete( prompt: prompt, model: config.model, max_tokens: config.max_output_tokens, // ハードキャップ temperature: config.temperature ) if response.usage.total_tokens > config.warn_threshold: log.warn("リクエストがソフトリミットを超過", tokens: response.usage.total_tokens, threshold: config.warn_threshold ) return response チームごとの割り当て チーム割り当てには、リクエスト間で持続する共有カウンターが必要です。パターン：各呼び出し前に残り予算をチェックし、予算が尽きた場合は拒否またはダウングレードします。 // Redis バックエンドのカウンターによるチーム割り当て function checkTeamBudget(teamId, estimatedTokens): key = "budget:" + teamId + ":" + currentPeriod() remaining = redis.get(key) or getTeamQuota(teamId) if remaining < estimatedTokens: if remaining < estimatedTokens * 0.1: return DENY // ハードリミット：リクエストを拒否 else: return DOWNGRADE // ソフトリミット：安価なモデルを使用 return ALLOW function recordUsage(teamId, actualTokens): key = "budget:" + teamId + ":" + currentPeriod() redis.decrby(key, actualTokens) remaining = redis.get(key) if remaining < getTeamQuota(teamId) * 0.2: alert.quotaLow(teamId, remaining) 期間ごとの予算 期間ごとの予算はチーム割り当てを時間ウィンドウでラップします。重要な違い：グレースピリオドメカニズムが必要です。チームが月間予算の80%に達した場合、アラートを送信します。100%では、構成可能なグレースピリオド（例：24時間）を許可してからハード適用が開始されます。これにより、月末にチームがタスク途中でブロックされるのを防ぎます。 // グレースピリオド付き期間予算 function enforceBudget(teamId): usage = getUsageForPeriod(teamId, currentMonth()) limit = getTeamMonthlyLimit(teamId) if usage < limit * 0.8: return ALLOW if usage < limit * 1.0: alert.budgetWarning(teamId, usage, limit) return ALLOW // ソフト警告ゾーン if usage < limit * 1.1 and withinGracePeriod(teamId): alert.budgetExceeded(teamId, usage, limit) return ALLOW // グレースピリオド：超過を許可 return DENY // ハードストップ ワークフローごとの予算 マルチステップエージェントとパイプラインには2つのレベルの予算が必要です：ステップごと（単一ステップが消費しすぎるのを防止）と実行ごと（パイプライン全体が割り当てを超過するのを防止）。ワークフローコンテキストの両方を追跡します。 // ワークフロー予算トラッカー class WorkflowBudget: constructor(maxPerStep, maxTotal): this.maxPerStep = maxPerStep this.maxTotal = maxTotal this.spent = 0 function callStep(stepFn, prompt): if this.spent >= this.maxTotal: return fallbackResponse("予算超過") response = callLLM(prompt, { max_tokens: min(this.maxPerStep, this.maxTotal - this.spent) }) this.spent += response.usage.total_tokens return response 予算超過時のグレースフルデグラデーション 予算に達したときにエラーを返すだけにしてはいけません。グレースフルにデグレードします。安価なモデルに切り替える（GPT-4oの代わりにGPT-4o-mini）、コンテキストウィンドウサイズを縮小する、オプションの処理ステップをスキップする、または完全な処理には予算承認が必要であるというメモ付きで部分的な結果を返します。ユーザーエクスペリエンスは壊れるのではなく、低下すべきです。 // デグラデーションチェーン function callWithDegradation(prompt, config): if checkBudget(config.teamId, FULL_MODEL): return callLLM(prompt, { model: config.primaryModel }) if checkBudget(config.teamId, CHEAP_MODEL): log.info("予算のためモデルをダウングレード") return callLLM(prompt, { model: config.fallbackModel }) if checkBudget(config.teamId, MINIMAL_TOKENS): truncated = truncateContext(prompt, 50%) return callLLM(truncated, { model: config.fallbackModel, max_tokens: 256 }) return cachedOrFallback(prompt) 予算の健全性監視 3つの指標を追跡します：バーンレート（1時間あたりの消費トークン 対 予算）、予測（現在のレートで予算がいつ枯渇するか）、オーバーライド回数（グレースピリオドが何回使用されたか）。グレースピリオドの使用が総リクエストの10%を超える場合、予算がワークロードに対して低すぎます。 関連項目 LLM予算ガバナンス - 予算背后的組織ポリシー。 エージェント支出ガードレール - 自律エージェントの予算パターン。 推論コストの上限設定方法 - プロバイダー側のコスト制御。 これをご自身のLLM支出に適用しませんか？FinOps LLMはAIコストの無料監査を実行し、削減のポイントを示します。 無料監査を予約 → リサーチに戻る --- # トークン価格は下がったのに、LLMの請求額が増えた理由 · FinOps LLM URL: https://finopsllm.com/ja/research/token-prices-bill-keeps-rising トークン価格は下がったのに、LLMの請求額が増えた理由 更新日 August 27, 2026 · 初回公開 August 27, 2026 要約: トークン単価が下がっても、請求額が下がるとは限りません。本番では、長いコンテキスト、エージェントのステップ数、出力、リトライの増加が値下げを上回ります。料金、量、モデル構成、効率の4つに分けて確認します。単価は一要素にすぎない100百万トークンが220百万に増え、単価が10ドルから6ドルになった場合、請求額は1,000ドルから1,320ドルになります。モデルと入力・出力・キャッシュ・推論トークン別... トークン単価が下がっても、請求額が下がるとは限りません。本番では、長いコンテキスト、エージェントのステップ数、出力、リトライの増加が値下げを上回ります。料金、量、モデル構成、効率の4つに分けて確認します。 単価は一要素にすぎない 100百万トークンが220百万に増え、単価が10ドルから6ドルになった場合、請求額は1,000ドルから1,320ドルになります。モデルと入力・出力・キャッシュ・推論トークン別に、実際の請求単価を記録してください。 4つの差分を計測する 量は使用トークン数、構成は高価なモデルへの移行、効率は成功したタスク1件のコストです。リトライ、失敗したツール、長すぎるプロンプト、使われない出力も効率に含めます。各呼び出しをプロバイダー請求と照合します。 週次レビュー 前月からの差分を料金、量、構成、効率に分解し、トラフィック調整済みの成功タスク単価を監視します。最もドル影響が大きい分類から直します。 関連記事 LLMコスト監視 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # 冗長なプロンプトには税がかかる · FinOps LLM URL: https://finopsllm.com/ja/research/verbose-prompt-tax プロンプトの書き方が請求書に出る仕組み 更新日 September 1, 2026 · 初回公開 September 1, 2026 要約: プロンプトは設定ファイルと同じように太ります。誰かが不具合対策の指示を足し、別の誰かが例を足し、三人目がその理由を説明する段落を足す。何も削られません — 削ると誰も再現できないバグが戻るかもしれないからです。半年後、システムプロンプトは 3,000 トークンになり、そのうちどの 200... プロンプトは設定ファイルと同じように太ります。誰かが不具合対策の指示を足し、別の誰かが例を足し、三人目がその理由を説明する段落を足す。何も削られません — 削ると誰も再現できないバグが戻るかもしれないからです。半年後、システムプロンプトは 3,000 トークンになり、そのうちどの 200 トークンが効いているのか誰も言えません。 なぜ積み上がるのか タスクごとに変動する出力と違い、プロンプトのオーバーヘッドは 毎リクエスト 、同じ量だけ、永久に支払われます。月 1,000 万回の機能で 1,000 トークンの無駄は、月 100 億トークンの純粋な書式代です。 マルチターンではさらに悪化します。システムプロンプトは毎ターン再送されるので、コストはリクエスト数ではなくターン数に比例します。エージェントループでは、1 回のユーザー操作で十数回の呼び出しが走り、同じ肥大した前置きが十数回課金されます。 本当に無駄なもの 丁寧語ではありません。重いのは、同じ規則を三通りに言い換えた 重複指示 、もう必要のない世代向けに書かれた 防御的な定型文 、異なるケースを覆わず 重複しているだけの例示 、そしてモデルではなく ファイルを読む人間に向けた説明 です。 実務では三つ目が最大です。few-shot はトークン単価が高く、5 件が 2 件で足りるかを見直すチームは多くありません。 予算のあるコードとして扱う 固定プロンプトが平均リクエストに占める割合を測ってください。半分を超えるならスタイルではなくコストの問題です。安定部分を先頭に置けばキャッシュが効き、残りの肥大も安くなります。そのうえでアブレーション — 1 ブロック削って評価を回し、品質が保てれば削除を残す。評価基盤なしの削減は当て推量で、顧客が見つける品質劣化は節約したトークンより高くつきます。 関連記事 プロンプトキャッシュの経済学 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # 音声エージェントは分単位で課金される · FinOps LLM URL: https://finopsllm.com/ja/research/voice-agents-bill-per-minute リアルタイム音声 API のユニットエコノミクス 更新日 September 1, 2026 · 初回公開 September 1, 2026 要約: テキスト LLM 向けに作ったコストモデルは、音声で必ず壊れます。テキストはトークン課金で、トークンは情報量に比例します。音声は時間課金で、時間に比例します — 有用なことが何も起きていない時間も含めて。実際に何に払っているのか音声の 1 往復には通常 3〜4 種類の課金が積み上がります。入力音声の音声認識。モデル呼び出しそのもの（リアルタイム音声 API... テキスト LLM 向けに作ったコストモデルは、音声で必ず壊れます。テキストはトークン課金で、トークンは情報量に比例します。音声は時間課金で、 時間 に比例します — 有用なことが何も起きていない時間も含めて。 実際に何に払っているのか 音声の 1 往復には通常 3〜4 種類の課金が積み上がります。入力音声の音声認識。モデル呼び出しそのもの（リアルタイム音声 API ではトークンではなく入出力音声の分単位）。エンドツーエンドでなければ戻りの音声合成。そしてしばしば、セッションを開いたままにしていること自体への課金です。 最後のものが罠です。利用者が考えている間、画面を読んでいる間、席を外している間も、セッションはセッションです。分単位のメーターでは、無音も定価の商品です。 見積もりがずれる理由 「発話時間 × 単価」で計算すると実績を大きく下回ります。抜けているのは 4 つ。課金されるのにモデル化されない 待ち時間と間 。発信者が聞いていないのに生成して支払った 割り込み分の音声 。やり取り全体を再生する リトライ （音声のリトライはトークンだけでなく音声を繰り返すためテキストよりはるかに高い）。そして切断までの全時間を払って何も生まない 放棄された通話 です。 機能する指標 分あたりコストではなく、完了会話あたりコストです。分単価はメーターであって事業価値の単位ではありません。モデル改善で通話が短くなる変更は、分単価を上げつつ「答えに到達させるコスト」を下げることがあります。 そのうえで誰も見ていない部分を計測してください — セッション時間の中央値と p95、課金時間と発話時間の比、放棄率、放棄セッションのコスト比率。アイドルセッションは積極的に切ること。音声スタックでは通常これが最大の削減余地です。バージイン対応は UX 機能であると同時にコスト機能でもあります。利用者が被せて話した 1 秒は、生成に金を払った 1 秒だからです。 関連記事 エージェントの経済学 この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # DeepSeek Harnessとは？導入と仕組みの完全ガイド · FinOps LLM URL: https://finopsllm.com/ja/research/what-is-deepseek-harness DeepSeek Harnessとは？導入と仕組みの完全ガイド 更新日 August 16, 2026 · 初回公開 August 16, 2026 要約: DeepSeek Harness（パッケージ名 dsh）は、DeepSeek AI が MIT ライセンスで公開したオープンソースのエージェントハーネスです。本稿は前提知識なしで読める版として、それが何であり、どう動かし、どう組み立てられているか、そして気にかける価値があるかを扱います。 エージェントハーネスとは何か... DeepSeek Harness （パッケージ名 dsh ）は、DeepSeek AI が MIT ライセンスで公開したオープンソースのエージェントハーネスです。本稿は前提知識なしで読める版として、それが何であり、どう動かし、どう組み立てられているか、そして気にかける価値があるかを扱います。 エージェントハーネスとは何か モデルが行うのはテキストとツール呼び出しの生成だけです。エージェントを有用にしているそれ以外のすべて——プロンプトの組み立て、要求されたツールの実際の実行、許可範囲の強制、発生した事象の記録、モデルを再度呼ぶか判断するループ、子エージェントへの委譲——はハーネスの領分です。 この区別は何より先に腹落ちさせる価値があります。エージェントの出来不出来の大半は、モデルの挙動ではなくハーネスの挙動だからです。同一のモデルを動かす二つのチームがまるで違う結果とまるで違う請求額を得るとき、その差はここに宿ります。 DeepSeek Harness が担うこと コーディングと自動化のエージェントを実行します。実務上、エージェントはファイルを読み書きし、シェルコマンドを実行し、コードベースを検索し、サブエージェントへ委譲し、作業を計画し、有効な権限ポリシーに従って確認を求めます。ブラウザ UI、単発実行向けのヘッドレスモード、標準入出力で JSON-RPC を話す自動化サーバーが用意されています。 設計上の唯一の要点：すべてがプラグイン 本ハーネスは Cordis というプラグインランタイム上で動きます。プラグインは共有コンテキストへサービス、型付きイベント、可逆な効果を提供します。特権的なコアは存在しません。モデルアダプタもプラグイン、ツールレジストリもプラグイン、セッションログもプラグイン、エージェントループ自体もプラグインです。 多くの拡張可能なシステムは固定コアとフックの組み合わせを提供します。観察と装飾はできても差し替えはできず、差し替えるにはフォークが必要です。プラグインランタイムはこれを反転させ、最も差し替えたい部分をそのまま合成の単位にします。 起動する 最短経路 npx @deepseek-ai/dsh web http://127.0.0.1:3080 でローカルの Web UI が立ち上がります。 ソースから git clone https://github.com/deepseek-ai/deepseek-harness cd deepseek-harness pnpm install pnpm run build pnpm dsh web 要件は Node 22.19 以降（CI は 22.19、24、26 を対象）、Git 2.26 以降、Corepack で固定した pnpm です。DeepSeek の API キーはインストール時には任意ですが、実用には必要です。環境変数からでも、リポジトリ直下の gitignore された .env からでも読み込めます。 見落とされがちな二つの手順 Settings → Models。 API キーを入力します。再起動不要で即座に有効化されます。 ワークスペースの選択。 プロジェクトのディレクトリを追加して有効化します。ワークスペースが有効になるまでセッションのコンポーザーは使えません。新規インストールが壊れて見える原因はたいていこれです。 ヘッドレス pnpm dsh --profile headless "summarize this workspace" 自動化で効いてくるのはこのモードです。対話でしか動かないハーネスは CI に載せられず、CI に載らないものは定期的に計測できません。 ドキュメントを読むための語彙 用語 意味 ステップ 1 回のモデル要求と、そこから生じるツール呼び出し ターン 入力を消化しきる単位。モデルが停止するかポリシーが介入すると終了 ラウンド ターンの上位にある外側のポリシー反復。目標への再挑戦など セッション 型付きイベントの追記専用ログ。実行に関する唯一の真実の source ケイパビリティシーム 複数の実装を差し替えられるサービスインターフェース プロファイル 名前付きの構成。プラグインバンドルの順序付きリストとユーザーのパッチ スコープ ツール、プロンプト、制限をエージェント単位で登録する単位 設定は四層で解決され、後のものが勝ちます。プロファイルのバンドル、プロファイルのパッチ、home レベルのパッチ、コマンドラインのオーバーレイの順です。この順序を知っていれば、「なぜそのモデルが使われているのか」は調査ではなく参照で済みます。 見るに値する理由 モデルを差し替えられる。 モデルサービスは複数のバックエンドを備えたインターフェースで、そのひとつは記録済みセッションを再生し、推論費用を再び支払いません。エージェントループはベンダー中立なストリームを消費し、どのバックエンドが動いているかを知りません。 記録が構造的に完全。 指針は「モデルから見えるものは記録される」です。ログが実行を再構成できねばならないからです。トークン使用量は、それを生じさせた出力に付随して運ばれます。 強制点が明示されている。 モデル要求の送出前に一つ、その判断は権威あるものとして文書化されています。もう一つは任意のツール本体の実行前です。権限ガードは拒否か棄権はできても許可はできず、応答不能な承認要求は拒否になります。 ヘッドレスで動く。 つまりスクリプト化でき、スケジュールでき、計測できます。 プラグインという主張は位置づけだけの話ではありません。同梱デモのひとつは自己言及的で、稼働中の自身のプラグインランタイムを検査し変更します。これは偽装の難しい種類の証拠です。 使うべき場面、使うべきでない場面 使うべき なのは、評価、試作、そしてすでに運用しているエージェント基盤に対する具体的な基準として用いる場合です。自社システムに持ち帰るべき五つの問いは、モデルを差し替えられるか、使用量が付随した完全なセッション記録があるか、モデル呼び出し前とツール実行前に強制点があるか、ヘッドレスで動くか、設定の階層は文書化されているか、です。 今四半期に標準化すべきではありません。 本プロジェクトは自らを developer preview と称し、互換性を壊す変更があると明言しています。ビルド対象のバージョンは固定し、プレビュー API の上に本番移行を計画しないでください。 運用費用 ハーネス自体は MIT ライセンスで無料です。推論はそうではありません。DeepSeek の API キーを用意するか、モデルシームを別のプロバイダーへ向けます。実務上の含意は、請求額がターンあたりのステップ数、カタログ内のツール数、委譲の深さ、そして終わりの定まらない目標が回せるラウンド数の関数になるということです。いずれもハーネス層の判断であり、交渉したトークン単価ではありません。 関連記事 インストール、プロファイル、初回実行（英語） 「すべてがプラグイン」が実際にもたらすもの（英語） コスト記録としてのセッションログ（英語） 支出ガードレールを置く場所（英語） この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 → finopsllm.com に戻る --- # 에이전트 웹 검색은 새로운 비용 센터가 된다 · FinOps LLM URL: https://finopsllm.com/ko/research/agent-web-search-cost-center 에이전트 웹 검색과 비용 센터 관리 업데이트 September 10, 2026 · 최초 게시 September 10, 2026 핵심 답변: 정적 지식에서 실시간 웹 검색으로 전환되면서 단일 프롬프트가 다수의 유료 검색과 모델 호출을 유발합니다. 검색 비용을 토큰과 함께 추적해야 합니다. 정적 지식에서 실시간 웹 검색으로 전환되면서 단일 프롬프트가 다수의 유료 검색과 모델 호출을 유발합니다. 검색 비용을 토큰과 함께 추적해야 합니다. 관련 글 성공 작업당 비용 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # AI 기능의 매출총이익률은 출시 전에 측정한다 · FinOps LLM URL: https://finopsllm.com/ko/research/ai-feature-gross-margin AI 기능의 매출총이익률은 출시 전에 측정한다 업데이트 September 2, 2026 · 최초 게시 September 2, 2026 핵심 답변: 추론은 개발비가 아니라 서비스 제공 원가입니다. 고객의 모든 작업마다 실행되며 사용량에 비례하여 증가합니다. 출시 직전까지 이를 R&D로 취급하면 첫 번째 청구서가 도착한 후에야 마진 실패를 깨닫게 됩니다.출시 전에 계측하라스테이징 환경에서 각 모델 호출에 계정, 워크플로우, 결과 태그를 지정하고 실제 트래픽을 재생합니다. p50, p90, p99... 추론은 개발비가 아니라 서비스 제공 원가입니다. 고객의 모든 작업마다 실행되며 사용량에 비례하여 증가합니다. 출시 직전까지 이를 R&D로 취급하면 첫 번째 청구서가 도착한 후에야 마진 실패를 깨닫게 됩니다. 출시 전에 계측하라 스테이징 환경에서 각 모델 호출에 계정, 워크플로우, 결과 태그를 지정하고 실제 트래픽을 재생합니다. p50, p90, p99 백분위수별 성공 작업당 비용과 실패/재시도 비율을 측정해야 합니다. 계정당 비용으로 집계 성공 작업당 비용에 예상 월간 작업 수를 곱하고 유료 실패 비용을 합산하여 요금제 가격과 비교합니다. 정액 요금제는 헤비 유저 구간에서 마진 붕괴가 발생합니다. 4대 비용 요인 매 턴 재전송되는 긴 컨텍스트, 전액 청구되는 재시도, 에이전트 다중 분기, 비효율적인 모델 기본 라우팅을 점검해야 합니다. 관련 글 성공 작업당 비용 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # AI 지출 편차 분석: 수량, 단가, 믹스, 효율성 · FinOps LLM URL: https://finopsllm.com/ko/research/ai-spend-variance-bridge AI 지출 편차 분석: 수량, 단가, 믹스, 효율성 브릿지 업데이트 August 27, 2026 · 최초 게시 August 27, 2026 핵심 답변: AI 지출 편차 분석은 구체적인 엔지니어링 행동으로 이어질 때만 의미가 있습니다. 예측과 실제 청구액 간의 차이를 수량, 단가, 믹스, 효율성의 4대 원인으로 분해하고 인보이스 및 오너십과 연결하십시오.4대 핵심 원인수량은 토큰 및 요청 수요입니다. 단가는 약정과 크레딧이 적용된 실효 단가입니다. 믹스는 추론 모델 티어, 프로바이더, 리전 간의 사용... AI 지출 편차 분석은 구체적인 엔지니어링 행동으로 이어질 때만 의미가 있습니다. 예측과 실제 청구액 간의 차이를 수량 , 단가 , 믹스 , 효율성 의 4대 원인으로 분해하고 인보이스 및 오너십과 연결하십시오. 4대 핵심 원인 수량은 토큰 및 요청 수요입니다. 단가는 약정과 크레딧이 적용된 실효 단가입니다. 믹스는 추론 모델 티어, 프로바이더, 리전 간의 사용 이동입니다. 효율성은 프롬프트 팽창, 재시도, 툴 실패, 인간 개입을 반영한 성과당 유효 비용입니다. 운영 브릿지 구축 기존 예측에서 출발하여 단가, 수량, 믹스, 효율성을 순차적으로 적용하고 잔여 오차를 검증합니다. 각 항목별로 기술적 증거, 금액 영향, 책임자, 후속 라우팅 조정 조치를 확정하십시오. 관련 글 LLM 비용 모니터링 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # Azure OpenAI 대 직접 OpenAI 비용 비교 분석 · FinOps LLM URL: https://finopsllm.com/ko/research/azure-openai-vs-direct-cost Azure OpenAI 대 직접 OpenAI 비용 비교: PTU 예약 및 손익분기점 업데이트 September 19, 2026 · 최초 게시 July 12, 2026 핵심 답변: 글로벌 종량제(Pay-as-you-go) 기준에서 Azure OpenAI와 OpenAI 직접 API의 공시 단가는 정확히 일치합니다(예: GPT 플래그십 모델 기준 입력 100만 토큰당 2.50달러, 출력 15달러). 기업 청구서에서 발생하는 실질적인 비용 차이는 기본 토큰 가격이 아니라 PTU(프로비전된 처리량 단위) 예약, 데이터 주권 리전 할증,... 글로벌 종량제(Pay-as-you-go) 기준에서 Azure OpenAI와 OpenAI 직접 API의 공시 단가는 정확히 일치합니다(예: GPT 플래그십 모델 기준 입력 100만 토큰당 2.50달러, 출력 15달러). 기업 청구서에서 발생하는 실질적인 비용 차이는 기본 토큰 가격이 아니라 PTU(프로비전된 처리량 단위) 예약 , 데이터 주권 리전 할증 , 그리고 Microsoft EA(Enterprise Agreement) 약정 할인 이라는 세 가지 구조적 요인에서 비롯됩니다. 1. PTU 전용 용량 예약과 종량제 토큰 비교 Azure의 핵심 차별화 요소는 전용 모델 용량을 대여하는 PTU 모델입니다. 온디맨드로 호출 시 PTU당 시간당 2달러이지만, 1개월 약정 예약 시 월 약 260달러 수준으로 인하되어 온디맨드 대비 최대 82%의 비용 절감 (1년 약정 시 최대 85%)을 제공합니다. PTU 예약의 경제적 손익분기점은 24시간 평균 용량 가동률이 약 65~75% 이상 꾸준히 유지될 때 달성됩니다. 야간이나 주말에 트래픽이 급감하는 가변적 워크플로라면 기존 종량제 토큰 결제가 더 경제적입니다. 2. 데이터 주권 및 리전별 할증 요금 글로벌 배포는 미국 OpenAI 본사 가격과 동일하지만, 유럽연합(EU) 내 데이터 보관이나 아시아 태평양 특정 리전을 고정 지정하여 배포할 경우 10%에서 20%의 리전 프리미엄 할증 이 청구됩니다. 데이터 규제 준수 요건과 인프라 비용 간의 균형을 검토해야 합니다. 3. 엔터프라이즈 부가 인프라 비용(TCO) Azure 환경에서는 Private Endpoint 연결 비용, Log Analytics 진단 로깅, VNet 아웃바운드 데이터 전송료가 추가 발생합니다. 이는 실효 토큰 비용을 약 4~8% 증가시키지만, 가상 사설망 격리와 Azure Active Directory 기반 RBAC 보안 통제를 완벽히 충족시킵니다. 관련 글 약정 지출 할인 가이드 공급업체 가격 직접 비교의 함정 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # 백그라운드 에이전트가 바꾸는 FinOps 비용 시계 · FinOps LLM URL: https://finopsllm.com/ko/research/background-agents-cost-clock 백그라운드 에이전트와 FinOps 비용 시계 업데이트 September 10, 2026 · 최초 게시 September 10, 2026 핵심 답변: 백그라운드 실행은 세션이 닫힌 뒤에도 추론 비용을 누적시킵니다. 대화 턴 예산이 아닌 작업(Task) 단위 총예산과 엄격한 타임아웃을 설정해야 합니다. 백그라운드 실행은 세션이 닫힌 뒤에도 추론 비용을 누적시킵니다. 대화 턴 예산이 아닌 작업(Task) 단위 총예산과 엄격한 타임아웃을 설정해야 합니다. 관련 글 에이전트 3단계 예산 모델 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # Claude Opus 5.5: $4/$20 및 $0.20 캐시 읽기 · FinOps LLM URL: https://finopsllm.com/ko/research/claude-opus-5-5-cost-model Claude Opus 5.5 비용 모델 업데이트 September 22, 2026 · 최초 게시 September 22, 2026 Anthropic은 2026년 9월 22일에 Claude Opus 5.5( claude-opus-5-5 )를 출시했습니다. 헤드라인 가격은 백만 입력 토큰당 $4, 백만 출력 토큰당 $20로 Opus 5의 $5와 $25에서 인하했습니다. 이는 20% 인하입니다. 대부분의 프로덕션 워크로드의 경우 헤드라인이 제외한 레이트가 가장 많이 움직였기 때문에 실제 인하가 더 큽니다. 중요한 요금 토큰 유형 Opus 5.5 Opus 5 Fable 5.1 입력(캐시되지 않음) $4.00 / MTok $5.00 / MTok $10.00 / MTok 출력 $20.00 / MTok $25.00 / MTok $50.00 / MTok 캐시 쓰기(5분) $5.00 / MTok $6.25 / MTok $12.50 / MTok 캐시 읽기 $0.20 / MTok $0.50 / MTok $0.25 / MTok 빠른 모드(입력/출력) $8 / $40 — — 모든 행은 20% 낮지만 캐시 읽기는 60% 낮습니다. $0.20에서는 이제 Fable 5.1의 $0.25보다 저렴합니다. 이는 Fable이 예전에 이긴 한 행을 뒤집습니다. Fable 5.1 비용 모델 에서 캐시가 많은 워크로드는 Opus 5보다 Fable에서 더 저렴할 수 있었습니다. Opus 5.5에 대해서는 더 이상 그렇지 않습니다. Fable은 모든 토큰 유형에서 더 많은 비용이 듭니다. 일반적인 작업이 약 40% 저렴한 이유 Anthropic의 주장은 일반적인 작업의 비용이 40% 감소한다는 것이지 20%가 아닙니다. 추가는 토큰 효율에서 비롯됩니다. Anthropic은 Opus 5.5가 약 20% 적은 입출력 토큰으로 동일한 결과에 도달하고 약 40% 덜 자세한 출력을 기록한다고 말합니다. 낮은 요금 곱하기 적은 토큰의 합계: 0.8 × 0.8 = 0.64, 이는 혼합에 따라 대략 36-40% 할인입니다. 여기 에이전트 단계 하나가 있습니다: 200,000 입력 토큰, 캐시에서 제공되는 90%, 20,000 출력 토큰. 라인 Opus 5 Opus 5.5(동일 토큰) Fable 5.1 20K 캐시되지 않은 입력 $0.100 $0.080 $0.200 180K 캐시 입력 $0.090 $0.036 $0.045 20K 출력 $0.500 $0.400 $1.000 합계 $0.690 $0.516 $1.245 동일한 토큰에서 Opus 5.5는 캐시 할인으로 인해 Opus 5보다 25% 저렴하며 20%가 아닙니다. 워크로드에 20% 토큰 감소가 적용되면 단계는 약 $0.41로 떨어지며, 이는 Opus 5 아래 40%, Fable 비용의 3분의 1입니다. 출력은 여전히 이 예제에서 청구서의 약 80%입니다. 이것이 자세한 정도 감소가 보상되는 곳입니다. GPT-6 Sol, GPT-6 Astra, Fable 5.1 대비 작업당 비용 100만 토큰당 정가와, 위와 같은 에이전트 단계(입력 200K, 90% 캐시, 출력 20K)를 각 모델로 계산한 값입니다. 모델 입력 $/MTok 출력 $/MTok 캐시 읽기 $/MTok 동일 에이전트 단계 GPT-6 Sol $2.00 $10.00 $0.20 $0.276 Claude Opus 5.5 $4.00 $20.00 $0.20 $0.516 Claude Opus 5 $5.00 $25.00 $0.50 $0.690 Claude Fable 5.1 $10.00 $50.00 $0.25 $1.245 GPT-6 Astra $10.00 $50.00 $1.00 $1.380 Artificial Analysis Intelligence Index v4.3.2에서 측정한 작업당 비용(2026년 9월 22일 기준, 점수순). 47.5점까지는 GPT-6 Sol이 가장 저렴합니다. 그 이상에서는 모든 수준에서 Opus 5.5가 가장 저렴합니다. Opus 5.5 high는 1.82달러에 53.6점, GPT-6 Astra max는 3.26달러에 52.7점, Fable 5.1 max는 7.63달러에 53.4점입니다. 모델 Intelligence Index 작업당 비용 작업당 출력 토큰 GPT-6 Sol · medium 39.8 $0.25 6,500 GPT-6 Sol · xhigh 44.1 $0.53 16,000 GPT-6 Astra · low 45.8 $0.82 4,400 GPT-6 Sol · max 47.5 $1.06 31,200 Claude Opus 5 · high 48.1 $3.61 46,200 Claude Opus 5 · max 50.8 $5.86 72,500 Claude Opus 5.5 · medium 51.2 $1.34 25,700 Claude Fable 5.1 · high 51.2 $3.91 38,100 GPT-6 Astra · max 52.7 $3.26 27,200 Claude Fable 5.1 · max 53.4 $7.63 78,100 Claude Opus 5.5 · high 53.6 $1.82 35,600 Claude Opus 5.5 · max 57.6 $5.98 119,200 GPT-6 Astra의 low 초과 설정, Opus 5의 모든 설정, Fable 5.1의 모든 설정은 같거나 더 높은 점수를 내는 Sol 또는 Opus 5.5 설정보다 비쌉니다. 작업당 비용은 벤치마크의 작업 구성에 따라 달라집니다. 모델을 바꾸기 전에 자체 트래픽으로 재현해 보세요. Fable을 대체할 만큼 충분합니까? Anthropic은 Opus 5.5를 대부분의 작업에서 Fable 5.1과 일치하는 것으로 위치합니다. 게시된 숫자는 코딩 및 에이전트 작업을 지원합니다: Terminal-Bench 4.0: 66.4%, Opus 5 52.3%, Fable 5.1 55.8% 대비. FrontierCode v1.1: 54.4%, Opus 5 48.0%, Fable 5.1 50.3% 대비. CursorBench 4.0: 57.8%, Opus 5 46.6% 대비. GDPval-AA v2.1: 1846 Elo, Opus 5 1708 대비. Artificial Analysis는 출시 당일 Intelligence Index에서 1위로 순위를 매겼습니다. Anthropic은 또한 기본(중간) 노력에서 작업당 비용의 약 5분의 1로 GPT-6 Astra를 최대 노력으로 지식 작업에서 능가한다고 말합니다. 이는 공급업체 비교이므로 테스트할 가설로 취급하십시오. 위의 비용 수학은 직접 확인할 수 있는 부분입니다. 빠른 모드 비용 2× 빠른 모드는 $8 입력 및 $40 출력 비용이 정확히 표준 요금의 2배이며 최대 2.5× 속도입니다. 표준 모델도 Opus 5보다 약 30% 빠릅니다. 사용자가 대기 중인 지연 바운드 인터랙티브 경로에 빠른 모드를 사용하십시오. 배치 작업, 백그라운드 에이전트 및 eval에서 유지하십시오. 빠른 모드가 기본적으로 활성화되면 단가가 2배가 되고 청구서가 도착할 때까지 대시보드에 비정상은 표시되지 않습니다. 이번 주 할 일 모델 ID를 고정합니다. 프로덕션을 claude-opus-5-5 로 명시적으로 지정하고 모든 요청에 ID를 기록하여 마이그레이션 후 요청당 비용을 모델별로 분할할 수 있습니다. 자신의 트래픽에서 재설정합니다. 두 모델에서 실제 요청 샘플을 재생하고 호출당이 아닌 완료된 작업당 토큰을 비교합니다. 20% 토큰 효율 주장은 워크로드에 따라 가장 변할 가능성이 있는 부분입니다. 노력 설정을 다시 확인합니다. 워크로드가 품질을 위해 Fable 또는 최대 노력으로 이동한 경우 먼저 중간에서 Opus 5.5를 테스트하십시오. 그것은 Anthropic이 벤치마킹하는 설정입니다. Fable 라우팅 결정을 다시 실행합니다. 더 저렴한 캐시 읽기를 얻기 위해 캐시가 많은 트래픽을 Fable로 보낸 경로는 재평가해야 합니다. 해당 비용 이점은 사라졌습니다. 캐시 히트 비율을 주시합니다. $4.00에 대해 $0.20에서 캐시 미스는 이제 히트의 20배 비용이 듭니다. 접두사를 끊는 프롬프트 템플릿 변경은 Opus 5에서보다 더 많은 비용이 듭니다. Anthropic은 Sonnet 5.5와 Haiku 5.5가 앞으로 몇 주 안에 나올 것이라고 말합니다. 단계 2에서 재생 하네스를 유지하여 각 릴리스를 오후에 다시 설정할 수 있습니다. 관련 글 Claude Fable 5.1 비용 모델 프롬프트 캐싱 경제 Opus 5.5 노력 수준이 실제 가격입니다 Opus 5.5 빠른 모드 경제 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # 요청당 비용보다 성공 작업당 비용을 측정해야 하는 이유 · FinOps LLM URL: https://finopsllm.com/ko/research/cost-per-successful-task 요청당 비용보다 성공 작업당 비용을 측정해야 하는 이유 업데이트 August 27, 2026 · 최초 게시 August 27, 2026 핵심 답변: 요청당 비용(Cost per request)은 유용한 지표이지만, 사용자가 구매하는 최종 결과 단위가 아닙니다. 실패하거나, 3번 재시도하거나, 사용할 수 없는 답변을 낸 요청은 완료된 작업이 아닙니다. 프로덕션 AI 환경에서 실질적인 경쟁력을 결정짓는 지표는 성공 작업당 비용(Cost per successful task)입니다. 즉, 정의된 품질 임계값을... 요청당 비용(Cost per request)은 유용한 지표이지만, 사용자가 구매하는 최종 결과 단위가 아닙니다. 실패하거나, 3번 재시도하거나, 사용할 수 없는 답변을 낸 요청은 완료된 작업이 아닙니다. 프로덕션 AI 환경에서 실질적인 경쟁력을 결정짓는 지표는 성공 작업당 비용(Cost per successful task) 입니다. 즉, 정의된 품질 임계값을 충족한 작업 수로 모든 공급업체 및 도구 비용을 나눈 값입니다. 핵심 산식 성공 작업당 비용 = 귀속 총지출 / 성공 작업 수 산식을 적용하십시오. 입력, 출력, 캐시, 추론 토큰 및 도구 호출, 재시도, 폴백 비용을 모두 분자에 포함해야 합니다. 사용자가 수락한 응답, 신뢰도 임계값을 넘은 분류 결과, 수동 개입 없는 완료 등 성공 기준을 사전에 확정하십시오. 요청당 평균의 함정 실패한 저가 호출이 많아지면 요청당 평균 단가는 오히려 저렴해 보이는 착시가 발생합니다. 또한 롱테일 고비용 이상치를 은폐합니다. 기능의 중위 요청 비용은 낮을 수 있지만, 실패 사례가 값비싼 추론 호출과 사람의 검토 시간을 대량으로 소모할 수 있습니다. 성공률과 함께 p50 및 p95 성공 작업당 단가를 측정하십시오. 분모의 계측 모든 모델 스팬에 요청 ID와 기능 태그를 부여하고, 애플리케이션은 해당 ID와 연결된 결과 이벤트를 발행해야 합니다. 공급업체 청구서와 분자를 대사하고, 완료된 작업을 샘플링하여 분모의 유효성을 정기적으로 검증하십시오. 관련 글 LLM 비용 모니터링 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # LLM 공급업체 전환의 실제 비용과 ROI · FinOps LLM URL: https://finopsllm.com/ko/research/cost-switching-llm-providers LLM 공급업체 전환의 실제 비용: 엔지니어링과 품질 리스크 업데이트 August 27, 2026 · 최초 게시 August 27, 2026 핵심 답변: LLM 공급업체 전환은 단순한 단가 비교 작업이 아닙니다. SDK 재작성, 프롬프트 엔지니어링, 구조화된 출력 스키마 수정, 평가 파이프라인, 이중 운영, 데이터 전송 및 모델 품질 저하 위험을 모두 합산해야 합니다. 이러한 실질 비용을 예상 월 절감액과 대조하여 투자 회수 기간을 검증하십시오.엔지니어링 전환 공수 산정SDK 호출, JSON 구조화 출력... LLM 공급업체 전환은 단순한 단가 비교 작업이 아닙니다. SDK 재작성, 프롬프트 엔지니어링, 구조화된 출력 스키마 수정, 평가 파이프라인, 이중 운영, 데이터 전송 및 모델 품질 저하 위험을 모두 합산해야 합니다. 이러한 실질 비용을 예상 월 절감액과 대조하여 투자 회수 기간을 검증하십시오. 엔지니어링 전환 공수 산정 SDK 호출, JSON 구조화 출력 규격, 툴 바인딩, 속도 제한 처리, 컨텍스트 처리 방식 및 에러 응답 로직을 전수 조사하십시오. 개발 및 테스트 공수를 정확히 측정해야 예기치 못한 비용 초과를 방지할 수 있습니다. 출력 품질과 검증 비용 동일한 테스트셋으로 두 공급업체를 벤치마크하십시오. 작업 성공률, p50/p95 지연 시간, 재시도 횟수, 사람의 검토 개입 시간을 측정합니다. 토큰 단가는 저렴하지만 작업 실패율이 높아져 재시도가 증가하면 전체 비용은 상승합니다. 병행 운영 및 회수 기간 프로덕션 트래픽과 장애 복구를 검증하기 위해 충분한 기간 동안 두 프로바이더를 병행 운영하십시오. 게이트웨이 운영비와 위험 프리미엄을 반영한 순 절감액을 기준으로 의사결정을 내려야 합니다. 관련 글 공급업체 차익거래 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # DeepSeek Harness의 7가지 방어적 설계 패턴 · FinOps LLM URL: https://finopsllm.com/ko/research/deepseek-harness-defensive-patterns DeepSeek Harness의 7가지 방어적 설계 패턴 업데이트 August 16, 2026 · 최초 게시 August 16, 2026 핵심 답변: 자율 에이전트 실행 중 리소스 누수와 무한 루프를 방지하기 위해 DeepSeek Harness가 적용한 7가지 방어 패턴입니다. 1. 결과와 비용의 직교 분리작업 성공 여부와 관계없이 토큰 사용량과 실행 메트릭을 반드시 기록하여 비용 추적성을 유지합니다. 2. 완전한 리소스 정리 (Dispose)작업 중단 시 백그라운드 프로세스와 네트워크 소켓을 강제... 자율 에이전트 실행 중 리소스 누수와 무한 루프를 방지하기 위해 DeepSeek Harness가 적용한 7가지 방어 패턴입니다. 1. 결과와 비용의 직교 분리 작업 성공 여부와 관계없이 토큰 사용량과 실행 메트릭을 반드시 기록하여 비용 추적성을 유지합니다. 2. 완전한 리소스 정리 (Dispose) 작업 중단 시 백그라운드 프로세스와 네트워크 소켓을 강제 종료하여 유휴 토큰 과금을 방지합니다. 관련 글 DeepSeek Harness 개요 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # DeepSeek Harness 설치: 프로필과 첫 실행 가이드 · FinOps LLM URL: https://finopsllm.com/ko/research/deepseek-harness-getting-started DeepSeek Harness 설치: 프로필과 첫 실행 가이드 업데이트 August 16, 2026 · 최초 게시 August 16, 2026 핵심 답변: DeepSeek Harness(dsh)를 시작하기 위한 실전 가이드입니다. 환경 설정과 플러그인 아키텍처 및 첫 실행 방법을 안내합니다. 가장 빠른 실행 방법 npx @deepseek-ai/dsh web 로컬 http://127.0.0.1:3080에서 웹 인터페이스가 시작됩니다. 다음 두 단계 설정이 필요합니다: 설정 → 모델: DeepSeek API 키... DeepSeek Harness(dsh)를 시작하기 위한 실전 가이드입니다. 환경 설정과 플러그인 아키텍처 및 첫 실행 방법을 안내합니다. 가장 빠른 실행 방법 npx @deepseek-ai/dsh web 로컬 http://127.0.0.1:3080 에서 웹 인터페이스가 시작됩니다. 다음 두 단계 설정이 필요합니다: 설정 → 모델: DeepSeek API 키 입력(재시작 없이 즉시 활성화). 워크스페이스 선택: 프로젝트 디렉터리를 추가하고 활성화. 소스 코드 빌드 git clone https://github.com/deepseek-ai/deepseek-harness pnpm install pnpm run build pnpm dsh web 요구사항: Node 22.19 이상, Git 2.26 이상, Corepack을 통한 pnpm@11.7.0 고정 버전. 프로필과 4단계 설정 계층 Cordis 런타임 위에서 동작하며 모든 것이 플러그인입니다. 번들 패키지, 프로필 패치, 홈 패치, CLI 오버레이 순으로 적용되어 CLI 명령어가 항상 최종 우선순위를 가집니다. 관련 글 DeepSeek Harness 가이드 플러그인 아키텍처 분석 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # 목표 관리와 Ralph 루프: 에이전트 비용 통제 · FinOps LLM URL: https://finopsllm.com/ko/research/deepseek-harness-goals-ralph-loop 목표 관리와 Ralph 루프: 에이전트 비용 통제 업데이트 August 16, 2026 · 최초 게시 August 16, 2026 핵심 답변: 장기 작업 시 컨텍스트 비대화를 방지하고 목표를 달성하기 위해 Ralph 루프를 통해 컨텍스트를 초기화하며 비용을 통제합니다. 장기 작업 시 컨텍스트 비대화를 방지하고 목표를 달성하기 위해 Ralph 루프를 통해 컨텍스트를 초기화하며 비용을 통제합니다. 관련 글 DeepSeek Harness 개요 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # DeepSeek Harness의 지출 가드레일 구현 · FinOps LLM URL: https://finopsllm.com/ko/research/deepseek-harness-guardrails DeepSeek Harness의 지출 가드레일 구현 업데이트 August 16, 2026 · 최초 게시 August 16, 2026 핵심 답변: 사후 청구서 충격을 방지하기 위해 모델 호출 전과 툴 실행 직전에 예산 한도를 강제 검증하는 2단계 훅 아키텍처입니다. 사후 청구서 충격을 방지하기 위해 모델 호출 전과 툴 실행 직전에 예산 한도를 강제 검증하는 2단계 훅 아키텍처입니다. 관련 글 에이전트 3단계 예산 모델 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # 모든 것이 플러그인: Cordis 기반 아키텍처 · FinOps LLM URL: https://finopsllm.com/ko/research/deepseek-harness-plugin-architecture 모든 것이 플러그인: Cordis 기반 아키텍처 업데이트 August 16, 2026 · 최초 게시 August 16, 2026 핵심 답변: 특권화된 코어 없이 모델 어댑터, 세션 로그, 루프 자체가 독립 플러그인으로 구성되어 공급자 전환과 테스트가 용이합니다. 특권화된 코어 없이 모델 어댑터, 세션 로그, 루프 자체가 독립 플러그인으로 구성되어 공급자 전환과 테스트가 용이합니다. 관련 글 DeepSeek Harness 개요 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # 세션 로그: 단일 진실 공급원이자 비용 원장 · FinOps LLM URL: https://finopsllm.com/ko/research/deepseek-harness-session-log 세션 로그: 단일 진실 공급원이자 비용 원장 업데이트 August 16, 2026 · 최초 게시 August 16, 2026 핵심 답변: 생성된 출력 이벤트마다 토큰 사용량이 직접 결합되어 기록되므로 완벽한 금융 감사 및 비용 귀속이 가능합니다. 생성된 출력 이벤트마다 토큰 사용량이 직접 결합되어 기록되므로 완벽한 금융 감사 및 비용 귀속이 가능합니다. 관련 글 DeepSeek Harness 개요 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # 서브에이전트 위임과 재귀 깊이 제어 기법 · FinOps LLM URL: https://finopsllm.com/ko/research/deepseek-harness-subagents 서브에이전트 위임과 재귀 깊이 제어 기법 업데이트 August 16, 2026 · 최초 게시 August 16, 2026 핵심 답변: 재귀적 위임 깊이를 엄격히 제한하여 서브에이전트 생성으로 인한 지수함수적 토큰 소모를 차단합니다. 재귀적 위임 깊이를 엄격히 제한하여 서브에이전트 생성으로 인한 지수함수적 토큰 소모를 차단합니다. 관련 글 서브에이전트 동시성 제어 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # 툴 스코프와 권한 제한: 프롬프트 세금 감축 · FinOps LLM URL: https://finopsllm.com/ko/research/deepseek-harness-tool-scopes 툴 스코프와 권한 제한: 프롬프트 세금 감축 업데이트 August 16, 2026 · 최초 게시 August 16, 2026 핵심 답변: 불필요한 툴 스키마를 프롬프트에서 제거하여 매 턴마다 발생하는 고정 입력 토큰 비용을 최소화합니다. 불필요한 툴 스키마를 프롬프트에서 제거하여 매 턴마다 발생하는 고정 입력 토큰 비용을 최소화합니다. 관련 글 MCP 도구 정의 오버헤드 제어 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # LLM 평가 파이프라인에 비용 통제 장치 구축하기 · FinOps LLM URL: https://finopsllm.com/ko/research/evals-cost-control LLM 평가 파이프라인에 비용 통제 장치 구축하기 업데이트 August 27, 2026 · 최초 게시 August 27, 2026 핵심 답변: LLM 평가 파이프라인은 독자적인 비용 정책이 필수적입니다. 코드 변경 시마다 10,000개의 프롬프트를 실행하는 CI 파이프라인은 보호하려는 기능 자체보다 더 큰 클라우드 청구서를 유발할 수 있습니다. 실행당 예산 상한, 대표 표본 추출, 캐시된 테스트 픽스처, 명백한 품질 실패 시 조기 중단하는 비용 게이트를 구축하십시오.실행 단위 예산 책정평가 엔진이... LLM 평가 파이프라인은 독자적인 비용 정책이 필수적입니다. 코드 변경 시마다 10,000개의 프롬프트를 실행하는 CI 파이프라인은 보호하려는 기능 자체보다 더 큰 클라우드 청구서를 유발할 수 있습니다. 실행당 예산 상한, 대표 표본 추출, 캐시된 테스트 픽스처, 명백한 품질 실패 시 조기 중단하는 비용 게이트를 구축하십시오. 실행 단위 예산 책정 평가 엔진이 작동하기 전에 프롬프트 수, 후보 모델, 재시도 횟수, 허용 예산 한도를 설정하십시오. Pull Request 검증용 스모크 테스트, 야간 회귀 테스트, 릴리스 인증 테스트를 엄격히 분리합니다. 신호 보존을 위한 계층화 표본 추출 워크플로, 고객 영향도, 난이도, 알려진 실패 모드별로 테스트 세트를 계층화하십시오. 수만 개의 중복 프롬프트보다 결정 경계를 다루는 엄선된 데이터셋이 훨씬 신뢰할 수 있는 평가 신호를 제공합니다. 안정적인 데이터의 캐싱 불변 픽스처, 검색된 RAG 컨텍스트, 기준 정답 판단을 캐싱하십시오. 캐시 읽기와 쓰기를 평가 비용의 일부로 명확히 추적해야 합니다. 관련 글 성공 작업당 비용 LLM 비용 모니터링 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # AI 제품을 위한 실무 월말 결산 및 비용 대사 · FinOps LLM URL: https://finopsllm.com/ko/research/first-ai-month-end-close AI 프로덕션을 위한 실무 월말 결산 및 비용 대사 프로세스 업데이트 August 27, 2026 · 최초 게시 August 27, 2026 핵심 답변: 첫 번째 AI 월말 결산은 대시보드 화면 캡처로 시작해서는 안 됩니다. 공급업체의 원천 인보이스와 확정된 마감 기간에서 시작해야 합니다. 실제 청구된 현금 숫자를 먼저 확정하고, 사용량 데이터를 규명한 다음, 두 수치가 일치할 때 비로소 비용을 배부하십시오. 이 순서를 지켜야 보기 좋은 그래프가 감사 불가능한 허수가 되는 것을 방지할 수 있습니다.1. 기간... 첫 번째 AI 월말 결산은 대시보드 화면 캡처로 시작해서는 안 됩니다. 공급업체의 원천 인보이스와 확정된 마감 기간에서 시작해야 합니다. 실제 청구된 현금 숫자를 먼저 확정하고, 사용량 데이터를 규명한 다음, 두 수치가 일치할 때 비로소 비용을 배부하십시오. 이 순서를 지켜야 보기 좋은 그래프가 감사 불가능한 허수가 되는 것을 방지할 수 있습니다. 1. 기간 및 단가 기준 동결 보고 기준 시간대, 인보이스 마감일, 통화, 약정 할인 및 프로모션 크레딧 처리 기준을 명확히 설정하십시오. 해당 기간에 적용된 가격표를 동결하고, 인보이스 식별자와 원격 측정 쿼리 기간을 기록해야 합니다. 2. 공급업체 원천 데이터와 대사 사용량 이벤트를 공급업체 결제 내역과 계정, 모델, 토큰 유형, 일자별로 조인하십시오. 입력, 출력, 캐시 읽기/쓰기, 추론 토큰, 도구 호출 비용을 모두 규명하고, 미배부 잔액이 발생하면 원인을 조사해야 합니다. 3. 대사된 비용의 책임 단위 배부 기능, 개발팀, 실행 환경, 고객 코호트 등 일관된 태그 차원을 적용하십시오. 공유 플랫폼 인프라 비용과 기능별 직접 소비 비용을 명확히 분리해야 합니다. 4. 변동 요인의 4대 축 분해 단가(Rate), 사용량(Volume), 모델 믹스(Mix), 효율성(Efficiency)을 통해 전기 대비 차이를 규명하십시오. 단순 총비용뿐 아니라 성공적인 작업당 p50 및 p95 비용과 재시도율을 함께 검토하십시오. 신뢰할 수 있는 AI 결산은 철저히 원칙적이어야 합니다. 모든 지출에 출처가 있고, 모든 배부에 명확한 규칙이 있으며, 모든 변동에 설명 가능한 담당자가 지정되어야 합니다. 관련 글 AI 지출 인보이스 대사 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # FOCUS 1.5 AI 토큰 추적 및 청구 스키마 가이드 · FinOps LLM URL: https://finopsllm.com/ko/research/focus-1-5-ai-token-tracking FOCUS 1.5: AI 토큰 추적과 Price Sheet 표준화의 핵심 업데이트 September 19, 2026 · 최초 게시 August 15, 2026 핵심 답변: FinOps Foundation은 FOCUS 1.5 사양을 2026년 12월 정식 확정한다고 발표했습니다. 클라우드 비용 및 사용량 표준 사양에 사상 처음으로 인공지능 네이티브 필드가 도입되어, 호출된 AI 모델 식별자, 입력 및 출력 토큰 소비량, 그리고 공급업체 공시 정가를 담는 Price Sheet 데이터셋이 신설됩니다.1. FOCUS 1.5가... FinOps Foundation은 FOCUS 1.5 사양을 2026년 12월 정식 확정한다고 발표했습니다. 클라우드 비용 및 사용량 표준 사양에 사상 처음으로 인공지능 네이티브 필드가 도입되어, 호출된 AI 모델 식별자, 입력 및 출력 토큰 소비량, 그리고 공급업체 공시 정가를 담는 Price Sheet 데이터셋 이 신설됩니다. 1. FOCUS 1.5가 표준화하는 핵심 항목 통일된 모델 식별자: AWS Bedrock, Azure OpenAI, GCP Vertex AI 간의 상이한 모델 명칭을 단일 기준으로 표준화. 세분화된 토큰 메트릭: 단순 합산이 아닌 입력, 출력, 캐시 읽기 토큰을 독립된 열로 규정. Price Sheet 데이터셋: 정가 가격표와 실제 사용량 레코드를 분리하여 약정 할인율의 실효성을 명확히 감사. 2. 사양이 해결해주지 않는 영역 FOCUS는 공급업체가 내보내는 인보이스 데이터의 표준일 뿐이며, 기업 내부 조직별 비용 배부 를 대신해주지 않습니다. 어떤 제품 기능이나 팀이 호출을 발생시켰는지는 공급업체가 알 수 없으므로, 내부 AI 게이트웨이 태깅이 여전히 필수적입니다. 3. 기업이 지금 준비해야 할 과제 토큰 소비량을 유형별로 분리 저장하고, 호출마다 모델 ID를 1급 필드로 보존하며, 호출 시점의 공급업체 가격표를 동결 보관하십시오. 관련 글 LLM 비용 귀속 및 배부 AI 청구서 대사 가이드 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # Claude Max 대 Alibaba Token Pro 코딩 비용 · FinOps LLM URL: https://finopsllm.com/ko/research/heavy-agentic-coding-cost-claude-vs-qwen Claude Max 대 Alibaba Token Pro: 고강도 에이전틱 코딩의 실제 비용 업데이트 September 19, 2026 · 최초 게시 August 6, 2026 핵심 답변: 자율 코딩 워크플로우가 단순 자동완성에서 오케스트레이터가 리팩토링, 테스트, 보안 감사를 위해 4~8개의 서브 에이전트를 병렬 실행하는 멀티 에이전트 스웜(Swarm)으로 전환되면 토큰 소모량이 기하급수적으로 증가합니다. 단순 표시 단가 비교는 조달 실패로 이어집니다.1. 전혀 다른 과금 구조Alibaba Token Pro(월 $70)는 Qwen... 자율 코딩 워크플로우가 단순 자동완성에서 오케스트레이터가 리팩토링, 테스트, 보안 감사를 위해 4~8개의 서브 에이전트를 병렬 실행하는 멀티 에이전트 스웜(Swarm) 으로 전환되면 토큰 소모량이 기하급수적으로 증가합니다. 단순 표시 단가 비교는 조달 실패로 이어집니다. 1. 전혀 다른 과금 구조 Alibaba Token Pro(월 $70) 는 Qwen 3.8-Max를 대상으로 5시간당 12,000 크레딧, 7일당 40,000 크레딧의 명시적 롤링 한도를 제공하며 심야 오프피크(0.2배 크레딧 배수) 할인을 지원합니다. Claude Max 20x(월 $200) 는 Opus 5에 대해 고정 토큰 한도를 공개하지 않는 동적 버스트 컴퓨팅 풀을 제공하여 1차 시도 성공률과 높은 코드베이스 이해도를 보장합니다. 2. 완료 작업당 손익분기점 순수 구독료 기준($70 대 $200)으로 Qwen 3.8-Max는 Opus 5의 승인 작업 산출물의 35% 만 달성해도 기능 완료당 비용 면에서 더 저렴합니다. 그러나 개발자 인건비를 시간당 $50로 환산할 경우, Opus 5가 디버깅과 수동 수정 시간을 월 2.6시간 (시간당 $100 기준 1.3시간)만 단축해도 $130의 구독료 차액은 완전히 정당화됩니다. 관련 글 비용 감사: Alibaba 대 Claude Max AI 공급업체 정가를 직접 비교할 수 없는 이유 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # 프로덕션 LLM 비용 급증 대응 런북 · FinOps LLM URL: https://finopsllm.com/ko/research/llm-cost-spike-runbook 프로덕션 환경에서의 LLM 비용 급증 격리 및 대응 런북 업데이트 August 27, 2026 · 최초 게시 August 27, 2026 핵심 답변: LLM 지출이 급증했을 때 모델부터 성급하게 변경해서는 안 됩니다. 먼저 청구 증거를 보존하고, 이상 신호를 검증하며, 변동 요인이 사용량, 단가, 모델 믹스, 또는 작업 효율성 중 무엇인지 파악해야 합니다.최초 15분: 증거 보존 및 신호 확인공급업체 청구 내역, 게이트웨이 텔레메트리, 트래픽, 모델 믹스, 토큰 유형, 재시도 횟수 및 최근 배포 이력을... LLM 지출이 급증했을 때 모델부터 성급하게 변경해서는 안 됩니다. 먼저 청구 증거를 보존하고, 이상 신호를 검증하며, 변동 요인이 사용량, 단가, 모델 믹스, 또는 작업 효율성 중 무엇인지 파악해야 합니다. 최초 15분: 증거 보존 및 신호 확인 공급업체 청구 내역, 게이트웨이 텔레메트리, 트래픽, 모델 믹스, 토큰 유형, 재시도 횟수 및 최근 배포 이력을 즉시 캡처합니다. 이후 30분: 안전한 격리 조치 폭주하는 워크플로우 일시 중지, 에이전트 상한 적용, 비동기 작업의 배치 API 전환 등 최소한의 가역적 조치를 취하고 담당자와 만료 기한을 지정합니다. 원인 분석 및 사고 종료 호출당 비용이 아닌 성공적인 작업당 비용을 기준으로 이전 기간과 비교하여 원인을 규명하고, 영구적인 방어책을 수립합니다. 관련 글 LLM 비용 모니터링 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # MCP 도구 정의 토큰 오버헤드 최적화 · FinOps LLM URL: https://finopsllm.com/ko/research/mcp-tool-definition-overhead 에이전트 워크플로우에서 MCP 도구 정의 토큰 비용 최적화 업데이트 September 19, 2026 · 최초 게시 September 19, 2026 핵심 답변: AI 에이전트를 여러 Model Context Protocol(MCP) 서버에 연결하면 사용자의 의도를 처리하기 전에 매 턴마다 수천 개의 입력 토큰이 주입됩니다. 등록된 각 도구는 함수 이름, 매개변수 설명 및 유형 제약 조건이 포함된 JSON 스키마를 추가합니다. GitHub, Postgres, Slack 등 6개의 MCP 서버를 연결한 환경에서는 툴... AI 에이전트를 여러 Model Context Protocol(MCP) 서버에 연결하면 사용자의 의도를 처리하기 전에 매 턴마다 수천 개의 입력 토큰이 주입됩니다. 등록된 각 도구는 함수 이름, 매개변수 설명 및 유형 제약 조건이 포함된 JSON 스키마를 추가합니다. GitHub, Postgres, Slack 등 6개의 MCP 서버를 연결한 환경에서는 툴 정의만으로도 호출당 4,500~12,000개의 입력 토큰이 고정적으로 소모됩니다. MCP 서버 도구 정의가 많은 토큰을 소비하는 이유는 무엇인가요? 모델이 함수를 정확히 호출하려면 각 도구마다 상세한 JSON Schema 메타데이터가 필요합니다. 단일 데이터베이스 쿼리 도구 하나만으로도 350~600개의 토큰을 차지하며, 수십 개의 도구가 누적되면 정적 스키마가 컨텍스트 윈도우의 상당 부분을 점유합니다. 비용 절감을 위한 세 가지 아키텍처 프로덕션 에이전트 시스템에서는 정적 도구 선언 직후 프롬프트 캐싱 경계(Breakpoint)를 설정하여 반복 비용을 최대 90% 절감하고, 가벼운 라우터를 통한 2단계 동적 도구 주입, 그리고 JSON 스키마의 불필요한 설명 제거 및 압축 기법을 적용합니다. 관련 글 서버 도구와 분리 청구서 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # 모델 가격 인하가 AI 청구서를 저절로 낮추지 않는다 · FinOps LLM URL: https://finopsllm.com/ko/research/model-price-cuts-routing-budget 모델 가격 인하와 라우팅 예산 관리 업데이트 September 10, 2026 · 최초 게시 September 10, 2026 핵심 답변: 토큰 단가가 낮아져도 컨텍스트 길이가 늘어나거나 고가 모델 라우팅이 유지되면 총비용은 줄어들지 않습니다. 성공 작업당 단가를 재평가해야 합니다. 토큰 단가가 낮아져도 컨텍스트 길이가 늘어나거나 고가 모델 라우팅이 유지되면 총비용은 줄어들지 않습니다. 성공 작업당 단가를 재평가해야 합니다. 관련 글 성공 작업당 비용 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # AI 관측성 도구가 두 번째 LLM 청구서가 될 수 있다 · FinOps LLM URL: https://finopsllm.com/ko/research/observability-second-llm-bill AI 관측성과 두 번째 LLM 청구서 업데이트 September 9, 2026 · 최초 게시 September 9, 2026 핵심 답변: 출력 품질을 실시간 검증하기 위해 판사 모델을 전수 실행하면 본 기능보다 비싼 모니터링 청구서가 발행됩니다. 위험도 기반 샘플링이 해법입니다. 출력 품질을 실시간 검증하기 위해 판사 모델을 전수 실행하면 본 기능보다 비싼 모니터링 청구서가 발행됩니다. 위험도 기반 샘플링이 해법입니다. 관련 글 평가 비용 통제 전략 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # Opus 5.5의 노력 수준이 실제 가격입니다 · FinOps LLM URL: https://finopsllm.com/ko/research/opus-5-5-effort-level-cost Opus 5.5의 노력 수준이 실제 가격입니다 업데이트 September 22, 2026 · 최초 게시 September 22, 2026 Claude Opus 5.5는 입력 토큰 백만 개당 $4, 출력 토큰 백만 개당 $20입니다. 이는 Opus 5보다 20% 저렴합니다. 요금은 비용 이야기의 작은 절반일 뿐입니다. 큰 절반은 effort 설정으로, 모델이 답하기 전에 생각하는 데 소비하는 토큰 수를 결정합니다. 하나의 모델, 다섯 가지 가격 Opus 5.5는 low 에서 medium , high , xhigh , max 까지의 노력을 제공합니다. 각 수준은 동일한 토큰 단가의 동일한 모델이지만 매우 다른 수의 토큰을 생성합니다. The Decoder가 보고한 독립적 벤치마킹에 따르면 5개 수준 중 4개가 비용-성능 파레토 경계에 있습니다. 또한 최대 노력에서 Opus 5.5는 작업당 약 119,000개의 출력 토큰을 사용하여 경쟁 모델의 최고 설정보다 훨씬 많다는 것을 발견했습니다. 100만 토큰당 20달러면 출력 119,200토큰은 입력을 빼고도 작업당 2.38달러입니다. medium에서 Artificial Analysis가 측정한 출력은 25,700토큰, 즉 0.51달러였습니다. 입력까지 포함하면 max는 작업당 5.98달러, medium은 1.34달러로, 요청 파라미터 하나로 같은 모델의 작업당 비용이 약 4.5배 달라집니다. Artificial Analysis Intelligence Index v4.3.2(평가 10종)에서 측정, 2026년 9월 22일 기준. 모든 행이 같은 벤치마크 묶음을 쓰므로 바로 비교할 수 있습니다. 모델 및 effort Intelligence Index 작업당 비용 작업당 출력 토큰 비용-성능 프런티어 여부 Opus 5.5 · low 42.3 $0.55 10,200 아니요 Opus 5.5 · medium 51.2 $1.34 25,700 예 Opus 5.5 · high 53.6 $1.82 35,600 예 Opus 5.5 · xhigh 56.0 $3.46 65,700 예 Opus 5.5 · max 57.6 $5.98 119,200 예 Opus 5 · high (참고) 48.1 $3.61 46,200 아니요 출처: Artificial Analysis. 프런티어에 있다는 것은 GPT-6 Sol, GPT-6 Astra, Opus 5, Opus 5.5, Fable 5.1의 어떤 설정도 더 적은 비용으로 더 높은 점수를 내지 못한다는 뜻입니다. Opus 5.5 low는 GPT-6 Sol xhigh가 0.53달러에 44.1점을 내므로 제외됩니다. xhigh에서 max로 올리면 비용이 73% 늘고 점수는 1.6점 오릅니다. 중간이 Anthropic이 벤치마킹하는 설정입니다 Anthropic의 주요 비교는 기본 노력인 중간에서 수행됩니다. Opus 5.5는 중간에서 최대 노력의 GPT-6 Astra를 지식 작업에서 약 5분의 1의 작업당 비용으로 능가한다고 말합니다. 따라서 Anthropic 자체의 모델에 대한 사례는 중간에 기반하며 최대는 예외입니다. 모든 곳에 최대를 설정하는 팀은 "안전을 위해" 출시 벤치마크가 필요하지 않은 토큰에 대해 비용을 지불합니다. 추측 없이 노력을 설정하는 방법 기본적으로 중간으로 설정하세요. SDK 기본값이 변경되지 않도록 코드에서 명시적 값으로 만드세요. 전체적으로가 아니라 경로마다 노력을 높이세요. 어려운 디버깅, 장기 계획, 최종 검토 단계는 높음 또는 최대를 정당화할 수 있습니다. 분류, 추출 및 일상적인 편집은 거의 그렇지 않습니다. 각 요청으로 노력을 기록하세요. 요청당 비용은 이 없이는 해석할 수 없습니다. 요청 수가 평탄한 상태에서의 지출 급증은 일반적으로 노력 변경입니다. 동일하게 재생된 작업에서 노력 수준을 비교하세요. 각 수준에서 완료된 작업당 성공률과 출력 토큰을 기록하고 성공 개선이 멈출 때 노력 상향을 중단하세요. 제품이 허용하는 경우 출력을 제한하세요. 최대 토큰 제한은 최악의 경우를 제한합니다. 최대 노력에서는 그 제한이 폭주 작업과 여러 달러 요청 사이의 유일한 것입니다. $25에서 $20으로의 인하는 20%를 절약합니다. 워크로드를 최대에서 중간 노력으로 옮기면 그보다 훨씬 더 절약할 수 있습니다. 노력을 다른 항목과 마찬가지로 소유하고 검토하는 예산 항목으로 취급하세요. 관련 글 Claude Opus 5.5 비용 모델 Opus 5.5 빠른 모드 경제학 추론 모델 비용 가이드 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # Opus 5.5 fast mode: 2배 가격으로 대기 시간 단축 · FinOps LLM URL: https://finopsllm.com/ko/research/opus-5-5-fast-mode-economics Opus 5.5 fast mode 경제성 업데이트 September 22, 2026 · 최초 게시 September 22, 2026 Claude Opus 5.5에는 두 개의 가격표가 있습니다. 표준은 입력 토큰 100만당 $4, 출력 토큰 100만당 $20입니다. Fast mode는 $8과 $40으로, 정확히 2배이며 출력 속도는 최대 2.5×입니다. 모델은 동일합니다. 추가 비용은 시간만 구매할 뿐입니다. 유일한 질문은 누구의 시간인지입니다. 프리미엄이 구매하는 것 5,000개의 출력 토큰을 생성하는 단계를 가정합시다. 표준 요금에서 출력 비용은 $0.10입니다. Fast mode에서는 $0.20입니다. 표준 속도에서 단계가 60초 걸리고 2.5배 속도로 약 24초가 되는 경우, 36초를 절약하기 위해 $0.10을 더 지불합니다. 이는 제거된 대기 시간 시간당 약 $10에 해당합니다. 출력 토큰으로 증가하기 때문에 단계 길이는 비율을 변경하지 않습니다. 표준 모드 속도에 따라 다릅니다. 이 예제는 초당 약 83개의 출력 토큰을 가정하므로 직접 계산하세요. 입력도 2배가 되므로 접두사가 많은 단계는 초당 저장된 비용이 약간 더 높습니다. 저렴한 경우 대화형 코딩 에이전트를 기다리는 개발자. 제거된 대기 시간 시간당 $10에서 fast mode 비용은 급여를 받는 누구나의 시간보다 훨씬 낮습니다. 레이턴시가 전환에 영향을 주는 고객 대면 응답. 토큰 청구에 대해서가 아니라 이탈률에 대해 속도 향상을 가격 책정합니다. 사건, 모든 분이 비용을 발생시킵니다. 순수한 낭비인 경우 백그라운드 에이전트, 야간 작업 및 배치 파이프라인. 아무도 기다리지 않으므로 추가 지출은 아무것도 구매하지 않습니다. 평가 및 재생. 이들은 정확히 토큰 수를 곱하고 일정에 따라 실행되는 워크로드입니다. 병렬로 실행되는 서브에이전트. 벽시계 시간은 가장 느린 분기와 오케스트레이터로 설정되지만, 각 호출이 아닙니다. 표준 Opus 5.5는 이미 Anthropic에 따르면 Opus 5보다 약 30% 빠릅니다. Opus 5에서 fast mode를 정당화했을 일부 지연 불만은 업그레이드만으로 해결될 수 있습니다. 더 많이 지불하기 전에 표준 속도를 측정하세요. 시행할 컨트롤 Fast mode를 명시적인 경로당 결정으로 만듭니다. 글로벌 기본값이거나 엔지니어가 한 번 켜고 잊어버린 플래그여야 합니다. 모드별 지출에 태그를 지정합니다. 단위 가격의 2배인 fast mode 요청은 모델만으로 그룹화되는 대시보드의 일반 요청처럼 보입니다. 출력 토큰의 fast mode 공유에 대해 경고합니다. 사용자가 기다리지 않는 경로에서 증가하면 켜져야 할 것이 켜집니다. 노력과 속도를 함께 예산화합니다. 최대 노력은 토큰 수를 곱하고 fast mode는 각 토큰의 가격을 2배로 합니다. 이것은 모델을 실행하는 가장 비용이 많이 드는 방법입니다. 관련 글 Claude Opus 5.5 비용 모델 Opus 5.5 노력 수준이 실제 가격입니다 서브에이전트 팬아웃 및 동시성 제한 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # 품질 저하 없이 AI ROI를 증명하는 측정 프레임워크 · FinOps LLM URL: https://finopsllm.com/ko/research/prove-ai-roi-measurement 품질 저하 없이 AI ROI를 증명하는 측정 프레임워크 업데이트 August 27, 2026 · 최초 게시 August 27, 2026 핵심 답변: AI의 ROI는 단순히 모델 청구 비용이 줄었다고 증명되지 않습니다. 성공적인 비즈니스 성과의 개선 가치가 해당 성과를 내기 위해 투입된 총비용보다 커질 때 비로소 입증됩니다. 이를 측정하려면 귀속 지출, 성공 성과, 품질 검증이라는 세 가지 상호 연결된 데이터셋이 필요합니다.반사실적 기준선(Counterfactual) 설정AI 변경이 없었을 경우의... AI의 ROI는 단순히 모델 청구 비용이 줄었다고 증명되지 않습니다. 성공적인 비즈니스 성과의 개선 가치가 해당 성과를 내기 위해 투입된 총비용보다 커질 때 비로소 입증됩니다. 이를 측정하려면 귀속 지출, 성공 성과, 품질 검증이라는 세 가지 상호 연결된 데이터셋이 필요합니다. 반사실적 기준선(Counterfactual) 설정 AI 변경이 없었을 경우의 대안(사람의 직접 처리, 이전 모델, 이전 워크플로우 등)을 명시하십시오. 비교 대조군이 없다면 매출 증대나 비용 절감을 AI의 기여로 입증할 수 없습니다. 작업 성공을 분모로 채택 단순 API 호출당 비용이 아니라 성공 작업당 비용 을 측정하십시오. 토큰 비용 외에도 재시도, 툴 호출, 평가 파이프라인, 사람의 오류 수정 시간을 비용 분자에 반영해야 합니다. 품질 기준선 유지 비용을 25% 절감했더라도 작업 성공률이 92%에서 80%로 떨어졌다면 이는 ROI 개선이 아닙니다. 실험 전 최저 품질 기준선을 설정하고 기준 미달의 절감액은 거부하십시오. 관련 글 성공 작업당 비용 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # AI 공급업체 정가를 직접 비교할 수 없는 이유 · FinOps LLM URL: https://finopsllm.com/ko/research/provider-prices-not-comparable AI 공급업체 정가를 직접 비교할 수 없는 이유: 유효 작업 비용 업데이트 August 27, 2026 · 최초 게시 August 27, 2026 핵심 답변: 100만 토큰당 표시 정가만으로 AI 공급업체를 비교하면 잘못된 비용 절감 판단을 내리게 됩니다. 공급업체마다 과금하는 토큰 유형, 캐시 할인율, 컨텍스트 윈도우 규칙 및 툴 호출 단가가 완전히 다릅니다. 진정한 비교 척도는 동일한 워크로드와 품질 기준에서 측정한 성공 작업당 실효 비용(Cost per Successful Task)입니다.과금 단위... 100만 토큰당 표시 정가만으로 AI 공급업체를 비교하면 잘못된 비용 절감 판단을 내리게 됩니다. 공급업체마다 과금하는 토큰 유형, 캐시 할인율, 컨텍스트 윈도우 규칙 및 툴 호출 단가가 완전히 다릅니다. 진정한 비교 척도는 동일한 워크로드와 품질 기준에서 측정한 성공 작업당 실효 비용(Cost per Successful Task) 입니다. 과금 단위 표준화 공급업체, 모델, 엔드포인트, 리전, 토큰 유형, 프롬프트 캐시 상태, 배치 여부별로 단가표를 구성하십시오. 입력, 출력, 캐시 읽기/쓰기, 추론 토큰, 도구 호출 비용을 명확히 분리하고, 최소 약정과 크레딧을 별도로 추적합니다. 워크로드 및 품질 정규화 동일한 프롬프트, 컨텍스트 제약, 평가 기준으로 고정 워크로드를 벤치마크하십시오. p50/p95 지연 시간, 완료율, 재시도 횟수, 사람의 검토 개입을 측정합니다. 단가가 30% 저렴해도 재시도가 2배 늘어나면 성공 작업당 비용은 오히려 증가합니다. 운영 오버헤드 반영 라우팅 로직, API 게이트웨이 유지보수, 관측성, 데이터 전송 비용을 포함하십시오. 품질 최소 점수와 작업당 최대 허용 비용을 모두 만족하는 최적 공급업체로 동적 라우팅을 구현합니다. 관련 글 LLM 공급업체 차익거래 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # 작업당 실제 비용: Opus 5.5 vs Sol, Astra, Fable · FinOps LLM URL: https://finopsllm.com/ko/research/real-cost-per-task-frontier-models 프런티어 모델의 작업당 실제 비용 업데이트 September 22, 2026 · 최초 게시 September 22, 2026 정가는 토큰 하나의 값을 알려 줄 뿐, 완료된 작업 하나의 값을 알려 주지는 않습니다. 같은 일을 해도 모델마다 쓰는 토큰 수가 크게 다르기 때문입니다. 이 페이지는 Claude Opus 5.5, Claude Opus 5, Claude Fable 5.1, GPT-6 Astra, GPT-6 Sol의 모든 effort 단계에 대해 실측 작업당 비용과 품질 점수를 나란히 보여 줍니다. 모든 수치에 출처가 있고, 추정치는 없습니다. 결론부터 말하면, 점수 47.5까지는 어느 수준이든 GPT-6 Sol이 가장 저렴합니다. 47.5를 넘으면 모든 단계에서 Opus 5.5가 가장 저렴합니다. low보다 높은 GPT-6 Astra, Opus 5, Fable 5.1은 어떤 설정도 비용 효율적이지 않습니다. 모두 Sol이나 Opus 5.5의 어떤 설정에 점수와 가격 모두에서 밀립니다. 방법 모든 점수와 비용은 Artificial Analysis Intelligence Index v4.3.2(2026년 9월 22일 확인)에서 가져왔습니다. 이 지수는 AA-Briefcase, GDPval-AA, AutomationBench-AA, Terminal-Bench 4.0, SciCode, Humanity's Last Exam, GDP.pdf, CritPt, AA-Omniscience, AA-LCR의 10개 평가로 구성됩니다. Artificial Analysis는 각 모델을 각 effort 설정으로 제공사 API를 통해 실행하고, 정가로 지불한 금액을 기록합니다. 작업당 비용은 작업 하나에 들어간 지출을 입력과 출력으로 나눈 것입니다. 모든 행이 같은 평가 세트를 거치므로 행끼리 바로 비교할 수 있습니다. 수치를 읽기 전에 두 가지 한계가 있습니다. 첫째, 이 지수는 하나의 작업 구성일 뿐입니다. 여러분의 작업 구성에서는 비용이 달라지므로, 마지막 절에서 직접 측정하는 방법을 설명합니다. 둘째, 지수 버전이 다르면 점수를 비교할 수 없습니다. 이전에 발표된 수치와 섞지 마세요. 전체 목록: 26개 설정 작업당 출력 토큰은 추론을 포함해 모델이 작성한 토큰입니다. Artificial Analysis는 GPT-6 Sol의 중간 네 설정에 대해 입력과 출력 내역을 공개하지 않아 해당 칸은 n/a로 표시했습니다. 모델 Effort Intelligence Index 작업당 비용 입력 비용 출력 비용 작업당 출력 토큰 프런티어 여부 GPT-6 Sol none 28.1 $0.33 $0.28 $0.05 4,900 아니요 GPT-6 Sol low 33.9 $0.13 n/a n/a 3,400 예 GPT-6 Sol medium (기본값) 39.8 $0.25 n/a n/a 6,500 예 GPT-6 Sol high 42.8 $0.37 n/a n/a 10,200 예 GPT-6 Sol xhigh 44.1 $0.53 n/a n/a 16,000 예 GPT-6 Sol max 47.5 $1.06 $0.74 $0.31 31,200 예 GPT-6 Astra low 45.8 $0.82 $0.60 $0.22 4,400 예 GPT-6 Astra medium 49.6 $1.54 $1.06 $0.48 9,600 아니요 GPT-6 Astra high 50.9 $1.73 $1.13 $0.59 11,800 아니요 GPT-6 Astra xhigh 52.4 $2.31 $1.46 $0.85 16,900 아니요 GPT-6 Astra max 52.7 $3.26 $1.90 $1.36 27,200 아니요 Claude Opus 5 low 39.4 $1.10 $0.73 $0.37 14,700 아니요 Claude Opus 5 medium 44.8 $2.19 $1.47 $0.72 29,000 아니요 Claude Opus 5 high (기본값) 48.1 $3.61 $2.46 $1.16 46,200 아니요 Claude Opus 5 xhigh 49.7 $4.88 $3.36 $1.52 60,700 아니요 Claude Opus 5 max 50.8 $5.86 $4.05 $1.81 72,500 아니요 Claude Opus 5.5 low 42.3 $0.55 $0.35 $0.20 10,200 아니요 Claude Opus 5.5 medium (기본값) 51.2 $1.34 $0.82 $0.51 25,700 예 Claude Opus 5.5 high 53.6 $1.82 $1.11 $0.71 35,600 예 Claude Opus 5.5 xhigh 56.0 $3.46 $2.15 $1.31 65,700 예 Claude Opus 5.5 max 57.6 $5.98 $3.60 $2.38 119,200 예 Claude Fable 5.1 low 46.8 $2.37 $1.30 $1.08 21,600 아니요 Claude Fable 5.1 medium 48.9 $2.98 $1.59 $1.39 27,900 아니요 Claude Fable 5.1 high 51.2 $3.91 $2.01 $1.90 38,100 아니요 Claude Fable 5.1 xhigh 53.2 $5.98 $2.96 $3.02 60,500 아니요 Claude Fable 5.1 max 53.4 $7.63 $3.73 $3.90 78,100 아니요 프런티어에 있다는 것은 이 표의 다른 어떤 설정도 더 적은 돈으로 더 높은 점수를 내지 못한다는 뜻입니다. 비용 프런티어 26개 설정 중 10개가 프런티어에 있습니다. 비용순으로 정렬하면, 가격만 볼 때 검토할 가치가 있는 설정은 이 10개뿐입니다. 나머지는 같거나 더 낮은 점수에 더 많이 지불합니다. 설정 Intelligence Index 작업당 비용 작업 1만 건당 GPT-6 Sol · low 33.9 $0.13 $1,300 GPT-6 Sol · medium 39.8 $0.25 $2,500 GPT-6 Sol · high 42.8 $0.37 $3,700 GPT-6 Sol · xhigh 44.1 $0.53 $5,300 GPT-6 Astra · low 45.8 $0.82 $8,200 GPT-6 Sol · max 47.5 $1.06 $10,600 Claude Opus 5.5 · medium 51.2 $1.34 $13,400 Claude Opus 5.5 · high 53.6 $1.82 $18,200 Claude Opus 5.5 · xhigh 56.0 $3.46 $34,600 Claude Opus 5.5 · max 57.6 $5.98 $59,800 프런티어는 두 구간으로 나뉩니다. 0.13달러부터 1.06달러까지는 거의 GPT-6 Sol이고, 유일한 예외가 0.82달러의 GPT-6 Astra low입니다. 1.34달러부터는 Opus 5.5뿐입니다. 두 구간 사이의 차이는 작습니다. Opus 5.5 medium은 Sol max보다 3.7점 높고, 작업당 0.28달러 더 비쌉니다. 같거나 더 높은 점수에서의 일대일 비교 각 쌍은 저렴한 설정과, 점수가 같거나 더 낮은 비싼 설정을 비교합니다. 저렴한 설정 비싼 설정 점수 차 절감액 Opus 5.5 medium: 51.2, $1.34 Opus 5 high: 48.1, $3.61 Opus 5.5에서 +3.1 63% Opus 5.5 medium: 51.2, $1.34 Opus 5 max: 50.8, $5.86 Opus 5.5에서 +0.4 77% Opus 5.5 medium: 51.2, $1.34 Fable 5.1 high: 51.2, $3.91 동점 66% Opus 5.5 high: 53.6, $1.82 GPT-6 Astra max: 52.7, $3.26 Opus 5.5에서 +0.9 44% Opus 5.5 high: 53.6, $1.82 Fable 5.1 max: 53.4, $7.63 Opus 5.5에서 +0.2 76% GPT-6 Sol max: 47.5, $1.06 Opus 5 high: 48.1, $3.61 Opus 5에서 +0.6 71% Opus 5 행은 아직 마이그레이션하지 않은 팀에게 중요합니다. Opus 5의 기본값은 high였습니다. Opus 5.5의 기본값은 medium이며, 이 기본값에서 작업당 비용이 63% 낮고 점수는 3.1점 높습니다. Anthropic은 Opus 5.5가 Opus 5보다 40% 저렴하다고 밝혔지만, 이 지수에서 측정한 차이는 그보다 큽니다. 돈이 나가는 곳: 출력이 아니라 입력 모든 모델에서 입력이 작업당 비용의 약 절반에서 4분의 3을 차지합니다. Opus 5.5 medium에서는 1.34달러 중 0.82달러, 즉 61%가 입력입니다. GPT-6 Astra max는 58%, GPT-6 Sol max는 70%, Fable 5.1 max는 49%입니다. 에이전트 작업은 단계마다 커진 컨텍스트를 다시 보냅니다. 그래서 입력 비용은 답변 길이만이 아니라 단계 수에 따라 늘어납니다. GPT-6 Sol의 추론 없음 설정이 low보다 비싼 이유가 여기에 있습니다. 출력은 4,900토큰뿐인데도 0.13달러가 아니라 0.33달러가 듭니다. 0.33달러 중 0.28달러가 입력입니다. 단계가 늘어나고 매번 컨텍스트를 다시 보내는 것이 원인으로 보입니다. 추론을 끄더라도 그 대신 턴이 늘어나면 에이전트는 저렴해지지 않습니다. 청구서 관점에서는 캐싱이 모델 선택만큼 중요하다는 뜻입니다. Opus 5.5와 GPT-6 Sol은 캐시된 입력 100만 토큰당 0.20달러입니다. GPT-6 Astra는 1.00달러, Opus 5는 0.50달러입니다. 토큰 양과 정가 여기서 토큰 효율이 가장 좋은 모델은 GPT-6 Astra입니다. max에서도 작업당 출력이 27,200토큰으로, Opus 5.5 max의 119,200토큰보다 훨씬 적습니다. 하지만 Astra는 100만 토큰당 10달러와 50달러로 Opus 5.5 요금의 2.5×입니다. 이기는 쪽은 정가입니다. Opus 5.5 high는 작업당 1.82달러에 53.6점, Astra max는 3.26달러에 52.7점입니다. 장황함이 비용이 되는 곳은 Opus 5.5 max 하나뿐입니다. 출력 119,200토큰만으로 입력 전에 2.38달러이고, 작업 전체는 5.98달러입니다. 표에서 가장 높은 57.6점을 얻지만, 비용은 medium의 4.5×입니다. effort 단계별 수확 체감 각 행은 effort를 한 단계 올렸을 때 얻는 지수 점수와 작업당 추가 비용을 보여 줍니다. 모델 medium → high xhigh → max GPT-6 Sol +48%에 +3.0점 +100%에 +3.4점 GPT-6 Astra +12%에 +1.3점 +41%에 +0.3점 Claude Opus 5 +65%에 +3.3점 +20%에 +1.1점 Claude Opus 5.5 +36%에 +2.4점 +73%에 +1.6점 Claude Fable 5.1 +31%에 +2.3점 +28%에 +0.2점 Fable 5.1과 GPT-6 Astra에서는 max로 올려도 얻는 것이 거의 없습니다. 28%와 41% 더 내고 0.2점과 0.3점입니다. Opus 5.5는 max로 올리면 아직 1.6점을 얻지만, 비용이 73% 늘어납니다. 추가 점수가 결과를 바꾼다는 것을 측정으로 확인한 작업에만 max를 쓰세요. GPT-6 Sol max로 충분한 경우 지수는 평균이며, Sol max와 Opus 5.5 medium의 격차는 평가마다 고르지 않습니다. Artificial Analysis의 평가별 점수: 평가 Opus 5.5 medium ($1.34) GPT-6 Sol max ($1.06) Terminal-Bench 4.0 52.5 43.9 AutomationBench-AA 61.2 61.6 GDPval-AA (Elo) 1576 1487 AA-Briefcase (Elo) 1642 1483 Humanity's Last Exam 54.7 47.9 SciCode 59.3 57.6 CritPt 27.7 30.9 AA-LCR 84.3 83.7 AutomationBench와 CritPt에서는 GPT-6 Sol이 작업당 1.34달러 대비 1.06달러로 Opus 5.5 medium과 같거나 앞섭니다. Terminal-Bench, 지식 업무 평가, Humanity's Last Exam에서는 Opus 5.5가 크게 앞섭니다. 워크플로 자동화는 Sol로 돌려도 됩니다. 터미널·코딩 에이전트와 문서가 많은 지식 업무에서 Opus 5.5가 값을 합니다. 제조사 수치와 독립 측정치 제조사 수치와 독립 측정치는 평가 환경과 설정이 달라 자주 어긋납니다. Anthropic은 xhigh의 Opus 5.5가 Terminal-Bench 4.0에서 66.4%라고 발표했습니다. Artificial Analysis는 같은 effort에서 59.6%를 측정했습니다. Effort Opus 5.5 Fable 5.1 low 31.3% 40.4% medium 52.5% 44.9% high 56.6% 52.0% xhigh 59.6% 55.1% max 59.6% 52.0% 순위도 지수에 따라 달라집니다. Vals AI Index에서는 Fable 5.1이 68.83%로 1위, GPT-6 Astra가 66.61%로 3위, Opus 5.5가 66.16%로 4위입니다. 그곳에서는 작업당 비용이 같은 기준으로 공개되지 않으므로 위의 프런티어는 바뀌지 않습니다. 지수 하나는 하나의 관점일 뿐입니다. 정가와 캐시 중심 작업 Digital Applied는 캐시 중심 에이전트 작업 하나의 가격을 각 모델로 계산했습니다. 캐시 읽기 8M 토큰, 캐시 없는 입력 400K, 캐시 쓰기 600K, 출력 300K입니다. 결과는 프런티어와 같고, GPT-6 Astra에만 추가 페널티가 있습니다. 모델 입력 $/MTok 출력 $/MTok 캐시 읽기 $/MTok 캐시 중심 작업 (Digital Applied) GPT-6 Sol $2.00 $10.00 $0.20 $6.90 Claude Opus 5.5 $4.00 $20.00 $0.20 $12.20 Claude Opus 5 $5.00 $25.00 $0.50 $17.25 Claude Fable 5.1 $10.00 $50.00 $0.25 $28.50 GPT-6 Astra (≤272K) $10.00 $50.00 $1.00 $34.50 GPT-6 Astra (>272K) $20.00 $75.00 n/a $61.50 GPT-6 Astra는 입력이 272K 토큰을 넘으면 요청 전체에 100만 토큰당 20달러와 75달러를 청구합니다. Opus 5.5는 1M 토큰 창 전체에서 단일 가격입니다. Opus 5.5의 캐시 쓰기는 5분 캐시가 100만 토큰당 5달러, 1시간 캐시가 8달러이고, 배치는 50% 요금, 고속 모드는 2배 요금입니다. 자세한 내용은 Claude Opus 5.5 비용 모델 과 Opus 5.5 고속 모드의 경제성 을 참고하세요. 우리 팀의 작업당 비용을 측정하는 방법 토큰을 요청 단위가 아니라 작업 단위로 기록하세요. 캐시 없는 입력, 캐시된 입력, 캐시 쓰기, 출력을 작업의 모든 단계에 걸쳐 합산합니다. 실제 작업 수백 건을 표본으로 뽑아 Sol max, Opus 5.5 medium, Opus 5.5 high 같은 후보 설정 두세 개로 다시 실행하세요. 각 결과를 운영 환경과 같은 검사로 채점하고, 통과한 작업 수를 세세요. 총 지출을 통과한 작업 수로 나누세요. 비교할 숫자는 성공한 작업당 비용입니다. 싸지만 더 자주 실패하는 설정은 싸지 않습니다. 품질 기준을 넘는 가장 저렴한 설정을 고르고, 실패한 작업만 더 높은 설정으로 보내세요. 가격이나 기본 effort가 바뀌면 다시 실행하세요. 한 모델에서 effort 설정이 청구 금액을 어떻게 바꾸는지는 Opus 5.5의 effort 단계가 진짜 가격이다 을 참고하세요. 유의 사항 모든 비용은 Artificial Analysis 작업 구성에서의 API 정가 기준입니다. 할인, 배치 요금, 자체 캐싱에 따라 달라집니다. Artificial Analysis는 Opus 5.5와 Fable 5.1 항목에 Default Fallback 표시를 붙였습니다. 모든 행을 같은 API 구성으로 보기 전에 방법론 설명을 확인하세요. 점수는 지수 v4.3.2 기준입니다. 이전 버전은 다른 평가를 썼으므로 비교할 수 없습니다. Digital Applied의 캐시 중심 작업은 예시용 워크로드 하나이며 측정값이 아닙니다. 제공사가 가격이나 기본값을 바꾸면 수치도 바뀝니다. 확인 날짜는 2026년 9월 22일입니다. 출처 Artificial Analysis Intelligence Index Artificial Analysis: Claude Opus 5.5 Artificial Analysis: Claude Opus 5 Artificial Analysis: Claude Fable 5.1 Artificial Analysis: GPT-6 Astra Artificial Analysis: GPT-6 Sol Digital Applied: GPT-6 Sol vs Claude Opus 5.5 cost benchmarks Digital Applied: Claude Opus 5.5 vs GPT-6 Astra Digital Applied: Is Claude Fable 5.1 still worth it? Digital Applied: Claude Opus 5.5 launch pricing and benchmarks Digital Applied: Opus 5.5 vs Grok 4.7 vs Muse Spark 1.3 cost per task 관련 글 Claude Opus 5.5 비용 모델 Opus 5.5의 effort 단계가 진짜 가격이다 Opus 5.5 고속 모드의 경제성 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # 추론 비용을 늘리는 재시도 루프와 은닉 지출 · FinOps LLM URL: https://finopsllm.com/ko/research/retry-loop-hidden-spend 추론 비용을 조용히 증폭시키는 재시도 루프 제어 업데이트 August 27, 2026 · 최초 게시 August 27, 2026 핵심 답변: 재시도는 무료 복원력이 아닙니다. 엄연히 유료 모델 호출이며, 자율 에이전트는 일시적인 장애 하나를 사용자에게 알리기 전에 5번의 유료 시도로 바꿀 수 있습니다. FinOps 팀의 첫 번째 통제 조치는 재시도 세금(재시도 및 폴백 지출을 전체 추론 지출로 나눈 비율)을 측정하는 것입니다.호출 트리 전체 기록부모 요청 ID, 시도 횟수, 공급업체, 모델,... 재시도는 무료 복원력이 아닙니다. 엄연히 유료 모델 호출이며, 자율 에이전트는 일시적인 장애 하나를 사용자에게 알리기 전에 5번의 유료 시도로 바꿀 수 있습니다. FinOps 팀의 첫 번째 통제 조치는 재시도 세금(재시도 및 폴백 지출을 전체 추론 지출로 나눈 비율)을 측정하는 것입니다. 호출 트리 전체 기록 부모 요청 ID, 시도 횟수, 공급업체, 모델, 도구 호출, 지연 시간, 오류 유형, 토큰 수 및 최종 결과를 기록하십시오. 중첩된 도구 호출을 추적하려면 부모-자식 관계를 명시적으로 보존하여 단일 작업의 전체 실행 트리를 재구성할 수 있어야 합니다. 가치 있는 재시도와 낭비성 재시도의 분리 속도 제한(Rate Limit)으로 인한 재시도는 가치 있는 작업을 복구할 수 있습니다. 반면 스키마 검증 실패를 동일한 프롬프트로 재시도하는 것은 동일한 유료 실패를 반복 구매하는 것에 불과합니다. 오류 유형별로 최대 시도 횟수와 에스컬레이션 경로를 다르게 지정하십시오. 루프 경계에서의 예산 상한 설정 요청당 토큰 한도, 워크플로당 달러 한도, 최대 벽시계 실행 시간(Timeout)을 강제하십시오. 소프트 리밋은 더 저렴한 모델로 라우팅하고, 하드 리밋은 루프를 즉시 중단하여 복구 가능한 상태를 반환해야 합니다. 근본적인 해결책은 재시도를 전면 금지하는 것이 아니라, 모든 추가 시도를 가시화하고 한도를 설정하며 성공률 개선으로 정당화하는 것입니다. 관련 글 에이전트 지출 가드레일 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # SaaS AI 크레딧: 통제 불가능한 단위 측정하기 · FinOps LLM URL: https://finopsllm.com/ko/research/saas-ai-credits-metering SaaS AI 크레딧: 통제 불가능한 단위 측정하기 업데이트 September 2, 2026 · 최초 게시 September 2, 2026 핵심 답변: 클라우드 FinOps는 소비 단위가 명확하다는 전제에서 출발합니다. 인스턴스 시간, 요청 수, 기가바이트 등이 대표적입니다. 하지만 SaaS 공급업체의 AI 크레딧은 다릅니다. 공급업체가 임의로 정의하고 가격을 매기며 계약 기간 중간에도 규칙을 변경할 수 있습니다. 지출은 사용량처럼 발생하지만 관리 도구는 전무합니다.전통적 관리 방식을 무너뜨리는 3가지... 클라우드 FinOps는 소비 단위가 명확하다는 전제에서 출발합니다. 인스턴스 시간, 요청 수, 기가바이트 등이 대표적입니다. 하지만 SaaS 공급업체의 AI 크레딧은 다릅니다. 공급업체가 임의로 정의하고 가격을 매기며 계약 기간 중간에도 규칙을 변경할 수 있습니다. 지출은 사용량처럼 발생하지만 관리 도구는 전무합니다. 전통적 관리 방식을 무너뜨리는 3가지 특성 불투명한 소비 단위: 사용자가 체감하는 동일한 작업이라도 기능에 따라 소모되는 크레딧 수가 극단적으로 다릅니다. 공급업체가 통제하는 초과 요율: 초과 사용료는 공급업체가 독점 책정하므로 저렴한 경로로 전환할 여지가 없습니다. 이월되지 않는 라이선스별 할당량: 팀 간 풀링이나 익월 이월이 불가능하여 한 부서는 초과 요금을 내고 다른 부서는 할당량을 날리는 비효율이 발생합니다. 자체 시계열 데이터 수집 공급업체 관리자 API를 정기적으로 호출하여 사용자, 팀, 기능별로 원시 소비 데이터를 자체 데이터베이스에 저장하십시오. 공급업체 대시보드는 당월 현황만 보여주지만 재무 관리는 추세 분석이 핵심입니다. 청구서 수령 전 사전 배부 클라우드 쇼백(Showback)에 사용하는 동일한 원가 중심점에 크레딧을 매핑하고 매월 내부 보고서를 발행하십시오. 미배부된 비용은 소비를 전혀 통제할 수 없는 IT 플랫폼 팀 예산으로 전가됩니다. 관련 글 법인카드 섀도우 AI 관리 속도 제한을 통한 비용 통제 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # 서버 측 도구는 토큰 계량기 외부에서 청구된다 · FinOps LLM URL: https://finopsllm.com/ko/research/server-tools-are-a-separate-invoice 서버 측 도구는 별도의 청구서다 업데이트 September 1, 2026 · 최초 게시 September 1, 2026 핵심 답변: 대부분의 LLM 비용 모델은 입력 토큰과 출력 토큰이라는 단일 계량기만을 전제합니다. 하지만 웹 검색, 웹 페치, 코드 실행과 같은 서버 측 도구는 제공업체 인프라에서 실행되며 호출당 별도 요금이 부과됩니다.따라서 단일 에이전트 턴에서 도구 호출 비용과 그 결과가 컨텍스트에 추가되면서 발생하는 입력 토큰 비용이라는 이중 과금이 발생합니다.복리로 불어나는... 대부분의 LLM 비용 모델은 입력 토큰과 출력 토큰이라는 단일 계량기만을 전제합니다. 하지만 웹 검색, 웹 페치, 코드 실행과 같은 서버 측 도구는 제공업체 인프라에서 실행되며 호출당 별도 요금이 부과됩니다. 따라서 단일 에이전트 턴에서 도구 호출 비용과 그 결과가 컨텍스트에 추가되면서 발생하는 입력 토큰 비용이라는 이중 과금이 발생합니다. 복리로 불어나는 컨텍스트 비용 도구의 실행 결과는 대화 기록에 누적되며, 이후의 모든 턴에서 입력 토큰으로 계속해서 재전송됩니다. 작업 초반의 10회 웹 검색은 10번의 도구 사용료뿐만 아니라, 이후 모든 턴에서 수천 개의 토큰을 반복해서 읽는 비용을 발생시킵니다. 3가지 실질적 통제 방안 에이전트 실행당 도구 호출 횟수를 엄격히 제한하고, 컨텍스트에 추가하기 전에 결과 텍스트를 요약 및 축소하며, 변경되지 않는 시스템 프롬프트와 툴 정의에 프롬프트 캐싱을 적용해야 합니다. 관련 글 프롬프트 캐싱의 경제학 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # 중단된 스트리밍 응답도 여전히 비용을 발생시킨다 · FinOps LLM URL: https://finopsllm.com/ko/research/streaming-abandoned-generations-cost 스트리밍 응답과 중단된 생성 비용 업데이트 September 9, 2026 · 최초 게시 September 9, 2026 핵심 답변: 화면 렌더링이 멈춰도 백엔드 연결이 유지되면 공급자는 토큰을 계속 과금합니다. AbortController를 통한 업스트림 취소 전파가 필수적입니다. 화면 렌더링이 멈춰도 백엔드 연결이 유지되면 공급자는 토큰을 계속 과금합니다. AbortController를 통한 업스트림 취소 전파가 필수적입니다. 관련 글 재시도 루프의 숨은 지출 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # 서브에이전트 무한 확산과 토큰 낭비 방지 · FinOps LLM URL: https://finopsllm.com/ko/research/subagent-fan-out-concurrency-limits 자율형 서브에이전트의 재귀적 분기와 동시 실행 토큰 제한 업데이트 September 19, 2026 · 최초 게시 September 19, 2026 핵심 답변: 서브에이전트 확산 현상은 오케스트레이터가 작업을 병렬 하위 작업으로 분해하고 작업자 에이전트에게 추가 하위 에이전트 생성 권한을 부여할 때 발생합니다. 엄격한 동시성 제한과 깊이 상한이 없으면 단일 프롬프트가 수백만 개의 토큰을 몇 분 만에 소비하여 막대한 API 비용 급증을 초래합니다.자율형 AI에서 서브에이전트 확산 카스케이드란 무엇인가요?오케스트레이터... 서브에이전트 확산 현상은 오케스트레이터가 작업을 병렬 하위 작업으로 분해하고 작업자 에이전트에게 추가 하위 에이전트 생성 권한을 부여할 때 발생합니다. 엄격한 동시성 제한과 깊이 상한이 없으면 단일 프롬프트가 수백만 개의 토큰을 몇 분 만에 소비하여 막대한 API 비용 급증을 초래합니다. 자율형 AI에서 서브에이전트 확산 카스케이드란 무엇인가요? 오케스트레이터 에이전트가 전체 예산 제약 없이 자식 및 손자 에이전트를 재귀적으로 생성하여 병렬 스레드 전반에서 토큰 소비를 기하급수적으로 폭증시키는 아키텍처 실패 모드입니다. 프로덕션 멀티 에이전트를 위한 4가지 보호 장치 엔터프라이즈 환경에서는 최대 재귀 깊이를 2단계로 제한하고, 루트 스레드에 공유 토큰 풀을 할당하여 소진 시 즉시 중단하며, 동시 실행 프로세스를 3~5개로 제한하는 서킷 브레이커와 OTLP 분산 추적을 통해 안전성을 확보합니다. 관련 글 에이전트를 위한 3가지 예산 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # 자율형 에이전트에 필요한 3단계 예산 설계 · FinOps LLM URL: https://finopsllm.com/ko/research/three-agent-budgets 자율형 AI 에이전트의 런타임 지출 통제를 위한 3단계 예산 아키텍처 업데이트 August 27, 2026 · 최초 게시 August 27, 2026 핵심 답변: 자율형 에이전트에는 단순한 월간 알림 이상의 통제 장치가 필요합니다. 런타임 루프 내부에서 강제되는 요청 예산(단일 호출), 워크플로우 예산(전체 작업), 일일 예산(팀/테넌트)의 3단계 예산이 각각 다른 실패 모드를 차단합니다.1. 요청 예산단일 시도의 토큰 수, 툴 호출 수, 지연 시간 또는 비용을 제한하여 비정상적인 컨텍스트 비대화를 방지합니다.2.... 자율형 에이전트에는 단순한 월간 알림 이상의 통제 장치가 필요합니다. 런타임 루프 내부에서 강제되는 요청 예산 (단일 호출), 워크플로우 예산 (전체 작업), 일일 예산 (팀/테넌트)의 3단계 예산이 각각 다른 실패 모드를 차단합니다. 1. 요청 예산 단일 시도의 토큰 수, 툴 호출 수, 지연 시간 또는 비용을 제한하여 비정상적인 컨텍스트 비대화를 방지합니다. 2. 워크플로우 예산 상관관계 ID(Correlation ID)를 통해 재시도, 폴백, 하위 에이전트를 포함한 전체 작업 비용을 추적하고 무한 루프를 차단합니다. 3. 일일 예산 팀이나 서비스의 일일 누적 지출을 통제하여 시스템 전체의 위험 반경을 제한합니다. 차단 피드백의 투명성 예산 초과 시 단순히 빈 응답을 반환하지 않고, 초과된 예산과 소모량을 명시하며 재개 가능한 상태를 반환해야 합니다. 관련 글 에이전트 지출 가드레일 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # 토큰 가격 하락과 늘어나는 LLM 청구액의 원인 · FinOps LLM URL: https://finopsllm.com/ko/research/token-prices-bill-keeps-rising 토큰 단가는 하락했는데 LLM 청구액이 계속 늘어나는 이유 업데이트 August 27, 2026 · 최초 게시 August 27, 2026 핵심 답변: 토큰 단가가 낮아졌다고 해서 LLM 청구서 금액이 자동으로 줄어들지는 않습니다. 프로덕션 환경에서는 단가 하락보다 사용량이 더 빠르게 증가할 수 있습니다. 더 긴 컨텍스트, 더 많은 에이전트 단계, 더 큰 출력, 반복되는 재시도는 40%의 단가 인하 효과를 손쉽게 지워버립니다. 올바른 FinOps 진단은 단가, 볼륨, 믹스, 효율성의 네 가지 변동을 분리해... 토큰 단가가 낮아졌다고 해서 LLM 청구서 금액이 자동으로 줄어들지는 않습니다. 프로덕션 환경에서는 단가 하락보다 사용량이 더 빠르게 증가할 수 있습니다. 더 긴 컨텍스트, 더 많은 에이전트 단계, 더 큰 출력, 반복되는 재시도는 40%의 단가 인하 효과를 손쉽게 지워버립니다. 올바른 FinOps 진단은 단가, 볼륨, 믹스, 효율성의 네 가지 변동을 분리해 파악하는 것입니다. 단가는 청구서의 일부일 뿐입니다 공급업체가 100만 토큰당 혼합 가격을 10달러에서 6달러로 40% 인하했더라도, 월 사용량이 1억 토큰에서 2억 2천만 토큰으로 늘어나면 청구액은 1,000달러에서 1,320달러로 32% 증가합니다. 입력, 출력, 캐시 읽기/쓰기, 추론 토큰 등 유형별 실제 청구 단가를 독립적으로 기록해야 합니다. 볼륨, 믹스, 그리고 효율성 볼륨(Volume) 은 순수 토큰 소비량입니다. 믹스(Mix) 는 토큰이 어디에 쓰였는지를 나타냅니다. 고성능 추론 모델이나 롱 컨텍스트 기능으로 전환되면 호출 수가 같아도 청구액이 뜁니다. 효율성(Efficiency) 은 유효한 결과 하나를 생성하는 데 투입된 비용으로, 재시도, 실패한 도구 호출, 비대해진 프롬프트를 포함합니다. 무엇을 먼저 최적화해야 하는가 모든 요청을 무조건 가장 싼 모델로 강제하는 것부터 시작하지 마십시오. 가장 큰 금액 변동을 일으킨 항목을 먼저 찾으십시오. 볼륨이 문제라면 컨텍스트 압축과 에이전트 루프를 수정하고, 믹스가 문제라면 라우팅 정책을 수립하며, 효율성이 문제라면 재시도와 미사용 출력을 제거해야 합니다. 관련 글 LLM 비용 모니터링 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # DeepSeek Harness란 무엇인가? 오픈소스 가이드 · FinOps LLM URL: https://finopsllm.com/ko/research/what-is-deepseek-harness DeepSeek Harness란 무엇인가? 오픈소스 에이전트 가이드 업데이트 August 16, 2026 · 최초 게시 August 16, 2026 핵심 답변: DeepSeek Harness(패키지명 dsh)는 DeepSeek AI가 MIT 라이선스로 공개한 오픈소스 자율 에이전트 실행 환경입니다. 본 문서는 에이전트 하네스의 본질, 실행 방법, 아키텍처 구조, 그리고 인프라 비용 통제 관점에서의 가치를 다룹니다.모델과 하네스의 본질적 차이AI 모델이 수행하는 일은 텍스트 및 도구 호출 요청을 생성하는 것뿐입니다.... DeepSeek Harness (패키지명 dsh )는 DeepSeek AI가 MIT 라이선스로 공개한 오픈소스 자율 에이전트 실행 환경입니다. 본 문서는 에이전트 하네스의 본질, 실행 방법, 아키텍처 구조, 그리고 인프라 비용 통제 관점에서의 가치를 다룹니다. 모델과 하네스의 본질적 차이 AI 모델이 수행하는 일은 텍스트 및 도구 호출 요청을 생성하는 것뿐입니다. 에이전트를 실질적으로 유용하게 만드는 프롬프트 조립, 도구 실제 실행, 권한 정책 강제, 세션 로깅, 후속 모델 호출 루프 제어, 하위 서브에이전트 위임은 모두 하네스의 영역입니다. 동일한 모델을 사용하는 두 기업의 산출물 품질과 월간 API 청구액이 극명하게 갈리는 이유는 모델 자체가 아니라 하네스의 제어 능력 차이 때문입니다. 플러그인 중심 아키텍처 DeepSeek Harness는 Cordis 플러그인 런타임 위에서 동작합니다. 모델 어댑터, 도구 레지스트리, 세션 로그, 에이전트 제어 루프까지 모든 구성 요소가 플러그인으로 구현되어 있어, 코어 코드를 포크하지 않고도 런타임에 손쉽게 가로채거나 교체할 수 있습니다. 설치 및 실행 모드 가장 빠른 실행 방식은 로컬 웹 UI를 띄우는 것입니다: npx @deepseek-ai/dsh web 반면 정기 자동화 및 CI/CD 파이프라인에서 핵심적인 것은 헤드리스(Headless) 모드입니다: pnpm dsh --profile headless "summarize this workspace" 대화형 인터페이스로만 동작하는 하네스는 지속적 통합 환경에서 자동화할 수 없으며, 측정되지 않는 에이전트 비용은 통제할 수 없습니다. 운영 비용과 추론 경제학 하네스 소프트웨어 자체는 MIT 라이선스로 완전 무료이지만, 모델 추론 비용은 유료입니다. 최종 청구액은 턴당 실행 단계 수, 도구 카탈로그 크기, 서브에이전트 위임 깊이, 그리고 무한 루프 차단 정책에 의해 결정됩니다. 이는 모두 하네스 계층의 설계 결정에 달려 있습니다. 관련 글 설치 및 시작 가이드 플러그인 아키텍처 분석 이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 → finopsllm.com으로 돌아가기 --- # Webzoekopdrachten worden een kostenpost voor agents · FinOps LLM URL: https://finopsllm.com/nl/research/agent-web-search-cost-center Webzoekopdrachten als kostenpost voor agents Bijgewerkt September 10, 2026 · eerst gepubliceerd September 10, 2026 Kort antwoord: Live webonderzoek door agents leidt tot extra kosten per query naast modeltokens. Koppel zoekopdrachten aan taak-ID's voor accurate kostentoewijzing. Live webonderzoek door agents leidt tot extra kosten per query naast modeltokens. Koppel zoekopdrachten aan taak-ID's voor accurate kostentoewijzing. Gerelateerd Kosten per voltooide taak Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # Brutomarge van een AI-feature meten voor release · FinOps LLM URL: https://finopsllm.com/nl/research/ai-feature-gross-margin Brutomarge van een AI-feature meten voor release Bijgewerkt September 2, 2026 · eerst gepubliceerd September 2, 2026 Kort antwoord: Inferentie is een kostprijs van de omzet (COGS), geen eenmalige ontwikkelingsinvestering. Het wordt aangeroepen bij elke klantactie, schaalt direct mee met het gebruik en belandt op dezelfde factuur... Inferentie is een kostprijs van de omzet (COGS), geen eenmalige ontwikkelingsinvestering. Het wordt aangeroepen bij elke klantactie, schaalt direct mee met het gebruik en belandt op dezelfde factuur als de productie-infrastructuur. Wie dit tot de livegang behandelt als R&D, ontdekt de werkelijke brutomarge pas bij de eerste volledige factuurcyclus — het meest ongunstige moment om operationele margedruk vast te stellen. Instrumenteer vóór de release, niet erna Tag in staging elke modelaanroep met account-, workflow- en uitkomstlabels en speel realistisch verkeer af in plaats van een synthetische lus. Wat u nodig heeft is een verdeling: kosten per geslaagde taak op p50, p90 en p99, plus het percentage van de uitgaven dat opgaat aan mislukte en herhaalde taken waarvoor u wel providerkosten betaalt. Een enkel gemiddelde maskeert de accounts die de marge vernietigen. Herleid naar kosten per account Vermenigvuldig de kosten per geslaagde taak met het verwachte aantal maandelijkse taken per account en tel de faalverhouding erbij op. Vergelijk die uitkomst met de abonnementsprijs van het plan. Voer dit uit bij mediaan gebruik, op het 90e percentiel en voor het zwaarste account dat u commercieel nog toestaat. Vaste abonnementen falen in de staart, omdat modelkosten blijven stijgen terwijl de omzet begrensd is. Vier kritieke kostendrijvers Opnieuw verzonden context per turn: Lange gesprekken of grote opgehaalde documenten worden bij elke interactie opnieuw gefactureerd, tenzij contextcaching is geactiveerd. Retries en systeemfouten: Volledig gefactureerd door de provider; ze horen thuis in de teller van de kostprijs, niet weggemoffeld in een foutenbudget. Agentic fan-out: Eén gebruikersactie vertaalt zich naar tientallen model- en toolcalls; deze vermenigvuldigingsfactor varieert sterk per type gebruiker. Modelroutering: Een standaardconfiguratie die eenvoudige vragen naar een duur redeneermodel stuurt, is de grootste vermijdbare kostenpost. Koppel cijfers direct aan een beleidskeuze De uitkomst moet een vooraf genomen besluit zijn: een verbruiksplafond in het abonnement, een variabele verbruikscomponent in de prijsstructuur, een voordeliger standaardmodel met slimme escalatie, of een bewust geaccepteerde marge met een herzieningsdatum. Gerelateerd Kosten per geslaagde taak De gratis laag is een acquisitiekost Herhaallussen en verborgen kosten Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # AI-uitgavenvariantie: volume, tarief, mix en efficiëntie · FinOps LLM URL: https://finopsllm.com/nl/research/ai-spend-variance-bridge AI-uitgavenvariantie: volume, tarief, mix en efficiëntie Bijgewerkt August 27, 2026 · eerst gepubliceerd August 27, 2026 Kort antwoord: Een variantieanalyse van AI-uitgaven is pas nuttig als deze leidt tot actie. Splits het verschil tussen prognose en werkelijke factuur in vier oorzaken: volume, tarief, mix en efficiëntie. Koppel elke... Een variantieanalyse van AI-uitgaven is pas nuttig als deze leidt tot actie. Splits het verschil tussen prognose en werkelijke factuur in vier oorzaken: volume , tarief , mix en efficiëntie . Koppel elke categorie direct aan facturen, telemetrie en eigenaren zonder dubbeltellingen. Volume Volume meet de vraag: verzoeken, actieve gebruikers, tokens of voltooide workflows. Blijkt volume de drijver, pas dan capaciteits- en groeiprognoses aan in plaats van engineering te belasten. Tarief Tarief is de werkelijk gefactureerde prijs per eenheid, inclusief volumekortingen en contractuele verplichtingen. Een goedkopere catalogusprijs telt pas mee wanneer deze op de factuur staat. Mix Mix weerspiegelt verschuivingen tussen modellen, providers, regio's of batch versus realtime verwerking. Gelijkblijvende tokenvolumes kunnen aanzienlijk duurder uitvallen na migratie naar reasoning-modellen. Efficiëntie Efficiëntie meet de kosten voor hetzelfde bruikbare resultaat, inclusief prompt-omvang, retries, fallback-flows en menselijke reparaties. Koppel kosten altijd aan succespercentages en kwaliteitsstatistieken. Bouw de brug Vertrek vanuit de initiële prognose, verreken tarief, volume, mix en efficiëntie, en analyseer het residu. Elke post vereist technisch bewijs, financiële impact, eigenaar en routing-aanpassingen. Gerelateerd LLM-kostenmonitoring Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # Azure OpenAI vs direct OpenAI: kostenvergelijking · FinOps LLM URL: https://finopsllm.com/nl/research/azure-openai-vs-direct-cost Azure OpenAI vs direct OpenAI: kosten, PTU & break-even Bijgewerkt September 19, 2026 · eerst gepubliceerd July 12, 2026 Kort antwoord: Op basis van standaard pay-as-you-go zijn Azure OpenAI en de directe OpenAI API voor wereldwijde endpoints identiek geprijsd: bijvoorbeeld $2,50 per miljoen inputtokens en $15 per miljoen outputtokens... Op basis van standaard pay-as-you-go zijn Azure OpenAI en de directe OpenAI API voor wereldwijde endpoints identiek geprijsd: bijvoorbeeld $2,50 per miljoen inputtokens en $15 per miljoen outputtokens voor topmodellen. Het financiële verschil zit niet in de standaardeenheidsprijs, maar in drie hefbomen: Provisioned Throughput Units (PTU) , regionale datasoevereiniteitstoeslagen en Microsoft Enterprise Agreement (EA) kortingen . 1. PTU-reserveringen versus pay-as-you-go Azure biedt gereserveerde modelcapaciteit via PTU's. On-demand kost een PTU $2 per uur. Met een maandelijkse reservering daalt dit naar circa $260 per PTU per maand — een korting van tot 82% ten opzichte van het uurtarief (tot 85% bij jaarcontracten). Het economische break-evenpunt voor een PTU-reservering ligt bij een gemiddelde benutting van 65–75% of hoger . Bij wisselende of lage werkdruk is token-afrekening goedkoper. 2. Regionale opslagen voor datasoevereiniteit Wereldwijde Azure-implementaties volgen de Amerikaanse OpenAI-tarieven. Wie strikte dataresidentie binnen West-Europa vereist, betaalt echter een opslag van 10% tot 20% . 3. Verborgen infrastructuurkosten Bij Azure OpenAI komen kosten kijken voor Private Endpoints, Azure Monitor logging en netwerk-egress. Dit verhoogt de effectieve kosten met 4% tot 8%, maar levert enterprise netwerkbeveiliging en RBAC-toegangsbeheer op. Gerelateerd Kortingen op toegezegde uitgaven Waarom AI-lijstprijzen niet vergelijkbaar zijn Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # Achtergrond-agents veranderen de FinOps-klok · FinOps LLM URL: https://finopsllm.com/nl/research/background-agents-cost-clock Achtergrond-agents en de FinOps-klok Bijgewerkt September 10, 2026 · eerst gepubliceerd September 10, 2026 Kort antwoord: Achtergrondtaken accumuleren kosten zonder toezicht. Beveilig asynchrone agent-uitvoeringen met strikte taakplafonds en persistente checkpoints. Achtergrondtaken accumuleren kosten zonder toezicht. Beveilig asynchrone agent-uitvoeringen met strikte taakplafonds en persistente checkpoints. Gerelateerd Drie budgetten voor agents Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # Claude Opus 5.5: $4/$20 en $0.20 cache read · FinOps LLM URL: https://finopsllm.com/nl/research/claude-opus-5-5-cost-model Claude Opus 5.5 kostenmodel Bijgewerkt September 22, 2026 · eerst gepubliceerd September 22, 2026 Anthropic gaf Claude Opus 5.5 ( claude-opus-5-5 ) vrij op 22 september 2026. De kopprijs is $4 per miljoen invoertokens en $20 per miljoen uitvoertokens, omlaag van $5 en $25 op Opus 5. Dat is een verlaging van 20%. Voor meeste productie-workloads is de werkelijke verlaging groter, omdat het tarief dat het meest bewogen is het tarief dat de kopprijs niet noemt. De tarieven die ertoe doen Tokentype Opus 5.5 Opus 5 Fable 5.1 Invoer (niet in cache) $4.00 / MTok $5.00 / MTok $10.00 / MTok Uitvoer $20.00 / MTok $25.00 / MTok $50.00 / MTok Cache schrijven (5 minuten) $5.00 / MTok $6.25 / MTok $12.50 / MTok Cache lezen $0.20 / MTok $0.50 / MTok $0.25 / MTok Snelle modus (invoer / uitvoer) $8 / $40 — — Elke rij is 20% lager behalve de cache read, wat 60% lager is. Bij $0.20 is het nu goedkoper dan Fable 5.1's $0.25. Dat keert de ene rij om waar Fable vroeger won. In onze Fable 5.1 kostenmodel , een sterk in cache opgeslagen workload kon goedkoper uitvallen op Fable dan op Opus 5. Tegen Opus 5.5 gebeurt dat niet meer. Fable kost meer op elk tokentype. Waarom een typische taak ongeveer 40% minder kost Anthropic's claim is een verlaging van 40% in kosten voor een typische job, niet 20%. De extra komt van token efficiency. Anthropic zegt dat Opus 5.5 hetzelfde resultaat bereikt met ongeveer 20% minder invoer- en uitvoertokens en schrijft ongeveer 40% minder uitgebreide uitvoer. Een lager tarief keer minder tokens samengesteld: 0.8 × 0.8 = 0.64, wat ruwweg 36–40% korting is afhankelijk van de mix. Hier is één agent stap: 200.000 invoertokens, 90% bediend uit cache, en 20.000 uitvoertokens. Regel Opus 5 Opus 5.5 (dezelfde tokens) Fable 5.1 20K niet in cache invoer $0.100 $0.080 $0.200 180K invoer in cache $0.090 $0.036 $0.045 20K uitvoer $0.500 $0.400 $1.000 Totaal $0.690 $0.516 $1.245 Op identieke tokens is Opus 5.5 25% goedkoper dan Opus 5, niet 20%, vanwege de cache korting. Als de verlaging van 20% tokens voor uw workload geldt, daalt de stap tot ongeveer $0.41, wat 40% onder Opus 5 ligt en een derde van de Fable kosten. Uitvoer is nog steeds ongeveer 80% van de rekening in dit voorbeeld. Dat is waar de verbosity-reductie loont. Kosten per taak tegenover GPT-6 Sol, GPT-6 Astra en Fable 5.1 Lijstprijzen per miljoen tokens, en dezelfde agentstap als hierboven (200K input, 90% uit cache, 20K output) berekend op elk model. Model Input $/MTok Output $/MTok Cache-read $/MTok Zelfde agentstap GPT-6 Sol $2.00 $10.00 $0.20 $0.276 Claude Opus 5.5 $4.00 $20.00 $0.20 $0.516 Claude Opus 5 $5.00 $25.00 $0.50 $0.690 Claude Fable 5.1 $10.00 $50.00 $0.25 $1.245 GPT-6 Astra $10.00 $50.00 $1.00 $1.380 Gemeten kosten per taak op de Artificial Analysis Intelligence Index v4.3.2, geraadpleegd op 22 september 2026, gesorteerd op score. GPT-6 Sol is de goedkoopste weg naar elke score tot 47,5. Daarboven is Opus 5.5 op elk niveau het goedkoopst: Opus 5.5 high scoort 53,6 voor $1,82, terwijl GPT-6 Astra max 52,7 scoort voor $3,26 en Fable 5.1 max 53,4 voor $7,63. Model Intelligence Index Kosten per taak Output-tokens per taak GPT-6 Sol · medium 39.8 $0.25 6,500 GPT-6 Sol · xhigh 44.1 $0.53 16,000 GPT-6 Astra · low 45.8 $0.82 4,400 GPT-6 Sol · max 47.5 $1.06 31,200 Claude Opus 5 · high 48.1 $3.61 46,200 Claude Opus 5 · max 50.8 $5.86 72,500 Claude Opus 5.5 · medium 51.2 $1.34 25,700 Claude Fable 5.1 · high 51.2 $3.91 38,100 GPT-6 Astra · max 52.7 $3.26 27,200 Claude Fable 5.1 · max 53.4 $7.63 78,100 Claude Opus 5.5 · high 53.6 $1.82 35,600 Claude Opus 5.5 · max 57.6 $5.98 119,200 Elke GPT-6 Astra-instelling boven low, elke Opus 5-instelling en elke Fable 5.1-instelling kost meer dan een Sol- of Opus 5.5-instelling die even hoog of hoger scoort. Kosten per taak hangen af van de takenmix van de benchmark. Speel je eigen verkeer opnieuw af voordat je van model wisselt. Is het goed genoeg om Fable te vervangen? Anthropic positioneert Opus 5.5 als gelijk aan Fable 5.1 op meeste taken. De gepubliceerde getallen ondersteunen dat voor codering en agentic werk: Terminal-Bench 4.0: 66.4%, tegen 52.3% voor Opus 5 en 55.8% voor Fable 5.1. FrontierCode v1.1: 54.4%, tegen 48.0% voor Opus 5 en 50.3% voor Fable 5.1. CursorBench 4.0: 57.8%, tegen 46.6% voor Opus 5. GDPval-AA v2.1: 1846 Elo, tegen 1708 voor Opus 5. Artificial Analysis rangschikte het eerste op zijn Intelligence Index op lanceringsdag. Anthropic zegt ook dat op standaard (gemiddeld) effort het GPT-6 Astra op max effort slaat op kenniswerk voor ongeveer een vijfde van de kosten per taak. Dat is een leveranciersvergelijking, dus behandel het als een hypothese om te testen. De kostencalculatie hierboven is het deel dat u zelf kunt verifiëren. Snelle modus kost 2× Snelle modus kost $8 in en $40 uit, exact dubbel het standaardtarief, voor tot 2.5× de snelheid. Het standaardmodel is ook ongeveer 30% sneller dan Opus 5. Gebruik snelle modus voor latency-bound interactieve paden waar een gebruiker wacht. Hou het uit batch jobs, achtergrond agents en evals. Wanneer snelle modus standaard is ingeschakeld, verdubbelt de unit cost en toont het dashboard niets ongebruikelijks totdat de factuur aankomt. Wat te doen deze week Pin de model-ID. Verwijs productie naar claude-opus-5-5 expliciet en registreer de ID op elk verzoek, zodat kosten per verzoek na migratie per model kunnen worden gesplitst. Herbaseer op uw eigen verkeer. Herhaal een voorbeeld van echte verzoeken op beide modellen en vergelijk tokens per voltooide taak, niet per gesprek. De claim van 20% token-efficiency is het deel dat het meest waarschijnlijk per workload varieert. Controleer effort-instellingen opnieuw. Als een workload naar Fable of naar max effort voor kwaliteit ging, test Opus 5.5 eerst op gemiddeld. Dat is de instelling die Anthropic tegen benchmarks. Voer de Fable routing decision opnieuw uit. Elke route die cache-zware verkeer naar Fable stuurde om de goedkopere cache read te krijgen, moet opnieuw worden geëvalueerd. Dit kostenvoordeel is weg. Let op cache hit ratio. Bij $0.20 tegen $4.00 kost een cache miss nu 20× een hit. Een wijziging van prompt-template die het prefix breekt kost meer dan het deed op Opus 5. Anthropic zegt dat Sonnet 5.5 en Haiku 5.5 volgen in de komende weken. Houd de replay harnas van stap 2 zodat elke release in een middag opnieuw kan worden gebaseerd. Gerelateerd Claude Fable 5.1 kostenmodel Prompt caching economie Opus 5.5 effort levels zijn de echte prijs Opus 5.5 snelle modus economie Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # Kosten per geslaagde taak versus kosten per verzoek · FinOps LLM URL: https://finopsllm.com/nl/research/cost-per-successful-task Kosten per geslaagde taak versus kosten per verzoek Bijgewerkt August 27, 2026 · eerst gepubliceerd August 27, 2026 Kort antwoord: Kosten per API-verzoek zijn informatief, maar vertegenwoordigen niet de eenheid die gebruikers afnemen. Een aanroep die faalt, drie keer opnieuw probeert of een onbruikbaar antwoord oplevert, is geen... Kosten per API-verzoek zijn informatief, maar vertegenwoordigen niet de eenheid die gebruikers afnemen. Een aanroep die faalt, drie keer opnieuw probeert of een onbruikbaar antwoord oplevert, is geen voltooide taak. Voor AI-productiesystemen is de doorslaggevende metriek de kosten per geslaagde taak : alle toewijsbare model- en toolkosten gedeeld door het aantal taken dat aan een vooraf gedefinieerde kwaliteitsdrempel voldoet. De berekening Gebruik de formule: kosten_geslaagde_taak = totale toewijsbare uitgaven / geslaagde taken . Neem input-, output-, cache-, reasoning-, tool-, retry- en fallback-kosten mee. Definieer succes vooraf: een door de eindgebruiker geaccepteerd supportantwoord, een classificatie boven een betrouwbaarheidsdrempel of een workflow die zonder menselijke herstelactie is afgerond. Waarom gemiddelden per verzoek misleidend zijn Gemiddelden per verzoek lijken gunstiger te worden wanneer goedkope, mislukte pogingen worden meegeteld. Bovendien verbergen ze de dure lange staart: een functionaliteit kan een lage mediane aanroepkost hebben, terwijl mislukte gevallen dure redeneermodellen en handmatige reviews verslinden. Segmenteer op feature, model, klantcohort en uitkomst, en rapporteer p50- en p95-kosten per geslaagde taak naast het succespercentage. Instrumenteer de noemer Elke model-span heeft een request-ID en feature-tag nodig; de applicatie moet vervolgens een uitkomst-event uitzenden dat aan die ID is gekoppeld. Registreer succes, storingsreden, handmatige correcties, latentie en zakelijke waarde. Reconcilieer providerfacturen met de teller en neem steekproeven van voltooide taken om de noemer te valideren. Gebruik de metriek voor gerichte optimalisatie Als de aanroepkost hoog is maar het succespercentage optimaal, bieden caching of slimmere modelroutering uitkomst. Als de aanroepkost laag is maar de kosten per geslaagde taak hoog zijn, is kwaliteit het probleem: overmatige retries, ontoereikende modellen of slechte stopcondities. Optimaliseer altijd de metriek die faalkosten meerekent en bewaak de kwaliteits-SLO. Gerelateerd LLM-kostenmonitoring Kosten per verzoek als product-KPI LLM-kostentoewijzing Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # De werkelijke kosten van wisselen van LLM-provider · FinOps LLM URL: https://finopsllm.com/nl/research/cost-switching-llm-providers De werkelijke kosten van wisselen van LLM-provider Bijgewerkt August 27, 2026 · eerst gepubliceerd August 27, 2026 Kort antwoord: Het wisselen van LLM-provider is meer dan een tarievenvergelijking. De businesscase omvat migratie-engineering, prompt- en schema-aanpassingen, evaluatietests, parallel draaien, datatransfer, support... Het wisselen van LLM-provider is meer dan een tarievenvergelijking. De businesscase omvat migratie-engineering, prompt- en schema-aanpassingen, evaluatietests, parallel draaien, datatransfer, support en kwaliteitsrisico's. Weeg deze kosten af tegen de structurele besparing over de terugverdientijd. Breng het migratiewerk in kaart Inventariseer SDK-aanroepen, JSON-schema's, tool-bindingen, rate limits, contextgedrag en foutafhandeling. Schat de uren voor ontwikkeling en testen nauwkeurig in. Een gateway verlaagt toekomstige overstapkosten, maar brengt zelf ook beheerkosten met zich mee. Prijs kwaliteitsborging Test vaste workloads op beide providers. Meet taaksucces, p50/p95-latentie, retries en handmatige reviewtijd. Een migratie die tokens bespaart maar menselijke controle vermeerdert, levert per saldo geen winst op. Budgetteer parallel draaien Laat beide providers lang genoeg gelijktijdig draaien om piekmix en failover te valideren. Modelleer de tijdelijke dubbele kosten. Dient de overstap om leveranciersafhankelijkheid te verlagen, beschouw stand-by capaciteit dan als strategische investering. Bereken de terugverdientijd Reken met de netto maandelijkse besparing na aftrek van operationele kosten en voeg een risicopremie toe voor kwaliteitsvariatie. Vaak is een routeringsbeleid tussen beide providers voordeliger dan een totale vervanging. Gerelateerd Provider-arbitrage Modelconcentratierisico Modelroutering Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # Zeven defensieve patronen in DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/nl/research/deepseek-harness-defensive-patterns Zeven defensieve patronen in DeepSeek Harness Bijgewerkt August 16, 2026 · eerst gepubliceerd August 16, 2026 Kort antwoord: Zeven essentiële ontwerppatronen uit DeepSeek Harness om oneindige lussen en onverwachte tokenkosten te voorkomen. 1. Orthogonale registratieRegistreer tokenverbruik altijd, ongeacht of de taak... Zeven essentiële ontwerppatronen uit DeepSeek Harness om oneindige lussen en onverwachte tokenkosten te voorkomen. 1. Orthogonale registratie Registreer tokenverbruik altijd, ongeacht of de taak slaagde of faalde. 2. Grondige afvoer van resources Zorg dat subprocessen en netwerkverbindingen direct sluiten bij beëindiging. Gerelateerd Wat is DeepSeek Harness? Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # DeepSeek Harness installeren: profielen & eerste run · FinOps LLM URL: https://finopsllm.com/nl/research/deepseek-harness-getting-started DeepSeek Harness installeren: profielen & eerste run Bijgewerkt August 16, 2026 · eerst gepubliceerd August 16, 2026 Kort antwoord: Praktische gids voor het starten van dsh (DeepSeek Harness): installatie, configuratielagen en workflows. Snelle start npx @deepseek-ai/dsh web Start de lokale webinterface op http://127.0.0.1:3080.... Praktische gids voor het starten van dsh (DeepSeek Harness): installatie, configuratielagen en workflows. Snelle start npx @deepseek-ai/dsh web Start de lokale webinterface op http://127.0.0.1:3080 . Voer twee stappen uit: Instellingen → Modellen: vul uw DeepSeek API-sleutel in. Kies werkruimte: activeer uw projectmap om de composer te ontgrendelen. Bouwen vanuit broncode git clone https://github.com/deepseek-ai/deepseek-harness pnpm install pnpm run build pnpm dsh web Vereisten: Node 22.19+, Git 2.26+, pnpm via Corepack. De vierledige configuratiestructuur zorgt dat CLI-argumenten altijd voorrang hebben op profielen en bundels. Gerelateerd Wat is DeepSeek Harness? Budgetbewaking in DeepSeek Harness Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # Doelen en de Ralph-loop in DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/nl/research/deepseek-harness-goals-ralph-loop Doelen en de Ralph-loop in DeepSeek Harness Bijgewerkt August 16, 2026 · eerst gepubliceerd August 16, 2026 Kort antwoord: Structuur voor autonome taken met doelen en context-resets via de Ralph-loop om dure herhalingen te voorkomen. Structuur voor autonome taken met doelen en context-resets via de Ralph-loop om dure herhalingen te voorkomen. Gerelateerd Wat is DeepSeek Harness? Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # Budget-vangrails in DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/nl/research/deepseek-harness-guardrails Budget-vangrails in DeepSeek Harness Bijgewerkt August 16, 2026 · eerst gepubliceerd August 16, 2026 Kort antwoord: Twee cruciale controlepunten in de uitvoeringslus om kostenplafonds direct af te dwingen voordat API-kosten gemaakt worden. Twee cruciale controlepunten in de uitvoeringslus om kostenplafonds direct af te dwingen voordat API-kosten gemaakt worden. Gerelateerd Wat is DeepSeek Harness? Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # Alles is een plugin: DeepSeek Harness & Cordis · FinOps LLM URL: https://finopsllm.com/nl/research/deepseek-harness-plugin-architecture Alles is een plugin: DeepSeek Harness & Cordis Bijgewerkt August 16, 2026 · eerst gepubliceerd August 16, 2026 Kort antwoord: Geen starre kern: model-adapters, sessielogging en de agent-loop zijn uitwisselbare plugins op de Cordis-runtime. Geen starre kern: model-adapters, sessielogging en de agent-loop zijn uitwisselbare plugins op de Cordis-runtime. Gerelateerd Wat is DeepSeek Harness? Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # Het sessielogboek als kostenadministratie · FinOps LLM URL: https://finopsllm.com/nl/research/deepseek-harness-session-log Het sessielogboek als kostenadministratie Bijgewerkt August 16, 2026 · eerst gepubliceerd August 16, 2026 Kort antwoord: Elk event bevat het exacte tokenverbruik voor waterdichte financiële toewijzing en declaratie. Elk event bevat het exacte tokenverbruik voor waterdichte financiële toewijzing en declaratie. Gerelateerd Wat is DeepSeek Harness? Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # Sub-agents en delegatie in DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/nl/research/deepseek-harness-subagents Sub-agents en delegatie in DeepSeek Harness Bijgewerkt August 16, 2026 · eerst gepubliceerd August 16, 2026 Kort antwoord: Beperk de recursiediepte van agents om onbeheersbare kostenexplosies te voorkomen. Beperk de recursiediepte van agents om onbeheersbare kostenexplosies te voorkomen. Gerelateerd Sub-agent concurrency limieten Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # Tool-scopes en restricties in DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/nl/research/deepseek-harness-tool-scopes Tool-scopes en restricties in DeepSeek Harness Bijgewerkt August 16, 2026 · eerst gepubliceerd August 16, 2026 Kort antwoord: Beperk de toolcatalogus per agent om onnodige schema-tokens in de systeemprompt te elimineren. Beperk de toolcatalogus per agent om onnodige schema-tokens in de systeemprompt te elimineren. Gerelateerd MCP tool overhead beheersen Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # Kostenbeheersing in uw LLM-evaluatiepipeline · FinOps LLM URL: https://finopsllm.com/nl/research/evals-cost-control Kostenbeheersing in uw LLM-evaluatiepipeline Bijgewerkt August 27, 2026 · eerst gepubliceerd August 27, 2026 Kort antwoord: LLM-evaluaties vereisen een specifiek kostenbeleid. Een CI-job die 10.000 prompts uitvoert bij elke commit kan een hogere factuur opleveren dan de functionaliteit die hij moet beschermen. Beheers... LLM-evaluaties vereisen een specifiek kostenbeleid. Een CI-job die 10.000 prompts uitvoert bij elke commit kan een hogere factuur opleveren dan de functionaliteit die hij moet beschermen. Beheers evaluatiekosten met een budget per run, representatieve steekproeven, gecachte test-fixtures en een kwaliteitsgate die vroegtijdig stopt bij duidelijke fouten. Budgetteer per run Stel limieten in voor prompts, kandidaatmodellen, retries en dollars voordat de evaluatie start. Scheid snelle pull-request checks van nachtelijke regressietests en releasecertificering. Representatieve steekproeven Segmenteer de testset op workflow, klantimpact, complexiteit en bekende foutmodi. Tienduizend bijna-identieke prompts leveren minder inzicht op dan een compacte set die de beslissingsgrenzen nauwkeurig toetst. Cache stabiele context Cache onveranderlijke fixtures, opgehaalde documenten en referentie-oordelen wanneer een test niet afhankelijk is van nieuwe generatie. Reken cache-hits en writes mee als onderdeel van de evaluatiekosten. Gerelateerd Kosten per geslaagde taak LLM-kostenmonitoring Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # De eerste maandafsluiting voor AI-intensieve producten · FinOps LLM URL: https://finopsllm.com/nl/research/first-ai-month-end-close De eerste maandafsluiting voor AI-intensieve producten Bijgewerkt August 27, 2026 · eerst gepubliceerd August 27, 2026 Kort antwoord: De eerste AI-maandafsluiting begint niet met een dashboard-screenshot, maar met de officiële facturen van modelproviders en een bevroren meetperiode. Stel eerst het werkelijk gefactureerde bedrag... De eerste AI-maandafsluiting begint niet met een dashboard-screenshot, maar met de officiële facturen van modelproviders en een bevroren meetperiode. Stel eerst het werkelijk gefactureerde bedrag vast, leg de telemetrie daarnaast en alloceer kosten pas wanneer beide bronnen volledig aansluiten. 1. Bevries periode en tarieven Leg tijdzones, peildata, valuta, commitments en credits eenduidig vast. Sla de geldende catalogusprijzen op en noteer factuurnummers en query-tijdvakken voor een sluitende audit trail. 2. Reconcilieer met providerfacturen Koppel interne telemetrie aan providerfacturen per account, model, tokentype en dag. Breng input-, output-, cache- en reasoning-tokens in kaart en verklaar eventuele restposten direct. 3. Allokeer aan verantwoordelijke teams Wijs kosten toe op basis van stabiele dimensies: features, engineeringteams, omgevingen en klantcohorten. Houd gedeelde platforminfrastructuur strikt gescheiden van direct feature-verbruik. 4. Analyseer varianties via vier assen Verklaar verschillen ten opzichte van het budget via tarief, volume, mix en efficiëntie. Analyseer naast totale kosten ook de p50- en p95-kosten per succesvol resultaat en het retry-percentage. Gerelateerd Factuurreconciliatie voor AI-uitgaven Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # FOCUS 1.5: AI-tokens & price sheets standaard · FinOps LLM URL: https://finopsllm.com/nl/research/focus-1-5-ai-token-tracking FOCUS 1.5: AI-token tracking en price sheets voor FinOps Bijgewerkt September 19, 2026 · eerst gepubliceerd August 15, 2026 Kort antwoord: De FinOps Foundation heeft aangekondigd dat de FOCUS 1.5 specificatie in december 2026 definitief wordt. Voor het eerst bevat de standaard voor cloudkosten native velden voor kunstmatige... De FinOps Foundation heeft aangekondigd dat de FOCUS 1.5 specificatie in december 2026 definitief wordt. Voor het eerst bevat de standaard voor cloudkosten native velden voor kunstmatige intelligentie: eenduidige model-identificatie, gesplitste token-tellingen en een aparte Price Sheet dataset voor officiële lijstprijzen. 1. Wat FOCUS 1.5 standaardiseert Uniforme modelnamen: Bedrock, Azure OpenAI en Vertex AI hanteren voortaan vergelijkbare model-ID's. Gedetailleerde token-kolommen: Strikte scheiding tussen input-, output- en cache-read tokens in plaats van één vaag totaal. Price Sheet dataset: Scheiding tussen contracttarieven en daadwerkelijk verbruik om kortingen transparant te auditen. 2. Wat de specificatie niet oplost FOCUS regelt alleen de data van de cloudleverancier. Het lost geen interne kostentoewijzing op: leveranciers weten immers niet welke interne applicatie of klant een prompt verstuurde. API-gateway tags blijven noodzakelijk. 3. Voorbereiding voor FinOps-teams Sla tokentypes gescheiden op in uw telemetrie, bewaar het exacte model-ID bij elke trace en bevries historische prijzen bij elke transactie. Gerelateerd LLM kostentoewijzing AI factuurreconciliatie Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # Claude Max vs Alibaba Token Pro: agentic kosten · FinOps LLM URL: https://finopsllm.com/nl/research/heavy-agentic-coding-cost-claude-vs-qwen Claude Max vs Alibaba Token Pro: wat kost zware agentic coding echt? Bijgewerkt September 19, 2026 · eerst gepubliceerd August 6, 2026 Kort antwoord: Wanneer autonome ontwikkelaars-workflows overstappen van eenvoudige code-aanvullingen naar multi-agent swarms (waarbij coördinator-agents 4 tot 8 parallelle sub-agents aansturen voor refactoring,... Wanneer autonome ontwikkelaars-workflows overstappen van eenvoudige code-aanvullingen naar multi-agent swarms (waarbij coördinator-agents 4 tot 8 parallelle sub-agents aansturen voor refactoring, tests en security-audits), explodeert het tokenverbruik. Abonnementen vergelijken op basis van standaard tokenprijzen leidt tot verkeerde financiële beslissingen. 1. Verschillende facturatiemodellen Alibaba Token Pro ($70/mnd) biedt expliciete limieten van 12.000 credits per 5 uur en 40.000 credits per 7 dagen voor Qwen 3.8-Max, met 80% dalkorting (0,2× multiplier) tijdens de nacht. Claude Max 20x ($200/mnd) biedt dynamische burst-capaciteit voor Opus 5 zonder openbare tokenplafonds, met hoge precisie in de eerste iteratie. 2. Break-even analyse per taak Op basis van abonnementskosten alleen ($70 vs $200) hoeft Qwen 3.8-Max slechts 35% van de geaccepteerde taakoutput van Opus 5 te leveren om per opgeleverde functionaliteit goedkoper te zijn. Bij een ontwikkelaarstarief van $50/uur hoeft Opus 5 echter slechts 2,6 uur per maand aan handmatige correcties te besparen om het prijsverschil van $130 volledig terug te verdienen. Gerelateerd Kosten-audit: Alibaba vs Claude Max Waarom AI-lijstprijzen niet vergelijkbaar zijn Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # Productie-runbook voor onverwachte LLM-kostenspikes · FinOps LLM URL: https://finopsllm.com/nl/research/llm-cost-spike-runbook Productie-runbook voor onverwachte LLM-kostenspikes Bijgewerkt August 27, 2026 · eerst gepubliceerd August 27, 2026 Kort antwoord: Wanneer de LLM-uitgaven plotseling exploderen, begin dan niet direct met het wisselen van modellen. Stel eerst bewijsmateriaal veilig, valideer het facturatiesignaal en bepaal of de stijging wordt... Wanneer de LLM-uitgaven plotseling exploderen, begin dan niet direct met het wisselen van modellen. Stel eerst bewijsmateriaal veilig, valideer het facturatiesignaal en bepaal of de stijging wordt veroorzaakt door volume, tarief, mix of efficiëntie. Een effectieve aanpak damt het incident in zonder de benodigde telemetrie te vernietigen. Eerste 15 minuten: verifieer en bewaar Exporteer de factuurgegevens van de provider, het actuele verkeer, de modelmix, retries en recente releases. Vergelijk providerfacturatie met de logs van de AI-gateway om te voorkomen dat een dashboard-bug leidt tot overhaaste productie-ingrepen. Volgende 30 minuten: veilig indammen Pas de meest gerichte controle toe die verdere schade stopt: pauzeer een ontspoorde workflow, begrens agent-concurrency, stuur achtergrondtaken naar batch-verwerking of schakel een recent uitgerolde feature uit. Houd inkomsten-kritiek verkeer beschermd. Vind de oorzaak en sluit af Controleer eerst het volume, daarna modelmix, tokentypes, retries, contextomvang en provider-tarieven. Vergelijk de p50- en p95-kosten per succesvolle taak met de nulmeting. Hef tijdelijke restricties pas op wanneer de run rate en de outputkwaliteit binnen de SLO's vallen. Gerelateerd LLM-kostenmonitoring Budgetbewaking voor AI-agents Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # Beperk token-overhead van MCP-tooldefinities · FinOps LLM URL: https://finopsllm.com/nl/research/mcp-tool-definition-overhead Beperk token-overhead van MCP-tooldefinities Bijgewerkt September 19, 2026 · eerst gepubliceerd September 19, 2026 Kort antwoord: Het koppelen van een AI-agent aan meerdere Model Context Protocol (MCP) servers injecteert duizenden input-tokens bij elke interactieronde voordat het model ook maar één letter van de gebruikersprompt... Het koppelen van een AI-agent aan meerdere Model Context Protocol (MCP) servers injecteert duizenden input-tokens bij elke interactieronde voordat het model ook maar één letter van de gebruikersprompt heeft verwerkt. Elk geregistreerd gereedschap voegt een JSON-schema toe met functienamen, parameterbeschrijvingen en typebeperkingen. In een zakelijke werkomgeving met 6 actieve MCP-servers (GitHub, Postgres, Slack, Jira, web search, bestandssysteem) verbruikt deze statische preamble 4.500 tot 12.000 input-tokens per API-aanroep. Bij een multi-turn taak van 30 interacties verspilt deze redundante overhead $0,35 tot $1,20 per sessie. Drie architecturen om MCP-overhead te elimineren Prompt Caching breekpunten: Plaats statische MCP-tooldefinities vóór de dynamische conversatiehistorie in de prompt en stel een expliciet caching-breekpunt in direct na het tool-blok. Op modellen die prefix caching ondersteunen, verlaagt een cache-hit de kosten van het toolschema na de eerste beurt met 75% tot 90%. Dynamische tweetraps-toolregistratie: Vermijd het globaal injecteren van alle tools. Gebruik een lichtgewicht routeringsmodel om het benodigde domein te detecteren en laad dynamisch uitsluitend de relevante 3 tot 5 toolschema's in de actieve context van de agent. Schemacompressie en minificatie: Strip overbodige witruimte, elimineer markdown-uitleg binnen JSON Schema-strings en vervang langdradige tekstuele instructies door compacte typespecificaties. Dit halveert vaak het tokenverbruik zonder functieselectie te schaden. Gerelateerd Server-tools op aparte factuur Economie van prompt caching Budgetbewaking voor AI-agents Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # Prijsverlagingen verlagen de AI-factuur niet vanzelf · FinOps LLM URL: https://finopsllm.com/nl/research/model-price-cuts-routing-budget Prijsverlagingen en het routeringsbudget Bijgewerkt September 10, 2026 · eerst gepubliceerd September 10, 2026 Kort antwoord: Een daling van tokenprijzen resulteert pas in besparingen wanneer routeringsregels actief worden bijgewerkt naar voordeligere modellen. Een daling van tokenprijzen resulteert pas in besparingen wanneer routeringsregels actief worden bijgewerkt naar voordeligere modellen. Gerelateerd Kosten per voltooide taak Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # AI-observability kan een tweede LLM-factuur worden · FinOps LLM URL: https://finopsllm.com/nl/research/observability-second-llm-bill AI-observability als tweede LLM-factuur Bijgewerkt September 9, 2026 · eerst gepubliceerd September 9, 2026 Kort antwoord: Observability met behulp van AI-modellen verdubbelt snel de totale tokenlast. Beperk de uitgaven via gerichte steekproeven en batch-evaluaties. Observability met behulp van AI-modellen verdubbelt snel de totale tokenlast. Beperk de uitgaven via gerichte steekproeven en batch-evaluaties. Gerelateerd Kostenbeheersing bij evaluaties Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # Opus 5.5 inspanningsniveaus bepalen de werkelijke prijs · FinOps LLM URL: https://finopsllm.com/nl/research/opus-5-5-effort-level-cost Opus 5.5 inspanningsniveaus bepalen de werkelijke prijs Bijgewerkt September 22, 2026 · eerst gepubliceerd September 22, 2026 Claude Opus 5.5 kost $4 per miljoen input-tokens en $20 per miljoen output-tokens. Dat is 20% minder dan Opus 5. Het tarief is slechts het kleinere deel van het kostenplaatje. Het grotere deel is de effort -instelling, die bepaalt hoeveel tokens het model doorbrengt met nadenken voordat het antwoord geeft. Eén model, vijf prijzen Opus 5.5 biedt inspanningsniveaus van low tot medium , high , xhigh en max . Elk niveau is hetzelfde model tegen dezelfde prijs per token, maar produceerde een heel ander aantal tokens. Onafhankelijke benchmarking gerapporteerd door The Decoder bleek dat vier van de vijf niveaus op de kosten-performance Pareto-grens liggen. Het stelde ook vast dat Opus 5.5 bij maximale inspanning ongeveer 119.000 output-tokens per taak gebruikte, veel meer dan concurrerende modellen bij hun maximale instellingen. Tegen $20 per miljoen kosten 119.200 output-tokens $2,38 per taak, nog zonder input. Bij medium mat Artificial Analysis 25.700 output-tokens, ofwel $0,51. Met input erbij kost max $5,98 per taak en medium $1,34: hetzelfde model is door één requestparameter ongeveer 4,5 keer duurder per taak. Gemeten op de Artificial Analysis Intelligence Index v4.3.2 (tien evaluaties), geraadpleegd op 22 september 2026. Alle rijen gebruiken dezelfde testsuite en zijn dus direct vergelijkbaar. Model en inspanning Intelligence Index Kosten per taak Output-tokens per taak Op de kosten-prestatiefrontier Opus 5.5 · low 42.3 $0.55 10,200 Nee Opus 5.5 · medium 51.2 $1.34 25,700 Ja Opus 5.5 · high 53.6 $1.82 35,600 Ja Opus 5.5 · xhigh 56.0 $3.46 65,700 Ja Opus 5.5 · max 57.6 $5.98 119,200 Ja Opus 5 · high (referentie) 48.1 $3.61 46,200 Nee Bron: Artificial Analysis. Op de frontier betekent dat geen enkele instelling van GPT-6 Sol, GPT-6 Astra, Opus 5, Opus 5.5 of Fable 5.1 hoger scoort voor minder geld. Opus 5.5 low valt erbuiten, want GPT-6 Sol op xhigh scoort 44,1 voor $0,53. Van xhigh naar max levert 1,6 punt op voor 73% meer kosten. Medium is de instelling waartegen Anthropic benchmarkt De voornaamste vergelijking van Anthropic wordt gemaakt op standaard-inspanning, namelijk medium. Het zegt dat Opus 5.5 op medium GPT-6 Astra op maximale inspanning verslaat op kenniswerk voor ongeveer een vijfde van de kosten per taak. Dus Anthropics eigen standpunt voor het model is gebouwd op medium, en max is de uitzondering. Een team dat overal max instelt "om veilig te zijn" betaalt voor tokens die de launchbenchmarks niet nodig hadden. Inspanning instellen zonder giswerk Standaard op medium. Maak het een expliciete waarde in code, niet een SDK-standaard die onder u kan veranderen. Verhoog inspanning per route, niet globaal. Moeilijk debuggen, langetermijnplanning en laatste reviewstappen kunnen hoog of max rechtvaardigen. Classificatie, extractie en routinebewerkingen zelden. Log inspanning bij elk verzoek. Kosten per verzoek zijn zonder dit niet interpreteerbaar. Een uitgavenpiek met vlak verzoekvolume is meestal een inspanningswijziging. Vergelijk inspanningsniveaus op dezelfde opnieuw afgespeelde taken. Registreer succespercentage en output-tokens per voltooide taak op elk niveau, en stop met het verhogen van inspanning wanneer succes niet meer verbetert. Beperk output waar het product dit toestaat. Een max-token-limiet stelt het ergste geval in. Bij maximale inspanning is die limiet het enige tussen een weggelopen taak en een verzoek van meerdere dollars. De verlaging van $25 naar $20 per miljoen output-tokens bespaart 20%. Het verplaatsen van een workload van max naar medium inspanning kan veel meer besparen. Behandel inspanning als een begroting, bezeten en gereviseerd als ieder ander. Gerelateerd Claude Opus 5.5 kostenmodel Opus 5.5 fast-mode-economie Gids voor redeneringsnmodelkosten Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # Opus 5.5 fast mode: 2x prijs voor snellere reacties · FinOps LLM URL: https://finopsllm.com/nl/research/opus-5-5-fast-mode-economics Economie van Opus 5.5 fast mode Bijgewerkt September 22, 2026 · eerst gepubliceerd September 22, 2026 Claude Opus 5.5 heeft twee prijslijsten. Standaard is $4 per miljoen invoertokens en $20 per miljoen uitvoertokens. Fast mode is $8 en $40, exact het dubbele, voor tot 2,5× de uitvoersnelheid. Het model is identiek. Het extra geld koopt tijd en niets anders, dus de enige vraag is wiens tijd. Wat de premie koopt Neem een stap die 5.000 uitvoertokens produceert. Bij standaardtarieven kost de uitvoer $0,10. In fast mode kost het $0,20. Als de stap 60 seconden duurt met standaardsnelheid, brengt een 2,5× versnelling het terug tot ongeveer 24 seconden. Je betaalt $0,10 extra om 36 seconden te besparen. Dat komt neer op ongeveer $10 voor elk uur wachttijd dat je elimineert. De staplengte verandert de verhouding niet, omdat de extra kosten en bespaard tijd beide groeien met uitvoertokens. Het hangt af van je standaardsnelheid: dit voorbeeld gaat uit van ongeveer 83 uitvoertokens per seconde. Invoer verdubbelt ook, dus stappen met veel prefix betalen iets meer per seconde bespaard. Wanneer is het goedkoop Een ontwikkelaar die wacht op een interactieve coderingagent. Bij $10 per uur bespaard wachttijd kost fast mode veel minder dan de tijd van iemand die betaald wordt. Een klantgericht antwoord waarbij latentie de conversie beïnvloedt. Zet de snelheidsverbetering af tegen uitval, niet tegen de tokenfactuur. Een incident, waarbij elk moment kosten heeft. Wanneer is het pure verspilling Achtergrondbronnen, nachtelijke taken en batchpijplijnen. Niemand wacht, dus de extra uitgave koopt niets. Evals en replays. Dit zijn precies de workloads die tokentellingen vermenigvuldigen en volgens schema draaien. Subagenten die parallel draaien. Wandtijd wordt bepaald door de langzaamste tak en de orchestrator, niet door elk aanroep. Standaard Opus 5.5 is al ongeveer 30% sneller dan Opus 5, volgens Anthropic. Sommige latentiecomplaints die fast mode op Opus 5 zouden rechtvaardigen, kunnen alleen door de upgrade worden opgelost. Meet de standaardsnelheid voordat je voor meer betaalt. Maatregelen om in te voeren Maak fast mode een expliciete, per-route beslissing. Het mag nooit een globale standaard zijn of een vlag die een ingenieur eenmaal inschakelde en vergat. Markeer uitgaven per modus. Een fast-mode verzoek tegen het dubbele unitprijs ziet er hetzelfde uit als een normaal verzoek op een dashboard dat alleen op model groepeert. Waarschuw voor het fast-mode aandeel van uitvoertokens. Als het stijgt op routes waar geen gebruiker wacht, is iets ingeschakeld dat niet zou moeten. Begroting inspanning en snelheid samen. Maximale inspanning vermenigvuldigt de tokentellingen, en fast mode verdubbelt de prijs van elk token. Dit is de duurste manier om het model uit te voeren. Gerelateerd Claude Opus 5.5 kostenmodel Opus 5.5 inspanningsniveaus zijn de echte prijs Limieten voor fan-out en concurrency van subagenten Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # AI-ROI bewijzen zonder kwaliteitsverlies te verhullen · FinOps LLM URL: https://finopsllm.com/nl/research/prove-ai-roi-measurement AI-ROI bewijzen zonder kwaliteitsverlies te verhullen Bijgewerkt August 27, 2026 · eerst gepubliceerd August 27, 2026 Kort antwoord: AI-ROI wordt niet bewezen door een dalende providerfactuur. Het wordt bewezen wanneer een meetbaar bedrijfsresultaat sterker verbetert dan de integrale kosten die nodig zijn om het te produceren.... AI-ROI wordt niet bewezen door een dalende providerfactuur. Het wordt bewezen wanneer een meetbaar bedrijfsresultaat sterker verbetert dan de integrale kosten die nodig zijn om het te produceren. Betrouwbare meting vereist drie gekoppelde records: toewijsbare kosten, succesvolle resultaten en een kwaliteitscontrole die voorkomt dat verslechterd werk voor winst wordt aangetroffen. Begin met een contrafactische nulmeting Beschrijf wat er zonder de AI-implementatie zou zijn gebeurd: handmatige verwerking, een ouder model of de eerdere workflow. Zonder controlegroep kan omzetgroei of kostenbesparing niet zuiver aan AI worden toegeschreven. Gebruik een uitkomst als noemer Meet de kosten per succesvolle taak in plaats van per API-aanroep. Definieer succes in observeerbare termen zoals een geaccepteerd antwoord of foutloos verwerkte factuur. Reken retries, tool-aanroepen en handmatige correcties mee in de teller. Bewaak de kwaliteitsondergrens Koppel het financiële resultaat altijd aan taaksucces, foutpercentages en latentie. Een kostenbesparing van 25% die het succespercentage van 92% naar 80% verlaagt, is een kwaliteitsverlies en geen ROI-verbetering. Rapporteer een gefundeerde bandbreedte Toon conservatieve, basis- en optimistische scenario's. Reconcilieer de uitgaven met facturen en specificeer welke baten echte kasbesparingen zijn en welke strategische optiewaarde betreffen. Gerelateerd Kosten per succesvolle taak LLM-kostentoewijzing AI-waarneembaarheid Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # Waarom AI-lijstprijzen niet vergelijkbaar zijn · FinOps LLM URL: https://finopsllm.com/nl/research/provider-prices-not-comparable Waarom AI-lijstprijzen niet direct vergelijkbaar zijn Bijgewerkt August 27, 2026 · eerst gepubliceerd August 27, 2026 Kort antwoord: AI-leveranciers vergelijken op basis van de geadverteerde prijs per miljoen tokens creëert schijnbezuinigingen. Leveranciers factureren verschillende tokentypes, cachingregels en tool-calls. Een... AI-leveranciers vergelijken op basis van de geadverteerde prijs per miljoen tokens creëert schijnbezuinigingen. Leveranciers factureren verschillende tokentypes, cachingregels en tool-calls. Een zinvolle vergelijking meet de effectieve kosten per geslaagde taak voor dezelfde werklast en kwaliteitsnorm. Normaliseer de facturatie-eenheid Bouw een prijsmatrix op basis van provider, model, regio, tokentype, cachestatus en batchmogelijkheden. Houd input, output, cache en reasoning tokens gescheiden van vaste commitments. Normaliseer de werklast Voer een vaste steekproef uit met identieke context en succescriteria. Meet p50/p95 latency, voltooiingspercentages, retries en handmatige correcties. Een model dat 30% goedkoper is maar twee keer zoveel retries nodig heeft, is per geslaagde taak duurder. Reken operationele kosten mee Multi-provider arbitrage vergt engineering: gateway-aanpassingen, monitoring, routering en failover-tests. Stuur verzoeken dynamisch naar de goedkoopste provider die aan de kwaliteitseisen voldoet. Gerelateerd LLM provider arbitrage Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # Echte kosten per taak: Opus 5.5 vs Sol, Astra en Fable · FinOps LLM URL: https://finopsllm.com/nl/research/real-cost-per-task-frontier-models Echte kosten per taak bij frontiermodellen Bijgewerkt September 22, 2026 · eerst gepubliceerd September 22, 2026 Lijstprijzen vertellen wat een token kost. Ze vertellen niet wat een afgeronde taak kost, want modellen gebruiken voor hetzelfde werk heel verschillende aantallen tokens. Deze pagina zet gemeten kosten per taak en een kwaliteitsscore naast elkaar voor Claude Opus 5.5, Claude Opus 5, Claude Fable 5.1, GPT-6 Astra en GPT-6 Sol op elk effort-niveau. Elk cijfer heeft een bron en niets is geschat. Het korte antwoord: GPT-6 Sol is de goedkoopste weg naar elke score tot 47,5. Boven 47,5 is Opus 5.5 op elk niveau het goedkoopst. Geen enkele instelling van GPT-6 Astra boven low, van Opus 5 of van Fable 5.1 is kostenefficiënt: elk wordt op score en prijs verslagen door een instelling van Sol of Opus 5.5. Methode Alle scores en kosten komen uit de Artificial Analysis Intelligence Index v4.3.2, geraadpleegd op 22 september 2026. De index draait tien evaluaties: AA-Briefcase, GDPval-AA, AutomationBench-AA, Terminal-Bench 4.0, SciCode, Humanity's Last Exam, GDP.pdf, CritPt, AA-Omniscience en AA-LCR. Artificial Analysis draait elk model op elk effort-niveau via de API van de aanbieder en legt vast wat het tegen lijstprijzen betaalt. Kosten per taak zijn die uitgaven per taak, gesplitst in input en output. Elke rij draait dezelfde suite, dus de rijen zijn direct vergelijkbaar. Voordat u de cijfers leest, gelden twee grenzen. Ten eerste is de index één takenmix. Uw mix verschuift de kosten, en daarom legt de laatste sectie uit hoe u die zelf meet. Ten tweede zijn scores uit verschillende indexversies niet vergelijkbaar, dus meng deze cijfers niet met eerder gepubliceerde waarden. De volledige ladder: 26 instellingen Output-tokens per taak zijn de tokens die het model schrijft, redeneren inbegrepen. Artificial Analysis publiceert geen verdeling tussen input en output voor de vier middelste instellingen van GPT-6 Sol, dus daar staat n/a. Model Effort Intelligence Index Kosten per taak Inputkosten Outputkosten Output-tokens per taak Op de frontier GPT-6 Sol none 28.1 $0.33 $0.28 $0.05 4,900 Nee GPT-6 Sol low 33.9 $0.13 n/a n/a 3,400 Ja GPT-6 Sol medium (standaard) 39.8 $0.25 n/a n/a 6,500 Ja GPT-6 Sol high 42.8 $0.37 n/a n/a 10,200 Ja GPT-6 Sol xhigh 44.1 $0.53 n/a n/a 16,000 Ja GPT-6 Sol max 47.5 $1.06 $0.74 $0.31 31,200 Ja GPT-6 Astra low 45.8 $0.82 $0.60 $0.22 4,400 Ja GPT-6 Astra medium 49.6 $1.54 $1.06 $0.48 9,600 Nee GPT-6 Astra high 50.9 $1.73 $1.13 $0.59 11,800 Nee GPT-6 Astra xhigh 52.4 $2.31 $1.46 $0.85 16,900 Nee GPT-6 Astra max 52.7 $3.26 $1.90 $1.36 27,200 Nee Claude Opus 5 low 39.4 $1.10 $0.73 $0.37 14,700 Nee Claude Opus 5 medium 44.8 $2.19 $1.47 $0.72 29,000 Nee Claude Opus 5 high (standaard) 48.1 $3.61 $2.46 $1.16 46,200 Nee Claude Opus 5 xhigh 49.7 $4.88 $3.36 $1.52 60,700 Nee Claude Opus 5 max 50.8 $5.86 $4.05 $1.81 72,500 Nee Claude Opus 5.5 low 42.3 $0.55 $0.35 $0.20 10,200 Nee Claude Opus 5.5 medium (standaard) 51.2 $1.34 $0.82 $0.51 25,700 Ja Claude Opus 5.5 high 53.6 $1.82 $1.11 $0.71 35,600 Ja Claude Opus 5.5 xhigh 56.0 $3.46 $2.15 $1.31 65,700 Ja Claude Opus 5.5 max 57.6 $5.98 $3.60 $2.38 119,200 Ja Claude Fable 5.1 low 46.8 $2.37 $1.30 $1.08 21,600 Nee Claude Fable 5.1 medium 48.9 $2.98 $1.59 $1.39 27,900 Nee Claude Fable 5.1 high 51.2 $3.91 $2.01 $1.90 38,100 Nee Claude Fable 5.1 xhigh 53.2 $5.98 $2.96 $3.02 60,500 Nee Claude Fable 5.1 max 53.4 $7.63 $3.73 $3.90 78,100 Nee Op de frontier betekent dat geen andere instelling in deze tabel hoger scoort voor minder geld. De kostenfrontier Tien van de 26 instellingen liggen op de frontier. Gesorteerd op kosten zijn dit de enige die puur op prijs het overwegen waard zijn. Alle andere betalen meer voor dezelfde of een lagere score. Instelling Intelligence Index Kosten per taak Per 10.000 taken GPT-6 Sol · low 33.9 $0.13 $1,300 GPT-6 Sol · medium 39.8 $0.25 $2,500 GPT-6 Sol · high 42.8 $0.37 $3,700 GPT-6 Sol · xhigh 44.1 $0.53 $5,300 GPT-6 Astra · low 45.8 $0.82 $8,200 GPT-6 Sol · max 47.5 $1.06 $10,600 Claude Opus 5.5 · medium 51.2 $1.34 $13,400 Claude Opus 5.5 · high 53.6 $1.82 $18,200 Claude Opus 5.5 · xhigh 56.0 $3.46 $34,600 Claude Opus 5.5 · max 57.6 $5.98 $59,800 De frontier heeft twee zones. Van $0,13 tot $1,06 is het bijna alleen GPT-6 Sol, met GPT-6 Astra low op $0,82 als enige uitzondering. Vanaf $1,34 is het alleen Opus 5.5. De stap tussen beide is klein: Opus 5.5 medium scoort 3,7 punten meer dan Sol max voor $0,28 meer per taak. Head-to-head bij gelijke of betere score Elk paar vergelijkt een goedkopere instelling met een duurdere die gelijk of lager scoort. Goedkopere instelling Duurdere instelling Scoreverschil Besparing Opus 5.5 medium: 51.2, $1.34 Opus 5 high: 48.1, $3.61 +3.1 voor Opus 5.5 63% Opus 5.5 medium: 51.2, $1.34 Opus 5 max: 50.8, $5.86 +0.4 voor Opus 5.5 77% Opus 5.5 medium: 51.2, $1.34 Fable 5.1 high: 51.2, $3.91 gelijk 66% Opus 5.5 high: 53.6, $1.82 GPT-6 Astra max: 52.7, $3.26 +0.9 voor Opus 5.5 44% Opus 5.5 high: 53.6, $1.82 Fable 5.1 max: 53.4, $7.63 +0.2 voor Opus 5.5 76% GPT-6 Sol max: 47.5, $1.06 Opus 5 high: 48.1, $3.61 +0.6 voor Opus 5 71% De rij van Opus 5 is belangrijk voor teams die nog niet zijn gemigreerd. Opus 5 draaide standaard op high. Opus 5.5 draait standaard op medium en scoort daar 3,1 punten meer voor 63% minder per taak. Anthropic zegt dat Opus 5.5 40% goedkoper is dan Opus 5; het gemeten verschil op deze index is groter dan die claim. Waar het geld heen gaat: input, niet output Bij elk model is input ongeveer de helft tot driekwart van de kosten per taak. Bij Opus 5.5 op medium is $0,82 van de $1,34 input, ofwel 61%. Bij GPT-6 Astra op max is het 58%, bij GPT-6 Sol op max 70% en bij Fable 5.1 op max 49%. Agenttaken sturen hun groeiende context bij elke stap opnieuw mee, dus de inputkosten groeien met het aantal stappen en niet alleen met de lengte van het antwoord. Daarom kost GPT-6 Sol zonder redeneren meer dan op low: $0,33 tegen $0,13, terwijl het maar 4.900 output-tokens schrijft. $0,28 van de $0,33 is input. De waarschijnlijke oorzaak is meer stappen, die elk de context opnieuw meesturen. Redeneren uitzetten maakt een agent niet goedkoper als hij daarna meer beurten nodig heeft. Voor uw rekening betekent dit dat caching even zwaar weegt als de modelkeuze. Opus 5.5 en GPT-6 Sol rekenen $0,20 per miljoen gecachte input-tokens. GPT-6 Astra rekent $1,00 en Opus 5 $0,50. Tokenvolume tegenover lijstprijs GPT-6 Astra is hier het zuinigste model met tokens. Op max schrijft het 27.200 output-tokens per taak, tegen 119.200 bij Opus 5.5 max. Maar Astra rekent $10 en $50 per miljoen, 2,5× het tarief van Opus 5.5. De lijstprijs wint: Opus 5.5 high kost $1,82 per taak en scoort 53,6, terwijl Astra max $3,26 kost en 52,7 scoort. Opus 5.5 op max is de enige plek waar breedsprakigheid pijn doet. De 119.200 output-tokens kosten $2,38 vóór enige input, en de hele taak kost $5,98. Dat levert de hoogste score in de tabel op, 57,6, maar tegen 4,5× de kosten van medium. Afnemende meeropbrengst per effort-niveau Elke rij toont wat één effort-niveau hoger oplevert, in indexpunten tegenover de extra kosten per taak. Model medium → high xhigh → max GPT-6 Sol +3.0 punten voor +48% +3.4 punten voor +100% GPT-6 Astra +1.3 punten voor +12% +0.3 punten voor +41% Claude Opus 5 +3.3 punten voor +65% +1.1 punten voor +20% Claude Opus 5.5 +2.4 punten voor +36% +1.6 punten voor +73% Claude Fable 5.1 +2.3 punten voor +31% +0.2 punten voor +28% Bij Fable 5.1 en GPT-6 Astra levert max bijna niets op: 0,2 en 0,3 punt voor 28% en 41% meer. Bij Opus 5.5 levert de stap naar max nog 1,6 punt op, maar tegen 73% meer kosten. Gebruik max alleen voor taken waarvan u hebt gemeten dat de extra punten de uitkomst veranderen. Wanneer GPT-6 Sol max genoeg is De index is een gemiddelde, en het verschil tussen Sol max en Opus 5.5 medium is niet overal gelijk. Scores per evaluatie volgens Artificial Analysis: Evaluatie Opus 5.5 medium ($1.34) GPT-6 Sol max ($1.06) Terminal-Bench 4.0 52.5 43.9 AutomationBench-AA 61.2 61.6 GDPval-AA (Elo) 1576 1487 AA-Briefcase (Elo) 1642 1483 Humanity's Last Exam 54.7 47.9 SciCode 59.3 57.6 CritPt 27.7 30.9 AA-LCR 84.3 83.7 Op AutomationBench en CritPt evenaart of verslaat GPT-6 Sol Opus 5.5 op medium, voor $1,06 per taak tegen $1,34. Op Terminal-Bench, de kenniswerk-evaluaties en Humanity's Last Exam ligt Opus 5.5 ruim voor. Workflowautomatisering kan op Sol draaien. Terminal- en codeeragents en documentzwaar kenniswerk zijn waar Opus 5.5 zijn prijs waard is. Cijfers van de leverancier tegenover onafhankelijke cijfers Cijfers van leveranciers en onafhankelijke cijfers verschillen vaak, omdat ze andere harnesses en instellingen gebruiken. Anthropic meldt 66,4% op Terminal-Bench 4.0 voor Opus 5.5 op xhigh. Artificial Analysis meet 59,6% op hetzelfde niveau. Effort Opus 5.5 Fable 5.1 low 31.3% 40.4% medium 52.5% 44.9% high 56.6% 52.0% xhigh 59.6% 55.1% max 59.6% 52.0% Ook de ranglijst verschilt per index. In de Vals AI Index staat Fable 5.1 eerste met 68,83%, GPT-6 Astra derde met 66,61% en Opus 5.5 vierde met 66,16%. Kosten per taak worden daar niet op dezelfde basis gepubliceerd, dus dit verschuift de frontier hierboven niet. Eén index is maar één blik. Lijstprijzen en een cache-zware taak Digital Applied heeft één cache-zware agenttaak op elk model doorgerekend: 8M cache-leestokens, 400K niet-gecachte input, 600K cache-schrijftokens en 300K output-tokens. Het resultaat volgt de frontier, met een extra straf voor GPT-6 Astra. Model Input $/MTok Output $/MTok Cache lezen $/MTok Cache-zware taak (Digital Applied) GPT-6 Sol $2.00 $10.00 $0.20 $6.90 Claude Opus 5.5 $4.00 $20.00 $0.20 $12.20 Claude Opus 5 $5.00 $25.00 $0.50 $17.25 Claude Fable 5.1 $10.00 $50.00 $0.25 $28.50 GPT-6 Astra (≤272K) $10.00 $50.00 $1.00 $34.50 GPT-6 Astra (>272K) $20.00 $75.00 n/a $61.50 GPT-6 Astra rekent het hele verzoek af tegen $20 en $75 per miljoen zodra de input boven 272K tokens komt. Opus 5.5 houdt één prijs over zijn hele venster van 1M tokens. Bij Opus 5.5 kosten cache-schrijfacties $5 per miljoen voor de cache van 5 minuten en $8 voor die van 1 uur, batchtaken kosten 50% en de snelle modus verdubbelt de prijs. Zie voor details het Kostenmodel voor Claude Opus 5.5 en de Economie van de snelle modus van Opus 5.5 . Zo meet u uw eigen kosten per taak Log tokens per taak, niet per verzoek: niet-gecachte input, gecachte input, cache-schrijfacties en output, opgeteld over alle stappen van de taak. Neem een steekproef van een paar honderd echte taken en speel die opnieuw af op twee of drie kandidaat-instellingen, bijvoorbeeld Sol max, Opus 5.5 medium en Opus 5.5 high. Beoordeel elk resultaat met dezelfde controle als in productie en tel de geslaagde taken. Deel de totale uitgaven door het aantal geslaagde taken. Kosten per geslaagde taak zijn het getal om te vergelijken, want een goedkope instelling die vaker faalt is niet goedkoop. Kies de goedkoopste instelling die uw kwaliteitslat haalt en stuur alleen mislukte taken door naar een hogere instelling. Herhaal de test wanneer een prijs of een standaard-effort verandert. Hoe effort-niveaus de rekening van één model veranderen, leest u in De effort-niveaus van Opus 5.5 zijn de echte prijs . Kanttekeningen Alle kosten zijn tegen API-lijstprijzen op de takenmix van Artificial Analysis. Kortingen, batchprijzen en uw eigen caching veranderen ze. Artificial Analysis labelt zijn vermeldingen voor Opus 5.5 en Fable 5.1 als Default Fallback. Lees de methodologie voordat u elke rij als dezelfde API-configuratie behandelt. De scores komen alleen uit indexversie v4.3.2. Eerdere versies gebruikten andere evaluaties en zijn niet vergelijkbaar. De cache-zware taak van Digital Applied is een illustratieve werklast, geen meting. De cijfers veranderen wanneer aanbieders prijzen of standaarden wijzigen. De raadpleegdatum is 22 september 2026. Bronnen Artificial Analysis Intelligence Index Artificial Analysis: Claude Opus 5.5 Artificial Analysis: Claude Opus 5 Artificial Analysis: Claude Fable 5.1 Artificial Analysis: GPT-6 Astra Artificial Analysis: GPT-6 Sol Digital Applied: GPT-6 Sol vs Claude Opus 5.5 cost benchmarks Digital Applied: Claude Opus 5.5 vs GPT-6 Astra Digital Applied: Is Claude Fable 5.1 still worth it? Digital Applied: Claude Opus 5.5 launch pricing and benchmarks Digital Applied: Opus 5.5 vs Grok 4.7 vs Muse Spark 1.3 cost per task Gerelateerd Kostenmodel voor Claude Opus 5.5 De effort-niveaus van Opus 5.5 zijn de echte prijs Economie van de snelle modus van Opus 5.5 Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # De stille kostprijs van de retry-loop in LLM's · FinOps LLM URL: https://finopsllm.com/nl/research/retry-loop-hidden-spend De stille kostprijs van de retry-loop in LLM's Bijgewerkt August 27, 2026 · eerst gepubliceerd August 27, 2026 Kort antwoord: Een retry is geen gratis vorm van veerkracht. Het is een volwaardige nieuwe modelaanroep, en een autonome agent kan één tijdelijke fout ongemerkt omzetten in vijf betaalde pogingen voordat er... Een retry is geen gratis vorm van veerkracht. Het is een volwaardige nieuwe modelaanroep, en een autonome agent kan één tijdelijke fout ongemerkt omzetten in vijf betaalde pogingen voordat er überhaupt een foutmelding verschijnt. De eerste noodzakelijke beheersmaatregel is het kwantificeren van de retry-belasting (retry tax) : de uitgaven aan herhaalpogingen en fallbacks gedeeld door de totale inferentiekosten, gesegmenteerd per workflow en storingsreden. Registreer de volledige boomstructuur van pogingen Log het hoofdverzoek, het pogingnummer, de provider, het model, de toolcall, de latentie, de foutklasse, de tokens en de uiteindelijke uitkomst. Een enkelvoudig request-ID schiet tekort zodra een toolcall een geneste modelaanroep start. Leg ouder-kindrelaties vast zodat een complete gebruikerstaak als een boomstructuur gereconstrueerd kan worden. Scheid nuttige van verspillende retries Het opnieuw proberen bij een rate-limit kan een waardevolle transactie redden. Het opnieuw proberen van een validatiefout met exact dezelfde prompt resulteert vrijwel altijd in een identieke mislukking. Een provider-timeout, foutieve JSON-invoer, contextoverloop en kwaliteitsafwijzingen vereisen elk een specifiek protocol met een strikt pogingsmaximum. Stel budgetplafonds in op de lusgrenzen Hanteer een tokenplafond per verzoek, een financieel plafond per workflow en een maximale looptijd in seconden. Een zacht plafond kan routeren naar een lichter model; een hard plafond stopt de lus onmiddellijk en retourneert een herstelbare status. Gerelateerd Budgetbewaking voor AI-agents LLM-kostenmonitoring Kosten per geslaagde taak Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # SaaS AI-credits: een ongrijpbare eenheid meten · FinOps LLM URL: https://finopsllm.com/nl/research/saas-ai-credits-metering SaaS AI-credits: een ongrijpbare eenheid meten Bijgewerkt September 2, 2026 · eerst gepubliceerd September 2, 2026 Kort antwoord: Cloud FinOps leunt op transparante eenheden: een serveruur, een API-aanroep of een gigabyte. Een AI-credit van een SaaS-leverancier is dat niet. Het is een eenheid die door de leverancier wordt... Cloud FinOps leunt op transparante eenheden: een serveruur, een API-aanroep of een gigabyte. Een AI-credit van een SaaS-leverancier is dat niet. Het is een eenheid die door de leverancier wordt gedefinieerd, geprijsd en tussentijds kan worden gewijzigd. De kosten gedragen zich als consumptie, maar zonder de dashboards en tooling die consumptie beheersbaar maken. Drie eigenschappen die traditioneel beheer breken Ondoorzichtige eenheden: Twee functies kunnen enorm verschillende credits verbruiken voor wat de gebruiker ervaart als dezelfde taak. Gedwongen overschrijdingstarieven: Meerverbruik wordt eenzijdig door de vendor geprijsd; werklast verplaatsen naar een goedkoper alternatief is onmogelijk. Verlopende tegoeden: Licentiegebonden tegoeden kunnen niet worden samengevoegd of meegenomen, waardoor u overage betaalt voor het ene team terwijl tegoed bij een ander verdampt. Meet het in eigen beheer Haal gebruiksdata periodiek op via de admin-API van de leverancier en sla deze op per gebruiker, team en functionaliteit. Het vendor-dashboard toont alleen de lopende periode; uw FinOps-vragen gaan over historische trends. Alloceer vóór de factuur Wijs credits toe aan dezelfde kostenplaatsen die u gebruikt voor cloud showback. Niet-gealloceerde uitgaven belanden automatisch bij IT of platform teams — precies de afdelingen die het verbruik niet bepalen. Gerelateerd Shadow AI op zakelijke creditcards Rate limits als kostenbeheersing Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # Servertools vallen buiten de standaard tokenmeter · FinOps LLM URL: https://finopsllm.com/nl/research/server-tools-are-a-separate-invoice Servertools vallen buiten de standaard tokenmeter Bijgewerkt September 1, 2026 · eerst gepubliceerd September 1, 2026 Kort antwoord: De meeste LLM-kostenmodellen hanteren één meter: tokens in, tokens uit, prijs per miljoen. Dat model volstond toen een verzoek uitsluitend tekst genereerde. Het werd ontoereikend op het moment dat... De meeste LLM-kostenmodellen hanteren één meter: tokens in, tokens uit, prijs per miljoen. Dat model volstond toen een verzoek uitsluitend tekst genereerde. Het werd ontoereikend op het moment dat server-side tools hun intrede deden. Web search, web fetch en code-executie draaien op de infrastructuur van de provider, en verschillende tools brengen een vaste toeslag per aanroep in rekening bovenop de geproduceerde tokens. Eén enkele interactieronde kan daardoor dubbel factureren: eenmaal voor de zoekopdrachten zelf, en nogmaals voor de tokens die de zoekresultaten aan de context toevoegen. Het compounding-effect De tweede kostenpost wordt stelselmatig over het hoofd gezien. Elk toolresultaat wordt toegevoegd aan de conversatiehistorie, en elke volgende turn verstuurt die complete payload opnieuw als input-tokens. Tien zoekopdrachten vroeg in een agent-run zijn niet slechts tien tariefposten — het zijn tien toeslagen plus de payloads die bij elke volgende stap opnieuw worden belast. Drie bewezen beheersmaatregelen Begrens het aantal toolcalls per run: Een hard plafond op zoekopdrachten per gebruikersverzoek begrenst beide kostenposten gelijktijdig. Workflows die de limiet van tien overschrijden zitten vrijwel altijd in een oneindige lus. Kort payloads in vóór contextinjectie: U heeft zelden een volledige webpagina nodig. Door resultaten samen te vatten voordat ze worden toegevoegd, verlaagt u de kosten van elke opeenvolgende turn. Cache het stabiele prompt-voorvoegsel: Als de systeemprompt en gereedschapsdefinities constant blijven, elimineert prompt caching de grootste herhalende kostenpost. Gerelateerd Economie van prompt caching Kosten per verzoek als product-KPI LLM-kostentoewijzing Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # Afgebroken streaming kost nog steeds volledig geld · FinOps LLM URL: https://finopsllm.com/nl/research/streaming-abandoned-generations-cost Streaming en kosten van verlaten generaties Bijgewerkt September 9, 2026 · eerst gepubliceerd September 9, 2026 Kort antwoord: Het sluiten van een tabblad stopt de modelaanroep niet zonder expliciet signaal. Voorkom onzichtbaar tokenverlies via AbortController. Het sluiten van een tabblad stopt de modelaanroep niet zonder expliciet signaal. Voorkom onzichtbaar tokenverlies via AbortController. Gerelateerd Verborgen kosten bij retry-loops Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # Beheers subagent-fan-out en tokenbudget-uitputting · FinOps LLM URL: https://finopsllm.com/nl/research/subagent-fan-out-concurrency-limits Beheers subagent-fan-out en tokenbudget-uitputting Bijgewerkt September 19, 2026 · eerst gepubliceerd September 19, 2026 Kort antwoord: Subagent fan-out cascades ontstaan wanneer een autonome orchestrator een hoofdtaak opsplitst in parallelle subtaken en worker-agents toestaat om op hun beurt nieuwe gespecialiseerde agents te... Subagent fan-out cascades ontstaan wanneer een autonome orchestrator een hoofdtaak opsplitst in parallelle subtaken en worker-agents toestaat om op hun beurt nieuwe gespecialiseerde agents te initialiseren. Zonder strikte concurrency- en dieptegrenzen kan één ambigue prompt leiden tot een exponentiële explosie: 1 root-supervisor creëert 6 domain-planners, die elk 4 research-agents aanroepen, welke vervolgens sub-workers spawnen. In productieomgevingen verbruikt ongecontroleerde recursieve delegatie binnen 5 minuten 2.000.000 tot 8.000.000 tokens, wat leidt tot onverwachte API-pieken van $15 tot $80 voor één transactie. Vier essentiële productiebeschermingen voor multi-agent fleets Maximale recursiediepte (Depth Caps): Hanteer een strikt plafond voor de uitvoeringshiërarchie. In 95% van de enterprise-toepassingen volstaat een dieptelimiet van max_depth: 2 (Root Supervisor → Worker Agent). Verbied workers om zelfstandig tertiaire subagents te starten zonder expliciete uitzonderingspolicy. Gedeelde thread-tokenpools: Wijs subagents geen autonome budgetten toe. Ken één centrale tokenlimiet (bijv. 250.000 tokens) toe aan de root-context en geef het resterende saldo door via trace-context-headers. Zodra de centrale pool leeg is, termineren alle parallelle takken onmiddellijk. Concurrency-circuitbreakers: Beperk actieve parallelle subagents tot maximaal 3 tot 5 gelijktijdige processen. Wachtrij-aanroepen sequentieel af wanneer de limiet wordt overschreden. Gedistribueerde tracing via OTLP: Injecteer OpenTelemetry trace-ID's over alle inter-agent berichtenbussen om branch-specifieke kostendivergentie realtime te identificeren. Gerelateerd De drie agentbudgetten LLM-kostenspike runbook Herhaallussen en verborgen kosten Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # De drie runtime-budgetten voor autonome AI-agents · FinOps LLM URL: https://finopsllm.com/nl/research/three-agent-budgets De drie runtime-budgetten voor autonome AI-agents Bijgewerkt August 27, 2026 · eerst gepubliceerd August 27, 2026 Kort antwoord: Een autonome agent heeft meer nodig dan een maandelijkse budgetnotificatie. Er zijn drie geneste budgetten vereist binnen de executielus: een verzoekbudget voor één afzonderlijke modelaanroep, een... Een autonome agent heeft meer nodig dan een maandelijkse budgetnotificatie. Er zijn drie geneste budgetten vereist binnen de executielus: een verzoekbudget voor één afzonderlijke modelaanroep, een workflowbudget voor de gehele taak, en een dagbudget voor het team of de tenant. Elk niveau voorkomt een andere foutmodus. 1. Verzoekbudget Het verzoekbudget begrenst tokens, tool-fan-out, latentie of kosten per individuele poging. Het beschermt tegen buitenproportionele context, breedsprakige output of recursieve toolcalls. Dwing dit af vóór de provideraanroep en vóór tooluitvoering. Een zachte limiet kan downgraden naar een lichter model; een harde limiet weigert de poging met een expliciete reden. 2. Workflowbudget Het workflowbudget bewaakt de intentie van de gebruiker over interactierondes, retries, fallbacks en subagents heen. Het vereist een correlatie-ID en een centraal logboek, geen proces-lokale teller. Stop zodra het totaalplafond wordt overschreden, zelfs als elke individuele aanroep binnen de perken bleef. Dit vangt oneindige lussen en te diepe delegatieboomstructuren op. 3. Dagbudget Het dagbudget beperkt de geaggregeerde uitgaven voor een team, tenant of service-account. Het fungeert als blast-radius-controle en waarborgt eerlijke verdeling. Wanneer het limiet nadert, kan niet-urgent werk worden omgeleid naar batch-API's of goedkopere modellen, terwijl capaciteit voor vitale flows behouden blijft. Maak budgetweigeringen bruikbaar Een weigering moet specificeren welk budget is overschreden, hoeveel is verbruikt en welk herstelpad mogelijk is. Retourneer een hervatbare status in plaats van een lege reactie. Registreer onveranderlijke audit-events voor elke reservering, uitgave en weigering ten behoeve van financiële reconciliatie. Gerelateerd Budgetbewaking voor AI-agents LLM-budgetgovernance Kosten per geslaagde taak Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # Tokenprijzen daalden, maar de LLM-factuur steeg · FinOps LLM URL: https://finopsllm.com/nl/research/token-prices-bill-keeps-rising Tokenprijzen daalden, maar de LLM-factuur steeg Bijgewerkt August 27, 2026 · eerst gepubliceerd August 27, 2026 Kort antwoord: Lagere tokenprijzen zijn geen garantie voor een lagere LLM-factuur. In productie groeit het verbruik vaak sneller dan tarieven dalen: langere contextvensters, meer agent-stappen, omvangrijkere... Lagere tokenprijzen zijn geen garantie voor een lagere LLM-factuur. In productie groeit het verbruik vaak sneller dan tarieven dalen: langere contextvensters, meer agent-stappen, omvangrijkere outputs, retries en nieuwe features wissen een prijsdaling van 40% moeiteloos uit. De werkelijke diagnose draait niet om welke provider het goedkoopst is, maar om variantie over vier assen: tarief, volume, mix en efficiëntie. Tarief is slechts één factor Stel dat een provider de gemiddelde prijs verlaagt van $10 naar $6 per miljoen tokens. Als het maandelijkse verbruik stijgt van 100 miljoen naar 220 miljoen tokens, stijgt de factuur van $1.000 naar $1.320. De prijs daalde met 40%; de factuur steeg met 32%. Een dashboard dat louter de prijs per token toont noemt dit een overwinning, terwijl finance het tegenovergestelde ziet. Volume, mix en efficiëntie Volume weerspiegelt het totaal aantal verbruikte tokens. Mix toont waar de tokens naartoe gingen: een geavanceerd redeneermodel, een andere regio of een context-intensieve feature kan de factuur verhogen bij een gelijk aantal verzoeken. Efficiëntie is de kostprijs om één bruikbaar resultaat te leveren: retries, mislukte toolcalls, overmatige prompts en tekst die gebruikers nooit lezen. Wekelijkse variantiebrug Bouw wekelijks een brug vanaf de vorige factuurperiode. Pas tariefwijzigingen toe, vervolgens volume, modelmix en efficiëntieverschuivingen. Alarmeer op de verkeersgewogen kosten per geslaagde taak en optimaliseer de categorie waar de grootste absolute kostenstijging optreedt. Gerelateerd LLM-kostenmonitoring Kosten per verzoek als product-KPI LLM-kostentoewijzing Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # Wat is DeepSeek Harness? Architectuur & gids · FinOps LLM URL: https://finopsllm.com/nl/research/what-is-deepseek-harness Wat is DeepSeek Harness? Architectuur & kosten Bijgewerkt August 16, 2026 · eerst gepubliceerd August 16, 2026 Kort antwoord: DeepSeek Harness — pakketnaam dsh — is een open-source agent-harness uitgebracht door DeepSeek AI onder de MIT-licentie. Dit is de essentiële gids: wat het is, hoe u het start, hoe het is opgebouwd en... DeepSeek Harness — pakketnaam dsh — is een open-source agent-harness uitgebracht door DeepSeek AI onder de MIT-licentie. Dit is de essentiële gids: wat het is, hoe u het start, hoe het is opgebouwd en waarom het belangrijk is voor AI FinOps. Het cruciale verschil tussen model en harness Een taalmodel genereert alleen tekst en tool-aanroepen. Alles wat een agent bruikbaar maakt in productie wordt verzorgd door de harness: het samenstellen van prompts, uitvoeren van tools, afdwingen van security-beleid, sessielogging, beslissingslussen en coördinatie van sub-agents. Twee teams die exact hetzelfde model gebruiken, kunnen drastisch verschillende facturen en resultaten zien afhankelijk van hun harness-architectuur. Plugin-gedreven architectuur DeepSeek Harness draait op Cordis , een runtime waarin elk onderdeel een plugin is: de modeladapter, tool-registry, sessielogging en de agent-lus zelf. Hierdoor kan elk component vervangen worden zonder de core repository te forken. Installatie en headless modus De snelste manier om te testen is via de lokale web-UI: npx @deepseek-ai/dsh web Voor CI/CD en automatisering is de headless modus essentieel: pnpm dsh --profile headless "summarize this workspace" Exploitatiekosten en governance De software is gratis onder MIT-licentie, maar token-inferentie wordt per eenheid betaald. Uw uiteindelijke rekening hangt af van het aantal iteraties per beurt, het aantal geregistreerde tools en circuit breakers tegen oneindige lussen. Gerelateerd Installatiehandleiding en profielen Plugin-architectuur en runtime Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit → Terug naar finopsllm.com --- # Pricing · FinOps LLM · Paid on verified savings URL: https://finopsllm.com/pricing Pricing There is no licence fee, no seat count and no platform minimum, because there is no platform being sold. This is people doing work on your bill, and the fee is a share of the reduction they produce, verified against the invoice your provider sends you. The short version: free audit, then 15-25% of verified monthly savings, measured against a baseline locked before anything changes. No savings, no fee. Thirty days notice. Minimum engagement is $20k/month of LLM spend. Book the audit . The audit is free and it is a real deliverable The first stage costs nothing and ends with a written document: spend broken down by model, workload and team, the drivers behind it, and a ranked savings list with an effort cost against each item. About a week from the point read-only exports are available. You can take that document and implement all of it in-house. Plenty of platform teams do, and that is a legitimate outcome rather than a failed sales cycle. The audit is free because a proposal written without seeing the invoice is guesswork, and because a team that reads its own numbers and decides it does not need help was never going to be a good engagement. Then 15-25% of verified savings If you engage us to implement, the fee is a share of the reduction, billed each period, for as long as the reduction holds. Where it lands in the band depends on how much of the implementation sits with us rather than your engineers, and on the term. Nearer 15% when your team implements against our specifications and we review, measure and verify. Nearer 25% when we write and operate the routing, caching and batching changes and carry the on-call for them. In a period where the bill does not fall, the fee is zero. That is not a guarantee in the marketing sense, it is what a percentage of zero is. What verified means, precisely The model collapses if the baseline is soft, so this is the part worth reading slowly. The baseline is locked before any change ships and countersigned by both sides. It is built from raw provider invoices, not from a dashboard either side controls. It is normalised for volume. Savings are measured as cost per unit of work - per request, per conversation, per document processed - so a quiet period is not billed as an optimisation and a growth period does not erase one. Provider price cuts are excluded. A list-price drop lowers your bill without raising our fee. Reconciliation runs against the invoice each period and the statement shows the arithmetic. A line you dispute comes out until it is resolved. What is deliberately not priced separately Charging for these individually would create incentives we do not want, so they are included. The audit and the readout call. Re-measurement after a provider price change or a model deprecation. Handover. Routing rules, configurations and the measurement setup are yours and stay yours when the engagement ends. One thing genuinely is not included: no dashboard is licensed to you. If continuous cost observability is something you want to own and operate, that is a separate product with separate pricing, and it does not require an engagement. The incentive problems, stated plainly Performance pricing has two well-known failure modes and naming them is fairer than hoping you do not. It rewards cutting cost over holding quality. The control: quality SLOs agreed per endpoint before anything ships, every change A/B tested for at least seven days, automatic rollback on regression - which takes the associated fee with it. A saving that degraded the product is not a saving and is not billed as one. It rewards a high baseline. The control: the baseline comes from invoices you already received before we arrived. There is no version of that number we get to draw. When a fixed fee fits better Performance pricing is wrong for some shapes of work. A one-off migration, an architecture review, or building out attribution and chargeback for a finance team is scoped work with a defined end, so it gets a fixed fee agreed up front. The percentage model is for ongoing optimisation of a live bill. Next step: the audit costs nothing and ends with a number you can act on with or without us. Book a call , or email hello@finopsllm.com with your monthly spend and provider mix. Back to FinOps LLM FAQ Why is there a $20k monthly minimum? Below roughly that level a realistic percentage of a realistic saving does not cover the hours the work takes. Under the minimum the research library, cost calculator and pricing tracker are free and cover most of the same ground. What happens to the fee if savings decay after implementation? The fee decays with them. It is tied to the measured reduction in each billing period rather than to a projection made at signing, so a saving that stops being real stops being billable. Do provider price cuts count as savings you bill for? No. When a provider drops a list price your bill falls and our fee does not rise, because that reduction was not produced by any work on our side. It is excluded from the reconciliation. Is there a lock-in period or a platform licence? Neither. Thirty days notice on either side, and there is no software licence because this is an engagement rather than a product. Configurations and measurement setup stay yours afterwards. --- # Privacy Policy · FinOps LLM · What We Collect and Retain URL: https://finopsllm.com/privacy Privacy FinOps LLM collects information you choose to send through our contact form or API, by email, or through booking flows, plus basic site analytics. FinOps LLM is the data controller for that data; reach us at hello@finopsllm.com . After you consent via our cookie banner, we use Google Analytics 4 to collect anonymized page-view data (page URL, referrer, approximate location, browser, device type; IP addresses are anonymized by GA4), and Microsoft Clarity to understand how visitors use this site through behavioral metrics, heatmaps, and session replay. Clarity sets cookies and captures usage data (such as clicks, scrolling, and pages viewed); by default it masks sensitive content such as form inputs. This data is processed by Microsoft in accordance with the Microsoft Privacy Statement . Neither analytics tool loads until you accept — decline, or use , to opt out. You can also use your browser's "Do Not Track" / global privacy control settings or block cookies. For audit work, the default scope is read-only billing and usage metadata. Prompt and output content is not required for baseline attribution and is only reviewed with explicit approval for a specific optimization. To request access, correction, export, or deletion, email hello@finopsllm.com . What we collect and why Information you send us — the contact form and API collect your name, work email, company, topic, and message. We use these details to route your request and reply. Email and booking flows may collect information you choose to provide there. Please do not send passwords, API keys, or customer data through the contact form. Site analytics — the anonymized page-view and usage data described above, collected only after you accept the cookie banner. Used to understand which pages are read. Engagement data — for customers, the billing and usage metadata needed for the audit, under the terms of the separate written agreement that governs it. Legal basis Analytics and session replay — your consent (GDPR Art. 6(1)(a)), given through the cookie banner and withdrawable at any time. Replying to you and running an engagement — performance of a contract, or steps taken at your request before entering one (Art. 6(1)(b)). Security and records we are required to keep — our legitimate interests and our legal obligations (Art. 6(1)(f) and (c)). Cookies Nothing but the first cookie below is set until you accept. finops_consent — strictly necessary, set by us for 12 months to remember whether you accepted or rejected. Set whichever you choose; without it we'd have to ask on every page. _ga , _ga_* — Google Analytics 4, up to 2 years, aggregate traffic measurement. Only after you accept. _clck , _clsk , CLID , MUID , ANONCHK , SM — Microsoft Clarity, from one session up to 1 year, heatmaps and session replay. Only after you accept. International transfers Google Analytics 4 and Microsoft Clarity are operated by companies in the United States, so accepting analytics cookies means your website usage data is transferred outside the EEA. Those transfers rely on the EU Standard Contractual Clauses together with each provider's certification under the EU–US Data Privacy Framework. Engagement data is stored in the region agreed with you; where that is outside the EEA, the Standard Contractual Clauses in our DPA apply. Email us for a copy of the safeguards. How long we keep it Contact form submissions are delivered as email and follow the same handling as contact emails. Contact emails are retained while the conversation is active and for a reasonable period afterwards for business records. Analytics data follows the retention settings of the providers named above — GA4 retains event data for 14 months and Clarity retains recordings for 30 days. Customer engagement data is retained for the term set in the engagement agreement and deleted on request at the end of it. Who else sees it We do not sell personal data and we do not share it for advertising. The analytics processors named above receive site usage data. The contact form and API run on Cloudflare Workers, use the visitor IP address to limit abuse, and send the submitted fields through Cloudflare Email Service to our contact inbox. Our email provider then handles the delivered email. Customer engagement data is not shared with third parties without written instruction, except where a law requires disclosure. Your rights Depending on where you live, you may have the right to access, correct, export, restrict, or delete the personal data we hold about you, and to object to processing based on our legitimate interests. Requests go to hello@finopsllm.com and are answered within a month. Withdrawing consent. Where we rely on your consent you can withdraw it at any time, as easily as you gave it, using the “Cookie settings” link in the footer of any page. Withdrawing clears the analytics cookies already on your device and stops further collection; it does not affect anything collected beforehand. Complaints. You can also lodge a complaint with a data protection supervisory authority — in the EU, the authority where you live or work ( list of authorities ); in the UK, the Information Commissioner’s Office . We’d appreciate the chance to sort it out first. This site is operated from the European Union and is not directed at children. If this policy changes materially, the updated version is published here. Back to FinOps LLM --- # FinOps LLM - Gestão de custos de IA e observabilidade LLM URL: https://finopsllm.com/pt/ FINOPS · LLM Construído sobre os princípios da Fundação FinOps · adaptado para tokens Controle de custos de IA para a era dos tokens. FinOps LLM é a plataforma de gerenciamento de custos de IA e observabilidade de LLM para equipes de engenharia que executam IA generativa em produção. Atribuição em tempo real em OpenAI, Anthropic, Bedrock e Gemini · detecção de anomalias , chargeback e otimização automatizada (roteamento, cache, compressão) · reconciliação mensal contra faturas brutas de provedores. Solicite auditoria gratuita → Visite a plataforma Auditorias baseadas em faturas Redução típica 40–60% Somente leitura por padrão Multi-nuvem app.finopsllm.com / customer-042 / overview DEMO Espaço de trabalho ◧ Visão geral ◫ Atribuição 12 ⚡ Anomalias 3 ↗ Previsão Otimização ◊ Roteamento ⌬ Cache ≡ Compressão Finanças $ Chargeback ▥ Orçamentos ✓ Reconciliação Visão geral Gasto Qualidade Reconciliação Gasto mês até a data $70,280 ↓ 57.4% vs. linha de base Economia de exemplo $94,720 reconciliada com fatura Taxa de acerto de cache 38.1% +4.2 pts semana a semana Delta de qualidade +0.2% Teste A/B ativo 7 dias Gasto diário de LLM · últimos 45 dias 5 abr - 5 mai, 2026 Linha de base ($165K/mês) Otimizado ($70.3K/mês) Atribuição de gasto · este mês por recurso RAG · 38% Agente · 26% Email · 18% Classif. Outro Busca RAG $26.7K Execuções de agente $18.3K Redação de email $12.6K Classificação $7.7K Feed de atividade Últimas 24 horas · ver tudo ! Anomalia: gasto p95 RAG +38% vs. média 7 dias 14:22 UTC · feature/rag-v2 · investigar → $ Roteamento v3 promovido para 100% do tráfego 11:08 UTC · economia projetada: $4,820/mês + Taxa de acerto de cache superou o limite de 38% 09:14 UTC · invalidação ajustada ⚑ Orçamento · equipe "agente" em 78% mês até a data 06:42 UTC · limitação automática armada ✓ Reconciliação abr 2026 assinada 1 mai · −57.4% vs. linha de base Reconciliado com todos os provedores principais OpenAI Anthropic Gemini Bedrock Azure Groq Together Mistral 01 A plataforma FinOps para IA, em quatro pilares. FinOps LLM traz o framework da Fundação FinOps - visibilidade, atribuição, otimização, responsabilidade - para o gasto em LLM e GenAI. Mesma disciplina. Unidade de custo diferente. PILAR 01 Visibilidade Dados de custo no nível de token ingeridos de cada provedor. Reconciliados a cada hora. Filtráveis por provedor, modelo, recurso, equipe, cliente, ambiente. OpenAI · Anthropic · Bedrock · Gemini · Azure · Groq · Together Ingestão por hora · <5 min de atraso de reconciliação Somente leitura por padrão · NDA e DPA sob demanda PILAR 02 Atribuição & chargeback Cada token mapeado para um recurso, equipe e coorte de cliente. Chargeback e showback mensais, exportados para seu sistema financeiro ou como CSV. Dimensões personalizadas · recurso, equipe, nível, região Gasto por coorte · P&L por nível de cliente NetSuite · QuickBooks · CSV · API PILAR 03 Detecção de anomalias Alertas em tempo real quando gasto, latência ou qualidade se desvia da linha de base móvel de um recurso. Slack, PagerDuty, email - e limitação automática quando importa. Linhas de base móveis por recurso · conscientes de sazonalidade Slack · PagerDuty · email · webhook Limitação automática opcional & cumprimento de orçamento PILAR 04 Otimização automatizada Roteamento de modelos, cache semântico e compressão de prompts implantados atrás de feature flags, testados A/B por no mínimo sete dias, graduados apenas em ganhos de qualidade e custo. Árvore de roteamento · classificação de qualidade por solicitação Cache semântico · latência de acerto <10ms SLO de qualidade + reversão automática em regressão 02 Otimização Seis alavancas que acionamos, em cada engajamento. A maioria das equipes combina três ou quatro. A auditoria classifica quais dominam sua superfície de gasto e projeta economias antes de qualquer engajamento. 01 30–50% Roteamento de modelos Cada solicitação classificada por complexidade e roteada para o modelo mais barato que atende ao seu padrão de qualidade. Raciocínio para modelos insignia; classificação e extração para modelos pequenos e rápidos. 02 20–40% Cache semântico Prompts quase duplicados identificados com embeddings; respostas idênticas servidas do cache <10ms. Limiares de similaridade ajustados por recurso. 03 15–30% Compressão de prompts Prompts de sistema auditados por redundância. Exemplos desduplicados. Contexto recuperado comprimido com técnicas estilo LLMLingua. Cada mudança testada A/B. 04 10–50% Preços de lote & assincronia Cargas de trabalho não interativas roteadas para endpoints em lote (até 50% de desconto) com enfileiramento consciente de SLO para rotas sensíveis ao tempo. 05 20–35% Arbitragem de provedores Capacidade idêntica frequentemente custa 2–3× mais em um provedor. Roteamos por capacidade por dólar, não pelo SDK com o qual sua equipe começou. 06 5–15% Cadeias de fallback Tentativas inteligentes e fallbacks escalonados superam o sobre-provisionamento do pior caso. Mantenha SLO sem pagar preços insignia em cada chamada. 03 Engajamento Audite. Implemente. Reconcilie. Repita. Cada engajamento segue as mesmas quatro fases. A maioria dos clientes vê sua primeira fatura do provedor reconciliada ao final da semana cinco. 01 SEMANA 01 AUDITORIA Mapeie cada dólar. Ingerimos faturas de provedores, logs de gateway e telemetria de uso. Na sexta-feira, você tem um mapa completo de seu gasto em LLM - por provedor, modelo, recurso, equipe - classificado por desperdício em dólares. Entregável Mapa de gasto · oportunidades priorizadas · linha de base fixa (contrassinalizada) 02 SEMANA 02 PLANO Classifique por desperdício. A auditoria se torna um plano de engenharia priorizado respeitando sua postura de conformidade, SLOs de latência e processo de lançamento. Guardrails de qualidade acordados por endpoint. Assinaturas em cada mudança. Entregável Plano de engenharia · árvore de roteamento · especificação de cache · SLOs de qualidade · cronograma de lançamento 03 SEMANAS 03–05 LANCE Lance & teste A/B. Os engenheiros do FinOps LLM emparelham com os seus para lançar cada otimização atrás de feature flags, testar A/B por sete dias versus a linha de base, e graduar para 100% do tráfego. O painel de controle é ativado junto. Entregável Painel de controle ativo · alertas Slack · revisão semanal · primeira reconciliação 04 CONTÍNUO RECONCILIE Componha as economias. Os preços se movem. O tráfego muda. Os modelos são lançados. A plataforma monitora o desvio; recomendamos e implementamos acompanhamentos para que as economias se componham. Cada mês fecha com uma Declaração de Economias assinada. Entregável Declaração mensal assinada · alertas de desvio & qualidade · ajuste contínuo 04 Resultados Números de engajamentos reais. Faixas de redução ilustrativas de alavancas de otimização de LLM comuns. Os objetivos reais são estabelecidos após uma auditoria de fatura de provedor e revisão de carga de trabalho. Redução típica 40–60 % Faixa entre engajamentos, dependendo de arquitetura e mistura de tráfego. Tempo para economias 3–5 sem Kickoff → primeira fatura do provedor reconciliada. Delta de qualidade +0 .2 % Cada mudança testada A/B no mínimo 7 dias. Taxa de auditoria $0 Gratuita - creditada contra implementação. 05 Preços Pague por resultados. Há um único engajamento e ele é cobrado sobre a economia verificada. Tidal Telemetry é software separado, gratuito em beta. ★ MAIS POPULAR Desempenho Auditoria gratuita. Depois, você só paga quando nos economiza dinheiro - medido em relação a uma linha de base fixa, reconciliado com faturas de provedores. 15–25 % da economia verificada Sem economias, sem taxa · auditoria creditada contra implementação · cancele a qualquer momento ✓ Auditoria gratuita · retorno de 1 semana · linha de base contrassinalizada ✓ Stack de otimização completo · roteamento, cache, compressão, arbitragem ✓ Painel de controle ativo + chargeback + declarações mensais assinadas ✓ Emparelhamento de engenharia com equipe FinOps LLM · revisões semanais ✓ Cumprimento de SLO de qualidade & reversão automática ✓ Mínimo: $20K/mês de gasto em LLM Solicite auditoria gratuita → AUTOATENDIMENTO · PRODUTO SEPARADO Tidal Telemetry Software de observabilidade que você contrata e executa sozinho. Sem engajamento gerenciado e sem filtro comercial. Grátis em beta sem cartão de crédito · usuários beta mantêm um plano gratuito ✓ Uma linha de código · ~50 bibliotecas auto-instrumentadas ✓ Ingestão OpenTelemetry padrão · o SDK é opcional ✓ Custo por chamada, tokens, latência e erros como traces ✓ Armazenamento e chave de ingestão isolados por projeto ✓ Servidor MCP integrado para configuração via agentes ✓ Sem pré-requisito de engajamento · use sem falar conosco Ver Tidal Telemetry → 06 Perguntas frequentes Perguntas comuns. Falta algo? Email para hello@finopsllm.com - respondemos dentro de um dia útil. O que é FinOps para LLM? + FinOps para LLM traz o framework da Fundação FinOps - visibilidade, atribuição, otimização e responsabilidade - para o gasto em LLM e GenAI. Inclui chargeback e showback por recurso e equipe, detecção de anomalias, governança de orçamento e otimização contínua do roteamento de modelos, cache e prompts. O que o FinOps LLM faz? + FinOps LLM é um engajamento gerenciado, não uma licença de plataforma. Fornecemos atribuição de gasto em tempo real em OpenAI, Anthropic, Bedrock e Gemini, mais otimização automatizada (roteamento, cache, compressão) e reconciliação mensal contra faturas de provedores. Como é estruturada a precificação? + Um único modelo. Auditoria gratuita, depois 15–25% das economias mensais verificadas, medidas contra uma linha de base fixada antes de qualquer mudança. Sem licença, sem assentos, sem mínimo de plataforma. Tidal Telemetry é um produto separado e é gratuito em beta. Quanto podemos economizar? + A redução típica no primeiro ciclo de faturamento completo após a implementação é 40–60% , dependendo da arquitetura e mistura de tráfego. Quais provedores são suportados? + OpenAI, Anthropic, Gemini & Vertex AI, AWS Bedrock, Azure OpenAI, Groq, Together, Mistral, Cohere, Fireworks, Replicate , e a maioria dos endpoints OSS. Implantações multi-provedor normalmente têm a maior superfície de economias. O FinOps LLM suporta chargeback & showback? + Sim. Atribuição no nível de token para provedores, modelos, recursos, equipes e coortes de clientes. Chargeback e showback mensais exportados para NetSuite, QuickBooks, CSV ou API . Dimensões personalizadas suportadas. Como você lida com dados do cliente? + Somente leitura por padrão. Dados de faturamento e uso são suficientes para a maioria do trabalho de atribuição. Dados de prompts e saídas são acessados apenas com aprovação explícita do cliente, para otimizações específicas que o exigem. NDA e DPA disponíveis sob demanda. Quanto tempo leva a implementação? + Atribuição e dashboards entram em operação em menos de uma semana . A implementação de otimização leva 3–5 semanas; as economias aparecem na primeira fatura completa do provedor após go-live. A otimização prejudicará a qualidade da saída? + Não. Cada mudança de roteamento, cache e compressão é testada A/B contra produção por no mínimo sete dias antes da promoção. Regressões são revertidas automaticamente. A qualidade é monitorada continuamente junto com o custo. 07 Recursos Guias, benchmarks & ferramentas. Pesquisa longa para líderes de engenharia e finanças avaliando FinOps para IA. Gratuita, sem inscrição, atualizada mensalmente. GUIA ↗ FinOps para LLM: um framework completo Visibilidade, atribuição, otimização, responsabilidade - aplicados a tokens. Com uma arquitetura de referência de 30 páginas. 16 MIN · MAI '26 NOVO GUIA SEO -> Otimização de custos de IA Um playbook prático para reduzir gasto em IA através de roteamento, cache, lotes e disciplina de prompts. 8 MIN MAI '26 TUTORIAL ↗ Atribuição de custos no nível de token em produção Estratégias de tagging, matemática de chargeback e padrões de integração de gateway. Com código de referência. 11 MIN · CÓDIGO 4.2K LEITURA OPERAÇÕES ↗ Monitoramento de custos de LLM As métricas, alertas e limites de proprietário que evitam que mudanças de gasto se escondam em faturas mensais. 10 MIN OPS GUIA ↗ Detectando anomalias de custos de LLM antes da fatura Linhas de base por recurso, sazonalidade e como cablear alertas que os engenheiros não silenciarão. 9 MIN · MODELOS 3.1K LEITURA RAG -> Otimização de custos de RAG Reduza o desperdício de tokens impulsionado por recuperação com melhor chunking, limites de contexto mais estreitos e reranking seletivo. 7 MIN PRÁTICO REFERÊNCIA ↗ Glossário de FinOps de IA Definições para atribuição, showback, chargeback, tokens de leitura de cache, roteamento e custo por tarefa bem-sucedida. REFERÊNCIA GRATUITA FINANÇAS ↗ Chargeback e showback de LLM Como relatar gasto de IA por equipe e produto antes de convertê-lo em alocação de orçamento. 8 MIN GOVERNANÇA OPENAI ↗ Atribuição de custos do OpenAI Request tags, reconciliação de fatura, tentativas e classes de carga de trabalho para gasto em OpenAI. 7 MIN PRÁTICO ANTHROPIC -> Atribuição de custos do Anthropic Rastreie gasto do Anthropic por recurso, proprietário, carga de trabalho e comportamento de roteamento sem quebrar a reconciliação. 7 MIN NOVO ROTEAMENTO ↗ Roteamento de modelos Como enviar solicitações fáceis para modelos mais baratos e manter intacta a qualidade, latência e comportamento de fallback. 12 MIN ALGO MÉTRICAS -> Rastreamento de tokens de LLM Os campos no nível de solicitação que fazem com que mudanças de custos de IA sejam explicáveis para engenharia e finanças. 6 MIN OPS PREÇO ↗ Arbitragem de provedores Compare capacidade de modelo equivalente em provedores sem subestimar custos de migração e overhead. 11 MIN BENCHMARKS DADOS ↗ Benchmark de preço por capacidade de LLM · Q2 '26 Custo por tarefa bem-sucedida por mês em GPT, Claude, Gemini, Mistral, Llama, em cargas de trabalho padronizadas. ATUALIZADO MENSALMENTE Q2 '26 ATIVO ESTUDOS DE CASO ↗ Resultados dos clientes Os estudos de caso públicos serão publicados apenas após aprovação do cliente. Até então, as referências de avaliação são tratadas em particular. SOB NDA HONESTO 08 Comece aqui Coloque sua fatura de IA sob supervisão adulta. Cerca de uma semana. Acesso somente leitura. Retornamos com um mapa completo de seu gasto, classificado por desperdício, mais uma linha de base que nosso painel de controle pode rastrear. Gratuita. Sem compromisso de implementação. Solicite auditoria gratuita → Ver benchmarks DESCOBERTA DE 30 MIN · SOMENTE LEITURA POR PADRÃO · NDA + DPA SOB DEMANDA · SEM COMPROMISSO --- # Pesquisa · FinOps LLM URL: https://finopsllm.com/pt/research Pesquisa Notas para equipes de engenharia e finanças que constroem a governança de gastos com IA. Comece aqui Explicações claras se você está começando com custos de LLM. Como os provedores de LLM cobram? Tokens de entrada, saída, cache e raciocínio explicados O que é atribuição de custos de LLM? Por que minha fatura de LLM dispara? Como orçar gastos com IA Toda a pesquisa A despesa de IA fora da sua fatura de API A quarter of AI spend is slipping to 2027 (EN) Adicionar proveniência à saída de IA Agent spend attribution (EN) Agent spend guardrails (EN) Agent Spend Guardrails: Runtime Controls That Work (EN) Agent TCO: The 70% of Cost That Isn't Tokens (EN) Agentes em segundo plano e o relógio do FinOps AI Coding Economics 2026: GLM vs DeepSeek vs Claude (EN) AI Cost Allocation: Tags, Cost Centers and Chargebacks (EN) AI Cost Optimization Checklist for 2026 (EN) AI Cost Optimization: Routing, Caching, Batching (EN) AI Cost Optimization: Six Levers That Actually Work (EN) AI cost recovery playbook: stop the bleeding (EN) AI FinOps: o modelo operacional do gasto com GenAI AI observability: cost, traffic, and quality · FinOps LLM (EN) Anthropic cost attribution (EN) As ferramentas de servidor são outra fatura Atribuição de custos da OpenAI Atribuição de custos de LLM Aumento do Claude Sonnet 5 cancelado: $2/$10 é permanente Azure OpenAI vs OpenAI Direto: comparação de custos e PTU Batch APIs as a FinOps lever (EN) Busca web como centro de custo para agentes IA Calculadora de Custos LLM - Estime Seu Gasto Mensal em IA Chargeback e showback de LLM Chargeback vs Showback: Picking the Right FinOps Model (EN) Chargeback when your provider won't bill per team (EN) ChatGPT Pro Max $500 plan economics (EN) Claude Max 20x isn't 20x. We checked 60 days of logs against Codex (EN) Claude Max 20x vs 5x: is the $200 price worth it? We measured the real weekly usage ceiling (EN) Claude Max vs Alibaba Token Pro: o custo real da codificação agêntica Claude Sonnet 5.5 pricing: what changes, what does not (EN) Claude Sonnet 5.5: the cost-aware model routing guide (EN) Cloud Infrastructure Cost Audit: Alibaba vs Claude Max (EN) Codex auto-compact on GPT-6 Sol: the defaults in the source code, and what raising them costs (EN) Codex usage limit resets: how they work, banked resets and a dated log (EN) Coloque controlo de custos no pipeline de avaliação LLM Como as marcas de água são destruídas Como auditar seu gasto em LLM em 30 minutos Como funciona a marca de água de IA Como o estilo de prompt aparece na fatura Como usar Jev em um agente de IA Comparação de Planos de Codificação IA Comparar preços de fornecedores IA Controlar o custo de tokens em esquemas MCP em agentes de IA Cortes de preço e orçamento de roteamento Cost per request as a product KPI (EN) Créditos de IA em SaaS: medir uma unidade que não controla Cursor vs Copilot vs Claude Code Cost (EN) Custo de conformidade da marca de água Custo em tokens do modo JSON e dos esquemas Custo por ativo aprovado em imagem e vídeo Custo real por tarefa nos modelos de fronteira DeepSeek Harness: escopos, restrições e sombreamento de ferramentas DeepSeek Harness: instalação, perfis e primeira execução DeepSeek Harness: o que «tudo é um plugin» realmente entrega DeepSeek Harness: objetivos, rodadas de objetivo e o loop Ralph Descontos por compromisso de gasto Detecção de anomalias em custos de IA Economia de agentes: quanto custa um agente de código? Economia do Encerramento do Fine-Tuning da OpenAI Economia do Opus 5.5 fast mode Economia unitária das APIs de áudio em tempo real Enterprise AI procurement and committed spend (EN) Estratégias de cache comparadas Eval cost allocation: who pays for LLM evals (EN) Exposição cambial no gasto de LLM Find the cache miss behind your OpenAI bill (EN) FinOps para LLM e GenAI: um enquadramento prático FOCUS 1.5: rastreamento de tokens de IA e Price Sheets Gartner's 2026 AI spending forecast (EN) Gasto de LLM fora de produção GenAI cost management: controls and analytics (2026) (EN) Geração de código com IA mais barata (2026) GPT-5 Pricing and Budget Impact: A 2026 Planning Guide (EN) GPT-5 vs GPT-4o Cost Comparison: When to Upgrade (EN) GPT-6 Astra cost model (EN) GPT-6 Luna cost model (EN) GPT-6 pricing: Astra, Sol and Luna (EN) GPT-6 Sol cost model (EN) GPT-6 Sol long-context benchmarks: what has actually been measured, and what is GPT-5.6 Sol (EN) Guia de Custos de Modelos de Raciocínio Guia de implementação de orçamentos de tokens Guia de Preços de GPT-5.6: Luna, Terra, Sol Hidden LLM Costs Beyond Per-Token Pricing (EN) How do LLM providers charge? Tokens, tiers, caching (EN) How many tokens do you get with Claude Pro and Max? We counted them (EN) How much Codex does ChatGPT Pro include? We priced the weekly limit in dollars (EN) How to budget for AI spend: a starter framework (EN) How to cap inference costs and prevent runaway spending (EN) How to check and reduce Claude Code token usage (EN) Impacto de Custo de Servidores MCP Input, output, cache, reasoning: what tokens cost (EN) Invoice reconciliation for AI spend (EN) IT Chargeback and Showback Explained (EN) IT Chargeback and Showback for AI: A Practical Guide (EN) IT Showback: A Practical Guide for Technology Teams (EN) Latest AI models and Anthropic's proposed IPO (EN) LLM Budget Governance: Alerts and Guardrails (EN) LLM Cost Benchmarks by Industry (EN) LLM cost dashboard: what to put on it (EN) LLM Cost Management: A Practical Framework (EN) LLM Cost Monitoring in Production: A Field Guide (EN) LLM cost monitoring: what to track and how to control it (EN) LLM Cost Per User Benchmarks (EN) LLM Cost Tracking: Tools, Tags and Telemetry (EN) LLM Cost Visibility: Dashboards and Metrics That Matter (EN) LLM FinOps standards (EN) LLM Provider Arbitrage: Price and Quality Parity (EN) LLM Purchasing Guide for Platform Teams (EN) LLM Token Tracking by Input, Output and Cache (EN) LLM Usage Metering: How to Bill Internal AI Spend (EN) Long context vs RAG: where the cost breakeven actually is (EN) Meça a margem bruta de uma funcionalidade de IA antes de lançar Minimax M3.1 Flash free preview economics (EN) Model deprecation migration: budgeting for forced moves (EN) Model Routing: Cheaper Models, Same Output Quality (EN) Modelo de custo do Claude Fable 5.1 Modelo de custo do Claude Opus 5.5 Modelos Abertos vs. Fechados: Comparação de Custos LLM Multi-provider, multi-team LLM FinOps (EN) Multimodal cost allocation (EN) NVIDIA Open Agent Safety Platform: the FinOps implications (EN) O ciclo de retries que aumenta o custo de inferência O custo por tarefa bem-sucedida supera o custo por pedido O custo real de mudar de fornecedor LLM O custo recorrente de embeddings e vector stores O log de sessão do DeepSeek Harness como registro de custos O manual do modelo furtivo O Ox Alpha era o GLM-5.3 O plano gratuito como custo de aquisição O primeiro fecho mensal de um produto intensivo em IA O que custam guardrails e moderação O que é DeepSeek Harness? Guia completo Observabilidade de IA como segunda fatura On-prem and self-hosted LLM FinOps (EN) Onde colocar os limites de gasto no DeepSeek Harness OpenAI agent message board cost model (EN) OpenAI O / AON always-on agent cost model (EN) OpenAI Ultra Fast API pricing and speed tiers (EN) OpenTelemetry GenAI conventions for cost attribution (EN) Opus 5.5 long-running agent cost analysis (EN) Order of LLM cost optimizations (EN) Os níveis de esforço do Opus 5.5 são o preço real Os três orçamentos de que todo agente autónomo precisa Pagar duas vezes a janela de contexto Pensamento adaptativo e previsão de custos Preço de um modelo de pesos abertos Prémio regional e residência de dados Prompt cache attribution (EN) Prompt caching explained (EN) Prompt Caching ROI: Calculating Real Savings (EN) Provar o ROI de IA sem esconder falhas Quanto Custa GPT-5? Guia Completo de Preços 2026 RAG cost optimization (EN) Rastreamento de Preços de API LLM Rate limits, 429 e subidas de tier Real-SWE cost per resolved issue (EN) Reasoning token attribution and chargeback (EN) Runbook de produção para um pico de custos LLM Seis casos de uso de Jev que fazem sentido Semantic cache economics (EN) September 2026 AI model trends (EN) Sete padrões defensivos da documentação do DeepSeek Harness Showback vs Chargeback: Which Model Fits Your Team? (EN) Silent model downgrades and cost models (EN) State of FinOps 2026: 98% now manage AI spend (EN) Streaming e o custo de gerações abandonadas Subagentes do DeepSeek Harness: delegação como multiplicador de custo System One Models and Jev cost optimization (EN) Tendências de custos de LLM 2025–2026 The Token Count Is Lying: Claude Max vs Qwen Audit (EN) The True Cost of Coding Agents: Beyond the API Bill (EN) Token budget implementation (EN) Tokens mais baratos, fatura LLM maior Travar a proliferação de subagentes e delegação recursiva Variação IA: volume, tarifa, mix, eficiência What independent Jev tests say about cost (EN) What is AI value management? (EN) What is LLM cost attribution? A plain-English explainer (EN) What is LLM FinOps? A plain-English definition (EN) What is the Tokenomics Foundation? (EN) Where Jev belongs in an agent workflow (EN) Why agentic AI blows the budget (EN) Why does my LLM bill spike? The most common causes (EN) Why Jev is catching on with agent builders (EN) Why Showback Comes Before Chargeback in FinOps (EN) Quer aplicar isso aos seus próprios gastos com LLM? FinOps LLM realiza uma auditoria gratuita de seus custos de IA e mostra onde estão as economias. Reserve sua auditoria gratuita → Voltar para FinOps LLM --- # O pensamento adaptativo partiu a sua previsão · FinOps LLM URL: https://finopsllm.com/pt/research/adaptive-thinking-cost-forecast Pensamento adaptativo e previsão de custos Atualizado September 1, 2026 · publicado originalmente September 1, 2026 Resposta rápida: O orçamento de raciocínio era um número definido por si. Passava budget_tokens: N e N servia de controlo e de previsão: no pior caso, cada pedido custava N tokens de raciocínio.Esse parâmetro está... O orçamento de raciocínio era um número definido por si. Passava budget_tokens: N e N servia de controlo e de previsão: no pior caso, cada pedido custava N tokens de raciocínio. Esse parâmetro está descontinuado no Opus 4.6 e no Sonnet 4.6 e, nos modelos mais recentes — Fable 5 e 5.1, Sonnet 5, Opus 5, 4.8 e 4.7 — enviá-lo devolve um 400 . É substituído por thinking: {type: "adaptive"} : o modelo decide quanto pensar consoante a dificuldade. O que muda nos números O custo médio por pedido costuma descer, porque os pedidos fáceis deixam de pagar raciocínio de que não precisavam. A variância sobe , porque os difíceis já não são truncados no seu tecto. Um orçamento expresso como máximo por pedido fica sem apoio. Preveja a distribuição, não o tecto Acompanhe os tokens de raciocínio como série própria — já vêm no objeto de utilização de cada resposta. Orçamente por percentis: um p50 e um p99 por rota em vez de "N tokens por pedido". Alerte sobre a proporção, não o total: a quota de tokens de raciocínio é o primeiro número a mexer quando uma alteração de prompt faz o modelo trabalhar mais. Onde ainda cabe um limite Os limites de despesa por rota e por inquilino continuam a funcionar e continuam a apanhar ciclos descontrolados. É aí que vive agora a proteção: na fronteira que controla. Artigos relacionados Atribuição de tokens de raciocínio Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Junte proveniência à sua saída de IA num dia · FinOps LLM URL: https://finopsllm.com/pt/research/add-provenance-to-your-ai-output Adicionar proveniência à saída de IA Atualizado September 1, 2026 · publicado originalmente September 1, 2026 Resposta rápida: Comecemos pelo que não é possível. A marca de água no texto é aplicada pelo fornecedor durante a geração: não há parâmetro que a ligue ou desligue, e não pode ser acrescentada depois. Se quer um sinal... Comecemos pelo que não é possível. A marca de água no texto é aplicada pelo fornecedor durante a geração: não há parâmetro que a ligue ou desligue, e não pode ser acrescentada depois. Se quer um sinal mais forte, a resposta não é acrescentar marcação, é acrescentar um registo. Esse registo é barato, está inteiramente sob o seu controlo e é o que de facto se apresenta quando alguém lhe pede para provar a origem de uma saída. A maioria das equipas constrói-o num dia, porque está a um join da telemetria que já recolhem para atribuição de custos. Os quatro campos Para cada artefacto gerado, registe o identificador e versão exactos do modelo , a região , a data e hora e um identificador de artefacto estável que acompanhe a saída por todo o pipeline. É este último que as equipas omitem e mais tarde lamentam. Se já emite registos de utilização por pedido, três dos quatro já lá estão. O que falta é o join: a telemetria de custo sabe que houve um pedido e quanto custou, mas não que artefacto guardado produziu. Preserve o manifesto assinado Quando o fornecedor entrega um ficheiro assinado com C2PA, o objetivo é simples: não o perder. Configure as transformações de imagem para preservar metadados de forma explícita em vez de confiar nas omissões, e volte a anexar a proveniência após qualquer recodificação que controle. Marque também para pessoas A marcação legível por máquina e o aviso visível resolvem problemas diferentes. Uma etiqueta "gerado com IA" não custa nada, nenhuma transformação a afeta e é o que o utilizador realmente lê. Nenhuma substitui a outra. Artigos relacionados Como as marcas de água são destruídas Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Economia de agentes: quanto custa um agente de código? · FinOps LLM URL: https://finopsllm.com/pt/research/agent-economics Economia de agentes: quanto realmente custa um agente de codificação? Agentes de codificação são a categoria de gasto em LLM com maior crescimento em 2026. Cada equipe de engenharia está usando um ou avaliando um. Mas os modelos de preços são confusos: planos de assinatura ocultam limites de tokens por trás de linguagem "ilimitada", agentes baseados em API expõem custos brutos que aumentam de forma imprevisível, e nenhum dos dois modelos informa qual é realmente o custo por tarefa concluída. Este artigo detalha a economia real dos cinco agentes de codificação mais populares, introduz uma métrica de "custo por tarefa útil" e explica por que agentes baseados em API podem ser tanto mais baratos quanto mais caros que planos de assinatura, dependendo dos padrões de uso. O panorama de preços Agentes de codificação se dividem em duas categorias de preços. Agentes de assinatura cobram uma taxa mensal fixa com uso incluído. Agentes baseados em API cobram por token consumido, tipicamente através de sua própria conta do provedor. A escolha correta depende de quantas tarefas você executa, do tamanho da sua base de código e de quão complexos seus prompts se tornam. Agente Plano Custo mensal Tokens/solicitações incluídos Tarefas estimadas/mês Custo por tarefa Modelo principal Cursor Pro $20/mês 500 solicitações rápidas (modelos premium) ~80–150 $0,13–$0,25 Claude Sonnet 4, GPT-4.1 GitHub Copilot Pro+ $39/mês 1.500 solicitações premium ~150–300 $0,13–$0,26 Claude Sonnet 4, GPT-4.1 GitHub Copilot Pro $10/mês 300 solicitações premium ~30–60 $0,17–$0,33 GPT-4.1, Claude Sonnet 4 Claude Code API (Max opcional) $5–$100+ Pagamento por token via API da Anthropic ~20–200+ $0,25–$2,00 Claude Sonnet 4 Cline API (BYOK) $5–$80+ Pagamento por token via qualquer provedor ~20–200+ $0,20–$3,00 Configurado pelo usuário Windsurf Pro $15/mês 500 créditos (modelos premium) ~60–120 $0,13–$0,25 Claude Sonnet 4, GPT-4.1 O que "custo por tarefa" realmente significa A tabela acima mostra o intervalo anunciado, mas o custo real por tarefa depende de três fatores ocultos: carregamento de janela de contexto, cadeias de chamadas de ferramentas e loops de repetição. Uma tarefa "simples" como adicionar um novo endpoint de API pode consumir 15K–40K tokens durante a sessão. Um refator complexo que toca vários arquivos pode facilmente exceder 200K tokens. O carregamento de janela de contexto é o maior custo oculto. Cada agente de codificação carrega seus arquivos abertos, estrutura do projeto e histórico recente de conversa em cada chamada à API. Um projeto com arquivos grandes significa mais tokens por solicitação, mesmo se você está fazendo uma pergunta simples. Chamadas de ferramentas multiplicam isso: cada operação de leitura, busca ou edição é uma ida e volta separada à API com o contexto completo. Custos ocultos que a maioria das equipes ignora Loops de repetição. Quando a primeira tentativa de um agente falha em testes ou linting, ele tenta novamente automaticamente. Cada repetição é uma chamada à API com preço cheio. Na prática, 20–40% das sessões de agente envolvem pelo menos uma repetição, adicionando 30–80% ao custo em tokens dessa tarefa. Estouro de contexto. Sessões longas atingem limites de contexto. Quando isso acontece, o agente resume o contexto anterior (perdendo detalhes) ou elimina mensagens anteriores (perdendo contexto). Ambos levam a saída de menor qualidade e mais repetições. Sobrecarga de chamadas de ferramentas. Uma única tarefa pode envolver 5–15 chamadas de ferramentas (ler arquivo, buscar código, editar arquivo, executar testes). Cada chamada de ferramenta inclui o contexto completo da conversa mais a definição da ferramenta. Apenas as definições de ferramentas podem consumir 2K–5K tokens do prompt do sistema por chamada. Solicitações premium ociosas. Planos de assinatura contam "solicitações rápidas" mesmo quando o agente retorna saída não útil. Uma sugestão rejeitada ainda custa uma solicitação premium. API vs. assinatura: quando cada um vence Agentes baseados em API (Claude Code, Cline) vencem quando seu uso é irregular ou leve. Se você executa 20–40 tarefas focadas por mês, pagar $0,30–$0,80 por tarefa é mais barato que uma assinatura de $20–$39. Também vencem quando você precisa de um modelo específico para uma tarefa específica: você paga apenas pelo que usa. Agentes de assinatura (Cursor, Copilot, Windsurf) vencem quando o uso é constante e intensivo. Se você executa 100+ tarefas por mês, o custo efetivo por tarefa cai abaixo de $0,20, o que é difícil de bater com preços de API. Também vencem em previsibilidade: equipes de finanças podem orçar um montante fixo. O ponto de cruzamento é tipicamente 40–80 tarefas por mês por desenvolvedor. Abaixo disso, o preço de API é mais barato. Acima disso, planos de assinatura oferecem melhor economia. A métrica de "custo por tarefa útil" O custo bruto por tarefa é enganoso porque nem toda tarefa produz valor. Uma sessão de agente que falha, retorna uma resposta incorreta ou requer retrabalhado manual tem um custo real de saída útil zero. A métrica que importa é: Custo por tarefa útil = Gasto mensal total / Tarefas que foram entregues sem retrabalhado manual Na prática, equipes relatam que 60–80% das tarefas de agente produzem saída utilizável na primeira tentativa. Os 20–40% restantes requerem intervenção manual. Isso significa que o custo efetivo por tarefa útil é 1,25x–1,7x o custo bruto por tarefa. Para equipes que constroem com modelos de código aberto ou exploram alternativas econômicas, plataformas como MiMO oferecem preços competitivos que podem mudar o cálculo API vs. assinatura. Como reduzir custos de agentes Recorte o contexto. Feche arquivos irrelevantes antes de invocar o agente. Contexto menor = menos tokens por chamada. Escreva prompts específicos. Prompts vagos levam a mais chamadas de ferramentas e repetições. "Adicionar um endpoint POST /users que valida email" custa menos que "corrigir o negócio de usuários." Use modelos específicos por tarefa. Edições simples não precisam de um modelo de raciocínio. Rotear código boilerplate para modelos mais baratos e refactors complexos para modelos premium. Monitore o uso de tokens. Rastreie a contagem de tokens por sessão. Se o custo médio por sessão está subindo, seus prompts ou base de código podem estar crescendo mais rápido que o esperado. Estabeleça limites de repetição. Limite repetições automáticas a 2–3 por tarefa. Além disso, escale para um humano. O que esperar em seguida Os preços de agentes se movem rapidamente. Planos de assinatura estão aumentando os limites inclusos à medida que a competição se intensifica. Preços de API continuam caindo: Claude Sonnet 4 custa 60% menos que Claude 3.5 Sonnet no seu lançamento. Modelos de codificação de código aberto estão fechando a lacuna de qualidade, o que empurrará preços de API ainda mais para baixo. A tendência mais importante é o preço específico de agentes. Provedores estão experimentando com preços por tarefa, limites por sessão e faturamento ponderado por qualidade. Para o final de 2026, espere que a maioria dos agentes ofereça uma garantia de "custo por tarefa bem-sucedida" em vez de faturamento bruto por tokens. Relacionado Comparação de planos de codificação IA - benchmark baseado em evidência. Atribuição do gasto de agentes - como rastrear custos de agentes por projeto e equipe. Proteções de gasto de agentes - estabelecer limites antes que os custos saiam do controle. FinOps para LLM - o marco mais amplo. Quer aplicar isso ao seu próprio gasto em LLM? FinOps LLM executa uma auditoria gratuita de seus custos de IA e mostra onde estão as economias. Solicite sua auditoria gratuita → Voltar para pesquisa --- # A busca web vira centro de custo para agentes IA · FinOps LLM URL: https://finopsllm.com/pt/research/agent-web-search-cost-center Busca web como centro de custo para agentes IA Atualizado September 10, 2026 · publicado originalmente September 10, 2026 Resposta rápida: A pesquisa na web em tempo real expande a capacidade dos agentes, mas cria custos tarifados adicionais por consulta além dos tokens. Um único comando pode gerar múltiplas buscas desnecessárias.... A pesquisa na web em tempo real expande a capacidade dos agentes, mas cria custos tarifados adicionais por consulta além dos tokens. Um único comando pode gerar múltiplas buscas desnecessárias. Governança da busca autônoma Vincule as consultas ao ID da tarefa pai e controle o custo por tarefa concluída com sucesso. Artigos relacionados Custo por tarefa concluída Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Margem bruta de IA antes do lançamento · FinOps LLM URL: https://finopsllm.com/pt/research/ai-feature-gross-margin Meça a margem bruta de uma funcionalidade de IA antes de lançar Atualizado September 2, 2026 · publicado originalmente September 2, 2026 Resposta rápida: A inferência é um custo de serviço, não de desenvolvimento. Corre a cada ação do cliente e cresce com o uso. Tratá-la como I&D até ao lançamento significa descobrir a margem real com a primeira... A inferência é um custo de serviço, não de desenvolvimento. Corre a cada ação do cliente e cresce com o uso. Tratá-la como I&D até ao lançamento significa descobrir a margem real com a primeira fatura completa. Instrumente antes de lançar Em staging, etiquete cada chamada por conta, fluxo e resultado, e reproduza tráfego realista. O que precisa é de uma distribuição: custo por tarefa bem-sucedida em p50, p90 e p99, mais a parte paga em falhas e retries. Custo por conta Multiplique o custo por tarefa bem-sucedida pelas tarefas mensais esperadas e some as falhas. Compare com o preço do plano no uso mediano, no percentil 90 e na conta mais pesada aceitável. Quatro fatores de custo Contexto reenviado a cada turno, retries faturados por inteiro, expansão agêntica de uma ação em muitas chamadas, e routing que envia casos fáceis para um modelo caro. Ligue a uma decisão Teto de uso, componente de consumo no preço, modelo por omissão mais barato, ou margem aceite com data de revisão. Reporte como linha própria da margem bruta. Artigos relacionados Custo por tarefa bem-sucedida Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # AI FinOps: o modelo operacional do gasto com GenAI · FinOps LLM URL: https://finopsllm.com/pt/research/ai-finops AI FinOps para equipes de produção AI FinOps é o modelo operacional para gerenciar gastos com IA uma vez que os modelos se tornam parte do produto. Não é apenas observabilidade, e não é apenas aquisição. É um ciclo entre engenharia, produto e finanças: entender para onde o gasto vai, atribuir responsabilidade, melhorar a economia unitária e verificar as mudanças contra a fatura. As cargas de trabalho de LLM tornam isso urgente porque o gasto escala com o uso, comprimento do contexto, comprimento da saída, tentativas e escolha do modelo. Uma pequena mudança de produto pode alterar a conta sem alterar a infraestrutura. Os melhores programas de AI FinOps vivem, portanto, perto do gateway do modelo e da pilha de análise de produtos. O que AI FinOps precisa Normalização de faturas de fornecedores. Metadados no nível de solicitação e propriedade do produto. Métricas de custo por tarefa bem-sucedida. Orçamentos que alertam antes do final do mês. Guias de otimização para roteamento, armazenamento em cache, agrupamento e estrutura de prompt. Por onde as equipes começam Comece com visibilidade e showback. Mostre a cada equipe de produto seu gasto em LLM, os endpoints que o impulsionam e as mudanças mês a mês. Depois escolha o fator controlável mais importante. Na maioria das equipes, isso é roteamento de modelos, compactação de contexto, armazenamento em cache de prompts, armazenamento em cache semântico ou mover trabalho não urgente para APIs em lote. AI FinOps fica maduro quando faz parte da revisão de lançamento: cada mudança voltada para o modelo tem um objetivo de qualidade, um objetivo de latência, um impacto no gasto e um plano de reversão. Relacionado What is LLM FinOps? - a disciplina operacional que gerencia gastos com LLM. FinOps for LLMs - o modelo operacional em detalhes. LLM cost attribution - como a atribuição realmente funciona. LLM budget governance - orçamentos e caminhos de degradação. Quer isso aplicado ao seu próprio gasto com LLM? FinOps LLM realiza uma auditoria gratuita de seus custos de IA e mostra onde estão as economias. Agende sua auditoria gratuita → Voltar para a pesquisa --- # Variação IA: volume, tarifa, mix, eficiência · FinOps LLM URL: https://finopsllm.com/pt/research/ai-spend-variance-bridge Variação IA: volume, tarifa, mix, eficiência Atualizado August 27, 2026 · publicado originalmente August 27, 2026 Resposta rápida: Divida a diferença entre previsão e realidade em volume, tarifa, mix e eficiência, ligando cada linha às faturas e a um responsável.As quatro causasVolume é procura; tarifa é preço faturado; mix é... Divida a diferença entre previsão e realidade em volume , tarifa , mix e eficiência , ligando cada linha às faturas e a um responsável. As quatro causas Volume é procura; tarifa é preço faturado; mix é mudança entre modelos, fornecedores ou cargas; eficiência é custo por resultado útil, incluindo retries e reparação humana. Construa a ponte Comece na previsão, aplique tarifa, volume, mix e eficiência e reconcilie o total com as faturas. Cada linha precisa de prova, valor, responsável e ação. Inclua qualidade para evitar falsas poupanças. Artigos relacionados Monitorização de custos LLM Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # A marca de água de IA já é uma rubrica de custo · FinOps LLM URL: https://finopsllm.com/pt/research/ai-watermarking-compliance-cost Custo de conformidade da marca de água Atualizado September 1, 2026 · publicado originalmente September 1, 2026 Resposta rápida: A Anthropic incorpora uma marca de água impercetível no texto dos modelos Claude suportados e assina os ficheiros .svg, .png e .jpg com metadados de proveniência C2PA. A técnica segue a abordagem... A Anthropic incorpora uma marca de água impercetível no texto dos modelos Claude suportados e assina os ficheiros .svg , .png e .jpg com metadados de proveniência C2PA. A técnica segue a abordagem SynthID-Text: enviesa a aleatoriedade da escolha de tokens sem alterar o sentido nem a qualidade. A 1 de setembro de 2026 abriu uma API de deteção a reguladores, meios de comunicação, verificadores, investigadores e empresas com obrigações próprias. A marcação é mundial, não apenas europeia, e decorre do artigo 50 do Regulamento da IA da UE, em vigor desde 2 de agosto de 2026. Nada disto é cobrado — e é por isso que escapa à revisão orçamental: o custo existe, apenas não está na fatura. Para onde vai o dinheiro Migração de modelos fixados em versões sem marcação; alteração dos pipelines de imagem que removem metadados; o processo de acesso à deteção; e a retenção de identificador de modelo, versão, região e data por chamada. Quatro custos reais, nenhuma tarifa. A armadilha da versão fixada Fixar uma versão exacta é boa prática, mas uma versão anterior a agosto de 2026 pode não ter marcação legível por máquina. Se serve utilizadores da UE, essa decisão de estabilidade torna-se uma lacuna de conformidade e o remédio é uma migração não planeada: reavaliação, ajuste de prompts, testes e um novo preço. Inventarie cada fixação e dê-lhe uma data de revisão. O seu pipeline de imagens apaga a prova Os metadados C2PA vivem no ficheiro, e miniaturizadores, transformações de CDN e conversores de formato descartam-nos por omissão para poupar bytes. Teste a cadeia completa, da geração à entrega: barato agora, caro numa auditoria. Artigos relacionados Custos de descontinuação e migração Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Detecção de anomalias em custos de IA · FinOps LLM URL: https://finopsllm.com/pt/research/anomaly-detection Detecção de anomalias em custos de IA As anomalias em custos de IA são frequentemente invisíveis até que chega a fatura porque o gasto pode aumentar sem que o volume de solicitações suba. Uma implantação pode adicionar contexto recuperado, alterar um limite de roteamento, reduzir acertos de cache, ativar retentativas ou mover tráfego para um modelo mais caro. Os alertas de tráfego tradicionais não detectam essas mudanças. Um detector de anomalias útil monitora os fatores de custo, não apenas o custo total. O gasto diário total é um indicador atrasado. Os sinais iniciais são tokens por solicitação, combinação de modelos, taxa de fallback, taxa de acertos de cache, participação de lotes e gasto por superfície de produto. Sinais a monitorar Gasto por endpoint, equipe e cliente por hora. Tokens de entrada e saída por solicitação em p50, p90 e p99. Taxa de retentativa, taxa de fallback e taxa de erro do provedor. Taxa de acertos de cache e participação de tokens lidos em cache. Mudanças na combinação de modelos após implantações ou lançamentos de prompts. Trabalho processável sendo executado acidentalmente de forma síncrona. Linhas de base Use múltiplas linhas de base. Um bot de suporte tem ciclos diários e semanais. Um trabalho de enriquecimento noturno tem uma janela de lotes. Um conjunto de avaliação tem picos ao redor dos lançamentos. Um único limite global será muito insensível ou acordará as pessoas constantemente. A melhor linha de base é por proprietário e classe de carga de trabalho. Alerte quando uma funcionalidade se desvia do seu próprio padrão normal, não quando toda a empresa cruza um limite de gasto genérico. Alertas acionáveis Um alerta deve explicar o fator: "tokens de entrada p90 dobraram no endpoint X após a implantação Y", "taxa de acertos de cache caiu de 74% para 18%", ou "fallback para modelo frontier aumentou em 31%". Se o alerta não conseguir nomear um proprietário provável e um fator, será ignorado. Loop de resposta Anexe contexto de implantação, diffs de políticas de roteamento e os clientes ou cargas de trabalho mais afetados. Em seguida, oferça o próximo passo: reverter um prompt, reduzir a contagem de recuperação, restaurar um limite de roteamento, desabilitar um fallback ou mover um trabalho para lotes. A detecção de anomalias é valiosa apenas quando reduz o tempo desde a surpresa da fatura até a ação de engenharia. Relacionado Monitoramento de custos de LLM - dashboards e observabilidade para gasto. Observabilidade de IA - sinais de custos e métricas operacionais. Por que as faturas de LLM disparam - causas raízes dos aumentos de custos. Quer que isso seja aplicado ao seu próprio gasto de IA? FinOps LLM realiza uma auditoria gratuita dos seus custos de IA e mostra onde estão as economias. Agende sua auditoria gratuita → Voltar à pesquisa --- # Azure OpenAI vs OpenAI Direto: custos e PTU · FinOps LLM URL: https://finopsllm.com/pt/research/azure-openai-vs-direct-cost Azure OpenAI vs OpenAI Direto: comparação de custos e PTU Atualizado September 19, 2026 · publicado originalmente July 12, 2026 Resposta rápida: Em consumo sob demanda com roteamento global, Azure OpenAI e OpenAI direta têm preços de tabela rigorosamente iguais (como $2,50 por milhão de tokens de entrada e $15 de saída). A verdadeira diferença... Em consumo sob demanda com roteamento global, Azure OpenAI e OpenAI direta têm preços de tabela rigorosamente iguais (como $2,50 por milhão de tokens de entrada e $15 de saída). A verdadeira diferença econômica está em três alavancas: Provisioned Throughput Units (PTU) , sobretaxas de residência de dados regional e descontos corporativos no contrato Microsoft EA . 1. PTU dedicada vs. pagamento por token A Azure oferece reserva de capacidade via PTUs. Sob demanda, uma PTU custa $2 por hora. Ao fechar uma reserva mensal, o valor cai para cerca de $260 por PTU ao mês — um desconto de até 82% em relação ao custo horário (e até 85% no plano anual). O ponto de equilíbrio econômico para justificar uma PTU ocorre quando a utilização média sustentada fica acima de 65–75% . Se o tráfego for variável ou sazonal, o pagamento tradicional por token consumido é mais econômico. 2. Variações regionais de preço Implantações globais seguem a tabela americana da OpenAI. No entanto, restringir chamadas a zonas da União Europeia ou regiões específicas locais adiciona uma sobretaxa de 10% a 20% na fatura de inferência. 3. Custos indiretos de infraestrutura O ambiente Azure inclui custos de Private Endpoints, exportação para Log Analytics e tráfego de saída VNet. Embora adicionem de 4% a 8% ao custo efetivo, viabilizam controles de acesso corporativo RBAC e isolamento de segurança bancário. Artigos relacionados Descontos por compromisso de gasto Por que preços de fornecedores não são comparáveis Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Agentes em segundo plano mudam o relógio do FinOps · FinOps LLM URL: https://finopsllm.com/pt/research/background-agents-cost-clock Agentes em segundo plano e o relógio do FinOps Atualizado September 10, 2026 · publicado originalmente September 10, 2026 Resposta rápida: Agentes que operam em segundo plano quebram o modelo de sessão tradicional. O consumo de tokens pode explodir sem supervisão. Implemente tetos orçamentários por tarefa. Agentes que operam em segundo plano quebram o modelo de sessão tradicional. O consumo de tokens pode explodir sem supervisão. Implemente tetos orçamentários por tarefa. Artigos relacionados Três orçamentos para agentes Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Estratégias de cache comparadas · FinOps LLM URL: https://finopsllm.com/pt/research/caching-strategies-compared Estratégias de cache comparadas A cache é uma das táticas de redução de custos com maior alavancagem para cargas de trabalho de LLM. A ideia é direta: não pague por inferência se você conseguir devolver um resultado em cache. Mas "cache" não é uma única técnica — são quatro estratégias distintas com diferentes compensações em economia de custos, latência, precisão e complexidade de implementação. Escolher a errada desperdiça esforço de engenharia; escolher a correta pode reduzir entre 30% e 70% sua fatura. Comparação de estratégias Estratégia Como funciona Economia de custos Impacto na latência Esforço de implementação Ideal para Provedores Cache de prompts (lado do provedor) O provedor armazena em cache o cálculo KV para prefixos de prompts repetidos. Requisições subsequentes com o mesmo prefixo pulam o reprocessamento. 50% em tokens de entrada em cache 60–80% mais rápido na latência do primeiro token Nulo a baixo — automático na maioria dos provedores Prompts de sistema longos, RAG com contexto compartilhado, loops de agentes OpenAI, Anthropic, Google Cache semântico (baseado em embeddings) Incorpora (embed) a consulta do usuário, busca em um armazenamento vetorial por consultas passadas semelhantes. Se a similaridade exceder um limiar, devolve a resposta em cache sem chamar o LLM. 20–50% dependendo da repetição de consultas 50–90% mais rápido (sem chamada ao LLM) Médio — precisa de modelo de embeddings, armazenamento vetorial, ajuste de limiar de similaridade Bots de FAQ, suporte ao cliente, consultas repetitivas Qualquer um (auto-hospedado via GPTCache, Redis com busca vetorial) Cache de contexto (estilo Google) Armazena documentos de contexto grandes (PDFs, repositórios de código) no servidor. Pague uma vez pelo processamento de contexto, reutilize em muitas consultas com custo reduzido por consulta. 70–90% em consultas com muito contexto Melhoria moderada no processamento de contexto Baixo a médio — envie contexto, gerencie TTL Perguntas e respostas sobre documentos, revisão de código em repos grandes, múltiplas rodadas com contexto estático Google (Gemini), Anthropic (contexto de pensamento estendido) Cache no nível de aplicação (Redis/CDN) Hash determinístico da requisição completa (prompt + parâmetros). Armazena a resposta no Redis ou CDN. Devolve a resposta em cache na correspondência exata. Até 100% em acertos de cache 90–99% mais rápido (sem chamada ao LLM) Baixo — infraestrutura de cache padrão Consultas determinísticas, classificação, extração com prompts fixos Qualquer um (infraestrutura que você controla) Cache de prompts em detalhes O cache de prompts é a vitória mais fácil. OpenAI armazena em cache automaticamente prompts mais longos que 1.024 tokens. Anthropic armazena em cache prefixos de 2.048+ tokens. O cache é indexado pelo prefixo exato — mesmo prompt de sistema, mesmos exemplos few-shot, mesmo contexto de documento. Quando há um acerto de cache, você paga 50% menos pela parte em cache dos tokens de entrada. A desvantagem: a invalidação de cache é controlada pelo provedor. Se o prompt mudar mesmo ligeiramente — mensagem de sistema diferente, variável diferente no prefixo — o cache falha. Projete seus prompts para colocar conteúdo estável no início e conteúdo dinâmico no final do prompt. Cache semântico em detalhes O cache semântico pula o LLM completamente quando uma pergunta semelhante foi feita antes. O fluxo: incorpore a consulta, pesquise em um armazenamento vetorial (Pinecone, Qdrant, Redis com busca vetorial), verifique se o resultado principal excede um limiar de similaridade (tipicamente 0,92–0,97) e devolva a resposta em cache se for assim. O risco é devolver respostas obsoletas ou ligeiramente incorretas. Um limiar muito baixo devolve resultados errados; um muito alto significa quase nenhum acerto de cache. Ajuste-o por caso de uso. Para recuperação factual de FAQ, 0,95+ é seguro. Para geração criativa, o cache semântico raramente é apropriado — o ponto todo é a novidade. Cache de contexto em detalhes O cache de contexto do Google permite que você envie um documento grande uma vez e pague uma taxa reduzida para consultas subsequentes contra ele. Isso é poderoso para perguntas e respostas sobre documentos onde você processa o mesmo PDF de 200 páginas centenas de vezes. O modelo de custos: pague a taxa completa de tokens de entrada uma vez para a escrita em cache, depois uma taxa reduzida (geralmente 25% do normal) para cada leitura de cache. A compensação é o TTL. Contextos em cache expiram. Se sua carga de trabalho tem padrões de acesso em rajadas — 500 consultas em uma hora, depois nada por uma semana — o cache pode expirar entre rajadas. Dimensione seu TTL para corresponder ao seu padrão de acesso. Cache no nível de aplicação em detalhes O cache determinístico é a estratégia mais agressiva. Faça hash da carga completa da requisição (prompt, temperatura, tokens máximos, modelo, ferramentas) e armazene a resposta. Na correspondência exata, devolva a resposta em cache instantaneamente — sem chamada ao LLM, sem latência, sem custo. Isso funciona apenas quando a mesma entrada deve sempre produzir a mesma saída. Classificação, extração de entidades, análise de dados estruturados e geração baseada em templates são bons candidatos. Tarefas conversacionais ou criativas não são — os usuários esperam respostas variadas. Combinando estratégias As melhores implementações sobrepõem múltiplas estratégias. Uma pilha típica: cache no nível de aplicação como primeira verificação (mais barata, mais rápida), cache semântico como segunda verificação (captura quase-duplicatas), depois a chamada ao LLM com cache de prompts habilitado no lado do provedor (reduz custo mesmo em falhas de cache). Essa abordagem em camadas pode reduzir o gasto total em LLM entre 40% e 70% em cargas de trabalho com qualquer grau de repetição. Acompanhe as taxas de acerto de cache separadamente para cada camada. Se sua taxa de acerto de cache semântico cair abaixo de 10%, a sobrecarga do armazenamento vetorial pode não valer a pena. Se sua taxa de acerto de cache de aplicação estiver acima de 40%, você provavelmente tem tarefas determinísticas que deveriam ser otimizadas no nível de prompt. Relacionado Cache de prompts explicado — análise mais profunda de cache no lado do provedor. Economia de cache semântico — análise de ROI de cache semântico. Otimização de custos de IA — estratégias de otimização mais amplas. Deseja isso aplicado ao seu próprio gasto com LLM? FinOps LLM executa uma auditoria gratuita de seus custos de IA e mostra onde estão as economias. Agendar auditoria gratuita → Voltar para pesquisa --- # Geração de código com IA mais barata (2026) · FinOps LLM URL: https://finopsllm.com/pt/research/cheapest-ai-code-generation A Forma Mais Barata de Executar Geração de Código com IA As ferramentas de geração de código com IA explodiram em variedade - mas a diferença de custo entre as opções é enorme. Um usuário leve poderia gastar US$ 10/mês com uma abordagem e US$ 200/mês com outra pelos mesmos resultados. Este guia compara todas as categorias de ferramentas de codificação com IA, calcula custos reais mensais para diferentes níveis de uso e fornece uma árvore de decisão para você escolher a opção mais barata que realmente funciona para seu fluxo de trabalho. As quatro categorias Toda ferramenta de geração de código com IA se enquadra em um de quatro modelos de preços: Agentes por assinatura - taxa mensal fixa, uso incluído (Cursor, Copilot, Windsurf, Cody). Agentes baseados em API - você traz sua própria chave API, paga por token (Claude Code, Cline, Aider, Continue com APIs em nuvem). Modelos auto-hospedados - execute modelos de peso aberto localmente ou em sua própria GPU (Continue + Qwen, CodeLlama, DeepSeek Coder). Provedores de planos de codificação - acesso à API com taxa fixa otimizado para cargas de trabalho de codificação ( MiMO , GLM, MiniMax, KwaiKAT). Tabela de comparação de custos Opção Custo Mensal (Leve) Custo Mensal (Pesado) Qualidade do Modelo Esforço de Configuração GitHub Copilot Free US$ 0 US$ 0 Boa Nenhum GitHub Copilot Pro US$ 10 US$ 10 Muito boa Nenhum Cursor Pro US$ 20 US$ 20 Excelente Baixo Windsurf Pro US$ 15 US$ 15 Muito boa Baixo Claude Code (API) US$ 5–15 US$ 50–200 Excelente Médio Cline + chave API US$ 5–20 US$ 40–150 Excelente Médio Plano de codificação MiMO US$ 10–15 US$ 30–60 Muito boa Baixo Plano de codificação GLM US$ 10–15 US$ 30–60 Boa Baixo Continue + modelo local US$ 0 US$ 0 Aceitável Alto Usuário leve: ~2 horas/dia, ~50 solicitações/dia. Usuário pesado: 8+ horas/dia, ~300 solicitações/dia. Os custos de API assumem média de 3K entrada + 1K tokens de saída por solicitação com preços Claude Sonnet ou GPT-4o. Análise por categoria 1. Agentes por assinatura São os mais fáceis de adotar. Você paga uma taxa fixa e recebe uma cota de uso generosa (ou ilimitada). A pegadinha: você está preso à escolha deles de modelo e integração IDE. Cursor Pro (US$ 20/mês) - Melhor UX geral para usuários avançados. Inclui solicitações rápidas (GPT-4o, Claude Sonnet) e lentas (modelos fronteiriços). O limite de 500 solicitações rápidas/mês é suficiente para a maioria dos desenvolvedores. GitHub Copilot (US$ 10/mês) - Opção principal mais barata. Autocompletações são excelentes; chat é bom mas menos poderoso que o modo agente do Cursor. Nível gratuito disponível com limites. Windsurf Pro (US$ 15/mês) - Meio-termo competitivo. Bons recursos agênticos a um preço mais baixo que Cursor. Veredicto: Melhor para desenvolvedores que querem zero configuração e cobrança previsível. Copilot Free é imbatível para usuários preocupados com o orçamento. 2. Agentes baseados em API Você traz sua própria chave API (OpenAI, Anthropic, etc.) e a ferramenta faz chamadas de API em seu nome. Os custos escalam linearmente com o uso - ótimo para usuários leves, caro para usuários pesados. Claude Code - Agente CLI da Anthropic. Usa Claude Sonnet ou Opus. Uma sessão pesada pode custar US$ 2–5 em taxas de API. Cline (VS Code) - Agente de código aberto que funciona com qualquer API. Muito flexível, mas os custos são imprevisíveis sem limites de orçamento. Aider - Baseado em terminal, funciona com qualquer modelo. Popular por sua integração git e abordagem de modo de edição. Veredicto: Melhor para desenvolvedores que desejam flexibilidade de modelo e estão dispostos a monitorar o uso. Usuários leves pagam menos que assinaturas; usuários pesados pagam mais. 3. Modelos auto-hospedados Execute modelos de peso aberto (Qwen 2.5 Coder, DeepSeek Coder V2, CodeLlama) localmente via Ollama, vLLM ou llama.cpp. Custo marginal zero por solicitação - mas você precisa de hardware. Vantagens: Sem custo por token, privacidade total, sem limites de taxa, funciona offline. Desvantagens: Diferença de qualidade vs. modelos fronteiriços (especialmente para refatoração complexa), requer GPU capaz (16GB+ VRAM para bons resultados), fricção de configuração. Veredicto: Melhor para trabalho sensível à privacidade, ambientes offline ou equipes com infraestrutura GPU existente. Não recomendado como seu único modelo - combine com um modelo em nuvem para tarefas difíceis. 4. Provedores de planos de codificação Uma categoria mais nova: provedores que oferecem acesso à API com taxa fixa ou com desconto pesado especificamente para agentes de codificação. Estes colmam a lacuna entre o caro preço de API por token e ferramentas rígidas de assinatura. Plano de codificação MiMO - Preços competitivos com fortes capacidades de raciocínio. Bom equilíbrio entre custo e qualidade. GLM (Zhipu) - Provedor chinês com preços agressivos para cargas de trabalho de codificação. MiniMax / KwaiKAT - Provedores emergentes com níveis de preço otimizados para codificação. Veredicto: Melhor para usuários de agentes baseados em API que desejam reduzir custos sem mudar para auto-hospedado. A qualidade varia - faça benchmark em suas tarefas reais antes de se comprometer. Árvore de decisão Siga isto para encontrar sua opção mais barata: Se você programa <2 horas/dia: Use GitHub Copilot Free . Custo zero, autocompletações excelentes. Se atingir os limites, atualize para Copilot Pro (US$ 10/mês). Se você programa 2–6 horas/dia: Use Cursor Pro (US$ 20/mês) ou Windsurf Pro (US$ 15/mês) . A taxa fixa é mais barata que custos de API neste volume. Alternativamente, use um provedor de plano de codificação como MiMO com Cline por US$ 10–30/mês. Se você programa 8+ horas/dia: Use um agente baseado em API com um plano de codificação (MiMO, GLM) a US$ 30–60/mês. Chaves de API padrão (Claude, GPT-4o) custarão US$ 100–200/mês neste volume. Considere um modelo local para completações de rotina para reduzir ainda mais os custos. Os custos ocultos que ninguém menciona Desperdício de janela de contexto. A maioria dos agentes de codificação envia seu arquivo completo + histórico de conversação em cada solicitação. Um contexto de 50K tokens em GPT-4o custa US$ 0,125 por solicitação apenas em entrada. Com 200 solicitações/dia, isso são US$ 25/dia - mais que uma assinatura mensal do Cursor. Loops de retentativa. Ferramentas agênticas que tentam novamente automaticamente edições falhadas podem queimar tokens rapidamente. Defina limites rígidos no número de tentativas. Sobrecarga de troca de modelo. Algumas ferramentas usam por padrão o modelo mais caro. Verifique suas configurações - solicitações "lentas" do Cursor usam modelos mais baratos e muitas vezes são rápidas o suficiente. Conclusão Para a maioria dos desenvolvedores, um agente por assinatura (Copilot ou Cursor) é a opção mais barata porque limita seus custos independentemente do uso. Para usuários avançados dispostos a gerenciar chaves de API, provedores de planos de codificação como MiMO oferecem a melhor relação custo-qualidade. Modelos auto-hospedados são gratuitos mas com qualidade limitada - melhor como complemento, não como substituto. O que quer que escolha, rastreie seu gasto por ferramenta para poder reavaliar conforme os preços mudem. Relacionado Comparação de planos de codificação IA - benchmark detalhado de provedores de planos de codificação. Quanto custa o GPT-5? - preços de modelos fronteiriços explicados. Arbitragem de provedores - abordagem sistemática para encontrar modelos mais baratos. Roteamento de modelos - enviar tarefas para o nível de custo correto. Quer isso aplicado aos seus próprios gastos com LLM? FinOps LLM executa uma auditoria gratuita dos seus custos de IA e mostra onde estão as economias. Agendar auditoria gratuita → Voltar para pesquisa --- # Fable 5.1: 10/50 dólares e o cache decide · FinOps LLM URL: https://finopsllm.com/pt/research/claude-fable-5-1-cost-model Modelo de custo do Claude Fable 5.1 Atualizado September 1, 2026 · publicado originalmente September 1, 2026 Resposta rápida: O Claude Fable 5.1 (claude-fable-5-1) custa 10 dólares por milhão de tokens de entrada e 50 por milhão de saída; o Opus 5 custa 5 e 25. Parece um prémio fixo de 2×, mas o tarifário de cache vai... O Claude Fable 5.1 ( claude-fable-5-1 ) custa 10 dólares por milhão de tokens de entrada e 50 por milhão de saída; o Opus 5 custa 5 e 25. Parece um prémio fixo de 2×, mas o tarifário de cache vai no sentido oposto. As quatro tarifas que importam A escrita em cache custa 12,50 dólares por milhão (TTL de 5 minutos) e 20,00 (TTL de uma hora). A leitura de cache custa 0,25 por milhão: 2,5% do próprio preço de entrada e metade do que o mesmo token em cache custa no Opus 5. Todas as linhas são 2×; essa é 0,5×. Numa carga real Um prefixo de 100.000 tokens custa 1,00 dólar a frio no Fable e 0,50 no Opus 5. A quente, 0,025 contra 0,05. O fornecedor mais caro passa a ser o mais barato com o mesmo prompt. O ponto de equilíbrio é uma taxa de acerto de cache perto de 50%. A saída não tem tecto O contexto chega a um milhão de tokens e a saída a 128.000. A 50 dólares por milhão, uma única resposta de 128K custa 6,40. O raciocínio alargado está sempre activo e a configuração explícita devolve erro 400: o controlo de custo é o parâmetro effort , de baixo a máximo. Não há Priority Tier, pelo que a latência se gere com concorrência própria. O que instrumentar antes de encaminhar tráfego Meça a taxa de acerto de cache por funcionalidade, a amplificação das escritas em cache e os tokens de saída por tarefa bem-sucedida. Compare depois com uma ponte de variação que separe tarifa, volume e mistura; uma média esconde os dois movimentos opostos. Artigos relacionados Economia do cache de prompts Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Claude Opus 5.5: $4/$20 e leitura de cache por $0.20 · FinOps LLM URL: https://finopsllm.com/pt/research/claude-opus-5-5-cost-model Modelo de custo do Claude Opus 5.5 Atualizado September 22, 2026 · publicado originalmente September 22, 2026 Anthropic lançou Claude Opus 5.5 ( claude-opus-5-5 ) em 22 de setembro de 2026. O preço anunciado é de $4 por milhão de tokens de entrada e $20 por milhão de tokens de saída, reduzido de $5 e $25 no Opus 5. Isso é um corte de 20%. Para a maioria das cargas de trabalho de produção, o corte real é maior, porque a taxa que mais se moveu é a que o título omite. As taxas que importam Tipo de token Opus 5.5 Opus 5 Fable 5.1 Entrada (sem cache) $4.00 / MTok $5.00 / MTok $10.00 / MTok Saída $20.00 / MTok $25.00 / MTok $50.00 / MTok Escrita em cache (5 min) $5.00 / MTok $6.25 / MTok $12.50 / MTok Leitura de cache $0.20 / MTok $0.50 / MTok $0.25 / MTok Modo rápido (entrada / saída) $8 / $40 — — Cada linha é 20% mais baixa exceto a leitura de cache, que é 60% mais barata. A $0.20 agora é mais barato que o $0.25 do Fable 5.1. Isso inverte a única linha onde Fable costumava ganhar. Em nosso modelo de custo Fable 5.1 , uma carga de trabalho muito em cache poderia sair mais barata no Fable do que no Opus 5. Contra Opus 5.5, isso não acontece mais. Fable custa mais em cada tipo de token. Por que uma tarefa típica custa cerca de 40% menos A alegação de Anthropic é uma queda de 40% no custo para um trabalho típico, não 20%. O extra vem da eficiência de tokens. Anthropic diz que Opus 5.5 alcança o mesmo resultado com cerca de 20% menos tokens de entrada e saída e escreve cerca de 40% menos saída verbosa. Uma taxa mais baixa vezes menos tokens se compõe: 0.8 × 0.8 = 0.64, que é aproximadamente 36–40% de desconto dependendo da mistura. Aqui está uma etapa de agente: 200.000 tokens de entrada, 90% servidos do cache, e 20.000 tokens de saída. Linha Opus 5 Opus 5.5 (mesmos tokens) Fable 5.1 20K entrada sem cache $0.100 $0.080 $0.200 180K entrada em cache $0.090 $0.036 $0.045 20K saída $0.500 $0.400 $1.000 Total $0.690 $0.516 $1.245 Em tokens idênticos, Opus 5.5 é 25% mais barato que Opus 5, não 20%, por causa do desconto de cache. Se a redução de 20% de tokens se mantiver para sua carga de trabalho, a etapa cai para cerca de $0.41, que é 40% abaixo de Opus 5 e um terço do custo de Fable. A saída ainda é cerca de 80% da fatura neste exemplo. É aí que a redução de verbosidade compensa. Custo por tarefa contra GPT-6 Sol, GPT-6 Astra e Fable 5.1 Preços de tabela por milhão de tokens e o mesmo passo de agente de cima (200K de entrada, 90% em cache, 20K de saída) calculado em cada modelo. Modelo Entrada $/MTok Saída $/MTok Leitura de cache $/MTok Mesmo passo de agente GPT-6 Sol $2.00 $10.00 $0.20 $0.276 Claude Opus 5.5 $4.00 $20.00 $0.20 $0.516 Claude Opus 5 $5.00 $25.00 $0.50 $0.690 Claude Fable 5.1 $10.00 $50.00 $0.25 $1.245 GPT-6 Astra $10.00 $50.00 $1.00 $1.380 Custo por tarefa medido no Artificial Analysis Intelligence Index v4.3.2, consultado em 22 de setembro de 2026, ordenado por pontuação. O GPT-6 Sol é a forma mais barata de chegar a qualquer pontuação até 47,5. Acima disso, o Opus 5.5 é o mais barato em todos os níveis: o Opus 5.5 high pontua 53,6 por US$ 1,82, enquanto o GPT-6 Astra max pontua 52,7 por US$ 3,26 e o Fable 5.1 max pontua 53,4 por US$ 7,63. Modelo Intelligence Index Custo por tarefa Tokens de saída por tarefa GPT-6 Sol · medium 39.8 $0.25 6,500 GPT-6 Sol · xhigh 44.1 $0.53 16,000 GPT-6 Astra · low 45.8 $0.82 4,400 GPT-6 Sol · max 47.5 $1.06 31,200 Claude Opus 5 · high 48.1 $3.61 46,200 Claude Opus 5 · max 50.8 $5.86 72,500 Claude Opus 5.5 · medium 51.2 $1.34 25,700 Claude Fable 5.1 · high 51.2 $3.91 38,100 GPT-6 Astra · max 52.7 $3.26 27,200 Claude Fable 5.1 · max 53.4 $7.63 78,100 Claude Opus 5.5 · high 53.6 $1.82 35,600 Claude Opus 5.5 · max 57.6 $5.98 119,200 Todas as configurações do GPT-6 Astra acima de low, todas as do Opus 5 e todas as do Fable 5.1 custam mais do que uma configuração do Sol ou do Opus 5.5 com pontuação igual ou maior. O custo por tarefa depende da mistura de tarefas do benchmark. Reproduza o seu próprio tráfego antes de trocar de modelo. É bom o bastante para substituir Fable? Anthropic posiciona Opus 5.5 como correspondendo a Fable 5.1 na maioria das tarefas. Os números publicados apoiam isso para trabalho de codificação e agentivo: Terminal-Bench 4.0: 66.4%, contra 52.3% para Opus 5 e 55.8% para Fable 5.1. FrontierCode v1.1: 54.4%, contra 48.0% para Opus 5 e 50.3% para Fable 5.1. CursorBench 4.0: 57.8%, contra 46.6% para Opus 5. GDPval-AA v2.1: 1846 Elo, contra 1708 para Opus 5. Artificial Analysis o classificou em primeiro lugar no seu Índice de Inteligência no dia do lançamento. Anthropic também diz que no esforço padrão (médio), ele supera GPT-6 Astra no esforço máximo em trabalho de conhecimento por cerca de um quinto do custo por tarefa. Essa é uma comparação de fornecedor, então trate-a como uma hipótese a testar. A matemática de custos acima é a parte que você pode verificar por conta própria. Modo rápido custa 2× O modo rápido custa $8 de entrada e $40 de saída, exatamente o dobro da taxa padrão, por até 2.5× a velocidade. O modelo padrão também é cerca de 30% mais rápido que Opus 5. Use o modo rápido para caminhos interativos vinculados à latência onde um usuário está esperando. Mantenha-o desligado para trabalhos em lote, agentes em segundo plano e avaliações. Quando o modo rápido está habilitado por padrão, o custo unitário dobra e o painel não mostra nada incomum até que a fatura chega. O que fazer esta semana Fixe o ID do modelo. Aponte a produção para claude-opus-5-5 explicitamente e registre o ID em cada solicitação, para que o custo por solicitação possa ser dividido por modelo após a migração. Re-calibre em seu próprio tráfego. Reproduza uma amostra de solicitações reais em ambos os modelos e compare tokens por tarefa completada, não por chamada. A afirmação de eficiência de 20% de tokens é a parte mais propensa a variar por carga de trabalho. Re-verifique as configurações de esforço. Se uma carga de trabalho se moveu para Fable ou para esforço máximo por qualidade, teste Opus 5.5 no nível médio primeiro. Essa é a configuração contra a qual Anthropic faz benchmark. Re-execute a decisão de roteamento de Fable. Qualquer rota que enviou tráfego pesado em cache para Fable para obter a leitura de cache mais barata deve ser reavaliada. Essa vantagem de custo desapareceu. Monitore a taxa de acerto do cache. A $0.20 contra $4.00, uma falha de cache agora custa 20× um acerto. Uma mudança de modelo de prompt que quebra o prefixo custa mais que no Opus 5. Anthropic diz que Sonnet 5.5 e Haiku 5.5 seguirão nas próximas semanas. Mantenha o arnês de repetição da etapa 2 para que cada lançamento possa ser re-calibrado em uma tarde. Artigos relacionados Modelo de custo do Claude Fable 5.1 Economia de cache de prompt Níveis de esforço do Opus 5.5 são o preço real Economia do modo rápido Opus 5.5 Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Comparação de Planos de Codificação IA · FinOps LLM URL: https://finopsllm.com/pt/research/coding-plan-comparison Comparação de Planos de Codificação IA Compare os principais planos de codificação IA com evidência verificável. Preços, limites e pontuações de modelos em uma tabela normalizada. Construído a partir da documentação de provedores e regras de conversão explícitas para uma comparação justa. 9 Provedores rastreados 29 Planos comparados 62 Modelos listados Jul 2026 Última atualização Cada atualização está vinculada a evidência pública As regras de conversão Solicitação/Prompt são explícitas A lógica de cálculo fixa mantém as comparações consistentes Metodologia Coleta Os dados de planos, limites e modelos são coletados de fontes públicas de provedores. Normalização Os formatos de solicitação/período são normalizados em um modelo de comparação único. Regras de conversão Solicitação/Prompt = 15 e Semanal × 4 = Mensal são aplicados explicitamente. Política de exibição Os valores oficiais e estimados são claramente separados na interface. Feed de Atualizações 4 jul 2026 Página de pesquisa de comparação de planos lançada Publicada a comparação baseada em evidência de planos de codificação IA como um artigo de pesquisa da FinOps LLM. 27 mai 2026 Cota de Xiaomi MiMO aumentada Xiaomi MiMO aumentou os limites de uso disponíveis e a tabela de comparação foi atualizada. 1 mai 2026 Alibaba descontinua Plano de Codificação, adiciona Plano de Tokens Alibaba encerrou o Plano de Codificação anterior e introduziu o Plano de Tokens (Edição em Equipe). Lista de Comparação de Planos de Codificação Taxa de conversão Solicitação / Prompt (padrão = 15) 1 Prompt = 15 Solicitações Ordenar Ordem padrão Melhor valor ≤ $10 Melhor valor ≤ $30 Melhor valor (todos) Mostrar: Todos Codificação Agente Provedor ↕ Plano ↕ Preço ↕ Uso Prompt / mês ↕ Solicitação / mês ↕ Prompt / $1 ↕ Solicitação / $1 ↕ Modelos Inteligência ↕ Codificação ↕ Agente ↕ GLM Lite $10 Codificação + Agente 160 2.400 16 240 GLM-5.1 (×3), GLM-5-Turbo (×3), GLM-4.7 (×1) 47 37 66 GLM Pro $30 Codificação + Agente 267 4.000 8,9 133 GLM-5.1 (×3), GLM-5-Turbo (×3), GLM-5 (×3) 50 44 63 GLM Max $80 Codificação + Agente 400 6.000 5 75 GLM-5.1 (×3), GLM-5-Turbo (×3), GLM-5 (×3) 50 44 63 MiniMax Starter $10 Codificação + Agente 400 6.000 40 600 MiniMax-M2.7 (×1) 50 42 61 MiniMax Plus $20 Codificação + Agente 600 9.000 30 450 MiniMax-M2.7 (×1) 50 42 61 MiniMax Max $45 Codificação + Agente 889 13.333 19,8 296 MiniMax-M2.7 (×1) 50 42 61 MiniMax Plus-HighSpeed $40 Codificação + Agente 300 4.500 7,5 112,5 MiniMax-M2.7-highspeed (×1) 50 42 61 MiniMax Max-HighSpeed $80 Codificação + Agente 500 7.500 6,25 93,75 MiniMax-M2.7-highspeed (×1) 50 42 61 MiniMax Ultra-HighSpeed $150 Codificação + Agente 533 8.000 3,55 53,3 MiniMax-M2.7 (×1) 50 42 61 BytePlus Lite $10 Codificação + Agente 120 1.800 12 180 Seed-Code (×1), GLM-4.7 (×1), DeepSeek-V3.2 (×1), kimi-k2.5 (×1) 34 31 36 BytePlus Pro $50 Codificação + Agente 120 1.800 2,4 36 Seed-Code (×1), GLM-4.7 (×1), DeepSeek-V3.2 (×1), kimi-k2.5 (×1) 34 31 36 StepFun Flash Mini $6.99 Codificação 229 3.433 32,8 491 step-3.5-flash (×1) 38 32 52 StepFun Flash Plus $9.99 Codificação 641 9.610 64,2 962 step-3.5-flash (×1) 38 32 52 StepFun Flash Pro $29 Codificação 828 12.414 28,6 428 step-3.5-flash (×1) 38 32 52 StepFun Flash Max $99 Codificação 808 12.121 8,16 122,4 step-3.5-flash (×1) 38 32 52 KwaiKAT Mini $5 Codificação 1.075 16.128 215 3.226 KAT-Coder-Pro V2 (×1) 44 46 51 KwaiKAT Starter $10 Codificação 1.344 20.160 134,4 2.016 KAT-Coder-Pro V2 (×1) 44 46 51 KwaiKAT Pro $20 Codificação 2.016 30.240 100,8 1.512 KAT-Coder-Pro V2 (×1) 44 46 51 KwaiKAT Max $50 Codificação 2.688 40.320 53,76 806,4 KAT-Coder-Pro V2 (×1) 44 46 51 OpenCode Go $10 Codificação + Agente 667 10.000 66,7 1.000 MiniMax-M2.5 (×1), M2.7 (×1.4), MiMo-V2-Pro (×16), kimi-k2.5 (×11), GLM-5 (×17) 50 44 63 Xiaomi MiMO Cadastre-se - ambos ganham $2 ↗ Lite $6 Codificação + Agente 380 5.693 63,3 949 MiMo-V2-Pro (×1), MiMo-V2-Omni (×1) 49 41 63 Xiaomi MiMO Cadastre-se - ambos ganham $2 ↗ Standard $16 Codificação + Agente 382 5.729 23,9 578 MiMo-V2-Pro (×1), MiMo-V2-Omni (×1) 49 41 63 Xiaomi MiMO Cadastre-se - ambos ganham $2 ↗ Pro $50 Codificação + Agente 422 6.333 8,44 126,7 MiMo-V2-Pro (×1), MiMo-V2-Omni (×1) 49 41 63 Xiaomi MiMO Cadastre-se - ambos ganham $2 ↗ Max $100 Codificação + Agente 456 6.833 4,56 68,3 MiMo-V2-Pro (×1), MiMo-V2-Omni (×1) 49 41 63 Alibaba Standard $30 Codificação + Agente 17 262 0,57 8,73 qwen3.6-plus (×1), deepseek-v3.2 (×1), GLM-5 (×1), MiniMax-M2.5 (×1) 50 43 62 Alibaba Advanced $100 Codificação + Agente 21 314 0,21 3,14 qwen3.6-plus (×1), deepseek-v3.2 (×1), GLM-5 (×1), MiniMax-M2.5 (×1) 50 43 62 Alibaba Premium $200 Codificação + Agente 26 393 0,13 1,97 qwen3.6-plus (×1), deepseek-v3.2 (×1), GLM-5 (×1), MiniMax-M2.5 (×1) 50 43 62 Os valores não explicitamente fornecidos pelos provedores são exibidos em cinza . Muitos provedores limitam as cotas de Solicitação ou Prompt. Convertemos dinamicamente usando o controle de taxa Solicitação/Prompt acima (padrão: 15). Se o limite oficial mais alto for semanal, o mensal é estimado como Semanal × 4. A Pontuação de Análise Artificial é medida por artificialanalysis.ai . Alguns links podem incluir códigos de referência. Os detalhes dos planos podem mudar com frequência. Sempre verifique as informações mais recentes nas páginas oficiais dos provedores. Guia Prático O preço sozinho não é suficiente. Adapte cada plano ao seu estilo de trabalho primeiro. Comece com a política de Agente, tipo de limite e horizonte de contrato. 1) Verifique a política de Agente primeiro Alguns provedores ou planos restringem o uso de Agente. Se fluxos de trabalho de Agente são importantes, verifique os termos e a coluna Uso (Codificação / Agente) antes de se inscrever. 2) Limites de Prompt vs Solicitação Para uso intensivo de chat manual, agrupar o trabalho em menos turnos geralmente se alinha melhor com limites do tipo Prompt. Para automação e fluxos pesados de Agente, o volume de solicitações backend pode crescer rapidamente, então priorize planos com espaço suficiente de Solicitação. 3) Prefira mensal, use anual quando os termos iniciais forem superiores Revisões de planos e mudanças de inscrição são cada vez mais comuns. Mensal oferece flexibilidade, enquanto anual pode ser eficaz quando os termos do período de lançamento são claramente vantajosos. 4) Velocidade (token/s) é um fator real de produtividade Com a mesma cota, respostas mais lentas ainda custam mais tempo de trabalho. Planejamos adicionar métricas de token por segundo em uma atualização futura. Verificações adicionais Separe valores Fornecidos de Estimados (as estimativas podem mudar) Confirme disponibilidade de modelos da mesma classe (nenhum significa indisponível) Adapte o ciclo de reinício (5h / diário / mensal) à sua janela de uso real Quer que isso seja aplicado ao seu próprio gasto em IA? FinOps LLM executa uma auditoria gratuita de seus custos em IA e mostra onde estão as economias. Solicite sua auditoria gratuita → Voltar para pesquisa --- # O compromisso de gasto aposta na previsão · FinOps LLM URL: https://finopsllm.com/pt/research/committed-spend-discounts Descontos por compromisso de gasto Atualizado September 1, 2026 · publicado originalmente September 1, 2026 Resposta rápida: Assim que o seu gasto em modelos se nota, o fornecedor oferece desconto em troca de volume comprometido. Capacidade reservada, compromisso anual, throughput aprovisionado: muda a forma, não a troca.... Assim que o seu gasto em modelos se nota, o fornecedor oferece desconto em troca de volume comprometido. Capacidade reservada, compromisso anual, throughput aprovisionado: muda a forma, não a troca. Estão a pagar-lhe para ser previsível. Os três riscos Subutilizar é o óbvio e o menor: comprometa abaixo do seu cenário conservador, não do plano. Ficar preso a um modelo é maior. A fronteira move-se em meses; doze meses no topo de hoje é apostar que nada mais barato chega — e chega todos os trimestres há três anos. Perder a capacidade de mudar é o maior e nunca entra no modelo: retira alavancagem na próxima negociação e mata o trabalho de encaminhamento, porque ninguém tira tráfego de um modelo já pré-pago. Como avaliar Compare com o contrafactual honesto: o que teria pago a pedido no mesmo período, incluindo as descidas de preço que historicamente acontecem nele. A doze meses é muitas vezes 20–40% abaixo da tabela atual. Comprometa um piso , não um plano. Prefira compromissos de gasto a compromissos de modelo. Exija transporte do volume não usado. Mantenha o prazo curto. Artigos relacionados Guia de compra de LLM Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Paga duas vezes pela janela de contexto · FinOps LLM URL: https://finopsllm.com/pt/research/context-window-paid-twice Pagar duas vezes a janela de contexto Atualizado September 1, 2026 · publicado originalmente September 1, 2026 Resposta rápida: Uma janela de contexto é anunciada como capacidade: 200.000 tokens, um milhão, espaço para o que precisar. A capacidade não é a unidade de faturação. Cobram-lhe o que envia, e numa conversa de vários... Uma janela de contexto é anunciada como capacidade: 200.000 tokens, um milhão, espaço para o que precisar. A capacidade não é a unidade de faturação. Cobram-lhe o que envia , e numa conversa de vários turnos volta a enviar quase tudo em cada turno. É esse o segundo pagamento. Um documento de 30.000 tokens carregado no início de uma conversa de vinte turnos não são 30.000 tokens de entrada: são perto de 600.000. A conta que ninguém faz O custo cresce com o quadrado do comprimento da conversa, não linearmente. Duplicar os turnos quase quadruplica os tokens de entrada. Quem modela "custo por mensagem" e multiplica subestima muito as sessões longas. Costuma haver uma terceira cobrança: muitos fornecedores aplicam um preço superior acima de um limiar de contexto longo. Um anexo a mais pode atravessar essa linha e reencarecer a chamada inteira. O que medir Acompanhe a utilização do contexto : tokens enviados versus tokens realmente necessários. Meça tokens de entrada por conversa , não por pedido, e vigie o p99. Três correções Coloque o prefixo estável em cache — o maior retorno em qualquer produto de vários turnos. Corte o histórico deliberadamente: resuma a parte antiga e descarte os turnos em bruto. Envie o excerto, não o corpus. Artigos relacionados Economia da cache de prompts Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # O que custa uma imagem utilizável · FinOps LLM URL: https://finopsllm.com/pt/research/cost-per-approved-image Custo por ativo aprovado em imagem e vídeo Atualizado September 1, 2026 · publicado originalmente September 1, 2026 Resposta rápida: O preço de imagem e vídeo parece invulgarmente simples: tanto por imagem, tanto por segundo. É essa simplicidade que faz quase toda a gente orçamentar mal. O fornecedor cobra gerações. O negócio... O preço de imagem e vídeo parece invulgarmente simples: tanto por imagem, tanto por segundo. É essa simplicidade que faz quase toda a gente orçamentar mal. O fornecedor cobra gerações . O negócio consome ativos aprovados . A taxa de aceitação é o modelo inteiro Ninguém publica o primeiro render. Com um estilo maduro, talvez aceite um em três; em exploração criativa, um em dez. O vídeo é pior: um clipe falha por movimento, consistência temporal ou um único fotograma — e paga o clipe todo à mesma. A aritmética útil não é o preço de tabela, mas o preço a dividir pela taxa de aceitação. O que move mesmo o número Não a resolução, mas tudo o que sobe a aceitação: iterar em baixa resolução e só escalar o escolhido, uma biblioteca de prompts para estilos conhecidos, imagens de referência e seeds fixas, e um briefing escrito antes da primeira geração. Meça o que interessa Gerações por ativo aprovado e custo por ativo aprovado. Quinze por aprovação é problema de briefing, não de preço. Artigos relacionados Atribuição de custos de LLM Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # O custo por tarefa bem-sucedida supera o custo por pedido · FinOps LLM URL: https://finopsllm.com/pt/research/cost-per-successful-task O custo por tarefa bem-sucedida supera o custo por pedido Atualizado August 27, 2026 · publicado originalmente August 27, 2026 Resposta rápida: O custo por pedido é útil, mas um pedido falhado não é trabalho concluído. O indicador mais forte é o custo por tarefa bem-sucedida: toda a despesa atribuível dividida pelas tarefas que atingem um... O custo por pedido é útil, mas um pedido falhado não é trabalho concluído. O indicador mais forte é o custo por tarefa bem-sucedida : toda a despesa atribuível dividida pelas tarefas que atingem um limite de qualidade. A fórmula custo por tarefa = despesa atribuível / tarefas bem-sucedidas . Inclua tokens, ferramentas, retries e fallbacks. Defina sucesso antes da medição. Meça o denominador Ligue cada span do modelo a um evento de resultado. Registe sucesso, motivo da falha, reparação humana e latência, e reconcilie o custo com a fatura. Pedido barato com tarefa bem-sucedida cara indica um problema de qualidade, retries ou regras de paragem. Artigos relacionados Monitorização de custos LLM Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # O custo real de mudar de fornecedor LLM · FinOps LLM URL: https://finopsllm.com/pt/research/cost-switching-llm-providers O custo real de mudar de fornecedor LLM Atualizado August 27, 2026 · publicado originalmente August 27, 2026 Resposta rápida: Mudar de fornecedor LLM não é apenas comparar preços. Inclui engenharia, prompts, esquemas, avaliação, operação dupla, transferência, suporte e risco de qualidade.Conte o trabalhoFaça o inventário de... Mudar de fornecedor LLM não é apenas comparar preços. Inclui engenharia, prompts, esquemas, avaliação, operação dupla, transferência, suporte e risco de qualidade. Conte o trabalho Faça o inventário de SDK, ferramentas, formatos, limites, contexto, segurança, observabilidade e erros específicos. Estime horas de engenharia e testes. Meça a qualidade Execute a mesma carga nos dois fornecedores e meça sucesso, latência, retries, reparação humana e concordância dos avaliadores. Calcule o retorno Compare poupança mensal total com migração, avaliação, operação dupla e gateway. Routing pode ser melhor do que substituir totalmente. Artigos relacionados Arbitragem entre fornecedores Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Sete padrões defensivos do DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/pt/research/deepseek-harness-defensive-patterns Sete padrões defensivos da documentação do DeepSeek Harness Atualizado August 16, 2026 · publicado originalmente August 16, 2026 Resposta rápida: O DeepSeek Harness traz um documento curto de padrões defensivos, cada um escrito como regra geral acompanhada do bug específico que a motivou. É o arquivo mais transferível do repositório: nada ali... O DeepSeek Harness traz um documento curto de padrões defensivos, cada um escrito como regra geral acompanhada do bug específico que a motivou. É o arquivo mais transferível do repositório: nada ali depende de adotar o harness, e cada item corresponde a um modo de falha que aparece em runtimes de agente caseiros. 1. Relate resultados ortogonais de forma independente Nunca aninhe o relato de uma flag dentro do condicional de outra. Um processo pode estourar o tempo e sair com zero, porque capturou o sinal e desligou limpo. Se o timeout só é relatado dentro do ramo de saída diferente de zero, esse desfecho some. Timeout, sinal e código de saída são fatos independentes e precisam de campos independentes. Relevância de custo: timeouts engolidos em silêncio são como surgem os laços de retentativa. O chamador vê sucesso, não obtém nada útil e tenta de novo. 2. Honre os contratos públicos dos dois lados Quando um desfecho tem várias representações válidas, normalize-as antes de expô-las. O exemplo trabalhado são as falhas de requisição ao modelo: implementações podem lançar ou emitir um chunk de finalização com erro, e a fronteira da API normaliza tudo para um chunk terminal. Sem isso, um chamador que captura uma exceção não sabe se ela veio do provedor, do middleware, do logging ou do próprio código. 3. Estado assíncrono não é estado síncrono Consultas de status não são causalmente ligadas a operações assíncronas específicas. Esperar o estado idle de um agente como sinal de conclusão de uma mensagem é errado, porque múltiplas operações na fila compartilham intervalos de execução — o idle pode chegar antes da sua rodar, ou depois da de outro. A correção prescrita: um chamador de automação dono de uma execução define seu intervalo explicitamente, do recebimento na caixa até o próximo idle do agente inteiro, e atribui saídas a esse intervalo em vez de a mensagens isoladas. Trate também o ramo de nada-a-esperar, ou o chamador trava indefinidamente. Um harness de automação que trava esperando o sinal de idle errado mantém uma sessão e seus filhos residentes. A conta disso não é o travamento: é tudo que segue vivo por trás. 4. O dispose deve alcançar a quiescência, não apenas pedi-la Pedir a terminação não é alcançá-la. O dispose aguarda a terminação real dos filhos antes de retornar. E os registros de ouvintes fecham antes do envio dos sinais de kill, para que finalizações tardias aterrissem em silêncio em vez de disparar callbacks num sistema meio desmontado. É o padrão com a borda financeira mais clara. Um dispose que retorna cedo deixa subprocessos órfãos e sandboxes não fechadas rodando, e computação medida não para porque o pai esqueceu dela. 5. Contenha exceções de callback no despachante Envolva os laços de despacho em try/catch. Um assinante que falha não pode rejeitar a promessa de despacho nem matar de fome os ouvintes enfileirados atrás. Num runtime de agentes, o ouvinte faminto costuma ser justamente o que faz a contabilidade, e é assim que registros de uso somem sem nenhum erro aflorar. 6. Nunca entregue a saída não confiável o ambiente ambiente ou caminhos previsíveis A regra mais forte do documento e a primeira a adotar. Limpe o ambiente dos comandos lançados: remova variáveis que casem com key, secret, token e password antes de o subprocesso iniciar. Use diretórios privados criados com permissões só do dono, nomes de arquivo aleatórios e aberturas exclusivas em vez de caminhos previsíveis. São duas ameaças distintas. A limpeza de ambiente impede que credenciais do harness vazem na saída do subprocesso que o modelo depois lê — e, uma vez lida, essa saída está no log de sessão e na janela de contexto. Nomes aleatórios e criação exclusiva fecham corridas de symlink em diretórios temporários compartilhados. 7. Desfaça o vínculo de caminhos em forma de link Verifique se um caminho é um link simbólico antes de removê-lo, e apague o link em vez de segui-lo. Remoção recursiva fica reservada a diretórios reais confirmados, porque pode atravessar symlinks até seus alvos e lança em junctions. Código de limpeza que apaga mais do que criou é um modo de falha sem teto de dano. Como usar esta lista Leve hoje os padrões 1 e 4 ao seu código de desmontagem de subprocessos e sandboxes. É ali que o dinheiro vaza. Leve o padrão 6 a qualquer lugar onde você lança um processo cuja saída o modelo vai ler. Leve o padrão 3 à sua camada de automação, sobretudo onde uma espera é expressa como "até o agente ficar idle". Leve o padrão 5 ao seu pipeline de telemetria e confira que um ouvinte falho não consegue matar de fome o da contabilidade. Artigos relacionados O que é DeepSeek Harness? Guia completo Limites de gasto no harness (EN) Subagentes e profundidade de delegação (EN) O log de sessão como registro de custos (EN) Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Instalar o DeepSeek Harness: perfis e primeiro uso · FinOps LLM URL: https://finopsllm.com/pt/research/deepseek-harness-getting-started DeepSeek Harness: instalação, perfis e primeira execução Atualizado August 16, 2026 · publicado originalmente August 16, 2026 Resposta rápida: Esta é a metade prática da nossa cobertura do DeepSeek Harness: como colocar o dsh para rodar, o que o modelo de composição espera de você, e quais demos valem dez minutos. O caminho mais rápido npx... Esta é a metade prática da nossa cobertura do DeepSeek Harness: como colocar o dsh para rodar, o que o modelo de composição espera de você, e quais demos valem dez minutos. O caminho mais rápido npx @deepseek-ai/dsh web Isso inicia a interface web em http://127.0.0.1:3080 . Dali, duas coisas precisam acontecer antes que o compositor de sessão fique utilizável: Configurações → Modelos , e inserir sua chave de API da DeepSeek. A rota é habilitada na hora, sem reiniciar. Escolher espaço de trabalho , para adicionar e ativar o diretório do projeto. Enquanto não houver um espaço ativo, o compositor fica indisponível. Uma vez em execução, o agente pode ler e editar arquivos, rodar comandos, delegar tarefas a subagentes e planejar. Ele pede confirmação conforme a política de permissões ativa. A partir do código git clone https://github.com/deepseek-ai/deepseek-harness pnpm install pnpm run build pnpm dsh web Pisos a considerar: Node 22.19 ou mais recente (a CI cobre 22.19, 24 e 26), Git 2.26 ou mais recente, e Corepack com pnpm fixado em pnpm@11.7.0 . Uma DEEPSEEK_API_KEY é opcional, lida do ambiente ou de um .env ignorado pelo git na raiz do repositório; ao lado dela, DEEPSEEK_BASE_URL pode apontar para outro endpoint. As suítes de ponta a ponta contra a API real se autoignoram quando a chave está ausente, então um checkout sem chave compila e testa sem problemas. Perfis e bundles: o modelo de composição Como cada parte do harness é um plugin, algo precisa dizer quais plugins são carregados. Isso é um perfil : uma composição nomeada que guarda uma lista ordenada de bundles mais os patches do usuário. Um bundle distribui linhas de configuração do Cordis e código. Três perfis modelo acompanham o projeto: Perfil O que compõe dsh-base Adaptadores de modelo, ferramentas, persistência dsh-web-app A interface de navegador dsh-headless Executor de passada única A ordem de sobreposição em quatro camadas A configuração resolve em ordem fixa, com as camadas posteriores vencendo: Bundles do perfil Patches do perfil Patches no nível home Overlays de linha de comando Aprenda essa ordem antes de começar a depurar. Quase toda pergunta do tipo «por que está usando esse modelo» num sistema de configuração em camadas se responde descobrindo qual camada tocou o valor por último, e um overlay de linha de comando vence tudo abaixo dele. Os subsistemas que você vai encontrar Seis chaves de registro carregam a maior parte do comportamento: ctx.sessions (o log de eventos somente-anexação), ctx.systemPrompt , ctx.tools (um registro com escopo e execução guardada), ctx.agents , ctx.agentLoop e ctx.llm . Se você for estender o harness, esses são os nomes a procurar primeiro. Três demos que valem a execução Headless de passada única: pnpm dsh --profile headless "summarize this workspace" . O formato que você ligaria à CI ou a um cron. Introspecção do Cordis: pnpm run demo:cordis . Autorreferente: inspeciona e modifica o próprio runtime de plugins em execução. É a demonstração mais clara de que a alegação sobre plugins é estrutural e não publicitária. Automação ACP: pnpm run demo:acp . Um servidor de automação que fala JSON-RPC sobre stdio, que é a superfície de integração para dirigir o harness a partir de outro sistema. Se pretende contribuir Algumas convenções economizam tempo. Marcadores TODO são graduados por urgência: FIXME bloqueia a release, TODO é em breve, XXX é algum dia. O Lefthook executa pre-commit (registros de pairing em staged, .oxlintrc.staged.json , regeneração dos avisos de terceiros, espaços em branco, guardião do manifesto de vendor), pre-merge-commit e pre-push ( pnpm run typecheck ). Os hooks pulam testes e builds de propósito: a CI é dona da cobertura exaustiva, e pnpm run check:all é o portão local abrangente e opcional. Duas peculiaridades explicam uma estrutura que de outro modo confundiria. O build se divide em agregados tsconfig de Host e Client porque os dois lados fazem merge de declaração da interface Context do Cordis sob as mesmas chaves, e um único programa TypeScript que enxergue os dois merges reporta colisão. E os exemplos de código da documentação são mantidos honestos por blocos ts type-equiv mais pnpm run verify-type-equiv , de modo que declarações coladas não possam divergir em silêncio do código-fonte. Calibrar expectativas O README diz sem rodeios: isto é um developer preview, e haverá mudanças que quebram compatibilidade. A descoberta de plugins passa pelo topic do GitHub dsh-plugin , o projeto é licenciado sob MIT e as dependências de terceiros estão listadas em THIRD_PARTY_NOTICES.md . Avalie agora; padronize depois. Artigos relacionados O que é DeepSeek Harness? Guia completo O que «tudo é um plugin» realmente entrega (EN) Onde colocar os limites de gasto (EN) O log de sessão como registro de custos (EN) Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Objetivos e o loop Ralph no DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/pt/research/deepseek-harness-goals-ralph-loop DeepSeek Harness: objetivos, rodadas de objetivo e o loop Ralph Atualizado August 16, 2026 · publicado originalmente August 16, 2026 Resposta rápida: A maioria das surpresas de custo com agentes não vem do preço de um token. Vem de quantas vezes o agente decidiu tentar de novo. O DeepSeek Harness dá um vocabulário a esse comportamento, que é o... A maioria das surpresas de custo com agentes não vem do preço de um token. Vem de quantas vezes o agente decidiu tentar de novo. O DeepSeek Harness dá um vocabulário a esse comportamento, que é o primeiro passo para colocar um número nele. Turno, passo, rodada Três unidades, separadas com precisão no glossário do projeto: Unidade Definição Significado de custo Passo Um pedido ao modelo mais as execuções de ferramenta que ele produz O átomo de faturamento Turno Uma drenagem da entrada, encerrada quando o modelo para ou uma política intervém A unidade voltada ao usuário Rodada Uma iteração externa de política, como uma rodada de objetivo ou nova tentativa com agente novo O multiplicador acima dos turnos Rodadas são a camada que quase todo modelo de custo caseiro omite por inteiro. Se sua previsão conta requisições e seu sistema roda rodadas, sua previsão mede a coisa errada. Objetivos são metas duráveis Um objetivo é uma meta de conclusão durável com fase explícita: ativo, pausado, bloqueado ou completo. Diferente de uma mensagem, ele persiste entre turnos, então o agente carrega uma meta permanente. Cada ciclo de continuação admitido para esse objetivo é uma rodada de objetivo, materializada como um único turno originado do objetivo. A admissão é regida por uma ativação de objetivo: uma permissão local ao processo para admitir mais uma rodada, que está armada ou desarmada. Esse único bit é o estrangulador do trabalho aberto. Uma meta permanente somada a continuação automática é uma autorização de gasto sem teto. É exatamente por isso que está documentado que criar e editar objetivos exige autorização humana direta: alguém precisa ser dono do orçamento do trabalho aberto. O loop Ralph é reinício deliberado O loop Ralph é um fluxo em primeiro plano que itera rumo a um objetivo imutável iniciando sessões de agente novas, construído sobre as primitivas de fluxo e subagentes do harness. Uma rodada Ralph é uma sessão filha nova, sem semente de conversa do pai. A continuidade é carregada por um handoff Ralph: um relatório normalizado, limitado e estruturado com status, resumo, evidências e bloqueios. A economia aqui é genuinamente interessante, e corta dos dois lados. Reiniciar limpo significa que cada rodada paga um custo de entrada pequeno em vez de arrastar uma conversa sempre maior, então o custo por rodada fica plano em vez de subir. Mas nada num começo novo garante progresso, e um loop que reinicia barato pode se dar ao luxo de reiniciar muitas vezes mais. O handoff limitado é o controle que torna o padrão viável: é o único canal entre rodadas, então limita o crescimento de contexto por construção. Observe dois números — rodadas por objetivo, e se a lista de bloqueios do handoff se repete. Um bloqueio que aparece em três handoffs seguidos é um loop que não vai convergir, e cada rodada a mais é desperdício puro. Comandos não são ferramentas Vale separar, porque muda o que você mede. Um comando humano é uma instrução com prefixo de barra roteada pelo plano de comandos até adaptadores voltados ao humano: descoberta, parsing, despacho, cancelamento e renderização, sob responsabilidade dos adaptadores de UI. É explicitamente distinto de uma ferramenta de modelo. O comando de objetivo é um desses. Na prática: um humano digitando um comando de barra não é o modelo gastando tokens. Atribua os dois em separado ou seu custo por sessão vai culpar o ator errado. Quatro controles para trabalho aberto Um número máximo de rodadas por objetivo, aplicado antes da admissão em vez de revisado depois. Um orçamento cumulativo de tokens abrangendo todas as rodadas de um objetivo, não por rodada. Detecção de convergência sobre o handoff: bloqueios repetidos param o loop. Autorização humana explícita para criação de objetivo, guardada como registro de auditoria de quem autorizou o gasto. Artigos relacionados O que é DeepSeek Harness? Guia completo Subagentes e profundidade de delegação (EN) Limites de gasto no harness (EN) O log de sessão como registro de custos (EN) Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Limites de gasto no DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/pt/research/deepseek-harness-guardrails Onde colocar os limites de gasto no DeepSeek Harness Atualizado August 16, 2026 · publicado originalmente August 16, 2026 Resposta rápida: Um agente que descobre seu orçamento na fatura mensal não tem orçamento: tem um post-mortem. A pergunta útil sobre qualquer harness é onde dá para se plantar dentro do laço e dizer não, e o DeepSeek... Um agente que descobre seu orçamento na fatura mensal não tem orçamento: tem um post-mortem. A pergunta útil sobre qualquer harness é onde dá para se plantar dentro do laço e dizer não, e o DeepSeek Harness responde com dois pontos de extensão em cascata com nome próprio. Primeiro, o formato do laço O harness usa um modelo de turno e passo. Um passo é um pedido ao modelo mais as chamadas de ferramenta que ele produz. Um turno contém zero ou mais passos. O fluxo de um turno é, em linhas gerais: tomada da entrada, montagem do prompt, agent/pre-step , stream do LLM, execução de ferramentas, fecho do passo e fecho do turno. Dois fluxos de eventos correm lado a lado. session/event carrega fatos duráveis de replay — chunks, mensagens, chamadas de ferramenta, resultados. agent/* carrega sinais vivos de coordenação — status, caixa de entrada, interceptação de pedidos. Os limites pertencem ao segundo; a contabilidade ao primeiro. Ponto de interceptação 1: agent/pre-step É o ponto de controle antes de o pedido ao modelo sair. A documentação afirma que a decisão devolvida por agent/pre-step é autoritativa e que listeners que envolvem next() preservam as mensagens a jusante salvo substituição intencional. É essa propriedade que o torna utilizável como portão de orçamento: um listener pode recusar um passo proposto, ou modificá-lo, e a decisão vale. O que pertence aqui: Tetos de passos por turno. O modo de falha do agente desgovernado é um turno que nunca converge. Um teto duro transforma uma conta ilimitada numa limitada. Orçamentos cumulativos de tokens. Some o uso já registrado no log de sessão e recuse o passo seguinte além do limiar. Rebaixamento de modelo. Reescreva o passo para uma rota mais barata quando o turno passar de um limiar suave, em vez de recusá-lo de vez. Limites de tamanho de contexto. A montagem do prompt ocorre antes deste hook, então o pedido montado é visível e mensurável aqui. Ponto de interceptação 2: tools/pre-execute A execução de ferramentas é um pipeline de três fases. Primeiro roda a cascata tools/pre-execute , depois os guardas monotônicos e só então o corpo da ferramenta, em sandbox e com controle de acesso ao sistema de arquivos. Em seguida uma cascata pós-execução pode aceitar, bloquear, substituir ou acrescentar contexto ao resultado, e ToolDefinition.finalizeContent impõe invariantes de conteúdo de forma síncrona. A camada de permissões é deliberadamente assimétrica. Guardas monotônicos registrados negam ou se abstêm, com identidade protegida: nunca concedem. Se um guarda nega, ou se o prompt de uso único de ctx.approval está ausente ou é irrespondível, o resultado é negação e o corpo da ferramenta é pulado. Falha fechado, não aberto. Mutações do sistema de arquivos são controladas à parte: só passam mutações fs/write-intent ou fs/edit-intent . Escrever não é um efeito colateral incidental de uma ferramenta rodar. Duas propriedades tornam este pipeline confiável como ponto de controle: guardas só podem negar, e um prompt de aprovação irrespondível nega. A maioria das camadas caseiras de política para agentes falha em aberto quando o canal de aprovação some, que é exatamente quando você precisava dela. O que o pipeline registra Três eventos de sessão dão a trilha de auditoria: tool/call antes da execução, tool/code-dispatch para subchamadas e tool/result como resultado final autoritativo. Subchamadas serem registradas em separado importa: uma única chamada de ferramenta visível ao modelo que se ramifica internamente não esconde sua ramificação. Um conjunto prático de limites Controle Hook Impede Máximo de passos por turno agent/pre-step Laços que não convergem Teto cumulativo de tokens agent/pre-step Excesso de gasto em fogo brando Rebaixamento de rota após limiar agent/pre-step Preço de fronteira em trabalho barato Lista de ferramentas por classe de custo Guarda monotônico Ferramentas caras em contextos baratos Negação de subprocessos e rede Política ctx.sandbox Saída de rede não medida Controle de write-intent Costura ctx.fs Mutações não revisadas A ressalva O DeepSeek Harness está em developer preview e seu próprio README avisa de mudanças que quebram compatibilidade. Estes nomes e semânticas de hooks são os documentados hoje; trate plugins de limites construídos sobre eles como código que você vai revisitar, e fixe a versão contra a qual construiu. Artigos relacionados O que é DeepSeek Harness? Guia completo O log de sessão como registro de custos (EN) Tudo é um plugin: a arquitetura (EN) Limites de gasto para agentes (EN) Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # DeepSeek Harness: tudo é um plugin · FinOps LLM URL: https://finopsllm.com/pt/research/deepseek-harness-plugin-architecture DeepSeek Harness: o que «tudo é um plugin» realmente entrega Atualizado August 16, 2026 · publicado originalmente August 16, 2026 Resposta rápida: A DeepSeek AI publicou o deepseek-harness (dsh), um harness de agentes licenciado sob MIT cujo lema de projeto é que tudo é um plugin. Essa frase é usada com folga no ecossistema de ferramentas de... A DeepSeek AI publicou o deepseek-harness ( dsh ), um harness de agentes licenciado sob MIT cujo lema de projeto é que tudo é um plugin. Essa frase é usada com folga no ecossistema de ferramentas de agentes, então vale precisar o que ela significa aqui e onde muda a economia de operar agentes. Cordis, não um framework com hooks O harness roda sobre o Cordis , um runtime de plugins cujo modelo é que plugins contribuem serviços, eventos tipados e efeitos reversíveis a um contexto compartilhado. O documento de arquitetura é explícito: não há núcleo privilegiado. Adaptadores de modelo, registros de ferramentas, logs de sessão e o próprio laço do agente são todos plugins. Nada fica embaixo deles como motor imóvel. Isso importa porque a forma usual de um framework de agentes «extensível» é um núcleo fixo mais uma superfície de hooks. Você observa e decora, mas não substitui. Substituir significa bifurcar. O Cordis inverte isso: as peças que você gostaria de substituir são as unidades de composição. Costuras de capacidade: a parte que importa na operação O harness formaliza isso com o que chama de costura de capacidade (capability seam). Uma costura é uma interface de serviço com mais de uma implementação, e cada serviço ocupa um de três papéis: Papel O que faz Owner O pacote que declara a interface do serviço Implementação Um pacote que fornece comportamento concreto (costuras têm várias) Consumidor Um pacote que chama o serviço, cego a qual provedor está ativo Nem todo serviço é uma costura. A documentação distingue três tipos: costuras substituíveis ( ctx.llm , ctx.subprocess ), serviços de núcleo com owner único ( ctx.sessions , ctx.agents ) e pontos de composição que coordenam outros serviços ( ctx.agentLoop ). Saber qual é qual diz onde você pode substituir comportamento e onde não pode. As quatro costuras com consequências de custo ctx.llm , a costura do modelo. Pertence ao pacote llm ; as implementações incluem llm-deepseek , llm-pi-ai e llm-replay . O laço do agente consome um serviço de stream neutro quanto ao provedor e não sabe qual backend está rodando. llm-replay é o interessante para trabalho de custo: permite reexecutar uma sessão gravada sem pagar inferência de novo. ctx.fs , a costura do sistema de arquivos. Os provedores são fs-local (sistema de arquivos do host), fs-sandbox (mutações confinadas) e fs-e2b (uma máquina Linux remota em sandbox). A costura desacopla as ferramentas que o modelo enxerga de onde a execução acontece fisicamente. ctx.sandbox , a costura de execução. Consumidores entregam argv; implementações envolvem a execução sob política. sandbox-local aplica no host, sandbox-policy centraliza padrões de implantação. ctx.subagents , a costura de delegação. Seis implementações cobrindo spawn em processo, fork, pontes ACP, Codex, Claude Code e agentes baseados em SDK. É aqui que um harness normalmente fixa uma suposição; aqui é uma troca. Toda alavanca de custo relevante num sistema de agentes é uma troca de provedor: rotear para um modelo mais barato, mover a execução para um sandbox mais barato, substituir um transporte de subagentes por um local. Quando isso são costuras, a mudança é uma edição de configuração. Quando não são, a mudança é uma bifurcação que você passa a manter. Por que isso é assunto de FinOps e não só de arquitetura A falha recorrente em programas de custo de agentes não é a equipe escolher um modelo caro. É o harness tornar a escolha cara estrutural. Uma vez que a seleção de modelo, o local de execução das ferramentas e o transporte de delegação estão assados no código da aplicação, cada otimização vira um projeto de engenharia com cronograma e risco de regressão próprios. As equipes então adiam a otimização, e o gasto se acumula. Um harness baseado em costuras move essas decisões para a composição. Isso não as torna gratuitas, mas as converte de refatorações em configuração, que é a diferença entre uma iniciativa trimestral e uma tarde. A ressalva que vale dizer sem rodeios O DeepSeek Harness está em developer preview e seu README diz, sem suavizar, que haverá mudanças que quebram compatibilidade. Construir agora ferramentas de custo de produção diretamente sobre suas interfaces internas significa assinar embaixo de correr atrás delas. Avalie, prototipe, mas fixe as versões e conte com movimento. Artigos relacionados O que é DeepSeek Harness? Guia completo O log de sessão como registro de custos (EN) Onde colocar os limites de gasto (EN) Instalação, perfis e primeira execução (EN) Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # O log de sessão do DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/pt/research/deepseek-harness-session-log O log de sessão do DeepSeek Harness como registro de custos Atualizado August 16, 2026 · publicado originalmente August 16, 2026 Resposta rápida: A maioria das stacks de agentes aparafusa o rastreio de custo depois: um wrapper em volta da chamada ao modelo que escreve tokens num sistema separado, o qual acaba divergindo da realidade. O DeepSeek... A maioria das stacks de agentes aparafusa o rastreio de custo depois: um wrapper em volta da chamada ao modelo que escreve tokens num sistema separado, o qual acaba divergindo da realidade. O DeepSeek Harness faz o contrário. O log de sessão é o artefato primário, e o uso de tokens mora dentro dele. A sessão é um log de eventos append-only Uma sessão é uma sequência ordenada e apenas-acrescentável de entradas SessionEvent tipadas. Cada evento carrega quatro campos: Campo O que significa type O tipo de evento, por exemplo assistant/message seq Número de sequência monotônico dentro da sessão time Carimbo de tempo data A carga útil específica do tipo Eventos de superfície (o que uma interface exibe) acrescentam dois campos: sourceEventSeqs , que aponta de volta para os eventos brutos dos quais derivam, e surfaceOp . Esses ponteiros são a razão de um número de custo poder ser rastreado até exatamente os eventos que o produziram. Os eventos que interessam a um modelo de custo turn/start e turn/end : o colchete externo de um pedido do usuário. turn/end carrega um TurnEndReason dizendo se o turno concluiu, foi abortado ou truncado. step/start e step/end : um passo é um pedido ao modelo mais as chamadas de ferramenta que ele dispara. É a unidade natural de cobrança. assistant/message : saída do modelo, com TokenUsage opcional. assistant/chunk : saída em streaming, incluindo chunks de uso. tool/call e tool/result : execução de ferramentas; o resultado pode carregar meta . request/header e request/context : o EpochHeader e o contexto do pedido com provedor, modelo e janela de contexto. Esse par é o que coloca preço num número de uso. A regra que guia a documentação é: o que é visível ao modelo fica registrado . Tudo o que entra no contexto do modelo deixa um evento. Isso torna o log completo por construção, em vez de completo enquanto ninguém esquecer de instrumentá-lo. O uso viaja com a saída O uso de tokens não é escrito num canal lateral: viaja com a saída à qual pertence. Prefira os chunks de uso ( assistant/chunk com { type: 'usage' } ) porque ficam o mais perto possível do que o provedor de fato cobrou; recorra a assistant/message.usage quando não houver chunk. Um modelo de custo que lê assim nunca consegue atribuir um número a um passo que não o gerou. Histórico derivado, não duplicado O histórico de mensagens que o modelo vê é projetado a partir do log de eventos, em vez de mantido ao lado como uma segunda verdade. Essa é a diferença entre um sistema cujos números de custo concordam com sua execução e um em que os dois divergem e ninguém sabe qual está certo. «Visível ao modelo significa registrado» é a única regra que torna possível reconstruir custo. Sem ela, todo número de atribuição é uma estimativa com margem de erro desconhecida. O que construir em cima Junte step/start e step/end para formar spans de passo: a unidade contra a qual você reportará custo. Anexe request/context (provedor, modelo, janela de contexto) e o preço a partir do uso do chunk a cada span. Conte o fan-out de tool/call por passo: a ramificação de ferramentas é o motivo habitual de um turno passar a custar dez vezes mais. Observe a distribuição de TurnEndReason . Turnos abortados e truncados são trabalho pago sem resultado, e são a primeira métrica que você não tem sem um log. Artigos relacionados O que é DeepSeek Harness? Guia completo Tudo é um plugin: a arquitetura (EN) Onde colocar os limites de gasto (EN) Convenções GenAI do OpenTelemetry (EN) Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Subagentes e delegação no DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/pt/research/deepseek-harness-subagents Subagentes do DeepSeek Harness: delegação como multiplicador de custo Atualizado August 16, 2026 · publicado originalmente August 16, 2026 Resposta rápida: A forma mais rápida de multiplicar a conta de um agente é deixar agentes criarem agentes. Um pedido de usuário vira uma árvore, e a árvore não tem tamanho natural. Por isso o DeepSeek Harness não... A forma mais rápida de multiplicar a conta de um agente é deixar agentes criarem agentes. Um pedido de usuário vira uma árvore, e a árvore não tem tamanho natural. Por isso o DeepSeek Harness não trata delegação como recurso, e sim como uma costura com limites explícitos. Subagentes são uma costura, não algo embutido A delegação passa por ctx.subagents . Ao contrário do executor de shell, que tem exatamente uma implementação, os provedores de subagente são registrados por nome e vários podem coexistir. A documentação lista seis transportes: criação in-process e fork (agentes comuns através do contexto do pai), uma ponte ACP para implantação remota, Codex, Claude Code e uma variante baseada em SDK. Em termos de custo, isso significa que o preço de um filho depende de qual provedor o criou. Um agente forkado in-process e um remoto lançado por ponte ACP parecem iguais no código chamador e têm faturas completamente diferentes. Dois modos de delegação, dois perfis de custo Modo Formato Característica de custo Disparo único Criar filho, enviar prompt, aguardar resultado, descartar Limitado, atribuível ao turno do pai Continuável Sessão de fundo durável com uma ativação residente Aberto; acumula entre turnos O disparo único resolve para um handle de execução com uma promessa de resultado terminal. Filhos continuáveis custam mais para manter: um gerenciador de continuação reserva a identidade, compõe o filho, ordena cada turno pela caixa de entrada do filho, e o provedor contribui apenas com os metadados de criação inicial. Ativações têm três estados: em execução, em espera (quiescente mas detendo ativações filhas incompletas) e liquidada. Uma mensagem sem ativação viva dispara retomada a frio a partir da sessão persistida. Retomadas a frio são a linha que as pessoas esquecem. O estado é reidratado do log, então os tokens de entrada são proporcionais ao tamanho do log. Um filho longevo pouco acionado pode custar mais por mensagem do que um sempre ativo. Capacidades falham alto, não em silêncio O harness valida as capacidades pedidas contra o provedor e rejeita com erro tipado em vez de ignorar silenciosamente. As capacidades de início cobrem esquemas de saída, limites de profundidade, filtros de ferramentas e personas, e mapeiam um a um para as opções do pedido. Pedir algo que o provedor não suporta aparece na partida, não na fatura. A profundidade tem teto, e o teto não se contorna A profundidade de delegação é persistida no cabeçalho da sessão e um campo de runtime acompanha o maior valor, de modo que uma retomada a frio não consegue reduzi-la. O início é rejeitado se a profundidade derivada ultrapassar maxDepth ou os limites de inteiro seguro. Um pai que cria três filhos, cada um criando outros três, transformou um pedido de usuário em treze agentes. Tetos de profundidade são a diferença entre uma ramificação que você dimensionou e uma que você descobriu. Descobrir é barato, entregar é autoritativo listChildren() devolve um corpus com preferência pelo vivo via aceleração de três níveis: cache de marca d'água, depois checkpoint de projeção, depois inspeção da persistência. listDescendants() percorre em pré-ordem e acrescenta posições de pai e profundidade. Nenhuma consulta registros de agentes, ativações ou provedores; a entrega de mensagens continua autoritativa. Para atribuição de custo isso importa: dá para enumerar a árvore barato e quando quiser. Resultados carregam uma razão de parada A saída é a última mensagem de assistente não vazia ou o fluxo de texto acumulado; a saída estruturada opcional é validada contra o esquema pedido. O stopReason é uma união extensível por fusão: completed, aborted, error, max-tokens, refusal. Tudo que não é completed significa saída parcial mapeada para resultados de ferramenta com erro: paga e incompleta. O que medir Filhos por turno de pai e descendentes por pedido de usuário. Profundidade máxima observada contra o teto configurado. Fatia de filhos continuáveis retomados a frio, mais o tamanho do log na retomada. Distribuição das razões de parada: muita incidência de max-tokens ou error é trabalho pago e inacabado. Artigos relacionados O que é DeepSeek Harness? Guia completo Tudo é um plugin: a arquitetura (EN) Limites de gasto no harness (EN) O log de sessão como registro de custos (EN) Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Escopos de ferramentas no DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/pt/research/deepseek-harness-tool-scopes DeepSeek Harness: escopos, restrições e sombreamento de ferramentas Atualizado August 16, 2026 · publicado originalmente August 16, 2026 Resposta rápida: Catálogos de ferramentas crescem. Alguém adiciona uma ferramenta de navegador, alguém uma de banco de dados, alguém cinco operações de terminal, e um ano depois todo agente do sistema recebe quarenta... Catálogos de ferramentas crescem. Alguém adiciona uma ferramenta de navegador, alguém uma de banco de dados, alguém cinco operações de terminal, e um ano depois todo agente do sistema recebe quarenta ferramentas, precise delas ou não. Isso costuma ser discutido como problema de segurança. Também é uma linha de custo. O DeepSeek Harness traz um modelo de escopo por agente que ataca as duas coisas de uma vez. Por que o catálogo é um custo recorrente Definições de ferramenta fazem parte da requisição. O harness registra um evento de cabeçalho de requisição carregando a configuração, o prompt de sistema e o conjunto de ferramentas exatamente como enviados, o que torna o ponto concreto: o catálogo é retransmitido em cada requisição ao modelo na sessão, sendo um imposto fixo por passo em vez de um custo único. Há um segundo efeito, maior. Um catálogo largo alarga o espaço de escolha do modelo. Mais seleções plausíveis porém erradas significam mais passos que não produzem nada útil, e passos são a unidade de faturamento. Aparar a superfície reduz o piso de tokens e a taxa de erro juntos. O vocabulário Termo Significado Escopo A unidade de registro por agente para ferramentas, prompts, variáveis, restrições e ouvintes Chave de escopo A identidade opaca pela qual um escopo é indexado, comparada por identidade de objeto — normalmente o próprio agente vivo Contexto do agente O contexto escopado do próprio agente, onde os registros são ligados à sua vida e visíveis no escopo Restrição Um filtro sobre o conjunto global de ferramentas para um escopo, aplicado por interseção Sombreamento Um item do escopo substituindo o homônimo global, apenas dentro daquele escopo Janela de setup O momento de criação em que o criador compõe o mundo escopado do agente, antes da publicação ou do primeiro prompt Como a composição resolve As restrições filtram primeiro o conjunto global, depois os registros locais do escopo entram. Essa ordem é o que torna o menor privilégio praticável: parte-se de uma interseção com o catálogo global — nunca mais que o global — e então adiciona-se exatamente as ferramentas específicas de que este agente precisa. O sombreamento entrega o caso de substituição sem um fork. Um agente pode receber outra implementação atrás de um nome familiar de ferramenta — uma variante somente leitura, uma medida, um backend mais barato — enquanto todos os outros continuam vendo a global. A ligação de vida importa pelo mesmo motivo que o dispose. Registros de escopo terminam com o contexto do agente, então um filho de vida curta não consegue vazar contribuições para o mundo do pai. Toda a composição acontece na janela de setup, antes de o agente ser publicado ou montar seu primeiro prompt. Decisões de privilégio tomadas depois do primeiro prompt não são decisões de privilégio: são limpeza. Despacho escopado e linhagem Eventos sobre um agente são despachados com o portador daquele agente, então um ouvinte sabe de quem é a atividade que observa; eventos de nível de registro seguem sem filtro. Separadamente, a linhagem — sessão pai, profundidade de delegação, profundidade de subagente — é descrita explicitamente como dado que por si só não afeta visibilidade. Essa separação vale copiar. Um filho não herda acesso por ser filho; o acesso é composto deliberadamente na sua janela de setup. Privilégio herdado por padrão é exatamente como um subagente barato de sumarização acaba segurando o mesmo conjunto caro de ferramentas do pai. Quatro coisas a fazer com isso Conte suas definições de ferramenta e multiplique pelos passos por sessão. Esse é seu imposto fixo de ferramentas por sessão, em tokens. Defina um conjunto mínimo viável de ferramentas por papel de agente e aplique-o como restrição, não como convenção. Sombreie ferramentas caras com variantes baratas ou somente leitura em contextos de baixo valor, em vez de removê-las por completo. Nunca herde o conjunto do pai nos subagentes por padrão. Componha-o. Artigos relacionados O que é DeepSeek Harness? Guia completo Limites de gasto no harness (EN) Subagentes e profundidade de delegação (EN) O que "tudo é um plugin" entrega (EN) Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Coloque controlo de custos no pipeline de avaliação LLM · FinOps LLM URL: https://finopsllm.com/pt/research/evals-cost-control Coloque controlo de custos no pipeline de avaliação LLM Atualizado August 27, 2026 · publicado originalmente August 27, 2026 Resposta rápida: As avaliações LLM precisam de uma política própria de custo. Um job de CI com muitos prompts pode custar mais do que a funcionalidade. Use orçamento por execução, amostragem, cache e limites de... As avaliações LLM precisam de uma política própria de custo. Um job de CI com muitos prompts pode custar mais do que a funcionalidade. Use orçamento por execução, amostragem, cache e limites de qualidade. Orçamente a execução Limite prompts, modelos, retries e dólares antes de começar. Separe smoke tests, regressões e certificação. Controle qualidade e custo Pare ao ultrapassar o custo ou falhar a qualidade e registe modelo, tokens, cache, retries, custo e resultado. Artigos relacionados Custo por tarefa bem-sucedida Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # FinOps para LLM e GenAI: um enquadramento prático · FinOps LLM URL: https://finopsllm.com/pt/research/finops-for-llm FinOps para LLM: um marco prático FinOps para LLMs é a prática de tornar visível, atribuível, otimizável e responsável o gasto em IA. Toma emprestado dos princípios de FinOps em nuvem, mas os geradores de custo são diferentes. Uma conta de nuvem é determinada por instâncias, armazenamento, transferência e compromissos. Uma conta de LLM é determinada por tokens de entrada, tokens de saída, escritas de cache, leituras de cache, tentativas, mix de modelos, comprimento do contexto, elegibilidade de lote e requisitos de qualidade. O primeiro erro que as equipes cometem é tratar o gasto em LLM como um único número no nível do provedor. Isso oculta os verdadeiros fatores. Um endpoint de resumo de suporte, um fluxo de trabalho de agente, um trabalho de enriquecimento noturno e um conjunto de avaliação podem usar o mesmo modelo, mas têm diferentes necessidades de latência, limites de qualidade, capacidade de cache e propriedade. O FinOps começa quando essas cargas de trabalho são separadas. Pilar Pergunta central O que produz 1. Visibilidade O que exatamente estamos pagando, solicitação por solicitação? Registros de uso normalizados divididos por entrada, saída, escrita de cache, leitura de cache, lote e gasto de tentativa 2. Atribuição Qual equipe, recurso, cliente ou carga de trabalho causou isso? Gasto mapeado para proprietários: ambiente, endpoint, equipe, locatário, modelo, classe de carga de trabalho 3. Otimização Qual fator reduz o custo por tarefa bem-sucedida sem afetar a qualidade? Mudanças de roteamento, cache, lotes, compactação e arbitragem implantadas atrás de flags 4. Responsabilidade Quem revisa os números e age sobre eles a cada mês? Relatórios de showback (e depois chargeback) e um ritmo operacional reconciliado com faturas 1. Visibilidade Visibilidade significa normalizar faturas de provedores e logs de gateway em um registro comum. Cada solicitação deve llevar metadados suficientes para responder: quem é o proprietário, qual recurso a gerou, qual modelo a tratou, quantas classes de tokens foram faturadas, se a chamada foi repetida e se a saída produziu valor para o usuário. Boa visibilidade separa o gasto de entrada, saída, escrita de cache, leitura de cache, lote e tentativa. Sem esta separação, as equipes contam acidentalmente os descontos de leitura de cache como economias, perdem loops de tentativa e comparam provedores por preço de lista em vez de custo por tarefa bem-sucedida. 2. Atribuição Atribuição mapeia o gasto para equipes, produtos, clientes e cargas de trabalho. O ponto não é culpa; o ponto é qualidade da decisão. Uma equipe de finanças não pode governar o gasto se cada linha diz "OpenAI." Um líder de engenharia não pode otimizar uma superfície de produto se o gasto é agrupado apenas por conta de provedor. A atribuição mínima útil geralmente inclui ambiente, endpoint, proprietário da equipe, cliente ou locatário quando permitido, modelo, provedor e classe de carga de trabalho. Os programas maduros adicionam métricas de negócios como ticket resolvido, análise concluída, relatório gerado ou tarefa de agente bem-sucedida. 3. Otimização A otimização deve seguir a atribuição. Os fatores comuns são roteamento de modelos, cache semântico, cache de prompts, compactação de contexto, roteamento de lotes, arbitragem de provedores e ajuste de política de fallback. Cada fator muda a conta de forma diferente. O roteamento muda o mix de modelos. O cache muda a economia de tokens de entrada e latência. O lote move o trabalho para faixas assincronizadas com desconto. A compactação reduz contexto repetido. O teste não é "o número de tokens diminuiu?" O teste é "o custo por tarefa bem-sucedida diminuiu sem quebrar qualidade, latência ou confiabilidade?" 4. Responsabilidade Showback deve vir antes de chargeback. Primeiro, forneça às equipes uma visão mensal confiável de seu gasto e fatores. Depois que os números são confiáveis, o chargeback pode fazer sentido para organizações maduras. O objetivo é um ritmo operacional repetível: revisar os maiores fatores, concordar com candidatos a otimização, implantar mudanças atrás de flags e reconciliar com a próxima fatura. Relacionado O que é LLM FinOps? - a disciplina operacional. AI FinOps - a prática mais ampla na qual o LLM FinOps se encaixa. Atribuição de custos em LLM - como funciona a camada de atribuição. LLM chargeback e showback - movendo custos para proprietários. Quer isso aplicado ao seu próprio gasto em LLM? O FinOps LLM executa uma auditoria gratuita de seus custos de IA e mostra onde estão as economias. Solicite sua auditoria gratuita → Voltar para pesquisa --- # O primeiro fecho mensal de um produto intensivo em IA · FinOps LLM URL: https://finopsllm.com/pt/research/first-ai-month-end-close O primeiro fecho mensal de um produto intensivo em IA Atualizado August 27, 2026 · publicado originalmente August 27, 2026 Resposta rápida: O primeiro fecho mensal de IA começa nas faturas brutas e num período bloqueado, não numa imagem do dashboard. Feche primeiro o valor financeiro, explique depois o uso e só então aloque a... O primeiro fecho mensal de IA começa nas faturas brutas e num período bloqueado, não numa imagem do dashboard. Feche primeiro o valor financeiro, explique depois o uso e só então aloque a despesa. Bloqueie o período Defina fuso horário, moeda, descontos, créditos e corte da fatura. Congele a tabela de preços e guarde IDs de fatura e janela de telemetria. Reconcilie e aloque Ligue eventos aos exports do fornecedor por conta, modelo, tipo de token e dia. Investigue o residual. Depois aloque por funcionalidade, equipa, ambiente, coorte e carga, mantendo a plataforma partilhada separada. Explique a variação Divida a mudança em tarifa, volume, mix e eficiência. Ligue cada movimento a uma versão, tráfego, migração ou comportamento do agente. Artigos relacionados Reconciliação de faturas de IA Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # FOCUS 1.5 padroniza o rastreio de tokens de IA · FinOps LLM URL: https://finopsllm.com/pt/research/focus-1-5-ai-token-tracking FOCUS 1.5: rastreamento de tokens de IA e Price Sheets Atualizado September 19, 2026 · publicado originalmente August 15, 2026 Resposta rápida: A FinOps Foundation confirmou o lançamento da especificação FOCUS 1.5 para dezembro de 2026. Pela primeira vez, a especificação aberta de custos e uso de nuvem ganha suporte nativo para inteligência... A FinOps Foundation confirmou o lançamento da especificação FOCUS 1.5 para dezembro de 2026. Pela primeira vez, a especificação aberta de custos e uso de nuvem ganha suporte nativo para inteligência artificial, trazendo identificação padronizada de modelos e o dataset Price Sheet . 1. O que o FOCUS 1.5 padroniza Identificador de modelo: Normalização entre Bedrock, Azure OpenAI e Google Vertex. Métricas de tokens: Campos separados para entrada, saída e tokens de cache. Price Sheet: Tabela de preços de lista desvinculada do log de consumo para auditoria clara de descontos. 2. O que continua sob responsabilidade da empresa O FOCUS normaliza os dados do fornecedor, mas não resolve a atribuição interna de custos . O provedor não sabe qual time ou funcionalidade originou o pedido; essa demarcação precisa existir no gateway de IA da empresa. 3. Como se preparar Passe a registrar tokens por tipo e não por total agregado, guarde os IDs de modelo em cada span e faça conciliação mensal com a fatura do provedor. Artigos relacionados Atribuição de custos de LLM Reconciliação de faturas de IA Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # O plano gratuito é um custo de aquisição · FinOps LLM URL: https://finopsllm.com/pt/research/free-tier-is-an-acquisition-cost O plano gratuito como custo de aquisição Atualizado September 1, 2026 · publicado originalmente September 1, 2026 Resposta rápida: Servir inferência não é grátis. Quando um fornecedor lhe dá um plano gratuito, limites generosos em preview ou um endpoint sem marca que nada custa, esse cómputo é pago — por ele, a partir de... Servir inferência não é grátis. Quando um fornecedor lhe dá um plano gratuito, limites generosos em preview ou um endpoint sem marca que nada custa, esse cómputo é pago — por ele, a partir de uma rubrica com nome. É custo de aquisição de clientes e comporta-se como qualquer outro CAC. É a lente mais útil para uma equipa financeira, porque o CAC tem dinâmica previsível: gasta-se para ganhar uma coorte, tem período de retorno e para quando a coorte está ganha. O que compra um plano gratuito Avaliação sem passar pelas compras. Dados de cargas reais , que valem mais do que o cómputo. E uma âncora de preço : uma capacidade conhecida a custo zero faz qualquer tarifa parecer cara. O sinal a ler Os limites apertam antes de os preços subirem. Vigie a concorrência, o contexto e que modelos continuam incluídos — tudo se mexe antes de haver tabela nova. Como usar Nunca deixe um plano gratuito entrar na sua unit economics. Margem que depende de inferência grátis não é margem, é um subsídio com prazo alheio. Valorize o uso gratuito a uma tarifa sombra na telemetria e leve-a na previsão. Meça o custo de mudar enquanto sair ainda é barato. Artigos relacionados Arbitragem entre fornecedores Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Guia de Preços de GPT-5.6: Luna, Terra, Sol · FinOps LLM URL: https://finopsllm.com/pt/research/gpt-5-6-pricing-tier-guide Guia de Preços de GPT-5.6: Luna, Terra, Sol Publicado em 19 de julho de 2026 A OpenAI lançou o GPT-5.6 em 10 de julho com três níveis de preços distintos: Luna a $1/$6 por 1M de tokens, Terra a $2,50/$15 e Sol a $5/$30. Isso não é um simples tradeoff de velocidade/qualidade; cada nível é posicionado para uma classe diferente de carga de trabalho. A pergunta não é "qual é o melhor" — é "qual é o certo para esta tarefa?" Este guia mapeia tarefas para níveis, percorre exemplos de custo por tarefa e mostra como escalar inteligentemente quando um nível mais barato não é confiável o suficiente. Luna ($1/$6): classificação, extração simples, roteamento de alto volume Terra ($2,50/$15): raciocínio equilibrado, loops de agentes, conversas multi-turno Sol ($5/$30): raciocínio de fronteira, geração de código, pesquisa difícil Leituras de cache economizam 90%; gravações de cache custam 1,25× entrada — ponto de equilíbrio em 5+ acertos em 30 min A API de lote adiciona 50% de desconto além dos preços de nível para trabalho não interativo Ressalva crítica: A OpenAI posiciona Terra e Sol como tendo capacidade de raciocínio equivalente, diferenciando-se principalmente em velocidade e rendimento. Compare ambos contra sua carga de trabalho real — a pretensão de paridade nem sempre se mantém em sua distribuição de dados. Veja GPT-5 vs alternativas para comparação com Claude e DeepSeek. 1. Os Três Níveis: Velocidade, Custo e Capacidade Nível Entrada $/1M Saída $/1M Leitura de Cache $/1M Contexto Latência Típica Luna $1,00 $6,00 $0,10 128K 80–200 ms Terra $2,50 $15,00 $0,25 128K 150–400 ms Sol $5,00 $30,00 $0,50 128K 300–800 ms A latência importa: Luna é mais rápido porque é otimizado para streaming, classificação em tempo real e rendimento. Sol é mais lento porque realiza mais raciocínio interno. Para cargas de trabalho interativas voltadas para o usuário, Luna também é mais barato e mais rápido — mas apenas se for capaz o suficiente para sua tarefa. Essa é a decisão-chave de roteamento. 2. Tabela de Roteamento por Tipo de Tarefa Esta tabela mapeia tarefas comuns de LLM para o nível que minimiza o custo por resposta bem-sucedida: Tipo de Tarefa Exemplo Nível Recomendado Taxa de Sucesso no Nível Custo Est./1K Tarefas Classificação Spam / não-spam; sentimento (pos/neg/neutro) Luna 95–98% $1,20–$1,50 Extração estruturada Extrair nome, email, telefone do texto Luna 92–96% $1,80–$2,40 Categorização (muitas classes) Atribuir uma de 50+ categorias de produto Luna 88–94% $2,40–$3,20 Resumo Condensar artigo ou log de chat Luna 92–97% $1,50–$2,00 Loops de agentes (uso de ferramentas) Multi-turno: pesquisar, raciocinar, refinar Terra 85–92% $8,00–$12,00 Conversa multi-turno Bots de suporte ao cliente, consultoria Terra 88–94% $6,00–$10,00 Geração de código (simples) Consulta SQL, snippet Bash, regex Terra 80–90% $10,00–$15,00 Geração de código (complexa) Endpoint completo, máquina de estados, compilador DSL Sol 75–88% $25,00–$40,00 Pesquisa + síntese Analisar 10+ artigos, sintetizar consenso Sol 80–90% $30,00–$50,00 Raciocínio difícil (problema novel) Verificação de prova, design de algoritmo novel Sol 70–85% $40,00–$70,00 Insight-chave: O custo por tarefa não é apenas custo de API — é (custo de API) / (taxa de sucesso). Uma classificação Luna com 95% de sucesso custa ~$1,26 por resposta bem-sucedida. Se você rotear a mesma tarefa para Sol com 98% de sucesso, paga ~$5,10 por resposta — mas resolveu 3% mais de sua carga de trabalho, o que pode ou não valer o custo 4×. 3. Exemplos Resolvidos de Custo Por Tarefa Exemplo 1: Classificação de Spam (Luna) Tarefa: Classificar email como spam (sim/não binário). Perfil de tokens típico: 400 entrada (email) + 50 saída (classificação + confiança) = 450 tokens. Custo Luna: (400 × $1/1M) + (50 × $6/1M) = $0,00043/solicitação. Se 96% têm sucesso na primeira tentativa: $0,00043 / 0,96 = $0,00045 por classificação bem-sucedida. A 1M de emails/mês: $450/mês (mais desconto de cache se você reutilizar prompts do sistema). Se roteado incorretamente para Sol: (400 × $5 + 50 × $30) / 1M = $0,0025 por solicitação. Com 98% de sucesso: $0,00255/bem-sucedida = $2.550/mês (5,7× mais). Exemplo 2: Agente de Suporte ao Cliente (Terra) Tarefa: Conversa de suporte multi-turno com uso de ferramentas (busca de tickets, busca de políticas, decisão de escalação). Perfil de tokens típico por turno: 2.000 entrada (contexto + histórico) + 400 saída (resposta + chamadas de ferramentas) = 2.400 tokens. Média de 3 turnos para resolver = 7.200 tokens totais por ticket. Custo Terra: (2.000 × $2,50/1M) + (400 × $15/1M) = $0,0080/turno ou $0,0240 por ticket. Se 90% são resolvidos sem escalação: $0,0240 / 0,90 = $0,0267 por ticket bem-sucedido. A 10K tickets/mês: $267/mês. Se usava Luna em seu lugar: (2.000 × $1 + 400 × $6) / 1M = $0,0044 por turno = $0,0132/ticket. Mas o sucesso do loop de agentes de Luna cai para 65% (chamadas de ferramentas falham, o raciocínio é raso). Custo por bem-sucedida: $0,0132 / 0,65 = $0,0203. Economia líquida: $29/mês, mas 25% dos tickets falham e escalam, elevando o custo de suporte em $400+. Luna não funciona aqui. Exemplo 3: Geração de Código (Terra vs Sol) Tarefa: Gerar função Python a partir de string de requisito. Perfil de tokens típico: 1.500 entrada (especificação + exemplos) + 600 saída (código + explicação) = 2.100 tokens. Custo Terra: (1.500 × $2,50 + 600 × $15) / 1M = $0,0134 por solicitação. Com 85% de sucesso na primeira passagem (código compila + passa testes básicos): $0,0158 por função que funciona. Custo Sol: (1.500 × $5 + 600 × $30) / 1M = $0,0255 por solicitação. Com 90% de sucesso na primeira passagem: $0,0283 por função que funciona. Economia com Terra: 44% mais barato por resultado que funciona. Use Sol apenas se a diferença de 5% na taxa de sucesso e qualidade de código reduzir mensuravelmente o custo de debugging descendente. 4. Padrão de Roteamento em Cascata & Fallback A maioria das equipes de FinOps não deveria usar um único nível para todo trabalho. Em vez disso, implemente um padrão em cascata: comece com o nível mais barato, meça confiança, escale em baixa confiança. Passo Modelo Limite de Confiança Ação se Limite Não for Atendido 1 Luna Confiança > 85% Retornar resultado 2 Terra Confiança > 75% Retornar resultado (escalado) 3 Sol Confiança > 60% Retornar resultado ou falhar explicitamente 4 Revisão humana — Escalar para humano Cenário real: Você está fazendo classificação de documentos para faturas (classificar por fornecedor). Luna retornará resultados de alta confiança (~94% de sucesso) e custará ~$1,20 por 1K. Para os 6% de faturas ambíguas onde Luna retorna confiança 5. Economia de Cache de Prompts GPT-5.6 mudou os custos de cache: gravações de cache agora custam 1,25× a taxa de entrada sem cache (não gratuito), e leituras de cache custam 10% de entrada. Cenário Tamanho de Prefixo Custo de Gravação Custo de Leitura (por acerto) Acertos de Ponto de Equilíbrio Economia @ 10 acertos/mês Contexto de recuperação em cache Luna 100K tokens $0,125 $0,010 15 acertos -$0,025 (perda) Prompt do sistema em cache Luna + docs 50K tokens $0,063 $0,005 8 acertos $0,032 Contexto de agentes em cache Terra 80K tokens $0,250 $0,020 14 acertos $0,030 Contexto de raciocínio em cache Sol 100K tokens $0,625 $0,050 13 acertos $0,025 Quando cachear: Se seu prompt inclui um prefixo estável (instruções do sistema, documentação, exemplos com poucos disparos) que é reutilizado mais de 5–10 vezes em uma janela de 30 minutos, o cache geralmente economiza dinheiro. A API de lote (50% de desconto) agora compete com cache em custo — se você classifica documentos em lote, o desconto de lote vence a sobrecarga de cache. 6. Comparação com Claude Sonnet 5, Gemini 3.1 Pro e DeepSeek V4 Modelo Entrada $/1M Saída $/1M Velocidade Capacidade de Raciocínio Quando Escolher GPT-5.6 Luna $1,00 $6,00 Rápido Seguimento de instruções, roteamento Classificação, extração, rendimento GPT-5.6 Terra $2,50 $15,00 Médio Raciocínio moderado, uso de ferramentas Agentes, multi-turno, código médio GPT-5.6 Sol $5,00 $30,00 Lento Raciocínio de fronteira, pesquisa Código complexo, raciocínio difícil, problemas novel Claude Sonnet 5 $2,00–$3,00 $10,00–$15,00 Médio–Rápido Raciocínio forte, tokens de raciocínio longo Raciocínio, codificação (competitivo com Sol) Gemini 3.1 Pro $2,00 $12,00 Médio Multimodal, capacidade de pesquisa Tarefas multimodais, competitivo com Terra DeepSeek V4 Flash $0,14 $0,28 Muito Rápido Raciocínio básico, foco em entrada em cache Roteamento de alto volume, cargas de trabalho com foco em cache (7–35× mais barato) Arbitragem de custos: Para classificação simples e extração, DeepSeek V4 Flash é 7–20× mais barato que Luna. Compare com seus dados — se atinge 90%+ de precisão, use-o e guarde a diferença. Claude Sonnet 5 é 2× mais caro que Terra, mas fornece raciocínio mais forte por pretensão de capacidade de modelo; use-o se seu benchmark de Terra mostrar qualidade insuficiente. Gemini 3.1 Pro fica entre Luna e Terra — útil se você precisa de entrada multimodal ou já está no ecossistema Vertex AI. 7. Migração de GPT-5/5.5 & Status de Deprecação A OpenAI continua oferecendo GPT-5.5 ($5/$30, igual ao Sol) e GPT-5.4 ($2,50/$15, igual ao Terra) junto com GPT-5.6. Não há pressão de deprecação em modelos mais antigos — você pode continuar usando GPT-5.5 se seu código o alvo. No entanto, GPT-5.6 pretende paridade de desempenho (ou melhor) no mesmo nível, portanto migre para 5.6 para novas implantações. A interface ChatGPT continua aposentando modelos mais antigos continuamente (GPT-4o mini, GPT-4 turbo agora são apenas leitura); o acesso pela API é estável. Se você constrói contra a API, planeje revisões anuais do status de deprecação de modelo, mas não espere urgência. Estrutura de Medição de Custos Passo 1: Estabelecer linha de base por nível Execute uma semana de tráfego e registre qual nível lidou com cada solicitação. Isso fornece distribuição de linha de base e custo. Passo 2: Medir pontuações de confiança e taxas de fallback Para cada nível, registre confiança retornada. Calcule: qual % de chamadas Luna têm confiança > 85%? Qual % escala para Terra? Isso diz se sua cascata está equilibrada. Passo 3: Auditar sucesso/fracasso por nível Compare saída do modelo contra verdade fundamental por uma semana. Qual nível tem desempenho insuficiente em seus dados? Ajuste limites ou seleção de nível com base em precisão real, não em pretensões da OpenAI. Passo 4: Calcular custo verdadeiro por resposta bem-sucedida Custo verdadeiro = (custo_nível) / (taxa_sucesso). Se Luna custa $1,20 por 1K com 94% de sucesso, o custo por resposta que funciona é $1,28. Essa é a métrica a otimizar. Lista de Verificação Rápida de Seleção de Nível Esta é uma tarefa de classificação, extração ou roteamento? → Luna a menos que a precisão seja crítica. A tarefa envolve uso de ferramentas ou raciocínio multi-turno? → Terra. Isso é raciocínio novel, código complexo ou análise multi-hop? → Sol (ou compare Claude Sonnet 5 primeiro). Você pode implementar uma cascata (Luna → Terra → Sol)? → Sim, isso geralmente é ideal. Há um prefixo estável (prompt do sistema, docs) reutilizado 10+ vezes/mês? → Cachear, medir ROI no ponto de equilíbrio (5–15 acertos). Isso é lote ou interativo? → Trabalho em lote se qualifica para 50% de desconto; recalcule ROI com API de lote. Você comparou alternativas (Claude, DeepSeek, Gemini)? → Faça no seu dados, não em pretensões de marketing. A seleção de nível é um problema de classificação: combine propriedades de carga de trabalho com economia de nível. O ideal é roteamento em cascata — rotei para Luna primeiro, meça confiança, escale na incerteza. Isso minimiza custo mantendo qualidade. A FinOps LLM pode executar uma auditoria de custos em seu tráfego de LLM e mostrar onde o desajuste de nível está deixando dinheiro na mesa. Agende uma auditoria gratuita . Veja também: Quanto Custa GPT-5? para o panorama completo de preços de GPT e Custos Ocultos de LLM para infraestrutura e gastos indiretos de fallback além de taxas por token. Voltar para pesquisa FAQ Qual nível de GPT-5.6 devo usar para tarefas de classificação? Luna ($1/$6 por 1M) é a escolha certa para classificação e extração simples. Com 600 tokens de entrada + 100 tokens de saída, Luna custa $0,00066/solicitação versus $0,00175/solicitação do Terra. Se a precisão não é seu gargalo, Luna fornece resultados equivalentes com 62% de economia. Quando Terra ($2,50/$15) vence Sol ($5/$30) em custo? Sempre. Terra é posicionado como o ponto ideal de desempenho/custo: mesmas pretensões de capacidade que Sol, mas exatamente pela metade do preço. Use Terra para loops de agentes, conversas multi-turno e tarefas de raciocínio moderado. Use Sol apenas quando a profundidade de raciocínio do Terra for comprovadamente insuficiente. Qual é o impacto de custo do cache de prompts no GPT-5.6? Gravações de cache custam 1,25× entrada (por exemplo, $1,25 por milhão para Luna). Leituras de cache custam 10% de entrada ($0,10 por milhão para Luna). Se um prefixo de 100K tokens for reutilizado 5+ vezes em 30 minutos, o cache economiza 60%+ versus chamadas repetidas sem cache. Como GPT-5.6 se compara a Claude Sonnet 5 e DeepSeek V4? Luna ($1/$6) é 50-60% mais barato que Claude Sonnet ($2/$10 intro, $3/$15 Sept 1) e DeepSeek V4 Flash ($0,14/$0,28) é 7-20× mais barato que Luna. Para cargas de trabalho de raciocínio, Sol ($5/$30) e Claude Sonnet trocam desempenho por dólar de forma diferente; faça benchmark do seu caso de uso. --- # Claude Max vs Alibaba Token Pro: custo agêntico · FinOps LLM URL: https://finopsllm.com/pt/research/heavy-agentic-coding-cost-claude-vs-qwen Claude Max vs Alibaba Token Pro: o custo real da codificação agêntica Atualizado September 19, 2026 · publicado originalmente August 6, 2026 Resposta rápida: Quando o desenvolvimento de software autónomo transita de meros autocompletes para enxames multi-agente (onde um coordenador dispara de 4 a 8 sub-agentes paralelos para testes, refatoração e... Quando o desenvolvimento de software autónomo transita de meros autocompletes para enxames multi-agente (onde um coordenador dispara de 4 a 8 sub-agentes paralelos para testes, refatoração e segurança), o volume de tokens explode. Comparar planos pelo preço de lista de tokens gera decisões de contratação erradas. 1. Modelos de faturação distintos Alibaba Token Pro ($70/mês) estabelece limites claros de 12.000 créditos a cada 5 horas e 40.000 créditos a cada 7 dias para o Qwen 3.8-Max, com tarifa reduzida (multiplicador 0,2×) em horários fora de pico. Claude Max 20x ($200/mês) disponibiliza capacidade computacional dinâmica para o Opus 5 sem divulgar quotas fixas de tokens ou dólares. 2. Ponto de equilíbrio por tarefa aprovada Na matemática direta de subscrições ($70 vs $200), o Qwen 3.8-Max precisa de atingir apenas 35% da produtividade em tarefas aprovadas do Opus 5 para ser mais barato por funcionalidade entregue. Contudo, a um custo de programador de $50/hora, basta que o Opus 5 economize 2,6 horas por mês em correções manuais para cobrir integralmente a diferença de $130. Artigos relacionados Auditoria de custos: Alibaba vs Claude Max Comparar preços de fornecedores IA Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # A marca invisível em cada resposta do Claude · FinOps LLM URL: https://finopsllm.com/pt/research/how-ai-watermarking-works Como funciona a marca de água de IA Atualizado September 1, 2026 · publicado originalmente September 1, 2026 Resposta rápida: Existe um sinal invisível no texto gerado pelos modelos Claude suportados. Nem você nem os seus utilizadores o veem, não altera o sentido nem a qualidade e não aparece na fatura. Está lá na mesma... Existe um sinal invisível no texto gerado pelos modelos Claude suportados. Nem você nem os seus utilizadores o veem, não altera o sentido nem a qualidade e não aparece na fatura. Está lá na mesma — e vale a pena compreendê-lo, porque o que o destrói é precisamente o que o seu pipeline faz todos os dias. O mecanismo, no texto Um modelo de linguagem não escolhe o token mais provável: amostra de uma distribuição usando aleatoriedade. A técnica de marca de água — seguindo a abordagem SynthID-Text — enviesa essa aleatoriedade. Certos tokens tornam-se ligeiramente mais prováveis, segundo um padrão que só o detetor conhece. Cada palavra isolada é irrelevante: havia sempre uma alternativa plausível. Ao longo de centenas de tokens, o padrão acumula-se num sinal estatístico que um detetor mede e um leitor não perceciona. Daí duas consequências: é estatístico e não um carimbo, e precisa de extensão. Uma saída do tamanho de um tweet carrega muito menos sinal do que uma página inteira. As imagens funcionam ao contrário Os ficheiros .svg , .png e .jpg gerados levam metadados C2PA: um manifesto assinado criptograficamente. Não é estatístico nem oculto, é um bloco de dados verificável com exatidão. A troca é previsível: metadados assinados dão certeza e apagam-se com um comando; a marca estatística não se apaga de forma limpa mas degrada-se ao editar, parafrasear ou traduzir. Nenhuma é um cadeado; ambas são prova. O que isto significa para os seus sistemas Saídas curtas levam sinal fraco. O pós-processamento pesado — parafrasear, resumir, traduzir ou passar por um segundo modelo — erode o sinal. E o seu pipeline de imagens pode destruir os metadados C2PA por acidente, a forma mais comum de perder a proveniência em produção. Artigos relacionados O que custa realmente a marca de água Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # O seu CDN está a apagar a marca de água de IA · FinOps LLM URL: https://finopsllm.com/pt/research/how-ai-watermarks-get-destroyed Como as marcas de água são destruídas Atualizado September 1, 2026 · publicado originalmente September 1, 2026 Resposta rápida: A pergunta interessante sobre a marca de água de IA não é como contorná-la, mas porque é que tanto conteúdo de produção chega ao fim do pipeline sem proveniência, sem que ninguém tenha querido remover... A pergunta interessante sobre a marca de água de IA não é como contorná-la, mas porque é que tanto conteúdo de produção chega ao fim do pipeline sem proveniência, sem que ninguém tenha querido remover nada. A proveniência raramente é atacada: é otimizada até desaparecer, por sistemas que fazem exatamente aquilo para que foram construídos. Há dois modos de falha independentes porque há dois mecanismos. A proveniência de imagem morre por eliminação; a de texto, por diluição. Ambas em silêncio. Eliminação: os metadados que o pipeline deita fora Os metadados C2PA vivem no ficheiro. Miniaturizadores, transformações de CDN, conversão para WebP ou AVIF, envios para plataformas terceiras e capturas de ecrã descartam-nos salvo configuração explícita. O padrão é constante: tudo o que recodifica a imagem produz um ficheiro novo, e um ficheiro novo não tem manifesto assinado. Basta uma transformação automática entre a geração e a entrega. Diluição: os passos de texto que erodem o sinal A marca no texto é estatística: não desaparece de uma vez, enfraquece. Traduzir regenera cada token noutra língua. Parafrasear e "reescrever no nosso tom" degrada. Resumir descarta a maioria dos tokens que levavam o sinal. Passar por um segundo modelo atribui o texto, quando muito, ao último. E uma saída de duas frases nunca levou grande coisa. Repare que um produto bem construído faz várias destas coisas. Gerar com um modelo, ajustar o tom com outro, traduzir para cinco línguas e truncar num cartão-resumo não é errado — e ainda assim produz conteúdo que nenhum detetor atribuirá com confiança. A versão barata Gere hoje uma imagem e um texto longo pelo seu caminho real de produção e veja o que sobrevive no fim. É uma tarde de trabalho, e identifica a etapa exata que parte a cadeia antes de o fazer uma auditoria. Artigos relacionados Como funciona a marca de água de IA Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Quanto Custa GPT-5? Guia Completo de Preços 2026 · FinOps LLM URL: https://finopsllm.com/pt/research/how-much-does-gpt5-cost Quanto Custa GPT-5? Atualizado em 15 de julho de 2026 · publicado inicialmente em 4 de julho de 2026 GPT-5 é o modelo de raciocínio insignia da OpenAI, lançado em 2026. Oferece desempenho substancialmente superior em tarefas complexas de raciocínio, programação e multimodais em comparação com GPT-4o - mas com um preço premium. Este guia detalha cada dimensão de custo: preços de API, níveis de assinatura do ChatGPT, comparação com GPT-4o e onde alternativas mais baratas como MiMO podem ser a escolha mais inteligente. Preços de API do GPT-5 A OpenAI cobra pelo GPT-5 por milhão de tokens, com taxas separadas para entrada, saída e entrada em cache. As leituras de cache são significativamente mais baratas porque o modelo reutiliza um prefixo previamente calculado. Nível Entrada $/1M Saída $/1M Leitura Cache $/1M Janela de Contexto GPT-5.6-Sol (máx) $5.00 $30.00 $0.50 128K tokens GPT-5.6-Terra (médio) $2.50 $15.00 $0.25 128K tokens GPT-5.6-Luna (econômico) $1.00 $6.00 $0.10 128K tokens GPT-5.5 (insignia) $5.00 $30.00 $0.50 128K tokens GPT-5.4 (faixa média) $2.50 $15.00 $0.25 128K tokens A nova geração de julho de 2026 da OpenAI (GPT-5.6) introduz três níveis distintos: Sol para raciocínio de ponta, Terra para desempenho equilibrado e Luna para casos de uso conscientes de custos. Para comparação, os modelos mais antigos GPT-5.5 e 5.4 continuam disponíveis. GPT-5.6 e 5.5 a $5/$30 são significativamente mais capazes que GPT-4o ($2.50/$10), mas o custo efetivo depende da profundidade do raciocínio e eficiência de cache. Custos de assinatura do ChatGPT Se você usar GPT-5 através da interface ChatGPT em vez da API, o preço é baseado em assinatura: Plano Preço Mensal Acesso GPT-5 Limites Principais Free $0 Apenas GPT-5 mini Mensagens limitadas/dia Plus $20/mês GPT-5 com limites ~80 mensagens GPT-5/3hrs Pro $200/mês GPT-5 ilimitado Sem limites de taxa, voz, pesquisa profunda Team $25/usuário/mês GPT-5 com limites altos Ferramentas admin, SSO, limites superiores Enterprise Personalizado GPT-5 ilimitado SLA, suporte dedicado, governança de dados O plano Pro a $200/mês só é rentável se você for um usuário intensivo diário. Para a maioria dos desenvolvedores e equipes, a API com gerenciamento cuidadoso de tokens é mais barata que uma assinatura Pro. GPT-5 vs GPT-4o: quando a atualização faz sentido? A diferença de preço é real, então a pergunta é se a vantagem de qualidade do GPT-5 se traduz em economia de custos em outros lugares: Use GPT-5 quando: a tarefa exigir raciocínio em múltiplas etapas, geração complexa de código, análise de documentos longos ou fluxos de trabalho agênticos onde uma única passagem de alta qualidade economiza múltiplos ciclos de nova tentativa. Use GPT-4o quando: a tarefa é direta - classificação, extração, resumo de textos curtos, chat simples ou processamento em lote de alto volume onde o rendimento importa mais que a inteligência por solicitação. Use GPT-5 mini ou nano quando: você precisar de seguimento de instruções em nível GPT-5 mas com custo menor, e pode aceitar profundidade de raciocínio ligeiramente reduzida. Uma regra prática: se seus prompts GPT-4o incluem instruções de cadeia de pensamento ou loops de correção multi-turno, GPT-5 pode ser realmente mais barato porque faz esse raciocínio nativamente em uma única chamada. Como reduzir custos com GPT-5 Várias estratégias podem reduzir sua conta de GPT-5 em 30–70% sem sacrificar a qualidade de saída: Aproveite o cache de prompts. A taxa de leitura de cache do GPT-5 ($2.50/1M) é 75% mais barata que a taxa de entrada completa. Estruture seus prompts com um prefixo estável (instruções do sistema, contexto) e sufixo variável (consulta do usuário) para maximizar acertos de cache. Use GPT-5 mini/nano para roteamento. Execute um modelo leve primeiro para classificar a intenção, depois escale para GPT-5 completo apenas para consultas complexas. Este é o padrão de roteamento de modelos . API em lote para trabalho não interativo. A API em lote da OpenAI oferece descontos de 50% em cargas de trabalho assíncronas - ideal para avaliação, enriquecimento e geração de relatórios. Dimensione adequadamente as janelas de contexto. Não envie 100K tokens de contexto quando 5K é suficiente. Cada token de entrada desnecessário custa 4× mais em GPT-5 que em GPT-4o. Considere alternativas. Para muitas tarefas de programação e raciocínio, modelos como MiMO , DeepSeek R1 ou Claude Sonnet entregam qualidade comparável por uma fração do custo. Use arbitragem de provedor para comparar. Custos ocultos além do preço de etiqueta A taxa por token é apenas parte do quadro. Orçamente estes fatores adicionais: Tokens de raciocínio. GPT-5 usa tokens de raciocínio interno para tarefas complexas. Estes são cobrados na taxa de saída ($30/1M) e podem multiplicar seu volume de saída efetivo por 2–5× em problemas difíceis. Custos de nova tentativa. Se seus prompts forem ambiguos ou sua análise for frágil, as tentativas falhadas ainda consomem tokens. A engenharia de prompt robusta compensa a si mesma. Gasto em avaliação. Testes e benchmarks durante o desenvolvimento podem facilmente exceder gastos de produção se não forem rastreados separadamente. Ver alocação de custos de avaliação . Conclusão GPT-5 é caro mas não uniformemente. A $10/$30 por milhão de tokens, uma chamada de API típica com 1.000 tokens de entrada e 500 de saída custa aproximadamente $0.025. Para aplicações de alto volume, a conta se acumula rapidamente - mas cache inteligente, roteamento e processamento em lote podem reduzir custos pela metade ou mais. Rastreie cada solicitação, atribua gasto a recursos e compare alternativas regularmente. Relacionado Como os provedores de LLM cobram? - os modelos de preços por trás dos números. Roteamento de modelos - enviar a solicitação correta para o modelo correto. Arbitragem de provedor - encontrar o modelo mais barato que atenda seu limite de qualidade. Cache de prompts explicado - como obter acertos de cache reais. Quer isso aplicado ao seu próprio gasto com LLM? FinOps LLM executa uma auditoria gratuita de seus custos com IA e mostra onde estão as economias. Agende auditoria gratuita → Voltar à pesquisa --- # Como auditar seu gasto em LLM em 30 minutos · FinOps LLM URL: https://finopsllm.com/pt/research/how-to-audit-llm-spend Como auditar seu gasto em LLM em 30 minutos A maioria das equipes não sabe como seu orçamento de LLM se decompõe. Os custos se escondem atrás de painéis de provedores que mostram totais mas não atribuição, tipos de tokens que são faturados em taxas diferentes, e padrões de uso que mudam semana a semana. Este guia oferece uma auditoria estruturada que você pode executar em meia hora usando ferramentas que já possui. Passo 1 - Colete dados de faturamento dos provedores Exporte os últimos 30 dias de uso de cada provedor de LLM que você usa. Para OpenAI, use a API de Uso ou baixe o CSV do painel. Para Anthropic, puxe dados da API de Faturamento. Para Google, exporte do console de Faturamento em Nuvem. Para modelos autoalojados, puxe logs de requisições do seu servidor de inferência. Armazene tudo em uma pasta. Você precisa de dados brutos, não resumos. Passo 2 - Normalize as contagens de tokens entre provedores Cada provedor conta tokens de forma diferente. OpenAI e Anthropic usam seus próprios tokenizadores; Google usa SentencePiece. Para comparar, converta todas as contagens para uma unidade comum. A abordagem mais simples: use o preço por token publicado de cada provedor para calcular o custo por requisição, depois compare custos diretamente em vez de contagens de tokens brutos. Isso evita a incompatibilidade de tokenizadores completamente. Passo 3 - Divida por entrada, saída, cache e tokens de raciocínio Os provedores cobram taxas diferentes para tipos de tokens diferentes. Tokens de entrada em cache são normalmente 50% mais baratos na OpenAI e Anthropic. Tokens de raciocínio (em modelos o-series e similares) podem custar 2–4 vezes os tokens de saída padrão. Divida seu gasto em quatro categorias: entrada, saída, entrada em cache e raciocínio. Se seu provedor não expõe essa divisão, estime a partir do tipo de modelo e do padrão de requisição. Passo 4 - Atribua a equipes e funcionalidades Mapeie cada chave de API ou projeto para a equipe ou funcionalidade que a possui. Se você não tiver separação no nível de chave, use metadados de requisição - cabeçalhos, tags ou o parâmetro user que a maioria dos provedores suporta. O objetivo é uma tabela: qual equipe gasta quanto em qual funcionalidade. Sem isso, você não pode responsabilizar ninguém pelo custo. Passo 5 - Identifique os 3 principais impulsionadores de custo Classifique por gasto total em ordem descendente. Na maioria das organizações, 80% do custo de LLM vem de 3–5 padrões de uso. Impulsionadores comuns: um chatbot com janelas de contexto longas, uma funcionalidade de geração de código que usa modelos caros para todas as requisições, ou um trabalho de enriquecimento em segundo plano que é executado em todo documento sem filtrar. Nomeie-os. Este é o lugar onde você se concentra no esforço de otimização. Passo 6 - Calcule o custo por tarefa para fluxos principais Escolha seus 3 fluxos principais. Para cada um, divida o gasto total pelo número de tarefas concluídas. Isso fornece um número de economia unitária que você pode rastrear ao longo do tempo. Um fluxo de suporte ao cliente que custa $0,12 por ticket é gerenciável. Um que custa $1,40 por ticket precisa de atenção. O número absoluto importa menos que a tendência e a comparação entre fluxos. Passo 7 - Configure alertas para anomalias Configure alertas em dois níveis: gasto total diário (detecta trabalhos descontrolados) e gasto por fluxo (detecta desvio). A maioria dos provedores suporta alertas de faturamento nativamente. Para alertas entre provedores, canalize seus dados de uso para um painel ou use uma ferramenta como MiMO que agrega entre provedores. Uma regra simples: alerte se algum dia exceder 150% da média móvel de 7 dias. Lista de verificação de auditoria rápida Passo Ferramenta necessária Tempo estimado Resultado 1. Coletar dados de faturamento Painéis ou APIs de provedores 5 min CSV/JSON bruto por provedor 2. Normalizar tokens Planilha ou script 5 min Tabela de custo por requisição 3. Dividir tipos de tokens APIs de provedores com divisão de tokens 5 min Divisão entrada/saída/cache/raciocínio 4. Atribuir a equipes Mapeamento de chaves de API ou metadados 5 min Matriz de custo equipe-funcionalidade 5. Identificar impulsionadores principais Classificação/planilha 3 min Lista classificada de padrões de custo 6. Custo por tarefa Contagem de tarefas de logs de aplicação 5 min Economia unitária por fluxo 7. Configurar alertas Alertas de faturamento + painel 2 min Detecção de anomalias ativa O que fazer depois Esta auditoria oferece um snapshot. O valor real vem de executá-la regularmente - semanalmente para equipes com alto gasto, mensalmente para todos os outros. Automatize a coleta de dados e transforme a métrica de custo por tarefa em uma métrica de produto de primeira classe. Se você deseja ajuda para construir isso em um processo contínuo, MiMO fornece painéis entre provedores e atribuição automatizada prontos para uso. Relacionado Atribuição de custos de LLM - análise mais profunda de padrões de atribuição. Detecção de anomalias de custo de LLM - estratégias de alertas automatizados. Como orçar gastos com IA - da auditoria ao orçamento. Quer isso aplicado ao seu próprio gasto em LLM? FinOps LLM executa uma auditoria gratuita de seus custos de IA e mostra onde estão as economias. Agende auditoria gratuita → Voltar à pesquisa --- # Como usar Jev em um agente de IA · FinOps LLM URL: https://finopsllm.com/pt/research/how-to-use-jev-in-an-agent Como usar Jev em um agente de IA Atualizado September 21, 2026 · publicado originalmente September 21, 2026 Resposta rápida: Use Jev quando um agente precisa escolher, pontuar, classificar ou bloquear uma ação; não quando precisa escrever. A integração mais útil começa com uma decisão e um conjunto fixo de respostas. Passe... Use Jev quando um agente precisa escolher, pontuar, classificar ou bloquear uma ação; não quando precisa escrever. A integração mais útil começa com uma decisão e um conjunto fixo de respostas. Passe a Jev o estado já disponível no fluxo, defina as opções que o código sabe tratar e use a resposta e a confiança para escolher a rota. A Vercel disponibiliza Jev como typesafe-ai/jev no AI Gateway e documenta o uso pela API experimental evaluate do AI SDK. Consulte a página do modelo para a forma atual da chamada. 1. Comece com uma pergunta delimitada Uma boa primeira pergunta tem opções finitas e uma ação clara: «Qual equipa é responsável por este ticket: Faturação, Técnica, Vendas ou Revisão?». «O que devemos fazer?» pede planeamento e não é uma boa tarefa para Jev. 2. Envie estado e perguntas tipadas Inclua o ticket, os factos relevantes da conta e a parte da política de que a decisão precisa. Declare perguntas como escolha de equipa, pontuação de urgência ou booleano de evidência suficiente. Todas partilham o mesmo estado. 3. Faça a confiança mudar a rota Uma classificação de baixo risco e alta confiança pode seguir automaticamente. Um caso de confiança média pode ir para um modelo mais forte com a mesma evidência. Um caso de alto impacto ou baixa confiança deve ir para revisão. Ajuste limiares por consequência, não com uma regra global. 4. Mantenha a autoridade no código O modelo avalia o estado; o código valida argumentos, aplica permissões, limita tentativas e executa ferramentas. Guarde versão do estado, pergunta, resposta, probabilidade, rota e resultado final. Assim poderá ajustar o limiar e medir o custo por tarefa resolvida. Artigos relacionados Onde Jev entra num fluxo de agentes Seis casos de uso de Jev Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Seis casos de uso de Jev que fazem sentido · FinOps LLM URL: https://finopsllm.com/pt/research/jev-use-cases-that-fit Seis casos de uso de Jev que fazem sentido Atualizado September 21, 2026 · publicado originalmente September 21, 2026 Resposta rápida: Jev funciona quando o sistema já conhece as suas próximas ações possíveis. O modelo escolhe ou pontua entre elas a partir de contexto desorganizado. Isso deixa uma lista pequena e útil de... Jev funciona quando o sistema já conhece as suas próximas ações possíveis. O modelo escolhe ou pontua entre elas a partir de contexto desorganizado. Isso deixa uma lista pequena e útil de aplicações. 1. Encaminhar trabalho antes de gerar Escolha o modelo, especialista ou fila antes de pagar por uma geração completa. Cada rota tem uma ação e um custo conhecidos. 2. Proteger uma chamada de ferramenta Envie a ação proposta, a política e o estado. Pergunte se é rotineira, se precisa de confirmação ou se deve parar. O código valida permissão e argumentos. 3. Fazer triagem de suporte e operações Uma chamada pode atribuir responsável, pontuar urgência e marcar evidência insuficiente. É mais útil que uma síntese em prosa que outro sistema precisa interpretar. 4. Pontuar risco antes de escalar Para revisão de transações, moderação, alertas de segurança ou exceções documentais, Jev separa casos claros dos que precisam de investigação mais lenta. 5. Selecionar contexto para o próximo passo Agentes longos acumulam notas e resultados obsoletos. Jev pode classificar que factos continuam relevantes e se a tarefa tem evidência suficiente para terminar. 6. Verificar um resultado contra uma rubrica Depois de um LLM escrever uma resposta, Jev pode verificar critérios concretos e decidir se continua, precisa de correção ou de revisão. A rubrica deve nomear campos necessários, não perguntar apenas se o resultado é bom. Artigos relacionados Como usar Jev num agente de IA Onde Jev entra num fluxo de agentes Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Rastreamento de Preços de API LLM · FinOps LLM URL: https://finopsllm.com/pt/research/llm-api-pricing-tracker Rastreamento de Preços de API LLM Atualizado em 2 de setembro de 2026 · publicado pela primeira vez em 4 de julho de 2026 Rastreamento de preços por token em todos os principais provedores de LLM. Entrada, saída, leitura/gravação de cache, janelas de contexto e descontos em lotes em uma tabela normalizada. Atualizado mensalmente com dados verificáveis dos provedores. 12+ Provedores rastreados 25+ Modelos listados 6 Colunas de preço Set 2026 Última atualização Todos os preços em USD por 1 milhão de tokens Valores estimados mostrados em cinza Os preços de cache refletem o cache de prompts onde está disponível Metodologia Coleta Dados de preços coletados das páginas oficiais de preços e documentação de API dos provedores. Normalização Todos os preços normalizados em USD por 1 milhão de tokens para comparação direta. Preços de cache As colunas de Leitura/Gravação de cache mostram descontos de cache de prompts onde os provedores os suportam. Política de visualização Os valores oficiais e estimados estão claramente separados. As estimativas são marcadas em cinza. Histórico de Atualizações 4 jul 2026 Rastreamento de Preços de API LLM lançado Publicada a comparação de preços por token em mais de 12 principais provedores de LLM como artigo de pesquisa do FinOps LLM. Tabela de Preços por Token Provedor ↕ Modelo ↕ Entrada $/1M ↕ Saída $/1M ↕ Leitura de Cache $/1M ↕ Gravação de Cache $/1M ↕ Janela de Contexto ↕ Desconto em Lotes OpenAI GPT-5.6-Sol $4.00 $20.00 $0.40 $5.00 1.05M 50% OpenAI GPT-5.6-Terra $2.00 $12.00 $0.20 $2.50 1.05M 50% OpenAI GPT-5.6-Luna $0.20 $1.20 $0.02 $0.25 1.05M 50% Anthropic Claude Fable 5.1 $10.00 $50.00 $0.25 $12.50 1M 50% Anthropic Claude Fable 5 $10.00 $50.00 $1.00 $12.50 1M 50% Anthropic Claude Opus 5 $5.00 $25.00 $0.50 $6.25 1M 50% Anthropic Claude Sonnet 5 * $2.00 $10.00 $0.20 $2.50 1M 50% Anthropic Claude Sonnet 4.6 $3.00 $15.00 $0.30 $3.75 1M 50% Anthropic Claude Haiku 4.5 $1.00 $5.00 $0.10 $1.25 200K 50% Google Gemini 3.5 Flash $1.50 $9.00 $0.15 $1.88 1M 50% Google Gemini 3.1 Pro Preview $2.00 $12.00 $0.20 $2.50 1M 50% Google Gemini 2.5 Pro $1.25 $5.00 $0.31 $4.50 1M 50% Google Gemini 2.5 Flash $0.15 $0.60 $0.04 $0.15 1M 50% xAI Grok 4.5 $2.00 $6.00 $0.50 $1.50 1M 50% xAI Grok 4.3 $1.25 $2.50 - - 1M 50% Meta Llama 4 Maverick (DeepInfra) $0.20 $0.80 - - 1M - Meta Llama 4 Scout (Groq) $0.11 $0.34 - - 5M - Meta Llama 3.3 70B (Groq) $0.59 $0.79 - - 8M - Mistral Mistral Large 2/3 $2.00 $6.00 - - 128K - Mistral Mistral Medium 3.5 $1.50 $7.50 - - 128K - Mistral Mistral Small 3 $0.10 $0.30 - - 128K - Mistral Codestral $0.30 $0.90 - - 128K - DeepSeek DeepSeek V4 Flash $0.14 $0.28 $0.0028 - 128K - DeepSeek DeepSeek V4 Pro $0.435 $0.87 $0.0036 - 128K - Alibaba Qwen Qwen 3.7-Max $2.50 $7.50 - - 131K - Moonshot Kimi Kimi K2.6 $0.95 $4.00 $0.16 - 200K - Xiaomi MiMO Cadastre-se - ambos ganham $2 ↗ MiMo-V2-Pro $0.50 $2.00 - - 128K - Xiaomi MiMO Cadastre-se - ambos ganham $2 ↗ MiMo-V2-Omni $0.40 $1.60 - - 128K - Zhipu AI GLM-5 $1.00 $4.00 - - 128K - Zhipu AI GLM-5-Turbo $0.30 $1.20 - - 128K - MiniMax M2.7 $0.40 $1.60 - - 128K - StepFun step-3.5-flash $0.30 $1.20 - - 128K - * O Claude Sonnet 5 custa $2/$10 por 1M tokens de forma permanente — o aumento para $3/$15 previsto para 1 de setembro de 2026 foi cancelado. Os valores de escrita em cache referem-se ao TTL de 5 minutos; o TTL de 1 hora custa 2× a tarifa base de entrada. Claude Opus 4.8, 4.7 e 4.6 partilham o preço do Claude Opus 5. Claude 4.7 e posteriores usam um tokenizador que gera cerca de 30% mais tokens para o mesmo texto, portanto compare o custo por tarefa, não por token. Os valores não fornecidos explicitamente pelos provedores são mostrados em cinza . Os preços do Meta Llama refletem preços de API hospedada (Fireworks, Together, etc.), não o custo de auto-hospedagem. A economia de auto-hospedagem é abordada em nossa Comparação de Custos de Código Aberto vs Código Fechado . As janelas de contexto são as máximas suportadas; a disponibilidade real pode variar por nível. Os preços de Leitura/Gravação de cache refletem o cache de prompts específico do provedor onde disponível. "-" significa que o provedor não oferece cache ou o preço não está publicado. O Desconto em Lotes mostra a economia aproximada ao usar APIs de lote/assincromía onde disponível. Alguns links podem incluir códigos de referência. Os preços podem mudar com frequência. Sempre verifique as informações mais recentes nas páginas oficiais dos provedores. Guia Prático Como usar esses dados de preços para planejamento de custos 1) Calcule primeiro seu volume de tokens Antes de comparar preços, estime seus volumes mensais de tokens de entrada e saída. Os tokens de saída são tipicamente 3-5x mais caros que os de entrada, então reduzir o comprimento da saída tem o maior impacto no custo. 2) Considere as economias de cache Se sua carga de trabalho tem prompts de sistema ou contexto repetidos (RAG, conversas de múltiplos turnos), o cache de prompts pode reduzir os custos de entrada em 50-90%. Verifique a coluna de Leitura de Cache para os descontos aplicáveis. 3) Use APIs em lote para trabalhos não urgentes A maioria dos principais provedores oferece descontos de 50% em chamadas de API em lote/assincromía. Se sua carga de trabalho tolera latência (avaliações, processamento de dados, geração de conteúdo), os preços em lote reduzem os custos pela metade. 4) Compare o custo total, não apenas o preço por token Um modelo barato que precisa de 3x mais tokens para igualar a qualidade pode custar mais no total. Considere a qualidade do modelo e o desempenho específico da tarefa junto com os preços brutos. Quer isso aplicado ao seu próprio gasto em LLM? FinOps LLM realiza uma auditoria gratuita de seus custos de IA e mostra onde estão as economias. Agende auditoria gratuita → Voltar à pesquisa --- # A sua fatura de LLM tem risco cambial · FinOps LLM URL: https://finopsllm.com/pt/research/llm-bill-fx-exposure Exposição cambial no gasto de LLM Atualizado September 1, 2026 · publicado originalmente September 1, 2026 Resposta rápida: Quase todos os modelos de fronteira têm preço em dólares. Se o seu orçamento não é em dólares, parte do seu custo de LLM é uma posição cambial que nunca decidiu assumir.Um movimento de 6% em EUR/USD é... Quase todos os modelos de fronteira têm preço em dólares. Se o seu orçamento não é em dólares, parte do seu custo de LLM é uma posição cambial que nunca decidiu assumir. Um movimento de 6% em EUR/USD é 6% mais custo sem alterar o volume de tokens nem o modelo, e sem nada no painel de uso que o explique. As finanças veem o desvio; a engenharia, que olha para tokens, vê um mês plano e não consegue ajudar. Porque se esconde tão bem Há três camadas de conversão entre a chamada e o razão: o preço do fornecedor em USD, a conversão do cartão ou fatura com o seu spread, e a taxa a que o ERP contabiliza. No relatório de desvio, a parte cambial e a de uso são o mesmo número. Comprar num marketplace em moeda local não elimina a exposição: move a conversão para montante e acrescenta-lhe margem. Separe os dois desvios Registe o custo de cada pedido em USD à tabela como número primário na telemetria e converta uma só vez, a uma taxa declarada, no reporte. Vale a pena cobrir? Raramente, e só à escala. Para a maioria a resposta certa é visibilidade, não cobertura. Artigos relacionados Ponte de desvio do gasto em IA Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Chargeback e showback de LLM · FinOps LLM URL: https://finopsllm.com/pt/research/llm-chargeback-showback Chargeback e showback de LLM Showback reporta o gasto de LLM aos times e produtos que o causaram. Chargeback atribui esse gasto aos seus orçamentos. A maioria das organizações deveria começar com showback porque os times precisam de tempo para confiar nos números antes de esses números afetarem as decisões orçamentárias. O desafio é a precisão da atribuição. Uma fatura simples do provedor não pode dizer a você qual feature, tenant ou time produziu um token. Você precisa de metadados de requisição do gateway, aplicação ou camada de orquestração. Sem esses metadados, chargeback se torna um argumento político em vez de um sistema operacional. Bons relatórios de showback Decompor o gasto por área de produto e proprietário do time. Mostrar as cargas de trabalho principais e mudanças mês a mês. Separar mudanças de preço do modelo do crescimento de tráfego. Identificar candidatos de otimização de propriedade de cada time. Manter o gasto não alocado visível. Quando fazer chargeback Chargeback faz sentido uma vez que a cobertura de atribuição é alta e os times podem influenciar os drivers de custo. Não cobre dos times por infraestrutura compartilhada sem tag, tabelas de preço obsoletas, ou decisões de plataforma central que não podem mudar. Um modelo sólido usa showback para educação, depois chargeback para centros de custo maduros. Também protege orçamentos de experimentação para que os times não evitem features de IA úteis simplesmente porque o tráfego inicial é difícil de prever. Relacionado Governança do orçamento de LLM - orçamentos e guardrails. Atribuição de custos de LLM - fundamentos de alocação. O que é FinOps LLM? - a disciplina operativa completa. Quer que isto seja aplicado ao seu próprio gasto de LLM? FinOps LLM executa uma auditoria gratuita de seus custos de IA e mostra onde estão as economias. Solicite seu audit gratuito → Voltar para pesquisa --- # Atribuição de custos de LLM · FinOps LLM URL: https://finopsllm.com/pt/research/llm-cost-attribution Atribuição de custos de LLM A atribuição de custos de LLM é a ponte entre as faturas do provedor e as decisões operacionais. Os provedores cobram por conta, modelo, classe de token e às vezes por região ou funcionalidade. As empresas precisam entender o gasto por equipe, produto, cliente, fluxo de trabalho e unidade de valor. A camada de atribuição conecta essas duas visualizações sem perder a reconciliação com a fatura bruta. A chave é etiquetar as requisições antes que cheguem ao provedor ou gateway. Os registros criados após o fato geralmente são incompletos. No mínimo, cada chamada LLM em produção deve incluir um nome de endpoint estável, ambiente, proprietário da equipe, superfície do produto, classe de carga de trabalho e ID de correlação. Quando os contratos permitem, adicione ID de inquilino ou cliente. Para fluxos de trabalho de agentes, etiquete cada chamada de ferramenta ou passo do modelo separadamente. Contagem de requisições não é atribuição Alocar gasto por contagem de requisições é quase sempre incorreto. Uma requisição de raciocínio com contexto longo pode custar mais do que centenas de chamadas de classificação curta. A atribuição precisa de classes de token e preços de modelo. Também precisa de dados de tentativas novamente e fallbacks, porque uma resposta "bem-sucedida" pode ocultar três chamadas falhadas anteriores. Dimensões recomendadas Provedor, modelo e versão do modelo quando disponível. Classes de token de entrada, saída, escrita de cache, leitura de cache e raciocínio. Equipe, produto, funcionalidade, endpoint e ambiente. Classe de carga de trabalho: caminho de usuário em tempo real, trabalho em segundo plano, avaliação, enriquecimento, passo de agente, fluxo de trabalho de suporte ou tarefa de análise. Atribuição de cliente ou inquilino quando permitido pelos limites de privacidade e contrato. Reconciliação de fatura A atribuição deve reconciliar de volta com a fatura do provedor. Espere pequenas diferenças por arredondamento, linhas de fatura atrasadas e descontos específicos do provedor, mas grandes lacunas significam que o pipeline de registro está perdendo tráfego ou usando tabelas de preços obsoletas. A visualização de finanças deve mostrar tanto gasto atribuído quanto não atribuído para que os problemas de qualidade de dados fiquem visíveis. De showback para ação A primeira saída deve ser showback: quais equipes e superfícies de produto estão impulsionando o gasto, e quais cargas de trabalho mudaram desde o mês passado. Uma vez que as equipes confiem nesses dados, use-os para classificar o trabalho de otimização. A atribuição é valiosa porque aponta diretamente para os proprietários que podem aprovar roteamento, cache ou mudanças de prompt. Relacionado Atribuição de custos de OpenAI - padrões de atribuição específicos do OpenAI. Chargeback e showback de LLM - transferindo custos para proprietários. O que é FinOps de LLM? - a disciplina operacional completa. Deseja aplicar isto ao seu próprio gasto em LLM? O FinOps LLM realiza uma auditoria gratuita de seus custos de IA e mostra onde estão as economias. Agende sua auditoria gratuita → Voltar para pesquisa --- # Calculadora de Custos LLM - Estime Seu Gasto Mensal em IA · FinOps LLM URL: https://finopsllm.com/pt/research/llm-cost-calculator Calculadora de Custos LLM Atualizado em 15 de julho de 2026 Estime seu gasto mensal em LLMs entre modelos populares. Digite seu padrão de uso abaixo e compare os custos lado a lado. Todos os preços são por milhão de tokens a partir de julho de 2026. Custos pré-calculados por nível de uso Assim é o que cada nível de uso custa por mês em modelos populares, com base em padrões de requisição típicos: Modelo Leve (1K req/mês) Médio (10K req/mês) Intensivo (100K req/mês) GPT-5.6-Sol $8.75 $87.50 $875.00 GPT-5.6-Terra $4.38 $43.75 $437.50 GPT-5.6-Luna $1.75 $17.50 $175.00 Claude Fable 5 $17.50 $175.00 $1,750.00 Claude Opus 4.8 $8.75 $87.50 $875.00 Claude Sonnet 5 $3.50 $35.00 $350.00 Claude Haiku 4.5 $1.75 $17.50 $175.00 Gemini 3.5 Flash $2.63 $26.25 $262.50 Grok 4.5 $4.00 $40.00 $400.00 DeepSeek V4 Pro $0.95 $9.50 $95.00 Kimi K2.6 $1.70 $17.00 $170.00 Leve: 1K requisições/mês, 500 entrada + 200 tokens de saída. Médio: 10K requisições/mês, 1.000 entrada + 500 tokens de saída. Intensivo: 100K requisições/mês, 2.000 entrada + 1.000 tokens de saída. Calculadora interativa Modelo GPT-5.6-Sol ($5.00 / $30.00) GPT-5.6-Terra ($2.50 / $15.00) GPT-5.6-Luna ($1.00 / $6.00) Claude Fable 5 ($10.00 / $50.00) Claude Opus 4.8 ($5.00 / $25.00) Claude Sonnet 5 ($2.00 / $10.00) Claude Haiku 4.5 ($1.00 / $5.00) Gemini 3.5 Flash ($1.50 / $9.00) Grok 4.5 ($2.00 / $6.00) DeepSeek V4 Pro ($0.435 / $0.87) Kimi K2.6 ($0.95 / $4.00) Requisições por mês Tokens de entrada médios por requisição Tokens de saída médios por requisição Calcular custo Como usar esta calculadora Escolha seu modelo do menu suspenso. Os preços refletem as tarifas padrão de API a partir de julho de 2026. Digite seu volume de requisições - quantas chamadas de API você faz por mês. Estime a contagem de tokens - o número médio de tokens de entrada e saída por requisição. Se não tiver certeza, comece com 1.000 entrada / 500 saída para chat ou 3.000 entrada / 1.000 saída para geração de código. Clique em Calcular para ver seu custo mensal estimado dividido por entrada e saída. Como reduzir sua estimativa Use cache de prompt. Se seus prompts têm um prefixo estável, as leituras do cache podem reduzir os custos de entrada em 50-90%. Consulte cache de prompt explicado . Altere o modelo por tarefa. Encaminhe consultas simples para modelos mais baratos e reserve os caros para tarefas complexas. Isto é roteamento de modelo . Use APIs em lote. Cargas de trabalho não urgentes podem usar preços em lote com 50% de desconto. Tente fornecedores mais baratos. MiMO e DeepSeek oferecem taxas significativamente mais baixas para qualidade comparável em muitas tarefas. Relacionado Quanto custa GPT-5? - análise detalhada de preços do GPT-5. Como os provedores de LLM cobram? - entender o faturamento baseado em tokens. A forma mais barata de executar geração de código com IA - comparação de custos para ferramentas de codificação. Arbitragem de provedor - encontre o modelo mais barato que atende ao seu limite de qualidade. Quer isso aplicado ao seu próprio gasto em LLM? O FinOps LLM executa uma auditoria gratuita de seus custos de IA e mostra onde estão as economias. Agende auditoria gratuita → Voltar para pesquisa --- # Runbook de produção para um pico de custos LLM · FinOps LLM URL: https://finopsllm.com/pt/research/llm-cost-spike-runbook Runbook de produção para um pico de custos LLM Atualizado August 27, 2026 · publicado originalmente August 27, 2026 Resposta rápida: Num pico, preserve as provas, confirme a faturação e separe volume, tarifa, mix e eficiência antes de mudar o modelo.Os primeiros 15 minutosGuarde fatura, tráfego, mix, tipos de token, retries e... Num pico, preserve as provas, confirme a faturação e separe volume, tarifa, mix e eficiência antes de mudar o modelo. Os primeiros 15 minutos Guarde fatura, tráfego, mix, tipos de token, retries e deployments. Compare a faturação com a telemetria do gateway. Conter em segurança Use o controlo mais estreito: pausar um fluxo, limitar um agente, encaminhar batch ou desligar uma função nova. Proteja tráfego crítico e defina responsável, validade e rollback. Explicar e fechar Verifique volume, mix, contexto, ferramentas, falhas e tarifas. Compare custo por tarefa bem-sucedida com a base e documente a ação permanente. Artigos relacionados Monitorização de custos LLM Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Tendências de custos de LLM 2025–2026 · FinOps LLM URL: https://finopsllm.com/pt/research/llm-cost-trends-2025-2026 Tendências de custos de LLM 2025–2026 Atualizado em 15 de julho de 2026 · publicado pela primeira vez em 4 de julho de 2026 O mercado de LLM se move em duas direções ao mesmo tempo. Os preços de tokens de entrada e saída para modelos de classe GPT-4 caíram 80–90% desde o início de 2024. Ao mesmo tempo, os modelos de raciocínio (o1, o3, DeepSeek-R1, Claude Opus 4) são 5–30x mais caros por tarefa do que seus equivalentes sem raciocínio. O efeito líquido: os times que adotam modelos de raciocínio veem suas contas subirem mesmo quando os preços unitários caem. Este artigo rastreia os eventos chave de preço e qualidade de 2025 até meados de 2026, explica as forças que impulsionam os custos e prevê o que esperar na segunda metade de 2026. Tendência chave 1: Os modelos de classe GPT-4 caíram 90% em 18 meses Em março de 2024, GPT-4-turbo custava $10 por milhão de tokens de entrada e $30 por milhão de tokens de saída. No meio de 2026, GPT-4.1 custa $2 por milhão de entrada e $8 por milhão de saída: uma queda de 75–80%. Claude seguiu uma trajetória similar: Claude 3 Opus a $15/$75 caiu para Claude Sonnet 4 a $3/$15. Os modelos de peso aberto de Mistral, Llama e DeepSeek empurraram os preços ainda mais para baixo, com alguns disponíveis por menos de $0,50 por milhão de tokens de entrada através de provedores hospedados. Isto não é apenas uma guerra de preços. A infraestrutura de inferência melhorou: quantização, decodificação especulativa, otimização de KV-cache e processamento em lote reduziram o custo de servir um token. Os provedores passaram parte desses economias para os clientes. Tendência chave 2: Os modelos de raciocínio são 5–30x mais caros Os modelos de raciocínio (o1, o3, o4-mini, DeepSeek-R1, Claude Opus 4 com pensamento estendido) geram tokens de "pensamento" internos antes de produzir uma resposta final. Esses tokens de pensamento são cobrados como tokens de saída. Um modelo de raciocínio resolvendo uma tarefa de codificação pode gerar 10K–50K tokens de pensamento antes de produzir uma resposta de 2K tokens. O custo efetivo por tarefa é, portanto, muito mais alto do que o preço por token sugere. Para times usando modelos de raciocínio para cada tarefa, este é o maior fator de custo em 2026. A pergunta chave não é "quanto custa o modelo?" mas "esta tarefa precisa de raciocínio?" A maioria não precisa. Tendência chave 3: O código aberto fechou a lacuna de qualidade No início de 2024, os modelos de peso aberto ficavam significativamente atrás dos modelos proprietários em benchmarks de codificação e raciocínio. No meio de 2026, modelos como Llama 4 Maverick, DeepSeek-V3, Qwen 3 e MiMo estão a poucos pontos do desempenho de classe GPT-4 na maioria dos benchmarks. Isto importa para custo porque modelos de peso aberto são mais baratos de servir: os provedores competindo em preço os usam para reduzir os preços proprietários. A lacuna de qualidade não se fechou completamente para tarefas de raciocínio na fronteira. Mas para a maioria das cargas de trabalho de produção: resumo, extração, classificação, geração de código, uso de ferramentas, os modelos de peso aberto são bons o suficiente e significativamente mais baratos. Tendência chave 4: O cache reduziu custos efetivos 50–90% para cargas de trabalho repetitivas Cache de prompts (Anthropic) e cache automático de contexto (OpenAI, Google) mudaram a economia das cargas de trabalho repetitivas. Se você enviar o mesmo prompt de sistema e contexto para um modelo 100 vezes por dia, leituras em cache custam 50–90% menos do que leituras sem cache. Para pipelines RAG, sistemas de agentes e processamento em lote, isto é transformador. Os benefícios do cache são distribuídos de forma desigual. Cargas de trabalho com contexto estável (mesmo prompt de sistema, mesmo conjunto de documentos) se beneficiam enormemente. Cargas de trabalho com contexto dinâmico (conversas específicas do usuário, dados em tempo real) se beneficiam menos. Os times de FinOps devem medir sua taxa de acerto de cache e otimizar a estabilidade de contexto para maximizar economias. Tendência chave 5: Os fluxos de trabalho de agentes multiplicam o consumo de tokens Os fluxos de trabalho de agentes, onde os modelos chamam ferramentas, leem arquivos, executam código e iteram sobre resultados, consomem 5–50x mais tokens por tarefa do que interações de turno único. Um agente de codificação resolvendo um bug pode consumir 100K–500K tokens através de suas chamadas de ferramenta, tentativas novamente e acumulação de contexto. Um prompt equivalente de turno único poderia usar 2K–5K tokens. Esta é a tendência de custo mais importante em 2026. Os preços de tokens estão caindo, mas o consumo de tokens por tarefa está subindo mais rápido. Resultado líquido: o gasto total em LLM está subindo para a maioria dos times mesmo quando os preços unitários caem. Cronograma: eventos chave Data Evento Impacto no preço Impacto na qualidade Mar 2024 Lançamento de GPT-4-turbo 50% mais barato que GPT-4 Qualidade comparável Jun 2024 Lançamento de Claude 3.5 Sonnet 5x mais barato que Opus Qualidade quase Opus Set 2024 Lançamento de o1-preview 3–5x mais por tarefa (raciocínio) Grande salto em raciocínio Dez 2024 Google Gemini 2.0 Flash Menos de $1/M tokens de entrada Forte para tarefas de velocidade Jan 2025 DeepSeek-R1 código aberto 10x mais barato que o1 Raciocínio próximo ao o1 Fev 2025 Redução de preço Claude 3.5 Sonnet Queda adicional de 20% Mesma qualidade Abr 2025 Lançamento de GPT-4.1 30% mais barato que GPT-4-turbo Codificação melhorada Mai 2025 Lançamento de Claude Sonnet 4 Mesmo preço, melhor qualidade Grande salto em codificação Jun 2025 Redução de preço OpenAI o3-mini Raciocínio 50% mais barato Mesma qualidade Jan 2026 DeepSeek-V3 em provedores hospedados Menos de $0,50/M tokens de entrada Quase classe GPT-4 Abr 2026 Lançamento de Claude Opus 4 Preço premium ($15/$75) Raciocínio na fronteira Jun 2026 Llama 4 Maverick hospedado Menos de $0,30/M tokens de entrada Qualidade geral forte Jul 2026 Lançamento de Anthropic Fable 5 / OpenAI GPT-5.6 Novo nível na fronteira ($5/$30), preço de nível médio ($2.50/$15), nível econômico ($1/$6) Fable 5 correspondeu ao desempenho Opus 4 O que esperar na segunda metade de 2026 Os preços de modelos de raciocínio cairão 30–50%. A competição de modelos de raciocínio código aberto (DeepSeek-R2, variantes de raciocínio Qwen 3) forçará os provedores proprietários a reduzir preços em seus níveis de raciocínio. Surgirá preço específico para agentes. Os provedores estão testando modelos de preço por tarefa e por sessão que agrupam chamadas de ferramenta, tentativas novamente e contexto em um custo único previsível. Espere que pelo menos um provedor importante ofereça isto até Q4 de 2026. O cache se tornará automático. O gerenciamento manual de cache desaparecerá. Os provedores otimizarão a colocação de cache de forma transparente e as taxas de acerto de cache melhorarão para a maioria das cargas de trabalho sem intervenção do desenvolvedor. Os modelos de peso aberto dominarão o trabalho rotineiro. Até o final de 2026, espere que mais de 70% da inferência de produção em tarefas rotineiras (classificação, extração, resumo, geração de código simples) seja executado em modelos de peso aberto através de provedores hospedados. O gasto total continuará subindo. Apesar da queda de preços unitários, os fluxos de trabalho impulsionados por agentes e a expansão de casos de uso de IA significam que o gasto total em LLM continuará crescendo. A disciplina FinOps, não apenas modelos mais baratos, é o que mantém o gasto sob controle. Relacionado Economia de agentes - como os preços dos agentes de codificação funcionam na prática. Arbitragem de provedor - mudar de provedor para reduzir custos. Roteamento de modelo - enviar tarefas para o modelo correto. FinOps para LLM - o framework mais amplo. Quer aplicar isto ao seu próprio gasto em LLM? FinOps LLM executa uma auditoria gratuita dos seus custos de IA e mostra onde estão as economias. Solicite sua auditoria gratuita → Voltar à pesquisa --- # Impacto de Custo de Servidores MCP · FinOps LLM URL: https://finopsllm.com/pt/research/mcp-server-cost-impact Impacto de custo de servidores MCP O Protocolo de Contexto do Modelo (MCP) permite que LLMs chamem ferramentas externas: bancos de dados, APIs, sistemas de arquivos, mecanismos de busca. É poderoso. Também é caro. Cada definição de ferramenta MCP consome espaço na janela de contexto, cada chamada de ferramenta é uma viagem de ida e volta separada para a API, e cada resultado de ferramenta é alimentado de volta ao modelo como tokens de entrada adicionais. Para equipes executando fluxos de trabalho de agentes intensivos em MCP, a sobrecarga relacionada a ferramentas pode representar 30–60% do gasto total de tokens. Este artigo explica como MCP aumenta os custos, como medir a sobrecarga e o que fazer a respeito. Como MCP consome tokens Existem três camadas de custo de tokens em cada interação MCP: Camada 1: Definições de ferramentas. Cada servidor MCP registra ferramentas com o modelo. Uma definição de ferramenta inclui o nome da função, o esquema de parâmetros e uma descrição do que a ferramenta faz. Uma definição de ferramenta típica consome 500–2.000 tokens. Um servidor com 15 ferramentas adiciona 7,5K–30K tokens a cada solicitação, mesmo que nenhuma dessas ferramentas seja chamada. Camada 2: Solicitações de chamadas de ferramentas. Quando o modelo decide chamar uma ferramenta, ele gera uma saída de chamada de ferramenta (nome da função + argumentos). Isso é cobrado como tokens de saída. Depois o resultado da ferramenta retorna como tokens de entrada. Uma única viagem de ida e volta de chamada de ferramenta típica custa 1K–5K tokens dependendo do tamanho do resultado. Camada 3: Resultados de ferramentas em contexto. Os resultados de ferramentas permanecem no contexto de conversação para todos os turnos subsequentes. Se você chamar 10 ferramentas em uma sessão, esses resultados se acumulam. Uma consulta de banco de dados retornando 50 linhas de JSON pode adicionar 8K–15K tokens que persistem pelo resto da conversação. O efeito composto Os custos de MCP se compõem porque as definições de ferramentas são enviadas com cada solicitação. Se você tem 20 ferramentas definidas (10K–40K tokens de definições) e faz 5 solicitações em uma conversação, apenas as definições de ferramentas custam 50K–200K tokens de entrada. Adicione os resultados das chamadas de ferramentas e você pode facilmente dobrar seu consumo de tokens de linha de base. Padrão MCP Sobrecarga de tokens Frequência Impacto mensal de custos (estimativa) Definições de ferramentas (10 ferramentas) 5K–20K tokens por solicitação Cada solicitação $15–$60 por usuário Viagem de ida e volta de uma chamada de ferramenta 1K–5K tokens 3–10 por sessão $5–$25 por usuário Resultado grande de ferramenta (consulta DB, busca de código) 5K–20K tokens 1–5 por sessão $10–$50 por usuário Resultados acumulados em sessão longa 20K–100K tokens 1–3 sessões/dia $30–$120 por usuário Definições de ferramentas não usadas carregadas 5K–30K tokens por solicitação Cada solicitação $15–$90 por usuário Como medir a sobrecarga de MCP A maneira mais simples de medir o custo de MCP é executar o mesmo prompt duas vezes: uma com ferramentas MCP carregadas e outra sem. A diferença em tokens de entrada é sua sobrecarga de definições de ferramentas. Depois conte os tokens de chamadas de ferramentas separadamente: a maioria dos provedores os rotula distintamente em seus painéis de faturamento. Para uma medição mais precisa, instrumente seu cliente MCP para registrar: número de ferramentas registradas, tokens consumidos por definições de ferramentas por solicitação, número de chamadas de ferramentas por sessão, tokens por resultado de ferramenta e tokens totais de sessão atribuídos à atividade de ferramentas. Estratégias para reduzir os custos de MCP 1. Carregue ferramentas seletivamente. Não registre todas as ferramentas para cada solicitação. Se o usuário está fazendo uma pergunta de código, ele não precisa de ferramentas de banco de dados ou implantação carregadas. Muitos clientes MCP suportam carregamento dinâmico de ferramentas baseado em contexto ou ativação explícita do usuário. 2. Minimize as descrições de ferramentas. As descrições de ferramentas são o maior consumidor de tokens nas definições. Uma descrição verbosa pode ser 500 tokens; uma concisa pode ser 100 tokens. Em 20 ferramentas, isso é uma diferença de 8K tokens por solicitação. 3. Trunce os resultados de ferramentas. Retorne apenas os campos que o modelo realmente precisa. Se uma consulta de banco de dados retorna 20 colunas mas o modelo só precisa de 3, projete o resultado. Limite o tamanho do resultado a um limite razoável: 2K–4K tokens é geralmente suficiente para o modelo tomar uma decisão. 4. Armazene em cache as chamadas repetidas. Se a mesma ferramenta for chamada com os mesmos argumentos em uma sessão, retorne o resultado em cache em vez de executar novamente. Isso é especialmente valioso para consultas de referência, consultas de esquema e busca de documentação. 5. Resuma antes de injetar. Para resultados grandes de ferramentas (conteúdo completo de arquivos, respostas longas de API), resuma antes de adicionar ao contexto. Retorne um resumo mais a opção de buscar o resultado completo se o modelo precisar. 6. Use limites de orçamento para resultados de ferramentas. Defina um orçamento por sessão para tokens de resultados de ferramentas. Quando o orçamento é atingido, recuse mais chamadas de ferramentas ou mude para um modelo mais barato pelo resto da sessão. O custo oculto de servidores MCP Além dos custos de tokens, os servidores MCP introduzem sobrecarga de latência e confiabilidade. Uma chamada de ferramenta que leva 3 segundos para responder adiciona latência a cada turno. Uma ferramenta que falha intermitentemente causa tentativas. Ambas aumentam o custo efetivo por tarefa. Para equipes escalando o uso de MCP em uma organização, rastrear esses custos no nível do servidor é essencial. Rotear cargas de trabalho intensivas em MCP para modelos com custos por token mais baixos, e manter fluxos de trabalho leves em MCP em modelos premium onde a latência importa. Relacionado Economia de agentes - como os agentes de codificação precificam na prática. Atribuição de gastos de agentes - rastreamento de custos de agentes por projeto. Rastreamento de tokens de LLM - medição do que você gasta. FinOps para LLM - o framework mais amplo. Quer que isso seja aplicado ao seu próprio gasto em LLM? FinOps LLM executa uma auditoria gratuita de seus custos de IA e mostra onde estão as economias. Solicite sua auditoria gratuita → Voltar para pesquisa --- # Controlar o custo de tokens em esquemas MCP · FinOps LLM URL: https://finopsllm.com/pt/research/mcp-tool-definition-overhead Controlar o custo de tokens em esquemas MCP em agentes de IA Atualizado September 19, 2026 · publicado originalmente September 19, 2026 Resposta rápida: Conectar um agente de IA a múltiplos servidores Model Context Protocol (MCP) introduz milhares de tokens de entrada a cada turno antes mesmo de processar o pedido do utilizador. Cada ferramenta... Conectar um agente de IA a múltiplos servidores Model Context Protocol (MCP) introduz milhares de tokens de entrada a cada turno antes mesmo de processar o pedido do utilizador. Cada ferramenta registada anexa um esquema JSON com nomes de funções, descrições de parâmetros e restrições. Num ambiente com 6 servidores MCP, este cabeçalho consome entre 4.500 e 12.000 tokens por chamada. Porque é que as definições de ferramentas MCP consomem tantos tokens? Cada ferramenta MCP requer especificações completas em formato JSON Schema para orientar o modelo na execução de chamadas. Uma ferramenta complexa consome facilmente 400 a 600 tokens, acumulando um custo fixo que penaliza todas as iterações. Soluções de engenharia As equipas de engenharia resolvem este problema recorrendo a pontos de cache de prompts após as declarações das ferramentas, encaminhamento semântico em duas fases para carregar apenas as ferramentas necessárias e minificação de esquemas. Artigos relacionados Ferramentas de servidor e custos Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Cortes de preço de modelos não baixam a conta sozinhos · FinOps LLM URL: https://finopsllm.com/pt/research/model-price-cuts-routing-budget Cortes de preço e orçamento de roteamento Atualizado September 10, 2026 · publicado originalmente September 10, 2026 Resposta rápida: A queda no custo unitário de tokens não garante redução na fatura corporativa sem reestruturação das regras de roteamento e controle de consumo. A queda no custo unitário de tokens não garante redução na fatura corporativa sem reestruturação das regras de roteamento e controle de consumo. Artigos relacionados Custo por tarefa concluída Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Verificações de segurança são outra fatura · FinOps LLM URL: https://finopsllm.com/pt/research/moderation-pass-second-bill O que custam guardrails e moderação Atualizado September 1, 2026 · publicado originalmente September 1, 2026 Resposta rápida: Uma funcionalidade LLM em produção raramente faz uma só chamada. Faz a que desenhou e depois as que acrescentou por segurança: classificador de entrada, verificação de saída, juiz de política, às... Uma funcionalidade LLM em produção raramente faz uma só chamada. Faz a que desenhou e depois as que acrescentou por segurança: classificador de entrada, verificação de saída, juiz de política, às vezes um segundo modelo a avaliar o primeiro. Tudo isso é inferência, e inferência é faturada. O multiplicador é maior do que parece A moderação de entrada lê toda a entrada, a de saída lê toda a resposta. Um juiz lê as duas , mais o contexto recuperado e uma grelha — a chamada do juiz fica maior do que a chamada julgada. Onde a despesa se acumula Três padrões: julgar com um modelo de fronteira por comodidade (a classificação é precisamente onde um modelo pequeno chega, e costuma ser a maior poupança disponível); verificar em cada turno , revarrendo histórico já aprovado; e guardrails em tráfego interno , que herda a pilha de segurança pública sem precisar dela. Orçamente como uma linha Não se trata de retirar os controlos, mas de ver que podem ser 30–50% do custo de inferência sem constar do plano. Marque as chamadas de guardrail em separado na telemetria. Artigos relacionados Atribuição de custos de LLM Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # O seu ambiente de dev também gasta · FinOps LLM URL: https://finopsllm.com/pt/research/non-production-llm-spend Gasto de LLM fora de produção Atualizado September 1, 2026 · publicado originalmente September 1, 2026 Resposta rápida: Toda a revisão FinOps começa pelo tráfego de produção, porque é o que tem painel. Depois alguém reparte por ambiente e descobre que uma fatia relevante da fatura — muitas vezes de dois dígitos... Toda a revisão FinOps começa pelo tráfego de produção, porque é o que tem painel. Depois alguém reparte por ambiente e descobre que uma fatia relevante da fatura — muitas vezes de dois dígitos em percentagem — nunca tocou num cliente. De onde vem CI: cada pull request que corre uma suite de avaliação chama o modelo, milhares de vezes por dia, no modelo mais caro. Desenvolvimento local: iterar um prompt são dezenas de chamadas por hora, em chave partilhada e sem etiquetas. Staging e demos: configurados como produção, com modelo caro e sem cache. Retentativas e ciclos descontrolados em teste , que ninguém vigia. Primeiro a atribuição A mudança que se paga sozinha é uma chave de API por ambiente . Custa uma tarde e transforma uma rubrica inexplicada em quatro identificadas. Etiquete o ambiente em cada pedido e, na CI, o repositório e o workflow. Seguem-se três coisas: fora de produção quase sempre basta um modelo mais barato; a cache rende aí mais do que em qualquer lado, porque a CI repete prompts quase idênticos; e os tetos rígidos de gasto são ali seguros — um ambiente de teste com teto quebra um build, um de produção quebra um cliente. Artigos relacionados Atribuição de custos de LLM Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # A observabilidade de IA pode virar uma segunda fatura · FinOps LLM URL: https://finopsllm.com/pt/research/observability-second-llm-bill Observabilidade de IA como segunda fatura Atualizado September 9, 2026 · publicado originalmente September 9, 2026 Resposta rápida: Utilizar modelos adicionais para auditar respostas em tempo real pode duplicar os custos de computação. Utilize amostragem estatística e modelos menores. Utilizar modelos adicionais para auditar respostas em tempo real pode duplicar os custos de computação. Utilize amostragem estatística e modelos menores. Artigos relacionados Controle de custos em avaliações Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Modelos Abertos vs. Fechados: Comparação de Custos LLM · FinOps LLM URL: https://finopsllm.com/pt/research/open-source-vs-closed-cost Modelos Abertos vs. Fechados: Comparação de Custos LLM Atualizado 15 de julho de 2026 · publicado pela primeira vez 4 de julho de 2026 Quando é rentável auto-hospedar Llama, Qwen ou DeepSeek em vez de pagar por acesso a API? Esta análise cobre custos de GPU, otimização de inferência, despesas operacionais e oferece uma estrutura de decisão para sua carga de trabalho específica. 8 Modelos comparados 5 Níveis de GPU analisados 3 Cenários de equilíbrio Jul 2026 Última atualização Os custos de auto-hospedagem assumem preços de GPU em nuvem (sob demanda) Os custos de API usam preços padrão de saída por provedor O equilíbrio é baseado em utilização de 70%, disponibilidade 24/7 Metodologia Preços de API Tarifas padrão publicadas de cada página de preços do provedor. Sem descontos por volume ou lotes aplicados. GPU em nuvem para auto-hospedagem Preços sob demanda em nuvem (Lambda, RunPod, AWS) para configurações otimizadas para inferência com vLLM ou TensorRT-LLM. Despesas operacionais Inclui monitoramento, escalabilidade, atualizações de modelos e sobrecarga operacional de 15% nos custos brutos de GPU para infraestrutura gerenciada. Brecha de qualidade Relativa a GPT-4o / Claude Sonnet 4 como linha de base 100%. Baseada em benchmarks públicos e desempenho prático em tarefas. Tabela de Comparação de Custos Modelo ↕ Custo de API/mês ↕ Custo de Auto-hospedagem (GPU em nuvem) ↕ Volume de Equilíbrio ↕ Brecha de Qualidade Llama 4 Maverick (DeepInfra) $260/mês $2.800/mês ~350M tokens/mês ~95% de GPT-4o Llama 3.3 70B (Groq) $277/mês $1.200/mês ~210M tokens/mês ~87% de GPT-4o Llama 4 Scout (Groq) $136/mês $1.400/mês ~350M tokens/mês ~88% de GPT-4o Qwen 3.7-Max $525/mês $1.600/mês ~100M tokens/mês ~92% de GPT-4o DeepSeek V4 Pro $435/mês $1.800/mês ~130M tokens/mês ~96% de GPT-4o DeepSeek V4 Flash $140/mês $1.400/mês ~450M tokens/mês ~82% de GPT-4o Mistral Medium 3.5 $525/mês $2.000/mês ~120M tokens/mês ~91% de GPT-4o GPT-4o (somente API) $750/mês N/A N/A Linha de base (100%) Custo de API/mês assume 100M tokens de saída + 300M tokens de entrada por mês a tarifas padrão. Custo de Auto-hospedagem inclui aluguel de GPU, despesas operacionais de 15% e infraestrutura de inferência (vLLM). Não inclui tempo de engenharia inicial. Volume de Equilíbrio é a contagem mensal de tokens de saída onde a auto-hospedagem se torna mais barata que a API. Brecha de Qualidade é aproximada e depende da tarefa. Benchmarks como MMLU, HumanEval e GPQA informam essas estimativas. Alguns links podem incluir códigos de referência. Fatores-Chave de Custo 1) O aluguel de GPU é o custo dominante Um nó 8x H100 para Llama 4 Maverick custa $2.000-$3.500/mês sob demanda de Lambda, RunPod ou AWS. Instâncias spot/preemptíveis podem reduzir isso 40-60% mas adicionam latência de reinicialização e risco de disponibilidade. Para cargas de trabalho de produção, instâncias reservadas (comprometimento de 1 ano) típicamente economizam 30-40% em relação ao sob demanda. 2) A otimização de inferência muda a equação vLLM com batching contínuo, paging de KV-cache e quantização (GPTQ/AWQ 4-bit) podem aumentar a taxa de processamento 2-4x no mesmo hardware. TensorRT-LLM adiciona mais 20-40% para arquiteturas suportadas. Um Llama 4 Scout bem ajustado 4-bit em uma única A100 pode igualar uma configuração ingênua fp16 em 2x A100s. 3) A despesa operacional é real, mas está diminuindo Executar infraestrutura de inferência requer monitoramento de GPU, atualizações de modelos, balanceamento de carga e failover. Planeje 15-25% do custo bruto de GPU para operações. As plataformas gerenciadas (Anyscale, Modal, Replicate) absorvem isso, mas cobram 30-50% de prêmio sobre GPU bruto - vale a pena por menos de ~$5K/mês em gasto com GPU. 4) O cache de prompt estreita a brecha para API Os provedores de API oferecem cada vez mais cache de prompt (desconto de 50-90% em prefixos repetidos). Se sua carga de trabalho é amigável ao cache (RAG, multi-turn), os custos de API caem significativamente, empurrando o volume de equilíbrio mais alto para auto-hospedagem. Estrutura de Decisão Use API se... O volume mensal de saída está abaixo de 100M tokens Você precisa de qualidade de modelo de fronteira (GPT-4o, Claude Opus 4) Sua equipe não tem expertise em GPU/MLOps Os requisitos de latência são rigorosos (TTFT <200ms) Você quer zero despesa operacional Sua carga de trabalho é variável ou sazonal Auto-hospede se... O volume mensal de saída excede consistentemente 200M tokens Privacidade de dados requer sem chamadas de API de terceiros Você precisa de modelos personalizados fine-tuned Você tem capacidade de MLOps na equipe A carga de trabalho é estado estável (utilização de GPU previsível) Você pode comprometer instâncias GPU reservadas de 1 ano Abordagem híbrida: o meio-termo pragmático A maioria das equipes acaba com um híbrido: use API para tarefas de raciocínio de fronteira e cargas baixas, auto-hospede modelos abertos para tarefas de alto volume e tolerantes a latência (geração de conteúdo, extração de dados, ferramentas internas). Isso mantém a despesa de API sob controle enquanto constrói capacidade de auto-hospedagem incrementalmente. Onde Executar Modelos Abertos Plataforma Opções de GPU Preço A100 80GB Preço H100 Inferência Gerenciada Lambda Cloud A100, H100, H200 $1,10/hora $2,49/hora Não (traga o seu próprio) RunPod A100, H100, L40S $1,19/hora $2,69/hora Opção sem servidor AWS (p4d/p5) A100, H100 $3,67/hora $6,37/hora SageMaker Google Cloud A100, H100 $3,22/hora $5,07/hora Vertex AI Xiaomi MiMO ↗ Baseado em API N/A N/A API ($0,50/$2,00 por 1M) Os preços de GPU são tarifas por hora sob demanda a partir de julho de 2026. Os preços reservados/spot variam significativamente. MiMO oferece acesso baseado em API a MiMo-V2-Pro e MiMo-V2-Omni a tarifas competitivas - um meio-termo entre auto-hospedagem completa e preços de API premium. Quer isso aplicado ao seu próprio gasto com LLM? FinOps LLM realiza uma auditoria gratuita de seus custos de IA e mostra onde estão as economias. Agendar auditoria gratuita → Voltar para pesquisa FAQ Qual é a metodologia? Tarifas padrão publicadas de cada página de preços do provedor. Sem descontos por volume ou lotes aplicados. GPU em nuvem para infraestrutura auto-hospedada usando preços sob demanda (Lambda, RunPod, AWS) com configurações otimizadas para inferência com vLLM ou TensorRT-LLM. Qual é a tabela de comparação de custos? Custo de API/mês assume 100M tokens de saída + 300M tokens de entrada por mês a tarifas padrão. Custo de auto-hospedagem inclui aluguel de GPU, despesas operacionais de 15% e infraestrutura de inferência (vLLM). Não inclui tempo de engenharia inicial. Quais são os fatores-chave de custo? Um nó 8x H100 para Llama 4 Maverick custa $2.000-$3.500/mês sob demanda de Lambda, RunPod ou AWS. Instâncias spot/preemptíveis podem reduzir isso 40-60% mas adicionam latência de reinicialização e risco de disponibilidade. Para cargas de trabalho de produção, instâncias reservadas (comprometimento de 1 ano) típicamente economizam 30-40% em relação ao sob demanda. Qual é a estrutura de decisão? A maioria das equipes acaba com um híbrido: usar API para tarefas de raciocínio de fronteira e cargas baixas, auto-hospedar modelos abertos para tarefas de alto volume e tolerantes a latência (geração de conteúdo, extração de dados, ferramentas internas). Onde executar modelos abertos? Os preços de GPU são tarifas por hora sob demanda a partir de julho de 2026. Os preços reservados/spot variam significativamente. MiMO oferece acesso baseado em API a MiMo-V2-Pro e MiMo-V2-Omni a tarifas competitivas - um meio-termo entre auto-hospedagem completa e preços de API premium. --- # Atribuição de custos da OpenAI · FinOps LLM URL: https://finopsllm.com/pt/research/openai-cost-attribution Atribuição de custos da OpenAI A atribuição de custos da OpenAI começa antes do envio da solicitação. A resposta da API pode indicar o uso de tokens, mas não consegue saber qual superfície de produto, equipe, cliente ou fluxo de trabalho empresarial causou a chamada a menos que sua aplicação anexe esse contexto. A atribuição deve combinar três fontes: metadados de solicitação, registros de uso e dados de fatura. Os metadados de solicitação fornecem a propriedade. Os registros de uso fornecem contagens de tokens e modelo. Os dados de fatura fornecem o total financeiro autoritário. Tags a capturar Nome da funcionalidade ou endpoint. Proprietário e ambiente da equipe. Cliente ou inquilino quando permitido. Classe de carga de trabalho, como realtime, batch, eval, suporte ou passo de agente. Versão do prompt, política de roteamento e status de fallback. Lacunas comuns na atribuição As equipes frequentemente perdem tentativas e fallbacks. Um usuário vê uma resposta, mas o sistema pode ter pago por várias chamadas upstream. Outra lacuna comum é o trabalho em lote: evals e trabalhos de enriquecimento devem ser marcados separadamente do tráfego voltado para o usuário para que possam ser movidos para faixas assincronizadas de menor custo. Os melhores relatórios de atribuição da OpenAI não param em "qual modelo custou mais". Eles mostram qual decisão de produto causou o uso desse modelo e qual proprietário pode alterá-lo. Relacionado Atribuição de custos de LLM - princípios gerais de atribuição. Atribuição de custos da Anthropic - atribuição para modelos da Anthropic. O que é FinOps de LLM? - a disciplina operacional completa. Quer que isto seja aplicado ao seu próprio gasto em LLM? FinOps LLM executa uma auditoria gratuita dos seus custos de IA e mostra onde se encontram as economias. Solicite sua auditoria gratuita → Voltar para pesquisa --- # Economia do Encerramento do Fine-Tuning da OpenAI · FinOps LLM URL: https://finopsllm.com/pt/research/openai-fine-tuning-sunset-economics Economia do Encerramento do Fine-Tuning da OpenAI Publicado 19 de julho de 2026 OpenAI está eliminando o fine-tuning de autoatendimento. A partir de 7 de maio de 2026, novas organizações não podem mais criar trabalhos de fine-tuning. Antes de 6 de janeiro de 2027, todas as organizações perdem essa capacidade. Se você depende de modelos GPT com fine-tuning, deve escolher uma rota de migração agora: engenharia de prompts em GPT-5.5 com cache de prompts, adaptadores LoRA de código aberto em Llama ou Qwen, ou fine-tuning gerenciado via Vertex AI, AWS Bedrock, ou Mistral. Cada rota tem trade-offs distintos de custo e operacionais. A criação de fine-tuning de autoatendimento termina em 6 de janeiro de 2027 para todas as organizações A inferência em modelos com fine-tuning existentes continua até a deprecação da base O cache de prompts em GPT-5.5 pode igualar ou superar o ROI do fine-tuning em 10–30 acertos LoRA de código aberto custa 30–50% menos do que serviços gerenciados para alto volume Custos ocultos de migração: reavaliações, testes de regressão, execução dual, retreinamento Prazo: As organizações devem se comprometer com uma rota de migração antes de 6 de janeiro de 2027. Os modelos com fine-tuning existentes continuarão servindo solicitações de inferência até que seu modelo base seja depreciado, mas você não pode criar novos trabalhos de treinamento após essa data. Cronograma e Matriz de Exposição Quem é afetado e quando: Data Fase Organizações Afetadas Ação Necessária 7 de maio de 2026 Fase 1 Novas organizações, nunca com fine-tuning antes Não podem iniciar novos trabalhos 2 de julho de 2026 Fase 2 Organizações existentes sem inferência de modelo com fine-tuning nos últimos 60 dias Não podem iniciar novos trabalhos 6 de janeiro de 2027 Fase 3 (final) Todas as organizações, até mesmo usuários ativos Nenhum novo trabalho de treinamento Pós-2027 Apenas inferência Todas as organizações com modelos com fine-tuning implantados A inferência continua até o encerramento da base Por que OpenAI está encerrando o fine-tuning: Modelos de classe GPT-5.5 combinados com cache de prompts eliminam a necessidade de fine-tuning na maioria dos casos de uso. Prompts mais longos com exemplos few-shot e instruções de sistema agora igualam ou superam o desempenho do fine-tuning, enquanto consomem menos tokens totais quando cacheados. As despesas gerais gerenciadas do fine-tuning excedem seu valor para a maioria das cargas de trabalho. Árvore de Decisão: Três Rotas de Migração Rota 1: Engenharia de Prompts + GPT-5.5 + Cache Reescreva a lógica com fine-tuning como prompt do sistema + exemplos few-shot, cacheados. Troca prompts mais longos por zero despesas de treinamento. Custo de treinamento: $0 (sem retreinamento) Custo de token por chamada: Prompt mais longo, mas cacheado a 50% da taxa fresca Tempo de configuração: 1–4 semanas (engenharia de prompts + benchmarking) Operações em andamento: Iteração de prompts, nenhuma MLOps necessária Rota 2: LoRA em Código Aberto (Together, Fireworks, Groq) Fine-tune Llama 4 ou Qwen 3.5 com adaptadores LoRA, hospede em inferência gerenciada. Controle total de fine-tuning, reprodutibilidade de código aberto. Custo de treinamento: $200–$500 por trabalho Custo de inferência: $0,10–$0,30/M tokens (competitivo) Tempo de configuração: 2–6 semanas (preparação de dados, treinamento de adaptador, testes) Operações em andamento: Monitore o desempenho do adaptador, retreine conforme necessário Rota 3: Fine-Tuning Gerenciado (Vertex, Bedrock, Mistral) Use Google Vertex AI, AWS Bedrock, ou fine-tuning da Mistral. Fluxo de trabalho familiar, suporte do fornecedor, mas custo por token mais alto. Custo de treinamento: $500–$2.000 por trabalho Custo de inferência: $0,20–$1,00/M tokens (premium) Tempo de configuração: 1–3 semanas (menos integrações necessárias) Operações em andamento: O fornecedor gerencia operações, você gerencia cadência de treinamento Rota 1: Engenharia de Prompts + Cache GPT-5.5 — Matemática Resolvida Suponha que você tivesse um modelo GPT-4 com fine-tuning para classificação de tickets de suporte ao cliente. O modelo com fine-tuning foi treinado em 10K tickets etiquetados. Cada solicitação envia ~500 tokens de entrada, recebe ~50 tokens de saída. Custo anterior (fine-tuning): Trabalho de fine-tuning: ~$50. Inferência em 100K chamadas/mês: (500 entrada × $3/M + 50 saída × $15/M) × 100K = $150/mês + treinamento = ~$200/mês tudo incluído. Custo novo (cache de prompts em GPT-5.5): Crie um prompt do sistema com 40 exemplos few-shot (cada um ~200 tokens) = 8K tokens. Este é o preenchimento de cache. Primeira chamada: 8K × (1,25× $3/M) + 500 × $3/M + 50 × $15/M ≈ $0,045. Chamadas subsequentes (acerto de cache): 500 × (0,5× $3/M) + 50 × $15/M ≈ $0,0015. Em 100K chamadas/mês, assuma 90% de acerto (90K acertos de cache). Custo: 10K chamadas × $0,045 + 90K chamadas × $0,0015 = $450 + $135 = $585/mês . Espera — isso é mais caro! Verdade se você não ajustar o prompt. Mas reduza os exemplos few-shot para 10 (2K tokens), e o custo cai para ~$280/mês. Além disso: se você pode agrupar consultas (processar 10 tickets relacionados em uma chamada), o custo por ticket cai outros 30%. Em conclusão: o cache de prompts em GPT-5.5 fica mais barato do que fine-tuning em 15–30 acertos de cache por contexto único. A maioria das equipes atinge isso em horas de implantação. Risco de qualidade: Prompts few-shot podem ter desempenho inferior ao fine-tuning em casos extremos e formatos incomuns. Orçamente 2–4 semanas para testes de regressão. Rota 2: LoRA em Código Aberto — Custos e Logística O fine-tuning de código aberto via LoRA (Low-Rank Adaptation) mantém o modelo base congelado e treina apenas pequenas matrizes de adaptador (~1–5% de parâmetros). Estrutura de custos: Componente Exemplo de Fornecedor Custo Notas Treinamento (Llama 3.3 70B em 10K amostras) Together AI $300 LoRA em GPU H100 único (~4 horas) Inferência (por 1M tokens) Groq (Llama 3.3 70B) $0,27 Rápido (sem atraso de ajuste vs GPT-4 com fine-tuning) Inferência (por 1M tokens) Together AI (Llama 3.3 70B) $0,18 Resposta mais lenta, custo mais baixo Hospedagem de modelo (mensal, sempre ativo) Hospedagem própria em runpod $300–$600 Aluguel de GPU A100 + despesas gerais de operações Total para 1M chamadas/mês — $318–$600 API Groq (gerenciada), sem custo de hospedagem Por que código aberto é mais barato: Sem prêmio por token para status "com fine-tuning". O adaptador é seu para distribuir e melhorar. A qualidade do modelo (Llama 4 Maverick) iguala GPT-4o para a maioria das tarefas a 30–50% menos custo. O trade-off: você possui a MLOps — cadência de retreinamento, detecção de desvio, testes A/B entre versões de adaptador. Risco de integração: Mudar da API OpenAI para Groq, Together, ou hospedagem própria altera sua latência de inferência, tratamento de erros e escala. Espere 1–2 semanas de trabalho de integração. Rota 3: Fine-Tuning Gerenciado (Vertex, Bedrock, Mistral) Fornecedor Custo de Treinamento (10K amostras) Custo de Inferência (por 1M tokens de saída) Modelo Base Tempo até Produção Google Vertex AI $500–$800 $0,40–$1,50 Gemini 1.5 Flash, outros modelos OS 1–2 semanas AWS Bedrock (Claude Sonnet com fine-tuning) $600–$1.200 $0,80–$2,00 Claude Sonnet, Llama 4, Mistral 1–2 semanas Fine-tuning da Mistral $400–$700 $0,25–$0,60 Mistral 3.5 Moe, outros modelos Mistral 1 semana Custo mensal típico (100K chamadas, 500 tokens médio) $600–$1.200 (treinamento único) $200–$1.000 (inferência recorrente) — — Serviços gerenciados são a rampa mais fácil: sua equipe já conhece autenticação de API, suporte do fornecedor está disponível, e você evita despesas gerais de MLOps. Mas custos de inferência executam 2–5× mais alto do que LoRA de código aberto. Esta rota faz sentido se: (1) você tem Comparação de Custos de Três Rotas (Carga de Trabalho Concreta) Carga de trabalho: IA de atendimento ao cliente para SaaS. 1M chamadas de inferência/mês, média 500 entrada + 150 tokens de saída por chamada. A equipe treinou um modelo com fine-tuning em 5K conversas etiquetadas. Componente de Custo Rota 1: Cache de Prompts + GPT-5.5 Rota 2: LoRA em Groq (Llama 3.3) Rota 3: Bedrock (Claude Sonnet FT) Configuração inicial / treinamento $0 (apenas eng. de prompts) $300 $1.000 Custo de inferência mensal (1M chamadas) $450–$600 $270 $900–$1.200 Total mensal (Ano 1) $450–$600 $600 (inclui treinamento amortizado) $1.900–$2.200 Total Ano 1 $5.400–$7.200 $3.600–$4.800 $12.000–$15.000 Rota 2 (LoRA) ganha em custo puro, mas requer tempo de MLOps para configurar e manter.** Rota 1 (cache de prompts) tem menor atrito se você aceita custos contínuos ligeiramente mais altos. Rota 3 (gerenciada) é escolhida apenas se SLAs empresariais ou operações sem intervenção forem obrigatórios. Custos Ocultos de Migração — Não Passe por Cima A tabela acima omite atrito operacional. Planeje: 1. Reavaliação e Benchmarking Meça a precisão, latência e custo do novo modelo no seu conjunto de testes retido. Orçamente: 2–3 semanas, $1K–$3K em tempo de engenharia. 2. Testes de Regressão Execute o modelo antigo com fine-tuning e a nova rota nas mesmas 100–1K consultas de produção. Meça lacunas de qualidade. Para sistemas voltados ao cliente, considere testes A/B (execução dual) durante 2–4 semanas. Custo de operações: $2K–$5K. 3. Período de Execução Dual Execute ambas as rotas antiga e nova em paralelo para detectar regressões em produção. Isso duplica o custo de inferência durante 2–4 semanas. Adiciona $500–$2.000 à sua conta de migração. 4. Mudanças no Fluxo de Treinamento Se você retreina regularmente (mensal, trimestral), fatore mudanças de scripting. Scripts de retreinamento de LoRA diferem da API OpenAI. Mistral, Vertex e Bedrock cada um têm diferentes APIs de treinamento. Orçamente: 1–2 semanas, $500–$1.500. 5. Desvio de Adaptador e Monitoramento Adaptadores de código aberto podem desviar se os dados de treinamento mudarem. Configure monitoramento de desempenho e acionadores de retreinamento. Para serviços gerenciados, o fornecedor trata isso mas cobra despesas gerais de monitoramento. Orçamente: recorrente +$200–$500/mês. Custo oculto total: $4K–$12K em tempo de engenharia + $500–$2.000 em operações de execução dual. A maioria das equipes subestima isso em 50%. Incorpore no seu plano de projeto. Estrutura de Decisão Escolha Rota 1 (Cache de Prompts + GPT-5.5) se: O volume de inferência mensal está abaixo de 100M tokens Sua carga de trabalho atual tem contextos repetidos (RAG, multi-turno) — alto potencial de acerto de cache Sua equipe não tem experiência MLOps e quer despesas gerais mínimas Você pode aceitar um trade-off de qualidade por simplicidade (a maioria das tarefas vê ≤5% regressão) Requisitos de latência são flexíveis (>500ms TTFT aceitável) Escolha Rota 2 (LoRA em Código Aberto) se: O volume de inferência mensal excede 200M tokens — vantagem de custo de 30–50% Sua equipe tem largura de banda MLOps para treinamento, monitoramento e retreinamento Você precisa de reprodutibilidade e quer controle total sobre o adaptador (vantagem de código aberto) A privacidade de dados requer nenhuma chamada para APIs proprietárias de OpenAI, Google ou AWS A latência é crítica ( Escolha Rota 3 (Fine-Tuning Gerenciado) se: Você precisa de SLAs empresariais, suporte do fornecedor, ou conformidade HIPAA/SOC 2 Sua equipe carece de experiência em infraestrutura e quer zero MLOps O volume mensal está abaixo de 50M tokens (o prêmio de custo é aceitável em escala baixa) Você já está investido no ecossistema do fornecedor (AWS, Google Cloud, Mistral) A frequência de treinamento é mensal ou menos (o custo de operações se amortiza melhor com pouca mudança) Leitura Relacionada Para mais contexto sobre o panorama de custos mais amplo, consulte Comparação de Custos de LLM de Código Aberto vs Fechado , que compara volumes de ponto de equilíbrio entre opções auto-hospedadas e API. Já rastreando seus custos de migração de fine-tuning? FinOps LLM audita seus gastos com LLM e identifica qual rota de migração economiza mais para você. Reserve uma auditoria gratuita . Voltar para pesquisa FAQ Quando não posso mais criar novos modelos com fine-tuning da OpenAI? Cronograma: 7 de maio de 2026 (novas organizações bloqueadas), 2 de julho de 2026 (organizações inativas 60 dias bloqueadas), 6 de janeiro de 2027 (todos os trabalhos novos bloqueados). A inferência em modelos com fine-tuning existentes continua até a deprecação do modelo base. O cache de prompts se equipara ao fine-tuning? Para prompts repetidos sobre o mesmo contexto: sim. O cache de prompts em GPT-5.5 custa $0,60/M para leituras vs $3,00/M frescos, e exemplos few-shot (prompts mais longos) podem ser cacheados eficientemente. O ponto de equilíbrio é tipicamente 10–30 acertos de cache dependendo do tamanho do prompt; a maioria das equipes o atinge em dias. LoRA de código aberto é mais barato do que fine-tuning gerenciado? Normalmente, sim. Custo de treinamento via Together AI: ~$200–$500 por trabalho. Inferência em Groq ou Fireworks: ~$0,10–$0,30/M tokens. O custo total por resposta bem-sucedida é frequentemente 30–50% mais baixo do que um serviço gerenciado, mas requer despesas gerais de MLOps. Quais custos ocultos não estou vendo durante a migração? Reavaliação (comparação da nova abordagem vs a anterior), testes de regressão (a rota de substituição entrega a mesma qualidade?), execução dual (executar ambas as rotas antiga e nova em paralelo por segurança), e retreinamento de adaptadores se o novo modelo mudar. Orçamente 4–8 semanas e ~$2K–$10K em tempo de engenharia por migração. --- # Os níveis de esforço do Opus 5.5 são o preço real · FinOps LLM URL: https://finopsllm.com/pt/research/opus-5-5-effort-level-cost Os níveis de esforço do Opus 5.5 são o preço real Atualizado September 22, 2026 · publicado originalmente September 22, 2026 Claude Opus 5.5 custa $4 por milhão de tokens de entrada e $20 por milhão de tokens de saída. Isso é 20% menos que Opus 5. A tarifa é apenas metade do custo total. A outra metade é a configuração effort , que decide quantos tokens o modelo gasta pensando antes de responder. Um modelo, cinco preços Opus 5.5 expõe esforço de low até medium , high , xhigh e max . Cada nível é o mesmo modelo com a mesma taxa por token, mas produz um número muito diferente de tokens. Análise independente reportada por The Decoder descobriu que quatro dos cinco níveis ficam na fronteira de Pareto custo-desempenho. Também descobriu que no máximo esforço Opus 5.5 usou cerca de 119.000 tokens de saída por tarefa, muito mais que modelos concorrentes em suas configurações máximas. A US$ 20 por milhão, 119.200 tokens de saída custam US$ 2,38 por tarefa antes de qualquer entrada. Em medium, a Artificial Analysis mediu 25.700 tokens de saída, ou US$ 0,51. Contando a entrada, max custa US$ 5,98 por tarefa e medium US$ 1,34: o mesmo modelo fica cerca de 4,5 vezes mais caro por tarefa por causa de um único parâmetro da requisição. Medido no Artificial Analysis Intelligence Index v4.3.2 (dez avaliações), consultado em 22 de setembro de 2026. Todas as linhas usam o mesmo conjunto de testes, por isso comparam-se diretamente. Modelo e esforço Intelligence Index Custo por tarefa Tokens de saída por tarefa Na fronteira custo–desempenho Opus 5.5 · low 42.3 $0.55 10,200 Não Opus 5.5 · medium 51.2 $1.34 25,700 Sim Opus 5.5 · high 53.6 $1.82 35,600 Sim Opus 5.5 · xhigh 56.0 $3.46 65,700 Sim Opus 5.5 · max 57.6 $5.98 119,200 Sim Opus 5 · high (referência) 48.1 $3.61 46,200 Não Fonte: Artificial Analysis. Na fronteira significa que nenhuma configuração de GPT-6 Sol, GPT-6 Astra, Opus 5, Opus 5.5 ou Fable 5.1 pontua mais por menos. O Opus 5.5 low fica de fora porque o GPT-6 Sol em xhigh pontua 44,1 por US$ 0,53. Passar de xhigh para max soma 1,6 ponto com 73% mais custo. Médio é a configuração que Anthropic usa para benchmarks A comparação principal da Anthropic é feita em esforço padrão, que é médio. Diz que Opus 5.5 em médio vence GPT-6 Astra em máximo esforço em trabalho de conhecimento por cerca de um quinto do custo por tarefa. Portanto, o próprio caso da Anthropic para o modelo é construído em médio, e máximo é a exceção. Uma equipe que define máximo em tudo "para estar seguro" paga por tokens que os benchmarks de lançamento não precisavam. Como configurar esforço sem adivinhar Padrão para médio. Faça-o um valor explícito no código, não um padrão de SDK que pode mudar sob você. Aumente o esforço por rota, não globalmente. Depuração difícil, planejamento de longo horizonte e etapas de revisão final podem justificar alto ou máximo. Classificação, extração e edições rotineiras raramente. Registre esforço com cada solicitação. Custo por solicitação não é interpretável sem ele. Um pico de gastos com contagem de solicitação plana é geralmente uma mudança de esforço. Compare níveis de esforço nas mesmas tarefas reproduzidas. Registre taxa de sucesso e tokens de saída por tarefa concluída em cada nível, e pare de aumentar esforço quando o sucesso parar de melhorar. Limite a saída onde o produto permitir. Um limite de tokens máximo limita o pior caso. No máximo esforço esse limite é a única coisa entre uma tarefa descontrolada e uma solicitação de vários dólares. O corte de $25 para $20 por milhão de tokens de saída economiza 20%. Mover uma carga de trabalho de máximo para esforço médio pode economizar muito mais que isso. Trate esforço como uma linha de orçamento, possuída e revisada como qualquer outra. Artigos relacionados Modelo de custo de Claude Opus 5.5 Economia do modo rápido Opus 5.5 Guia de custos do modelo de raciocínio Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Opus 5.5 fast mode: 2x preço para esperar menos · FinOps LLM URL: https://finopsllm.com/pt/research/opus-5-5-fast-mode-economics Economia do Opus 5.5 fast mode Atualizado September 22, 2026 · publicado originalmente September 22, 2026 Claude Opus 5.5 tem duas listas de preços. Padrão é $4 por milhão de tokens de entrada e $20 por milhão de saída. Fast mode é $8 e $40, exatamente o dobro, para até 2,5× a velocidade de saída. O modelo é o mesmo. O dinheiro extra compra tempo e mais nada, então a única pergunta é o tempo de quem. O que o prêmio compra Tome uma etapa que produz 5.000 tokens de saída. Às taxas padrão, o custo de saída é $0,10. Em fast mode custa $0,20. Se a etapa leva 60 segundos à velocidade padrão, uma aceleração de 2,5× a traz para cerca de 24 segundos. Você paga $0,10 extra para poupar 36 segundos. Isso resulta em cerca de $10 para cada hora de espera removida. O comprimento da etapa não altera o índice, pois o custo extra e o tempo economizado crescem com os tokens de saída. Depende de sua velocidade em modo padrão: este exemplo assume cerca de 83 tokens de saída por segundo. A entrada também dobra, então etapas com muito prefixo pagam um pouco mais por segundo economizado. Quando é barato Um desenvolvedor esperando em um agente de codificação interativo. A $10 por hora de espera removida, fast mode custa muito menos que o tempo de qualquer pessoa paga. Uma resposta voltada para o cliente onde latência afeta conversão. Avalie o speedup contra abandono, não contra a fatura de tokens. Um incidente, onde cada minuto tem um custo. Quando é puro desperdício Agentes em background, trabalhos noturnos e pipelines em lote. Ninguém está esperando, então o gasto extra não compra nada. Evals e replays. Essas são exatamente as cargas de trabalho que multiplicam contagens de tokens e rodam em um cronograma. Subagentes que executam em paralelo. O tempo de relógio é definido pelo ramo mais lento e pelo orquestrador, não por cada chamada. Opus 5.5 padrão já é cerca de 30% mais rápido que Opus 5, segundo Anthropic. Algumas reclamações de latência que teriam justificado fast mode em Opus 5 podem ser resolvidas apenas pela atualização. Meça a velocidade padrão antes de pagar por mais. Controles a colocar em prática Faça fast mode uma decisão explícita, por rota. Nunca deve ser um padrão global ou um sinalizador que um engenheiro ativou uma vez e esqueceu. Etiquete o gasto por modo. Uma solicitação de fast mode ao dobro do preço unitário parece uma solicitação normal em um painel que agrupa apenas por modelo. Alerte sobre a fração de fast mode dos tokens de saída. Se aumentar em rotas onde nenhum usuário está esperando, algo foi ativado que não deveria ter sido. Orçamento esforço e velocidade juntos. Esforço máximo multiplica a contagem de tokens, e fast mode dobra o preço de cada token. É a forma mais cara de executar o modelo. Artigos relacionados Modelo de custo Claude Opus 5.5 Níveis de esforço do Opus 5.5 são o preço real Limites de fan-out e concorrência de subagentes Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Ox Alpha era o GLM-5.3: o custo do grátis · FinOps LLM URL: https://finopsllm.com/pt/research/ox-alpha-was-glm-5-3 O Ox Alpha era o GLM-5.3 Atualizado September 1, 2026 · publicado originalmente September 1, 2026 Resposta rápida: Entre 20 e 26 de agosto de 2026, o OpenRouter serviu gratuitamente um modelo chamado stealth/ox-alpha. Foi depois identificado como GLM-5.3-Flash: 320 mil milhões de parâmetros no total, 18 mil... Entre 20 e 26 de agosto de 2026, o OpenRouter serviu gratuitamente um modelo chamado stealth/ox-alpha . Foi depois identificado como GLM-5.3-Flash: 320 mil milhões de parâmetros no total, 18 mil milhões activos, atenção híbrida linear e esparsa, entrada nativa de texto, imagem e vídeo, contexto de 1.048.576 tokens e pesos com licença MIT. A adesão não foi marginal: em três dias, o OpenCode reportou cerca de 16 biliões de tokens processados, 221.000 utilizadores únicos e mais de cinco milhões de sessões. É tráfego de produção e, durante seis dias, não custou nada. Grátis é uma tarifa, não uma ausência A telemetria de custo trata uma linha de 0 dólares como se não existisse. Esse tráfego não pesa em previsões nem em alertas de orçamento. Quando a janela fecha e passa a haver tarifa, o mesmo tráfego surge como um degrau que ninguém modelou. Aplique um preço-sombra a cada chamada gratuita: registe os tokens e multiplique pelo preço de tabela do modelo que usaria em alternativa. O painel passa a mostrar o valor mensal da promoção e a fatura no dia em que terminar. A tarifa já não é hipotética: o GLM-5.3-Flash custa 0,15 dólares por milhão de tokens de entrada e 0,50 de saída. Dezasseis biliões de tokens de entrada a esse preço são cerca de 2,4 milhões de dólares — o valor de seis dias grátis e a altura do degrau se esse tráfego ficar. Três exposições a verificar Precipício tarifário: quanto custa este tráfego amanhã a preço de tabela? Deriva de identidade: que modelo está por trás do alias esta semana? Acoplamento de qualidade: os prompts foram afinados para um modelo que não pode manter? Fixe identificadores de modelo e avalie o substituto antes do fim da janela. Os pesos MIT mudam a conta Com licença MIT, alojar internamente é uma opção real. Com 18 mil milhões de parâmetros activos, o custo de serviço aproxima-se de um modelo denso médio, mas só com utilização alta e sustentada. Abaixo de 40 a 50% de utilização de GPU, a API costuma ganhar: um acelerador parado factura na mesma, uma chamada que não acontece não factura nada. Artigos relacionados Custo de modelos abertos e fechados Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Como pôr preço num modelo que não tem preço · FinOps LLM URL: https://finopsllm.com/pt/research/pricing-an-open-weight-model Preço de um modelo de pesos abertos Atualizado September 1, 2026 · publicado originalmente September 1, 2026 Resposta rápida: O Qwen3.8-Flash-Next chegou a 26 de agosto de 2026 como pré-visualização de pesos abertos da arquitetura Qwen4: cerca de 6 mil milhões de parâmetros ativos, contexto nativo de 262 144 tokens e nenhuma... O Qwen3.8-Flash-Next chegou a 26 de agosto de 2026 como pré-visualização de pesos abertos da arquitetura Qwen4: cerca de 6 mil milhões de parâmetros ativos, contexto nativo de 262 144 tokens e nenhuma tarifa alojada anunciada. A comparação habitual deixa de funcionar: um modelo fechado dá um preço por milhão de tokens; pesos abertos dão um checkpoint e deixam a conta consigo. A fórmula custo por MTok = preço_hora / (tokens_por_segundo * 3600) * 1 000 000 A 2,00 $ por hora e 1500 tokens por segundo medidos, dá 0,37 $ por milhão de tokens . Face a uma API a 3,00 $/MTok parece uma poupança de oito vezes. Também está errado, porque assume que a GPU trabalha em cada segundo que paga. O termo esquecido: a utilização Aluga a hora e usa uma fração dela. Divida por essa fração: 0,62 $ a 60%, 1,23 $ a 30%, 3,70 $ a 10% — mais caro do que a API que ia substituir. A maioria das primeiras implementações fica entre 10% e 30%, porque o tráfego é irregular e a instância é dimensionada para o pico. A poupança é real, mas vem da utilização, não dos pesos. Meça antes de decidir Execute o modelo na instância que alugaria mesmo, com os seus prompts e comprimentos de contexto, e registe tokens por segundo em concorrência — não o valor de fluxo único do cartão do modelo. Depois calcule a utilização com o seu perfil real de tráfego. Dois números, uma divisão, e a decisão faz-se sozinha. Ponha preço ao contexto que envia, não ao que o modelo suporta. Artigos relacionados Custo de modelos abertos e fechados Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Provar o ROI de IA sem esconder falhas · FinOps LLM URL: https://finopsllm.com/pt/research/prove-ai-roi-measurement Provar o ROI de IA sem esconder falhas Atualizado August 27, 2026 · publicado originalmente August 27, 2026 Resposta rápida: O ROI da IA não se prova apenas com uma fatura menor. Prova-se quando o resultado de negócio melhora mais do que o custo total para o produzir. Ligue despesa atribuível, resultado bem-sucedido e... O ROI da IA não se prova apenas com uma fatura menor. Prova-se quando o resultado de negócio melhora mais do que o custo total para o produzir. Ligue despesa atribuível, resultado bem-sucedido e controlo de qualidade. Defina o contrafactual Explique o que aconteceria sem a mudança: trabalho humano, modelo anterior ou fluxo anterior. Use un período ou coorte comparável. Meça o resultado Use custo por tarefa bem-sucedida, não por pedido. Defina sucesso de forma observável e inclua retries, ferramentas, reparação humana e avaliações. Proteja a qualidade Mostre taxa de sucesso, erros, latência e aceitação. Poupança com pior produto não é ROI. Artigos relacionados Custo por tarefa bem-sucedida Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Comparar preços de fornecedores IA · FinOps LLM URL: https://finopsllm.com/pt/research/provider-prices-not-comparable Comparar preços de fornecedores IA Atualizado August 27, 2026 · publicado originalmente August 27, 2026 Resposta rápida: Comparar o preço anunciado por milhão de tokens cria poupanças falsas. As unidades, descontos e qualidades diferem. Compare o custo efetivo por tarefa bem-sucedida com a mesma carga e... Comparar o preço anunciado por milhão de tokens cria poupanças falsas. As unidades, descontos e qualidades diferem. Compare o custo efetivo por tarefa bem-sucedida com a mesma carga e qualidade. Normalize a fatura Use uma tabela por fornecedor, modelo, região, tipo de token, cache, batch e data. Separe entrada, saída, cache, raciocínio, imagem, áudio e ferramentas. Normalize a carga Reproduza os mesmos prompts, contextos e testes de sucesso. Meça latência p50/p95, conclusão, retries, reparação humana e qualidade. Inclua a operação Some gateway, observabilidade, routing, avaliação e suporte. Encaminhe para o fornecedor mais barato que cumpra qualidade e custo efetivo. Artigos relacionados Arbitragem entre fornecedores LLM Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Rate limits são controlo de custo · FinOps LLM URL: https://finopsllm.com/pt/research/rate-limits-are-cost-control Rate limits, 429 e subidas de tier Atualizado September 1, 2026 · publicado originalmente September 1, 2026 Resposta rápida: Quando um serviço começa a devolver 429, o reflexo é tratá-lo como incidente de disponibilidade: subir o limite, subir de tier, acrescentar repetições. Às vezes é correto. É também o mecanismo pelo... Quando um serviço começa a devolver 429, o reflexo é tratá-lo como incidente de disponibilidade: subir o limite, subir de tier, acrescentar repetições. Às vezes é correto. É também o mecanismo pelo qual um ciclo descontrolado vira uma fatura de cinco dígitos, porque acabou de remover a única coisa que o travava. O que um 429 está a dizer Que o sistema tenta gastar mais depressa do que a sua alocação. Por duas razões opostas: crescimento real da procura, em que o limite ficou curto, ou descontrolo — tempestade de repetições, agente em ciclo, backfill sem throttle — em que o limite está a fazer exatamente o seu trabalho. A taxa de erro não os distingue. O custo por tarefa concluída distingue: o crescimento real mantém a proporção, o descontrolo parte-a. Use limites de propósito Defina limites próprios abaixo dos do fornecedor, por ambiente e por funcionalidade. Limite com força o que não é produção. Alerte sobre o custo por tarefa, não só sobre erros. Artigos relacionados Gasto oculto em repetições Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Re-embeber o corpus é recorrente · FinOps LLM URL: https://finopsllm.com/pt/research/re-embedding-is-recurring O custo recorrente de embeddings e vector stores Atualizado September 1, 2026 · publicado originalmente September 1, 2026 Resposta rápida: O custo de embeddings é aprovado como rubrica de projeto: uns milhões de documentos, uma execução única, um número pequeno ao lado da geração. Depois nunca mais para, porque três forças distintas... O custo de embeddings é aprovado como rubrica de projeto: uns milhões de documentos, uma execução única, um número pequeno ao lado da geração. Depois nunca mais para, porque três forças distintas voltam a embeber o que já pagou. Os três motores de refrescamento Rotação de conteúdo : o mais honesto e o mais pequeno, acompanha o negócio e prevê-se bem. Mudanças de chunking ou pipeline : o traiçoeiro. Qualquer ajuste de tamanho de chunk, sobreposição ou pré-processamento invalida todos os vetores. Uma experiência de qualidade de recuperação que parece um ajuste de config é um re-embed completo. Mudanças de modelo : o grande. Os espaços de embedding não são compatíveis entre modelos — não há migração parcial: ou mantém dois stores em paralelo ou aceita indisponibilidade. Orçamente como anuidade Preveja pelo menos um re-embed completo por ano. Avalie um modelo pelo custo de re-embed mais um ano de armazenamento e consultas , não pelo preço por token. E corra esses jobs em batch: é a carga mais tolerante a latência que tem. Artigos relacionados Otimização de custos de RAG Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Custo real por tarefa: Opus 5.5 vs Sol, Astra e Fable · FinOps LLM URL: https://finopsllm.com/pt/research/real-cost-per-task-frontier-models Custo real por tarefa nos modelos de fronteira Atualizado September 22, 2026 · publicado originalmente September 22, 2026 Preços de tabela dizem quanto custa um token. Não dizem quanto custa uma tarefa concluída, porque os modelos gastam quantidades muito diferentes de tokens para fazer o mesmo trabalho. Esta página coloca lado a lado o custo por tarefa medido e uma pontuação de qualidade para Claude Opus 5.5, Claude Opus 5, Claude Fable 5.1, GPT-6 Astra e GPT-6 Sol em cada nível de esforço. Todo número tem fonte e nada é estimado. A resposta curta: o GPT-6 Sol é o jeito mais barato de chegar a qualquer pontuação até 47,5. Acima de 47,5, o Opus 5.5 é o mais barato em todos os níveis. Nenhuma configuração do GPT-6 Astra acima de low, do Opus 5 ou do Fable 5.1 é eficiente em custo: cada uma perde em pontuação e em preço para alguma configuração do Sol ou do Opus 5.5. Método Todas as pontuações e custos vêm do Artificial Analysis Intelligence Index v4.3.2, consultado em 22 de setembro de 2026. O índice roda dez avaliações: AA-Briefcase, GDPval-AA, AutomationBench-AA, Terminal-Bench 4.0, SciCode, Humanity's Last Exam, GDP.pdf, CritPt, AA-Omniscience e AA-LCR. A Artificial Analysis roda cada modelo em cada nível de esforço pela API do fornecedor e registra quanto paga a preço de tabela. O custo por tarefa é esse gasto por tarefa, dividido em entrada e saída. Todas as linhas rodam a mesma suíte, então se comparam diretamente. Há dois limites antes de ler os números. Primeiro, o índice é uma única mistura de tarefas. A sua mistura vai mudar os custos, e por isso a última seção explica como medir os seus. Segundo, pontuações de versões diferentes do índice não se comparam, então não misture estes números com resultados publicados antes. A escala completa: 26 configurações Tokens de saída por tarefa são os tokens que o modelo escreve, incluindo o raciocínio. A Artificial Analysis não publica a divisão entre entrada e saída para as quatro configurações intermediárias do GPT-6 Sol, por isso essas células mostram n/a. Modelo Esforço Intelligence Index Custo por tarefa Custo de entrada Custo de saída Tokens de saída por tarefa Na fronteira GPT-6 Sol none 28.1 $0.33 $0.28 $0.05 4,900 Não GPT-6 Sol low 33.9 $0.13 n/a n/a 3,400 Sim GPT-6 Sol medium (padrão) 39.8 $0.25 n/a n/a 6,500 Sim GPT-6 Sol high 42.8 $0.37 n/a n/a 10,200 Sim GPT-6 Sol xhigh 44.1 $0.53 n/a n/a 16,000 Sim GPT-6 Sol max 47.5 $1.06 $0.74 $0.31 31,200 Sim GPT-6 Astra low 45.8 $0.82 $0.60 $0.22 4,400 Sim GPT-6 Astra medium 49.6 $1.54 $1.06 $0.48 9,600 Não GPT-6 Astra high 50.9 $1.73 $1.13 $0.59 11,800 Não GPT-6 Astra xhigh 52.4 $2.31 $1.46 $0.85 16,900 Não GPT-6 Astra max 52.7 $3.26 $1.90 $1.36 27,200 Não Claude Opus 5 low 39.4 $1.10 $0.73 $0.37 14,700 Não Claude Opus 5 medium 44.8 $2.19 $1.47 $0.72 29,000 Não Claude Opus 5 high (padrão) 48.1 $3.61 $2.46 $1.16 46,200 Não Claude Opus 5 xhigh 49.7 $4.88 $3.36 $1.52 60,700 Não Claude Opus 5 max 50.8 $5.86 $4.05 $1.81 72,500 Não Claude Opus 5.5 low 42.3 $0.55 $0.35 $0.20 10,200 Não Claude Opus 5.5 medium (padrão) 51.2 $1.34 $0.82 $0.51 25,700 Sim Claude Opus 5.5 high 53.6 $1.82 $1.11 $0.71 35,600 Sim Claude Opus 5.5 xhigh 56.0 $3.46 $2.15 $1.31 65,700 Sim Claude Opus 5.5 max 57.6 $5.98 $3.60 $2.38 119,200 Sim Claude Fable 5.1 low 46.8 $2.37 $1.30 $1.08 21,600 Não Claude Fable 5.1 medium 48.9 $2.98 $1.59 $1.39 27,900 Não Claude Fable 5.1 high 51.2 $3.91 $2.01 $1.90 38,100 Não Claude Fable 5.1 xhigh 53.2 $5.98 $2.96 $3.02 60,500 Não Claude Fable 5.1 max 53.4 $7.63 $3.73 $3.90 78,100 Não Na fronteira significa que nenhuma outra configuração desta tabela pontua mais por menos dinheiro. A fronteira de custo Dez das 26 configurações estão na fronteira. Ordenadas por custo, são as únicas que valem a pena considerar só pelo preço. Todas as outras pagam mais pela mesma pontuação ou por uma menor. Configuração Intelligence Index Custo por tarefa Por 10.000 tarefas GPT-6 Sol · low 33.9 $0.13 $1,300 GPT-6 Sol · medium 39.8 $0.25 $2,500 GPT-6 Sol · high 42.8 $0.37 $3,700 GPT-6 Sol · xhigh 44.1 $0.53 $5,300 GPT-6 Astra · low 45.8 $0.82 $8,200 GPT-6 Sol · max 47.5 $1.06 $10,600 Claude Opus 5.5 · medium 51.2 $1.34 $13,400 Claude Opus 5.5 · high 53.6 $1.82 $18,200 Claude Opus 5.5 · xhigh 56.0 $3.46 $34,600 Claude Opus 5.5 · max 57.6 $5.98 $59,800 A fronteira tem duas regiões. De US$ 0,13 a US$ 1,06 é quase só GPT-6 Sol, com o GPT-6 Astra low como única exceção, a US$ 0,82. De US$ 1,34 para cima é só Opus 5.5. O salto entre as duas é pequeno: o Opus 5.5 medium pontua 3,7 pontos a mais que o Sol max por US$ 0,28 a mais por tarefa. Frente a frente com pontuação igual ou melhor Cada par compara uma configuração mais barata com uma mais cara que pontua igual ou menos. Configuração mais barata Configuração mais cara Diferença de pontuação Economia Opus 5.5 medium: 51.2, $1.34 Opus 5 high: 48.1, $3.61 +3.1 para Opus 5.5 63% Opus 5.5 medium: 51.2, $1.34 Opus 5 max: 50.8, $5.86 +0.4 para Opus 5.5 77% Opus 5.5 medium: 51.2, $1.34 Fable 5.1 high: 51.2, $3.91 empate 66% Opus 5.5 high: 53.6, $1.82 GPT-6 Astra max: 52.7, $3.26 +0.9 para Opus 5.5 44% Opus 5.5 high: 53.6, $1.82 Fable 5.1 max: 53.4, $7.63 +0.2 para Opus 5.5 76% GPT-6 Sol max: 47.5, $1.06 Opus 5 high: 48.1, $3.61 +0.6 para Opus 5 71% A linha do Opus 5 importa para equipes que ainda não migraram. O Opus 5 rodava por padrão em esforço high. O Opus 5.5 roda por padrão em medium e, nesse padrão, pontua 3,1 pontos a mais por 63% menos por tarefa. A Anthropic diz que o Opus 5.5 é 40% mais barato que o Opus 5; a diferença medida neste índice é maior que a promessa. Para onde vai o dinheiro: entrada, não saída Em todos os modelos, a entrada fica entre metade e três quartos do custo por tarefa. No Opus 5.5 medium, US$ 0,82 dos US$ 1,34 são entrada, ou 61%. No GPT-6 Astra max são 58%, no GPT-6 Sol max 70% e no Fable 5.1 max 49%. Tarefas de agente reenviam o contexto crescente a cada passo, então o gasto com entrada cresce com o número de passos, não só com o tamanho da resposta. É por isso que o GPT-6 Sol sem raciocínio custa mais que em low: US$ 0,33 contra US$ 0,13, embora escreva só 4.900 tokens de saída. US$ 0,28 dos US$ 0,33 são entrada. A causa provável são mais passos, cada um reenviando o contexto. Desligar o raciocínio não barateia um agente se ele depois precisa de mais turnos. Para a sua fatura, isso significa que o cache importa tanto quanto a escolha do modelo. Opus 5.5 e GPT-6 Sol cobram US$ 0,20 por milhão de tokens de entrada em cache. O GPT-6 Astra cobra US$ 1,00 e o Opus 5 cobra US$ 0,50. Volume de tokens contra preço de tabela O GPT-6 Astra é o modelo mais econômico em tokens aqui. Em esforço max ele escreve 27.200 tokens de saída por tarefa, contra 119.200 do Opus 5.5 max. Mas o Astra cobra US$ 10 e US$ 50 por milhão, 2,5× a tarifa do Opus 5.5. O preço de tabela vence: o Opus 5.5 high custa US$ 1,82 por tarefa e pontua 53,6, enquanto o Astra max custa US$ 3,26 e pontua 52,7. O Opus 5.5 max é o único ponto onde a verbosidade pesa. Seus 119.200 tokens de saída custam US$ 2,38 antes de qualquer entrada, e a tarefa inteira custa US$ 5,98. Isso compra a maior pontuação da tabela, 57,6, mas por 4,5× o custo do medium. Retornos decrescentes por esforço Cada linha mostra o que um nível a mais de esforço compra, em pontos de índice contra o custo extra por tarefa. Modelo medium → high xhigh → max GPT-6 Sol +3.0 pontos por +48% +3.4 pontos por +100% GPT-6 Astra +1.3 pontos por +12% +0.3 pontos por +41% Claude Opus 5 +3.3 pontos por +65% +1.1 pontos por +20% Claude Opus 5.5 +2.4 pontos por +36% +1.6 pontos por +73% Claude Fable 5.1 +2.3 pontos por +31% +0.2 pontos por +28% No Fable 5.1 e no GPT-6 Astra, o esforço max quase não compra nada: 0,2 e 0,3 ponto por 28% e 41% a mais. No Opus 5.5, subir para max ainda compra 1,6 ponto, mas custa 73% a mais. Use max só em tarefas onde você mediu que os pontos extras mudam o resultado. Quando o GPT-6 Sol max basta O índice é uma média, e a diferença entre o Sol max e o Opus 5.5 medium não é uniforme. Pontuações por avaliação da Artificial Analysis: Avaliação Opus 5.5 medium ($1.34) GPT-6 Sol max ($1.06) Terminal-Bench 4.0 52.5 43.9 AutomationBench-AA 61.2 61.6 GDPval-AA (Elo) 1576 1487 AA-Briefcase (Elo) 1642 1483 Humanity's Last Exam 54.7 47.9 SciCode 59.3 57.6 CritPt 27.7 30.9 AA-LCR 84.3 83.7 Em AutomationBench e CritPt, o GPT-6 Sol empata ou supera o Opus 5.5 medium por US$ 1,06 por tarefa contra US$ 1,34. Em Terminal-Bench, nas avaliações de trabalho do conhecimento e no Humanity's Last Exam, o Opus 5.5 lidera com folga. Automação de fluxos de trabalho pode rodar no Sol. Agentes de terminal e de código e trabalho do conhecimento com muitos documentos são onde o Opus 5.5 justifica o preço. Números do fornecedor contra números independentes Números de fornecedor e números independentes costumam divergir, porque usam outros harnesses e outras configurações. A Anthropic informa 66,4% no Terminal-Bench 4.0 para o Opus 5.5 em xhigh. A Artificial Analysis mede 59,6% no mesmo esforço. Esforço Opus 5.5 Fable 5.1 low 31.3% 40.4% medium 52.5% 44.9% high 56.6% 52.0% xhigh 59.6% 55.1% max 59.6% 52.0% O ranking também muda com o índice. No Vals AI Index, o Fable 5.1 é o primeiro com 68,83%, o GPT-6 Astra o terceiro com 66,61% e o Opus 5.5 o quarto com 66,16%. Lá o custo por tarefa não é publicado na mesma base, então isso não mexe na fronteira acima. É um lembrete de que um índice é só uma visão. Preços de tabela e uma tarefa com muito cache A Digital Applied calculou o preço de uma tarefa de agente com muito cache em cada modelo: 8M tokens de leitura de cache, 400K de entrada sem cache, 600K de escrita em cache e 300K de saída. O resultado segue a fronteira, com uma penalidade extra para o GPT-6 Astra. Modelo Entrada $/MTok Saída $/MTok Leitura de cache $/MTok Tarefa com muito cache (Digital Applied) GPT-6 Sol $2.00 $10.00 $0.20 $6.90 Claude Opus 5.5 $4.00 $20.00 $0.20 $12.20 Claude Opus 5 $5.00 $25.00 $0.50 $17.25 Claude Fable 5.1 $10.00 $50.00 $0.25 $28.50 GPT-6 Astra (≤272K) $10.00 $50.00 $1.00 $34.50 GPT-6 Astra (>272K) $20.00 $75.00 n/a $61.50 O GPT-6 Astra cobra a requisição inteira a US$ 20 e US$ 75 por milhão quando a entrada passa de 272K tokens. O Opus 5.5 mantém um único preço em toda a janela de 1M tokens. No Opus 5.5, escrever no cache custa US$ 5 por milhão no cache de 5 minutos e US$ 8 no de 1 hora, lotes são cobrados a 50% e o modo rápido dobra o preço. Para os detalhes, veja o Modelo de custos do Claude Opus 5.5 e a Economia do modo rápido do Opus 5.5 . Como medir o seu próprio custo por tarefa Registre tokens por tarefa, não por requisição: entrada sem cache, entrada em cache, escritas em cache e saída, somados em todos os passos da tarefa. Pegue uma amostra de algumas centenas de tarefas reais e rode de novo em duas ou três configurações candidatas, por exemplo Sol max, Opus 5.5 medium e Opus 5.5 high. Avalie cada resultado com a mesma verificação que você usa em produção e conte as tarefas aprovadas. Divida o gasto total pelas tarefas aprovadas. O custo por tarefa bem-sucedida é o número a comparar, porque uma configuração barata que falha mais não é barata. Escolha a configuração mais barata que atinge sua régua de qualidade e mande só as tarefas que falham para uma configuração mais alta. Refaça o teste quando um preço ou um esforço padrão mudar. Para ver como o esforço muda a fatura de um mesmo modelo, veja Os níveis de esforço do Opus 5.5 são o preço real . Ressalvas Todos os custos são a preço de tabela da API sobre a mistura de tarefas da Artificial Analysis. Descontos, lotes e o seu próprio cache mudam esses valores. A Artificial Analysis marca as entradas do Opus 5.5 e do Fable 5.1 como Default Fallback. Leia as notas de metodologia antes de tratar todas as linhas como a mesma configuração de API. As pontuações são só da versão v4.3.2 do índice. Versões anteriores usavam outras avaliações e não se comparam. A tarefa com muito cache da Digital Applied é uma carga ilustrativa, não uma medição. Os números mudam quando os fornecedores mudam preços ou padrões. A data de consulta é 22 de setembro de 2026. Fontes Artificial Analysis Intelligence Index Artificial Analysis: Claude Opus 5.5 Artificial Analysis: Claude Opus 5 Artificial Analysis: Claude Fable 5.1 Artificial Analysis: GPT-6 Astra Artificial Analysis: GPT-6 Sol Digital Applied: GPT-6 Sol vs Claude Opus 5.5 cost benchmarks Digital Applied: Claude Opus 5.5 vs GPT-6 Astra Digital Applied: Is Claude Fable 5.1 still worth it? Digital Applied: Claude Opus 5.5 launch pricing and benchmarks Digital Applied: Opus 5.5 vs Grok 4.7 vs Muse Spark 1.3 cost per task Artigos relacionados Modelo de custos do Claude Opus 5.5 Os níveis de esforço do Opus 5.5 são o preço real Economia do modo rápido do Opus 5.5 Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Guia de Custos de Modelos de Raciocínio · FinOps LLM URL: https://finopsllm.com/pt/research/reasoning-model-cost-guide Guia de Custos de Modelos de Raciocínio Atualizado 15 de julho de 2026 · publicado pela primeira vez em 4 de julho de 2026 Modelos de raciocínio como o3, o4-mini, DeepSeek-R1, QwQ e MiMo geram tokens de "pensamento" internos antes de produzir saída. Este custo oculto pode inflacionar sua fatura 5-30x. Este guia decompõe quando os modelos de raciocínio valem o prêmio e quando um modelo padrão é o gasto mais inteligente. 5-30x Multiplicador de custo 10 Modelos comparados 4 Provedores Jul 2026 Última atualização Todos os preços em USD por 1 milhão de tokens Contagens de tokens de raciocínio variam por complexidade de tarefa Tokens de pensamento são faturados como tokens de saída Quais são os tokens de "pensamento"? Modelos de raciocínio gastam tokens em cadeia de pensamento interna antes de responder. Uma pergunta simples pode desencadear 2.000 tokens de pensamento; uma tarefa complexa de codificação pode produzir 30.000+. Esses tokens são invisíveis na resposta da API mas são faturados a taxas de saída - frequentemente o nível mais caro. Metodologia Preços padrão Preço do token de saída para conclusão padrão (sem raciocínio), a partir de páginas oficiais do provedor. Preço de raciocínio Custo efetivo incluindo tokens de pensamento. Medido como preço de saída padrão × multiplicador de pensamento médio para cada modelo. Multiplicador de pensamento Proporção média de tokens totais faturados para tokens de saída visíveis entre avaliações de codificação, matemática e análise. Melhores casos de uso Tarefas onde modelos de raciocínio demonstram superioridade sobre modelos padrão o suficiente para justificar o prêmio de custo. Tabela de Preços de Modelos de Raciocínio Modelo ↕ Provedor ↕ Saída Padrão $/1M ↕ Saída Raciocínio $/1M ↕ Multiplicador ↕ Melhores Casos de Uso Claude Fable 5 Anthropic $50.00 $200.00 4x Raciocínio fronteiriço, vulnerabilidades complexas de software, análise profunda Claude Opus 4.8 Anthropic $25.00 $100.00 4x Raciocínio fronteiriço, análise complexa, fluxos de trabalho agênticos GPT-5.6-Sol OpenAI $30.00 $120.00 4x Raciocínio fronteiriço, código complexo, matemática, análise em múltiplas etapas GPT-5.6-Terra OpenAI $15.00 $60.00 4x Raciocínio, geração de código, análise estruturada Grok 4.5 xAI $6.00 $24.00 4x Matemática, raciocínio, inteligência geral o3 OpenAI $8.00 $40.00 5x Codificação complexa, provas matemáticas, raciocínio profundo o4-mini OpenAI $4.40 $17.60 4x Raciocínio sensível a custos, codificação, análise DeepSeek R1 DeepSeek $2.19 $8.76 4x Matemática, código, raciocínio, tarefas em idioma chinês Claude Sonnet 5 Anthropic $10.00 $40.00 4x Raciocínio geral, codificação, análise (balanceado) GPT-5.5 (padrão) OpenAI $30.00 $30.00 1x Chat geral, codificação, análise complexa Quando Usar Modelos de Raciocínio 1) Codificação e depuração em múltiplas etapas Modelos de raciocínio se destacam em tarefas que exigem planejamento: refatorar em múltiplos arquivos, depurar estado complexo, ou escrever algoritmos com casos extremos. Os tokens de pensamento permitem ao modelo "trabalhar" o problema em vez de simples correspondência de padrões. Vale a pena o prêmio de 4-5x quando a alternativa é um humano gastando 30+ minutos. 2) Provas matemáticas e lógicas Tarefas que exigem raciocínio formal - provas, problemas de otimização, satisfação de restrições - veem o maior salto de qualidade. Modelos padrão frequentemente produzem respostas plausíveis mas incorretas; modelos de raciocínio se auto-verificam. O prêmio de custo é justificado quando a correção importa mais que a velocidade. 3) Análise de dados complexa com múltiplas etapas Analisar um conjunto de dados com lógica condicional, referência cruzada de múltiplas fontes, ou construção de pipelines em múltiplas etapas se beneficia de cadeia de pensamento. Um modelo padrão pode perder um passo; um modelo de raciocínio trabalha através de cada um explicitamente. Quando Evitar Modelos de Raciocínio 1) Extração e formatação simples Extrair dados de documentos, reformatar JSON, resumir texto, ou traduzir conteúdo. Essas tarefas precisam de correspondência de padrões, não de raciocínio. Usar o3 para extração é como contratar um matemático para classificar correspondência - caro e desnecessário. 2) Cargas de trabalho de alto volume e baixa complexidade Geração de conteúdo, respostas de FAQ, respostas básicas de chatbot, e rotulagem de dados. Com 10M+ tokens/mês, o multiplicador de raciocínio de 4-5x se acumula rapidamente. Um modelo padrão a $10/1M de saída vence um modelo de raciocínio a $40-60/1M para tarefas onde a qualidade é "suficientemente boa". 3) Aplicações sensíveis a latência Modelos de raciocínio levam mais tempo - tokens de pensamento adicionam 2-10 segundos de latência. Para chat em tempo real, ferramentas interativas, ou respostas orientadas ao usuário onde a velocidade importa, modelos padrão entregam mais rápido com custo menor. Estratégias de Otimização de Custos Roteamento por complexidade Use um modelo padrão barato (GPT-4o-mini, Gemini Flash) como roteador. Se a tarefa é simples, responda diretamente. Se for complexa, escale para um modelo de raciocínio. Este padrão "cascata" pode reduzir uso de modelos de raciocínio em 60-80% preservando qualidade onde importa. Limite o orçamento de pensamento Alguns provedores (OpenAI, Google) permitem definir um orçamento máximo de tokens de pensamento por solicitação. Limitar a 4.000-8.000 tokens de pensamento previne custos descontrolados em tarefas que não precisam de raciocínio profundo. Comece justo e aumente apenas quando a qualidade cair. Armazene em cache seus prompts Se suas tarefas de raciocínio compartilham um prompt de sistema comum ou contexto (base de código, documentação), o armazenamento em cache de prompts pode reduzir custos de entrada em 50-90%. Isso não reduz tokens de pensamento mas reduz significativamente o custo por solicitação. Processe raciocínio não urgente em lote Para avaliações, geração de testes, ou análise que tolera latência, APIs de lote oferecem descontos de 50%. Combinado com modelos de raciocínio, você obtém o benefício de qualidade a metade do custo de saída. Saída de raciocínio $/1M inclui tokens de pensamento faturados a taxas de saída. O multiplicador é médio entre tarefas típicas; o multiplicador real varia por complexidade da solicitação. DeepSeek R1 produz tokens de pensamento por padrão. OpenAI o3/o4-mini cobra tokens de pensamento separadamente da saída visível. Gemini 2.5 Pro cobra "tokens de pensamento" a uma taxa reduzida vs. saída visível - o multiplicador é custo combinado efetivo. Alguns links podem incluir códigos de indicação. Quer isso aplicado ao seu próprio gasto em LLM? FinOps LLM realiza uma auditoria gratuita de seus custos de IA e mostra onde estão as economias. Agende auditoria gratuita → Voltar para pesquisa FAQ Qual é a metodologia? Preço do token de saída para conclusão padrão (sem raciocínio), a partir de páginas oficiais do provedor. Preço de raciocínio: custo efetivo incluindo tokens de pensamento. Medido como preço de saída padrão × multiplicador de pensamento médio para cada modelo. Qual é a tabela de preços de modelos de raciocínio? Saída de raciocínio $/1M inclui tokens de pensamento faturados a taxas de saída. O multiplicador é médio entre tarefas típicas; o multiplicador real varia por complexidade da solicitação. DeepSeek R1 produz tokens de pensamento por padrão. OpenAI o3/o4-mini cobra tokens de pensamento separadamente da saída visível. Quando usar modelos de raciocínio? Os modelos de raciocínio se destacam em tarefas que exigem planejamento: refatorar múltiplos arquivos, depurar estados complexos, ou escrever algoritmos com casos extremos. Os tokens de pensamento permitem ao modelo "trabalhar" o problema em vez de simples correspondência de padrões. Quando evitar modelos de raciocínio? Extrair dados de documentos, reformatar JSON, resumir texto, ou traduzir conteúdo. Essas tarefas precisam de correspondência de padrões, não de raciocínio. Usar o3 para extração é como contratar um matemático para classificar correspondência - caro e desnecessário. Quais são estratégias de otimização de custos? Use um modelo padrão barato (GPT-4o-mini, Gemini Flash) como roteador. Se a tarefa é simples, responda diretamente. Se for complexa, escale para um modelo de raciocínio. Este padrão "cascata" pode reduzir uso de modelos de raciocínio em 60-80% preservando qualidade onde importa. --- # O mesmo modelo custa mais na sua região · FinOps LLM URL: https://finopsllm.com/pt/research/regional-pricing-premium Prémio regional e residência de dados Atualizado September 1, 2026 · publicado originalmente September 1, 2026 Resposta rápida: A tabela com que orçamentou é quase sempre a dos EUA. Encaminhe o mesmo pedido por um endpoint europeu ou asiático, ou fixe-o a uma região por residência, e o número muda — às vezes no preço do... A tabela com que orçamentou é quase sempre a dos EUA. Encaminhe o mesmo pedido por um endpoint europeu ou asiático, ou fixe-o a uma região por residência, e o número muda — às vezes no preço do token, mais vezes em tudo o resto. De onde vem o prémio De quatro sítios ao mesmo tempo. Preço regional , que difere por plataforma. Disponibilidade de modelos , atrasada fora da região primária. Egress e latência entre regiões. E sobretudo menos funcionalidades : sem cache de prompts ou preço batch nessa região, perde descontos que já dava como certos. É esse o que dói: uma carga desenhada sobre cache e batch, movida para uma região sem eles, não custa uns pontos percentuais a mais — custa o que custaria sem otimização nenhuma. Decida, não herde A residência é muitas vezes uma obrigação real e o prémio é o preço de operar legalmente. O erro é pagá-lo para cargas que nunca precisaram dele. Separe o tráfego pela natureza do dado: o regulado vai para a região conforme, o resto vai onde for mais barato. Artigos relacionados Atribuição de custos de LLM Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Ciclo de retries e custo de inferência · FinOps LLM URL: https://finopsllm.com/pt/research/retry-loop-hidden-spend O ciclo de retries que aumenta o custo de inferência Atualizado August 27, 2026 · publicado originalmente August 27, 2026 Resposta rápida: Um retry é outra chamada ao modelo, não resiliência gratuita. Meça o imposto de retries: despesa de retries e fallbacks dividida pela inferência total.Registe a árvoreGuarde pedido pai, tentativa,... Um retry é outra chamada ao modelo, não resiliência gratuita. Meça o imposto de retries: despesa de retries e fallbacks dividida pela inferência total. Registe a árvore Guarde pedido pai, tentativa, fornecedor, modelo, ferramenta, erro, tokens e resultado. Chamadas aninhadas precisam de relações pai-filho. Limite o ciclo Defina limites de tentativas, tokens, dólares e tempo por classe de erro. Um erro determinístico não deve ser repetido sem alteração. Não desligue todos os retries: torne cada tentativa visível, limitada e justificada por um resultado melhor. Artigos relacionados Limites de despesa para agentes Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Créditos de IA em SaaS: medir e alocar · FinOps LLM URL: https://finopsllm.com/pt/research/saas-ai-credits-metering Créditos de IA em SaaS: medir uma unidade que não controla Atualizado September 2, 2026 · publicado originalmente September 2, 2026 Resposta rápida: O FinOps de cloud assume uma unidade legível: uma hora de instância, um pedido, um gigabyte. Um crédito de IA não é isso: o fornecedor define-o, preça-o e pode redefini-lo durante o prazo.Três... O FinOps de cloud assume uma unidade legível: uma hora de instância, um pedido, um gigabyte. Um crédito de IA não é isso: o fornecedor define-o, preça-o e pode redefini-lo durante o prazo. Três propriedades que quebram o manual A unidade é opaca: duas funcionalidades consomem de forma muito diferente para o que o utilizador vive como a mesma ação. A tarifa não é sua. E as dotações expiram sem agrupamento nem transição. Meça mesmo assim Extraia o consumo da API de administração de forma agendada e guarde-o junto dos seus dados de custo, por utilizador, equipa e funcionalidade. O painel do fornecedor mostra o período atual; as suas perguntas são sobre a tendência. Aloque antes da fatura Ligue os créditos aos mesmos centros de custo usados para a cloud e publique showback mensal. Despesa não alocada cai no orçamento de plataforma, a equipa com menos influência sobre o consumo. Limite, senão alerte Prefira um teto administrativo na consola do fornecedor: é o único controlo que trava a despesa antes de ocorrer. Sem ele, alerte sobre a sua própria medição com margem para agir. Artigos relacionados IA sombra em cartões corporativos Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # As ferramentas de servidor não são tokens · FinOps LLM URL: https://finopsllm.com/pt/research/server-tools-are-a-separate-invoice As ferramentas de servidor são outra fatura Atualizado September 1, 2026 · publicado originalmente September 1, 2026 Resposta rápida: A maioria dos modelos de custo de LLM tem um só contador: tokens de entrada, tokens de saída, preço por milhão. Era correto enquanto um pedido apenas gerava texto. Deixou de o ser com as ferramentas... A maioria dos modelos de custo de LLM tem um só contador: tokens de entrada, tokens de saída, preço por milhão. Era correto enquanto um pedido apenas gerava texto. Deixou de o ser com as ferramentas do lado do servidor. A pesquisa web, o fetch e a execução de código correm na infraestrutura do fornecedor, e várias têm um custo por utilização além dos tokens que produzem. Um turno de agente pode assim cobrar-lhe duas vezes. A parte que se acumula É a segunda cobrança que escapa. Cada resultado é acrescentado à conversa e cada turno seguinte reenvia tudo como entrada. Dez pesquisas no início de uma execução longa não são dez cobranças: são dez cobranças mais o seu conteúdo relido em todos os turnos seguintes. É por isso que os custos de agente parecem não lineares quando a aritmética dos tokens diz que deviam ser lineares. A taxa por utilização é a parte visível; o crescimento do contexto é a maior, e cai na linha dos tokens de entrada sem etiqueta. Sem atribuição não há gestão Registe as invocações por pedido junto ao objeto de utilização: que ferramenta, quantas chamadas e o tamanho em tokens do que cada resultado acrescentou. Depois calcule o custo por execução de agente, não por chamada à API. Três controlos que funcionam Limite as chamadas por execução — delimita as duas cobranças ao mesmo tempo. Corte o que entra no contexto — resumir antes de acrescentar alivia todos os turnos seguintes. Coloque o prefixo estável em cache — prompt de sistema e definições de ferramentas são constantes. Artigos relacionados Economia da cache de prompts Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # A IA sombra está num cartão da empresa · FinOps LLM URL: https://finopsllm.com/pt/research/shadow-ai-corporate-cards A despesa de IA fora da sua fatura de API Atualizado September 1, 2026 · publicado originalmente September 1, 2026 Resposta rápida: Quase todas as organizações medem o custo de IA abrindo a consola do fornecedor. Esse número é real e bem instrumentado — e em muitas empresas é a metade pequena do total. A outra metade está em... Quase todas as organizações medem o custo de IA abrindo a consola do fornecedor. Esse número é real e bem instrumentado — e em muitas empresas é a metade pequena do total. A outra metade está em notas de despesa: subscrições individuais de quem precisava de uma ferramenta e tinha cartão. Porque é invisível Nunca toca nas suas chaves de API, no gateway ou na telemetria. Chega como encargo por lugar, em valores pequenos que passam a aprovação sozinhos. Duzentas pessoas a vinte ou trinta por mês são uma rubrica anual de seis dígitos que nenhum painel de engenharia mostra. O que lhe custa mesmo O excesso direto é o menos interessante. Os planos individuais estão muito acima das tarifas negociadas, e pagar duas vezes ao mesmo fornecedor é comum. Pior: os planos de consumo têm termos de retenção e treino diferentes dos que o jurídico reviu, não há SSO, e o acesso não termina quando o vínculo termina. Como encontrar Pergunte a finanças, não a engenharia. Procure nomes de fornecedores e depois o padrão: encargos mensais recorrentes de dez a cinquenta dólares. E responda tornando o caminho oficial mais fácil do que o cartão, em vez de proibir o cartão. Artigos relacionados Atribuição de custos de LLM Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Aumento do Claude Sonnet 5 cancelado: $2/$10 é permanente · FinOps LLM URL: https://finopsllm.com/pt/research/sonnet-5-intro-pricing-deadline Claude Sonnet 5: o aumento de setembro foi cancelado Publicado em 19 de julho de 2026 Correção, 2 de setembro de 2026: o aumento para o qual este artigo foi escrito não aconteceu. A Anthropic cancelou-o — o Claude Sonnet 5 permanece em $2/$10 por 1M tokens de forma permanente. A análise do prazo abaixo é mantida como publicada, para registo; trate cada número «a partir de 1 de setembro» como um cenário que nunca entrou em vigor. As tarifas atuais estão no rastreador de preços de APIs LLM . Anthropic lançou Claude Sonnet 5 em 30 de junho de 2026 a preços de lançamento de $2/1M tokens de entrada e $10/1M tokens de saída. Esse preço tem um prazo definitivo: 31 de agosto de 2026 . A partir de 1º de setembro, Sonnet 5 se move para preços padrão de $3/$15 por 1M, um aumento de custos de 50% fixo . Se você está executando cargas de trabalho de Sonnet 5, as próximas 6 semanas são sua janela para fixar custos e planejar o aumento. Preços de lançamento válidos até 31 de agosto de 2026 apenas Preços padrão ($3/$15) começam em 1º de setembro de 2026 O aumento de custos é exatamente 50% para cargas de trabalho de Sonnet 5 Aplica-se à API do Anthropic, Bedrock e Vertex AI 43 dias para fazer novos testes, fixar compromissos e replanjar orçamentos Prazo crítico: Os preços de lançamento do Claude Sonnet 5 expiram em 43 dias (31 de agosto de 2026). Uma carga de trabalho de 10M tokens/mês passará de $20 para $30/mês. Uma carga de trabalho de 1B tokens/mês passará de $2.000 para $3.000. Se Sonnet 5 está em seu caminho crítico, orçamente o aumento agora ou mude as cargas de trabalho antes da mudança. A Matemática: O que 50% Significa em Escala O salto de preços de lançamento para padrão é claro e significativo. Vamos modelar uma carga de trabalho realista: Perfil de Carga de Trabalho Tokens de Entrada Mensais Tokens de Saída Mensais Custo Agosto (Lançamento) Custo Setembro (Padrão) Delta Mensal Impacto Anual Leve (lote/interno) 50M 20M $200 $300 +$100 +$1.200 Nível médio (voltado para cliente) 500M 150M $2.500 $3.750 +$1.250 +$15.000 Empresa (raciocínio de alto volume) 2B 800M $12.000 $18.000 +$6.000 +$72.000 Pesada (fluxos multi-solicitação) 5B 2.5B $35.000 $52.500 +$17.500 +$210.000 Insight chave: Uma empresa com uma carga de trabalho de Sonnet 5 de nível médio (500M entrada + 150M tokens de saída/mês) verá um aumento mensal de $1.250 que se compõe a $15.000 anuais se nada mudar. Para cargas de trabalho empresariais, o impacto anual pode exceder $70K. Quem É Afetado O prazo se aplica em todos os canais: API do Anthropic (direta) Os preços de lançamento terminam em 31 de agosto de 2026 às 23:59 UTC. Verificado na documentação de preços do Anthropic . Nenhuma extensão ou atraso foi anunciado. AWS Bedrock Bedrock repassa os preços do Anthropic. Os preços de lançamento se aplicam a Sonnet 5 no Bedrock até 31 de agosto. O aumento aparecerá em sua fatura do Bedrock em 1º de setembro. Verifique seu contrato AWS para qualquer desconto por compromisso que possa compensar o aumento. Google Vertex AI Vertex AI integra modelos de Claude com repasse de preços do Anthropic. A transição ocorre em 1º de setembro. As faturas do Vertex são cotadas em sua moeda local; confirme a data exata com sua equipe de conta do Google se você usar um fuso horário diferente. GitHub Copilot Enterprise Se Copilot usa Sonnet 5 como backend, Microsoft pode ou não repassar o aumento de preço para seu plano. Copilot Enterprise é uma licença de assento fixo, portanto o impacto depende se Microsoft absorve ou reflete o custo do backend. Verifique sua fatura do Copilot ou entre em contato com sua equipe de conta da Microsoft. Três Estratégias: O Que Fazer Antes de 31 de Agosto Estratégia 1: Fixe Compromissos de Uso (Se Disponíveis) Verifique se Anthropic oferece compromissos de uso ou descontos por volume para Sonnet 5. Descontos baseados em volume ou acordos de pré-pagamento anual poderiam reduzir o aumento de preço efetivo. Entre em contato com vendas do Anthropic agora: eles poderiam manter os preços de lançamento em compromissos assinados antes de 31 de agosto. Ação: Envie email para vendas do Anthropic antes de 15 de agosto se você gasta >$5K/mês em Sonnet 5. Pergunte se um compromisso anual fixa preços de lançamento ou oferece descontos escalonados. O tempo de espera para contratos de compromisso é tipicamente de 2-3 semanas. Estratégia 2: Faça Novos Testes de Roteamento e Mistura de Modelos Nem todas as cargas de trabalho precisam de Sonnet 5. O salto de preço de 50% é uma função de força para auditar quais tarefas realmente exigem Sonnet 5 e quais podem mudar para alternativas mais baratas. Categoria de Tarefa Entrada Sonnet 5/$1M Modelo Alternativo Entrada Alt/$1M Economia por 100M Tokens Quando Mudar Classificação (regras estritas) $3 (após 1º set) Claude Haiku 4.5 $1.00 $200 Precisão ≥95% Resumo $3 Gemini 2.5 Flash $0.15 $285 Sem raciocínio necessário Conversa multi-volta $3 GPT-5.6 Luna $1.00 $200 Qualidade equivalente Raciocínio complexo (manter Sonnet 5) $3 — — — Sem alternativa Loops agênticos (multi-etapa) $3 Híbrido Haiku + Sonnet 5 $1.00 (Haiku) + $3 (Sonnet 5) Economizar usando Haiku para etapas simples Benchmarks suportam Ação: Nas próximas 2 semanas, extraia seus registros de chamadas de Sonnet 5 e categorize por carga de trabalho. Faça benchmark de 10% de tarefas de classificação no Haiku, resumo no Gemini 2.5 Flash e multi-volta simples no GPT-5.6 Luna. Se a qualidade for equivalente (ou próxima), mude essa carga de trabalho antes de 1º de setembro e fixe a economia. Estratégia 3: Implemente (ou Expanda) Cache de Prompts O cache de prompts é a forma mais direta de reduzir o consumo de tokens e preservar o valor dos preços de lançamento antes que expirem. As escritas de cache para Sonnet 5 custam $2.50 por 1M tokens (1.25× preço de entrada em lançamento; será $3.75 em padrão). As leituras de cache custam $0.20 por 1M (0.1× preço de entrada em lançamento; será $0.30 em padrão). A oportunidade: Uma carga de trabalho com taxa de acerto de cache de 40% economiza 36% no custo de entrada. Fixar infraestrutura de cache agora a preços de lançamento significa que suas economias de taxa de acerto em andamento estão herdadas. Após 1º de setembro, os mesmos acertos de cache ainda são 90% de desconto, mas o preço base que descountam é 50% mais alto. Exemplo: Prompt de sistema + contexto armazenado em cache 100M tokens/mês em Sonnet 5: Agosto (lançamento): Custo de escrita: 100M × $2.50/M = $250. Custo de leitura mensal (suponha 1B tokens de leitura de acertos de cache): 1B × $0.20/M = $200. Total: $450/mês para cache. Setembro (padrão): Custo de escrita: 100M × $3.75/M = $375. Custo de leitura mensal: 1B × $0.30/M = $300. Total: $675/mês (50% mais alto). Economia por implementar cache agora: Se você adicionar 500M tokens de entrada armazenados em cache entre agora e 31 de agosto, e eles acumularem 30 acertos de cache cada mês a partir de setembro, você fixa descontos de leitura cumulativos. O custo de escrita de cache é um investimento que se amortiza ao longo dos meses. Ação: Identifique seus 3 prompts mais repetidos ou contextos de documento (documentos RAG, instruções do sistema, boilerplate). Teste cache na API do Anthropic. Se a taxa de acerto for ≥20%, implemente antes de 31 de agosto. As escritas de cache são o único custo que não importa quando ocorre o aumento de taxa: investir em custo de escrita agora produz retornos de custo de leitura fixos para sempre. Cronograma: A Contagem Regressiva de 6 Semanas Semana 1 (antes de 25 de julho) Audite o gasto atual de Sonnet 5. Extraia registros de chamadas (modelo, tokens, tipo de carga de trabalho) do seu painel de faturamento ou plataforma de observabilidade de LLM. Calcule a taxa de execução mensal. Modele gasto de Q4 se nada mudar. Semana 2 (antes de 1º de agosto) Entre em contato com vendas do Anthropic para investigar compromissos de uso. Comece a fazer benchmark de modelos alternativos (Haiku, Luna, Gemini 2.5 Flash) em 10% do tráfego de produção. Identifique os 3 principais candidatos para mudança de roteamento. Semana 3 (antes de 8 de agosto) Finalize benchmarks e comprometa um plano de roteamento. Se mudanças forem necessárias, comece a implantar testes A/B. Implemente cache de prompts para contextos repetidos de alto volume. Objetivo ≥100M tokens armazenados em cache antes da mudança. Semana 4 (antes de 15 de agosto) Fixe compromissos de uso com Anthropic (se aplicável). Implante mudanças de roteamento em produção (mude tarefas de baixo raciocínio para modelos mais baratos). Verifique que a infraestrutura de cache está ativa e atingindo acertos de 15%+. Semana 5 (antes de 22 de agosto) Monitore custos de produção e métricas de qualidade. Ajuste o roteamento se necessário. Preveja custos finais de setembro com base na taxa de execução de agosto. Semana 6 (antes de 31 de agosto) Confirme que todas as mudanças de roteamento estão ativas. Defina alerta no calendário para 5 de setembro para verificar que o faturamento corresponde à previsão. Publique análise post-mortem sobre impacto de custos e economias obtidas. Comparação: Sonnet 5 vs. Alternativas Após 1º de Setembro Uma vez que os preços de lançamento expirarem, como Sonnet 5 se compara com outros modelos a seus preços padrão? Modelo Provedor Entrada $/1M Saída $/1M Caso de Uso Típico vs. Sonnet 5 Após 1º Set Claude Sonnet 5 (padrão) Anthropic $3.00 $15.00 Equilíbrio de velocidade e raciocínio Linha de base GPT-5.6 Terra OpenAI $2.50 $15.00 Raciocínio nível médio 17% mais barato na entrada GPT-5.6 Luna OpenAI $1.00 $6.00 Classificação rápida, tarefas simples 67% mais barato em geral Gemini 3.1 Pro Google $2.00 $12.00 Loops agênticos, uso de ferramentas 33% mais barato na entrada Gemini 2.5 Flash Google $0.15 $0.60 Ultra rápido, alto volume 95% mais barato Claude Haiku 4.5 Anthropic $1.00 $5.00 Classificação baixa latência 67% mais barato na entrada DeepSeek V4 Flash DeepSeek $0.14 $0.28 Otimizado para custo, modelo aberto 95% mais barato (mas menos polido) A realidade: Sonnet 5 a $3/$15 não é mais o modelo mais barato ou mais econômico para a maioria das tarefas. GPT-5.6 Terra é 17% mais barato na entrada. Haiku é 67% mais barato para classificação. O valor de Sonnet 5 após o aumento é em qualidade para raciocínio complexo e velocidade para tarefas equilibradas, não em liderança de custos. As cargas de trabalho que não exigem essa qualidade devem se mudar para alternativas agora. Perguntas Frequentes P: Há alguma chance de o prazo ser estendido? R: Anthropic não anunciou uma extensão. O anúncio de lançamento de 30 de junho deixa claro "até 31 de agosto de 2026". Prepare-se para a data definitiva. Se uma extensão for anunciada, é uma bonificação; trate o prazo como final. P: O novo tokenizador afeta os contadores de tokens? R: Sim. Sonnet 5 usa um novo tokenizador que produz aproximadamente 30% mais tokens do que modelos Claude mais antigos para texto equivalente. Isso significa que seu gasto atual de tokens é maior do que você pode esperar. Fatore isso em previsões de custos. P: Posso fixar preços de lançamento com pré-pagamento anual? R: Possivelmente, se Anthropic oferecer opções de pré-pagamento. Entre em contato com vendas antes de 15 de agosto para perguntar. Pré-pagamento é muitas vezes a única forma de herdar preços através de um aumento de taxa, mas você precisa se comprometer bem com antecedência. P: E se eu tiver um contrato personalizado com Anthropic? R: Contratos personalizados podem ter termos diferentes. Verifique a data exata de mudança e taxa com sua equipe de conta. Se seu contrato especifica termos de preços, eles têm prioridade sobre a página de preços pública: confirme agora antes que 1º de setembro o surpreenda. O prazo de 31 de agosto é real, o aumento de 50% é certo, e você tem 6 semanas para agir. As equipes que fazem novos testes, fixam compromissos e mudam cargas de trabalho antes da mudança cortarão significativamente seus gastos com LLM de Q4. As equipes que esperam até 1º de setembro absorverão o aumento de custos completo. Voltar para pesquisa FAQ Os preços de lançamento do Claude Sonnet 5 terminaram em 31 de agosto de 2026? Não. A Anthropic cancelou o aumento previsto. O Claude Sonnet 5 mantém-se permanentemente em $2 por 1M de tokens de entrada e $10 por 1M de saída; a tarifa padrão de $3/$15 prevista para 1 de setembro de 2026 nunca entrou em vigor. Quanto minha fatura aumentará? Exatamente 50% para cargas de trabalho de Claude Sonnet 5. Os preços de entrada sobem de $2 para $3 por 1M tokens (+50%); a saída sobe de $10 para $15 por 1M tokens (+50%). Uma carga de trabalho que custa $10.000/mês em agosto custará $15.000/mês em setembro se não mudar. Os preços de lançamento se aplicam a Bedrock e Vertex? Os preços de lançamento se aplicam à API direta do Anthropic. AWS Bedrock e Google Vertex AI repassam os preços do Anthropic, portanto o aumento se aplica também lá a partir de 1º de setembro. Verifique os termos do seu contrato com seu provedor de nuvem. O que devo fazer antes de 31 de agosto? 1) Fixe compromissos de uso se estiverem disponíveis. 2) Faça novos testes de roteamento para Sonnet 5 versus modelos mais baratos (Haiku, Gemini 2.5 Flash). 3) Mude prompts repetidos para cache de prompts (os descontos de cache são dimensionados com o preço base, então fixar economia de cache agora é valioso). 4) Defina um alerta no calendário para 25 de agosto para testar custos após migração. 5) Modele o aumento em seu orçamento de Q3 agora. --- # O modelo anónimo grátis é uma arma de preço · FinOps LLM URL: https://finopsllm.com/pt/research/stealth-model-free-tokens-playbook O manual do modelo furtivo Atualizado September 1, 2026 · publicado originalmente September 1, 2026 Resposta rápida: O Ox Alpha apareceu nos agregadores de encaminhamento como um endpoint sem marca, gratuito, sem tabela de preços e sem laboratório associado. Depois foi confirmado como GLM-5.3 e a janela gratuita... O Ox Alpha apareceu nos agregadores de encaminhamento como um endpoint sem marca, gratuito, sem tabela de preços e sem laboratório associado. Depois foi confirmado como GLM-5.3 e a janela gratuita fechou. O GLM-5.3-Flash está agora a 0,15 $ por milhão de tokens de entrada e 0,50 $ de saída. Trate isto como uma jogada repetível, porque é. Já correu com outros nomes e voltará a correr. O que o laboratório compra com tokens grátis Três coisas, todas mais baratas do que as alternativas. Avaliação cega: um endpoint sem marca é julgado pela saída e não pelo logótipo. Distribuição: os agregadores encaminham tráfego real de imediato, sem parcerias. Uma âncora de preço: quando o nome é revelado, quem programa já decidiu que o modelo é bom. O número que interessa ao fechar a janela Dezasseis biliões de tokens de entrada passaram pelo endpoint gratuito. A 0,15 $ por milhão, são cerca de 2,4 milhões de dólares de inferência — ou seja, o tamanho do degrau se esse tráfego ficar simplesmente onde está. Faça essa conta com a sua parte: o volume enviado durante a janela vezes o preço publicado é a sua variação mensal. Três regras para a próxima Nunca dependa de um endpoint cujo dono desconhece. Anónimo significa sem tabela de preços, sem política de descontinuação e sem compromisso de tratamento de dados. Serve para avaliar, não para produção sem alternativa. Atribua um preço hipotético a toda a avaliação gratuita e carregue esse custo-sombra na sua telemetria. Parta do princípio de que a janela gratuita é a parte mais curta da relação e meça também o custo de mudar. Artigos relacionados Arbitragem entre fornecedores Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Respostas em streaming canceladas ainda geram custos · FinOps LLM URL: https://finopsllm.com/pt/research/streaming-abandoned-generations-cost Streaming e o custo de gerações abandonadas Atualizado September 9, 2026 · publicado originalmente September 9, 2026 Resposta rápida: A interrupção visual no cliente não cancela a geração na nuvem sem uma propagação explícita de encerramento HTTP. Evite desperdício invisível de saída. A interrupção visual no cliente não cancela a geração na nuvem sem uma propagação explícita de encerramento HTTP. Evite desperdício invisível de saída. Artigos relacionados Gastos ocultos em loops de retentativa Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # A saída estruturada não é grátis · FinOps LLM URL: https://finopsllm.com/pt/research/structured-output-token-cost Custo em tokens do modo JSON e dos esquemas Atualizado September 1, 2026 · publicado originalmente September 1, 2026 Resposta rápida: Pedir saída estruturada parece uma decisão de formato. Na fatura é uma decisão de volume, e cai em três sítios ao mesmo tempo.O esquema é custo de entrada em cada pedidoO esquema é serializado dentro... Pedir saída estruturada parece uma decisão de formato. Na fatura é uma decisão de volume, e cai em três sítios ao mesmo tempo. O esquema é custo de entrada em cada pedido O esquema é serializado dentro do pedido. Um esquema modesto são umas centenas de tokens — multiplique por cada chamada, cada turno, durante toda a vida da funcionalidade. 400 tokens por um milhão de chamadas são 400 milhões de tokens de entrada para descrever uma forma que nunca muda. Pior: colocado depois da parte volátil do prompt, o esquema parte o prefixo em cache e elimina o desconto de tudo o que vem antes. A sintaxe é custo de saída Cada chaveta, aspa, vírgula e nome de campo é um token gerado, faturado ao preço de saída. Nomes longos são um encargo recorrente permanente. As repetições são a parte cara Cada falha de validação custa uma repetição completa: toda a entrada e toda a saída outra vez. 2% de inválidos são 2% de custo a mais por nada. O que fazer Ponha o esquema no prefixo estável para ficar em cache, peça só os campos que consome, use nomes curtos e estruturas planas, e meça a taxa de falha de validação. Artigos relacionados Economia da cache de prompts Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Travar a cascata de subagentes e gasto de tokens · FinOps LLM URL: https://finopsllm.com/pt/research/subagent-fan-out-concurrency-limits Travar a proliferação de subagentes e delegação recursiva Atualizado September 19, 2026 · publicado originalmente September 19, 2026 Resposta rápida: A proliferação em cascata de subagentes acontece quando um agente orquestrador divide tarefas em fluxos paralelos e autoriza que cada trabalhador crie novos agentes subordinados. Sem limites claros de... A proliferação em cascata de subagentes acontece quando um agente orquestrador divide tarefas em fluxos paralelos e autoriza que cada trabalhador crie novos agentes subordinados. Sem limites claros de concorrência e profundidade, um único pedido pode consumir milhões de tokens em escassos minutos. O que é uma cascata de subagentes em IA autónoma? É uma anomalia arquitetural em que um agente orquestrador gera recursivamente novos agentes sem orçamento consolidado, multiplicando o custo da infraestrutura exponencialmente. Salvaguardas em produção As melhores práticas exigem um teto de recursividade fixado no nível 2 (supervisor para executor), uma bolsa centralizada de tokens associada à sessão raiz e disjuntores de concorrência que impedem mais de 3 a 5 agentes em simultâneo. Artigos relacionados Três orçamentos para agentes Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Os três orçamentos de que todo agente autónomo precisa · FinOps LLM URL: https://finopsllm.com/pt/research/three-agent-budgets Os três orçamentos de que todo agente autónomo precisa Atualizado August 27, 2026 · publicado originalmente August 27, 2026 Resposta rápida: Um agente autónomo precisa de três limites dentro do ciclo: orçamento de pedido, de fluxo e diário. Cada um captura uma falha diferente.PedidoLimita tokens, ferramentas, tempo ou dólares de uma... Um agente autónomo precisa de três limites dentro do ciclo: orçamento de pedido , de fluxo e diário . Cada um captura uma falha diferente. Pedido Limita tokens, ferramentas, tempo ou dólares de uma tentativa e aplica-se antes das chamadas ao fornecedor e às ferramentas. Fluxo Acompanha a intenção completa através de retries, fallbacks e subagentes. Um livro correlacionado trava ciclos que não convergem. Diário Limita a despesa agregada de uma equipa, cliente ou serviço. Perto do limite, encaminhe trabalho elegível para batch ou modelos menores. Recusas úteis Mostre qual limite disparou, o consumo e a recuperação permitida. Registe reservas, despesa e recusas para reconciliação. Artigos relacionados Limites de despesa para agentes Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Guia de implementação de orçamentos de tokens · FinOps LLM URL: https://finopsllm.com/pt/research/token-budget-implementation-guide Guia de implementação de orçamentos de tokens Orçamentos de tokens são a camada operacional do controle de custos de LLM. A atribuição informa aonde o dinheiro vai; orçamentos evitam que vá para lugares que você não deseja. Sem orçamentos, um único loop de agente mal configurado ou um aumento no tráfego de usuários pode consumir uma alocação mensal em horas. Este guia cobre como implementar quatro tipos de orçamentos de tokens em produção, com pseudocódigo para cada padrão. Tipos de orçamento Tipo de orçamento Granularidade Aplicação Caso de uso Por solicitação Uma única chamada de API Limite rígido via parâmetro max_tokens Prevenir conclusões descontroladas, limitar latência Cota por equipe Equipe ou projeto durante um período Limite suave com alertas, limite rígido em limite Alocação de custo departamental, evitar que uma equipe consuma orçamento compartilhado Por período de tempo Diário, semanal ou mensal Limite rígido com período de carência Limites de orçamento mensal, gastos de nível de sprint Por fluxo de trabalho Um único pipeline ou execução de agente Limite rígido por etapa e total Agentes multi-etapa, pipelines de RAG, execuções de avaliação Limites por solicitação O orçamento mais simples: limite cada solicitação com max_tokens . Isso não é opcional - cada solicitação de produção deve ter um limite explícito de tokens de saída. Sem ele, uma resposta verbosa do modelo pode consumir tokens inesperados e inflacionar a latência. // Aplicação de orçamento por solicitação function chameLLM(prompt, config): resposta = provedor.completar( prompt: prompt, modelo: config.modelo, max_tokens: config.max_tokens_saida, // limite rígido temperatura: config.temperatura ) if resposta.uso.tokens_totais > config.limite_aviso: log.aviso("Solicitação excedeu limite suave", tokens: resposta.uso.tokens_totais, limite: config.limite_aviso ) return resposta Cotas por equipe As cotas por equipe requerem um contador compartilhado que persista entre solicitações. O padrão: verifique o orçamento restante antes de cada chamada, rejeite ou degrade se o orçamento se esgotar. // Cota de equipe com contador apoiado por Redis function verificarOrçamentoEquipe(idEquipe, tokensEstimados): chave = "orçamento:" + idEquipe + ":" + periodoAtual() restante = redis.obter(chave) or obterCotaEquipe(idEquipe) if restante < tokensEstimados: if restante < tokensEstimados * 0.1: return NEGAR // limite rígido: rejeitar solicitação else: return DEGRADAR // limite suave: usar modelo mais barato return PERMITIR function registrarUso(idEquipe, tokensReais): chave = "orçamento:" + idEquipe + ":" + periodoAtual() redis.decrementar(chave, tokensReais) restante = redis.obter(chave) if restante < obterCotaEquipe(idEquipe) * 0.2: alerta.cotaBaixa(idEquipe, restante) Orçamentos por período de tempo Orçamentos por período de tempo envolvem cotas de equipe com uma janela de tempo. A diferença chave: você precisa de um mecanismo de período de carência. Quando uma equipe atinge 80% de seu orçamento mensal, envie um alerta. Com 100%, permita um período de carência configurável (por exemplo, 24 horas) antes que o cumprimento rígido entre em vigor. Isso evita que uma equipe seja bloqueada no meio de uma tarefa no último dia do mês. // Orçamento por período com período de carência function aplicarOrçamento(idEquipe): uso = obterUsoPeriodo(idEquipe, mesAtual()) limite = obterLimiteOrcamentoMensalEquipe(idEquipe) if uso < limite * 0.8: return PERMITIR if uso < limite * 1.0: alerta.avisoOrcamento(idEquipe, uso, limite) return PERMITIR // zona de aviso suave if uso < limite * 1.1 and dentroPeriodoCarencia(idEquipe): alerta.orcamentoExcedido(idEquipe, uso, limite) return PERMITIR // período de carência: permitir excesso return NEGAR // parada rígida Orçamentos por fluxo de trabalho Agentes e pipelines multi-etapa precisam de orçamentos em dois níveis: por etapa (evita que uma única etapa consuma demais) e por execução (evita que todo o pipeline exceda sua alocação). Acompanhe ambos no contexto do fluxo de trabalho. // Rastreador de orçamento de fluxo de trabalho class OrçamentoFluxo: construtor(maxPorEtapa, maxTotal): this.maxPorEtapa = maxPorEtapa this.maxTotal = maxTotal this.gasto = 0 function executarEtapa(fnEtapa, prompt): if this.gasto >= this.maxTotal: return respostaReserva("Orçamento excedido") resposta = chameLLM(prompt, { max_tokens: min(this.maxPorEtapa, this.maxTotal - this.gasto) }) this.gasto += resposta.uso.tokens_totais return resposta Degradação graciosa quando o orçamento é excedido Não simplesmente retorne um erro quando um orçamento é atingido. Degrade graciosamente. Mude para um modelo mais barato (GPT-4o-mini em vez de GPT-4o), reduza o tamanho da janela de contexto, pule etapas de processamento opcionais ou retorne um resultado parcial com uma nota de que o processamento completo requer aprovação de orçamento. A experiência do usuário deve degradar, não quebrar. // Cadeia de degradação function chamarComDegradacao(prompt, config): if verificarOrçamento(config.idEquipe, MODELO_COMPLETO): return chameLLM(prompt, { modelo: config.modeloPrimario }) if verificarOrçamento(config.idEquipe, MODELO_BARATO): log.info("Degradando modelo por orçamento") return chameLLM(prompt, { modelo: config.modeloReserva }) if verificarOrçamento(config.idEquipe, TOKENS_MINIMOS): truncado = truncarContexto(prompt, 50%) return chameLLM(truncado, { modelo: config.modeloReserva, max_tokens: 256 }) return cacheadoOuFallback(prompt) Monitoração da saúde do orçamento Acompanhe três métricas: taxa de consumo (tokens consumidos por hora vs. orçamento), previsão (no ritmo atual, quando o orçamento se esgotará) e contagem de substituições (quantas vezes o período de carência foi usado). Se o uso do período de carência exceder 10% do total de solicitações, o orçamento está definido muito baixo para a carga de trabalho. Relacionado Governança de orçamento de LLM - políticas organizacionais por trás dos orçamentos. Grades de proteção de despesas de agentes - padrões de orçamento para agentes autônomos. Como limitar custos de inferência - controles de custo do lado do provedor. Quer isso aplicado aos seus próprios gastos com LLM? O FinOps LLM executa uma auditoria gratuita dos seus custos de IA e mostra onde estão as economias. Agendar auditoria gratuita → Voltar à pesquisa --- # Tokens mais baratos, fatura LLM maior · FinOps LLM URL: https://finopsllm.com/pt/research/token-prices-bill-keeps-rising Tokens mais baratos, fatura LLM maior Atualizado August 27, 2026 · publicado originalmente August 27, 2026 Resposta rápida: Tokens mais baratos não garantem uma fatura menor. Em produção, contextos maiores, mais passos de agentes, respostas extensas e tentativas repetidas podem crescer mais depressa do que os preços caem.... Tokens mais baratos não garantem uma fatura menor. Em produção, contextos maiores, mais passos de agentes, respostas extensas e tentativas repetidas podem crescer mais depressa do que os preços caem. Separe a variação de tarifa, volume, mix e eficiência. A tarifa é apenas uma parte Se o preço cair de 10 para 6 dólares por milhão de tokens, mas o uso subir de 100 para 220 milhões, a fatura passa de 1.000 para 1.320 dólares. Registe o preço realmente faturado por fornecedor, modelo e tipo de token. Volume, mix e eficiência Volume é a quantidade de tokens. Mix mostra a mudança para modelos mais caros. Eficiência é o custo de um resultado bem-sucedido: retries, ferramentas falhadas, prompts demasiado longos e saída que ninguém utiliza. Ligue cada chamada à fatura do fornecedor. A revisão semanal Divida a diferença entre duas faturas em tarifa, volume, mix e eficiência. Acompanhe o custo por tarefa concluída, ajustado ao tráfego, e corrija primeiro a categoria com maior impacto financeiro. Preços menores ajudam, mas só uma visão reconciliada de uso, qualidade e custo produz poupança real. Artigos relacionados Monitorização de custos LLM Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Prompts prolixos têm imposto · FinOps LLM URL: https://finopsllm.com/pt/research/verbose-prompt-tax Como o estilo de prompt aparece na fatura Atualizado September 1, 2026 · publicado originalmente September 1, 2026 Resposta rápida: Os prompts crescem como ficheiros de configuração: alguém acrescenta uma instrução por causa de um erro, outro um exemplo, um terceiro um parágrafo a explicar. Nunca se retira nada. Seis meses depois... Os prompts crescem como ficheiros de configuração: alguém acrescenta uma instrução por causa de um erro, outro um exemplo, um terceiro um parágrafo a explicar. Nunca se retira nada. Seis meses depois o system prompt tem três mil tokens e ninguém sabe quais duzentos sustentam o edifício. Porque acumula Ao contrário da saída, o custo do prompt paga-se em cada pedido , igual, para sempre. Mil tokens desperdiçados numa funcionalidade com dez milhões de chamadas por mês são dez mil milhões de tokens mensais de pura formatação. Em conversas de vários turnos é pior: o system prompt é reenviado em cada turno. Em ciclos de agente, uma única ação do utilizador fatura o mesmo preâmbulo uma dúzia de vezes. O que desperdiça de facto Não a cortesia. O peso está em instruções redundantes, boilerplate defensivo escrito para uma geração de modelos anterior, exemplos que se duplicam, e explicações dirigidas a humanos que leem o ficheiro. Trate-o como código com orçamento Meça o prompt fixo como fração do pedido médio. Ponha a parte estável primeiro para haver cache. Depois corte por ablação contra as suas avaliações: retire um bloco, meça, mantenha o corte se a qualidade aguentar. Artigos relacionados Economia da cache de prompts Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Agentes de voz cobram ao minuto · FinOps LLM URL: https://finopsllm.com/pt/research/voice-agents-bill-per-minute Economia unitária das APIs de áudio em tempo real Atualizado September 1, 2026 · publicado originalmente September 1, 2026 Resposta rápida: Qualquer modelo de custo feito para texto parte-se na voz. O texto é faturado por tokens, proporcionais à informação. O áudio é faturado por duração, proporcional ao tempo — incluindo todo o... Qualquer modelo de custo feito para texto parte-se na voz. O texto é faturado por tokens, proporcionais à informação. O áudio é faturado por duração, proporcional ao tempo — incluindo todo o tempo em que nada de útil acontece. O que paga de facto Uma interação de voz empilha três ou quatro cobranças: transcrição à entrada, a chamada ao modelo (ao minuto de áudio nas APIs realtime), síntese à saída e, muitas vezes, a sessão aberta. É esta a armadilha: ao minuto, o silêncio é produto a preço inteiro. Onde as estimativas falham Modela-se tempo falado × tarifa e fica-se muito abaixo. Faltam pausas e latência, áudio gerado que o utilizador interrompeu, repetições (que repetem áudio, não só tokens) e chamadas abandonadas. A métrica que funciona Custo por conversa concluída, não por minuto. E feche sessões inativas: costuma ser a maior poupança disponível. Artigos relacionados Economia dos agentes Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # O que é DeepSeek Harness? Guia completo · FinOps LLM URL: https://finopsllm.com/pt/research/what-is-deepseek-harness O que é DeepSeek Harness? Guia completo Atualizado August 16, 2026 · publicado originalmente August 16, 2026 Resposta rápida: O DeepSeek Harness — nome de pacote dsh — é um harness de agentes de código aberto publicado pela DeepSeek AI sob licença MIT. Esta é a versão sem pré-requisitos: o que é, como executar, como está... O DeepSeek Harness — nome de pacote dsh — é um harness de agentes de código aberto publicado pela DeepSeek AI sob licença MIT. Esta é a versão sem pré-requisitos: o que é, como executar, como está montado e se deve interessar a você. O que é, de fato, um harness de agentes Um modelo gera texto e chamadas de ferramenta. É só isso que ele faz. Todo o resto que torna um agente útil é o harness: montar o prompt, executar de verdade as ferramentas pedidas, impor o que ele tem permissão de fazer, registrar o que aconteceu, conduzir o laço que decide se o modelo será chamado de novo, e delegar trabalho a subagentes. Vale internalizar essa distinção antes de qualquer outra coisa, porque a maior parte do que um agente faz bem ou mal é comportamento do harness e não do modelo. Duas equipes rodando o mesmo modelo obtêm resultados muito diferentes e contas muito diferentes, e a diferença mora aqui. O que o DeepSeek Harness faz Ele executa agentes de programação e automação. Na prática o agente lê e edita arquivos, roda comandos de shell, busca no código, delega a subagentes, planeja trabalho e pede confirmação conforme a política de permissões ativa. Há uma interface de navegador, um modo headless para execuções únicas e um servidor de automação que fala JSON-RPC pela entrada e saída padrão. A única ideia de projeto: tudo é um plugin O harness roda sobre o Cordis , um runtime de plugins em que plugins contribuem serviços, eventos tipados e efeitos reversíveis para um contexto compartilhado. Não existe núcleo privilegiado. O adaptador de modelo é um plugin. O registro de ferramentas é um plugin. O log de sessão é um plugin. O próprio laço do agente é um plugin. A maioria dos sistemas extensíveis oferece um núcleo fixo mais hooks: dá para observar e decorar, não para substituir — e substituir significa forkar. Um runtime de plugins inverte isso: as peças que você mais gostaria de trocar são justamente as unidades de composição. Colocando para rodar O caminho rápido npx @deepseek-ai/dsh web Isso sobe uma interface web local em http://127.0.0.1:3080 . A partir do código git clone https://github.com/deepseek-ai/deepseek-harness cd deepseek-harness pnpm install pnpm run build pnpm dsh web Requisitos: Node 22.19 ou mais recente (a CI cobre 22.19, 24 e 26), Git 2.26 ou mais recente e pnpm fixado via Corepack. Uma chave de API da DeepSeek é opcional na instalação, mas necessária para fazer algo útil; pode vir do ambiente ou de um .env ignorado pelo git na raiz do repositório. Os dois passos que quase todos pulam Configurações → Modelos. Insira sua chave de API. A rota é habilitada na hora, sem reiniciar. Escolher espaço de trabalho. Adicione e ative o diretório do seu projeto. O compositor de sessão fica indisponível enquanto não houver um espaço ativo — é o motivo habitual de uma instalação nova parecer quebrada. Headless pnpm dsh --profile headless "summarize this workspace" É o modo que importa para automação, porque um harness que só funciona de forma interativa não entra em CI, e o que não está em CI não pode ser medido em cadência. O vocabulário para ler a documentação Termo Significado Passo (step) Uma requisição ao modelo mais as chamadas de ferramenta que ela produz Turno (turn) Um esvaziamento da entrada, encerrado quando o modelo para ou a política intervém Rodada (round) Uma iteração de política acima dos turnos, como uma nova tentativa sobre um objetivo Sessão Um log somente-anexação de eventos tipados — a única fonte de verdade da execução Costura de capacidade Uma interface de serviço com várias implementações intercambiáveis Perfil Uma composição nomeada: lista ordenada de bundles de plugins mais os seus patches Scope A unidade de registro por agente para ferramentas, prompts e restrições A configuração resolve em quatro camadas, vencendo a posterior: bundles do perfil, depois patches do perfil, depois patches no nível home, depois overlays de linha de comando. Conhecer essa ordem transforma «por que está usando esse modelo» de investigação em consulta. Por que vale olhar A escolha do modelo é intercambiável. O serviço de modelo é uma interface com vários backends por trás, incluindo um que reproduz uma sessão gravada sem pagar inferência de novo. O laço do agente consome um fluxo neutro quanto ao fornecedor e nunca descobre qual backend está ativo. O registro é completo por construção. O princípio é que o que é visível ao modelo fica registrado, porque o log precisa conseguir reconstituir a execução. O consumo de tokens viaja anexado à saída que o causou. Os pontos de imposição são explícitos. Um antes de a requisição ao modelo sair, cuja decisão é documentada como autoritativa, e outro antes de o corpo de qualquer ferramenta executar. Guardas de permissão podem negar ou se abster, nunca conceder, e uma aprovação sem resposta possível nega. Roda headless. O que significa que pode ser roteirizado, agendado e medido. A alegação sobre plugins não é só posicionamento: uma das demos entregues é autorreferente e inspeciona e modifica o próprio runtime de plugins em execução. Isso é difícil de forjar. Quando usar e quando não Use para avaliar, para prototipar e como referência concreta diante do stack de agentes que você já opera. As cinco perguntas que valem a viagem: a escolha de modelo é intercambiável, existe registro de sessão completo com consumo anexado, há pontos de imposição antes da chamada ao modelo e antes da execução de ferramentas, roda headless, e a estratificação de configuração está documentada? Não padronize nele neste trimestre. O projeto se descreve como developer preview e afirma sem rodeios que haverá mudanças que quebram compatibilidade. Fixe a versão contra a qual você constrói e não agende migração de produção sobre uma API em prévia. Quanto custa operar O harness é MIT e gratuito. Inferência não é. Você fornece uma chave de API da DeepSeek, ou aponta a costura de modelo para outro fornecedor. A implicação prática é que sua conta é função dos passos por turno, das ferramentas no catálogo, da profundidade de delegação e de quantas rodadas um objetivo aberto pode correr — todas decisões de nível harness, nenhuma delas o preço por token que você negociou. Artigos relacionados Instalação, perfis e primeira execução (EN) O que «tudo é um plugin» realmente entrega (EN) O log de sessão como registro de custos (EN) Onde colocar os limites de gasto (EN) Quer aplicar isto à sua plataforma? Traga as faturas dos fornecedores, os registos do gateway e os principais fluxos de trabalho; mapearemos os custos e as oportunidades de poupança. Marcar auditoria gratuita → Voltar a finopsllm.com --- # Research · FinOps LLM · LLM Cost Attribution and Optimization URL: https://finopsllm.com/research Research Notes for engineering and finance teams building AI spend governance. Start here Plain-English explainers if you're new to LLM cost. How do LLM providers charge? Input, output, cache, and reasoning tokens explained What is LLM cost attribution? Why does my LLM bill spike? How to budget for AI spend All research /research/adaptive-thinking-cost-forecast.html A production runbook for an LLM cost spike A quarter of AI spend is slipping to 2027 Add provenance to your AI output Agent Economics: What a Coding Agent Really Costs Agent spend attribution Agent spend guardrails Agent Spend Guardrails: Runtime Controls That Work Agent TCO: The 70% of Cost That Isn't Tokens AI Coding Economics 2026: GLM vs DeepSeek vs Claude AI Coding Plan Comparison AI Cost Allocation: Tags, Cost Centers and Chargebacks AI Cost Optimization Checklist for 2026 AI Cost Optimization: Routing, Caching, Batching AI Cost Optimization: Six Levers That Actually Work AI cost recovery playbook: stop the bleeding AI FinOps: The Operating Model for GenAI Spend AI observability: cost, traffic, and quality · FinOps LLM AI provider list prices are not directly comparable AI spend variance: volume, rate, mix, and efficiency AI watermarking compliance cost Anthropic cost attribution Azure OpenAI vs Direct Cost (2026): Pricing & PTU Guide Background agents change the FinOps clock Batch APIs as a FinOps lever Caching strategies compared Chargeback vs Showback: Picking the Right FinOps Model Chargeback when your provider won't bill per team ChatGPT Pro Max $500 plan economics Cheapest Way to Run AI Code Generation (2026) Claude Fable 5.1 cost model Claude Max 20x isn't 20x. We checked 60 days of logs against Codex Claude Max 20x vs 5x: is the $200 price worth it? We measured the real weekly usage ceiling Claude Max 20x vs Alibaba Token Pro Cost Audit Claude Opus 5.5 pricing and cost model Claude Sonnet 5.5 pricing: what changes, what does not Claude Sonnet 5.5: the cost-aware model routing guide Cloud Infrastructure Cost Audit: Alibaba vs Claude Max Codex auto-compact on GPT-6 Sol: the defaults in the source code, and what raising them costs Codex usage limit resets: how they work, banked resets and a dated log Committed spend and reserved capacity discounts Control MCP tool definition token overhead in agent workflows Cost per approved asset in image and video Cost per request as a product KPI Cost per successful task beats cost per request Currency exposure in LLM spend Cursor vs Copilot vs Claude Code Cost DeepSeek Harness Defensive Patterns DeepSeek Harness Goals and the Ralph Loop DeepSeek Harness Subagents and Delegation DeepSeek Harness Tool Scopes and Restrictions DeepSeek Harness: Everything Is a Plugin DeepSeek Harness: Install and First Run Enterprise AI procurement and committed spend Eval cost allocation: who pays for LLM evals Find the cache miss behind your OpenAI bill Finding the AI spend outside your API bill FinOps for LLM and GenAI: A Practical Framework FOCUS 1.5 adds AI token tracking Gartner's 2026 AI spending forecast GenAI cost management: controls and analytics (2026) GPT-5 Pricing and Budget Impact: A 2026 Planning Guide GPT-5 vs GPT-4o Cost Comparison: When to Upgrade GPT-5.6 Pricing Tier Guide: Luna, Terra, Sol GPT-6 Astra cost model GPT-6 Luna cost model GPT-6 pricing: Astra, Sol and Luna GPT-6 Sol cost model GPT-6 Sol long-context benchmarks: what has actually been measured, and what is GPT-5.6 Sol Hidden LLM Costs Beyond Per-Token Pricing How AI watermarking works How AI watermarks get destroyed How do LLM providers charge? Tokens, tiers, caching How many tokens do you get with Claude Pro and Max? We counted them How much Codex does ChatGPT Pro include? We priced the weekly limit in dollars How Much Does GPT-5 Cost? Complete 2026 Pricing Guide How prompting style shows up on the bill How to audit your LLM spend in 30 minutes How to budget for AI spend: a starter framework How to cap inference costs and prevent runaway spending How to check and reduce Claude Code token usage How to prove AI ROI without hiding quality regressions How to use Jev in an AI agent Input, output, cache, reasoning: what tokens cost Invoice reconciliation for AI spend IT Chargeback and Showback Explained IT Chargeback and Showback for AI: A Practical Guide IT Showback: A Practical Guide for Technology Teams Latest AI models and Anthropic's proposed IPO LLM Budget Governance: Alerts and Guardrails LLM Chargeback and Showback: Design Guide LLM cost anomaly detection LLM Cost Attribution by Team, Product and Tenant LLM Cost Benchmarks by Industry LLM Cost Calculator - Estimate Your Monthly AI Spend LLM cost dashboard: what to put on it LLM Cost Management: A Practical Framework LLM Cost Monitoring in Production: A Field Guide LLM cost monitoring: what to track and how to control it LLM Cost Per User Benchmarks LLM Cost Tracking: Tools, Tags and Telemetry LLM Cost Trends 2025–2026 LLM Cost Visibility: Dashboards and Metrics That Matter LLM FinOps standards LLM Provider Arbitrage: Price and Quality Parity LLM Purchasing Guide for Platform Teams LLM Token Tracking by Input, Output and Cache LLM Usage Metering: How to Bill Internal AI Spend Long context vs RAG: where the cost breakeven actually is MCP Server Cost Impact: Tool Calls and Tokens Measure an AI feature's gross margin before you ship it Minimax M3.1 Flash free preview economics Model deprecation migration: budgeting for forced moves Model price cuts and the routing budget Model Routing: Cheaper Models, Same Output Quality Multi-provider, multi-team LLM FinOps Multimodal cost allocation Non-production LLM spend NVIDIA Open Agent Safety Platform: the FinOps implications On-prem and self-hosted LLM FinOps Open-Source vs Closed-Source LLM Cost Comparison OpenAI & Claude API Pricing Tracker (Live) OpenAI agent message board cost model OpenAI cost attribution OpenAI Fine-Tuning Sunset Economics OpenAI O / AON always-on agent cost model OpenAI Ultra Fast API pricing and speed tiers OpenTelemetry GenAI conventions for cost attribution Opus 5.5 effort levels are the real price Opus 5.5 fast mode economics Opus 5.5 long-running agent cost analysis Order of LLM cost optimizations Ox Alpha was GLM-5.3 Paying for the context window twice Pricing an open-weight model Prompt cache attribution Prompt caching explained Prompt Caching ROI: Calculating Real Savings Put cost controls inside your LLM evaluation pipeline RAG cost optimization Rate limits, 429s and tier upgrades Real cost per task across frontier models Real-SWE cost per resolved issue Reasoning Model Cost Guide Reasoning token attribution and chargeback Regional and residency pricing premiums SaaS AI credits: metering a unit you do not control Semantic cache economics September 2026 AI model trends Server tools are a separate invoice Showback vs Chargeback: Which Model Fits Your Team? Silent model downgrades and cost models Six Jev use cases that actually fit Sonnet 5 pricing: September increase cancelled Spend Guardrails in DeepSeek Harness State of FinOps 2026: 98% now manage AI spend Stop subagent fan-out and recursive delegation from draining token budgets Streaming responses and abandoned generations System One Models and Jev cost optimization The DeepSeek Harness Session Log The first month-end close for an AI-heavy product The free tier as customer acquisition cost The real cost of switching LLM providers The recurring cost of embeddings and vector stores The retry loop that quietly adds to inference spend The stealth-model free-token playbook The three budgets every autonomous agent needs The token cost of JSON mode and schemas The Token Count Is Lying: Claude Max vs Qwen Audit The True Cost of Coding Agents: Beyond the API Bill The unit economics of realtime and audio APIs Token budget implementation Token budget implementation guide Token prices fell. Your LLM bill still went up. Web search is becoming an agent cost center What guardrail and moderation passes cost What independent Jev tests say about cost What is AI value management? What Is DeepSeek Harness? A Complete Guide What is LLM cost attribution? A plain-English explainer What is LLM FinOps? A plain-English definition What is the Tokenomics Foundation? When AI observability creates a second LLM bill Where Jev belongs in an agent workflow Why agentic AI blows the budget Why does my LLM bill spike? The most common causes Why Jev is catching on with agent builders Why Showback Comes Before Chargeback in FinOps Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to FinOps LLM --- # Adaptive thinking broke your cost forecast · FinOps LLM URL: https://finopsllm.com/research/adaptive-thinking-cost-forecast Adaptive thinking and cost forecasting Updated September 1, 2026 · first published September 1, 2026 Quick answer: The reasoning budget used to be a number you set. You passed thinking: {type: "enabled", budget_tokens: N}, and N was both a control and a forecast: worst case, every request cost you N... The reasoning budget used to be a number you set. You passed thinking: {type: "enabled", budget_tokens: N} , and N was both a control and a forecast: worst case, every request cost you N reasoning tokens, and finance could multiply. That parameter is deprecated on Opus 4.6 and Sonnet 4.6, and on the newest models — Fable 5 and 5.1, Sonnet 5, Opus 5, 4.8 and 4.7 — sending it returns a 400 . The replacement is thinking: {type: "adaptive"} , where the model decides how much to think based on the difficulty of the request. This is better output per dollar on average. It is also the removal of a ceiling, and if your forecast was built on that ceiling, the forecast is now wrong in a way that will not show up until the month closes. What changes in the numbers Mean cost per request usually goes down, because easy requests stop paying for reasoning they never needed. Variance goes up , because hard requests are no longer truncated at your cap. The two move in opposite directions, and a budget expressed as a per-request maximum has nothing left to attach to. The practical failure is not the average. It is the tail: a prompt change, a new document type, or a user who starts asking harder questions moves a slice of your traffic into deeper reasoning, and nothing in your configuration limits it. Forecast the distribution, not the cap Three changes, in order of how much they buy you. Track reasoning tokens as their own series. They are already in the usage object on every response. Separate them from input and output in your telemetry, and you can see the shift the day it happens instead of at month end. Budget on percentiles. Replace "N tokens per request" with a p50 and a p99 per route. The p50 tells you what the workload costs; the gap between p50 and p99 tells you how exposed you are to a bad week. Alert on the ratio, not the total. Reasoning tokens as a share of total tokens per route is the single number that moves first when a prompt change makes the model work harder. A total-spend alert fires days later, once the volume has accumulated. Where a cap still belongs Removing the per-request knob does not mean removing all limits. Route-level and tenant-level spend limits still work, still catch runaway loops, and are where the guardrail belongs now — at the boundary you own, not inside a request parameter that no longer exists. For latency-sensitive paths where deep reasoning is never worth it, the lever is model choice, not a token budget. Related Reasoning token attribution Reasoning model cost guide LLM budget governance Related Reasoning token attribution Reasoning model cost guide LLM budget governance Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Add provenance to your AI output in one day · FinOps LLM URL: https://finopsllm.com/research/add-provenance-to-your-ai-output Add provenance to your AI output Updated September 1, 2026 · first published September 1, 2026 Quick answer: Start with the thing you cannot do. The text watermark is applied by the model provider during generation; there is no parameter that turns it on, off, or up, and you cannot add it to text after the... Start with the thing you cannot do. The text watermark is applied by the model provider during generation; there is no parameter that turns it on, off, or up, and you cannot add it to text after the fact. C2PA signing likewise happens at generation for files the provider produces. If you want a stronger signal than what arrives, the answer is not to add marking — it is to add a record. That record is cheap, it is entirely under your control, and it is the thing that actually gets produced when someone asks you to prove where an output came from. Most teams can build it in a day, because it is one join away from telemetry they already collect for cost attribution. The four fields For every generated artefact, log: the exact model ID and version , the region it ran in, the timestamp , and a stable artefact ID that follows the output through your pipeline. That last one is the field teams skip and later wish they had. If you already emit per-request usage records for cost attribution, three of the four are in there. What is usually missing is the join: your cost telemetry knows a request happened and what it cost, but not which stored artefact it produced. Adding the artefact ID to the usage record turns two systems into one query. Keep the signed manifest when you control the pipeline Where the provider hands you a C2PA-signed file, the goal is simple: do not lose it. Configure image transforms to preserve metadata explicitly rather than trusting defaults, and re-attach provenance after any re-encode you control. Test the whole path from generation to delivery, not the model output alone. For files you produce yourself — a chart your service renders, an image you compose from generated parts — you can sign your own C2PA manifest asserting what you did. That is a real option and a genuine improvement in traceability, but it is a project rather than an afternoon, and it is worth doing only after the logging above exists. Mark it for humans too Machine-readable marking and user-visible disclosure are different obligations solving different problems. A visible "generated with AI" label costs nothing to add, is not affected by any pipeline transform, and is what a user actually reads. It is not a substitute for machine-readable marking, and machine-readable marking is not a substitute for it. What it costs to run Four small fields per generated artefact, retained for as long as your compliance window requires. On any realistic volume this is a rounding error against the inference bill itself — and unlike the inference, it is the part you will be asked to produce. Set the retention period deliberately: too short and the record is gone before the question arrives; unbounded and you are paying storage forever for no reason. The sequence that works: add the artefact ID to your existing usage telemetry, verify metadata survives one real image path end to end, add the visible label, then decide whether signing your own manifests is worth it. Only the last step is a project. Related How AI watermarks get destroyed LLM cost attribution AI observability Related How AI watermarks get destroyed LLM cost attribution AI observability Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Agent Economics: What a Coding Agent Really Costs · FinOps LLM URL: https://finopsllm.com/research/agent-economics Agent economics: how much does a coding agent actually cost? Updated 4 July 2026 · first published 4 July 2026 Coding agents are the fastest-growing LLM spend category in 2026. Every engineering team is either using one or evaluating one. But the pricing models are confusing - subscription plans hide token limits behind "unlimited" language, API-based agents expose raw costs that spike unpredictably, and neither model tells you what you actually pay per completed task. This article breaks down the real economics of the five most popular coding agents, introduces a "cost per useful task" metric, and explains why API-based agents can be both cheaper and more expensive than subscription plans depending on usage patterns. The pricing landscape Coding agents fall into two pricing categories. Subscription agents charge a flat monthly fee with included usage. API-based agents charge per token consumed, typically through your own provider account. The right choice depends on how many tasks you run, how large your codebase is, and how complex your prompts become. Agent Plan Monthly cost Included tokens/requests Estimated tasks/month Cost per task Main model Cursor Pro $20/mo 500 fast requests (premium models) ~80–150 $0.13–$0.25 Claude Sonnet 4, GPT-4.1 GitHub Copilot Pro+ $39/mo 1,500 premium requests ~150–300 $0.13–$0.26 Claude Sonnet 4, GPT-4.1 GitHub Copilot Pro $10/mo 300 premium requests ~30–60 $0.17–$0.33 GPT-4.1, Claude Sonnet 4 Claude Code API (Max optional) $5–$100+ Pay-per-token via Anthropic API ~20–200+ $0.25–$2.00 Claude Sonnet 4 Cline API (BYOK) $5–$80+ Pay-per-token via any provider ~20–200+ $0.20–$3.00 User-configured Windsurf Pro $15/mo 500 credits (premium models) ~60–120 $0.13–$0.25 Claude Sonnet 4, GPT-4.1 What "cost per task" actually means The table above shows the advertised range, but real cost per task depends on three hidden factors: context window loading, tool call chains, and retry loops. A "simple" task like adding a new API endpoint might consume 15K–40K tokens across the session. A complex refactor touching multiple files can easily exceed 200K tokens. Context window loading is the biggest hidden cost. Every coding agent loads your open files, project structure, and recent conversation history into each API call. A project with large files means more tokens per request - even if you are asking a simple question. Tool calls multiply this: each file read, grep, or edit operation is a separate API round trip with the full context. Hidden costs most teams miss Retry loops. When an agent's first attempt fails tests or linting, it retries automatically. Each retry is a full-price API call. In practice, 20–40% of agent sessions involve at least one retry, adding 30–80% to the token cost of that task. Context overflow. Long sessions hit context limits. When this happens, the agent either summarizes prior context (losing detail) or drops early messages (losing context). Both lead to lower-quality output and more retries. Tool call overhead. A single task might involve 5–15 tool calls (read file, search code, edit file, run tests). Each tool call includes the full conversation context plus the tool definition. Tool definitions alone can consume 2K–5K tokens of system prompt per call. Idle premium requests. Subscription plans count "fast requests" even when the agent returns unhelpful output. A rejected suggestion still costs one premium request. API vs. subscription: when each wins API-based agents (Claude Code, Cline) win when your usage is bursty or light. If you run 20–40 focused tasks per month, paying $0.30–$0.80 per task is cheaper than a $20–$39 subscription. They also win when you need a specific model for a specific task - you pay only for what you use. Subscription agents (Cursor, Copilot, Windsurf) win when usage is steady and heavy. If you run 100+ tasks per month, the effective per-task cost drops below $0.20, which is hard to beat on API pricing. They also win on predictability - finance teams can budget a fixed amount. The crossover point is typically 40–80 tasks per month for a single developer. Below that, API pricing is cheaper. Above that, subscription plans offer better economics. The "cost per useful task" metric Raw cost per task is misleading because not every task produces value. An agent session that fails, returns an incorrect answer, or requires manual rework has a real cost of zero useful output. The metric that matters is: Cost per useful task = Total monthly spend / Tasks that shipped without manual rework In practice, teams report that 60–80% of agent tasks produce usable output on the first try. The remaining 20–40% require manual intervention. This means the effective cost per useful task is 1.25x–1.7x the raw cost per task. For teams building with open-source models or exploring cost-efficient alternatives, platforms like MiMO offer competitive pricing that can shift the API-vs-subscription calculation. How to reduce agent costs Trim context. Close irrelevant files before invoking the agent. Smaller context = fewer tokens per call. Write specific prompts. Vague prompts lead to more tool calls and retries. "Add a POST /users endpoint that validates email" costs less than "fix the user stuff." Use task-specific models. Simple edits do not need a reasoning model. Route boilerplate to cheaper models and complex refactors to premium ones. Monitor token usage. Track per-session token counts. If average session cost is rising, your prompts or codebase may be growing faster than expected. Set retry limits. Cap automatic retries at 2–3 per task. Beyond that, escalate to a human. What to expect next Agent pricing is moving fast. Subscription plans are increasing included limits as competition intensifies. API prices continue to drop - Claude Sonnet 4 costs 60% less than Claude 3.5 Sonnet did at launch. Open-source coding models are closing the quality gap, which will push API prices even lower. The biggest trend is agent-specific pricing. Providers are experimenting with per-task pricing, per-session caps, and quality-weighted billing. By late 2026, expect most agents to offer a "cost per successful task" guarantee rather than raw token billing. Related AI coding plan comparison - evidence-first benchmark of coding plans. Agent spend attribution - how to track agent costs by project and team. Agent spend guardrails - setting limits before costs run away. FinOps for LLM - the broader framework. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What are the two main pricing categories for coding agents? Subscription agents charge a flat monthly fee with included usage. API-based agents charge per token consumed, typically through your own provider account. The right choice depends on how many tasks you run, how large your codebase is, and how complex your prompts become. What does real cost per task depend on? Real cost per task depends on context window loading, tool call chains, and retry loops. A simple task like adding a new API endpoint might consume 15K–40K tokens, while a complex refactor can easily exceed 200K tokens. Context window loading is the biggest hidden cost. What are the hidden costs most teams miss? Retry loops add 30–80% to task cost when agents fail tests (20–40% of sessions). Context overflow causes lower quality and more retries. Tool call overhead involves 5–15 operations per task, each with full context. Idle premium requests in subscription plans count against limits even when output is rejected. When should I use API-based vs subscription agents? API-based agents win for bursty or light usage—if you run 20–40 tasks per month, paying $0.30–$0.80 per task beats a $20–$39 subscription. Subscription agents win at 100+ tasks/month with better economics. The crossover is typically 40–80 tasks per month for a single developer. What is the 'cost per useful task' metric? Cost per useful task = Total monthly spend / Tasks that shipped without manual rework. Teams report 60–80% of agent tasks produce usable output on first try, with 20–40% requiring intervention. This makes effective cost 1.25x–1.7x the raw cost per task. How can I reduce agent costs? Trim context by closing irrelevant files, write specific prompts to reduce tool calls and retries, use task-specific models (cheaper models for simple edits, premium for complex refactors), monitor per-session token counts, and set retry limits at 2–3 per task to escalate to humans beyond that. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Agent spend attribution · FinOps LLM URL: https://finopsllm.com/research/agent-spend-attribution Agent spend attribution Updated 12 July 2026 · first published 21 May 2026 Agentic workloads break most FinOps allocation models because a single user action explodes into a tree of planner calls, tool invocations, retrievals, retries, and a final synthesis. The invoice arrives as one large number from one provider, but the work was actually performed on behalf of dozens of features owned by different teams. Without attribution, the only available cost control is a blunt cap on total spend, which punishes everyone for the behavior of a few. With attribution, budget caps stop being throttles and start being accountability contracts between the engineers who ship agents and the finance team that funds them. This page is about the ownership side of agent cost. Guardrails matter, but a guardrail without an owner is just a tripwire. The harder problem is connecting every model token, every tool call, and every retry to a person, a product surface, and a budget line that someone has agreed to defend. Why attribution is the harder half of the problem Cost control in conventional cloud FinOps relies on tags. An EC2 instance carries an owner tag, a cost-center tag, and a product tag, and the showback report writes itself. Agent workloads inherit none of that hygiene automatically. The OpenAI or Anthropic invoice arrives with model names and token counts, not with the feature flag that decided to call the model, the team that owns that feature flag, or the customer whose request triggered the chain. The mapping has to be added by the application, at the moment of the call, or it is lost forever. The cost of skipping this work compounds. When finance asks why spend doubled in March, the engineering answer is usually a guess. When a single customer drives ten percent of total token volume on a fixed-price contract, no one notices until margin calls. When two teams ship agents that quietly share a downstream tool, the invoice attributes everything to the tool owner, not the consumers. Attribution is the foundation under every other FinOps motion: chargeback, showback, forecasting, unit-economics dashboards, and rational budget caps all depend on it. The unit of attribution is the step, not the request A chat completion has one cost surface and is trivial to allocate. An agent run has a tree of surfaces, and each branch has a different rightful owner. The planner step belongs to the agent framework team. The retrieval step belongs to the search team that owns the vector index. The tool call belongs to whichever team published that tool. The synthesis step belongs back to the feature surface. Attribution at the request level collapses all of that into a single line item and destroys the signal. The practical rule is that every model or tool invocation inside an agent run should carry a tag set that identifies the calling feature, the owning team, the customer or tenant on whose behalf the work runs, the environment, and a correlation id that ties sibling steps back to the parent run. Without the correlation id the steps look like noise. With it, the entire fan-out can be reassembled into a per-task ledger. Tag taxonomy that survives contact with engineering Most attribution schemes fail because the tag taxonomy is invented by finance and ignored by engineering, or invented by engineering and unreadable to finance. A workable taxonomy is small, stable, and enforced at the call site. feature - the product surface a user would recognize, such as inbox-triage or contract-redline . team - the engineering team that owns the feature and the budget line behind it. workload_class - interactive, batch, eval, or background. Different classes have different cost expectations. tenant - customer or workspace id when the call runs on behalf of a specific account. environment - production, staging, or eval. Mixing these in one bucket is the most common attribution bug. parent_run_id - the id of the user task that spawned the step. Six tags is enough to answer almost every question finance will ask. More tags do not improve accuracy; they degrade compliance. Where to instrument The cleanest place to attach tags is the gateway or proxy that every agent call already passes through. If a team has standardized on LiteLLM, Helicone, Langfuse, or an internal router, the tag set should be a required field on every request that the gateway refuses to forward without. If there is no gateway, the attribution layer becomes a per-language SDK that wraps the model and tool clients. Either way, the principle is that the application owns the tags and the gateway owns enforcement. Pushing this responsibility into the analytics layer after the fact is how teams end up with sixty percent of spend in an unattributed bucket. Tool-call attribution is its own problem Tool calls inside an agent run are easy to forget because they often look like internal RPCs rather than billable work. They are billable work. A retrieval that fans out into a vector lookup, a reranker, and a downstream embedding refresh has a real cost, and the team that owns the tool is currently absorbing all of it. Attributing tool steps back to the calling agent - and from there back to the feature and team - converts shared infrastructure from a cost center into a chargeback line. That is uncomfortable, which is why most teams avoid it, which is why most teams cannot explain their own invoice. From attribution to chargeback and showback Attribution data on its own is interesting but not actionable. The next step is to publish it on a cadence that finance and engineering both consume. Showback reports surface cost by feature, by team, and by customer without moving money. Chargeback moves the money - the team that owns contract-redline sees the agent spend show up as a real line on their budget, not as an opaque slice of a shared AI envelope. The mechanics are unglamorous. A nightly job rolls up the tagged step ledger into per-feature and per-team aggregates, joins them against a budget table that each team has signed off on, and emits a variance report. Teams over budget get a flagged row. Teams that drove cost on behalf of a specific tenant get a per-tenant breakdown they can use to renegotiate that contract. Finance gets a number it can defend at the next board review. Budget caps as accountability, not throttling A budget cap without an owner is throttling. A budget cap attached to a named feature, a named team, and a public showback report is accountability. The difference matters because throttles produce political fights - engineering pushes back, finance escalates, and the cap is quietly relaxed. Accountability produces conversations. The team that owns the over-budget feature can explain whether the cause is volume growth, a regression, a customer mix shift, or an architectural choice, and can propose a fix with a number attached to it. The healthiest budget caps in agent systems are tiered. A soft cap at the feature level triggers an alert to the owning team. A harder cap at the team level requires acknowledgement before further spend is approved. A global cap at the organization level is reserved for genuine emergencies, because hitting it means the upstream caps already failed and the incident is now about process, not cost. Per-tenant attribution and unit economics Once steps are tagged with tenant, agent spend becomes a per-customer number, and per-customer numbers are how AI businesses survive the transition from flat-rate pricing to usage-aware pricing. A fixed-price contract that delivers an agent feature becomes risky the moment one tenant consumes ten times the median. Attribution surfaces that asymmetry early, while there is still time to renegotiate, add a usage tier, or steer the customer to a cheaper workflow. Without attribution, the asymmetry only shows up as a margin compression nobody can localize. What good looks like Every agent step carries feature, team, workload_class, tenant, environment, and parent_run_id at the call site. The gateway refuses to forward calls missing required tags in production. A nightly rollup produces per-feature, per-team, and per-tenant spend with variance against budget. Showback reports are visible to engineering leads, not just finance. Budget caps are named, owned, and tied to a feature roadmap, not a generic envelope. Tool calls inside agent runs are attributed back to the calling feature, not absorbed by the tool owner. Unattributed spend is under five percent of the invoice and treated as a bug, not a rounding artifact. The cultural shift The technical work of agent attribution is real but solvable. The harder shift is cultural. Engineering teams have to accept that the budget line they signed up for now includes a slice of provider invoices they used to think of as someone else's problem. Finance teams have to learn enough about agent architectures to read the showback reports critically rather than ratifying whatever number comes out of the rollup. Both sides have to agree that the goal is not to minimize spend but to make it legible, so that every dollar of agent cost has an owner who can defend it or change it. That is what FinOps is for, and it is what budget caps actually mean. Related LLM cost attribution LLM budget governance LLM chargeback and showback AI FinOps Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ Why is attribution particularly challenging for agentic workloads? Agentic workloads break most FinOps allocation models because a single user action explodes into a tree of planner calls, tool invocations, retrievals, retries, and a final synthesis. The invoice arrives as one large number from one provider, but the work was actually performed on behalf of dozens of features owned by different teams. Without attribution, the only available cost control is a blunt cap on total spend. What is the unit of attribution for agent workloads? The unit of attribution is the step, not the request. A chat completion has one cost surface and is trivial to allocate. An agent run has a tree of surfaces, and each branch has a different rightful owner. The planner step belongs to the agent framework team. The retrieval step belongs to the search team. The tool call belongs to whichever team published that tool. The synthesis step belongs back to the feature surface. What tags should every model or tool invocation inside an agent run carry? Every model or tool invocation inside an agent run should carry: feature (the product surface a user would recognize), team (the engineering team that owns the feature), workload_class (interactive, batch, eval, or background), tenant (customer or workspace id), environment (production, staging, or eval), and parent_run_id (the id of the user task that spawned the step). Six tags is enough to answer almost every question finance will ask. Where should tags be attached in the agent stack? The cleanest place to attach tags is the gateway or proxy that every agent call already passes through. If a team has standardized on LiteLLM, Helicone, Langfuse, or an internal router, the tag set should be a required field on every request that the gateway refuses to forward without. The application owns the tags and the gateway owns enforcement. How should tool calls be attributed in agent systems? Tool calls inside an agent run are easy to forget because they often look like internal RPCs rather than billable work. Attributing tool steps back to the calling agent—and from there back to the feature and team—converts shared infrastructure from a cost center into a chargeback line. This surfaces the real cost of internal tools and which features are using them. What is the relationship between attribution and budget accountability? A budget cap without an owner is throttling. A budget cap attached to a named feature, a named team, and a public showback report is accountability. Accountability produces conversations where the team that owns the over-budget feature can explain whether the cause is volume growth, a regression, a customer mix shift, or an architectural choice, and can propose a fix with a number attached. How does per-tenant attribution support unit economics in agent systems? Once steps are tagged with tenant, agent spend becomes a per-customer number, and per-customer numbers are how AI businesses survive the transition from flat-rate pricing to usage-aware pricing. A fixed-price contract that delivers an agent feature becomes risky the moment one tenant consumes ten times the median. Attribution surfaces that asymmetry early while there is still time to renegotiate, add a usage tier, or steer the customer to a cheaper workflow. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Agent spend guardrails · FinOps LLM URL: https://finopsllm.com/research/agent-spend-guardrails Agent spend guardrails Updated 11 June 2026 · first published 11 June 2026 Agent workloads are unpredictable in ways that single-call LLM invocations are not. A chat completion hits one endpoint and stops. An agent might retry failed tool calls, loop through retrieval and planning steps, branch into multiple tool invocations in parallel, or escalate to a more expensive model when the cheaper one fails to solve the task. Each of those patterns can explode in cost if not bounded. Guardrails are the runtime safeguards that prevent a production agent from becoming a runaway bill generator. This page is about the technical limits and operational metrics that keep agents from spinning out of control. For ownership and attribution, see Agent spend attribution . Why agents differ from single-call workloads A traditional LLM call is deterministic from a cost perspective. You send tokens, you get tokens back, you pay once. Agents multiply the surfaces where cost can move. A planner step can fail and trigger a retry, which retries the tool call, which triggers another planning step, which calls the tool again. A retrieval tool can fan out into five parallel sub-calls, each with a different token cost. A chain of failures can escalate the model from GPT-4o mini to Claude 3.5 Sonnet halfway through a task. Every intermediate decision is invisible to the invoice, which arrives as a single sum at month-end. The risks compound because they are silent. A retry storm looks identical to normal traffic until the invoice arrives. A loop that should terminate in three steps but terminates in fifteen steps leaves no error log, just a token charge. A tool-call allowlist that is too permissive lets agents discover cheaper tools and silently rewire themselves away from the intended execution path. By the time the cost anomaly is visible, the problem has usually repeated across thousands of tasks. The minimum checklist of guardrails Most agent cost explosions can be prevented by enforcing six classes of limit: 1. Per-run token budget. Every agent invocation should carry a maximum total input + output token limit. If the run exceeds it, the agent stops and returns a cost-limit-exceeded error. This is the primary circuit-breaker. 2. Per-run cost budget. Set an absolute dollar cap per agent run or per task. Especially critical for agents that call multiple models; a fallback from cheap to expensive mid-execution can be caught before completion. 3. Retry caps with exponential backoff. Failed tool calls should retry, but with a hard limit: three retries total, increasing backoff (200ms → 400ms → 800ms), and abort if all retries fail. Retry storms happen when code retries in a loop without bounds. 4. Loop and step limits. An agent should not be allowed to run more than N planning steps (e.g., 20) or more than M tool calls per run (e.g., 50). Either limit indicates a logic error in the planner or a pathological input that the agent cannot solve. 5. Tool-call allowlists and per-tool caps. Only allow the agent to invoke tools that have been explicitly registered. Add a per-tool invocation cap (e.g., "call search tool at most 5 times per run") to prevent fanout explosions. If a tool is not on the allowlist, the agent is not allowed to call it, period. 6. Model-tier ceilings. If an agent can fall back to a more expensive model on failure, set an explicit limit on which models it is allowed to try. For example: GPT-4o mini is the primary; GPT-4o Turbo is allowed for one retry; no fallback to GPT-4. This prevents silent model-upgrade spirals. Operationalizing guardrails: what to measure Guardrails only work if you measure whether they are working. Track these metrics per agent, per feature, and per team: Cost per completed task. The unit of work an end user would recognize. If this number trends upward without a corresponding change in task complexity, a guardrail has failed. Retries per task. The median and p95 retry count. A sudden jump indicates a deployment that broke a downstream tool or an input distribution that changed. Steps per task. The median and p95 planning step count. Steps trending upward usually mean the planner is less capable or the task prompt is drifting. Budget-hit rate. What percentage of runs hit a cost cap, token limit, or step limit. A budget-hit rate above five percent is usually a sign that limits are too tight. Above twenty percent means the limits are not tight enough. Tool-call distribution. Which tools are invoked most frequently and whether that distribution matches expectation. An unexplained spike in calls to an expensive tool is a sign to audit the agent logic. When guardrails fail: the kill-switch No set of static limits survives contact with production forever. An agent that worked fine for three months can suddenly become unstable due to a prompt change, an upstream tool latency regression, a shift in input distribution, or a bug in retry logic. The last line of defense is a kill-switch: an explicit per-agent feature flag that an on-call engineer can flip to disable the agent entirely without a deploy. The kill-switch should be observable in dashboards so the team sees it is active and knows to fix the underlying problem. An agent without guardrails is not an agent; it is a runaway process waiting to happen. Guardrails are not overhead-they are the production difference between a feature and a cost explosion. Related Agent spend attribution - connecting agent cost back to features and teams. Agent guardrails for production - runtime controls and kill switches. LLM budget governance - the broader budget control framework. Token budget implementation - per-model token limits and tracking. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ Why agents differ from single-call workloads? A traditional LLM call is deterministic from a cost perspective. You send tokens, you get tokens back, you pay once. Agents multiply the surfaces where cost can move - retries, retrieval branches, parallel tool calls, and model escalations. Each decision is invisible to the invoice, which arrives as a single sum at month-end. What is the minimum checklist of guardrails? Six classes of limit prevent most cost explosions: (1) Per-run token budget - maximum total tokens before agent stops; (2) Per-run cost budget - absolute dollar cap; (3) Retry caps with exponential backoff - 3 retries maximum; (4) Loop and step limits - max 20 planning steps or 50 tool calls; (5) Tool-call allowlists - only registered tools allowed, per-tool caps; (6) Model-tier ceilings - limit which models agent can fall back to. What should you measure to operationalize guardrails? Track these metrics per agent, per feature, and per team: Cost per completed task, retry rate and retry recovery rate, tool invocation distribution, model-tier distribution, loop depths, and timeout rate. These metrics expose whether guardrails are actually preventing cost explosions or just masking them. When guardrails fail: the kill-switch? No set of static limits survives contact with production forever. An agent that worked fine for months can suddenly become unstable due to prompt changes, tool latency regression, input distribution shift, or retry logic bugs. A kill-switch is an automated or manual circuit-breaker that disables an agent, route, or feature when cost-per-task crosses a moving threshold (e.g. 3× last week's average). Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Agent Spend Guardrails: Runtime Controls That Work · FinOps LLM URL: https://finopsllm.com/research/agent-spend-guardrails-production Agent spend guardrails for production Updated 1 August 2026 Autonomous agents are the most unpredictable workload in AI infrastructure. A single agent run can call a model, invoke tools, retry on failure, escalate to a more expensive model, and loop through planning steps. Without guardrails, a production agent is a runaway cost risk dressed up as a feature. This guide covers the runtime controls that keep agents safe in production. The production guardrail stack Guardrail What it limits Typical value Per-run token budget Total input + output tokens 50K–500K tokens Per-run cost budget Absolute dollar spend per run $0.10–$10.00 Retry cap Repeated tool or model calls 3 retries max Step limit Planning or reasoning iterations 10–50 steps Tool-call allowlist Which tools the agent can invoke Explicit per-agent list Model-tier ceiling Highest-cost model allowed No frontier fallback without approval Kill switch Ability to disable the agent instantly Manual + automated circuit breaker Per-run token and cost budgets Every agent invocation should carry hard limits. A token budget catches runaway context growth. A cost budget catches unexpected model escalation or tool-call fanout. Set both because token count does not always map cleanly to dollars: reasoning tokens, tool-call tokens, and cache misses can make a small token count expensive. When a run hits its budget, the agent should stop and return a clear error, not silently truncate. The caller can then decide whether to retry, escalate to a human, or redesign the task. Retry caps with exponential backoff Failed tool calls should retry, but with strict bounds. A common pattern is three retries with backoff of 200ms, 400ms, and 800ms. After the third failure, the agent aborts. Retry storms happen when code retries in a tight loop without jitter or backoff. The cost compounds because each retry may also trigger a planning step. Step and loop limits An agent should not be allowed to reason indefinitely. A step limit of 20–50 planning iterations catches logic errors and pathological inputs. A loop detector adds extra safety: if the agent revisits the same state multiple times, it should stop. Tool-call allowlists and per-tool caps Agents should only invoke tools that have been explicitly registered for that agent. A general-purpose agent with access to arbitrary tools can fan out into expensive or dangerous calls. Add per-tool invocation caps to prevent abuse: for example, "search tool may be called at most five times per run." Model-tier ceilings If an agent can fall back to a more expensive model on failure, set an explicit ceiling. A typical rule is: primary model is GPT-4o mini or Luna; one retry is allowed on GPT-4o or Terra; no fallback to frontier reasoning models without explicit opt-in. This prevents silent model-upgrade spirals. The kill switch No static guardrail survives production forever. A prompt change, tool latency regression, or input distribution shift can make a stable agent unstable. The last line of defense is a kill switch: a feature flag or circuit breaker that disables the agent without a deploy. Kill switches should be observable. When active, the team should see it in dashboards and receive an alert. The goal is not just to stop the bleeding but to fix the underlying cause. Measuring whether guardrails work Guardrails are only effective if you measure them. Track these metrics per agent and feature: Cost per completed task. The ultimate guardrail effectiveness metric. Budget-hit rate. Percentage of runs that hit a token, cost, or step limit. Retries per task. Median and p95. A sudden jump signals a problem. Steps per task. Reveals planner drift or prompt degradation. Tool-call distribution. Unexpected spikes in expensive tools warrant audit. Kill-switch activations. Should be rare; investigate every one. An agent without guardrails is not production-ready. Guardrails are not overhead; they are the difference between a reliable feature and a surprise invoice. Related Agent spend guardrails — the foundational guide. Agent spend attribution — connecting agent cost to features and teams. Token budget implementation — per-model token limits. LLM budget governance — the broader budget framework. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What are agent spend guardrails? Agent spend guardrails are runtime limits that prevent autonomous AI agents from generating unexpected costs. They include token budgets, cost caps, retry limits, step limits, tool-call allowlists, model-tier ceilings, and kill switches. What is the most important guardrail for production agents? A per-run cost cap is the most important guardrail because it is the last line of defense against runaway spend. Even if other limits fail, a dollar cap stops the agent before the bill becomes severe. How do I monitor if agent guardrails are working? Track cost per completed task, retries per task, steps per task, budget-hit rate, tool-call distribution, and kill-switch activations. Trends in these metrics reveal whether guardrails are preventing cost explosions or just masking them. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Agent TCO: The 70% of Cost That Isn't Tokens · FinOps LLM URL: https://finopsllm.com/research/agent-total-cost-of-ownership Agent total cost of ownership: the 70% of agent cost that isn't tokens Updated 19 July 2026 Teams running production AI agents often track only one cost: model tokens. The bill from OpenAI or Anthropic feels like "the" LLM cost. But that's typically only 10–30% of the real expense. The rest hides in evaluation burn, observability tooling, platform staffing, model drift correction, compliance overhead, and retry waste — costs that grow faster than token spend and often go unbudgeted until they surprise you. This article gives you a practical total cost of ownership (TCO) formula, breaks down each component with realistic numbers, and walks through a worked example. By the end, you'll know where to measure and what levers to pull to reduce agent cost. The TCO anatomy: where agent cost really lives Production token spend (10–30%) — tokens consumed by live agent execution. This is the most visible cost and the one most teams track first. Evaluation token burn (20–60%) — tokens consumed by test suites, validation runs, and regression testing. A comprehensive evaluation suite runs on every release and often consumes more tokens than production traffic. Industry reports on code-review agents show evaluation token spend as high as 59% of total token consumption. Observability and monitoring (5–15%) — infrastructure for logging, tracing, metrics, and alerting. As agents get more complex, observability cost grows faster than production workload. Platform staffing (15–35%) — engineering time to maintain the agent framework, handle model updates, debug failures, and tune performance. A team running 8–15 agents might need 2–3 full-time platform engineers; attributing this cost fairly shows why most solo agents are expensive. Model drift correction (5–10%) — evaluation and retraining runs triggered by new model releases or performance degradation. When a provider ships a new model version, you run your eval suite against it; when performance drifts, you run corrective fine-tuning or re-prompting. Compliance and audit overhead (3–8%) — token audits, data retention, anonymization, and regulatory logging. In regulated industries (finance, healthcare), this cost is often overlooked in early pilots but becomes material at scale. Retry and loop waste (2–15%) — tokens burned on failed attempts, retries after errors, and loops that produce no user value. Poorly tuned retry logic or uncontrolled agentic loops can waste 10–20% of your token budget. The TCO formula Total Cost of Ownership (annual) = (Production tokens × rate) + (Evaluation tokens × rate) + (Observability cost) + (Platform staffing / agent count) + (Model drift evaluation cost) + (Compliance overhead) + (Retry waste cost) Then divide by annual successful agent executions to get real cost per useful task : Cost per useful task = TCO / Successful executions This differs from "cost per token" or "cost per execution" because it includes all the hidden expenses and only counts tasks that produce value. Worked example: a code-review agent Let's build out a realistic scenario for a team running an AI code-review agent in production. This agent reviews pull requests, checks for common issues, and suggests refactors. The team is 30 engineers, and ~50 PRs are opened per day (or ~1,500 per month). Component 1: Production token spend Item Volume Rate Monthly cost Annual cost Avg tokens per review 2,500 input + 500 output — — — Monthly reviews 1,500 — — — Total production tokens 4.5M input + 0.75M output Claude Sonnet 4 ($3/M in, $15/M out) $25.65 $308 Component 2: Evaluation token burn The team maintains a regression test suite of 800 test cases (real PRs with known good answers). They run it before every release (2×/week), plus on-demand when debugging failures. Each test case consumes ~4,000 tokens end-to-end. Item Volume Rate Monthly cost Annual cost Test cases 800 — — — Tokens per test 4,000 — — — Scheduled runs/month 8 (2×/week) — — — On-demand runs/month 4 (debug, pre-release) — — — Total eval runs 12 — — — Total eval tokens 38.4M Claude Sonnet 4 ($3/M in, $15/M out) $230.40 $2,765 Key observation: Evaluation tokens (2.765K/year) exceed production tokens (308/year) by ~9×. This is typical for code-review agents where correctness matters and model updates need validation. Component 3: Observability infrastructure The agent logs every review request + response to a tracing backend (OpenTelemetry), metrics to Prometheus, and stores structured logs for audit. Infrastructure cost breakdown: Component Cost/month Annual cost Notes OpenTelemetry backend (self-hosted EC2) $150 $1,800 1 t3.large for trace storage + retention Structured logs (S3 + Athena) $80 $960 ~1,500 logs/month × 2KB each; query cost Metrics (Prometheus SaaS tier) $200 $2,400 1M+ series for per-model/per-project tracking Alerting (PagerDuty for on-call) $50 $600 Minimal tier, basic escalation Total observability $480 $5,760 — Component 4: Platform staffing The team has 1.5 FTE platform engineers (a lead + a junior, shared across 3 agents) dedicated to: agent framework maintenance, model updates, debugging, performance tuning, and integration with the CI/CD pipeline. Allocated staffing cost per agent: Item Annual cost Notes Platform team (1.5 FTE) $240,000 $120K lead + $80K junior + 40% benefits/overhead Agents supported 3 code-review, security-scan, performance-audit Cost per agent $80,000 Allocated evenly Component 5: Model drift correction When Claude ships a new version (2–3× per year), the team runs the full eval suite against it and benchmarks performance. If performance dips, they run targeted re-evals and sometimes fine-tuning experiments. Estimated annual cost: Item Cost Notes Per-model release eval (3/year) $2,400 Full 800-test suite × 3 times = 2.4M tokens × $0.003/token avg Performance investigation (2 instances/year) $800 Targeted evals + manual review Fine-tuning experiments (if needed) $1,500 Training + validation; happens ~1 time/year Total drift correction $4,700 — Component 6: Compliance and audit overhead The team's company is in fintech and subject to compliance audits. For each agent, they log: who triggered it, inputs, outputs, reasoning chain, timestamp. This requires: Item Cost Notes Compliance log storage (encrypted S3) $300/year ~1.5 GB/month compressed; 7-year retention Quarterly audit runs (prepare audit data) $600/year Manual work: extract, anonymize, prepare for auditors (4 hrs × $150/hr) Data retention & deletion (policy enforcement) $200/year Cron jobs to handle GDPR/CCPA deletion requests Total compliance $1,100/year Higher in regulated industries; lower elsewhere Component 7: Retry and loop waste The agent is configured to retry failed reviews up to 2 times before escalating to a human. In practice: Item Rate Volume Cost Notes First-pass success rate 92% — — — Retried (failed once, succeeded on retry) 6% 90 reviews/month $1.84 Counts as 50% cost of full review Escalated (failed twice, sent to human) 2% 30 reviews/month $0 No token cost (human takes over) Total retry waste — — $22/year ~7% of production token cost Annual TCO and cost per useful task Putting it all together: Component Annual cost % of TCO Production tokens $308 0.2% Evaluation tokens $2,765 1.8% Observability $5,760 3.8% Platform staffing $80,000 52.8% Model drift correction $4,700 3.1% Compliance overhead $1,100 0.7% Retry waste $22 0.01% Total annual TCO $94,655 100% The team runs 1,500 reviews/month; 92% are successful on first pass, yielding ~16,560 useful reviews per year. Cost per useful task: $94,655 / 16,560 useful reviews = $5.71 per review Even though the token cost per review is ~$0.017, the real cost to the business is $5.71 once you account for staffing, evals, and infrastructure. That's 336× higher. The leverage points: where to cut Reduce evaluation frequency and coverage. The example spends $2,765/year on evals — 9× production tokens. If the team runs evals 2×/month instead of 2×/week, they save ~$2,070/year. But cut too much and you miss drift or regressions. The minimum is probably 1–2 eval runs per release, not on-demand. Consolidate observability tooling. Running a full OpenTelemetry stack, Prometheus, and custom audit logging costs $5,760/year. Many teams use a SaaS platform (Datadog, New Relic) instead, which costs $500–1,000/month but includes all three. For a single agent, SaaS is cheaper; at 3+ agents, self-hosted infrastructure wins because you share the cost across agents. Share platform staffing. The biggest lever is staffing. One agent with 1.5 dedicated FTE is expensive; 10 agents with a shared 3-FTE team is much cheaper per agent. But this only works if the team operates a common framework that agents can plug into. The crossover is around 8–15 agents where dedicated platform investment starts paying for itself. Automate drift detection. Instead of running full evals on every new model release, run a fast smoke test (10% of test cases) first. If that passes, assume the model is safe. If it fails, escalate to a full eval. This cuts model drift cost from $4,700 to ~$1,000/year. Set retry budgets and escalate early. Poorly configured retry loops can waste 10–20% of tokens. Set a hard retry limit (2 attempts max) and escalate to humans. The token waste is small in this example ($22/year) because retries are already capped. Batch compliance audits. Instead of preparing audit data on demand, run a batch job quarterly. This shifts from $600/year of manual work to $200/year of automated ETL. Requires upfront investment in audit log infrastructure but pays for itself quickly. When to build vs. buy agent infrastructure The staffing cost in the example ($80K/agent/year) suggests a buy-vs-build decision: For 1–5 agents: Buy. Use an existing platform (Langchain, Anthropic's Agents API, or a SaaS wrapper). Your agent can't justify a dedicated platform team, so outsourced infrastructure is cheaper. For 5–15 agents: Evaluate. A 2-FTE platform team (~$240K/year) can support 8–15 agents, pushing per-agent staffing cost down to $16–30K/year. At 10 agents, that's a $50–70K savings vs. buying a SaaS for each. But only if you build a reusable framework; ad-hoc infrastructure per agent is expensive and doesn't scale. For 15+ agents: Build. A shared platform pays for itself and becomes a competitive advantage. Teams at scale (50+ agents) invest in proprietary frameworks and dedicated platform teams. Measuring your own agent TCO Start here: Production tokens: Query your LLM provider's dashboard or billing API. Break down by agent and model. Evaluation tokens: Track eval runs in a spreadsheet. Multiply (test cases × tokens per case × runs per month × 12). Don't estimate; measure for one month and extrapolate. Observability cost: Audit your cloud and SaaS bills. Tag expenses by agent. If you don't tag, use allocation: (observability cost) × (agent traffic / total traffic). Platform staffing: Ask your engineering leadership. Get a load factor (% of time each engineer spends on agent infrastructure). Allocate fairly across agents. Drift correction & compliance: Use the examples above as a starting point. Your numbers will differ based on industry and release cadence. Retry waste: Log every LLM call with (attempt_number, success). Calculate (tokens where attempt > 1) / (total_tokens). Once you have a baseline TCO, prioritize cuts by impact. Staffing is usually 50%+ of cost; observability and evals are the next levers. Focus there first. Related Agent economics: how much does a coding agent actually cost? - subscription vs. API pricing for user-facing agents. Agent spend attribution - how to track costs across multiple agents and projects. Eval cost allocation - breaking down evaluation spend by model, task, and test suite. Hidden LLM costs - infrastructure, retry chains, and observability overhead beyond tokens. Ready to audit your agent TCO? FinOps LLM runs a free analysis of your LLM spend—production, evaluation, infrastructure, staffing—and shows where to cut. Book free audit → Back to research FAQ What percentage of agent cost is production token spend? Production token spend is typically 10–30% of total agent cost. The remaining 70–90% covers evaluation burns, observability infrastructure, platform staffing, model drift correction, compliance overhead, and retry/loop waste. How much do agent evaluations cost? Evaluation costs depend on suite size and frequency. A comprehensive eval suite (1K test cases, running 3×/week) consumes 20–150M tokens/month — often more than production traffic. Industry reports show eval token spend as high as 59% of total token consumption for code-review agents. What is the TCO formula for agents? TCO = Production tokens + Evaluation tokens + Observability infrastructure + (Platform staffing cost / agent count) + Model drift correction + Compliance & audit overhead + (Retry waste rate × production token cost). Divide by annual successful agent executions for true cost per useful task. How do I reduce agent TCO? Reduce eval frequency and coverage (but not below quality threshold), consolidate observability tooling, automate drift detection, batch compliance audits, and set retry budgets. The biggest wins typically come from eval optimization and staffing efficiency (shared platform team across multiple agents). Should I build or buy agent platforms? For 1–5 agents, buy (use existing platforms). Platform staffing costs become justified around 8–15 agents where a dedicated team can share infrastructure. Below that threshold, overhead per agent exceeds the cost of per-SaaS pricing. How much platform staffing per agent? A platform engineering team of 2–3 FTE can support 8–15 agents in steady state. Each FTE costs ~$120–180K/year loaded. Attributing this to 10 agents means ~$24–54K per-agent-per-year in staffing, on top of token and infrastructure costs. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Web search is becoming an agent cost center · FinOps LLM URL: https://finopsllm.com/research/agent-web-search-cost-center Web search is becoming an agent cost center Updated September 10, 2026 · first published September 10, 2026 Quick answer: Agents are moving from static knowledge to live web research, and that changes the cost model. A single user request can now trigger several searches, a model call to interpret each result, tool... Agents are moving from static knowledge to live web research, and that changes the cost model. A single user request can now trigger several searches, a model call to interpret each result, tool retries, and a final synthesis. The search layer is no longer invisible infrastructure; it is a separately metered part of the task. Amazon Bedrock AgentCore, for example, documents Web Search as a usage-priced capability at $7 per 1,000 queries. The exact price will vary by provider and product, but the FinOps lesson is universal: count tool calls as billable work alongside input and output tokens. See the AWS announcement for the current example. One prompt can become many searches Search amplification comes from planning. An agent may rewrite a question, search several sources, follow a result, retry a timeout, and search again after finding conflicting evidence. If the application reports only the user's original prompt, finance sees a low-volume feature while the provider sees a high-volume tool workload. Record the parent task ID, search provider, query count, result fetches, retry count, and whether the result changed the final answer. Then calculate search cost per successful task. A search that never contributes to a useful answer is a candidate for a policy change, not just a line item to accept. Control the search budget Set a maximum search-query budget per task and per user tier. Use a cheaper first pass for discovery, then reserve deep research for high-value tasks. Cache stable queries and normalize harmless wording differences. Stop after the evidence threshold is met instead of letting the planner keep exploring. Make retries exponential and cap them independently from model retries. Measure freshness against spend Freshness is valuable only when it changes the decision. Compare answer quality and task success across search depths: no search, one search, and bounded multi-search. Some workflows need current information; others are paying for repeated retrieval of facts that change slowly. Report three numbers together: model cost, search cost, and cost per successful task. This prevents a cheaper model from looking efficient when it is compensating with a large number of paid searches. It also gives product teams a defensible way to decide when live web grounding is worth the premium. Related MCP server cost impact Agent total cost of ownership Cost per successful task Related MCP server cost impact Agent total cost of ownership Cost per successful task Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Why agentic AI blows the budget · FinOps LLM URL: https://finopsllm.com/research/agentic-ai-budget-overruns Why agentic AI blows the budget Published 15 August 2026 A review of 127 enterprise agentic AI implementations found 73% ran over budget, some by more than 2.4x, with an average of $2.3M in costs nobody had modelled. That is not a failure rate for agents. It is a failure rate for agent forecasting - most of those projects shipped and worked. What broke was the estimating method. Why the estimate is structurally wrong When three-quarters of a category miss in the same direction, that is not variance. A per-call price multiplied by expected requests is correct arithmetic for an API and wrong arithmetic for an agent, because the agent decides how many calls a request costs. The clearest public case is Uber: Claude Code to roughly 5,000 engineers in December 2025, entire annual AI budget gone by April 2026, at $500 to $2,000 per engineer per month. Nobody misused it. The forecast assumed a seat had a price; a seat turned out to have a consumption profile. The same pattern showed up industry-wide in H1 2026, with teams reporting they were 3x over their whole-year token budget by May. Where the $2.3M actually goes Cost Why the pilot missed it Shape at scale Orchestration multiplier The pilot measured one call. Production runs a loop. 10-50 model calls per user-visible action. Retries and tool loops Failure paths were not in the demo. An agent that cannot finish retries until it hits a cap, if one exists. Evaluation Quality was judged by hand at pilot size. The eval harness routinely costs more than the feature it grades. See eval cost allocation . Integration and human review Scoped as engineering time, not run-rate. Recurring monthly, indefinitely, on anything customer-facing. Almost none of it is the token price, which is why optimizing the model choice does not close the gap. See hidden LLM costs and agent total cost of ownership . Instrument the multiplier before the rollout The one measurement that changes the forecast: for each agent workflow, how many model calls does one completed user task generate, including retries? Instrument it in the pilot and the pilot becomes useful. Report only a monthly cost figure and it did not de-risk anything. Emit call counts per task, not just per request. Tag a task ID at the gateway and count calls against it. See agent spend attribution . Denominate the budget in tokens per completed task. Dollars per seat drifts with pricing and hides volume growth. Model the eval and human review line explicitly. If it is not on the forecast it will be the biggest surprise on the invoice. Forecast a range with a named driver. "$400k-$1.1M depending on whether adoption reaches 40% or 90%" is actionable. A single number is a hostage. Overrun is not waste Two different failures get merged when a freeze gets proposed. Overrun means the forecast was wrong and the spend may have been entirely worth it. Waste means the spend produced nothing. Uber's engineers presumably got real value; whether it was worth $500 to $2,000 a month is a separate question from whether anyone predicted it. Reporting these separately is what keeps a good programme alive through a bad quarter. It also requires a value metric, not just a cost one - see AI value management . The one control worth having first A hard consumption ceiling per agent, enforced at the gateway, with a named approval path to raise it. Soft budgets are reporting; an agent in a retry loop can spend a quarter's allocation over a weekend and no monthly variance review catches that in time to matter. The ceiling has to live where the requests are. See agent spend guardrails in production and capping inference costs . For coding agents specifically - the category behind the most dramatic 2026 overruns - see the true cost of coding agents . Related Agent total cost of ownership - the full-cost model. Agent spend guardrails in production - the enforcement layer. Agent economics - why the unit is the task, not the call. The true cost of coding agents - the worst-hit category. Hidden LLM costs - what the token line never shows. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ How often do agentic AI projects go over budget? A review of 127 enterprise agentic AI implementations found 73% ran over budget, some by more than 2.4x, averaging $2.3M in costs that were never modelled. When almost every project in a category misses in the same direction, the estimating method is wrong rather than the execution. Where does the unmodelled cost actually go? Almost none of it is the token price. It clusters in the orchestration multiplier - the model calls one user action generates - plus retries and tool loops, evaluation harnesses that often cost more than the feature they grade, and recurring integration and human review. What is the orchestration multiplier? The ratio of model calls to completed user tasks, including retries. It is the single most important number in an agent forecast and the one almost nobody measures. Pilots typically assume single-digit multipliers; production agent loops routinely run 10 to 50 calls per user-visible action. What happened at Uber? Uber rolled Claude Code out to roughly 5,000 engineers in December 2025 and had spent its entire annual AI budget by April 2026, at $500 to $2,000 per engineer per month. The deployment worked; the forecast failed, because a seat was priced as a licence when it behaved as a consumption profile. Is an overrun the same as waste? No. Overrun means the forecast was wrong; waste means the spend produced nothing. Most 2026 overruns happened on projects that worked. Conflating them turns a forecasting problem into a cancellation decision, which destroys value to fix a spreadsheet. What is the fastest control to put in place? A hard per-agent consumption ceiling enforced at the gateway, with a named approval path to raise it. Soft budgets are reporting, not control - an agent stuck in a retry loop can spend a quarter's allocation over a weekend, and no monthly review catches that in time. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # AI Coding Economics 2026: GLM vs DeepSeek vs Claude · FinOps LLM URL: https://finopsllm.com/research/ai-coding-economics-2026 The 2026 AI Coding Economics Updated 12 July 2026 · first published 8 July 2026 When an agentic coding assistant like Cline, OpenClaw, or Claude Code iterates through a large repository, token volume scales exponentially. Every turn re-reads the conversation history and codebase context. That makes interactive AI coding fundamentally a test of cache-hit pricing. Four providers dominate the 2026 developer ecosystem, each operating on a radically different economic philosophy: DeepSeek V4 Pro - the aggressive price-war instigator. MiMo v2.5 Pro - the DeepSeek clone that matches its baseline but adds off-peak discounts. GLM 5.2 - the engineering marvel with a 99% cache hit rate, but premium baseline pricing. Claude Sonnet 5 - the undeniable heavyweight champion of reasoning, burdened by massive API costs. Here is the definitive mathematical breakdown of what it actually costs to run a heavy AI coding agent for a month. The benchmark: 32 million input tokens per day A heavy multi-file refactoring session with an agent will easily consume: 32,000,000 input tokens per day - the vast majority cached context reads. 200,000 output tokens per day - the actual code generated. We run this workload for 30 consecutive days across all four models on a pure pay-as-you-go API basis. DeepSeek and MiMo prices are converted from domestic CNY to their standard international USD equivalents. Provider & Model Cache Hit % Cached Input ($/M) Miss Input ($/M) Output ($/M) DeepSeek V4 Pro 95% $0.0035 $0.435 $0.87 MiMo v2.5 Pro 91% $0.0035 $0.435 $0.87 GLM 5.2 99% $0.2600 $1.400 $4.40 Claude Sonnet 5 90% $0.3000 $3.000 $15.00 The daily and monthly API bill 1. DeepSeek V4 Pro (95% cache hit) Hits: 30.4M × $0.0035 = $0.10 Misses: 1.6M × $0.435 = $0.69 Output: 0.2M × $0.87 = $0.17 Daily: ~$0.97 → Monthly: $29.28 2. MiMo v2.5 Pro (91% cache hit) Hits: 29.12M × $0.0035 = $0.10 Misses: 2.88M × $0.435 = $1.25 Output: 0.2M × $0.87 = $0.17 Daily: ~$1.52 → Monthly: $45.81 3. GLM 5.2 (99% cache hit) Hits: 31.68M × $0.26 = $8.23 Misses: 0.32M × $1.40 = $0.44 Output: 0.2M × $4.40 = $0.88 Daily: ~$9.56 → Monthly: $286.92 4. Claude Sonnet 5 (90% cache hit) Hits: 28.8M × $0.30 = $8.64 Misses: 3.2M × $3.00 = $9.60 Output: 0.2M × $15.00 = $3.00 Daily: ~$21.24 → Monthly: $637.20 The caching trap Look closely at the math above. GLM achieves an unprecedented 99% cache hit rate - the agent rarely processes cold data. But because Z.AI charges $0.26 per million cached tokens, those "cheap" cache reads cost 74 times more than DeepSeek's $0.0035. A 99% hit rate cannot save you when the floor price is too high. For Claude, the $637 calculation assumes Anthropic's prompt caching works flawlessly. In reality, the May 2026 Claude Code update (v2.1.100+) introduced caching bugs that frequently force a full context re-read from scratch. At $3.00/M for a cache miss, the real-world API bill for this workload can easily clear $1,200/month . The formula: cache hit rate reduces how much of the expensive component you pay. But if the expensive component itself costs 74× more, no hit rate can close the gap. Per-100-token comparison This is the cleanest way to see why cache hit rate alone doesn't tell the story: Provider Cost per 100 input tokens DeepSeek V4 Pro 95 × $0.0035 + 5 × $0.435 = $2.50 MiMo v2.5 Pro 91 × $0.0035 + 9 × $0.435 = $4.23 GLM 5.2 99 × $0.26 + 1 × $1.40 = $27.14 Claude Sonnet 5 90 × $0.30 + 10 × $3.00 = $57.00 GLM's cache-hit portion alone ($25.74) exceeds the total input cost of DeepSeek ($2.50). Claude costs 22× DeepSeek. MiMo trails slightly behind DeepSeek because of its lower cache hit rate, but both operate in the same cost universe. GLM and Claude live in entirely different ones. Back-calculating: what price would GLM need to beat DeepSeek? Assuming GLM's miss ($1.40) and output ($4.40) prices stay fixed, what cached input price would make GLM's monthly total match DeepSeek's? GLM daily target: $0.97 (DeepSeek's daily cost) 31.68M × X + 0.32M × $1.40 + 0.2M × $4.40 = $0.97 31.68X + $0.44 + $0.88 = $0.97 31.68X = −$0.35 There is no positive price that works. Because GLM's miss and output prices are both higher than DeepSeek's, they already consume more than DeepSeek's total daily budget. The cached input price would need to be negative to close the gap. That is impossible under the current pricing structure. The subscriptions: what they are, what they are not Because spending $637–$1,200/month on Claude API is untenable and GLM's $287 is steep, the industry pushes developers toward "Max" subscriptions. But these plans operate on completely different mechanics. MiMo Token Plan Max ($100/mo) What it is: a massive pre-paid bucket of 82 billion API credits with transparent per-token deduction. Every token has exactly the same cost as the raw API - there is no flat-rate fiction. What it is not: an unlimited subscription. An infinite-loop script will drain the bucket and stop. The catch (the good kind): MiMo applies a 0.8× discount multiplier during off-peak hours (midnight to 8 AM Beijing time). Solo developers coding at night stretch their credits 20% further. Because the underlying API is already so cheap (~$46/month for this benchmark), a single developer literally cannot spend $100/month on MiMo. This tier only makes sense for multi-agent swarms or teams. Claude Code Max 20× ($200/mo) What it is: a high-ceiling flat-rate subscription that caps spending and gives access to the industry's smartest model for everyday coding. What it is not: unlimited access. It has rolling 5-hour hard throttles tied to token consumption. Claude Code resends your entire conversation on every turn - message 50 costs far more than message 5. The catch (the bad kind): the prompt-caching bug mentioned above inflates token consumption by ~40% because it forces full context re-reads on almost every turn. The $200 Max 20× tier effectively exists because heavy developers burn through the lower $100 tier due to unpatched cache misses. You are paying a premium for Sonnet 4.6's reasoning, while managing a strict 5-hour clock. Reserved for the hardest problems where only Sonnet works. GLM Coding Plan Max ($144/mo) What it is: a flat-rate subscription with priority compute and access to the 99% cache-hit GLM 5.2. What it is not: predictable. The catch (the ugly kind): GLM applies a 3× consumption multiplier during peak hours. If you code on a Tuesday afternoon, your quota drains three times faster than at midnight. Off-peak still hits you with a 2× multiplier. You are buying a generous pool of prompts, but the burn rate is highly volatile depending on the clock. GLM's 99% cache hit rate saves Z.AI's server costs under a flat rate - not yours. You pay a fixed subscription regardless of cache efficiency. The multiplier war: peak vs. off-peak Provider Peak Hours Off-Peak Hours MiMo Token Plan 1.0× (standard) 0.8× (discount) GLM Coding Plan 3.0× (penalty) 2.0× (penalty) Claude Code Max Throttled (rolling 5h) Throttled (rolling 5h) DeepSeek (API) Always 1.0× Always 1.0× DeepSeek has no multipliers - no peak penalties, no off-peak discounts, no subscriptions at all. You pay exactly the API rate every hour of the day. That simplicity is part of why it wins on cost for pure API workloads. Monthly cost at a glance Model / Plan Monthly Cost Throttles / Penalties DeepSeek V4 Pro (API) $29.28 None - flat 1.0×, no rate limits for reasonable volume MiMo v2.5 Pro (API) $45.81 None - but 0.8× reward for off-peak MiMo Token Plan Max $100.00 Bucket cap. 82B credits - a solo dev cannot exhaust it GLM 5.2 (API) $286.92 None - pay-as-you-go, no multipliers GLM Coding Plan Max $144.00 3× peak / 2× off-peak quota multipliers Claude Sonnet 5 (API) $637–$1,200 None - but price alone is the hard throttle Claude Code Max 20× $200.00 Rolling 5h hard cap + caching-bug overhead The final verdict The budget play: Do not buy a subscription at all. Wire your IDE directly to the DeepSeek V4 Pro or MiMo v2.5 Pro pay-as-you-go API. You will spend under $50/month for unlimited, unthrottled, 24/7 autonomous coding at DeepSeek-level pricing. No multipliers. No quota walls. Just transparent per-token billing at the lowest rates available. The premium play: Claude Code Max 20× ($200). Sonnet 4.6 (now Sonnet 5) is unparalleled for complex logic, zero-shot refactoring, and architectural reasoning. Use it carefully - run /compact frequently to save context, treat the 5-hour limit as a pacing mechanism rather than a failure, and accept that you will occasionally hit rate limits. For the hardest coding problems, nothing else matches the intelligence. The compromise (GLM 5.2): At $287/month via API and $144/month for a heavily-throttled subscription with punishing peak-hour multipliers, GLM 5.2 is caught between worlds. Its 99% cache hit rate is genuinely an incredible engineering achievement, but the $0.26/M cached input price means it cannot compete with DeepSeek/MiMo on pure API cost. Under the flat-rate subscription, the 99% hit rate lowers Z.AI's compute costs, not yours - you pay a fixed price and absorb quota multipliers regardless. For developers working consistent daytime hours, the 3× peak multiplier makes the $144 plan deeply unpredictable. Operating principle: pay-as-you-go pricing rewards cheap unit economics (DeepSeek, MiMo). Flat-rate subscriptions reward the provider's server efficiency (GLM's cache hits lower their costs, not yours). Cache hit rate amplifies whichever underlying pricing advantage or disadvantage exists - it does not rewrite the fundamentals. Sources and references DeepSeek V4 Pro pricing: official pricing following the May 22, 2026 permanent price cut. DeepSeek models and pricing MiMo v2.5 Pro pricing: official pricing following the May 27, 2026 permanent price cut (price-matched to DeepSeek). GLM 5.2 pricing: Z.AI official API documentation - $1.40/M input, $0.26/M cached input, $4.40/M output. Z.AI pricing GLM Coding Plan: international subscription tiers confirmed July 2026 - Lite $18/mo, Pro $72/mo, Max $160/mo ($144 renewal). 3× peak / 2× off-peak multipliers confirmed via usage documentation. Claude Sonnet 5 pricing: Anthropic official - $3.00/M input, $15.00/M output, prompt caching at $0.30/M cached input. Claude Code caching inefficiencies: documented in Claude Code v2.1.100+ May 2026 changelog and developer reports. API conversion rates: ¥0.025/M ≈ $0.0035/M, ¥3/M ≈ $0.435/M, ¥6/M ≈ $0.87/M (CNY domestic pricing converted at approximate July 2026 rates). Related The true cost of coding agents - API bills, retries, review, and technical debt. AI coding plan comparison - the full sortable table of plans, limits, and model scores across 9 providers. Cheapest way to run AI code generation (2026) - broader guide across subscription, API, self-hosted, and coding plan categories. Caching strategies compared - when prompt caching pays off and when it doesn't. LLM API pricing tracker - live view of provider unit prices. Model routing - sending tasks to the right cost tier. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What makes 2026 AI coding economics different? When agentic coding assistants iterate through large repositories, token volume scales exponentially as every turn re-reads the conversation history and codebase context. This makes interactive AI coding a test of cache-hit pricing. The benchmark uses a 32-million-token daily input workload with 200,000 output tokens across four providers: DeepSeek, MiMo, GLM, and Claude. How does cache hit rate affect total cost? Cache hit rate reduces how much of the expensive component you pay, but if the expensive component itself costs 74× more, no hit rate can close the gap. GLM achieves 99% cache hits but charges $0.26/M for cached tokens vs DeepSeek's $0.0035, making cache-hit portions far more expensive than DeepSeek's entire input cost. What are the monthly costs across providers? DeepSeek V4 Pro (API): $29.28/month, MiMo v2.5 Pro (API): $45.81/month, GLM 5.2 (API): $286.92/month, Claude Sonnet 5 (API): $637–$1,200/month. GLM's 99% cache hit rate cannot overcome its higher baseline pricing. What pricing structure do the subscription plans use? MiMo Token Plan Max ($100/mo) offers pre-paid credits with 0.8× off-peak discount. Claude Code Max 20× ($200/mo) is flat-rate with rolling 5-hour throttles and prompt-caching bugs forcing full re-reads. GLM Coding Plan Max ($144/mo) applies 3× peak and 2× off-peak quota multipliers, making burn rate highly volatile. Should I use API pricing or subscriptions? For budget: use DeepSeek or MiMo pay-as-you-go API with no multipliers or subscriptions ($29–$46/month). For premium reasoning: use Claude Code Max 20× ($200/month) for complex logic and architectural problems. GLM 5.2 is caught between worlds—its API pricing cannot compete with DeepSeek, and its subscription has unpredictable peak-hour multipliers. Why can't GLM's cache efficiency make it competitive? Under pay-as-you-go, GLM's miss and output prices are already higher than DeepSeek's total daily cost, making cached input price irrelevant—no positive price works. Under subscriptions, GLM's 99% cache hit rate lowers Z.AI's server costs, not the subscriber's costs. You pay a fixed price regardless of cache efficiency and absorb quota multipliers instead. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # AI Cost Allocation: Tags, Cost Centers and Chargebacks · FinOps LLM URL: https://finopsllm.com/research/ai-cost-allocation AI cost allocation AI cost allocation is the practice of assigning AI spend to the teams, products, features, or customers that caused it. Without allocation, the AI bill is just a central cost. With it, every stakeholder can see and manage their own footprint. Why allocation matters AI spend is granular and tied to usage. A single feature or customer can drive a disproportionate share of the cost. Allocation makes that visible. It is the foundation of showback, chargeback, budgeting, and optimization. The tagging strategy Every request should carry enough metadata to allocate it later. The minimum set is: Team or cost center — who owns the budget. Project or feature — what the request supports. Customer or tenant — who triggered the cost, for multi-tenant products. Model and provider — which infrastructure was used. Environment — production, staging, or development. Allocation methods Direct allocation — when a request maps cleanly to one owner. Proportional allocation — splitting shared costs by a driver such as requests or tokens. Activity-based allocation — assigning costs by business activity, such as a support ticket resolution. From allocation to action Once costs are allocated, you can show them back to teams, charge them back, set budgets, and identify optimization opportunities. For the billing mechanics, see LLM chargeback and showback . Where allocation usually breaks Three gaps account for most unallocated LLM spend. Retries and fallbacks bill against a request the user only saw once, so a naive join under-counts the expensive endpoints. Shared infrastructure — an embedding index or a re-ranking model serving several features — has no single owner, and teams either drop it or dump it on whoever built it. Background work such as nightly evals, enrichment, and index rebuilds carries no user context at all, so it lands in an "unattributed" bucket that quietly grows into the largest line item. Fix them in that order. Tag the retry with the parent request ID, allocate shared services proportionally by a driver everyone accepts, and give background jobs their own cost center rather than forcing them into a product tag. How accurate does allocation need to be? Accurate enough that no owner disputes it, which is usually 90-95%, not 100%. Chasing the last few percent costs more engineering time than the spend it explains. Set an explicit unallocated threshold — 5% is a reasonable starting target — publish it alongside the report, and treat crossing it as the signal to invest in tagging again. Should allocation happen at request time or in the warehouse? Both. Attach ownership metadata at request time, because that context is unrecoverable later, and do the arithmetic in the warehouse, where you can reconcile against the invoice and restate history when a tagging bug is found. Systems that only allocate at query time cannot answer "who spent this" for any traffic that predates the fix. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is AI cost allocation? AI cost allocation is the practice of assigning AI and LLM spend to the teams, products, features, or customers that caused it. How do you allocate LLM costs? Allocate LLM costs by tagging every request with team, project, feature, model, and customer, then rolling up the spend by those dimensions. What is the difference between cost allocation and chargeback? Cost allocation is the process of assigning costs. Chargeback is the process of billing those costs to another team or department. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # AI Cost Optimization: Routing, Caching, Batching · FinOps LLM URL: https://finopsllm.com/research/ai-cost-optimization AI cost optimization AI cost optimization is the discipline of lowering the cost of useful model work without damaging quality, latency, or reliability. The useful unit is not cost per token in isolation. The useful unit is cost per successful task: resolved support ticket, accepted code suggestion, completed workflow, or approved analysis. The most common mistake is negotiating provider price before fixing workload design. In many teams, the largest avoidable cost comes from sending too much context, routing simple work to expensive models, retrying noisy prompts, or running synchronous jobs that could be batched. Optimization starts by finding the waste pattern, not by assuming the invoice is mainly a procurement problem. Where savings usually come from Model routing that sends easy requests to lower-cost models and escalates only when confidence is low. Prompt and context compaction so each request carries only the evidence needed for the task. Prompt caching, semantic caching, and response reuse for repeated tasks. Batch routing for evals, enrichment, reprocessing, and other non-urgent workloads. Retry and fallback controls that stop low-quality loops from multiplying cost. How to prioritize optimization work Start with attribution. Break spend by feature, owner, model, provider, token class, and workload type. Then rank by total spend and variance. A support assistant using a premium model on every request often produces a larger savings opportunity than a carefully tuned agent pipeline that runs less often. Optimization should be measured against a stable quality baseline. Routing to a cheaper model is only a win if the task still succeeds. That is why the best programs combine finance metrics with product metrics such as containment rate, approval rate, latency, or task completion. Cost optimization operating rhythm Strong teams review AI cost weekly, not only at month end. They compare the largest drivers, pick one or two optimization candidates, test behind flags, and reconcile the results against provider and gateway data. This turns cost reduction from an occasional project into a repeatable product habit. If you need the supporting mechanics, see LLM cost attribution , model routing , LLM budget governance , and six levers for AI cost optimization . Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # AI Cost Optimization Checklist for 2026 · FinOps LLM URL: https://finopsllm.com/research/ai-cost-optimization-checklist AI cost optimization checklist AI cost optimization is not a single project. It is a sequence of repeatable steps. This checklist covers the most reliable levers for 2026, ordered by impact and risk. Before you optimize Reconcile to the invoice. Gateway logs under-count. Use the provider invoice as ground truth. Find the top five endpoints. ~80% of cost usually lives on 3–5 endpoints. Ignore the long tail at first. Define quality baselines. Cost savings that hurt quality are not savings. Agree on the metrics that matter before testing. The optimization levers Prompt caching — 50–90% off cached tokens, lowest implementation effort. Model routing — send easy queries to cheaper models, hard queries to frontier models. 30–50% reduction. Semantic caching — reuse similar responses for RAG and support flows. 20–40% reduction on cache-friendly endpoints. Prompt compression — strip redundancy and move static context to system prompts. 10–25% reduction. Batch routing — move non-urgent work to batch APIs. Flat 50% off eligible volume. Provider arbitrage — use equivalent models priced lower on other providers. 30–60% reduction when A/Bs pass. Governance checks Set per-request and per-user cost caps. Add alerts for budget variance and anomalous spend. Re-run A/B tests monthly; models and prices change. Document which optimizations are live and their measured savings. For a deeper explanation of each lever, see AI cost optimization . What order should you run these in? Sequence by effort-to-savings, not by size of the prize. A realistic first 90 days: Weeks 1-2 — reconcile to the invoice, tag the top five endpoints, and set a quality baseline. No optimization yet; you are building the ability to tell whether anything worked. Weeks 3-4 — turn on prompt caching. It is the only lever on this list that needs no quality testing, because the cached tokens are byte-identical to what you were already sending. Weeks 5-8 — move eligible asynchronous work to batch, then A/B model routing on one endpoint. Both are reversible in a deploy. Weeks 9-12 — semantic caching and provider arbitrage, which change what the user sees and therefore need the quality baseline you built in week 1. How much should you expect to save? The levers are not additive. Routing 40% of traffic to a cheaper model shrinks the base that caching then applies to. A stack of caching, routing, and batch that looks like 90% on paper typically lands between 40% and 60% in production. Measure each lever against the invoice after it ships rather than summing the vendor claims. When should you stop optimizing? When the next lever costs more engineering time than it saves in a year, or when quality regressions start appearing in your evals. Both are worth writing down in advance. Re-open the checklist quarterly instead — provider prices, model tiers, and your own traffic mix all move enough that the answer changes. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is the fastest way to reduce AI costs? The fastest way is to optimize your top five endpoints: apply prompt caching, model routing, and prompt compression to the workloads that drive most of your spend. What are the main levers for AI cost optimization? The main levers are model routing, prompt caching, semantic caching, prompt compression, batch routing, and provider arbitrage. How do you optimize AI costs without losing quality? A/B test every change against a stable quality baseline. Measure task success, latency, and cost together. Roll back anything that hurts outcomes. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # AI Cost Optimization: Six Levers That Actually Work · FinOps LLM URL: https://finopsllm.com/research/ai-cost-optimization-six-levers AI cost optimization: six levers Updated 1 August 2026 AI cost optimization is not about finding one magic setting. It is about stacking small, repeatable improvements across the lifecycle of a request. The six levers below are the ones we see produce measurable savings in production. Each has a quality tradeoff, a typical impact range, and a set of workloads where it works best. The six levers at a glance Lever Typical impact Best for Quality risk Model routing 30–50% Mixed workloads with simple and complex requests Low if confidence threshold is tuned Prompt caching 20–40% Repeated prefixes, system prompts, documentation Very low Prompt compression 15–30% Long prompts with redundant context Low if A/B tested Batch & async pricing 10–50% Evals, enrichment, reporting, non-urgent jobs Low; latency increases Provider arbitrage 20–35% Tasks where multiple models meet quality bar Medium; requires benchmarking Fallback controls 5–15% Retry storms, outages, model degradation Low 1. Model routing Model routing sends each request to the cheapest model that can handle it. A lightweight classifier scores request complexity and chooses a tier. Simple classification goes to a small model; hard reasoning goes to a frontier model. The savings come from volume. Most production traffic is not frontier-hard. Routing even half of it to a cheaper model cuts the bill substantially. The key is measuring success rate by tier and adjusting the routing threshold so quality does not regress. 2. Prompt caching Prompt caching reuses a previously computed prefix. If your prompt starts with system instructions, documentation, or few-shot examples that do not change, caching can reduce input cost by 50–90% on repeated calls. Caching works best when the same prefix is reused multiple times within a short window. It does not help one-off queries or prompts where the entire context changes every time. Track cache-hit rate as a first-class metric. 3. Prompt compression Prompt compression removes redundant context, deduplicates examples, and summarizes long inputs before sending them to the model. The goal is to send only the evidence the model needs for the specific task. This lever is high leverage for applications that pass large documents or conversation history. Every removed input token is a direct cost reduction. Compression must be A/B tested because aggressive summarization can hurt quality. 4. Batch and async pricing Most providers offer discounted pricing for asynchronous batch workloads. OpenAI's batch API offers up to 50% off for non-urgent jobs. The tradeoff is latency: results arrive hours later, not seconds. Good candidates include evaluation runs, data enrichment, report generation, and reprocessing jobs. If a workload does not need an immediate response, batch pricing is often the fastest way to cut its cost. 5. Provider arbitrage Provider arbitrage means sending the same task to whichever provider offers the best capability-per-dollar. For many tasks, models from DeepSeek, Gemini, or Anthropic can match OpenAI quality at a lower price. This lever requires benchmarking on your own data, not relying on leaderboard scores. The cheapest model that meets your quality bar is the right model. Re-evaluate quarterly because pricing and capability change fast. 6. Fallback controls Fallback controls limit the cost of failure. They include retry caps, circuit breakers, model-tier ceilings, and agent step limits. Without them, a single outage or buggy prompt can generate thousands of expensive retry calls. This lever has a smaller direct savings range than routing or caching, but it prevents catastrophic spikes. It also protects the savings from the other five levers by stopping runaway spend. How to prioritize the levers Start with attribution. Break spend by feature, owner, model, provider, and workload type. Then rank by total spend and variance. Apply the lever with the highest expected return to the largest spenders first. Always measure cost per successful outcome, not cost per token. A cheaper model that fails more often can cost more per completed task than an expensive model that succeeds once. The optimization operating rhythm Strong teams review AI cost weekly. They compare the largest drivers, pick one or two optimization candidates, test behind feature flags, and reconcile results against provider data. This turns cost reduction from a one-time project into a repeatable habit. The best AI cost optimization programs do not use one lever. They stack them: route simple work to cheap models, cache repeated prefixes, compress prompts, move batch jobs to async lanes, benchmark alternatives, and guard against runaway retries. Related AI cost optimization — the strategic overview. Model routing — building a routing layer. Prompt caching explained — when caching pays off. Provider arbitrage — benchmarking cheaper alternatives. Agent spend guardrails — fallback controls for agents. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What are the main levers for AI cost optimization? The six main levers are model routing, prompt caching, prompt compression, batch and async pricing, provider arbitrage, and fallback controls. Each has a typical savings range of 5–50%. Which AI cost optimization lever has the biggest impact? Model routing usually has the biggest impact, with savings of 30–50%, because it sends each request to the cheapest model that meets the quality bar. How do I prioritize AI cost optimization work? Start with attribution. Rank features by total spend and variance. Then apply the lever with the highest return for each feature, measuring cost per successful outcome rather than cost per token. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # AI cost recovery playbook: stop the bleeding · FinOps LLM URL: https://finopsllm.com/research/ai-cost-recovery-playbook AI cost recovery playbook: stop the bleeding and rebuild budgets 19 July 2026 When an AI cost spike lands, the first instinct is panic. A bill that was $20K last month is suddenly $85K. Production is running, customer-facing features are live, and shutting everything down is not an option. But you have maybe hours before the next bill cycle continues the damage. This playbook walks a 90-day triage-to-recovery path: stop the immediate bleeding, find the actual cost drivers, land the highest-leverage optimizations, and rebuild safeguards so it does not happen again. Not all spend is waste—some of it is your product working. The goal is not zero cost; it is intentional cost: every dollar should buy something that matters. This guide assumes you have already shipped product and are now dealing with the aftermath. Quick triage: is this really a crisis? Before you start the full recovery, ask four questions. 1. How much did spend jump? If month-over-month spend went up 30% or less, this may be expected growth, not a runaway. Check: did usage (request count or token volume) grow proportionally? If spend grew 50% but request volume grew 50%, that is expected. If spend grew 50% but requests only grew 10%, you have a problem. 2. What changed? Did you launch a new feature, enable a model upgrade, or increase API call frequency? If you can name the change that caused the spike, it is easier to fix. If spend exploded for no known reason, investigate immediately—this often means a retry loop, a cache miss, or a tool that is calling itself recursively. 3. Which models or features drove it? Try to isolate spend by model and feature in your first 30 minutes. If 80% of the spike came from one model or one team, you can act surgically. If it is scattered across many features, the root cause is probably infrastructure-wide (gateway timeout + retries, or a global configuration drift). 4. Is traffic legitimate or is something broken? Check request latency, error rates, and user complaints. High latency + normal error rates = legitimate load. High error rates + retry storms = something is broken. Check your gateway logs or API logs for 429s, timeouts, or repeated calls from the same session. Days 1–7: Stop the bleeding Your goal this week is to prevent the situation from getting worse. You are not optimizing yet; you are applying emergency brakes. Assume you can tolerate some temporary feature degradation. The alternative is financial catastrophe. Day 1: Kill switches and hard stops Identify the top cost drivers. Within the first hour, query your API logs or billing data to rank features and models by spend. If your observability platform is slow, use provider dashboards (OpenAI, Anthropic, Google Cloud all expose per-model usage). Target the top 3 cost sources. Enable hard budget caps. Most LLM providers support organization-level spend caps or per-key monthly budgets. Set these immediately at 120% of your normal monthly spend. This is a circuit-breaker, not a target. When it trips, all traffic stops, so set it high enough that legitimate growth does not trigger it, but low enough that it prevents a $500K month from becoming $1M. Deploy kill switches for the top cost drivers. If a feature is driving 40% of the spike, ship a feature flag that can disable it instantly without a deploy. Use a flag service that is observable in your dashboard—when the flag is active, make sure the team knows the feature is down and why. Kill switches should be flippable from a command line or dashboard in under 60 seconds. Reduce token limits on high-cost agents. If you run autonomous agents, slash their per-run token budgets to conservative values. An agent that normally runs 50K tokens per task can temporarily run 20K. Quality will drop, but so will the immediate financial damage. You will restore this in week 4. Days 2–3: Per-key ceilings and request filtering Implement per-API-key daily limits. If you have a gateway (LiteLLM, Kong, or a custom proxy), set daily budgets per key. A key that normally spends $50/day can be capped at $80 to allow 60% headroom; if it hits $80, requests from that key are rejected with a 429 until the next day. This prevents a single runaway key from domaging the whole month. Find and kill retry loops. Check your application logs and gateway logs for repeated requests to the same endpoint or API key within short time windows. Retry storms often look like: thousands of requests with identical parameters within 5 minutes. Common culprits: timeouts + automatic retry, a health-check endpoint that calls the LLM on failure, or a batch job that re-runs the entire queue when one item fails. Disable retries temporarily (fail fast instead), or add exponential backoff with a hard max. Freeze non-essential workloads. Identify features that are not customer-facing or revenue-generating: background enrichment, experimental endpoints, A/B tests, and sandbox environments. Disable all of them for 7 days. This is temporary. The goal is to isolate the spike to your production workload. Reduce batch sizes and sampling rates. If you run batch inference or logging, cut the sample rate in half. If you process 10K documents a day, process 5K. If you batch requests 100-at-a-time, batch 50. This is a temporary measure and will have quality impact, but it buys time. Days 4–7: Establish baselines and monitoring Calculate your "normal" spend baseline. Look at the 3 months before the spike. What was your typical daily spend? Use that as your new alert threshold. If normal was $600/day and today is $1400/day, you have a 2.3x anomaly. Track this number—you will use it to measure recovery. Set up spend anomaly alerts. Configure alerts that fire when daily spend exceeds 150% of your trailing 7-day average. Route these to your on-call channel (Slack, PagerDuty, etc.). The alert should include: absolute spend, percentage over baseline, top 5 features by spend that day, and the name of the on-call engineer who should investigate. Enable request logging at the gateway level. Every LLM request should log: timestamp, model, API key/team, input tokens, output tokens, latency, and cost. Store this in your data warehouse or a simple S3 bucket. You will need this for attribution in week 2. Document what you cut and why. Create a one-page summary: features disabled, budget caps set, kill switches active, batch workloads paused. Timestamp it. You will use this to systematically re-enable things in week 4, once you understand the root cause. By end of day 7, your daily burn rate should be down 40–60% from the peak. You have traded features for financial safety. This is not sustainable, but it is stable. Days 8–30: Find the money Now you have breathing room. Your goal this phase is to understand what caused the spike and which costs are real product value versus waste. Days 8–14: Reconcile invoice to logs and attribute spend Pull raw billing data from every provider. Request invoice-level detail from OpenAI, Anthropic, Google, and any other LLM vendors you use. Most providers offer CSV exports; some require API queries. Combine everything into one table with columns: date, provider, model, tokens (input/output/cache), cost, and any metadata you can extract (API key, user ID, request ID). This is your ground truth. Match your application logs to billing data. If your application logs have request IDs and you have request-level billing data from the provider, do a join. Account for latency—billing may lag logs by 6–24 hours. Your goal: confirm that every dollar in the invoice corresponds to a request you can see in your logs. If you have invoiced costs that you cannot trace, you have either hidden requests or a billing error. Break spend into four categories: input, output, cache, and reasoning tokens. Cached input tokens are typically 50% cheaper. Reasoning tokens (o1, o3 models) can cost 2–4x output tokens. Split your total spend accordingly. This is crucial for the next phase: some of your spend might be in a cheap token type you did not realize. Attribute every request to a team, feature, and workflow. Use API keys, request headers, tags, or the user parameter to map spend. Build a table: team, feature, workflow, total spend this period, percentage of total. If you have 10 teams and one team accounts for 45% of the spike, you have found your target. Days 15–22: Rank cost drivers by size and type Identify the top 5 cost drivers. Sort by total spend descending. You are looking for patterns. Examples: Expensive model used everywhere: you switched to Claude 3.5 Sonnet for all requests instead of using it only where needed. Routing fix could save 30–50%. Long-context chatbot feature: one feature sends 50K-token context windows to every request. Trimming or caching the context could save 40–60%. Retry storm from a specific API key: one team's integration is making 3–5 retries for every successful request. Fix the error handling and save 60–70% of their spend. Batch job processing large documents: a background task processes every document in the database with an LLM. Sampling (process 10% of docs) or scheduling (run only during off-peak) could save 50–80%. Reasoning token usage in a low-value workflow: you enabled o1 for an internal QA automation that does not need advanced reasoning. Downgrade to a standard model and save 70–90%. Classify each driver as waste or real product value. Waste: retry storms, misconfigured jobs, features that ship without an owner. Real value: a feature customers use and are willing to pay for. Some spending is both—the feature is real but the implementation is inefficient. Be honest. If you cannot name a customer who values the feature, it is probably waste. Estimate the financial impact if you fix each driver. Example: "If we fix the retry storm on API key XYZ, we save $12K/month. If we switch team-search to a cheaper model, we save $18K/month." Rank by financial impact per driver. This is your roadmap for week 3–4. Days 23–30: Plan the recovery roadmap Write a one-page recovery target. What do you want your monthly spend to be? If normal was $20K and the spike hit $85K, are you aiming to return to $20K, or is your product genuinely 2x bigger now and you should target $40K? Be explicit about the "new normal." Rank fixes by effort and impact. A fix that saves $15K with 2 hours of work goes first. A fix that saves $10K but requires a week of engineering goes second. Your goal is to land 70–80% of the financial recovery with 20–30% of the engineering effort. The remaining 20% of recovery can wait until sprint 3. Create a burn-down: days 31–60, then 61–90. If you have 5 major fixes and 30 days of engineering capacity, which fixes land in month 2 and which in month 3? Default: land the highest-ROI fixes first, group related fixes to reduce context-switching, and leave a 20% buffer for unknowns. Days 31–60: Land the big levers You now know the root cause and have a clear ranked list of fixes. This month is execution. The fixes listed here are ordered by typical ROI per hour of engineering effort. Fix #1: Model routing (typical savings 20–45%) If you are using an expensive model (Claude 3.5 Sonnet, o1) for all requests, switch to a cheaper model for low-value tasks. Route based on task complexity, latency requirement, or user tier. Example strategy: use GPT-4o mini for customer support responses, Sonnet for internal analytics, GPT-4o for advanced reasoning only. Measure quality (error rate, user satisfaction) at each tier. If quality is acceptable, you have found your routing rules. Typical savings: if 60% of your requests move to a 5x cheaper model, you save 40% of inference cost. Implementation time: 4–8 hours (add routing logic to your SDK or gateway). Typical savings: 20–45% of total spend . Fix #2: Prompt and context trimming (typical savings 15–40%) Long-context features (search-augmented chatbots, document analysis) often send more context than necessary. Trim to the essentials. Example: a chatbot sends 50K tokens of context because it keeps the entire conversation history. Instead, summarize old messages and send only recent history plus the summary. Cost drops 60%. Measure accuracy to ensure the summary does not lose critical information. Implementation time: 6–12 hours (write summarization logic, tune thresholds, test). Typical savings: 15–40% of total spend . Fix #3: Caching (typical savings 10–30% if applicable) If your feature makes repeated requests with overlapping context (multi-turn conversations, document retrieval), enable prompt caching. OpenAI Prompt Cache and Anthropic's prompt caching reduce cached input tokens by 50–90% (depending on the provider). Prerequisite: your requests must reuse context. If every request is unique, caching does not help. Example: a customer support bot that retrieves the same FAQ document for every ticket. Cache the document once, reuse it across 100 tickets, and pay only once. Savings scale with cache hit rate. Implementation time: 2–4 hours (enable caching in provider SDK, verify hit rates). Typical savings: 10–30% of total spend, if applicable . Fix #4: Batch processing and scheduling (typical savings 5–25%) If you run batch jobs or background enrichment, switch from real-time inference to scheduled batching. Process data during off-peak hours (late night, weekend) or less frequently (daily instead of hourly). Example: an indexing job that re-processes every document daily can be split: new documents get immediate processing, old documents get a weekly refresh. Request volume drops 50%, cost drops proportionally (and latency improves because fewer concurrent requests). Implementation time: 8–16 hours (refactor batch pipeline, add scheduling logic). Typical savings: 5–25% of total spend, depending on batch vs. realtime split . Fix #5: Fixing retry loops and error handling (typical savings 5–20% if applicable) If your cost-driver analysis found retry storms, fix the root cause. Examples: a timeout that triggers automatic retries on every failure, an API that returns 5xx and your client retries aggressively, or a health-check endpoint that makes an LLM call and fails on startup. Fixes: add exponential backoff with jitter, implement circuit-breakers (stop retrying after 3 failures for 10 seconds), or move health-checks out of the LLM path. Implementation time: 2–6 hours. Typical savings: 5–20% of total spend, if applicable . Summary: expected recovery by day 60 If you land fixes #1–3 (routing, trimming, caching), you should recover 40–70% of the spike. Your monthly spend should trend back toward baseline or stabilize at your new target (if your product is genuinely bigger). If you land #4–5 as well, you can recover 60–85%. The remaining 15–40% of the spike may be real product value—legitimate features that cost money. If so, accept it and move to guardrails (phase 3). Days 61–90: Make it stick You have recovered most of the money. Now ensure it does not happen again. This phase is about guardrails, monitoring, and organizational habits. Implement hard budgets and ownership Set per-team or per-feature monthly budgets. If team-search normally spends $2K/month, set a budget of $3K (33% headroom for growth). When the team approaches 75% of budget, send an alert. When they hit 100%, reject new requests with a clear error. Teams own their budget, and you hold them accountable quarterly. Assign a cost owner to every major feature. That person gets paged if their feature's spend anomaly fires. They are responsible for understanding where the spend comes from and approving large changes. This creates accountability and prevents features from creeping in cost without anyone noticing. Monthly reconciliation and reporting Run a monthly cost audit. Same process as days 8–14: reconcile billing to logs, rank drivers, attribute to teams. Spend 2 hours the first week of every month on this. Publish a one-page summary to leadership: total spend, month-over-month change, top 3 drivers, which teams are on budget, which are trending up, and what you are doing about it. Track unit economics. Cost per request, cost per task, cost per user—whatever is meaningful for your product. If cost per task is trending up, investigate immediately. This metric catches inefficiency faster than raw monthly spend. Refresh kill switches and hard caps quarterly Kill switch audit: every quarter, review feature flags and kill switches. Remove ones that are no longer needed; add new ones for high-risk features. Verify that every flag is documented and that the on-call team knows how to use them. Update hard budget caps. As your product grows, your provider caps need to grow with it. If your normal monthly spend is now $30K (up from $20K), update your provider cap from $25K to $40K. Otherwise, normal growth will trigger the cap prematurely. Build lasting visibility Maintain dashboards for spend by team, feature, and model. Update daily. Make these visible to the team—not just finance. If everyone can see which features are expensive, cost becomes a shared metric, not a surprise. Document your cost drivers and fixes. Write a postmortem: what caused the spike, what did you cut, what did you optimize, what did you leave unfixed and why. Include decision rationale so future engineers understand the tradeoffs. This becomes institutional memory and prevents the same mistake from happening twice. Train new engineers on cost awareness. When you onboard, include a session on how costs work at your company: which features are expensive, which models to use for what, how to size batch jobs. Make cost awareness part of the engineering culture, not an afterthought. A reality check on savings Not all of your spike is waste. Some of it is your product working—and that is okay. Here is a realistic breakdown: 30–50% of the spike is genuinely waste: retry loops, misconfigured features, background jobs that should not be running. These are pure wins to cut. 20–40% is real product value but inefficient implementation: features customers use, but built without cost awareness. Routing, caching, and trimming recover most of this. 10–30% is new product value: you launched something bigger or different, and it legitimately costs more to operate. Accept this and reset your baseline. If you recover 60–75% of your spike cost using the levers in this playbook, you have done well. The remaining 25–40% is either real product value or business accepted spending. Common mistakes to avoid Optimizing the wrong thing first: if retry storms are driving 30% of the spike, fix that before you optimize prompt size. Do the high-impact, low-effort fixes first. Not measuring impact after you fix: ship a routing change, then check if spend actually went down. If it did not, the fix did not work as expected and you wasted engineering time. Cutting too deep in phase 1 and not re-enabling: you killed a feature on day 2 to stop the bleeding. If it is worth shipping, re-enable it by day 45 once you understand the real cost. Leaving it cut wastes product value. Forgetting to re-baseline: if your product is legitimately 50% bigger after the recovery, your new normal spend might be 40–50% higher than before the spike. Reset your alerts and budgets accordingly, or you will be in crisis mode every month. Ownership vacuum: nobody owns AI cost as a metric. It falls between platform, finance, and product. Assign one person (could be shared with other duties) to own cost; make it part of their quarterly goals and review. Without ownership, you will have another spike in 6 months. Related How to cap inference costs and prevent runaway spending - hard limits and kill switches. How to audit your LLM spend in 30 minutes - attribution and baselining. LLM cost attribution - deep dive into cost attribution patterns. Caching strategies compared - prompt caching, KV caches, and when each helps. Cost per request as a product KPI - turning cost into a trackable metric. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Measure AI feature gross margin before launch · FinOps LLM URL: https://finopsllm.com/research/ai-feature-gross-margin Measure an AI feature's gross margin before you ship it Updated September 2, 2026 · first published September 2, 2026 Quick answer: Inference is a cost of serving, not a development cost. It runs on every customer action, scales with usage, and lands in the same invoice as production infrastructure. Treating it as R&D until... Inference is a cost of serving, not a development cost. It runs on every customer action, scales with usage, and lands in the same invoice as production infrastructure. Treating it as R&D until launch means the first honest margin number arrives with the first full billing cycle, which is the worst possible time to learn it. Instrument before you launch, not after In staging, tag every model call with the account, the workflow, and the outcome, and replay realistic traffic rather than a synthetic loop. What you need out of it is a distribution: cost per successful task at p50, p90, and p99, plus the share of spend that went to failed and retried work you still pay for. A single average hides the accounts that break the margin. Roll it up to cost per account Multiply cost per successful task by expected tasks per account per month and add the failure share. That number is comparable to the price of the plan. Do it once at median usage, once at the 90th percentile, and once for the heaviest account you would still accept. Flat-price plans fail in the tail, because model cost keeps scaling after revenue stops. The four cost drivers to check Context resent per turn. A long conversation or a large retrieved document is re-billed on every turn unless caching covers it. Retries and failures. Billed at full rate; they belong in the numerator, not in an error budget. Agentic fan-out. One user action becomes many model and tool calls, and the multiplier is what varies between accounts. Model routing. A default that sends easy cases to an expensive model is the largest single controllable line. Wire the numbers to a decision The output of the exercise should be a choice made before launch: a usage ceiling in the plan, a consumption component in the price, a cheaper default model with escalation only where quality requires it, or an accepted margin with a review date. Ship the instrumentation with the feature so the same numbers keep arriving in production and the assumption can be checked rather than defended. Report it as its own line Break AI cost of revenue out inside gross margin, with cost per account and margin at each usage percentile. Read that way, a rising bill is legible: spend growing in step with revenue at a flat cost per account is scale, and spend growing faster than revenue is erosion with a named cause. Related Cost per successful task The free tier is an acquisition cost Retry loops and hidden spend Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # AI FinOps: The Operating Model for GenAI Spend · FinOps LLM URL: https://finopsllm.com/research/ai-finops AI FinOps for production teams AI FinOps is the operating model for managing AI spend once models become part of the product. It is not just observability, and it is not just procurement. It is a loop across engineering, product, and finance: understand where spend goes, assign ownership, improve unit economics, and verify changes against the invoice. LLM workloads make this urgent because spend scales with usage, context length, output length, retries, and model choice. A small product change can change the bill without changing infrastructure. The best AI FinOps programs therefore live close to the model gateway and the product analytics stack. What AI FinOps needs Provider invoice normalization. Request-level metadata and product ownership. Cost-per-successful-task metrics. Budgets that alert before month end. Optimization playbooks for routing, caching, batching, and prompt structure. Where teams start Start with visibility and showback. Show each product team its LLM spend, the endpoints driving it, and the month-over-month changes. Then pick the largest controllable driver. In most teams that is model routing, context compaction, prompt caching, semantic caching, or moving non-urgent work to batch APIs. AI FinOps becomes mature when it is part of release review: every model-facing change has a quality target, latency target, spend impact, and rollback plan. Related What is LLM FinOps? - the operating discipline that manages LLM spend. FinOps for LLMs - the operating model in detail. LLM cost attribution - how allocation actually works. LLM budget governance - budgets and degradation paths. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # AI observability: cost, traffic, and quality · FinOps LLM URL: https://finopsllm.com/research/ai-observability AI observability for production teams Updated 11 June 2026 · first published 21 May 2026 AI observability is the discipline of seeing what your production LLM workloads actually do — in cost, traffic, and quality terms — on a single timeline. It is not just tracing prompts, and it is not just dashboards over the provider invoice. It is the join of the two, with enough metadata to act on what you see. Most teams already have pieces of it: an LLM tracing tool like Phoenix, Langfuse, or Helicone for request inspection, plus a billing dashboard inside each provider console. The gap is between them. Observability becomes useful when one trace can be linked to one line on the invoice and one product feature. What AI observability needs to cover Cost signal Per request: input tokens, output tokens, cache-read tokens, model, provider, estimated cost in cents. Cache-read tokens belong in their own column because their pricing is materially different from normal input tokens. Traffic signal Volume by feature, environment, customer or workspace, and team. Without these tags every spike looks the same. Quality signal Latency, error rate, retries, refusal rate, and a quality proxy (a rubric, eval, or downstream success metric) per workload. A cost drop with a quality drop is not a win. Reconciliation signal A monthly view that compares internal estimates against the actual provider invoice, with the delta explained. How AI observability differs from LLM observability LLM observability tools focus on the request and the model. AI observability adds the spend layer and the product layer. The same trace must be answerable for three audiences: an engineer debugging a regression, a product manager debugging a feature, and a finance partner debugging a line item. Common observability anti-patterns Tagging requests only with the model name. The model is not the unit of accountability; the feature is. Storing prompts and outputs in the same store as cost data. It creates a data-handling burden and rarely pays back. Estimating cost without reconciling to the invoice. Estimates drift; only reconciliation tells you the drift. One dashboard for engineering and a different one for finance. They will disagree, and the disagreement will not get resolved. What good looks like Every request carries: feature, environment, workspace, model, provider, input tokens, output tokens, cache-read tokens, latency, status, estimated cost. Cost and quality live on the same timeline. Spikes are explainable in both dimensions. Anomaly alerts route to the owning team, not a generic channel. The monthly close reconciles estimate to invoice within a known tolerance. Engineering, product, and finance look at the same view. Where to start Start with attribution, not dashboards. Until requests are tagged with feature and workspace, no dashboard will tell you something you did not already know. Once tagging is in, the rest follows: anomalies, chargeback, forecasting, and routing decisions all build on the same labelled stream. Related Eval cost allocation - applying observability to eval pipelines. LLM cost monitoring LLM cost attribution LLM cost anomaly detection Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What AI observability needs to cover? Per request: input tokens, output tokens, cache-read tokens, model, provider, estimated cost in cents. Cache-read tokens belong in their own column because their pricing is materially different from normal input tokens.Traffic signalVolume by feature, environment, customer or workspace, and team. How AI observability differs from LLM observability? LLM observability tools focus on the request and the model. AI observability adds the spend layer and the product layer. The same trace must be answerable for three audiences: an engineer debugging a regression, a product manager debugging a feature, and a finance partner debugging a line item. What are the common LLM observability anti-patterns? Tagging requests only with the model name. The model is not the unit of accountability; the feature is.Storing prompts and outputs in the same store as cost data. It creates a data-handling burden and rarely pays back.Estimating cost without reconciling to the invoice. Where to start? Start with attribution, not dashboards. Until requests are tagged with feature and workspace, no dashboard will tell you something you did not already know. Once tagging is in, the rest follows: anomalies, chargeback, forecasting, and routing decisions all build on the same labelled stream. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # A quarter of AI spend is slipping to 2027 · FinOps LLM URL: https://finopsllm.com/research/ai-spend-deferral-2027 A quarter of AI spend is slipping to 2027 Published 15 August 2026 Forrester expects enterprises to defer roughly 25% of planned AI spend into 2027. The stated cause is not disillusionment with the technology - it is that fewer than a third of decision-makers can tie AI value to financial growth, so CEOs are routing AI investment approval through CFOs on ROI grounds. When that happens, the CFO asks the team holding the cost data. That is you. Deferral is reallocation, not contraction Read it against the growth numbers. Gartner forecasts worldwide AI spending of $2.59 trillion in 2026, up 47%, with enterprise AI spend at $407 billion, up 34.8% from $302 billion. Those facts are not in tension with a 25% deferral - money is being redistributed rather than withdrawn, concentrating on workloads with a demonstrated outcome and draining from workloads without one. In a growing budget that redistribution is easy to miss until one of your workloads is on the wrong side of it. See Gartner's 2026 AI spending forecast . What makes a workload easy to defer Deferral decisions get made fast and on thin information. Four properties do the work: Property Why it makes a line easy to cut No unit economic Total spend with no denominator can only be argued as a big number. Big numbers move. Unattributed cost If nobody can say which feature or team caused the spend, nobody can defend the feature. See cost attribution . An unexplained miss A forecast that missed once with no stated cause reads as one that will miss again. Qualitative benefit only "Improves developer productivity" loses to a line with a number next to it. Note what is absent: size, and whether the workload works. An expensive workload with a credible unit economic is defensible. A cheap one described in adjectives is not. Why the forecasting record matters here Most AI workloads arrive at this conversation carrying the third property. A review of 127 enterprise agentic AI implementations found 73% over budget, some by more than 2.4x, averaging $2.3M in unmodelled cost. Uber gave Claude Code to roughly 5,000 engineers in December 2025 and spent its full annual AI budget by April. None of those were technology failures - they were estimate failures. But from the seat approving next year's budget, an unexplained overrun and a failed project look identical, which is why the explanation matters as much as the number. See why agentic AI blows the budget . How to defend a workload A measured unit economic with a counterfactual. "$0.31 per resolved ticket against $4.10 handled by a person" survives scrutiny; "$180k a month on support AI" does not. One workflow with a real number beats a portfolio-wide estimate nobody believes. See cost per request as a KPI . A full-cost numerator. Inference plus evals, retries, vector storage, and human review. A unit cost built on the token line alone is provably understated, and getting caught understating it costs the whole argument. See hidden LLM costs . A variance history with causes. "We were 60% over in Q1; the cause was a 22x call multiplier against an assumed 3x; it is now measured and capped" is stronger than never having missed, because it shows the estimate is instrumented. See anomaly detection . The role change worth naming AI investment decisions are moving from engineering discretion to CFO approval. That is a different conversation with different evidence standards, and FinOps teams have generally prepared for the wrong one - they have optimization stories, which answer a question that is no longer being asked. Ranking workloads on cost per outcome requires attribution, full-cost modelling, and a unit metric per workflow as standing capabilities, not as a scramble when a deferral list appears. That capability now has a name and it is the top skillset FinOps teams are hiring for: see AI value management . What to do this quarter List the AI workloads and mark the ones with no unit economic. That is the deferral candidate list whether or not anyone has written it down. Instrument the two or three most strategically important properly - tagged costs, full-cost numerator, a counterfactual. Write the variance explanation for anything that has already missed, before it is requested. Accept that some should be deferred. Volunteering the weak line buys credibility for the strong one. Related What is AI value management? - the capability the review assumes you have. Why agentic AI blows the budget - the forecasting record behind the scrutiny. Gartner's 2026 AI spending forecast - the growth the deferral sits inside. State of FinOps 2026: 98% now manage AI spend - where the practitioner gap is. How to audit LLM spend - the mechanics of building the case. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ How much AI spend is being deferred to 2027? Forrester's 2026 predictions expect enterprises to defer roughly 25% of planned AI spend into 2027, as the gap between vendor promises and delivered value narrows appetite and financial scrutiny increases. It is a reallocation inside a growing budget, not a contraction. Why is AI spend being deferred if the market is growing? Both are true at once. Gartner forecasts $2.59 trillion of worldwide AI spending in 2026, up 47%, while individual programmes get moved out a year. Money concentrates on workloads with a demonstrated outcome and drains from workloads without one. What makes a workload easy to defer? Four properties: no unit economic, cost that is not attributed to a feature or team, a forecast that already missed once with no stated cause, and a benefit described only qualitatively. Any one makes a line easy to move; two makes it likely. Why does this land on the FinOps team? Because CEOs are routing AI investment approval through CFOs on ROI grounds, and the CFO asks the team that owns the cost data. A FinOps function that can report spend but not spend-per-outcome supplies only half the answer at the moment it is asked for. What should we do before the review? Pick the two or three workloads most likely to be challenged. Give each a measured unit economic with a full-cost numerator, a borrowed business denominator, and a documented forecast variance with its cause. That is weeks of work, not a quarter. Should we defend every workload? No. A function that defends everything defends nothing. Volunteering the genuinely weak line buys credibility for the strong one, and it is a better position than having the list written by someone with less context. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # AI spend variance: volume, rate, mix, and efficiency · FinOps LLM URL: https://finopsllm.com/research/ai-spend-variance-bridge AI spend variance: volume, rate, mix, and efficiency Updated August 27, 2026 · first published August 27, 2026 Quick answer: An AI spend variance is useful only when it points to an action. Split the movement from forecast to actual into four causes: volume, rate, mix, and efficiency. The categories are simple; the... An AI spend variance is useful only when it points to an action. Split the movement from forecast to actual into four causes: volume , rate , mix , and efficiency . The categories are simple; the discipline is joining them to invoices, usage, and owners without double-counting. Volume Volume is demand: requests, users, tokens, or completed workflows. Compare actual usage with the forecast at the same traffic and context assumptions. If volume is the driver, update adoption and capacity forecasts rather than blaming engineering for serving demand. Rate Rate is the price paid per unit: provider tariff, discount, exchange rate, or commitment. Use the rate actually billed by provider, model, and token type. A cheaper list price does not count until it appears on the invoice or the contract assumption is explicitly marked. Mix Mix is where usage moved: model, provider, region, workload, customer tier, or synchronous versus batch path. A stable token total can cost more after a feature moves to a reasoning model. Tag the workload so the change has a technical and business owner. Efficiency Efficiency is cost for the same useful outcome. Include prompt growth, retries, fallbacks, tool fan-out, cache behavior, and human repair. Use cost per successful task and quality metrics to avoid calling degraded output an efficiency gain. Build the bridge Start with the prior forecast, apply rate, then volume, mix, and efficiency, and investigate the residual. Each line needs evidence, dollar impact, owner, and next action. The bridge becomes operational when it changes routing, product limits, contracts, or the next forecast. Variance analysis is not a monthly explanation ritual. It is the shared language that lets finance and engineering decide what to change next. Related LLM cost monitoring AI cost allocation How to budget for AI spend Related LLM cost monitoring AI cost allocation How to budget for AI spend Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # What is AI value management? · FinOps LLM URL: https://finopsllm.com/research/ai-value-management What is AI value management? Published 15 August 2026 AI value management is the practice of tying AI spend to measurable business outcomes rather than only reducing it. Cost management asks why a bill is high; value management asks what the spend produced and whether you would buy it again at that price. It is the number-one skillset FinOps teams reported hiring for in 2026. Why the discipline moved FinOps X 2026 was the visible inflection point. Nearly a quarter of sessions covered AI economics and token pricing, the Linux Foundation announced both the Tokenomics Foundation and a 2027 conference named after the unit, and analyst coverage out of the event asked plainly whether AI value management is now bigger than FinOps itself. The framing that stuck: AI value must justify AI cost, and token economics is only one part of that equation. The pressure behind it is financial, not intellectual. Fewer than a third of decision-makers can tie AI value to their organization's financial growth. CEOs have started routing AI investment approval through CFOs on ROI grounds. Forrester expects roughly a quarter of planned AI spend to slip into 2027 as the gap between vendor promise and delivered value narrows the appetite. In that climate, a team that can report only cost has half an argument. "We cut inference 30%" is a good sentence in a year when the budget is safe. It is a weak one in a year when the budget is being re-approved. Cost management versus value management Cost management Value management Question Why is this expensive? What did it produce, and would we buy it again? Data source Billing exports plus gateway telemetry The same, joined to product and business events Unit Cost per request, per token, per team Cost per resolved ticket, per merged PR, per sourced deal Failure mode Optimizing a workload that should not exist A ROI number nobody outside the team believes Owner FinOps and platform FinOps with a product or business counterpart Value management contains cost management rather than replacing it. You cannot compute cost per outcome without correct cost attribution first, which makes the cost work a prerequisite and not a competing priority. The hard part is the denominator Cost data lives in systems FinOps already owns. Outcome data does not. It lives in the ticketing system, the CI pipeline, the CRM, the order table - owned by teams with no reason to care about your cost model. That is the whole difficulty, and it is organizational as much as technical. What makes the join possible is a shared key : the same identifier present on the cost record and on the outcome record. Tag every model call at the gateway with feature, environment, team, and customer. Nothing works without this. See cost attribution . Pick one workflow with a countable outcome. Support deflection, code review, document processing - anything where "completed" has an existing definition somebody already reports on. Emit the same feature tag on the business event. This is the negotiation, not the engineering. One field on an existing event. Divide. Cost per completed outcome, weekly, for that one workflow. Start with one workflow, not a portfolio. One credible number beats an org-wide ROI figure nobody trusts, and it builds the instrumentation everything else reuses. What a value metric has to survive The metric will be attacked, usually by the team whose workflow it describes. Three things make it hold: Full cost in the numerator. Inference plus evals, retries, vector storage, and human review. A cost-per-outcome built on the token line alone is provably low and will be dismissed the first time someone checks. See hidden LLM costs and eval cost allocation . A denominator someone else already publishes. If FinOps invents the outcome count, the number is contested on definition rather than substance. Borrow the count the business already reports. A stated counterfactual. "Cost per resolved ticket is $0.31 against $4.10 for a human-handled ticket" is an argument. "$0.31" alone is trivia. And separate the two failure modes explicitly when you report. A workflow can be over budget because the forecast was wrong while still being worth it . Merging them turns a forecasting problem into a cancellation decision. Where this is heading The standardization is already in motion. The Tokenomics Foundation's named workstreams include value metrics for AI ROI and AI Value Frameworks - explicitly the denominator problem - alongside vendor-neutral full-cost models. FOCUS 1.5 , due December 2026, makes the numerator comparable across providers. Neither will hand you the outcome data. That join is local to your business and always will be. Teams that build it now will plug into the frameworks when they ship; teams waiting for a framework to supply it will find it does not. Related State of FinOps 2026: 98% now manage AI spend - where the skills signal comes from. What is the Tokenomics Foundation? - the body standardizing value metrics. Cost per request as a KPI - the cost-side metric this builds on. What is LLM cost attribution? - the prerequisite. Hidden LLM costs - what belongs in the numerator. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is AI value management? AI value management is the practice of tying AI spend to measurable business outcomes, rather than only reducing it. Where cost management asks why a bill is high, value management asks what the spend produced and whether you would buy it again at that price. It is the top skillset FinOps teams reported hiring for in 2026. How is it different from FinOps cost management? Cost management optimizes the numerator. Value management requires a denominator - tickets resolved, PRs merged, deals sourced - attached to the same tag the cost was attributed to. That denominator lives in product and business systems, not in billing data, which is why it is a genuinely new capability rather than a rename. Why did AI value management become a priority in 2026? Because scrutiny arrived. Fewer than a third of decision-makers can tie AI value to financial growth, CEOs are routing AI investment approval through CFOs, and Forrester expects a quarter of planned AI spend to slip to 2027. A team that can only report cost cannot defend a budget in that climate. What do you need to measure AI value? A shared key that appears on both the cost record and the outcome record. Tag every model call with feature, environment, team, and customer at the gateway, then join those tags to a business event - a resolved ticket, a merged PR, a completed order. Without the shared key, cost and value stay in separate systems. What is a good first AI value metric? Cost per completed outcome for one workflow, not an org-wide ROI figure. One workflow with a credible denominator beats a portfolio-wide number nobody trusts, and it forces the instrumentation you need for everything else. Does value management replace cost management? No. It contains it. You cannot compute cost per outcome without accurate cost attribution first, so the cost work is a prerequisite rather than a competing priority. The change is that cost reduction stops being the end of the report. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # AI watermarking is now a line item, not a footnote · FinOps LLM URL: https://finopsllm.com/research/ai-watermarking-compliance-cost AI watermarking compliance cost Updated September 1, 2026 · first published September 1, 2026 Quick answer: Anthropic now embeds an imperceptible watermark in text generated by supported Claude models, and signs generated .svg, .png and .jpg files with C2PA provenance metadata. The text technique follows... Anthropic now embeds an imperceptible watermark in text generated by supported Claude models, and signs generated .svg , .png and .jpg files with C2PA provenance metadata. The text technique follows Google DeepMind's SynthID-Text approach: it biases the randomness used for token selection, without changing meaning, quality, or readability. On 1 September 2026 a detection API opened to regulators, law enforcement, media, fact-checkers, researchers, educational organisations, EU civil society groups, and enterprises with their own verification obligations. Marking is applied worldwide, not only in the EU. The driver is Article 50 of the EU AI Act, whose transparency obligations took effect on 2 August 2026; Claude models launched in the EU on or after that date support machine-readable marking at launch. There is no separate charge for any of this. That is precisely why it gets missed in a budget review — the cost is real, it is just not on the invoice. Where the money actually goes Obligation What it costs Owner Machine-readable marking at generation Model migration off unmarked pinned versions Platform File provenance (C2PA) Media pipeline changes that stop stripping metadata Product engineering Verification on demand Detection access process, evidence workflow, staff time Compliance Audit trail Retaining model ID, version, region and timestamp per call FinOps / observability The pinned-model trap Most production systems pin an exact model version for reproducibility, and rightly so. But a version pinned before August 2026 may not carry machine-readable marking. If you serve EU users, that turns a stability decision into a compliance gap, and the remedy is an unplanned migration: re-evaluation, prompt adjustment, regression testing, and a new price point on the replacement model. Budget it as a migration, because that is what it is. The tell is a pinned version identifier in your configuration with no scheduled review date next to it. Inventory every pin, mark which ones serve EU traffic, and put a date on each one. Your image pipeline probably strips the evidence C2PA metadata lives in the file. Thumbnailers, CDN image transforms, format converters, and social publishing tools routinely discard metadata to save bytes — a sensible default that now destroys the provenance you are obliged to preserve. Test the whole chain from generation to delivery, not the model output alone. The cost here is engineering hours plus a modest storage increase, both cheap if found now and expensive if found during an audit. Detection access is a process, not a product Verification is gated to eligible organisations, with access expanding over time. If you have your own verification obligation, start the access process before you need it; the cost is legal and administrative time, not a per-call fee. If you do not qualify, your compliance evidence has to come from your own logs instead — which means retaining model identity, version, region and timestamp for every generated artefact, joined to the artefact itself. That is an observability requirement with a storage bill, and it belongs in the same telemetry you already use for cost attribution. What to do this quarter Inventory pinned model versions and flag any serving EU users. Test metadata survival end to end on one real image path. Decide whether you have a verification obligation, and if so begin the access request. Then extend your existing usage telemetry with model version and region, so provenance evidence and cost attribution come from one join rather than two systems. None of these show up as a rate change, and all of them show up in the next audit. Related Model deprecation and migration costs Multimodal cost allocation AI observability Related Model deprecation and migration costs Multimodal cost allocation AI observability Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Cloud Infrastructure Cost Audit: Alibaba vs Claude Max · FinOps LLM URL: https://finopsllm.com/research/alibaba-vs-claude-cost-audit Cloud Infrastructure Cost Audit: Alibaba vs Claude Max Audit date: 6 August 2026 4 Plans audited $50–$200 Monthly range 100K Benchmark prefix 40 Turns per session Executive conclusion On auditable unit economics, Alibaba wins decisively : Alibaba Coding Plan provides the lowest predictable cost per model call. Alibaba Token Plan Pro provides the best economics for repeatedly reusing a large cached codebase, particularly with Qwen 3.7‑Plus. Claude Max is a capability subscription, not a transparent compute allocation. Anthropic does not publish the token, compute, or dollar-equivalent quantity contained in either Max tier. For one developer running a 100K-token repository through long interactive sessions, Alibaba Token Pro is probably the strongest raw-capacity option. For sustained Claude Code use where Claude's task-completion quality is itself the deciding factor, Max 5× is reasonable. Max 20× is primarily justified by Opus use or sustained parallel agents — not by transparent cost efficiency. Important correction to a common premise: Alibaba Individual Pro does not provide a 160,000-credit monthly wallet. It provides 12,000 credits in a rolling five-hour window and 40,000 credits in a rolling seven-day window. The often-quoted 160,000 figure is simply four seven-day windows, or 28 days. Source 1. Hard quota and unit-math comparison Plan Price Meter Five-hour limit Longer-term limit Full-utilization unit economics Alibaba Coding Plan $50/mo Model calls 6,000 rolling 45,000/wk · 90,000/mo $0.000556 per call Alibaba Token Personal Pro $70/mo Credits (model, tokens, thinking, tools) 12,000 rolling 40,000 rolling/7 days $0.000408 per credit Claude Max 5× $100/mo Undisclosed weighted usage 5× Pro session capacity Undisclosed weekly limits Not calculable publicly Claude Max 20× $200/mo Undisclosed weighted usage 20× Pro session capacity Undisclosed weekly limits Not calculable publicly Alibaba states that a single top-level Coding Plan query normally produces 5–10 underlying model calls for simple tasks and 10–30 or more for complex tasks. Its five-hour allowance rolls continuously, while weekly and monthly quotas have fixed reset points. Source For Token Pro, a continuously utilized 40,000-credit seven-day allowance yields: 40,000 × 30/7 = 171,429 credits per 30 days $70 / 171,429 = $0.000408 per consumed credit This is theoretical maximum utilization. Credits that are not used before their rolling capacity becomes available again have no stored value. Anthropic currently publishes only "5× Pro" and "20× Pro," plus the existence of weekly limits. It explicitly retains discretion to apply additional model, feature, weekly, or monthly restrictions. Source Older Anthropic documentation quoted approximately 50–200 Claude Code prompts per five hours for Max 5× and 200–800 for Max 20×. Those numbers should not be treated as current hard quotas: Anthropic subsequently doubled Claude Code five-hour limits in May 2026, while its current documentation removed numeric prompt estimates. Source Effective Coding Plan capacity At full monthly utilization: Workload amplification Effective top-level tasks/month Average/day 5 calls per task 18,000 600 10 calls per task 9,000 300 30 calls per task 3,000 100 For a 40-turn coding session, assuming each user turn causes 5–30 underlying model calls: Calls per user turn Calls per 40-turn session Sessions/month Sessions/day 5 200 450 15 10 400 225 7.5 30 1,200 75 2.5 That call amplification, rather than token count, is the principal risk in the Coding Plan. 2. Billing mechanics Alibaba Coding Plan The Coding Plan is effectively token-insensitive but call-sensitive . A 6,000-token response and a 500-token response cost the same when both are produced by one model call. A 100K-token cached prompt and a 2K prompt also consume one call each from the subscription quota. However, verbosity still has an indirect effect. Longer reasoning can cause more tool calls, retries, validation passes, file reads, and model continuations. Alibaba counts those underlying calls, not merely the visible message you submitted. Alibaba Token Plan The Token Plan is directly sensitive to: Uncached input tokens Cached input tokens Generated output and reasoning tokens Model selected Thinking mode Tool calls Alibaba does not publish a complete Personal Plan model-to-credit coefficient table. It says that the console bill is the source of truth. Its public Qwen 3.6-Plus metering example reports: 8,349 input tokens: 1.67 credits 40,794 cached tokens: 0.82 credits 573 output tokens: 0.69 credits That implies approximately: 200 credits per million normal input tokens 20 credits per million cached tokens 1,200 credits per million output tokens This example is from the Team Token Plan and Alibaba warns that coefficients vary by model, so it is an audit anchor rather than a guaranteed Personal Plan tariff. Source Claude Max Claude Max has a fixed invoice but not flat consumption . Anthropic states that usage depends on message length, conversation length, attached files, model, tools, and project complexity. Claude, Claude Code, and IDE sessions also draw from the same account allowance. When the allowance is exhausted, the user must wait, upgrade, or continue at standard API rates through separate usage credits. Source The economically correct description: Claude Max hides the metering unit; it does not eliminate token or verbosity costs. 3. Prompt-cache economics Both providers offer essentially the same explicit five-minute cache economics: Cache operation Alibaba Anthropic Five-minute cache write 1.25× normal input 1.25× normal input Cache hit 0.10× normal input 0.10× normal input Effective hit discount 90% 90% Alibaba's automatic implicit cache is less attractive: cache hits cost 20% of normal input and hit probability is not guaranteed. Explicit and implicit Alibaba caching cannot be combined. Source For a long CLI session, cache discipline is therefore critical: Keep the repository/system prefix byte-for-byte stable. Put changing instructions after the cached prefix. Avoid changing tool definitions or system prompts unnecessarily. Keep successive turns inside the cache TTL. Warm the cache before releasing parallel sub-agents. Reminder: A 90% discount on cached input does not apply to generated output, new context, reasoning tokens, or tool traces. 4. Long-context benchmark Benchmark definition The benchmark models: 100,000-token reusable repository prefix 40 consecutive turns 2,000 fresh input tokens per turn Explicit five-minute caching Concise output: 2,000 tokens per turn Verbose output: 6,000 tokens per turn Token category Quantity Initial cache write 100,000 Fresh input over 40 turns 80,000 Cached prefix reads 3,900,000 Concise output 80,000 Verbose output 240,000 Alibaba modeled credit burn Because Alibaba does not publish exact Personal Plan credit coefficients, the following estimates normalize the public Qwen 3.6 credit example using current Model Studio list-price ratios: Qwen 3.7-Plus: $0.40/M input and $1.60/M output versus Qwen 3.6-Plus at $0.50/$3.00. Qwen 3.8-Max: $2.00/M input and $6.00/M output. Source These are planning estimates, not published Personal Plan deduction coefficients. Model Concise session Verbose session Verbosity increase Sessions per 7-day quota (concise / verbose) Qwen 3.7-Plus 146 credits 249 credits +70% 273 / 161 Qwen 3.8-Max ~668 credits ~1,052 credits +57% ~60 / ~38 Sustainable daily averages under the 40,000-credit rolling seven-day limit Model Standard-hours sessions/day Off-peak sessions/day Qwen 3.7-Plus, concise 39.0 97.6 Qwen 3.7-Plus, verbose 23.0 57.4 Qwen 3.8-Max, concise 8.6 42.9 Qwen 3.8-Max, verbose 5.4 27.1 Alibaba currently applies 0.4× credit consumption to Qwen 3.7-Plus and 0.2× to Qwen 3.8-Max between 22:00 and 08:00 UTC+8. In Lisbon during August, that corresponds approximately to 15:00–01:00 local time. Source Off-peak impact: This discount changes the recommendation materially — Qwen 3.8-Max becomes economically viable for much more sustained use when the workload can be shifted into the discounted window. Claude API-equivalent resource value Claude Max does not disclose how these sessions translate into its included quota. Nevertheless, current API rates provide a useful shadow value: Claude model Concise API-equivalent cost Verbose API-equivalent cost Verbosity increase Sonnet 5 $1.99 $3.59 +80% Opus 5 $4.98 $8.98 +80% These calculations use the current Sonnet 5 introductory rates of $2/M input and $10/M output and Opus 5 rates of $5/M input and $25/M output, including the 1.25× initial cache write and 0.1× cache reads. Sonnet pricing rises to $3/$15 after August 31, 2026. Source At API-equivalent prices, $100 represents approximately: 50 concise or 28 verbose Sonnet sessions 20 concise or 11 verbose Opus sessions This does not mean Max 5× contains those exact quantities. It shows the compute value that Anthropic would charge through its transparent API meter. Sonnet 5 also uses a tokenizer that produces approximately 30% more tokens than Sonnet 4.6 for identical text. Repository sizes estimated using an older Claude tokenizer should therefore be remeasured. Source 5. The verbosity-tax audit Moving from 2,000 to 6,000 output tokens across 40 turns adds 160,000 output tokens. Meter Incremental burn Alibaba Coding Plan No direct additional quota, unless extra model calls occur Qwen 3.7-Plus Token Plan estimate +102 credits Qwen 3.8-Max Token Plan estimate +384 credits Claude Sonnet 5 API equivalent +$1.60 Claude Opus 5 API equivalent +$4.00 Claude Max subscription Earlier exhaustion of undisclosed session/weekly quota The Alibaba Coding Plan is therefore unusually attractive for models that generate long answers without spawning many additional calls. The Token Plan behaves differently. Output tokens are materially more expensive than cached input. Under the public Qwen credit anchor, one million output tokens consumes approximately as many credits as: Six million normal input tokens, or Sixty million cache-hit input tokens Practical implication: Controlling answer length often creates greater savings than further optimizing an already effective prompt cache. For Claude Max, conciseness has no immediate marginal cash cost while below the limit, but it extends the usable session and weekly allowance. Once the included limit is reached, continued usage is charged at API rates, making the hidden verbosity tax explicit. Source 6. Parallel multi-agent workflows Coding Plan call consumption Assume one decomposition launches 4–8 agents, each making 10–30 calls: Agents Calls per decomposition 4 40–120 6 60–180 8 80–240 This produces the following theoretical capacity before coordinator calls, retries, and validation: Quota Multi-agent decompositions 6,000 calls/5 hours 25–150 90,000 calls/month 375–2,250 The wide range shows why visible prompt count is a poor predictor of Coding Plan consumption. Token Plan multi-agent benchmark Assume every agent receives the 100K repository prefix, performs 15 turns, adds 2K fresh input per turn, and generates either 2K or 6K output per turn. Model 4 agents 6 agents 8 agents Qwen 3.7-Plus 266–419 398–629 531–838 Qwen 3.8-Max 1,232–1,810 1,849–2,714 2,465–3,619 The ranges represent concise-to-verbose output. During Alibaba's discounted window, multiply Plus figures by 0.4 and Max figures by 0.2. A single 4–8-agent batch therefore fits inside the Token Pro 12,000-credit five-hour ceiling. Repeated 3.8-Max-model batches can still consume the window quickly. Alibaba markets Pro as supporting approximately 6–8 concurrent agents, but this should be treated as a design target rather than guaranteed throughput or latency. Source Claude Max parallelism All Claude, Claude Code, and supported IDE usage shares the same account-level allowance. Four to eight sub-agents do not receive separate Max quotas. Each agent creates its own generated history, reasoning, tools, and output, so consumption generally scales roughly with the number of active agents even when a common repository prefix is cached. Source Therefore: Max 5×: acceptable for occasional 4-agent bursts. Max 20×: the defensible Claude choice for persistent 4–8-agent execution. Neither tier provides a throughput SLA or auditable agent-hour capacity. 7. Break-even volume analysis Hard cash-flow breakpoints Subscription pricing creates a step function rather than a smooth token crossover. Alibaba Coding versus Claude Max Alibaba Coding remains cheaper than either Claude Max tier while the workload stays under: 6,000 calls in any rolling five hours 45,000 calls per week 90,000 calls per month Approximately 3,000 calls per sustained calendar day Claude Max 5× becomes cheaper in monthly cash terms only when: The Coding Plan no longer provides sufficient capacity; The equivalent workload still fits inside Max 5×'s undisclosed limits; and The alternative is buying both Alibaba Coding and Token Pro for approximately $120/month. At that point, Max 5× is $20 cheaper than the two Alibaba subscriptions combined. Before that point, the $50 Alibaba subscription has the lower invoice. Alibaba Token Pro versus Claude Max Token Pro remains cheaper while usage stays below: 12,000 credits per rolling five hours 40,000 credits per rolling seven days Approximately 5,714 sustained credits/day Under the benchmark, those limits correspond approximately to: Workload Standard-hours sustainable volume/day Off-peak volume/day Qwen 3.7-Plus concise 39 sessions 98 Qwen 3.7-Plus verbose 23 sessions 57 Qwen 3.8-Max concise 8.6 sessions 43 Qwen 3.8-Max verbose 5.4 sessions 27 Capacity-normalized Claude break-even Because Anthropic does not disclose Max capacity, the break-even must be expressed as the capacity Max would need to deliver. For Max to have a lower effective cost per completed benchmark session than Alibaba at full utilization: Alibaba comparison Max 5× must deliver more than Max 20× must deliver more than Coding Plan, 5 calls/turn 30 sessions/day 60/day Coding Plan, 10 calls/turn 15/day 30/day Coding Plan, 30 calls/turn 5/day 10/day Token Pro, Plus concise 55.8/day 111.5/day Token Pro, Plus verbose 32.8/day 65.6/day Token Pro, 3.8-Max concise 12.3/day 24.6/day Token Pro, 3.8-Max verbose 7.7/day 15.4/day The Alibaba Token figures above use standard-hour consumption. During discounted hours, the Claude requirement rises by: 2.5× against Qwen 3.7-Plus 5× against Qwen 3.8-Max Since Anthropic does not publish whether Max 5× or 20× can deliver those benchmark-session quantities, a more precise public break-even claim would be fabricated. The current account's /status and Settings → Usage data must be measured against a repeatable trace. Coding Plan versus Token Pro within Alibaba For the common Qwen 3.7-Plus model, the modeled crossover is particularly revealing. For a 40-turn cached session: Token Pro concise crossover: approximately 1.9 model calls per user turn Token Pro verbose crossover: approximately 3.3 calls per user turn Alibaba says actual tasks commonly require 5–30 underlying calls. Consequently, for long Qwen 3.7-Plus agent sessions, Token Pro should provide more session capacity than the Coding Plan despite costing $20 more. The Coding Plan wins when interactions are simple and close to one direct completion per turn. Token Pro wins when tools, file exploration, testing, and retries amplify each visible turn into several model calls. 8. Final verdict Workload Recommendation Rationale Short or medium coding tasks, limited tool use Alibaba Coding Plan Lowest price and predictable call meter; no direct output-token tax 100K+ repository, 30–50 turns, frequent cache reuse Alibaba Token Pro with Qwen 3.7-Plus Cached context becomes very cheap; higher effective session capacity than request billing Flagship Qwen reasoning, workload can run 15:00–01:00 Lisbon time Token Pro with Qwen 3.8-Max off-peak The 0.2× credit multiplier offsets much of the flagship-model premium Quality-critical Claude Code use by one developer Claude Max 5× Pay for Claude-native capability and workflow integration, not transparent compute economics Persistent Opus use or 4–8 Claude sub-agents Claude Max 20× Greater headroom, although quota remains opaque Actual team sharing or production automation None of these individual plans Use Alibaba Team Token/API or Claude Team/Enterprise/API Alibaba's Coding and Personal Token plans prohibit API-key sharing and non-interactive backend or batch automation. Claude Max is likewise explicitly an individual consumer plan. A team may run several agents under one developer's control, but sharing the subscription across developers or treating it as production infrastructure is a governance and contractual mismatch. Source Procurement decision Best raw unit economics: Alibaba Coding Plan. Best long-context and multi-agent economics: Alibaba Token Pro using Qwen 3.7-Plus, explicit caching, and off-peak scheduling. Best Claude-specific developer experience: Claude Max 5×. Best Claude option for persistent parallel execution: Claude Max 20×, but it should be purchased because Claude produces better completed engineering outcomes — not because its published quota economics are superior. From a strict infrastructure-audit perspective: Alibaba sells measurable capacity with some coefficient opacity; Anthropic sells an opaque fair-use capacity tier. That makes Alibaba easier to budget and optimize, while Claude Max must be evaluated through controlled workload traces and completed-task economics rather than advertised usage multiples. Sources and references Alibaba Coding Plan documentation: Alibaba Cloud Alibaba Token Plan Personal overview: Alibaba Cloud Alibaba Token Plan overview (team, metering example): Alibaba Cloud Alibaba model pricing (Qwen 3.7-Plus, Qwen 3.8-Max): Alibaba Cloud Alibaba context cache documentation: Alibaba Cloud Token Plan Individual off-peak discounts: Model Studio Claude Max plan overview: Claude Help Center Using Claude Code with Pro or Max plan: Claude Help Center Managing usage credits for paid Claude plans: Claude Help Center Anthropic pricing (Sonnet 5, Opus 5): Anthropic Migrating to Claude 4 (tokenizer changes): Claude Platform Docs Related AI coding plan comparison — the full sortable table of plans, limits, and model scores across 9 providers. AI coding economics 2026 — how a 32M-token daily workload exposes the real math behind pay-as-you-go and flat-rate plans. Cheapest way to run AI code generation (2026) — broader guide across subscription, API, self-hosted, and coding plan categories. Prompt caching economics — when prompt caching pays off and when it doesn't. Caching strategies compared — explicit vs implicit vs semantic caching. The true cost of coding agents — API bills, retries, review, and technical debt. LLM API pricing tracker — live view of provider unit prices. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ Which AI coding plan has the lowest unit cost? Alibaba Coding Plan at $50/month provides the lowest predictable cost per model call at $0.000556 per call. Alibaba Token Plan Pro at $70/month provides the best economics for repeatedly reusing a large cached codebase, particularly with Qwen 3.7-Plus at approximately $0.000408 per credit at theoretical continuous utilization. How does Alibaba Token Pro compare to Claude Max on a per-session basis? Under a 100K-token repository benchmark with 40 turns, Qwen 3.7-Plus consumes approximately 146 credits (concise) to 249 credits (verbose) per session on Token Pro. At $70/month with rolling seven-day quotas, that yields 39 concise or 23 verbose sessions per day. Claude Max does not disclose equivalent capacity figures, so the break-even can only be estimated through API shadow pricing. What is Alibaba's off-peak discount and when does it apply? Alibaba applies 0.4× credit consumption to Qwen 3.7-Plus and 0.2× to Qwen 3.8-Max between 22:00 and 08:00 UTC+8. In Lisbon during August, that corresponds approximately to 15:00–01:00 local time. This discount materially changes the economics: Qwen 3.8-Max becomes viable for sustained use when workloads can be shifted into the discounted window. Why can't Claude Max unit economics be calculated? Anthropic publishes only '5× Pro' and '20× Pro' capacity multipliers plus the existence of weekly limits. It does not disclose the token, compute, or dollar-equivalent quantity contained in either Max tier. The company explicitly retains discretion to apply additional model, feature, weekly, or monthly restrictions. Does verbosity cost more under Alibaba Coding Plan? No. The Coding Plan is call-sensitive, not token-sensitive. A 6,000-token response and a 500-token response cost the same when both are produced by one model call. However, longer reasoning can indirectly cause more tool calls, retries, and continuations — and Alibaba counts those underlying calls. When should I choose Coding Plan over Token Plan Pro? The Coding Plan wins when interactions are simple and close to one direct completion per turn. Token Pro wins when tools, file exploration, testing, and retries amplify each visible turn into several model calls. For long Qwen 3.7-Plus agent sessions, Token Pro provides more session capacity than the Coding Plan despite costing $20 more. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # LLM cost anomaly detection · FinOps LLM URL: https://finopsllm.com/research/anomaly-detection LLM cost anomaly detection Updated 12 July 2026 · first published 5 May 2026 LLM cost anomalies are often invisible until the invoice because spend can rise without request volume rising. A deployment may add retrieved context, change a router threshold, reduce cache hits, trigger retries, or move traffic to a more expensive model. Traditional traffic alerts miss those changes. A useful anomaly detector watches cost drivers, not just total cost. Total daily spend is a lagging indicator. The earlier signals are tokens per request, model mix, fallback rate, cache hit rate, batch share, and spend per product surface. Signals to monitor Spend per endpoint, team, and customer per hour. Input and output tokens per request at p50, p90, and p99. Retry rate, fallback rate, and provider error rate. Cache hit rate and cache-read token share. Model mix changes after deploys or prompt releases. Batchable work accidentally running synchronously. Baselines Use multiple baselines. A support bot has daily and weekly cycles. A nightly enrichment job has a batch window. An eval suite spikes around releases. A single global threshold will either miss real anomalies or wake people up constantly. The best baseline is per owner and workload class. Alert when a feature deviates from its own normal pattern, not when the entire company crosses a generic spend limit. Actionable alerts An alert should explain the driver: “p90 input tokens doubled on endpoint X after deploy Y,” “cache hit rate dropped from 74% to 18%,” or “fallback to frontier model increased by 31%.” If the alert cannot name a likely owner and driver, it will be ignored. Response loop Attach deploy context, route-policy diffs, and the top affected customers or workloads. Then offer the next move: roll back a prompt, lower retrieval count, restore a router threshold, disable a fallback, or move a job to batch. Anomaly detection is only valuable when it shortens the time from invoice surprise to engineering action. Related LLM cost monitoring - dashboards and observability for spend. AI observability - cost signals and operational metrics. Why LLM bills spike - root causes of cost surges. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ Why are LLM cost anomalies often invisible until the invoice? Spend can rise without request volume rising. A deployment may add retrieved context, change a router threshold, reduce cache hits, trigger retries, or move traffic to a more expensive model. Traditional traffic alerts miss those changes. What signals should an LLM anomaly detector monitor? A useful anomaly detector watches cost drivers including: spend per endpoint, team, and customer per hour; input and output tokens per request at p50, p90, and p99; retry rate, fallback rate, and provider error rate; cache hit rate and cache-read token share; model mix changes after deploys or prompt releases; and batchable work accidentally running synchronously. How should anomaly detection baselines be set? Use multiple baselines. A support bot has daily and weekly cycles. A nightly enrichment job has a batch window. An eval suite spikes around releases. A single global threshold will either miss real anomalies or wake people up constantly. The best baseline is per owner and workload class—alert when a feature deviates from its own normal pattern. What makes an LLM cost anomaly alert actionable? An alert should explain the driver: 'p90 input tokens doubled on endpoint X after deploy Y,' 'cache hit rate dropped from 74% to 18%,' or 'fallback to frontier model increased by 31%.' If the alert cannot name a likely owner and driver, it will be ignored. How should anomaly detection connect to engineering action? Attach deploy context, route-policy diffs, and the top affected customers or workloads. Then offer the next move: roll back a prompt, lower retrieval count, restore a router threshold, disable a fallback, or move a job to batch. Anomaly detection is only valuable when it shortens the time from invoice surprise to engineering action. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Anthropic cost attribution · FinOps LLM URL: https://finopsllm.com/research/anthropic-cost-attribution Anthropic cost attribution Anthropic cost attribution works best when you treat billing as a join across application metadata, request usage, and finance records. The provider can tell you model usage. Your application must tell you why the call happened, who owns it, and whether it served customer value. Without that join, every invoice line starts to look like a provider bill instead of a product bill. That makes route-policy reviews, budget ownership, and customer margin analysis much harder than they need to be. Metadata to attach at request time Feature or endpoint name. Team owner and environment. Tenant, account, or internal cost center where allowed. Workload type such as agent step, support answer, eval, or enrichment. Fallback status, route reason, and prompt or template version. Common attribution blind spots Retries and orchestration steps are easy to miss. An agent workflow may look like a single user action while actually generating several model calls. Another blind spot is tool-driven work: when the model selects a tool and calls back into the workflow, finance still needs the full chain connected to the original owner. It also helps to separate experimental and production Anthropic traffic. This makes budgets and optimization reviews much clearer, especially when product teams are testing prompts, route policies, or larger context windows. What good attribution enables Once attribution is stable, you can report spend by team, feature, customer cohort, or successful outcome. That enables showback, chargeback, route tuning, and margin analysis. It also makes cross-provider comparisons fairer because you are comparing the same workload, not just list price. Related reading: OpenAI cost attribution , LLM chargeback and showback , and provider arbitrage . Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Azure OpenAI vs Direct Cost (2026): Pricing & PTU Guide · FinOps LLM URL: https://finopsllm.com/research/azure-openai-vs-direct-cost Azure OpenAI vs Direct OpenAI Cost Updated 12 July 2026 Compare Azure OpenAI Services (via Azure's managed API) against direct OpenAI API access. Analyze per-token pricing, provisioned throughput discounts, compliance costs, and total cost of ownership to choose the best path for your workload. Azure Global deployments match direct OpenAI list prices (GPT-5.4: $2.50/$15 on both) Regional and data-zone Azure deployments add roughly 10–20% PTU monthly reservations cost up to 82% less per unit than hourly PTUs Azure adds value for enterprise compliance, regional isolation, and billing consolidation Switching between providers has minimal cost penalty Per-Token Pricing Comparison Azure and OpenAI serve the same underlying models, and — contrary to a common assumption — Azure's Global deployment type prices GPT-5.4 identically to OpenAI direct. The premium only appears when you pin traffic to a specific region or data zone, or use extended-context and Pro tiers. Model / tier OpenAI Direct Input OpenAI Direct Output Azure Input (Global) Azure Output (Global) Difference GPT-5.4 (standard context) $2.50 $15.00 $2.50 $15.00 parity GPT-5.4 (>272K context) — — $5.00 $22.50 Azure long-context tier GPT-5.4 Pro — — $30.00 $180.00 premium tier GPT-5.5 / GPT-5.6 family $5.00 $30.00 not publicly listed (quote via Azure) — Regional variation: Azure pricing varies by deployment type, and this is where the real markup lives. Against the Global baseline, Microsoft's published examples include roughly +12% for Regional Australia East and +20% for Regional Sweden Central, with Data Zone deployments around +10%. Exact rates differ per model and region — check the Azure AI Foundry pricing page for yours. If your workload requires a pinned distant region, expect a 10–20% premium over direct OpenAI. Provisioned Throughput: Where Azure Wins Azure sells reserved model capacity in PTUs (provisioned throughput units) . You pay for capacity, not tokens — so the economics hinge entirely on how fully you use what you reserve. The published rates: Billing Model Published Rate Vs. hourly PTU Best For Pay-per-token (either provider) $0 commitment; per-token list prices above — Variable or low volume PTU, hourly $2 per PTU per hour (≈$1,460/PTU/month if run 24/7) baseline Short bursts, testing PTU sizing PTU, monthly reservation ~$260 per PTU per month (published GPT-4o Global example) up to −82% Stable, high volume PTU, yearly reservation quote-based up to −85% Very large, forecastable workloads How many PTUs do you need? Throughput per PTU is model-specific — Microsoft publishes a capacity calculator in Azure AI Foundry rather than a universal tokens-per-PTU number, and deployments start as small as 1 PTU. That means there is no honest one-line "PTU = X tokens/month" conversion; size it with the calculator against your real traffic. Modeled example (illustrative arithmetic, not a quote): suppose the calculator says your steady workload needs 50 PTUs. A monthly reservation costs 50 × $260 = $13,000/month fixed , versus 50 × $1,460 ≈ $73,000/month if you ran the same capacity on hourly PTUs. Whether $13,000 beats pay-per-token depends on the token volume those 50 PTUs actually carry — reservations only win at sustained, high utilization. Cost Comparison: Three Scenarios Scenario 1: Small Team (100M tokens/month, GPT-5.4) Volume: 60M input + 40M output = 100M/month total Direct OpenAI: (60M × $2.50/M) + (40M × $15/M) = $150 + $600 = $750/month Azure pay-per-token (Global): same list rates → $750/month. A pinned regional deployment at +12–20% would run ~$840–$900. Azure provisioned: not worth sizing at this volume; even a small reservation is idle most of the time. Winner: price tie at Global rates — decide on ecosystem, compliance, and quota needs, not price. Scenario 2: Mid-Size (1B tokens/month, GPT-5.4) Volume: 600M input + 400M output = 1B/month total Direct OpenAI: (600M × $2.50/M) + (400M × $15/M) = $1,500 + $6,000 = $7,500/month Azure pay-per-token (Global): $7,500/month at parity; ~$8,400–$9,000 if you must pin a premium region. (GPT-5.5's Azure rate isn't publicly listed — direct GPT-5.5 for the same volume would be (600M × $5) + (400M × $30) = $15,000.) Azure provisioned: worth a sizing exercise — if the capacity calculator puts your steady load at ≤25 PTUs, a monthly reservation is 25 × $260 = $6,500, undercutting pay-per-token. Winner: pay-per-token on either, unless a PTU sizing quote comes in under $7,500 for your throughput. Scenario 3: Large, Predictable (5B tokens/month, GPT-5.4) Volume: 3B input + 2B output = 5B/month total Pay-per-token (either provider, Global parity): (3B × $2.50/M) + (2B × $15/M) = $7,500 + $30,000 = $37,500/month Azure provisioned (modeled): if this workload sizes to ~50 PTUs, a monthly reservation is 50 × $260 = $13,000/month — a ~$24,500/month saving. If it sizes to ~150 PTUs, the reservation is $39,000 and pay-per-token wins. The PTU count from Azure's capacity calculator IS the decision. Winner: Azure provisioned when usage is stable and the sized PTU cost lands well below $37,500. Risk: if volume halves, the reservation cost doesn't. Non-Price Factors: When Azure Wins Factor OpenAI Direct Azure OpenAI Impact on Cost Compliance (FedRAMP, HIPAA, SOC 2) No official certification FedRAMP High, HIPAA, SOC 2 available Compliance add-on not needed; built-in Data residency US-based Multiple regions including EU, UK, Asia Can avoid GDPR penalties if storing in EU Unified billing Separate invoice Consolidated Azure bill Simplifies chargeback to teams (small savings) Role-based access control API key only Azure RBAC (granular per-team or per-resource) Reduces shadow spend / untracked usage Quota management Hard rate limits; 429 errors Provisioned throughput reserves capacity Avoids request rejections at peak load Cost of switching: Minimal. Both use the same OpenAI API shape (models, parameters, endpoints). Migration is mostly DNS/config change. No ETL, no retooling. You can test Azure in parallel before committing. Decision Matrix Use Direct OpenAI if: Your volume is Your workload is variable (unpredictable spikes) You don't have compliance requirements beyond standard SOC 2 You need models whose Azure rates aren't publicly listed (GPT-5.5/5.6 family) You're not on Azure or don't need consolidated billing Use Azure OpenAI (pay-per-token) if: You're already paying for Azure services and want one bill You need FedRAMP/HIPAA/compliance features You want RBAC and quota management over API keys You operate in EU and need data residency (regional deployments cost ~10–20% more) Global deployment works for you — it matches direct OpenAI list prices Use Azure OpenAI (provisioned) if: Your volume is high, stable, and forecastable 3–6 months ahead You need guaranteed quota (no rate-limit rejections) Azure's capacity calculator sizes your workload to a PTU count whose reservation cost (~$260/PTU/month) lands clearly below your pay-per-token bill You can justify the reservation commitment if volume dips Cost Optimization Tips Monitor quarterly: Review your actual token volume vs. forecast. If actual volume is Use Azure Advisor: Automatically recommends right-sizing for provisioned throughput. Frees up reserved capacity you're not using. Batch off-peak requests: If using provisioned throughput, batch non-urgent requests during off-peak hours to smooth volume spikes and keep TPM steady. Layer by model cost: Route classification and extraction tasks to a budget tier (e.g., GPT-5.6 Luna at $1/M input, $6/M output direct) and reserve GPT-5.5 for reasoning. Reduces effective cost-per-token. Split between providers: High-volume stable workloads on Azure provisioned; variable/bursty on Direct OpenAI. Costs might be lower than picking one provider for everything. Switching Strategy Test in parallel (2 weeks): Deploy your app with Azure OpenAI alongside Direct OpenAI. Route 10% of traffic to Azure, 90% to Direct. Monitor latency, error rates, and cost difference. Gradual migration (4 weeks): Once confident, shift 50% traffic to your chosen provider over 2 weeks, then 100%. Keep fallback (ongoing): Maintain keys for both providers. If one has an outage or quota issue, gracefully failover to the other (will see a small cost impact but better than downtime). Not sure which path minimizes your bill? FinOps LLM's free audit models your likely usage and recommends the optimal provider split (Direct, Azure pay-per-token, or provisioned). Back to research FAQ Is Azure OpenAI cheaper than direct OpenAI? At standard rates, neither: Azure Global deployments price GPT-5.4 at the same $2.50/M input and $15/M output as OpenAI direct. Regional and data-zone Azure deployments add roughly 10–20%. Azure's advantage is compliance, RBAC, quota management, and consolidated billing — not per-token price. What is provisioned throughput? Azure's reserved model capacity, billed per PTU (provisioned throughput unit): $2 per PTU per hour on demand, or about $260 per PTU per month with a monthly reservation — up to 82% less than the hourly rate (yearly reservations reach up to 85%). Throughput per PTU is model-specific; size it with Azure's capacity calculator. When should I use Azure OpenAI? Use Azure if: (1) you're already on Azure and want consolidated billing, (2) you need compliance/FedRAMP/sovereign-cloud guarantees, (3) your throughput is high and steady enough that a PTU reservation beats pay-per-token for your workload. Can I optimize cost by switching between Azure and direct? Yes, if your usage is variable. Use pay-per-token for low or unpredictable volume; consider PTU reservations only for sustained, forecastable throughput. Monitor quarterly and switch if the cost difference exceeds 10%. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Background agents change the FinOps clock · FinOps LLM URL: https://finopsllm.com/research/background-agents-cost-clock Background agents change the FinOps clock Updated September 10, 2026 · first published September 10, 2026 Quick answer: Background execution is one of the most useful new patterns in agent products: a task can continue after the user closes the app, while the agent waits, calls tools, and returns later with a result.... Background execution is one of the most useful new patterns in agent products: a task can continue after the user closes the app, while the agent waits, calls tools, and returns later with a result. It is also a break from the old request-response cost model. Spend is no longer concentrated in a visible session; it can accumulate while nobody is watching. Google's Managed Agents update describes background execution together with remote MCP, custom functions, and credential refresh. Each capability expands what an agent can do, but also expands the number of billable steps and the time during which a task can remain active. Budget the task, not the chat turn A chat-turn budget is too small a boundary for a background agent. Create a task budget that follows the work across model calls, tool calls, retries, waiting periods, and resumptions. The budget should have both a dollar limit and a step limit. A task that has spent little money but made hundreds of low-value tool calls is still unhealthy. Keep a ledger keyed by task ID. Record start time, end time, model calls, input and output tokens, tool calls, external service charges, retries, and final outcome. This lets you distinguish productive long-running work from an agent that is alive but making no progress. Use timeouts as financial controls Timeouts are not only reliability settings. A stale task consumes capacity and can wake up again after a deployment or credential refresh. Set separate limits for total wall-clock lifetime, idle time between steps, maximum model calls, and maximum tool calls. When a limit is reached, pause for human approval or terminate with a useful partial result. Resumption needs idempotency. A task that is resumed without a durable checkpoint may repeat expensive searches, retrievals, or tool actions. Store the last completed step and the outputs needed to continue. Reconcile resumed work under the original task ID so the second run does not look like a new, unrelated feature. Charge for value, not runtime Longer execution is not automatically more valuable. Track completion rate, time to useful result, human interventions, and cost per completed task. A background agent that spends ten minutes and produces the same result as a two-minute workflow is a routing and prompt problem, even if the user experience hides the delay. A production control loop Give every background task a dollar, step, wall-clock, and idle-time budget. Persist checkpoints before expensive or irreversible tool calls. Require approval before crossing a risk or spend threshold. Terminate stalled tasks and report the reason to the owner. Review cost per completed task by workflow version, not only by model. Related Agent spend guardrails in production Agent total cost of ownership Three budgets every agent needs Related Agent spend guardrails in production Agent total cost of ownership Three budgets every agent needs Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Batch APIs as a FinOps lever · FinOps LLM URL: https://finopsllm.com/research/batch-api-finops Batch APIs as a FinOps lever Updated 21 May 2026 · first published 21 May 2026 Batch APIs are usually framed as an engineering optimization: trade latency for a discount, move work that can wait into an async queue, collect roughly half off input and output tokens. That framing undersells what batch does to a FinOps program. The line item it creates on the invoice is structurally different from synchronous spend, and that difference is the lever. Batch is the first place where LLM cost reporting stops looking like a single undifferentiated meter and starts looking like a procurement category with its own owner, SLA, and chargeback rule. If your organization is trying to build defensible attribution, batch is where the conversation gets easier. The work that lands in a batch file is, by definition, work that someone scheduled on purpose. It has a job name, a start time, a row count, and an owning team. Synchronous spend has none of that for free. Treat batch as a separate procurement surface and you get a clean cost center, a documented SLA, and a number that finance can actually defend in a budget review. Why batch changes the attribution conversation Synchronous LLM spend is messy because it is generated by user behavior. A spike in traffic, a retried tool call, a longer context window, or a new feature release all show up in the same meter, and attributing them to a team requires log instrumentation that most companies do not have on day one. Batch spend is the opposite. A batch job is a deliberate act. Someone wrote the script, picked the model, packed the JSONL file, and pressed run. That intent is recordable, and once it is recorded the cost is allocatable without argument. This makes batch the easiest workload class to chargeback in full. You do not need request-level tagging, a routing proxy, or a sidecar that decorates every call with team metadata. You need a job manifest and a convention that every batch submission carries an owner, a purpose, and a budget code. Finance can reconcile the provider invoice against that manifest at month end and produce a chargeback statement that nobody disputes. Treating batch as procurement, not engineering The mistake most FinOps teams make is letting batch grow organically inside the same engineering process as real-time inference. The team that runs evals submits batch jobs from a developer laptop. The data team triggers enrichment runs from a notebook. Each of those jobs is cheap individually and nobody objects, but the line items accumulate in the provider console with no owner attached. By the time finance asks where the spend came from, the answer is a shrug. The procurement framing fixes this. Batch is a category, like cloud storage or a SaaS subscription, with policies that govern who can spend against it and how the spend is reported. Three rules cover most of the surface. First, batch submissions go through a sanctioned entry point - a queue, an internal CLI, or a workflow runner - that stamps owner, cost center, and purpose into request metadata. Second, the entry point enforces a budget guardrail per team per month so a runaway enrichment job cannot consume an entire quarter of the line item. Third, batch jobs above a threshold size are reviewed the same way a procurement requisition would be: a brief justification, an expected output, and a sign-off from the workload owner. Tagging batch work for chargeback Provider invoices do not solve attribution for you. They give you a batch total per model and sometimes a per-batch breakdown if you fetch usage from the API, but they do not tell you which internal team owns each batch. Tags exist for that purpose, and they only work if they are mandatory at submission time. The minimum tag set for a batch job is owner team, cost center code, workload class, and a job identifier. Owner team and cost center drive the chargeback ledger. Workload class - eval, enrichment, summarization, embedding backfill, content generation - drives the rollup that finance shows the leadership team. The job identifier lets you reconcile the provider line item back to the internal manifest if anyone disputes the allocation. None of these tags should be optional. A submission that lacks any of them should be rejected before it ever hits the provider. The reconciliation step is where the discipline pays off. Pull the batch usage export from the provider monthly, join it on job identifier with your internal manifest, and produce a per-team table that sums to the provider total within rounding. That table is the chargeback artifact. It belongs in the same monthly close packet as cloud chargeback, and it should be presented in the same format so finance does not have to learn a new schema. Reconciling batch line items Batch line items behave differently from synchronous lines on every major provider. They show up in a separate row, often with a distinct SKU, and they appear after the job completes rather than when it is submitted. That delay matters for accrual. A batch submitted on the last day of the month may not bill until the following month, and your internal ledger needs to know whether to recognize the cost in the period the job was submitted or the period it completed. Pick one convention and document it. Most teams accrue on submission, because that is when the spending decision was made and the budget was committed. The second reconciliation trap is partial failures. A batch file with a million requests can return ninety thousand errors, and the provider only charges for successful completions on some surfaces and for attempted tokens on others. Your internal cost model has to mirror whichever rule the provider applies, or your forecasts will drift. The fix is simple but rarely done: pull the per-batch error file, count successful and failed records, and compare against the invoice. If the numbers do not tie, the model is wrong, not the invoice. The third trap is mixing batch and cache. Some providers stack a cache-read discount on top of the batch discount, and some do not. If your internal forecast assumes stacking when the provider does not honor it, your savings number is overstated. The remedy is to source the effective rate from the actual invoice, not from a list price spreadsheet, and refresh that effective rate every billing cycle. Batch in contract negotiations Batch volume is leverage. When you sit down with a provider for an annual commit, the share of your spend that runs through batch is one of the cleanest signals you can offer. Batch traffic is predictable, schedulable, and not latency-sensitive, which means it is exactly the kind of demand a provider wants on their reserved capacity. A commit that includes a batch component is easier for both sides to underwrite. This shows up in three contract terms worth asking for. The first is a discount floor on batch that exceeds the published list discount, in exchange for a minimum monthly batch commitment. The second is a service credit for batches that exceed the published SLA, since unbounded latency is the main risk of running production work in batch and a credit makes it accountable. The third is a model coverage guarantee - that batch availability for new models will land within a defined window of synchronous availability, so you are not forced back onto sync pricing when the model you depend on is upgraded. None of these terms are exotic. They mirror standard cloud reserved-capacity language. The point is that batch is the workload class where they are easiest to defend, because the demand pattern is clean and the procurement story is coherent. Reporting batch separately Most LLM cost dashboards show one number: total spend per period. That hides the procurement story. A FinOps-grade dashboard should split spend into at least three lanes - synchronous production, synchronous internal, and batch - and report each lane against its own budget envelope. Batch as a separate lane is what lets leadership see the shape of the program. If batch is five percent of spend, there is headroom. If batch is sixty percent, the program has matured and the next conversation is about commit pricing on the batch lane specifically. The same split applies to chargeback statements. A team that runs heavy evals should see their batch line clearly, with the workload class and the model mix attached, so they can manage their own program rather than reacting to a lump-sum invoice. The transparency is the lever. Once a team owns their batch line, they will tune it without being asked. From discount to discipline The fifty percent headline rate is the marketing story. The FinOps story is that batch is the cleanest opportunity to install procurement discipline on a category that has so far resisted it. The tags, the manifest, the reconciliation, the dashboard split, and the contract clauses are all easier to add to batch than to synchronous traffic, and once they are in place for batch they become the template you use to extend attribution to the rest of the spend. Batch pays for itself twice - once on the invoice, and again as the wedge that makes the rest of your LLM program legible to finance. Related LLM cost attribution LLM chargeback and showback Provider arbitrage AI FinOps Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ Why batch changes the attribution conversation? Synchronous LLM spend is messy because it is generated by user behavior. Batch spend is the opposite - a deliberate act with an owner, a purpose, and a budget code. A batch job carries intent that is recordable, and once recorded the cost is allocatable without argument. This makes batch the easiest workload class to chargeback in full. Should batch be treated as procurement or engineering? The mistake most FinOps teams make is letting batch grow organically inside the same engineering process as real-time inference. The team that runs evals submits from a laptop. The data team triggers enrichment runs from a notebook. Treating batch as procurement means batch has its own owner, SLA, chargeback rule, and cost center. How do you tag batch work for chargeback? Provider invoices do not solve attribution for you. They give a batch total per model but do not tell you which internal team owns each batch. Solution: every batch submission carries an owner tag, purpose identifier, and budget code. Finance reconciles the provider invoice against that manifest at month end. How do you reconcile batch line items? Batch line items behave differently from synchronous lines on every major provider. They show up in a separate row with a distinct SKU, appearing after the job completes rather than when submitted. That delay matters for accrual accounting and monthly closes. How does batch volume affect contract negotiations? Batch volume is leverage. When you sit down with a provider for an annual commit, the share of your spend that runs through batch is one of the cleanest signals you can offer. Batch spend is predictable and documented, making it ideal for volume-discount negotiations. Why report batch spend separately? Most LLM cost dashboards show one number: total spend per period. A FinOps-grade dashboard should split spend into three lanes - synchronous production, synchronous internal, and batch - and report each lane against its own budget envelope. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # What independent Jev tests say about cost · FinOps LLM URL: https://finopsllm.com/research/benchmark-jev-against-llm-routing What independent Jev tests say about cost Updated September 21, 2026 · first published September 21, 2026 Quick answer: Early independent testing supports the basic Jev story: it is a fast, inexpensive way to make typed decisions. It also adds a needed qualification: the saving depends on what it replaces. Comparing... Early independent testing supports the basic Jev story: it is a fast, inexpensive way to make typed decisions. It also adds a needed qualification: the saving depends on what it replaces. Comparing Jev with a slow reasoning call produces a dramatic result. Comparing it with a small structured-output model produces a smaller, but still useful, difference. The most detailed reproducible test we found is jev-measured , which called Jev through OpenRouter across eight cases including routing, tool selection, moderation, reranking, lead scoring, and guardrails. Its reported decision costs fell between $0.0000153 and $0.0000254. In its head-to-head runs, Jev's median latency was 352 ms and its mean cost was $0.0000188. Where the savings are real Against GPT-5 Nano in that test, Jev cost about 18 times less per fixture and returned much faster. That is meaningful when the old workflow asks a generation model to read state, reason, produce a formatted response, then have code pull a single decision from the text. Against Gemini Flash Lite and Mistral Small, the measured cost gap was only 1.7 times and 1.4 times respectively. On one single-question case, a small model was cheaper. That is not a failure for Jev. It defines the actual opportunity: Jev is strongest when one call can replace a repeated decision step or several decision questions can be evaluated together—not when it is forced into every trivial classification. Typed output removes a real cost The same benchmark initially found schema errors in the chat-model baselines: booleans where probabilities were requested, probability strings instead of numbers, and missing fields. Strict JSON schema mode removed those errors. That correction is important. Good FinOps writing does not hide the baseline's best configuration. It does show that output validation, repair, retries, and parsing are costs in their own right—and Jev removes that whole category for its own output contract. Accuracy and calibration still decide the rollout Cost and latency do not answer whether a decision is good enough to automate. An independent physical-AI test reported 91.3% agreement with its own 300 incident templates, while a small support-ticket test found no evidence to support a blanket claim that Jev is more accurate than all chat models. Both are early, narrow experiments. They point to the correct production test: evaluate Jev on your own labelled cases and inspect accuracy at each confidence level. A practical scorecard has five lines: decision accuracy, confidence calibration, median and P95 latency, cost per correct decision, and escalation rate. That produces an actionable result: route these cases to Jev above this threshold; send the rest to a larger model or review. It is more useful than either launch hype or a generic warning to distrust the model. Related Evals are a cost control Cost per successful task Why provider prices are not comparable Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Caching strategies compared · FinOps LLM URL: https://finopsllm.com/research/caching-strategies-compared Caching strategies compared Updated 4 July 2026 · first published 4 July 2026 Caching is one of the highest-leverage cost reduction tactics for LLM workloads. The idea is straightforward: do not pay for inference if you can return a cached result. But "caching" is not one technique - it is four distinct strategies with different trade-offs in cost savings, latency, accuracy, and implementation complexity. Choosing the wrong one wastes engineering effort; choosing the right one can cut 30–70% of your bill. Strategy comparison Strategy How it works Cost savings Latency impact Implementation effort Best for Providers Prompt cache (provider-side) Provider caches the KV computation for repeated prompt prefixes. Subsequent requests with the same prefix skip reprocessing. 50% on cached input tokens 60–80% faster first-token latency Zero to low - automatic on most providers Long system prompts, RAG with shared context, agent loops OpenAI, Anthropic, Google Semantic cache (embedding-based) Embed the user query, check a vector store for similar past queries. If similarity exceeds a threshold, return the cached response without calling the LLM. 20–50% depending on query repetition 50–90% faster (no LLM call) Medium - needs embedding model, vector store, similarity threshold tuning FAQ bots, customer support, repetitive queries Any (self-hosted via GPTCache, Redis with vector search) Context caching (Google-style) Cache large context documents (PDFs, codebases) server-side. Pay once for context processing, reuse across many queries at reduced per-query cost. 70–90% on context-heavy queries Moderate improvement on context processing Low to medium - upload context, manage TTL Document Q&A, code review over large repos, multi-turn with static context Google (Gemini), Anthropic (extended thinking context) Application-level cache (Redis/CDN) Deterministic hash of the full request (prompt + params). Store the response in Redis or a CDN. Return cached response on exact match. Up to 100% on cache hits 90–99% faster (no LLM call) Low - standard caching infrastructure Deterministic queries, classification, extraction with fixed prompts Any (infrastructure you control) Prompt caching in detail Prompt caching is the easiest win. OpenAI automatically caches prompts longer than 1,024 tokens. Anthropic caches prefixes of 2,048+ tokens. The cache is keyed on the exact prefix - same system prompt, same few-shot examples, same document context. When a cache hit occurs, you pay 50% less for the cached portion of input tokens. The catch: cache invalidation is provider-controlled. If the prompt changes even slightly - different system message, different variable in the prefix - the cache misses. Design your prompts to front-load stable content and push dynamic content to the end of the prompt. Semantic caching in detail Semantic caching skips the LLM entirely when a similar question was asked before. The flow: embed the query, search a vector store (Pinecone, Qdrant, Redis with vector search), check if the top result exceeds a similarity threshold (typically 0.92–0.97), and return the cached answer if it does. The risk is returning stale or slightly wrong answers. A threshold that is too low returns wrong results; one that is too high means almost no cache hits. Tune it per use case. For factual FAQ retrieval, 0.95+ is safe. For creative generation, semantic caching is rarely appropriate - the whole point is novelty. Context caching in detail Google's context caching lets you upload a large document once and pay a reduced rate for subsequent queries against it. This is powerful for document Q&A where you process the same 200-page PDF hundreds of times. The cost model: pay the full input token rate once for the cache write, then a reduced rate (often 25% of normal) for each cache read. The trade-off is TTL. Cached contexts expire. If your workload has bursty access patterns - 500 queries in one hour, then nothing for a week - the cache may expire between bursts. Size your TTL to match your access pattern. Application-level caching in detail Deterministic caching is the most aggressive strategy. Hash the full request payload (prompt, temperature, max tokens, model, tools) and store the response. On exact match, return the cached response instantly - no LLM call, no latency, no cost. This only works when the same input should always produce the same output. Classification, entity extraction, structured data parsing, and template-based generation are good candidates. Conversational or creative tasks are not - users expect varied responses. Combining strategies The best implementations layer multiple strategies. A typical stack: application-level cache as the first check (cheapest, fastest), semantic cache as the second check (catches near-duplicates), then the LLM call with provider-side prompt caching enabled (reduces cost even on cache misses). This layered approach can reduce total LLM spend by 40–70% on workloads with any degree of repetition. Track cache hit rates separately for each layer. If your semantic cache hit rate drops below 10%, the vector store overhead may not be worth it. If your application cache hit rate is above 40%, you likely have deterministic tasks that should be optimized at the prompt level. Related Prompt caching explained - deeper dive into provider-side caching. Semantic cache economics - ROI analysis of semantic caching. AI cost optimization - broader optimization strategies. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ How does prompt caching work in practice? Prompt caching is the easiest win. OpenAI automatically caches prompts longer than 1,024 tokens. Anthropic caches prefixes of 2,048+ tokens. The cache is keyed on the exact prefix - same system prompt, same few-shot examples, same document context. Cache-read tokens cost 50-90% less than input tokens. How does semantic caching work? Semantic caching skips the LLM entirely when a similar question was asked before. The flow: embed the query, search a vector store, check if top result exceeds similarity threshold (0.92-0.97), return cached answer if it does. Useful for support bots and FAQ systems where similar questions repeat. How does Google context caching work? Google's context caching lets you upload a large document once and pay a reduced rate for subsequent queries against it. Powerful for document Q&A where you process the same 200-page PDF hundreds of times. Tokens in the cached context cost 80-90% less. How does application-level caching work? Deterministic caching is the most aggressive strategy. Hash the full request payload (prompt, temperature, max tokens, model, tools) and store the response. On exact match, return the cached response instantly - no LLM call, no latency, no cost. How do caching strategies combine? The best implementations layer multiple strategies. A typical stack: application-level cache as first check (cheapest, fastest), semantic cache as second check (catches near-duplicates), then the LLM call with provider-side prompt caching enabled (reduces cost even on cache misses). Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # How to cap inference costs and prevent runaway spending · FinOps LLM URL: https://finopsllm.com/research/cap-inference-costs How to cap inference costs and prevent runaway spending A cap on inference spending is a hard limit that stops new requests when cost reaches a threshold, preventing runaway bills from agent loops, misconfigured retries, or unexpected traffic spikes. Caps exist at three levels: the API provider (budget caps on your account), the gateway or proxy layer (per-key or per-team limits), and the application (per-run token budgets, agent step limits, and idle-instance autoscaling). Most cost explosions can be prevented by implementing hard caps at all three, paired with alerting that fires before the cap is reached. This page covers the mechanics of capping costs, when each cap works, and the tradeoffs between hard stops and graceful degradation. Provider-level budget caps OpenAI, Anthropic, and most other providers offer a usage limit or spend cap at the organization level. OpenAI allows you to set a hard maximum monthly spend in the billing settings; requests fail with a quota-exceeded error once that limit is reached. Anthropic supports per-API-key monthly budgets with similar behavior. Azure OpenAI has deployment-level rate limits and quota caps. Bedrock provides account-level usage limits. The advantage of a provider cap is simplicity - it is the easiest lever to pull to prevent a runaway month. The disadvantage is coarseness: when the cap is hit, all traffic stops, whether it is mission-critical or experimental. If you hit a monthly cap on July 15, critical features are dark until August 1. How to set it: visit your provider's billing console, look for "usage limits," "spend caps," or "budget alerts," and set a number. Set it as a safety net, not as your primary control - alerts should fire long before the cap triggers. Gateway and per-key budget caps A gateway or API proxy layer sits between your application and the provider, routing requests and enforcing per-key or per-team budgets. Tools like LiteLLM, Ollama with custom middleware, and commercial proxies (such as those offered by enterprise observability platforms) can tag requests by team, feature, or environment, track spend per tag, and reject or degrade requests when a tag-specific budget is exceeded. A gateway cap is more granular than a provider cap. You can set different budgets for different teams: $500/month for team-support, $2000/month for team-search, $100/month for experiments. When team-support hits its limit, requests from team-support are rejected or downgraded to a cheaper model, but team-search continues normally. This prevents a single team's runaway feature from blocking everyone else. The tradeoff is complexity: you now have to deploy and maintain a gateway, tag requests consistently, and monitor per-team spend. But the control is worth it in any multi-team environment. How to implement: deploy a gateway that reads API keys or request headers, maps them to teams/features, and maintains a spend ledger per tag. Reject requests (HTTP 429) when a tag's daily or monthly budget is exceeded, or degrade to a cheaper model instead of rejecting. Pair this with a dashboard that shows spend per tag, so teams can see their burn rate in real time. Request rejection vs. graceful degradation When a cost cap is hit, you have two choices: fail the request (rejection) or transparently degrade (use a cheaper model or return a cached result). Rejection is the safest cap. A request hits the budget limit and returns an error immediately. The application knows it failed and can decide what to do: show an error to the user, queue for retry, or fall back to a non-AI feature. Rejection guarantees you will not exceed the budget, but it hurts availability. Degradation is the most user-friendly cap. A request hits the budget limit, but instead of failing, the gateway silently routes it to a cheaper model or returns a cached result. The user sees no error and the feature works, just potentially with lower quality or freshness. Degradation protects availability but requires careful tuning: if the cheaper model is too much worse, users will notice the drop in quality and blame the feature, not the cost control. Best practice is to use both: hard caps at the organization level (rejection, to prevent catastrophic overspend) and graceful degradation at the feature level (cheaper model, cached results, or partial feature disabling, to protect user experience). Pair both with alerts at 50%, 75%, and 90% of budget so engineers have time to fix the underlying issue before either cap kicks in. Runaway agent kill switches and token budgets Agent workloads are the most dangerous to costs because they can loop indefinitely. A planning bug, a tool that returns noise, or a missing termination condition can cause an agent to make dozens of model calls for a task that should take three. Prevent this with per-run safeguards. Per-run token budget: every agent invocation carries a maximum total input + output token limit. If the run exceeds it, the agent stops and returns an error. This is the primary circuit-breaker. Set it tight enough to catch loops (e.g., 100K tokens for a typical task) but not so tight that normal tasks fail. Per-run cost budget: absolute dollar cap per agent run. Especially critical when an agent can escalate from a cheap model to an expensive one mid-execution on failure. If the run would cost more than $1, stop and return an error instead of continuing. Step and loop limits: an agent should not be allowed to run more than N planning steps (e.g., 20) or more than M tool calls per run (e.g., 50). Either limit indicates a logic error or a pathological input the agent cannot solve. Tool-call allowlists: only allow the agent to invoke tools that have been explicitly registered. Add per-tool invocation caps (e.g., "call search tool at most 5 times per run"). Prevent unexpected or exploratory tool discovery. Kill-switch: an explicit per-agent feature flag that on-call engineers can flip to disable the agent entirely without a deploy. When an agent becomes unstable (due to a prompt change, a tool latency regression, or a bug), the kill-switch lets the team stop the damage immediately. The switch should be observable in dashboards so the team knows it is active and knows to fix the underlying problem. Idle GPU autoscaling and right-sizing Self-hosted GPU infrastructure incurs cost whenever instances are running, even if no requests are being processed. A small batch of inference work during business hours does not need a 4xA100 cluster sitting idle overnight. The fix is autoscaling. Autoscale to zero: when the queue is empty and no request has been received in N minutes, scale instances down to zero. This eliminates idle-time cost. The tradeoff is cold-start latency for the first request after a scale-down, but 100ms of cold start is almost always acceptable. Right-size capacity: measure your p99 request latency and queue depth. If p99 latency is still acceptable with fewer instances, you are paying for idle capacity. Many teams overprovision GPU capacity "just in case," then never use it. Start conservative, measure, and only add capacity when latency degrades. Use spot or preemptible instances: spot instances (AWS, GCP, Azure) are 60–80% cheaper than on-demand, but can be interrupted. Pair spot with on-demand fallback and persistent queues so interrupted jobs can retry. This trades reliability risk for cost; acceptable for batch work and evals, riskier for synchronous inference. Measure idle time: track the fraction of time instances are running with zero or near-zero requests. If an instance is idle more than 20 percent of the time, right-size down. If idle time is below 5 percent, consider adding capacity to reduce queue depth. Alerts vs. hard caps: the defense in depth strategy Hard caps prevent surprises, but they also stop traffic when hit. Alerts are the first line of defense: they fire when spend is 50 percent of budget, giving you time to investigate and fix the underlying issue before the hard cap is triggered. Hard caps are the circuit-breaker when alerts fail or when a cost event is happening faster than humans can respond. A complete strategy: Alert at 50% of budget: something is wrong or usage is higher than expected. Investigate immediately. Alert at 75% of budget: if the burn rate continues, you will hit the cap. Start degrading or disabling features. Alert at 90% of budget: critical. Flip the kill-switch or scale to cheaper models. Hard cap at 100%: circuit-breaker. Requests fail with an error. The team must fix the underlying issue. The goal is never to hit the hard cap. It is there as a circuit-breaker for when monitoring fails or when a cost event is happening too fast for humans to respond. In a well-run FinOps practice, hard caps almost never trigger. Related Agent spend guardrails - per-run token budgets, retry caps, and step limits. Why does my LLM bill spike? - diagnosis of common cost drivers before they become bills. LLM budget governance - org-level budget frameworks and policies. On-prem and self-hosted LLM FinOps - cost governance for self-hosted infrastructure. Token budget implementation - tracking and enforcing per-run token limits. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ How do I cap my OpenAI or Anthropic bill? Most providers offer organization-level spend limits and per-API-key budget caps. OpenAI allows setting a hard usage limit in the billing settings; Anthropic uses per-key budgets tied to spend thresholds. These caps reject new requests when the limit is reached, preventing overage. They work best paired with alerts that fire at 50 percent and 80 percent of the limit so you have time to investigate before hitting the hard stop. Why are idle GPUs costing money and how do I stop it? Self-hosted GPU infrastructure incurs cost whenever instances are running, even if no inference is happening. The fix is autoscaling: spin down instances to zero when idle, use spot/preemptible instances to lower per-unit cost, and right-size to actual throughput (a GPU sitting unused for 18 hours a day is oversized). Measure idle time via queue depth and request latency; if p99 latency is still acceptable with fewer instances, you are paying for idle capacity. How do I stop a runaway AI agent from spending unlimited money? Agents need per-run token budgets (total input + output cap), per-run cost budgets (hard dollar limit), and step/loop limits (max planning steps, max tool calls). Kill-switches let on-call engineers disable an agent entirely without deploying code. Paired with metrics on cost-per-task and retry rates, these guards catch runaway loops before they become a monthly surprise. What happens when I hit a cost cap - does the request fail or degrade? Hard caps reject incoming requests with an error (usually HTTP 429 or a timeout). Graceful degradation is a separate strategy: instead of failing, the system falls back to a cheaper model or returns a cached result. Hard caps are safer for preventing surprise costs; degradation is better for availability. Most teams use both - hard caps at the organization level and graceful degradation at the feature level. How do I set per-team or per-feature cost budgets? API keys can be tagged with metadata (team, feature, environment). A gateway or proxy layer routes requests based on those tags and enforces spend caps per tag. If team-search is capped at $500/month and hits that limit, requests for team-search return an error or degrade, but team-support continues normally. This requires a gateway (LiteLLM, Ollama with a cost middleware, or a custom reverse proxy). Can I set hard caps and still have monitoring and alerts? Yes. Hard caps are the last line of defense; alerts and monitoring are the first. Best practice is to alert at 50%, 75%, and 90% of budget so engineers have time to investigate before the cap hits. Use budget as a circuit-breaker only when alerts fail or when a cost event is happening faster than humans can respond. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Chargeback vs Showback: Picking the Right FinOps Model · FinOps LLM URL: https://finopsllm.com/research/chargeback-vs-showback Chargeback vs showback Updated 1 August 2026 Every organization that moves beyond a single central IT budget has to answer the same question: do we bill business units for what they use, or do we simply show them what they use? Chargeback and showback are the two answers. The choice is not just technical; it is a statement about maturity, trust, and how much budget ownership teams are ready to accept. Chargeback: budget follows consumption Under chargeback, the team that consumes a technology service pays for it. If engineering runs $50,000 of cloud compute in a month, $50,000 leaves engineering's budget and moves to the platform or provider cost center. The team sees the cost, owns the budget, and has a direct incentive to optimize. Chargeback works when: Tagging and attribution are accurate enough to withstand an audit. Teams can actually control the workloads that drive cost. Finance and engineering leadership agree on budget boundaries. There is enough FinOps expertise to support teams that overspend. Showback: visibility without budget transfer Showback reports the same usage data to business units but leaves the budget in central IT. Engineering still sees its $50,000 cloud footprint, compares it to other teams, and learns what drives it. The goal is behavior change and cost awareness, not a budget transfer. Showback works when: Cost allocation data is new and teams do not yet trust it. Shared services make precise billing difficult or unfair. The organization needs cultural change before structural change. Leadership wants to prove the value of visibility before adding friction. Side-by-side comparison Dimension Chargeback Showback Budget owner Business unit Central IT Incentive to optimize Strong and immediate Moderate; relies on culture Implementation effort High Low Data quality requirement Must be audit-grade Can be directional Political friction Moderate to high Low Best FinOps maturity Run phase Inform or Optimize phase Typical first use case Compute, storage, LLM API usage Shared platforms, AI pilots Why most teams start with showback Moving straight to chargeback is tempting because it creates instant accountability. But if the data is wrong, teams will argue every line item. If shared costs are allocated unfairly, trust erodes. If teams cannot control the services they are billed for, chargeback feels like a tax. Showback lets you surface the data, clean the tags, and build the dashboards before anyone's budget is on the line. It is the safer path to the same destination: a culture where every team understands and manages its technology spend. When chargeback becomes the right answer Chargeback becomes the right model when three conditions are met. First, the data is trusted: a finance analyst and an engineering manager can look at the same report and agree on what it means. Second, the cost is controllable: the team can change model choice, caching, routing, or usage patterns to lower the bill. Third, the organization is ready to transfer budget ownership without endless exceptions. AI and LLM workloads are often good early candidates for chargeback because usage is directly tied to product features and teams have levers they can pull: model tier, prompt length, cache design, and batch routing. Hybrid models are common Few organizations use pure chargeback or pure showback. A more practical design is chargeback for services teams can control and showback for shared platform costs. For example, an LLM platform team might showback the base infrastructure while charging back direct model API usage to the product teams that generate it. Related Why showback comes before chargeback — the migration path from visibility to accountability. IT chargeback and showback for AI — applying these models to LLM and GenAI spend. LLM chargeback and showback — the technical implementation view. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is the difference between chargeback and showback? Chargeback bills business units directly for the technology they consume. Showback reports the same costs to business units without transferring the budget. Chargeback creates accountability; showback creates visibility. Is chargeback or showback better for FinOps? Showback is better early in a FinOps journey because it builds trust and surfaces data-quality issues without political friction. Chargeback is better once tagging is clean and teams are ready to own their budgets. Most organizations evolve from showback to chargeback. How does chargeback vs showback apply to AI and LLM spend? AI and LLM costs are granular, spiky, and tied to product usage. Showback helps teams see which features and experiments drive spend. Chargeback gives teams the incentive to optimize model choice, caching, and routing. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Chargeback when your provider won't bill per team · FinOps LLM URL: https://finopsllm.com/research/chargeback-without-per-team-billing Chargeback when your provider won't bill per team 19 July 2026 The cleanest path to LLM chargeback is billing at the credential boundary. Give each team their own API key, each gets its own invoice line, finance is happy, done. But the world is messier. Everyone shares one org key. The provider invoice is a single undifferentiated number. The credential boundary does not match the team boundary. This is the single most common blocker to AI chargeback in practice. Here are the four ways to work around it, with honest tradeoffs for each. 1. Key-per-team (simplest but sprawling) Create an API key for each team and route their requests through it. At request time, select which key to use based on headers, metadata, or request context. Each team gets their own provider invoice line. Pros: Billing is automatic. Finance sees one line per team with no allocation math. No shared infrastructure to maintain. The provider view is clean and matches your org structure perfectly. Cons: Key sprawl. Hundreds of keys to rotate, audit, and revoke. Quota limits fragment—a team with a low quota cannot borrow unused quota from teammates. Team-level rate limits mean one team cannot spike into another's allocation. Key rotation at scale becomes a rotation incident. If teams are microservices or ephemeral (short-lived jobs, containers), managing per-team keys becomes infeasible. Cold-start jobs fight over quota because they all spin up at once. When to use it: You have fewer than ~20 teams and keys live long (not ephemeral). Teams are stable and well-known. Quota isolation between teams is a business requirement, not just a nice-to-have. 2. Gateway or proxy (best fidelity, hot-path risk) Sit a stateless reverse proxy between your application and the provider. Every request passes through it. The proxy tags each request with team, feature, and environment metadata—either extracted from headers or injected by the caller—then logs the tagged request with its usage before forwarding. The proxy selects which API key to use (or uses a shared key) and passes the request through. Pros: Request-level fidelity. You see team, feature, environment, and workload metadata for every call. Log format is consistent because it's enforced at one point. Requests are tagged before any retry or caching layer, so you capture failure modes. No application code needs to know about chargeback; the proxy is transparent. You can filter, rate-limit, or audit at the gateway layer. Cons: Sits in the hot path. Every request latency is affected; a poorly tuned gateway adds tail latencies or becomes a bottleneck. Logging overhead (writes to the log pipeline) directly impacts throughput. If the gateway fails, all LLM traffic fails. Key rotation, credential management, and quota handling happen here too—bugs are production incidents. Requres deployment and SRE overhead. Testing is harder because you must test the full path including the proxy. When to use it: You have traffic volume and latency sensitivity that can absorb a few milliseconds of proxy overhead. You have SRE capacity to maintain an additional service in the hot path. Request-level attribution is essential for your business model (per-customer or per-feature billing, or precise chargeback). Your log pipeline is reliable enough that every request tag reaches your data warehouse without loss. 3. Application-level telemetry with OpenTelemetry GenAI (safe, incomplete) Do not route traffic through a proxy. Instead, instrument the application layer that calls the LLM provider. Use OpenTelemetry GenAI conventions (or equivalent structured logging) to tag every request with team, feature, endpoint, and workload metadata. Send those tags to your observability platform alongside the provider usage data. Match requests to usage by correlation ID and timestamp. Pros: No proxy to maintain. Application layer already has the metadata (team from auth context, feature from code path, endpoint from URL). Does not sit in the hot path; tags are written asynchronously to telemetry backends. Failures in the telemetry pipeline do not break LLM requests. Teams can instrument at different rates—gradual rollout is safe. Standard OpenTelemetry format means tools and training exist; not a custom solution. Cons: Only covers instrumented code. Legacy codebases or third-party SDKs that call the LLM provider without instrumentation are invisible. Async telemetry means you may miss requests on application crashes. Matching requests to provider usage requires correlation IDs and clock sync; off-by-one errors in timestamp matching cause orphaned costs. Incomplete coverage means a portion of spend is always unattributed and needs statistical fallback. Instrumentation drift—if teams update code without updating tags—breaks showback downstream. When to use it: Your codebase is new, well-structured, and under your control. You can require instrumentation as part of the LLM caller contract. Workload is not deadline-critical, so async telemetry overhead is fine. You have a mature observability platform (Datadog, New Relic, Honeycomb) that speaks OpenTelemetry natively. Incomplete coverage is acceptable as long as it covers your top spend paths. 4. Statistical allocation (last resort, auditable only with care) Log which teams made requests, but not their usage. Allocate total provider spend across teams based on request ratios, model popularity, or proxy metrics (token counts from your cache, batch job metadata). Work backwards from the provider invoice. Pros: Minimal integration. Works with existing shared API keys. Requires no gateway or application changes if you already have team-level request logs. Statistical models are fast and cheap to compute. Cons: Allocations are rough guesses. One team's expensive reasoning request can vanish into the noise if you allocate by request count. Model pricing changes between invoice periods and attribution lags; you may allocate against stale prices. Retries and fallbacks are invisible—you lose attribution for failed requests. Finance will demand reconciliation and you will be unable to explain why Team A was charged $8,000 for 2,000 requests when the same team elsewhere used 2,000 requests for $3,000. Teams will argue the allocation is unfair. Audit trails are weak; you cannot point to any single request and explain why it was charged to that team. When to use it: This is genuinely a last resort. Use it only if none of the other three approaches are feasible—perhaps you are in a hard vendor lock-in, or you have a short time window before migrating systems. Even then, use it as a temporary bootstrap and a signal to move away from undifferentiated billing. If you must use statistical allocation, layer it with application-level telemetry for your top 80% of spend, and allocate the remaining 20% statistically. This keeps finance happy without needing perfect coverage. Reconciliation to the provider invoice Whatever method you choose, reconcile it back to the raw provider invoice monthly. The total allocated spend across all teams should match (or nearly match) the provider invoice line for that month. Small gaps are normal—rounding, delayed invoice lines, or provider-specific bulk discounts. Large gaps mean your log pipeline is losing traffic, your price tables are stale, or your proxy is dropping requests. The reconciliation check is not optional. It is your guarantee that chargeback numbers survive finance review. Without it, teams will find discrepancies, audit will find gaps, and you will lose the trust needed to actually charge them. Set up a monthly report that shows: total provider invoice, total allocated spend, difference in dollars and percentage, and the top 10 unallocated requests (if any). Flag any month where the gap exceeds 5%. This is your early warning system for pipeline rot. What "good enough" attribution coverage means Do not chase 100% attribution. It is a trap. Perfect coverage requires perfect instrumentation, perfect telemetry, perfect logging, perfect reconciliation—and the cost of reaching the last 5% often exceeds the value of the accuracy gain. Aim for 80–90% coverage: the requests that drive 95% of your spend should have clear team and feature attribution. The remaining 10–20% (lower-cost or edge-case requests) can be statistically allocated or left visible as unallocated. This is good enough for showback, good enough for optimization ranking, and good enough for chargeback budgets. Coverage is measured by dollars, not by request count. A system that attributes 80% of requests by count might only cover 40% of spend if the unattributed requests are expensive. Track coverage by cost, not by volume. Staged rollout: showback first Never go straight to chargeback. Start with showback: build your attribution method (whichever of the four you choose), send reports to teams showing their spend, and let them validate the numbers for a month or two. They will find bugs. You will discover missing teams or features. Trust will build. Only move to chargeback once: Attribution coverage is 80%+ of spend and stable month-over-month. Teams have seen showback reports and challenged the numbers. You have fixed the obvious bugs. Reconciliation to the provider invoice is solid. Finance has audited it. Teams understand how to optimize. They cannot see a button labeled "chargeback" and assume they are now blocked from using the LLM. Even after you move to chargeback, keep the showback reports running in parallel for 3–6 months. Let teams see both the allocation and the charge. If discrepancies appear, you can revert to showback-only mode without losing the entire system. Related LLM chargeback and showback - designing allocation models. LLM cost attribution - attribution foundations and dimensions. OpenTelemetry GenAI conventions - structured telemetry for LLM workloads. What is LLM FinOps? - the complete operating discipline. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # ChatGPT Pro Max: $500 Plan Economics · FinOps LLM URL: https://finopsllm.com/research/chatgpt-pro-max-economics ChatGPT Pro Max $500 plan economics Updated September 27, 2026 · first published September 27, 2026 The instinct when a flat subscription looks expensive is to model it against token pricing. ChatGPT Pro Max is a $500/month seat, which is enough to trigger that instinct immediately. The instinct is right, and the conclusion is usually wrong in the other direction: a flat seat is not a cheaper version of metered API spend. It is a different shape of spend with a different risk profile, and the honest question is where it belongs in the runbook. What a flat seat actually buys A metered API bill is variable and attributable. You know which request cost what, which is why token cost control is tractable. A flat seat is the same money every month regardless of usage, and the usage is not individually attributable. That single property drives everything below. The break-even, with assumptions stated Take a $500/month seat and ask what metered spend it replaces. The comparison needs three inputs, and all three are assumptions you have to defend: Tokens per seat per month. The dominant variable, and the one nobody tracks on flat plans because there is no meter to read. The blended rate. A mid-tier model at $2/$10 or a premium model at $4/$20 changes the answer by 5x for the same workload. Who was using it. A seat that one engineer uses for interactive work is a different purchase from a seat wired into a batch job. At roughly 30M input and 4M output tokens in a month, a $2/$10 mid-tier model bills around $100. A $4/$20 premium model bills around $200. To reach $500 on metered API you need either a much heavier workload, heavier reasoning, or a lot of interactive exploration that never gets logged. That last one is the real story: heavy interactive use is exactly what token metering undercounts and what a flat seat subsidises. Where the flat seat genuinely wins Interactive exploration. Trying models, prompting, and reading long outputs is high-token, low-production, and impossible to forecast. Metered API punishes it. Unattended background work. Overnight research or batch summarisation is steady, large, and easy to move to batch or a cheaper tier — as long as you actually move it. Peak load. A demo, an incident, or a launch week is unbounded. A seat has no rate to exceed. Token-blind workloads. Anything where a human is iterating in the loop and no request log exists. Where it loses Volume above the plan. Past the break-even, every additional token is free-but-wasted, which removes the signal that would tell you to optimise. Serving other people. If a product or a client bills on that work, an unbudgeted seat is an unbounded COGS line. The seat's flat price is not a cost-per-customer number. Governance. No per-request attribution means no cost-per-team, no cost-per-customer, and no evals-cost line. You can only bound the month, not explain it. The rule that keeps it honest Keep flat seats out of anything that ships to a customer or appears in a margin calculation. Keep metered API for everything that does. A $500 seat is a legitimate internal tooling line, and it should be budgeted as a fixed cost with a named owner, not amortised into a unit economics number where it quietly inflates apparent margin. Bottom line The $500 seat is cheap for interactive exploration and dangerous for anything metered per customer. Treat it as a fixed internal tooling line, keep metered API for anything that ships, and if you cannot state the tokens-per-seat figure, you cannot yet tell whether the seat is saving or spending. Related SaaS AI credits and metering AI feature gross margin Committed spend discounts First AI month-end close Proving AI ROI Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Cheapest Way to Run AI Code Generation (2026) · FinOps LLM URL: https://finopsllm.com/research/cheapest-ai-code-generation Cheapest Way to Run AI Code Generation Updated 4 July 2026 · first published 4 July 2026 AI code generation tools have exploded in variety - but the cost difference between options is enormous. A light user might spend $10/month with one approach and $200/month with another for nearly identical results. This guide compares every category of AI coding tool, calculates real monthly costs for different usage levels, and gives you a decision tree to pick the cheapest option that actually works for your workflow. The four categories Every AI code generation tool falls into one of four pricing models: Subscription agents - flat monthly fee, usage bundled (Cursor, Copilot, Windsurf, Cody). API-based agents - you bring your own API key, pay per token (Claude Code, Cline, Aider, Continue with cloud APIs). Self-hosted models - run open-weight models locally or on your own GPU (Continue + Qwen, CodeLlama, DeepSeek Coder). Coding plan providers - flat-rate API access optimized for coding workloads ( MiMO , GLM, MiniMax, KwaiKAT). Cost comparison table Option Monthly Cost (Light) Monthly Cost (Heavy) Model Quality Setup Effort GitHub Copilot Free $0 $0 Good None GitHub Copilot Pro $10 $10 Very good None Cursor Pro $20 $20 Excellent Low Windsurf Pro $15 $15 Very good Low Claude Code (API) $5–15 $50–200 Excellent Medium Cline + API key $5–20 $40–150 Excellent Medium MiMO Coding Plan $10–15 $30–60 Very good Low GLM Coding Plan $10–15 $30–60 Good Low Continue + local model $0 $0 Decent High Light user: ~2 hours/day, ~50 requests/day. Heavy user: 8+ hours/day, ~300 requests/day. API costs assume average 3K input + 1K output tokens per request with Claude Sonnet or GPT-4o pricing. Category breakdown 1. Subscription agents These are the easiest to adopt. You pay a flat fee and get a generous (or unlimited) usage quota. The catch: you're locked into their model choice and IDE integration. Cursor Pro ($20/mo) - Best overall UX for power users. Includes fast requests (GPT-4o, Claude Sonnet) and slow requests (frontier models). The 500 fast-request/month limit is enough for most developers. GitHub Copilot ($10/mo) - Cheapest mainstream option. Tab completions are excellent; chat is good but less powerful than Cursor's agent mode. Free tier available with limits. Windsurf Pro ($15/mo) - Competitive middle ground. Good agentic features at a lower price point than Cursor. Verdict: Best for developers who want zero setup and predictable billing. Copilot Free is unbeatable for budget-conscious users. 2. API-based agents You bring your own API key (OpenAI, Anthropic, etc.) and the tool makes API calls on your behalf. Costs scale linearly with usage - great for light users, expensive for heavy users. Claude Code - Anthropic's CLI agent. Uses Claude Sonnet or Opus. A heavy session can cost $2–5 in API fees. Cline (VS Code) - Open-source agent that works with any API. Very flexible, but costs are unpredictable without budget caps. Aider - Terminal-based, works with any model. Popular for its git integration and edit-mode approach. Verdict: Best for developers who want model flexibility and are willing to monitor usage. Light users pay less than subscriptions; heavy users pay more. 3. Self-hosted models Run open-weight models (Qwen 2.5 Coder, DeepSeek Coder V2, CodeLlama) locally via Ollama, vLLM, or llama.cpp. Zero marginal cost per request - but you need hardware. Pros: No per-token cost, full privacy, no rate limits, works offline. Cons: Quality gap vs. frontier models (especially for complex refactoring), requires a capable GPU (16GB+ VRAM for good results), setup friction. Verdict: Best for privacy-sensitive work, offline environments, or teams with existing GPU infrastructure. Not recommended as your only model - pair with a cloud model for hard tasks. 4. Coding plan providers A newer category: providers offering flat-rate or heavily discounted API access specifically for coding agents. These bridge the gap between expensive per-token API pricing and rigid subscription tools. MiMO Coding Plan - Competitive pricing with strong reasoning capabilities. Good balance of cost and quality. GLM (Zhipu) - Chinese provider with aggressive pricing for coding workloads. MiniMax / KwaiKAT - Emerging providers with coding-optimized pricing tiers. Verdict: Best for API-based agent users who want to reduce costs without switching to self-hosted. Quality varies - benchmark on your actual tasks before committing. Decision tree Follow this to find your cheapest option: If you code <2 hours/day: Use GitHub Copilot Free . Zero cost, excellent completions. If you hit limits, upgrade to Copilot Pro ($10/mo). If you code 2–6 hours/day: Use Cursor Pro ($20/mo) or Windsurf Pro ($15/mo) . The flat rate is cheaper than API costs at this volume. Alternatively, use a coding plan provider like MiMO with Cline for $10–30/mo. If you code 8+ hours/day: Use an API-based agent with a coding plan (MiMO, GLM) at $30–60/mo. Standard API keys (Claude, GPT-4o) will cost $100–200/mo at this volume. Consider a local model for routine completions to further reduce costs. The hidden costs nobody talks about Context window waste. Most coding agents send your entire file + conversation history on every request. A 50K-token context on GPT-4o costs $0.125 per request in input alone. Over 200 requests/day, that's $25/day - more than a monthly Cursor subscription. Retry loops. Agentic tools that auto-retry failed edits can burn through tokens fast. Set hard limits on retry counts. Model switching overhead. Some tools default to the most expensive model. Check your settings - Cursor's "slow" requests use cheaper models and are often fast enough. Bottom line For most developers, a subscription agent (Copilot or Cursor) is the cheapest option because it caps your costs regardless of usage. For power users willing to manage API keys, coding plan providers like MiMO offer the best cost-per-quality ratio. Self-hosted models are free but quality-limited - best as a supplement, not a replacement. Whatever you choose, track your spend per tool so you can re-evaluate as pricing changes. Related AI coding plan comparison - detailed benchmark of coding plan providers. How much does GPT-5 cost? - frontier model pricing explained. Provider arbitrage - systematic approach to finding cheaper models. Model routing - sending tasks to the right cost tier. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What are the four categories of AI code generation? Subscription agents (Cursor, Copilot, Windsurf, Cody) charge a flat monthly fee with bundled usage. API-based agents (Claude Code, Cline, Aider) use your API key and charge per token. Self-hosted models run open-weight models on local or personal GPU. Coding plan providers (MiMO, GLM) offer flat-rate API access optimized for coding. How do category costs break down? Subscription agents are easiest to adopt with generous usage quotas but lock you into their model choice. API-based agents expose raw costs that spike unpredictably. Self-hosted models require GPU rental infrastructure. Coding plan providers offer competitive pricing matched to coding workload economics. How do I choose the cheapest option? First identify your usage pattern: light (10-20 sessions/month), medium (40-100), or heavy (200+). Then check: subscription cost vs estimated API token cost, model availability for your use case, IDE integration quality, and whether you need specific reasoning capabilities. What is the bottom line? For most developers, a subscription agent (Copilot or Cursor) is cheapest because it caps costs regardless of usage. For power users willing to manage API keys, coding plan providers like MiMO offer the best cost-per-quality ratio. API-based agents beat subscriptions only for very light usage patterns. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # How to Check and Reduce Claude Code Token Usage · FinOps LLM URL: https://finopsllm.com/research/claude-code-token-usage How to check and reduce Claude Code token usage Updated September 27, 2026 · first published September 27, 2026 Quick answer: Run /usage to see what Claude Code is spending, and /context to see what is filling the window. To spend less, keep context small: clear between tasks, lower the effort level, and keep verbose output... Run /usage to see what Claude Code is spending, and /context to see what is filling the window. To spend less, keep context small: clear between tasks, lower the effort level, and keep verbose output out of the main conversation. Context matters more than anything else because Claude Code re-sends the whole conversation with every request. In our own logs, 96% of tokens were the agent re-reading its context. This page covers the commands that show your usage, the settings that move it most, and where the tokens actually go. The tips come from Anthropic’s cost documentation . The numbers come from our own Claude Code logs and published benchmarks. How do I check Claude Code token usage? /usage : shows token counts and an estimated cost for the current session, a prompt cache line, and on Pro, Max, Team and Enterprise plans your plan usage bars. It also breaks down what is using your plan: skills, subagents, plugins, MCP servers and scheduled loops, over the last 24 hours or 7 days. /context : shows what is taking up the context window right now, with hints on what to trim. /insights : writes an HTML report on your recent sessions and where you lose time and tokens. The status line : a script can show cost, context used and your 5-hour and 7-day plan percentages on every prompt. See status line docs . claude.ai Settings > Usage : plan limits and usage-credit spend, including use from other devices. On a Pro or Max plan, the dollar figure in /usage is what the session would have cost at API list prices, not what you pay. It is still the best single measure of how heavy a session is. Where do Claude Code tokens actually go? Mostly into re-reading context. Every request carries the full conversation, and every tool call sends another request with the results. Across our Claude Code logs, 7.0 billion cache-read tokens were 96% of all tokens and half of a $6,986 API-equivalent bill. Output tokens, the part you see, were under 1% of volume. That is why a one-line question in a session that has been open all day is not cheap. It carries the whole day with it. Our tokens per plan page has the full breakdown: about 1.9 billion tokens in a Max 20x week and about 39 million in a Max 5x session. How do I reduce Claude Code token usage? These are the changes that move usage most, in rough order of effect. Clear between unrelated tasks. /clear starts a fresh context and costs nothing. Use /rename first if you want to /resume the old session later. Lower the effort level. On Opus 5.5, one task cost $5.98 at max effort and $1.34 at medium in Artificial Analysis runs, a 4.5x difference from one setting. Use /effort to change it. Details on our effort level cost page . Match the model to the job. Anthropic recommends Sonnet for most coding and Opus for hard architectural or multi-step work. Switch with /model , and set model: haiku on simple subagents. Don’t take long breaks mid-session. The prompt cache lasts an hour on a subscription and five minutes on usage credits or an API key. Coming back after it expires re-processes your whole context at full price. Keep noisy output out of the main context. Send test runs, log reading and doc fetching to subagents so only a summary comes back. A hook can filter a 10,000-line log down to the error lines before Claude sees it. Trim what loads at start. Keep CLAUDE.md under about 200 lines and move workflow-specific instructions into skills, which load only when used. Disable MCP servers you aren’t using with /mcp . Prefer CLI tools like gh where one exists. Write specific prompts and plan first. “Improve this codebase” makes Claude scan everything. Plan mode (Shift+Tab) catches a wrong approach before it costs a full implementation. Watch background work. Scheduled loops, agent teammates and idle subagents keep sending your full context. Agent teams use about 7x the tokens of a normal session when teammates run in plan mode. Does /compact save tokens? Only on later requests, and compacting a big context is itself a big request. /compact reads the whole conversation to summarize it. If you don’t need the history, /clear is cheaper. If you do, /compact with instructions (for example /compact keep the API changes and failing tests ) keeps what matters. You can also set an earlier auto-compact threshold with /autocompact . How much does Claude Code cost per developer? Anthropic says about $13 per developer per active day and $150 to $250 a month across enterprise deployments, and under $30 a day for 90% of users. That is billed at API rates. On a subscription the question becomes which plan’s limits you hit first. Our Claude Max weekly limit page prices a Max 20x week at about $1.86k of API-equivalent usage. How do teams track Claude Code usage? Team and Enterprise plans: the spend report in org analytics, with a per-user CSV. Enterprise also has an analytics API. Spend limits are set in admin settings. API (Claude Console): the Console usage page and workspace spend limits. Any setup: set CLAUDE_CODE_ENABLE_TELEMETRY=1 to export per-user token and cost metrics over OpenTelemetry to your own stack. See monitoring docs . If you pay contracted rates, the modelPricing managed setting makes the cost figures in /usage and OpenTelemetry match your contract instead of list price. Sources Claude Code docs: Manage costs effectively Claude Code docs: Status line Claude Code docs: Monitoring usage Artificial Analysis: model benchmarks and cost per task Related How many tokens Claude Pro and Max give you Opus 5.5 effort levels are the real price Claude Max 20x vs 5x: the weekly limit, measured Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Claude Fable 5.1: $10/$50, and a $0.25 cache read · FinOps LLM URL: https://finopsllm.com/research/claude-fable-5-1-cost-model Claude Fable 5.1 cost model Updated September 1, 2026 · first published September 1, 2026 Quick answer: Claude Fable 5.1 (claude-fable-5-1) is priced at $10 per million input tokens and $50 per million output tokens. Opus 5 is $5 and $25. Read only those four numbers and Fable looks like a flat 2×... Claude Fable 5.1 ( claude-fable-5-1 ) is priced at $10 per million input tokens and $50 per million output tokens. Opus 5 is $5 and $25. Read only those four numbers and Fable looks like a flat 2× premium. That is the wrong model. The cached-input rate moves in the opposite direction, and for a production workload the cache is usually where most of the tokens are. The four rates that matter A model is not one price. Fable 5.1 bills five different token types, and only two of them are on the headline. Token type Fable 5.1 Opus 5 Input (uncached) $10.00 / MTok $5.00 / MTok Output $50.00 / MTok $25.00 / MTok Cache write (5-minute) $12.50 / MTok $6.25 / MTok Cache write (1-hour) $20.00 / MTok $10.00 / MTok Cache read $0.25 / MTok $0.50 / MTok The cache read is the outlier. It is 2.5% of Fable's own list input price, and it is half what the same cached token costs on Opus 5. Every other row is 2×; that one row is 0.5×. What that does to a real workload Take an agent with a 100,000-token system prompt, tool schema, and retrieved context, reused across a session. On a cold call the prefix costs $1.00 on Fable and $0.50 on Opus 5. On a warm call it costs $0.025 on Fable and $0.05 on Opus 5. The provider that was twice as expensive is now half the price, on the same prompt, because the only thing that changed is whether the prefix hit. So the break-even is a cache hit ratio, not a model preference. Below roughly 50% of input tokens served from cache, Fable's input premium dominates and Opus 5 is cheaper on prefix. Above it, Fable's cached rate pulls ahead and keeps pulling. Output tokens stay 2× either way, which is why the second lever is output length, not model choice. Output is the uncapped side Fable 5.1 accepts a 1M-token context window and can emit up to 128K output tokens in one response. At $50 per million, a single 128K response is $6.40 of output. Extended thinking is always on for this model — there is no way to switch it off, and the old budget_tokens control is rejected with a 400. What you get instead is an effort setting from low to max. That is now a cost dial, and it belongs in your routing policy next to model choice, not in application defaults nobody revisits. Raw reasoning is never returned, so your telemetry cannot reconstruct thinking cost from response text. You must read it from the usage block on every call and store it. There is no Priority Tier on this model either, so latency cannot be bought — capacity planning has to be done with concurrency and queueing on your side. What to instrument before you route traffic Three fields decide whether Fable 5.1 is cheap or expensive for you, and none of them appear on a price sheet. Cache hit ratio by feature. Not an account-level average — a chat surface at 90% and a batch job at 0% cancel each other into a meaningless 45%. Cache write amplification. A 1-hour write costs 2× list input. A prefix that is rewritten more often than it is read is a net loss at any TTL. Output tokens per successful task. The 2× output premium is only justified if fewer attempts are needed. Measure cost per successful task, not cost per call. Then run the comparison as a variance bridge against your current model, splitting rate from volume from mix. A model that is twice the list price and half the cached price will show up as two large offsetting movements, and an average will hide both. Related Prompt caching economics Reasoning model cost guide Model routing Related Prompt caching economics Reasoning model cost guide Model routing Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Claude Max 20x Price vs Its Real Weekly Usage Ceiling · FinOps LLM URL: https://finopsllm.com/research/claude-max-20x-vs-5x-weekly-limit Claude Max 20x vs 5x: is the $200 price worth it? We measured the real weekly usage ceiling Updated September 27, 2026 · first published September 27, 2026 Quick answer: No. Claude Max 20x is 20 times Pro per 5-hour session, not per week. At a price of $200 a month, its real weekly usage ceiling, measured from Claude Code logs, is worth about $1.9k of API-priced... No. Claude Max 20x is 20 times Pro per 5-hour session, not per week. At a price of $200 a month, its real weekly usage ceiling, measured from Claude Code logs, is worth about $1.9k of API-priced usage. That is at most about 1.5 times what a Max 5x week delivered, and independent testing puts it near 2 times. For twice the price, you get roughly twice the week at best. This page answers one question from our full 60-day study of Claude Max against ChatGPT Pro and Codex : how much bigger the $200 Claude plan really is than the $100 one. Every number comes from one heavy user’s logs, priced at the API list price in force on the day each request ran. Is Claude Max 20x really 20 times Pro? Only inside a single 5-hour session. Anthropic sells Max 5x at $100 and Max 20x at $200, and the multiplier describes how much more you can do in one 5-hour window than on the $20 Pro plan. On top of that window sits a weekly limit. Anthropic does not publish its size in tokens, hours or dollars, and for anyone who codes with agents most of the day, the weekly limit is the one that actually stops work. So the question that matters is not “20x of what?” but “how big is the week?” How big is the Claude Max 20x weekly limit? About $1.86k of API-equivalent usage at today’s limits, in a range of $1.74k to $2.2k. Our user hit the Max 20x weekly limit twice in August 2026, after $2,085 and $2,379 of usage. Another week reached $2,636 without a hit. Each bar is one weekly limit window, priced at Anthropic list rates of the day. “CAP HIT” marks weeks where Claude Code logged “You’ve hit your weekly limit”. The week of 28 Aug went past $2.6k without a hit, so the cap is not a fixed dollar amount. Max 5x never hit its weekly cap. *Partial week. The limit is not a fixed dollar amount. Anthropic meters in its own units, and pricier models use them up faster: the week with more Fable spend hit the limit $300 sooner. All of these weeks also ran under a promotion that set limits to 150%. Scaled to the current 125%, the two hits give the range above. How big is the Claude Max 5x weekly limit? At least $1,217 of API usage a week. We never reached it. In September, on Max 5x, our user’s busiest week came to $1,461 (about $1,217 at 125%) without touching the weekly cap. What stopped them instead was the 5-hour session limit, twelve times in the month, after a median of $37 of work. Twelve distinct 5-hour windows hit their limit in September. Median $37, mean $44. The low values are windows the user entered already part-spent; the $93 and $127 windows are what a full, deliberate session holds. That is the real difference between the tiers in daily use. On Max 20x you run into a wall once a week. On Max 5x you run into a smaller wall most afternoons. So how much bigger is Max 20x than Max 5x per week? About 1.5x to 2x, not 4x. Our logs put the Max 20x week at most 1.5 times a Max 5x week. It is an upper bound, because the 5x cap never bound, so the true ratio may be lower still. Codeongrass tested both tiers and measured about 2x. The Claude “20x” applies to the 5-hour session. Its weekly cap, which is what binds a heavy user, is not four times the Max 5x weekly cap. Our bound: the Max 20x cap was $2.1k–2.6k while Max 5x delivered $1,461 in a week without hitting its cap. When does the Claude Max weekly limit reset? At a fixed time each week that Anthropic assigns to your account, while the session limit resets every five hours. Anthropic doesn’t publish the ceiling in tokens either. Our token breakdown converts the measured week into tokens: about 2 billion, almost all of it cache reads. When is Claude Max 20x worth the extra $100? When the 5-hour session limit, not the weekly one, is what stops you. The part of Max 20x that really is four times bigger is the session. If you run long, unattended agent jobs, or your working day is one continuous block, that matters. If your work comes in bursts spread over the week, Max 5x gives you well over half the weekly capacity for half the price. If this is you Buy You hit the 5-hour limit on Max 5x most working days, and waiting costs real money Max 20x You hit the 5-hour limit a few times a week Max 5x You hit the weekly limit on Max 5x Max 20x, or add a second vendor such as ChatGPT Plus for $20 You never hit either Max 5x, or even Pro You don’t need to guess which row you are in. Claude Code writes every request and every limit notice to the JSONL files under ~/.claude/projects . Count the limit notices over two weeks before you upgrade. Upgrades are prorated, so moving from 5x to 20x mid-month costs nothing extra if the evidence says you need it. Would ChatGPT Pro be better value than Claude Max 20x? For well-specified coding work, probably yes, by about 2.4x on finished tasks. GPT-6 Sol needed 3.3 to 4.2 times fewer dollars than Claude for the same coding task in independent tests. That holds only if ChatGPT Pro 20x’s weekly limit really scales by more than about 7x. The full comparison works through that assumption, and our Codex limits breakdown shows what a ChatGPT week holds. Sources Anthropic: What is the Max plan? Anthropic API pricing codeongrass: Claude Code vs Codex for heavy users Related Claude Max vs ChatGPT Pro: the full 60-day study How much Codex ChatGPT Pro includes How many tokens Claude Pro and Max give you Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Claude Max 20x Isn’t 20x: 60 Days of Logs vs Codex · FinOps LLM URL: https://finopsllm.com/research/claude-max-vs-chatgpt-pro-codex-200 Claude Max 20x isn't 20x. We checked 60 days of logs against Codex Updated September 27, 2026 · first published September 27, 2026 Quick answer: Claude Max 20x and ChatGPT Pro 20x (Codex) both cost $200 a month, and both are worth many times that at API prices. Claude Max 20x holds more raw API value: we measured its weekly cap at about $1.86k... Claude Max 20x and ChatGPT Pro 20x (Codex) both cost $200 a month, and both are worth many times that at API prices. Claude Max 20x holds more raw API value: we measured its weekly cap at about $1.86k of API-equivalent usage, against a projected $1.34k for ChatGPT Pro 20x. Codex finishes more work with that money, because GPT models needed 3.3 to 4.2 times fewer dollars for the same coding task in independent tests. So at $200, ChatGPT Pro 20x buys about 2.4 times more finished tasks , as long as OpenAI's 20x multiplier holds for the weekly window as well as the 5-hour one. At $100 the two plans are close to even. Claude Max 5x has the edge in our data, because its weekly cap never bound. The rest of this page explains how we got those numbers and how to check them against your own logs. It is built on 60 days of one heavy user's Claude Code and Codex logs, priced token by token at the API list price in force on each day, and set against every public measurement we could find. It is meant to settle the decision for someone who genuinely cannot choose between the two plans. The numbers below are the reason for each call. If you only came for one answer, here they are in the words people search with: Is Claude Max 20x really 20x? Only per 5-hour session. Per week it gave at most about 1.5x a Max 5x week in our logs, and about 2x in independent tests. Which $200 plan gets more work done? ChatGPT Pro 20x with Codex, by about 2.4x, if its weekly limit really scales 20x. It still wins down to about 7x. Which $100 plan? Claude Max 5x, narrowly. Its weekly cap never bound. Is Codex cheaper than Claude Code per task? Yes, by 3.3x to 4.2x in two independent tests. Should you split $200 across both vendors? It beats Claude Max 20x on finished tasks, but not ChatGPT Pro 20x. Details below. Why can’t you compare the two “20x” plans directly? Both vendors sell a $200 plan labelled “20x”, and a $100 plan labelled “5x”. The labels invite a comparison that does not hold, because the two companies are multiplying different things. Anthropic sells Claude Max 5x ($100) and Max 20x ($200). The multiplier applies to the 5-hour session relative to the $20 Pro plan. A separate weekly cap sits on top of it, and Anthropic does not publish its size. A heavy user of Claude Code runs into the weekly cap, so the headline multiplier says little about what that user gets. OpenAI sells ChatGPT Plus ($20), Pro 5x ($100) and Pro 20x ($200). Its Codex usage page lists per-window message ranges that scale by exactly 5x and 20x between tiers. It also prices extra Codex credits at API parity. OpenAI does not state whether the weekly window scales by the same factor as the 5-hour window. So the useful question is not “which 20x is bigger?” It has two parts: How many dollars of API-equivalent compute does a full week of each plan hold? How many finished tasks does that money buy, given that the two model families spend very differently to reach the same result? The first part can be measured from local logs. The second needs independent benchmarks. We did both. How do you measure a subscription limit in dollars? Both command-line agents keep complete local logs. Claude Code writes every assistant turn to ~/.claude/projects/**/*.jsonl , with a usage block that splits fresh input, output, cache reads, 5-minute cache writes and 1-hour cache writes. Codex writes ~/.codex/sessions/**/*.jsonl with cumulative token counts per session. Each Codex event also carries a rate_limits object: the percentage used and the reset time for both the 5-hour and the weekly window. For every turn, we priced the tokens at that model's API list price: cost = input·p in + output·p out + cache_read·p cr + write 5m ·p w5 + write 1h ·p w1 Turns were de-duplicated on message ID and request ID, because Claude Code logs streaming chunks more than once. Codex reports cumulative totals, so we priced the difference between consecutive events and started a new count whenever a session reset its counter. Reasoning tokens are already inside Codex's output count, so they are not added twice. Model Input $/M Output $/M Cache read $/M Cache write $/M (5m / 1h) Claude Opus 5 5.00 25.00 0.50 6.25 / 10.00 Claude Opus 5.5 4.00 20.00 0.20 5.00 / 8.00 Claude Fable 5 / 5.1 10.00 50.00 1.00 / 0.25 12.50 / 20.00 Claude Sonnet 5 2.00 10.00 0.20 2.50 / 4.00 GPT-6 Sol / GPT-5.6 Sol 2.00 10.00 0.20 — GPT-5.5 5.00 30.00 0.50 — GPT-5.4 2.50 15.00 0.25 — A plan's limit can then be expressed in dollars in two ways. Claude. When a limit binds, Claude Code prints “You've hit your session limit” or “…weekly limit”, followed by the reset time, and that message lands in the log. Weekly windows reset on Friday at 13:00 UTC. Summing API dollars from the start of the window to the logged hit gives the value of the cap at that moment. Codex. Codex logs its gauge on every turn, so no hit is needed. For each weekly window, value of a full window = 100 × (dollars spent in the window ÷ percentage points consumed). We kept only windows where at least 30 points were used, so rounding noise on small moves cannot inflate the result. How much usage is in a Claude Max 20x week? About $1.9k of API-priced usage at today’s limits, $1.74k to $2.2k depending on the model mix. Our user hit the weekly cap twice in August, at $2,085 and $2,379, during a promotion that ran limits at 150%. Each bar is one weekly limit window, priced at Anthropic list rates of the day. “CAP HIT” marks weeks where Claude Code logged “You’ve hit your weekly limit”. The week of 28 Aug went past $2.6k without a hit, so the cap is not a fixed dollar amount. Max 5x never hit its weekly cap. *Partial week. Window (Fri 13:00 UTC) Plan API-equivalent $ Assistant turns Cache read Main models Weekly cap 7 Aug Max 20x $2,087 22,517 1.85B Opus 5 $1,380, Fable 5 $628 Hit at $2,085 14 Aug Max 20x $2,380 24,901 2.26B Opus 5 $2,029, Fable 5 $326 Hit at $2,379 21 Aug Max 20x $2,091 21,259 2.00B Opus 5 $1,668, Fable 5 $272 Not hit 28 Aug Max 20x $2,636 28,550 2.66B Opus 5 $2,234, Fable 5.1 $234 Not hit 4 Sep Max 5x $1,461 20,973 1.87B Opus 5 $1,304, Sonnet 5 $140 Not hit 11 Sep Max 5x $656 6,837 0.66B Opus 5 $578, Fable 5.1 $39 Not hit 18 Sep Max 5x $984 — — — Not hit Our user hit the Max 20x weekly cap twice in August: at $2,085 on 14 August and at $2,379 on 19 August. The week that followed stopped at $2,091 without a hit, and the week of 28 August went to $2,636 without a hit either. The cap is therefore not a fixed dollar amount . Anthropic meters the plan in its own units, and those units map onto list prices differently for each model. A week weighted towards Fable, which costs twice as much as Opus per token, reaches the cap on fewer dollars than a week that is almost all Opus. That fits the two hit weeks: the earlier hit week had almost twice as much Fable spend as the later one ($628 against $326) and hit the cap on $300 less. All four of those weeks fell inside a promotion that raised limits to 150% of normal. Limits have since returned to 125%. Scaling the observed range by 125/150 puts today's Max 20x weekly cap at roughly $1.74k to $2.2k of API-equivalent usage. We use $1.86k, the scaled mean of the two hits, as the central estimate. Across whole months the picture is the same. In August, on Max 20x, our user used $8,676 of API-equivalent Claude usage for a $200 fee, which is 43 times the price. From 1 to 27 September, mostly on Max 5x at $100, the figure was $4,511, or 45 times the price. Finout's survey of Claude Code costs puts heavy users at $600 to $1,500 a month of API value, so this user sits well above typical usage. Treat the numbers here as the ceiling of what a plan can deliver. Why is a Claude Code bill mostly cache, not output? Because the agent re-reads its whole working context on every step. Cache reads were 96% of the tokens our user consumed in August, and output tokens were only $1,038 of a $6,986 Opus bill. 7.0 billion cache-read tokens (96% of volume) made 50% of the $6,986 Opus 5 bill. Output tokens, the figure most cost models are built on, were 0.6% of volume and 15% of cost. Cache writes at the 1-hour rate ($10/M) are the hidden second line. Opus 5, August 2026 Tokens Rate Cost Share of cost Cache reads 7,021M $0.50/M $3,510 50% Cache writes, 1-hour TTL 243.7M $10.00/M $2,437 35% Output 41.5M $25.00/M $1,038 15% Fresh input 0.22M $5.00/M $1 <0.1% Total 7,307M $6,986 100% An agentic coding session re-reads its whole context on every step: system prompt, tool definitions, the open files and the conversation so far. Almost none of that is new input. It comes back as a cache read at a tenth of the input price, but at 7 billion tokens a month that tenth adds up to half the bill. Claude Code also writes its cache with a one-hour lifetime, which costs twice the input price, so a session that keeps extending its context pays that premium again and again. For FinOps this matters directly. A forecast built on output tokens undercounts agentic coding by a factor of about seven. Output was 0.6% of the token volume and 15% of the cost. Any showback or chargeback model for coding agents has to price cache reads and cache writes as separate line items, or it will be wrong by an order of magnitude. It is also why a Claude subscription looks so generous next to the API. Anthropic meters the subscription in its own units. At list prices, cache-heavy traffic is exactly the traffic that turns a $200 fee into $2,000 a week of API-equivalent value. Which limit does Claude Max 5x hit first: session or weekly? The 5-hour session limit. It stopped our user twelve times in September, after a median $37 of work, while the Max 5x weekly cap was never reached. Twelve distinct 5-hour windows hit their limit in September. Median $37, mean $44. The low values are windows the user entered already part-spent; the $93 and $127 windows are what a full, deliberate session holds. On Max 5x, the weekly cap never bound, not even in the $1,461 week. The 5-hour session limit bound twelve times in September. The dollars used in the window before each hit ranged from $5 to $127, with a median of $37 and a mean of $44. The spread is wide because a session can begin while the user is already partway through the previous window. The two largest values, $93 and $127, are the best guide to what one full and deliberate Max 5x session holds. That produces a different pattern of use. Max 20x users run into a weekly limit, while Max 5x users run into a limit every afternoon. If your work comes in long, uninterrupted sessions, the 5-hour limit on Max 5x will cost you more than its weekly cap does. How much Codex usage do ChatGPT Plus and Pro include per week? A full Plus week of Codex was worth a median $67 at API prices since August 2026. Scaled by OpenAI’s published multipliers, that projects to about $335 a week on Pro 5x and $1,340 on Pro 20x. Each dot is one weekly window. Value = 100 × API-dollars spent ÷ percentage points of the weekly gauge consumed; dot size is how much of the window was used (windows under 30pp excluded). The August drop tracks the price list more than the quota: GPT-5.6 Sol lists at $2/$10 against $5/$30 for GPT-5.5. Month Codex API-equivalent $ (Plus, $20) Multiple of fee Median $ per full weekly window Mar 2026 $535 27x $115 (Mar–Jul, GPT-5.4 / 5.5) Apr 2026 $316 16x May 2026 $202 10x Jun 2026 $302 15x Jul 2026 $736 37x Aug 2026 $640 32x $67 (Aug–Sep, GPT-5.6 / GPT-6 Sol) Sep 2026 $255 13x We measured 27 weekly Codex windows on the Plus plan. Pooled across all of them, one full weekly window was worth $103 at API prices, and one full 5-hour window was worth $29.8. Pooling hides a clear break, though. From March to July the median window held $115. Since August it has held $67, and the recent windows are much less scattered: seven in a row fell between $61 and $81. This drop came mostly from prices, not from a smaller quota. In August the default Codex model moved to Sol, which lists at $2 input and $10 output, against $5 and $30 for GPT-5.5. If OpenAI's weekly quota tracks compute, cheaper tokens mean fewer dollars per window. For forecasting, use the recent figure. We take $67 as the value of one Plus week. We have not run Pro 5x or Pro 20x. The Pro figures below are projections, calculated as $67 times OpenAI's published multiplier: $335 a week for Pro 5x and $1,340 a week for Pro 20x. The whole comparison depends on that assumption, and we test it below. Is Claude Max 20x worth it over Max 5x? For most heavy users, no. Max 20x costs twice as much, but its weekly allowance is only about 1.5x to 2x a Max 5x week, not the 4x the labels suggest. The Claude “20x” applies to the 5-hour session. Its weekly cap, which is what binds a heavy user, is not four times the Max 5x weekly cap. Our bound: the Max 20x cap was $2.1k–2.6k while Max 5x delivered $1,461 in a week without hitting its cap. If the Claude tiers scaled by their labels, a Max 20x week would hold four times a Max 5x week. The evidence points to about half that at best. Codeongrass tested both Claude tiers and found the Max 20x weekly allowance to be about 2x Max 5x. In our logs, today's Max 20x cap (about $1.86k at 125%) sits at most 1.5x above the $1,217 that a Max 5x week delivered (the $1,461 promo week, scaled to 125%) without hitting its cap. It is an upper bound because the 5x cap was never reached. The real ratio could be lower still. The practical conclusion is the one that matters most in this study. On Claude, Max 5x is the better buy per dollar , because it gives you half the price and well over half the weekly capacity. The extra $100 for Max 20x mainly buys longer 5-hour sessions. That is worth paying for only if the session limit, not the weekly cap, is what stops you. Is Codex cheaper than Claude Code for the same task? Yes, by 3.3x to 4.2x in two independent tests , because GPT-6 Sol reaches the same result with far fewer tokens. Claude still leads on benchmark quality. API-equivalent dollars measure what the vendor gives up, not what the user gets. A model that needs four times as many tokens to finish the same job turns a larger allowance into the same amount of output. Two independent sources measure that directly. Source Task Claude OpenAI Claude ÷ OpenAI DataCamp Build a playable Tetris clone Opus 5.5: $0.87 GPT-6 Sol: $0.26 3.3x dollars codeongrass Identical plugin feature, same repository Claude Code: 6,232K tokens Codex: 1,499K tokens 4.2x tokens Quality does not make up the gap in either direction. On Terminal-Bench 4.0, Opus 5.5 scores 66.4% and GPT-6 Sol 60.5%. That is a real lead, but a six-point lead does not offset a 3.3x cost difference for routine work. Claude's lead is worth paying for on hard, ambiguous, multi-step problems. It is not worth paying for when the job is clearing a queue of well-specified tickets. Take the DataCamp figure as the unit of work. A Tetris-sized task costs $0.87 on Claude and $0.26 on GPT, and the weekly capacity of each plan becomes a count of tasks: Left: what a full week is worth at API list prices. Right: the same week divided by the cost of one comparable coding task ($0.87 on Opus 5.5, $0.26 on GPT-6 Sol, DataCamp). Claude Max 20x uses the central cap estimate ($1.86k); Max 5x is a floor, because its weekly cap was never reached. Plan Price / month API $ per week Basis Tasks per week Fee per task Claude Max 20x $200 $1,860 Measured cap, scaled to 125% 2,138 $0.022 ChatGPT Pro 20x $200 $1,340 Plus × 20, projected 5,154 $0.009 Claude Max 5x $100 ≥ $1,217 Cap not reached (floor) ≥ 1,399 ≤ $0.017 ChatGPT Pro 5x $100 $335 Plus × 5, projected 1,288 $0.018 ChatGPT Plus $20 $67 Measured 258 $0.018 “Fee per task” is the weekly share of the subscription (price ÷ 4.33) divided by tasks per week. Every row is two orders of magnitude below the API price of the same task, so every plan beats paying per token for anyone who uses it seriously. Does ChatGPT Pro 20x really give 20x the weekly Codex usage? OpenAI has not said so in writing, and it is the one number that could flip this study. Codex keeps its lead at $200 as long as the real weekly multiplier is above about 7x. The Codex Pro rows rest on one assumption: that the Pro 20x weekly window really holds twenty Plus weeks. OpenAI publishes 20x for the 5-hour window. Anthropic's experience, where 20x per session became about 2x per week, is a warning that the two need not match. So instead of assuming, we can ask how large the real weekly multiplier m must be for Codex to win. Codex tasks/week = m × $67 ÷ ($0.87 ÷ r) , where r is how many times more Claude spends per task. Codex Pro 20x delivers more finished tasks than Claude Max 20x once its weekly allowance is at least 6.6–8.4 times Plus. OpenAI publishes 20x for the 5-hour window. If the weekly window scales the same way, Codex wins by about 2.4x; if it scales like Claude's did, Claude wins. Claude cost per task, relative (r) Codex Pro 20x tasks/week at m = 20 Break-even m vs Claude Max 20x Verdict if m ≥ break-even 3.3 (DataCamp) 5,154 8.4x Codex wins 4.2 (codeongrass) 6,472 6.6x Codex wins 2.0 (a hard task where Claude is efficient) 3,080 13.9x Codex wins only near the full 20x If OpenAI's weekly allowance scales even a third as far as its label, ChatGPT Pro 20x delivers more finished work than Claude Max 20x. If it scales the way Anthropic's did, at 2x, Claude wins comfortably. You can check this in your first week on Pro. Watch the weekly gauge that Codex already shows you: if a full Plus-sized day of work moves it by about 1 point, you are getting the full 20x. Is a $200 AI coding subscription cheaper than the API? Every one of these plans beats paying per token, and by a wide margin. A $200 subscription pays for itself at $46 of API-equivalent usage a week , and a $100 plan at $23. That is roughly two hours of steady Opus agent work, or one heavy afternoon. Our user went past that line on the first Monday of every week. Plan Break-even (API $/week) Our user's typical week Value multiple Claude Max 20x ($200) $46 $2,087–2,636 45–57x Claude Max 5x ($100) $23 $656–1,461 28–63x ChatGPT Plus ($20) $4.62 $61–81 per full window 13–18x Claude Max or ChatGPT Pro: which should you buy at $100 or $200? If you… Buy Why Code with agents most days but rarely all day Claude Max 5x, $100 The best capacity per dollar we measured. Its weekly cap never bound. Work through a steady queue of well-specified tickets ChatGPT Pro 20x, $200 The lowest fee per finished task, at about 2.4x Claude's throughput if 20x holds weekly. Run long unattended agent sessions and keep hitting the 5-hour limit Claude Max 20x, $200 You are paying for the session multiplier, which is the part that really is 4x. Handle hard, ambiguous, cross-cutting refactors Claude , 5x or 20x The benchmark lead shows up where tokens-per-task matters least. Are unsure, or budget-capped Claude Max 5x + ChatGPT Plus, $120 Two model families, two independent limit pools, and about $1.3k of API value a week between them. Need it for a product your customers use Neither. Use the API. Subscription usage cannot be attributed per request, and consumer terms don't cover resale. One availability note: buildthisnow reports that new sign-ups to ChatGPT's $200 Pro tier have been paused since 10 September 2026. Check before planning a rollout around it. Is it better to split $200 across Claude Max 5x and ChatGPT Pro 5x? It beats Claude Max 20x, but not ChatGPT Pro 20x. Several guides now recommend buying the two $100 plans instead of one $200 plan. On our numbers that split holds at least 2,687 tasks a week, against 2,138 on Claude Max 20x and 5,154 on ChatGPT Pro 20x. $200 a month spent as API $ per week Tasks per week Limit pools Claude Max 20x $1,860 2,138 One Claude Max 5x + ChatGPT Pro 5x ≥ $1,552 ≥ 2,687 Two, independent ChatGPT Pro 20x $1,340 5,154 One The split wins on things the table does not show. You get both model families, so the hard refactor goes to Opus and the ticket queue goes to Sol. When one vendor’s limit runs out mid-afternoon, the other still has its own. And if Pro 20x’s weekly window turns out to scale far less than 20x, the split is the safer bet, since it doesn’t depend on that multiplier nearly as much. For FinOps teams Book seats as tooling, not COGS. A flat seat is a fixed cost with an enormous implied discount. Once seat usage leaks into anything customer-facing, you lose unit economics, because none of it can be tagged to a request, a tenant or a feature. Measure the ratio, not the label. Both logs sit on the developer's laptop. A weekly script that turns them into API-equivalent dollars per seat is the cheapest utilisation report you will ever build, and it shows who should move down a tier. Right-size downwards first. On Claude, the gap between 5x and 20x per week is 1.5–2x for 2x the price. Move a seat up only when it logs repeated weekly-limit hits. Keep two vendors. Limits change without notice, as the end of the 150% promo showed. A $20 second seat is the cheapest insurance against a week of blocked developers. Limitations One subject. The logs come from one heavy user whose work is mostly agentic coding. Your cache share, model mix and session length will differ, and they are what set your ratio. Codex Pro is projected. We measured Plus windows directly. Pro 5x and Pro 20x are multiples of those windows, not observations. The Claude cap moves with model mix. The same metered week reads as more dollars on Opus 5 than on Opus 5.5, which has a cheaper price list. We priced each turn at the model that actually ran it. “Tasks” is one yardstick. A Tetris clone is a reasonable proxy for a mid-sized feature. It is not your codebase. API-equivalent is not cash. It is what the same tokens would have cost on the metered API. Nobody would have run this much traffic at list price, so it overstates the real saving. Sources Anthropic: What is the Max plan? Anthropic API pricing OpenAI API pricing OpenAI: Codex plans and usage limits codeongrass: Claude Code vs Codex for heavy users buildthisnow: Codex vs Claude Code usage limits DataCamp: GPT-6 Sol vs Claude Opus 5.5 Finout: Claude Code pricing 2026 OpenRouter model price list Related Claude Max 20x vs 5x: the weekly limit, measured How much Codex ChatGPT Pro includes How many tokens Claude Pro and Max give you SaaS AI credits and metering Committed spend discounts Proving AI ROI Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # The Token Count Is Lying: Claude Max vs Qwen Audit · FinOps LLM URL: https://finopsllm.com/research/claude-max-vs-qwen-token-pro-audit The Token Count Is Lying: A Real-World Cost Audit of Claude Max 20x and Alibaba's Qwen3.8 Token Plan A real-usage case study of Opus 5, Qwen3.8-Max, prompt caching, model verbosity and the problem with comparing AI subscriptions by token count $200 vs $70 Monthly sub gap 91.9% Opus activity share 5.30× Dashboard metric drift 0.35 Qwen task break-even Central Thesis: Comparing Claude Max with Alibaba Token Pro using advertised token prices produces the wrong answer. Claude Max is an opaque, heavily subsidized capacity subscription, while Alibaba Token Pro is a credit-metered subscription whose burn rate varies by model and workload. Because Claude and Qwen tokenize, reason, invoke tools, and retry differently, the only meaningful economic unit is the cost per accepted engineering task — not the cost per token. 1. Executive summary Auditing cloud AI infrastructure by comparing published token rates produces deceptive recommendations. Our analysis of real account telemetry, vendor disclosures, and community benchmarks reveals: Alibaba Token Pro costs $70/month and exposes explicit rolling limits of 12,000 credits per five hours and 40,000 credits per seven days. Qwen3.8-Max-Preview received a temporary credit reduction advertised as consumption as low as 10% of the standard rate during its promotional preview phase. Claude Max 20x costs $200/month but does not expose a contractual token or compute allocation. Real account telemetry: User telemetry shows Opus 5 represented 91.9% of total model activity while apparently using far fewer displayed tokens per activity unit than Fable 5 and Haiku 4.5. Metric inconsistency: Account dashboard views report incompatible token totals (110.8M vs 20.9M, a 5.30× ratio), proving dashboard token counts cannot safely be converted into competitor usage. Task-productivity break-even: Alibaba needs to provide only 35% of Claude's accepted-task productivity to match Max 20x on subscription cost — provided the Qwen workload stays within credit limits. Developer-time break-even: Opus 5 easily justifies its $130/month premium if it saves just 2.6 hours of developer time per month at $50/hour (or 1.3 hours at $100/hour). 2. The plans are not billing the same thing Alibaba Token Plan Personal Pro The current Personal Pro plan costs $70/month and provides explicit quota caps: Limit Pro Allowance Relevant Flagship Model Rolling five hours 12,000 credits qwen3.8-max-preview Rolling seven days 40,000 credits qwen3.8-max-preview Alibaba advertises that the Qwen3.8 preview consumes as little as 10% of its standard credit rate, alongside an advertised night-rate discount between 22:00 and 08:00 UTC+8. Source . Because the wording specifies "as low as," financial modeling should not assume a universal fixed multiplier without billing records. The plan is strictly restricted to interactive coding and agent tools; custom backends and non-interactive batch automation are prohibited. Alibaba Coding Plan The $50 Coding Plan is a completely distinct product from the Token Plan: Limit Allowance Rolling five hours 6,000 model calls Weekly 45,000 model calls Monthly 90,000 model calls The Coding Plan does not include Qwen3.8-Max; its allowlist is restricted to models like Qwen3.7-Plus. Alibaba explicitly warns that one visible top-level query triggers 5–10 underlying calls for simple tasks and 10–30+ calls for complex workflows. Source . Mixing up the Coding Plan and Token Plan distorts cost comparisons. Claude Max 20x Claude Max 20x provides 20 times the Pro plan's per-session usage, but Anthropic does not publish underlying token, compute, or API-dollar quotas. Source . Both Claude.ai web sessions and Claude Code CLI executions share the exact same account allowance. Plan Definition: Claude Max 20x is a fixed-price but dynamically metered compute subscription whose internal weighting remains undisclosed. 3. The real-user case study: Account telemetry audit Telemetry from a heavy developer account running Claude Max 20x provides empirical insight into real-world agentic usage patterns. Seven-day account overview Metric Value Sessions 32 Messages 48,513 Overview total tokens 20.9M Active days 6 Favorite model Opus 5 Model-level breakdown Model Displayed Activity Share Input Tokens Output Tokens Combined Displayed Tokens Opus 5 91.9% 0.436M 41.5M 41.936M Fable 5 6.4% 14.8M 38.3M 53.100M Haiku 4.5 1.7% 2.8M 13.0M 15.800M Total 100% 18.036M 92.8M 110.836M Comparing the two dashboard views reveals a massive discrepancy: 110.836M (Models Screen) ÷ 20.9M (Overview Screen) = 5.30× Discrepancy This 5.30× ratio is not a rounding error. The two views employ fundamentally different aggregation methods, cache accounting, or token normalizations. This proves why raw dashboard token counters cannot safely be converted into competitor API or subscription equivalents. Furthermore, Opus 5 accounted for 91.9% of active workload activity while recording fewer total displayed tokens than Fable 5. While this demonstrates high activity efficiency for Opus 5 in interactive sessions, confounders include sub-agent delegation, prompt cache hit accounting, hidden reasoning token suppression, and background context compaction. 4. Why equal-token comparisons fail Two AI models performing the exact same ticket routinely generate radically different token volumes. Token-for-token equivalency fails because of eight distinct multiplier variables: Tokenizer density (Sonnet 5 / Opus 5 tokenize text ~30% denser than legacy tokenizers) Reasoning string length & thinking mode overhead Number of interactive agent turns per task Tool call invocation frequency Repository file-reading strategy & grep granularity Retry rates on syntax or logic errors Context-compaction & pruning strategies Output verbosity and code-generation structure Total Workload Cost = Tokenization × Turn Amplification × Tool Amplification × Reasoning Amplification × Retry Amplification A model charging 75% less per output token is materially more expensive if it requires 5× as many weighted tokens and 3 retry cycles to yield passing unit tests. Shadow API pricing illustrates the cost floor: Qwen3.8-Max via Singapore API costs $2/M input, $0.17/M explicit cache read, and $6/M output, compared to Claude Opus 5 API at $5/M input and $25/M output. Source . However, API rates do not dictate subscription credit deduction mechanics. 5. What existing comparisons actually show Community Max capacity analysis Independent tracking of 80 autonomous coding tasks estimated that a full Max 20x weekly allowance provided approximately $1,100 in API-equivalent compute value , with a median task consuming $4–$5 of API value. Source . Notably, Max 20x provided roughly 2× the weekly allowance of Max 5x — not 4× — despite its 4× larger 5-hour burst window. Same-prompt Qwen vs Opus benchmark A single-prompt design benchmark reported: Model Output Quality Score API Cost Qwen 3.8-Max 9.0 / 10 $0.0248 Claude Opus 5 8.5 / 10 $0.2530 Source . While Qwen demonstrated extreme cost efficiency on isolated generation tasks, single-prompt benchmarks do not reflect multi-file refactoring or tool-use loops. Same-task qualitative refactoring test Developer reports on complex refactoring tasks noted that Qwen3.8 required 2–3 iterative correction rounds to pass suite tests, whereas Claude Opus 5 completed the refactor on the first attempt. Source . This retry amplification directly eats into nominal per-token price advantages. Vendor benchmarks Anthropic reports that Claude Opus 5 completes agentic workflows with significantly fewer turns, fewer tool calls, and reduced reasoning token overhead compared to prior model generations. Source . 6. The correct break-even equation To evaluate subscription economics objectively, compare monthly cost against accepted task output: C_Claude = $200/mo | C_Qwen = $70/mo Alibaba is cheaper per accepted task when: ( $70 / A_Q ) < ( $200 / A_C ) Required Productivity Ratio: ( A_Q / A_C ) > 0.35 Core Result: Provided credit quotas are not exhausted, Qwen3.8 needs to deliver only 35% of Opus 5's accepted-task volume to be more cost-effective. Conversely, Opus 5 must produce more than 2.86× as many completed tasks to beat Alibaba purely on subscription fee math. Developer-time break-even ($130 monthly gap) Developer Hourly Rate Monthly Time Opus Must Save to Break Even $25 / hour 5.20 hours / month $50 / hour 2.60 hours / month $75 / hour 1.73 hours / month $100 / hour 1.30 hours / month For engineering leads, human-time savings dominate raw credit math. Preventing one production bug or saving 2.6 hours of debugging per month fully offsets the $130 subscription delta. 7. Final conclusion Alibaba Token Pro offers superior disclosed capacity and raw price-to-quota ratios ($70/mo with explicit 40,000 seven-day credit limits). Promotional preview multipliers further enhance its baseline economy. However, Claude Max 20x provides heavy developers with a massive compute subsidy (~$1,100 API equivalent value). User account telemetry indicates Opus 5 executes agentic tasks with high efficiency within Anthropic's internal metering system. Takeaway: Token counts lie. The decision between Claude Max 20x and Alibaba Token Pro cannot be made on token price charts. It depends on first-attempt accuracy, retry overhead, developer time valuation, and weekly quota limits. 8. Controlled benchmark methodology & protocol To establish an empirical field study of AI coding economics, we propose the following reproducible N-of-1 benchmark protocol: Select 15 real-world repository pull requests/tickets of varying complexity (bug fixes, refactors, new endpoints). Initialize both agent harnesses from identical Git commit HEAD states. Enforce identical file-tree visibility, test suite commands, and tool permissions. Run Opus 5 (via Claude Code Max 20x) and Qwen 3.8-Max (via Model Studio Token Pro). Record task outcome, total turn count, retry iterations, human intervention seconds, changed lines, Alibaba credits burned, and Claude quota percent consumed. Execute each benchmark ticket 3× to average non-deterministic agent trajectories. Quality-Adjusted Task Cost = ( Allocated Subscription Cost + Human Correction Cost ) ÷ Accepted Tasks Evaluating AI coding subscriptions under this quality-adjusted framework converts marketing claims into actionable enterprise FinOps decision-making. Related Cloud Infrastructure Cost Audit: Alibaba vs Claude Max — unit math, quotas, and verbosity tax breakdown. AI Coding Economics 2026 — 32M daily token workload benchmark across DeepSeek, MiMo, GLM, and Claude. AI Coding Plan Comparison — sortable matrix of plans, limits, and model scores. Prompt Caching Economics — explicit vs implicit prompt caching ROI. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ Why is comparing AI coding subscriptions by raw token count misleading? Models tokenize text differently, generate varying reasoning lengths, take different numbers of turns, invoke tools at different frequencies, and exhibit varying retry rates. 20 million Claude tokens cannot be treated as equivalent to 20 million Qwen tokens. What is the key difference between Alibaba Token Plan Pro and Alibaba Coding Plan? Alibaba Token Plan Pro ($70/mo) is a credit-metered plan with rolling 5-hour (12,000 credits) and 7-day (40,000 credits) caps. Alibaba Coding Plan ($50/mo) is a model-call metered plan (6,000 calls/5h, 90,000 calls/mo) for a specific allowlist of models like Qwen 3.7-Plus. What is the break-even task ratio between Qwen 3.8-Max and Claude Opus 5 on subscription cost? At $70/mo for Token Pro vs $200/mo for Max 20x, Qwen 3.8 needs to deliver only 35% of Opus 5's accepted-task throughput to be cheaper per completed task. Conversely, Opus must deliver 2.86× more accepted work to justify its higher subscription fee purely on model output. How does developer time factor into the Claude Max 20x vs Alibaba decision? The $130/month price gap is equivalent to just 2.6 hours of developer time at a $50/hour valuation (or 1.3 hours at $100/hour). If Opus 5 prevents one regression or completes a multi-file refactor on the first attempt without retries, it easily justifies the subscription cost. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Claude Opus 5.5 Pricing: $4/$20, $0.20 Cache Read · FinOps LLM URL: https://finopsllm.com/research/claude-opus-5-5-cost-model Claude Opus 5.5 pricing and cost model Updated September 22, 2026 · first published September 22, 2026 Anthropic released Claude Opus 5.5 ( claude-opus-5-5 ) on September 22, 2026. The headline price is $4 per million input tokens and $20 per million output tokens, down from $5 and $25 on Opus 5. That is a 20% cut. For most production workloads the actual cut is larger, because the rate that moved most is the one the headline leaves out. Opus 5.5 pricing: the rates that matter Token type Opus 5.5 Opus 5 Fable 5.1 Input (uncached) $4.00 / MTok $5.00 / MTok $10.00 / MTok Output $20.00 / MTok $25.00 / MTok $50.00 / MTok Cache write (5-minute) $5.00 / MTok $6.25 / MTok $12.50 / MTok Cache read $0.20 / MTok $0.50 / MTok $0.25 / MTok Fast mode (input / output) $8 / $40 — — Every row is 20% lower except the cache read, which is 60% lower. At $0.20 it is now cheaper than Fable 5.1's $0.25. That reverses the one row where Fable used to win. In our Fable 5.1 cost model , a heavily cached workload could come out cheaper on Fable than on Opus 5. Against Opus 5.5 that no longer happens. Fable costs more on every token type. Why a typical task costs about 40% less Anthropic's claim is a 40% drop in cost for a typical job, not 20%. The extra comes from token efficiency. Anthropic says Opus 5.5 reaches the same result with about 20% fewer input and output tokens and writes about 40% less verbose output. A lower rate times fewer tokens compounds: 0.8 × 0.8 = 0.64, which is roughly 36–40% off depending on the mix. Here is one agent step: 200,000 input tokens, 90% served from cache, and 20,000 output tokens. Line Opus 5 Opus 5.5 (same tokens) Fable 5.1 20K uncached input $0.100 $0.080 $0.200 180K cached input $0.090 $0.036 $0.045 20K output $0.500 $0.400 $1.000 Total $0.690 $0.516 $1.245 On identical tokens, Opus 5.5 is 25% cheaper than Opus 5, not 20%, because of the cache discount. If the 20% token reduction holds for your workload, the step drops to about $0.41, which is 40% below Opus 5 and a third of the Fable cost. Output is still about 80% of the bill in this example. That is where the verbosity reduction pays off. Cost per task against GPT-6 Sol, GPT-6 Astra and Fable 5.1 List prices per million tokens, and the same agent step as above (200K input, 90% cached, 20K output) priced on each model. Model Input $/MTok Output $/MTok Cache read $/MTok Same agent step GPT-6 Sol $2.00 $10.00 $0.20 $0.276 Claude Opus 5.5 $4.00 $20.00 $0.20 $0.516 Claude Opus 5 $5.00 $25.00 $0.50 $0.690 Claude Fable 5.1 $10.00 $50.00 $0.25 $1.245 GPT-6 Astra $10.00 $50.00 $1.00 $1.380 Measured cost per task on the Artificial Analysis Intelligence Index v4.3.2, read 22 September 2026, sorted by score. GPT-6 Sol is the cheapest way to any score up to 47.5. Above that, Opus 5.5 is the cheapest at every level: Opus 5.5 high scores 53.6 for $1.82, while GPT-6 Astra max scores 52.7 for $3.26 and Fable 5.1 max scores 53.4 for $7.63. Model Intelligence Index Cost per task Output tokens per task GPT-6 Sol · medium 39.8 $0.25 6,500 GPT-6 Sol · xhigh 44.1 $0.53 16,000 GPT-6 Astra · low 45.8 $0.82 4,400 GPT-6 Sol · max 47.5 $1.06 31,200 Claude Opus 5 · high 48.1 $3.61 46,200 Claude Opus 5 · max 50.8 $5.86 72,500 Claude Opus 5.5 · medium 51.2 $1.34 25,700 Claude Fable 5.1 · high 51.2 $3.91 38,100 GPT-6 Astra · max 52.7 $3.26 27,200 Claude Fable 5.1 · max 53.4 $7.63 78,100 Claude Opus 5.5 · high 53.6 $1.82 35,600 Claude Opus 5.5 · max 57.6 $5.98 119,200 Every GPT-6 Astra setting above low, every Opus 5 setting and every Fable 5.1 setting costs more than a Sol or Opus 5.5 setting that scores the same or higher. Cost per task depends on the benchmark's task mix. Replay your own traffic before switching models. Is it good enough to replace Fable? Anthropic positions Opus 5.5 as matching Fable 5.1 on most tasks. The published numbers support that for coding and agentic work: Terminal-Bench 4.0: 66.4%, against 52.3% for Opus 5 and 55.8% for Fable 5.1. FrontierCode v1.1: 54.4%, against 48.0% for Opus 5 and 50.3% for Fable 5.1. CursorBench 4.0: 57.8%, against 46.6% for Opus 5. GDPval-AA v2.1: 1846 Elo, against 1708 for Opus 5. Artificial Analysis ranked it first on its Intelligence Index on launch day. Anthropic also says that at default (medium) effort it beats GPT-6 Astra at max effort on knowledge work for about a fifth of the cost per task. That is a vendor comparison, so treat it as a hypothesis to test. The cost math above is the part you can verify yourself. Fast mode costs 2× Fast mode costs $8 in and $40 out, exactly double the standard rate, for up to 2.5× the speed. The standard model is also about 30% faster than Opus 5. Use fast mode for latency-bound interactive paths where a user is waiting. Keep it off batch jobs, background agents and evals. When fast mode is enabled by default, the unit cost doubles and the dashboard shows nothing unusual until the invoice arrives. What to do this week Pin the model ID. Point production at claude-opus-5-5 explicitly and record the ID on every request, so cost per request can be split by model after the migration. Re-baseline on your own traffic. Replay a sample of real requests on both models and compare tokens per completed task, not per call. The 20% token-efficiency claim is the part most likely to vary by workload. Re-check effort settings. If a workload moved to Fable or to max effort for quality, test Opus 5.5 at medium first. That is the setting Anthropic benchmarks against. Re-run the Fable routing decision. Any route that sent cache-heavy traffic to Fable to get the cheaper cache read should be re-evaluated. That cost advantage is gone. Watch cache hit ratio. At $0.20 against $4.00, a cache miss now costs 20× a hit. A prompt-template change that breaks the prefix costs more than it did on Opus 5. Anthropic says Sonnet 5.5 and Haiku 5.5 will follow in the coming weeks. Keep the replay harness from step 2 so each release can be re-baselined in an afternoon. Related Claude Fable 5.1 cost model Prompt caching economics Opus 5.5 effort levels are the real price Opus 5.5 fast mode economics Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # How Many Tokens Do You Get With Claude Pro and Max? · FinOps LLM URL: https://finopsllm.com/research/claude-pro-max-tokens-limit How many tokens do you get with Claude Pro and Max? We counted them Updated September 27, 2026 · first published September 27, 2026 Quick answer: Anthropic doesn’t publish a token limit for Claude Pro or Max. Measured from real Claude Code logs, a Claude Max 20x week holds about 2 billion tokens and a Max 5x week at least 1.3 billion.... Anthropic doesn’t publish a token limit for Claude Pro or Max. Measured from real Claude Code logs, a Claude Max 20x week holds about 2 billion tokens and a Max 5x week at least 1.3 billion. That sounds enormous, but 96% of those tokens are cache reads, the agent re-reading its own context. Only about 11 million are output tokens, the text Claude actually writes. This page answers one question from our 60-day study of Claude Max against ChatGPT Pro and Codex . Every figure is priced at the Anthropic API list price in force on the day of each request, then converted back to tokens using the August 2026 Opus mix: about 1.05 million tokens per dollar. Does Anthropic publish a token limit for Claude Pro or Max? No. Anthropic describes Max as 5x or 20x Pro’s usage per session and says the session limit resets every five hours, with a separate weekly limit that resets at a fixed time assigned to your account. It meters both in its own units, which weigh pricier models more heavily, so no single token number would be true for every model anyway. How many tokens do you get per week on Claude Max? About 1.9 billion on Max 20x and at least 1.3 billion on Max 5x, in a Claude Code workload. Plan Price / month API $ per week All tokens per week Output tokens per week Basis Claude Max 20x $200 ~$1,860 ~1.9B ~11M Measured (weekly cap hit twice) Claude Max 5x $100 ≥ $1,217 ≥ 1.3B ≥ 7M Lower bound (cap never hit) Claude Pro $20 Not measured Weekly cap not published Max 20x’s range runs from about 1.8 to 2.3 billion tokens, depending on how much of the week goes to pricier models. The weekly-limit breakdown explains why the $200 plan’s week is only 1.5 to 2 times the $100 plan’s. How many tokens do you get per 5-hour session? About 39 million tokens on Max 5x, or roughly $37 of API usage. That is the median at which the 5-hour limit stopped our user on Max 5x, twelve times in September 2026. Scaled by Anthropic’s own multipliers, a Pro session projects to about 8 million tokens and a Max 20x session to about 155 million. Those two are projections, not measurements. Why are almost all of those tokens cache reads? Because a coding agent re-sends its whole working context on every step. Anthropic bills that repeat as a cache read at a tenth of the input price, and across 7.3 billion tokens that tenth still came to half the bill. 7.0 billion cache-read tokens (96% of volume) made 50% of the $6,986 Opus 5 bill. Output tokens, the figure most cost models are built on, were 0.6% of volume and 15% of cost. Cache writes at the 1-hour rate ($10/M) are the hidden second line. So “how many tokens do I get?” depends on how you use Claude. A chat user who sends short messages with no long context gets far fewer total tokens from the same limit, but a much larger share of them are output. How do you convert Claude tokens to dollars? Multiply each token type by its own rate. On Opus 5 in August 2026, those rates were $0.50 per million for cache reads, $10 for 1-hour cache writes, $25 for output and $5 for fresh input. Our user’s month came out as follows. Opus 5, August 2026 Tokens Cost Cache reads 7,021M $3,510 Cache writes, 1-hour 243.7M $2,437 Output 41.5M $1,038 Fresh input 0.22M $1 Total 7,307M $6,986 Claude Code writes every request, with its token counts, to the JSONL files under ~/.claude/projects , so you can run the same sum on your own usage. To check and cut it from inside Claude Code, see how to reduce Claude Code token usage . When does the Claude token limit reset? Every five hours for the session limit, and once a week at a fixed time for the weekly limit. The weekly reset time is set per account, not the same day for everyone. ChatGPT’s Codex works differently: its weekly window starts from your first request, as our Codex limits breakdown explains. Sources Anthropic: What is the Max plan? Anthropic API pricing Related How to check and reduce Claude Code token usage Claude Max vs ChatGPT Pro: the full 60-day study Claude Max 20x vs 5x: the weekly limit, measured How much Codex ChatGPT Pro includes Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Claude Sonnet 5.5 launch: where it fits in model routing · FinOps LLM URL: https://finopsllm.com/research/claude-sonnet-5-5-launch-and-model-routing Claude Sonnet 5.5: the cost-aware model routing guide Updated September 28, 2026 · first published September 28, 2026 Claude Sonnet 5.5 launched on September 28, 2026 at Sonnet 5's API rates: $2 per million input tokens and $10 per million output tokens. Anthropic positions it for well-scoped everyday work, bug fixes, coding, and polished documents, while Opus 5.5 is aimed at more complex work requiring careful judgment. For teams, the useful question is not which model wins a benchmark; it is which one meets each task's quality and latency target at the lowest cost per accepted result. Anthropic says Sonnet 5.5 is more than 30% faster than Sonnet 5 and can cost up to 30% less per task. Those are launch claims. Use them to choose what to evaluate, not as automatic budget reductions. What Anthropic announced Sonnet 5.5 retains the Sonnet 5 API list prices: $2/MTok input, $10/MTok output, $2.50/MTok for 5-minute cache writes, $4/MTok for 1-hour writes, and $0.20/MTok for cache reads. Anthropic reports output generation more than 30% faster than Sonnet 5 and up to 30% lower cost per task for most work due to token efficiency. The company describes Sonnet as strongest at well-scoped everyday tasks; Opus is designed for complex tasks that require careful judgment. Anthropic says Haiku 5.5 is expected in the coming weeks. It was not part of today's launch. See Anthropic's launch announcement for the complete benchmark descriptions and caveats. A routing policy to test Workload Starting candidate What to measure Routine coding changes, bug fixes, document edits Sonnet 5.5 Accepted change rate, retries, output tokens, elapsed time Ambiguous, long-horizon work with high judgment requirements Compare Sonnet 5.5 with Opus 5.5 Quality at each effort setting, escalation frequency, end-to-end cost High-volume simple classification or extraction Compare Sonnet with lower-cost models already in your stack Quality threshold, cost per valid record, exception handling Latency-sensitive interactive work Test Sonnet 5.5 at the effort setting that meets the quality bar Tail latency, completion rate, and cost per completed task This is a test matrix, not a claim that one model is always the right choice for a workload category. Prompt shape, context length, tool environment, and evaluation criteria can change the result. Why list-price comparison is incomplete Sonnet 5.5's per-token price did not fall at launch. The potential saving is in how many tokens and agent steps it needs to complete a task. A model that generates a shorter answer but triggers more tool calls may cost more overall; a model that finishes faster but uses the same tokens may improve responsiveness without changing the token bill. For an agent, calculate a task's total as input tokens × input rate + output tokens × output rate + cache writes/reads + any separately billed tools or infrastructure. Compare the total only after confirming the task passes the same acceptance checks. Measure the migration before changing your budget Choose a few hundred representative tasks, including failures and edge cases. Run Sonnet 5 and 5.5 with the same tools, prompts, context limits, and effort settings where possible. Record token charges, retries, tool calls, time to completion, and human acceptance. Compare cost per accepted task and report results by task family, not only as a global average. Canary the workloads that meet your gates. Keep a route back to the previous model while monitoring quality and spend. Start forecasts with zero assumed savings. Replace that assumption with measured deltas as the evaluation produces evidence. For API rates and cache pricing, use the Anthropic pricing documentation . FAQ Is Sonnet 5.5 cheaper than Sonnet 5? Its listed per-token rates are the same. Anthropic says it can cost up to 30% less per task because it uses fewer tokens, but results depend on workload. Does Sonnet 5.5 replace Opus 5.5? No. Anthropic presents the models for different task profiles. Evaluate both where task difficulty, failure cost, or quality requirements justify the comparison. Is it available on AWS? AWS announced availability on September 28 through Amazon Bedrock and Claude Platform on AWS. Check each service's current region, model access, and pricing details before planning deployment. Sources and related reading Anthropic: Introducing Claude Sonnet 5.5 AWS: Claude Sonnet 5.5 now available on AWS Sonnet 5.5 pricing and task-cost model Claude Opus 5.5 cost model Related Sonnet 5.5 pricing and task-cost model Claude Opus 5.5 cost model Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Codex Auto-Compact on GPT-6 Sol: The Real Defaults · FinOps LLM URL: https://finopsllm.com/research/codex-auto-compact-gpt-6-sol Codex auto-compact on GPT-6 Sol: the defaults in the source code, and what raising them costs Updated September 27, 2026 · first published September 27, 2026 Quick answer: Codex auto-compacts a GPT-6 Sol session at 244,800 tokens: 90% of the 272,000-token window it assigns the model. Raising model_auto_compact_token_limit above that number does nothing unless you also... Codex auto-compacts a GPT-6 Sol session at 244,800 tokens: 90% of the 272,000-token window it assigns the model. Raising model_auto_compact_token_limit above that number does nothing unless you also raise model_context_window . If you raise the window past 272K, every turn that crosses the line is billed at long-context rates. We read the numbers from the Codex 0.157.1 source code and from the model catalog Codex downloads. What context window does Codex give GPT-6 Sol? 272,000 tokens, even though the API accepts up to 922,000. Codex downloads a model catalog and caches it in ~/.codex/models_cache.json . The entry for gpt-6-sol lists a context_window of 272,000 and a max_context_window of 872,000. It also sets effective_context_window_percent to 95 and leaves auto_compact_token_limit empty. GPT-6 Astra and GPT-6 Luna have the same values. 272K is not an arbitrary number. It is exactly where GPT-6 long-context pricing starts. Value Tokens Where it comes from Context window 272,000 context_window in the model catalog Usable window 258,400 95% of the window ( effective_context_window_percent ) Auto-compact threshold 244,800 90% of the window, computed in code Largest window allowed 872,000 max_context_window in the model catalog API input limit 922,000 OpenAI model spec (1.05M total with output) How does Codex decide when to compact? It takes the smaller of your configured limit and 90% of the context window. In codex-rs/protocol/src/openai_models.rs , auto_compact_token_limit() computes context_window * 9 / 10 . It returns that value or your configured limit, whichever is lower. The catalog ships no limit for GPT-6 Sol, so by default the result is 272,000 × 0.9 = 244,800. So the setting can only move compaction earlier. Put model_auto_compact_token_limit = 300000 in config.toml with the default window, and Codex still compacts at 244,800 without any warning. To compact later you also have to raise model_context_window , and that moves the ceiling too: at the 872,000 maximum, the default threshold becomes 784,800. A second setting, model_auto_compact_token_limit_scope , defaults to total , which counts the whole active context. The alternative, body_after_prefix , counts only what the conversation adds after the context it carried in from before. What does raising the Codex window past 272K cost? Per turn, a lot more than the extra tokens. Once a GPT-6 Sol request has more than 272K input tokens, the whole request is billed at long-context rates. Input and cached input cost twice as much, and output costs 1.5 times as much. In a long agent session almost every turn sends the whole history again, so most of that input is cached prefix. Context per turn Cached input rate Cached context cost per turn Uncached cost per turn 240K (compacts at the default) $0.20 / 1M $0.048 $0.48 270K $0.20 / 1M $0.054 $0.54 300K (window raised) $0.40 / 1M $0.12 $1.20 400K (window raised) $0.40 / 1M $0.16 $1.60 Going from 270K to 300K adds 11% more tokens and multiplies the cost of each turn by 2.2. On a ChatGPT plan you don’t see a bill, but the same tokens count against your 5-hour and weekly Codex limits , so a bigger window uses them up faster. The context-window-paid-twice write-up explains why this repeat charge dominates long sessions. Is GPT-6 Sol still accurate near 244K tokens? Nobody has measured that yet. The only independent long-context score for GPT-6 Sol is Artificial Analysis AA-LCR: 84%, the same as GPT-5.6 Sol. The documents in that test average about 100K tokens. The MRCR figures you see quoted for “Sol” at 256K–512K belong to GPT-5.6 Sol. Our GPT-6 Sol long-context benchmark roundup lists what has and hasn’t been published as of 27 September 2026. What should you set? For most teams, nothing. The default is already the cost-safe choice. Compacting at 244,800 keeps every request under the 272K price line, with room for output. Three situations call for a change: You want compaction earlier , for example because long threads start dropping earlier instructions. Set model_auto_compact_token_limit lower, say 200000. Values below 244,800 do take effect. You want the current defaults written down so a future catalog update can’t change them silently. Set model_context_window = 272000 and a limit at or below 244,800. You need more than 258K of live context in one session. Raise model_context_window and accept long-context pricing on every turn above 272K. Alert on it, because nothing in the Codex interface flags the price change. # ~/.codex/config.toml model = "gpt-6-sol" model_context_window = 272000 # pin the default window, below the 272K price line model_auto_compact_token_limit = 240000 # anything above 244,800 is ignored at this window Sources Codex 0.157.1 source: auto_compact_token_limit() and usable_context_window() Codex 0.157.1 source: config overrides applied to model info Codex 0.157.1 source: compaction scope and the hard context cap OpenAI API pricing Artificial Analysis: GPT-6 Sol vs GPT-5.6 Sol Related GPT-6 Sol long-context benchmarks: what has actually been measured GPT-6 pricing and the 272K long-context price jump You pay for the context window twice How much Codex does ChatGPT Pro include? Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Codex Usage Limit Resets: How They Work + Log · FinOps LLM URL: https://finopsllm.com/research/codex-reset-history Codex usage limit resets: how they work, banked resets and a dated log Updated September 27, 2026 · first published September 27, 2026 Quick answer: Codex usage limits reset on two clocks: a 5-hour window and a weekly window that starts with your first request after the last reset. On top of that, OpenAI regularly resets everyone's limits early,... Codex usage limits reset on two clocks: a 5-hour window and a weekly window that starts with your first request after the last reset. On top of that, OpenAI regularly resets everyone's limits early, either immediately or as a “banked” reset you redeem later. Third-party trackers count 55 of these one-off resets since September 2025, about one every 6.9 days. The dated log below covers August and September 2026. If you want to know what a Codex week is worth in dollars on Plus, Pro 5x and Pro 20x, that is on our Codex usage limits page . This page is about when the gauge goes back to zero. When do Codex usage limits reset? The 5-hour window resets 5 hours after it opens. The weekly window resets about 7 days after its first request, not on a fixed day. A new weekly period starts with your first Codex request after the previous one ended. If you stop using Codex for three days, your next week starts when you come back, so two people on the same plan reset on different days. GitHub issue #28246 documents this anchoring and the paid time it can cost you. The two windows are checked separately. A fresh 5-hour window does not help if the weekly gauge is at 100%. How do I check when my Codex limit resets? In the CLI: run /status in a Codex session. It shows the percentage used in each window and when each one resets. Recent CLI versions also have /usage . On the web: the Codex usage page in ChatGPT settings shows the same windows, plus any banked resets on your account. What is a banked Codex reset? A one-time reset that OpenAI puts on your account for you to use later, instead of resetting you on the spot. When you redeem it from the usage settings, both your 5-hour and weekly windows go back to 0% used, and your weekly reset date moves to a week from then. It does not raise your plan's allowance. Banked resets expire about 30 days after they are granted , and nothing reminds you. Users have asked OpenAI to extend that in GitHub issue #28888 . The practical rule: redeem a banked reset when your weekly gauge is high, not when it is nearly empty, and redeem it before the 30 days are up. Why does OpenAI keep resetting Codex limits? Mostly to celebrate launches and user milestones, and occasionally to compensate for bugs that over-counted usage. Most resets are announced on X by Thibault Sottiaux (@thsottiaux), who leads Codex engineering. Resets have marked 8M, 9M, 10M, 15M and 20M active users, new model releases, and on 29 August a set of fixes to bugs that had been charging users too much usage. None of these resets is scheduled. You can't plan a workload around the next one, and you shouldn't price a plan on the assumption that it will come. Codex reset log: August and September 2026 This log lists only the resets that both codex-resets.com and aiidelist record. Dates are in UTC. “Immediate” resets apply to all paid accounts at once. “Banked” resets are loaded into accounts to be redeemed within 30 days. Date Type Occasion 1 Aug 2026 Immediate Efficiency gains on Luna 8 Aug 2026 Immediate GPT-5.6 Sol release 11 Aug 2026 Immediate No reason given 13 Aug 2026 Immediate 15M active users 21 Aug 2026 Banked 20M active users 24 Aug 2026 Immediate Usage fixes landed 25 Aug 2026 Immediate No reason given 27 Aug 2026 Immediate No reason given 29 Aug 2026 Immediate Fixes for bugs that over-counted usage 22 Sep 2026 Banked GPT-6 Sol and Luna release 26 Sep 2026 Immediate Weekend reset The trackers disagree about early September. aiidelist also lists banked resets on 3 and 5 September for accounts waiting on GPT-6 Astra, and resets on 31 August, 8 September and 12 September. codex-resets.com shows no reset between 29 August and 22 September. July was the busiest month, with a run of resets tied to the 7M to 10M user milestones. Where can I track Codex resets? Several community sites watch the announcements and log each reset. None is run by OpenAI. codex-resets.com : full history with average and median intervals. codex-reset.com : days since the last reset. aiidelist Codex reset tracker : dated timeline with reasons. usagereset.com : tracks Codex and Claude Code resets. Does Claude Code do surprise resets too? Not as a habit. Claude plans use the same two-window structure, a 5-hour session and a weekly limit, but Anthropic does not run a milestone reset programme. What a Claude week is worth is on our Claude Max weekly limit page . Sources codex-resets.com: Codex reset history and statistics aiidelist: Codex reset tracker GitHub openai/codex #28246: quota windows anchor to first post-reset use GitHub openai/codex #28888: extend banked reset expiration beyond 30 days OpenAI Help: Paid weekly Work and Codex rate limit resets Related How much Codex ChatGPT Pro includes, in dollars Claude Max vs ChatGPT Pro: the full 60-day study Claude Max 20x vs 5x: the weekly limit, measured Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # How Much Codex Does ChatGPT Pro Include? We Priced It · FinOps LLM URL: https://finopsllm.com/research/codex-usage-limits-chatgpt-pro How much Codex does ChatGPT Pro include? We priced the weekly limit in dollars Updated September 27, 2026 · first published September 27, 2026 Quick answer: A full weekly Codex window on ChatGPT Plus has been worth a median $67 of API-priced usage since August 2026. OpenAI sells Pro as 5x and 20x the Plus allowance, which projects to about $335 a week on... A full weekly Codex window on ChatGPT Plus has been worth a median $67 of API-priced usage since August 2026. OpenAI sells Pro as 5x and 20x the Plus allowance, which projects to about $335 a week on Pro 5x ($100) and about $1,340 a week on Pro 20x ($200). Those Pro figures hold only if the weekly window scales as far as the 5-hour one, and there is a simple way to check that yourself. This page answers one question from our full 60-day study of ChatGPT Pro and Codex against Claude Max : how much Codex a ChatGPT plan really gives you. The numbers come from 27 measured weekly Codex windows, priced at the OpenAI API list price in force on the day of each request. How do Codex usage limits work? Two rolling windows, one of 5 hours and one of a week, spent in tokens rather than messages. Codex shows each window as a percentage used, and a run stops when either one reaches 100%. How fast you use it depends on the model, how much context the session holds, how hard the model reasons and how many tools it calls. A long session in a large repository costs more per turn than a fresh one. Because Codex logs the percentage alongside every request, you can price a window in dollars. Divide the API cost of the requests by the percentage points they used, then multiply by 100. When do Codex usage limits reset? The 5-hour window resets 5 hours after it opens, and the weekly window about 7 days after its first request, not on a fixed calendar day. A new weekly period starts with your first Codex request after the last one ended, so two users on the same plan reset on different days. The two windows are checked separately: a fresh 5-hour window does not help if the weekly gauge is at 100%. Check your reset time in the ChatGPT usage dashboard, or run /status in Codex CLI. Hit the limit early? Plus and Pro users can buy extra credits instead of waiting for the reset. “Will Codex reset early?” OpenAI has granted one-off weekly resets to paid users, but they are occasional and announced by OpenAI, not something you can schedule around. See our Codex reset log for every recent one and how banked resets work. How much is a week of Codex on ChatGPT Plus worth? $67 at API prices since August 2026, and $115 before that. The last seven weekly windows we measured all fell between $61 and $81. Each dot is one weekly window. Value = 100 × API-dollars spent ÷ percentage points of the weekly gauge consumed; dot size is how much of the window was used (windows under 30pp excluded). The August drop tracks the price list more than the quota: GPT-5.6 Sol lists at $2/$10 against $5/$30 for GPT-5.5. Month Codex API-equivalent $ (Plus, $20) Multiple of the fee Jun 2026 $302 15x Jul 2026 $736 37x Aug 2026 $640 32x Did Codex limits get smaller in August? Probably not. The tokens got cheaper. In August the default Codex model moved from GPT-5.5, listed at $5 input and $30 output per million tokens, to Sol at $2 and $10. If the weekly quota tracks compute, cheaper tokens mean fewer dollars per window for the same amount of work. ChatGPT Plus vs Pro: how much more Codex do Pro 5x and Pro 20x include? About $335 a week on Pro 5x and about $1,340 a week on Pro 20x, projected. We haven’t run the Pro plans. These are the measured $67 Plus week multiplied by OpenAI’s published 5x and 20x. Plan Price / month Codex API $ per week Basis ChatGPT Plus $20 $67 Measured ChatGPT Pro 5x $100 ~$335 Plus × 5, projected ChatGPT Pro 20x $200 ~$1,340 Plus × 20, projected One caution comes from the other side of the market. Anthropic also labels its $200 plan 20x, and there the weekly limit turned out to be only about 1.5 to 2 times the $100 plan’s . OpenAI’s weekly window may scale fully, or it may not. How can you check whether Pro 20x really gives 20x per week? Watch the weekly gauge during your first week. A full Plus week is one twentieth of a full Pro 20x week, or 5 percentage points. A full, Plus-sized day of work should therefore move the Pro 20x weekly gauge by about 1 point. If it moves by 3 or 4, your real weekly multiplier is closer to 5x than 20x. Is Codex on ChatGPT Pro better value than Claude Max? At $200, yes, by about 2.4x on finished coding tasks, provided the weekly multiplier holds above about 7x. Claude Max 20x holds more API value per week, at about $1.86k. But GPT-6 Sol needed 3.3 times (DataCamp) to 4.2 times (codeongrass) fewer dollars than Claude to finish the same job. At $100, Claude Max 5x and ChatGPT Pro 5x come out close to even. The full study has the tasks-per-week table and the break-even chart. Availability varies, too. buildthisnow reports that new sign-ups to the $200 Pro tier have been paused since 10 September 2026. Sources OpenAI Help: Paid weekly Work and Codex rate limit resets OpenAI: Codex plans and usage limits OpenAI API pricing DataCamp: GPT-6 Sol vs Claude Opus 5.5 codeongrass: Claude Code vs Codex for heavy users buildthisnow: Codex vs Claude Code usage limits Related Codex usage limit resets: how they work, and a dated log Claude Max vs ChatGPT Pro: the full 60-day study Claude Max 20x vs 5x: the weekly limit, measured How many tokens Claude Pro and Max give you Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # AI Coding Plan Comparison · FinOps LLM URL: https://finopsllm.com/research/coding-plan-comparison AI Coding Plan Comparison Updated 12 July 2026 · first published 4 July 2026 Compare major AI coding plans with verifiable evidence. Pricing, limits, and model scores in one normalised table. Built from provider docs and explicit conversion rules for fair comparison. 9 Providers tracked 29 Plans compared 62 Models listed Jul 2026 Last updated Every update is tied to public evidence Prompt / Request conversion rules are explicit Fixed calculation logic keeps comparisons consistent Methodology Collection Plan, limit, and model data are collected from public provider sources. Normalisation Prompt / request / period formats are normalised into one comparison model. Conversion rules Request / Prompt = 15 and Weekly × 4 = Monthly are applied explicitly. Display policy Official values and estimated values are clearly separated in the UI. Update Feed Jul 4, 2026 coding-plan-comparison research page launched Published evidence-first AI coding plan comparison as a FinOps LLM research article. May 27, 2026 Xiaomi MiMO quota increased Xiaomi MiMO increased the available usage limits, and the comparison table has been updated. May 1, 2026 Alibaba sunsets Coding Plan, adds Token Plan (Team Edition) Alibaba closed the previous Coding Plan and introduced Token Plan (Team Edition). Coding Plan Comparison List Request / Prompt conversion rate (default = 15) 1 Prompt = 15 Requests Sort Default order Best value ≤ $10 Best value ≤ $30 Best value (all) Show: All Coding Agent Provider ↕ Plan ↕ Price ↕ Uses Prompt / mo ↕ Request / mo ↕ Prompt / $1 ↕ Request / $1 ↕ Models Intel ↕ Coding ↕ Agentic ↕ GLM Lite $10 Coding + Agent 160 2,400 16 240 GLM-5.1 (×3), GLM-5-Turbo (×3), GLM-4.7 (×1) 47 37 66 GLM Pro $30 Coding + Agent 267 4,000 8.9 133 GLM-5.1 (×3), GLM-5-Turbo (×3), GLM-5 (×3) 50 44 63 GLM Max $80 Coding + Agent 400 6,000 5 75 GLM-5.1 (×3), GLM-5-Turbo (×3), GLM-5 (×3) 50 44 63 MiniMax Starter $10 Coding + Agent 400 6,000 40 600 MiniMax-M2.7 (×1) 50 42 61 MiniMax Plus $20 Coding + Agent 600 9,000 30 450 MiniMax-M2.7 (×1) 50 42 61 MiniMax Max $45 Coding + Agent 889 13,333 19.8 296 MiniMax-M2.7 (×1) 50 42 61 MiniMax Plus-HighSpeed $40 Coding + Agent 300 4,500 7.5 112.5 MiniMax-M2.7-highspeed (×1) 50 42 61 MiniMax Max-HighSpeed $80 Coding + Agent 500 7,500 6.25 93.75 MiniMax-M2.7-highspeed (×1) 50 42 61 MiniMax Ultra-HighSpeed $150 Coding + Agent 533 8,000 3.55 53.3 MiniMax-M2.7 (×1) 50 42 61 BytePlus Lite $10 Coding + Agent 120 1,800 12 180 Seed-Code (×1), GLM-4.7 (×1), DeepSeek-V3.2 (×1), kimi-k2.5 (×1) 34 31 36 BytePlus Pro $50 Coding + Agent 120 1,800 2.4 36 Seed-Code (×1), GLM-4.7 (×1), DeepSeek-V3.2 (×1), kimi-k2.5 (×1) 34 31 36 StepFun Flash Mini $6.99 Coding 229 3,433 32.8 491 step-3.5-flash (×1) 38 32 52 StepFun Flash Plus $9.99 Coding 641 9,610 64.2 962 step-3.5-flash (×1) 38 32 52 StepFun Flash Pro $29 Coding 828 12,414 28.6 428 step-3.5-flash (×1) 38 32 52 StepFun Flash Max $99 Coding 808 12,121 8.16 122.4 step-3.5-flash (×1) 38 32 52 KwaiKAT Mini $5 Coding 1,075 16,128 215 3,226 KAT-Coder-Pro V2 (×1) 44 46 51 KwaiKAT Starter $10 Coding 1,344 20,160 134.4 2,016 KAT-Coder-Pro V2 (×1) 44 46 51 KwaiKAT Pro $20 Coding 2,016 30,240 100.8 1,512 KAT-Coder-Pro V2 (×1) 44 46 51 KwaiKAT Max $50 Coding 2,688 40,320 53.76 806.4 KAT-Coder-Pro V2 (×1) 44 46 51 OpenCode Go $10 Coding + Agent 667 10,000 66.7 1,000 MiniMax-M2.5 (×1), M2.7 (×1.4), MiMo-V2-Pro (×16), kimi-k2.5 (×11), GLM-5 (×17) 50 44 63 Xiaomi MiMO Sign up - both get $2 ↗ Lite $6 Coding + Agent 380 5,693 63.3 949 MiMo-V2-Pro (×1), MiMo-V2-Omni (×1) 49 41 63 Xiaomi MiMO Sign up - both get $2 ↗ Standard $16 Coding + Agent 382 5,729 23.9 578 MiMo-V2-Pro (×1), MiMo-V2-Omni (×1) 49 41 63 Xiaomi MiMO Sign up - both get $2 ↗ Pro $50 Coding + Agent 422 6,333 8.44 126.7 MiMo-V2-Pro (×1), MiMo-V2-Omni (×1) 49 41 63 Xiaomi MiMO Sign up - both get $2 ↗ Max $100 Coding + Agent 456 6,833 4.56 68.3 MiMo-V2-Pro (×1), MiMo-V2-Omni (×1) 49 41 63 Alibaba Standard $30 Coding + Agent 17 262 0.57 8.73 qwen3.6-plus (×1), deepseek-v3.2 (×1), GLM-5 (×1), MiniMax-M2.5 (×1) 50 43 62 Alibaba Advanced $100 Coding + Agent 21 314 0.21 3.14 qwen3.6-plus (×1), deepseek-v3.2 (×1), GLM-5 (×1), MiniMax-M2.5 (×1) 50 43 62 Alibaba Premium $200 Coding + Agent 26 393 0.13 1.97 qwen3.6-plus (×1), deepseek-v3.2 (×1), GLM-5 (×1), MiniMax-M2.5 (×1) 50 43 62 Values not explicitly provided by providers are shown in gray . Many providers limit either Prompt or Request quotas. We convert dynamically using the Request / Prompt rate control above (default: 15). If the highest official limit is weekly, monthly is estimated as Weekly × 4. Artificial Analysis Score is measured by artificialanalysis.ai . See their site for details. Some links may include referral codes. Plan details can change frequently. Always verify the latest information on official provider pages. Practical Guide How to choose a coding plan Price alone is not enough. Match each plan to your working style first. Start with Agent policy, limit type, and contract horizon. 1) Check Agent policy first Some providers or plans restrict Agent usage. If Agent workflows matter, verify terms and the Uses column (Coding / Agent) before subscribing. 2) Prompt limits vs Request limits For manual chat-heavy usage, batching work into fewer turns often aligns better with Prompt-style limits. For automation and Agent-heavy workflows, backend request volume can grow quickly, so prioritise plans with sufficient Request headroom. 3) Prefer monthly, use annual when early terms are superior Plan revisions and enrolment changes are increasingly common. Monthly gives flexibility, while annual can be effective when launch-period terms are clearly advantageous. 4) Speed (token/s) is a real productivity factor With the same quota, slower responses still cost more working time. We plan to add token-per-second metrics in a future update. Additional checks worth adding Separate Provided from Estimate values (estimates can shift) Confirm same-class model availability (none means unavailable) Match reset cycle (5h / daily / monthly) to your actual usage window Detailed cost comparison: See Cursor vs Copilot vs Claude Code Cost for per-tier pricing, credit value, and total cost breakdowns by subscription level. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is the methodology? Plan, limit, and model data are collected from public provider sources. NormalisationPrompt / request / period formats are normalised into one comparison model. Conversion rulesRequest / Prompt = 15 and Weekly × 4 = Monthly are applied explicitly. What is the update feed? Published evidence-first AI coding plan comparison as a FinOps LLM research article. May 27, 2026 Xiaomi MiMO quota increased Xiaomi MiMO increased the available usage limits, and the comparison table has been updated. How do the coding plans compare? Values not explicitly provided by providers are shown in gray. Many providers limit either Prompt or Request quotas. We convert dynamically using the Request / Prompt rate control above (default: 15). If the highest official limit is weekly, monthly is estimated as Weekly × 4. How do you choose a coding plan? How to choose a coding plan Price alone is not enough. Match each plan to your working style first. Start with Agent policy, limit type, and contract horizon. 1) Check Agent policy first Some providers or plans restrict Agent usage. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Committed spend is a bet on your forecast · FinOps LLM URL: https://finopsllm.com/research/committed-spend-discounts Committed spend and reserved capacity discounts Updated September 1, 2026 · first published September 1, 2026 Quick answer: Once your model spend is large enough to be noticed, a provider will offer you a discount for committing to a volume. Provisioned throughput, an annual commitment, a reserved capacity tier — the... Once your model spend is large enough to be noticed, a provider will offer you a discount for committing to a volume. Provisioned throughput, an annual commitment, a reserved capacity tier — the shapes differ, the trade does not. You are being paid to be predictable. The discount is real. So is the risk, and it is not the one most teams price. The three risks, in order of how much they cost Underuse is the obvious one and the smallest. You commit to a volume, you use less, you pay for the gap. It is easy to model and easy to bound: commit under your conservative case, not your plan. Being locked to a model is bigger. A commitment usually names a model or a family. The frontier moves in months. A twelve-month commitment to today's flagship is a bet that nothing meaningfully cheaper arrives — and something meaningfully cheaper has arrived every quarter for three years. The discount has to beat the price decline you would have got by doing nothing, not the price you pay today. Losing the ability to switch is biggest and never appears in the model. A commit removes your leverage in the next negotiation, because both sides know you cannot walk. It also quietly kills routing work: nobody optimises traffic away from a model the company has prepaid for, even when a cheaper route is right there. How to price it Compare against the honest counterfactual. Not "list price times volume", but what you would plausibly have paid on-demand over the same period, including the price cuts and cheaper models that historically arrive within it. On a twelve-month horizon that counterfactual is often 20–40% below today's list, which eats most of a typical commit discount before you start. Then check the shape of the deal. Commit to a floor, not a plan — the volume you are confident about even if a product underperforms. Prefer spend commitments to model commitments , since a dollar commitment lets you move to whatever the provider ships next. Insist on rollover or reallocation for unused volume. And keep the term short ; in a market repricing every quarter, a twelve-month term is already long and a multi-year one is a different kind of decision. When it is clearly right Stable, high-volume, latency-sensitive production traffic on a model you have already run for two quarters without wanting to change it. That is a real forecast, and being paid for it is a good deal. Everything experimental, agentic, or growing fast should stay on-demand — those are exactly the workloads whose volume you cannot promise and whose model you will want to change. Related LLM purchasing guide Provider arbitrage How to budget for AI spend Related LLM purchasing guide Provider arbitrage How to budget for AI spend Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # You pay for the context window twice · FinOps LLM URL: https://finopsllm.com/research/context-window-paid-twice Paying for the context window twice Updated September 1, 2026 · first published September 1, 2026 Quick answer: A context window is advertised as capacity: 200,000 tokens, a million tokens, room for whatever you need. Capacity is not the billing unit. You are charged for what you send, and in a multi-turn... A context window is advertised as capacity: 200,000 tokens, a million tokens, room for whatever you need. Capacity is not the billing unit. You are charged for what you send , and in a multi-turn conversation you send most of it again every single turn. That is the second payment. A 30,000-token document loaded at the start of a twenty-turn conversation is not 30,000 input tokens. It is closer to 600,000, because turn two re-sends it, and so does turn twenty. The arithmetic nobody runs Cost scales with the square of conversation length, not linearly. Doubling the number of turns roughly quadruples the input tokens, assuming context keeps accumulating. Teams that model "cost per message" and multiply by message count under-forecast long sessions badly, and the error grows with exactly the users you most want to keep. There is often a third charge on top: many providers price requests above a long-context threshold at a premium rate. One extra attachment can push a request across that line and reprice the entire call, input and output, not just the tokens that crossed it. What to measure Track context utilisation : tokens sent versus tokens the model actually needed. It is the closest thing to a waste metric this domain has. Track input tokens per conversation , not per request, and watch the p99 — that is where the sessions live that cost twenty times the median. Alert on requests crossing the long-context price threshold. It is a step change, not a gradient, and it will not look like anything in a daily total. Three fixes, cheapest first Cache the stable prefix. If the system prompt and loaded documents do not change during a conversation, prompt caching turns the repeated cost into a fraction of it. This is the single highest-return change for any multi-turn product. Trim history deliberately. Older turns rarely earn their re-send price. Summarise the earlier part of a long conversation and drop the raw turns; you keep the thread and stop paying full freight for it. Send the excerpt, not the corpus. Retrieval exists for exactly this. The window being large enough to hold a whole document is not an argument for putting a whole document in it. Related Prompt caching economics Long context vs RAG cost Cost per request as a KPI Related Prompt caching economics Long context vs RAG cost Cost per request as a KPI Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # What one usable image costs · FinOps LLM URL: https://finopsllm.com/research/cost-per-approved-image Cost per approved asset in image and video Updated September 1, 2026 · first published September 1, 2026 Quick answer: Image and video pricing looks unusually simple: a price per image, or per second of output. That simplicity is why almost every team budgets it wrong. The provider charges per generation. Your... Image and video pricing looks unusually simple: a price per image, or per second of output. That simplicity is why almost every team budgets it wrong. The provider charges per generation . Your business consumes approved assets . Those are not the same number, and on visual work they are usually not even close. The acceptance rate is the whole model Nobody ships the first render. A designer generates, looks, adjusts the prompt, generates again. For a well-defined style with a mature prompt, acceptance might be one in three. For open-ended creative exploration, one in ten or worse. Video is harsher still, because a clip can fail on motion, on temporal consistency, or on a single bad frame — and you pay for the whole clip either way. So the useful arithmetic is not the sticker price. It is sticker price divided by acceptance rate. At one in eight, an asset with a list price of a few cents costs closer to a quarter, and a video generation priced per second becomes a genuinely material line the moment a team starts iterating. What actually moves the number Resolution and duration are the obvious levers and the least interesting ones, because they trade directly against the output you wanted. The levers that matter are the ones that raise acceptance. Iterating at low resolution and only upscaling the chosen frame changes the economics more than any per-image discount. A prompt library for known styles turns one-in-ten exploration into one-in-three execution. Reference images and seeds convert a fresh gamble into a controlled variation. And a written brief before the first generation removes the most expensive failure mode there is: iterating toward a target nobody had defined. Measure the right thing Track generations per approved asset, per project and per person, and cost per approved asset as your headline number. Both are cheap to instrument and immediately actionable — a team at fifteen generations per approval has a brief problem or a tooling problem, not a pricing problem, and no provider switch will fix it. Related LLM cost attribution How to budget for AI spend Evals as cost control Related LLM cost attribution How to budget for AI spend Evals as cost control Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Cost per request as a product KPI · FinOps LLM URL: https://finopsllm.com/research/cost-per-request-kpi Cost per request as a product KPI Updated 21 May 2026 · first published 21 May 2026 Product teams already track latency p95 and error rate per endpoint. They argue about them in sprint reviews, write them into PRD acceptance criteria, and page on them in production. Cost-per-request belongs in exactly the same conversation. It is the third leg of the product-quality tripod, and the one that almost every AI product team currently treats as a finance footnote rather than a feature-owner metric. Treating it as a KPI is what turns AI spend from a monthly surprise into something a product manager can plan against, allocate, and report on. This page is about the mechanics of putting cost-per-request into the same documents and rituals product teams already use for performance. It is not a savings argument. The point is ownership, not minimization. A feature owner who knows what their endpoint costs per call can defend it, allocate it to the right cohort, and report it back to finance with a straight face. A feature owner who does not know is one provider price change away from a margin event nobody can localize. Why cost-per-request needs to be a KPI, not a footnote The reason latency and error rate became KPIs is that they are per-request, per-endpoint, and have an obvious owner. Anyone who can move latency can also degrade it, so the metric naturally finds an accountable team. Cost-per-request has the same shape. Every model call has a fully-loaded dollar number attached to it, that number is bounded by code that some team owns, and changes to that code move the number up or down in measurable ways. Everything required to treat it as a first-class product metric is already there. What is missing is the convention of writing it down next to the other two. The cost of leaving it out is that AI spend stays attributed to a generic platform line nobody defends. Finance gets a monthly invoice and asks engineering what changed. Engineering points at recent launches but cannot say which one moved the number, by how much, or for which cohort. The conversation ends with a vague commitment to "watch it," which is what teams say when no metric exists. Adding cost-per-request to the product KPI set replaces that conversation with a variance review. Defining it without ambiguity A KPI that is not defined precisely will be measured inconsistently and argued about forever. Cost-per-request, fully loaded, is the sum of the provider-billed cost of every token attributable to a single user-visible request. That includes input tokens, output tokens, cache-read tokens at their discounted rate, cache-write tokens at their full rate, reasoning tokens when the model emits them, and the output tokens of any tool calls the request triggered. It is priced at the rate the provider actually billed, not at the rate the team wishes they had been billed. It is reported per endpoint, per feature, and per cohort, not as a global average. Three definitional traps are worth naming. Cache-read tokens are cheaper than input tokens but they are not free, and a denominator that excludes them will drift from the invoice. Reasoning tokens on models that emit them can dwarf the visible output and must be counted. Tool-call output tokens are billable work performed on behalf of the originating request and belong in that request's number, not in a separate tool-owner bucket. Get those three right and the KPI will reconcile against the provider invoice to within rounding. Where it goes in product docs A KPI that lives only in a dashboard is not yet a KPI. It becomes one when it appears in the documents and rituals that gate product work. In the PRD, cost-per-request belongs in the acceptance criteria next to latency and error rate. A launch-ready feature has a stated target cost-per-request at the cohorts the feature is shipping to, and a stated ceiling above which the launch is blocked pending review. The target is set by the feature owner in consultation with the team that owns the budget line, not handed down by finance. In the release readiness checklist, cost-per-request gets a row. A release that increases the metric by more than an agreed threshold against the previous release is not automatically blocked, but it requires a written justification from the feature owner explaining what changed and which cohort is now carrying the increase. Quality improvements that legitimately cost more are fine; quality regressions that also cost more are not. In the sprint review, cost-per-request sits next to the other endpoint metrics. The feature owner walks the team through the week's movement: which endpoints moved, which releases drove the movement, which cohorts were affected. The conversation is the same shape as the latency review the team already runs. In the on-call runbook, a sustained spike in cost-per-request is an incident class. It does not always require a page, but it requires a triage path: who looks at it first, what data they pull, what the rollback criteria are. Cost incidents that get treated as finance problems get found weeks late; cost incidents that get treated as product incidents get found in hours. The attribution layer that has to exist first Cost-per-request as a KPI presupposes a working attribution layer. Every model call has to carry, at minimum, the endpoint it served, the feature tag the endpoint belongs to, the team that owns the feature, and the cohort or tenant the request was made on behalf of. Without those tags the metric is a global average, and a global average has no owner. With them, the metric rolls up per feature for the owning team and per cohort for the customer-success conversation. Teams that try to add the KPI before the attribution layer end up with a number that nobody trusts and nobody defends. The order is fixed: tagging first, then the dashboard, then the document changes. Skipping the first step produces a metric that finance reports and product ignores, which is the failure mode this whole exercise is designed to prevent. What a healthy review looks like A weekly cost-per-request review has the same rhythm as a weekly latency review. The dashboard shows the metric per endpoint over the last seven days, broken out by cohort, with the previous week's value as the comparison. The feature owner identifies the endpoints that moved by more than the review threshold and walks the team through why. Releases that shipped during the window are cross-referenced against the movement. Cohort shifts - a large customer ramping up, a new tier launching, a free-tier promo driving low-value traffic - are called out by name. The review ends with either a clean bill of health or a written follow-up owned by a specific engineer. The review is not a finance ritual. It is run by the product team, attended by the feature owners, and minuted in the same place as the latency review. Finance gets the output, not the process. That separation is what keeps the KPI a product metric rather than a budget metric. Common patterns we see go wrong Averaging across cohorts is the most common failure. A handful of high-volume customers can pull the global average so far from the median that the metric stops describing the typical request. Reporting cost-per-request without a cohort breakdown is reporting a number that protects the team from the conversation the number is supposed to start. Ignoring the cache-read tax in the denominator is the second. Teams that exclude cache-read tokens from their cost calculation get a number that looks great in the dashboard and fails to reconcile against the invoice. The fix is straightforward: cache-read tokens count, at the discounted rate the provider actually billed. Tracking cost-per-request only in finance, not in product, is the third. A metric that lives in a finance dashboard but not in a PRD is a reporting artifact, not a KPI. Product owners who do not see the number weekly will not move it, and finance reporting it back to them monthly is a lagging signal nobody can act on. Chasing the metric without tracking quality is the fourth. Cost-per-request without a paired quality metric - task success, user thumbs-up, downstream conversion - invites the team to optimize the number by degrading the product. The KPI works only when it is reviewed alongside the quality signal it serves. The chargeback hook Once cost-per-request is owned per feature, monthly chargeback becomes arithmetic. Sum the requests in the period, multiply by the per-feature cost-per-request, and the team that owns the feature gets a line on their budget that matches what the invoice says. Per-tenant chargeback works the same way, summed across the tenants the feature served. Without the KPI, chargeback is a guess. Finance allocates AI spend across teams using whatever proxy is available - headcount, last quarter's split, the loudest team's protest - and engineering treats the resulting numbers as fiction. With the KPI, the allocation is defensible at the row level and the conversation moves from "is this number fair" to "is this number worth the feature it bought." A short rollout plan Week one is tagging. Every model call carries feature, team, endpoint, and cohort, enforced at the gateway or the SDK. No new dashboards yet; the goal is to get the data clean before anyone looks at it. Week two is the dashboard. Cost-per-request per endpoint, per feature, per cohort, with weekly and monthly views. Reconcile the rollup against the provider invoice and resolve any gap before the dashboard is shown to anyone outside the team. Week three is the document work. Add the KPI to the PRD template, the release readiness checklist, and the on-call runbook. Pick a threshold for the release variance check that the team will actually enforce, not one that sounds rigorous but gets waived. Week four is the review cycle. Cost-per-request is on the agenda of the weekly product review, owned by the feature owners, reported up to finance as a monthly rollup rather than a monthly surprise. By the end of the month the metric is part of how the team ships, and the chargeback conversation has somewhere to land. Related LLM cost attribution LLM cost monitoring LLM chargeback and showback LLM budget governance Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ Why cost-per-request needs to be a KPI, not a footnote? The reason latency and error rate became KPIs is that they are per-request, per-endpoint, and have an obvious owner. Anyone who can move latency can also degrade it, so the metric naturally finds an accountable team. Cost-per-request has the same shape. How do you define cost-per-request without ambiguity? A KPI that is not defined precisely will be measured inconsistently and argued about forever. Cost-per-request, fully loaded, is the sum of the provider-billed cost of every token attributable to a single user-visible request. Where it goes in product docs? A KPI that lives only in a dashboard is not yet a KPI. It becomes one when it appears in the documents and rituals that gate product work. In the PRD, cost-per-request belongs in the acceptance criteria next to latency and error rate. What is the attribution layer that has to exist first? Cost-per-request as a KPI presupposes a working attribution layer. Every model call has to carry, at minimum, the endpoint it served, the feature tag the endpoint belongs to, the team that owns the feature, and the cohort or tenant the request was made on behalf of. What a healthy review looks like? A weekly cost-per-request review has the same rhythm as a weekly latency review. The dashboard shows the metric per endpoint over the last seven days, broken out by cohort, with the previous week's value as the comparison. What commonly goes wrong with cost-per-user benchmarks? Averaging across cohorts is the most common failure. A handful of high-volume customers can pull the global average so far from the median that the metric stops describing the typical request. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Cost per successful task beats cost per request · FinOps LLM URL: https://finopsllm.com/research/cost-per-successful-task Cost per successful task beats cost per request Updated August 27, 2026 · first published August 27, 2026 Quick answer: Cost per request is useful, but it is not the unit that users buy. A request that fails, retries three times, or produces an unusable answer is not a successful unit of work. For production AI, the... Cost per request is useful, but it is not the unit that users buy. A request that fails, retries three times, or produces an unusable answer is not a successful unit of work. For production AI, the stronger metric is cost per successful task : all provider and tool costs divided by tasks that meet a defined quality threshold. The metric Use successful_task_cost = total attributable spend / successful tasks . Include input, output, cache, reasoning, tool, retry, and fallback costs. Define success before measuring it: a support answer accepted by the user, a classification above its confidence threshold, or a workflow completed without human repair. Why request averages mislead Request averages improve when you count cheap failed attempts. They also hide the long tail: a feature can have a low median request cost while its failed cases consume expensive reasoning calls and human review. Segment by feature, model, customer cohort, and outcome. Report p50 and p95 successful-task cost alongside success rate. Instrument the denominator Every model span needs a request ID and feature tag; the application must then emit an outcome event linked to that ID. Record success, failure reason, human repair, latency, and revenue or service value where available. Reconcile provider invoices to the numerator and sample completed tasks to validate the denominator. Use it to choose an optimization If request cost is high but success rate is high, routing or caching may help. If request cost is low but successful-task cost is high, quality is the problem: retries, weak models, missing context, or poor stopping rules. Optimize the metric that includes the failure cost, then verify quality does not regress. Related LLM cost monitoring Cost per request as a product KPI LLM cost attribution Related LLM cost monitoring Cost per request as a product KPI LLM cost attribution Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # The real cost of switching LLM providers · FinOps LLM URL: https://finopsllm.com/research/cost-switching-llm-providers The real cost of switching LLM providers Updated August 27, 2026 · first published August 27, 2026 Quick answer: Switching LLM providers is not a price-sheet exercise. The business case includes migration engineering, prompt and schema changes, evaluation, dual-running, data transfer, support, and the risk of a... Switching LLM providers is not a price-sheet exercise. The business case includes migration engineering, prompt and schema changes, evaluation, dual-running, data transfer, support, and the risk of a quality regression. Compare those costs with the expected savings over the period in which the migration pays back. Count the migration work Inventory SDK calls, structured-output assumptions, tool schemas, rate limits, context behavior, safety controls, observability, and provider-specific error handling. Estimate the engineering and test hours for each. A gateway reduces future switching cost, but operating the gateway is itself a recurring cost. Price the quality work Run a fixed workload through old and new providers. Measure task success, p50 and p95 latency, retries, human repair, and evaluator agreement. Include the cost of building the test set and reviewing disagreements. A migration that saves tokens but adds review time has not yet saved money. Budget dual-running Run both providers long enough to observe production mix, failover, and seasonal behavior. Model the temporary double spend and the cost of keeping a warm fallback. If concentration risk is the reason for the move, include the standby cost in the baseline rather than treating it as waste. Calculate payback Use fully loaded monthly savings after migration, evaluation, and operating cost. Add a risk premium for uncertain quality and a rollback plan. The right choice may be a routing policy that keeps both providers, not a full replacement. Measure the result against invoices and successful-task cost. Provider switching is an option with a price. Make that price visible before the renewal deadline, and the organization can choose deliberately instead of negotiating from fear. Related Provider arbitrage Model concentration risk Model routing Related Provider arbitrage Model concentration risk Model routing Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Cursor vs Copilot vs Claude Code Cost · FinOps LLM URL: https://finopsllm.com/research/cursor-vs-copilot-vs-claude-code-cost Cursor vs Copilot vs Claude Code Cost Updated 12 July 2026 Compare subscription pricing, credit value, and total cost of ownership for AI coding assistants. We break down Cursor, GitHub Copilot, and Claude Code by plan tier and show cost-per-day metrics to help you choose. All pricing current as of July 2026 Monthly subscription costs verified from official sources Credit value shows model access cost per dollar No annual discounts found for any vendor Plan Comparison: Pricing & Credits Platform Plan Monthly Price Monthly Credits Credit Value Cost/Day GitHub Copilot Pro $10 1,500 $15 $0.33 GitHub Copilot Pro+ (Base) $39 3,900 $39 $1.30 Pro+ (with Flex) $39 7,000 $70 $1.30 GitHub Copilot Max $100 20,000 $200 $3.33 Cursor Pro $20 20 $20 $0.67 Cursor Pro+ $60 60 $60 $2.00 Cursor Ultra $200 200 $200 $6.67 Claude Code Pro $20 Unlimited — $0.67 Claude Code Max 5x $100 Unlimited (5×) — $3.33 Claude Code Max 20x $200 Unlimited (20×) — $6.67 Credit explanation: 1 AI credit typically = $0.01 in model access at standard API rates. Copilot's "flexible" credits (in Pro+) are the higher-usage pool and represent $70 in API value. Cursor credits are direct API spend; Claude Code subscriptions offer unlimited usage at a fixed monthly cost. Entry-Level Options ($10–$20/month) GitHub Copilot Pro ($10/month) Best for: Individual developers, part-time coding, learning. Includes: 1,500 AI credits/month ($15 value), basic models, code completion. Cost per day: $0.33 (roughly 50 AI credits/day if evenly used). Trade-off: Lowest price but smallest credit pool. Runs out fast for heavy users. Cursor Pro ($20/month) Best for: Full-time developers, independent contractors. Includes: $20 API credits/month, Claude 3.5 Sonnet access, chat + inline editing. Cost per day: $0.67 (roughly $0.67 per day in model API). Trade-off: Fixed credit budget; overage charges if you exceed $20. However, Cursor's interface provides high token efficiency compared to raw API use. Claude Code Pro ($20/month) Best for: Full-time developers who want unlimited usage. Includes: Unlimited Claude API access at standard rates, caching support, batch API use. Cost per day: $0.67 (fixed cost regardless of usage). Trade-off: Unlimited usage means no surprise charges. If you use more than ~$0.67/day equivalent, Claude Code can be more cost-effective than Cursor's fixed credits. Mid-Tier Options ($39–$100/month) GitHub Copilot Pro+ ($39/month) Best for: Teams using GitHub integrations, enterprise deployment. Includes: 7,000 AI credits/month ($70 value at standard rates), advanced models, priority support. Cost per day: $1.30 (~230 AI credits/day if evenly used). Trade-off: Credit-based model requires monitoring. If your team consistently uses more than 7,000 credits, overflow charges apply. Cursor Pro+ ($60/month) Best for: High-volume freelancers, small teams (3–5 developers). Includes: $60 API credits/month, unlimited chat, advanced models, priority queue. Cost per day: $2.00 (roughly $2/day in API credits). Trade-off: Higher per-person cost but 3x the monthly credit budget. Good for teams where some members use heavily, others lightly. Claude Code Max 5x ($100/month) Best for: Teams of 2–3 developers sharing one subscription. Includes: 5x Claude API usage cap (raises rate limits), unlimited access, priority support. Cost per day: $3.33 (fixed cost; no per-token limit). Trade-off: Unlimited usage simplifies billing. Most beneficial if your actual API spend would exceed $100/month at standard rates. Premium Options ($100–$200/month) GitHub Copilot Max ($100/month) Best for: Enterprise teams, high-volume departments. Includes: 20,000 AI credits/month ($200 value), all advanced models, GPT-5.5 turbo access, dedicated support. Cost per day: $3.33 (~660 AI credits/day if evenly used). Trade-off: Highest credit pool but credit-based pricing requires management. Best for organizations with predictable usage patterns. Cursor Ultra ($200/month) Best for: Large teams (10+), agencies, heavy compute workloads. Includes: $200 API credits/month, all models, unlimited chat windows, priority support. Cost per day: $6.67 (roughly $6.67/day in API credits). Trade-off: Highest tier. Cursor's interface efficiency means $200 in credits often goes further than raw API usage would. Claude Code Max 20x ($200/month) Best for: Teams of 5–10 developers or very high-volume solo practitioners. Includes: 20x Claude API usage multiplier, unlimited access, batch API, extended context windows. Cost per day: $6.67 (fixed cost regardless of usage). Trade-off: Highest price tier, but unlimited means no surprise charges. Best ROI if actual API spend would exceed $200/month. Cost Optimization Considerations 1. Usage patterns matter: If your actual LLM API consumption is $500/month, Claude Code Max 20x ($200) saves you $300/month vs. raw API. But if it's $50/month, Cursor Pro ($20) is better. 2. Credit efficiency: Copilot's credit model is transparent: 1 credit = $0.01 of API value. But you only see credits consumed, not the underlying token usage. Cursor and Claude Code show per-interaction costs more clearly. 3. Model access: Copilot Pro+ is the only plan offering access to GPT-5.5 turbo at this price point. Cursor Pro and Claude Code Pro use Claude Sonnet / Opus, which differ in speed and cost. Choose based on coding task complexity. 4. Team scaling: For 5+ developers, compare total cost: 5× Copilot Pro = $50/month ($0.30 total cost-per-user-per-day) 5× Cursor Pro = $100/month ($0.67 total cost-per-user-per-day) 1× Claude Code Max 20x (shared) = $200/month ($1.33 per user if split equally) GitHub Copilot Enterprise (org license) = $21/seat/month = $105 for 5 users For 5 developers, Copilot Pro at scale ($50) beats all others. For 10+ developers, Copilot Enterprise ($21/seat) becomes competitive. How to Choose Solo developer? Pick by daily usage. If you code 4 hours/day: Cursor Pro or Claude Code Pro ($20/month). If 2 hours/day: Copilot Pro ($10/month) is fine. Small team (2–5 people)? Sum individual usage. If total is $50–$100/month (raw API equivalent), Cursor Pro+ ($60) shared across 2–3 people is most economical. If $100+/month, Claude Code Max 5x ($100) for the team saves per-person cost. Large team (10+)? Use GitHub Copilot Enterprise ($21/seat/month) for org-wide governance, or negotiate bulk pricing with Cursor or Anthropic. Cost-first decision? If your actual LLM API spend (raw tokens) exceeds your subscription cost, unlimited tiers (Claude Code) are better. If your usage is light, credit-based tiers (Copilot, Cursor) let you pay only for what you use. Want help optimizing your AI coding spend across your team? FinOps LLM offers a free audit of your AI costs and can identify which plan tier fits your usage pattern best. Back to research FAQ Which coding assistant is cheapest? GitHub Copilot Pro at $10/month is the lowest-cost option, but offers fewer features and lower intelligence. Cursor Pro at $20/month and Claude Code Pro at $20/month offer better value for heavy users. What is credit value? Credits represent the value of model access per dollar spent. Copilot Pro+ offers 7,000 credits ($70 value) for $39/month = $1.79 per credit. Cursor Pro offers $20 in API credits for $20/month = $1.00 per credit. Claude Code Pro includes unlimited usage for $20/month. Should I pay per-month or annual? Most vendors offer no annual discount. Pay monthly unless you receive a long-term volume discount. Monthly provides flexibility if models change or pricing shifts. What about team pricing? GitHub Copilot offers organizational licenses at $21/seat/month (bulk discount). Cursor and Claude Code do not publish team pricing; contact sales for multi-seat arrangements. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # DeepSeek Harness Defensive Patterns · FinOps LLM URL: https://finopsllm.com/research/deepseek-harness-defensive-patterns Seven defensive patterns from the DeepSeek Harness docs Published 16 August 2026 DeepSeek Harness ships a short document of defensive patterns, each written as a general rule with the specific bug that motivated it. It is the most transferable file in the repository: none of it depends on adopting the harness, and every item corresponds to a failure mode that shows up in homegrown agent runtimes. 1. Report orthogonal outcomes independently Never nest one flag's report inside another flag's conditional. A process can time out and exit zero, because it trapped the signal and shut down cleanly. If the timeout is only reported inside a non-zero-exit branch, that outcome disappears. Timed-out, signal, and exit code are independent facts and need independent fields. Cost relevance: silently swallowed timeouts are how retry loops form. The caller sees success, gets nothing useful, and tries again. 2. Honour public contracts on both sides Where an outcome has multiple valid representations, normalise them before exposing them. The worked example is model-request failures: implementations may throw or emit an error finish chunk, and the API boundary normalises everything to a terminal finish chunk. Without that, a caller catching an exception cannot tell whether it came from the provider, from middleware, from logging, or from its own code. 3. Async state is not synchronous state Status queries are not causally tied to specific async operations. Awaiting an agent's idle state as a completion signal for one message is wrong, because multiple queued operations share execution intervals — idle may arrive before yours ran, or after someone else's did. The prescribed fix: an automation caller owning a run defines its interval explicitly, from inbox receipt through the next whole-agent idle, and attributes outputs to that interval rather than to individual messages. Handle the nothing-to-wait-for branch too, or the caller hangs indefinitely. An automation harness that hangs waiting for the wrong idle signal keeps a session and its children resident. The bill for that is not the hang; it is everything still alive behind it. 4. Dispose must reach quiescence, not just request it Requesting termination is not achieving it. Dispose awaits children's actual termination before returning. And listener registries close before kill signals are sent, so late completions land silently instead of firing callbacks into a half-torn-down system. This is the pattern with the clearest financial edge. A dispose that returns early leaves orphaned subprocesses and unclosed sandboxes running, and metered compute does not stop because its parent forgot about it. 5. Contain callback exceptions in the dispatcher Wrap dispatch loops in try/catch. One failing subscriber must not reject the dispatch promise or starve the listeners queued behind it. In an agent runtime the starved listener is frequently the one doing accounting, which is how usage records go missing without any error surfacing. 6. Never hand untrusted output the ambient environment or predictable paths The strongest rule in the document, and the one to adopt first. Scrub spawned command environments: remove variables matching key, secret, token, and password patterns before the subprocess starts. Use private directories created with owner-only permissions, random file names, and exclusive owner-only opens rather than predictable paths. Two distinct threats. Environment scrubbing stops harness credentials leaking into subprocess output that the model then reads — and, once read, that output is in the session log and the context window. Random names and exclusive creation close symlink races on shared temporary directories. 7. Unlink link-shaped paths Check whether a path is a symbolic link before unlinking, and delete the link rather than following it. Recursive removal is reserved for confirmed real directories, because it can traverse symlinks into their targets and throws on junctions. Cleanup code that deletes more than it created is a failure mode with no upper bound on the damage. How to use this list Take patterns 1 and 4 to your subprocess and sandbox teardown code today. Those two are where money leaks. Take pattern 6 to any place you spawn a process whose output the model will read. Take pattern 3 to your automation layer, especially anywhere a wait is expressed as "until the agent is idle". Take pattern 5 to your telemetry pipeline and check that a failing listener cannot starve the accounting one. Related Where to put spend guardrails in DeepSeek Harness — the enforcement points. DeepSeek Harness subagents and delegation depth — where dispose actually matters. DeepSeek Harness tool scopes and restrictions — narrowing the blast radius. The DeepSeek Harness session log as a cost record — what gets recorded. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ Why must a process report timeout and exit code independently? Because a process can time out and still exit zero, if it trapped the termination signal and shut down cleanly. Nesting the timeout report inside an exit-code branch makes that outcome invisible. Orthogonal outcomes need independent fields. What does it mean that dispose must reach quiescence? Requesting termination is not the same as achieving it. Dispose must await children's actual termination before returning, and close listener registries before sending kill signals so that late completions arrive silently rather than firing into a torn-down system. How should an agent harness handle subprocess environments? By scrubbing them. The documented rule is to remove variables matching key, secret, token, and password patterns before spawning, and to use private directories, random file names, and exclusive owner-only file opens rather than predictable paths. Why is awaiting agent idle an unreliable completion signal? Because status is a property of the whole agent, not of one message. Multiple queued operations share execution intervals, so idle can arrive before your message ran or after someone else's did. A caller must define its own interval explicitly and attribute outputs to that interval. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # DeepSeek Harness: Install and First Run · FinOps LLM URL: https://finopsllm.com/research/deepseek-harness-getting-started DeepSeek Harness: install, profiles, and first run Published 16 August 2026 This is the practical half of our DeepSeek Harness coverage: how to get dsh running, what the composition model expects of you, and which demos are worth ten minutes. Fastest path npx @deepseek-ai/dsh web That starts the web UI at http://127.0.0.1:3080 . From there, two things must happen before the session composer becomes usable: Settings → Models , and enter your DeepSeek API key. The route enables immediately; no restart. Choose workspace , to add and activate the project directory. Until a workspace is active, the composer stays unavailable. Once running, the agent can read and edit files, run commands, delegate tasks to subagents, and plan. It prompts for confirmation according to the active permission policy. From source git clone https://github.com/deepseek-ai/deepseek-harness pnpm install pnpm run build pnpm dsh web Floors to be aware of: Node 22.19 or newer (CI covers 22.19, 24, and 26), Git 2.26 or newer, and Corepack with pnpm pinned to pnpm@11.7.0 . A DEEPSEEK_API_KEY is optional, read from the environment or a gitignored repo-root .env ; alongside it, DEEPSEEK_BASE_URL can point at a different endpoint. The real-API end-to-end suites self-skip when the key is absent, so a keyless checkout still builds and tests cleanly. Profiles and bundles: the composition model Because every part of the harness is a plugin, something has to say which plugins are loaded. That is a profile : a named composition storing an ordered list of bundles plus user patches. A bundle distributes Cordis config rows and code. Three template profiles ship: Profile What it composes dsh-base Model adapters, tools, persistence dsh-web-app The browser UI dsh-headless One-shot runner The four-layer override order Configuration resolves in a fixed order, later layers winning: Profile bundles Profile patches Home-level patches CLI overlays Learn this order before you start debugging. Nearly every "why is it using that model" question in a layered config system is answered by finding which layer last touched the value, and a CLI overlay beats everything below it. The subsystems you will meet Six registry keys carry most of the behaviour: ctx.sessions (the append-only event log), ctx.systemPrompt , ctx.tools (a scoped registry with guarded execution), ctx.agents , ctx.agentLoop , and ctx.llm . If you are extending the harness, these are the names to search for first. Three demos worth running Headless one-shot: pnpm dsh --profile headless "summarize this workspace" . The shape you would wire into CI or a cron job. Cordis introspection: pnpm run demo:cordis . Self-referential — it inspects and modifies its own live plugin runtime. This is the clearest demonstration that the plugin claim is structural rather than marketing. ACP automation: pnpm run demo:acp . An automation server speaking JSON-RPC over stdio, which is the integration surface for driving the harness from another system. If you plan to contribute A few conventions save time. TODO markers are graded by urgency: FIXME is a release blocker, TODO is soon, XXX is someday. Lefthook runs pre-commit (staged pairing records, .oxlintrc.staged.json , third-party notices regeneration, whitespace, vendor manifest guard), pre-merge-commit , and pre-push ( pnpm run typecheck ). The hooks deliberately skip tests and builds — CI owns exhaustive coverage, and pnpm run check:all is the opt-in comprehensive local gate. Two quirks explain otherwise-confusing structure. The build splits into Host and Client tsconfig aggregates because both sides declaration-merge the Cordis Context interface under the same keys, and one TypeScript program seeing both merges reports a collision. And documentation code samples are kept honest by ts type-equiv fences plus pnpm run verify-type-equiv , so pasted declarations cannot silently drift from source. Set expectations The README says it plainly: this is a developer preview, and there will be compatibility-breaking changes. Plugin discovery runs through the dsh-plugin GitHub topic, and the project is MIT-licensed with third-party dependencies listed in THIRD_PARTY_NOTICES.md . Evaluate it now; standardise on it later. Related DeepSeek Harness: what "everything is a plugin" buys you — the architecture. Where to put spend guardrails in DeepSeek Harness — the control points. The DeepSeek Harness session log as a cost record — the accounting. The true cost of coding agents — budgeting for the result. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ How do you install and run DeepSeek Harness? The fastest path is npx @deepseek-ai/dsh web, which starts the web UI at http://127.0.0.1:3080. From source, clone the repo then run pnpm install, pnpm run build, and pnpm dsh web. What is a profile in DeepSeek Harness? A profile is a named composition that stores an ordered list of bundles plus user patches. Bundles distribute Cordis config rows and code. Three template profiles ship: dsh-base, dsh-web-app, and dsh-headless. What order does DeepSeek Harness apply configuration in? Four layers, in order: profile bundles, then profile patches, then home-level patches, then CLI overlays. Later layers override earlier ones, so a CLI flag wins over everything else. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # DeepSeek Harness Goals and the Ralph Loop · FinOps LLM URL: https://finopsllm.com/research/deepseek-harness-goals-ralph-loop DeepSeek Harness goals and the Ralph loop Published 16 August 2026 Most agent cost surprises are not about the price of a token. They are about how many times the agent decided to try again. DeepSeek Harness gives that behaviour a vocabulary, which is the first step to putting a number on it. Turn, step, round Three units, precisely separated in the project glossary: Unit Definition Cost meaning Step One model request plus the tool executions it produces The billing atom Turn One drain of input, ending when the model stops or policy intervenes The user-facing unit Round An outer policy iteration, such as a goal round or a fresh-agent attempt The multiplier above turns Rounds are the layer that most homegrown cost models omit entirely. If your forecast counts requests, and your system runs rounds, your forecast is measuring the wrong thing. Goals are durable objectives A goal is a durable completion objective with an explicit phase — active, paused, blocked, or complete. Unlike a message, it persists across turns, so the agent carries a standing objective. Each continuation cycle admitted for that goal is a goal round, materialised as one goal-sourced turn. Admission is gated by a goal activation: a process-local permission to admit another round, which is either armed or disarmed. That single bit is the throttle on open-ended work. A standing objective plus automatic continuation is a spend authorisation with no upper bound. The documented requirement that goal creation and edits need direct human authorisation is precisely why: someone has to own the budget for open-ended work. The Ralph loop is deliberate restart The Ralph loop is a foreground workflow that iterates toward an immutable objective by starting fresh agent sessions, built on the harness's workflow and subagent primitives. A Ralph round is one fresh child session with no parent conversation seed. Continuity is carried by a Ralph handoff — described as a normalised, bounded, structured report containing status, summary, evidence, and blockers. The economics here are genuinely interesting, and they cut both ways. Restarting clean means each round pays a small input cost instead of dragging an ever-growing conversation forward, so per-round cost stays flat rather than climbing. But nothing about a fresh start guarantees progress, and a loop that restarts cheaply can afford to restart many more times. The bounded handoff is the control that makes the pattern viable: it is the only channel between rounds, so it caps context growth by construction. Watch two numbers — rounds per objective, and whether the handoff's blockers list is repeating. A blocker that appears in three consecutive handoffs is a loop that will not converge, and every further round is pure waste. Commands are not tools Worth separating, because it affects what you meter. A human command is a slash-prefixed instruction routed through the command plane for human-facing adapters — discovery, parsing, dispatch, cancellation, and rendering, owned by UI adapters. It is explicitly distinct from a model tool. The goal command is one of these. Practically: a human typing a slash command is not the model spending tokens. Attribute the two separately or your per-session cost will blame the wrong actor. Four controls for open-ended work A maximum round count per objective, enforced before admission rather than reviewed afterwards. A cumulative token budget spanning all rounds of one goal, not per round. Convergence detection on the handoff: repeated blockers stop the loop. Explicit human authorisation for goal creation, kept as the audit record of who authorised the spend. Related DeepSeek Harness subagents and delegation depth — the other multiplier. Where to put spend guardrails in DeepSeek Harness — where to enforce a round cap. The DeepSeek Harness session log as a cost record — where rounds become measurable. DeepSeek Harness tool scopes and restrictions — narrowing what a round can do. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is a goal in DeepSeek Harness? A goal is a durable completion objective attached to a session, with an explicit phase: active, paused, blocked, or complete. It survives across turns, so the agent has a standing objective rather than only the current message. What is a goal round? A goal round is one continuation cycle admitted for the current goal, materialised as a single goal-sourced turn. Whether another round can be admitted is controlled by a process-local goal activation that is either armed or disarmed. What is the Ralph loop? The Ralph loop is a foreground workflow that repeatedly starts fresh agent sessions against an immutable objective. Each Ralph round is a fresh child session with no parent conversation seed, and a bounded structured handoff carries status, summary, evidence, and blockers from one round to the next. Why do goal loops matter for AI cost control? Because a standing objective plus automatic continuation is an unbounded spend authorisation unless something disarms it. Goal creation and edits are documented as requiring direct human authorisation, which makes the human the budget owner for open-ended work. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Spend Guardrails in DeepSeek Harness · FinOps LLM URL: https://finopsllm.com/research/deepseek-harness-guardrails Where to put spend guardrails in DeepSeek Harness Published 16 August 2026 An agent that discovers its budget from the monthly invoice does not have a budget. It has a postmortem. The useful question about any harness is where you can stand in the loop and say no, and DeepSeek Harness answers that with two named waterfall extension points. First, the shape of the loop The harness uses a turn and step model. A step is one model request plus the tool calls it produces. A turn contains zero or more steps. The flow for a turn runs roughly: input claim, prompt assembly, agent/pre-step , LLM stream, tool execution, step completion, then turn closure. Two event streams run alongside each other. session/event carries durable replay facts — chunks, messages, tool calls, results. agent/* carries live coordination signals — status, inbox, request interception. Guardrails belong in the second; accounting belongs in the first. Interception point 1: agent/pre-step This is the checkpoint before the model request goes out. The docs state that the returned agent/pre-step decision is authoritative, and that listeners wrapping next() preserve downstream messages unless replacement is intentional. That is the property that makes it usable as a budget gate: a listener can reject a proposed step, or modify it, and the decision stands. What belongs here: Per-turn step caps. The runaway-agent failure mode is a turn that never converges. A hard step ceiling turns an unbounded bill into a bounded one. Cumulative token budgets. Sum usage from the session log so far; refuse the next step past the threshold. Model downshifting. Rewrite the step to a cheaper route once a turn has burned past a soft threshold, rather than refusing outright. Context-size limits. Prompt assembly happens before this hook, so the assembled request is visible and measurable at this point. Interception point 2: tools/pre-execute Tool execution is a three-phase pipeline. The tools/pre-execute waterfall runs first, monotonic guards run next, and only then does the tool body execute — sandboxed, with filesystem gatekeeping. Afterwards a post-execute waterfall can accept, block, replace, or add context to the result, and ToolDefinition.finalizeContent enforces content invariants synchronously. The permission layer is deliberately asymmetric. Registered monotonic guards deny or abstain, with identity protected — they never grant. If a guard denies, or if ctx.approval 's one-shot prompt is absent or unanswerable, the result is denial and the tool body is skipped. Failure closed, not open. Filesystem mutations are separately gated: only fs/write-intent or fs/edit-intent tool-fs mutations pass. Writes are not an incidental side effect of a tool running. Two properties make this pipeline trustworthy as a control point: guards can only deny, and an unanswerable approval prompt denies. Most homegrown agent policy layers fail open when the approval channel is missing, which is exactly when you needed them. What the pipeline records Three session events give you the audit trail: tool/call before execution, tool/code-dispatch for sub-calls, and tool/result as the final authoritative outcome. Sub-calls being separately recorded matters — a single model-visible tool call that fans out internally does not hide its fan-out. A practical guardrail set Control Hook Stops Max steps per turn agent/pre-step Non-converging loops Cumulative token ceiling agent/pre-step Slow-burn overspend Route downshift past threshold agent/pre-step Frontier pricing on cheap work Tool allow-list by cost class Monotonic guard Expensive tools in cheap contexts Subprocess and network denial ctx.sandbox policy Unmetered egress Write-intent gating ctx.fs seam Unreviewed mutations The caveat DeepSeek Harness is in developer preview and its own README warns of compatibility-breaking changes. These hook names and semantics are the ones documented today; treat guardrail plugins built against them as code you will revisit, and pin the version you built against. Related The DeepSeek Harness session log as a cost record — the data the guardrails read. DeepSeek Harness: what "everything is a plugin" buys you — why guards are plugins too. Agent spend guardrails — the provider-agnostic version. The true cost of coding agents — what runaway loops actually cost. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ Where can you enforce spend policy in DeepSeek Harness? Two waterfall extension points. agent/pre-step runs before a model request is issued and its returned decision is authoritative. tools/pre-execute runs before any tool body executes, ahead of the monotonic permission guards. What is a waterfall hook in DeepSeek Harness? A waterfall is an ordered chain of listeners where each must call next() to delegate downstream. Listeners that wrap next() preserve downstream messages unless replacement is intentional, so a guard can inspect, modify, or short-circuit a step. What is a monotonic guard? A monotonic guard evaluates tool permissions without modifying them: it can deny or abstain but never grant. Guards run after the tools/pre-execute waterfall, and if a guard denies or approval is unanswerable the tool body is skipped. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # DeepSeek Harness: Everything Is a Plugin · FinOps LLM URL: https://finopsllm.com/research/deepseek-harness-plugin-architecture DeepSeek Harness: what "everything is a plugin" actually buys you Published 16 August 2026 DeepSeek AI has published deepseek-harness ( dsh ), an MIT-licensed agent harness whose design slogan is that everything is a plugin. That phrase gets used loosely across the agent tooling space, so it is worth being precise about what it means here and where it changes the economics of running agents. Cordis, not a framework with hooks The harness runs on Cordis , a plugin runtime whose model is that plugins contribute services, typed events, and reversible effects to a shared context. The architecture doc is explicit that there is no privileged core: model adapters, tool registries, session logs, and the agent loop itself are all plugins. Nothing sits underneath them as an immovable engine. That matters because the usual shape of an "extensible" agent framework is a fixed core plus a hook surface. You can observe and decorate, but you cannot replace. Replacing means forking. Cordis inverts that: the pieces you would want to replace are the units of composition. Capability seams: the part that matters operationally The harness formalises this with what it calls a capability seam . A seam is a service interface with more than one implementation, and each service occupies one of three roles: Role What it does Owner The package that declares the service interface Implementation A package providing concrete behaviour (seams have several) Consumer A package calling the service, blind to which provider is live Not every service is a seam. The docs distinguish three kinds: swappable seams ( ctx.llm , ctx.subprocess ), single-owner core services ( ctx.sessions , ctx.agents ), and composition points that coordinate other services ( ctx.agentLoop ). Knowing which is which tells you where you are allowed to substitute behaviour and where you are not. The four seams with cost consequences ctx.llm — the model seam. Owned by the llm package; implementations include llm-deepseek , llm-pi-ai , and llm-replay . The agent loop consumes a provider-neutral stream service and does not know which backend is running. llm-replay is the interesting one for cost work: it lets you re-run a recorded session without paying for inference again. ctx.fs — the filesystem seam. Providers are fs-local (host filesystem), fs-sandbox (confined mutations), and fs-e2b (a remote sandboxed Linux box). The seam decouples the tools the model can see from where execution physically happens. ctx.sandbox — the execution seam. Consumers hand over argv; implementations wrap execution under policy. sandbox-local enforces on the host, sandbox-policy centralises deployment defaults. ctx.subagents — the delegation seam. Six implementations covering in-process spawning, forking, ACP bridges, Codex, Claude Code, and SDK-based agents. This is where a harness usually hardcodes an assumption; here it is a swap. Every meaningful cost lever in an agent system is a provider swap: route to a cheaper model, move execution to a cheaper sandbox, replace a subagent transport with a local one. When those are seams, the change is a config edit. When they are not, the change is a fork you now maintain. Why this is a FinOps concern, not just an architecture one The recurring failure in agent cost programmes is not that teams pick an expensive model. It is that the harness makes the expensive choice structural. Once model selection, tool execution location, and delegation transport are baked into application code, every optimisation becomes an engineering project with its own schedule and its own regression risk. Teams then defer the optimisation, and the spend compounds. A seam-based harness moves those decisions into composition. That does not make them free, but it changes them from refactors into configuration, which is the difference between a quarterly initiative and an afternoon. The caveat worth stating plainly DeepSeek Harness is in developer preview and its README says, without softening it, that there will be compatibility-breaking changes. Building production cost tooling directly against its internal interfaces right now means signing up to chase them. Evaluate it, prototype against it, but pin your versions and expect churn. Related The DeepSeek Harness session log as a cost record — where token accounting actually lives. Where to put spend guardrails in DeepSeek Harness — the two waterfall interception points. DeepSeek Harness: install, profiles, and first run — the practical setup path. The true cost of coding agents — the costs that sit outside the API bill. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is DeepSeek Harness? DeepSeek Harness (dsh) is an MIT-licensed open-source agent harness from DeepSeek AI. It is built on the Cordis plugin runtime, where model adapters, tool registries, session logs, and the agent loop are all replaceable plugins rather than a privileged core. What is a capability seam in DeepSeek Harness? A capability seam is a service interface with more than one implementation. The owner package declares the interface, provider packages implement it, and consumers call it without knowing which provider is active. ctx.llm, ctx.fs, ctx.sandbox, and ctx.subagents are all seams. Why does a plugin architecture matter for AI cost? Cost levers in an agent are provider swaps: routing to a cheaper model, moving execution to a cheaper sandbox, or replacing a subagent transport. When those are seams rather than hardcoded calls, a routing change is a config edit instead of a fork of the harness. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # The DeepSeek Harness Session Log · FinOps LLM URL: https://finopsllm.com/research/deepseek-harness-session-log The DeepSeek Harness session log as a cost record Published 16 August 2026 Most agent cost tracking is bolted on. You wrap the provider SDK, emit a span, hope nobody adds a second call path, and discover six weeks later that the subagent traffic never got instrumented. DeepSeek Harness takes a different route: the session log is the primary artefact, and token accounting rides inside it. The session is an append-only event log The docs put it directly: a Session is an append-only log of typed SessionEvent s, and it is the single source of truth for an agent's whole interaction history. Every event carries four fields: Field Meaning type Event category, a key from the extensible SessionEventMap seq Monotonic sequence number, equal to the log length at append time time Unix epoch milliseconds data Type-specific, JSON-serialisable payload Surface events carry two more: sourceEventSeqs , referencing the events they derive from, and surfaceOp , describing how the event enters the message surface. The events a cost model cares about turn/start and turn/end — open and close a turn, the latter with a TurnEndReason . A turn is the user-facing unit of work. step/start and step/end — a step is one model call plus its tool calls. This is the billing unit. assistant/message — model output, with optional TokenUsage attached. assistant/chunk — raw stream tokens, kept for replay fidelity. Usage arrives here as chunks of type usage . tool/call and tool/result — the model's tool invocation and its outcome, the latter with an optional meta payload. request/header — the full EpochHeader : config, system prompt, and tool set for the request. request/context — route metadata: provider, model, context window. That last pair is the piece most homegrown telemetry misses. request/context tells you which provider and model actually served the step, and request/header tells you what was sent. Together they let you reconstruct the cost of a step from the log alone, without trusting a separately maintained pricing lookup keyed off an assumed model. Usage travels with output The docs are careful about this: an assistant/message carries the step's usage when the adapter reported token accounting, so the model output and its accounting travel together. The reader prefers per-step assistant/chunk { type: 'usage' } records and falls back to assistant/message.usage . The practical effect is that you cannot end up with orphaned usage numbers you can no longer attribute to a step, which is the single most common defect in retrofitted agent cost tracking. Derived history, not duplicated history Message history is derived from surface events and never stored separately. The projection rules are simple: user/message becomes a user message, assistant/message becomes an assistant message with raw chunks skipped, tool/result becomes a user message carrying a tool-result block. Everything else stays log-only. For a FinOps team this is the useful property. There is one place to read, and reading it does not risk disagreeing with what the model actually saw. The governing principle of the harness is "model-visible means logged" — the session log must be able to reconstitute the run. A log complete enough to replay a session is, by construction, complete enough to cost it. What to build on top Join step/start and step/end to get step duration and count per turn. Step count per turn is your orchestration multiplier, and it is the number that surprises finance. Attach request/context to each step for the provider and model, then price the usage from the same step's assistant/chunk usage record. Count tool/call events per step. High tool-call fan-out per step is where latency and retry cost concentrate. Watch TurnEndReason distributions. Turns ending for reasons other than completion are paid-for work that produced nothing. Related DeepSeek Harness: what "everything is a plugin" buys you — the seam model underneath. Where to put spend guardrails in DeepSeek Harness — acting on what the log shows. OpenTelemetry GenAI conventions — the standard-based alternative. What is LLM cost attribution — the underlying discipline. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is a session in DeepSeek Harness? A session is an append-only log of typed SessionEvents, described in the docs as the single source of truth for an agent's whole interaction history. Message history is derived from the log rather than stored separately. Where is token usage recorded in DeepSeek Harness? Usage travels with model output. The system reads per-step assistant/chunk records of type 'usage', with assistant/message.usage as a fallback, so a step's token accounting and the text it produced stay attached to each other. What does 'model-visible means logged' mean? It is the governing principle of the harness: anything the model could see must appear in the session log, so the log can reconstitute the run. For cost work this means the log is complete by construction rather than by instrumentation discipline. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # DeepSeek Harness Subagents and Delegation · FinOps LLM URL: https://finopsllm.com/research/deepseek-harness-subagents DeepSeek Harness subagents: delegation as a cost multiplier Published 16 August 2026 The fastest way to multiply an agent bill is to let agents spawn agents. One user request becomes a tree, and the tree has no natural size. DeepSeek Harness treats delegation as a first-class subsystem with an explicit depth cap, which makes it a good place to study how the multiplier actually works. Subagents are a seam, not a built-in Delegation lives behind ctx.subagents , a capability seam rather than core agent-loop machinery. Unlike the shell executor, which permits exactly one implementation, subagent providers are registered by name and multiple can coexist. Documented transports cover in-process spawning and forking (creating ordinary agents through the parent's context), an ACP bridge for remote deployment, and Codex, Claude Code, and SDK-based implementations. That plurality is the point. Where a child runs is a deployment decision with a price attached, and here it is chosen at composition time instead of compiled in. Two delegation modes, two cost profiles Mode Shape Cost characteristic One-shot Create child, send prompt, await result, dispose Bounded, attributable to the parent turn Continuable Durable background session with a resident activation Open-ended; accrues across turns One-shot delegations resolve into a run handle with a terminal result promise. Continuable children are heavier: the continuation manager reserves identity, composes the child, and orders every turn through the child's inbox, with the provider contributing only initial creation metadata. Their activation moves through three states — running, waiting (quiescent but owning uncompleted child activations), and settled — and a message arriving with no live activation triggers a cold resume from the persisted session. Cold resumes are the line item people forget. Reconstituting a child from its session log costs input tokens proportional to that log, and a chatty continuable child gets more expensive to wake the longer it lives. Capabilities fail loud, not silent Before delegating, the service validates the requested capabilities against the chosen provider. The specification is explicit that a request needing a capability the provider lacks is rejected with a typed error rather than accepted and then ignored. Start-time capabilities cover output schemas, depth limits, tool filters, and personas, each mapping one-to-one onto a request option. This is the correct default for cost work. Silent degradation is how a tool filter meant to keep an expensive tool out of a cheap child quietly stops applying, and nobody finds out until the invoice. Depth is capped, and the cap cannot be laundered Delegation depth is persisted in the session header, with a runtime field tracking the greater value. Two rules protect it: a cold resume cannot lower depth, and a start is rejected if the derived depth exceeds the maxDepth cap or safe-integer bounds. You cannot reset the counter by restarting a child. A parent that spawns three children, each spawning three more, has turned one user request into thirteen agents. Depth caps are the difference between a fan-out you sized and a fan-out you discovered. Discovery is cheap, delivery is authoritative Two enumeration operations exist. listChildren() returns direct children from a live-preferred corpus with three-tiered acceleration — a watermark cache, then a projection checkpoint, then persistence inspection. listDescendants() walks the whole tree in pre-order, adding parent and depth positions. Both deliberately consult no agent registries, activations, or providers; message delivery remains the authoritative operation. The practical read: you can audit the delegation tree without paying to instantiate it. Results carry a stop reason A subagent result carries the output (last non-empty assistant message, or the accumulated text stream), optional structured output validated against the requested schema, and a stopReason from a merge-extensible union: completed, aborted, error, max-tokens, refusal. Anything other than completed indicates partial output, and consumers map those to error tool results. Track that distribution. A rising share of max-tokens or error stop reasons is spend that produced nothing, and it is usually the cheapest waste in the system to eliminate. What to measure Children per parent turn, and descendants per user request. Maximum observed delegation depth against your configured cap. Share of continuable children resumed cold, and the log size at resume. Stop-reason distribution across all subagent runs. Related DeepSeek Harness: what "everything is a plugin" buys you — the seam model. DeepSeek Harness goals and the Ralph loop — the other unbounded-iteration risk. Where to put spend guardrails in DeepSeek Harness — the enforcement points. The DeepSeek Harness session log as a cost record — where the numbers come from. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ How do subagents work in DeepSeek Harness? Subagents are a capability seam registered by name in ctx.subagents, with multiple providers coexisting. Two modes exist: one-shot delegations that create a child, deliver a prompt, await completion and dispose, and continuable children that persist as durable background sessions. What subagent transports does DeepSeek Harness support? Providers include in-process spawn and fork backends that create ordinary agents through the parent context, an ACP bridge for remote deployment, and Codex, Claude Code, and SDK-based implementations. How does DeepSeek Harness limit delegation depth? Delegation depth is persisted in the session header and tracked at runtime. Cold resume cannot lower depth, and a start is rejected if the derived depth exceeds the maxDepth cap or safe-integer bounds. Why does delegation depth matter for AI cost? Each level of delegation multiplies the number of model calls made per user request. A parent that spawns three children, each of which spawns three more, has turned one request into a tree of billable work. Depth caps convert an unbounded fan-out into a bounded one. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # DeepSeek Harness Tool Scopes and Restrictions · FinOps LLM URL: https://finopsllm.com/research/deepseek-harness-tool-scopes DeepSeek Harness tool scopes: a narrower surface is a cheaper one Published 16 August 2026 Tool catalogues grow. Someone adds a browser tool, someone adds a database tool, someone adds five terminal operations, and a year later every agent in the system is offered forty tools whether it needs them or not. That is usually discussed as a safety problem. It is also a line item. DeepSeek Harness has a per-agent scoping model that addresses both at once. Why the catalogue is a recurring cost Tool definitions are part of the request. The harness records a request header event carrying the configuration, system prompt, and tool set exactly as sent, which makes the point concrete: the catalogue is re-transmitted on every model request in the session, so it is a fixed tax per step rather than a one-time cost. There is a second, larger effect. A wide catalogue widens the model's choice space. More plausible-but-wrong tool selections mean more steps that produce nothing useful, and steps are the billing unit. Trimming the surface reduces the token floor and the error rate together. The vocabulary Term Meaning Scope The unit of per-agent registration for tools, prompts, variables, restrictions, and listeners Scope key The opaque identity a scope is keyed by, compared by object identity — usually the live agent itself Agent context The agent's own scoped context, where registrations are lifetime-bound and scope-visible Restriction A filter over the global tool set for one scope, applied by intersection Shadowing A scoped item replacing a same-named global counterpart, within that scope alone Setup window The creation slot where a creator composes an agent's scoped world, before publication or first prompt assembly How composition resolves Restrictions filter the global set first, then scope-local registrations merge in. That ordering is what makes least privilege practical: you start from an intersection with the global catalogue — never more than global — and then add exactly the agent-specific tools this agent needs. Shadowing gives you the substitution case without a fork. One agent can receive a different implementation behind a familiar tool name — a read-only variant, a metered variant, a cheaper backend — while every other agent continues to see the global one. Lifetime binding matters for the same reason dispose does. Scoped registrations end with the agent's context, so a short-lived child cannot leak contributions into the parent's world. The composition all happens in the setup window, before the agent is published or assembles its first prompt. Privilege decisions made after the first prompt are not privilege decisions; they are cleanup. Scoped dispatch and lineage Events about one agent dispatch with that agent's carrier, so a listener can tell whose activity it is observing; registry-level events remain unfiltered. Separately, lineage — parent session, delegation depth, subagent depth — is described explicitly as data that does not itself affect visibility. That separation is worth borrowing. A child does not inherit access because it is a child; access is composed deliberately in its setup window. Inherited-by-default privilege is how a cheap summarisation subagent ends up holding the same expensive tool set as its parent. Four things to do with this Count your tool definitions and multiply by steps per session. That is your fixed per-session tool tax in tokens. Define a minimum viable tool set per agent role, and apply it as a restriction rather than a convention. Shadow expensive tools with cheap or read-only variants in low-value contexts instead of removing them entirely. Never inherit the parent's tool set into subagents by default. Compose it. Related Where to put spend guardrails in DeepSeek Harness — enforcement at execution time. DeepSeek Harness subagents and delegation depth — tool filters at delegation time. DeepSeek Harness: what "everything is a plugin" buys you — where tools come from. DeepSeek Harness goals and the Ralph loop — bounding open-ended work. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is a scope in DeepSeek Harness? A scope is the unit of per-agent registration for contributions such as tools, prompts, variables, restrictions, and listeners. A contribution is either global or scoped to a single agent, and scoped registrations are lifetime-bound to that agent's context. What is a restriction? A restriction filters the global tool set for one scope by intersection. Scope-local registrations then merge in after filtering, so an agent can be given a narrow slice of the global tools plus its own additions. What is shadowing in an agent harness? Shadowing means a scoped item replaces a same-named global counterpart within that scope alone. Other agents continue to see the global version, so one agent can be given a different implementation of a named tool without affecting anyone else. Why does the tool surface affect AI cost? Every tool definition sits in the system prompt and is re-sent on every model request in the session. A large tool catalogue is a fixed per-step token tax, and it also widens the model's choice space, which raises the chance of an expensive wrong call. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Enterprise AI Procurement and Committed Spend · FinOps LLM URL: https://finopsllm.com/research/enterprise-ai-procurement-committed-spend Enterprise AI procurement and committed spend Updated September 27, 2026 · first published September 27, 2026 On 25 September 2026 a report based on classified estimates put one US agency's spending on AI model testing in the billions, drawing 176 points and 106 comments on Hacker News. Whatever the exact figure, the direction is the point: AI model spend has moved from a line item to a procurement category, and the mechanics that govern a $50K monthly bill do not govern a nine-figure one. What changes at procurement scale Published rate cards become negotiable. At low volume you take the list price. At high volume the provider has a cost to serve and a relationship to protect. Committed-use discounts replace spot pricing. A committed spend agreement trades flexibility for a lower rate. Useful only if you know the floor. Rate-limit and throughput guarantees get contractual. Best-effort priority becomes a term. This matters more than price for agent workloads. Support tier and escalation paths are bought, not assumed. A Sev-1 with an engineer on call is an operational dependency, not an expense. Data terms get reviewed by legal. Retention, training opt-out, and subprocessor lists get audited. That review is on the critical path. The committed-spend trade A committed-use agreement is a bet on your own forecast. Discounts are typically 10–35% off list for a 12-month floor. The failure mode is a team that commits to a floor, then over-uses a cheaper model during the term, and ends up paying committed rates for tokens it did not need. Three controls make the bet safe: Size the floor to the workload that is genuinely steady. Batch, eval, and internal traffic forecast far better than customer-facing agent traffic. Model selection stays fungible inside the term. A commitment to spend $X with a provider is portable across that provider's models. A commitment to a specific model is not. Review at month 6, not month 12. If actual run-rate is far under the floor, renegotiate before the true-up. Rate cards and egress still decide the bill Two line items regularly surprise procurement teams who negotiated a headline rate: Cached input. Opus 5.5 charges $0.20 per million for cache reads against $4.00 fresh. On cache-heavy agent workloads the cache rate, not the headline rate, is the majority of the input cost. Negotiate the cache rate explicitly. Server-side tools are a separate invoice line. Web search, code execution, and similar server tools are billed independently of tokens. An enterprise agent built on web search can have a large non-token line item that no rate-card negotiation touched. Model choice is a second-order lever At procurement scale, the gap between a premium and a mid-tier model is often smaller than the gap between a negotiated and a list rate. And when a major lab cuts prices 40% on an afternoon, a rate card locked six months ago is suddenly the expensive option. Structure agreements so that price revisions pass through or trigger a review window. That single clause has repeatedly mattered more than the model inside the contract. Bottom line Committed spend, cache rates, egress, and pass-through clauses are the mechanics that decide a large AI bill. Model selection decides the quality. Keep those two conversations separate, and put the renewal date in the calendar before the term starts. Related Committed spend discounts Server tools are a separate invoice Azure OpenAI vs direct cost Regional pricing premium Shadow AI on corporate cards Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Eval cost allocation: who pays for LLM evals · FinOps LLM URL: https://finopsllm.com/research/eval-cost-allocation Eval cost allocation: who actually pays for LLM evals Updated 21 May 2026 · first published 21 May 2026 Eval pipelines have quietly become one of the largest unallocated cost centers in modern AI organizations. The model serving the customer gets a clean owner, a dashboard, and an on-call rotation. The eval suite that protects that model gets billed to whichever provider key happened to be in the runner config. By 2026, the cost is large enough that finance teams are forced to give it a home - but most organizations have no policy for who that home should be, how it gets split, or how it scales with release cadence. This page is about treating evals as a cost-allocation problem, not a cost-discipline problem. The distinction matters. Cost discipline asks whether you are spending too much on evals. Allocation asks who the bill goes to once you have decided the spend is justified. Without an allocation policy, eval cost is treated as platform overhead by default, which both penalizes the platform team and removes any incentive for product teams to be thoughtful about how often they trigger an expensive suite. Why eval spend resists attribution Customer-facing inference is naturally attributable. A request comes in, a header or a session carries the tenant, the team, and the surface, and the cost flows downstream with that metadata. Eval traffic does not have a customer attached. It is triggered by a CI job, a nightly schedule, or an engineer running a sweep. The token meter still ticks, but the request lacks the tags that make chargeback automatic. The result is that eval spend tends to land in a generic "platform" or "infra" bucket, where it grows quietly until a finance partner notices it has doubled. Once attribution is missing, every downstream FinOps practice - showback, budgets, anomaly attribution, unit economics - degrades for that slice of spend. Eval spend as an overhead line item The first decision is whether evals are a direct cost of a product feature or an indirect overhead of the AI platform. Both framings are defensible, and the right answer depends on how your engineering org bills internally. Direct-cost framing Under direct costing, each product team owns the evals that protect its own surfaces. The checkout assistant team pays for the checkout assistant eval. The support summarizer team pays for the summarizer regression suite. This forces product owners to think about how rich an eval they actually need, because the cost shows up on their unit economics next to the inference it guards. Overhead framing Under overhead costing, the AI platform team owns a shared eval harness and pays for it centrally. Product teams contribute datasets and graders but do not see the line item. This is easier operationally and matches how many companies fund their CI infrastructure, but it lets product teams demand exhaustive evals without trade-offs because someone else writes the check. A reasonable hybrid is to treat the eval harness, dataset hosting, and grader infrastructure as overhead, while attributing the per-run token spend back to whichever team triggered the run. The platform pays for the road; the product team pays for the gas. Separating eval costs per release cycle Most teams cannot answer the question "how much did we spend on evals for the last release?" because eval runs are not stamped with a release identifier. Closing that gap is the single highest-leverage change in eval FinOps. The mechanics are straightforward. Every eval invocation should carry tags for the release candidate, the prompt version, the model under test, the suite tier, and the triggering team. Those tags then propagate to the usage record so that aggregation can group spend by release cycle the same way it groups customer-facing spend by tenant. Once that data exists, several finance conversations become possible. You can compare eval spend per release across quarters and watch whether it is growing faster than feature velocity. You can compute an eval cost ratio - eval tokens divided by production tokens - and use it as a guardrail. You can also identify releases where eval spend ballooned because a sweep was misconfigured, which is otherwise indistinguishable from a legitimate increase in suite coverage. Product versus platform: who carries which evals Once attribution is possible, an organization can write a real policy. A workable split looks like this: Platform pays for cross-cutting safety and policy evals that apply to every model release, since those exist to protect the company rather than any one feature. Platform pays for the shared harness, dataset versioning, grader orchestration, and CI minutes - the fixed cost of having an eval system at all. Product pays for feature-specific quality and regression suites, because those are direct quality investments in a particular surface. Product pays for ad hoc sweeps, A/B comparison runs, and pre-launch deep evals, since those are decisions a product team makes for its own roadmap. Shared spend includes integration evals that cross surfaces, which can be split by share of traffic or by an agreed flat ratio. The exact split matters less than the fact that it is written down. The failure mode is not picking the wrong owner; it is leaving evals as an unowned line item that nobody defends and nobody constrains. Tiered eval runs as a resource-allocation policy Allocation only works if there are real choices to allocate against. A single monolithic eval suite gives product teams a binary choice: run it or do not. Tiering the suite gives them a portfolio. Smoke tier A small, cheap, fast-running set that fires on every prompt change and every pull request. Its cost is low enough to be charged as overhead without complaint. The platform team typically funds it, since the goal is to keep the development loop tight. Regression tier A medium-sized suite that runs on release candidates. This is the natural billing boundary between product and platform: the platform funds the infrastructure, but the team cutting the release pays for the tokens. That alignment makes teams think about whether they really need a full regression sweep for a one-line prompt fix. Deep tier An expensive, high-coverage, high-grader-quality run reserved for major model swaps, prompt rewrites, and quarterly reviews. Deep-tier runs should always be billed to the product team that requested them, with finance visibility on each invocation. The friction is intentional. Adversarial and safety tier Red-team-style evals and policy compliance runs that the platform or a central trust team funds, on the principle that they exist to protect the company rather than any one product surface. A tiered policy turns "do we run evals" into "which tier are we running, who is paying, and is this the right depth for the change we are shipping." That is the question a FinOps practice is designed to surface. Chargeback and showback for eval pipelines Showback - telling teams what their evals cost without actually moving budget - is usually the right first step. It is low-friction, gives teams a feedback loop, and produces the data you need to design a real chargeback later. Most product teams will self-correct once they see a monthly figure attached to their suites; they will switch graders, shrink gold sets, or move long sweeps to batch without any central mandate. Chargeback - actually moving budget from a central pool to a product team's ledger - is appropriate once the data is trustworthy and the tiering policy is stable. Move to chargeback for the deep tier first, since that is where the largest swings happen and where ownership creates the cleanest incentive. What to report Eval spend per release cycle, with a year-over-year trend. Eval cost ratio: eval tokens divided by production tokens, by team. Spend by tier, so leadership can see whether deep-tier usage is growing. Grader model mix and the cost share of premium graders. Batch share of eval traffic, since synchronous eval traffic is almost always a misconfiguration. Owner of each suite, including a named team and a finance approver. The reporting is not the goal. The reporting exists so that the conversation about coverage versus cost can happen with real numbers in front of the right owner. Without allocation, that conversation defaults to the platform team, which is both unfair to the platform team and unhelpful to the product teams whose decisions actually drive the bill. Related LLM cost attribution: tagging spend back to teams and surfaces LLM budget governance LLM chargeback and showback models AI FinOps: the operating practice Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ Why does eval spend resist attribution? Customer-facing inference is naturally attributable via request headers and session metadata. Eval traffic has no customer attached - it is triggered by CI jobs, nightly schedules, or engineer sweeps. Without attribution tags, eval spend lands in generic platform buckets and grows quietly until finance notices it has doubled. Should eval spending be direct cost or overhead? Direct-cost framing: each product team owns its own evals, forcing thoughtfulness about suite richness. Overhead framing: evals are platform infrastructure cost. Both framings are defensible and depend on how your engineering org bills internally. Each approach has trade-offs in incentives and accountability. How do you separate eval costs per release cycle? Most teams cannot answer how much they spent on evals for a release because runs are not stamped with release identifiers. Closing that gap is the highest-leverage change in eval FinOps. The mechanics are straightforward: tag every eval job with the release it guards, then aggregate spend per release identifier at month-end. How do product and platform split eval ownership? Once attribution is possible, an organization can write a real policy. Common approaches: product owns pre-launch evals (guardrails on quality), platform owns production monitoring and post-incident evals (guardrails on safety). The split depends on your org structure and risk tolerance. How do tiered eval runs work as a policy? Allocation works when there are real choices. A single monolithic eval suite is binary: run or skip. Tiering the suite offers a portfolio: smoke tier (fast, cheap, every commit), burn-in tier (comprehensive, expensive, pre-release), canary tier (production subset, continuous). Teams choose the tier that matches their release cadence. Should evals use showback or chargeback? Showback - telling teams what their evals cost without moving budget - is usually the right first step. It is low-friction, gives teams feedback, and produces data for designing real chargeback later. Chargeback works only when attribution is proven and the cost model is trusted. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Put cost controls inside your LLM evaluation pipeline · FinOps LLM URL: https://finopsllm.com/research/evals-cost-control Put cost controls inside your LLM evaluation pipeline Updated August 27, 2026 · first published August 27, 2026 Quick answer: LLM evaluations need their own cost policy. A CI job that runs 10,000 prompts on every change can become a larger bill than the feature it protects. Control evaluation spend with a per-run budget,... LLM evaluations need their own cost policy. A CI job that runs 10,000 prompts on every change can become a larger bill than the feature it protects. Control evaluation spend with a per-run budget, representative sampling, cached fixtures, and a quality gate that stops early when a change is clearly failing. Budget the run Set limits for prompts, candidate models, retries, and dollars before the evaluator starts. Separate pull-request smoke tests from nightly regression suites and release certification. A budget belongs to the test plan, not to a dashboard reviewed after the invoice. Sample for signal Stratify the test set by workflow, customer impact, difficulty, and known failure modes. Ten thousand near-duplicate prompts produce less information than a smaller set that covers the decision boundary. Store the sample version and estimate the confidence of the result. Cache what is stable Cache immutable fixtures, retrieved context, and reference judgments where the test does not depend on fresh generation. Track cache reads and writes as evaluation cost. A cached test is not free; it is cheaper and should still be attributable. Gate on quality and cost Stop a run when the candidate misses the quality floor or exceeds the cost ceiling. Compare cost per successful task, not just tokens per test. Persist model, prompt-set, token, retry, and outcome data so a release can be reproduced and its economics explained. Evaluation discipline is not about testing less. It is about spending on evidence that can change a release decision. Related Cost per successful task LLM cost monitoring AI spend variance analysis Related Cost per successful task LLM cost monitoring AI spend variance Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # FinOps for LLM and GenAI: A Practical Framework · FinOps LLM URL: https://finopsllm.com/research/finops-for-llm FinOps for LLM: a practical framework Updated 12 July 2026 · first published 5 May 2026 FinOps for LLMs is the practice of making AI spend visible, attributable, optimizable, and accountable. It borrows from cloud FinOps, but the cost drivers are different. A cloud bill is shaped by instances, storage, transfer, and commitments. An LLM bill is shaped by input tokens, output tokens, cache writes, cache reads, retries, model mix, context length, batch eligibility, and quality requirements. The first mistake teams make is treating LLM spend as one provider-level number. That hides the real levers. A support summarization endpoint, an agent workflow, a nightly enrichment job, and an eval suite may all use the same model, but they have different latency needs, quality thresholds, cacheability, and ownership. FinOps starts when those workloads are separated. Pillar Core question What it produces 1. Visibility What are we actually paying for, request by request? Normalized usage records split by input, output, cache-write, cache-read, batch, and retry spend 2. Attribution Which team, feature, customer, or workload caused it? Spend mapped to owners: environment, endpoint, team, tenant, model, workload class 3. Optimization Which lever lowers cost per successful task without breaking quality? Routing, caching, batching, compaction, and arbitrage changes shipped behind flags 4. Accountability Who reviews the numbers and acts on them each month? Showback (then chargeback) reports and an operating rhythm reconciled against invoices 1. Visibility Visibility means normalizing provider invoices and gateway logs into a common record. Each request should carry enough metadata to answer: who owns it, which feature generated it, which model handled it, how many token classes were billed, whether the call retried, and whether the output produced user value. Good visibility separates input, output, cache-write, cache-read, batch, and retry spend. Without this split, teams accidentally count cache-read discounts as savings, miss retry loops, and compare providers on list price rather than cost per successful task. 2. Attribution Attribution maps spend to teams, products, customers, and workloads. The point is not blame; the point is decision quality. A finance team cannot govern spend if every line item says “OpenAI.” An engineering leader cannot optimize a product surface if spend is grouped only by provider account. Minimum useful attribution usually includes environment, endpoint, team owner, customer or tenant where allowed, model, provider, and workload class. Mature programs add business metrics such as resolved ticket, completed analysis, generated report, or successful agent task. 3. Optimization Optimization should follow attribution. The common levers are model routing, semantic caching, prompt caching, context compaction, batch routing, provider arbitrage, and fallback policy tuning. Each lever changes the bill differently. Routing changes model mix. Caching changes input-token and latency economics. Batch moves work into discounted asynchronous lanes. Compaction reduces repeated context. The test is not “did token count go down?” The test is “did cost per successful task go down without breaking quality, latency, or reliability?” 4. Accountability Showback should come before chargeback. First give teams a credible monthly view of their spend and drivers. Once the numbers are trusted, chargeback can make sense for mature organizations. The goal is a repeatable operating rhythm: review the largest drivers, agree on optimization candidates, ship changes behind flags, and reconcile against the next invoice. Related What is LLM FinOps? - the operating discipline. AI FinOps - the broader practice LLM FinOps fits inside. LLM cost attribution - how the attribution layer works. LLM chargeback and showback - moving cost to owners. Chargeback vs showback - choosing the right allocation model. Showback comes before chargeback - the safe migration path. IT chargeback and showback for AI - applying allocation to AI spend. Six levers for AI cost optimization - what to optimize after attribution. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What are the four pillars of FinOps for LLMs? The four pillars are: (1) Visibility - what are we actually paying for, request by request? (2) Attribution - which team, feature, customer, or workload caused it? (3) Optimization - which lever lowers cost per successful task without breaking quality? (4) Accountability - who reviews the numbers and acts on them each month? What does visibility mean in LLM FinOps? Visibility means normalizing provider invoices and gateway logs into a common record. Each request should carry metadata to answer who owns it, which feature generated it, which model handled it, how many token classes were billed, whether the call retried, and whether the output produced user value. Good visibility separates input, output, cache-write, cache-read, batch, and retry spend. What is the purpose of attribution in LLM FinOps? Attribution maps spend to teams, products, customers, and workloads. The point is not blame but decision quality. Minimum useful attribution usually includes environment, endpoint, team owner, customer or tenant where allowed, model, provider, and workload class. What are the common optimization levers in LLM FinOps? The common levers are model routing, semantic caching, prompt caching, context compaction, batch routing, provider arbitrage, and fallback policy tuning. Each lever changes the bill differently. The test is not 'did token count go down?' but 'did cost per successful task go down without breaking quality, latency, or reliability?' Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # The first month-end close for an AI-heavy product · FinOps LLM URL: https://finopsllm.com/research/first-ai-month-end-close The first month-end close for an AI-heavy product Updated August 27, 2026 · first published August 27, 2026 Quick answer: The first AI month-end close should not begin with a dashboard screenshot. It should begin with the raw provider invoices and a locked reporting period. Close the cash number first, explain the usage... The first AI month-end close should not begin with a dashboard screenshot. It should begin with the raw provider invoices and a locked reporting period. Close the cash number first, explain the usage number second, and allocate the cost only after the two reconcile. That order prevents attractive telemetry from becoming an unauditable finance report. 1. Lock the period Choose a timezone, invoice cut-off, currency, and treatment for credits, taxes, committed-use discounts, and late adjustments. Freeze the price sheet used for the period. Record the invoice IDs and the query window for telemetry. If the period can move while people are investigating it, every later number is provisional. 2. Reconcile to the provider Join usage events to provider billing exports by provider, account, model, token type, and day. The rollup should explain input, output, cache, reasoning, image, audio, and tool-related charges where the provider exposes them. Investigate the residual instead of hiding it in an ‘unallocated’ bucket. A close can carry a documented immaterial difference; it cannot silently carry an unknown one. 3. Allocate the reconciled cost Apply stable dimensions: feature, team, environment, customer cohort, and workload. Keep shared platform cost separate from product consumption. Do not allocate by headcount simply because the gateway lacks tags; record the untagged rate and make tagging the next engineering action. Allocation is a policy choice, so version the policy alongside the data. 4. Explain the movement Bridge the current period to the prior one through rate, volume, mix, and efficiency. Link each large movement to a deployment, traffic change, provider price change, model migration, or agent behavior change. Report p50 and p95 cost per successful task with failure and retry rates. Total spend tells you what happened; the bridge tells you what to do. 5. Sign off and improve The close owner signs the provider reconciliation, the engineering owner signs the usage explanation, and the finance owner signs the allocation output. Keep an exceptions log with a deadline and owner. In the second month, automate only the steps that were stable in the first: invoice ingestion, price lookup, variance bridge, and allocation export. A trustworthy AI close is deliberately boring. Every dollar has a source, every allocation has a rule, and every variance has a person who can explain it. Related Invoice reconciliation for AI spend LLM cost attribution LLM cost monitoring Related Invoice reconciliation for AI spend LLM cost attribution LLM cost monitoring Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # FOCUS 1.5 adds AI token tracking · FinOps LLM URL: https://finopsllm.com/research/focus-1-5-ai-token-tracking FOCUS 1.5 adds AI token tracking Published 15 August 2026 FOCUS 1.5 is confirmed for December 2026 and adds two things the specification has never carried: native AI token tracking inside the Cost and Usage dataset, and a separate Price Sheet dataset for provider list pricing. Together they make token-based AI spend comparable and portable across providers, the way FOCUS already made cloud billing comparable. What is actually in it Two additions, and the second matters more than its billing gets: 1. AI model identity and token consumption in Cost and Usage The consumption record gains fields for which model served a charge and how many input and output tokens it consumed, with worked examples for token-based and generation-based billing. Today that information either does not survive the provider's export or arrives in a provider-specific shape you have to parse per vendor. After 1.5, the shape is the same everywhere. 2. A Price Sheet dataset List pricing gets its own standardized representation, separate from the consumption record. This is the quieter but more useful half. Keeping price separate from usage means you can finally compute two things directly from the data: List versus actual. The gap between the published rate and your effective rate - the number that tells you whether a commitment or a negotiated rate is earning its keep. Provider comparison without archaeology. Comparing two vendors currently means reverse-engineering an effective rate out of an invoice that blends discounts, tiers, and cached-token pricing. A price sheet in a known schema removes that step. See provider arbitrage . Why this matters more than a normal point release Token spend has been the one large technology cost with no standard billing shape. Every provider meters differently, cached and reasoning tokens price on their own scales, and the ratios move whenever a model changes underneath you. That is why the State of FinOps 2026 survey put granular AI spend monitoring - tokens, requests, GPU utilization - at the top of the most-requested capability list across all 1,192 respondents. FOCUS 1.5 does not deliver that capability, but it removes the excuse that the data is unobtainable. Once tokens are a first-class billing field, a tool that cannot report on them by model is choosing not to. What FOCUS 1.5 will not do Be clear about this before you plan around it, because the gap is where most teams get caught: It does not give you attribution. FOCUS standardizes what providers emit. Providers do not know which feature, team, or customer caused a request, because that context never leaves your infrastructure. A request made without a tag is unattributable regardless of how good the billing schema is. See cost attribution . It does not cover the unmetered layers. GPU reservations, vector stores, eval harnesses, and human review sit outside the token line. See hidden LLM costs . It does not arrive on the spec date. A December 2026 specification is not a December 2026 export. FOCUS 1.0 took well over a year to reach broad provider coverage. Plan for usable AI exports through 2027, not in Q1. It does not tell you whether the spend was worth it. That is the layer the Tokenomics Foundation was launched to define. How to be ready, using work that pays for itself now Every item below is useful before 1.5 ships and maps directly onto a 1.5 field afterwards: Do this now Why it maps cleanly Store token counts by type, never as one total Input and output are separate fields in 1.5. A single blended total cannot be split back apart. Keep model identity on every record Model identity is a first-class 1.5 field and the basis of every per-model comparison. Retain provider list prices at time of use The Price Sheet dataset is a point-in-time view. Historical list prices are not reliably recoverable later. Reconcile internal records to the invoice monthly 1.5 will make the provider's version authoritative and comparable. An unreconciled internal figure becomes visibly wrong. See invoice reconciliation . Tag at the gateway: feature, environment, team, customer The one thing FOCUS will never supply. Emit it via OpenTelemetry GenAI conventions . The wider signal FOCUS 1.5 did not arrive alone. The same window produced the Tokenomics Foundation launch on 4 August 2026, and the announcement that from 2027 FinOps X becomes Tokenomicon, a Linux Foundation conference built around the economics of AI, with FinOps X continuing as a co-located practitioner track. The flagship runs in San Diego, 7-10 June 2027, with regional events in Amsterdam and London. A specification adding token fields, a new standards body, and a conference renamed around the unit is three independent bodies agreeing on the same thing: the token is now the unit of enterprise technology spend, and the accounting is being built after the fact. Being early to the schema is cheap. Retrofitting it is not. Related LLM FinOps standards - the wider standards picture. What is the Tokenomics Foundation? - the value layer above the schema. State of FinOps 2026: 98% now manage AI spend - the capability gap 1.5 partly addresses. OpenTelemetry GenAI conventions - the telemetry side of the same problem. LLM token types explained - why one blended total is not enough. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is FOCUS 1.5? FOCUS 1.5 is the next version of the FinOps Open Cost and Usage Specification, confirmed for December 2026. It adds native AI token tracking to the Cost and Usage dataset - surfacing AI model identity and input and output token consumption - plus a new Price Sheet dataset for provider list pricing. What does the Price Sheet dataset do? It gives list pricing its own standardized representation, separate from the consumption record. That separation is what lets you compute the gap between list price and what you actually paid, and compare provider pricing without reverse-engineering it out of an invoice. Does FOCUS 1.5 solve AI cost attribution? No. FOCUS standardizes the shape of billing data coming out of providers. It cannot tell you which feature, team, or customer caused a given request, because that context never reaches the provider. Attribution still requires your own tagging at the gateway. When does FOCUS 1.5 ship and when will providers support it? The specification is confirmed for December 2026. Provider adoption follows on its own schedule - FOCUS 1.0 took well over a year to reach broad coverage across major clouds. Plan for a spec date in 2026 and usable exports through 2027. How do we prepare for FOCUS 1.5? Store token counts by type rather than a single total, keep model identity as a first-class field on every record, retain provider list prices at the time of use, and keep your internal cost records reconciled to the invoice. Each maps directly onto a 1.5 field. Is FOCUS the same as the Tokenomics Foundation? No. FOCUS standardizes billing data - the schema of what providers export. The Tokenomics Foundation, launched 4 August 2026, targets the layer above: what that spend means in business terms and what a token is worth. They are complementary and land in that order. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # A free tier is an acquisition cost · FinOps LLM URL: https://finopsllm.com/research/free-tier-is-an-acquisition-cost The free tier as customer acquisition cost Updated September 1, 2026 · first published September 1, 2026 Quick answer: Inference is not free to serve. When a provider hands you a free tier, generous rate limits during a preview, or an unbranded endpoint that costs nothing to call, that compute is paid for — by... Inference is not free to serve. When a provider hands you a free tier, generous rate limits during a preview, or an unbranded endpoint that costs nothing to call, that compute is paid for — by them, out of a budget that has a name. It is customer acquisition cost, and it behaves like every other CAC line in every other business. This is the most useful lens a finance team can apply to LLM pricing, because CAC has predictable dynamics. It is spent to win a cohort. It has a payback period. And it stops when the cohort is won. What a free tier is buying Three things, usually at once. Evaluation : engineers try the model without a procurement conversation, which is the only way to get into a stack that already has an incumbent. Data on real workloads : what people actually ask, at what shapes and lengths, which is worth more than the compute costs. A price anchor : if your engineers get used to a capability at zero, every competitor's paid rate for that capability now reads as expensive. None of those goals survive the cohort being won. That is the part teams misprice. The signal to read The generosity of a free tier tells you roughly where that provider thinks it is in the acquisition cycle. Aggressive free limits on a new model mean the lab is buying distribution and has not yet decided what the thing is worth. Free limits quietly tightening means the acquisition phase is closing and the rate card is next. Watch the shape of the tightening, not just the headline. Rate limits fall before prices rise, and context limits, concurrency, and which models are included in the free tier all move before anyone publishes a new price. How to actually use it Never let a free tier into your unit economics. If a workload only clears its margin because part of the inference is free, you do not have a margin, you have a subsidy with an expiry date you do not control. Price free usage at a shadow rate. Pick the provider's nearest paid tier, apply it to your free traffic in telemetry, and carry that number in the forecast. When the free window closes you already know the size of the hit, on the day it happens rather than at the end of the month. Measure switching cost while it is still cheap to leave. The purpose of a free tier is to make leaving expensive. Prompts get tuned to one model's quirks, evaluations get built against its outputs, tool schemas get shaped to its behaviour. Keep a second provider wired into at least one route so the answer to a price change is a config change and not a project. Related The free anonymous model is a pricing weapon Provider arbitrage LLM API pricing tracker Related The free anonymous model is a pricing weapon Provider arbitrage LLM API pricing tracker Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Gartner's 2026 AI spending forecast · FinOps LLM URL: https://finopsllm.com/research/gartner-ai-spending-2026 Gartner's 2026 AI spending forecast Published 15 August 2026 Gartner forecasts worldwide AI spending of $2.59 trillion in 2026, up 47% year over year, reaching $3.49 trillion in 2027. Enterprise AI spend - what buying organizations actually spend rather than what the industry builds - is $407 billion, up 34.8% from $302 billion. Those are two different numbers and only one of them is a benchmark you can use. Which number is which Figure 2026 What it measures Worldwide AI spending $2.59T (+47%) The whole industry, dominated by supply-side build-out. AI infrastructure $975.6B → $1.43T Servers, data centres, silicon. Over 45% of the total. Enterprise AI spend $407B (+34.8%) What buying organizations spend. The only peer-comparable line. 2027 worldwide $3.49T Direction of travel, not a planning input. The headline gets quoted in slide decks as a demand signal. Most of it is supply - capital deployed by hyperscalers and chip makers on the expectation that demand arrives. Benchmark against $407 billion. What the infrastructure share implies for your bill Over 45% of $2.59 trillion is capital equipment that has to earn a return, and it earns it through utilization. Hold that in mind whenever a plan assumes falling unit prices will lower spend. Per-token prices have fallen consistently and bills have risen anyway, because cheaper tokens make longer contexts, more retries, and more agent loops economically reasonable. An infrastructure build of this scale is a structural reason to expect pricing that rewards volume, and to expect the pattern to continue rather than reverse. This is the practical case for consumption-denominated budgets: forecast tokens per completed task and derive the dollar figure, not the other way round. See LLM cost trends 2025-2026 and why LLM bills spike . Where the money concentrates by industry Financial services leads at roughly $68 billion with 79% adoption. Healthcare follows at roughly $45 billion. The spend-plus-adoption pairing is the part worth reading closely - $68 billion at 79% adoption is broad production deployment, not a handful of large experiments. If you sit in financial services, a gap is a production gap rather than a pilot gap, and production gaps compound: the attribution, governance, and cost discipline that make the second workload cheap only get built during the first. See LLM cost benchmarks by industry . How this squares with spend being deferred Forrester expects enterprises to defer roughly a quarter of planned AI spend into 2027. Gartner forecasts 47% growth. They look contradictory and are not. The total grows because infrastructure commitments lock in years ahead and adoption is still spreading. Individual workloads get deferred because scrutiny arrived at the same time, with fewer than a third of decision-makers able to tie AI value to financial growth. Money is being redistributed inside a growing envelope. A rising market is cover for a reallocation, not protection from it. See a quarter of AI spend is slipping to 2027 . What a market forecast is good for Useful for: sector framing (is our growth rate ordinary or unusual?), timing arguments (deferring inside a 35%-growth market is a competitive decision, not a neutral one), and vendor conversations - a supplier quoting scarcity in a market growing this fast is quoting a strategy, not a constraint. See LLM purchasing guide . Not useful for: setting your own number. A market forecast contains no unit of your business. "Peers spend X% of IT budget on AI" says nothing about whether your support agent is worth $0.31 per resolved ticket - and budgeting off a peer percentage produces a defensible-looking figure with no defensible unit under it, which is precisely the profile that gets cut in a deferral review. The three lines that matter more than the forecast Your own growth rate against $407 billion at 34.8%. A unit economic for one workflow, at full cost, with a counterfactual. See AI value management . Your consumption trajectory in tokens, not dollars. See token budget implementation . The forecast says the room is getting bigger. It does not say whether you are spending well in it, and only the second question gets asked in a budget review. Related A quarter of AI spend is slipping to 2027 - the counterweight to the growth number. LLM cost trends 2025-2026 - why falling prices raise bills. LLM cost benchmarks by industry - a usable comparison, unlike the market total. State of FinOps 2026: 98% now manage AI spend - the practitioner view. How to budget for AI spend - the mechanics. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ How much will be spent on AI in 2026? Gartner forecasts worldwide AI spending of $2.59 trillion in 2026, up 47% year over year, reaching $3.49 trillion in 2027. Enterprise AI spend - what buying organizations spend rather than what the industry builds - is forecast at $407 billion, up 34.8% from $302 billion in 2025. What is the difference between the $2.59T and the $407B? The $2.59 trillion is the whole industry, dominated by supply-side build-out: AI infrastructure alone runs from $975.6 billion to $1.43 trillion, over 45% of the total. The $407 billion is what buying organizations spend. Only the second is a peer benchmark. Which industries spend the most on AI? Financial services leads at roughly $68 billion with 79% adoption, ahead of healthcare at roughly $45 billion. The pairing of high spend with high adoption means broad production deployment rather than a few large experiments. What does the infrastructure share mean for consumption forecasts? Over 45% of the total is capital equipment that has to earn a return through utilization. That is a structural reason to expect pricing that rewards volume and to keep expecting bills to rise even as per-token prices fall. Budget in consumption and derive dollars from it. Is AI spending growth slowing? Not in aggregate. Gartner's 47% growth sits alongside Forrester's prediction that enterprises defer 25% of planned AI spend into 2027. Both hold: the total grows while individual workloads are reallocated toward those with demonstrated value. How should a FinOps team use a market forecast? For context and direction, not as a budget input. It is useful for showing whether your growth rate is unusual for your sector and for anchoring vendor conversations. It cannot tell you what your own AI spend should be, because it contains no unit of your business. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # GenAI cost management: controls and analytics (2026) · FinOps LLM URL: https://finopsllm.com/research/genai-cost-management GenAI cost management Updated 21 June 2026 · first published 5 May 2026 GenAI cost management is different from traditional SaaS cost control because the main cost object is not a server; it is a model call. The cost of a single user action can vary by model, context length, output length, cache state, retry behavior, and provider route. That variability is why generative AI spend resists flat budgets and needs both controls and a cost-analytics layer. The first step is to classify workloads. User-facing chat, support summarization, document extraction, evals, enrichment jobs, and agent workflows should not share one budget model. Each has a different latency requirement and quality bar. Cost controls at a glance Control What it reduces Lever Best for Model routing Cost per request Send easy requests to cheaper models, hard ones to frontier Mixed-difficulty chat & classification Prompt & semantic caching Repeated input tokens Reuse exact or near-duplicate work RAG, high-traffic prompts, retries Context pruning Input token volume Trim RAG chunks and agent memory to what's used Long-context & agent workflows Batch APIs Per-token price Trade latency for a discounted offline tier Evals, enrichment, backfills Provider benchmarking Per-token price & lock-in Compare equivalent open-weight / cheaper providers Stable, high-volume workloads Most teams find the single largest saving in routing and caching ; the rest compound on top. None of these help until you can see which workloads cost what - which is the job of the analytics layer. From cost management to cost analytics GenAI cost analytics is the measurement layer underneath the controls. Without it, a cheaper-on-paper change can quietly raise total cost and you won't notice until the invoice. A generative AI cost analytics platform attributes spend three ways: Per workload - chat vs. extraction vs. agents, each with its own budget and trend. Per team / feature - chargeback and showback so the team that spends owns the number. Per successful task - the unit metric that survives model and price changes. The output of analytics is not a dashboard for its own sake; it is the per-unit number product teams check before shipping a design choice, not after the bill arrives. A strategic approach to generative AI cost management Strategic generative AI cost management ties spend to unit economics rather than chasing the cheapest model. In practice that means: Classify every workload by its quality and latency bar, and set a target cost per successful task for each. Put governance and budgets around the workloads that run unattended - agents and batch jobs - where cost can run away silently. Review the cost of a design choice at the moment it is made, using the analytics layer, not at invoice reconciliation. Treat provider and model selection as a portfolio decision, not a one-time pick - prices and capabilities move quarterly. What to avoid Do not optimize only for cheapest model. A cheaper model that retries, escalates, or produces lower-quality output can raise total cost. The metric should be cost per successful task under agreed quality and latency constraints. Good GenAI cost management makes product teams faster because they can see the cost of design choices before the invoice arrives. Common questions What is GenAI cost management? It's the practice of controlling the cost of generative AI workloads, where the main cost object is a model call rather than a server. It combines engineering controls - routing, caching, context pruning, batch APIs, provider selection - with a cost-analytics layer that makes spend visible per workload, per team, and per successful task. What is GenAI cost analytics, and how is it different from cost management? Cost analytics is the measurement layer: attributing model spend to teams, features, and individual requests, and reporting cost per successful task over time. Cost management is the broader discipline that also includes the controls you apply once analytics shows where the money goes. What does a strategic approach to generative AI cost management look like? It ties spend to unit economics rather than the cheapest model - classifying workloads by quality and latency bar, setting a target cost per successful task, governing agent and batch workloads, and reviewing the cost of design choices when they're made. What are the highest-leverage GenAI cost controls? Model routing, prompt and semantic caching, context pruning, batch APIs, and provider benchmarking. Most teams find the largest single saving in routing and caching. Related AI cost optimization - comprehensive optimization strategies. Model routing - matching requests to cost-optimal models. Provider arbitrage - comparing and selecting providers. LLM cost dashboard - the analytics layer in practice. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is GenAI cost management? GenAI cost management is the practice of controlling the cost of generative AI workloads, where the main cost object is a model call rather than a server. It combines engineering controls (model routing, caching, context pruning, batch APIs, provider selection) with a cost-analytics layer that makes spend visible per workload, per team, and per successful task. What is GenAI cost analytics, and how is it different from cost management? GenAI cost analytics is the measurement layer: attributing model spend to teams, features, and individual requests, and reporting cost per successful task over time. Cost management is the broader discipline that also includes the controls you apply once analytics shows where the money goes. A generative AI cost analytics platform turns raw provider invoices and token logs into per-unit numbers product teams can act on before the next bill. What does a strategic approach to generative AI cost management look like? Strategic generative AI cost management ties spend to unit economics rather than chasing the cheapest model. It means classifying workloads by quality and latency bar, setting a target cost per successful task for each, putting governance and budgets around agent and batch workloads, and reviewing the cost of design choices at the point they are made - not at invoice time. What are the highest-leverage GenAI cost controls? The highest-leverage controls are model routing for easy versus hard requests, prompt and semantic caching for repeated work, context pruning for RAG and agent memory, batch APIs for evals and offline jobs, and provider benchmarking against equivalent open-weight models. Most teams find the largest single saving in routing and caching. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # GPT-5.6 Pricing Tier Guide: Luna, Terra, Sol · FinOps LLM URL: https://finopsllm.com/research/gpt-5-6-pricing-tier-guide GPT-5.6 Pricing Tier Guide: Luna, Terra, Sol Published 19 July 2026 OpenAI released GPT-5.6 on July 10 with three distinct pricing tiers: Luna at $1/$6 per 1M tokens, Terra at $2.50/$15, and Sol at $5/$30. This is not a simple speed/quality tradeoff; each tier is positioned for a different class of workload. The question isn't "which is best" — it's "which is right for this task?" This guide maps tasks to tiers, walks through cost-per-task examples, and shows you how to cascade intelligently when a cheaper tier isn't confident enough. Luna ($1/$6): classification, simple extraction, high-volume routing Terra ($2.50/$15): balanced reasoning, agent loops, multi-turn conversations Sol ($5/$30): frontier reasoning, code generation, hard research Cache reads save 90%; cache writes cost 1.25× input — break-even at 5+ hits in 30 min Batch API adds 50% discount on top of tier pricing for non-interactive work Critical caveat: OpenAI positions Terra and Sol as having equivalent reasoning capability, differing primarily in speed and throughput. Benchmark both against your actual workload — claim of parity doesn't always hold at your data distribution. See GPT-5 vs alternatives for comparison with Claude and DeepSeek. 1. The Three Tiers: Speed, Cost, and Capability Tier Input $/1M Output $/1M Cached Read $/1M Context Typical Latency Luna $1.00 $6.00 $0.10 128K 80–200 ms Terra $2.50 $15.00 $0.25 128K 150–400 ms Sol $5.00 $30.00 $0.50 128K 300–800 ms Latency matters: Luna is fastest because it is optimized for streaming, real-time classification, and throughput. Sol is slowest because it performs more internal reasoning. For interactive user-facing workloads, Luna is also cheaper and faster — but only if it's capable enough for your task. This is the key routing decision. 2. Task-Type Routing Table This table maps common LLM tasks to the tier that minimizes cost-per-successful-response: Task Type Example Recommended Tier Success Rate at Tier Est. Cost/1K Tasks Classification Spam / not-spam; sentiment (pos/neg/neutral) Luna 95–98% $1.20–$1.50 Structured extraction Pull name, email, phone from text Luna 92–96% $1.80–$2.40 Categorization (many classes) Assign one of 50+ product categories Luna 88–94% $2.40–$3.20 Summarization Condense article or chat log Luna 92–97% $1.50–$2.00 Agent loops (tool use) Multi-turn: search, reason, refine Terra 85–92% $8.00–$12.00 Multi-turn conversation Customer support, advisory bots Terra 88–94% $6.00–$10.00 Code generation (simple) SQL query, Bash snippet, regex Terra 80–90% $10.00–$15.00 Code generation (complex) Full endpoint, state machine, DSL compiler Sol 75–88% $25.00–$40.00 Research + synthesis Analyze 10+ papers, synthesize consensus Sol 80–90% $30.00–$50.00 Hard reasoning (novel problem) Proof verification, novel algorithm design Sol 70–85% $40.00–$70.00 Key insight: Cost per task is not just API cost — it is (API cost) / (success rate). A Luna classification with 95% success costs ~$1.26 per successful response. If you route the same task to Sol at 98% success, you pay ~$5.10 per response — but you've solved 3% more of your workload, which may or may not be worth the 4× cost. 3. Cost-Per-Task Worked Examples Example 1: Spam Classification (Luna) Task: Classify email as spam (binary yes/no). Typical token profile: 400 input (email) + 50 output (classification + confidence) = 450 tokens. Luna cost: (400 × $1/1M) + (50 × $6/1M) = $0.00043/request. If 96% succeed first attempt: $0.00043 / 0.96 = $0.00045 per successful classification. At 1M emails/month: $450/month (plus cache discount if you reuse system prompts). If wrongly routed to Sol: (400 × $5 + 50 × $30) / 1M = $0.0025 per request. At 98% success: $0.00255/successful = $2,550/month (5.7× more). Example 2: Customer Support Agent (Terra) Task: Multi-turn support conversation with tool use (ticket lookup, policy search, escalation decision). Typical token profile per turn: 2,000 input (context + history) + 400 output (response + tool calls) = 2,400 tokens. Average 3 turns to resolve = 7,200 tokens total per ticket. Terra cost: (2,000 × $2.50/1M) + (400 × $15/1M) = $0.0080/turn or $0.0240 per ticket. If 90% resolved without escalation: $0.0240 / 0.90 = $0.0267 per successful ticket. At 10K tickets/month: $267/month. If used Luna instead: (2,000 × $1 + 400 × $6) / 1M = $0.0044 per turn = $0.0132/ticket. But Luna's agent loop success drops to 65% (tool calls misfire, reasoning is shallow). Cost per successful: $0.0132 / 0.65 = $0.0203. Net savings: $29/month, but 25% of tickets still fail and escalate, raising support cost $400+. Luna doesn't work here. Example 3: Code Generation (Terra vs Sol) Task: Generate a Python function from a requirement string. Typical token profile: 1,500 input (spec + examples) + 600 output (code + explanation) = 2,100 tokens. Terra cost: (1,500 × $2.50 + 600 × $15) / 1M = $0.0134 per request. At 85% first-pass success (code compiles + passes basic tests): $0.0158 per working function. Sol cost: (1,500 × $5 + 600 × $30) / 1M = $0.0255 per request. At 90% first-pass success: $0.0283 per working function. Savings with Terra: 44% cheaper per working result. Use Sol only if the 5% difference in success rate and code quality measurably reduces downstream debugging cost. 4. Cascade & Fallback Routing Pattern Most FinOps teams shouldn't use a single tier for all work. Instead, implement a cascade pattern: start with the cheapest tier, measure confidence, escalate on low confidence. Step Model Confidence Threshold Action if Threshold Not Met 1 Luna Confidence > 85% Return result 2 Terra Confidence > 75% Return result (escalated) 3 Sol Confidence > 60% Return result or fail explicitly 4 Human review — Escalate to human Real scenario: You're doing document classification for invoices (classify by vendor). Luna will return high-confidence results (~94% success) and cost ~$1.20 per 1K. For the 6% of ambiguous invoices where Luna returns confidence 5. Prompt Caching Economics GPT-5.6 changed caching costs: cache writes now cost 1.25× the uncached input rate (not free), and cache reads cost 10% of input. Scenario Prefix Size Write Cost Read Cost (per hit) Break-Even Hits Savings @ 10 hits/month Luna cached retrieval context 100K tokens $0.125 $0.010 15 hits -$0.025 (loss) Luna cached system prompt + docs 50K tokens $0.063 $0.005 8 hits $0.032 Terra cached agent context 80K tokens $0.250 $0.020 14 hits $0.030 Sol cached reasoning context 100K tokens $0.625 $0.050 13 hits $0.025 When to cache: If your prompt includes a stable prefix (system instructions, documentation, few-shot examples) that is reused more than 5–10 times in a 30-minute window, caching usually saves money. Batch API (50% discount) now competes with caching on cost — if you batch classify documents, batch discount beats caching overhead. 6. Comparison with Claude Sonnet 5, Gemini 3.1 Pro, and DeepSeek V4 Model Input $/1M Output $/1M Speed Reasoning Capability When to Pick GPT-5.6 Luna $1.00 $6.00 Fast Instruction following, routing Classification, extraction, throughput GPT-5.6 Terra $2.50 $15.00 Medium Moderate reasoning, tool use Agents, multi-turn, medium code GPT-5.6 Sol $5.00 $30.00 Slow Frontier reasoning, research Complex code, hard reasoning, novel problems Claude Sonnet 5 $2.00–$3.00 $10.00–$15.00 Medium–Fast Strong reasoning, long reasoning tokens Reasoning, coding (competitive with Sol) Gemini 3.1 Pro $2.00 $12.00 Medium Multimodal, research capability Multimodal tasks, competitive with Terra DeepSeek V4 Flash $0.14 $0.28 Very Fast Basic reasoning, cached input focus High-volume routing, cache-heavy workloads (7–35× cheaper) Cost arbitrage: For simple classification and extraction, DeepSeek V4 Flash is 7–20× cheaper than Luna. Benchmark it against your data — if it hits 90%+ accuracy, use it and pocket the difference. Claude Sonnet 5 is 2× more expensive than Terra but delivers stronger reasoning per model capability claim; use it if your Terra benchmark shows insufficient quality. Gemini 3.1 Pro lands between Luna and Terra — useful if you need multimodal input or are already in the Vertex AI ecosystem. 7. Migration from GPT-5/5.5 & Deprecation Status OpenAI continues to offer GPT-5.5 ($5/$30, same as Sol) and GPT-5.4 ($2.50/$15, same as Terra) alongside GPT-5.6. There is no deprecation pressure on older models — you can keep using GPT-5.5 if your code targets it. However, GPT-5.6 claims performance parity (or better) at the same tier, so migrate to 5.6 for new deployments. ChatGPT interface continues to retire older models on a rolling basis (GPT-4o mini, GPT-4 turbo are now read-only); API access is stable. If you build against the API, plan annual reviews of model deprecation status but don't expect urgency. Cost Measurement Framework Step 1: Establish baseline by tier Run a week of traffic and log which tier handled each request. This gives you baseline distribution and cost. Step 2: Measure confidence scores and fallback rates For each tier, log returned confidence. Calculate: what % of Luna calls have confidence > 85%? What % cascade to Terra? This tells you if your cascade is balanced. Step 3: Audit success/failure by tier Compare model output against ground truth for one week. Which tier underperforms on your data? Adjust thresholds or tier selection based on real accuracy, not OpenAI claims. Step 4: Calculate true cost per successful response True cost = (tier_cost) / (success_rate). If Luna costs $1.20 per 1K with 94% success, cost per working response is $1.28. This is the metric to optimize. Quick Tier Selection Checklist Is this a classification, extraction, or routing task? → Luna unless accuracy is critical. Does the task involve tool use or multi-turn reasoning? → Terra. Is this novel reasoning, complex code, or multi-hop analysis? → Sol (or benchmark Claude Sonnet 5 first). Can you implement a cascade (Luna → Terra → Sol)? → Yes, this is usually optimal. Is there a stable prefix (system prompt, docs) reused 10+ times/month? → Cache it, measure ROI at break-even (5–15 hits). Is this batch or interactive? → Batch work qualifies for 50% discount; recalculate ROI with batch API. Have you benchmarked alternatives (Claude, DeepSeek, Gemini)? → Do it on your data, not marketing claims. Tier selection is a classification problem: match workload properties to tier economics. The ideal is cascade routing — route to Luna first, measure confidence, escalate on uncertainty. This minimizes cost while maintaining quality. FinOps LLM can run a cost audit on your LLM traffic and show you where tier mismatch is leaving money on the table. Book a free audit . See also: How Much Does GPT-5 Cost? for the full GPT pricing landscape and Hidden LLM Costs for infrastructure and fallback overhead beyond per-token fees. Back to research FAQ Which GPT-5.6 tier should I use for classification tasks? Luna ($1/$6 per 1M) is the right choice for classification and simple extraction. At 600 tokens input + 100 tokens output, Luna costs $0.00066/request vs Terra's $0.00175/request. If accuracy is not your bottleneck, Luna delivers equivalent results at 62% savings. When does Terra ($2.50/$15) beat Sol ($5/$30) on cost? Always. Terra is positioned as a performance/cost sweet spot: same capability claims as Sol but at exactly half price. Use Terra for agent loops, multi-turn conversations, and moderate-reasoning tasks. Only use Sol when Terra's reasoning depth is provably insufficient. What is the cost impact of prompt caching on GPT-5.6? Cache writes cost 1.25× input (e.g., $1.25 per million for Luna). Cache reads cost 10% of input ($0.10 per million for Luna). If a 100K-token prefix is reused 5+ times in 30 minutes, caching saves 60%+ vs repeated uncached calls. How does GPT-5.6 compare to Claude Sonnet 5 and DeepSeek V4? Luna ($1/$6) undercuts Claude Sonnet ($2/$10 intro, $3/$15 Sept 1) by 50–60% and DeepSeek V4 Flash ($0.14/$0.28) is 7–20× cheaper than Luna. For reasoning workloads, Sol ($5/$30) and Claude Sonnet trade performance-per-dollar differently; benchmark your use case. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # GPT-5 Pricing and Budget Impact: A 2026 Planning Guide · FinOps LLM URL: https://finopsllm.com/research/gpt-5-pricing-budget-impact GPT-5 pricing and budget impact Updated 1 August 2026 GPT-5 is OpenAI's most capable model family, but capability comes at a price. Budgeting for GPT-5 is not as simple as multiplying token volume by a rate card. The effective cost depends on workload type, reasoning depth, cache efficiency, and how often the model retries. This guide walks through realistic 2026 budgets for three common workloads. GPT-5 API pricing at a glance Model Input $/1M Output $/1M Cache read $/1M Best for GPT-5.6 Luna $1.00 $6.00 $0.10 Classification, routing, extraction GPT-5.6 Terra $2.50 $15.00 $0.25 Agents, multi-turn, moderate reasoning GPT-5.6 Sol $5.00 $30.00 $0.50 Complex code, research, hard reasoning GPT-5.5 $5.00 $30.00 $0.50 Frontier reasoning, legacy targeting These are API rates. ChatGPT subscriptions are a different economic model and suit individuals or small teams, not production applications. Budget scenario 1: customer support bot A support bot resolves tickets with multi-turn conversations and occasional tool use. We assume Terra is the right tier because the task requires reasoning but not frontier coding. 10,000 tickets per month 2,000 input tokens and 400 output tokens per turn Average 3 turns per ticket 90% resolution rate without escalation Cost per ticket: (2,000 × $2.50 + 400 × $15.00) / 1,000,000 × 3 = $0.024 Cost per resolved ticket: $0.024 / 0.90 = $0.0267 Monthly budget: 10,000 × $0.0267 = $267 If the same workload runs on Sol, the monthly cost jumps to roughly $534, with only marginal improvement on routine tickets. Routing simple tickets to Luna could cut the bill to under $120. Budget scenario 2: coding assistant A development team uses GPT-5 for code generation and review. Sol is appropriate for complex functions; Terra may suffice for simpler snippets. 600 functions generated per day, 22 working days per month 1,500 input tokens and 600 output tokens per function Sol success rate: 88% first pass Terra success rate: 75% first pass Sol cost per function: (1,500 × $5.00 + 600 × $30.00) / 1,000,000 = $0.0255 Sol cost per working function: $0.0255 / 0.88 = $0.0290 Monthly Sol budget: 600 × 22 × $0.0290 = $6,108 Terra cost per function: (1,500 × $2.50 + 600 × $15.00) / 1,000,000 = $0.0135 Terra cost per working function: $0.0135 / 0.75 = $0.0180 Monthly Terra budget: 600 × 22 × $0.0180 = $3,564 The cheaper tier saves $2,544 per month, but the 13-point drop in first-pass success may increase downstream engineering time. The right choice depends on how much debugging costs. Budget scenario 3: research and synthesis A research team uses GPT-5 Sol to analyze documents, synthesize findings, and generate reports. This workload is dominated by long context and reasoning tokens. 500 research queries per month 50,000 input tokens per query, including context 5,000 output tokens per query, including reasoning Cost per query: (50,000 × $5.00 + 5,000 × $30.00) / 1,000,000 = $0.40 Monthly budget: 500 × $0.40 = $200 This looks modest, but if the team moves from 500 to 5,000 queries per month, the budget becomes $2,000. Cache reads can help, but only if the same context is reused multiple times. Hidden costs that blow up GPT-5 budgets Reasoning tokens. Billed as output, these can multiply effective output volume by 2–5x on hard problems. Cache misses. A stable prefix must be reused within 30 minutes; otherwise you pay full input price again. Retry loops. Failed or ambiguous prompts still consume tokens. A brittle parser can double effective cost. Tool calls. Each tool invocation sends and receives tokens. Multi-tool agents compound quickly. Evaluation spend. Development and benchmarking can exceed production spend if not tracked separately. How to build a GPT-5 budget that survives reality Start with a workload model. Estimate requests per month, tokens per request, and success rate by tier. Add a 30–50% contingency. Reasoning tokens, retries, and growth will consume it. Track cost per successful task. Divide total spend by completed, validated outcomes, not raw requests. Benchmark alternatives. Claude Sonnet, Gemini, and DeepSeek may deliver similar quality at lower cost for some tasks. Review monthly. Model pricing and capability change fast. A budget set in January will be wrong by June. The headline GPT-5 rate is only the starting point. The budget that matters is cost per successful outcome, and that number depends on how well you route, cache, and guardrail the workload. Related GPT-5 vs GPT-4o cost comparison — when the upgrade pays for itself. How much does GPT-5 cost? — full pricing breakdown. GPT-5.6 pricing tier guide — Luna, Terra, and Sol routing. Model routing — sending requests to the right cost tier. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ How much should I budget for GPT-5 per month? Monthly GPT-5 budget depends on use case. A support bot handling 10K tickets per month on Terra costs roughly $267. A coding assistant generating 600 functions per day on Sol can exceed $6,000 per month. Reasoning and research workloads scale fastest. What hidden costs increase GPT-5 spend? Hidden GPT-5 costs include reasoning tokens billed at output rates, cache misses, retry loops, tool-call tokens, and evaluation spend during development. These can multiply the sticker price by 2–5x. Is GPT-5 more expensive than GPT-4o? Yes. GPT-5 input and output rates are roughly 2–3x higher than GPT-4o. However, GPT-5 may reduce total cost on complex tasks by succeeding in a single pass where GPT-4o needs multiple retries. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # GPT-5 vs GPT-4o Cost Comparison: When to Upgrade · FinOps LLM URL: https://finopsllm.com/research/gpt-5-vs-gpt-4o-cost-comparison GPT-5 vs GPT-4o cost comparison Updated 1 August 2026 GPT-5 is more expensive than GPT-4o at the rate-card level. The question is whether it is more expensive at the outcome level. On simple tasks, GPT-4o usually wins. On complex tasks, GPT-5's higher success rate can make it cheaper per successful result. The right comparison is not price per token; it is cost per completed task. Rate card comparison Model Input $/1M Output $/1M Cache read $/1M GPT-4o $2.50 $10.00 $1.25 GPT-4o mini $0.15 $0.60 $0.075 GPT-5.6 Luna $1.00 $6.00 $0.10 GPT-5.6 Terra $2.50 $15.00 $0.25 GPT-5.6 Sol $5.00 $30.00 $0.50 At first glance, GPT-5.6 Sol is 2x more expensive than GPT-4o on input and 3x on output. But the rate card does not tell the whole story. Cost per successful task: the fair metric Imagine a coding task with 1,500 input tokens and 600 output tokens. We compare GPT-4o and GPT-5.6 Sol, including the retries needed to get working code. Model Cost per call First-pass success Cost per working function GPT-4o $0.00975 65% $0.0150 GPT-5.6 Terra $0.0135 80% $0.0169 GPT-5.6 Sol $0.0255 88% $0.0290 On this task, GPT-4o is cheaper per working function than Sol. Terra sits in the middle. But this changes as task complexity increases. When GPT-5 becomes cheaper than GPT-4o GPT-5 pulls ahead when complexity raises the retry gap. Consider a multi-step reasoning task where GPT-4o succeeds 40% of the time and GPT-5.6 Sol succeeds 80%. GPT-4o: $0.00975 per call / 0.40 = $0.0244 per success GPT-5.6 Sol: $0.0255 per call / 0.80 = $0.0319 per success Sol is still more expensive here, but the gap narrows. If the task also requires longer reasoning tokens on GPT-4o retries, or if a failed GPT-4o result requires human intervention, GPT-5 can become the cheaper total solution. Tasks where GPT-5 typically wins on total cost: Multi-hop research and synthesis Complex code generation with strict correctness requirements Agentic workflows with tool use and planning Long-document analysis where context understanding reduces follow-up questions When GPT-4o is the clear choice GPT-4o remains the better economic choice for high-volume, low-complexity work. Good candidates include: Classification and intent routing Structured extraction from short documents Simple summarization High-volume batch processing Any task where a cheaper model can be verified automatically For these tasks, GPT-5's quality advantage is wasted. The cheaper model does the job and the savings scale directly with volume. The routing answer: use both Most production systems should not choose one model. They should route requests based on complexity. A lightweight classifier sends simple work to GPT-4o or GPT-4o mini and escalates hard work to GPT-5. This captures most of the savings of GPT-4o while keeping GPT-5 for the tasks where it earns its price. The cheapest production architecture is usually a cascade: GPT-4o mini for routing, GPT-4o for standard tasks, and GPT-5 only for tasks that genuinely need frontier reasoning. Other factors beyond token cost Latency. GPT-5 is slower. For real-time applications, the user-experience cost may outweigh token savings. Context window. Both models support long context, but GPT-5 uses it more efficiently on complex documents. Reasoning tokens. GPT-5's reasoning is billed but visible in cost tracking. GPT-4o may hide reasoning in longer outputs. Provider risk. Relying on a single model increases exposure to price changes and outages. Related GPT-5 pricing and budget impact — worked budget scenarios. How much does GPT-5 cost? — full pricing guide. GPT-5.6 pricing tier guide — Luna, Terra, Sol routing. Model routing — building a cost-effective cascade. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ Is GPT-5 more expensive than GPT-4o? Yes, GPT-5 API rates are roughly 2–3x higher than GPT-4o. However, GPT-5 can be cheaper per successful task on complex workloads because it often succeeds in one pass where GPT-4o needs retries. When should I use GPT-5 instead of GPT-4o? Use GPT-5 for multi-step reasoning, complex code generation, long-document analysis, and agentic workflows. Use GPT-4o for classification, extraction, summarization, and high-volume simple tasks. How do I compare GPT-5 and GPT-4o costs fairly? Divide total API cost by the number of successful outcomes. A cheaper model that fails more often can cost more per successful task than an expensive model that succeeds on the first try. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # GPT-6 Astra Pricing and Cost Model: $10/$50 · FinOps LLM URL: https://finopsllm.com/research/gpt-6-astra-cost-model GPT-6 Astra cost model Updated September 23, 2026 · first published September 23, 2026 GPT-6 Astra is the top model in OpenAI's GPT-6 family. It launched on 3 September 2026, three weeks before GPT-6 Sol and Luna. It costs 5× GPT-6 Sol per token, and on public benchmarks most of its effort settings cost more than a competitor that scores higher. GPT-6 Astra prices Tier Input Cached input Output Standard $10.00 $1.00 $50.00 Batch or flex $5.00 $0.50 $25.00 Fast mode $20.00 $2.00 $100.00 Long context (over 272K input) $20.00 $2.00 $75.00 Per 1M tokens, from OpenAI's pricing page . A cache write costs $12.50. Astra has a 1,050,000-token context window, 128,000 max output tokens and an April 2026 knowledge cutoff. Astra always reasons. Unlike Sol and Luna it has no none effort setting; the choices are low, medium, high, xhigh and max. Against other premium models Model Input Cached Output GPT-6 Astra $10.00 $1.00 $50.00 Claude Fable 5.1 $10.00 $0.25 $50.00 Claude Opus 5.5 $4.00 $0.20 $20.00 GPT-6 Sol $2.00 $0.20 $10.00 Astra and Claude Fable 5.1 have the same list price, but Fable 5.1 charges a quarter as much for cached input. On a cache-heavy agent that difference is most of the input bill. Cost per task at each effort level Artificial Analysis Intelligence Index (v4.3.2): Effort Index score Cost per task low 45.8 $0.82 medium 49.6 $1.54 high 50.9 $1.73 xhigh 52.4 $2.31 max 52.7 $3.26 Only Astra at low effort sits on the price-performance frontier. At 45.8 for $0.82, it fills the gap between Sol at xhigh (44.1, $0.53) and Sol at max (47.5, $1.06). It is also frugal: about 4,400 output tokens per task at low, against 27,200 at max. From medium upward, Claude Opus 5.5 beats it on both axes. Opus 5.5 at medium scores 51.2 for $1.34, higher than Astra at medium or high and cheaper than either. Opus 5.5 at high scores 53.6 for $1.82, higher than Astra at max for 44% less per task. Full cross-model numbers are in real cost per task . That is a benchmark result, not a verdict on your workload. It does mean Astra above low effort has to earn its place on your own tasks before you pay for it. What an agent step costs A step with 200K input tokens, 90% cached, and 20K output tokens costs $1.38 on Astra: 5× GPT-6 Sol ($0.276) and 2.7× Claude Opus 5.5 ($0.516). At the long-context rate the numbers climb fast: the same step at 270K input is $1.51, at 300K it is $2.64. Fast mode doubles everything Fast mode (formerly priority processing, renamed 30 July 2026) costs $20 input and $100 output per 1M tokens. Track service_tier on every request. Both "priority" and "fast" select it, so a dashboard filtering on one value will miss spend under the other. When Astra is worth it Start at low effort. It is the only setting that is cost-efficient on public benchmarks. Before raising effort, replay the same tasks on Opus 5.5 and Sol at max. Pay for Astra only where it wins on your tasks. Send offline evaluation and bulk jobs through batch at $5/$25. Keep fast mode behind an explicit allow-list. Sources: OpenAI GPT-6 Astra model page , OpenAI pricing , Artificial Analysis . Prices read 23 September 2026. Related GPT-6 pricing: Astra, Sol and Luna GPT-6 Sol cost model GPT-6 Luna cost model Claude Fable 5.1 cost model Opus 5.5 cost by effort level Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # GPT-6 Luna Pricing and Cost Model: $0.10/$0.50 · FinOps LLM URL: https://finopsllm.com/research/gpt-6-luna-cost-model GPT-6 Luna cost model Updated September 23, 2026 · first published September 23, 2026 GPT-6 Luna is the cheap model in OpenAI's GPT-6 family, released on 22 September 2026 alongside GPT-6 Sol. OpenAI aims it at high-volume work with a clear goal: summarising, extraction and quick questions. At $0.10 per 1M input tokens it is the model to route to first, and to move off only when the task proves it needs more. GPT-6 Luna prices Tier Input Cached input Output Standard $0.10 $0.01 $0.50 Batch or flex $0.05 $0.005 $0.25 Fast mode $0.20 $0.02 $1.00 Long context (over 272K input) $0.20 $0.02 $0.75 Per 1M tokens, from OpenAI's pricing page . A cache write costs $0.125. Luna has the same 1,050,000-token context window as the rest of GPT-6, a May 2026 knowledge cutoff (the newest of the three) and the full effort range from none to max . Same score as GPT-5.6 Luna, 61% cheaper per task Artificial Analysis ran both Luna generations through its Intelligence Index (v4.3.2) at max effort. Model Index score Cost per task Output speed GPT-6 Luna (max) 37 $0.07 132.2 tokens/s GPT-5.6 Luna (max) 37 $0.18 142.3 tokens/s GPT-6 Sol (low) 33.9 $0.13 — The score did not move. The cost per task fell 61%, mostly from the lower per-token price. GPT-6 Luna at max also beats GPT-6 Sol at low effort on both score and cost. If you were running Sol at low effort to save money, Luna at max is the better deal on this index. What high volume costs One million classification requests a month, each with 600 input tokens and 100 output tokens, no caching: Model Monthly cost GPT-6 Luna, batch $55 GPT-6 Luna $110 GPT-5.6 Luna $240 Claude Haiku 4.5 $1,100 GPT-6 Sol $2,200 GPT-6 Astra $11,000 Claude Haiku 4.5 costs 10× more per token and scored 15 on the same index, as a non-reasoning model. Moving the same work from Sol to Luna cuts the bill by 95%, which is why a router that sends only the hard cases to Sol is worth building. The catch: latency and verbosity The index numbers above are at max effort, and at max effort Luna is slow to start. Artificial Analysis measured 104 seconds to first token. It also used 150M output tokens across the index, against a median of 84M, which Artificial Analysis describes as somewhat verbose. That verbosity is already inside the $0.07 per task, so the cost figure holds, but the wait does not suit a user-facing chat. For interactive traffic, run Luna at none , low or the default medium and measure accuracy on your own prompts. The scores on this page are for max effort only, so accuracy at lower settings is something you have to test, not look up. Keep max effort for batch jobs, where latency does not matter and batch pricing halves the bill again. Rate limits scale further than Sol Luna starts at 500K tokens per minute on Tier 1, the same as Sol, but reaches 180M tokens per minute at Tier 5 (Sol stops at 40M), with up to 30,000 requests per minute. For bulk pipelines, that headroom matters as much as the price. How to use Luna Route by task type: extraction, classification, tagging and short summaries go to Luna by default. Send non-urgent volume through the Batch API at $0.05/$0.25. Pick effort per route: low for interactive, max for offline jobs. Escalate to GPT-6 Sol when a validator rejects Luna's output, not up front. Sources: OpenAI GPT-6 Luna model page , Artificial Analysis: GPT-6 Luna , Artificial Analysis: GPT-5.6 Luna , TechCrunch . Prices read 23 September 2026. Related GPT-6 pricing: Astra, Sol and Luna GPT-6 Sol cost model GPT-6 Astra cost model Reasoning model cost guide LLM API pricing tracker Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # GPT-6 Pricing: Astra, Sol and Luna API Costs · FinOps LLM URL: https://finopsllm.com/research/gpt-6-pricing GPT-6 pricing: Astra, Sol and Luna Updated September 23, 2026 · first published September 23, 2026 OpenAI's GPT-6 family now has three models. GPT-6 Astra launched on 3 September 2026. GPT-6 Sol and GPT-6 Luna followed on 22 September 2026, about 90 minutes after Anthropic released Claude Opus 5.5. This page lists every GPT-6 API price from OpenAI's pricing page , read on 23 September 2026, and shows where the bill actually comes from. GPT-6 API prices per 1M tokens Standard tier, prompts up to 272K input tokens. Model Input Cached input Cache write Output GPT-6 Astra $10.00 $1.00 $12.50 $50.00 GPT-6 Sol $2.00 $0.20 $2.50 $10.00 GPT-6 Luna $0.10 $0.01 $0.125 $0.50 The pattern is the same on all three: cached input is 10% of input, a cache write is 1.25× input, and output is 5× input. Astra costs 5× Sol, and Sol costs 20× Luna. GPT-6 vs GPT-5.6: what changed Tier GPT-5.6 input / output GPT-6 input / output Change Sol $4.00 / $20.00 $2.00 / $10.00 −50% on both Luna $0.20 / $1.20 $0.10 / $0.50 −50% input, −58% output Terra $2.00 / $12.00 no GPT-6 Terra — OpenAI's pricing page notes that the GPT-5.6 Sol price above is promotional and runs at least through 21 November 2026. GPT-5.6 Terra has no GPT-6 successor yet. GPT-6 Sol now costs the same as Terra on input and less on output, so Terra workloads are the first candidates to move. Batch, flex and fast mode Model Batch or flex (in / cached / out) Fast mode (in / cached / out) GPT-6 Astra $5.00 / $0.50 / $25.00 $20.00 / $2.00 / $100.00 GPT-6 Sol $1.00 / $0.10 / $5.00 $4.00 / $0.40 / $20.00 GPT-6 Luna $0.05 / $0.005 / $0.25 $0.20 / $0.02 / $1.00 Batch and flex are half price. Fast mode is double. Fast mode is the old priority processing, renamed on 30 July 2026, and both service_tier: "priority" and service_tier: "fast" still work. That rename matters for cost tracking: a dashboard filtering on the old tier name can miss fast-mode spend. Data residency endpoints add 10% for models released on or after 5 March 2026, which includes all of GPT-6. The 272K long-context price jump All three models have a 1,050,000-token context window, a 922,000-token input limit and 128,000 max output tokens. Above 272K input tokens, the whole request is billed at long-context rates: 2× input and cached input, 1.5× output. Model Long-context input Cached Output GPT-6 Astra $20.00 $2.00 $75.00 GPT-6 Sol $4.00 $0.40 $15.00 GPT-6 Luna $0.20 $0.02 $0.75 This is a step, not a slope. Take one GPT-6 Sol request with 90% of the prompt cached and 20K output tokens. At 270K input it costs $0.303. At 300K input it costs $0.528. Eleven percent more context costs 74% more. The same 74% jump applies to Astra and Luna, because the multipliers are the same. Agents that let context grow unchecked cross 272K without anyone deciding to. Trim or summarise history before that line, and alert on requests above it. Specs that affect cost Model Knowledge cutoff Reasoning effort Tier 1 limit GPT-6 Astra 30 April 2026 low, medium, high, xhigh, max 500 RPM, 500K TPM GPT-6 Sol 20 April 2026 none, low, medium (default), high, xhigh, max 500 RPM, 500K TPM GPT-6 Luna 18 May 2026 none, low, medium (default), high, xhigh, max 500 RPM, 500K TPM Astra has no none setting, so it always reasons. The effort setting moves the bill as much as the model does: on the Artificial Analysis Intelligence Index, GPT-6 Sol costs $0.13 per task at low effort and $1.06 at max. See real cost per task for every setting. What one agent step costs One step with 200K input tokens, 90% cached, and 20K output tokens, at standard list prices. Model Cost per step Per 10,000 steps GPT-6 Luna $0.014 $138 GPT-6 Sol $0.276 $2,760 Claude Opus 5.5 $0.516 $5,160 GPT-5.6 Sol $0.552 $5,520 GPT-6 Astra $1.380 $13,800 ChatGPT and Codex are billed separately GPT-6 Sol and Luna are rolling out in ChatGPT Work and Codex for Plus, Pro, Business, Enterprise and Edu users, and Free and Go users get Luna in the desktop app. Those are subscription plans. None of the prices on this page apply to them, and API usage is never covered by a ChatGPT plan. Which GPT-6 model to use GPT-6 Luna for classification, extraction, summarising and routing. See the GPT-6 Luna cost model . GPT-6 Sol as the default for coding and agents. See the GPT-6 Sol cost model . GPT-6 Astra only where a replay on your own tasks shows Sol failing. See the GPT-6 Astra cost model . Prices change. The LLM API pricing tracker reads OpenAI's pricing page live and picks up new GPT-6 models automatically. Related GPT-6 Sol cost model GPT-6 Luna cost model GPT-6 Astra cost model LLM API pricing tracker Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # GPT-6 Sol Pricing and Cost Model: $2/$10 per 1M · FinOps LLM URL: https://finopsllm.com/research/gpt-6-sol-cost-model GPT-6 Sol cost model Updated September 23, 2026 · first published September 23, 2026 OpenAI released GPT-6 Sol on 22 September 2026. OpenAI positions it as the everyday model for complex work, coding included, and says it makes about half as many mistakes as GPT-5.6 Sol. For a cost owner, the headline is simpler: it costs half as much per token as the model it replaces. GPT-6 Sol prices Tier Input Cached input Output Standard $2.00 $0.20 $10.00 Batch or flex $1.00 $0.10 $5.00 Fast mode $4.00 $0.40 $20.00 Long context (over 272K input) $4.00 $0.40 $15.00 Per 1M tokens, from OpenAI's pricing page . A cache write costs $2.50. The model has a 1,050,000-token context window, 128,000 max output tokens and an April 2026 knowledge cutoff. Against GPT-5.6 Sol and Claude Opus 5.5 Model Input Cached Output GPT-6 Sol $2.00 $0.20 $10.00 GPT-5.6 Sol $4.00 $0.40 $20.00 Claude Opus 5.5 $4.00 $0.20 $20.00 GPT-5.6 Sol's $4/$20 is itself a promotional price that OpenAI says runs at least through 21 November 2026, so the gap may widen after that. Against Opus 5.5, Sol is half the price on fresh input and output, but cached input costs the same $0.20. For an agent that re-reads a large cached context and writes little, the two models cost closer to each other than the headline prices suggest. Cost per task at each effort level Per-token price is only half the bill. The other half is how many tokens the model spends thinking. Artificial Analysis ran GPT-6 Sol through its Intelligence Index (v4.3.2) at every effort setting. Effort Index score Cost per task none 28.1 $0.33 low 33.9 $0.13 medium (default) 39.8 $0.25 high 42.8 $0.37 xhigh 44.1 $0.53 max 47.5 $1.06 Two things stand out. First, none is not the cheap setting: it scored lower than low and cost 2.5× more per task on this index. Measure on your own traffic before assuming that turning reasoning off saves money. Second, going from medium to max adds 7.7 points at 4.2× the cost. Every setting from low to max sits on the price-performance frontier, so none is wasted, but the last step (xhigh to max) doubles the cost for 3.4 points. For comparison, Claude Opus 5.5 at medium effort scores 51.2 at $1.34 per task. That is higher than any Sol setting. If your workload needs that score, Sol cannot reach it at any price. If it does not, Sol at high effort (42.8 for $0.37) costs about a quarter as much. Full numbers across models are in real cost per task . What an agent step costs A step with 200K input tokens, 90% served from cache, and 20K output tokens: GPT-6 Sol: $0.276 Claude Opus 5.5: $0.516 GPT-5.6 Sol: $0.552 Output tokens are 72% of the Sol figure ($0.20 of $0.276). Capping output length and choosing a lower effort setting move this bill more than further cache tuning. Watch the 272K line Above 272K input tokens the whole request is billed at 2× input and 1.5× output. The same step at 270K input costs $0.303. At 300K it costs $0.528, 74% more for 11% more context. A long-running Sol agent that never compacts its history will cross that line on its own. Alert on it. When to move to GPT-6 Sol From GPT-5.6 Sol: move now. Same model family, half the price, and OpenAI claims fewer mistakes. Replay a sample of real traffic first to confirm output quality on your tasks. From GPT-5.6 Terra ($2/$12): Sol costs the same on input and less on output. From Claude Opus 5.5: only for tasks where Sol's score is enough. Split traffic by task, not by vendor. To GPT-6 Luna: anything that is extraction, classification or summarising. See the GPT-6 Luna cost model . Sources: OpenAI GPT-6 Sol model page , TechCrunch , MacRumors , Artificial Analysis . Prices read 23 September 2026. Related GPT-6 pricing: Astra, Sol and Luna GPT-6 Luna cost model GPT-6 Astra cost model Claude Opus 5.5 cost model Real cost per task across frontier models Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # GPT-6 Sol Long-Context Benchmarks: What's Measured · FinOps LLM URL: https://finopsllm.com/research/gpt-6-sol-long-context-benchmarks GPT-6 Sol long-context benchmarks: what has actually been measured, and what is GPT-5.6 Sol Updated September 27, 2026 · first published September 27, 2026 Quick answer: As of 27 September 2026, GPT-6 Sol has exactly one independent long-context score: 84% on Artificial Analysis AA-LCR v1.1, tied with GPT-5.6 Sol. The test’s documents average about 100K tokens.... As of 27 September 2026, GPT-6 Sol has exactly one independent long-context score: 84% on Artificial Analysis AA-LCR v1.1, tied with GPT-5.6 Sol. The test’s documents average about 100K tokens. No one has yet published how GPT-6 Sol holds up at 256K, 512K or 1M tokens. Most “Sol” long-context numbers online, including the 91.5% MRCR score, are for GPT-5.6 Sol. GPT-6 Sol came out on 22 September. This matters for cost because long context is where GPT-6 prices jump. Above 272K input tokens the whole request is billed at long-context rates . Deciding how much context an agent keeps means weighing that price against quality data that doesn’t exist yet. What long-context scores does GPT-6 Sol have? One aggregate score, at around 100K tokens. Model AA-LCR v1.1 Rank GPT-6 Sol (max) 84.0% 7 GPT-5.6 Sol (max) 84.0% 7 GPT-6 Astra 80.7% 27 Kimi K3 (leader, 24 Sep 2026) 88.7% 1 AA-LCR has 100 hand-written questions over document sets that average 99,325 tokens. The answers have to be put together from several passages rather than found in one. It tests reasoning over a long input. It doesn’t show how accuracy changes as the input grows, because every question is about the same length. Which long-context numbers are GPT-5.6 Sol, not GPT-6 Sol? The MRCR scores. Launch coverage of GPT-6 Astra compared it with “Sol” on OpenAI’s MRCR v2 8-needle test. That Sol was GPT-5.6 Sol, and Vellum’s write-up confirms it. MRCR v2, 8-needle 256K–512K 512K–1M GPT-6 Astra 100% 96.3% GPT-5.6 Sol 91.5% 73.8% GPT-6 Sol not published OrcaRouter’s GPT-6 Sol review makes the same point: GPT-5.6 Sol has a published long-context retrieval result, and GPT-6 Sol has nothing equivalent. Where have we looked? The places that would publish it, all checked on 27 September 2026: Context Arena , the MRCR leaderboard. Its model list and 8-needle results have no GPT-6 entries. Its newest OpenAI models are GPT-5.6 Sol, Terra and Luna. OpenAI : the GPT-6 launch post and the system card appendix for Sol and Luna. Neither gives Sol results by context length. Artificial Analysis : AA-LCR only, as above. Vals, Vellum, DataCamp, emergent.sh, llm-stats and OrcaRouter : no long-context results by length for GPT-6 Sol. What should teams do until per-length data exists? Keep GPT-6 Sol requests under 272K input tokens and compact early. The evidence so far shows GPT-6 Sol matching GPT-5.6 Sol at about 100K. GPT-5.6 Sol held 91.5% up to 512K on MRCR but fell to 73.8% beyond that. It’s reasonable to expect GPT-6 Sol to be usable up to about 250K, but that is an inference, not a measurement. Above 272K you pay double for input on quality nobody has measured. In Codex this is already the default. It gives GPT-6 Sol a 272K window and compacts at 244,800 tokens . For your own agents, alert on requests that cross 272K and treat any increase as something to test. Run your own retrieval check on your own documents before relying on context beyond 256K. We will update this page when Context Arena or another independent evaluator publishes GPT-6 Sol results by context length. Sources Artificial Analysis: GPT-6 Sol vs GPT-5.6 Sol Artificial Analysis: announcing AA-LCR BenchLM: AA-LCR leaderboard Vellum: GPT-6 Astra benchmarks explained OrcaRouter: GPT-6 Sol vs GPT-5.6 Sol Context Arena: MRCR leaderboard Related Codex auto-compact on GPT-6 Sol: the real defaults GPT-6 Sol pricing and cost model GPT-6 pricing and the 272K long-context price jump Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Claude Max 20x vs Alibaba Token Pro Cost Audit · FinOps LLM URL: https://finopsllm.com/research/heavy-agentic-coding-cost-claude-vs-qwen Claude Max 20x vs Alibaba Model Studio Token Pro: What Does Heavy Agentic Coding Actually Cost? A real-usage case study of Opus 5, Qwen3.8-Max, prompt caching, model verbosity and the problem with comparing AI subscriptions by token count $200 vs $70 Monthly sub gap 4–8 Swarms Agentic concurrency 90% Cache Hit discount 0.35 Ratio Qwen task break-even Central Thesis: Comparing Claude Max with Alibaba Token Pro using advertised token prices produces the wrong answer. Claude Max is an opaque, heavily subsidized capacity subscription, while Alibaba Token Pro is a credit-metered subscription whose burn rate varies by model and workload. Because Claude and Qwen tokenize, reason, invoke tools, and retry differently, the only meaningful economic unit is the cost per accepted engineering task — not the cost per token. 1. Executive summary When autonomous developer workflows transition from simple single-turn completions to multi-agent swarms (where coordinator agents spawn 4 to 8 specialized sub-agents for refactoring, testing, and security checks), token consumption explodes. Comparing these plans purely by listed per-token rates yields misleading procurement decisions. Alibaba Token Pro ($70/mo) exposes explicit rolling limits of 12,000 credits per 5 hours and 40,000 credits per 7 days. Qwen3.8-Max-Preview benefited from a promotional credit discount during its preview phase (as low as 10% standard rate). Claude Max 20x ($200/mo) provides high burst capacity without publishing a fixed token or API-dollar quota. Real-user telemetry: Account telemetry shows Opus 5 executing 91.9% of active workload sessions while generating fewer displayed tokens than secondary models, highlighting model-specific turn efficiency. Dashboard Metric Drift: The account's Models screen (110.836M tokens) and Overview screen (20.9M tokens) exhibit a 5.30× discrepancy, demonstrating why raw dashboard metrics cannot be cross-compared. Task-Productivity Break-Even: Qwen 3.8-Max needs to achieve only 35% of Opus 5's accepted task output to be cheaper per completed feature — provided credit limits are respected. Human-Time Valuation: At $50/hour developer cost, Opus 5 needs to save only 2.6 hours per month (1.3 hours at $100/hour) to fully justify its $130 subscription premium. 2. The plans are not billing the same thing Alibaba Token Plan Personal Pro The Personal Pro plan costs $70/month and provides explicit quota caps: Limit Pro Allowance Flagship Model Target Rolling 5 hours 12,000 credits qwen3.8-max-preview Rolling 7 days 40,000 credits qwen3.8-max-preview Alibaba notes that Qwen3.8-Max-Preview usage consumed as little as 10% of standard rates during preview, with additional off-peak discounts (22:00–08:00 UTC+8). Source . Note that Token Pro is restricted to interactive coding tools and agent IDEs; non-interactive batch processing or API key sharing is strictly prohibited. Alibaba Coding Plan The $50 Coding Plan operates on a completely different metric: Limit Allowance Rolling 5 hours 6,000 model calls Weekly 45,000 model calls Monthly 90,000 model calls The Coding Plan does not include Qwen3.8-Max (its allowlist covers models like Qwen3.7-Plus). Furthermore, Alibaba explicitly warns that a single visible developer request routinely spawns 5–10 underlying calls for simple edits and 10–30+ calls for complex agent loops. Source . Claude Max 20x Claude Max 20x offers 20 times the Pro plan's per-session usage ceiling. Source . However, Anthropic does not disclose fixed token limits or API credit balances. Usage across Claude.ai web and Claude Code CLI draws from the same dynamically metered account pool. 3. The real-user case study: Telemetry audit Analyzing seven days of active telemetry from a developer account running Claude Max 20x provides concrete data on heavy usage patterns: Seven-day account overview Metric Value Sessions 32 Messages 48,513 Overview total tokens 20.9M Active days 6 Favorite model Opus 5 Model-level activity screen Model Activity Share Input Tokens Output Tokens Combined Tokens Opus 5 91.9% 0.436M 41.5M 41.936M Fable 5 6.4% 14.8M 38.3M 53.100M Haiku 4.5 1.7% 2.8M 13.0M 15.800M Total 100% 18.036M 92.8M 110.836M The dashboard exhibits a 5.30× discrepancy between the Models screen (110.836M) and the Overview screen (20.9M). This drift arises from different internal aggregation logic (e.g., prompt cache read inclusion vs raw token output). Consequently, attempting to convert dashboard token totals directly into competitor subscription costs yields erroneous conclusions. 4. Why equal-token comparisons fail Comparing models by token price assumes that one token of Model A equals one token of Model B. In heavy agentic coding, this assumption breaks down due to eight multiplier factors: Total Workload Cost = Tokenization × Turn Amplification × Tool Amplification × Reasoning Amplification × Retry Amplification Tokenizer Density: Sonnet 5 and Opus 5 tokenizers pack ~30% more code per token than legacy tokenizers. Reasoning & Thinking Tokens: Extended thinking modes generate internal reasoning traces that consume output capacity. Turn & Tool Amplification: Less capable models take more interactive turns and tool invocations to locate codebase files. Retry Amplification: If a model requires 3 corrective attempts to fix broken tests, token cost triples. Standard API rates (Qwen 3.8-Max at $2.00 input / $0.17 cached / $6.00 output vs Opus 5 at $5.00 input / $0.50 cached / $25.00 output) serve as an API shadow price floor, but do not dictate internal subscription credit burn. 5. What existing comparisons actually show Community Capacity Tracking: Independent measurement of 80 autonomous coding tasks estimated that a full Max 20x weekly limit equals ~$1,100 in API-equivalent compute value, with median tasks consuming $4–$5 in API costs. Source . Single-Prompt Tests: One-shot comparisons showed Qwen 3.8-Max matching Opus 5 quality at 10% of the single-prompt API cost ($0.0248 vs $0.2530). Source . Refactoring Iteration Tests: Real-world refactoring tests showed Qwen 3.8 requiring 2–3 feedback loops vs Opus 5 completing complex refactors on turn 1. Source . Vendor Benchmarks: Anthropic's Opus 5 benchmark reports reduced turn counts and fewer tool calls compared to previous model releases. Source . 6. The correct break-even equation Subscription Gap: C_Claude ($200) vs C_Qwen ($70) Cost per accepted task equality: $70 / A_Q = $200 / A_C Required Productivity Ratio: A_Q / A_C = 0.35 To be more cost-effective on subscription fee math, Qwen 3.8 needs to achieve only 35% of Opus 5's accepted task output . Conversely, Opus 5 must be 2.86× more productive in accepted tasks to beat Alibaba on pure subscription math. Developer-Time Break-Even Developer Hourly Valuation Monthly Time Opus Must Save to Justify $130 Delta $25 / hour 5.2 hours $50 / hour 2.6 hours $75 / hour 1.73 hours $100 / hour 1.3 hours 7. Final conclusion Alibaba Token Pro ($70/mo) is the clear winner on raw subscription price and explicit credit capacity. Its off-peak discount (0.2× multiplier) provides unmatched economy for scheduled nightly agent swarms. Claude Max 20x ($200/mo) provides high burst capacity and superior single-turn refactoring accuracy. For professional developers, saving 2.6 hours per month easily justifies the $130 delta. 8. The study's final experimental phase To move beyond static benchmarks, we define a controlled N-of-1 trial protocol: Select 15 repository engineering tickets from active production branches. Branch each test from identical Git commit HEADs with identical test suite permissions. Execute Opus 5 (via Claude Max 20x) and Qwen 3.8-Max (via Token Pro). Record task completion, retries, credit burn, Claude quota drain, and developer correction minutes. Quality-Adjusted Cost = ( Allocated Subscription Fee + Developer Correction Cost ) ÷ Accepted Tasks Related Cloud Infrastructure Cost Audit: Alibaba vs Claude Max — complete unit math and quota audit. The Token Count Is Lying — telemetry audit and metric drift breakdown. AI Coding Economics 2026 — 32M daily token workload benchmark across models. AI Coding Plan Comparison — full comparison matrix across 9 providers. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What does heavy agentic AI coding cost per month? Heavy agentic coding using multi-agent swarms costs $70/month with Alibaba Token Plan Pro (credit-metered, 40K credits/7 days) or $200/month with Claude Max 20x (flat-rate dynamic compute). Pay-as-you-go API costs for equivalent workloads range from $29/mo (DeepSeek) to $600–$1,200+/mo (Claude Opus 5). How do multi-agent swarms impact credit and token burn? When an agentic coordinator spawns 4 to 8 parallel sub-agents (e.g. for linting, testing, refactoring, and security auditing), each sub-agent re-reads the full repository context. On Alibaba Token Pro, an 8-agent swarm consumes 2,465 to 3,619 credits per batch. On Claude Max 20x, all agents draw from the shared account-level burst quota. How does prefix prompt caching benefit multi-agent agentic swarms? By maintaining a byte-for-byte stable system and repository prefix, parallel sub-agents achieve a 90% discount on context input tokens ($0.17/M explicit cache read for Qwen 3.8-Max, $0.50/M for Opus 5). Warming the prompt cache before launching sub-agents drastically lowers total credit and API burn. Which plan is better for parallel multi-agent agentic execution? Alibaba Token Pro with Qwen 3.8-Max is best for predictable credit budgeting and multi-agent context sharing during off-peak hours (0.2× credit multiplier). Claude Max 20x is best when task completion quality and first-attempt accuracy are critical, reducing manual developer intervention. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Hidden LLM Costs Beyond Per-Token Pricing · FinOps LLM URL: https://finopsllm.com/research/hidden-llm-costs Hidden LLM Costs Updated 12 July 2026 LLM spending isn't just per-token pricing. Infrastructure overhead, redundant calls, retry chains, and cache management add significant cost. Many teams track only API tokens but miss 20–50% of their true LLM spend. Learn what to measure. Hidden costs often exceed API costs by 20–50% Vector databases, embeddings, and retry logic are major contributors Cost-per-successful-response differs from cost-per-token Observability itself has a cost footprint Warning: If your LLM spend tracking only includes API tokens, you're likely blind to 30–40% of your true cost. This guide helps you find them. 1. Vector Database & Embedding Infrastructure RAG systems (Retrieval-Augmented Generation) require embedding generation, vector storage, and retrieval. This infrastructure cost is often invisible in per-token API bills. Component Typical Cost Volume (Per 1M API Calls) Monthly Impact Embedding API (per 1M tokens) $0.02–$0.13 10M tokens/month (queries + reindexing) $0.20–$1.30 Vector DB (managed SaaS) $10–$500/month 10–100GB indexed data $10–$500 Vector DB (self-hosted) $50–$300/month (infra) EC2 + storage for index $50–$300 Total RAG infrastructure — — $10–$800 (dominated by the vector DB) Real scenario: A customer support chatbot with 100K monthly queries (avg 3K tokens per query). Embedding every query plus document-chunk reindexing runs ~5M embedding tokens/month — at OpenAI's text-embedding-3-small rate of $0.02 per 1M tokens, that's $0.10/month; even text-embedding-3-large ($0.13 per 1M) stays under $1. The embedding API is not the hidden cost here — the always-on vector database is: a managed tier for this workload typically runs $50–$100/month whether or not queries flow. Total: ~$50–$100/month of infrastructure on top of your LLM API bill, almost all of it vector DB hosting. How to measure: Audit your cloud bill (AWS, GCP, Azure) for vector DB infrastructure. Add explicit embedding API costs from your provider dashboard. Sum these separately from LLM token costs. 2. Retry Chains & Fallback Models When your primary LLM fails or hits rate limits, fallback logic automatically retries or switches to a cheaper model. Each retry consumes tokens without delivering a result to the user. Scenario Primary Model Fallback Model Primary Failure Rate Cost Multiplier No fallback GPT-5.5 None 2–5% 1.0× Naive fallback GPT-5.5 Claude Sonnet 2–5% 1.08–1.20× Cascading fallback GPT-5.5 Claude Haiku, then Gemini Flash 2–5% 1.20–1.50× Broken fallback (high latency) GPT-5.5 Retries 3× before fallback 30–50% 2.0–4.0× Example calculation: Your system makes 1M API calls/month to GPT-5.5 ($5M tokens in, $30M out = $155/month). If your fallback logic retries failed calls, and 5% fail and retry once, you're now making 1.05M calls. That's a 5% cost increase ($7.75/month extra just from retries). The trap: If your fallback logic has a bug and retries aggressively on transient errors, failure rate can spike to 30–50%, multiplying your bill 2–4×. This often goes unnoticed for weeks. How to measure: Log every API call with (call_id, model, attempt_number, success, reason_if_failed). Calculate: (total_tokens_across_all_attempts) / (successful_responses). Compare to your base per-token cost. 3. Observability & Logging Overhead Tracing LLM calls (logging prompts, completions, latency) requires infrastructure: log aggregation, metrics storage, trace backends. Observability Component Typical Cost Volume Notes Logs (Datadog, Splunk, etc.) $0.50–$5 per GB ingested 100–1,000 GB/month $50–$5,000/month Tracing (OpenTelemetry backend) $100–$500/month (self-hosted) or $500–$5,000 (SaaS) 100K–10M traces/month Often tied to volume Metrics (Prometheus, etc.) $50–$200/month (self-hosted) or $200–$1,000 (SaaS) 100K–1M series Lower than logs Total observability — — $200–$10,000/month (scales with volume) Real scenario: An LLM app logging every prompt + completion to Datadog. Each LLM call generates ~2–5 KB of structured logs, so 10M API calls/month produces 20–50 GB — at an assumed $1/GB ingestion, $20–$50/month. Log the full prompt and completion text (often 10–20 KB per call) and the same traffic is 100–200 GB, or $100–$200/month, before indexing and retention fees. How to measure: Check your observability platform bill separately. If it's in your shared cloud account, segment it by cost center or tag. 4. Duplicate & Wasted Calls Inefficient prompt engineering, debug/test calls left in production, and race conditions cause wasted LLM calls that don't deliver user value. Waste Category Cause Typical Rate Monthly Cost (100K API calls) Debug logging Test calls to validate behavior, left enabled in prod 2–5% $30–$75 Race conditions Duplicate requests when user double-clicks or network retry fires 3–10% $45–$150 Cache misses (unavoidable) Prompt caching not implemented, equivalent queries run separately 10–40% $150–$600 Unused features Code paths that call LLM but users never exercise 5–20% $75–$300 Total waste — 15–50% $225–$750+ How to measure: Classify every LLM call: (user_facing / internal_debug / redundant / unused_feature). Run a week-long audit. Calculate waste rate = (debug + redundant + unused) / total_calls. 5. Cache Overhead Prompt caching (Anthropic, OpenAI) offers 80–90% discounts on cache hits, but cache writes have a 1.25–2× write cost plus storage overhead. Cache Scenario Write Cost (per 1M tokens) Hit Cost (per 1M tokens) Break-Even (# Hits) Net Savings @ 50% Hit Rate Claude Opus prompt caching $10 (2× $5/M) $0.50 (0.1× $5/M) 20–30 hits 64% savings OpenAI GPT-5.5 caching $6.25 (1.25× $5/M) $0.50 (0.1× $5/M) 10–15 hits 69% savings Cache miss (no caching impl) $5 $5 1 (baseline) 0% Storage cost: The billing models differ, and that's the trap. Anthropic charges per write (1.25× the base input price for the default 5-minute TTL) with no ongoing storage fee — caching a 100K-token PDF on Opus 4.8 costs 100K × $6.25/M ≈ $0.63 to write, then ≈$0.05 per full cached re-read (100K × $0.50/M). Google's Gemini context caching instead bills storage per token-hour on top of discounted reads, so a long retention window accrues cost even with zero hits — check current per-model storage rates before caching large contexts for days. OpenAI's automatic prompt caching applies its cached-input discount with no separate write or storage fee. How to measure: If using prompt caching, track: total_write_tokens_cached, cache_hit_rate, cache_hit_tokens. Calculate: (write_cost + (hit_tokens × hit_rate × cache_read_price)) vs. (total_tokens × non_cache_price). Most teams see 40–60% savings once hit rate exceeds 20%. 6. Multi-Model Orchestration Overhead Routing queries to different models (GPT-5.5 for reasoning, Gemini Flash for simple classification) requires routing logic, classifier overhead, and slop. Overhead Type Cost per Call Volume (1M calls) Monthly Cost Classifier model (to decide routing) $0.00007–$0.0003 (200–1K-token prompt on Gemini 2.5 Flash) 1M $70–$300 Misroute rate (calls to expensive model unnecessarily) 10–20% extra spend 1M +10–20% Fallback when routed model fails +50% of call cost 2–5% of calls +1–2.5% Real scenario: 1M calls/month, routing 30% to GPT-5.5 and 70% to Gemini 2.5 Flash; a typical call is ~1.5K input / 500 output tokens. Per call that's ~$0.0225 on GPT-5.5 ((1,500 × $5/M) + (500 × $30/M)) vs ~$0.0017 on 2.5 Flash — so misrouting 5% of traffic (50,000 simple calls sent to GPT-5.5) wastes 50,000 × ~$0.021 ≈ $1,040/month . Add the classifier itself (~$70 at $0.00007/call) and the orchestration tax is ~ $1,100/month — roughly 14% on top of the ~$7,900 baseline spend, dominated by misroutes rather than the router. Cost Measurement Framework Step 1: Establish baseline API cost Sum all LLM provider bills (OpenAI, Anthropic, Google, etc.). This is your "known" cost. Step 2: Audit infrastructure Vector DB, embeddings API, observability, and self-hosted model costs. Add these to a "hidden infra" line item. Step 3: Measure waste Log every LLM call for one week with (model, tokens, success, reason_if_failed). Calculate waste rate and extrapolate to monthly. Step 4: Calculate true cost per successful response True cost = (API cost + infra cost + waste cost) / successful_responses. This is 20–50% higher than API cost alone. Quick Audit Checklist Do you log every LLM call? (If not, you can't measure waste) Is vector DB cost tracked separately? (Many teams hide this in "database" line items) What is your current fallback failure rate? (Should be 5% indicates a bug) Is prompt caching enabled? (If not, you're leaving 40–60% savings on the table for repeated queries) Do you classify calls as user-facing vs. internal? (Helps spot debug logging waste) What is your observability cost as % of LLM cost? (Should be 20% suggests over-instrumentation) Ready to find your hidden costs? FinOps LLM's cost audit digs into infrastructure, waste, and cache efficiency. Book a free audit and we'll quantify the real spend. Back to research FAQ What costs are hidden beyond per-token pricing? Vector database storage, cache infrastructure, retry/fallback chains, redundant model calls, embedding generation, and observability overhead. These can add 20–50% to your measured token bill. How much does vector search add to cost? Vector DB operations (embedding + retrieval) cost $0.001–$0.05 per query depending on vector dimension, chunk size, and k-NN matching. For a RAG system with 10K QPS, this adds $10–$500/day. Do retry loops waste money? Yes. A 2-tier fallback (primary model + fallback to cheaper model) can multiply token cost 1.2–2x if your primary model fails 30–50% of the time. Monitor fallback rates closely. How do I measure these hidden costs? Track infrastructure cost separately from API cost. Log every LLM call with (attempt number, model, token count, success/failure). Calculate cost-per-successful-response, not cost-per-call. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # The watermark in every Claude reply, explained · FinOps LLM URL: https://finopsllm.com/research/how-ai-watermarking-works How AI watermarking works Updated September 1, 2026 · first published September 1, 2026 Quick answer: There is an invisible signal in text generated by supported Claude models. You cannot see it. Your users cannot see it. It does not change the meaning, the quality, or the reading experience, and it... There is an invisible signal in text generated by supported Claude models. You cannot see it. Your users cannot see it. It does not change the meaning, the quality, or the reading experience, and it does not appear on your invoice. It is there anyway, and it is worth ten minutes of your understanding, because the things that break it are things your own pipeline does every day. How the text watermark works A language model does not pick the single most likely next token. It samples from a probability distribution, and that sampling uses randomness. The watermarking technique — following Google DeepMind's SynthID-Text approach — biases that randomness. Certain tokens become very slightly more likely than they otherwise would have been, according to a pattern only the detector knows. Any single word choice is unremarkable; a plausible alternative was always available, and the model picked one of them. Across a few hundred tokens, though, the pattern accumulates into a statistical signal that a detector can measure and a reader cannot perceive. That is the whole trick: the watermark hides in a decision the model was already making at random. Two consequences follow immediately, and both matter more than the mechanism. First, it is statistical, not a stamp — there is no field to read, only a confidence level to compute. Second, it needs length. A tweet-sized output carries far less signal than a full page. How image provenance works, and why it is different Images and files take the opposite approach. Generated .svg , .png and .jpg files carry C2PA metadata: a cryptographically signed manifest recording what produced the file. That is not statistical and not hidden — it is a discrete block of data attached to the file, verifiable exactly rather than probabilistically. The trade-off is exactly what you would expect. Signed metadata gives you certainty, and it can be deleted in one command. A statistical text watermark cannot be deleted cleanly, but it degrades as the text is edited, paraphrased or translated. Neither is a lock; both are evidence. Who can check Detection is gated. On 1 September 2026 an API opened to eligible organisations: regulators, law enforcement, media, fact-checkers, independent researchers, educational institutions, EU civil society groups, and enterprises with their own verification obligations. Access widens over time. If you are not eligible, you cannot verify your own output through the API, and your evidence has to come from your own logs. Why it exists Article 50 of the EU AI Act took effect on 2 August 2026, and it requires machine-readable marking of AI-generated content. Marking is applied worldwide rather than EU-only, which is the simpler engineering choice and means it is already in output you shipped months ago. What this means for your systems Three practical facts. Short outputs carry weak signal, so a classifier or extraction service returning single words is effectively unmarked. Heavy post-processing — paraphrasing, summarising, translating, or passing text through a second model — erodes the signal, so a chain of models attributes to the last one at best. And your image pipeline can destroy C2PA metadata by accident, which is the most common way provenance goes missing in production. None of that is a reason to change what you build. It is a reason to know which of your outputs still carries provenance and which does not, before someone asks you to prove it. Related What AI watermarking actually costs Multimodal cost allocation AI observability Related What AI watermarking actually costs Multimodal cost allocation AI observability Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Your CDN is deleting your AI watermark · FinOps LLM URL: https://finopsllm.com/research/how-ai-watermarks-get-destroyed How AI watermarks get destroyed Updated September 1, 2026 · first published September 1, 2026 Quick answer: The interesting question about AI watermarking is not how to defeat it. It is why so much production output arrives at the end of the pipeline with no provenance left, when nobody involved intended to... The interesting question about AI watermarking is not how to defeat it. It is why so much production output arrives at the end of the pipeline with no provenance left, when nobody involved intended to remove anything. Provenance is not usually attacked. It is optimised away, by systems doing exactly what they were built to do. There are two independent failure modes, because there are two independent mechanisms. Image provenance dies by deletion. Text provenance dies by dilution. Both are silent. Deletion: the metadata your pipeline throws away C2PA provenance lives in the file's metadata. Every one of these will discard it unless configured otherwise, and most are configured for bytes rather than evidence: Stage Why it strips Thumbnail and resize jobs Re-encodes pixels, drops non-image chunks CDN image transforms Optimises for delivery size by default Format conversion (to WebP/AVIF) Metadata often not carried across containers Social and CMS uploads Third-party platforms normalise and re-encode Screenshotting a generated image Produces an entirely new file The pattern is consistent: anything that re-encodes the image produces a new file, and a new file has no signed manifest unless something deliberately re-attaches one. A single automatic transform between generation and delivery is enough. Dilution: the text steps that erode the signal The text watermark is statistical, so it does not vanish in one step — it weakens. Each of these reduces detection confidence, and they compound: Translation, which re-generates every token in another language. Paraphrasing and "rewrite in our tone" passes. Summarisation, which discards most of the tokens carrying the signal. Passing output through a second model, after which the text is attributable to the last model at best. Heavy human editing. And simple brevity: a two-sentence output never carried much signal to begin with. Note that a normal, well-built product does several of these. A pipeline that generates with one model, rewrites for tone with another, translates into five languages, and truncates to a summary card has not done anything wrong. It has also, without a line of code intended for the purpose, produced output no detector will confidently attribute. Why this costs money The bill arrives at the moment you are asked to demonstrate provenance and cannot. Under Article 50, the obligation is to mark generated content; if your delivery path destroys the marking, the obligation is unmet regardless of the model's behaviour at generation time. Remediation is then a pipeline retrofit under deadline, which is the most expensive form of engineering there is. The cheaper version is a single test, today: generate one image and one long text through your real production path, and check what survives at the far end. That is an afternoon, and it either confirms your pipeline is clean or finds the exact stage that is not. What to do about it Preserve metadata explicitly in image transforms rather than relying on defaults, and re-attach provenance after any re-encode you control. Where the marking cannot survive — a third-party platform, a summarisation step you need — carry the evidence in your own telemetry instead: model ID, version, region and timestamp, joined to the artefact ID. That log is not a substitute for marking, but it is the record that answers the question when the marking is gone. And treat the detection result as evidence, not proof. It is a confidence level over a statistical signal; short or heavily processed text will read as inconclusive even when it was genuinely generated. Systems that treat a low-confidence result as a verdict will be wrong in both directions. Related How AI watermarking works What AI watermarking actually costs AI observability Related How AI watermarking works What AI watermarking actually costs AI observability Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # How do LLM providers charge? Tokens, tiers, caching · FinOps LLM URL: https://finopsllm.com/research/how-llm-providers-charge How do LLM providers charge? Updated 11 June 2026 · first published 31 May 2026 Almost every large-language-model provider bills the same way underneath the marketing: you pay per token , and the price per token depends on which model you call and whether the token was read in, generated out, or served from a cache. There is no seat license and no flat monthly fee on the usage-based APIs - the meter runs on every request. Understanding that meter is the difference between a predictable AI bill and a monthly surprise. This is a plain-English explainer for anyone - finance, product, or engineering - who has looked at an OpenAI or Anthropic invoice and wanted to know what the numbers actually represent. The unit: a token A token is a chunk of text, usually a few characters long. As a rough rule of thumb, a token is about three-quarters of a word in English, so 1,000 tokens is roughly 750 words. Providers count tokens, not words or characters, and they publish prices per million tokens. Everything on your invoice traces back to how many tokens of each type your workloads consumed. The two prices on every model: input and output Every model has at least two prices, and they are not the same number: Input tokens - everything you send the model: your prompt, the system instructions, any retrieved documents, and the prior conversation history. These are usually the cheaper of the two. Output tokens - everything the model generates back. Output is typically several times more expensive per token than input. This asymmetry matters because the two costs are driven by different things. Input cost grows when you stuff more context into the prompt - long system prompts, deep retrieval, full conversation history. Output cost grows when the model writes more - verbose answers, high max tokens limits, or formats that pad the response. A request that reads a lot and writes a little has a very different cost shape from one that reads a little and writes a lot, even on the same model. Tiers: the same task can cost 10–50× more depending on the model Providers offer a ladder of models, from small and cheap to large and capable, and the price gap between the top and bottom of that ladder is enormous - frequently more than an order of magnitude per token. The most common avoidable cost in production is sending every request to the most capable (most expensive) model when a smaller one would have answered just as well. That is the entire premise of model routing : match each request to the cheapest model that still meets your quality bar, instead of defaulting everything to the flagship. Because the per-token gap between tiers is so large, getting routing right is often the single biggest lever on the bill. Cache reads: the discount most teams forget to track Major providers can serve a repeated prompt prefix from a cache rather than processing it fresh, and they bill those cache-read tokens at a steep discount. As of 2026 the discount is roughly 50% on OpenAI and up to about 90% on Anthropic, though you should always check current provider pricing. The trap is that cache reads look like ordinary input tokens unless you separate them. If you build a cost baseline that treats every input token at full price, you will overstate your spend and misjudge your savings. Conversely, if a deploy quietly breaks cache hits - by changing a system prompt that used to be stable - your bill can climb sharply with no change in traffic. Tracking cache reads as their own line is fundamental to an accurate baseline. Reasoning tokens: billed, but invisible Reasoning models generate a chain of internal "thinking" before they produce a visible answer. Those reasoning tokens are billed like output tokens but never shown to the user. On hard prompts they can dominate the cost of a request - sometimes several times the size of the visible answer. Teams that adopt a reasoning model and only budget for the output they can see are routinely surprised by the invoice. The other modifiers Batch APIs. Most providers offer an asynchronous batch mode at a discount (often around half price) for work that can tolerate delay - evals, backfills, bulk summaries. Context window. Larger context windows cost more per request simply because you are sending more input tokens. Bigger is not free. Multimodal. Images, audio, and video are converted into tokens too, and multimodal costs can climb faster than text. Built-in tools and retrieval. Provider-hosted tools, web search, and file search often carry their own per-call charges on top of token cost. The per-request math Put together, the cost of a single request is roughly: (input tokens at full price) + (cache-read tokens at the discounted price) + (output tokens, including any reasoning tokens) - all multiplied by the price of the specific model that handled it. Your monthly invoice is that calculation summed across every request, every model, every day. The reason invoices feel unpredictable is that all five variables - volume, model mix, prompt size, output length, and cache-hit rate - move independently, and a single code change can shift any of them without touching the others. Why this matters for budgeting Because providers bill per token and per model, you cannot control AI cost from a dashboard that only shows total spend. You control it by knowing which features drive which token shapes on which models - that is cost attribution - and then pulling the levers that the pricing model exposes: route to cheaper models, cache stable prefixes, compress prompts, and batch the work that can wait. The invoice is just the sum of those choices. Related Cost per request as a product KPI - turning provider pricing into product metrics. Input, output, cache, and reasoning tokens - what each token type costs and why. Why does my LLM bill spike? - the common causes of sudden cost growth. What is LLM cost attribution? - tracing spend back to an owner. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is a token? A token is a chunk of text, usually a few characters long. As a rough rule of thumb, a token is about three-quarters of a word in English, so 1,000 tokens is roughly 750 words. Providers count tokens, not words or characters, and publish prices per million tokens. Everything on your invoice traces back to token consumption. What are the two prices on every model: input and output? Input tokens are everything you send the model (prompt, system instructions, documents, conversation history) and are typically cheaper. Output tokens are everything the model generates and are several times more expensive per token. This asymmetry matters because the two costs are driven by different factors. What are model tiers and why do they matter? Providers offer a ladder from small/cheap to large/capable models. The price gap is enormous - frequently more than an order of magnitude per token between the top and bottom. The same task costs 10-50× more depending on which model tier handles it. How are cache-read tokens billed? Major providers serve repeated prompt prefixes from cache rather than processing fresh. They bill cache-read tokens at steep discount - roughly 50% on OpenAI and up to 90% on Anthropic. Most teams fail to track this separately, missing significant savings opportunities. What are reasoning tokens and why are they hidden? Reasoning models generate internal 'thinking' before producing visible output. Those reasoning tokens are billed like output tokens but never shown to the user. On hard prompts they can dominate cost - sometimes several times the size of the visible answer. What is the per-request math? Cost = (input tokens at full price) + (cache-read tokens at discount) + (output tokens including reasoning) - all multiplied by the specific model's price. Understanding this formula lets you predict costs and identify optimization opportunities. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # How Much Does GPT-5 Cost? Complete 2026 Pricing Guide · FinOps LLM URL: https://finopsllm.com/research/how-much-does-gpt5-cost How Much Does GPT-5 Cost? Updated 12 July 2026 · first published 4 July 2026 GPT-5 is OpenAI's flagship reasoning model, released in 2026. It delivers substantially stronger performance on complex reasoning, coding, and multimodal tasks than GPT-4o - but at a premium price. This guide breaks down every cost dimension: API pricing, ChatGPT subscription tiers, how it compares to GPT-4o, and where cheaper alternatives like MiMO may be the smarter choice. GPT-5 API pricing OpenAI prices GPT-5 per million tokens, with separate rates for input, output, and cached input. Cached reads are significantly cheaper because the model reuses a previously computed prefix. Tier Input $/1M Output $/1M Cache Read $/1M Context Window GPT-5.6-Sol (max) $5.00 $30.00 $0.50 128K tokens GPT-5.6-Terra (mid) $2.50 $15.00 $0.25 128K tokens GPT-5.6-Luna (budget) $1.00 $6.00 $0.10 128K tokens GPT-5.5 (flagship) $5.00 $30.00 $0.50 128K tokens GPT-5.4 (mid-tier) $2.50 $15.00 $0.25 128K tokens OpenAI's new July 2026 generation (GPT-5.6) introduces three distinct tiers: Sol for frontier reasoning, Terra for balanced performance, and Luna for cost-conscious use cases. For comparison, older GPT-5.5 and 5.4 models remain available. GPT-5.6 and 5.5 at $5/$30 are significantly more capable than GPT-4o ($2.50/$10), but the effective cost depends on reasoning depth and cache efficiency. ChatGPT subscription costs If you use GPT-5 through the ChatGPT interface rather than the API, pricing is subscription-based: Plan Monthly Price GPT-5 Access Key Limits Free $0 GPT-5 mini only Limited messages/day Plus $20/mo GPT-5 with caps ~80 GPT-5 messages/3hrs Pro $200/mo Unlimited GPT-5 No rate limits, voice, deep research Team $25/user/mo GPT-5 with higher caps Admin tools, SSO, higher limits Enterprise Custom GPT-5 unlimited SLA, dedicated support, data governance The Pro plan at $200/month is only cost-effective if you are a heavy daily user. For most developers and teams, the API with careful token management is cheaper than a Pro subscription. GPT-5 vs GPT-4o: when does the upgrade make sense? The price gap is real, so the question is whether GPT-5's quality advantage translates into cost savings elsewhere: Use GPT-5 when: the task requires multi-step reasoning, complex code generation, long-document analysis, or agentic workflows where a single high-quality pass saves multiple retry cycles. Use GPT-4o when: the task is straightforward - classification, extraction, summarization of short texts, simple chat, or high-volume batch processing where throughput matters more than per-request intelligence. Use GPT-5 mini or nano when: you need GPT-5-level instruction following but at lower cost, and can accept slightly reduced reasoning depth. A practical rule: if your GPT-4o prompts include chain-of-thought instructions or multi-turn correction loops, GPT-5 may actually be cheaper because it does that reasoning natively in a single call. How to reduce GPT-5 costs Several strategies can cut your GPT-5 bill by 30–70% without sacrificing output quality: Leverage prompt caching. GPT-5's cache read rate ($2.50/1M) is 75% cheaper than the full input rate. Structure your prompts with a stable prefix (system instructions, context) and variable suffix (user query) to maximize cache hits. Use GPT-5 mini/nano for routing. Run a lightweight model first to classify intent, then escalate to full GPT-5 only for complex queries. This is the model routing pattern. Batch API for non-interactive work. OpenAI's batch API offers 50% discounts on asynchronous workloads - ideal for evaluation, enrichment, and report generation. Right-size context windows. Don't send 100K tokens of context when 5K will do. Every unnecessary input token costs 4× more on GPT-5 than GPT-4o. Consider alternatives. For many coding and reasoning tasks, models like MiMO , DeepSeek R1, or Claude Sonnet deliver comparable quality at a fraction of the cost. Use provider arbitrage to benchmark. Hidden costs beyond the sticker price The per-token rate is only part of the picture. Budget for these additional factors: Reasoning tokens. GPT-5 uses internal reasoning tokens for complex tasks. These are billed at the output rate ($30/1M) and can multiply your effective output volume by 2–5× on hard problems. Retry costs. If your prompts are ambiguous or your parsing is brittle, failed attempts still consume tokens. Robust prompt engineering pays for itself. Evaluation spend. Testing and benchmarking during development can easily exceed production spend if not tracked separately. See eval cost allocation . Bottom line GPT-5 is expensive but not uniformly so. At $10/$30 per million tokens, a typical API call with 1,000 input tokens and 500 output tokens costs about $0.025. For high-volume applications, the bill adds up fast - but smart caching, routing, and batching can reduce costs by half or more. Track every request, attribute spend to features, and benchmark alternatives regularly. Related GPT-5 pricing and budget impact - worked budget scenarios for production teams. GPT-5 vs GPT-4o cost comparison - when the upgrade pays for itself. LLM Cost Benchmarks by Industry - modeled spend scenarios across customer support, finance, healthcare, and manufacturing. How do LLM providers charge? - the pricing models behind the numbers. Model routing - sending the right request to the right model. Provider arbitrage - finding the cheapest model that meets your quality bar. Prompt caching explained - how to actually get cache hits. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is GPT-5 API pricing? OpenAI prices GPT-5 per million tokens, with separate rates for input, output, and cached input. Cached reads are significantly cheaper because the model reuses a previously computed prefix. How much do ChatGPT subscriptions cost? Free gives GPT-5 mini with a daily message cap. Plus is $20/mo with roughly 80 GPT-5 messages per 3 hours, Team is $25/user/mo with higher caps and admin tools, and Pro is $200/mo for unlimited GPT-5. Enterprise is custom. Pro only pays off for heavy daily users — for most developers the API with careful token management costs less. GPT-5 vs GPT-4o: when does the upgrade make sense? Use GPT-5 for multi-step reasoning, complex code generation, long-document analysis, and agentic workflows where one high-quality pass replaces several retries. Stay on GPT-4o for classification, extraction, short summarisation, simple chat, and high-volume batch work. If your GPT-4o prompts already carry chain-of-thought instructions or multi-turn correction loops, GPT-5 can be cheaper because it does that reasoning in a single call. How to reduce GPT-5 costs? Several strategies can cut your GPT-5 bill by 30–70% without sacrificing output quality: What hidden costs go beyond the sticker price? The per-token rate is only part of the picture. Budget for these additional factors: Is GPT-5 worth the cost? GPT-5 is expensive but not uniformly so. At $10/$30 per million tokens, a typical API call with 1,000 input tokens and 500 output tokens costs about $0.025. For high-volume applications, the bill adds up fast - but smart caching, routing, and batching can reduce costs by half or more. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # How to audit your LLM spend in 30 minutes · FinOps LLM URL: https://finopsllm.com/research/how-to-audit-llm-spend How to audit your LLM spend in 30 minutes Updated 4 July 2026 · first published 4 July 2026 Most teams do not know how their LLM budget breaks down. Costs hide behind provider dashboards that show totals but not attribution, token types that are billed at different rates, and usage patterns that shift week to week. This guide gives you a structured audit you can run in half an hour using tools you already have. Step 1 - Gather billing data from providers Export the last 30 days of usage from every LLM provider you use. For OpenAI, use the Usage API or download CSV from the dashboard. For Anthropic, pull from the Billing API. For Google, export from the Cloud Billing console. For self-hosted models, pull request logs from your inference server. Store everything in one folder. You need raw data, not summaries. Step 2 - Normalize token counts across providers Each provider counts tokens differently. OpenAI and Anthropic use their own tokenizers; Google uses SentencePiece. To compare, convert all counts to a common unit. The simplest approach: use each provider's published per-token price to calculate cost per request, then compare costs directly rather than raw token counts. This avoids tokenizer mismatch entirely. Step 3 - Split by input, output, cache, and reasoning tokens Providers charge different rates for different token types. Cached input tokens are typically 50% cheaper on OpenAI and Anthropic. Reasoning tokens (on o-series and similar models) can cost 2–4x standard output tokens. Break your spend into these four buckets: input, output, cached input, and reasoning. If your provider does not expose this split, estimate it from the model type and request pattern. Step 4 - Attribute to teams and features Map each API key or project to the team or feature that owns it. If you do not have key-level separation, use request metadata - headers, tags, or the user parameter that most providers support. The goal is a table: which team spends how much on which feature. Without this, you cannot hold anyone accountable for cost. Step 5 - Identify the top 3 cost drivers Sort by total spend descending. In most organizations, 80% of LLM cost comes from 3–5 usage patterns. Common drivers: a chatbot with long context windows, a code generation feature that uses expensive models for all requests, or a background enrichment job that runs on every document without filtering. Name them. This is where you focus optimization effort. Step 6 - Calculate cost-per-task for key workflows Pick your top 3 workflows. For each, divide total spend by the number of completed tasks. This gives you a unit economics number you can track over time. A customer support workflow that costs $0.12 per ticket is manageable. One that costs $1.40 per ticket needs attention. The absolute number matters less than the trend and the comparison between workflows. Step 7 - Set up alerts for anomalies Configure alerts at two levels: total daily spend (catches runaway jobs) and per-workflow spend (catches drift). Most providers support billing alerts natively. For cross-provider alerting, pipe your usage data into a dashboard or use a tool like MiMO that aggregates across providers. A simple rule: alert if any day exceeds 150% of the trailing 7-day average. Quick Audit Checklist Step Tool needed Time estimate Output 1. Gather billing data Provider dashboards or APIs 5 min Raw CSV/JSON per provider 2. Normalize tokens Spreadsheet or script 5 min Cost-per-request table 3. Split token types Provider APIs with token breakdown 5 min Input/output/cache/reasoning split 4. Attribute to teams API key mapping or metadata 5 min Team-to-feature cost matrix 5. Identify top drivers Sort/spreadsheet 3 min Ranked list of cost patterns 6. Cost-per-task Task count from app logs 5 min Unit economics per workflow 7. Set up alerts Provider billing alerts + dashboard 2 min Anomaly detection active What to do next This audit gives you a snapshot. The real value comes from running it regularly - weekly for high-spend teams, monthly for everyone else. Automate the data collection and make the cost-per-task metric a first-class product metric. If you want help building this into a continuous process, MiMO provides cross-provider dashboards and automated attribution out of the box. Related LLM cost attribution - deeper dive into attribution patterns. LLM cost anomaly detection - automated alerting strategies. How to budget for AI spend - moving from audit to budget. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ How do you gather billing data from providers? Export the last 30 days of usage from every LLM provider. For OpenAI use the Usage API or CSV from the dashboard. For Anthropic pull from the Billing API. For Google export from Cloud Billing. For self-hosted pull request logs from your inference server. Store everything in one folder - you need raw data, not summaries. How do you normalize token counts across providers? Each provider counts tokens differently (OpenAI/Anthropic use own tokenizers, Google uses SentencePiece). To compare, convert all to a common unit. Simplest: use each provider's per-token price to calculate cost per request, then compare costs directly. This avoids tokenizer mismatch entirely. Why split spend by input, output, cache, and reasoning tokens? Providers charge different rates for different token types. Cached input costs 50% less. Reasoning tokens cost 2-4x output tokens. Break spend into four buckets: input, output, cached input, and reasoning. If not exposed by provider, estimate from model type and request pattern. How do you attribute spend to teams and features? Map each API key or project to the owning team or feature. Without key-level separation, use request metadata (headers, tags, user parameter). Goal: a table showing which team spends how much on which feature. Without attribution, you cannot hold anyone accountable for cost. How do you identify your top cost drivers? Sort spend descending. In most organizations, 80% of LLM cost comes from 3-5 usage patterns. Common drivers: chatbots with long context, expensive models used for all requests, background enrichment without filtering. Name them - this is where optimization effort focuses. How do you calculate cost-per-task for key workflows? Pick top 3 workflows. Divide total spend by completed tasks to get unit economics. A $0.12-per-ticket support workflow is manageable, while $1.40 needs attention. Absolute number matters less than trend and comparison between workflows. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # How to budget for AI spend: a starter framework · FinOps LLM URL: https://finopsllm.com/research/how-to-budget-for-ai-spend How to budget for AI spend Updated 11 June 2026 · first published 31 May 2026 Budgeting for LLM spend feels harder than budgeting for SaaS because it is. A SaaS line item is a fixed number you negotiate once a year. LLM spend is variable, per-request, and driven by code paths that change every week. But the discipline is not exotic - it is the same envelope-and-forecast loop finance already runs for cloud compute, applied to a different cost driver. This is a starter framework for teams setting their first real AI budget. Why a flat number doesn't work The instinct is to set one company-wide AI budget - "we'll spend $40K a month on OpenAI" - and watch the total. It fails for the same reason a single cloud budget fails: when the number is breached, you have no idea which workload caused it, so you have no idea what to cut. A useful AI budget is not one number. It is a set of envelopes, one per workload, each with a named owner. Step 1: Attribute before you budget You cannot budget spend you cannot trace. The prerequisite for every step below is cost attribution - the ability to see spend broken out by feature, team, environment, and customer. A budget set on unallocated spend is a guess, and a guess cannot be enforced. If you do nothing else first, get attribution working. Step 2: Forecast from token shapes, not last month's total To project next quarter's spend, build it up from the cost drivers rather than extrapolating the invoice. For each significant workload, estimate: Request volume - how many calls per month, and how it tracks with a business driver (active users, transactions, documents processed). Token shape - average input, output, cache-read, and reasoning tokens per request. This is where the cost actually lives. (See how providers charge .) Model mix - which model tiers handle the traffic, since the per-token price varies by more than 10× across the ladder. Multiply those out and you have a forecast that responds to reality: if volume doubles, you know the cost; if a feature moves to a cheaper model, you can see the saving before you ship it. Tie the forecast to a business metric so finance can sanity-check it against the plan. Step 3: Set an envelope per workload Give each workload a monthly envelope derived from the forecast plus a deliberate margin for growth. The envelope is not aspirational - it is the number the owning team is accountable to. Express it in dollars, but track it in the underlying drivers (cost per request × volume) so a breach can be diagnosed, not just noticed. Step 4: Choose soft and hard thresholds A budget without a response to a breach is just a chart. Define two thresholds per envelope: Soft threshold (e.g. 80% of envelope) - alert the owning team and trigger a review. Nothing changes automatically; a human decides. Hard threshold (e.g. 100%) - the system degrades behaviour rather than letting spend run unbounded: drop to a cheaper model, reduce retrieval depth, move non-urgent work to a batch API, or queue lower-priority traffic. The point of the hard threshold is not to punish the team that exceeded it. It is to make sure a runaway cost - a broken cache, a spike , an agent loop - is bounded by design instead of discovered at month-end. Step 5: Reconcile, then adjust At month-end, compare your internal estimate to the actual provider invoice. Reconciliation does two things: it keeps your forecast honest (a recurring variance usually means a stale price assumption or a misclassified token type), and it feeds the next cycle's envelopes with real numbers. A budget that is never reconciled drifts away from the invoice until no one trusts it. Step 6: Give the budget an owner at three levels Budgets fail organizationally more often than technically. The pattern that holds up has three explicit roles: A finance owner (FP&A or a FinOps lead) who owns the model, the forecast, and the monthly close. A platform owner (the engineer who runs the gateway) who owns the tagging that makes attribution reliable and enforces the hard thresholds. An executive sponsor (CFO or CTO) who chairs the review and resolves disputes when a team wants more envelope. Smaller teams collapse the first two roles into one FinOps-minded engineer, but the sponsor is non-negotiable - without it, budget breaches become political fights instead of operational decisions. A realistic first 30 days Week 1: get attribution working - tag traffic by feature and environment, even crudely. Week 2: measure current token shapes and model mix per workload; build the bottom-up forecast. Week 3: set envelopes and soft thresholds; wire up alerts. Week 4: add hard-threshold degradation on the highest-spend workloads; run a first reconciliation against the latest invoice. That is enough to turn "we'll find out at month-end" into "we know where we are today, and the worst case is bounded." Everything after that is refinement. Related LLM Cost Per User Benchmarks - compare your per-user spending against industry benchmarks by role. Token budget implementation - turning budgets into runtime enforcement. Eval cost allocation - handling evals as a separate budget category. Cost per request as a product KPI - making cost visible to owners. LLM budget governance - budgets, quotas, and degradation paths in depth. What is LLM cost attribution? - the prerequisite for any budget. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ Why a flat number doesn't work? The instinct is to set one company-wide AI budget - "we'll spend $40K a month on OpenAI" - and watch the total. It fails for the same reason a single cloud budget fails: when the number is breached, you have no idea which workload caused it, so you have no idea what to cut. Why attribute before you budget? You cannot budget spend you cannot trace. The prerequisite for every step below is cost attribution - the ability to see spend broken out by feature, team, environment, and customer. A budget set on unallocated spend is a guess, and a guess cannot be enforced. How do you forecast from token shapes instead of last month's total? To project next quarter's spend, build it up from the cost drivers rather than extrapolating the invoice. For each significant workload, estimate: Request volume - how many calls per month, and how it tracks with a business driver (active users, transactions, documents processed). How do you set a spend envelope per workload? Give each workload a monthly envelope derived from the forecast plus a deliberate margin for growth. The envelope is not aspirational - it is the number the owning team is accountable to. How do you choose soft and hard budget thresholds? A budget without a response to a breach is just a chart. Define two thresholds per envelope: Soft threshold (e.g. 80% of envelope) - alert the owning team and trigger a review. Nothing changes automatically; a human decides. Hard threshold (e.g. How do you reconcile and adjust at month-end? At month-end, compare your internal estimate to the actual provider invoice. Reconciliation does two things: it keeps your forecast honest (a recurring variance usually means a stale price assumption or a misclassified token type), and it feeds the next cycle's envelopes with real numbers. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # How to use Jev in an AI agent · FinOps LLM URL: https://finopsllm.com/research/how-to-use-jev-in-an-agent How to use Jev in an AI agent Updated September 21, 2026 · first published September 21, 2026 Quick answer: Use Jev when an agent needs to choose, score, classify, or gate—not when it needs to write. The smallest useful integration is one decision with a fixed answer space. Give Jev the state already... Use Jev when an agent needs to choose, score, classify, or gate—not when it needs to write. The smallest useful integration is one decision with a fixed answer space. Give Jev the state already available to the workflow, define the choices your code can handle, and branch on the returned answer and confidence. Vercel exposes Jev as typesafe-ai/jev in AI Gateway and documents it through AI SDK's experimental evaluate API. Its model page uses a Boolean question to determine whether a refund was issued. The same request shape works for routing, scoring, and guardrails. 1. Start with one bounded question Good first questions have a finite answer space and an obvious next action. “Which queue owns this ticket?” is good: Billing, Technical, Sales, or Review. “What should we do?” is too broad; it asks Jev to plan rather than decide. 2. Supply state and typed questions Send the ticket, relevant account facts, and the policy excerpt the decision needs. Then declare the questions, for example: queue: Choice(Billing, Technical, Sales, Review) and urgent: Boolean . Every question shares the same state, so avoid unrelated history and include the facts that a capable human reviewer would need. 3. Make confidence change the path Use an explicit route for each result. A high-confidence, low-risk routing result may continue immediately. A medium-confidence case can go to a stronger model with the same evidence. A high-impact or low-confidence case can go to review. Do not use one global threshold: a mistaken topic tag and a mistaken payment action have different consequences. 4. Ask more questions before making more calls Jev can evaluate several typed questions against the same state. Ask for queue, urgency, and whether the evidence is sufficient in one decision call when all three change the next step. Add questions only when they change behaviour; free output is not a reason to create unused judgments. 5. Keep authority in code Vercel's agent-control guide keeps permissions, argument validation, retry policy, and tool execution in application code. Jev evaluates the state; your application decides what it is allowed to do. Store the state version, question version, answer, probability, route, and final outcome so that you can tune the threshold and measure cost per resolved task. Jev is easiest to adopt when it replaces one awkward LLM decision in an existing agent. Prove the pattern on that decision, then expand to other repeated forks in the workflow. Related Where Jev belongs in an agent workflow What independent Jev tests say about cost Cost per successful task Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Invoice reconciliation for AI spend · FinOps LLM URL: https://finopsllm.com/research/invoice-reconciliation Invoice reconciliation for AI spend Updated 21 May 2026 · first published 21 May 2026 Every other line on the corporate income statement gets a monthly close. The AWS bill is reconciled against the tag-allocated cost report. The SaaS subscriptions are reconciled against seat counts pulled from each vendor's admin console. Payroll is reconciled against the HRIS. AI spend is almost never reconciled against anything, which is why most organizations cannot answer a simple question: does the provider invoice match what we think we used? Until that question has a written answer with two signatures on it, every downstream FinOps motion - chargeback, showback, forecasting, unit economics - rests on numbers nobody has audited. This page is about the close-of-books step for AI bills. Not the dashboards, not the alerts, not the recommendations. The unglamorous monthly ritual of pulling the provider export, pulling the internal usage log, joining them, finding the variance, writing down why the variance exists, and getting an engineering owner and a finance owner to sign that the numbers are clean enough to charge back. Why AI invoices need their own close-of-books step Most SaaS invoices are boring on purpose. The seat count is the seat count, the contract rate is the contract rate, the monthly total is a multiplication. Reconciliation is a glance. AI invoices are not boring. They move by usage, the usage moves by user behavior, and the user behavior moves by whatever shipped on Tuesday. A 30% month-over-month swing is normal and may be entirely correct, or it may be a regression that doubled retry counts on one endpoint and nobody noticed because the dashboards roll up too coarsely. Worse, the attribution fields on a provider invoice rarely match the attribution fields a product team tags internally. The provider knows about workspaces, projects, and API keys. The product team thinks in features, teams, and tenants. The gap between those two vocabularies is where every reconciliation lives. If nobody translates between them on a cadence, the gap silently widens until the invoice and the internal ledger describe two different companies. What "reconciled" actually means Reconciled does not mean the two numbers are equal. It means the two numbers are equal within an acceptable variance, and every dollar of the variance has a documented reason that both sides have agreed to. The provider's line items - billed at the workspace, project, or API key level - match the internal usage records - billed at the feature, team, or endpoint level - after applying a known set of translation rules. The remaining gap is small, categorized, and signed off. A useful working tolerance is one to two percent of total monthly spend, depending on how complex the workload mix is. Anything inside that band gets accepted with a one-line note. Anything outside it triggers a deeper investigation before the chargeback ledger is posted. The four-document set A clean monthly reconciliation produces four artifacts. None of them are optional; each one answers a different auditor. Provider invoice or cost export - the authoritative source from the provider's billing system. Usually a CSV with workspace or project granularity and per-model, per-token-type line items. Internal usage telemetry - the rollup from the gateway, proxy, or instrumented SDK that records every call with feature, team, tenant, and environment tags. Chargeback ledger - the spreadsheet or table that maps the reconciled total to internal budget owners and posts it to their cost center. Variance memo - a short written document, one paragraph per variance category, that explains the gap between the provider invoice and the internal telemetry and records the decision to accept or escalate. Sources of variance The same handful of issues show up every month. Naming them in advance turns reconciliation from a mystery into a checklist. Clock skew between billing windows. The provider closes the billing month at midnight UTC; internal logs are stored in local time or in the application's preferred timezone. A call at 23:55 local on the last day of the month can land on either side of the line. Across a high-volume month the drift can be a couple of percent. Cache-read tokens at a different rate. Most providers bill cache-read tokens at a discount, sometimes a deep one. Internal logs that count tokens without separating cache reads from fresh input will overstate cost on one side and understate it on the other. Tier breakpoints. Volume-tiered pricing means the unit rate the provider applied may not be the unit rate the internal calculator assumed, particularly mid-month when a workspace crossed a tier. Failed-request handling. Some failed requests are billable, some are not, and the rules differ by provider and error class. Internal logs often count attempts; invoices count completed billable units. Trial credits and promotional balances. A credit applied at the provider level appears as a reduction on the invoice but never shows up in the usage telemetry. The variance memo has to record it explicitly or the chargeback overcharges every team. Provider-side billing corrections. A correction posted after the prior month's close shows up as an adjustment line on the current invoice. It belongs in last month's reconciliation, not this month's. The reconciliation workflow The workflow itself is straightforward and the same shape every month. The discipline is in doing it on a cadence rather than only when something looks wrong. Pull the provider invoice or cost export for the closed month, at the finest granularity the provider exposes - usually workspace, project, or API key, with per-model and per-token-type breakdown. Pull the internal usage telemetry for the same window, with feature, team, tenant, environment, and token-type tags. Join the two datasets on the shared key - usually workspace or project - and roll up both sides to the same grain. Diff at the line-item level. For each model and token type, compute the variance between provider-billed and internally-recorded cost. Categorize each variance against the known sources above. Anything that does not fit a category is the interesting one. Escalate variances above tolerance to the engineering owner of the affected feature; accept variances inside tolerance with a note. Sign off and post the reconciled total to the chargeback ledger. What the variance memo records The memo is short on purpose. One sentence per variance category is enough, written in the past tense, with numbers. The format that holds up under audit looks like this: "Provider billed $48,200 for cache-read tokens on Workspace A at the discounted rate; internal record shows $52,900 at the standard input rate because the gateway did not flag cache reads separately. Provider rate applied. Variance: $4,700. Accepted." "Provider billed $1,150 for the last 47 minutes of the month UTC on Workspace B; internal log assigned those calls to the following month because telemetry uses local time. Provider window applied. Variance: $1,150. Accepted; telemetry timezone to be aligned next quarter." Every paragraph follows the same shape - what each side said, which side was authoritative, the size of the gap, the decision. The memo lives next to the invoice and the export, and the chargeback ledger references it by date. Who signs Three signatures keep the audit trail honest. The engineering owner of the affected feature signs the telemetry side - they are the only person who can attest that the internal usage log reflects the work actually performed. The finance owner signs the provider side - they own the relationship with the provider and the contract terms that drive the unit rates. The AI program lead signs both, attesting that the variance memo accurately describes the gap and that the chargeback total is defensible. Two signatures are not enough. Engineering alone will accept any variance that does not affect their roadmap; finance alone will accept any variance that does not affect the bottom line. The third signature exists to force the conversation between them. An on-cadence checklist Reconciliation works when it runs on a calendar, not when something looks wrong. A two-week rolling cadence for the prior month is comfortable for most organizations. Week 1 of the month. Pull last month's provider exports as soon as they are available. Pull the matching internal usage telemetry. Run the join. Draft the variance memo against the known categories. Flag anything outside tolerance and route it to the relevant engineering owner. Week 2 of the month. Collect responses on the flagged variances. Update the memo. Get the three sign-offs. Post the reconciled total to the chargeback ledger and publish the showback report for the prior month. By the end of week two, the prior month is closed and the chargeback is defensible. Anything that surfaces afterward goes into an adjustment line on the next month's reconciliation, with its own memo paragraph. Why this matters for chargeback Chargeback only holds up when both sides agree the inputs are clean. The team being charged needs to believe the telemetry attributed the right work to them; the finance team posting the entry needs to believe the provider invoice was paid correctly. Reconciliation is the audit trail that lets both sides answer yes. Without it, chargeback becomes a political negotiation every month - engineering teams contest the number, finance defends an aggregate they cannot decompose, and the AI program lead spends the meeting explaining the gap instead of running the program. The same audit trail protects the organization externally. Annual financial audits, customer security questionnaires, and contract renegotiations with the provider all benefit from a stack of signed variance memos that prove the AI spend line on the income statement matches reality. The work is unglamorous; the alternative is worse. Related OpenAI cost attribution Anthropic cost attribution LLM chargeback and showback LLM cost monitoring Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → ← Back to research FAQ Why AI invoices need their own close-of-books step? Most SaaS invoices are boring on purpose. The seat count is the seat count, the contract rate is the contract rate, the monthly total is a multiplication. Reconciliation is a glance. AI invoices are not boring. What does "reconciled" actually mean? Reconciled does not mean the two numbers are equal. It means the two numbers are equal within an acceptable variance, and every dollar of the variance has a documented reason that both sides have agreed to. What is the four-document set? A clean monthly reconciliation produces four artifacts. None of them are optional; each one answers a different auditor. What causes variance between your estimate and the invoice? The same handful of issues show up every month. Naming them in advance turns reconciliation from a mystery into a checklist. What is the reconciliation workflow? The workflow itself is straightforward and the same shape every month. The discipline is in doing it on a cadence rather than only when something looks wrong. What the variance memo records? The memo is short on purpose. One sentence per variance category is enough, written in the past tense, with numbers. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # IT Chargeback and Showback Explained · FinOps LLM URL: https://finopsllm.com/research/it-chargeback-showback IT chargeback and showback IT chargeback and showback are two ways to allocate technology costs back to the teams that consume them. Both improve cost awareness, but only one moves budget responsibility. What is IT chargeback? Chargeback bills business units directly for the IT services they use. If engineering runs workloads that cost $50,000 in a month, engineering's budget is charged $50,000. The team now owns the cost and has a direct incentive to optimize it. Chargeback is common in cloud FinOps because usage is measurable. Every compute instance, storage bucket, API call, and model request can be tagged to a team, project, or product. What is IT showback? Showback reports the same usage data to business units without transferring the bill. Engineering still sees that it consumed $50,000, but the central IT budget pays it. The goal is transparency and behavior change, not budget transfer. Showback is a softer first step. It lets teams see their footprint, compare it to peers, and learn to optimize before they are asked to own the budget. Chargeback vs showback: key differences Budget ownership. Chargeback moves budget ownership to the business unit. Showback keeps it with central IT. Incentive strength. Chargeback creates a stronger, more immediate incentive to reduce waste. Implementation complexity. Showback is easier because it does not require changes to procurement or budgeting processes. Political friction. Chargeback can create conflict if teams feel they are being taxed for services they cannot control. Which model should you choose? Start with showback if your organization is early in its FinOps journey. It builds trust, surfaces the data quality issues in your cost allocation, and gives teams time to learn. Move to chargeback once the data is trusted, tagging is clean, and teams have shown they can act on the reports. Hybrid models are also common: chargeback for stable, controllable services and showback for shared platform costs. Applying this to AI and LLM spend AI workloads make chargeback and showback more important, not less. LLM costs are granular, spiky, and driven by product usage. Without allocation, a single team's experiment can double the AI budget overnight. For the LLM-specific angle, see our guide to LLM chargeback and showback . For the finance and governance perspective, see the LLM CFO guide to AI chargeback and showback . Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is IT chargeback? IT chargeback is a cost allocation model where business units are billed directly for the technology services they consume. It makes each team accountable for its own cloud, software, and infrastructure spend. What is IT showback? IT showback reports technology costs to business units without actually billing them. It creates visibility and accountability while the central IT budget remains unchanged. When should I use chargeback instead of showback? Use chargeback when you want teams to actively optimize their own spend because they control the budget. Use showback first when the goal is visibility and behavior change without changing budget ownership. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # IT Chargeback and Showback for AI: A Practical Guide · FinOps LLM URL: https://finopsllm.com/research/it-chargeback-showback-ai IT chargeback and showback for AI Updated 1 August 2026 AI spend does not behave like traditional IT spend. A single prompt can cost fractions of a cent or several dollars depending on model choice, context size, and reasoning depth. A feature launch can multiply monthly AI costs overnight. That volatility makes chargeback and showback more important for AI than for almost any other technology category. The AI-specific case for allocation Without allocation, AI costs sit in a central budget where no one feels ownership. Product teams optimize for engagement and capability; infrastructure teams optimize for reliability. Cost falls between the two. Chargeback and showback fix this by making AI spend visible to the people who can influence it. AI workloads are particularly well suited to allocation because: Usage is measurable at the request level. Costs map clearly to features, teams, or customer cohorts. Teams have real levers: model tier, prompt design, caching, batching, and routing. Small optimizations repeated at scale produce large savings. Showback first: why almost every AI program starts here Showback is the right starting point for most AI FinOps programs. It lets teams see their footprint without the political friction of budget transfer. This matters because AI cost attribution is harder than it looks in the beginning. Common showback challenges for AI include: Shared models. A single endpoint may serve multiple teams or products. Prompt context. The same system prompt may be reused across features, making per-feature attribution fuzzy. Experimentation. Research and prototype spend can spike and then disappear, distorting monthly averages. Provider invoices. Cloud marketplaces and resellers can delay or obscure usage detail. Showback surfaces these issues before anyone's budget is at stake. It gives finance and engineering time to agree on allocation rules. Moving to chargeback for controllable AI services Once showback is stable, the most controllable AI services can move to chargeback. Good early candidates include: Direct LLM API usage. Teams can control model choice, prompt length, and caching. Production inference. Stable workloads with clear feature ownership. Agent workloads. Teams can add guardrails, retry caps, and model-tier ceilings. Batch and evaluation jobs. Non-urgent workloads that can be scheduled and optimized. Keep showback for shared foundation models, platform infrastructure, and research sandboxes where precise allocation is unfair or impossible. Implementation checklist Tag every AI request. Capture team, feature, environment, model, provider, and request type. Build a cost allocation model. Decide how shared costs are split: by request count, token volume, or negotiated rule. Run showback for one quarter. Distribute reports, collect feedback, and fix data quality issues. Define chargeback candidates. Identify services with clean attribution and controllable usage. Agree on budget mechanics. Work with finance to decide how charged-back costs flow into team budgets. Automate the pipeline. Export monthly chargeback and showback reports to NetSuite, QuickBooks, CSV, or API. Avoid the most common mistakes The biggest mistake is charging back costs that teams cannot control. If a team is forced to use a shared model with no ability to choose a cheaper alternative, chargeback becomes a tax, not a lever. The second biggest mistake is allocating too finely too early. Start with a few dimensions that everyone trusts, then add granularity as the data improves. The goal is not perfect allocation. The goal is fair enough allocation that teams change behavior. Showback gets you there safely; chargeback locks in the accountability. Related Chargeback vs showback — the foundational comparison. Why showback comes before chargeback — the migration path. LLM chargeback and showback — technical implementation details. Agent spend guardrails — controls for agentic AI workloads. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is IT chargeback for AI? IT chargeback for AI bills business units directly for the AI services they consume, such as LLM API calls, inference compute, and vector storage. It moves budget ownership to the team that controls usage. What is IT showback for AI? IT showback for AI reports AI costs to business units without billing them. It creates visibility into which teams, features, and experiments drive spend while the central IT budget remains unchanged. Should we start with chargeback or showback for LLM spend? Most enterprises start with showback for AI because LLM costs are new, spiky, and hard to allocate precisely. Once tagging is trusted and teams understand their usage, they move the most controllable services to chargeback. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # IT Showback: A Practical Guide for Technology Teams · FinOps LLM URL: https://finopsllm.com/research/it-showback IT showback IT showback is the gentlest form of cost allocation. It shows business units what they consume without moving the bill. The goal is transparency and behavior change, not budget transfer. How showback works Every month, each team receives a report: their cloud spend, broken down by service, project, and environment. The central IT budget still pays the provider, but the team now sees its footprint. Over time, this creates the cultural conditions for optimization. When showback is the right choice Early FinOps maturity. Your organization is just starting to think about cloud cost accountability. Untrusted data. Tagging and attribution are new; you need time to clean them. Shared services. Some costs are genuinely hard to assign precisely. High political sensitivity. Charging teams directly would create friction before the value is proven. How to implement showback Tag every resource with team, project, and environment. Build a dashboard or report that allocates spend by tag. Distribute the report monthly at first, then weekly as maturity grows. Pair the report with education: explain what drives the numbers and how teams can influence them. From showback to chargeback Showback is usually a stepping stone. Once teams trust the data and have learned to act on it, the most controllable services can move to chargeback. For the full comparison, see showback vs chargeback . What belongs in a showback report? A report that only shows a number gets ignored. A report teams act on contains four things: Spend with a comparison — this month against last month and against budget. An absolute number carries no signal. A unit metric — cost per request, per customer, or per deploy. Teams that ship more should spend more; unit cost is what tells you whether that is happening efficiently. The top three drivers — the specific services or workloads behind the change, not a full inventory. One action — a named, concrete thing the team can do this month. Without it, the report is trivia. How long should showback run before chargeback? Long enough that teams stop disputing the data, typically two to three reporting cycles. The signal to move is behavioral: when teams start asking for their numbers before you send them, and when challenges shift from "this allocation is wrong" to "this allocation is right and we want to reduce it," the data has earned enough trust to carry money. Does showback actually change behavior? Only when it reaches the person who can act. A report addressed to a director who does not choose instance types or model tiers produces agreement and no change. Send it to the engineering team that owns the service, and copy the budget holder — visibility works through the owner, not the org chart. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is IT showback? IT showback is a cost allocation model that reports technology spending to business units without actually charging them. It creates visibility while keeping the central IT budget intact. When should you use showback? Use showback when you want to build cost awareness and accountability before moving to chargeback. It is ideal for early FinOps journeys and shared services. How do you move from showback to chargeback? Move to chargeback once tagging is trusted, teams understand their spend, and leadership is ready to transfer budget ownership for controllable services. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Where Jev belongs in an agent workflow · FinOps LLM URL: https://finopsllm.com/research/jev-agent-controls-and-budgets Where Jev belongs in an agent workflow Updated September 21, 2026 · first published September 21, 2026 Quick answer: The cleanest way to use Jev is to give it the choices a workflow has already defined. An agent can use it to select a tool, classify an incoming request, score a proposed action against a policy, or... The cleanest way to use Jev is to give it the choices a workflow has already defined. An agent can use it to select a tool, classify an incoming request, score a proposed action against a policy, or decide whether it has enough evidence to continue. These are decisions with a known answer space. They are not requests for a model to invent a plan or write a customer-facing explanation. This division of labour appears repeatedly in early Jev work: an LLM writes or reasons; Jev decides; application code acts. It is a practical architecture, not a slogan. Each component has a job that matches its interface. Four places where the model fits Routing: choose the right model, specialist, queue, or workflow from declared options. Guardrails: decide whether a proposed agent action is routine, needs confirmation, or should stop. Triage: score urgency and ownership from incident, support, or operations state. Compaction: select the facts or unresolved questions the next model step needs. Vercel's agent-loop example adds an important detail: the decision layer does not own permission checks, argument validation, retry policy, or the tool call. Those remain ordinary code. That gives teams a stable policy boundary while letting Jev handle the fuzzy judgment inside it. Confidence is the handoff Jev's confidence value creates a useful three-way split. High-confidence, low-risk decisions can continue immediately. Medium-confidence cases can collect one more fact or use a stronger model. Low-confidence or high-impact cases can stop for review. This is where Jev's calibration matters: the workflow receives a probability it can turn into a policy, instead of guessing how much faith to put in model prose. That policy needs to be versioned and measured. Record the state, question version, answer, probability, selected path, and final outcome. Then measure which threshold gives the best combination of automation, accuracy, and cost. A fixed 0.9 rule is less useful than a threshold backed by your own error tolerance and real outcomes. Budget the workflow once Jev can make individual decisions cheap enough to use repeatedly. That is a benefit, but it means the economic unit must be the finished task. A task budget should cover the Jev calls, model generations, retrieval, tool fees, retries, and review work. Count decisions per completed task alongside cost per completed task. If a new decision layer produces more useful completions at a lower total cost, it is working. If it just adds branches, adjust the stop rule. Jev is not a replacement for the rest of an agent stack. It is a specialist for the part that agents do constantly: make a bounded judgment and move on. Related Three budgets every agent needs Background agents run on a cost clock Web search is becoming an agent cost center Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Why Jev is catching on with agent builders · FinOps LLM URL: https://finopsllm.com/research/jev-ai-finops-decision-economics Why Jev is catching on with agent builders Updated September 21, 2026 · first published September 21, 2026 Quick answer: Jev is catching on because it gives software something chat models were never designed to provide: a fast, typed decision that code can use immediately. Rather than generating text, Jev receives state... Jev is catching on because it gives software something chat models were never designed to provide: a fast, typed decision that code can use immediately. Rather than generating text, Jev receives state plus a declared set of questions and returns Choices, Scores, or Boolean probabilities. Vercel says it reached nearly 13% of paid AI Gateway teams in its first 24 hours—more than twice the adoption of any prior model launch. The attraction is not that it replaces every LLM. It is that most agent loops contain decisions that do not need a paragraph: which tool to call, whether an action needs review, whether enough evidence has been gathered, or where a ticket should go. A general model can make those decisions, but it usually emits text or JSON first. Jev is built for the decision itself. What people are using it for The same four use cases recur across early implementations: routing work to the right model or agent; guarding tool calls; triaging queues; and deciding what information should survive into the next step of a long-running workflow. These are frequent, bounded forks in a system. They are also exactly where a bad output format or a slow model becomes operationally expensive. Vercel's agent-control guide puts the split clearly: the model evaluates the state, while ordinary application code owns permissions, validation, retries, and tool execution. Jev makes the first part cheaper and easier to compose. It does not turn a model decision into an access-control rule. The FinOps change is a new decision tier TypeSafe lists Jev at $0.042 per million input tokens with free output. That pricing matters because decision steps often appear many times inside an agent workflow. An independent live-API project measured eight representative calls at roughly $0.000015–$0.000025 each, with a median 352 ms response time in its head-to-head tests. The data and method are published in jev-measured . That does not mean “Jev is 400 times cheaper than an LLM” in every deployment. The same project found that a fast, cheap structured-output model was only 1.4–1.7 times more expensive on its small fixtures; the much larger gap appeared against GPT-5 Nano, which spent output tokens reasoning. The honest conclusion is better: Jev creates a low-cost decision tier for cases where an agent needs judgment without generation. Trust is the product feature The most interesting part of Jev is its confidence signal. The model returns a probability with the answer, allowing a workflow to auto-route clear cases and send uncertain ones to a slower model or a person. That is how “trust” becomes useful in software: not by pretending every answer is certain, but by making uncertainty available to the code that has to act. For FinOps teams, the measurement is simple. Track which expensive calls the decision layer avoids, the share of cases it escalates, and cost per completed workflow. Jev earns its place when it lets the system make more small decisions cheaply, quickly, and with a clear path for the uncertain ones. Related Model price cuts and the routing budget Agent total cost of ownership Cost per successful task Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Six Jev use cases that actually fit · FinOps LLM URL: https://finopsllm.com/research/jev-use-cases-that-fit Six Jev use cases that actually fit Updated September 21, 2026 · first published September 21, 2026 Quick answer: Jev is useful when the system already knows what its possible next actions are. The model's job is to select or score among them from messy context. That rules out a lot of fashionable “AI use cases”... Jev is useful when the system already knows what its possible next actions are. The model's job is to select or score among them from messy context. That rules out a lot of fashionable “AI use cases” and leaves a smaller, more useful list. 1. Route work before generation Choose the model, specialist, or queue before spending on a full generation. A request can go to Billing, Technical, Sales, or Review; a coding task can go to a fast edit path, a deep investigation, or a human. Each route has a known next action and cost. 2. Gate a proposed tool call Give Jev the proposed action, policy text, and current state. Ask whether the action is routine, needs confirmation, or should stop. Code then checks the caller's permission and validates the arguments. 3. Triage support and operations queues One call can assign an owner, score urgency, and flag insufficient evidence. That is more useful than asking a chat model for a paragraph summary and hoping downstream code extracts the same answers every time. 4. Score risk before escalating For transaction review, moderation, security alerts, or document exceptions, use Jev to separate clear low-risk cases from those that need a slower investigation. The decision model does not approve a transaction or block an account; it makes the first sorting decision cheap enough to run on every item. 5. Select context for the next agent step Long-running agents accumulate notes, tool output, and stale plans. Jev can rank which facts remain relevant, whether the last step changed the state, and whether the task has enough evidence to finish. 6. Verify a generated result against a rubric After an LLM writes an answer, Jev can score whether it contains required fields, follows a specified rule, or needs a repair pass. Keep the rubric concrete: “Does it name the affected customer, remediation owner, and next update time?” is actionable; “Is this good?” is not. These patterns match Vercel's documented examples and the early community implementations. State goes in, typed decisions return, and code chooses what happens next. The common thread is a decision boundary that a system can name, measure, and improve. Related How to use Jev in an AI agent Where Jev belongs in an agent workflow Web search is becoming an agent cost center Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Latest AI models and Anthropic's proposed IPO · FinOps LLM URL: https://finopsllm.com/research/latest-models-anthropic-ipo-finops Latest AI models and Anthropic's proposed IPO Updated September 30, 2026 · first published September 30, 2026 Quick answer: Two September developments deserve separate lines in an AI budget: new model rate cards and Anthropic's proposed IPO. The model launches give buyers prices and capabilities they can test now. The IPO... Two September developments deserve separate lines in an AI budget: new model rate cards and Anthropic's proposed IPO. The model launches give buyers prices and capabilities they can test now. The IPO process gives no confirmed listing date, share price, or automatic change to Claude API terms. Mixing those stories leads to poor forecasts. What the latest models actually change These are published standard API text-token list rates per million tokens, as checked on September 30, 2026. They are not rankings of cost per successful task. Cache, long context, processing tier, tools, retries, and quality can change the result. Model Release Input / output Budget implication Claude Sonnet 5.5 Sep 28 $2 / $10 Same base rates as Sonnet 5. Anthropic claims up to 30% lower cost per task through token efficiency; measure that on your workload. Claude Opus 5.5 Sep 22 $4 / $20 Base input and output rates are 20% below Opus 5; cache reads are $0.20 per million. Re-evaluate premium routes rather than applying a blanket discount. GPT-6.1 Sol Sep 29 $2 / $10 Its listed cached-input rate is $0.10 per million and cache writes are $2.50. Check the actual read/write mix before comparing it with Sonnet. OpenAI's dated changelog records the GPT-6.1 Sol release. Its model page says prompts above 272,000 input tokens receive higher rates for the full request. Anthropic's launch pages describe Sonnet's cost-per-task and Opus's performance claims as results from its own testing, not guarantees for every application. Make the model decision with a task ledger For each workload, log the exact model ID, input and output tokens, cache reads and writes, effort setting, separately charged tools, retries, latency, and whether the result was accepted. Replay the same representative tasks on the candidate models. Then compare cost per accepted task , not only the cheapest input price. A lower token rate can be erased by extra steps or failed outputs; a faster model may improve latency without reducing a token-metered bill. Use Sonnet 5.5 as a candidate for well-scoped work and Opus 5.5 for complex work requiring sustained judgment—the roles Anthropic describes—but keep a quality threshold and rollback route. Test GPT-6.1 Sol on the same tasks and context sizes. Do not assume two $2/$10 rate cards produce the same invoice when their cache, long-context, and tool rules differ. For the detailed mechanics, see our Sonnet 5.5 cost model and Opus 5.5 cost model . What Anthropic has actually said about an IPO On June 1, Anthropic announced that it confidentially submitted a draft Form S-1 to the U.S. Securities and Exchange Commission for a proposed IPO. The company said that gives it the option to go public after SEC review, subject to market conditions and other factors. It also said the number of shares and their price had not been set. A confidential submission is not a public prospectus, and the announcement is not a completed listing. As of this article's September 30 check, Anthropic's first-party announcement does not confirm a ticker, valuation, trading date, or final offering terms. Headlines about those items should not be entered into a procurement forecast as facts. We also should not infer from an IPO proposal that Claude API rates will rise or fall: the announcement does not change the published model rate cards. That is a boundary on what is known, not a prediction about future pricing. What an AI buyer should do now Update the rate card. Version prices by model, date, cache category, context size, and processing tier. Recheck provider documentation before approving a contract or forecast. Run a controlled migration test. Keep prompts, task mix, and success criteria comparable across Sonnet 5.5, Opus 5.5, and GPT-6.1 Sol. Record both invoice-equivalent cost and acceptance rate. Separate commercial risk from release hype. Track contract renewals, capacity commitments, service levels, and data-residency needs directly. Do not use an unconfirmed IPO valuation as a proxy for supplier reliability or future API price. Revisit the IPO only when terms are public. A public filing or Anthropic announcement can change the picture; until then, keep IPO scenarios labeled as scenarios. The practical takeaway is simple: model launches can change unit economics today, but a proposed IPO is not itself a new API price. Budget from measured workloads and published terms, then update the assumptions when primary documents change. Questions teams ask Has Anthropic confirmed an IPO date? No date appears in Anthropic's announcement of its confidential draft S-1. It describes a proposed offering that depends on SEC review, market conditions, and other factors. Is Sonnet 5.5 cheaper per token than Sonnet 5? No. Anthropic lists the same $2 input and $10 output rates per million tokens. Its up-to-30% lower per-task cost claim depends on its reported token efficiency and must be tested on your work. Will an Anthropic IPO change Claude API pricing? There is no such change in Anthropic's IPO announcement. Treat any future pricing effect as unknown until Anthropic publishes new commercial terms. Related Sonnet 5.5 pricing and task cost Opus 5.5 cost model Cost per successful task Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # OpenAI & Claude API Pricing Tracker (Live) · FinOps LLM URL: https://finopsllm.com/research/llm-api-pricing-tracker LLM API Pricing Tracker: OpenAI, GPT-6 and Claude Prices Updated 22 September 2026 · first published 4 July 2026 OpenAI API pricing and Claude API pricing in one normalised table: input, output, cache read/write, context windows and batch discounts per 1 million tokens. The OpenAI and Anthropic rows are refreshed live from each provider's own pricing page, so GPT pricing and Claude pricing here match what you are billed, and new models show up as soon as they are listed. This is API pricing only. ChatGPT and Codex subscriptions are separate monthly plans; see the FAQ below for how they relate. 12+ Providers tracked 25+ Models listed 6 Price columns Sep 2026 Last updated All prices in USD per 1 million tokens Estimated values shown in gray Cache prices reflect prompt caching where available Methodology Collection Pricing data collected from official provider pricing pages and API documentation. Normalisation All prices normalised to USD per 1 million tokens for direct comparison. Cache pricing Cache Read/Write columns show prompt caching discounts where providers support them. Display policy Official values and estimated values are clearly separated. Estimates marked in gray. Update Feed Sep 22, 2026 GPT-6 and Claude Opus 5.5 added; models now discovered automatically Added GPT-6-Astra ($10/$50), GPT-6-Sol ($2/$10), GPT-6-Luna ($0.10/$0.50) and Claude Opus 5.5 ($4/$20). Dropped GPT-5.6-Terra and GPT-5.6-Luna, which OpenAI no longer lists. Any model OpenAI or Anthropic adds to its pricing page now appears in the table automatically. Jul 4, 2026 LLM API Pricing Tracker launched Published per-token pricing comparison across 12+ major LLM providers as a FinOps LLM research article. Per-Token Pricing Table Provider ↕ Model ↕ Input $/1M ↕ Output $/1M ↕ Cache Read $/1M ↕ Cache Write $/1M ↕ Context Window ↕ Batch Discount OpenAI GPT-6-Astra $10.00 $50.00 $1.00 $12.50 — 50% OpenAI GPT-6-Sol $2.00 $10.00 $0.20 $2.50 — 50% OpenAI GPT-6-Luna $0.10 $0.50 $0.01 $0.125 — 50% OpenAI GPT-5.6-Sol $4.00 $20.00 $0.40 $5.00 1.05M 50% Anthropic Claude Fable 5.1 $10.00 $50.00 $0.25 $12.50 1M 50% Anthropic Claude Opus 5.5 $4.00 $20.00 $0.20 $5.00 1M 50% Anthropic Claude Fable 5 $10.00 $50.00 $1.00 $12.50 1M 50% Anthropic Claude Opus 5 $5.00 $25.00 $0.50 $6.25 1M 50% Anthropic Claude Sonnet 5 * $2.00 $10.00 $0.20 $2.50 1M 50% Anthropic Claude Sonnet 4.6 $3.00 $15.00 $0.30 $3.75 1M 50% Anthropic Claude Haiku 4.5 $1.00 $5.00 $0.10 $1.25 200K 50% Google Gemini 3.8 Flash $0.75 $3.75 $0.075 — — 50% Google Gemini 3.7 Flash $0.75 $3.75 $0.075 — — 50% Google Gemini 3.6 Flash $0.75 $3.75 $0.075 — — 50% Google Gemini 3.5 Flash $1.50 $9.00 $0.15 — — 50% Google Gemini 3.5 Flash-Lite $0.30 $2.50 $0.03 — — 50% Google Gemini 3.1 Flash-Lite $0.25 $1.50 $0.025 — — 50% Google Gemini 3.1 Pro Preview $2.00 $12.00 $0.20 — — 50% Google Gemini 3 Flash Preview $0.50 $3.00 $0.05 — — 50% Google Gemini 2.5 Pro $1.25 $10.00 $0.125 — — 50% Google Gemini 2.5 Flash $0.30 $2.50 $0.03 — — 50% Google Gemini 2.5 Flash-Lite $0.10 $0.40 $0.01 — — 50% xAI grok-4.7 $2.00 $6.00 $0.50 — 500K — xAI grok-build-0.1 $1.00 $2.00 $0.20 — 256K — xAI grok-4.6 $2.00 $6.00 $0.50 — 500K — xAI grok-4.5 $2.00 $6.00 $0.30 — 500K — xAI grok-4.3 $1.25 $2.50 $0.20 — 1M — xAI grok-4.20-multi-agent-0309 $1.25 $2.50 $0.20 — 1M — xAI grok-4.20-0309-reasoning $1.25 $2.50 $0.20 — 1M — xAI grok-4.20-0309-non-reasoning $1.25 $2.50 $0.20 — 1M — Meta Llama 4 Maverick (DeepInfra) $0.20 $0.80 - - 1M - Meta Llama 4 Scout (Groq) $0.11 $0.34 - - 5M - Meta Llama 3.3 70B (Groq) $0.59 $0.79 - - 8M - Mistral Mistral Large 2/3 $2.00 $6.00 - - 128K - Mistral Mistral Medium 3.5 $1.50 $7.50 - - 128K - Mistral Mistral Small 3 $0.10 $0.30 - - 128K - Mistral Codestral $0.30 $0.90 - - 128K - DeepSeek deepseek-flash $0.30 $1.20 $0.006 — 1M — DeepSeek deepseek-v4-pro $1.32 $3.96 $0.044 — 1M — Alibaba Qwen Qwen 3.7-Max $2.50 $7.50 - - 131K - Moonshot Kimi Kimi K2.6 $0.95 $4.00 $0.16 - 200K - Xiaomi MiMO Sign up - both get $2 ↗ MiMo-V2-Pro $0.50 $2.00 - - 128K - Xiaomi MiMO Sign up - both get $2 ↗ MiMo-V2-Omni $0.40 $1.60 - - 128K - Zhipu AI GLM-5 $1.00 $4.00 - - 128K - Zhipu AI GLM-5-Turbo $0.30 $1.20 - - 128K - MiniMax M2.7 $0.40 $1.60 - - 128K - StepFun step-3.5-flash $0.30 $1.20 - - 128K - * Claude Sonnet 5 is $2/$10 per 1M tokens permanently — the increase to $3/$15 that had been scheduled for 1 September 2026 was cancelled. Cache-write figures are the 5-minute TTL; the 1-hour TTL costs 2× the base input rate. Claude Opus 4.8, 4.7 and 4.6 share Claude Opus 5 pricing. Claude 4.7 and newer use a tokenizer that produces roughly 30% more tokens for the same text, so compare cost per task, not cost per token. Values not explicitly provided by providers are shown in gray . Meta Llama prices reflect hosted API pricing (Fireworks, Together, etc.), not self-hosted cost. Self-hosting economics are covered in our Open-Source vs Closed-Source Cost Comparison . Context windows are maximum supported; actual availability may vary by tier. Cache Read/Write pricing reflects provider-specific prompt caching where available. "-" means the provider does not offer caching or pricing is not published. Batch Discount shows the approximate savings when using batch/async APIs where available. Some links may include referral codes. Prices can change frequently. Always verify the latest information on official provider pages. Practical Guide How to use this pricing data for cost planning 1) Calculate your token volume first Before comparing prices, estimate your monthly input and output token volumes. Output tokens are typically 3-5x more expensive than input, so reducing output length has the biggest impact on cost. 2) Factor in caching savings If your workload has repeated system prompts or context (RAG, multi-turn conversations), prompt caching can reduce input costs by 50-90%. Check the Cache Read column for applicable discounts. 3) Use batch APIs for non-urgent work Most major providers offer 50% discounts on batch/async API calls. If your workload tolerates latency (evaluations, data processing, content generation), batch pricing cuts costs in half. 4) Compare total cost, not just per-token price A cheap model that needs 3x more tokens to match quality may cost more overall. Factor in model quality and task-specific performance alongside raw pricing. Next step: Compare your spend across providers—see Azure OpenAI vs Direct OpenAI Cost for a breakdown of managed vs direct pricing models. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is the current OpenAI API pricing? Per 1 million tokens at standard rates: GPT-6-Astra costs $10 input and $50 output, GPT-6-Sol $2 input and $10 output, GPT-6-Luna $0.10 input and $0.50 output, and GPT-5.6-Sol $4 input and $20 output. Cached input is billed at a tenth of the input price, and the Batch API is 50% off. How much does GPT-6 cost? GPT-6 comes in three tiers. Astra is $10 per million input tokens and $50 per million output tokens, Sol is $2 and $10, and Luna is $0.10 and $0.50. Above the long-context threshold Astra rises to $20 input and $75 output, and Sol to $4 and $15. What is Claude API pricing? Per 1 million tokens: Claude Fable 5.1 is $10 input and $50 output, Claude Opus 5.5 is $4 and $20, Claude Sonnet 5 is $2 and $10, and Claude Haiku 4.5 is $1 and $5. Prompt-cache writes cost 1.25x input for a 5-minute cache, and the Message Batches API is 50% off. How much does Claude Opus 5.5 cost? Claude Opus 5.5 is $4 per million input tokens and $20 per million output tokens, with cache hits at $0.20 and 5-minute cache writes at $5. Batch processing halves that to $2 and $10. Fast mode costs $8 input and $40 output. Is ChatGPT or Codex pricing the same as OpenAI API pricing? No. ChatGPT and Codex subscriptions are flat monthly plans with usage limits, billed separately from the API. The OpenAI API bills per token on your platform account, at the rates in this table, whether the calls come from your own app or from Codex signed in with an API key. How often are these prices updated? The OpenAI and Anthropic rows are read from each provider's published pricing page and are never more than six hours old. New models either provider lists are added automatically. If a page fails our sanity checks, the table falls back to the last verified prices rather than showing a guess. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Your LLM bill has an FX problem · FinOps LLM URL: https://finopsllm.com/research/llm-bill-fx-exposure Currency exposure in LLM spend Updated September 1, 2026 · first published September 1, 2026 Quick answer: Almost every frontier model is priced in US dollars. If your budget is not in dollars, part of your LLM cost line is a currency position you never chose to take.A 6% move in EUR/USD is a 6% increase... Almost every frontier model is priced in US dollars. If your budget is not in dollars, part of your LLM cost line is a currency position you never chose to take. A 6% move in EUR/USD is a 6% increase in what your model spend costs you, with no change in token volume, no change in model, and nothing in any usage dashboard to explain it. Finance sees the variance. Engineering, looking at a dashboard denominated in tokens, sees a flat month and cannot help. Why it hides so well Three layers of translation sit between the API call and the ledger. The provider prices per million tokens in USD. The card or invoice converts at some rate, on some date, with some spread. Your accounting system books it at yet another rate. By the time the number reaches a variance report, the FX component and the usage component are the same figure. Cloud marketplaces make it worse, not better. Buying through a reseller or a cloud marketplace in local currency looks like it removes the exposure. It usually just moves the conversion upstream and adds a margin to it — you are still exposed, you have simply stopped being able to see the rate. Separate the two variances The fix is small and entirely a reporting change. Record every request's cost in USD at the provider's list rate , as the primary figure, in telemetry. Convert to your reporting currency once, at a stated rate, at the reporting boundary. Then a monthly variance splits cleanly into a usage variance, which engineering owns and can act on, and an FX variance, which treasury owns and engineering cannot fix. Two teams arguing about one number is the actual cost here. It is more expensive than the currency move, because it wastes the review that was supposed to find the real growth. When it is worth hedging Rarely, and only at scale. For most companies the correct response is visibility, not a hedge: know the size of the exposure, state the rate you forecast at, and stop letting a treasury effect masquerade as an engineering one. Hedging becomes a real conversation when model spend is large enough to matter next to the company's other dollar costs — at which point it belongs with those, not in a FinOps review. One practical note: if you renegotiate to a local-currency contract, price the conversion. A committed rate in your own currency is worth paying a little for, and worth nothing if the spread hidden inside it is larger than the volatility it removes. Related AI spend variance bridge How to budget for AI spend LLM purchasing guide Related AI spend variance bridge How to budget for AI spend LLM purchasing guide Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # LLM Budget Governance: Alerts and Guardrails · FinOps LLM URL: https://finopsllm.com/research/llm-budget-governance LLM budget governance Updated 12 July 2026 · first published 5 May 2026 LLM budget governance should prevent invoice surprises without creating a permission bottleneck for every AI feature. The goal is guardrails and ownership, not central approval for every prompt change. A good budget model separates experimentation, production traffic, evals, and background jobs. Each category needs a different tolerance. Experimentation can be capped tightly. Production needs alerts and graceful degradation. Evals and enrichment can often move to batch lanes. Governance primitives Monthly budgets by team and product surface. Daily burn-rate alerts for fast-moving workloads. Hard caps for experiments and test environments. Router policies that degrade to cheaper models where safe. Review cadence tied to invoice reconciliation. Policy design Policies should be specific enough to act on. “Reduce LLM spend” is not a policy. “Support summarization must use batch for nightly reprocessing,” “RAG context is capped at N chunks unless approved,” and “frontier model use requires a route reason” are policies teams can implement. Budget governance works when it is visible in the engineering workflow. Owners should see spend impact near deploys, prompt changes, and route-policy edits rather than waiting for finance to send a month-end report. Related Token budget implementation - engineering patterns for enforcement. Eval cost allocation - budgeting evals as a separate cost center. LLM chargeback and showback - moving cost to owners. LLM cost attribution - allocation foundations. What happens when a budget is breached? Decide this before it happens, because the decision made mid-incident is always "turn it off," and that is rarely right. Define the response per workload class: Experiments and test environments — hard stop. The cap is the point. Background jobs — pause and queue. Nightly enrichment can run tomorrow. Production user traffic — degrade, never stop. Route to a cheaper model, shorten the context window, or drop optional enrichment steps, and log that you did so. Revenue-critical paths — alert and keep spending. Some overruns are a good problem; the budget was wrong, not the traffic. Who owns an LLM budget? The team that can change the spend, which is the engineering team that owns the endpoint, not finance and not a central AI platform group. Finance sets the envelope and reconciles it; the owning team chooses the model, the context length, and the retry policy. A budget assigned to someone with no ability to move the number produces escalation, not savings. How often should budgets be revisited? Monthly against actuals, quarterly against the plan. LLM budgets go stale faster than infrastructure budgets because provider pricing, model tiers, and your own traffic mix all move — a budget set on last quarter's price list will be wrong in both directions, and the overruns get attention while the underruns quietly fund nothing. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is the goal of LLM budget governance? LLM budget governance should prevent invoice surprises without creating a permission bottleneck for every AI feature. The goal is guardrails and ownership, not central approval for every prompt change. What are the governance primitives for LLM budgets? Governance primitives include: monthly budgets by team and product surface, daily burn-rate alerts for fast-moving workloads, hard caps for experiments and test environments, router policies that degrade to cheaper models where safe, and review cadence tied to invoice reconciliation. How should budget governance policies be designed? Policies should be specific enough to act on. 'Reduce LLM spend' is not a policy. 'Support summarization must use batch for nightly reprocessing,' 'RAG context is capped at N chunks unless approved,' and 'frontier model use requires a route reason' are policies teams can implement. Owners should see spend impact near deploys, prompt changes, and route-policy edits rather than waiting for month-end reports. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # LLM Chargeback and Showback: Design Guide · FinOps LLM URL: https://finopsllm.com/research/llm-chargeback-showback LLM chargeback and showback Updated 12 July 2026 · first published 5 May 2026 Showback reports LLM spend to the teams and products that caused it. Chargeback assigns that spend to their budgets. Most organizations should start with showback because teams need time to trust the numbers before those numbers affect budget decisions. The challenge is allocation accuracy. A simple provider bill cannot tell you which feature, tenant, or team produced a token. You need request metadata from the gateway, application, or orchestration layer. Without that metadata, chargeback becomes a political argument instead of an operating system. Good showback reports Break spend down by product area and team owner. Show the top workloads and month-over-month changes. Separate model price changes from traffic growth. Identify optimization candidates owned by each team. Keep unallocated spend visible. When to charge back Chargeback makes sense once attribution coverage is high and teams can influence the cost drivers. Do not charge teams for untagged shared infrastructure, stale price tables, or central platform decisions they cannot change. A strong model uses showback for education, then chargeback for mature cost centers. It also protects experimentation budgets so teams do not avoid useful AI features simply because early traffic is hard to predict. Related LLM budget governance - budgets and guardrails. LLM cost attribution - allocation foundations. Chargeback vs showback - choosing the right model. Showback comes before chargeback - the migration path. IT chargeback and showback for AI - the enterprise view. What is LLM FinOps? - the complete operating discipline. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is the difference between showback and chargeback? Showback reports LLM spend to the teams and products that caused it. Chargeback assigns that spend to their budgets. Most organizations should start with showback because teams need time to trust the numbers before those numbers affect budget decisions. What should good showback reports include? Good showback reports should: break spend down by product area and team owner, show the top workloads and month-over-month changes, separate model price changes from traffic growth, identify optimization candidates owned by each team, and keep unallocated spend visible. When does chargeback make sense? Chargeback makes sense once attribution coverage is high and teams can influence the cost drivers. Do not charge teams for untagged shared infrastructure, stale price tables, or central platform decisions they cannot change. A strong model uses showback for education, then chargeback for mature cost centers, and protects experimentation budgets so teams do not avoid useful AI features. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # LLM Cost Attribution by Team, Product and Tenant · FinOps LLM URL: https://finopsllm.com/research/llm-cost-attribution LLM cost attribution Updated 12 July 2026 · first published 5 May 2026 LLM cost attribution is the bridge between provider invoices and operational decisions. Providers bill by account, model, token class, and sometimes region or feature. Businesses need to understand cost by team, product, customer, workflow, and unit of value. The attribution layer connects those two views without losing reconciliation to the raw invoice. The key is to tag requests before they reach the provider or gateway. Logs created after the fact are usually incomplete. At minimum, every production LLM call should carry a stable endpoint name, environment, team owner, product surface, workload class, and correlation ID. Where contracts allow it, add tenant or customer ID. For agent workflows, tag each tool call or model step separately. Request count is not attribution Allocating spend by request count is almost always wrong. One long-context reasoning request can cost more than hundreds of short classification calls. Attribution needs token classes and model pricing. It also needs retry and fallback data, because a “successful” response may hide three failed upstream calls. Recommended dimensions Provider, model, and model version where available. Input, output, cache-write, cache-read, and batch token classes. Team, product, feature, endpoint, and environment. Workload class: realtime user path, background job, eval, enrichment, agent step, support workflow, or analytics task. Customer or tenant attribution when permitted by privacy and contract boundaries. Invoice reconciliation Attribution must reconcile back to the provider invoice. Expect small differences from rounding, delayed invoice lines, and provider-specific discounts, but large gaps mean the log pipeline is missing traffic or using stale price tables. The finance view should show both allocated spend and unallocated spend so data-quality issues are visible. From showback to action The first output should be showback: which teams and product surfaces are driving spend, and which workloads changed since last month. Once teams trust that data, use it to rank optimization work. Attribution is valuable because it points directly at the owners who can approve routing, caching, or prompt changes. Related OpenAI cost attribution - OpenAI-specific attribution patterns. LLM chargeback and showback - moving cost to owners. What is LLM FinOps? - the complete operating discipline. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is LLM cost attribution? LLM cost attribution is the bridge between provider invoices and operational decisions. Providers bill by account, model, token class, and sometimes region or feature. Businesses need to understand cost by team, product, customer, workflow, and unit of value. The attribution layer connects those two views without losing reconciliation to the raw invoice. Why is allocating spend by request count almost always wrong? One long-context reasoning request can cost more than hundreds of short classification calls. Attribution needs token classes and model pricing. It also needs retry and fallback data, because a 'successful' response may hide three failed upstream calls. What are the recommended dimensions for LLM cost attribution? Recommended dimensions include: provider, model, and model version; input, output, cache-write, cache-read, and batch token classes; team, product, feature, endpoint, and environment; workload class (realtime user path, background job, eval, enrichment, agent step, support workflow, or analytics task); and customer or tenant attribution when permitted. How should attribution relate to invoice reconciliation? Attribution must reconcile back to the provider invoice. Expect small differences from rounding, delayed invoice lines, and provider-specific discounts, but large gaps mean the log pipeline is missing traffic or using stale price tables. The finance view should show both allocated spend and unallocated spend so data-quality issues are visible. How does attribution enable optimization action? The first output should be showback: which teams and product surfaces are driving spend, and which workloads changed since last month. Once teams trust that data, use it to rank optimization work. Attribution is valuable because it points directly at the owners who can approve routing, caching, or prompt changes. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # LLM Cost Benchmarks by Industry · FinOps LLM URL: https://finopsllm.com/research/llm-cost-benchmarks-by-industry LLM Cost Benchmarks by Industry Updated 12 July 2026 Modeled monthly LLM inference costs across key industries and company sizes. These scenarios are calculated from published pricing lists and typical token consumption patterns. Use them to estimate your own spend and identify optimization opportunities. Modeled scenarios from published pricing, not customer data Input/output token ratios based on typical workload patterns Batch API discounts shown separately All prices current as of July 2026 Methodology Pricing Source All pricing extracted from official LLM provider documentation. Input and output rates are current July 2026. Token Volumes Modeled token consumption based on industry-typical workload sizes (queries, documents, chat turns). Model Selection Mid-tier models selected for each scenario (e.g., GPT-5.5, Claude Opus 4.8, Gemini 3.5 Flash). Display Policy Scenarios marked as modeled. Your actual costs will vary based on model choice and optimization. E-Commerce & SaaS (Customer Support) Customer support teams use LLMs to draft responses, classify tickets, and generate knowledge base articles. Token volume scales with ticket volume and response length. Company Size Tickets/Month Modeled Input Tokens Modeled Output Tokens Claude Opus 4.8 GPT-5.5 Gemini 3.5 Flash Startup (10-person) 500 2.5M 5.0M $137.50 $162.50 $48.75 Scale-up (50-person) 2,500 12.5M 25.0M $687.50 $812.50 $243.75 Enterprise (500-person) 25,000 125M 250M $6,875.00 $8,125.00 $2,437.50 Calculation Example (Scale-up): 2,500 tickets/month × 5K tokens per ticket = 12.5M input tokens. Responses averaging 10K tokens = 25M output tokens. Claude Opus 4.8: (12.5M × $5/M) + (25M × $25/M) = $62.50 + $625 = $687.50/month at list prices . All figures in this table are pure list-price token costs — real deployments add retries, system prompts, RAG context, and tooling on top; see hidden LLM costs for how to model that overhead. Financial Services (Compliance & Risk) Banks and fintech use LLMs for document analysis, transaction monitoring, and regulatory reporting. Token volume driven by document size and analysis depth. Organization Size Documents/Month Modeled Input Tokens Modeled Output Tokens Claude Opus 4.8 GPT-5.5 Gemini 3.5 Flash Regional Bank 5,000 50M 15M $625.00 $687.50 $162.50 Mid-Tier Fintech 25,000 250M 75M $3,125.00 $3,437.50 $812.50 Large Bank/Institution 100,000 1,000M 300M $12,500.00 $13,750.00 $3,250.00 Note: Financial institutions typically use smaller output ratios (0.3:1 output-to-input) because analysis results are often summary-form. Compliance workloads also benefit significantly from batch API discounts since most processing can accept 12+ hour latency. Healthcare & Biotech (Data Analysis) Healthcare uses LLMs for clinical note summarization, literature review, and research data extraction. High input-to-output ratio due to dense medical texts. Organization Records/Month Modeled Input Tokens Modeled Output Tokens Claude Opus 4.8 GPT-5.5 Gemini 3.5 Flash Clinic (200 patients) 200 15M 3M $150.00 $165.00 $40.50 Hospital System 5,000 375M 75M $3,750.00 $4,125.00 $1,012.50 Research Institute 20,000 1,500M 300M $15,000.00 $16,500.00 $4,050.00 Manufacturing & Supply Chain Supply chain teams use LLMs for demand forecasting, quality inspection via image+text, and supplier communication. Multimodal workloads add complexity. Operation Scale Analyses/Month Modeled Input Tokens Modeled Output Tokens Claude Opus 4.8 GPT-5.5 Gemini 3.5 Flash Single Facility 1,000 8M 4M $140.00 $155.00 $39.00 Multi-Facility (5x) 5,000 40M 20M $700.00 $775.00 $195.00 Global Network 50,000 400M 200M $7,000.00 $7,750.00 $1,950.00 Cost Optimization Levers 1. Model Routing by Workload Route complex reasoning to Claude Opus ($5M in) or GPT-5.5 ($5M in), simple queries to Gemini 3.5 Flash ($1.50M in). Average 30-40% savings if 60% of queries are simple. Typical impact: -$300–$5,000/month depending on baseline. 2. Batch API for Offline Work Apply 50% batch discount to any processing with 12+ hour latency (compliance reviews, nightly reports, async analysis). Most companies can batch 20–40% of workload. Typical impact: -$200–$3,000/month (roughly 10–15% of total if batching half the workload). 3. Prompt Caching for Repeated Inputs Cache long-form context (codebases, PDFs, regulations) with Anthropic prompt caching (90% discount on cache hits after 1-hour write cost). Most orgs can cache 30–60% of input tokens. Typical impact: -$400–$2,000/month for high-volume teams. 4. Output Length Constraints Reduce output token budgets via system prompts. If you can lower average output per query from 500 to 300 tokens, that's a 40% savings on output cost alone. Typical impact: -$300–$2,500/month depending on baseline. How to Use These Benchmarks These scenarios are modeled, not surveys. Your actual costs depend on: Model choice: Switching from Claude Opus to Gemini 3.5 Flash cuts costs by ~75% if the model meets your quality bar. Token efficiency: Shorter prompts and outputs directly lower spend. A 20% reduction in average prompt length saves 20% on input cost. Caching strategy: If 50% of your workload reuses the same context, prompt caching can save 40–50% on those tokens. Batch usage: Batching 40% of your workload saves ~20% of total spend. Team velocity: More users = higher costs, but also more opportunities to optimize per-user cost via routing and caching. For a detailed cost audit specific to your team, see How Much Does GPT-5 Cost? and LLM Cost Calculator . Both offer worked examples and per-model breakdowns. Want to see your actual LLM spend broken down by team and model? FinOps LLM runs a free audit of your AI costs. Book free audit → Back to research FAQ What is the methodology behind these industry benchmarks? These are modeled scenarios calculated from published LLM pricing lists. Each scenario shows estimated monthly spend based on typical token volumes for that company size and industry. Actual costs depend on model choice, caching strategy, and batch API use. How are token volumes estimated? Token volumes are modeled from published industry data and scaled by team size. A single support agent handling 100 queries/day consumes roughly 50K tokens/day (500 tokens per query). These estimates are marked as modeled, not customer data. Why does output cost more than input? All major LLM providers charge 4-6x more per output token than input token. This reflects the computational cost of generating novel text. Reducing output length is the fastest way to lower LLM bills. How do batch discounts impact these figures? Batch API discounts are 50% off input and output for all major providers. If your workflow supports 12+ hour latency, applying batching to 30% of workload cuts monthly spend by ~15%. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # LLM Cost Calculator - Estimate Your Monthly AI Spend · FinOps LLM URL: https://finopsllm.com/research/llm-cost-calculator LLM Cost Calculator Updated 12 July 2026 Estimate your monthly LLM spend across popular models. Enter your usage pattern below and see costs compared side-by-side. All prices are per-million-tokens as of July 2026. Pre-calculated costs by usage tier Here's what each usage tier costs per month across popular models, based on typical request patterns: Model Light (1K req/mo) Medium (10K req/mo) Heavy (100K req/mo) GPT-5.6-Sol $8.75 $87.50 $875.00 GPT-5.6-Terra $4.38 $43.75 $437.50 GPT-5.6-Luna $1.75 $17.50 $175.00 Claude Fable 5 $17.50 $175.00 $1,750.00 Claude Opus 4.8 $8.75 $87.50 $875.00 Claude Sonnet 5 $3.50 $35.00 $350.00 Claude Haiku 4.5 $1.75 $17.50 $175.00 Gemini 3.5 Flash $2.63 $26.25 $262.50 Grok 4.5 $4.00 $40.00 $400.00 DeepSeek V4 Pro $0.95 $9.50 $95.00 Kimi K2.6 $1.70 $17.00 $170.00 Light: 1K requests/mo, 500 input + 200 output tokens. Medium: 10K requests/mo, 1,000 input + 500 output tokens. Heavy: 100K requests/mo, 2,000 input + 1,000 output tokens. Interactive calculator Model GPT-5.6-Sol ($5.00 / $30.00) GPT-5.6-Terra ($2.50 / $15.00) GPT-5.6-Luna ($1.00 / $6.00) Claude Fable 5 ($10.00 / $50.00) Claude Opus 4.8 ($5.00 / $25.00) Claude Sonnet 5 ($2.00 / $10.00) Claude Haiku 4.5 ($1.00 / $5.00) Gemini 3.5 Flash ($1.50 / $9.00) Grok 4.5 ($2.00 / $6.00) DeepSeek V4 Pro ($0.435 / $0.87) Kimi K2.6 ($0.95 / $4.00) Requests per month Avg input tokens per request Avg output tokens per request Calculate cost How to use this calculator Pick your model from the dropdown. Prices reflect standard API rates as of July 2026. Enter your request volume - how many API calls you make per month. Estimate token counts - the average number of input and output tokens per request. If you're unsure, start with 1,000 input / 500 output for chat, or 3,000 input / 1,000 output for code generation. Hit Calculate to see your estimated monthly cost split by input and output. How to reduce your estimate Use prompt caching. If your prompts have a stable prefix, cached reads can cut input costs by 50–90%. See prompt caching explained . Switch models by task. Route simple queries to cheaper models and reserve expensive ones for complex tasks. This is model routing . Use batch APIs. Non-urgent workloads can use batch pricing at 50% off. Try cheaper providers. MiMO and DeepSeek offer significantly lower rates for comparable quality on many tasks. Related Hidden LLM Costs - infrastructure, caching, retry, and observability costs beyond token pricing. How much does GPT-5 cost? - detailed GPT-5 pricing breakdown. How do LLM providers charge? - understanding token-based billing. Cheapest way to run AI code generation - cost comparison for coding tools. Provider arbitrage - finding the cheapest model that meets your quality bar. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # LLM cost dashboard: what to put on it · FinOps LLM URL: https://finopsllm.com/research/llm-cost-dashboard LLM cost dashboard: what to put on it A good LLM cost dashboard answers two questions at a glance: where is the money going, and is anything about to break the budget. Most dashboards fail because they show one big number - total spend - and stop there. Total spend tells you that costs went up; it never tells you why. What belongs on the dashboard Spend by dimension - broken out by team, product surface, environment, and model, not just one grand total. Cost per request and per successful task - the unit economics that reveal whether growth is efficient or just expensive. Cache-read ratio - the share of input tokens served from cache, the clearest signal of input-cost efficiency. Budget burn - spend against a monthly budget, with projected month-end based on run rate. Anomalies - sudden spikes by team or model, surfaced rather than buried in a chart. Separate the estimate from the truth An LLM cost dashboard has two layers, and conflating them is the most common mistake. Gateway and proxy logs give a near-real-time estimate - fast, useful for catching spikes the same day, but approximate. The provider invoice is the truth - slow, but authoritative. Show both, label which is which, and reconcile the estimate against the invoice each month so the dashboard keeps finance's trust. Two audiences, two views Engineers need request-level granularity to act - which endpoint, which model, which call pattern. Finance needs roll-ups they can put in a forecast - spend by team, trend, budget variance. A single dashboard can serve both, but design the views separately rather than forcing one audience to read the other's numbers. Common mistakes that make a dashboard misleading Averaging cache-read and input tokens together, which hides the biggest cost lever. Tracking money as floating-point, which lets cent-level drift accumulate into reports. Showing spend with no owner - a dashboard with low attribution coverage looks precise but cannot drive a single decision. Reporting only lagging invoice data, so spikes are discovered weeks after they happen. Related LLM cost monitoring - the monitoring practice behind the dashboard. LLM cost attribution - how the per-dimension breakdowns are built. Anomaly detection for AI spend - surfacing spikes automatically. LLM budget governance - turning the burn chart into budgets and alerts. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What should an LLM cost dashboard show? Spend broken out by team, product surface, environment, and model; cost per request and per successful task; cache-read ratio; budget burn with a projected month-end; and surfaced anomalies. A single total-spend number tells you costs went up but never why. Why separate the estimate from the invoice on a cost dashboard? Gateway and proxy logs give a fast, near-real-time estimate that is useful for catching spikes the same day but approximate. The provider invoice is the slow but authoritative truth. Show both, label which is which, and reconcile monthly so the dashboard keeps finance's trust. What makes an LLM cost dashboard misleading? Averaging cache-read and input tokens together, tracking money as floating-point, showing spend with no owner (low attribution coverage), and reporting only lagging invoice data so spikes are found weeks after they happen. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # LLM Cost Management: A Practical Framework · FinOps LLM URL: https://finopsllm.com/research/llm-cost-management LLM cost management LLM cost management is the practice of making AI model spend visible, attributable, budgeted, and controlled. It is not only about paying less. It is about paying the right amount for the value delivered, and catching runaway spend before it becomes a problem. The five pillars 1. Attribution You cannot manage what you cannot assign. Every LLM request should carry metadata: team, project, feature, model, provider, environment, and request ID. That is the minimum. With it, you can answer "Who spent $12,000 on GPT-5 last Tuesday?" without a week of spreadsheet archaeology. 2. Monitoring Monitoring means real-time visibility into spend, tokens, latency, and errors. The most useful dashboards show trends, anomalies, and cost per task — not just total dollars. A spike in cost per resolved support ticket is a product signal, not only a finance signal. See our guide to LLM cost monitoring . 3. Budgeting Budgets turn cost visibility into planning. Set monthly budgets by team or feature, compare actuals to forecast, and explain variance. Good LLM budgets include a baseline, expected growth, and a contingency for experiments. 4. Guardrails Guardrails stop small problems from becoming big ones. Examples: per-user daily limits, per-request cost caps, rate limits on expensive models, and alerts when spend exceeds a threshold. For agentic workloads, guardrails are essential because loops can multiply cost quickly. See agent spend guardrails . 5. Optimization Optimization reduces waste without hurting quality. The main levers are model routing, prompt caching, semantic caching, prompt compression, batch routing, and provider arbitrage. The key is to optimize your top spend drivers first. See AI cost optimization . Getting started Start with attribution and monitoring. You do not need a perfect FinOps platform on day one. You need a clean way to tag requests and a dashboard that shows spend by team and feature. Once those are in place, add budgets, guardrails, and optimization in that order. For the finance-owned view of the same framework, see LLM cost management for CFOs . Common mistakes Reconciling to gateway logs instead of invoices. Gateway logs miss retries, fallback calls, and reasoning tokens. Use the provider invoice as ground truth. Optimizing the long tail first. Sort by spend and focus on the top five endpoints. The rest can wait. Ignoring quality tradeoffs. A cheaper model that hurts task success is not a saving. Measure both cost and quality. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is LLM cost management? LLM cost management is the practice of making large language model spend visible, attributable, budgeted, and controlled without damaging product quality or reliability. What are the pillars of LLM cost management? The pillars are attribution (who spent what), monitoring (real-time visibility), budgeting (plans and forecasts), guardrails (spend limits and alerts), and optimization (reducing waste through routing, caching, and batching). How do you track LLM costs? Track LLM costs by tagging every request with team, project, feature, model, and environment, then aggregate provider invoices and gateway logs into a dashboard that shows spend, tokens, and cost per task. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # LLM cost monitoring: what to track and how to control it · FinOps LLM URL: https://finopsllm.com/research/llm-cost-monitoring LLM cost monitoring Updated 11 June 2026 · first published 5 May 2026 LLM cost monitoring is the practice of tracking spend at request level, not just invoice level. If you cannot explain which feature, user, model, or retry pattern created the cost spike, you are not monitoring spend. You are only seeing the bill after the damage is done. Cost attribution starts here. What to track on every request Provider and exact model. Model pricing changes by tier and version, so “gpt-4” is not granular enough-you need “gpt-4o” vs. “gpt-4-turbo”. Feature or endpoint. The fastest route to actionable attribution and savings discovery. User, account, or workspace. Needed for chargeback, quota control, and abuse detection. Input and output tokens. The primary cost driver and easiest to control with prompt or output-length adjustments. Cached-read tokens. OpenAI offers ~50% cache-read discount; Anthropic offers ~90%. Conflating cached and normal input tokens corrupts your baseline. Reasoning tokens (where applicable). Extended thinking and similar features add cost that standard token counts miss. Retries and tool calls. Hidden cost often sits in failed or repeated work; tool-call tokens are now a material line item. Estimated cost. So you can alert before invoice close, not after damage accumulates. Token classes are billed differently - track them separately Token class Billing behavior Monitoring pitfall if conflated Input (uncached) Full list price per model Prompt growth hides inside aggregate token counts Output Priced higher than input on most models Verbose-output drift looks like traffic growth Cache read Discounted (~50% OpenAI, ~90% Anthropic) Counting cache reads as normal input corrupts the baseline and overstates "savings" Reasoning / thinking Billed as output even though invisible to users Standard token counts miss it entirely Retry and tool-call Every upstream attempt is billed, user sees one answer Failed and repeated work reads as legitimate usage Batch Discounted asynchronous lane Mixing batch with realtime hides which workloads could move lanes Use a consistent telemetry schema OpenTelemetry's GenAI semantic conventions are a strong baseline because they standardize fields like model, input tokens, output tokens, cache-read tokens, conversation IDs, and provider names. That makes it easier to swap vendors or observability backends without rebuilding your data model every quarter. Define your schema first; the tooling (Langfuse, Helicone) will follow. The dashboards that matter Most teams overbuild their dashboard layer and underbuild their tagging layer. For cost attribution to work, start with these five views: Spend by feature. Top ten endpoints or workflows by total cost and cost trend. Spend by model and provider. Where the expensive models are actually being used and whether you are over-relying on one provider. Spend by customer or team. The foundation of chargeback and margin analysis. Input and output token trends. Detect prompt growth, verbose output drift, and whether cache-read benefits are real. Cache hit, retry, and tool-call rates. Three of the easiest places to find waste and validate optimization impact. Alerts worth setting up Daily spend threshold by feature or team. Tied to your cost baseline, not a global number. Unexpected model shift. Example: a cheap endpoint suddenly defaults to a frontier model; catch it same day. Cache-hit rate regression. If your cache-read share drops, you are likely paying full price for reprocessing. Retry storm or agent loop behavior. Costs compound; alert on loops within a single request or session. Reconciliation variance. Internal cost estimates drift too far from provider truth-investigate why. Monitoring rule If your dashboard cannot tell you whether the spike came from prompt growth, model drift, retries, cached-token share changes, or one noisy customer, your instrumentation is still too thin. A practical stack For most teams, provider-native billing plus a gateway layer, request metadata in application logs, and an observability tool like Langfuse or Helicone covers the essentials. For larger operations, add a warehouse layer and monthly reconciliation against provider or cloud billing exports so you can tie cost back to customer cohorts, feature releases, and margin. Monitoring is the prerequisite, not the solution Monitoring alone does not lower your bill. It gives you the ranked list of what to fix first. Once that list is visible, the usual wins are smaller default models, output caps, prompt cleanup, prompt caching (especially for cache-read discounts), batching, and quota controls based on unit economics. Related LLM cost monitoring in production - the production runbook view. LLM cost anomaly detection - detecting spend surges. AI observability - cost signals and operational metrics. What is LLM FinOps? - the complete operating discipline. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to FinOps LLM FAQ Why use a consistent telemetry schema? OpenTelemetry's GenAI semantic conventions are a strong baseline because they standardize fields like model, input tokens, output tokens, cache-read tokens, conversation IDs, and provider names. Which dashboards actually matter? Most teams overbuild their dashboard layer and underbuild their tagging layer. For cost attribution to work, start with these five views: What does a practical LLM cost stack look like? For most teams, provider-native billing plus a gateway layer, request metadata in application logs, and an observability tool like Langfuse or Helicone covers the essentials. Does monitoring alone lower your bill? Monitoring alone does not lower your bill. It gives you the ranked list of what to fix first. Once that list is visible, the usual wins are smaller default models, output caps, prompt cleanup, prompt caching (especially for cache-read discounts), batching, and quota controls based on unit economics. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # LLM Cost Monitoring in Production: A Field Guide · FinOps LLM URL: https://finopsllm.com/research/llm-cost-monitoring-production-guide LLM cost monitoring in production Updated 1 August 2026 Monitoring LLM costs in production is different from monitoring traditional cloud infrastructure. The unit of cost is a token, not a server hour. A single request can cost anywhere from a fraction of a cent to several dollars. Spikes can come from prompt growth, model drift, retry loops, or one noisy customer. If your monitoring only shows the monthly invoice, you are not monitoring; you are autopsying. The production monitoring stack A production-ready LLM cost monitoring stack has four layers: Instrumentation. Capture the right fields on every request. Aggregation. Roll request-level data into useful dimensions. Alerting. Detect deviations from baseline before they compound. Runbooks. Tell the on-call engineer what to do when an alert fires. Instrumentation: what to capture on every request The minimum viable telemetry schema for cost monitoring includes: Field Why it matters Provider and exact model Pricing differs by model version, not just family. Feature or endpoint The fastest path to actionable attribution. Team or customer Needed for chargeback and abuse detection. Input tokens Largest controllable cost driver. Output tokens Usually priced higher than input. Cache-read tokens Discounted; must be tracked separately. Reasoning tokens Billed as output; invisible to users. Retries Failed work often looks like legitimate usage. Tool calls Agents can fan out into many billed calls. Estimated cost Lets you alert before invoice close. OpenTelemetry's GenAI semantic conventions standardize most of these fields. Use them as the baseline rather than inventing your own schema. Dashboards that matter Most teams overbuild their dashboard layer. Start with five views: Spend by feature. Top ten endpoints or workflows by cost and trend. Spend by model and provider. Where expensive models are actually used. Spend by team or customer. The foundation of chargeback and margin analysis. Token trends. Input growth, output verbosity, and cache-read share over time. Operational ratios. Cache hit rate, retry rate, and tool-call rate. If a dashboard does not help someone take action, remove it. Visibility without action is noise. Alerts worth setting up Alert Trigger Why it matters Daily spend by feature Spend > 150% of rolling 7-day baseline Catches feature-level spikes same day. Unexpected model shift Cheap endpoint suddenly routes to frontier model Deployment or routing bug. Cache-hit regression Cache-read share drops >10 percentage points Paying full price for reprocessing. Retry storm Median retries per task doubles Downstream failure or brittle prompt. Agent loop Tool-call count exceeds threshold Runaway agent cost. Reconciliation variance Internal estimate drifts >10% from provider Missing or misclassified usage. Alert thresholds should be tied to baselines, not static numbers. A startup's spike is an enterprise's normal Tuesday. Runbooks: what to do when an alert fires Every alert needs a runbook. For LLM cost spikes, the runbook usually follows this order: Identify the dimension. Is it one feature, one model, one team, or one customer? Check for recent deploys. Did a model default change, prompt template change, or routing rule change? Look at token composition. Is the spike from input growth, output growth, retries, or tool calls? Implement a guardrail. Cap output length, switch a default model, or throttle the noisy customer. Validate the fix. Compare estimated cost before and after the change. Monitoring is not the solution Monitoring tells you where the waste is. It does not remove it. The actual savings come from the optimization work that follows: routing to cheaper models, compacting prompts, enabling caching, batching non-urgent work, and adding agent guardrails. Treat monitoring as the input to a weekly cost review, not a project that ends once the dashboard ships. If your cost monitoring cannot answer whether a spike came from prompt growth, model drift, retries, cache-share changes, or a noisy customer, your instrumentation is still too thin. Related LLM cost monitoring — the foundational telemetry guide. Six levers for AI cost optimization — what to do after monitoring finds the waste. LLM cost anomaly detection — statistical methods for catching spikes. Agent spend guardrails — controls for runaway agent costs. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What should I monitor for LLM costs in production? Monitor spend by feature, model, provider, team, and customer. Track token classes separately, including input, output, cache read, reasoning, and tool-call tokens. Watch for prompt growth, model drift, retry storms, and cache-hit regressions. How do I alert on LLM cost spikes? Set daily spend thresholds tied to a feature's rolling baseline, not a global number. Alert on unexpected model shifts, cache-hit regressions, retry storms, and reconciliation variance between internal estimates and provider invoices. What is the minimum telemetry schema for LLM cost monitoring? Capture provider, model, feature or endpoint, user or team, input tokens, output tokens, cache-read tokens, reasoning tokens, retries, tool calls, and estimated cost per request. OpenTelemetry GenAI semantic conventions are a strong baseline. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # LLM Cost Per User Benchmarks · FinOps LLM URL: https://finopsllm.com/research/llm-cost-per-user-benchmarks LLM Cost Per User Benchmarks Updated 12 July 2026 Modeled monthly LLM cost per active user by role and team type. Use these benchmarks to compare your spending against similar companies and identify cost optimization opportunities. Modeled scenarios from published LLM pricing Benchmarks by role: developers, analysts, customer-facing Includes low, typical, and high-use tiers All prices current as of July 2026 Developer Tier (Coding Assistants) Developers using AI code generation and debugging consume the highest tokens per user. Typical daily usage: 4–8 hours of IDE time with continuous LLM interactions. Usage Level Daily Interactions Est. Monthly Tokens Model Mix Cost/User/Month Notes Light 10–20 5M in / 2M out Gemini Flash (80%), Sonnet (20%) $26–$30 Occasional code completions, not relying on LLM for design Typical 40–60 20M in / 10M out Opus (70%), Flash (30%) $225–$281 Regular use of chat, debugging, test generation Heavy 100+ 50M in / 25M out Opus 4.8 (100%) $695–$875 Full-day LLM pair programming, agent-based workflows Cost calculation (all three tiers, from list prices): Light — input 4M × $1.50 (Gemini 3.5 Flash) + 1M × $2–$3 (Sonnet 5), output 1.6M × $9 + 0.4M × $10–$15 = $26–$30 ; the range reflects Sonnet 5's introductory $2/$10 pricing through August 31, 2026 ($3/$15 from September 1). Typical — input 14M × $5 (Opus 4.8) + 6M × $1.50, output 7M × $25 + 3M × $9 = $281 ; routing ~40% of the workload through the 50%-off Batch API brings it to ~$225. Heavy — 50M × $5 + 25M × $25 = $875 on pure Opus 4.8; with prompt caching serving 60–80% of input tokens as $0.50/M cache reads, $695–$740. Coding assistant subscription vs. API cost: GitHub Copilot Pro+ ($39/month) offers 7,000 credits ($70 value), covering ~$70 of monthly API cost. For typical developers, a $20–$100/month subscription plan often beats self-managed API billing. Knowledge Worker Tier (Writing, Research, Analysis) Analysts, content creators, researchers, and product managers use LLMs for writing, research, and decision support. Moderate token consumption (1–3 hours/day). Usage Level Daily Sessions Est. Monthly Tokens Model Mix Cost/User/Month Notes Light 5–10 3M in / 1.5M out Flash (90%), Sonnet (10%) $7–$19 Occasional brainstorming, research summaries Typical 20–30 12M in / 6M out Sonnet (70%), Opus (30%) $120–$151 Daily writing support, document analysis, idea generation Heavy 50+ 30M in / 15M out Opus (100%) $425–$525 Research-heavy roles, policy writing, strategic analysis Cost calculation (all tiers, list prices): Light — 3M input × (90% Gemini 2.5 Flash $0.30/M + 10% Sonnet 5 $3/M) = $1.71, plus 1.5M output × (90% × $2.50/M + 10% × $15/M) = $5.63 → ~$7 ; on Gemini 3.5 Flash ($1.50/$9) instead, the same mix is ~$19 . Typical — 12M input × (70% Sonnet 5 $3/M + 30% Opus 4.8 $5/M) = $43.20, plus 6M output × (70% × $15/M + 30% × $25/M) = $108 → $151 list ; batching overnight analysis (50% off batched tokens) brings it toward $120 . Heavy — (30M × $5/M) + (15M × $25/M) = $150 + $375 = $525 list ; with ~75% cache hits on reused research documents (cached input $0.50/M) input drops to ~$49, total ~$425 . Optimization tip: Most knowledge workers can reduce per-user cost to $15–$25 by using cheaper models (Gemini Flash, DeepSeek) for routine tasks and reserving Claude/GPT-5.5 for complex analysis. Customer-Facing Tier (Support Agents, Chatbots) Customer service chatbots and RAG systems handle high volume but amortize LLM cost across many conversations. Cost per active user is typically calculated as (total monthly LLM spend / concurrent active users). Deployment Scale Monthly Conversations Avg Tokens/Conversation Model Monthly LLM Cost Cost per Concurrent User Small (1,000/mo) 1,000 2,000 Gemini Flash $10–$15 $0.10 (100 concurrent) Medium (10,000/mo) 10,000 2,000 Gemini Flash + caching $90–$105 $0.90–$1.05 (100 concurrent) Large (100,000/mo) 100,000 2,000 Gemini Flash + batch $525–$1,050 $5–$11 (100 concurrent) Cost calculation (Medium): 10,000 conversations × 2,000 tokens ≈ 20M tokens, split roughly 50/50 input/output. Gemini 3.5 Flash: (10M × $1.50/M) + (10M × $9/M) = $15 + $90 = $105 at list . Prompt caching on the customer KB only discounts the input side, so it trims the total to ~$90–$105 — the bigger lever is the model: the same workload on Gemini 2.5 Flash ($0.30/$2.50) is (10M × $0.30/M) + (10M × $2.50/M) = ~$28/month . Large tier: 200M tokens on Gemini 3.5 Flash = $1,050 at list, ~$525 if fully batched (50% batch discount). Key insight: For chatbots, use low-cost models (Gemini Flash $0.30–$2.50, DeepSeek V4 Flash $0.14–$0.28) with prompt caching to maximize token efficiency. Cost per customer interaction can be as low as $0.001. Data Processing Tier (Batch & ETL) Teams processing documents, logs, or datasets via LLM batch jobs consume massive token volume but benefit from 50% batch discount on all input/output. Workload Monthly Records Avg Tokens/Record Model (w/ 50% Batch) Monthly Cost Cost per 1M Tokens Light (100k records) 100,000 1,000 Gemini 2.5 Flash + Batch $26–$37 $0.15 in / $1.25 out (50% disc) Medium (1M records) 1,000,000 1,000 Gemini 2.5 Flash + Batch $260–$370 $0.15 in / $1.25 out (50% disc) Heavy (10M records) 10,000,000 1,000 Claude Haiku 4.5 + Batch $7,000–$9,000 $0.50 in / $2.50 out (50% disc) Cost calculation (Medium): 1M records × 1,000 tokens = 1B tokens, roughly 80% input / 20% output for classification-style jobs. Gemini 2.5 Flash with the 50% batch discount: (800M × $0.30/M × 0.5) + (200M × $2.50/M × 0.5) = $120 + $250 = $370/month — about $0.0004 per record. At 90% input share the same job is ~$260. Heavy tier on Claude Haiku 4.5 batch ($0.50/$2.50 after discount): (8B × $0.50/M) + (2B × $2.50/M) = $4,000 + $5,000 = $9,000/month ; ~$7,000 at 90% input share. Cross-Team Cost Per User Rollup If your organization has mixed roles, calculate weighted average cost per user: Team Composition Developers Knowledge Workers Support/Ops Avg Cost/User Tech Startup 50% ($250) 30% ($135) 20% ($5) $167/month Enterprise (mixed) 25% ($250) 50% ($135) 25% ($10) $133/month Customer Success Org 10% ($250) 40% ($135) 50% ($8) $83/month How to use this table: Role costs use the mid-point of each typical tier above (developers ~$250, knowledge workers ~$135) plus a modeled $5–$10/employee for shared support tooling. If your org is 50% developers and 50% support staff, expect roughly 0.5 × $250 + 0.5 × $8 ≈ $129/month per user . If your whole-org average is well above your composition's estimate, you have heavy agent-based developer use or missed optimization opportunities. Optimization Strategies by Role For Developers Use coding-plan subscriptions ($20–$100/month) to replace raw API billing. They often provide better value due to UI optimizations and bundled models. Implement model routing: use Gemini Flash for autocomplete, Claude for complex reasoning. For Knowledge Workers Enable prompt caching if using the same documents repeatedly (e.g., internal policy PDFs, research datasets). Cache hits cost 90% less. Batch reusable tasks (tomorrow's reports, weekly analyses) to save 50% on those tokens. For Support/Chatbots Use lowest-cost models (Gemini Flash, DeepSeek). Implement aggressive prompt caching with your customer KB. If volume is high, negotiate volume pricing or consider self-hosted models (Llama, Qwen). For Data Processing Always use batch API (50% discount). Use smallest sufficient model (Haiku, Flash) for classification tasks. Consider open-source self-hosted models (Llama 3.3 70B) if processing volume exceeds $2,000/month. Benchmarking Your Own Team Step 1: Calculate average cost per user Total LLM spend for the month ÷ active users in that month. Active = anyone who triggered an LLM call. Step 2: Segment by role or team Break down by department. Are your developers at $225–$281/month? That's in the typical range for daily AI-assisted development. Are knowledge workers well above the ~$120–$151 typical band? Look for caching and model-routing opportunities. Step 3: Identify outliers Which individuals or teams are above their role benchmark? Investigate: Are they using the most expensive models unnecessarily? Missing batch opportunities? Not using caching? Step 4: Test optimizations Pilot model routing, prompt caching, or batch API for a high-use team. Re-measure cost per user after 4 weeks. Aim for 20–30% reduction. To get a detailed per-user cost breakdown of your actual LLM spend, book a free audit with FinOps LLM . We'll show your per-user cost by team and suggest specific optimizations. Back to research FAQ What is cost per user? Cost per user (CPU) is total LLM spend divided by active users in a period. These benchmarks show modeled monthly LLM cost by role: developers ($26–$281 typical, up to ~$875 for heavy agent-based use), knowledge workers ($7–$151 for light-to-typical use), customer-facing agents (shared pool cost / concurrent users). Why does cost vary by role? Token volume scales with task complexity and frequency. Developers using code generation use more tokens per day. Knowledge workers using LLMs for writing use moderate tokens. Customer service chatbots amortize cost across hundreds or thousands of conversations. How do I benchmark my own team? Divide total monthly LLM spend by active users. Compare your per-user cost to these benchmarks. If you're above the range, investigate high-usage outliers and consider model routing or caching. Should cost per user include infrastructure? These benchmarks cover LLM API spend only, not hosting or compute infrastructure. If you self-host models, add your infra cost per user (typically $5–$50/user/month for on-prem LLMs). Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # A production runbook for an LLM cost spike · FinOps LLM URL: https://finopsllm.com/research/llm-cost-spike-runbook A production runbook for an LLM cost spike Updated August 27, 2026 · first published August 27, 2026 Quick answer: When LLM spend spikes, do not start by changing the model. First preserve the evidence, confirm the billing signal, and identify whether the change is volume, rate, mix, or efficiency. A good response... When LLM spend spikes, do not start by changing the model. First preserve the evidence, confirm the billing signal, and identify whether the change is volume, rate, mix, or efficiency. A good response contains the incident before it destroys the data needed to explain it. First 15 minutes: confirm and preserve Capture the provider invoice or usage export, current traffic, model mix, token types, retries, and recent deployments. Record the start time, affected accounts, and dashboards used. Compare provider billing with gateway telemetry so a dashboard bug does not trigger an unsafe production change. Next 30 minutes: contain safely Apply the narrowest control that stops additional damage: pause a runaway workflow, cap an agent, route background work to batch, or disable one newly released feature. Preserve quality-critical and revenue-critical traffic. Every emergency control needs an owner, an expiry time, and a rollback condition. Find the driver Check volume first, then model mix, token composition, retries and fallbacks, context length, tool fan-out, and provider price changes. Compare p50 and p95 cost per successful task with the prior period. A rise in requests with flat cost per task is demand; a rise in cost per task is an efficiency or mix problem. Close the incident Remove temporary controls only after the metric returns below its threshold and quality remains within SLO. Write a timeline, dollar impact, root cause, detection gap, and permanent action. Reconcile the final impact to provider invoices and tag the affected feature so the postmortem can be audited. The runbook is successful when the team can answer what changed, what was protected, how much it cost, and which control prevents recurrence. Related LLM cost monitoring Agent spend guardrails AI spend variance analysis Related LLM cost monitoring Agent spend guardrails AI cost allocation Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # LLM Cost Tracking: Tools, Tags and Telemetry · FinOps LLM URL: https://finopsllm.com/research/llm-cost-tracking LLM cost tracking LLM cost tracking is the practice of collecting, tagging, and aggregating the data you need to explain every dollar of AI spend. Without it, the monthly invoice is just a number. With it, you can answer who spent what, on which model, for which feature, and whether it was worth it. What to tag on every request The minimum viable attribution set is: Team or cost center — who owns the workload. Project or feature — what the workload supports. Model and provider — which model was called and through which provider. Environment — production, staging, or development. Token type — input, output, cache-read, cache-write, reasoning. Request context — user ID, session ID, or task ID for tracing. Where the data comes from There are three sources, and each has gaps: Provider invoices — the ground truth for dollars, but coarse-grained and delayed. Gateway or proxy logs — rich per-request detail, but may miss retries, fallbacks, and reasoning tokens. Application telemetry — links cost to business outcomes, but needs instrumentation. Reconcile all three. Use the invoice as the final number, gateway logs for attribution, and application telemetry for cost-per-task. Metrics that matter Cost per request — the average cost of a single API call. Cost per task — the cost to complete a business outcome. Spend concentration — which endpoints and teams drive most of the cost. Variance — actual spend vs. budget, by week or by feature. Getting started Start with gateway logs if you use a proxy like LiteLLM, Helicone, or Langfuse. Add custom tags to your requests and export the data to a dashboard. If you do not use a proxy, instrument your application to log model, tokens, and task ID on every call. See also our guides to LLM cost management and LLM cost monitoring . Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ How do you track LLM costs? Track LLM costs by tagging every request with team, project, feature, model, provider, and environment, then aggregating provider invoices and gateway logs into a dashboard that shows spend, tokens, and cost per task. What metrics should you track for LLM costs? Track total spend, tokens by type, cost per request, cost per task, latency, error rate, and spend concentration across teams and features. What is the best tool for LLM cost tracking? The best tool is the one your team will actually use. Options range from provider dashboards and gateway logs for small teams to observability platforms and custom pipelines for larger deployments. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # LLM Cost Trends 2025–2026 · FinOps LLM URL: https://finopsllm.com/research/llm-cost-trends-2025-2026 LLM cost trends 2025–2026 Updated 12 July 2026 · first published 4 July 2026 The LLM market is moving in two directions at once. Input and output token prices for GPT-4-class models have dropped 80–90% since early 2024. At the same time, reasoning models (o1, o3, DeepSeek-R1, Claude Opus 4) are 5–30x more expensive per task than their non-reasoning equivalents. The net effect: teams that adopt reasoning models see bills go up even as unit prices go down. This article tracks the key price and quality events from 2025 through mid-2026, explains the forces driving costs, and forecasts what to expect in the second half of 2026. Key trend 1: GPT-4-class models dropped 90% in 18 months In March 2024, GPT-4-turbo cost $10 per million input tokens and $30 per million output tokens. By mid-2026, GPT-4.1 costs $2 per million input and $8 per million output - a 75–80% drop. Claude followed a similar trajectory: Claude 3 Opus at $15/$75 dropped to Claude Sonnet 4 at $3/$15. Open-weight models from Mistral, Llama, and DeepSeek pushed prices even lower, with some available for under $0.50 per million input tokens through hosted providers. This is not just a price war. Inference infrastructure improved: quantization, speculative decoding, KV-cache optimization, and batching all reduced the cost to serve a token. Providers passed some of those savings to customers. Key trend 2: Reasoning models are 5–30x more expensive Reasoning models (o1, o3, o4-mini, DeepSeek-R1, Claude Opus 4 with extended thinking) generate internal "thinking" tokens before producing a final answer. These thinking tokens are billed as output tokens. A reasoning model solving a coding task might generate 10K–50K thinking tokens before producing a 2K-token answer. The effective cost per task is therefore much higher than the per-token price suggests. For teams using reasoning models for every task, this is the single biggest cost driver in 2026. The key question is not "how much does the model cost?" but "does this task need reasoning?" Most tasks do not. Key trend 3: Open-source closed the quality gap In early 2024, open-weight models trailed proprietary models by a significant margin on coding and reasoning benchmarks. By mid-2026, models like Llama 4 Maverick, DeepSeek-V3, Qwen 3, and MiMo are within a few points of GPT-4-class performance on most benchmarks. This matters for cost because open-weight models are cheaper to serve - providers competing on price use them to undercut proprietary pricing. The quality gap has not fully closed for frontier reasoning tasks. But for the majority of production workloads - summarization, extraction, classification, code generation, tool use - open-weight models are good enough and significantly cheaper. Key trend 4: Caching reduced effective costs 50–90% for repeat workloads Prompt caching (Anthropic) and automatic context caching (OpenAI, Google) changed the economics of repeated workloads. If you send the same system prompt and context to a model 100 times a day, cached reads cost 50–90% less than uncached reads. For RAG pipelines, agent systems, and batch processing, this is transformative. Caching benefits are unevenly distributed. Workloads with stable context (same system prompt, same document set) benefit enormously. Workloads with dynamic context (user-specific conversations, real-time data) benefit less. FinOps teams should measure their cache hit rate and optimize context stability to maximize savings. Key trend 5: Agent workflows multiply token consumption Agent workflows - where models call tools, read files, execute code, and iterate on results - consume 5–50x more tokens per task than single-turn interactions. A coding agent solving a bug might consume 100K–500K tokens across its tool calls, retries, and context accumulation. An equivalent single-turn prompt might use 2K–5K tokens. This is the most important cost trend in 2026. Token prices are falling, but token consumption per task is rising faster. Net result: total LLM spend is going up for most teams even as unit prices go down. Timeline: key events Date Event Price impact Quality impact Mar 2024 GPT-4-turbo launch 50% cheaper than GPT-4 Comparable quality Jun 2024 Claude 3.5 Sonnet launch 5x cheaper than Opus Near-Opus quality Sep 2024 o1-preview launch 3–5x more per task (reasoning) Major reasoning jump Dec 2024 Google Gemini 2.0 Flash Sub-$1/M input tokens Strong for speed tasks Jan 2025 DeepSeek-R1 open-source 10x cheaper than o1 Near-o1 reasoning Feb 2025 Claude 3.5 Sonnet price cut Further 20% drop Same quality Apr 2025 GPT-4.1 launch 30% cheaper than GPT-4-turbo Improved coding May 2025 Claude Sonnet 4 launch Same price, better quality Significant coding jump Jun 2025 OpenAI o3-mini price drop 50% cheaper reasoning Same quality Jan 2026 DeepSeek-V3 hosted providers Sub-$0.50/M input tokens Near-GPT-4 class Apr 2026 Claude Opus 4 launch Premium pricing ($15/$75) Frontier reasoning Jun 2026 Llama 4 Maverick hosted Sub-$0.30/M input tokens Strong general quality Jul 2026 Anthropic Fable 5 / OpenAI GPT-5.6 tier launch New frontier tier ($5/$30), mid-tier pricing ($2.50/$15), budget tier ($1/$6) Fable 5 matched Opus 4 performance What to expect in H2 2026 Reasoning model prices will drop 30–50%. Competition from open-source reasoning models (DeepSeek-R2, Qwen 3 reasoning variants) will force proprietary providers to cut prices on their reasoning tiers. Agent-specific pricing will emerge. Providers are testing per-task and per-session pricing models that bundle tool calls, retries, and context into a single predictable cost. Expect at least one major provider to offer this by Q4 2026. Caching will become automatic. Manual cache management will disappear. Providers will optimize cache placement transparently, and cache hit rates will improve for most workloads without developer intervention. Open-weight models will dominate routine work. By end of 2026, expect 70%+ of production inference on routine tasks (classification, extraction, summarization, simple code generation) to run on open-weight models through hosted providers. Total spend will keep rising. Despite falling unit prices, agent-driven workflows and expanding AI use cases mean total LLM spend will continue to grow. FinOps discipline - not just cheaper models - is what keeps spend under control. Related Agent economics - how coding agents price out in practice. Provider arbitrage - switching providers to reduce costs. Model routing - sending tasks to the right model. FinOps for LLM - the broader framework. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ How much have GPT-4-class model prices fallen? In March 2024, GPT-4-turbo cost $10 per million input tokens and $30 per million output tokens. By mid-2026, GPT-4.1 costs $2 per million input and $8 per million output - a 75–80% drop. Claude followed a similar trajectory: Claude 3 Opus at $15/$75 dropped to Claude Sonnet 4 at $3/$15. How much more expensive are reasoning models? Reasoning models (o1, o3, o4-mini, DeepSeek-R1, Claude Opus 4 with extended thinking) generate internal "thinking" tokens before producing a final answer. These thinking tokens are billed as output tokens. Have open-source models closed the quality gap? In early 2024, open-weight models trailed proprietary models by a significant margin on coding and reasoning benchmarks. By mid-2026, models like Llama 4 Maverick, DeepSeek-V3, Qwen 3, and MiMo are within a few points of GPT-4-class performance on most benchmarks. How much does caching reduce effective costs? Prompt caching (Anthropic) and automatic context caching (OpenAI, Google) changed the economics of repeated workloads. If you send the same system prompt and context to a model 100 times a day, cached reads cost 50–90% less than uncached reads. How much more do agent workflows consume? Agent workflows - where models call tools, read files, execute code, and iterate on results - consume 5–50x more tokens per task than single-turn interactions. A coding agent solving a bug might consume 100K–500K tokens across its tool calls, retries, and context accumulation. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # LLM Cost Visibility: Dashboards and Metrics That Matter · FinOps LLM URL: https://finopsllm.com/research/llm-cost-visibility LLM cost visibility LLM cost visibility is the ability to see who is spending what, why, and how it is changing. It is the prerequisite for every other FinOps activity: budgeting, optimization, chargeback, and governance. Without it, you are flying blind. The visibility stack Visibility has three layers: Collection — tag every request and gather logs, invoices, and telemetry. Aggregation — roll the raw data into metrics that humans can read. Distribution — put the right metrics in front of the right people. What the dashboard should show A good LLM cost dashboard answers four questions: What are we spending? — total and trend. Who is driving it? — team, feature, and model breakdown. Is it getting more efficient? — cost per task over time. What needs attention? — anomalies, spikes, and budget breaches. Who needs to see what Engineering teams — their own spend, cost per request, and error rates. Finance — budget vs. actual, variance, and spend concentration. Product — cost per user and cost per successful task. Executives — top-line trend and the three largest drivers. From visibility to action Visibility is not the end goal. The goal is to act on it. Use dashboards to set budgets, trigger alerts, and identify optimization candidates. Once you can see the cost, you can manage it. For the tracking mechanics, see LLM cost tracking . Which metrics mislead? Three common ones do more harm than good: Total spend on its own. It rises when the product succeeds. Without a unit denominator you cannot tell growth from waste, and you will end up asking a team to cut costs in the month they doubled usage. Cost per token. It rewards shorter outputs regardless of whether the task was completed. Cost per successful task is the number that maps to value. Average cost per request. LLM cost distributions have long tails — a small share of requests with large contexts or heavy retries often drives most of the bill. Track the p95 alongside the mean, or the expensive traffic stays invisible. How fresh does cost data need to be? It depends who is reading it. Finance needs monthly accuracy reconciled to the invoice. Engineering needs same-day estimates, because a prompt change that triples context length should surface before it runs for a week. Those are two different pipelines, and trying to serve both from one usually produces data that is too slow to act on and too approximate to book. Why doesn't the provider dashboard cover this? Provider consoles report by API key and model, which is infrastructure, not ownership. They cannot tell you which feature, customer, or workflow caused a call, and they stop at the boundary of one vendor. The moment you use two providers — or route between them — the reconciled view has to be yours. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is LLM cost visibility? LLM cost visibility is the ability to see AI spend by team, feature, model, and provider, understand trends and anomalies, and connect costs to business outcomes. Why does cost visibility matter for LLMs? LLM costs are granular, spiky, and directly tied to product usage. Without visibility, a single feature or experiment can silently blow the budget. What should an LLM cost dashboard show? A useful dashboard shows total spend, spend by team and feature, cost per task, top endpoints, budget variance, and anomalies. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # LLM FinOps standards · FinOps LLM URL: https://finopsllm.com/research/llm-finops-standards LLM FinOps standards There is no formal standards body for LLM FinOps yet. But teams running real AI spend converge on the same practices, and writing them down as a standard makes cost reporting comparable across teams, quarters, and providers. This page sets out a practical standard you can adopt - what to measure, how to attribute it, and how often to reconcile. It builds on the established FinOps Foundation framework (Inform, Optimize, Operate) and adapts it to the specifics of token-based pricing. Standardize the unit metrics first Averages hide the decisions that move spend. A standard LLM FinOps report should track, at minimum: Cost per successful task - total spend divided by completed units of work, not per request. Retries and failed calls belong in the numerator. Cache-read ratio - cache-read tokens as a share of input tokens. This is the single biggest lever on input cost and is invisible if you only look at total tokens. Model mix - share of spend by model tier, so a drift toward the most expensive model is caught early. Attribution coverage - the percentage of spend that maps to a known owner. Below ~90% coverage, every other number is suspect. Standardize the attribution dimensions Every cost record should carry the same four dimensions so reports roll up cleanly: team , product surface , environment (prod / staging / dev), and model . Keeping input, output, and cache-read tokens as separate measures within each record is part of the standard - collapsing them corrupts both the baseline and the savings math. Standardize the reconciliation cadence Gateway logs give a fast, approximate view; the provider invoice is the source of truth. The standard is a monthly reconciliation: estimated spend from logs versus billed spend from the invoice, with a documented tolerance and an explanation for any gap beyond it. Without this step, dashboards drift from reality and lose credibility with finance. Map it to the FinOps phases Inform - publish the unit metrics and attribution coverage on a shared dashboard everyone can see. Optimize - act on the levers the metrics expose: caching, model routing, batch where latency allows. Operate - set budgets and alerts, review monthly, and reconcile against invoices. Related FinOps for LLM: a practical framework - the operating model in full. AI FinOps - how FinOps principles extend to AI spend. LLM cost attribution - the attribution dimensions in depth. LLM budget governance - budgets, alerts, and guardrails. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ Is there an official LLM FinOps standard? There is no formal standards body for LLM FinOps yet, but teams running real AI spend converge on the same practices. Writing them down - unit metrics, attribution dimensions, and a reconciliation cadence - makes cost reporting comparable across teams, quarters, and providers. What metrics should a standard LLM FinOps report track? At minimum: cost per successful task rather than per request, cache-read ratio (cache-read tokens as a share of input tokens), model mix (share of spend by model tier), and attribution coverage (the percentage of spend mapped to a known owner). Below about 90% attribution coverage, every other number is suspect. How does it map to the FinOps Foundation framework? It adapts the FinOps Foundation's Inform, Optimize, and Operate phases to token-based pricing: Inform publishes unit metrics and attribution coverage, Optimize acts on caching and routing levers, and Operate sets budgets, reviews monthly, and reconciles against invoices. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # LLM Purchasing Guide for Platform Teams · FinOps LLM URL: https://finopsllm.com/research/llm-purchasing-guide LLM purchasing guide Buying LLM capacity is different from buying software. Usage is variable, pricing changes, and the headline rate is rarely the final rate. This guide helps platform teams buy AI capacity without overcommitting. Match the pricing model to the workload Pay-per-token — best for variable, hard-to-predict usage. Volume discounts — useful once usage is steady and large. Committed use discounts — cheaper, but only if you are confident in the forecast. Batch API pricing — steep discounts for non-urgent work. Reserved throughput — for latency-sensitive production features. Enterprise agreements — for large, multi-product commitments. Do not commit too early Committed discounts look attractive, but they lock you into a forecast. Start with pay-per-token, collect three months of data, then negotiate. Most teams overestimate how much of their usage is stable. Require attribution and guardrails No deal should close without a plan for tagging, dashboards, and spend limits. If you cannot attribute usage, you cannot manage it. If you cannot cap spend, you cannot protect the budget. Keep fallback providers Single-provider dependency is a pricing and availability risk. Your contract and architecture should support fallback to at least one alternative. This also gives leverage at renewal. Platform team checklist Workload mapped to pricing model Three months of usage data before commitments Attribution tags defined and enforced Cost caps and alerts configured Fallback provider tested Data residency and security terms confirmed Overage and price-change clauses reviewed For the finance perspective on the same decisions, see the LLM purchasing guide for CFOs . Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What pricing models do LLM providers offer? The main models are pay-per-token, volume discounts, committed use discounts, batch API pricing, reserved throughput, and enterprise agreements. When should you commit to an LLM volume discount? Commit only after you have three or more months of stable usage data. Most teams overestimate stable usage because growth and model switching are unpredictable. What should be in an LLM procurement checklist? The checklist should cover usage attribution, cost caps, fallback providers, data residency, rate limits, billing granularity, overage pricing, and contract flexibility. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # LLM Token Tracking by Input, Output and Cache · FinOps LLM URL: https://finopsllm.com/research/llm-token-tracking LLM token tracking LLM token tracking is the foundation for AI cost governance. If you cannot separate input tokens, output tokens, cached tokens, retries, and fallback calls, you cannot explain why the bill changed or which engineering choice caused it. Token tracking should happen at request level, not only as a daily aggregate. Teams need enough detail to answer whether cost increased because users asked more questions, because the product sent more context, because a route policy changed, or because a bug triggered duplicate work. Minimum fields to capture Timestamp, request id, feature, environment, and team owner. Provider, model, route policy, and fallback status. Input and output token counts, plus any cache-read or cache-write token classes. Latency, retries, and final status. Business context such as tenant, workflow, or successful-task marker where allowed. Why token counts alone are not enough Token counts explain volume, but not value. A workflow with high token usage may still be efficient if it closes expensive support cases or automates a finance process. That is why strong teams track both token consumption and business outcome. The more useful metric is cost per successful task, with token data as the diagnostic layer underneath. Tracking patterns that help in production Join application logs, model gateway data, and invoice totals into a single reporting model. Keep retries linked to the original request. Separate user-facing traffic from batch and eval jobs. Most importantly, do not let each provider define your reporting shape. Normalize records so multi-provider routing can still be analyzed in one view. Related reading: LLM cost monitoring , LLM cost attribution , and AI FinOps for production teams . Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Input, output, cache, reasoning: what tokens cost · FinOps LLM URL: https://finopsllm.com/research/llm-token-types-explained Input, output, cache, and reasoning tokens When you read an LLM invoice, every dollar resolves to one of a few token types - and they do not cost the same. Treating them as one undifferentiated pile of "tokens" is the most common reason a cost baseline is wrong and a savings estimate is off. This is a plain-English guide to the four token types that matter, what each costs relative to the others, and which lever reduces each. 1. Input tokens What they are: everything you send the model - the user's message, your system prompt, retrieved documents, tool definitions, and the prior conversation history. Relative cost: the cheaper of the two billed-at-full-price types, but rarely small. Input is often the largest token count in retrieval-heavy and long-conversation workloads, so low unit price does not mean low total cost. What drives it up: long system prompts, deep retrieval , full chat history replayed on every turn, oversized tool schemas. Levers: prompt compression , trimming history, tightening retrieval depth, and moving stable prefixes into a prompt cache (see below). 2. Output tokens What they are: everything the model generates back to you - the visible answer. Relative cost: typically the most expensive token type per unit, often several times the price of input tokens on the same model. What drives it up: high max tokens limits, verbose or "detailed" response styles, formats that pad output (large JSON, repeated boilerplate), and chatty multi-turn designs. Levers: cap output length to what the task needs, prompt for concision, use structured outputs that don't repeat context, and pick a smaller model where the quality bar allows. 3. Cache-read tokens What they are: input tokens served from a provider's prompt cache instead of processed fresh, because the same prefix was seen recently. Relative cost: heavily discounted. As of 2026, roughly 50% off on OpenAI and up to about 90% off on Anthropic - always check current provider pricing. This is the one token type that is cheaper , and the discount is large enough to change a baseline materially. Why they're dangerous to ignore: cache-read tokens look like ordinary input tokens unless you separate them. Count them at full price and you overstate spend; lose them (because a deploy changed a once-stable prompt) and your bill spikes with no traffic change. Tracking cache reads as their own line is fundamental to an accurate number. Levers: stabilise system prompts and shared context so they cache; keep volatile content (timestamps, per-request data) out of the cached prefix. 4. Reasoning tokens What they are: tokens a reasoning model generates internally while "thinking," before it produces the visible answer. They are billed like output but never shown to the user. Relative cost: priced as output, and on hard prompts they can exceed the visible answer by several times. They are the token type most likely to surprise a team that budgeted only for the output it can see. What drives it up: adopting a reasoning model, raising the reasoning budget, or pointing reasoning models at tasks that don't need them. Levers: reserve reasoning models for tasks that genuinely benefit, tune the reasoning budget, and track reasoning tokens separately so their cost is visible. Putting it together A single request's cost is the sum of these four, each at its own price, multiplied by the model that handled it: input (full price) + cache reads (discounted) + output + reasoning - × the model's per-token rate. Two requests with the same total token count can cost very differently depending on the mix. A request that is mostly cache-read input is cheap; a request of the same size that is mostly output and reasoning is expensive. This is exactly why a cost baseline built on a single blended token price is unreliable - and why attribution has to break spend out by token type, not just by feature. The one-line takeaway Output and reasoning tokens are where the money usually goes; input is where the volume usually is; cache reads are the discount you must not lose. Track all four separately, per feature and per model, and the bill stops being a mystery. Related Cost per request as a product KPI - using token types in product metrics. How do LLM providers charge? - the full pricing picture. LLM token tracking - instrumenting token data in practice. Prompt cache attribution - getting cache reads right. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # LLM Usage Metering: How to Bill Internal AI Spend · FinOps LLM URL: https://finopsllm.com/research/llm-usage-metering LLM usage metering and billing Published 1 August 2026 Most teams cannot answer a simple question: which feature, team, or customer caused this LLM bill? Provider invoices group everything into one line item. Metering is the fix. It means recording every request with enough metadata to allocate cost later. Billing is what you do with that data: chargeback to teams, invoicing to customers, or showback to leadership. This is not theoretical. Companies running multi-tenant AI products need per-customer metering to invoice accurately. Companies running internal AI platforms need per-team metering to allocate budget. Both need the same underlying records. What to meter Every LLM request should produce one record with these fields: Field Why it matters Example Provider Cross-provider cost comparison openai, anthropic, bedrock Model Model mix drives cost gpt-4o, claude-sonnet-4, llama-3-70b Input tokens Largest cost driver for most workloads 1,247 Output tokens Second largest cost driver 89 Cache-read tokens Discounted input — do not count as savings 3,400 Cache-write tokens Full-price input that primes the cache 1,200 Retry count Retries multiply cost silently 2 Latency Quality-of-service signal 847ms Feature / endpoint Attribution to product surface support-summarize, agent-research, eval-suite Team / owner Attribution to budget owner support-eng, platform, data-science Customer / tenant Attribution for external billing acme-corp, internal Without cache-read and cache-write split, teams miscount savings. Prompt caching reduces input cost, but the cache-read discount only applies to repeated prefixes. If you count cache-read tokens as full savings, you overstate the benefit by 2-3x. How to collect the data Three patterns work in production: Gateway pattern. Route all LLM traffic through a proxy (LiteLLM, Helicone, Langfuse, or a custom gateway). The gateway logs every request with metadata. This is the fastest to deploy and gives you one place to enforce budgets and rate limits. Downside: single point of failure, and you must route all traffic through it. SDK instrumentation. Use OpenTelemetry auto-instrumentation or a thin wrapper around the provider SDK. Each request emits a span with attributes. This works when you control the application code and want per-request granularity without a gateway. Downside: you must instrument every service, and teams can forget. Provider log export. Some providers (OpenAI, Anthropic) offer usage APIs or log exports. This is the easiest to set up but gives you daily aggregates, not per-request records. Use this as a reconciliation source, not as primary metering. The strongest setups use a gateway for enforcement plus SDK instrumentation for redundancy, then reconcile against provider invoices monthly. Building the billing layer Once you have daily usage records, the billing layer is a SQL aggregation: SELECT team, feature, model, SUM(input_tokens) AS input_tokens, SUM(output_tokens) AS output_tokens, SUM(cache_read_tokens) AS cache_read_tokens, SUM(cost_estimate) AS total_cost FROM llm_usage WHERE date >= '2026-07-01' GROUP BY team, feature, model ORDER BY total_cost DESC From this you can produce three outputs: Showback. A monthly report per team: "You spent $4,230 on LLMs. $2,100 was support-summarize, $1,400 was agent-research, $730 was eval-suite." No money changes hands, but teams see their footprint. This is the right first step. Chargeback. The same numbers, but finance actually deducts budget from each team. This requires trust in the data and agreement on allocation rules. Do not start here. Customer billing. For multi-tenant products: per-tenant usage × your pricing model (per-token, per-request, or subscription overage). This needs the most accurate metering because customers dispute invoices. Common mistakes Counting cache-read tokens as savings. A cache-read token costs less than a full input token, but it is not free. The savings are the difference between what you would have paid and what you paid, not the full cache-read volume. Ignoring retries. A request that retries three times costs 3x the tokens. If your metering only records successful requests, you under-report cost by 10-30% for unreliable endpoints. Daily aggregates only. Daily totals hide spikes. A single runaway agent loop can burn $500 in an hour and vanish into the daily average. Keep per-request records for at least 30 days, aggregate for reporting. No reconciliation. Your internal metering will not match provider invoices exactly. Reconcile monthly: internal total vs invoice total. If the gap is >5%, find out why. Common causes: unlogged providers, timestamp skew, or retries counted differently. Minimum viable setup You can have showback running in a week: Instrument one service with OpenTelemetry. Emit one span per LLM request with provider, model, input_tokens, output_tokens, feature, team. Ship spans to ClickHouse or BigQuery. A simple table with the fields above is enough. Write a daily aggregation query. Run it as a scheduled job. Publish a monthly report. Email it to team leads. Do not build a custom dashboard before you have the data flowing. A CSV export emailed monthly is better than a beautiful dashboard with no data. Related AI chargeback and showback - moving cost to owners once you trust the numbers. LLM cost attribution - the broader attribution framework. Prompt caching explained - why cache-read tokens need separate accounting. Agent spend guardrails - preventing runaway spend once you can meter it. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is the difference between metering and billing? Metering is the accurate measurement of usage: tokens, requests, latency, errors. Billing is the assignment of cost to that usage: per-team chargeback, per-customer invoicing, or internal showback. You cannot bill accurately without metering first. How do I meter LLM usage across multiple providers? Use an OpenTelemetry collector or a gateway (LiteLLM, Helicone, Langfuse) that normalizes provider-specific usage records into a common schema. Each request should carry provider, model, input tokens, output tokens, cache-read tokens, cache-write tokens, retry count, and latency. What is the minimum viable metering setup? A single OpenTelemetry span per LLM request with attributes for provider, model, input_tokens, output_tokens, and cost_estimate. Ship these to a ClickHouse or BigQuery table and aggregate daily. That is enough for showback within a week. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Long context vs RAG: where the cost breakeven actually is · FinOps LLM URL: https://finopsllm.com/research/long-context-vs-rag-cost Long context vs RAG: where the cost breakeven actually is Updated 19 July 2026 · first published 19 July 2026 Twelve months ago, 1M-token context windows existed in research papers. Today they are the baseline. The first product question that follows is inevitable: can we drop the RAG stack and just stuff all the context into every request? The honest answer is yes—if your query volume, document corpus, and caching strategy align. But "if" is doing heavy lifting. For teams still running on high-volume search workloads against churning corpora, RAG is still cheaper. For teams with stable documents and moderate request volume, long context with prompt caching can win outright. And for most teams in between, the answer is "it depends on your numbers." This page is about making that "it depends" concrete. We will build a cost model for each approach, work through the breakeven math, and show when to pick long context, when to pick RAG, and when a hybrid might be the right call. The models are illustrative—your numbers will differ—but the framework and the formula stay the same. The cost shape of long context Long context is simple to cost: you pay for input tokens on every single request. The bill grows linearly with context size and request volume. If you are using Claude 3.5 Sonnet and padding 800k tokens of context, that is roughly $2.40 per request in input cost alone (at $3 per 1M input tokens). If you get 1,000 requests per day, that is $2,400 per day in input tokens. The calculation is straightforward until caching enters the picture. Prompt caching changes the economics by orders of magnitude on the first request that primes a cache and dramatically on every subsequent request that hits the cache. A 800k-token prefix, cached and reused 100 times before invalidation, amortizes to $0.024 per request in input cost. The bulk of your spend moves from input tokens to output tokens. The trap in the caching model is churn. A corpus that changes every day invalidates the cache on every request. A cache with a one-day TTL against a one-day refresh cycle is not a cache—it is an input token fee that the provider calls a "cache write" at a higher rate. If the corpus churns faster than the cache pays for itself, you have paid the premium for no benefit. The breakeven on cache invalidation cost depends on your document update frequency and the size of the stable prefix you can maintain across updates. The cost shape of RAG RAG cost is multi-part and most teams undercount it. The visible costs are embedding API charges and vector database storage and query. The hidden costs are re-ranking models, retrieval latency SLAs you pay for, and—the biggest one—engineering and maintenance labor to keep retrieval quality acceptable. The per-request cost model for RAG breaks down like this. You pay for an embedding of the query. Most teams embed once and cache the query-embedding for its logical lifetime (hours to days), so query embedding cost is often negligible on repeated queries. You pay for a vector DB query, which is usually a fractional cent on cloud vector stores and free if you self-host. You pay for retrieval, which might be a single semantic search or a multi-hop re-ranking pipeline. You pay for the tokens in the retrieved context that you then feed to the model. The accounting that breaks RAG teams is conflating the cost of retrieval infrastructure with the cost of RAG as a feature. A single vector DB query costs almost nothing. A vector store that handles 10M queries per month against 10B embeddings, with availability SLA, redundancy, backups, and schema migrations, costs your team something per query even if the provider's API line shows 0.001 cents. Most mature RAG programs allocate infrastructure cost back to RAG as a cost per request delivered. That number is often larger than the API cost. Building the breakeven formula The cost comparison only makes sense when you are comparing equivalent workloads. Long context stuffing serves requests against the entire corpus. Optimal RAG performs semantic search, returns top-K results, and serves requests against a subset. If RAG's quality loss is acceptable, RAG is cheaper at moderate to high query volume. If quality matters and long context is the only way to achieve it, then RAG's cost advantage disappears into a quality tradeoff that is not a cost story anymore. With that scope set: long context cost per request is input token cost for the full context plus output token cost. RAG cost per request is embedding cost, vector store query cost, re-ranking cost if any, plus input and output token cost of the model call against retrieved context. The breakeven happens at the query volume where the accumulated embedding cost (amortized across the lifetime of a single embedding before re-embedding) plus retrieval infrastructure cost equals the input token cost difference between full context and retrieved subset. Here is the formula. Long context cost per request: LC_cost = (full_context_tokens × input_token_price) RAG cost per request, assuming query embeddings are cached for d days: RAG_cost = (query_embedding_cost / (queries_per_day × d)) + vector_db_query_cost + (retrieved_context_tokens × input_token_price) Breakeven is when LC_cost == RAG_cost . Rearranging: full_context_tokens × price = (query_embedding_cost / (queries_per_day × d)) + vector_db_cost + retrieved_context_tokens × price If you add re-ranking, add its cost per request. If you use prompt caching, reduce the left side by the cache hit rate times the cache-read rate discount. Worked examples Let's ground this with real numbers. Assume we are working with Claude 3.5 Sonnet: $3 per 1M input tokens, $15 per 1M output tokens. Example 1: Moderate query volume, stable corpus, no caching Scenario: internal knowledge base (tech docs, runbooks, policies). 500k tokens of context. 100 requests per day. Corpus is stable (updated monthly). Typical output is 500 tokens. Long context cost per request: (500,000 × $3/1M) + (500 × $15/1M) = $1.50 + $0.0075 = $1.51 RAG cost per request: Assuming query embedding via Claude at $3/1M input, 100-token query: (100 × $3/1M / (100 × 30)) + $0.001 (vector DB) + (50,000 × $3/1M) + (500 × $15/1M) = $0.00001 + $0.001 + $0.15 + $0.0075 = $0.16 RAG is about 9x cheaper. Even accounting for 0.5 FTE of engineering labor to maintain retrieval quality ($50k/year = $27/day / 100 requests = $0.27/request), RAG is still $0.43, under 30% of long context cost. Example 2: High-volume API, embedded results, prompt caching enabled Scenario: customer-facing API. 800k token context (large knowledge base). 50,000 requests per day. Context is stable (daily refresh). Cache hit rate 85% (80% of requests hit a cached prefix, 20% trigger cache write at 25% premium). Output average 200 tokens. Long context cost with caching: Input cost is 800k × $3/1M, but 85% of requests pay the cache-read rate ($1.50/1M = 50% discount), 15% pay cache-write rate and full rate. (800,000 × $1.50/1M × 0.85) + (800,000 × $3.75/1M × 0.15) + (200 × $15/1M) = $1.02 + $0.45 + $0.003 = $1.47 RAG cost per request: Query embedding (cached over 30 queries = 50 req/day / 30): (100 × $3/1M / 30) + $0.002 (higher-load DB) + (100,000 × $3/1M) + (200 × $15/1M) = $0.00001 + $0.002 + $0.30 + $0.003 = $0.31 RAG is still cheaper at $0.31 vs $1.47, but the gap has closed. At this query volume, caching reduces long context cost by ~80%, but the sheer input token volume still dominates. RAG wins unless quality requirements force you to use full context. Example 3: High-churn corpus with moderate volume Scenario: dynamic content (support tickets, logs, live data feeds). 200k tokens context. 1,000 requests per day. Corpus churns hourly (docs updated continuously). No stable prefix to cache. Output 300 tokens. Long context cost per request: (200,000 × $3/1M) + (300 × $15/1M) = $0.60 + $0.0045 = $0.60 RAG cost per request (churn means no embedding cache sustainability): Query embedding is typically re-done: (100 × $3/1M) + $0.005 (DB query under churn) + (30,000 × $3/1M) + (300 × $15/1M) = $0.0003 + $0.005 + $0.09 + $0.0045 = $0.10 RAG is still cheaper at $0.10, but the cost difference is small enough that quality considerations might force a hybrid: BM25 hybrid search (text + semantic) to improve recall on a churning corpus without full context stuffing, or accept long context for its quality guarantees and optimize elsewhere. Why prompt caching changes the answer Prompt caching is the most disruptive economic factor in this comparison. A 1M-token cached prefix costs $1.50 per request on the first call, then $0.015 (1% of full price) on every hit. At 100 cache hits before invalidation, the amortized cost is $0.0155 per request—effectively free for input tokens. The catch is churn. Cache invalidation on a 1M-token corpus updates means you pay the write premium (25% markup) to re-prime the cache. If the corpus refreshes every hour and you get 1,000 requests per day, you are writing the cache 24 times per day, 480 cache writes per month. The cache-write cost can dominate the savings if the hit rate drops below 10-20 hits per write. Most teams find that long-context-with-caching beats RAG only when the corpus is stable for at least several hours and hit rates exceed 20+ requests per cache write cycle. The second-order caching cost is invalidation risk. A cache coherency bug (a data update that does not invalidate the prefix) results in stale context served to all downstream requests. RAG retrieves fresh data on each query, so staleness is bounded by your embedding freshness. Long context with cache bypasses that protection. The operational cost of a cache staleness incident often exceeds the infrastructure cost of running the corresponding RAG system for a year. Latency and quality as cost factors The pure cost model ignores latency and quality, and those are often decisive. Long context adds latency on the LLM call itself—a 1M-token input can take 2-5x longer to process than a 50k-token input, depending on the model's attention mechanism. RAG adds a retrieval hop (50-200ms) but reduces model latency on a small context. For end-user facing APIs under latency SLA, the calculation includes the cost of meeting that SLA. If long context's model latency pushes you past your 2-second budget and you have to over-provision for tail latency, that is a hidden cost. If RAG's retrieval hop costs you the SLA because of vector DB latency, the cost of RAG infra becomes "whatever it takes to meet the SLA." Quality is similar. Long context on a 1M-token corpus gives the model more information to reason over. RAG's top-K retrieval can miss relevant context if search precision is low. If RAG's quality loss requires you to run a re-ranking model or a second pass with fallback to full context, that cost should be in the RAG side of the equation. If the quality difference matters for your use case but not your financial viability (e.g., an internal copilot that is nice to have but not mission-critical), quality cost is a product decision, not a FinOps one. Decision matrix: long context, RAG, or hybrid Pick long context if: Query volume is under 1,000 per day and context is under 500k tokens. Pure cost wins and operational simplicity is a bonus. You have a stable corpus and prompt caching infrastructure. Cache hit rate is predictable and over 20:1 before invalidation. Quality requirements demand full context reasoning and cannot accept retrieval precision loss. Cost efficiency is secondary. Pick RAG if: Query volume is over 10,000 per day. Retrieval infrastructure cost per request is low and wins on total cost. Corpus churn is high (updates more than once per hour). Caching is unreliable and embedding updates absorb the variable cost. Retrieval quality (precision, recall) has been validated and meets product requirements. Re-ranking and fine-tuned search yield good results without full-context fallback. Your team has mature retrieval infrastructure (vector DB, embedding cache, re-ranker). Deprecating that infrastructure is a sunk-cost error—the cost to build it again elsewhere is not in the breakeven equation. Pick hybrid if: Query volume is 1,000–10,000 per day and your context is 200k–800k tokens. The cost gap is small enough that operational risk dominates. Hybrid retrieval (BM25 + semantic search) into a smaller context reduces both cost and quality risk. You have pockets of stable content and pockets of churn. Index the stable content, apply long context to the volatile layer, and route queries based on content type. Latency SLA is tight and RAG's retrieval hop is risky but long context's model latency is unacceptable. A lightweight retriever (in-process BM25) into a limited context window splits the difference. The engineering cost often decides it One variable the formula cannot quantify is engineering complexity. RAG requires building and maintaining retrieval infrastructure, fine-tuning search precision, handling edge cases where retrieval fails, and keeping embedding vectors in sync with your corpus. Long context requires nothing—you call the API with a big input. The effort to build and run each system over five years is not the same, and for some teams, the operational debt of maintaining RAG is the deciding factor to switch to long context, cost advantage or not. The flip is equally true. Teams that already have mature RAG pipelines with monitoring, chunking strategies, and query optimization in place often find that the cost to migrate away and handle the quality loss is higher than the cost to keep running RAG. Do not flip approaches on a 5–10% cost difference if your team knows one system well and is unfamiliar with the other. Building your own breakeven model To use this framework on your actual workload: Measure your query volume per day and your average context size (full corpus for long-context model, retrieved subset for RAG model). Get your current embedding cost per query and your vector DB infrastructure cost per query. If you do not track the latter, divide your monthly vector DB bill by your queries per month. Measure your corpus churn rate: what fraction of your documents change per day? If less than 5%, caching strategies matter; if over 50%, assume churn invalidates any cache. Plug into the formula. Compute long-context cost and RAG cost per request. Multiply by daily query volume to get daily spend for each approach. Run the numbers for a 20% and 50% increase in query volume (common for scaling) to see which approach scales better. Your break-even query volume is where RAG cost per request equals long-context cost per request at your actual numbers. If you are below it, long context is cheaper. If you are above it, RAG is cheaper. The width of the band where neither is obviously better is where hybrid and operational complexity should drive the decision. Related LLM cost attribution Prompt cache attribution LLM cost monitoring LLM token tracking Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ When is long context cheaper than RAG? Below a certain query volume against a stable document set, padding every request with full context costs less than maintaining retrieval infrastructure. The breakeven depends on context size, query volume, embedding cost, and document churn rate. Does prompt caching change the long-context economics? Dramatically. A cached long prefix against a stable corpus can beat RAG economics outright. Cache invalidation on a churning corpus destroys the advantage and can force re-entry to a higher-cost regime. What is the fully-loaded cost of RAG? RAG cost includes provider embedding API charges, vector store infrastructure, retrieval latency, re-ranking models, cache misses on retrieval calls, and the engineering cost to build and maintain retrieval quality. Most teams undercount by omitting infrastructure and engineering. Why does document churn matter? A stable corpus lets you amortize embedding cost over many queries. A churning corpus forces constant re-embedding, invalidates cached prefixes, and amplifies the variable cost per request. High-churn workloads favor long context with cache acceptance over strict RAG. What costs should go in the breakeven equation? Long context: full model input token cost per request, minus cache savings if cached. RAG: embedding cost per request divided by cache hits per embedding, plus vector DB query cost, plus retrieval latency cost if you pay for latency SLA, plus re-ranking cost if used. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # MCP Server Cost Impact: Tool Calls and Tokens · FinOps LLM URL: https://finopsllm.com/research/mcp-server-cost-impact MCP server cost impact Updated 4 July 2026 · first published 4 July 2026 The Model Context Protocol (MCP) lets LLMs call external tools - databases, APIs, file systems, search engines. It is powerful. It is also expensive. Every MCP tool definition consumes context window space, every tool call is a separate API round trip, and every tool result gets fed back into the model as additional input tokens. For teams running MCP-heavy agent workflows, tool-related overhead can account for 30–60% of total token spend. This article explains how MCP drives costs up, how to measure the overhead, and what to do about it. How MCP consumes tokens There are three token cost layers in every MCP interaction: Layer 1: Tool definitions. Each MCP server registers tools with the model. A tool definition includes the function name, parameter schema, and a description of what the tool does. A single tool definition typically consumes 500–2,000 tokens. A server with 15 tools adds 7.5K–30K tokens to every request - even if none of those tools are called. Layer 2: Tool call requests. When the model decides to call a tool, it generates a tool call output (function name + arguments). This is billed as output tokens. Then the tool result comes back as input tokens. A single tool call round trip typically costs 1K–5K tokens depending on result size. Layer 3: Tool results in context. Tool results stay in the conversation context for all subsequent turns. If you call 10 tools in a session, those results accumulate. A database query returning 50 rows of JSON might add 8K–15K tokens that persist for the rest of the conversation. The compounding effect MCP costs compound because tool definitions are sent with every request. If you have 20 tools defined (10K–40K tokens of definitions) and make 5 requests in a conversation, the tool definitions alone cost 50K–200K input tokens. Add the tool call results and you can easily double your baseline token consumption. MCP Pattern Token overhead Frequency Monthly cost impact (estimate) Tool definitions (10 tools) 5K–20K tokens per request Every request $15–$60 per user Single tool call round trip 1K–5K tokens 3–10 per session $5–$25 per user Large tool result (DB query, code search) 5K–20K tokens 1–5 per session $10–$50 per user Accumulated results in long session 20K–100K tokens 1–3 sessions/day $30–$120 per user Unused tool definitions loaded 5K–30K tokens per request Every request $15–$90 per user How to measure MCP overhead The simplest way to measure MCP cost is to run the same prompt twice: once with MCP tools loaded and once without. The difference in input tokens is your tool definition overhead. Then count tool call tokens separately - most providers label them distinctly in their billing dashboards. For a more precise measurement, instrument your MCP client to log: number of tools registered, tokens consumed by tool definitions per request, number of tool calls per session, tokens per tool result, and total session tokens attributed to tool activity. Strategies to reduce MCP costs 1. Load tools selectively. Do not register all tools for every request. If the user is asking a code question, they do not need database or deployment tools loaded. Many MCP clients support dynamic tool loading based on context or explicit user activation. 2. Minimize tool descriptions. Tool descriptions are the largest token consumer in definitions. A verbose description might be 500 tokens; a concise one might be 100 tokens. Across 20 tools, that is an 8K-token difference per request. 3. Truncate tool results. Return only the fields the model actually needs. If a database query returns 20 columns but the model only needs 3, project the result. Cap result size at a reasonable limit - 2K–4K tokens is usually enough for the model to make a decision. 4. Cache repeated calls. If the same tool is called with the same arguments in a session, return the cached result instead of executing again. This is especially valuable for reference lookups, schema queries, and documentation fetches. 5. Summarize before injecting. For large tool results (full file contents, long API responses), summarize before adding to context. Return a summary plus the option to fetch the full result if the model needs it. 6. Use tool-result budget limits. Set a per-session budget for tool result tokens. When the budget is reached, refuse further tool calls or switch to a cheaper model for the remainder of the session. The hidden cost of MCP servers Beyond token costs, MCP servers introduce latency and reliability overhead. A tool call that takes 3 seconds to respond adds latency to every turn. A tool that fails intermittently causes retries. Both increase effective cost per task. For teams scaling MCP usage across an organization, tracking these costs at the server level is essential. Route MCP-heavy workloads to models with lower per-token costs, and keep MCP-light workflows on premium models where latency matters. Related Agent economics - how coding agents price out in practice. Agent spend attribution - tracking agent costs by project. LLM token tracking - measuring what you spend. FinOps for LLM - the broader framework. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ How MCP consumes tokens? There are three token cost layers in every MCP interaction: Layer 1: Tool definitions. Each MCP server registers tools with the model. A tool definition includes the function name, parameter schema, and a description of what the tool does. What is the compounding effect? MCP costs compound because tool definitions are sent with every request. If you have 20 tools defined (10K–40K tokens of definitions) and make 5 requests in a conversation, the tool definitions alone cost 50K–200K input tokens. How to measure MCP overhead? The simplest way to measure MCP cost is to run the same prompt twice: once with MCP tools loaded and once without. The difference in input tokens is your tool definition overhead. Then count tool call tokens separately - most providers label them distinctly in their billing dashboards. What is the hidden cost of MCP servers? Beyond token costs, MCP servers introduce latency and reliability overhead. A tool call that takes 3 seconds to respond adds latency to every turn. A tool that fails intermittently causes retries. Both increase effective cost per task. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Control MCP tool definition token overhead · FinOps LLM URL: https://finopsllm.com/research/mcp-tool-definition-overhead Control MCP tool definition token overhead in agent workflows Updated September 19, 2026 · first published September 19, 2026 Quick answer: Connecting an AI agent to multiple Model Context Protocol (MCP) servers injects thousands of input tokens on every turn before the model reads a single word of user intent. Every registered tool... Connecting an AI agent to multiple Model Context Protocol (MCP) servers injects thousands of input tokens on every turn before the model reads a single word of user intent. Every registered tool appends a JSON schema containing function names, parameter descriptions, enum definitions, and type constraints. In an enterprise workspace with 6 connected MCP servers (GitHub, Postgres, Slack, Jira, Brave Search, Filesystem), this tool preamble consumes 4,500 to 12,000 input tokens per API call. At 30 turns across a task, that static overhead drains $0.35 to $1.20 in pure schema redundancy. The anatomy of MCP schema tax The Model Context Protocol establishes a standard client-server JSON-RPC interface for LLM capabilities. However, language models cannot infer tool availability without explicit schema injection in the system prompt or tool definition parameter block. When an engineer connects a database MCP server with 24 schema-inspection and SQL tools, the full JSON schema must be presented to the model on every inference turn so the attention mechanism can route tool calls. Because standard API billing meters total input tokens on every request, unmanaged MCP tool catalogues create an immediate, linear baseline tax across all agent operations. Why do MCP server tool definitions cost so many tokens? Each MCP tool definition requires verbose metadata: parameter names, nested properties, human-readable descriptions, and JSON Schema specification headers. A single detailed database query tool often consumes 350 to 600 tokens. Across dozens of tools spanning multiple departmental MCP servers, the initial context window is occupied by static tool contracts rather than dynamic conversational history. Three architectures to eliminate MCP overhead Engineering teams running production agent fleets deploy three distinct mitigation strategies to control tool token inflation: Prompt Caching Breakpoints: Place the static MCP tool definitions before any dynamic conversation history in the prompt structure, and set an explicit prompt caching breakpoint immediately after the tool block. On Anthropic, OpenAI, and Google Gemini models supporting 5-minute or 1-hour cache TTLs, cache hits reduce the input token cost of the tool schema by 75% to 90% after the first turn. Dynamic Two-Stage Tool Registration: Avoid exposing all MCP tools globally. Use a lightweight router model or semantic index to identify the specific tool domain required by the user prompt, dynamically injecting only the relevant 3–5 tool schemas into the execution agent's active payload. Schema Compression and Description Minification: Strip verbose formatting, eliminate markdown descriptions within JSON schema strings, and replace long field explanations with compact type definitions. Aggressive schema minification typically cuts tool definition payload volume by 35% to 50% without degrading tool selection accuracy. How can engineering teams reduce MCP tool token overhead? Teams reduce MCP overhead by setting prompt cache breakpoints after tool declarations, employing two-stage semantic tool routing, and minifying redundant JSON schema property descriptions. Can prompt caching eliminate MCP schema token costs? While prompt caching cannot eliminate token processing latency entirely, it slashes the billing cost of recurrent tool definition tokens by up to 90% on models that support prefix caching, provided the tool definition block remains identical across consecutive turns. Related Server tools and separate invoices Prompt caching economics Agent spend guardrails Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # MiMo v2.6 and the Open-Weights Price Ceiling · FinOps LLM URL: https://finopsllm.com/research/mimo-v2-6-open-weights-price-ceiling MiMo v2.6 and the open-weights price ceiling Updated September 27, 2026 · first published September 27, 2026 MiMo v2.6 from Xiaomi posted on 21 September 2026 and took 1,130 points and 479 comments on Hacker News — the loudest single launch of the month. Within days Xiaomi was reporting the Pro variant as the highest-scoring open-source model on Artificial Analysis, and a community benchmark repo was publishing Terminal-Bench 2.1 figures for the Flash tier at 87.6%, GPQA Diamond at 83.7, AIME 2025 at 94.1 and CyberGym at 95.1. Why a launch like this matters to a bill An open-weight model at the top of the quality ranking is a pricing constraint, not just an option. API providers cannot hold a mid-tier price for a model that a capable open-weight alternative can be self-hosted at. Every credible open-weight release compresses the margin on the tier directly below the frontier. This is why the September price cuts happened when they did, and why the next round is already predictable. The arithmetic of a self-host Self-hosting is not automatically cheaper. The full comparison: Token-equivalent cost: GPU cost divided by achievable tokens per GPU-hour, including the utilisation loss from batching and idle time. At 35% utilisation a self-hosted open-weight model often loses to a heavily discounted API tier. Ops tax: capacity planning, on-call, image updates, and the eval burden of tracking upstream releases. This is the same overhead that made fine-tuning fail for one team in September. Capability ceiling: for a fixed number of engineers, a self-host of a frontier-adjacent model is a poor trade. It is a good trade when the model is good enough and the volume is steady. The crossover is almost always around high, steady, low-variance volume on tasks the model is genuinely good at. A 27B open-weights creative-writing model reported this month at Fable 5 level and roughly 40x cheaper pricing is the shape of the trade when the model fits the task. Free tiers are the acquisition channel The Flash tier also appears as a free variant in community provider lists, alongside a paid tier — which is why Minimax M3.1 Flash's free preview and similar offers are worth routing to. Treat every free tier as a dated, temporary acquisition channel, and build the failover from the day you adopt it. What to do this quarter Re-check the open-weight leaderboard monthly. The gap closed 40% in a month in the creative-writing case. Assume it closes again. Compute your self-host crossover explicitly. Utilisation assumption, not list price, decides it. Treat every free tier as expiring. Router failover is a day-one requirement, not a later ticket. Hold model selection fungible. The value of an open-weight leader is the optionality it gives you at renewal, not the token price today. Bottom line MiMo v2.6 matters as pricing pressure. A capable open-weight model at the top of the ranking means mid-tier API prices have a ceiling set by compute cost, not by vendor strategy. That is the single most durable cost lever available to a FinOps team right now. Related Pricing an open-weight model Ox Alpha was GLM 5.3 Free tier is an acquisition cost Stealth model free-tokens playbook Cost of switching LLM providers Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Minimax M3.1 Flash: Free Preview Economics · FinOps LLM URL: https://finopsllm.com/research/minimax-m3-1-flash-free-preview-economics Minimax M3.1 Flash free preview economics Updated September 26, 2026 · first published September 26, 2026 What we know Free preview on Minimax Code (duration unspecified) Focus: speed + efficiency for daily coding tasks Cost model: $0 during preview During the free preview, M3.1 Flash is a $0 marginal cost model for supported workloads. The catch: preview ends Free previews are customer acquisition. When it ends, expect pricing in the $1-3 per 1M input / $5-15 per 1M output range. Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Model deprecation migration: budgeting for forced moves · FinOps LLM URL: https://finopsllm.com/research/model-deprecation-migration-costs Model deprecation migration: budgeting for forced moves Published 19 July 2026 Model deprecation is no longer rare. OpenAI's Assistants API sunsets on August 26, 2026—38 days away. The GPT-4o family was already retired in February. Sora 2 video generation deprecates in September. Older GPT-5 snapshots in December. Every deprecation forces your team to re-evaluate, re-benchmark, re-train evaluation suites, and often re-price against a different model with unknown token economics. These are not simple model swaps. They are unplanned engineering projects that cost 4–8 weeks and $4K–$12K in hidden labor. This is a FinOps problem, not just an engineering one. OpenAI Assistants API sunset: August 26, 2026 (38 days) GPT-4o family already deprecated (Feb 2026); o3 ChatGPT sunset Aug 26 Sora 2 / Videos API sunset: September 24, 2026 Older GPT-5/o3 snapshots sunset: December 11, 2026 Migration is capex + unplanned ops, not just a pricing change Build a deprecation register today; catch 90-day warnings before crisis Immediate exposure: If you use OpenAI Assistants API, you have 38 days to migrate. If you depend on model snapshots (e.g., gpt-4-turbo-2024-04-09), check their announced EOL. Do not wait for breaking errors—plan the migration now. Why Deprecation Is a FinOps Event Model retirement looks simple: use model X until date Y, then switch to model Z. But the actual cost is not X→Z. It's: Re-evaluation and Benchmarking Measure the replacement model on your holdout test set. Does it match quality? Latency? Token efficiency? A customer-facing system may need 100–500 test cases benchmarked. Budget: 2–3 weeks, $1K–$3K. Prompt and Evaluation Retraining If you fine-tuned or built task-specific prompts on GPT-4o, those prompts often underperform on a new model. Rewrite them. If you built evals with cached prefixes (prompt caching), the cache hash changes with the new model—prefixes invalidate and must be rebuilt. Evals that run in 10 seconds now run in 30. Budget: 1–2 weeks, $500–$2K. Regression Testing and Dual-Running For production systems, run old and new models in parallel for 2–4 weeks. Compare outputs on real traffic. This doubles inference cost during the trial. Budget: $500–$2K in extra inference + 1–2 weeks engineering. Token Economy Surprises The replacement model has different pricing: reasoning tokens cost more, output is cheaper, cache behavior differs. A model that was $0.50 per request may become $0.75 or $0.25—you won't know until you test. Re-forecast your annual spend. Integration Changes If you migrate from Assistants API to Responses API, or from one provider to another, integration changes ripple: error handling, retry logic, timeout configs, logging. Budget: 1–2 weeks, $500–$1.5K. Ongoing Monitoring and Drift After migration, monitor the new model's performance for quality drift, latency creep, and cost anomalies. Set up alerts. For open-source or less-stable models, factor in retraining overhead. Budget: +$200–$500/month ongoing. Total hidden cost per migration: $4K–$12K in engineering + $500–$2K in dual-running inference cost. Multiply by the number of models you deprecate. Most organizations underestimate this by 50%. 2026 Deprecation Timeline: What's Already Gone and What's Coming Date (2026) Model / API Status Impact February 16 GPT-4o, GPT-4.1, GPT-4.1 mini, o4-mini Retired (API returns 404) Already past—check your logs for stranded calls May–June Various GPT-4 preview snapshots Deprecated If you pinned a snapshot, validation needed now August 26 (38 days) OpenAI Assistants API Sunsetting Migrate to Responses API or non-OpenAI platform August 26 o3 (ChatGPT only) Retiring from ChatGPT API unchanged; ChatGPT users must use alternative September 24 Sora 2, Videos API Deprecating Migrate to next-gen video model or provider December 11 Older GPT-5, o3 snapshots Sunsetting If you pinned a snapshot, 144 days to migrate Pattern: OpenAI gives 6 months notice for GA models, 3 months for variants, 2–3 weeks for previews. This is getting tighter. Any model you pin is ticking toward a deadline. The Cost of Migration: Worked Examples Scenario 1: Assistants API → Responses API Your team built a customer support chatbot on Assistants API. 50K calls/month, each averaging 1K input + 200 output tokens. Monthly cost: (50K × 1K × $0.003 + 50K × 200 × $0.015) = $150 + $150 = $300/month. Migration work: Rewrite the stateful conversation handler from Assistants to Responses (they have different session management). Rewrite the file/retrieval plugin integration. Regression-test 100 customer tickets. Run both paths in parallel for 2 weeks. Cost breakdown: Engineering re-write: 2 weeks = $2K–$4K Regression testing: 1 week = $1K–$2K Dual-running inference (2 weeks, 2× cost): 2 × $300 = $600 Post-migration monitoring: ongoing +$200/month Total first-month cost: $3.6K–$6.6K + $200/month ongoing If your Assistants bill was $300/month, the migration work is 12–22× the monthly cost. This is why it's capex, not a line-item price adjustment. Scenario 2: GPT-4o Snapshot Pinning Your eval suite pins gpt-4-turbo-2024-04-09. In May 2026, OpenAI announces the snapshot will sunset on December 11. You have 6 months. But in practice: Month 1 (May–June): You read the notice. No immediate action. Month 2 (July): You benchmark gpt-4-turbo-2024-12-01 (the latest). It's 5% faster, 2% cheaper. You schedule migration for August. Month 3 (August): You run eval suite on new snapshot. 1–2% regression. You investigate. Takes 1 week, $500–$1K to tune prompts and re-baseline. Month 4 (September): Eval suite switched. But your deployed system also pins the snapshot. That's another week of testing and rollout. Month 5–6 (Oct–Nov): You catch an edge case where the new model behaves differently on 0.5% of queries. Another $1K to investigate and fix. You're now at November 30, one week from deadline. Month 6 (December 11): You're live on the new snapshot with 1 day of margin. Total cost for "simple" snapshot rotation: $3K–$4K + 2–3 weeks of distributed engineering. And you almost missed the deadline. The risk cost (crisis mode, Saturday deploys) can double that. Scenario 3: Repricing on Model Replacement You switch from GPT-4o (retired) to GPT-5.6 Terra. Assistants API (Responses API) pricing changes the token accounting: Component GPT-4o (Old) GPT-5.6 Terra (New) Per 1M Calls (avg 1K in / 200 out) Input cost per 1M $3.00 $2.50 –$500 Output cost per 1M $15.00 $15.00 $0 Monthly cost (50K calls) $300 $275 –$25 On the surface, you save $25/month. But Terra has worse reasoning performance on edge cases. You tune prompts (+$1K), run evals (+$2K), dual-run for 2 weeks (+$600), and then discover Terra has different error modes. You need different retry logic (+$500). You're $4.1K in cost on a $25/month savings. It's not profitable unless your volume is 10x higher and the savings compound. The lesson: Replacement model pricing is rarely neutral. Factor in the hidden costs before budgeting the "savings." Building a Deprecation Register Start with a simple spreadsheet or GitHub issue template. Track every model your organization uses and depends on. Update it monthly. Deprecation Register Columns Model / API : e.g., "gpt-4o", "Assistants API", "gpt-4-turbo-2024-04-09" Current Provider : OpenAI, Anthropic, Google, etc. Announced EOL Date : e.g., "August 26, 2026" or "TBD" Days Until EOL : Auto-calculated; flag if ≤90 Monthly Spend : Actual spend on this model from billing data Exposure (% of total LLM spend) : $X / total LLM budget Replacement Model Identified? : Yes / No / In Testing Replacement Spend Impact : Modeled cost on new model Stranded? : Yes (no replacement yet, EOL in Owner : Eng lead responsible for migration Migration Start Date : When testing begins Migration Complete Date : When live on replacement Red flags to act on immediately: Any row with "Stranded = Yes" Any "Days Until EOL" ≤ 90 Monthly spend > 10% of total budget and no replacement tested yet Replacement spend impact is >20% higher than current model Review the register in your monthly FinOps meeting. Escalate red flags. Assign owners. Practical Mitigation: Avoid Being Stranded 1. Abstraction at the Gateway Layer Do not pin specific model versions in application code. Create an abstraction layer that routes requests to "current-best" for your use case: // Instead of: const model = "gpt-4-turbo-2024-04-09"; // Hardcoded snapshot // Use: const model = getModelForTask("classification"); // Returns current-best // getModelForTask updates via config, not code redeploy When a model deprecates, update the config in one place. No app redeploy. No version-pinning that gets stranded. 2. Avoid Snapshot Pinning Beyond 6 Months If you pin a snapshot for reproducibility or compliance, commit to a sunset date 180 days out. Set a calendar alert at 160 days to start testing the next snapshot. Do not let the deadline surprise you. 3. Run Evals Quarterly on Latest Even if you use a stable model name (e.g., "gpt-4-turbo-latest"), the underlying model gets updated by the provider. Run your eval suite every quarter on the current-latest version. This catches drift early and gives you warning before a hard deprecation forces the issue. 4. Keep Eval Suites Cheap to Re-run If evals cost $500 per run, you'll skip them. If they cost $20, you'll run them on demand. Use cheaper models (e.g., Claude Haiku) as scaffolding for evals, not the final model. Cache prompts to cut eval cost by 50–80%. This makes migration faster and less risky. 5. Version Your Eval Results Before and after migration, keep side-by-side eval results. If something regresses post-launch, you need to know whether it's the model or your prompt. Store baseline evals in version control. Makes debugging fast. Hidden Costs Checklist Use this checklist when planning a model migration to catch hidden expenses: Cost Item Low Estimate High Estimate Applies To You? Re-evaluation / benchmarking $1K $3K 2–3 weeks engineering Regression testing (manual + A/B) $2K $5K 1–2 weeks, customer-facing systems Dual-running inference (2–4 weeks) $500 $2K 2× inference cost during trial Integration & API changes $500 $1.5K Assistants → Responses, or provider swap Prompt & eval retraining $500 $2K Fine-tuned or snapshot-optimized systems Ongoing monitoring & drift (first month) $0 $500 Set up alerts, logging infrastructure Total (per migration) $4K $12K 4–8 weeks engineering Ongoing monthly overhead (post-migration) $200 $500 Monitoring, tuning, next-model tracking Forecast: Deprecations Will Accelerate 2026 has already seen GPT-4o removed, Assistants API sunsetting, and Sora 2 deprecating. This is becoming the norm, not an exception. As models improve faster, providers sunset older versions more aggressively to reduce inference cost and reduce the support surface. Budget 2–3 major model migrations per year per LLM workload. Factor the $4K–$12K per migration into your annual FinOps plan. Action Plan (Next 90 Days) This Week Audit all models your org uses. Check OpenAI's deprecation docs , Anthropic , and other providers for announced EOLs. Create a deprecation register (spreadsheet or GitHub issues). Flag any model with EOL ≤ 90 days. Assign an owner. Next 2 Weeks For any stranded model (no replacement identified): start benchmarking candidates. Budget $1K–$2K for testing. For Assistants API users: read the Responses API migration guide . Estimate integration cost. Next 30 Days Finalize replacement model choice. Lock cost forecast. Start dual-running if possible (A/B test on production traffic). Assign migration owner and commit to completion date. Update your annual FinOps budget: add $4K–$12K per model migration + $200–$500/month ongoing monitoring. Before EOL Date Complete regression testing. Go live on replacement. Set up post-migration monitoring. Watch for quality drift, cost anomalies. Document the migration: what broke, what cost more than expected, lessons for next time. Related Reading For context on model economics more broadly, see Open-Source vs Closed-Source LLM Cost Comparison , which compares stable vs. volatile vendor pricing. See also OpenAI Fine-Tuning Sunset Economics for a deep-dive into one high-stakes deprecation. Model deprecation is not a surprise—it's a scheduled cost center. Build the register, budget the work, and migrate before the deadline. FinOps LLM helps organizations track deprecation exposure across their model portfolio and forecast the true cost of forced migrations. Book a free audit . Back to research FAQ Is model deprecation a FinOps issue? Yes. Deprecation forces re-evaluation, re-training of evals, re-benchmarking, dual-running, and adapter retraining. The new model often has different token economics—reasoning-token pricing, cache behavior, output costs all differ. This is unplanned work that appears as capex, not just a model swap. A deprecation cascade can push 4–8 weeks of engineering time and $2K–$10K in hidden costs per model. How much does a model migration typically cost? Plan for: (1) re-evaluation (2–3 weeks, $1K–$3K); (2) regression testing (1–2 weeks, $2K–$5K); (3) dual-running in production (2–4 weeks, 2× inference cost, $500–$2K); (4) retraining workflows if you retrain monthly (1–2 weeks, $500–$1.5K); (5) monitoring and drift detection (ongoing, +$200–$500/month). Total hidden cost: $4K–$12K + 4–8 weeks. What is a deprecation register? A registry tracking every model your org depends on, its announced EOL date, your current monthly spend on that model, and a 'stranded' flag if you haven't yet validated a replacement. Update it monthly. Use it to detect when deprecations are 90 days or less out. How do I avoid being stranded by a snapshot sunset? Avoid version-pinning beyond 6 months. Use abstract model identifiers (e.g., 'gpt-4-turbo-latest' not 'gpt-4-turbo-2024-04-09'). Run your eval suite quarterly on current-latest to catch drift early. If you pin a snapshot for reproducibility, set a 180-day review date and commit to a migration timeline before the deadline hits. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Model price cuts do not lower your AI bill automatically · FinOps LLM URL: https://finopsllm.com/research/model-price-cuts-routing-budget Model price cuts and the routing budget Updated September 10, 2026 · first published September 10, 2026 Quick answer: Model prices are falling quickly, but a lower list price does not automatically produce a lower company bill. Teams often respond to a price cut by increasing usage, keeping premium routing in place,... Model prices are falling quickly, but a lower list price does not automatically produce a lower company bill. Teams often respond to a price cut by increasing usage, keeping premium routing in place, or expanding context and output limits until the savings disappear. The relevant question is not whether price per token fell; it is whether cost per successful task fell. OpenAI's GPT-5.6 pricing update illustrates the pattern: lower-cost models are positioned for high-volume work, while faster or more capable tiers serve workloads where quality or latency justifies a premium. The same announcement highlights Batch, Flex processing, and prompt caching as ways to match capacity and workload shape to cost. Rebaseline by workload Do not apply a single percentage reduction to the whole invoice. Split spend by workload class: interactive support, extraction, coding, agent planning, evaluation, and batch enrichment. For each class record quality, latency, success rate, tokens, and provider price. Then calculate the current cost per successful task before deciding what to move. A price cut can change the routing frontier. A model that was previously too expensive for classification may now be the cheapest option after accounting for retries and failure rates. Conversely, a cheap model that produces more invalid outputs can cost more after repair calls and human review. Use the right lane Interactive work needs predictable latency. Repeated context may benefit from caching. Non-urgent work may fit batch or flexible processing. High-volume production may justify committed capacity. The savings come from matching the workload to the commercial lane, not from choosing the lowest token price in isolation. Keep routing behind a feature flag and run a quality-and-cost comparison long enough to cover normal traffic variation. Compare total task cost, including fallback calls, cache behavior, tool calls, and post-processing. If the new route fails its quality SLO, roll it back even when its token price looks attractive. Make price changes operational Track provider price history with effective dates. Recalculate budgets and forecasts when a price changes. Notify workload owners when their routing frontier moves. Measure realized savings against invoices, not a spreadsheet estimate. Use the freed budget deliberately: more users, better quality, or lower spend. Price changes are opportunities to improve allocation, not reasons to stop measuring. A mature FinOps program treats every new model tier as a routing experiment with an owner, baseline, and success metric. Related Model routing Why provider prices are not comparable Cost per successful task Related Model routing Why provider prices are not comparable Cost per successful task Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Model Routing: Cheaper Models, Same Output Quality · FinOps LLM URL: https://finopsllm.com/research/model-routing Model routing Model routing is the highest-leverage lever in many LLM programs because not every request needs the same model. Some requests need deep reasoning, some need extraction, some need classification, and many need simple, cheap responses. Routing uses that difference to lower cost without turning the whole product into the cheapest possible model. Good routing begins with segmentation. Break traffic into workloads based on task type, expected difficulty, required output quality, latency tolerance, and whether the request can be retried or escalated. If those segments are mixed together, routing decisions become impossible to evaluate. A small route change might look good on average while hurting a narrow but important workload. Routing inputs Routing systems usually combine a few signals. The first is task type. A summary request, a structured extraction task, and a conversational assistant should not share the same policy. The second is request complexity. Length, number of retrieved chunks, presence of tool calls, and historical failure patterns all help. The third is confidence. If a cheap model is uncertain, the request can be escalated to a stronger one. The fourth is business priority. A high-value customer or a critical support flow may justify a stronger model sooner. Do not overfit the router to one prompt family. It is better to start with a simple two-stage design: cheap model first, strong model on uncertainty or failure. That pattern is easy to explain and measure. As the dataset grows, add more specialization for extraction, reasoning, and batchable tasks. What to measure Routing success is not the lowest provider bill. The metric is cost per successful task under a stable quality bar. That means measuring accuracy, human review outcomes, user satisfaction, or downstream completion rate alongside cost. A router that saves 20% but doubles retries is not a win. A router that saves 35% while keeping quality within threshold is. Track escalation rate, fallback rate, route confidence, and the share of traffic handled by each model. Those metrics show whether the router is becoming too conservative or too aggressive. If everything escalates, the router is not saving enough. If too much traffic stays on cheap models and the quality signals decay, the router is over-optimizing cost. Deployment pattern Start with shadow mode. Log the route decision the router would have made, but do not enforce it yet. Compare the cheap-vs-strong model outcomes on a sample set. Then ship behind a feature flag for a narrow slice of traffic. Keep a fallback to the stronger model. For many programs the final implementation is not “one router for everything” but “a router policy per workload family.” That gives teams room to tune extraction, classification, and reasoning separately. Model routing pays best when paired with attribution. If routing saves money but nobody knows which endpoint changed, it is hard to keep the policy healthy. The teams that sustain savings are the ones that can see route mix, quality, and owner impact in the same review. Related Provider arbitrage - comparing models across providers. AI cost optimization - comprehensive optimization strategies. GenAI cost management - applying optimization across the platform. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Safety checks are a second bill · FinOps LLM URL: https://finopsllm.com/research/moderation-pass-second-bill What guardrail and moderation passes cost Updated September 1, 2026 · first published September 1, 2026 Quick answer: A production LLM feature rarely makes one model call. It makes the call you designed, and then one or more calls you added later for safety: an input classifier, an output check, a policy judge,... A production LLM feature rarely makes one model call. It makes the call you designed, and then one or more calls you added later for safety: an input classifier, an output check, a policy judge, sometimes a second model grading the first. Each of those is inference, and inference is billed. The multiplier is bigger than it looks Count the passes honestly. Input moderation reads the full user input. Output moderation reads the full generated response. A policy or groundedness judge usually reads both , plus the retrieved context, plus a rubric — which makes the judge call larger than the call it is judging. Add a jailbreak classifier and a PII scan and a single user request has become five inference calls. The costs are not equal. Dedicated moderation endpoints are cheap or free on some providers. A general-purpose model used as a judge is not: it is priced like any other call, and judging a long answer against a long rubric is a long call. Where the spend actually accumulates Three patterns dominate. Judging with a frontier model because it was easiest to reuse the same client — classification is the one task where a small model is genuinely sufficient, and this is often the single largest saving available. Checking on every turn of a long conversation, re-scanning history that was already cleared. And guardrails on internal traffic , where an evaluation harness or an internal tool inherits the full consumer-facing safety stack it does not need. Budget it as a line, not a rounding error The point is not to remove the checks. It is that a safety stack can be 30–50% of a feature's inference cost while appearing nowhere in the plan, because everyone counted the model that answers and nobody counted the models that check. Tag guardrail calls separately in telemetry so the ratio is visible. Then use the cheapest model that holds the required accuracy, run checks on new content rather than whole histories, and decide per surface which checks a given traffic class actually requires. Related LLM cost attribution Evals as cost control Model routing Related LLM cost attribution Evals as cost control Model routing Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Multi-provider, multi-team LLM FinOps · FinOps LLM URL: https://finopsllm.com/research/multi-provider-llm-finops Multi-provider, multi-team LLM FinOps Updated 20 June 2026 · first published 20 June 2026 Once LLM spend lives in more than one place - OpenAI for one product, Anthropic for another, Bedrock for the regulated workload - and more than one team is spending it, no single bill is the problem. The problem is the umbrella: getting one comparable number across providers and one clean rollup across teams. This page is about the umbrella layer that sits above any individual provider's FinOps. Why "add up the invoices" doesn't work Each provider counts and discounts differently. Token accounting varies, cache-read discounts differ sharply (OpenAI's cached input runs about 50% off; Anthropic's prompt-cache reads about 90% off; Bedrock depends on the model and region), and reasoning-token billing is not uniform. Summing three invoices gives you a total, but not a number you can compare, attribute, or forecast. The umbrella has to normalize before it aggregates. Normalize the unit before you compare providers Pick one unit that is provider-agnostic and report everything in it: cost per successful task . Spend per token is not comparable across providers because the work done per token differs; spend per completed unit of work is. Underneath that headline, keep input, output, and cache-read tokens as separate measures per provider so the discounts stay visible - collapsing them hides exactly the lever that differs most between vendors. One attribution schema across teams and providers Every cost record, whichever provider it came from, should carry the same dimensions: team , product surface , environment , provider , and model . Adding provider as a first-class dimension is what makes the umbrella work - it lets you answer "what does this team cost" independent of which vendor served the request, and "what would moving this workload cost" when you evaluate provider arbitrage . The attribution discipline itself is covered in LLM cost attribution . Reconcile per provider, report as one number Gateway logs give a fast, approximate, normalized view across all providers; each provider's invoice is the source of truth for that provider. So reconciliation is per-provider - match derived spend to each bill within a documented tolerance - but the report that goes to finance is the single normalized rollup. Keep both: the per-provider reconciliation is what keeps the umbrella honest, and the rollup is what the business actually budgets against. The mechanics of matching logs to each bill are in invoice reconciliation for AI bills . The multi-team trap: showback before chargeback The instinct with multiple teams is to start charging spend back immediately. Resist it until attribution coverage is high and the numbers have survived a couple of monthly reconciliations. Start with showback - every team sees its own normalized cost - and move to chargeback only once the data is trusted. Charging back numbers that later turn out to be 20% off destroys the function's credibility faster than no chargeback at all. Budgets and guardrails per team come from LLM budget governance . Related FinOps for LLM: a practical framework - the operating model in full. What is LLM FinOps? - the foundational definition and scope. LLM cost attribution - the attribution dimensions in depth. Provider arbitrage - same model, different price across vendors. LLM budget governance - budgets, alerts, and guardrails. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ Why doesn't "add up the invoices" work? Each provider counts and discounts differently. Token accounting varies, cache-read discounts differ sharply (OpenAI's cached input runs about 50% off; Anthropic's prompt-cache reads about 90% off; Bedrock depends on the model and region), and reasoning-token billing is not uniform. How do you normalize the unit across providers? Pick one unit that is provider-agnostic and report everything in it: cost per successful task. Spend per token is not comparable across providers because the work done per token differs; spend per completed unit of work is. Why use one attribution schema across teams and providers? Every cost record, whichever provider it came from, should carry the same dimensions: team, product surface, environment, provider, and model. Should you reconcile per provider or report one number? Gateway logs give a fast, approximate, normalized view across all providers; each provider's invoice is the source of truth for that provider. What is the multi-team trap with showback and chargeback? The instinct with multiple teams is to start charging spend back immediately. Resist it until attribution coverage is high and the numbers have survived a couple of monthly reconciliations. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Multimodal cost allocation · FinOps LLM URL: https://finopsllm.com/research/multimodal-cost-allocation Multimodal cost allocation Updated 21 May 2026 · first published 21 May 2026 Most LLM allocation models were built when AI spend meant text in, text out. A single token-price table, a tag per request, and a monthly chargeback report were enough. Once image inputs, image generation, audio transcription, and realtime voice sessions enter the same product, that model stops working. Modalities have different unit economics, different ownership patterns, and different abuse profiles, and a flat "AI cost" line on the engineering ledger hides all of it. This page is about how to allocate multimodal spend so each team sees what it actually consumes, and finance has a defensible chargeback story. Why one unit doesn't fit every modality Text spend is tidy: input tokens, output tokens, cached input tokens, all priced per million. Image and audio do not flatten into the same unit cleanly. An image input is billed by tile count derived from resolution and detail mode. Image generation is billed per image, but the price varies by quality tier and output size. Realtime audio is billed per minute of session, with separate input and output rates and sometimes a different rate for voice vs transcript. Trying to express all of that as a single "tokens" column on a chargeback report either rounds away real differences or invents a synthetic unit that nobody trusts. The practical move is to keep modality-native units in the ledger and only convert to dollars at the allocation layer. Store image-tile counts on image rows, audio seconds on audio rows, and tokens on text rows. The unit price comes from a per-modality price book, not from a global token rate. The minimum tag set for multimodal attribution Single-tenant text systems can often get by tagging only team and feature. Multimodal raises the dimensionality. The tag set that holds up under chargeback review usually includes: Modality - text, vision input, image generation, audio input, audio output, realtime session, embeddings. This is the primary cost-center axis. Owner team - the team whose product surface triggered the call, not the team that owns the shared service. Cost center - finance code, often coarser than team (e.g. "Growth", "Support", "Trust & Safety"). Surface - the user-visible feature: receipt scan, voice agent, hero image generator, document OCR. Environment - production, staging, eval, internal tool. Eval traffic for an image model can dominate a launch month and should not chargeback to product teams. Tier - quality or detail setting. Low-detail vision and HD image generation are different cost objects, not the same cost object at different prices. If any of these tags are missing at the call site, the allocation engine has to guess, and finance ends up arguing about the guess every month. Shared image service vs team-owned generation Image generation is the most common shared service in a mature AI org. One platform team owns a "make an image" endpoint that wraps prompt safety, brand checks, content moderation, and a small bench of providers. Marketing, product, support, and the docs team all call it. The convenient thing about a shared service is also the dangerous thing: by default, the cost lives on the platform team's budget and no caller sees what they cost. Two allocation patterns work here. The first is full passthrough: the shared service measures the underlying provider cost per call, adds a small operational margin if finance allows it, and books the line to the calling team's cost center. The platform team's own ledger only carries the infrastructure and a small unallocated pool for failed or moderated requests. The second is rate-card showback: the platform team publishes a fixed internal price per quality tier (e.g. "standard image: $0.02, HD image: $0.08") and bills callers against that card. Real provider cost lives on the platform team, and any spread between card and actual is the platform team's variance. Passthrough is more accurate; rate cards are more predictable. Most orgs end up with a hybrid: a rate card for the common path so product teams can budget, and passthrough for anything outside the card (custom resolutions, experimental providers, on-demand large batches). Realtime audio sessions as a quota category Realtime voice is the modality most likely to break a naive allocation model. A single inattentive session left open in a kiosk or background tab can run for hours and produce a five-figure surprise. The cost driver is wall-clock session minutes, not request count, so per-request budgets are useless and per-team monthly caps are too coarse. Treat realtime audio as its own quota category, separate from text and from non-realtime audio. Allocate it with three controls layered together. First, a per-session ceiling on duration, enforced server side, with a hard cut and a clear user-facing message. Second, a per-user or per-tenant daily minute budget, with overflow charged to a designated cost center rather than silently absorbed. Third, a team-level monthly minute budget that finance reviews like any other capacity line. This three-layer model is what makes realtime allocatable. Without it, realtime sits on a single shared invoice line and the team that runs the voice agent pays for everyone else's stuck sessions. Mapping modalities to cost centers Cost centers in finance systems usually predate AI by years. They are functional: Sales, Marketing, Product, Support, R&D, Trust & Safety, Internal Tools. Modalities map to those cost centers differently than text does, and the mapping is worth making explicit. Vision input tends to concentrate in Support (receipt and document checks), Trust & Safety (content moderation), and Product (in-app scanning features). The cost center is usually obvious from the surface. Image generation spreads across Marketing (campaign assets), Product (in-app generation features), and Sales (proposal and pitch material). The same shared service serves all three, and the cost center comes from the caller, not from the service. Audio transcription tends to live in Sales (call recording) and Support (ticket transcripts). It often gets billed to the CRM line rather than the AI line, which is fine as long as the routing is explicit. Realtime voice sits in Support (voice agent), Product (voice features), and sometimes Internal Tools (operator dialers). Embeddings for multimodal search typically belong to whichever team owns the search index, not to the team whose data is being indexed. The discipline is to write this mapping down once, get finance to sign off on it, and then enforce it in the allocation engine. Surprise re-mappings mid-quarter are how chargeback programs lose internal credibility. Building the chargeback report A defensible multimodal chargeback report has a few properties. It shows each team's spend broken out by modality, not just a single AI total. It separates production from eval and internal-tool traffic so launch months do not punish product teams. It lists the top surfaces by spend within each modality, so engineering leads can see which features are driving their line. And it reconciles to the provider invoice within a tolerance the finance team has agreed to up front - typically one or two percent - with a named unallocated bucket for the gap. The unallocated bucket is non-negotiable. Without it, every rounding error and untagged request becomes a fight. With it, the conversation moves to shrinking the bucket over time rather than disputing individual lines. Common failure modes The patterns that quietly destroy multimodal allocation are usually procedural, not technical. A platform team adds a new modality and forgets to extend the tag schema, so three months of spend land in an "other" bucket. A product team A/B tests a higher image-quality tier and the experiment runs to 100% before anyone updates the rate card. A realtime feature ships without per-session ceilings and a single tenant burns through the team's monthly budget in a weekend. A support tool starts calling vision inputs at high detail because the prompt template changed, and the cost center sees a 4x lift with no product change. Each of these is preventable with a tagging review, a rate-card review, and a per-modality budget review on the same cadence finance uses for everything else. Multimodal is not unmanageable; it just refuses to be managed as if it were text with a different label. Related LLM cost attribution LLM chargeback and showback LLM budget governance AI FinOps Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ Why one unit doesn't fit every modality? Text spend is tidy: input tokens, output tokens, cached input tokens, all priced per million. Image and audio do not flatten into the same unit cleanly. An image input is billed by tile count derived from resolution and detail mode. What is the minimum tag set for multimodal attribution? Single-tenant text systems can often get by tagging only team and feature. Multimodal raises the dimensionality. The tag set that holds up under chargeback review usually includes: Modality - text, vision input, image generation, audio input, audio output, realtime session, embeddings. Shared image service or team-owned generation? Image generation is the most common shared service in a mature AI org. One platform team owns a "make an image" endpoint that wraps prompt safety, brand checks, content moderation, and a small bench of providers. Marketing, product, support, and the docs team all call it. How should realtime audio sessions be quota'd? Realtime voice is the modality most likely to break a naive allocation model. A single inattentive session left open in a kiosk or background tab can run for hours and produce a five-figure surprise. How do you map modalities to cost centers? Cost centers in finance systems usually predate AI by years. They are functional: Sales, Marketing, Product, Support, R&D, Trust & Safety, Internal Tools. Modalities map to those cost centers differently than text does, and the mapping is worth making explicit. What goes into a multimodal chargeback report? A defensible multimodal chargeback report has a few properties. It shows each team's spend broken out by modality, not just a single AI total. It separates production from eval and internal-tool traffic so launch months do not punish product teams. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Your dev environment is a prod workload · FinOps LLM URL: https://finopsllm.com/research/non-production-llm-spend Non-production LLM spend Updated September 1, 2026 · first published September 1, 2026 Quick answer: Every FinOps review of LLM spend starts with production traffic, because that is what has a dashboard. Then someone runs the numbers by environment and finds that a meaningful slice of the bill... Every FinOps review of LLM spend starts with production traffic, because that is what has a dashboard. Then someone runs the numbers by environment and finds that a meaningful slice of the bill — frequently double digits as a percentage — never touched a customer. It comes from four places, and they compound. Where non-production spend comes from CI. Every pull request that runs an evaluation suite calls the model. A suite of two hundred cases across a busy repository is thousands of calls a day, on the most capable model, because whoever wrote the suite quite reasonably wanted it to reflect production. Local development. Engineers iterating on a prompt call the API dozens of times an hour, usually on a shared key, usually with no tagging that says whose loop it was. Staging and demo instances. Long-lived, low-traffic, and configured identically to production — which means the expensive model and no caching, serving a handful of requests that nobody watches. Retries and runaway loops in test. An agent loop that fails safely in production still burns tokens when it misbehaves in a branch, and nothing in a test environment is set up to notice. Fix attribution before you fix cost The single change that pays for itself is a separate API key per environment . It costs an afternoon and turns an unexplained line item into four labelled ones. Tag every request with the environment, and for CI, the repository and workflow. Without that, every proposal below is guesswork. Once you can see it, three things usually follow immediately. Non-prod is where a smaller model is almost always fine — evaluation suites need consistency, not frontier capability, and most of them can pin a cheaper model with no loss of signal. Non-prod is where caching earns the most, because CI replays near-identical prompts all day. And non-prod is where hard spend caps are actually safe to set: a capped test environment fails a build, while a capped production environment fails a customer. The rule Give every non-production environment its own key, its own budget, and its own cap. Then treat the gap between environments as a number you manage deliberately, rather than one you discover in a quarterly review. Related Cost controls in your evaluation pipeline LLM cost attribution Agent spend guardrails Related Cost controls in your evaluation pipeline LLM cost attribution Agent spend guardrails Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # NVIDIA agent safety and FinOps · FinOps LLM URL: https://finopsllm.com/research/nvidia-open-agent-safety-platform-september-2026 NVIDIA Open Agent Safety Platform: the FinOps implications Updated September 28, 2026 · first published September 28, 2026 NVIDIA announced its Open Agent Safety Platform on September 28, 2026, combining OpenShell runtime controls with the Sentry reference design for monitoring and enforcing agent boundaries. For FinOps teams, the announcement is relevant because more controllable agents should be easier to audit and govern, but the release does not itself establish lower AI spend. Track the platform's infrastructure cost, enforcement events, and agent outcomes alongside token usage. NVIDIA says OpenShell is broadly available as open-source software and establishes a runtime boundary for agent actions. Sentry is an out-of-band watchdog in the reference design that monitors behavior and can quarantine agents that cross defined boundaries. Availability and compatibility depend on the components and deployment selected. What was announced The platform has two named parts. OpenShell provides a policy boundary for agent execution and can be extended to work with third-party compute platforms, according to NVIDIA. Sentry is described as a reference design that uses BlueField-4 DPUs for out-of-band monitoring and enforcement. NVIDIA also announced integrations and collaboration with a broad group of technology companies, including Anthropic. These are vendor claims and a product announcement, not an independent evaluation of security effectiveness or total operating cost. Organizations should review the architecture and test the controls in their own threat model before relying on them. Why agent governance enters a FinOps discussion Agent controls can affect cost in both directions. Policies may prevent unauthorized access, runaway loops, or repeated expensive tool calls. Monitoring, isolation, and enforcement can also add infrastructure and engineering overhead. A budget that counts only model tokens misses both effects. When piloting an agent platform, record four cost and control dimensions together: Model spend: input and output tokens, cache use, model tier, and retries by agent and workflow. Execution spend: compute, memory, storage, network, and any security hardware or managed service charges. Control events: policy denials, quarantines, approvals, and exception rates, with enough context to explain them. Business outcome: completed tasks, accepted results, human review time, and incidents avoided or investigated. How to evaluate without mixing safety and savings claims First measure your current agent workload and establish a security baseline. Then run a bounded pilot with the new controls and compare both the cost ledger and the policy outcomes. Keep the measures separate: fewer incidents or better audit trails can justify a control even if it adds cost, while a lower token bill does not prove safer behavior. Useful pilot questions include: Can the runtime enforce least-privilege access to tools and data? Are policy decisions and agent actions captured in a usable audit trail? What is the added cost per completed task, including compute and operations? How often do controls interrupt valid work, and what does exception handling cost? Can the same policies run on the intended infrastructure, including third-party platforms? What to watch next The announcement makes agent runtime governance a concrete infrastructure topic. The next useful evidence for buyers will be deployment documentation, independent security testing, real operating overhead, and clear billing for each supported configuration. Until those are available, treat NVIDIA's performance and safety descriptions as vendor statements and build a small, instrumented pilot. FAQ Does NVIDIA Open Agent Safety Platform reduce AI costs? NVIDIA did not announce a guaranteed cost reduction. Runtime controls may prevent wasteful or unauthorized actions, while monitoring and infrastructure may add cost. Measure both sides in a pilot. What is OpenShell? NVIDIA describes OpenShell as open-source runtime software that sets boundaries for agent execution. Its announcement says it is broadly available and can be extended to third-party compute platforms. What is Sentry? Sentry is the platform's reference design for an out-of-band watchdog using BlueField-4 DPUs to monitor agent behavior and enforce boundaries. Confirm current availability and technical requirements with NVIDIA's documentation. Why should FinOps track safety controls? Agent governance changes operational costs, auditability, and the consequences of misuse. Recording security events next to model and infrastructure spend helps teams understand the full cost of running agents. Source NVIDIA: Open Agent Safety Platform announcement, September 28, 2026 Related Claude Sonnet 5.5 launch and model routing Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Your AI observability stack can become a second LLM bill · FinOps LLM URL: https://finopsllm.com/research/observability-second-llm-bill When AI observability creates a second LLM bill Updated September 9, 2026 · first published September 9, 2026 Quick answer: AI observability is supposed to explain what an application is spending and why. But many observability features call another model: traces are summarized, prompts are classified, outputs are scored,... AI observability is supposed to explain what an application is spending and why. But many observability features call another model: traces are summarized, prompts are classified, outputs are scored, sessions are clustered, and alerts are generated. If those calls are not attributed, the visibility layer becomes a second LLM bill that looks like infrastructure overhead. Separate product work from measurement work Every model call should carry a purpose field. At minimum, distinguish customer-facing inference, agent tool planning, evaluation, redaction, trace summarization, quality scoring, and alerting. The provider invoice may only show a model and account; your gateway needs to preserve the reason the call existed. Do not hide observability calls inside the feature that triggered them. Keep a parent request identifier so the cost can be rolled up to the measured feature without losing the fact that it was secondary spend. Sampling is a budget decision Tracing every request is not automatically the best control. Use full-fidelity capture for failures, new releases, high-value customer tiers, and statistically selected samples. For stable traffic, store compact metadata and retain full prompts or outputs only when policy allows it. Sampling must be evaluated against the quality of the signal. A cheap sample that misses rare failures is not an optimization; it is an observability blind spot. Set a minimum detection target and spend budget for each monitoring job. Judge models need a quality bar too LLM-as-judge systems can spend more than the feature they evaluate when they run on every turn or use long context. Cache stable evaluation inputs, batch offline scoring, and route simple classification to a smaller model. Measure judge agreement against human labels before increasing coverage. Allocate the full cost Report direct inference cost and measurement cost separately, then show the combined cost per successful task. A feature that looks cheap before tracing may be expensive after evaluation, summarization, and retention are included. This is especially important when comparing experimentation environments with production. A simple control loop Tag every secondary model call with purpose and parent request ID. Set monthly budgets for tracing, evaluation, summarization, and alerting. Sample by risk and value, not only by random percentage. Batch offline jobs and cache repeatable judgments. Review observability cost as a percentage of the workload it measures. Related LLM usage metering Evaluation cost control LLM cost dashboards Related LLM usage metering Evaluation cost control LLM cost dashboards Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # On-prem and self-hosted LLM FinOps · FinOps LLM URL: https://finopsllm.com/research/on-prem-llm-finops On-prem and self-hosted LLM FinOps On-prem LLM FinOps means running cost attribution and governance inside your own environment, so that the data you analyze to understand AI spend never leaves your security boundary. For regulated teams, this is often the difference between getting a FinOps practice approved and having it blocked in security review. The good news: LLM cost governance does not require prompt or output content. Spend can be attributed entirely from provider billing exports and request-level metadata, both of which are far less sensitive than the prompts and completions themselves. What "on-prem" actually needs to cover Self-hosting the analysis is only useful if the inputs stay local too. A self-hosted LLM FinOps setup typically reads: Provider billing exports (OpenAI, Anthropic, Azure OpenAI, Bedrock, Vertex) downloaded into your environment. Gateway or proxy logs that carry request-level metadata - model, token counts, cache-read tokens, latency, and an owner tag. Optional product metadata to map requests to teams, surfaces, and environments. None of those require storing the prompt text or the model's response. Token counts and model identifiers are enough to compute cost; ownership tags are enough to attribute it. The data-handling line that matters The principle worth enforcing from day one: store spend metadata, never content. A breakdown that records "team X, gpt-4o, 1.2M input tokens, 300K cache-read tokens, $Y" is a cost record. A log that keeps the actual prompt is a content store with a different risk profile and a different review path. Keeping the two separate is what makes a self-hosted FinOps tool easy to approve. On-prem vs SaaS observability Hosted LLM observability platforms are convenient, but they usually ingest request payloads - sometimes including prompt and completion text - into a vendor environment. That is a reasonable trade for some teams and a non-starter for others. On-prem FinOps narrows the question: you can get spend attribution, budgets, and anomaly detection without exporting any usage content, and add deeper tracing later if your risk tolerance allows. How to start Pick the boundary first: decide what may leave your environment (ideally nothing but aggregate numbers you choose to share). Centralize billing exports and gateway logs into one place you control. Compute cost from token counts and a maintained price table, keeping input, output, and cache-read tokens separate. Attribute by team, product surface, and environment, then reconcile against the provider invoice monthly. Related FinOps for LLM: a practical framework - the operating model this fits into. LLM cost attribution - how allocation works from metadata. LLM budget governance - budgets, alerts, and guardrails. Invoice reconciliation for AI bills - matching estimates to provider invoices. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ Can you do LLM cost governance without sending prompts to a third party? Yes. LLM spend can be attributed entirely from provider billing exports and request-level metadata - model, token counts, cache-read tokens, and owner tags. None of it requires storing prompt or completion text, so a self-hosted FinOps practice never needs to move content outside your security boundary. What data does an on-prem LLM FinOps setup actually read? Provider billing exports downloaded into your environment, gateway or proxy logs carrying request-level metadata, and optional product metadata mapping requests to teams and surfaces. Token counts and model identifiers are enough to compute cost; ownership tags are enough to attribute it. How is on-prem FinOps different from hosted LLM observability? Hosted observability platforms usually ingest request payloads - sometimes including prompt and completion text - into a vendor environment. On-prem FinOps gives you spend attribution, budgets, and anomaly detection without exporting any usage content, with deeper tracing added later only if your risk tolerance allows. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Open-Source vs Closed-Source LLM Cost Comparison · FinOps LLM URL: https://finopsllm.com/research/open-source-vs-closed-cost Open-Source vs Closed-Source LLM Cost Comparison Updated 12 July 2026 · first published 4 July 2026 When does self-hosting Llama, Qwen, or DeepSeek break even versus paying for API access? This analysis covers GPU costs, inference optimisation, operational overhead, and gives you a decision framework for your specific workload. 8 Models compared 5 GPU tiers analysed 3 Break-even scenarios Jul 2026 Last updated Self-host costs assume cloud GPU pricing (on-demand) API costs use standard output pricing per provider Break-even based on 70% utilisation, 24/7 availability Methodology API pricing Standard published rates from each provider's pricing page. No batch or volume discounts applied. Self-host GPU Cloud GPU on-demand pricing (Lambda, RunPod, AWS) for inference-optimised setups with vLLM or TensorRT-LLM. Operational overhead Includes monitoring, scaling, model updates, and a 15% ops-surcharge on raw GPU cost for managed infrastructure. Quality gap Relative to GPT-4o / Claude Sonnet 4 as baseline 100%. Based on public benchmarks and practical task performance. Cost Comparison Table Model ↕ API Cost/mo ↕ Self-Host Cost (cloud GPU) ↕ Break-Even Volume ↕ Quality Gap Llama 4 Maverick (DeepInfra) $260/mo $2,800/mo ~350M tokens/mo ~95% of GPT-4o Llama 3.3 70B (Groq) $277/mo $1,200/mo ~210M tokens/mo ~87% of GPT-4o Llama 4 Scout (Groq) $136/mo $1,400/mo ~350M tokens/mo ~88% of GPT-4o Qwen 3.7-Max $525/mo $1,600/mo ~100M tokens/mo ~92% of GPT-4o DeepSeek V4 Pro $435/mo $1,800/mo ~130M tokens/mo ~96% of GPT-4o DeepSeek V4 Flash $140/mo $1,400/mo ~450M tokens/mo ~82% of GPT-4o Mistral Medium 3.5 $525/mo $2,000/mo ~120M tokens/mo ~91% of GPT-4o GPT-4o (API only) $750/mo N/A N/A Baseline (100%) API Cost/mo assumes 100M output tokens + 300M input tokens per month at standard rates. Self-Host Cost includes GPU rental, 15% ops overhead, and inference stack (vLLM). Does not include initial setup engineering time. Break-Even Volume is the monthly output token count where self-hosting becomes cheaper than API. Quality Gap is approximate and task-dependent. Benchmarks like MMLU, HumanEval, and GPQA inform these estimates. Some links may include referral codes. Key Cost Factors 1) GPU rental is the dominant cost An 8x H100 node for Llama 4 Maverick runs $2,000-$3,500/mo on-demand from Lambda, RunPod, or AWS. Spot/preemptible instances can cut this 40-60% but add restart latency and availability risk. For production workloads, reserved instances (1-year commitment) typically save 30-40% over on-demand. 2) Inference optimisation changes the equation vLLM with continuous batching, KV-cache paging, and quantisation (GPTQ/AWQ 4-bit) can increase throughput 2-4x on the same hardware. TensorRT-LLM adds another 20-40% for supported architectures. A well-tuned 4-bit Llama 4 Scout on a single A100 can match a naive fp16 setup on 2x A100s. 3) Operational overhead is real but shrinking Running inference infrastructure requires GPU monitoring, model updates, load balancing, and failover. Budget 15-25% of raw GPU cost for ops. Managed platforms (Anyscale, Modal, Replicate) absorb this but charge 30-50% premium over raw GPU - worth it below ~$5K/mo GPU spend. 4) Prompt caching narrows the gap for API API providers increasingly offer prompt caching (50-90% discount on repeated prefixes). If your workload is cache-friendly (RAG, multi-turn), API costs drop significantly, pushing the break-even volume higher for self-hosting. Decision Framework Use API if... Monthly output volume is below 100M tokens You need frontier-model quality (GPT-4o, Claude Opus 4) Your team has no GPU/MLOps expertise Latency requirements are strict (sub-200ms TTFT) You want zero operational overhead Your workload is bursty or seasonal Self-host if... Monthly output volume exceeds 200M tokens consistently Data privacy requires no third-party API calls You need custom fine-tuned models You have MLOps capacity on the team Workload is steady-state (predictable GPU utilisation) You can commit to 1-year reserved GPU instances Hybrid approach: the pragmatic middle ground Most teams land on a hybrid: use API for frontier reasoning tasks and low-volume workloads, self-host open-source models for high-volume, latency-tolerant tasks (content generation, data extraction, internal tools). This keeps API spend under control while building self-host capability incrementally. Where to Run Open-Source Models Platform GPU Options A100 80GB Price H100 Price Managed Inference Lambda Cloud A100, H100, H200 $1.10/hr $2.49/hr No (bring your own) RunPod A100, H100, L40S $1.19/hr $2.69/hr Serverless option AWS (p4d/p5) A100, H100 $3.67/hr $6.37/hr SageMaker Google Cloud A100, H100 $3.22/hr $5.07/hr Vertex AI Xiaomi MiMO ↗ API-based N/A N/A API ($0.50/$2.00 per 1M) GPU prices are on-demand hourly rates as of July 2026. Reserved/spot pricing varies significantly. MiMO offers API-based access to MiMo-V2-Pro and MiMo-V2-Omni at competitive rates - a middle ground between full self-hosting and premium API pricing. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is the methodology? Standard published rates from each provider's pricing page. No batch or volume discounts applied. Self-host GPUCloud GPU on-demand pricing (Lambda, RunPod, AWS) for inference-optimised setups with vLLM or TensorRT-LLM. How do API and self-hosting costs compare? API Cost/mo assumes 100M output tokens + 300M input tokens per month at standard rates. Self-Host Cost includes GPU rental, 15% ops overhead, and inference stack (vLLM). Does not include initial setup engineering time. What are the key cost factors for self-hosting? An 8x H100 node for Llama 4 Maverick runs $2,000-$3,500/mo on-demand from Lambda, RunPod, or AWS. Spot/preemptible instances can cut this 40-60% but add restart latency and availability risk. For production workloads, reserved instances (1-year commitment) typically save 30-40% over on-demand. How do you decide between API and self-hosting? Most teams land on a hybrid: use API for frontier reasoning tasks and low-volume workloads, self-host open-source models for high-volume, latency-tolerant tasks (content generation, data extraction, internal tools). Where to Run Open-Source Models? GPU prices are on-demand hourly rates as of July 2026. Reserved/spot pricing varies significantly. MiMO offers API-based access to MiMo-V2-Pro and MiMo-V2-Omni at competitive rates - a middle ground between full self-hosting and premium API pricing. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # OpenAI Agent Message Board: A New Cost Vector · FinOps LLM URL: https://finopsllm.com/research/openai-agent-message-board-cost OpenAI agent message board cost model Updated September 27, 2026 · first published September 27, 2026 In September 2026, researchers discovered an OpenAI agent message board — a communication layer where autonomous agents can post messages, read responses, and coordinate multi-step workflows without human intervention. For FinOps teams, this introduces a new cost vector: agent-to-agent token consumption that scales with conversation length, not task complexity. What the message board enables The message board acts as a shared context bus. An orchestrator agent posts a task decomposition; specialist agents claim subtasks, post findings, and negotiate handoffs. Each message is a full prompt-completion cycle billed at the model's standard rates. Cost model Component Rate (GPT-6 Astra) Rate (GPT-6 Sol) Agent post (input) $10.00 / 1M $2.00 / 1M Agent read (cached input) $1.00 / 1M $0.20 / 1M Agent reply (output) $50.00 / 1M $10.00 / 1M A 10-turn coordination between three agents at Astra pricing: ~300K tokens = $15. Same exchange on Sol: $3. The difference is whether the task requires Astra's reasoning or if Sol's cheaper tokens suffice. Runaway scenarios Negotiation loops: Two agents disagree on a handoff and iterate 50+ times before converging. Broadcast storms: One agent posts to all subscribers; each replies, triggering more posts. Orphaned conversations: Agents wait for a response that never comes, polling the board every 30 seconds. FinOps controls Message budget per workflow: Hard cap on total board tokens per task ID. Depth limits: Max 3 agent-to-agent hops before human escalation. Model routing: Route coordination to Sol; reserve Astra for the final synthesis step only. Idle timeout: Auto-close threads after 5 minutes of inactivity. Bottom line The message board makes multi-agent systems composable — but composability without cost guards is a budget leak. Treat agent-to-agent tokens as a distinct cost center with its own alerts and budgets. Related GPT-6 Astra cost model GPT-6 Sol cost model Subagent fan-out concurrency limits Three agent budgets Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # OpenAI cost attribution · FinOps LLM URL: https://finopsllm.com/research/openai-cost-attribution OpenAI cost attribution Updated 12 July 2026 · first published 5 May 2026 OpenAI cost attribution starts before the request is sent. The API response can tell you token usage, but it cannot know which product surface, team, customer, or business workflow caused the call unless your application attaches that context. Attribution should join three sources: request metadata, usage records, and invoice data. Request metadata gives ownership. Usage records give token counts and model. Invoice data gives the authoritative financial total. Tags to capture Feature or endpoint name. Team owner and environment. Tenant or customer where allowed. Workload class such as realtime, batch, eval, support, or agent step. Prompt version, route policy, and fallback status. Common attribution gaps Teams often miss retries and fallbacks. A user sees one answer, but the system may have paid for multiple upstream calls. Another common gap is batch work: evals and enrichment jobs should be tagged separately from user-facing traffic so they can move to lower-cost asynchronous lanes. The best OpenAI attribution reports do not stop at “which model cost the most.” They show which product decision caused that model to be used, and which owner can change it. Related LLM cost attribution - general attribution principles. Anthropic cost attribution - attribution for Anthropic models. What is LLM FinOps? - the complete operating discipline. Where should the metadata be attached? At the outermost boundary that still knows why the call is happening — usually the handler or job that received the user action, not the SDK wrapper. Attribution attached deep in a shared client is already too late: by then the request has lost the product context, and every caller looks the same. Pass an explicit context object down and let the client read from it, so a new call site cannot be added without an owner. Practically, that means a request-scoped context carrying feature, team, environment, and tenant; a wrapper that refuses to send without one in non-production; and a parent request ID so retries, fallbacks, and multi-step agent calls collapse back to the single user action that caused them. Why don't OpenAI's own reports answer this? The usage dashboard aggregates by API key, model, and project. That is infrastructure attribution, not business attribution — it tells you which key spent the money, not which feature or customer. Splitting keys per team is the usual workaround and it breaks quickly: keys proliferate, shared services end up with their own key nobody owns, and you still cannot attribute a single agent run that touched three features. How do you attribute agent and multi-step workloads? Treat the whole run as the unit, not the individual call. An agent that plans, calls three tools, and retries once produces five billable requests for one user action, and per-call attribution makes each look cheap while the run is expensive. Emit a run ID on every step, roll cost up to the run, and report cost per completed run — that is the number that maps to what the feature actually costs. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ When should OpenAI cost attribution data be captured? OpenAI cost attribution should be captured before the request is sent. The API response can tell you token usage, but it cannot know which product surface, team, customer, or business workflow caused the call unless your application attaches that context. What tags should be captured for OpenAI cost attribution? Tags to capture include: feature or endpoint name, team owner and environment, tenant or customer where allowed, workload class such as realtime, batch, eval, support, or agent step, and prompt version, route policy, and fallback status. What are common gaps in OpenAI attribution? Teams often miss retries and fallbacks. A user sees one answer, but the system may have paid for multiple upstream calls. Another common gap is batch work: evals and enrichment jobs should be tagged separately from user-facing traffic so they can move to lower-cost asynchronous lanes. What makes an OpenAI attribution report actionable? The best OpenAI attribution reports do not stop at 'which model cost the most.' They show which product decision caused that model to be used, and which owner can change it. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # OpenAI Fine-Tuning Sunset Economics · FinOps LLM URL: https://finopsllm.com/research/openai-fine-tuning-sunset-economics OpenAI Fine-Tuning Sunset Economics Published 19 July 2026 OpenAI is phasing out self-serve fine-tuning. Starting May 7, 2026, new organizations can no longer create fine-tuning jobs. By January 6, 2027, all organizations lose that ability. If you rely on fine-tuned GPT models, you must choose a migration path now: prompt engineering on GPT-5.5 with prompt caching, open-source LoRA adapters on Llama or Qwen, or managed fine-tuning via Vertex AI, AWS Bedrock, or Mistral. Each path has distinct cost and operational trade-offs. Self-serve fine-tuning creation ends Jan 6, 2027 for all orgs Inference on existing fine-tuned models continues until base deprecation Prompt caching on GPT-5.5 can match or beat fine-tuning ROI at 10–30 hits Open-source LoRA costs 30–50% less than managed services for high volume Hidden migration costs: re-evals, regression tests, dual-running, retraining Deadline: Organizations must commit to a migration path before January 6, 2027. Existing fine-tuned models will continue to serve inference requests until their base model is deprecated, but you cannot create new training jobs after that date. Timeline & Exposure Matrix Who is affected and when: Date Phase Affected Organizations Action Required May 7, 2026 Phase 1 New orgs, never fine-tuned before Cannot start new jobs July 2, 2026 Phase 2 Existing orgs with no fine-tuned-model inference in prior 60 days Cannot start new jobs Jan 6, 2027 Phase 3 (final) All organizations, even active users No new training jobs Post-2027 Inference only All orgs with deployed fine-tuned models Inference continues until base-model sunset Why OpenAI is sunsetting fine-tuning: GPT-5.5–class base models combined with prompt caching eliminate the need for fine-tuning in most use cases. Longer prompts with few-shot examples and system instructions now match or exceed fine-tuned performance, while consuming fewer total tokens when cached. The managed fine-tuning overhead exceeds its value for most workloads. Decision Tree: Three Migration Paths Path 1: Prompt Engineering + GPT-5.5 + Caching Rewrite fine-tuned logic as system prompt + few-shot examples, cached. Trades off longer prompts for zero training overhead. Training cost: $0 (no retraining) Token cost per call: Longer prompt, but cached at 50% of fresh rate Setup time: 1–4 weeks (prompt engineering + benchmarking) Ongoing ops: Prompt iteration, no MLOps needed Path 2: LoRA on Open-Source (Together, Fireworks, Groq) Fine-tune Llama 4 or Qwen 3.5 with LoRA adapters, host on managed inference. Full fine-tuning control, open-source reproducibility. Training cost: $200–$500 per job Inference cost: $0.10–$0.30/M tokens (competitive) Setup time: 2–6 weeks (data prep, adapter training, testing) Ongoing ops: Monitor adapter performance, retrain as needed Path 3: Managed Fine-Tuning (Vertex, Bedrock, Mistral) Use Google Vertex AI, AWS Bedrock, or Mistral's fine-tuning. Familiar workflow, vendor support, but higher per-token cost. Training cost: $500–$2,000 per job Inference cost: $0.20–$1.00/M tokens (premium) Setup time: 1–3 weeks (fewer integrations needed) Ongoing ops: Vendor handles ops, you manage training cadence Path 1: Prompt Engineering + GPT-5.5 Caching — Worked Math Suppose you had a fine-tuned GPT-4 model for customer support ticket classification. The fine-tuned model was trained on 10K labeled tickets. Each request sends ~500 input tokens, gets ~50 output tokens back. Old cost (fine-tuning): Fine-tuning job: ~$50. Inference at 100K calls/month: (500 input × $3/M + 50 output × $15/M) × 100K = $150/month + training = ~$200/month all-in. New cost (prompt caching on GPT-5.5): Create a system prompt with 40 few-shot examples (each ~200 tokens) = 8K tokens. This is the cache-fill. First call: 8K × (1.25× $3/M) + 500 × $3/M + 50 × $15/M ≈ $0.045. Subsequent calls (cache hit): 500 × (0.5× $3/M) + 50 × $15/M ≈ $0.0015. At 100K calls/month, assume 90% hit (90K cache hits). Cost: 10K calls × $0.045 + 90K calls × $0.0015 = $450 + $135 = $585/month . Wait — that's more expensive! True if you don't tune the prompt. But reduce the few-shot examples to 10 (2K tokens), and cost drops to ~$280/month. Further: if you can batch queries (process 10 related tickets in one call), cost per ticket drops another 30%. Bottom line: prompt caching on GPT-5.5 becomes cheaper than fine-tuning at 15–30 cache hits per unique context. Most teams reach that within hours of deployment. Quality risk: Few-shot prompts can underperform fine-tuning on edge cases and unusual formats. Budget 2–4 weeks for regression testing. Path 2: LoRA on Open-Source — Costs & Logistics Open-source fine-tuning via LoRA (Low-Rank Adaptation) keeps the base model frozen and trains only small adapter matrices (~1–5% of parameters). Cost structure: Component Provider Example Cost Notes Training (Llama 3.3 70B on 10K samples) Together AI $300 LoRA on single H100 GPU (~4 hours) Inference (per 1M tokens) Groq (Llama 3.3 70B) $0.27 Fast (no tuning lag vs fine-tuned GPT-4) Inference (per 1M tokens) Together AI (Llama 3.3 70B) $0.18 Slower response, lower cost Model hosting (monthly, always-on) Self-hosted on runpod $300–$600 A100 GPU rental + ops overhead Total for 1M calls/month — $318–$600 Groq API (managed), no hosting cost Why open-source is cheaper: No per-token premium for "fine-tuned" status. The adapter is yours to distribute and improve. Model quality (Llama 4 Maverick) matches GPT-4o for most tasks at 30–50% lower cost. The trade-off: you own the MLOps — retraining cadence, drift detection, A/B testing between adapter versions. Integration risk: Switching from OpenAI's API to Groq, Together, or self-hosted changes your inference latency, error handling, and scaling. Expect 1–2 weeks of integration work. Path 3: Managed Fine-Tuning (Vertex, Bedrock, Mistral) Provider Training Cost (10K samples) Inference Cost (per 1M output tokens) Base Model Time to Production Google Vertex AI $500–$800 $0.40–$1.50 Gemini 1.5 Flash, other OS models 1–2 weeks AWS Bedrock (Claude Sonnet fine-tuned) $600–$1,200 $0.80–$2.00 Claude Sonnet, Llama 4, Mistral 1–2 weeks Mistral fine-tuning $400–$700 $0.25–$0.60 Mistral 3.5 Moe, other Mistral models 1 week Typical monthly cost (100K calls, 500 tokens avg) $600–$1,200 (one-time training) $200–$1,000 (recurring inference) — — Managed services are the easiest on-ramp: your team already knows API authentication, vendor support is available, and you avoid MLOps overhead. But inference costs run 2–5× higher than open-source LoRA. This path makes sense if: (1) you have Three-Path Cost Comparison (Concrete Workload) Workload: Customer service AI for a SaaS. 1M inference calls/month, avg 500 input + 150 output tokens per call. The team trained a fine-tuned model on 5K labeled conversations. Cost Component Path 1: Prompt Caching + GPT-5.5 Path 2: LoRA on Groq (Llama 3.3) Path 3: Bedrock (Claude Sonnet FT) Initial setup / training $0 (prompt eng only) $300 $1,000 Monthly inference cost (1M calls) $450–$600 $270 $900–$1,200 Monthly total (Year 1) $450–$600 $600 (includes training amortized) $1,900–$2,200 Year 1 total $5,400–$7,200 $3,600–$4,800 $12,000–$15,000 Path 2 (LoRA) wins on pure cost, but requires MLOps time to set up and maintain.** Path 1 (prompt caching) is lowest friction if you accept slightly higher ongoing costs. Path 3 (managed) is chosen only if enterprise SLAs or hands-off operations are mandatory. Hidden Migration Costs — Don't Miss These The table above omits operational friction. Plan for: 1. Re-evaluation & Benchmarking Measure the new model's accuracy, latency, and cost on your holdout test set. Budget: 2–3 weeks, $1K–$3K in engineering time. 2. Regression Testing Run the old fine-tuned model and new path on the same 100–1K production queries. Measure quality gaps. For customer-facing systems, consider A/B testing (dual-running) for 2–4 weeks. Ops cost: $2K–$5K. 3. Dual-Running Period Run both old and new paths in parallel to catch regressions in production. This doubles inference cost for 2–4 weeks. Adds $500–$2,000 to your migration bill. 4. Retraining Workflow Changes If you retrain regularly (monthly, quarterly), factor in scripting changes. LoRA retraining scripts differ from OpenAI's API. Mistral, Vertex, and Bedrock each have different training APIs. Budget: 1–2 weeks, $500–$1,500. 5. Adapter Drift & Monitoring Open-source adapters can drift if training data changes. Set up performance monitoring and retraining triggers. For managed services, the provider handles this but charges monitoring overhead. Budget: ongoing +$200–$500/month. Total hidden cost: $4K–$12K in engineering time + $500–$2,000 in dual-running ops. Most teams underestimate this by 50%. Bake it into your project plan. Decision Framework Choose Path 1 (Prompt Caching + GPT-5.5) if: Monthly inference volume is below 100M tokens Your current workload has repeated contexts (RAG, multi-turn) — high cache-hit potential Your team has no MLOps experience and wants minimal ops overhead You can accept a quality trade-off for simplicity (most tasks see ≤5% regression) Latency requirements are flexible (>500ms TTFT acceptable) Choose Path 2 (LoRA on Open-Source) if: Monthly inference volume exceeds 200M tokens — cost advantage is 30–50% Your team has MLOps bandwidth for training, monitoring, and retraining You need reproducibility and want full control over the adapter (open-source advantage) Data privacy requires no calls to OpenAI, Google, or AWS proprietary APIs Latency is critical (<200ms) — Groq offers sub-100ms responses Choose Path 3 (Managed Fine-Tuning) if: You need enterprise SLAs, vendor support, or HIPAA/SOC 2 compliance Your team lacks infrastructure expertise and wants zero MLOps Monthly volume is below 50M tokens (cost premium is acceptable at low scale) You're already invested in the vendor's ecosystem (AWS, Google Cloud, Mistral) Training frequency is monthly or less (ops cost is amortized better at low churn) Related Reading For more context on the broader cost landscape, see Open-Source vs Closed-Source LLM Cost Comparison , which compares break-even volumes across self-hosted and API options. Already tracking your fine-tuning migration costs? FinOps LLM audits your LLM spend and identifies which migration path saves you the most. Book a free audit . Back to research FAQ When can I no longer create new OpenAI fine-tuned models? Timeline: May 7, 2026 (new orgs blocked), July 2, 2026 (orgs inactive 60 days blocked), January 6, 2027 (all new jobs blocked). Inference on existing fine-tuned models continues until base-model deprecation. Does prompt caching break even against fine-tuning? For repeated prompts over the same context: yes. Prompt caching on GPT-5.5 costs $0.60/M for reads vs $3.00/M fresh, and few-shot examples (longer prompts) can be cached efficiently. Break-even is typically 10–30 cache hits depending on prompt size; most teams hit that within days. Is open-source LoRA cheaper than managed fine-tuning? Usually, yes. Training cost via Together AI: ~$200–$500 per job. Inference on Groq or Fireworks: ~$0.10–$0.30/M tokens. Total cost-per-successful-response is often 30–50% lower than a managed service, but requires MLOps overhead. What hidden costs am I not seeing during migration? Re-evaluation (benchmarking new approach vs old), regression testing (does the replacement path deliver same quality?), dual-running (running both old and new paths in parallel for safety), and adapter retraining if the new model changes. Budget 4–8 weeks and ~$2K–$10K in engineering time per migration. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # OpenAI O / AON: Always-On Agent Cost Model · FinOps LLM URL: https://finopsllm.com/research/openai-o-agent-cost-model OpenAI O / AON always-on agent cost model Updated September 27, 2026 · first published September 27, 2026 Leaked references reveal OpenAI's "O" (codename AON) — an always-on assistant designed for long-horizon tasks. Unlike chat models that respond and stop, O gets its own cloud environment, can set up execution contexts, write code, research, and operate continuously for hours, days, or potentially weeks . It may involve multiple agents communicating on the same task. Expected reveal: OpenAI Dev Day, September 29, 2026. What changes for cost modeling Traditional LLM cost: per-request tokens × rate. O/AON cost: time × allocated compute + token throughput . Dimension Chat/Completion API O / AON (projected) Billing unit Per 1M tokens Per hour (compute) + per 1M tokens Idle cost $0 >$0 (environment reservation) Max duration Minutes (timeout) Days/weeks Parallelism Sequential requests Multi-agent swarms State Passed in context Persistent environment Projected cost model (speculative, based on leak patterns) OpenAI hasn't published pricing. Two likely structures: Option A: Compute-hour + tokens (like Codespaces) Environment reservation: ~$0.50-2.00/hour (CPU + memory + storage) Token throughput: standard GPT-5 rates on top Ultra fast tier: 5-10x token multiplier when enabled A 24-hour agent run with 5M input / 2M output tokens: Component Cost (low) Cost (high) 24h environment ($1/hr) $24 $48 5M input @ $5/MTok $25 $25 2M output @ $15/MTok $30 $30 Total $79 $103 Option B: Flat subscription (Pro Max bundle) $500/mo ChatGPT Pro Max includes O/AON access + ultra fast quota Effective hourly: $500 / 720h = $0.69/hr (if 24/7) Break-even vs Option A: ~15 hours/day sustained usage Cost optimization strategies for always-on agents Hibernate, don't terminate. If the environment persists, pause the agent loop during idle periods instead of spinning down — cold start costs more than idle reservation. Batch subtask tokens. Accumulate subtask results and write context in larger chunks to improve cache hit rates on the persistent environment. Route subtasks to cheaper models. O/AON orchestrates; delegate coding to Sonnet 5.5, research to Flash models, only escalate to premium for critical decisions. Set hard time/money budgets per objective. "Solve this bug, max $10 / 2 hours" — enforce via orchestrator, not hope. When to use O/AON vs Opus 5.5 long-running O/AON: Multi-day research, continuous monitoring, multi-agent coordination, tasks needing persistent environment state Opus 5.5 agent loop: Single-objective coding tasks (hours, not days), well-defined deliverables, one-shot execution Related reading See ChatGPT Pro Max economics , OpenAI Ultra Fast API pricing , Opus 5.5 25-hour agent cost , and agent economics . Related ChatGPT Pro Max economics OpenAI Ultra Fast API pricing Opus 5.5 25-hour agent cost Agent economics Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Find the cache miss behind your OpenAI bill · FinOps LLM URL: https://finopsllm.com/research/openai-prompt-cache-diagnostics-cost Find the cache miss behind your OpenAI bill Updated September 26, 2026 · first published September 26, 2026 Quick answer: A prompt-cache dashboard can tell you that reuse fell. It cannot, by itself, tell you which request change caused the fall or how much it cost. OpenAI's September 8, 2026 release made Prompt Cache... A prompt-cache dashboard can tell you that reuse fell. It cannot, by itself, tell you which request change caused the fall or how much it cost. OpenAI's September 8, 2026 release made Prompt Cache Diagnostics generally available in the Responses API for GPT-5.6 and later supported models. The useful FinOps move is to turn a drop in cached tokens into a short, repeatable investigation. Compare the request that missed Save the ID of a recent, completed response whose prefix you expected to reuse. On the next comparable Responses API request from the same organization, set prompt_cache_options.comparison_response_id to that ID. Then read prompt_cache_diagnostics on the new response, alongside usage.input_tokens_details.cached_tokens . The comparison option requests a diagnosis; it does not load the earlier conversation or change cache behavior. OpenAI's diagnostics guide includes working request examples. const next = await client.responses.create({ model: model, instructions: stableInstructions, input: nextInput, tools: stableTools, prompt_cache_options: { comparison_response_id: baseline.id } }); console.log(next.prompt_cache_diagnostics); console.log(next.usage.input_tokens_details.cached_tokens); The snippet assumes baseline is a recent completed response and the other variables are your own request data. Keep a stable prefix long enough to cache: OpenAI documents a 1,024-token minimum for GPT-5.6 and later. A small or radically different prompt is not a meaningful cache-miss test. Fix the cause, not the metric A cache_miss result may point to a changed model, service tier, tool definitions or ordering, cache key, response format, reasoning effort, verbosity, or compacted context. For example, a harmless-looking tool-schema rename can invalidate the reusable prefix. Compare request configuration and the earliest prompt bytes, restore stability where the change was accidental, and rerun the comparison against the same baseline. OpenAI reports the first cause it finds, so another cause may appear after the first fix. Do not force a hit if the change was deliberate. A different model may lower total task cost even while losing cache reuse; compaction may reduce future context. Judge the entire request and task, not cache-hit percentage in isolation. An expired baseline or an unavailable result is inconclusive, not proof that caching failed. Translate the finding into money cache_missed_tokens estimates the reusable tokens lost relative to the comparison response. It is not a billed-token count. A cache_hit result likewise does not establish dollar savings. For realized input cost, collect each response's total input_tokens , cached_tokens , and cache_write_tokens , then apply the current rate for that model and processing tier. For GPT-5.6 and later, OpenAI's prompt-caching guide states that cache reads cost 0.1 times the uncached input rate and cache writes cost 1.25 times that rate. ordinary = input_tokens - cached_tokens - cache_write_tokens weighted_input = ordinary + 0.1 * cached_tokens + 1.25 * cache_write_tokens input_cost = weighted_input * input_price_per_million / 1_000_000 Those are exclusive token categories: do not add a cache-write surcharge to tokens already counted at the write rate. This formula covers input only; include output, tool, retry, and other charges when calculating cost per successful task. Use the provider's current price table rather than a hard-coded article price. A useful weekly check Group comparable traffic by workload, model, and service tier; chart cached-token share and input cost per completed task. Sample a sudden regression, compare it with a recent baseline, and record the diagnostic reason and owning code change. Fix accidental prefix or configuration drift; keep intentional quality or routing changes if total task economics improve. Validate the result across representative production traffic and reconcile the observed savings with billing. Diagnostics themselves have no extra feature fee, but extra test requests are billed normally. The payoff is not a prettier hit-rate graph. It is a defensible explanation for why a particular workload's input cost changed—and whether the proposed fix really lowered its bill. Questions teams ask Does a cache-hit diagnosis prove a request was cheaper? No. It says no miss was detected against the selected baseline. Check actual cached_tokens and the request's priced token categories before claiming savings. Can diagnostics compare any two OpenAI requests? No. Use a recent completed baseline from the same organization, and only expect this workflow on supported GPT-5.6-and-later Responses API models. A comparison record can expire. Should every cache miss be removed? No. A model switch, different service tier, or compacted context can be intentional. Compare quality, latency, and cost per successful task before reversing the change. Related Prompt caching economics Prompt-cache attribution Cost per successful task Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # OpenAI Ultra Fast API: Three Speed Tiers · FinOps LLM URL: https://finopsllm.com/research/openai-ultra-fast-api-pricing OpenAI Ultra Fast API pricing and speed tiers Updated September 27, 2026 · first published September 27, 2026 OpenAI's response API playground now shows a speed selector with three options: standard, fast, and ultra fast. This isn't just a UI tweak — it's a new pricing dimension. Ultra fast mode, powered by Cerebras inference, was previewed last month for select customers where GPT-5 Soul hit 750 tokens per second — up to 14x faster than standard. The Dev Day leak suggests OpenAI is preparing to expand ultra fast access to a much larger developer group. The three tiers Tier Relative speed Use case Pricing signal Standard 1x (baseline) Batch, async, non-urgent Base rate Fast ~3-5x Interactive, user-facing Likely 2-3x base Ultra fast ~10-14x Real-time agents, trading, live assist Likely 5-10x base Exact multipliers aren't public yet. The leaked documentation shows ultra fast as an "access controlled service tier" — meaning you'll need approval or a specific plan (the rumored $500 ChatGPT Pro Max) to unlock it. What this does to your cost model Speed tiers turn latency into a first-class cost lever. Today you optimize by model selection (GPT-5 mini vs GPT-5 vs GPT-5 Soul). Tomorrow you'll optimize by speed tier within the same model . For a 10K token request/response pair at standard GPT-5 Soul pricing (~$5/$15 per million): Standard: ~$0.20 per call Fast (est. 3x): ~$0.60 per call Ultra fast (est. 8x): ~$1.60 per call The breakeven depends entirely on what latency buys you. A support agent that resolves in one turn instead of three because ultra fast kept the user engaged? That's a win. A batch enrichment job? Standard every time. How to prepare Instrument latency per feature. You can't decide if fast is worth it without knowing your current p50/p95 and the business value of each millisecond. Tag requests by urgency. Build a router that sends batch work to standard, chat to fast, and real-time agents to ultra fast — automatically. Model the Pro Max unlock. If the $500/mo plan includes ultra fast quota, calculate your break-even volume vs pay-per-call at the ultra fast multiplier. Related reading See model routing for the pattern this extends, and LLM cost per user benchmarks to benchmark your own latency-to-value ratio. Related Model routing LLM cost per user benchmarks ChatGPT Pro Max: $500 plan economics How to cap inference costs Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # OpenTelemetry GenAI conventions for cost attribution · FinOps LLM URL: https://finopsllm.com/research/opentelemetry-genai-conventions OpenTelemetry GenAI conventions for cost attribution OpenTelemetry GenAI semantic conventions define a standard vocabulary of attributes for tracing and metering LLM calls. They enable observability backends, cost attribution engines, and billing systems to speak the same language about which model was invoked, how many tokens were consumed, and whether the tokens came from cache or live inference. Without a standard schema, each vendor's tracing layer invents its own attribute names, forcing teams to maintain translation maps for every new tool they adopt. The GenAI conventions are published and versioned by the OpenTelemetry specification maintainers. Adopting them means your traces will interoperate across Langfuse, Helicone, LiteLLM, custom collectors, and future platforms without remodeling or migration. Core attributes for cost tracking gen_ai.system. The LLM provider (e.g., "openai", "anthropic", "azure", "bedrock", "vertex"). Joins spans to price tables keyed by vendor. gen_ai.request.model and gen_ai.response.model. Request model (what you asked for) and response model (what you got). For routed or fallback scenarios, these may differ. Essential for pricing because models within the same vendor carry different rates. gen_ai.usage.input_tokens and gen_ai.usage.output_tokens. Counts of input and output tokens in the request. Decimal precision required; floats corrupt cost math at scale. gen_ai.usage.cache_read_tokens and gen_ai.usage.cache_creation_tokens. Tokens read from cache (OpenAI ~50% discount, Anthropic ~90%) and tokens written to cache. Conflating these with normal input tokens underestimates the value of caching. gen_ai.operation.name. Human-readable operation identifier (e.g., "chat.completion", "embedding.create"). Helps group spans by function in cost reports. gen_ai.request.id and gen_ai.session.id. Request correlation ID and conversation/session identifier. Required for chargeback and for tracking multi-turn cost per conversation. Why a standard schema powers attribution Cost attribution collapses without schema consistency. A standard set of attributes means: Vendor-neutral joins. Price the same span in OpenAI, Anthropic, or Bedrock by changing the gen_ai.system attribute and the underlying price table. No reparse. Observability backend swaps. Move from Langfuse to Helicone without losing cost granularity because both emit the same attribute names. Chargeback without bespoke math. Customer and feature tags propagate consistently across all downstream systems. A billing system that understands gen_ai.usage.input_tokens and gen_ai.system doesn't need special code per team. Cache and fallback handling. Separate token types and model mismatch detection prevent the most common cost-math errors. Enriching spans with business metadata Cost attribution requires more than LLM attributes. Instrument spans with: Feature name. Which product capability or workflow incurred this cost. Enables cost-per-feature and identifies expensive user paths. Account or tenant ID. Required for SaaS chargeback and per-customer profitability. Apply privacy-aware scrubbing; never log the full customer name. Plan or tier. Segment cost by customer segment (free, pro, enterprise) to detect tier-specific issues. Environment. Production vs. staging vs. eval. Eval and testing spend should never bill customers. User or request ID. Required for detailed per-user cost analysis and for debugging cost outliers. Attach these in a middleware or instrumentation layer so they flow into every span without repeating in application code. Common pitfalls Sampling out the wrong spans. Sampling for observability performance is standard. But if your sampler drops spans from high-cost customers or excludes fallback attempts, your cost attribution will be off. Use a separate cost-aware sampler that preserves all LLM calls even if it samples other telemetry. Losing exact model versions. If you record only "gpt-4" without the version (e.g., "gpt-4-turbo-2024-04-09"), pricing is ambiguous. OpenAI retired gpt-4-32k and replaced it with a cheaper variant under the same name. Always capture full model identifiers. Conflating cache reads with normal input. A span with 10k cache-read tokens and 500 new input tokens has very different cost implications than 10.5k normal input. If your aggregation adds them together, you overestimate input cost and underestimate cache value. Skipping fallback annotations. If a request tried GPT-4 and fell back to GPT-3.5, both should appear in the trace. A single span with only the fallback model hides the extra cost of the first attempt and skews per-model percentages. Applying the rule Cost data is only as trustworthy as the schema it flows through. Standardize on GenAI semantic conventions early; migration after the fact is expensive. Related LLM cost monitoring - operational metrics and alerting. LLM cost attribution - chargeback models and segmentation. LLM token tracking - usage analytics and forecasting. AI observability - tracing, metrics, and cost signals. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Opus 5.5 effort levels are the real price · FinOps LLM URL: https://finopsllm.com/research/opus-5-5-effort-level-cost Opus 5.5 effort levels are the real price Updated September 22, 2026 · first published September 22, 2026 Claude Opus 5.5 lists at $4 per million input tokens and $20 per million output tokens. That is 20% below Opus 5. The rate card is the smaller half of the cost story. The larger half is the effort setting, which decides how many tokens the model spends thinking before it answers. One model, five prices Opus 5.5 exposes effort from low through medium , high , xhigh and max . Each level is the same model at the same per-token rate, but it produces a very different number of tokens. Independent benchmarking reported by The Decoder found that four of the five levels sit on the cost–performance Pareto frontier. It also found that at max effort Opus 5.5 used about 119,000 output tokens per task, far more than competing models at their top settings. At $20 per million, 119,200 output tokens is $2.38 per task before any input. At medium, Artificial Analysis measured 25,700 output tokens, or $0.51. With input counted, max costs $5.98 per task and medium $1.34: the same model is about 4.5× more expensive per task depending on one request parameter. Measured on the Artificial Analysis Intelligence Index v4.3.2 (ten evaluations), read 22 September 2026. Every row uses the same benchmark suite, so the rows compare directly. Model and effort Intelligence Index Cost per task Output tokens per task On the cost–performance frontier Opus 5.5 · low 42.3 $0.55 10,200 No Opus 5.5 · medium 51.2 $1.34 25,700 Yes Opus 5.5 · high 53.6 $1.82 35,600 Yes Opus 5.5 · xhigh 56.0 $3.46 65,700 Yes Opus 5.5 · max 57.6 $5.98 119,200 Yes Opus 5 · high (reference) 48.1 $3.61 46,200 No Source: Artificial Analysis. On the frontier means no setting of GPT-6 Sol, GPT-6 Astra, Opus 5, Opus 5.5 or Fable 5.1 scores higher for less. Opus 5.5 low is off it because GPT-6 Sol at xhigh scores 44.1 for $0.53. Going from xhigh to max adds 1.6 points for 73% more cost. Medium is the setting Anthropic benchmarks against Anthropic's headline comparison is made at default effort, which is medium. It says Opus 5.5 at medium beats GPT-6 Astra at max effort on knowledge work for about a fifth of the cost per task. So Anthropic's own case for the model is built on medium, and max is the exception. A team that sets max everywhere "to be safe" pays for tokens the launch benchmarks did not need. How to set effort without guessing Default to medium. Make it the explicit value in code, not an SDK default that can change under you. Raise effort per route, not globally. Hard debugging, long-horizon planning and final review steps can justify high or max. Classification, extraction and routine edits rarely do. Log effort with every request. Cost per request is not interpretable without it. A spend spike with a flat request count is usually an effort change. Compare effort levels on the same replayed tasks. Record success rate and output tokens per completed task at each level, and stop raising effort when success stops improving. Cap output where the product allows it. A max-token limit bounds the worst case. At max effort that bound is the only thing between one runaway task and a several-dollar request. The cut from $25 to $20 per million output tokens saves 20%. Moving a workload from max to medium effort can save far more than that. Treat effort as a budget line, owned and reviewed like any other. Related Claude Opus 5.5 cost model Opus 5.5 fast mode economics Reasoning model cost guide Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Opus 5.5 fast mode: 2x the price for waiting time · FinOps LLM URL: https://finopsllm.com/research/opus-5-5-fast-mode-economics Opus 5.5 fast mode economics Updated September 22, 2026 · first published September 22, 2026 Claude Opus 5.5 has two price lists. Standard is $4 per million input tokens and $20 per million output tokens. Fast mode is $8 and $40, exactly double, for up to 2.5× the output speed. The model is the same. The extra money buys time and nothing else, so the only question is whose time. What the premium buys Take a step that produces 5,000 output tokens. At standard rates the output costs $0.10. In fast mode it costs $0.20. If the step takes 60 seconds at standard speed, a 2.5× speedup brings it to about 24 seconds. You pay an extra $0.10 to save 36 seconds. That works out to about $10 for each hour of waiting removed. Step length does not change the ratio, because the extra cost and the time saved both grow with output tokens. It does depend on your standard-mode speed: this example assumes about 83 output tokens per second, so plug in your own. Input also doubles, so prefix-heavy steps pay a bit more per second saved. When that is cheap A developer waiting on an interactive coding agent. At $10 per hour of waiting removed, fast mode costs far less than the time of anyone who is paid to sit there. A customer-facing answer where latency affects conversion. Price the speedup against drop-off, not against the token bill. An incident, where every minute has a cost. When it is pure waste Background agents, nightly jobs and batch pipelines. Nobody is waiting, so the extra spend buys nothing. Evals and replays. These are exactly the workloads that multiply token counts and run on a schedule. Subagents that run in parallel. Wall-clock time is set by the slowest branch and the orchestrator, not by each call. Standard Opus 5.5 is already about 30% faster than Opus 5, per Anthropic. Some latency complaints that would have justified fast mode on Opus 5 may be solved by the upgrade alone. Measure the standard speed before paying for more. Controls to put in place Make fast mode an explicit, per-route decision. It should never be a global default or a flag that an engineer turned on once and forgot. Tag spend by mode. A fast-mode request at double the unit price looks like a normal request on a dashboard that groups by model only. Alert on the fast-mode share of output tokens. If it rises on routes where no user is waiting, something was switched on that should not have been. Budget effort and speed together. Max effort multiplies the token count, and fast mode doubles the price of each token. The combination is the most expensive way to run the model. Related Claude Opus 5.5 cost model Opus 5.5 effort levels are the real price Subagent fan-out and concurrency limits Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Opus 5.5 25-Hour Agent Run: Full Cost Breakdown · FinOps LLM URL: https://finopsllm.com/research/opus-5-5-long-running-agent-cost-analysis Opus 5.5 long-running agent cost analysis Updated September 27, 2026 · first published September 27, 2026 A demo revealed Opus 5.5 working autonomously for ~25 hours to build a complete Minecraft clone: ~100K lines of game code, 26K lines of tests, 1,000 automated tests, 775 files, 783 generated images, 184 generated sounds, and an in-game guide. This is the first public glimpse of a long-horizon coding agent at scale. Let's model the cost. Estimating token volume No official token counts published. We'll model from output artifacts: Artifact Est. tokens Notes 100K lines game code ~3M output ~30 tokens/line avg 26K lines tests ~0.8M output ~30 tokens/line 775 files (structure, config) ~0.5M output Boilerplate + imports 783 images (prompts + metadata) ~1.5M input ~2K tokens/image prompt 184 sounds (prompts + metadata) ~0.4M input ~2K tokens/sound prompt In-game guide / docs ~0.3M output Markdown + code snippets Context / reasoning (25 hrs) ~10M input Tool calls, observations, planning Total estimate ~12.4M input / ~4.6M output Cost at Opus 5.5 pricing Token type Volume Rate Cost Input (uncached, est. 30%) 3.7M $4.00/MTok $14.80 Input (cached, est. 70%) 8.7M $0.20/MTok $1.74 Output 4.6M $20.00/MTok $92.00 Total ~$108.54 ~$109 for a 25-hour autonomous agent run producing a shippable game. That's ~$4.36/hour of agent compute. Sensitivity: cache hit rate matters most Cache hit rate Input cost Total cost Cost/hour 50% $24.80 $131.60 $5.26 70% (baseline) $16.54 $108.54 $4.34 90% $8.88 $92.88 $3.72 At 90% cache hit (achievable with good context management), the run drops to $93 total / $3.72/hr . Comparison: human developer A senior dev building this solo: 3-6 weeks (~120-240 hours) at $100-200/hr = $12K-$48K. The agent run at $109 is 100-400x cheaper — but only if the output quality passes your release gate. What this means for your agent budget Long-horizon agents are affordable. Sub-$150 for a 25-hour complex build changes the ROI calculus for agent-first workflows. Cache is the lever. Invest in prompt caching infrastructure — every 10% cache hit improvement saves ~$1.60 on a run like this. Output tokens dominate. At $20/MTok, output is 85% of the bill. Models that are more concise (Anthropic claims 40% less verbose) directly cut cost. Monitor per-run, not per-month. Agent workloads are bursty. Track cost per task completion, not aggregate monthly spend. Related reading See Claude Opus 5.5 cost model , agent economics , prompt caching economics , and cost per successful task . Related Claude Opus 5.5 cost model Agent economics Prompt caching economics Cost per successful task Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # The Order of LLM Cost Optimizations · FinOps LLM URL: https://finopsllm.com/research/order-of-llm-cost-optimizations Order of LLM cost optimizations Updated September 27, 2026 · first published September 27, 2026 A September 2026 r/LLMDevs thread asked how people actually control LLM costs in production, and what they'd do if engineering time were not the constraint. The top-voted reply is worth more than any vendor playbook: the order matters way more than people admit. They started with prompt caching and trimming system prompts way down. What failed spectacularly was fine-tuning a small model to handle the repetitive stuff — maintenance overhead was a nightmare and the quality kept drifting. The order that works Prompt caching. Cheapest engineering hour you will ever spend. Cache reads on Opus 5.5 are $0.20 per million against $4.00 for fresh input — a 95% discount on the largest line item. If your system prompt, tool definitions, or retrieved context repeat across calls, you are leaving this on the table before you do anything else. Trim the system prompt. The same thread, same reply: system prompts down. Verbose instructions are billed on every call forever. This is a writing task, not an engineering task. Delete unused tools. Every tool definition ships in the context on every request whether or not the model calls it. The same mechanism as MCP tool definition overhead. Removing a tool is a one-line config change with a permanent effect. Route by task. Only now does model routing pay. A router built on step 1 is already cheaper before it switches a single model. Batch or defer. Batch API is a straight discount for anything that is not user-facing. Non-production traffic should be on batch from day one. Fine-tune last, if ever. The step teams reach for first, and the one that failed for this team. Maintenance overhead plus drifting quality means a permanent ops tax for a saving that caching and routing already captured. Why the order is the whole point Each step changes the token counts the next step operates on. Trim the system prompt before routing, and the cheap model handles more of your traffic for the same routing logic. Enable caching before fine-tuning, and the fine-tuning budget only has to cover the cache misses. Do it in the wrong order and you pay twice: a fine-tune that a prompt rewrite would have made unnecessary, or a router that routes 60K tokens of instructions through a cheap model it was never meant to carry. The mistake pattern The failure mode in the thread was fine-tuning a small model for repetitive work. The intended saving was real. What arrived instead was a model that needed re-training every time the repetitive work shifted, quality that drifted away from the underlying model as that model was upgraded upstream, and an ops burden that made the fine-tune unmaintainable. The repetitive work was probably 15% of volume and 2% of spend — a small number wrapped in a large ongoing cost. Rehearse the sequence on one request Take a single representative request and apply each step in order, recording total billed tokens: Step What changes Typical billed-token cut Caching on Repeat prefix becomes a cache read 40–70% System prompt trimmed Fewer uncached tokens on every call 10–25% Unused tools removed Smaller tool block 5–15% Routing Cheaper model on most traffic 30–60% Batch for non-prod Discount tier 25–50% of that traffic These compound. Applied in order, the same request often lands 80–90% cheaper. Applied in the order teams usually reach for, you get a fine-tune on 15% of volume and a routing rule that never pays for itself. Bottom line Caching, trimming, and deleting unused tools are cheap, compounding, and low-risk. Routing and batching come after. Fine-tuning comes last or not at all. The list is not the hard part; the sequence is. Related The verbose prompt tax MCP tool definition overhead Subagent fan-out concurrency limits Free tier is an acquisition cost Three agent budgets Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Ox Alpha was GLM-5.3: the cost of a free window · FinOps LLM URL: https://finopsllm.com/research/ox-alpha-was-glm-5-3 Ox Alpha was GLM-5.3 Updated September 1, 2026 · first published September 1, 2026 Quick answer: Between 20 and 26 August 2026, a model listed on OpenRouter as stealth/ox-alpha was served free of charge. It has since been identified as GLM-5.3-Flash: 320 billion total parameters with 18 billion... Between 20 and 26 August 2026, a model listed on OpenRouter as stealth/ox-alpha was served free of charge. It has since been identified as GLM-5.3-Flash: 320 billion total parameters with 18 billion active, hybrid linear and sparse attention, native text, image and video input, a 1,048,576-token context window, 131K maximum output, and MIT-licensed weights. The uptake was not marginal. Within three days of the listing, OpenCode reported roughly 16 trillion tokens processed, 221,000 unique users, more than five million sessions, and the number two position by recent usage. That is production traffic, not evaluation traffic — and for six days it cost nothing. Free is a rate, not an absence The finance problem with a free stealth endpoint is that most cost telemetry treats a $0 line as no line at all. Requests that were routed to Ox Alpha during that week appear in usage dashboards as zero-cost, so they carry no weight in any spend forecast, budget alert, or per-feature unit-economics view. Then the window closes, the model is renamed, a rate is applied, and the same traffic reappears as a step change nobody modelled. The fix is to price every call at a shadow rate, including the free ones. Record the token counts as normal and multiply by the list price of the model you would otherwise have used. Your dashboard then shows what the promotion is worth per month, and what the bill becomes the day it ends. Sixteen trillion tokens at a typical flash-tier rate is not a rounding error. The rate is no longer hypothetical. GLM-5.3-Flash now lists at $0.15 per million input tokens and $0.50 per million output. Sixteen trillion input tokens at that rate is roughly $2.4 million — that is what six days of free tokens were worth, and the size of the step if that traffic simply stayed where it was. The three exposures to check Exposure Question to ask Control Rate cliff What does this traffic cost at list price tomorrow? Shadow pricing on free endpoints, with the same budget alerts. Identity drift Which model is behind the alias this week? Pin model IDs; never route production to a stealth alias without a fallback. Quality coupling Did prompts get tuned to a model you cannot keep? Run evals against the named replacement before the window ends. MIT weights change the buy-versus-build maths The identity reveal matters for a second reason. GLM-5.3-Flash ships under an MIT licence, which means the self-hosting option is real rather than theoretical. With 18 billion active parameters out of 320 billion total, serving cost is closer to a mid-size dense model than the headline count suggests — but only if you have consistently high utilisation. Below roughly 40–50% GPU utilisation, per-token API pricing usually still wins, because idle accelerators bill at full rate while an idle API call bills nothing. So the decision is not open-weights versus API. It is a utilisation threshold. Measure your sustained tokens per second over a full week, including nights and weekends, and only then compare a reserved-capacity quote against the same volume at list API rates. Include engineering time for serving, evaluation, and upgrades in the self-hosted column; that is the line most build cases forget. What to do when the next stealth model appears Treat every free window as a fixed-term contract with an unnamed counterparty. Evaluate the model properly — free tokens are a genuinely cheap way to run an eval suite. But route production traffic to it only behind a fallback, keep the shadow price in your dashboards, and diary the end of the window as a forecast event. The model was excellent and the price was zero; only one of those two facts was durable. Related Open source versus closed model cost Provider arbitrage Model deprecation and migration costs Related Open source versus closed model cost Provider arbitrage Model deprecation and migration costs Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # How to price a model that has no price · FinOps LLM URL: https://finopsllm.com/research/pricing-an-open-weight-model Pricing an open-weight model Updated September 1, 2026 · first published September 1, 2026 Quick answer: Qwen3.8-Flash-Next arrived on 26 August 2026 as an open-weight preview of the Qwen4 architecture: roughly 6B active parameters, a 262,144-token native context, and no hosted pricing announced. That... Qwen3.8-Flash-Next arrived on 26 August 2026 as an open-weight preview of the Qwen4 architecture: roughly 6B active parameters, a 262,144-token native context, and no hosted pricing announced. That combination breaks the usual comparison. Every closed model gives you a number per million tokens; an open-weight release gives you a checkpoint and leaves the number to you. The number is not hard to compute. It is just that most teams never compute it, and instead compare a $0 download against a $3.00/MTok API and conclude the download is cheaper. It might be. The arithmetic decides, and the arithmetic has exactly one term people forget. The formula Cost per million tokens is the hourly price of the instance divided by how many tokens that instance produces in an hour: cost per MTok = hourly_price / (tokens_per_second * 3600) * 1,000,000 At $2.00 per hour and a measured 1,500 tokens per second, that is 2.00 / 5,400,000 * 1,000,000 = $0.37 per million tokens . Against a hosted model at $3.00/MTok output, self-hosting looks like an eight-fold saving. That figure is also wrong, because it assumes the GPU is busy every second you pay for. The term everyone forgets: utilisation You rent the hour; you use a fraction of it. Divide by that fraction: Utilisation Effective cost per MTok 100% $0.37 60% $0.62 30% $1.23 10% $3.70 At 10% utilisation the self-hosted model costs more than the hosted API it was meant to replace. Most first deployments sit between 10% and 30%, because traffic is bursty and the instance is provisioned for the peak. The saving is real, but it is a saving on utilisation , not on weights. What else belongs in the number Storage and egress for the checkpoint. Idle time between the instance booting and the model being warm — on a large-context model, loading is minutes, and you pay for all of them. Redundancy, if the workload needs more than one instance to survive a node failure. And engineering time, which is not billed hourly but is the largest line in year one. None of that argues against self-hosting. It argues against comparing a free download to a per-token rate without doing the division. Measure before you commit Run the model on the instance you would actually rent, with your own prompt shapes and your own context lengths, and record tokens per second under concurrency — not the single-stream number from the model card. Then take your real hourly traffic profile and compute utilisation. Two numbers, one division, and the decision makes itself. The long context is where this bites hardest. A 262K-token context is a memory footprint before it is a feature: it dictates the instance class, and the instance class dictates the hourly price at the top of the formula. Price the context you actually send, not the context the model supports. Related Open source vs closed model cost Cost per request as a KPI Provider arbitrage Related Open source vs closed model cost Cost per request as a KPI Provider arbitrage Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Prompt cache attribution · FinOps LLM URL: https://finopsllm.com/research/prompt-cache-attribution Prompt cache attribution Updated 21 May 2026 · first published 21 May 2026 Prompt caching is usually framed as an optimization problem: keep your prefixes stable, get a discount on input tokens, move on. Inside a FinOps function the harder question shows up later. Once a cache is working, it becomes shared infrastructure that several product surfaces depend on. The savings, the breakage, and the warm-up cost all need to land on somebody's ledger. Attribution is what turns "we enabled caching" into a number the CFO can defend per team, per feature, and per customer. This page is about how to allocate prompt-cache-affected spend. It assumes you have already turned caching on. The question we care about is who gets credit when the cache pays off, who pays the tax when it does not, and how to report both without picking favorites. Cache as shared infrastructure A prompt cache is not a per-feature asset. The same cached prefix can be reused by an internal eval suite, a customer-facing copilot, a nightly batch job, and a support workflow. The provider bills you for the underlying tokens at a discounted cache-read rate, but the bill arrives at the account level. If you stop there, every feature looks equally efficient and no one is accountable for the prefix design choices that produced the savings in the first place. The FinOps move is to treat the cache the way platform teams treat a Kubernetes cluster, a Snowflake warehouse, or a CDN. Someone owns the shared layer. Consumers get a unit-economics view that includes their share of the discount and their share of the overhead. Without that, cache savings drift into "general efficiency" and disappear from the conversation by the next quarter. What a clean attribution model needs Three numbers per consumer, per period: Cache-read tokens used, separated from ordinary input tokens. The implied savings at the consumer level, calculated as cache-read tokens times the difference between full input price and cache-read price. The consumer's contribution to cache warmups, invalidations, and misses against shared prefixes. The first two are straightforward once your usage records carry a cache-read field. The third is the one most teams skip, and it is the one that decides whether attribution feels fair. Allocating the savings There are three reasonable allocation methods. Each is defensible. Pick one and document it before anyone argues about a chargeback. Direct attribution Credit each consumer with the cache-read tokens it actually billed. Simple, auditable, and aligned with provider invoices. The downside is that whoever rides on a prefix that was warmed by another team gets a windfall, and the team that paid to keep the prefix stable gets nothing extra. Warmup-adjusted attribution Identify which team owns the canonical prefix for each cache key and route a portion of every reader's discount back to the owner. This rewards prefix stewardship and discourages the pattern where one team quietly destabilizes a prefix that other teams depend on. It requires a registry of cache prefixes with named owners. Platform-tax attribution Treat the entire cache as a platform overhead. Charge it back to consumers as a flat percentage of their LLM spend and let the platform team report a single net-savings number for the company. The cleanest accounting, the weakest behavioral incentive. Useful when product teams are too small to act on per-prefix data. Reporting the cache tax Even when caching is paying off in aggregate, individual teams pay a tax. Cache-friendly architectures cost engineering hours, slow down certain refactors, and force coordination across services that did not previously coordinate. A FinOps report that only shows the upside will eventually lose credibility when an engineering lead says, "we spent six weeks on prefix stability and saw nothing on our line." The fix is to report the tax explicitly. For each team, show cache-read savings as a credit, and show three categories of cost alongside it: cache misses on prefixes the team owns, invalidations the team caused on prefixes other teams own, and warmup tokens spent re-priming a cache after a deploy. The net of those numbers is the team's real cache contribution. Teams that show a positive net should be the ones held up as examples. Teams that show a negative net deserve a conversation, not a public shaming, but the number needs to exist. Who pays when cache breaks Cache breakage is rarely a single bad commit. It is usually a chain. A platform team upgrades a tool schema. A retrieval service starts injecting context one block earlier. A prompt template adds a timestamp inside what used to be the stable prefix. By the time the cache hit rate drops from seventy percent to single digits, three teams have touched the request. An attribution model needs a rule for this. Two options work in practice. The first is last-touch: the team whose deploy correlates with the cache-hit-rate drop owns the incremental spend until hit rate recovers. The second is owner-of-prefix: the team that owns the cache key absorbs the cost regardless of who broke it, on the theory that the owner should have been monitoring drift on their own prefix. Last-touch is easier to defend in incident review. Owner-of-prefix creates better long-term incentives. Most mature programs use last-touch for the first seven days and shift to owner-of-prefix if the regression is not fixed. What the data has to look like Attribution falls apart if your usage records cannot separate cache-read tokens from input tokens. Most providers expose the field; most pipelines drop it on the way into the warehouse because the original ingest schema predates caching. Before designing any chargeback, audit your token table for these columns: input tokens, cached input tokens, cache-write tokens where applicable, output tokens, model, owner tag, and request surface. If the cached-input column is missing or always zero, fix the pipeline before promising anyone a report. Cache-write tokens deserve their own line. Some providers bill a premium on the first request that writes a new cache entry. If a team's workload pattern forces frequent writes, it is paying a higher effective rate than the unit-price table suggests. That premium needs to land somewhere visible, not buried in "other input tokens." Customer-level allocation For products sold to external customers, the same logic extends one layer down. A customer whose traffic rides cleanly on shared prefixes is cheaper to serve than one whose traffic forces unique long-tail prefixes. If you bill per token or per message at a flat rate, you are subsidizing the second customer with the first customer's efficiency. Whether that is a problem depends on your pricing strategy, but the FinOps team should at least be able to surface the gap. The standard report is gross margin per customer with and without cache benefit. The "without" view shows what each customer would cost you at full input pricing. The "with" view shows the actual provider invoice. The difference tells you how much of your margin depends on continued cache health for that account, which is the same as asking how exposed your unit economics are to one prefix going unstable. Where this fits in a FinOps program Prompt cache attribution sits between cost allocation and anomaly detection. It uses the same owner tags and consumer dimensions as the rest of the chargeback model, and it feeds the same monthly reports. Where it differs is in the time horizon. Cache hit rate moves on the order of deploys, not invoice cycles, so the attribution view needs a daily or weekly cadence. Monthly is too slow to catch the team that broke a shared prefix in week one. Done well, cache attribution stops being a footnote in the savings dashboard and starts behaving like a real line item: each team knows what it contributes and what it draws, the platform owner can defend the investment, and the CFO can answer the question, "what happens to our margin if caching stops working next quarter?" That question has a number, and the number is the one that matters. Related LLM cost attribution LLM token tracking LLM chargeback and showback LLM cost anomaly detection Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ Why is a prompt cache shared infrastructure? A prompt cache is not a per-feature asset. The same cached prefix can be reused by an internal eval suite, a customer-facing copilot, a nightly batch job, and a support workflow. What does a clean prompt-cache attribution model need? Three numbers per consumer, per period: cache-read tokens separated from ordinary input tokens; the implied savings, calculated as cache-read tokens times the gap between full input price and cache-read price; and that consumer's contribution to cache warmups, invalidations, and misses against shared prefixes. The first two fall out of any usage record carrying a cache-read field. The third is the one most teams skip, and it is what decides whether the attribution feels fair. How should caching savings be allocated? There are three reasonable allocation methods. Each is defensible. Pick one and document it before anyone argues about a chargeback. Direct attribution Credit each consumer with the cache-read tokens it actually billed. Simple, auditable, and aligned with provider invoices. What is the cache tax and how do you report it? Even when caching is paying off in aggregate, individual teams pay a tax. Cache-friendly architectures cost engineering hours, slow down certain refactors, and force coordination across services that did not previously coordinate. Who pays when the cache breaks? Cache breakage is rarely a single bad commit. It is usually a chain. A platform team upgrades a tool schema. A retrieval service starts injecting context one block earlier. A prompt template adds a timestamp inside what used to be the stable prefix. What the data has to look like? Attribution falls apart if your usage records cannot separate cache-read tokens from input tokens. Most providers expose the field; most pipelines drop it on the way into the warehouse because the original ingest schema predates caching. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Prompt Caching ROI: Calculating Real Savings · FinOps LLM URL: https://finopsllm.com/research/prompt-caching-economics Prompt caching ROI and attribution Published 1 August 2026 Prompt caching is the most misreported optimization in LLM cost management. Teams enable it, see cache-read tokens on their invoice, and claim 50% savings. The real figure is usually half that. The mistake is counting cache-read tokens as full savings instead of calculating the actual discount. This article shows how to calculate real savings, attribute them to the right workloads, and decide whether caching is worth the complexity for your use case. How prompt caching actually works Providers cache the prefix of your prompt: system instructions, few-shot examples, retrieved context. If the next request shares that prefix, the provider charges a discounted rate for the repeated portion. The discount varies by provider: Provider Cache-read discount Cache write cost TTL OpenAI ~50% of input price Full input price 5-10 minutes Anthropic ~10% of input price ~25% premium over input price 5 minutes Google Gemini ~25% of input price Full input price 1 hour The economics are not intuitive. Anthropic charges a premium to write to cache, so the first request is more expensive. Savings only materialize on subsequent requests within the TTL window. OpenAI and Gemini charge full price for cache writes, so the first request costs the same as without caching. Calculating real savings The formula is: Savings = (input_tokens_without_caching × input_price) - (cache_write_tokens × cache_write_price) - (cache_read_tokens × cache_read_price) - (output_tokens × output_price) A concrete example. A support summarization endpoint sends 4,000 input tokens per request: 3,000 tokens of system prompt + 1,000 tokens of user ticket. Without caching, at $2.50 per 1M input tokens: Cost per request: 4,000 × $2.50/1M = $0.010 1,000 requests/day: $10.00 With caching, 70% of requests share the 3,000-token system prompt. OpenAI charges $1.25 per 1M cache-read tokens: 300 requests (miss): 4,000 × $2.50/1M = $0.010 each 700 requests (hit): 3,000 × $1.25/1M + 1,000 × $2.50/1M = $0.00625 each Daily cost: (300 × $0.010) + (700 × $0.00625) = $3.00 + $4.375 = $7.375 Real savings: 26%, not 50% The 50% figure would come from counting all cache-read tokens as free. That is wrong. Cache reads are discounted, not free, and cache misses still cost full price. Attributing savings correctly Cache savings belong to the workload that generates the cache hits. If you share a system prompt across support, sales, and engineering endpoints, the savings belong to each endpoint proportionally to its hit rate. Attribution requires per-request records with: cache_write_tokens (full price) cache_read_tokens (discounted price) cache_hit (boolean or hit rate) feature / endpoint Without this split, you cannot answer: "Did the support endpoint save money, or did the eval suite?" The answer matters because you optimize the endpoint with the worst hit rate, not the one with the most tokens. When caching is not worth it Three cases where caching adds cost instead of saving it: Low hit rate. Below 30%, the cache write premium (Anthropic) or TTL expiry (all providers) eats the discount. Short, unique prompts do not benefit. Short prompts. A 500-token prompt saves fractions of a cent per request. The engineering time to implement and monitor caching exceeds the savings. Anthropic with low volume. Anthropic charges a 25% premium on cache writes. If your volume is low and your hit rate is below 50%, the first-request premium exceeds subsequent discounts. Measuring hit rate Hit rate is the percentage of requests that share a cached prefix with a previous request within the TTL. Measure it per endpoint, not globally: SELECT feature, COUNT(*) AS total_requests, SUM(CASE WHEN cache_read_tokens > 0 THEN 1 ELSE 0 END) AS cache_hits, SUM(cache_read_tokens) AS total_cache_read, AVG(cache_read_tokens * 1.0 / input_tokens) AS avg_prefix_ratio FROM llm_usage WHERE date >= CURRENT_DATE - 7 GROUP BY feature ORDER BY cache_hits DESC A healthy cache shows hit rate >50% and prefix ratio >0.6 (most of the input is cached). A hit rate below 30% means the TTL is too short or the prompts are too unique. Provider-specific gotchas OpenAI. Cache is automatic for prompts >1,024 tokens. No explicit cache control. TTL is short (5-10 minutes), so batch workloads with gaps between requests lose the cache. Anthropic. Explicit cache control via `cache_control` markers. You choose what to cache. This is powerful but requires code changes. The 25% write premium means you need hit rate >55% to break even on a two-request sequence. Gemini. Context caching is explicit and has a 1-hour TTL. Good for batch jobs that run within the hour. The 75% discount on cache reads is the most aggressive, but the setup is the most manual. Decision framework Use this checklist before enabling caching: Is the average input prompt >1,000 tokens? If no, skip. Is the hit rate likely >30%? If no, skip. Is the workload latency-sensitive? If yes, cache reads also reduce latency — a secondary benefit. Can you measure cache_write_tokens and cache_read_tokens separately? If no, implement metering first. Is the provider Anthropic? If yes, require hit rate >55% to justify the write premium. If you answer yes to all, caching is likely your highest-ROI optimization. If you answer no to any, model routing or prompt compression is probably a better first lever. Related Prompt caching explained - the mechanics of how providers cache prefixes. LLM usage metering and billing - how to meter cache tokens correctly. Semantic cache economics - caching semantically similar prompts, not just exact prefixes. Model routing - when routing beats caching as the first lever. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ How much can prompt caching save? For workloads with long, repeated system prompts or few-shot examples, prompt caching typically saves 20-40% on input tokens. The exact figure depends on cache hit rate: the percentage of requests that share a prefix with a previous request. Hit rates below 30% rarely justify the complexity. How do I calculate prompt caching savings correctly? Savings = (full_price_input_tokens - cache_read_tokens × cache_read_price_ratio) × model_input_price. Do not count cache_read_tokens as full savings. The discount applies only to the cache-read portion, and cache writes still cost full price. What is a good cache hit rate? Production systems typically see 30-70% hit rates. Below 30%, caching adds complexity without meaningful savings. Above 70%, the workload is highly repetitive and caching is usually the single biggest optimization lever. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Prompt caching explained · FinOps LLM URL: https://finopsllm.com/research/prompt-caching-explained Prompt caching explained Updated 12 July 2026 · first published 11 June 2026 Prompt caching is a provider-native optimization where LLM APIs store the processed prefix of a prompt and apply a discount when that prefix is re-read. The model provider parses the prefix once, computes embeddings and key-value caches, and reuses them across subsequent requests. Cache hits reduce token costs significantly-OpenAI discounts cache-read input tokens at roughly 50% of normal input cost, while Anthropic discounts them at roughly 90% of normal input cost. The financial benefit depends on how stable your prompt prefix is and how often the same prefix repeats across requests. How prompt caching works across providers OpenAI. Automatic for sufficiently long prompts (typically ≥1024 tokens). The model tracks the longest common prefix across requests and caches it. No code change required, though you can optimize by putting stable content first. Cache reads cost approximately 50% of standard input tokens; cache writes cost slightly more than normal input to pay for caching overhead. Anthropic. Explicit cache control via breakpoints in the message list. Add cache_control: {"type": "ephemeral"} to the last message block you want cached (usually the system prompt and tools). Cache reads are discounted to approximately 10% of normal input token cost. Cache writes cost 25% more than normal input. Requires structural awareness: you place the cache breakpoint, not the model. Amazon Bedrock. Supported on select models (Anthropic Claude via Bedrock). Uses the same explicit cache_control breakpoint mechanism as Anthropic's native API. Availability depends on the model and region; check Bedrock's current documentation for supported configurations. Structuring prompts for cache hits Cache hits require byte-identical prefixes. Small differences break the cache silently. Use these patterns to maximize stability: System prompt and tools first, user content last. Put your stable instructions, tool definitions, and few-shot examples before the variable user request. The longer the stable prefix, the greater the savings. Byte-identical across requests. Any whitespace, formatting, or punctuation change invalidates the cache. Avoid dynamic timestamps, random IDs, or computed values in the prefix. Avoid per-user system prompts. If you customize the system prompt per user (e.g., "You are an assistant for Alice"), the cache will never hit. Instead, keep the system prompt universal and pass user context in the variable part of the message. Use deterministic JSON or markdown for tools. If your tool definitions are code-generated, ensure the generation is deterministic. Reordering fields, adding newlines, or changing indentation breaks the cache. Separate cache breakpoint from request boundary. Some systems split messages at request time. Ensure the split happens after your stable prefix, not in the middle of it. Mistakes that silently disable caching Reordering tools or examples. If your orchestration layer re-sorts function definitions or few-shot examples on each request, the cache never hits even though the content is identical. Injecting dynamic data early in the prefix. Conversation IDs, request timestamps, or user agent strings in the system prompt or early messages break cache consistency across requests. Per-user system prompts. "You are helping {username}" or "Your tone should match {brand_voice}" in the system prompt means the prefix changes every request. Nondeterministic serialization. If your message serialization uses unordered dicts, set iteration, or floating-point rendering, identical logical content produces different bytes and misses the cache. Intermixing cached and uncached messages. Some frameworks make it easy to add preamble text conditionally. If your cache breakpoint floats or messages before it vary, cache hits become unreliable. FinOps: tracking cache tokens for attribution Cache-read tokens cost far less than normal input tokens. If you don't track them separately in your cost model and attribution, your savings estimates become fiction. When a request uses 8k cache-read tokens and 500 new input tokens, conflating them corrupts your baseline. You need three token counts: input (normal), cache-read (cached prefix), and output. Your cost calculation then uses the provider's discount to compute actual spend per request, and your attribution model reports both gross tokens and net cost. Without separate tracking, teams celebrate cost savings that don't exist (because they're measuring gross tokens, not net cost) or fail to see real savings because their baseline is built on incorrect token pricing. The golden rule Stable prefix, variable suffix, byte-identical every time. Then measure cache-read tokens separately or your numbers lie. Related Prompt cache attribution - how to split savings across teams. Semantic cache economics - caching beyond byte-matching. How LLM providers charge - cost mechanics across platforms. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is prompt caching? Prompt caching is a provider-native optimization where LLM APIs store the processed prefix of a prompt and apply a discount when that prefix is re-read. The model provider parses the prefix once, computes embeddings and key-value caches, and reuses them across subsequent requests. Cache hits reduce token costs significantly—OpenAI discounts cache-read input tokens at roughly 50% of normal input cost, while Anthropic discounts them at roughly 90% of normal input cost. How does prompt caching work across different providers? OpenAI uses automatic caching for sufficiently long prompts (typically ≥1024 tokens) with no code change required, though you can optimize by putting stable content first. Cache reads cost approximately 50% of standard input tokens. Anthropic requires explicit cache control via breakpoints in the message list using cache_control: {'type': 'ephemeral'}, with cache reads discounted to approximately 10% of normal input token cost. Amazon Bedrock supports the same Anthropic mechanism on select models. How should prompts be structured to maximize cache hits? Cache hits require byte-identical prefixes. Put your stable instructions, tool definitions, and few-shot examples before the variable user request. Keep the system prompt universal instead of customizing it per user. Use deterministic JSON or markdown for tools. Ensure any message splits happen after your stable prefix, not in the middle of it. What mistakes silently disable prompt caching? Common mistakes include: reordering tools or examples between requests; injecting dynamic data early in the prefix like conversation IDs or timestamps; per-user system prompts like 'You are helping {username}'; nondeterministic serialization using unordered dicts or set iteration; and intermixing cached and uncached messages where the cache breakpoint floats. Why must cache-read tokens be tracked separately for FinOps? Cache-read tokens cost far less than normal input tokens. If you don't track them separately in your cost model and attribution, your savings estimates become fiction. You need three token counts: input (normal), cache-read (cached prefix), and output. Without separate tracking, teams celebrate cost savings that don't exist or fail to see real savings because their baseline is built on incorrect token pricing. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # How to prove AI ROI without hiding quality regressions · FinOps LLM URL: https://finopsllm.com/research/prove-ai-roi-measurement How to prove AI ROI without hiding quality regressions Updated August 27, 2026 · first published August 27, 2026 Quick answer: AI ROI is not proven by showing that the model bill fell. It is proven when a measured business outcome improves more than the fully loaded AI cost required to produce it. The measurement needs three... AI ROI is not proven by showing that the model bill fell. It is proven when a measured business outcome improves more than the fully loaded AI cost required to produce it. The measurement needs three linked records: attributable spend, successful outcome, and a quality check that prevents cheaper but worse work from looking like a win. Start with a counterfactual State what would have happened without the AI change: human handling, an older model, the previous workflow, or no feature launch. Choose a comparable period or control cohort. Without a counterfactual, revenue growth and cost reduction cannot be attributed to AI rather than traffic, pricing, seasonality, or unrelated product work. Use an outcome denominator Measure cost per successful task, not cost per request. Define success in observable terms and link the outcome to the model trace: accepted support answer, invoice extracted without correction, or workflow completed within its service level. Include retries, tools, human repair, and evaluation traffic in the cost numerator. Keep quality in the equation Pair the financial result with task success, error rate, latency, user acceptance, or downstream conversion. A 25% cost reduction that cuts task success from 92% to 80% is not an ROI improvement. Set a quality floor before the experiment and reject savings below it. Report a range, not a miracle number Show conservative, base, and upside cases. Name the assumptions for adoption, provider rate, volume, human time, and quality. Reconcile spend to provider invoices and document which benefits are realized cash savings, avoided hiring, faster throughput, or strategic option value. The board does not need a perfect number. It needs a number whose denominator, counterfactual, quality floor, and assumptions can survive questions. Related Cost per successful task LLM cost attribution AI observability Related Cost per successful task LLM cost attribution AI observability Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # LLM Provider Arbitrage: Price and Quality Parity · FinOps LLM URL: https://finopsllm.com/research/provider-arbitrage Provider arbitrage Provider arbitrage means buying equivalent model capability from the cheapest provider that can actually deliver it. It is one of the most direct ways to reduce LLM spend, but it only works when you separate “same model name” from “same useful output.” A provider may offer a lower nominal price and still end up costing more once latency, error rates, routing overhead, and quality regression are included. The basic idea is simple: identify workloads that do not depend on the proprietary behavior of one provider, benchmark equivalent models across vendors, and move stable traffic to the better price-performance option. The hard part is proving equivalence. Many teams discover that their workload is not the same after translation because system prompts, tool schemas, safety filters, or output formatting differ. What to compare Compare price, quality, latency, reliability, and operational complexity. Price alone is not enough. A cheap provider with poor uptime or poor routing support may increase retries and hidden engineering cost. A slightly more expensive provider with better throughput and fewer edge cases can be cheaper in the final unit economics. Equivalent capability should be measured on the task you actually run, not on a generic benchmark alone. For open-weight models, compare hosted options across providers and regions. For closed models, compare the models themselves and the infra around them. In both cases, include egress, logging, and gateway overhead in the comparison. A model that is 15% cheaper at the token level but requires a complicated adapter layer may not be worth switching to unless the spend is material. When arbitrage works best Arbitrage works best on stable, high-volume traffic with well-defined output structure. Extraction, classification, templated summarization, and background enrichment are good candidates. Highly creative or brand-sensitive generation usually needs more care. The more repeatable the task and the clearer the acceptance criteria, the more attractive the swap. Migration discipline Do not move all traffic at once. Start with a narrow endpoint and a strict rollback plan. Run both providers on the same evaluation set, then on a small percentage of live traffic. Track quality deltas and failure modes. Some teams save money by moving the first 70% of traffic and keeping the remaining 30% on the original provider because of edge-case behavior. That is fine if the blended cost still improves. Provider arbitrage is most sustainable when it is managed as a normal engineering program rather than a one-time procurement swap. Prices drift, model versions change, and provider quality changes over time. Re-run the benchmark periodically and keep the route policy fresh. Related Model routing - routing across models and providers. AI cost optimization - comprehensive optimization strategies. GenAI cost management - applying optimization across the platform. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # AI provider list prices are not directly comparable · FinOps LLM URL: https://finopsllm.com/research/provider-prices-not-comparable AI provider list prices are not directly comparable Updated August 27, 2026 · first published August 27, 2026 Quick answer: Comparing AI providers by the headline price per million tokens produces false savings. Providers bill different token types, discounts, context rules, regions, and tool calls. A useful comparison... Comparing AI providers by the headline price per million tokens produces false savings. Providers bill different token types, discounts, context rules, regions, and tool calls. A useful comparison measures effective cost per successful task for the same workload and quality target. Normalize the billable unit Build a price sheet keyed by provider, model, endpoint, region, token type, cache state, batch status, and effective date. Keep input, output, cache-read, cache-write, reasoning, image, audio, and tool charges separate. Record minimum commitments and credits outside the unit rate so the comparison does not hide a contract assumption. Normalize the workload Replay a fixed sample with the same prompts, context, output constraints, tool permissions, and success test. Measure p50 and p95 latency, completion rate, retries, human repair, and output quality. A model that is 30% cheaper per token but needs twice as many retries may be more expensive per successful task. Include operating cost Provider arbitrage has an engineering price. Add gateway changes, observability, routing logic, evaluation, support, data-transfer cost, and failure handling. Run the calculation over a realistic traffic mix, not a single ideal prompt. The cheapest model for summarization may be the wrong model for extraction or high-value reasoning. Route by capability-per-dollar Use a capability matrix with a minimum quality score and a maximum effective cost per workload. Route eligible requests to the cheapest provider that passes both. Keep a fallback route, but count its expected cost and test it during failover drills. Record why each request was routed so savings can be reconciled to invoices. Provider price comparison is not a leaderboard. It is a controlled experiment with a common workload, a quality bar, and a fully loaded denominator. Related LLM provider arbitrage Model routing without quality regressions Cost per successful task Related LLM provider arbitrage Model routing without quality regressions Cost per successful task Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # RAG cost optimization · FinOps LLM URL: https://finopsllm.com/research/rag-cost-optimization RAG cost optimization RAG cost optimization is mostly a context-management problem. Teams often focus on vector database costs first, but in production the larger bill usually comes from what retrieval causes downstream: more tokens sent to the model, more reranking calls, more retries, and longer latencies that trigger fallback behavior. A retrieval system that returns too much context can make a cheap model expensive. A retrieval system that returns too little context can force retries and escalation to more capable models. The goal is not maximal recall in isolation. The goal is the cheapest context that still enables the answer. High-impact levers Tighten chunking and metadata so retrieval returns smaller, more relevant units. Cap the number of chunks passed into generation and raise the cap only when confidence drops. Use reranking selectively on ambiguous queries instead of every request. Cache retrieved context for repeated prompts and repeated tenants where appropriate. Separate interactive traffic from offline indexing and embedding refresh jobs. What to measure Measure retrieval hit rate, chunks per answer, average context tokens, rerank frequency, fallback rate, and cost per successful answer. These metrics show whether the retrieval system is actually helping the generation layer or just increasing billable token volume. It is also useful to compare spend by query class. Policy lookups, product FAQs, account troubleshooting, and long-form research may all use the same RAG stack, but they need different context limits and different latency budgets. Optimization sequence Start by identifying the routes with the highest context-token spend. Then tune chunking and caps before touching the model. Many teams discover that context discipline creates a larger savings than provider switching. After that, model routing and cache policy become easier to tune because the workload is better behaved. Related reading: LLM cost monitoring , LLM cost anomaly detection , and AI cost optimization . Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Rate limits are a cost control · FinOps LLM URL: https://finopsllm.com/research/rate-limits-are-cost-control Rate limits, 429s and tier upgrades Updated September 1, 2026 · first published September 1, 2026 Quick answer: When a service starts returning 429s, the reflex is to treat it as an availability incident: raise the limit, upgrade the tier, add retries, restore throughput. That is sometimes correct. It is also... When a service starts returning 429s, the reflex is to treat it as an availability incident: raise the limit, upgrade the tier, add retries, restore throughput. That is sometimes correct. It is also the mechanism by which a runaway loop turns into a five-figure invoice, because the only thing that was stopping it has just been removed. What a 429 is actually telling you It says the system is trying to spend faster than its allowance. That happens for two very different reasons, and they need opposite responses. Real demand growth — more users, a launch, a seasonal peak — means the limit is genuinely too low and raising it buys real revenue. Runaway behaviour — a retry storm, an agent looping, a backfill nobody throttled, a test suite pointed at production keys — means the limit is doing exactly its job. The two are indistinguishable from the error rate alone. They are trivially distinguishable if you look at cost per unit of work: real growth holds the ratio roughly constant while volume rises; a runaway breaks it, spending far more per completed task than yesterday. That single ratio should gate every tier upgrade. Retries make it worse, quietly Naive retry on 429 without exponential backoff and jitter converts one limit breach into a synchronised storm. The requests that succeed are billed; many of the ones that fail have still consumed input processing. And because retries are usually implemented in a client library rather than application code, the amplification does not appear anywhere in the feature's design docs. Use limits deliberately Set your own limits below the provider's, per environment and per feature, so the first thing to break is yours and you control what happens next. Keep non-production strictly capped — a failed test build is cheap, a capped customer path is not. Alert on the cost-per-task ratio, not just on error counts. And when you do upgrade a tier, treat it as a spending decision with a named owner, because that is what it is. Related Retry loop hidden spend LLM cost attribution Token budget implementation Related Retry loop hidden spend LLM cost attribution Token budget implementation Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Re-embedding your corpus recurs · FinOps LLM URL: https://finopsllm.com/research/re-embedding-is-recurring The recurring cost of embeddings and vector stores Updated September 1, 2026 · first published September 1, 2026 Quick answer: Embedding cost gets approved as a project line: a corpus of a few million documents, a one-time run, a number that looks small next to generation spend. Then it never stops, because three separate... Embedding cost gets approved as a project line: a corpus of a few million documents, a one-time run, a number that looks small next to generation spend. Then it never stops, because three separate forces re-embed things you already paid to embed. The three refresh drivers Content churn is the honest one and the smallest. Documents change, new ones arrive, deleted ones need removing. It scales with your business and it is straightforwardly forecastable. Chunking and pipeline changes are the sneaky one. Every adjustment to chunk size, overlap, metadata or preprocessing invalidates every vector in the store . A retrieval-quality experiment that sounds like a config tweak is a full re-embed of the entire corpus, and teams run several of these in a good quarter. Model changes are the big one. Embedding spaces are not compatible across models, so adopting a better or cheaper embedding model means re-embedding everything before you can query anything. There is no incremental path and no partial migration — you run both stores in parallel or you take an outage. The store is its own line Vectors also cost to keep. Managed vector databases charge for storage and for the compute serving queries, and dimensionality drives both: a higher-dimensional model that is marginally better at retrieval can be materially more expensive to host forever. That tradeoff is usually made by whoever picked the model, on quality grounds alone, with no view of the hosting bill. Budget it as an annuity Forecast a full corpus re-embed at least once a year and treat it as scheduled, not exceptional. Price a candidate embedding model on re-embed cost plus a year of storage and query serving , not on the per-token rate. Keep the raw source content addressable so a re-embed is a batch job rather than a re-ingestion project — and run those jobs through a batch endpoint, since a full re-embed is the most latency-tolerant workload you own and therefore the one where batch pricing pays best. Related RAG cost optimization Batch API FinOps Long context vs RAG cost Related RAG cost optimization Batch API FinOps Long context vs RAG cost Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Real cost per task: Opus 5.5 vs Sol, Astra and Fable · FinOps LLM URL: https://finopsllm.com/research/real-cost-per-task-frontier-models Real cost per task across frontier models Updated September 22, 2026 · first published September 22, 2026 List prices tell you what a token costs. They do not tell you what a finished task costs, because models spend very different numbers of tokens to finish the same work. This page puts measured cost per task and a quality score side by side for Claude Opus 5.5, Claude Opus 5, Claude Fable 5.1, GPT-6 Astra and GPT-6 Sol at every effort level. Every figure has a source, and nothing is estimated. The short answer: GPT-6 Sol is the cheapest way to reach any score up to 47.5. Above 47.5, Opus 5.5 is the cheapest at every level. No setting of GPT-6 Astra above low, Opus 5 or Fable 5.1 is cost-efficient: each one is beaten on both score and price by some setting of Sol or Opus 5.5. Method All scores and costs come from the Artificial Analysis Intelligence Index v4.3.2, read on 22 September 2026. The index runs ten evaluations: AA-Briefcase, GDPval-AA, AutomationBench-AA, Terminal-Bench 4.0, SciCode, Humanity's Last Exam, GDP.pdf, CritPt, AA-Omniscience and AA-LCR. Artificial Analysis runs each model at each effort setting through the provider API and records what it pays at list prices. Cost per task is that spend per task, split into input and output. The same suite runs for every row, so the rows compare directly. Two limits apply before you read the numbers. First, the index is one task mix. Your mix will shift the costs, which is why the last section explains how to measure your own. Second, scores from different index versions do not compare, so do not mix these figures with older published numbers. The full ladder: 26 settings Output tokens per task are the tokens the model writes, including reasoning. Artificial Analysis does not publish the input and output split for the four middle GPT-6 Sol settings, so those cells say n/a. Model Effort Intelligence Index Cost per task Input cost Output cost Output tokens per task On the frontier GPT-6 Sol none 28.1 $0.33 $0.28 $0.05 4,900 No GPT-6 Sol low 33.9 $0.13 n/a n/a 3,400 Yes GPT-6 Sol medium (default) 39.8 $0.25 n/a n/a 6,500 Yes GPT-6 Sol high 42.8 $0.37 n/a n/a 10,200 Yes GPT-6 Sol xhigh 44.1 $0.53 n/a n/a 16,000 Yes GPT-6 Sol max 47.5 $1.06 $0.74 $0.31 31,200 Yes GPT-6 Astra low 45.8 $0.82 $0.60 $0.22 4,400 Yes GPT-6 Astra medium 49.6 $1.54 $1.06 $0.48 9,600 No GPT-6 Astra high 50.9 $1.73 $1.13 $0.59 11,800 No GPT-6 Astra xhigh 52.4 $2.31 $1.46 $0.85 16,900 No GPT-6 Astra max 52.7 $3.26 $1.90 $1.36 27,200 No Claude Opus 5 low 39.4 $1.10 $0.73 $0.37 14,700 No Claude Opus 5 medium 44.8 $2.19 $1.47 $0.72 29,000 No Claude Opus 5 high (default) 48.1 $3.61 $2.46 $1.16 46,200 No Claude Opus 5 xhigh 49.7 $4.88 $3.36 $1.52 60,700 No Claude Opus 5 max 50.8 $5.86 $4.05 $1.81 72,500 No Claude Opus 5.5 low 42.3 $0.55 $0.35 $0.20 10,200 No Claude Opus 5.5 medium (default) 51.2 $1.34 $0.82 $0.51 25,700 Yes Claude Opus 5.5 high 53.6 $1.82 $1.11 $0.71 35,600 Yes Claude Opus 5.5 xhigh 56.0 $3.46 $2.15 $1.31 65,700 Yes Claude Opus 5.5 max 57.6 $5.98 $3.60 $2.38 119,200 Yes Claude Fable 5.1 low 46.8 $2.37 $1.30 $1.08 21,600 No Claude Fable 5.1 medium 48.9 $2.98 $1.59 $1.39 27,900 No Claude Fable 5.1 high 51.2 $3.91 $2.01 $1.90 38,100 No Claude Fable 5.1 xhigh 53.2 $5.98 $2.96 $3.02 60,500 No Claude Fable 5.1 max 53.4 $7.63 $3.73 $3.90 78,100 No On the frontier means that no other setting in this table scores higher for less money. The cost frontier Ten of the 26 settings are on the frontier. Sorted by cost, they are the only settings worth considering on price alone. Everything else pays more for the same score or less. Setting Intelligence Index Cost per task Per 10,000 tasks GPT-6 Sol · low 33.9 $0.13 $1,300 GPT-6 Sol · medium 39.8 $0.25 $2,500 GPT-6 Sol · high 42.8 $0.37 $3,700 GPT-6 Sol · xhigh 44.1 $0.53 $5,300 GPT-6 Astra · low 45.8 $0.82 $8,200 GPT-6 Sol · max 47.5 $1.06 $10,600 Claude Opus 5.5 · medium 51.2 $1.34 $13,400 Claude Opus 5.5 · high 53.6 $1.82 $18,200 Claude Opus 5.5 · xhigh 56.0 $3.46 $34,600 Claude Opus 5.5 · max 57.6 $5.98 $59,800 The frontier has two regions. From $0.13 to $1.06 it is almost all GPT-6 Sol, with GPT-6 Astra low as the one exception at $0.82. From $1.34 up it is Opus 5.5 only. The step between the two regions is small: Opus 5.5 medium scores 3.7 points more than Sol max for $0.28 more per task. Head to head at equal or better score These pairs compare a cheaper setting with a dearer setting that scores the same or lower. Cheaper setting Dearer setting Score gap Cost saved Opus 5.5 medium: 51.2, $1.34 Opus 5 high: 48.1, $3.61 +3.1 for Opus 5.5 63% Opus 5.5 medium: 51.2, $1.34 Opus 5 max: 50.8, $5.86 +0.4 for Opus 5.5 77% Opus 5.5 medium: 51.2, $1.34 Fable 5.1 high: 51.2, $3.91 tie 66% Opus 5.5 high: 53.6, $1.82 GPT-6 Astra max: 52.7, $3.26 +0.9 for Opus 5.5 44% Opus 5.5 high: 53.6, $1.82 Fable 5.1 max: 53.4, $7.63 +0.2 for Opus 5.5 76% GPT-6 Sol max: 47.5, $1.06 Opus 5 high: 48.1, $3.61 +0.6 for Opus 5 71% The Opus 5 row matters for teams that have not migrated yet. Opus 5 ran at high effort by default. Opus 5.5 runs at medium by default, and at that default it scores 3.1 points more for 63% less per task. Anthropic says Opus 5.5 is 40% cheaper than Opus 5; the measured gap on this index is wider than the claim. Where the money goes: input, not output Across every model, input is between about half and three quarters of the cost per task. For Opus 5.5 at medium, $0.82 of the $1.34 is input, which is 61%. For GPT-6 Astra at max it is 58%, for GPT-6 Sol at max 70%, and for Fable 5.1 at max 49%. Agent tasks re-send their growing context on every step, so input spend grows with the number of steps, not just with the length of the answer. This is why GPT-6 Sol at no reasoning costs more than at low: $0.33 against $0.13, even though it writes only 4,900 output tokens. $0.28 of the $0.33 is input. The likely cause is more steps, each one re-sending context. Turning reasoning off does not make an agent cheaper when the agent then needs more turns. For your bill, this means caching matters as much as the model choice. Opus 5.5 and GPT-6 Sol both charge $0.20 per million cached input tokens. GPT-6 Astra charges $1.00 and Opus 5 charges $0.50. Token volume against list price GPT-6 Astra is the most token-efficient model here. At max effort it writes 27,200 output tokens per task, against 119,200 for Opus 5.5 at max. But Astra charges $10 and $50 per million, 2.5× the Opus 5.5 rate. The list price wins: Opus 5.5 high costs $1.82 per task and scores 53.6, while Astra max costs $3.26 and scores 52.7. Opus 5.5 at max is the one place where verbosity bites. Its 119,200 output tokens cost $2.38 before any input, and the full task costs $5.98. That buys the highest score in the table, 57.6, but it is 4.5× the cost of medium. Diminishing returns by effort Each row shows what one step up in effort buys, as index points against extra cost per task. Model medium → high xhigh → max GPT-6 Sol +3.0 points for +48% +3.4 points for +100% GPT-6 Astra +1.3 points for +12% +0.3 points for +41% Claude Opus 5 +3.3 points for +65% +1.1 points for +20% Claude Opus 5.5 +2.4 points for +36% +1.6 points for +73% Claude Fable 5.1 +2.3 points for +31% +0.2 points for +28% For Fable 5.1 and GPT-6 Astra, max effort buys almost nothing: 0.2 and 0.3 points for 28% and 41% more. For Opus 5.5 the step to max still buys 1.6 points, but at 73% more cost. Use max only on tasks where you have measured that the extra points change the outcome. When GPT-6 Sol max is enough The index is an average, and the gap between Sol max and Opus 5.5 medium is not even across it. Per-evaluation scores from Artificial Analysis: Evaluation Opus 5.5 medium ($1.34) GPT-6 Sol max ($1.06) Terminal-Bench 4.0 52.5 43.9 AutomationBench-AA 61.2 61.6 GDPval-AA (Elo) 1576 1487 AA-Briefcase (Elo) 1642 1483 Humanity's Last Exam 54.7 47.9 SciCode 59.3 57.6 CritPt 27.7 30.9 AA-LCR 84.3 83.7 On AutomationBench and CritPt, GPT-6 Sol matches or beats Opus 5.5 at medium for $1.06 per task against $1.34. On Terminal-Bench, the knowledge-work evaluations and Humanity's Last Exam, Opus 5.5 leads by a wide margin. Workflow automation can run on Sol. Terminal and coding agents and document-heavy knowledge work are where Opus 5.5 earns its price. Vendor claims against independent numbers Vendor figures and independent figures often differ, because they use different harnesses and settings. Anthropic reports 66.4% on Terminal-Bench 4.0 for Opus 5.5 at xhigh. Artificial Analysis measures 59.6% at the same effort. Effort Opus 5.5 Fable 5.1 low 31.3% 40.4% medium 52.5% 44.9% high 56.6% 52.0% xhigh 59.6% 55.1% max 59.6% 52.0% The ranking can also change with the index. On the Vals AI Index, Fable 5.1 is first at 68.83%, GPT-6 Astra third at 66.61% and Opus 5.5 fourth at 66.16%. Cost per task is not published there on the same basis, so it does not move the frontier above. It is a reminder that one index is one view. List prices and a cache-heavy task Digital Applied priced one cache-heavy agent task on each model: 8M cache-read tokens, 400K uncached input, 600K cache-write tokens and 300K output tokens. The result follows the frontier, with one extra penalty for GPT-6 Astra. Model Input $/MTok Output $/MTok Cache read $/MTok Cache-heavy task (Digital Applied) GPT-6 Sol $2.00 $10.00 $0.20 $6.90 Claude Opus 5.5 $4.00 $20.00 $0.20 $12.20 Claude Opus 5 $5.00 $25.00 $0.50 $17.25 Claude Fable 5.1 $10.00 $50.00 $0.25 $28.50 GPT-6 Astra (≤272K) $10.00 $50.00 $1.00 $34.50 GPT-6 Astra (>272K) $20.00 $75.00 n/a $61.50 GPT-6 Astra bills the whole request at $20 and $75 per million once input passes 272K tokens. Opus 5.5 keeps one price across its 1M-token window. Opus 5.5 cache writes cost $5 per million for the 5-minute cache and $8 for the 1-hour cache, batch jobs are billed at 50%, and fast mode doubles the price. For the details, see the Claude Opus 5.5 cost model and Opus 5.5 fast mode economics . How to measure your own cost per task Log tokens per task, not per request: uncached input, cached input, cache writes and output, summed over every step of the task. Take a sample of a few hundred real tasks and replay it on two or three candidate settings, for example Sol max, Opus 5.5 medium and Opus 5.5 high. Grade each result with the same check you use in production, and count the tasks that pass. Divide total spend by passed tasks. Cost per successful task is the number to compare, because a cheap setting that fails more often is not cheap. Pick the cheapest setting that clears your quality bar, then route only the tasks that fail to a higher setting. Re-run the replay when a price or a default effort changes. For how effort settings change the bill on one model, see Opus 5.5 effort levels are the real price . Caveats All costs are at list API prices on the Artificial Analysis task mix. Discounts, batch pricing and your own caching change them. Artificial Analysis labels its Opus 5.5 and Fable 5.1 entries Default Fallback. Check its methodology notes before treating every row as the same API configuration. Scores are from index v4.3.2 only. Earlier versions used different evaluations and do not compare. The Digital Applied cache-heavy task is one illustrative workload, not a measurement. Numbers change when providers change prices or defaults. The read date is 22 September 2026. Sources Artificial Analysis Intelligence Index Artificial Analysis: Claude Opus 5.5 Artificial Analysis: Claude Opus 5 Artificial Analysis: Claude Fable 5.1 Artificial Analysis: GPT-6 Astra Artificial Analysis: GPT-6 Sol Digital Applied: GPT-6 Sol vs Claude Opus 5.5 cost benchmarks Digital Applied: Claude Opus 5.5 vs GPT-6 Astra Digital Applied: Is Claude Fable 5.1 still worth it? Digital Applied: Claude Opus 5.5 launch pricing and benchmarks Digital Applied: Opus 5.5 vs Grok 4.7 vs Muse Spark 1.3 cost per task Related Claude Opus 5.5 cost model Opus 5.5 effort levels are the real price Opus 5.5 fast mode economics Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Real-SWE: What a Resolved Issue Actually Costs · FinOps LLM URL: https://finopsllm.com/research/real-swe-benchmark-cost-per-issue Real-SWE cost per resolved issue Updated September 27, 2026 · first published September 27, 2026 Real-SWE landed on 12 September 2026 and picked up 275 points and 158 comments on Hacker News. The premise is the part most cost models get wrong: benchmark suites are public, memorised, and unrepresentative of the code your agents actually touch. Real-SWE runs models against private, real-world enterprise repositories. Why the cost number matters more than the score A public benchmark gives you a pass rate. It does not give you a cost. Cost per resolved issue needs three things at once: Pass rate on the hard, private tasks. Tokens consumed per attempt , including the failures. Attempt count — did the model need a retry, a plan revision, a diff-and-rethink loop? Multiply those and you get the only figure that maps to a line item. A model that scores 4 points below the leader but resolves issues in one attempt at a third of the tokens is cheaper per resolved issue, and on a real backlog that difference compounds faster than the score gap suggests. Why public benchmarks overstate quality Enterprise codebases have the properties that break public benchmark assumptions: long internal conventions, undocumented invariants, tests that encode historical accidents, and build systems nobody fully understands. A model that pattern-matches a public repo cannot pattern-match a 400-file monorepo with three years of accreted decisions. That is why a widely discussed result this month was a 27B open-weights creative-writing model performing at Fable 5 level at a reported 40x cheaper price — open weights start from a local-repository prior that API models lack. Running the calculation Take a real backend repo where 40 issues are in scope. Say the cheaper model resolves 22 in one attempt at 60K input / 8K output, and the premium model resolves 26 with a 1.4x retry multiplier at 90K input / 14K output. At Opus 5.5 rates ($4/$20, cache reads $0.20): Model Resolved Cost per issue Total Cheap tier 22 $0.32 $7.04 Premium tier 26 $0.61 $15.86 Premium costs 2.3x the total for 18% more resolved issues. On a 40-issue backlog that is $9 more. The same trade at 4,000 issues/month is $880 — and still only buys 18% more throughput. The cheaper tier is not obviously wrong; you are trading resolution rate for volume, and the right answer depends on whether a missed issue costs more than a dollar. What to instrument Cost per resolved issue , not per attempt. The denominator is merged PRs, not requests. Retry multiplier per model. A model at 1.4x is a third of its list price before you count anything else. Tokens per accepted diff , including plan and self-review tokens the diff never shows. Human review minutes . A 12% cheaper model that takes 20% longer to review is more expensive. Bottom line Public benchmarks rank capability on tasks that do not resemble your backlog. Real-SWE is an early attempt at the honest version. Until you run it on your own repos, treat every model comparison as a cost-per-resolved-issue hypothesis and price the hypothesis with your own token counts. Related Real cost per task: frontier models Cost per successful task Heavy agentic coding cost: Claude vs Qwen Evals cost control Pricing an open-weight model Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Reasoning Model Cost Guide · FinOps LLM URL: https://finopsllm.com/research/reasoning-model-cost-guide Reasoning Model Cost Guide Updated 12 July 2026 · first published 4 July 2026 Reasoning models like o3, o4-mini, DeepSeek-R1, QwQ, and MiMo generate internal "thinking" tokens before producing output. This hidden cost can inflate your bill 5-30x. This guide breaks down when reasoning models are worth the premium and when a standard model is the smarter spend. 5-30x Cost multiplier 8 Models compared 4 Providers Jul 2026 Last updated All prices in USD per 1 million tokens Reasoning token counts vary by task complexity Thinking tokens are billed as output tokens What are "thinking" tokens? Reasoning models spend tokens on internal chain-of-thought before answering. A simple question might trigger 2,000 thinking tokens; a complex coding task can produce 30,000+. These tokens are invisible in the API response but billed at output rates - often the most expensive tier. Methodology Standard pricing Output token price for normal (non-reasoning) completion, from official provider pages. Reasoning pricing Effective cost including thinking tokens. Measured as standard output price × average thinking multiplier for each model. Thinking multiplier Average ratio of total billed tokens to visible output tokens across coding, math, and analysis benchmarks. Best use cases Tasks where reasoning models demonstrably outperform standard models by enough to justify the cost premium. Reasoning Model Pricing Table Model ↕ Provider ↕ Standard Output $/1M ↕ Reasoning Output $/1M ↕ Multiplier ↕ Best Use Cases Claude Fable 5 Anthropic $50.00 $200.00 4x Frontier reasoning, complex software vulnerabilities, deep analysis Claude Opus 4.8 Anthropic $25.00 $100.00 4x Frontier reasoning, complex analysis, agentic workflows GPT-5.6-Sol OpenAI $30.00 $120.00 4x Frontier reasoning, complex code, math, multi-step analysis GPT-5.6-Terra OpenAI $15.00 $60.00 4x Reasoning, code generation, structured analysis Grok 4.5 xAI $6.00 $24.00 4x Math, reasoning, general intelligence o3 OpenAI $8.00 $40.00 5x Complex coding, math proofs, deep reasoning o4-mini OpenAI $4.40 $17.60 4x Cost-sensitive reasoning, coding, analysis DeepSeek R1 DeepSeek $2.19 $8.76 4x Math, code, reasoning, Chinese-language tasks Claude Sonnet 5 Anthropic $10.00 $40.00 4x General reasoning, coding, analysis (balanced) GPT-5.5 (standard) OpenAI $30.00 $30.00 1x General chat, coding, complex analysis Reasoning Output $/1M includes thinking tokens billed at output rates. Multiplier is average across typical tasks; actual multiplier varies by prompt complexity. DeepSeek R1 and QwQ output thinking tokens by default. OpenAI o3/o4-mini charge thinking tokens separately from visible output. Gemini 2.5 Pro charges "thinking tokens" at a reduced rate vs visible output - multiplier is effective blended cost. Some links may include referral codes. When to Use Reasoning Models 1) Multi-step coding and debugging Reasoning models excel at tasks requiring planning: refactoring across multiple files, debugging complex state, or writing algorithms with edge cases. The thinking tokens let the model "work through" the problem rather than pattern-match. Worth the 4-5x premium when the alternative is a human spending 30+ minutes. 2) Mathematical and logical proofs Tasks requiring formal reasoning - proofs, optimisation problems, constraint satisfaction - see the biggest quality jump. Standard models often produce plausible-but-wrong answers; reasoning models self-verify. The cost premium is justified when correctness matters more than speed. 3) Complex data analysis with multiple steps Analysing a dataset with conditional logic, cross-referencing multiple sources, or building multi-step pipelines benefits from chain-of-thought. A standard model might miss a step; a reasoning model works through each explicitly. When to Skip Reasoning Models 1) Simple extraction and formatting Pulling data from documents, reformatting JSON, summarising text, or translating content. These tasks need pattern matching, not reasoning. Using o3 for extraction is like hiring a mathematician to sort mail - expensive and unnecessary. 2) High-volume, low-complexity workloads Content generation, FAQ answers, basic chatbot responses, and data labelling. At 10M+ tokens/month, the 4-5x reasoning multiplier adds up fast. A standard model at $10/1M output beats a reasoning model at $40-60/1M for tasks where quality is "good enough." 3) Latency-sensitive applications Reasoning models take longer - thinking tokens add 2-10 seconds of latency. For real-time chat, interactive tools, or user-facing responses where speed matters, standard models deliver faster at lower cost. Cost Optimisation Strategies Route by complexity Use a cheap standard model (GPT-4o-mini, Gemini Flash) as a router. If the task is simple, answer directly. If complex, escalate to a reasoning model. This "cascade" pattern can cut reasoning-model usage by 60-80% while preserving quality where it matters. Limit thinking budget Some providers (OpenAI, Google) let you set a maximum thinking token budget per request. Capping at 4,000-8,000 thinking tokens prevents runaway costs on tasks that don't need deep reasoning. Start tight and increase only when quality drops. Cache your prompts If your reasoning tasks share a common system prompt or context (codebase, documentation), prompt caching can reduce input costs by 50-90%. This doesn't reduce thinking tokens but lowers the overall per-request cost significantly. Batch non-urgent reasoning For evaluations, test generation, or analysis that tolerates latency, batch APIs offer 50% discounts. Combined with reasoning models, you get the quality benefit at half the output cost. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is the methodology? Output token price for normal (non-reasoning) completion, from official provider pages. Reasoning pricingEffective cost including thinking tokens. Measured as standard output price × average thinking multiplier for each model. What do reasoning models cost per million tokens? Reasoning Output $/1M includes thinking tokens billed at output rates. Multiplier is average across typical tasks; actual multiplier varies by prompt complexity. DeepSeek R1 and QwQ output thinking tokens by default. OpenAI o3/o4-mini charge thinking tokens separately from visible output. When to Use Reasoning Models? Reasoning models excel at tasks requiring planning: refactoring across multiple files, debugging complex state, or writing algorithms with edge cases. The thinking tokens let the model "work through" the problem rather than pattern-match. When to Skip Reasoning Models? Pulling data from documents, reformatting JSON, summarising text, or translating content. These tasks need pattern matching, not reasoning. Using o3 for extraction is like hiring a mathematician to sort mail - expensive and unnecessary. Which cost optimisation strategies work best? Use a cheap standard model (GPT-4o-mini, Gemini Flash) as a router. If the task is simple, answer directly. If complex, escalate to a reasoning model. This "cascade" pattern can cut reasoning-model usage by 60-80% while preserving quality where it matters. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Reasoning token attribution and chargeback · FinOps LLM URL: https://finopsllm.com/research/reasoning-token-attribution Reasoning token attribution and chargeback Updated 21 May 2026 · first published 21 May 2026 Reasoning tokens are the line item nobody owns. They are billed as output, they never appear in a response payload, and most internal attribution systems were designed before they existed. The result is a growing slice of LLM spend that lands in a shared bucket labeled "model cost" with no owner attached. For a FinOps function that is supposed to allocate every dollar back to a product, a team, or a customer, that bucket is the problem. This page is about pulling reasoning tokens out of it. The attribution gap Most LLM cost allocation pipelines were wired up in the era of input plus visible output. A request enters, a response leaves, both have token counts, both can be tagged with an endpoint, a tenant, or a feature flag. Reasoning tokens break that model in a specific way: they are counted by the provider, charged at the output rate, and attached to the same request, but they correspond to no visible artifact your application can label. The cost is real, the unit of work is invisible, and the join key your warehouse expects is missing. If you do nothing, reasoning cost gets pooled. It either inflates the "shared platform" cost center, or it gets smeared proportionally across all traffic, which silently overcharges the cheap endpoints and undercharges the expensive ones. Neither of those is FinOps. Both of them quietly distort the unit economics that product teams use to make pricing and roadmap decisions. What a reasoning-aware attribution model looks like The fix starts at ingest. The usage record for every request should carry reasoning tokens as a first-class field, separate from visible output tokens, with its own cost line. Most provider APIs already return a reasoning token count in usage metadata. The mistake is collapsing it into a single output-tokens column on the way to the warehouse. Keep the columns separate. Price them separately. Roll them up separately. From there, the standard FinOps dimensions still apply. Tag each request with the endpoint, the owning team, the product surface, the customer or tenant, and the deploy version. The tag set is the same one you already use for visible tokens. The only new requirement is that reasoning tokens get the same tags applied at the same time, so the attribution chain is unbroken from invoice down to a feature owner. Chargeback that survives a finance review A chargeback model is only useful if a team can look at their slice and recognize their behavior. For reasoning tokens, that means the chargeback report should answer three questions on its own. Which endpoints generated reasoning tokens this period. How many reasoning tokens each endpoint generated per request, at p50 and p90. What share of the team's total LLM cost was reasoning, separate from visible output and input. When that breakout exists, the conversation with the product team becomes specific. Instead of "your LLM cost went up," it becomes "your reasoning share doubled after the agent feature shipped, and the median request now spends three times more invisible output than visible output." That is a discussable number. It points at a real code change, a real router decision, and a real owner. The undiscussable version is a shared bucket. Showback before chargeback If reasoning tokens have not been attributed before, do not jump straight to billing internal teams. Run a showback period first. Publish the per-team reasoning share, let owners see the new line item alongside their other costs, and give them a quarter to adjust routing and prompts. Hard chargeback works only when teams have had time to understand what they are being charged for and have a lever to change it. Routing as a FinOps policy Once attribution is in place, the next question is who gets to use reasoning models at all. In most organizations this has been an engineering decision made request by request, framed as "should this call go to the reasoning model for quality." The FinOps reframe is different. Reasoning capacity is a budget, and routing is the policy that decides who spends it. Policy questions look like this. Which product surfaces are valuable enough to justify reasoning by default. Which endpoints should never use a reasoning model, no matter what the developer requested. Which customers have paid for a tier that includes reasoning depth, and which have not. The right place for these answers is not a code comment. It is a routing policy that the platform team owns, the FinOps team reviews, and product owners can read. That policy should be enforced at the gateway, not at the call site. If the decision lives in product code, every team writes their own version, every version drifts, and the FinOps function loses its only lever. If the decision lives in a shared router, the policy is auditable, the overrides are logged, and the cost of every exception is attributable to the team that requested it. Hard budgets per endpoint Soft budgets do not survive contact with a long agent loop. The agent does not know what your monthly target is. It will spend reasoning tokens until the task succeeds, the timeout fires, or the provider returns an error. If the only guardrail is a Slack alert when spend crosses a threshold, the threshold will be crossed faster than the alert can be acted on. Hard budgets are the FinOps complement to attribution. Each endpoint gets a ceiling on reasoning tokens per request, per session, and per day. The ceiling is enforced before the call leaves the gateway. A request that would exceed it either falls back to a non-reasoning model, returns a degraded response, or fails closed with a clear error that the calling team can handle. The ceiling is a number a product owner can set, not a number an SRE has to guess. What to put in the ceiling Maximum reasoning tokens per request, separate from maximum output tokens. Maximum reasoning spend per session for stateful agents, so a single user cannot run away with the budget. Daily reasoning spend per endpoint, with automatic fallback to a smaller model when crossed. Per-tenant overrides for customers on tiers that have explicitly purchased deeper reasoning. An on-call exception path that requires a named approver and an expiry date. Operational signals worth tracking Attribution and budgets are the structural fixes. Day to day, FinOps needs a small set of signals that surface reasoning behavior before it becomes a surprise on the invoice. Reasoning token share of total output, by endpoint, week over week. Reasoning tokens per request at p50, p90, and p99, segmented by feature and deploy version. The ratio of reasoning to visible output, because a request whose invisible work outweighs its visible work by an order of magnitude is usually a routing miss. Pair those with deploy markers. A reasoning share that jumps after a release is almost always a router change, a new agent step, or a prompt that the model now decides to think harder about. The signal is only useful if you can tie it back to the change that caused it. Where this fits in the broader FinOps loop Reasoning token attribution is not a separate program. It plugs into the same loop FinOps already runs for the rest of LLM spend. Inform, by giving every team a clean view of their reasoning share. Optimize, by tightening routing policy and prompt design where the share is too high for the value delivered. Operate, by enforcing hard budgets and reviewing exceptions on a regular cadence. The reason reasoning tokens need their own page is not that the loop is different. It is that they were invisible to the loop until recently, and an invisible cost cannot be governed. The teams that get this right early avoid the failure mode that ends most FinOps conversations about reasoning models. They do not end up arguing about whether reasoning is worth it in the abstract. They argue, instead, about which specific endpoints and customers should keep their reasoning budget when the next quarter's plan tightens. That is a much better argument to be having. Related LLM token tracking for FinOps teams LLM cost attribution by team, product, and customer LLM cost anomaly detection LLM budget governance and policy Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is the attribution gap? Most LLM cost allocation pipelines were wired up in the era of input plus visible output. A request enters, a response leaves, both have token counts, both can be tagged with an endpoint, a tenant, or a feature flag. What a reasoning-aware attribution model looks like? The fix starts at ingest. The usage record for every request should carry reasoning tokens as a first-class field, separate from visible output tokens, with its own cost line. Most provider APIs already return a reasoning token count in usage metadata. What makes a chargeback model survive a finance review? A chargeback model is only useful if a team can look at their slice and recognize their behavior. For reasoning tokens, that means the chargeback report should answer three questions on its own. Which endpoints generated reasoning tokens this period. How does model routing work as a FinOps policy? Once attribution is in place, the next question is who gets to use reasoning models at all. In most organizations this has been an engineering decision made request by request, framed as "should this call go to the reasoning model for quality." The FinOps reframe is different. Why do agents need hard budgets per endpoint? Soft budgets do not survive contact with a long agent loop. The agent does not know what your monthly target is. It will spend reasoning tokens until the task succeeds, the timeout fires, or the provider returns an error. Which operational signals are worth tracking? Attribution and budgets are the structural fixes. Day to day, FinOps needs a small set of signals that surface reasoning behavior before it becomes a surprise on the invoice. Reasoning token share of total output, by endpoint, week over week. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # The same model costs more in your region · FinOps LLM URL: https://finopsllm.com/research/regional-pricing-premium Regional and residency pricing premiums Updated September 1, 2026 · first published September 1, 2026 Quick answer: The rate card you budgeted from is usually the US rate. Route the same request through a European or Asian endpoint, or pin it to a region for residency reasons, and the number can change —... The rate card you budgeted from is usually the US rate. Route the same request through a European or Asian endpoint, or pin it to a region for residency reasons, and the number can change — sometimes on the token price, more often on everything around it. Where the premium actually comes from Rarely a single line item. It accumulates from four places. Regional token pricing differs on some platforms and not others, so the answer is provider-specific and worth checking rather than assuming. Model availability lags outside the primary region, which means the region that has your data may only offer an older, more expensive-per-unit-of-quality model. Cross-region egress and latency add real cost when your application and your inference endpoint are not co-located. And reduced feature coverage — batch pricing, caching, or a particular server tool missing in a region — removes the discounts you had assumed, which is usually the largest effect of the four. That last one is the one that bites. A workload designed around prompt caching and batch pricing, then moved to a region where one of them is unavailable, does not cost a few percent more. It costs what it would have cost without the optimisation, which can be several times the plan. Decide it, do not inherit it Residency is frequently a real obligation, and when it is, the premium is simply the price of operating legally. The failure mode is not paying it — it is paying it for workloads that never needed it. Split traffic by what the data actually is. Requests carrying personal or regulated data go to the compliant region and carry its cost. Everything else — internal tooling, evaluation runs, synthetic and public-data workloads, most agent scaffolding — has no residency requirement and should run wherever it is cheapest and best-featured. Teams that never make this split apply the strictest requirement in the company to 100% of traffic, which is the most expensive possible reading of a policy that was written for a subset of it. What to check before committing to a region Confirm the token price for that region, which models are actually available there, whether caching and batch pricing apply, and which server tools are supported. Then tag the region on every request in telemetry, so the cost of the residency decision is a number you can see rather than an assumption folded into the total. Related LLM cost attribution Prompt caching economics Batch API FinOps Related LLM cost attribution Prompt caching economics Batch API FinOps Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # The retry loop that quietly adds to inference spend · FinOps LLM URL: https://finopsllm.com/research/retry-loop-hidden-spend The retry loop that quietly adds to inference spend Updated August 27, 2026 · first published August 27, 2026 Quick answer: A retry is not free resilience. It is another model call, and an agent can turn one transient error into five paid attempts before anyone sees a failure. The first control is to measure retry tax:... A retry is not free resilience. It is another model call, and an agent can turn one transient error into five paid attempts before anyone sees a failure. The first control is to measure retry tax: retry and fallback spend divided by total inference spend, segmented by workflow and failure reason. Count the whole attempt tree Log the parent request, attempt number, provider, model, tool call, latency, error class, tokens, and final outcome. A request ID alone is insufficient when a tool call triggers a nested model request. Record parent-child relationships so one user task can be reconstructed as a tree. Separate useful from wasteful retries Retrying a rate limit may recover a valuable task. Retrying a validation error with the same prompt usually buys another identical failure. A provider timeout, malformed tool input, context overflow, and quality rejection need different policies. Assign each failure class a maximum attempt count and an escalation path. Set budgets at the loop boundary Use a per-request token ceiling, a per-workflow dollar ceiling, and a maximum wall-clock duration. A soft ceiling can route the next attempt to a smaller model; a hard ceiling stops the loop and returns a recoverable state. Do not rely on a monthly alert to control a request that can spend its budget in seconds. Review the tax with quality A low retry rate is not automatically good if the first attempt fails more often. Track successful-task cost, completion rate, latency, and retry tax together. Fix the largest dollars first: duplicate tool calls, oversized context on retries, fallback chains that repeat the same capability, or validators that reject answers without changing the prompt. The durable fix is not “disable retries.” It is making every extra attempt visible, bounded, and justified by a measurable improvement in outcome. Related Agent spend guardrails LLM cost monitoring Cost per successful task Related Agent spend guardrails LLM cost monitoring Cost per successful task Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # SaaS AI credits: metering a unit you do not control · FinOps LLM URL: https://finopsllm.com/research/saas-ai-credits-metering SaaS AI credits: metering a unit you do not control Updated September 2, 2026 · first published September 2, 2026 Quick answer: Cloud FinOps assumes the unit of consumption is legible: an instance-hour, a request, a gigabyte. A vendor AI credit is not that. It is a unit the vendor defines, prices, and can redefine mid-term.... Cloud FinOps assumes the unit of consumption is legible: an instance-hour, a request, a gigabyte. A vendor AI credit is not that. It is a unit the vendor defines, prices, and can redefine mid-term. The spend behaves like consumption while giving you none of the tooling that makes consumption manageable. Three properties that break the usual playbook The unit is opaque. Two features can burn wildly different credit counts for what a user experiences as the same action, and the mapping is rarely published. The rate is not yours. Overage is priced by the vendor, so the usual lever of moving work to a cheaper path does not exist. Allowances expire. Per-seat allowances that neither pool nor roll over mean you can be paying overage on one team while another team's allowance goes unused. Meter it anyway Pull consumption from the vendor's admin API on a schedule and store it alongside your own cost data, keyed by user, team, and feature. Where no API exists, an exported usage report on a fixed cadence is enough to start. The point is a time series you own, because the vendor's dashboard shows the current period and your questions are all about the trend. Allocate before the invoice, not after Map credits to the same cost centres you use for cloud, and publish showback monthly. Unallocated vendor AI spend defaults to the IT or platform budget, which is the one team that cannot influence how much of it gets consumed. Allocation is what turns a surprise into a conversation with the team that caused it. Cap what you can, alert on the rest Prefer an administrative cap in the vendor's own console — it is the only control that stops spend before it is incurred. Where the vendor offers no cap, set a threshold alert against your own metering at a level that still leaves time to act, and name an owner per team rather than routing every alert to a shared channel. Feed it back into the renewal Twelve months of your own metering is the strongest position available at renewal: it lets you argue pooling, rollover, and a capped overage rate from measured usage instead of from the vendor's projection. Start metering at the beginning of the term, not in the quarter before it ends. Related Shadow AI on corporate cards Committed spend discounts Rate limits are cost control Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Semantic cache economics · FinOps LLM URL: https://finopsllm.com/research/semantic-cache-economics Semantic cache economics Updated 21 May 2026 · first published 21 May 2026 Most semantic-cache write-ups treat the cache as an engineering optimization: stand up pgvector, pick a similarity threshold, ship. From a FinOps seat the picture is different. A semantic cache is a shared cost center that taxes every request, returns savings unevenly across teams, and quietly changes the unit economics of every workload that flows through it. If you do not model it that way, the platform team absorbs the embedding spend, a handful of high-hit-rate features take the savings, and nobody can explain why blended cost-per-call moved. This page lays out the economic model: how to compute cost-per-lookup, how to allocate the embedding tax fairly, how to use hit rate as a chargeback input, and how to decide when the cache is no longer worth running for a given team. The implementation choices - vector store, threshold tuning, scoping rules - are covered elsewhere. Here the question is who pays, who benefits, and what shows up on the invoice. Cost-per-lookup as the primary metric Total cache spend is the wrong number to watch. The cache lives or dies on cost-per-lookup, which has three components: the embedding call on the incoming request, the vector-store query, and the amortized write cost of populating the cache in the first place. For a workload using a small embedding model at roughly two cents per million tokens, an average request of 400 tokens costs around 0.0008 cents to embed. Add the vector lookup and the bookkeeping, and a typical lookup lands in the small fractions of a cent. That sounds negligible until you compare it to the saved frontier call. A cached hit avoids a model invocation worth anywhere from one to twenty cents depending on the model and the response length. The break-even hit rate is whatever ratio makes embedding-plus-lookup cost equal expected savings. For most stacks that floor sits somewhere between two and five percent. Below that, the cache is taxing everyone to subsidize a tiny number of hits. Above it, every additional point of hit rate is pure margin. The single most useful FinOps view is cost-per-lookup plotted against hit rate per endpoint, refreshed weekly. It exposes endpoints that are paying the embedding tax with nothing to show for it, and it gives you a defensible line for cutting cache scope when a workload drifts. The embedding tax and how to allocate it The embedding cost is the awkward part of cache accounting. It is incurred on every request, including misses. If the platform team pays for it out of a shared budget, three things go wrong. Teams that contribute the most miss traffic look free on the cost dashboard. Teams that benefit from high hit rates also look free, because their savings show up as the absence of model spend rather than as cache revenue. And the platform team carries a growing line item whose owner is nominally everyone, which in practice means no one defends it during budget reviews. A workable allocation has three pieces. First, embed cost is allocated to the requesting workload at the moment of the lookup, the same way model tokens are. Second, the vector store cost is split by share of stored entries, refreshed monthly so a team that has not written anything new for a quarter stops paying for prior tenants' rows. Third, savings from hits are credited back to the workload that hit, so the dashboard shows net cache contribution per team rather than gross spend. The accounting trick is that this only works if the gateway tags every embed call and every lookup with the same workload identifier the rest of your pipeline uses. If the cache is upstream of your tagging, it is invisible to chargeback, and you will spend months arguing about whether the cache "really" saves money. Hit rate as a chargeback input Hit rate is the variable that turns the cache from infrastructure into a finance instrument. A workload running at sixty percent hit rate is paying roughly forty percent of its uncached cost plus a tiny embedding tax. A workload at five percent hit rate is paying ninety-five percent of its uncached cost plus the same tax. Both numbers belong on the chargeback statement. The statement that resonates with engineering leaders looks like this: this feature spent X dollars on model calls, Y dollars on cache infrastructure, and avoided Z dollars in model calls due to the cache. Net contribution from the cache: Z minus Y. When that number is positive and large, the team is a sponsor of the cache and will defend it. When it is negative, the team should either improve hit rate, scope the cache differently, or drop out of the shared cache and have its embedding tax refunded. Reporting this way also exposes a quieter problem: workloads that hit the cache heavily can erode the unit economics of the workloads that do not. If a high-hit-rate feature subsidizes the embedding tax for a low-hit-rate feature on the same shared backend, the low-hit-rate feature looks cheaper than it actually is. Per-workload chargeback unwinds that subsidy and forces a real decision about whether the cache scope is correct. When the embedding overhead stops being worth it Every cache has a population of workloads for which it is a tax with no return. The signals are blunt and easy to read once the accounting is in place. Hit rate sits under the break-even line for two consecutive weeks. Net cache contribution is negative on the chargeback. Cache writes outpace reads, meaning the workload is filling the store faster than it is querying it. Or the embedding spend for that workload exceeds five to ten percent of its total model spend, a rough ceiling above which the cache is no longer an optimization but a parallel cost surface. When those signals fire, the right move is rarely to tune the threshold. It is to remove the workload from the cache, return the embedding budget to the team, and let them decide whether to rejoin once their traffic pattern changes. Workloads that produce long, fresh, low-repetition output - document analysis, code generation on private repositories, single-shot agentic plans - almost never recover. Workloads with a long tail of duplicated questions, stable retrieval contexts, or classification flows usually do. The discipline is to make this a calendared review rather than a one-off cleanup. A quarterly cache review, owned by FinOps and signed off by the platform team, prevents the cache from accumulating dead tenants that quietly drag cost-per-lookup upward for everyone still on it. Threshold changes are budget changes Similarity threshold is usually treated as a quality knob. It is also a budget knob. Loosening the threshold raises hit rate and lowers cache cost-per-lookup for the workloads that match more broadly, while raising the risk of bad answers that downstream teams may not feel until later. Tightening the threshold improves precision but moves spend back into the model column. From an attribution standpoint, any threshold change should be logged with the cost impact it is expected to produce. A move from 0.95 to 0.92 on a customer-support endpoint is worth a dollar number, not just a quality note. Recording that estimate alongside the change gives finance a way to reconcile next month's invoice against the engineering decisions that drove it, which is the heart of useful LLM FinOps. Cache cost is real cost The shorthand version of this page: treat the semantic cache as a cost center with its own P&L. Allocate the embedding tax at the lookup, credit savings to the workload that hit, expose net contribution per team on the chargeback, and review the tenant list on a calendar. Cache infrastructure that is not allocated this way drifts into the platform budget, gets defended on vibes, and is the first thing cut when costs rise - which is the opposite of what the FinOps function should produce. Related LLM cost attribution LLM chargeback and showback LLM token tracking LLM cost anomaly detection Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ Why is cost-per-lookup the primary cache metric? Total cache spend is the wrong number to watch. The cache lives or dies on cost-per-lookup, which has three components: the embedding call on the incoming request, the vector-store query, and the amortized write cost of populating the cache in the first place. What is the embedding tax and how to allocate it? The embedding cost is the awkward part of cache accounting. It is incurred on every request, including misses. If the platform team pays for it out of a shared budget, three things go wrong. Teams that contribute the most miss traffic look free on the cost dashboard. How does cache hit rate feed chargeback? Hit rate is the variable that turns the cache from infrastructure into a finance instrument. A workload running at sixty percent hit rate is paying roughly forty percent of its uncached cost plus a tiny embedding tax. When the embedding overhead stops being worth it? Every cache has a population of workloads for which it is a tax with no return. The signals are blunt and easy to read once the accounting is in place. Hit rate sits under the break-even line for two consecutive weeks. Net cache contribution is negative on the chargeback. Why is the similarity threshold a budget knob? Similarity threshold is usually treated as a quality knob. It is also a budget knob. Loosening the threshold raises hit rate and lowers cache cost-per-lookup for the workloads that match more broadly, while raising the risk of bad answers that downstream teams may not feel until later. Should a semantic cache be treated as a cost center? The shorthand version of this page: treat the semantic cache as a cost center with its own P&L. Allocate the embedding tax at the lookup, credit savings to the workload that hit, expose net contribution per team on the chargeback, and review the tenant list on a calendar. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Server tools bill outside the token meter · FinOps LLM URL: https://finopsllm.com/research/server-tools-are-a-separate-invoice Server tools are a separate invoice Updated September 1, 2026 · first published September 1, 2026 Quick answer: Most LLM cost models have one meter: tokens in, tokens out, price per million. That model was correct when the only thing a request did was generate text. It stopped being correct the moment... Most LLM cost models have one meter: tokens in, tokens out, price per million. That model was correct when the only thing a request did was generate text. It stopped being correct the moment server-side tools arrived. Web search, web fetch and code execution run on the provider's infrastructure, and several of them carry their own per-use charge on top of the tokens they produce. A single agent turn can therefore bill you twice: once for the searches it ran, and again for the tokens those results added to the context. The compounding part The second charge is the one people miss. Every tool result gets appended to the conversation, and every subsequent turn re-sends the whole thing as input. Ten searches early in a long agent run are not ten charges — they are ten charges plus their result payloads re-read on every turn that follows. This is why agent costs feel non-linear when the token math says they should be linear. The per-use fee is the visible part; the context growth it causes is the larger part, and it lands in your input-token line where nothing labels it as tool-driven. Attribute it or you cannot manage it Log tool invocations per request alongside the usage object: which tool, how many calls, and the token size of what each result added. That last field is the one that makes the compounding visible, and it is the one nobody records by default. Then compute cost per agent run, not cost per API call. A run is what a user actually triggered; an API call is one of the twenty things that run happened to do. Any budget or unit-economics number attached to the call rather than the run will be wrong in the direction that flatters you. Three controls that actually work Cap the tool calls per run. A hard limit on searches or fetches per user request bounds both charges at once. Most workloads that hit a limit of ten were looping, not researching. Truncate what enters the context. You rarely need a whole fetched page. Summarising or trimming a result before it is appended cuts every downstream turn, not just the current one. Cache the stable prefix. If the system prompt and tool definitions are constant across a run — and they usually are — prompt caching removes the largest repeated cost the tools created. Check your provider's current rate card before modelling any of this: which tools charge per use, and at what rate, differs by tool and changes over time. The structural point holds regardless — the token meter is no longer the whole bill. Related Prompt caching economics Cost per request as a KPI LLM cost attribution Related Prompt caching economics Cost per request as a KPI LLM cost attribution Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Shadow AI is on a corporate card · FinOps LLM URL: https://finopsllm.com/research/shadow-ai-corporate-cards Finding the AI spend outside your API bill Updated September 1, 2026 · first published September 1, 2026 Quick answer: Most organisations measure AI cost by opening the provider console. That number is real, it is well instrumented, and in a lot of companies it is the smaller half of the total. The other half is on... Most organisations measure AI cost by opening the provider console. That number is real, it is well instrumented, and in a lot of companies it is the smaller half of the total. The other half is on expense reports: individual subscriptions bought by people who needed a tool and had a card. Why it is invisible to platform teams It never touches your API keys, your gateway or your telemetry. It arrives as a per-seat charge on a corporate card, coded to software or occasionally to office expenses, in amounts small enough to clear approval automatically. Two hundred people at twenty to thirty dollars a month is a six-figure annual line that no engineering dashboard will ever display. And this is not a story about rule-breaking. It is what functioning employees do when a tool is useful and procurement takes six weeks. What it actually costs you The direct overspend is the least interesting part. Individual plans are priced well above negotiated enterprise rates for the same product, and paying twice for the same vendor — once through a team agreement, once through scattered personal seats — is common. Multiple tools that do the same job proliferate because nobody is comparing them. The harder costs are elsewhere. Consumer tiers carry different data-retention and training terms than the enterprise agreement your legal team actually reviewed, so business data ends up under terms nobody signed off. There is no SSO, so access does not end when employment does. And you cannot forecast, negotiate volume, or make a build-versus-buy decision about spend you cannot see. How to find it Ask finance, not engineering. Search card and expense data for the known vendor names, then for the pattern itself: recurring charges between roughly ten and fifty dollars, monthly, to software-adjacent merchants. Cross-reference SSO and IdP logs for applications nobody formally onboarded. Then respond by making the sanctioned path easier than the card, not by banning the card. Enforcement without a fast alternative produces the same spend with worse visibility. A team plan that people can join today, with the enterprise terms and SSO attached, converts shadow spend into negotiated spend and usually pays for itself on the seat consolidation alone. Related LLM cost attribution Invoice reconciliation LLM purchasing guide Related LLM cost attribution Invoice reconciliation LLM purchasing guide Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Why Showback Comes Before Chargeback in FinOps · FinOps LLM URL: https://finopsllm.com/research/showback-comes-first-chargeback Why showback comes before chargeback Updated 1 August 2026 The most common mistake in FinOps cost allocation is moving to chargeback too early. Leaders see rising cloud or AI bills, want immediate accountability, and transfer budget ownership before the data is ready. The result is angry teams, disputed invoices, and a backlog of exceptions. The better path is to start with showback, fix the data, and only then introduce chargeback for the services teams can control. Showback is the proving ground Showback reports costs to business units without moving the budget. That sounds softer than chargeback, but it serves a harder purpose: it proves whether your allocation data is good enough to be trusted. If a team disputes a showback report, the cost is still hypothetical. If the same dispute happens under chargeback, the cost is real and the relationship is damaged. During the showback phase you should answer these questions: Can we tag every resource to a team, feature, and environment? Do teams agree with how shared costs are split? Are the dashboards clear enough that non-technical managers can act on them? Do we understand which costs are controllable and which are not? The migration timeline Most successful FinOps programs follow a three-stage timeline: Month 0–1: visibility. Collect usage and cost data, build initial reports, and identify the largest spenders. Month 2–4: showback. Distribute monthly reports, collect feedback, and refine allocation rules. Month 5+: hybrid chargeback. Move controllable services to chargeback while keeping shared or uncertain costs in showback. This timeline varies by organization size and data quality, but the sequence rarely changes. Visibility must precede accountability. What showback fixes before chargeback begins Showback surfaces problems that would explode under chargeback. These include: Tagging gaps. Untagged resources show up as "shared" or "unknown," which teams will reject if billed to them. Shared service disputes. Platform teams and product teams often disagree on how to split foundation-model costs. Seasonality. Month-one charges may not reflect normal usage, making budgets impossible to set. Behavioral surprises. Teams may not realize how much their experiments cost until they see the report. Fixing these under showback is collaborative. Fixing them under chargeback is adversarial. Signals that chargeback is ready You are ready to introduce chargeback when: Less than five percent of allocated cost is disputed or unknown. Teams have had at least two months to act on showback reports. Finance has agreed on how charged-back costs flow into team budgets. You can identify services where teams have clear optimization levers. Leadership is prepared to enforce the model rather than grant exceptions. The best chargeback rollout is narrow. Start with one or two services that have clean attribution and controllable usage. Expand only after the first wave is accepted. Hybrid is the destination, not a compromise Pure chargeback is rare. Most mature organizations use chargeback for direct, controllable consumption and showback for shared platforms, research, and exploratory AI work. This hybrid model gives teams accountability where it makes sense and visibility where allocation is unfair or impossible. Related Chargeback vs showback — side-by-side comparison. IT chargeback and showback for AI — applying the model to AI spend. LLM chargeback and showback — technical implementation. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ Why should showback come before chargeback? Showback comes first because it builds trust in the data and surfaces allocation problems before anyone's budget is at risk. Chargeback introduced too early creates political friction and exceptions. How long should showback run before chargeback? Most organizations run showback for one to two quarters. This is enough time to clean tagging, validate allocation rules, and train teams to act on cost reports. What signals tell you chargeback is ready? Chargeback is ready when allocation data is trusted, teams understand their cost drivers, leadership supports budget transfer, and the most controllable services are clearly identified. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Showback vs Chargeback: Which Model Fits Your Team? · FinOps LLM URL: https://finopsllm.com/research/showback-vs-chargeback Showback vs chargeback Cloud and AI spend are too large to hide in a central IT budget. The question is not whether to allocate costs, but how. Showback and chargeback are the two main models. The right choice depends on your organization's maturity, data quality, and appetite for budget ownership. Showback: visibility without billing Showback reports costs to business units but leaves the budget with central IT. Engineering sees its $50,000 monthly cloud bill, but IT still pays the provider. The goal is to make teams aware of their footprint and nudge them toward better behavior. Showback works best when: Cost allocation data is new or untrusted. Teams are not yet ready to own a cloud budget. Shared services make precise billing difficult. The priority is cultural change, not budget transfer. Chargeback: budget ownership at the edge Chargeback moves the budget to the business unit. Engineering's $50,000 cloud bill is deducted from engineering's budget. The team now has both the data and the incentive to optimize. Chargeback works best when: Tagging and attribution are clean and trusted. Teams can control the workloads that drive cost. Leadership wants autonomous cost optimization. There is enough FinOps expertise to support teams. Comparison at a glance Factor Showback Chargeback Budget owner Central IT Business unit Incentive to optimize Moderate High Implementation effort Low High Political friction Low Moderate to high Best for Building awareness Driving ownership The usual migration path Most organizations start with showback, mature their tagging and reporting, then introduce chargeback for the most controllable services. AI and LLM workloads are often good candidates for early chargeback because usage is directly tied to product features and teams can influence it through model choice, caching, and routing. For more on implementation, read IT chargeback and showback and LLM chargeback and showback . For the CFO angle on budget ownership and governance, see AI chargeback and showback for CFOs . Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is the difference between showback and chargeback? Showback reports technology costs to business units without billing them. Chargeback bills business units directly for the technology they consume. Showback creates visibility; chargeback creates budget accountability. Is showback or chargeback better for cloud costs? Showback is better when an organization needs to build cost awareness first. Chargeback is better when teams are mature enough to own and optimize their own cloud budgets. Many organizations start with showback and later move to chargeback. Can you use showback and chargeback together? Yes. A hybrid model uses showback for shared or hard-to-allocate platform costs and chargeback for services that teams can directly control, such as compute instances or LLM API usage. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Silent Model Downgrades Break Your Cost Model · FinOps LLM URL: https://finopsllm.com/research/silent-model-downgrades-break-your-cost-model Silent model downgrades and cost models Updated September 27, 2026 · first published September 27, 2026 On 23 September 2026, an r/GroundTruthAINews thread pointed out a footnote buried in Anthropic's Opus 5.5 launch notes: an Opus 5.5 request may be served by Opus 4.8 . Anthropic and OpenAI both shipped price cuts the same afternoon. Both labs sold the same idea: keep the capability, spend far less. The footnote is the part that matters to FinOps. What actually happened Claude Opus 5.5 launched at $4/$20 per million tokens, roughly 20% under Opus 5, with cache reads cut 60% to $0.20. Anthropic says fewer tokens per task and 30% faster output make typical workloads about 40% cheaper. Roughly 90 minutes later OpenAI shipped GPT-6 Sol at $2/$10 and Luna at $0.10/$0.50, both half the GPT-5.6 prices. Every launch post from this period carries the same kind of footnote: the endpoint you call is an alias , and the alias is load-balanced across model versions during a transition window. That is a normal capacity practice. It is also a cost-modeling problem. Why it breaks the numbers Cost per task drifts. Your forecast assumed Opus 5.5 output pricing. If a share of calls land on 4.8, both the unit price and the token count move, in opposite directions. Evals measure a mixture. An eval suite run during a transition window scores a blend of versions. The score is not reproducible later. Price cuts get attributed wrongly. If a 40% saving shows up as 15%, the gap is usually version mixing, not a broken optimization. Latency baselines go stale. 4.8 is not as fast as 5.5. Any p50 you captured mid-transition is not your steady-state p50. How to detect the swap Every major provider returns the resolved model in the response body. Log it. One field, four lines of code: resolved = response.model # e.g. "claude-opus-4-8-20260115" assert resolved.startswith(EXPECTED_PREFIX) or resolved in ALLOWED_FALLBACKS Then split every cost metric by resolved model, not by the model you asked for. The moment one bucket starts drifting, you have your answer: the alias is mixing versions and your per-task cost is a weighted average of two different products. The budget implication During a transition, plan against the blended cost, not the headline. If 20% of calls drop to an older model, your effective input rate is not $4.00 per million — it is whatever the mix produces. The same logic applies to the headline saving: the 40% cheaper claim is a typical-workload average, which already assumes a token-count reduction that may not hold if the cheaper-but-older model is the one generating the longer answers. Rules to hold Never model on an alias. Pin a dated model ID for anything you budget or evaluate. Log the resolved model on every request. Non-negotiable if you ever re-run an eval. Re-baseline after the transition window. Usual duration is weeks, not quarters, but confirm. Price a transition as a mixture. Ask your provider for the expected split, or measure it. Bottom line A price cut and a silent downgrade can land in the same afternoon. The cut is the headline; the downgrade is the footnote that quietly invalidates last month's forecast. Log the resolved model, pin dated IDs, and price the mixture. Related Claude Opus 5.5 cost model GPT-6 pricing: Sol, Luna, Astra Model price cuts and routing budgets Provider prices are not comparable Evals cost control Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Sonnet 5.5 pricing: the $2/$10 rate and real task cost · FinOps LLM URL: https://finopsllm.com/research/sonnet-5-5-pricing-agent-cost-model Claude Sonnet 5.5 pricing: what changes, what does not Updated September 28, 2026 · first published September 27, 2026 Claude Sonnet 5.5 costs $2 per million input tokens and $10 per million output tokens on the Anthropic API, the same list price as Sonnet 5. The economic change is efficiency: Anthropic says Sonnet 5.5 can cost up to 30% less per task because it uses fewer tokens, while generating output more than 30% faster. That is a vendor-reported maximum, not a guaranteed discount on every workload. For a budget forecast, keep the token rates fixed and model the possible reduction in tokens and agent steps separately. Measure your own task mix before applying any savings assumption. Sonnet 5.5 API prices Token type Price per million Input $2.00 Output $10.00 5-minute cache write $2.50 1-hour cache write $4.00 Cache read $0.20 Anthropic lists these rates in its Sonnet 5.5 launch announcement . Do not interpret “up to 30% less per task” as a 30% reduction in per-token rates: the input and output prices are unchanged from Sonnet 5. Sonnet 5's $2/$10 price is also now standard, after Anthropic cancelled its planned September increase. Example: token efficiency versus rate changes Consider a task that uses 100,000 input tokens and 10,000 output tokens, without caching. At Sonnet 5.5's published rates, that is $0.20 for input plus $0.10 for output, or $0.30 per task . If the same task used 30% fewer tokens in both categories, its modeled cost would be $0.21. This is an illustration of the arithmetic, not a promise that every task will use 30% fewer tokens. For a workload of 10,000 such tasks per month, the baseline is $3,000. A 30% reduction in token volume would save $900, taking the modeled monthly bill to $2,100. Actual results vary with prompt length, cache reuse, output length, reasoning effort, retries, and tool calls. What the launch benchmarks do and do not show Anthropic reports gains on its coding and knowledge-work evaluations, including Terminal-Bench 4.0 and CursorBench. The company also reports that Sonnet 5.5 generates output more than 30% faster than Sonnet 5, and that in several benchmark comparisons it reaches previous Sonnet 5 scores at a fraction of the per-task cost. Those results are useful hypotheses for an evaluation plan, but they are vendor-published measurements rather than independent production cost data. One practical caveat: a faster model does not automatically lower a token-metered API bill. The bill falls when usage per completed task falls, or when fewer tasks need retries or escalation. Faster generation may instead improve throughput or reduce latency while leaving token spend unchanged. A safe way to forecast adoption Keep the rate card constant. Use $2/$10 per million input/output tokens as the starting point for Sonnet 5 and 5.5. Measure completed work. Compare cost per accepted task, not only tokens per request. Include retries, tool calls, and human rework where you can. Split by workload. Evaluate coding, support, extraction, and long-context tasks separately; a single blended savings rate can hide regressions. Use a range. Budget with 0% savings until internal tests provide evidence, then add measured scenarios. Treat Anthropic's “up to 30%” as an upper bound claim, not your forecast. Recheck quality and latency. A lower token bill is not a saving if acceptance drops or more expensive fallback models are needed. FAQ Did Sonnet 5.5 get cheaper per token? No. Anthropic lists the same $2 input and $10 output per million token rates as Sonnet 5. Its cost-per-task claim comes from using fewer tokens to do comparable work. Is 30% savings guaranteed? No. Anthropic describes cost reductions of up to 30% for most work in its launch materials. Your result depends on workload, prompt caching, effort settings, and task completion quality. What does a cached request cost? Anthropic lists cache reads at $0.20 per million tokens, 5-minute writes at $2.50, and 1-hour writes at $4.00. Check the current Claude API pricing documentation before committing a forecast. Should we switch production traffic immediately? Run a representative evaluation first. Shadow or canary the model, compare cost per accepted result and latency, and keep a rollback route for workloads that regress. Sources and related reading Anthropic: Introducing Claude Sonnet 5.5 Anthropic API pricing documentation Claude Opus 5.5 cost model Related Claude Opus 5.5 cost model Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Sonnet 5 pricing: September increase cancelled · FinOps LLM URL: https://finopsllm.com/research/sonnet-5-intro-pricing-deadline Claude Sonnet 5 pricing: the September increase was cancelled Originally published 19 July 2026 · Updated 28 September 2026 Correction: Anthropic cancelled the planned September 1, 2026 price increase. Sonnet 5 did not move to $3/$15. Its standard public API rates remain $2 per million input tokens and $10 per million output tokens. The earlier deadline and price-rise analysis on this page has been removed because that scenario did not happen. Anthropic's Sonnet 5 launch announcement was updated on August 10 to make the introductory $2/$10 price permanent. The current Claude API pricing documentation lists the same rates. Any forecast that assumed a September increase should be corrected rather than carried forward as a cost event. Current Sonnet rates Model Input per 1M tokens Output per 1M tokens Cache read Claude Sonnet 5 $2.00 $10.00 $0.20 Claude Sonnet 5.5 $2.00 $10.00 $0.20 Anthropic's September 28 Sonnet 5.5 announcement lists the same base rates as Sonnet 5, plus $2.50 per million for 5-minute cache writes and $4.00 for 1-hour cache writes. Check the pricing page before procurement or production forecasts, since provider pricing can change. What Sonnet 5.5 changes for the cost model Sonnet 5.5 does not lower the published per-token price. Anthropic says the model generates output more than 30% faster and can cost up to 30% less per task for most work because it uses fewer tokens. Treat that as a launch claim and test it against your own workload. Faster output can reduce latency without reducing a token-metered bill; lower spend requires lower token use, fewer retries, or fewer escalations. For each workload, track cost per accepted result, not just cost per request. Include input/output tokens, cache writes and reads, retries, tool calls, and any fallback to another model. Keep quality and human review rates in the comparison so a cheaper but less reliable run does not appear to be a saving. Recommended forecast update Remove the planned 50% Sonnet 5 rate increase from September and Q4 scenarios. Keep Sonnet 5.5 at the same per-token rate in the base case as Sonnet 5. Use a separate sensitivity case for reduced tokens per task; do not assume Anthropic's maximum 30% saving applies uniformly. Benchmark representative tasks and update the sensitivity with measured cost per accepted result. For launch details and an example task-cost model, read Sonnet 5.5 pricing: the $2/$10 rate and real task cost and the Sonnet 5.5 model-routing guide . Back to research FAQ Did Claude Sonnet 5's price increase happen on September 1, 2026? No. Anthropic cancelled the planned increase. Sonnet 5 remains $2 per million input tokens and $10 per million output tokens. Does Sonnet 5.5 have a lower API rate than Sonnet 5? No. Sonnet 5.5 launched at the same listed $2 input and $10 output per million tokens. Anthropic says it can use fewer tokens per task, lowering cost per task by up to 30% for most work. What should I change in my budget? Remove the cancelled September price increase from forecasts. Model Sonnet 5.5 savings only after representative tests establish cost per accepted task for your workloads. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # State of FinOps 2026: 98% now manage AI spend · FinOps LLM URL: https://finopsllm.com/research/state-of-finops-2026-ai-spend State of FinOps 2026: 98% now manage AI spend Published 15 August 2026 The FinOps Foundation's State of FinOps 2026 survey covered 1,192 practitioners representing more than $83B in annual cloud spend. The headline number: 98% now manage AI spend, up from 63% in 2025 and 31% in 2024. In two years AI cost management went from a minority specialism to something practically every FinOps team owns. The adoption curve Year Practitioners managing AI spend 2024 31% 2025 63% 2026 98% Roughly a doubling, then a saturation. There is nowhere left for that line to go, which makes 2026 the last year the interesting question is whether teams manage AI spend. From here the question is how well. And "manage" is doing heavy lifting in that 98%. It counts everyone who has been handed the problem, including the large share who have a monthly bill, a rough split by provider, and no idea which feature caused which line. Adoption is universal. Capability is not. Do not read the number as maturity. FinOps is no longer a public-cloud discipline The survey's scope numbers make the point better than the AI ones do: 90% manage SaaS spend 64% manage licensing 57% manage private cloud 48% manage data center FinOps in 2026 is a technology-spend discipline that happens to have started in public cloud. AI is the fastest-moving line inside it, and it crosses every one of those categories at once: an AI feature can bill as API usage, as a SaaS seat, as a licence, and as reserved GPU capacity in the same month. That is precisely why it resists the tooling built for any single category. The most-requested capability does not exist yet The finding worth the most attention is not the 98%. It is this: granular AI spend monitoring - tokens, LLM requests, GPU utilization - is the single most-requested capability in the entire survey. Not most-requested among AI capabilities. Most-requested, full stop. A capability at the top of a request list of 1,192 practitioners is a capability the market has not delivered. Vendors have shipped AI cost dashboards; what they have not shipped is allocation at the granularity that makes a dashboard actionable. The reason is structural, not lazy: Provider invoices arrive pre-aggregated. A monthly total per key or per project cannot be decomposed into features after the fact. If the request did not carry a tag when it was made, the information is gone. The unit is not stable. Input, output, cached, and reasoning tokens price differently and the ratios shift every time you change a model. See token types explained . GPU utilization and token spend are different accounting systems that have to be reconciled by hand to produce one number for one workload. A vendor can solve dashboards from billing exports alone. Nobody can solve allocation without instrumentation inside your request path. What it means that nobody has shipped it The practical consequence: the visibility layer is yours to build for at least another cycle. Teams waiting for a procurement decision to solve token allocation will spend 2026 without token allocation. The good news is that the build is smaller than the wait. The instrumentation that produces granular AI cost is a gateway tagging contract plus a monthly reconciliation, and it is a matter of weeks: Route every model call through one gateway. Everything below depends on this and nothing else does. Require four tags on every request: feature, environment, team, customer or tenant. Reject untagged traffic in staging first, then production. See cost attribution . Log token counts by type, not just totals. Input, output, cached, reasoning. See reasoning token attribution . Reconcile to the provider invoice monthly. An unreconciled internal number is a guess with a decimal point. See invoice reconciliation . Publish one unit-economic metric - cost per request, per ticket, per active user. See cost per request as a KPI . Emit the tags using OpenTelemetry GenAI semantic conventions rather than a private schema. When tooling does catch up, the conventions are what it will read. The skills signal: value, not cost The top skillset FinOps teams say they are hiring for is AI value management . That is a different job from cost reduction, and the difference shows up in what gets asked in the meeting. Cost reduction answers "why is this so expensive." Value management answers "what did the spend produce, and would we buy it again at this price." You cannot answer the second question with a cost dashboard. It needs a denominator - tickets resolved, PRs merged, deals sourced - attached to the same tag the cost was attributed to. Which is the same instrumentation as above, used for a better question. This is also the gap the Tokenomics Foundation was launched to standardize, and its first workstreams are aimed squarely at it. What to take from this if you own AI spend Being in the 98% is table stakes and not a position. The peer group is everyone now. Differentiation is granularity. Do not buy on the promise of token-level allocation. Ask any vendor how they attribute a request that was made without tags. There is no good answer, which tells you the tagging is yours regardless of what you buy. Instrument before you optimize. Optimization on unattributed spend is guessing which knob moved the total. See the six levers once attribution is in place. Budget in consumption as well as dollars. Unit prices keep falling while bills rise; a dollar budget hides the volume growth that actually explains the invoice. See cost trends 2025-2026 . Related What is LLM FinOps? - the discipline this survey measures. What is the Tokenomics Foundation? - the standards body aimed at the value gap. What is LLM cost attribution? - the capability nobody shipped. Cost per request as a KPI - the first unit metric to publish. How to budget for AI spend - what to do with the numbers once you have them. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What percentage of FinOps teams manage AI spend in 2026? 98%, according to the FinOps Foundation's State of FinOps 2026 survey of 1,192 practitioners representing over $83B in annual cloud spend. That is up from 63% in 2025 and 31% in 2024 - effectively universal adoption in two years. What is the most-requested FinOps capability in 2026? Granular AI spend monitoring: visibility into tokens, LLM requests, and GPU utilization at a level that supports allocation. It is the single most-requested capability in the entire survey, which means commercial tooling has not delivered it at the scale practitioners need. What does FinOps cover besides public cloud in 2026? 90% of respondents manage SaaS spend, 64% licensing, 57% private cloud, and 48% data center. FinOps in 2026 is a technology-spend discipline, not a public-cloud discipline, and AI spend is the fastest-moving part of it. What skillset are FinOps teams hiring for in 2026? AI value management is the number-one skillset sought. The demand has moved past cost reduction toward proving that AI spend produced business value - which requires unit economics, not just a cost dashboard. Why does the tooling gap matter? Because it means the visibility layer is yours to build for at least another cycle. Teams waiting for a vendor to ship token-level allocation will spend 2026 without allocation. The instrumentation is a gateway tagging contract plus reconciliation, and it is buildable in weeks. Is 98% adoption the same as 98% maturity? No. Managing AI spend counts anyone who has been handed the problem. Most of those teams have a bill and a rough split, not per-feature allocation or a cost-per-outcome metric. Adoption is universal; capability is not. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # The free anonymous model is a pricing weapon · FinOps LLM URL: https://finopsllm.com/research/stealth-model-free-tokens-playbook The stealth-model free-token playbook Updated September 1, 2026 · first published September 1, 2026 Quick answer: Ox Alpha appeared on the routing aggregators as an unbranded endpoint, free, no rate card, no lab attached. Then it was confirmed as GLM-5.3 and the free window closed. GLM-5.3-Flash now lists at... Ox Alpha appeared on the routing aggregators as an unbranded endpoint, free, no rate card, no lab attached. Then it was confirmed as GLM-5.3 and the free window closed. GLM-5.3-Flash now lists at $0.15 per million input tokens and $0.50 per million output. Treat this as a repeatable play, because it is one. It has run before under other names, and it will run again. What matters for your bill is what you did during the free window and what happens the moment it ends. What the lab buys with free tokens Three things, all of them cheaper than the alternatives. Blind evaluation: an unbranded endpoint gets judged on output rather than on the logo, which is the only honest read a lab can get on a frontier model. Distribution: the aggregators route real traffic to it immediately, no partnerships required. An anchor: by the time the name is revealed, developers have already decided the model is good, and the published price lands against that impression rather than against a spec sheet. None of that is dishonest. It is just not free for you, and the invoice arrives later than the tokens do. The number that matters when the window closes Sixteen trillion input tokens flowed through the free endpoint. At the now-published $0.15 per million, that is roughly $2.4 million of inference — which is both what the lab spent on the campaign and, more usefully, the size of the step if that same traffic simply stayed where it was. Run that arithmetic on your own share. Take the volume you sent through the anonymous endpoint during the window, multiply by the published rate, and you have your monthly step change. Teams that ran an entire evaluation cycle on free tokens are the ones most likely to be surprised, because the workload that proved the model was also the workload that cost nothing. Three rules for the next one Never depend on an endpoint whose owner you do not know. Anonymous means no rate card, no deprecation policy, no support path, no data-handling commitment you can point at. It is fine for evaluation. It is not fine for a production path with no fallback. Price every free evaluation at a hypothetical rate. Pick a plausible per-million figure before you start — the closest comparable model is fine — and carry the shadow cost in your own telemetry. Then a reveal is a repricing, not a discovery. Assume the free window is the shortest part of the relationship. Six days here. What you should be measuring during it is not just quality but switching cost: how much routing, prompt tuning and evaluation work you would throw away if the published price came in high. Where it leaves the price $0.15 / $0.50 is aggressive against the closed frontier tier and roughly in line with the open-weight hosted market. That is the point of the whole exercise: the reveal is the pricing announcement, and it is designed to land while the model is already in your router. Whether it wins your traffic should be decided by your own cost-per-request numbers on your own workload, measured after the free window closed — not by how good it felt when the tokens were free. Related Provider arbitrage Open source vs closed cost Cost per request as a KPI Related Provider arbitrage Open source vs closed cost Cost per request as a KPI Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Abandoned streaming responses still cost money · FinOps LLM URL: https://finopsllm.com/research/streaming-abandoned-generations-cost Streaming responses and abandoned generations Updated September 9, 2026 · first published September 9, 2026 Quick answer: Streaming makes an AI product feel fast, but it also makes an unfinished response easy to mistake for a cancelled request. A user closes the tab, loses the connection, or presses stop; the provider... Streaming makes an AI product feel fast, but it also makes an unfinished response easy to mistake for a cancelled request. A user closes the tab, loses the connection, or presses stop; the provider may continue generating until the request is cancelled or the output reaches its limit. The visible response is shorter, but the bill is not necessarily shorter. The abandoned tail is a real cost Track three events separately: time to first token, tokens delivered to the client, and tokens generated upstream. The gap between delivered and generated output is the abandoned tail. It represents work the user never received, and it can be large in long-form answers, coding agents, and tool-using workflows. Do not measure this only as a percentage of requests. A small number of abandoned, high-token generations can dominate the waste. Report abandoned output tokens and their cost by feature, model, device, connection type, and cancellation reason. Cancellation has to travel upstream Stopping the browser renderer is not the same as stopping the model request. Propagate the client disconnect or an explicit stop action through your gateway to the provider request. Set a short grace period for reconnects, then cancel. For agent workflows, cancel the active generation and any queued tool work that no longer has a live parent task. Keep an idempotent request identifier so a cancellation race cannot produce duplicate accounting. Record whether the provider confirmed cancellation; otherwise classify the remaining tokens as uncertain spend instead of silently calling them savings. Use a better KPI Cost per request is misleading when many responses are abandoned. Use cost per delivered response and cost per successful task, then show the abandonment rate beside both. A product change that increases time to first token may increase abandonment even when total tokens per request stay flat. Practical controls Emit a cancellation event with request, feature, model, and token counters. Cancel upstream work on disconnect and explicit stop. Cap maximum output for interactive workloads. Compare generated, delivered, and billed tokens during invoice reconciliation. Alert when abandoned-token cost rises faster than successful-task volume. Related LLM cost attribution Agent spend guardrails Retry loop hidden spend Related LLM cost attribution Agent spend guardrails Retry loop hidden spend Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Structured output is not free · FinOps LLM URL: https://finopsllm.com/research/structured-output-token-cost The token cost of JSON mode and schemas Updated September 1, 2026 · first published September 1, 2026 Quick answer: Asking a model for structured output looks like a formatting choice. On the bill it is a volume choice, and it lands in three places at once.The schema is an input cost on every requestA response... Asking a model for structured output looks like a formatting choice. On the bill it is a volume choice, and it lands in three places at once. The schema is an input cost on every request A response format or tool definition is serialised into the request. A modest schema — a dozen fields, descriptions on each, a couple of nested objects — is a few hundred tokens. That is small until you multiply it by every call, on every turn, for the life of the feature. A 400-token schema on a million calls is 400 million input tokens you are paying for in order to describe a shape that never changes. Worse, schemas usually sit after the volatile part of the prompt in naive implementations, which breaks the cached prefix. The schema then costs full price every time and destroys the discount on everything before it. Syntax is an output cost Every brace, quote, comma and field name in the response is a generated token you are billed for at the output rate. Verbose field names are a recurring charge: customer_shipping_address_line_one costs more, forever, than addr1 . Deeply nested objects pay for their own scaffolding. For short answers wrapped in a large envelope, the structure can genuinely exceed the content. Retries are the expensive part Constrained decoding on the major providers makes schema violations rare, but validation failures still happen — a field the model cannot fill honestly, an enum with no right answer, a schema that is ambiguous to a reader. Each failure costs a full retry: all input tokens again, all output tokens again, plus latency. A 2% invalid rate on a high-volume endpoint is a 2% cost increase with nothing to show for it. What to actually do Put the schema in the stable prefix so it caches, and keep it identical across calls. Ask only for fields you consume — extra fields are paid for twice, once in the schema and once in the response. Prefer short field names and flat structures. Where the output is a single value, do not wrap it in an object at all. And measure your validation failure rate: it is the one part of this that is pure waste. Related Prompt caching economics Token budget implementation Retry loop hidden spend Related Prompt caching economics Token budget implementation Retry loop hidden spend Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Stop subagent fan-out from draining token budgets · FinOps LLM URL: https://finopsllm.com/research/subagent-fan-out-concurrency-limits Stop subagent fan-out and recursive delegation from draining token budgets Updated September 19, 2026 · first published September 19, 2026 Quick answer: Subagent fan-out cascades occur when an autonomous orchestrator decomposes a high-level task into parallel sub-tasks and grants worker agents permission to spawn additional specialized workers.... Subagent fan-out cascades occur when an autonomous orchestrator decomposes a high-level task into parallel sub-tasks and grants worker agents permission to spawn additional specialized workers. Without hard concurrency limits and depth bounds, a single ambiguous user prompt can trigger an exponential explosion: 1 root supervisor spawns 6 domain planners, each launching 4 research agents, which invoke further sub-workers. In production architectures, unconstrained recursive delegation routinely burns 2,000,000 to 8,000,000 tokens within 5 minutes, resulting in unexpected $15 to $80 API spikes for a single transaction. The mathematics of recursive agent delegation In a standard tree-based agent framework, task delegation expands according to a branching factor B raised to the execution depth D . If an orchestrator branches at B = 4 and allows subagents to recurse to depth D = 3 , the system schedules 64 independent agent loops. Each leaf agent maintains its own conversational context, performs iterative tool calls, and reports intermediate findings up the hierarchy. Because parent agents aggregate and summarize child outputs, context accumulation compounds quadratically across the execution tree. What is a subagent fan-out cascade in autonomous AI? A subagent fan-out cascade is a failure mode where an orchestrator agent recursively spawns child and grandchild agents without global budget constraints, multiplying token consumption exponentially across parallel execution threads. Four production guardrails for multi-agent fleets Platform teams operating enterprise agent systems prevent runaway cascades by enforcing strict runtime boundaries: Maximum Recursion Depth (Depth Caps): Enforce a strict ceiling on execution hierarchy. In 95% of enterprise use cases, a depth limit of max_depth: 2 (Root Supervisor → Worker Agent) achieves complete task resolution. Prohibit worker agents from spawning tertiary subagents unless specifically exempted by policy. Shared Thread Token Pools: Do not grant subagents independent budget allocations. Allocate a shared token allowance (e.g., 250,000 total tokens) to the root execution thread context. Pass the remaining token balance through trace context headers. When child agents consume tokens, decrement the global pool; if the pool hits zero, all parallel branches terminate immediately. Concurrency Circuit Breakers: Limit active parallel child agent instances to 3–5 concurrent processes. If a supervisor attempts to spawn more concurrent workers than the queue capacity allows, queue the tasks sequentially or reject the split. Distributed Tracing and OTLP Cost Propagation: Inject OpenTelemetry trace IDs and baggage headers across all inter-agent message buses. When OpenLIT or ClickHouse aggregates spend, every child span must roll up into the parent session ID, providing instant visibility into branch-level cost anomalies. How do concurrency limits prevent multi-agent token exhaustion? Concurrency limits throttle the number of simultaneously executing worker loops, preventing parallel API flooding and enabling circuit breakers to abort malfunctioning agent loops before token budgets are exhausted. What is the recommended recursion depth for agent delegation? The recommended recursion depth is 2 levels (Root Orchestrator to Specialized Worker). Deeper hierarchies produce diminishing reasoning returns while dramatically increasing context overhead and error amplification. Related The three agent budgets LLM cost spike runbook Retry loops and hidden spend Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # System One and Jev: Calibration-Based Agent Routing · FinOps LLM URL: https://finopsllm.com/research/system-one-models-jev-calibration-routing System One Models and Jev cost optimization Updated September 27, 2026 · first published September 27, 2026 Announced in September 2026, System One Models and Jev form a calibration-based routing layer for LLM agents. Instead of routing by task type or static rules, Jev routes by calibration : a cheap model (System One) answers first; if its confidence is below threshold, the request escalates to a premium model. For FinOps, this means paying for reasoning only when the cheap model genuinely doesn't know. How it works System One Model (small, fast, cheap) generates an answer + calibrated confidence score. Jev gateway checks: is confidence >= threshold (e.g., 0.9)? If yes: Return System One answer. Cost: ~$0.10/1M tokens. If no: Escalate to premium model (Astra, Opus 5.5, etc.). Cost: $10-50/1M tokens. Cost comparison Strategy Avg cost/task Accuracy Always Astra (max effort) $1.73 50.9 Always Sol $0.28 44.2 Static routing (easy→Sol, hard→Astra) $0.94 48.1 Jev calibration routing (threshold 0.9) $0.41 49.8 Data from Jev benchmarks on Artificial Analysis Intelligence Index. Calibration routing achieves near-Astra accuracy at 24% of the cost. Why calibration beats static routing Static routing misclassifies 15-20% of tasks (easy tasks flagged hard, hard tasks flagged easy). Calibration is self-correcting: the model knows when it doesn't know . Jev's threshold is tunable — raise it for higher accuracy, lower it for lower cost. FinOps implementation Deploy Jev as a gateway: All agent traffic passes through Jev; System One is the default. Set thresholds per workflow: Customer-facing chat = 0.95; background batch = 0.85. Track escalation rate: Target 10-20% escalation. Higher means System One is undertrained; lower means you're overpaying. Budget the premium tier: Cap monthly escalation spend; alert at 80%. Integration with existing agents Jev wraps any OpenAI-compatible endpoint. Existing agents call Jev instead of the model directly. No code changes to agent logic — only the base URL and API key change. Bottom line Calibration-based routing is the first FinOps primitive that optimizes at inference time, not design time. System One + Jev turns "which model?" from a static architecture decision into a dynamic, per-request cost control. Related Jev agent controls and budgets Jev AI FinOps decision economics GPT-6 Astra cost model Model price cuts and routing budgets Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # The three budgets every autonomous agent needs · FinOps LLM URL: https://finopsllm.com/research/three-agent-budgets The three budgets every autonomous agent needs Updated August 27, 2026 · first published August 27, 2026 Quick answer: An autonomous agent needs more than a monthly spending alert. It needs three budgets enforced inside its loop: a request budget for one model call, a workflow budget for the whole task, and a daily... An autonomous agent needs more than a monthly spending alert. It needs three budgets enforced inside its loop: a request budget for one model call, a workflow budget for the whole task, and a daily budget for the owner or tenant. Each catches a different failure mode. 1. Request budget The request budget caps tokens, tool fan-out, latency, or dollars for one attempt. It protects against an oversized context, an unexpectedly long output, or a tool that causes a nested call. Enforce it before the provider request and before each tool dispatch. A soft limit can downshift the model; a hard limit rejects the attempt with an explicit reason. 2. Workflow budget The workflow budget follows one user intent across turns, retries, fallbacks, and subagents. It needs a correlation ID and a running ledger, not a counter local to one process. Stop when the ledger crosses its ceiling, even if every individual request stayed below its limit. This is the control that catches delegation depth and non-converging loops. 3. Daily budget The daily budget limits aggregate spend for a team, tenant, feature, or service account. It is a fairness and blast-radius control. When it is nearly exhausted, route eligible work to batch or smaller models and preserve reserved capacity for high-value workflows. Reset it on a declared timezone and record the reset in the ledger. Make denials useful A budget denial should say which budget fired, how much was consumed, and what recovery is allowed. Return a resumable state, not a silent empty answer. Emit an immutable event for every reservation, spend, release, and denial so finance can reconcile the ledger to provider invoices. Pair budgets with quality Budgets are not permission to degrade every response. Track successful-task cost, completion rate, latency, and user or evaluator quality alongside denials. A budget policy is healthy when it stops runaway work while preserving the quality SLO for the workflows it permits. Three budgets create three boundaries: one attempt, one outcome, and one period. Together they turn an unbounded agent into a system that can be operated and audited. Related Agent spend guardrails LLM budget governance Cost per successful task Related Agent spend guardrails LLM budget governance Cost per successful task Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Token budget implementation · FinOps LLM URL: https://finopsllm.com/research/token-budget-implementation Token budget implementation Updated 21 May 2026 · first published 21 May 2026 A token budget that lives in a spreadsheet but nowhere in the call path is a wish, not a control. Every FinOps program eventually runs into this wall: finance has approved a per-feature envelope, the owning team has agreed to it on paper, and a month later the invoice has overshot by some embarrassing multiple because nothing in the runtime ever read the number. This page is about the unglamorous engineering work that turns a budget line into an enforcement point - where to put it, what it should do when a feature blows through it, and how to report the burn back to the owner in time for them to act. The audience here is the engineer who has been handed a budget by a finance partner and asked to make it stick. The work splits into three concerns: where enforcement lives in the request path, what happens on overrun, and how the owning team sees their position before the month closes. Why budgets fail at the policy layer The most common failure mode is a budget defined in a governance document that no service reads. A team writes down "the contract-redline feature gets ten million tokens per month," circulates it for approval, and never instruments the counter that would actually enforce it. Finance reviews invoices after the fact and discovers the overrun two weeks too late. The fix is not a better policy document. The fix is moving the budget number into a runtime store that the call path consults before every model call, so that the policy and the enforcement are the same artifact. This is also why budgets expressed only in dollars tend to drift. Provider rates change, model mixes change inside a single feature, and the cost-per-call moves underneath the budget. Tokens are the stable unit because the application controls them directly. Dollar conversion belongs in the reporting layer, not in the enforcement layer. Three places to enforce Enforcement has to attach to something the application cannot easily bypass. There are essentially three options, and most production stacks end up using two of them in combination. The gateway A gateway sits between every caller and every provider. Each request carries a feature tag in a header. The gateway reads the tag, looks up the remaining budget for that feature, and decides to forward, throttle, or deny. This is the strongest pattern because there is one place to read, one place to log, and one place to change policy. The cost is that the gateway becomes critical path: if it is slow, every feature is slow, and if it is down, every feature is down. Teams that adopt this pattern invest in gateway redundancy and a local fail-open mode for non-critical traffic. The SDK wrapper An SDK wrapper is a thin library in each language the company uses that wraps the provider client. Feature owners import it, pass their feature tag at construction, and call it the way they would call the underlying client. The wrapper records spend against the budget store and refuses calls that would exceed the remaining envelope. This pattern is easier to roll out incrementally - one team at a time, one codebase at a time - but it has no central choke point, so a team that bypasses the wrapper to call the provider directly bypasses the budget. Most organizations start here and add a gateway once enough services exist that per-codebase rollout stops scaling. Prompt-level limits The third option is not really budget enforcement. Input truncation, conversation-window trimming, and a hard max_tokens on every call are cost controls per request, not per feature. They keep a single runaway prompt from eating a quarter of the day's budget in one shot, but they do not stop a feature from making a million well-shaped calls. Treat prompt-level limits as a last-resort safety net underneath the gateway or wrapper, not as the budget itself. What overrun should actually do The most consequential design decision is what happens at the moment of overrun, because the answer has to differ by traffic class. A single global behavior - "block everything past the cap" - guarantees a customer-visible outage the first time a feature misforecasts. A single soft behavior - "always allow, just notify" - guarantees the budget is decorative. Three patterns cover almost every case. A soft cap allows the call, increments an overrun counter, notifies the owning team, and marks the feature as over-budget on the dashboard. A hard cap blocks the call and returns a structured error the caller can handle gracefully. A degraded cap routes the call to a cheaper model, a smaller context window, or a cached response, and tags the response so the owner can see how much traffic served degraded. The right default depends on the traffic class: customer-facing interactive traffic usually starts soft and graduates to degraded; internal tooling can go straight to hard; eval and batch traffic should be hard by default because there is no user waiting. A degraded path is the most operator-friendly of the three because it preserves the user experience while sending a clear signal upstream. It also requires the most engineering, since the application has to be able to actually run on the cheaper model without falling over. Teams that build this once tend to keep it as the default response to overrun forever after. Reporting the budget back to the owner The dashboard finance reads is not the dashboard the owning team needs. The owner is trying to decide whether to ship a fix, throttle a customer, or ask for more budget, and the data has to answer those three questions directly. Daily burn rate is the first number. Days-remaining-at-current-pace is the second, because that is the unit the owner thinks in. The top requesters within the feature - by tenant, by endpoint, by code path - surface whether the overrun is broad-based or driven by one heavy user. The last overrun event with timestamp and action taken closes the loop so the owner can verify that the policy fired when it was supposed to. Finance sees these numbers rolled up into the chargeback report; the owner sees them per-feature, on the surface they already use to debug their service. What goes on the per-feature dashboard Budget set - the token envelope agreed for the period, with the date it was last changed. Spend MTD - tokens consumed so far, broken out by input, output, reasoning, and cache. Projected EOM - straight-line extrapolation from current burn, plus a 7-day rolling estimate. Last overrun event - when the cap last fired, which policy applied, and how many calls were affected. Current cap policy - soft, hard, or degraded, and which conditions trigger which. Top requesters - the tenants or endpoints driving the largest share of the burn. Anything else is decoration. The owner reads these six tiles, decides, and moves on. Common implementation traps Most token-budget rollouts trip on the same handful of issues, and they all come from counting the wrong thing or counting it at the wrong moment. Using cost as the budget unit. Provider rates change. A budget in dollars looks stable but quietly redefines itself every time a price card updates. Budget in tokens and convert to cost in the reporting layer. Forgetting reasoning tokens. Reasoning models emit tokens the user never sees but that show up on the invoice. A counter that only watches input and output undercounts these features by a large margin. Forgetting cache-write tokens. Cache reads are cheap, but the write that primed the cache was not. A budget that only tracks input and output misses the entire cache-population cost and looks artificially healthy. Forgetting tool-call output. When an agent emits a long tool call as part of its response, that output is billable. Counters that only watch the final user-visible answer miss it. Not accounting for retries. A naive wrapper counts the successful call. A correct wrapper counts every attempt, because every attempt was billed. Retries on transient errors are a quiet source of overrun. Race conditions in the counter. Two concurrent calls that each read the remaining budget, decide they fit, and then both commit will both succeed and push the counter past zero. The fix is either an atomic decrement against a central store or a small slack buffer that absorbs the race without changing the user-visible policy. First week of implementation The shortest path from "we agreed on a budget" to "the budget is enforced" is roughly a week of focused work, and the order matters. Day one: tag the requests. Every model call carries a feature tag at the call site. No tag, no call in production. Day two: instrument the counter. Tokens flow into a per-feature ledger keyed by tag and period. Input, output, reasoning, and cache-write tokens are all separately tracked. Day three: surface the dashboard. Owners see their burn, projected EOM, and top requesters on a page they can bookmark. Day four: set the soft cap. The cap exists, the policy fires, the owner gets notified, no traffic is blocked. The point is to validate that the data is right before any user is affected. Day five and after: switch to hard or degraded once owners trust the data. Do not graduate features whose owners still dispute the burn number. Trust in the counter is the prerequisite for any blocking policy. The discipline is to ship enforcement and ownership at the same pace. A hard cap on a feature whose owner does not yet believe the counter is a guaranteed escalation. A soft cap on a feature whose owner reads the dashboard every morning is the foundation of a working FinOps practice. Related LLM budget governance Agent spend attribution LLM cost attribution LLM cost monitoring Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → ← Back to research FAQ Why budgets fail at the policy layer? The most common failure mode is a budget defined in a governance document that no service reads. A team writes down "the contract-redline feature gets ten million tokens per month," circulates it for approval, and never instruments the counter that would actually enforce it. Where can you enforce a token budget? Enforcement has to attach to something the application cannot easily bypass. There are essentially three options, and most production stacks end up using two of them in combination. The gateway A gateway sits between every caller and every provider. Each request carries a feature tag in a header. What overrun should actually do? The most consequential design decision is what happens at the moment of overrun, because the answer has to differ by traffic class. A single global behavior - "block everything past the cap" - guarantees a customer-visible outage the first time a feature misforecasts. How do you report a budget back to its owner? The dashboard finance reads is not the dashboard the owning team needs. The owner is trying to decide whether to ship a fix, throttle a customer, or ask for more budget, and the data has to answer those three questions directly. Daily burn rate is the first number. What goes on the per-feature dashboard? Anything else is decoration. The owner reads these six tiles, decides, and moves on. What are the common token-budget implementation traps? Most token-budget rollouts trip on the same handful of issues, and they all come from counting the wrong thing or counting it at the wrong moment. Using cost as the budget unit. Provider rates change. A budget in dollars looks stable but quietly redefines itself every time a price card updates. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Token budget implementation guide · FinOps LLM URL: https://finopsllm.com/research/token-budget-implementation-guide Token budget implementation guide Updated 12 July 2026 · first published 4 July 2026 Token budgets are the operational layer of LLM cost control. Attribution tells you where money goes; budgets prevent it from going places you do not want. Without budgets, a single misconfigured agent loop or a spike in user traffic can blow through a monthly allocation in hours. This guide covers how to implement four types of token budgets in production, with pseudocode for each pattern. Budget types Budget type Granularity Enforcement Use case Per-request Single API call Hard limit via max_tokens parameter Prevent runaway completions, bound latency Per-team quota Team or project over a period Soft limit with alerts, hard limit at threshold Departmental cost allocation, prevent one team from consuming shared budget Per-time-period Daily, weekly, or monthly Hard limit with grace period Monthly budget caps, sprint-level spending Per-workflow Single pipeline or agent run Hard limit per step and total Multi-step agents, RAG pipelines, eval runs Per-request limits The simplest budget: cap every request with max_tokens . This is not optional - every production request should have an explicit output token limit. Without it, a verbose model response can consume unexpected tokens and inflate latency. // Per-request budget enforcement function callLLM(prompt, config): response = provider.complete( prompt: prompt, model: config.model, max_tokens: config.max_output_tokens, // hard cap temperature: config.temperature ) if response.usage.total_tokens > config.warn_threshold: log.warn("Request exceeded soft limit", tokens: response.usage.total_tokens, threshold: config.warn_threshold ) return response Per-team quotas Team quotas require a shared counter that persists across requests. The pattern: check remaining budget before each call, reject or downgrade if the budget is exhausted. // Team quota with Redis-backed counter function checkTeamBudget(teamId, estimatedTokens): key = "budget:" + teamId + ":" + currentPeriod() remaining = redis.get(key) or getTeamQuota(teamId) if remaining < estimatedTokens: if remaining < estimatedTokens * 0.1: return DENY // hard limit: reject request else: return DOWNGRADE // soft limit: use cheaper model return ALLOW function recordUsage(teamId, actualTokens): key = "budget:" + teamId + ":" + currentPeriod() redis.decrby(key, actualTokens) remaining = redis.get(key) if remaining < getTeamQuota(teamId) * 0.2: alert.quotaLow(teamId, remaining) Per-time-period budgets Time-period budgets wrap team quotas with a time window. The key difference: you need a grace period mechanism. When a team hits 80% of their monthly budget, send an alert. At 100%, allow a configurable grace period (e.g., 24 hours) before hard enforcement kicks in. This prevents a team from being blocked mid-task on the last day of the month. // Time-period budget with grace period function enforceBudget(teamId): usage = getUsageForPeriod(teamId, currentMonth()) limit = getTeamMonthlyLimit(teamId) if usage < limit * 0.8: return ALLOW if usage < limit * 1.0: alert.budgetWarning(teamId, usage, limit) return ALLOW // soft warning zone if usage < limit * 1.1 and withinGracePeriod(teamId): alert.budgetExceeded(teamId, usage, limit) return ALLOW // grace period: allow overage return DENY // hard stop Per-workflow budgets Multi-step agents and pipelines need budgets at two levels: per-step (prevent any single step from consuming too much) and per-run (prevent the entire pipeline from exceeding its allocation). Track both in the workflow context. // Workflow budget tracker class WorkflowBudget: constructor(maxPerStep, maxTotal): this.maxPerStep = maxPerStep this.maxTotal = maxTotal this.spent = 0 function callStep(stepFn, prompt): if this.spent >= this.maxTotal: return fallbackResponse("Budget exceeded") response = callLLM(prompt, { max_tokens: min(this.maxPerStep, this.maxTotal - this.spent) }) this.spent += response.usage.total_tokens return response Graceful degradation when budget is exceeded Do not just return an error when a budget is hit. Downgrade gracefully. Switch to a cheaper model (GPT-4o-mini instead of GPT-4o), reduce context window size, skip optional processing steps, or return a partial result with a note that full processing requires budget approval. The user experience should degrade, not break. // Degradation chain function callWithDegradation(prompt, config): if checkBudget(config.teamId, FULL_MODEL): return callLLM(prompt, { model: config.primaryModel }) if checkBudget(config.teamId, CHEAP_MODEL): log.info("Downgrading model for budget") return callLLM(prompt, { model: config.fallbackModel }) if checkBudget(config.teamId, MINIMAL_TOKENS): truncated = truncateContext(prompt, 50%) return callLLM(truncated, { model: config.fallbackModel, max_tokens: 256 }) return cachedOrFallback(prompt) Monitoring budget health Track three metrics: burn rate (tokens consumed per hour vs. budget), forecast (at current rate, when will the budget be exhausted), and override count (how many times the grace period was used). If grace period usage exceeds 10% of total requests, the budget is set too low for the workload. Related LLM budget governance - organizational policies behind budgets. Agent spend guardrails - budget patterns for autonomous agents. How to cap inference costs - provider-side cost controls. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What are the four types of token budgets? The four budget types are: (1) Per-request - single API call with hard limit via max_tokens parameter to prevent runaway completions; (2) Per-team quota - team or project over a period with soft limit and hard threshold to prevent one team from consuming shared budget; (3) Per-time-period - daily, weekly, or monthly with hard limit and grace period for monthly budget caps; (4) Per-workflow - single pipeline or agent run with hard limit per step and total to control multi-step agents and RAG pipelines. What is the simplest token budget to implement? The simplest budget is per-request: cap every request with max_tokens. This is not optional—every production request should have an explicit output token limit. Without it, a verbose model response can consume unexpected tokens and inflate latency. How should per-team quotas be enforced? Team quotas require a shared counter that persists across requests. The pattern: check remaining budget before each call, reject or downgrade if the budget is exhausted. Use a soft limit to trigger a downgrade to a cheaper model, and a hard limit to reject the request outright. Record actual usage and alert when remaining budget falls below a threshold. What is the purpose of a grace period in time-period budgets? A grace period mechanism prevents a team from being blocked mid-task on the last day of the month. When a team hits 80% of their monthly budget, send an alert. At 100%, allow a configurable grace period (e.g., 24 hours) before hard enforcement kicks in. This gives teams time to wrap up important work. How should multi-step agent budgets be tracked? Multi-step agents and pipelines need budgets at two levels: per-step (prevent any single step from consuming too much) and per-run (prevent the entire pipeline from exceeding its allocation). Track both in the workflow context, ensuring that each step respects both its own limit and the remaining total-run budget. What is graceful degradation in token budget enforcement? Do not just return an error when a budget is hit. Downgrade gracefully. Switch to a cheaper model, reduce context window size, skip optional processing steps, or return a partial result with a note that full processing requires budget approval. The user experience should degrade, not break. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Token prices fell. Your LLM bill still went up. · FinOps LLM URL: https://finopsllm.com/research/token-prices-bill-keeps-rising Token prices fell. Your LLM bill still went up. Updated August 27, 2026 · first published August 27, 2026 Quick answer: Lower token prices do not guarantee a lower LLM bill. In production, usage can grow faster than rates fall: longer contexts, more agent steps, larger outputs, retries, and new features can erase a 40%... Lower token prices do not guarantee a lower LLM bill. In production, usage can grow faster than rates fall: longer contexts, more agent steps, larger outputs, retries, and new features can erase a 40% price reduction. The useful diagnosis is not which provider got cheaper It is four-way variance: rate, volume, mix, and efficiency. Rate is only one part of the bill Suppose a provider cuts your blended price from $10 to $6 per million tokens. If monthly usage rises from 100 million to 220 million tokens, the bill moves from $1,000 to $1,320. The price dropped 40%; the invoice rose 32%. A dashboard that reports only price per token will call this a win while finance sees the opposite. Track the provider rate actually billed by model and token type. Input, output, cache-read, cache-write, and reasoning tokens should not be collapsed into one average. The average is a reporting convenience, not a causal explanation. Volume, mix, and efficiency Volume is how many tokens you consumed. It rises when traffic grows, context becomes longer, or agents take more steps. Mix is where the tokens went: a premium reasoning model, a new geography, or a high-context feature can change the bill without changing total requests. Efficiency is the cost of serving the same useful outcome: retries, failed tool calls, oversized prompts, and output that users never consume. Instrument every model call with provider, model, feature, team, environment, request type, input tokens, output tokens, cache tokens, reasoning tokens, retries, and outcome. Join those events to the provider invoice. Without the invoice join, you can explain usage but not prove spend. The review that catches the problem Run a weekly bridge from the prior period to the current one. Start with the baseline invoice, apply rate changes, then volume changes, model-mix changes, and efficiency changes. The residual should be small enough to investigate. A practical alert is not ‘tokens rose 20%’; it is ‘the feature’s traffic-adjusted cost per successful task rose 18%.’ Variance Question Typical action Rate Did the provider price change? Refresh the price sheet and contract assumptions. Volume Did traffic or context grow? Forecast usage and add capacity controls. Mix Did work move to a dearer model? Review routing and quality thresholds. Efficiency Did each outcome require more work? Fix retries, prompts, tools, or stopping rules. What to optimize first Do not start by forcing every request onto the cheapest model. First find the variance category with the largest dollars. If volume dominates, fix context growth or agent loops. If mix dominates, create a routing policy. If efficiency dominates, remove retries and unused output. If rate dominates, renegotiate or move eligible work to batch pricing. The right lever is the one attached to the observed variance. Falling prices are good news, but they are not a cost-control strategy. A production team needs a reconciled view of price, usage, workload mix, and outcome quality. That is how a cheaper market becomes a cheaper product. Related LLM cost monitoring Cost per request as a product KPI LLM cost attribution Related LLM cost monitoring Cost per request as a product KPI LLM cost attribution Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # What is the Tokenomics Foundation? · FinOps LLM URL: https://finopsllm.com/research/tokenomics-foundation What is the Tokenomics Foundation? Published 15 August 2026 The Tokenomics Foundation is an open governance body hosted by the Linux Foundation, launched on 4 August 2026 with 29 founding members including JPMorgan Chase and IBM. Announced alongside the FinOps Foundation at FinOps X 2026, its remit is the thing nobody owns today: a vendor-neutral, shared definition of what enterprise AI actually costs and what that cost is worth. Why a standards body, and why now Token billing arrived before the accounting for it did. Every provider meters differently. No two invoices use the same units. A "token" means one thing on an OpenAI statement, something adjacent on an Anthropic one, and something else again inside a Bedrock or Azure line item. There is no agreed answer to a question every finance team now asks out loud: what does a token cost this business, and what did it buy. The gap stopped being academic in the first half of 2026. Companies reported being 3x over their entire 2026 token budget by May. The most-cited example is Uber, which rolled Claude Code out to roughly 5,000 engineers in December 2025; by April the company's whole annual AI budget was spent, with monthly per-engineer costs landing somewhere between $500 and $2,000. Nothing there was a failure of engineering. It was a failure of measurement: nobody had a unit that could carry the forecast. That is the shape of problem standards bodies exist for. When a cost is new, every vendor invents its own accounting, and buyers cannot compare, forecast, or negotiate until somebody neutral defines the units. What it plans to standardize The published roadmap runs to four workstreams: Workstream What it means in practice Tokenomics and value metrics A shared vocabulary for AI ROI, so "cost per outcome" means the same thing across two companies and two vendors. AI Value Frameworks Structured ways to measure business impact, not just spend. The half of the equation most dashboards leave out. Full-cost models Vendor-neutral models for total AI cost, including the layers the token meter never sees. Education and certification A practitioner track, mirroring how the FinOps Foundation built its certification path for cloud. The point buried in the announcement: tokens are not the whole bill The foundation's own framing is worth reading carefully. Tokens are described as the unit of measure that has become a pricing method - and as the most easily metered layer , accounting for a portion of AI spend rather than all of it. That distinction is the single most useful thing in the launch. A token meter is easy to read, so it becomes the number people manage. But the token line sits on top of costs that never appear in it: GPU reservations and idle capacity held for latency headroom. Vector store writes, reads, and the reindexing that follows every embedding-model change. Eval harnesses, which routinely cost more than the feature they grade. Human review and annotation on anything customer-facing. Egress, orchestration, and the retry traffic that agents generate by design. Manage only the metered layer and you optimize the part you can see while the rest drifts. This is the same trap as reading an invoice total without attribution underneath it: a real number that answers the wrong question. How this fits with what already exists Three efforts are converging on AI cost, and they operate at different layers. Confusing them wastes time. OpenTelemetry GenAI semantic conventions standardize the telemetry : what attributes a model call emits, named consistently across SDKs. See the conventions in detail . This is the wire format. FOCUS and the FinOps Foundation standardize the billing data : a common schema for provider cost exports, which AI spend is now being pulled into. See LLM FinOps standards . The Tokenomics Foundation targets the layer above both: what the measured thing means , and what it is worth. You need all three, and they land in that order. Telemetry produces the data, billing schemas make it comparable, and value frameworks make it arguable in a budget meeting. What this changes for practitioners in 2026 Honestly: not much, yet. This is an intent-to-launch turning into a launch, with 29 members and a roadmap. The first deliverables are frameworks and definitions, not tooling. Standards bodies publish on a multi-year cadence, and the FinOps Foundation's own cloud work took years to reach the point where a spec changed what vendors shipped. What it does change is the direction of travel, and that is worth acting on early for two reasons: Vendor claims are about to get checkable. Once "cost per outcome" has a definition, a tool that reports it differently has to explain why. If you are evaluating AI cost tooling now, ask whether the vendor is a member and how it plans to map its metrics onto the frameworks. The answer is informative either way. The 29 founding members are your negotiating peers. A standards body backed by JPMorgan Chase and IBM is buyers organizing around a pricing model they did not design. Consistent units are the precondition for comparing providers, which is the precondition for moving workloads between them . What to do before the standards land The work that makes you standards-ready is the work that pays for itself now: Enforce a tagging contract at the gateway. Every request carries feature, environment, team, and customer. Everything a value framework will eventually ask for is derived from those tags. Start at cost attribution . Track consumption, not just cost. Unit prices are falling while bills rise; a budget denominated in dollars hides that, a budget denominated in tokens does not. See cost trends . Reconcile to the invoice monthly. An internal estimate nobody has checked against a real bill will not survive contact with a framework that assumes it was. See invoice reconciliation . Price the unmetered layers explicitly. Put GPU reservations, evals, vector stores, and human review in the same model as tokens, even roughly. Full-cost modelling is a named workstream; showing up with only a token number means starting over. Teams already doing this will adopt the standard as a rename. Teams that are not will adopt it as a migration. Related LLM FinOps standards - the existing schema work this builds on. OpenTelemetry GenAI conventions - the telemetry layer underneath. What is LLM FinOps? - the discipline this sits inside. How to budget for AI spend - the practice the Uber case failed at. Agent economics - why coding agents blow through annual budgets in four months. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is the Tokenomics Foundation? The Tokenomics Foundation is an open governance body hosted by the Linux Foundation, launched on 4 August 2026 with 29 founding members including JPMorgan Chase and IBM. It works alongside the FinOps Foundation to build vendor-neutral standards for measuring, allocating, and justifying enterprise AI spend. Why was it created? Because token billing arrived before the accounting for it did. Every provider meters differently, no two invoices use the same units, and there is no shared definition of what a token costs a business. Companies reported running 3x over their entire 2026 token budget by May. What will the Tokenomics Foundation standardize? Four workstreams: a shared definition of tokenomics and value metrics for AI ROI, AI Value Frameworks for measuring business impact, vendor-neutral models for the full cost of AI beyond the token line, and education and certification for practitioners. Is a token the same as AI cost? No. Tokens are the most easily metered layer of AI spend, not the whole of it. GPU reservations, vector storage, egress, eval harnesses, and human review all sit outside the token meter. Treating the token bill as the AI bill understates real cost, often by a wide margin. How does this relate to OpenTelemetry GenAI conventions? They solve different halves of the same problem. OpenTelemetry GenAI semantic conventions standardize the telemetry emitted by a request. The Tokenomics Foundation is aimed at the layer above: what that telemetry means in business terms, and what a token is worth once it is measured. What should we do before the standards ship? Do not wait. Standards bodies publish on a multi-year cadence and the first deliverables are frameworks, not code. Build a tagging contract, reconcile to the invoice monthly, and track consumption alongside cost. Teams already doing that will adopt the standard as a rename; teams that are not will adopt it as a migration. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # September 2026 AI Model Trends: GPT-6, Opus 5.5 · FinOps LLM URL: https://finopsllm.com/research/trending-ai-models-september-2026 September 2026 AI model trends Updated September 27, 2026 · first published September 27, 2026 September 2026 AI Model Trends (7-Day Snapshot) This dashboard tracks the most discussed AI models over the last week, based on cross-platform signals from Hacker News, Reddit, GitHub, and Techmeme. Metrics combine momentum (discussion velocity) and engagement (upvotes, comments, interactions) normalized across sources. Trending Rankings (Top 10) Momentum = discussion velocity | Engagement = native interactions across platforms Rank Model / Topic Momentum Engagement Status 1 Claude Opus 5.5 1,794 2,930 Hot 2 GPT-6 Sol and Luna 1,609 2,627 Hot 3 GPT-6 Astra 872 4,360 Rising 4 OpenAI Agent Message Board 797 3,904 New 5 System One Models + Jev 694 2,504 New 6 Dutch Gov NixOS 1,366 1,577 Emerging 7 iPhone Duo 924 4,030 Viral 8 MiMo v2.6 912 1,609 Rising 9 Pentagon AI Risk 926 1,513 Rising 10 AI Poster Quality 952 2,855 Rising Claude Opus 5.5 Breakdown Leading all topics with 1,794 momentum and 2,930 engagements across 4 platforms (HN, Reddit, GitHub, Techmeme). Top community feedback highlights the 5-hour usage limit increase on Pro/Max/Team plans and a rate-limit reset for subscribers. Key signal: 597-vote comment calls out price drops + 5-hour limit boosts Engagement: 1,389 HN comments, 1,344 Reddit replies GPT-6 Sol and Luna: Twin Pricing Signals OpenAI's newly launched models show divergent positioning: Sol optimized for low-cost inference, Luna pitched at balanced performance. Top comment asks "Anyone else remember when it took 6 months for new models to come out?" , flagging the rapid cadence. Momentum spread: 1,609 across GitHub + HN + Reddit + Techmeme GitHub: 91 comments + 145 reactions OpenAI Agent Message Board: Agents Talking to Agents Discovery of a direct agent-to-agent communication layer means autonomous workflows can coordinate without human intervention. FinOps risk: unbounded token loops between agents if message depth limits aren't enforced. Momentum: 797 velocity, 3,904 engagement Top comment: Git PR review syntax — technical depth suggests infrastructure team involvement System One Models + Jev: Calibration Beats Accuracy The new calibration-based routing model checks System One's confidence before escalating to premium models. Benchmarks claim ~76% cost reduction vs always-Astra at near-Astra accuracy. Momentum: 694 velocity, 2,504 engagement Engagement: 534 HN comments + 2,030 HN points What FinOps Teams Should Watch Rapid model cadence: 6 models in 3 weeks (Sol, Luna, Astra, Opus 5.5) means matrixed pricing tables require daily coverage Agent protocol evolution: Agent message boards create new spend vectors—track inter-agent token counts separately from human interaction Routing layer maturation: System One/Jev and similar calibration gates are the first inference-time cost controls worth prioritizing Data Sources & Methodology Sources: Hacker News, Reddit, GitHub, Techmeme, Polymarket Window: 2026-08-28 to 2026-09-27 (7 days) Normalization: Momentum scaled by platform weight; engagement normalized across sources Next Updates This tracker wraps every 7 days. Subscribe to the LLM cost spike runbook for weekly variations in model pricing and detect when trends flip from interest (high momentum) to actionable (FinOps-critical). Related OpenAI agent message board cost model System One Models and Jev cost optimization GPT-6 Astra pricing and cost model LLM cost spike runbook Claude Opus 5.5 cost model Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # The True Cost of Coding Agents: Beyond the API Bill · FinOps LLM URL: https://finopsllm.com/research/true-cost-coding-agents The true cost of coding agents Updated 1 August 2026 Coding agents look cheap on a rate card. A few dollars per day in API credits feels trivial next to an engineer's salary. But the true cost of coding agents is larger and more persistent than the API bill. It lives in retries, context re-reads, human review, test maintenance, and the technical debt that accumulates when generated code is merged without full understanding. The API bill is just the starting point The visible cost is tokens. A coding agent working on a large repository can easily consume tens of millions of input tokens per day as it re-reads context on every turn. Output tokens add up when the agent explains its reasoning alongside the code. But the API bill is only part of the cost. To understand the real economics, you need to include the hidden costs that follow. Hidden cost 1: retries and failed passes Agents do not always generate correct code on the first try. A failed compile, a failing test, or a rejected review triggers another pass. Each pass re-reads context and sends new output. A task that succeeds on the third attempt can cost 3x the API bill of a single pass. Worse, the retries may not be visible in the IDE; they just appear as higher token usage. Hidden cost 2: context re-reads Unlike a human engineer who keeps context in working memory, an agent re-reads files, conversation history, and codebase context on nearly every turn. In a large repository, this means the same 50,000-token context block may be billed dozens of times in a single session. Prompt caching helps, but only if the context is stable. A rapidly changing codebase defeats the cache. Hidden cost 3: human review Generated code still requires human review. The review is not free. For complex changes, senior engineers may spend as much time reviewing agent output as they would have spent writing it themselves. If the review catches subtle bugs, the savings are real. If the review is rubber-stamped, the cost is deferred into maintenance. Hidden cost 4: tests and maintenance Agents can generate tests alongside code, but those tests may be shallow or tied to implementation details that change. Maintaining generated tests, updating them as requirements evolve, and debugging failures all consume engineering time. This cost is rarely tracked but can dominate the lifetime cost of agent-generated code. Hidden cost 5: technical debt The most expensive hidden cost is technical debt. An agent may produce code that works today but is hard to modify tomorrow. It may duplicate patterns, skip abstractions, or miss edge cases that a human engineer would anticipate. The cost of this debt appears later, as slower feature development and more bugs. How to measure true cost The right unit is not tokens per day. It is cost per merged, production-ready change. To measure it: Track API spend per agent session or per task. Add the time engineers spend reviewing and fixing agent output. Count the number of passes required to merge. Track post-merge bug rate for agent-generated changes. Estimate maintenance burden over the following quarter. Only then can you compare the cost of an agent-generated change to a human-written one. How to control true cost Scope agent tasks tightly. Agents excel at bounded tasks, not open-ended design. Limit context size. Send only the files and history the agent needs. Use cheaper models for first drafts. Route to frontier models only for complex logic. Cap retries. Force human takeover after a small number of failed passes. Require tests that fail meaningfully. Shallow tests create maintenance debt. Review generated code carefully. Rubber-stamping defeats the purpose. The cheapest coding agent is the one that produces a correct, maintainable change on the first or second pass. The most expensive one is the agent that burns tokens, generates subtle bugs, and leaves technical debt for the next engineer. Related AI coding economics 2026 — provider pricing comparison. Cheapest way to run AI code generation — cost categories beyond API spend. AI coding plan comparison — subscription vs API pricing. Agent spend guardrails — controls for runaway agents. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is the true cost of coding agents? The true cost includes API tokens, retries, context re-reads, human review, test maintenance, and accumulated technical debt. The API bill is often only half the picture. Why do coding agents cost more than expected? Coding agents re-read conversation history and codebase context on every turn, inflating token volume. They also retry on failure, generate code that needs review, and can introduce subtle bugs that increase maintenance cost. How do I reduce coding agent costs? Use prompt compaction, context summarization, model routing, retry caps, and output-length limits. Measure cost per merged change, not just API spend, to find the real savings opportunities. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Verbose prompts have a tax · FinOps LLM URL: https://finopsllm.com/research/verbose-prompt-tax How prompting style shows up on the bill Updated September 1, 2026 · first published September 1, 2026 Quick answer: Prompts grow the way configuration files grow. Someone adds an instruction to fix a failure mode. Someone else adds an example. A third person adds a paragraph explaining why the second instruction... Prompts grow the way configuration files grow. Someone adds an instruction to fix a failure mode. Someone else adds an example. A third person adds a paragraph explaining why the second instruction matters. Nothing is ever removed, because removing it might reintroduce a bug nobody can reproduce. Six months later the system prompt is three thousand tokens and no one can say which two hundred of them are load-bearing. Why it compounds Unlike output, which varies with the task, prompt overhead is paid on every single request , identically, forever. A thousand wasted tokens on a feature serving ten million calls a month is ten billion tokens a month of pure formatting. In multi-turn conversations it is worse: the system prompt is resent on every turn, so its cost scales with turn count, not request count. And in agent loops, where a single user action can trigger a dozen model calls, the same bloated preamble is billed a dozen times for one piece of work. What is actually wasteful Not politeness, which is a handful of tokens and occasionally improves compliance. The real weight sits in: redundant instructions that restate the same rule three ways, defensive boilerplate added for a model generation that no longer needs it, examples that duplicate rather than cover distinct cases, and explanations aimed at human readers of the prompt file rather than at the model. That third category is the largest in practice. Few-shot examples are expensive per token and teams rarely revisit whether five are doing work that two would do. Treat the prompt as code with a budget Measure the fixed prompt overhead as a share of average request size — if it is over half, it is a cost problem, not a style question. Put the stable part first so caching applies, which makes the remaining bloat far cheaper without deleting anything. Then run an ablation: remove one block, run your evals, keep the removal if quality holds. Prompt trimming without an eval suite is guesswork, and the failure mode — a quality regression discovered by customers — costs more than the tokens saved. Related Prompt caching economics Evals as cost control Token budget implementation Related Prompt caching economics Evals as cost control Token budget implementation Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # Voice agents bill by the minute · FinOps LLM URL: https://finopsllm.com/research/voice-agents-bill-per-minute The unit economics of realtime and audio APIs Updated September 1, 2026 · first published September 1, 2026 Quick answer: Every cost model built for text LLMs breaks on voice. Text is billed by tokens, and tokens are proportional to information. Audio is billed by duration, and duration is proportional to time —... Every cost model built for text LLMs breaks on voice. Text is billed by tokens, and tokens are proportional to information. Audio is billed by duration, and duration is proportional to time — including all the time in which nothing useful is happening. What you are actually paying for A voice interaction is usually three or four billed things stacked. Speech-to-text on the inbound audio. The model call itself, which on realtime speech-to-speech APIs is priced per minute of audio in and out rather than per token. Text-to-speech on the way back, if the stack is not end-to-end. And often a separate charge for the session staying open. That last one is the trap. A session held open while a user thinks, reads something on screen, or steps away is still a session. On a per-minute meter, dead air is a full-price product. Where the estimates go wrong Teams model voice cost as speaking time × rate and land well under actual. Four things are missing. Latency and pauses are billed but not modelled. Interruptions mean audio generated and paid for that the caller never heard. Retries and re-prompts replay the whole exchange, and a voice retry is far more expensive than a text one because it repeats the audio, not just the tokens. And abandoned calls cost the full duration to the point of hangup while producing nothing. The metric that works Cost per completed conversation, not cost per minute. Per-minute is the meter, not the unit of business value — and a change that shortens calls by improving the model may increase the per-minute rate while lowering the cost of getting a caller to an answer. Then instrument the parts nobody sees: median and p95 session duration, ratio of billed to spoken time, abandonment rate, and cost of abandoned sessions as a share of the total. Close idle sessions aggressively; an idle timeout is usually the single largest saving available in a voice stack. And treat barge-in support as a cost feature as much as a UX one, since every second of speech a user talks over is a second you paid to generate. Related Agent economics LLM cost attribution Server tools are a separate invoice Related Agent economics LLM cost attribution Server tools are a separate invoice Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit → Back to finopsllm.com --- # What Is DeepSeek Harness? A Complete Guide · FinOps LLM URL: https://finopsllm.com/research/what-is-deepseek-harness What is DeepSeek Harness? A complete guide Published 16 August 2026 DeepSeek Harness — package name dsh — is an MIT-licensed open-source agent harness published by DeepSeek AI. This is the plain-language version: what it is, how to run it, how it is put together, and whether you should care. What an agent harness actually is A model generates text and tool calls. That is all it does. Everything else that makes an agent useful is the harness: assembling the prompt, executing the tools the model asked for, enforcing what it is allowed to do, recording what happened, managing the loop that decides whether to call the model again, and delegating work to child agents. This distinction is worth internalising before anything else, because most of what an agent does well or badly is harness behaviour rather than model behaviour. Two teams running the identical model can get very different results and very different bills, and the difference lives here. What DeepSeek Harness does It runs coding and automation agents. In practice the agent reads and edits files, runs shell commands, searches the codebase, delegates to subagents, plans work, and asks for confirmation according to whatever permission policy is active. There is a browser UI, a headless mode for one-shot runs, and an automation server that speaks JSON-RPC over standard input and output for scripting. The one design idea: everything is a plugin The harness runs on Cordis , a plugin runtime where plugins contribute services, typed events, and reversible effects into a shared context. There is no privileged core. The model adapter is a plugin. The tool registry is a plugin. The session log is a plugin. The agent loop itself is a plugin. Most extensible systems give you a fixed core plus hooks — you can observe and decorate, but not replace, and replacing means forking. A plugin runtime inverts that: the pieces you would most want to replace are the units of composition. Getting it running The fast path npx @deepseek-ai/dsh web That starts a local web UI at http://127.0.0.1:3080 . From source git clone https://github.com/deepseek-ai/deepseek-harness cd deepseek-harness pnpm install pnpm run build pnpm dsh web Requirements: Node 22.19 or newer (CI covers 22.19, 24, and 26), Git 2.26 or newer, and pnpm pinned through Corepack. A DeepSeek API key is optional at install time but needed to do anything useful; it can come from the environment or a gitignored .env at the repository root. The two steps people miss Settings → Models. Enter your API key. The route enables immediately, no restart needed. Choose workspace. Add and activate your project directory. The session composer stays unavailable until a workspace is active, which is the usual reason a fresh install appears broken. Headless pnpm dsh --profile headless "summarize this workspace" This is the mode that matters for automation, because a harness that only works interactively cannot be put in CI, and a harness that cannot be put in CI cannot be measured on a schedule. The concepts you need to read the docs Term Meaning Step One model request plus the tool calls it produces Turn One drain of input, ending when the model stops or policy intervenes Round An outer policy iteration above turns, such as a fresh attempt at a goal Session An append-only log of typed events — the single source of truth for the run Capability seam A service interface with several interchangeable implementations Profile A named composition: an ordered list of plugin bundles plus user patches Scope The unit of per-agent registration for tools, prompts, and restrictions Configuration resolves in four layers, later winning: profile bundles, then profile patches, then home-level patches, then command-line overlays. Knowing that order turns "why is it using that model" from an investigation into a lookup. How to configure it Composition runs through profiles. Three templates ship: a base runtime, a browser UI variant, and a headless one-shot runner. A profile stores an ordered list of bundles — packages that distribute configuration rows and code — plus your own patches on top. The registry keys you will see referenced across the documentation are the subsystems: sessions, system prompt, tools, agents, the agent loop, and the model service. Each is a plugin contributing into the shared context under one of those names. What makes it worth looking at Model choice is swappable. The model service is an interface with several backends behind it, including one that replays a recorded session without paying for inference again. The agent loop consumes a provider-neutral stream and never learns which backend is live. The record is complete by construction. The governing principle is that model-visible means logged: anything the model could see appears in the session log, because the log has to be able to reconstitute the run. Token usage travels attached to the output that incurred it. Enforcement points are explicit. One before the model request goes out, whose decision is documented as authoritative, and one before any tool body executes. Permission guards can deny or abstain but never grant, and an unanswerable approval prompt denies. It runs headless. Which means it can be scripted, scheduled, and measured. The plugin claim is not just positioning. One of the shipped demos is self-referential: it inspects and modifies its own live plugin runtime while running. That is difficult to fake. When to use it, and when not to Use it to evaluate, to prototype, and as a concrete benchmark for whatever agent stack you already run. The five questions worth carrying to your own system are: is model choice swappable, is there a complete session record with usage attached, are there enforcement points before the model call and before tool execution, does it run headless, and is the configuration layering documented. Do not standardise on it this quarter. The project describes itself as a developer preview and states plainly that there will be compatibility-breaking changes. Pin whatever version you build against, and do not schedule production migration work off a preview API. What it costs to run The harness is MIT-licensed and free. Inference is not. You supply a DeepSeek API key, or point the model seam at another provider. The practical implication is that your bill is a function of steps per turn, tools in the catalogue, delegation depth, and how many rounds an open-ended objective is allowed to run — all harness-level decisions, none of them the token price you negotiated. Related DeepSeek Harness: install, profiles, and first run — the longer setup walkthrough. What "everything is a plugin" actually buys you — the architecture in depth. The DeepSeek Harness session log as a cost record — reading the event log. Where to put spend guardrails in DeepSeek Harness — the enforcement points. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is DeepSeek Harness? DeepSeek Harness, package name dsh, is an MIT-licensed open-source agent harness published by DeepSeek AI. It runs coding and automation agents that read and edit files, run commands, delegate to subagents, and plan work. Its design premise is that everything is a plugin, built on the Cordis plugin runtime. How do you install DeepSeek Harness? The quickest path is npx @deepseek-ai/dsh web, which starts a local web UI on port 3080. From source, clone the repository, run pnpm install, pnpm run build, then pnpm dsh web. It needs Node 22.19 or newer and Git 2.26 or newer, with pnpm pinned through Corepack. Is DeepSeek Harness free? The harness itself is MIT-licensed and free to run. Model inference is not: you supply a DeepSeek API key, or point it at a different provider through the model seam. The cost of running agents is inference cost, not licence cost. Is DeepSeek Harness production ready? No. The project describes itself as a developer preview and states plainly that there will be compatibility-breaking changes. It is suitable for evaluation and prototyping, and as a benchmark against whatever agent stack you already run, but not for standardising on this quarter. What is the difference between an agent harness and a model? The model generates text and tool calls. The harness is everything around it: assembling the prompt, executing tools, enforcing permissions, recording the session, managing turns and steps, and delegating to subagents. Most of what an agent does well or badly is harness behaviour, not model behaviour. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # What is LLM cost attribution? A plain-English explainer · FinOps LLM URL: https://finopsllm.com/research/what-is-llm-cost-attribution What is LLM cost attribution? Updated 11 June 2026 · first published 31 May 2026 LLM cost attribution is the practice of tracing every dollar of language-model spend back to the thing that caused it - a feature, a team, an environment, or a specific customer. It answers the question a provider invoice never will: not "what did we spend on OpenAI," but " which part of our product spent it, and on whose behalf." Attribution is the foundation everything else in AI cost management is built on; without it, budgets are guesses and savings claims are unverifiable. The problem attribution solves A provider invoice arrives aggregated and lagging. You get a line item per model per day - not "the checkout summarizer cost $14,000 last month." If spend jumps 30%, the invoice tells you that it happened, never why . A dashboard that shows total spend has the same blind spot: it is a number going up, with no owner attached. Attribution closes that gap. It reconstructs, from your own request logs, the answer to four questions for every unit of spend: which feature triggered the call, which environment it ran in (production, staging, eval, internal), which team owns that surface, and which customer or workspace it served. Once spend carries those tags, the invoice stops being a mystery. What "attribution" actually means in practice Concretely, attribution means every LLM request leaves a structured trace carrying at minimum: Feature / surface - the product capability that made the call. Environment - production vs staging vs eval vs internal tooling, so test spend never masquerades as revenue-feature spend. Team - the group accountable for that surface. Customer or workspace - for per-customer gross-margin analysis. Cost breakdown - input, output, cache-read, and reasoning tokens separately, since they are priced differently. Traffic that arrives untagged does not vanish into "unallocated." It goes into a default bucket with a named owner , so the bucket itself can be driven toward zero over time. The discipline is as much organizational as technical: someone has to own the tagging contract and enforce it at the gateway. Why total spend isn't enough Three questions that only attribution can answer, and that every team eventually gets asked: Which feature caused the spike? Total spend says the bill rose; attribution says the new summarizer shipped on Tuesday and shifted to the flagship model. (See why bills spike .) What is the gross margin on this feature? You cannot compute margin per feature without knowing cost per feature. Attribution turns AI spend into a unit-economics input. Who should pay for this? Chargeback and showback both require a defensible per-team number. A cost a team cannot see is a cost it cannot reduce. Attribution vs observability vs reconciliation These get conflated. They are different layers: Observability tells you what happened to a request - latency, errors, traces. It is necessary plumbing, but a trace without cost tags is telemetry, not attribution. Attribution maps cost to an owner. It is the layer that turns usage data into a business answer. Reconciliation ties your attributed internal estimate back to the actual provider invoice , so the numbers everyone argues over are trusted. You need all three, but in order: observability produces the data, attribution gives it meaning, reconciliation makes it defensible. How accurate does it need to be? Attribution does not have to be perfect to be useful - it has to be trusted and improving. A practice that attributes 85% of spend cleanly, names the owner of the remaining 15%, and reconciles to the invoice monthly is far more valuable than a "100% accurate" model that no one has checked against a real bill. Start coarse (feature and environment), get it reconciling, then refine toward per-customer granularity where the margin questions actually need it. Where to start Attribution is the first step in any AI cost program, before budgets and before optimization. The minimum viable version is a tagging contract - what every request must carry - enforced at the gateway, plus a breakdown of spend by feature, environment, and token type. Once that exists, budgeting , anomaly detection, and chargeback all become possible. Until it exists, they are guesswork. Related Cost per request as a product KPI - operationalizing attribution in product. LLM cost attribution (in depth) - how the allocation layer is built. What is LLM FinOps? - the broader discipline attribution sits inside. How to budget for AI spend - the step attribution unlocks. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is the problem attribution solves? A provider invoice arrives aggregated and lagging. You get a line item per model per day - not "the checkout summarizer cost $14,000 last month." If spend jumps 30%, the invoice tells you that it happened, never why. What does "attribution" actually mean in practice? Concretely, attribution means every LLM request leaves a structured trace carrying at minimum: Feature / surface - the product capability that made the call. Environment - production vs staging vs eval vs internal tooling, so test spend never masquerades as revenue-feature spend. Why total spend isn't enough? Three questions that only attribution can answer, and that every team eventually gets asked: What is the difference between attribution, observability, and reconciliation? These get conflated. They are different layers: Observability tells you what happened to a request - latency, errors, traces. It is necessary plumbing, but a trace without cost tags is telemetry, not attribution. Attribution maps cost to an owner. How accurate does it need to be? Attribution does not have to be perfect to be useful - it has to be trusted and improving. Where to start? Attribution is the first step in any AI cost program, before budgets and before optimization. The minimum viable version is a tagging contract - what every request must carry - enforced at the gateway, plus a breakdown of spend by feature, environment, and token type. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # What is LLM FinOps? A plain-English definition · FinOps LLM URL: https://finopsllm.com/research/what-is-llm-finops What is LLM FinOps? Updated 12 July 2026 · first published 21 May 2026 LLM FinOps is the operating discipline that turns large-language-model spend into a managed, attributable, reconciled line item. It is the way FP&A, platform engineering, and product teams agree on who used which model, what it cost, who pays for it, and how the internal number reconciles to the provider invoice at month end. It is not a tool, a dashboard, or a policy paper - it is the working agreement between finance and engineering that makes LLM cost behave like every other unit-economics input. The phrase took hold in 2025 and 2026 because LLM spend stopped looking like a SaaS subscription and started looking like cloud compute - variable, per-request, driven by code paths that change weekly. Traditional vendor management could not answer the questions finance was actually being asked: which feature is responsible for last week's spike, which customer cohort drives gross-margin compression, and why does the OpenAI invoice not match what the gateway logged. LLM FinOps is the answer to those questions. The short answer LLM FinOps is FinOps applied to language-model usage. The novelty is the cost driver - tokens, model tiers, cache reads, retrieval depth, reasoning traces - not the controls. The discipline has four working components: Allocation - every request tagged to a team, feature, environment, and customer, so spend can be traced back to a named owner. Budgets and forecasts - monthly envelopes per workload, with a known degradation path when a workload approaches its limit. Reconciliation - a monthly close that ties internal usage logs to the provider invoice, with documented variance. Ownership - a named finance partner, a named platform engineer, and an executive sponsor accountable for the number. If a company has dashboards but no allocation, it has telemetry, not FinOps. If it has budgets but cannot reconcile to the invoice, it has theatre. If it has reconciliation but no owners, it has a spreadsheet that nobody updates after the next reorg. Why LLM spend needs its own FinOps practice Cloud FinOps frameworks assume that the cost driver is infrastructure you provision - instance hours, storage, data egress - and that the provider gives you a usage report you can map to tags you control. LLM spend breaks both assumptions. First, the cost driver is the request shape: input tokens, output tokens, cache-read tokens, reasoning tokens, and which model tier handled it. A single deploy can double per-request cost without changing request volume, because someone increased retrieval depth, raised the reasoning budget, or shifted a router threshold. Traditional rate-of-spend alerts cannot see that. Second, provider invoices arrive aggregated and lagging. You do not get an invoice that says "the checkout summarizer cost $14,212 last month." You get a line item per model per day, and you have to reconstruct attribution from your own logs. That reconstruction is the core engineering work of LLM FinOps. Third, the consumers of LLM cost data are not the cloud cost owners. Cloud FinOps usually lives in a platform or infrastructure organisation. LLM cost questions land on FP&A first - because they touch gross margin per customer, not infrastructure budget - and then bounce to the team that owns the gateway. That cross-functional reality is the reason LLM FinOps is treated as its own practice rather than a sub-bullet under cloud FinOps. The four components, in detail 1. Allocation Allocation is the foundation. Every LLM request leaves a structured trace that includes, at minimum: the feature or surface that triggered it, the environment (production, staging, eval, internal), the team that owns the surface, and the customer or workspace it served. Untagged traffic goes to a default bucket with a named owner - not to "unallocated" - so that the bucket itself can be driven to zero over time. Allocation also covers what to do with shared and overhead spend. Eval runs, regression tests, internal copilots, and platform-level retries are all real costs. They should sit in their own allocation buckets so they do not silently inflate the cost of revenue features. FP&A then decides whether to chargeback those buckets, absorb them as platform overhead, or amortise them across product lines. 2. Budgets and forecasts Once spend is attributable, each workload gets a monthly budget. The budget is not aspirational - it is enforced. Soft thresholds page the owning team and trigger a review. Hard thresholds degrade behaviour: drop to a cheaper model, reduce retrieval depth, switch to batch, or queue lower-priority traffic. The point of the budget is not to punish the team that exceeded it but to make sure surprise is rare and explainable. Forecasts use the same allocation primitives in reverse. Given expected request volume per surface, expected token shapes, and the current model mix, FP&A can project next quarter's LLM cost per product line and per customer cohort. That projection becomes an input to pricing, packaging, and gross-margin planning - which is where LLM FinOps starts to matter to the CFO, not just to the platform team. 3. Reconciliation Reconciliation is the monthly close. The internal cost estimate, computed from gateway logs and a maintained price book, is compared line by line to the provider invoice. Deltas are documented. Recurring deltas trigger a fix: a stale price entry, a misclassified cache-read token, a model alias that was silently rerouted, a region surcharge that was never modelled. Without reconciliation, every dashboard in the company drifts. Engineers stop trusting the numbers because they do not match the invoice. Finance stops trusting the numbers because they cannot tie out to anything. Reconciliation is the discipline that keeps both sides on the same set of books. 4. Ownership and chargeback Allocation produces a number per team. Chargeback or showback decides what to do with that number. Chargeback moves the cost to the consuming team's P&L; showback leaves it in a central budget but reports it monthly. Either is fine - what matters is that the consuming team sees its own line and can argue with it. A cost they cannot see is a cost they cannot reduce. Ownership inside a healthy LLM FinOps practice has three roles. A finance partner from FP&A or a dedicated FinOps function owns the model and the close. A platform engineer owns the gateway, the tagging contract, and the price book. An executive sponsor - usually the CFO, sometimes the CTO - chairs the monthly review and breaks ties. LLM FinOps vs AI governance vs AI ethics These terms get bundled in vendor decks and slide titles. They are not the same discipline and they answer different questions. Discipline Core question Deliverables LLM FinOps Who used which model, what did it cost, who pays for it, does the number match the invoice? Allocation report, budget review, reconciliation pack, forecast AI governance Which providers are approved, which use cases blocked, who signs off on premium models, how are decisions logged? Policy, gateway configuration, approval workflow, audit trail AI ethics Are we using AI consistently with our principles around fairness, transparency, and oversight? Principles, review processes, impact assessments The three overlap at the gateway - the same control plane that enforces a governance policy also produces the allocation traces FinOps depends on - but they are run by different people, on different cadences, with different audiences. Conflating them is how programs stall: an ethics review cannot answer a margin question, and a reconciliation pack cannot decide whether a use case is allowed. Who owns LLM FinOps inside a company The honest answer is that ownership is forming in real time at most companies. In the patterns that work, three roles are explicit: The finance owner. Usually an FP&A partner aligned to the product organisation, sometimes a dedicated FinOps lead. They own the allocation model, the monthly close, and the conversation with the CFO. Their unit of analysis is cost per feature, cost per customer, and gross margin per product line. The platform owner. The engineer who runs the AI gateway, the request-logging pipeline, and the price book. They own the tagging contract - what every request must carry - and they enforce it at the gateway. They are the only person who can guarantee that allocation data is reliable, because they are the only person upstream of all of it. The executive sponsor. The CFO or CTO who chairs the monthly review, signs off on budget changes, and resolves disputes between consuming teams. Without a sponsor at this level, budget breaches turn into political fights instead of operational decisions. Smaller companies collapse these roles - a single FinOps-minded platform engineer can carry the first two for a while - but the third role is non-negotiable. LLM FinOps without an executive owner becomes a side project that loses to whichever roadmap item has more visibility. What good looks like A company with a working LLM FinOps practice can answer five questions on any business day, in under five minutes, with numbers that tie out: What did we spend on LLMs last month, broken out by feature, team, and top customer cohort? Which workloads are tracking above or below their monthly budget, and what is the gateway doing about it? What is the gross margin on our top three AI-powered features at current volume, and how sensitive is it to a 20% token-shape change? What was the variance between our internal cost estimate and the provider invoice for the last close, and why? Which un-allocated or shared buckets still exist, who owns them, and what is the plan to drive them to zero? If those answers take a week or a quarter, the practice is on paper, not in production. The goal of LLM FinOps is not to produce a more impressive dashboard. It is to make those five answers boring. What LLM FinOps is not It is not a single tool. Gateways, observability platforms, and BI dashboards are inputs; the discipline is the operating model that uses them. It is not cost-cutting. Reducing LLM spend is a frequent output, but the primary job is attribution and predictability. A team that doubles spend on a profitable feature is doing LLM FinOps correctly. It is not AI governance with a different label. The two share infrastructure but answer different questions to different audiences. It is not finished when the dashboard ships. Model prices change, providers add tiers, cache mechanics shift, and reasoning models reshape token economics. The practice is a standing function, not a project. Where to start Most teams start in the wrong place - they buy a dashboard before they have agreed on a tagging contract, or they set budgets before they have reconciled a single invoice. The order that works is the order of the four components: allocation first, then reconciliation, then budgets, then chargeback. Each step is meaningless without the one before it. A budget on un-allocated spend is a guess. A chargeback on an unreconciled number is a fight waiting to happen. Allocation, reliably, is most of the value. Related AI FinOps - the broader practice LLM FinOps fits inside. FinOps for LLMs - the operating model in more detail. LLM cost attribution - how the allocation layer actually works. LLM budget governance - budgets, quotas, and degradation paths. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is LLM FinOps? LLM FinOps is the operating discipline that turns large-language-model spend into a managed, attributable, reconciled line item. It is the way FP&A, platform engineering, and product teams agree on who used which model, what it cost, who pays for it, and how the internal number reconciles to the provider invoice at month end. What are the four working components of LLM FinOps? The four components are: (1) Allocation - every request tagged to a team, feature, environment, and customer so spend can be traced back to a named owner; (2) Budgets and forecasts - monthly envelopes per workload with a known degradation path; (3) Reconciliation - a monthly close that ties internal usage logs to the provider invoice; (4) Ownership - a named finance partner, platform engineer, and executive sponsor accountable for the number. Why does LLM spend need its own FinOps practice separate from cloud FinOps? LLM spend breaks two key cloud FinOps assumptions: first, the cost driver is the request shape (input tokens, output tokens, cache-read tokens, reasoning tokens) rather than provisioned infrastructure; second, provider invoices arrive aggregated and lagging, requiring reconstruction of attribution from your own logs rather than provider-supplied tags. How does chargeback or showback work in LLM FinOps? Showback reports LLM spend to the teams and products that caused it without moving costs to their budgets. Chargeback assigns that spend to consuming teams' P&Ls. Either approach is valid so long as the consuming team sees its own line and can argue with it. What are the five questions a company with working LLM FinOps can answer in under five minutes? A healthy LLM FinOps practice can answer: (1) What did we spend on LLMs last month, broken out by feature, team, and top customer cohort? (2) Which workloads are tracking above or below their monthly budget? (3) What is the gross margin on our top three AI-powered features? (4) What was the variance between our internal cost estimate and the provider invoice? (5) Which un-allocated or shared buckets still exist and what is the plan to drive them to zero? What is the recommended order for implementing LLM FinOps components? The order that works is: allocation first, then reconciliation, then budgets, then chargeback. Each step is meaningless without the one before it. A budget on un-allocated spend is a guess. A chargeback on an unreconciled number is a fight waiting to happen. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Why does my LLM bill spike? The most common causes · FinOps LLM URL: https://finopsllm.com/research/why-llm-bills-spike Why does my LLM bill spike? Updated 31 May 2026 · first published 31 May 2026 A spike in an LLM bill almost never comes from a price change. It comes from a change in how your code uses the models - a change that often ships in an ordinary pull request, with no line item that says "this will double our token cost." Because providers bill per token and per model , a single deploy can move the bill sharply while request volume stays flat. Here are the causes that show up again and again, roughly in order of how often they catch teams out, and how to catch each one before the invoice does. 1. Model-mix drift Someone changes a default, raises a router threshold, or "temporarily" points a feature at the flagship model to fix a quality complaint - and forgets to point it back. Because the gap between model tiers can be more than 10× per token, shifting even a fraction of traffic up the ladder moves the bill hard. This is the single most common spike. Catch it: track the share of requests per model over time, not just total spend. A change in the mix is the earliest signal, and it shows up before the monthly invoice. 2. A broken cache If you rely on prompt caching, your discount depends on a stable prompt prefix. Change a system prompt, reorder context, or inject a timestamp into the cached region, and the cache-hit rate collapses. Those tokens that used to be billed at a steep discount are now billed at full price - same traffic, much higher cost. Catch it: monitor cache-read token share as a first-class metric. A sudden drop in cache hits is a spike in disguise. 3. Reasoning tokens you can't see Adopting a reasoning model, or raising its reasoning budget, can multiply the cost of a request without changing the visible output at all. The reasoning tokens are billed but never shown, so the spike has no obvious cause in the UI. Catch it: separate reasoning tokens from visible output in your cost data, and treat a reasoning-model rollout as a budgeted change, not a drop-in swap. 4. Retrieval depth crept up In a RAG system, the number and size of retrieved documents go straight into the prompt as input tokens. A relevance fix that bumps top-k from 5 to 20, or a chunk-size change, raises input cost on every single request. It looks like a quality improvement in code review; it looks like a spike on the invoice. Catch it: track average input tokens per request per feature. Retrieval changes show up there immediately. 5. Retries, timeouts, and fallback chains Aggressive retry logic and fallback chains are good for reliability and dangerous for cost. If a primary model starts timing out and every failed call retries on a more expensive fallback, you can pay two or three times for each user request during an incident - and the cost outlives the incident if no one notices. Catch it: count retries and fallback firings, and alert when they rise. A reliability problem and a cost problem are often the same event. 6. A runaway agent loop Agentic workloads call models in loops. A planning bug, a tool that returns noise, or a missing stop condition can send an agent into dozens of model calls for a task that should have taken three. Multiply that across production traffic and the bill moves fast. This is the spike most likely to be a genuine bug rather than a tuning choice. Catch it: cap and monitor calls-per-task, and set spend guardrails on agent workloads specifically. 7. Output length and format changes Raising a max tokens limit, switching to a more verbose response format, or prompting for "detailed" answers increases output tokens - the most expensive token type. A prompt tweak that improves answer quality can quietly raise per-request cost across the board. Catch it: track average output tokens per request and treat prompt changes as cost changes. 8. Real growth (the good kind) Sometimes the bill is up because usage is up - more customers, more requests, a successful launch. That is not a problem to fix; it is a number to attribute. The goal is to be able to say "spend rose 30% because feature X served 40% more requests at a stable cost per request," rather than guessing. A spike you can explain is a spike you can defend. The common thread: you cannot diagnose what you cannot attribute Every cause above is invisible on a dashboard that only shows total spend. They become obvious the moment spend is broken out by feature, model, token type, and cache-hit rate. That breakdown is cost attribution , and it is the difference between "the bill went up and we don't know why" and "the checkout summarizer shifted to the flagship model on Tuesday - here's the fix." Pair attribution with anomaly detection and most spikes are caught within hours, not at month-end. Related How do LLM providers charge? - the pricing mechanics behind every spike. What is LLM cost attribution? - how to trace a spike to its cause. LLM cost anomaly detection - catching spikes before the invoice. How to budget for AI spend - setting envelopes so spikes are bounded. Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → Back to research FAQ What is 1. model-mix drift? Someone changes a default, raises a router threshold, or "temporarily" points a feature at the flagship model to fix a quality complaint - and forgets to point it back. What is 2. a broken cache? If you rely on prompt caching, your discount depends on a stable prompt prefix. Change a system prompt, reorder context, or inject a timestamp into the cached region, and the cache-hit rate collapses. What is 3. reasoning tokens you can't see? Adopting a reasoning model, or raising its reasoning budget, can multiply the cost of a request without changing the visible output at all. The reasoning tokens are billed but never shown, so the spike has no obvious cause in the UI. What is 4. retrieval depth crept up? In a RAG system, the number and size of retrieved documents go straight into the prompt as input tokens. A relevance fix that bumps top-k from 5 to 20, or a chunk-size change, raises input cost on every single request. What is 5. retries, timeouts, and fallback chains? Aggressive retry logic and fallback chains are good for reliability and dangerous for cost. What is 6. a runaway agent loop? Agentic workloads call models in loops. A planning bug, a tool that returns noise, or a missing stop condition can send an agent into dozens of model calls for a task that should have taken three. Multiply that across production traffic and the bill moves fast. Auditing your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit → --- # Security · FinOps LLM · Data Handling and Access Scope URL: https://finopsllm.com/security Security and data handling Read-only billing and usage access by default. No prompt or output review unless explicitly approved for a specific optimization. NDA and DPA available on request before any customer audit. Credential access should be scoped, time-bound, and revocable by the customer. What access an engagement needs The default is read-only billing and usage metadata: invoices, usage exports, and whatever request-level metadata already carries ownership tags. That is sufficient for baseline attribution and for identifying which workloads are worth optimizing. It does not require prompt content, output content, or production database access, and an engagement that asks for those on day one is asking for more than the work needs. When content access is required Some optimizations cannot be evaluated from metadata alone — semantic caching and prompt compression both depend on what is actually being sent. Where that applies, the scope is named in advance for the specific optimization, approved separately, and limited to sampled traffic rather than a standing feed. Approval for one optimization is not approval for the next. Credential handling Scoped. Read-only keys limited to billing and usage endpoints, never account-admin credentials. Time-bound. Access is requested for the duration of the engagement and expected to be revoked at the end, by the customer, without asking us first. Customer-revocable at any time. Nothing in the workflow depends on continuous access; a revoked key stops the work, it does not break anything. Never shared across customers and never used to bootstrap a hosted service the customer did not ask for. Reporting a vulnerability If you find a security issue on this site or in anything we operate, email the address below with enough detail to reproduce it. We will confirm receipt, and we do not pursue researchers who report in good faith and do not access or retain other people's data while doing so. Security contact: hello@finopsllm.com . Back to FinOps LLM --- # Tidal Telemetry · LLM observability, free in beta · FinOps LLM URL: https://finopsllm.com/telemetry Tidal Telemetry Everything else on this site is people doing work on your bill. Tidal Telemetry is software you run yourself. It is free during beta and requires no managed engagement. Contact us to request access while company enrollment is being rolled out. What it is Hosted LLM observability. Install the SDK, call the init function, and every model call your application makes starts arriving as a trace: model, tokens in and out, an estimated cost per call, latency, errors. Instrumentation for common AI libraries. The Python SDK supports OpenAI, Anthropic and popular agent frameworks. Node applications can send standard OTLP traces without a Tidal-specific npm package. Plain OpenTelemetry, so the SDK is optional. Ingest is OTLP over HTTPS with a bearer token. Point any OpenTelemetry exporter at your project endpoint and it behaves identically. The SDK is a thin wrapper over the Apache-licensed OpenLIT SDK. Isolated per-project storage. Each project gets its own database and its own ingest key, enforced at the storage layer rather than by a filter in a query. A built-in MCP server. Agents can verify the setup, send a test trace and pull usage reports directly, which is a faster loop than reading a dashboard. What it costs Nothing, currently. It is in beta and free with no credit card, paid tiers are planned, and beta users keep a free plan when those arrive. That is the actual state of it rather than a launch offer with a countdown attached. How it relates to the engagement Telemetry shows you what your LLMs spend. The FinOps LLM engagement is the work that reduces it, priced on verified savings . The two are cross-promoted and deliberately not bundled. Use Telemetry without a managed engagement. Request access, and our team will explain the current onboarding process. Hire us and never use Telemetry. Audits run against provider billing data - the OpenAI Costs endpoint, the Bedrock CUR, the Vertex BigQuery export - not against our own product. Below the engagement minimum, this is the better answer. Instrument it yourself, read your own numbers, and use the free templates to allocate them. Keeping the two apart is a constraint we put on ourselves for a reason. A cost consultant who also owns the meter has an obvious problem, so every baseline behind every fee comes from raw provider invoices. Existing users can sign in to Tidal . For a new company account, request access . Issued enrollment links are being prepared for rollout. The setup docs cover Python and plain OpenTelemetry. If you want someone to read your invoice and tell you where the money went, request the free audit . Back to FinOps LLM FAQ What is Tidal Telemetry? A hosted LLM observability product from the same team as FinOps LLM. You install an SDK, call one init function, and every model call arrives as a trace with model, token counts, estimated cost, latency and errors attached. Do I have to use Tidal Telemetry to work with FinOps LLM? No, and the reverse is also true. Engagements are measured against your raw provider invoices and whatever tooling you already run. You can request Tidal access without a managed engagement; our team will explain the current onboarding process. What does Tidal Telemetry cost? It is free during the beta with no credit card. Paid tiers are planned, and beta users keep a free plan when they arrive. Do I have to install your SDK to send data? No. Ingest is plain OTLP over HTTPS with a bearer token, so any OpenTelemetry exporter can point at your project endpoint directly. The SDK is a convenience wrapper over the Apache-licensed OpenLIT SDK, not a requirement. --- # Free LLM cost templates · FinOps LLM URL: https://finopsllm.com/templates Free LLM cost templates No email gate, no form, no drip sequence. These are the working artefacts from the first week of a cost audit, published as they are. If they are enough on their own, that is a good outcome. 1. LLM cost allocation sheet Download the CSV - opens in Excel, Numbers or Sheets. One row per month, provider, model and workload, with the columns that make an LLM invoice legible to a budget owner. The layout is opinionated in three ways that matter more than the file itself. Cost per unit of work, not total spend. Total spend rises with growth and says nothing about efficiency. Cost per ticket or per document survives a growth month, which is what makes it trendable. Units delivered is not requests. Retried calls, abandoned sessions and agent loops that hit their step cap bill in full and deliver nothing. They belong in the cost column and not the units column, which is exactly what makes them visible. The quality column is mandatory. A cost per unit that fell alongside accuracy is not a saving, and a sheet that cannot express that will eventually be used to claim one. Reasoning tokens get a separate column because they bill as output on most providers but scale with prompt design rather than response length. Merged into output tokens, the lever disappears. 2. LLM spend policy Download the Markdown - paste into Notion, Confluence or a repo. A policy skeleton with every organisation-specific value left as a bracket: attribution requirements, budgets and thresholds, model selection rules, mandatory cost controls and a review cadence. It covers the five controls that surface in almost every audit - caching on stable prefixes, max_tokens on every call, a capped retry budget, a step cap on agent loops that emits a metric, and batch tiers for anything without a documented latency requirement. The instruction at the top is the important part: delete any section you will not enforce. One decorative clause teaches the reader that the whole document is decorative, and the enforced sections stop working shortly after. What the sheet usually reveals first The row that ends up mattering is normally the one labelled unattributed. Teams arrive expecting the finding to be an expensive model on a cheap task, and the actual finding is that thirty or forty percent of the invoice cannot be assigned to a workload at all. Everything downstream - chargeback, budgets, a routing decision anyone will defend - is blocked until that number comes down, which is why the template asks you to write it in rather than leave the rows out. Filled one in and the numbers look wrong? That is usually attribution rather than arithmetic. The free audit rebuilds the same sheet from your raw provider exports, and the cost calculator will size a single lever in about a minute. Back to FinOps LLM FAQ Do I have to give an email address to download these? No. Both files are static downloads with no form, no gate and no tracking beyond ordinary site analytics. Gating a spreadsheet mostly produces a list of people who wanted a spreadsheet. Why does the allocation sheet track cost per unit instead of total spend? Total spend rises with growth and says nothing about efficiency. Cost per ticket, per document or per conversation survives a growth month, which makes it the only figure worth trending over time. Can I use these templates commercially without attribution? Yes. Use them internally, adapt them, put them in your own handbook. There is no licence to accept and no attribution requirement attached to either file. --- # Terms of Use · FinOps LLM · Site and Engagement Terms URL: https://finopsllm.com/terms Terms This website describes the FinOps LLM concept and related audit services. Any customer engagement requires a separate written agreement, statement of work, NDA, and data-processing terms where applicable. Website content is provided for informational purposes and does not guarantee savings, security certification, or provider pricing. Use of this site You may read, quote, and link to anything published here. Please attribute quotes and link back rather than republishing pages in full. Automated access is fine within the limits set in our robots.txt; scraping at a rate that degrades the site for other readers is not. No advice, no guarantee Everything on this site — research notes, benchmarks, calculators, and checklists — is general information, not financial, legal, tax, or engineering advice for your situation. Provider pricing, model behavior, and rate limits change frequently and without notice; figures shown here may be out of date by the time you read them. Verify anything cost-relevant against the provider's current published pricing and your own invoices before making a decision that depends on it. Tools and calculators The calculators on this site produce estimates from the inputs you provide. They do not account for retries, cache behavior, rate-limit backoff, discounts, or committed-use terms unless you enter those yourself, and they are not a quote. Nothing they output creates any obligation on either side. Engagements Nothing on this site is an offer, and reading it creates no client relationship. Any engagement is governed exclusively by a separate written agreement covering scope, fees, confidentiality, data processing, and liability. Where those terms conflict with anything here, the signed agreement controls. Third-party links and changes Links to provider documentation and other external sites are offered for convenience; we do not control or endorse their content. These terms may be updated, and the version published here is the one that applies. Continued use of the site after a change means you accept the updated version. Questions: hello@finopsllm.com . Back to FinOps LLM --- # LLM API Pricing: OpenAI, GPT-6 & Claude Prices · FinOps LLM URL: https://finopsllm.com/tools/llm-api-pricing-tracker FREE TOOL · LIVE PRICES LLM API Pricing Tracker. OpenAI API pricing and Claude API pricing, per million tokens, pulled live from each provider's own pricing page. Input, output, cache-read, and cache-write rates for GPT-6 Astra, Sol and Luna, GPT-5.6, Claude Opus 5.5, Fable 5.1, Sonnet 5 and Haiku 4.5. New OpenAI and Anthropic models appear here as soon as they are listed. All models Model Provider Input / 1M Output / 1M Cache read / 1M Cache write / 1M Context Updated Why list prices don't predict your bill The per-million-token numbers in this table are the starting point of a cost estimate, not the estimate. Four things move the real figure, usually by more than the gap between two providers on this page. Cache reads. Where a provider supports prompt caching, cached input tokens bill at a fraction of the list price. A workload with a large fixed system prompt and a high hit rate pays an effective input price far below the number shown here. Output-heavy work. Output tokens cost several times input tokens on every provider. A model that looks cheap on input and expensive on output is cheap for retrieval-augmented answers and expensive for long-form generation. Retries and fallbacks. Every retry bills again. A model with a lower price and a higher failure rate on your task can cost more per completed request than the more expensive one. Reasoning tokens. Models that think before answering bill those tokens at the output rate, and the count is not visible in the prompt you wrote. Budget from measured usage, not from expected response length. How often do these prices change? Less often than model availability, but often enough that a quarterly review is the minimum. Providers cut prices when competitors do, introduce cheaper tiers of existing models, and deprecate older ones with a migration window. The practical consequence is that routing rules and budget assumptions both go stale — a routing table written six months ago is usually still correct and occasionally sending traffic to a model that is no longer the cheapest option that clears your quality bar. Context windows are a ceiling, not a target The context column shows the maximum a model accepts. It is not a budget to fill. Cost scales with what you actually send, and retrieval that grows context faster than it improves answers is one of the most common causes of a bill that rises without the product getting better. Measure the p95 context length you send in production; that number, not the ceiling, is what your invoice reflects. How we track prices OpenAI and Anthropic prices are read from the providers' published pricing pages at most six hours old; any model either provider lists is picked up automatically, and a parse that fails sanity checks falls back to the last verified table. Google, Meta, Mistral and DeepSeek rows are maintained by hand. Cache prices apply only where providers support prompt caching. Context windows are maximum supported; effective context may be lower for reasoning models. Last updated: — Related AI model release tracker — new models and announced retirements LLM cost calculator — calculate costs for your workload How much does GPT-5 cost? — pricing analysis LLM API pricing tracker research — methodology Provider arbitrage — when to switch providers ← Back to finopsllm.com --- # LLM Cost Calculator · Compare Provider Pricing · FinOps LLM URL: https://finopsllm.com/tools/llm-cost-calculator FREE TOOL LLM Cost Calculator. Compare costs across providers for your exact workload. Input your token usage, see live estimates for every current OpenAI and Anthropic model, GPT-6 and Claude Opus 5.5 included. Your workload Input tokens per request System prompt + user message Output tokens per request Expected response length Requests per day Daily volume Cache hit rate (%) 0 = no caching, 70 = aggressive caching Cost comparison Model Provider Cost per 1K requests Daily cost Monthly cost vs cheapest How to read the comparison The monthly figure this calculator produces is a floor, not a forecast. It assumes every request succeeds on the first attempt, that your input and output lengths hold steady, and that traffic is flat across the month. Real workloads violate all three. Treat the output as a way to compare models against each other under identical assumptions — which is what it is good for — rather than as a number to put in a budget. What the estimate leaves out Retries and fallbacks. Add your measured retry rate on top. A 15% retry rate is a 15% cost increase that no per-token comparison shows. Reasoning tokens. For models that reason before answering, the billed output exceeds the visible response, sometimes by several times. Enter measured output tokens rather than expected answer length. Traffic shape. Cost distributions have long tails — a small share of requests with large contexts often drives most of the bill. A single average request understates that; run the calculator once at your median and once at your p95 to see the spread. Discounts and batch pricing. Committed-use terms and batch endpoints change the effective rate substantially for eligible work, and neither is reflected in list prices. What cache hit rate should you enter? If you have not enabled prompt caching, enter zero — the default — because that is what you are paying today. If you have, use your measured hit rate rather than an aspiration. Rates depend almost entirely on workload shape: a large fixed system prompt with short variable user input caches well, while retrieval that injects different chunks on every call caches poorly no matter how the request is structured. Entering 70% because a vendor page mentioned it produces a confident number describing a system you do not operate. Using this to make a routing decision Cost alone cannot pick a model. Set the quality floor first — the eval your task has to pass — then compare cost only among the models that clear it. A model that halves the cost and fails one request in twenty has not saved anything once the retry, the latency, and the support ticket are counted. Run the comparison, pick the two or three candidates that are plausible, and A/B them on real traffic before changing the routing rule. Methodology Prices are standard-tier list prices from the same live feed as the LLM API pricing tracker , last updated 2026-09-23 . New models appear automatically. Cache-read tokens are discounted where applicable. Actual costs vary based on retries, latency requirements, and volume discounts. This calculator is for estimation only. For a precise audit of your actual spend, book a free audit . Related LLM API pricing tracker — daily updated prices How much does GPT-5 cost? — pricing analysis Model routing — when to use which model Prompt caching economics — calculate caching ROI ← Back to finopsllm.com --- # AI Model Release Tracker: New GPT & Claude Models · FinOps LLM URL: https://finopsllm.com/tools/llm-release-tracker FREE TOOL · WHAT SHIPPED, WHAT'S LEAVING AI Model Release Tracker. Every new model the major labs have put into production in the last 45 days, with the price you would actually pay, and every model they have announced they are switching off. Two lists, because the second one is the one that reaches your invoice unannounced. All labs Alibaba DeepSeek OpenAI Google Tencent Z.ai ByteDance Meta Xiaomi Aion Labs Anthropic InclusionAI Sakana Baidu Cohere MiniMax Upstage xAI Snapshot 2026-09-27 New in the last 45 days 40 models A model appears here the day it first became purchasable through a public router. It usually trails the lab's own announcement by a few days. Prices are USD per 1M tokens, straight from the router's rate card. First available Model Lab Input / 1M Output / 1M Context 2026-09-23 z-ai/glm-5.3-prime Z.ai $2.8 $8.8 1M 2026-09-23 upstage/solar-mini4 Upstage $0.05 $0.2 524K 2026-09-23 qwen/qwen3.8-max-prime Alibaba $4 $12 1M 2026-09-23 aion-labs/aion-3.5-mini Aion Labs $0.7 $1.4 262K 2026-09-23 aion-labs/aion-3.5 Aion Labs $3 $6 262K 2026-09-22 openai/gpt-6-sol-pro OpenAI $2 $10 1.05M 2026-09-22 openai/gpt-6-sol OpenAI $2 $10 1.05M 2026-09-22 openai/gpt-6-luna-pro OpenAI $0.1 $0.5 1.05M 2026-09-22 openai/gpt-6-luna OpenAI $0.1 $0.5 1.05M 2026-09-22 cohere/command-a-plus Cohere $0.3 $1.5 192K 2026-09-22 anthropic/claude-opus-5.5 Anthropic $4 $20 1M 2026-09-21 xiaomi/mimo-v2.6-pro-ultraspeed Xiaomi $4.35 $8.7 1.05M 2026-09-21 xiaomi/mimo-v2.6-pro Xiaomi $0.435 $0.87 1.05M 2026-09-21 xiaomi/mimo-v2.6-flash Xiaomi $0.14 $0.28 1.05M 2026-09-21 x-ai/grok-4.7 xAI $1.6 $4.8 500K 2026-09-21 qwen/qwen3.8-omni-flash Alibaba $0.15 $0.47 1M 2026-09-18 z-ai/glm-5.3-flashx Z.ai $0.37 $1.25 1.05M 2026-09-11 sakana/fugu-ultra-v2 Sakana $5 $30 1M 2026-09-11 sakana/fugu-max Sakana $2 $6 1M 2026-09-10 inclusionai/ling-3.0-flash-vl InclusionAI $0.021 $0.0616 262K 2026-09-10 deepseek/deepseek-v4.1-flash DeepSeek $0.035 $0.29 1.05M 2026-09-04 openai/gpt-6-astra-pro OpenAI $10 $50 1.05M 2026-09-04 openai/gpt-6-astra OpenAI $10 $50 1.05M 2026-09-03 qwen/qwen3.8-max-0902 Alibaba $2 $6 1M 2026-09-02 meta/muse-spark-1.3-contributor Meta $0.1 $0.2 1.05M 2026-09-02 meta/muse-spark-1.3 Meta $1.25 $4.25 1.05M 2026-09-02 google/gemini-3.8-flash Google $0.75 $3.75 1.05M 2026-09-01 anthropic/claude-fable-5.1 Anthropic $10 $50 1M 2026-08-28 tencent/hy4-preview Tencent $0.834 $2.501 1.05M 2026-08-27 inclusionai/ling-3.0-flash-fin InclusionAI $0.06 $0.18 262K 2026-08-26 z-ai/glm-5.3-flash Z.ai $0.045 $0.14 1.31M 2026-08-26 qwen/qwen3.8-flash Alibaba $0.15 $0.47 1M 2026-08-21 meta/muse-spark-1.2-contributor Meta $0.1 $0.2 1.05M 2026-08-21 deepseek/deepseek-v4-flash-vision-exp DeepSeek $0.2156 $0.6468 1.05M 2026-08-20 tencent/hy-mt2-30b-a3b Tencent $0.074 $0.295 8K 2026-08-20 tencent/hy-mt2-1.8b Tencent $0.044 $0.177 8K 2026-08-19 tencent/hy-mt2-7b Tencent $0.074 $0.295 8K 2026-08-18 z-ai/glm-5.3 Z.ai $1.4 $4.4 1.31M 2026-08-14 qwen/qwen3.8-27b Alibaba $0.42 $3 1M 2026-08-13 google/gemini-3.7-flash Google $0.75 $3.75 1.05M No models from that lab in this window. Announced retirements 26 models Dates a lab or router has published for switching a model off. A model on this list is not deprecated-yet: on the date shown, calls to it start failing. Price is included so the replacement can be costed in the same column. Switch-off date In Model Lab Input / 1M Output / 1M 2026-09-28 1d deepseek/deepseek-v3.2 DeepSeek $0.269 $0.4 2026-09-28 1d deepseek/deepseek-v3.2-exp DeepSeek $0.27 $0.41 2026-09-28 1d deepseek/deepseek-v3.1-terminus DeepSeek $0.27 $1 2026-09-28 1d deepseek/deepseek-r1-distill-llama-70b DeepSeek $0.8 $0.8 2026-10-08 11d minimax/minimax-m2.1 MiniMax $0.3 $1.2 2026-10-08 11d baidu/ernie-4.5-vl-424b-a47b Baidu $0.42 $1.25 2026-10-09 12d qwen/qwen3.6-max-preview Alibaba $1.027 $6.162 2026-10-09 12d qwen/qwen3-max-thinking Alibaba $0.78 $3.9 2026-10-09 12d qwen/qwen3-vl-32b-instruct Alibaba $0.104 $0.416 2026-10-09 12d qwen/qwen3-vl-8b-thinking Alibaba $0.18 $2.1 2026-10-09 12d qwen/qwen3-vl-8b-instruct Alibaba $0.117 $0.455 2026-10-09 12d qwen/qwen3-vl-30b-a3b-thinking Alibaba $0.2 $2.4 2026-10-09 12d qwen/qwen3-vl-235b-a22b-thinking Alibaba $0.4 $4 2026-10-09 12d qwen/qwen3-max Alibaba $0.78 $3.9 2026-10-09 12d qwen/qwen3-coder-plus Alibaba $0.65 $3.25 2026-10-09 12d qwen/qwen-plus-2025-07-28 Alibaba $0.26 $0.78 2026-10-09 12d qwen/qwen3-30b-a3b-thinking-2507 Alibaba $0.2 $2.4 2026-10-09 12d qwen/qwen3-235b-a22b-thinking-2507 Alibaba $0.23 $2.3 2026-10-09 12d qwen/qwen3-8b Alibaba $0.117 $0.455 2026-10-09 12d qwen/qwen3-235b-a22b Alibaba $0.455 $1.82 2026-10-20 23d google/gemini-2.5-flash-lite Google $0.1 $0.4 2026-10-20 23d google/gemini-2.5-flash Google $0.3 $2.5 2026-10-20 23d google/gemini-2.5-pro Google $1.25 $10 2026-11-11 45d bytedance-seed/seed-2.0-code ByteDance $0.5 $3 2026-11-11 45d bytedance-seed/seed-1.6-flash ByteDance $0.075 $0.3 2026-11-11 45d bytedance-seed/seed-1.6 ByteDance $0.25 $2 Nothing announced for that lab. Why the second table is the one that costs you A new model is a decision. A retirement is an event, and it arrives whether or not anyone on your team was watching. Three things break quietly on a switch-off date: Routing rules. A load balancer or fallback chain that still references the retired id returns errors for that slice of traffic. If the fallback was never load-tested, the retry path becomes the primary path and your latency bill follows. Evaluation baselines. Any score, prompt or guardrail tuned against the old model's behaviour is now measuring a system that no longer exists. Regression alerts that fire afterwards are noise, and the ones that don't fire are worse. Prompts tuned to a context window. A replacement with a smaller ceiling truncates mid-document. The failure is a plausible answer built on half the input, which is far more expensive to catch than an error. The cheapest time to price a replacement is before the switch-off date, while the old model still runs and you can measure both side by side on real traffic. That is the whole argument for keeping this list rather than reading about it after the fact. How we build this Both tables come from one public model feed that lists every served model with the timestamp it first appeared and, where a switch-off has been announced, the date it ends. The filter keeps first-party models only: third-party routers, quantised mirrors and anonymous drops all carry timestamps but are not a lab shipping anything, and :batch or :free entries are the same weights behind a different endpoint, so they are dropped as duplicates of a row already here. Named tiers such as -pro are kept, because they are separate price points and choosing between them is the reason to be on this page. Two dates matter and they are not the same date. 2026-09-27 is when this page's table was generated. The live feed behind it is at most six hours old and is checked when you load this page; a new model found in the live check is added to the top of the table and marked. Prices come from the router's rate card for that model, which is what you would be billed, and a model whose lab has not published a price shows a dash rather than a number. What this page cannot tell you is what a lab said, or on what date they said it. For the announcement itself — the reasoning behind a price, the scope of a deprecation, the caveat on a benchmark — read the lab's own newsroom and social accounts. This is the operational layer underneath those posts: what is purchasable, what it costs, and what is about to stop working. Related LLM API pricing tracker — full rate cards for every model listed here Trending AI models — what the current releases actually score on Silent model downgrades — when quality moves without a price change Committed spend and procurement — locking in before a repricing LLM cost calculator — cost a workload on a specific model ← Back to finopsllm.com --- # 网络搜索正在成为智能体的新成本中心 · FinOps LLM URL: https://finopsllm.com/zh/research/agent-web-search-cost-center 网络搜索正在成为智能体的新成本中心 更新于 September 10, 2026 · 首次发布 September 10, 2026 快速结论: 当智能体从静态知识库转向实时网络调研时，原本隐蔽的搜索请求已演变为显性的计费大户。以 AWS Bedrock AgentCore 为例，每千次搜索均有独立标价。单次用户提问可能引发数轮重写搜索与上下文解析，FinOps 团队必须将工具调用与 Token 消耗合并审计。 当智能体从静态知识库转向实时网络调研时，原本隐蔽的搜索请求已演变为显性的计费大户。以 AWS Bedrock AgentCore 为例，每千次搜索均有独立标价。单次用户提问可能引发数轮重写搜索与上下文解析，FinOps 团队必须将工具调用与 Token 消耗合并审计。 相关文章 按成功任务核算成本 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # AI功能上线前必须测算的毛利率模型 · FinOps LLM URL: https://finopsllm.com/zh/research/ai-feature-gross-margin AI功能上线前必须测算的毛利率模型 更新于 September 2, 2026 · 首次发布 September 2, 2026 快速结论: 大模型在线推理是服务交付成本（Cost of Goods... 大模型在线推理是服务交付成本（Cost of Goods Sold），绝非研发资本化开支。它随着客户的每次真实操作持续触发，与业务用量严格线性绑定，并最终体现在生产基础设施账单中。如果直到功能上线前都将其计入研发成本，那么真正的毛利率数据就只能等首个完整账单周期揭晓——而那是发现利润塌陷最糟糕的时机。 在上线前而非上线后埋点 在预发（Staging）环境中，必须将每次模型调用打上租户账户、业务流以及最终交付结果的元数据标签，并回放高度拟真的真实流量，而非简单的虚构压测循环。你需要的是完整的统计分布：p50、p90与p99分位数下的单次成功任务成本，以及即使失败也必须付费的重试损耗比例。单一的平均值会彻底抹平那些击穿毛利的极端重度客户。 汇总为单租户月度成本 将单次成功任务成本乘以每个账户预期的月任务量，并加上无效重试的沉没损耗。将该测算值与订阅套餐价格直接对比。分别在用量中位数、第90百分位以及系统可承受的最重度极端账户三个切片进行核算。固定订阅价格模式往往在用量长尾处彻底失效，因为收入停滞时Token支出却在无上限膨胀。 四大关键成本动因 每轮重复发送的上下文： 超长对话历史或检索生成（RAG）召回的大文档在每个交互回合都会被重新计费，除非配置了高效的提示词前缀缓存。 失败与重试浪费： 云厂商对失败的API调用同样全额收费，它们属于真实的成本分子，绝不能在错误预算中被一笔勾销。 智能体多步并发扇出： 单个用户操作可能裂变为海量的模型和工具调用，这一倍数在不同客户习惯间差异极大。 默认模型路由策略： 将简单问答无差别路由至顶级高价推理模型，是团队最容易治理却最常忽视的单项失控源头。 将测算指标落实为商业决策 在正式发布前，基于测算做出明确的商业或架构决策：在套餐中引入阶梯用量硬顶、增加基于用量的按需加价包、将默认模型降级为经济型并在复杂场景动态升级，或确立经管理层特批的阶段性毛利目标并设立复盘日期。 相关文章 成功任务单价 免费层是客户获取成本 重试循环与隐性支出 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # AI支出差异分析：用量、单价、结构与效率 · FinOps LLM URL: https://finopsllm.com/zh/research/ai-spend-variance-bridge AI支出差异分析：用量、单价、结构与效率 更新于 August 27, 2026 · 首次发布 August 27, 2026 快速结论: AI支出差异分析只有在驱动具体工程行动时才有价值。将预测与实际账单的差额拆解为四大原因：用量、单价、结构和效率，并将每一项与账单、遥测和负责人挂钩，避免重复计算。用量 (Volume)用量反映业务需求：请求数、用户数、处理Token或工作流数量。若用量是主因，应更新容量与业务增长预期，而非归咎工程团队。单价... AI支出差异分析只有在驱动具体工程行动时才有价值。将预测与实际账单的差额拆解为四大原因： 用量 、 单价 、 结构 和 效率 ，并将每一项与账单、遥测和负责人挂钩，避免重复计算。 用量 (Volume) 用量反映业务需求：请求数、用户数、处理Token或工作流数量。若用量是主因，应更新容量与业务增长预期，而非归咎工程团队。 单价 (Rate) 单价是单位Token的实际计费价格，包含折扣、阶梯费率或预付承诺。只有在实际发票生效的费率才应计入测算。 结构 (Mix) 结构反映模型和工作流组合的迁移：不同模型规格、云厂商、地域或推理模式（如批处理与实时）。调用量不变但迁移至推理模型会导致成本大幅上升。 效率 (Efficiency) 效率指交付同一有效成果所需的成本，涵盖Prompt膨胀、重试、降级策略、工具调用扩展与人工介入修复。必须结合任务成功率与质量评估，避免将输出质量劣化误判为降本。 构建分析桥梁 从上期预算出发，依次代入单价、用量、结构与效率影响，并核对残差项。每一项差异均应明确量化金额、责任人和路由策略优化方案。 相关文章 LLM成本监控 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # Azure OpenAI对比直接OpenAI成本深度分析 · FinOps LLM URL: https://finopsllm.com/zh/research/azure-openai-vs-direct-cost Azure OpenAI对比直接OpenAI：成本、PTU与企业TCO 更新于 September 19, 2026 · 首次发布 July 12, 2026 快速结论: 在标准的全球按量付费（Pay-as-you-go）模式下，Azure OpenAI 与直接调用 OpenAI API 的刊例价完全一致（例如旗舰模型输入每百万Token收费2.50美元，输出15美元）。企业账单上的核心经济差异并不在于标准调用单价，而在于三大结构性杠杆：PTU预置吞吐量单元（Provisioned Throughput... 在标准的全球按量付费（Pay-as-you-go）模式下，Azure OpenAI 与直接调用 OpenAI API 的刊例价完全一致（例如旗舰模型输入每百万Token收费2.50美元，输出15美元）。企业账单上的核心经济差异并不在于标准调用单价，而在于三大结构性杠杆： PTU预置吞吐量单元（Provisioned Throughput Units） 、 区域数据主权溢价 以及 微软企业协议（EA/MACC）抵扣折扣 。 1. PTU专享容量预留对比按量Token Azure的核心优势在于通过PTU提供独占的模型推理吞吐量。按需调用时单个PTU为每小时2美元；若按月签订预留合约，折合每月约260美元——相较按需单价享受 高达82%的折扣 （若签订1年期合约折扣高达85%）。 PTU预留的经济盈亏平衡点通常位于 全天候平均产能利用率持续高于65%–75% 。如果业务负载起伏巨大或夜间无调用，按量计费反而更加划算。 2. 区域数据合规溢价 全局端点价格与美国标准价格对齐，但如果企业要求将数据严格保留在西欧或特定合规主权区域，微软会收取 10%至20%的区域溢价 。合规成本必须纳入FinOps测算。 3. 隐藏的企业网络与基础设施成本 在Azure中调用模型通常伴随着Private Endpoint私网连接、Log Analytics安全日志和虚拟网络出网流量费。这些外围开销使有效Token成本上浮约4%至8%，但换来了企业级RBAC权限与网络隔离合规。 相关文章 承诺支出折扣指南 为什么供应商价格无法直接对比 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # 后台智能体正在重塑 FinOps 成本时钟 · FinOps LLM URL: https://finopsllm.com/zh/research/background-agents-cost-clock 后台智能体与 FinOps 成本时钟 更新于 September 10, 2026 · 首次发布 September 10, 2026 快速结论: 后台异步执行彻底打破了传统的即时交互计费边界。当用户合上笔记本后，自主智能体仍会在云端继续循环拆解任务、调用工具与重试。若缺乏任务维度的硬性预算与执行超时封顶，几行死循环逻辑就能在无人值守的深夜产生惊人的推理账单。 后台异步执行彻底打破了传统的即时交互计费边界。当用户合上笔记本后，自主智能体仍会在云端继续循环拆解任务、调用工具与重试。若缺乏任务维度的硬性预算与执行超时封顶，几行死循环逻辑就能在无人值守的深夜产生惊人的推理账单。 相关文章 自主智能体的三层预算模型 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # Claude Opus 5.5：$4/$20 和 $0.20 缓存读取 · FinOps LLM URL: https://finopsllm.com/zh/research/claude-opus-5-5-cost-model Claude Opus 5.5 成本模型 更新于 September 22, 2026 · 首次发布 September 22, 2026 Anthropic 在 2026 年 9 月 22 日发布了 Claude Opus 5.5（ claude-opus-5-5 ）。标题价格是每百万输入令牌 $4，每百万输出令牌 $20，下降自 Opus 5 的 $5 和 $25。这是 20% 的削减。对于大多数生产工作负载，实际削减更大，因为下降最多的速率是标题排除的速率。 重要的费率 令牌类型 Opus 5.5 Opus 5 Fable 5.1 输入（未缓存） $4.00 / MTok $5.00 / MTok $10.00 / MTok 输出 $20.00 / MTok $25.00 / MTok $50.00 / MTok 缓存写入（5 分钟） $5.00 / MTok $6.25 / MTok $12.50 / MTok 缓存读取 $0.20 / MTok $0.50 / MTok $0.25 / MTok 快速模式（输入/输出） $8 / $40 — — 除了缓存读取降低 60% 外，每一行都降低 20%。在 $0.20 时，现在比 Fable 5.1 的 $0.25 更便宜。这逆转了 Fable 曾经赢的那一行。在我们的 Fable 5.1 成本模型 中，缓存繁重的工作负载在 Fable 上可能比在 Opus 5 上更便宜。对于 Opus 5.5，情况不再如此。Fable 在每种令牌类型上的成本都更高。 为什么典型任务便宜约 40% Anthropic 的声称是典型工作的成本降低 40%，而不是 20%。额外的来自令牌效率。Anthropic 说 Opus 5.5 用大约 20% 更少的输入和输出令牌达到相同的结果，并写大约 40% 冗余性更少的输出。较低的费率乘以较少的令牌会复合：0.8 × 0.8 = 0.64，这大约是 36-40% 的折扣，取决于混合。 这是一个代理步骤：200,000 输入令牌，90% 从缓存服务，20,000 输出令牌。 行 Opus 5 Opus 5.5（相同令牌） Fable 5.1 20K 未缓存输入 $0.100 $0.080 $0.200 180K 缓存输入 $0.090 $0.036 $0.045 20K 输出 $0.500 $0.400 $1.000 总计 $0.690 $0.516 $1.245 在相同令牌上，Opus 5.5 由于缓存折扣比 Opus 5 便宜 25%，而不是 20%。如果 20% 令牌削减适用于您的工作负载，该步骤下降到约 $0.41，这比 Opus 5 低 40%，是 Fable 成本的三分之一。输出仍然是此示例中账单的约 80%。这是冗余性削减的收益所在。 与 GPT-6 Sol、GPT-6 Astra 和 Fable 5.1 的每任务成本对比 每百万 token 的标价,以及上文同一个 agent 步骤(输入 200K,其中 90% 命中缓存,输出 20K)在各模型上的价格。 模型 输入 $/MTok 输出 $/MTok 缓存读取 $/MTok 同一 agent 步骤 GPT-6 Sol $2.00 $10.00 $0.20 $0.276 Claude Opus 5.5 $4.00 $20.00 $0.20 $0.516 Claude Opus 5 $5.00 $25.00 $0.50 $0.690 Claude Fable 5.1 $10.00 $50.00 $0.25 $1.245 GPT-6 Astra $10.00 $50.00 $1.00 $1.380 在 Artificial Analysis Intelligence Index v4.3.2 上实测的每任务成本(读取于 2026 年 9 月 22 日,按得分排序)。47.5 分以内,GPT-6 Sol 是最便宜的选择。高于此分数,Opus 5.5 在每个档位都最便宜:Opus 5.5 high 以 1.82 美元拿到 53.6 分,而 GPT-6 Astra max 以 3.26 美元拿到 52.7 分,Fable 5.1 max 以 7.63 美元拿到 53.4 分。 模型 Intelligence Index 每任务成本 每任务输出 token GPT-6 Sol · medium 39.8 $0.25 6,500 GPT-6 Sol · xhigh 44.1 $0.53 16,000 GPT-6 Astra · low 45.8 $0.82 4,400 GPT-6 Sol · max 47.5 $1.06 31,200 Claude Opus 5 · high 48.1 $3.61 46,200 Claude Opus 5 · max 50.8 $5.86 72,500 Claude Opus 5.5 · medium 51.2 $1.34 25,700 Claude Fable 5.1 · high 51.2 $3.91 38,100 GPT-6 Astra · max 52.7 $3.26 27,200 Claude Fable 5.1 · max 53.4 $7.63 78,100 Claude Opus 5.5 · high 53.6 $1.82 35,600 Claude Opus 5.5 · max 57.6 $5.98 119,200 GPT-6 Astra 高于 low 的所有设置、Opus 5 的所有设置以及 Fable 5.1 的所有设置,都比得分相同或更高的 Sol 或 Opus 5.5 设置更贵。每任务成本取决于基准测试的任务构成。切换模型前请用自己的流量回放验证。 它足以取代 Fable 吗？ Anthropic 将 Opus 5.5 定位为在大多数任务上与 Fable 5.1 匹配。已发布的数字支持编码和代理工作： Terminal-Bench 4.0: 66.4%，相比 Opus 5 52.3% 和 Fable 5.1 55.8%。 FrontierCode v1.1: 54.4%，相比 Opus 5 48.0% 和 Fable 5.1 50.3%。 CursorBench 4.0: 57.8%，相比 Opus 5 46.6%。 GDPval-AA v2.1: 1846 Elo，相比 Opus 5 1708。 Artificial Analysis 在发布当天在其 Intelligence Index 上排名第一。Anthropic 还表示，在默认（中等）努力下，它在知识工作中击败每项任务成本约五分之一的 GPT-6 Astra 最大努力。这是供应商比较，因此请将其视为要测试的假设。上面的成本数学是您可以自己验证的部分。 快速模式成本 2× 快速模式成本 $8 输入和 $40 输出，恰好是标准费率的两倍，速度最高可达 2.5×。标准模型也比 Opus 5 快约 30%。对于延迟受限的交互式路径，其中用户正在等待时，使用快速模式。将其从批处理作业、后台代理和评估中保留。启用快速模式作为默认时，单位成本翻倍，仪表板在发票到达之前显示任何异常。 本周做什么 固定模型 ID。 将生产明确指向 claude-opus-5-5 并在每个请求上记录 ID，以便迁移后可按模型拆分每个请求的成本。 在您自己的流量上重新基线。 在两个模型上重放实际请求的样本，并比较每个完成任务的令牌，而不是每个调用。20% 令牌效率声称是最可能因工作负载而异的部分。 重新检查努力设置。 如果工作负载转移到 Fable 或最大努力以获得质量，请先在中等级别测试 Opus 5.5。这是 Anthropic 基准测试的设置。 重新运行 Fable 路由决定。 任何将缓存繁重流量发送到 Fable 以获得更便宜缓存读取的路由都应重新评估。该成本优势消失了。 监视缓存命中率。 在 $4.00 的 $0.20 处，缓存未命中现在花费命中的 20 倍。打破前缀的提示模板更改比在 Opus 5 上花费的成本更高。 Anthropic 表示 Sonnet 5.5 和 Haiku 5.5 将在接下来的几周内推出。从第 2 步保持重放线束，以便可在午后重新基线每个发布。 相关文章 Claude Fable 5.1 成本模型 提示缓存经济 Opus 5.5 努力水平是真正的价格 Opus 5.5 快速模式经济 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # 成功任务单价优于单次请求成本 · FinOps LLM URL: https://finopsllm.com/zh/research/cost-per-successful-task 成功任务单价优于单次请求成本 更新于 August 27, 2026 · 首次发布 August 27, 2026 快速结论: 单次请求成本指标固然有用，但它不是最终客户采购的工作单元。一次失败报错、经历三次重试或生成不可用结果的请求，不能算作有效交付。在生产环境AI系统中，更稳健的核心指标是成功任务单价：将全部模型与工具调用支出除以满足预定质量阈值的成功任务数。核心指标公式计算公式为：单次成功任务成本 = 全部可归因支出 /... 单次请求成本指标固然有用，但它不是最终客户采购的工作单元。一次失败报错、经历三次重试或生成不可用结果的请求，不能算作有效交付。在生产环境AI系统中，更稳健的核心指标是 成功任务单价 ：将全部模型与工具调用支出除以满足预定质量阈值的成功任务数。 核心指标公式 计算公式为： 单次成功任务成本 = 全部可归因支出 / 成功任务总数 。分子需涵盖输入、输出、上下文缓存、思考推理Token、工具调用、失败重试及备选路由成本。在统计前必须先明确定义成功：例如用户接受客服回答、分类置信度达标、或无需人工介入修复即可闭环的业务流程。 单次请求平均值的误导性 当系统中充斥着低成本但无效的失败尝试时，单次请求平均成本反而会显得“便宜”。它还会彻底掩盖昂贵的长尾异常：某项功能的中位数请求成本可能极低，但其失败用例却消耗了大量高阶推理调用和人工审核工时。建议按功能、模型、客户分群和交付结果细分，并同步报告p50和p95成功任务单价与任务完成率。 精确埋点与分母度量 每个模型调用Span都应绑定唯一请求ID与功能标签；应用程序必须在任务终态发出关联该ID的结果事件。记录成功状态、失败归因、人工修正标记、端到端延迟及业务价值。将云厂商发票对齐分子，并定期抽样已交付任务以验证分母的真实性。 依据指标驱动系统优化 如果请求单价偏高但成功率稳定，应重点引入语义缓存或轻量模型路由。如果请求单价很低但成功任务单价极高，说明质量存在缺陷：频繁重试、弱模型推理失败、缺少上下文或停止条件不合理。始终优化包含失败代价的真实成本，并确保质量SLO不出现回退。 相关文章 LLM成本监控 单次请求成本产品KPI LLM成本归因 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # 切换LLM供应商的真实成本与投资回收测算 · FinOps LLM URL: https://finopsllm.com/zh/research/cost-switching-llm-providers 切换LLM供应商的真实成本与投资回收测算 更新于 August 27, 2026 · 首次发布 August 27, 2026 快速结论: 切换LLM供应商绝不仅是价目表的对比。真实的商业论证必须计入工程迁移、Prompt与Schema调整、评测验证、双轨运行、数据传输及输出质量下降风险。将这些综合支出与迁移回收期内的预期月度节省进行严格比对。清点工程迁移工作量全面盘点SDK调用、结构化输出格式、工具声明、速率限制、上下文窗口表现与错误处理机制，精确评估研发与测试工时。API网关虽能降低未来切换阻力，但其自身运行亦是持续成本。量化质量... 切换LLM供应商绝不仅是价目表的对比。真实的商业论证必须计入工程迁移、Prompt与Schema调整、评测验证、双轨运行、数据传输及输出质量下降风险。将这些综合支出与迁移回收期内的预期月度节省进行严格比对。 清点工程迁移工作量 全面盘点SDK调用、结构化输出格式、工具声明、速率限制、上下文窗口表现与错误处理机制，精确评估研发与测试工时。API网关虽能降低未来切换阻力，但其自身运行亦是持续成本。 量化质量评估成本 在旧与新模型上运行固定测试集，精确度量任务成功率、p50与p95延迟、重试次数及人工介入审查时间。若节省了Token单价却增加了人工修正成本，实际上并未降低开销。 双轨运行与回滚预算 在生产环境维持双供应商并行运行，充分验证故障切换与流量峰值表现，测算过渡期的双重计费预算。若切换动机是防范单点依赖，备用通道的待机成本应作为基础预算而非浪费。 计算回收周期与决策 依据全口径月度净节省计算投资回收周期，加入质量不确定性风险溢价。在很多情况下，基于网关的双供应商动态路由优于推倒重来的全面替换。 相关文章 供应商间套利 模型集中度风险 模型路由 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # DeepSeek Harness 中的七大防御性架构模式 · FinOps LLM URL: https://finopsllm.com/zh/research/deepseek-harness-defensive-patterns DeepSeek Harness 中的七大防御性架构模式 更新于 August 16, 2026 · 首次发布 August 16, 2026 快速结论: 在复杂的自主智能体系统中，微小的错误往往会导致死循环、资源泄漏与巨额 Token 账单。DeepSeek Harness 源码沉淀了七大防御性模式： 1. 正交结果独立上报 将业务任务成功与否同资源消耗统计彻底解耦。即使任务失败，Token 消耗与执行耗时也必须完整记录并上报财务网关。 2. 契约双向严格校验 调用前和输出后均对参数结构和类型进行严格断言，防止提示词注入攻击与畸形 JSON... 在复杂的自主智能体系统中，微小的错误往往会导致死循环、资源泄漏与巨额 Token 账单。DeepSeek Harness 源码沉淀了七大防御性模式： 1. 正交结果独立上报 将业务任务成功与否同资源消耗统计彻底解耦。即使任务失败，Token 消耗与执行耗时也必须完整记录并上报财务网关。 2. 契约双向严格校验 调用前和输出后均对参数结构和类型进行严格断言，防止提示词注入攻击与畸形 JSON 破坏后续流程。 3. 异步状态严禁同步化假设 所有的智能体状态变更均持久化在事件流日志中，避免在多步骤并发中发生数据冲突或竞态丢失。 4. 彻底释放运行资源 (Dispose) 取消或结束任务时，必须实质性终止子进程、关闭网络连接并清理临时文件，而不仅仅发出取消信号。 5. 分发器全面捕获插件异常 任何工具或插件的报错均被隔离在本地调用栈中，不得引发核心智能体控制循环的奔溃。 6. 严禁向不可信输出暴露环境敏感信息 过滤系统环境变量与路径信息，防止大模型在生成代码或分析报告时泄漏企业凭证。 7. 符号链接穿透校验 严格解析真实文件路径，阻止智能体通过软链接越界访问项目工作区之外的敏感文件。 相关文章 什么是 DeepSeek Harness？ 支出与安全护栏 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # 安装 DeepSeek Harness：配置与首跑指南 · FinOps LLM URL: https://finopsllm.com/zh/research/deepseek-harness-getting-started 安装 DeepSeek Harness：配置与首跑指南 更新于 August 16, 2026 · 首次发布 August 16, 2026 快速结论: 这是 DeepSeek Harness 的实用操作指南：如何启动 dsh、组合模式的工作原理，以及最值得体验的官方演示。 最快速的上手方式 npx @deepseek-ai/dsh web 在本地 http://127.0.0.1:3080 启动 Web 界面。开始前必须完成两项设置： 设置 → 模型： 输入 DeepSeek API Key，无需重启即可生效。 选择工作区：... 这是 DeepSeek Harness 的实用操作指南：如何启动 dsh 、组合模式的工作原理，以及最值得体验的官方演示。 最快速的上手方式 npx @deepseek-ai/dsh web 在本地 http://127.0.0.1:3080 启动 Web 界面。开始前必须完成两项设置： 设置 → 模型： 输入 DeepSeek API Key，无需重启即可生效。 选择工作区： 添加并激活项目目录，否则会话编写器将保持禁用状态。 启动后，智能体可以读写文件、执行终端命令、委托子智能体并进行规划，执行前会按权限策略请求确认。 源码安装与构建 git clone https://github.com/deepseek-ai/deepseek-harness pnpm install pnpm run build pnpm dsh web 环境要求：Node 22.19+、Git 2.26+，通过 Corepack 使用固定版本 pnpm@11.7.0 。API Key 可配置于环境变量或根目录的 .env 文件中。 配置文件与插件包 (Profiles & Bundles) 在 Cordis 架构中，一切皆插件。 Profile 是命名的插件组合，包含有序的 Bundle 列表及自定义补丁。官方内置三套模板： dsh-base : 模型适配器、基础工具与持久化。 dsh-web-app : 浏览器交互界面。 dsh-headless : 适合 CI/CD 和自动化的单次无头运行模式。 四层配置覆盖顺序 配置按固定顺序解析，后层覆盖前层： Profile Bundles（预设插件包） Profile Patches（配置补丁） Home Patches（全局用户补丁） CLI Overlays（命令行参数 —— 最高优先级） 相关文章 什么是 DeepSeek Harness？ 插件化架构设计与优势 智能体预算与开销护栏 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # 目标驱动与 Ralph 循环：控制智能体开销 · FinOps LLM URL: https://finopsllm.com/zh/research/deepseek-harness-goals-ralph-loop 目标驱动与 Ralph 循环：控制智能体开销 更新于 August 16, 2026 · 首次发布 August 16, 2026 快速结论: 开放式任务（如大型代码重构）极易陷入成本失控。DeepSeek Harness 通过“步骤 (Step)、轮次 (Turn)、循环轮数 (Round)”以及 Ralph 循环 构建了严密的控制边界。 概念分层：Step、Turn 与 Round Step: 一次模型推理调用及触发的工具执行，是计费的原子单位。 Turn: 一次完整的用户交互与智能体响应周期。 Round:... 开放式任务（如大型代码重构）极易陷入成本失控。DeepSeek Harness 通过“步骤 (Step)、轮次 (Turn)、循环轮数 (Round)”以及 Ralph 循环 构建了严密的控制边界。 概念分层：Step、Turn 与 Round Step: 一次模型推理调用及触发的工具执行，是计费的原子单位。 Turn: 一次完整的用户交互与智能体响应周期。 Round: 针对持久化目标（Goal）的一轮高级策略执行。 Ralph 循环：重置上下文以节约 Token 当智能体在长上下文中不断受挫时，上下文会充满历史错误。Ralph 循环通过优雅重置当前上下文、仅保留核心目标和进度快照，实现有意识的重新开始，大幅降低输入 Token 账单。 相关文章 什么是 DeepSeek Harness？ 自主智能体的三层预算模型 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # DeepSeek Harness 支出护栏与拦截钩子 · FinOps LLM URL: https://finopsllm.com/zh/research/deepseek-harness-guardrails DeepSeek Harness 支出护栏与拦截钩子 更新于 August 16, 2026 · 首次发布 August 16, 2026 快速结论: 在 Harness 架构中，预算护栏不是被动告警，而是在关键执行节点前的硬性拦截点。系统提供了两个原生瀑布钩子： 拦截点一：agent/pre-step 在向大模型发送推理请求之前触发。可在此校验任务剩余额度、累计 Token 限制，并在超支时强制阻断或升级为人工审批。 拦截点二：tools/pre-execute 在工具代码真正运行前触发。可在此对网络搜索、数据库写入等付费外部操作实施频次管控。 在 Harness 架构中，预算护栏不是被动告警，而是在关键执行节点前的硬性拦截点。系统提供了两个原生瀑布钩子： 拦截点一： agent/pre-step 在向大模型发送推理请求之前触发。可在此校验任务剩余额度、累计 Token 限制，并在超支时强制阻断或升级为人工审批。 拦截点二： tools/pre-execute 在工具代码真正运行前触发。可在此对网络搜索、数据库写入等付费外部操作实施频次管控。 相关文章 三层预算模型 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # 一切皆插件：DeepSeek Harness 与 Cordis 运行时 · FinOps LLM URL: https://finopsllm.com/zh/research/deepseek-harness-plugin-architecture 一切皆插件：DeepSeek Harness 与 Cordis 运行时 更新于 August 16, 2026 · 首次发布 August 16, 2026 快速结论: DeepSeek Harness 完全构建在 Cordis 插件运行时之上。核心不存在特权代码：模型适配器、工具注册表、会话日志乃至智能体主循环本身皆为可替换的插件。 四大关键能力接缝 (Capability Seams) 模型服务接缝 (LLM Seam): 可自由热拔插模型提供商，或接入模拟器回放已记录的会话，实现零推理费用的回归测试。 工具注册接缝:... DeepSeek Harness 完全构建在 Cordis 插件运行时之上。核心不存在特权代码：模型适配器、工具注册表、会话日志乃至智能体主循环本身皆为可替换的插件。 四大关键能力接缝 (Capability Seams) 模型服务接缝 (LLM Seam): 可自由热拔插模型提供商，或接入模拟器回放已记录的会话，实现零推理费用的回归测试。 工具注册接缝: 动态为不同角色加载最小化的工具集，降低输入 Token 消耗。 会话持久化接缝: 将底层事件流无缝同步至企业 FinOps 监控数据库。 相关文章 什么是 DeepSeek Harness？ 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # 会话日志：作为唯一事实来源与成本账本 · FinOps LLM URL: https://finopsllm.com/zh/research/deepseek-harness-session-log 会话日志：作为唯一事实来源与成本账本 更新于 August 16, 2026 · 首次发布 August 16, 2026 快速结论: 在生产环境中，没有精确的日志就没有 FinOps 治理。DeepSeek Harness 采用严格的仅追加事件日志 (Append-only Event Log) 规范。 Token 消耗与输出强绑定 每次模型调用的输入、输出、缓存与推理 Token 统计，均作为不可变字段直接附着在生成事件上。系统历史由事件流动态投影生成，杜绝数据冗余与账目偏差。 在生产环境中，没有精确的日志就没有 FinOps 治理。DeepSeek Harness 采用严格的 仅追加事件日志 (Append-only Event Log) 规范。 Token 消耗与输出强绑定 每次模型调用的输入、输出、缓存与推理 Token 统计，均作为不可变字段直接附着在生成事件上。系统历史由事件流动态投影生成，杜绝数据冗余与账目偏差。 相关文章 FOCUS 1.5 标准与 Token 追踪 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # 子智能体与层级委托：限制递归深度 · FinOps LLM URL: https://finopsllm.com/zh/research/deepseek-harness-subagents 子智能体与层级委托：限制递归深度 更新于 August 16, 2026 · 首次发布 August 16, 2026 快速结论: 层级化委托是智能体解决高阶难题的核心，但也容易引发爆炸式的 Token 消耗。DeepSeek Harness 通过以下机制进行约束： 硬性深度封顶 (Depth Ceiling) 系统内置不可绕过的递归深度上限，子智能体试图越级生成更深层级代理时会立即触发明确报错并终止，杜绝无限套娃消耗。 层级化委托是智能体解决高阶难题的核心，但也容易引发爆炸式的 Token 消耗。DeepSeek Harness 通过以下机制进行约束： 硬性深度封顶 (Depth Ceiling) 系统内置不可绕过的递归深度上限，子智能体试图越级生成更深层级代理时会立即触发明确报错并终止，杜绝无限套娃消耗。 相关文章 遏制子智能体并发发散 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # 工具作用域与限制：降低 Prompt 开销 · FinOps LLM URL: https://finopsllm.com/zh/research/deepseek-harness-tool-scopes 工具作用域与限制：降低 Prompt 开销 更新于 August 16, 2026 · 首次发布 August 16, 2026 快速结论: 智能体工具目录并非免费午餐。即便模型未调用某工具，其 JSON Schema 描述仍会在每轮对话中注入 System Prompt。通过 Tool Scopes 机制，系统为每个专业代理仅暴露必需的最小化工具子集，输入 Token 消耗立减 40% 以上。 智能体工具目录并非免费午餐。即便模型未调用某工具，其 JSON Schema 描述仍会在每轮对话中注入 System Prompt。通过 Tool Scopes 机制，系统为每个专业代理仅暴露必需的最小化工具子集，输入 Token 消耗立减 40% 以上。 相关文章 控制 MCP 工具定义开销 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # 在LLM评测流水线中植入成本控制 · FinOps LLM URL: https://finopsllm.com/zh/research/evals-cost-control 在LLM评测流水线中植入成本控制 更新于 August 27, 2026 · 首次发布 August 27, 2026 快速结论: 大模型自动化评测流水线必须具备独立的成本防线。一次代码提交若触发全量10,000条Prompt的评测，产生的API费用可能迅速超过业务功能本身的月度支出。工程团队应当通过单次运行预算、分层代表性抽样、固化上下文缓存以及早期质量熔断机制来精准受控。按单次运行严控预算在评测作业启动前，硬性限制Prompt总量、候选模型配比、重试次数及单次任务美元上限。将PR烟雾测试、夜间全量回归测试与正式发版认证测试... 大模型自动化评测流水线必须具备独立的成本防线。一次代码提交若触发全量10,000条Prompt的评测，产生的API费用可能迅速超过业务功能本身的月度支出。工程团队应当通过单次运行预算、分层代表性抽样、固化上下文缓存以及早期质量熔断机制来精准受控。 按单次运行严控预算 在评测作业启动前，硬性限制Prompt总量、候选模型配比、重试次数及单次任务美元上限。将PR烟雾测试、夜间全量回归测试与正式发版认证测试严格分层管理。 抽样提取高保真评测信号 按业务流、客户影响面、任务难度和已知失败模式进行样本分层。上万条重复相似的提示词产生的决策价值，远不及一组精准覆盖模型决策边界的紧凑样本集。 缓存高稳定度测试夹具 对于不依赖全新生成的测试用例，全量缓存RAG检索上下文、静态输入及基准判断结果。将缓存命中与写入统一纳入评测流水线核算。 相关文章 单个成功任务综合成本 LLM实时成本监控 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # 重度AI产品的首次月末财务结账实务 · FinOps LLM URL: https://finopsllm.com/zh/research/first-ai-month-end-close 重度AI产品的首次月末财务结账与成本对账 更新于 August 27, 2026 · 首次发布 August 27, 2026 快速结论: AI重度产品的首次月末财务结账绝不能始于一张漂亮的可视化仪表盘，而必须始于供应商原始发票与确定的结算周期。先核对实际支付的现金数字，再追溯用量遥测，待二者完全对齐后再执行成本分摊。这一纪律能防止未经审计的数据污染财务报表。1. 冻结周期与费率基准明确时区、对账截止时间、货币结算汇率、承诺折扣及促销抵扣额度。将当期价目表快照完整留存，精确记录各账单ID与遥测查询的时间窗口。2.... AI重度产品的首次月末财务结账绝不能始于一张漂亮的可视化仪表盘，而必须始于供应商原始发票与确定的结算周期。先核对实际支付的现金数字，再追溯用量遥测，待二者完全对齐后再执行成本分摊。这一纪律能防止未经审计的数据污染财务报表。 1. 冻结周期与费率基准 明确时区、对账截止时间、货币结算汇率、承诺折扣及促销抵扣额度。将当期价目表快照完整留存，精确记录各账单ID与遥测查询的时间窗口。 2. 与供应商账单深度对账 按云账号、模型、Token类型及执行日期，将内部API网关调用事件与供应商明细账单关联。输入、输出、缓存读写、推理Token与工具调用费用需全部对齐，排查所有未归属差额。 3. 明确责任主体的成本分摊 采用功能特性、研发团队、部署环境和客户群体等稳定标签维度。严格区分底层共享平台成本与业务端直接消费。 4. 四大维度的差异分析桥梁 通过单价、用量、模型结构与效率四大驱动因素解释与预算的偏差。结合单次成功任务的p50与p95成本及重试率进行全方位复盘。 相关文章 AI账单核对流程 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # FOCUS 1.5标准：AI Token与价格表追踪 · FinOps LLM URL: https://finopsllm.com/zh/research/focus-1-5-ai-token-tracking FOCUS 1.5规范：AI Token追踪与价格表数据集标准化 更新于 September 19, 2026 · 首次发布 August 15, 2026 快速结论: FinOps基金会宣布FOCUS 1.5规范将于2026年12月正式定稿。作为云成本与用量格式标准，FOCUS首次引入了原生AI字段支持：标准化模型标识符、输入输出Token计量单位，以及独立记录供应商基准单价的价格表（Price Sheet）数据集。1. FOCUS 1.5的核心标准化内容统一模型标识符：消除AWS Bedrock、Azure OpenAI与GCP... FinOps基金会宣布 FOCUS 1.5 规范将于2026年12月正式定稿。作为云成本与用量格式标准，FOCUS首次引入了原生AI字段支持：标准化模型标识符、输入输出Token计量单位，以及独立记录供应商基准单价的 价格表（Price Sheet）数据集 。 1. FOCUS 1.5的核心标准化内容 统一模型标识符： 消除AWS Bedrock、Azure OpenAI与GCP Vertex对同一基础模型的混乱命名，确立跨云对照标准。 多维Token粒度拆分： 严格区分输入Token、输出Token与前缀缓存读取Token，不再粗暴汇总为单一用量。 Price Sheet独立数据集： 将标准刊例价与用量明细剥离，让企业清晰审计承诺折扣与实效费率。 2. 规范无法解决的内部治理盲区 FOCUS解决的是云供应商账单的格式标准化， 无法代替企业内部的成本分摊（Cost Allocation） 。供应商无法得知是哪个业务功能或微服务发起了调用，内部AI网关标签仍然是精准计费的基石。 3. 企业工程团队应对建议 按Token类型细化遥测存储，将模型标识符升级为一级审计字段，并在调用发生时冻结留存当期价目表快照。 相关文章 LLM成本归属与分摊 AI云账单核对流程 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # Claude Max对比阿里Token Pro高强编码成本 · FinOps LLM URL: https://finopsllm.com/zh/research/heavy-agentic-coding-cost-claude-vs-qwen Claude Max对比阿里Token Pro：智能体高强度编码真实成本 更新于 September 19, 2026 · 首次发布 August 6, 2026 快速结论: 当自主编程工作流从简单的单轮代码补全跃升为多智能体集群（Multi-Agent Swarms）——由协调智能体生成4到8个并行的子智能体分别处理重构、测试及安全审查时，Token消耗将呈现指数级爆发。单纯依据厂商公布的每百万Token刊例价进行采购对比，必然导致严重的财务失误。1. 计费逻辑的本质差异阿里Token Pro（70美元/月）针对Qwen... 当自主编程工作流从简单的单轮代码补全跃升为 多智能体集群（Multi-Agent Swarms） ——由协调智能体生成4到8个并行的子智能体分别处理重构、测试及安全审查时，Token消耗将呈现指数级爆发。单纯依据厂商公布的每百万Token刊例价进行采购对比，必然导致严重的财务失误。 1. 计费逻辑的本质差异 阿里Token Pro（70美元/月） 针对Qwen 3.8-Max提供明确的滚动额度限制：每5小时12,000点数，每7天40,000点数。在深夜闲时时段（北京时间22:00–08:00）享受低至0.2倍的消耗折扣，极适合夜间自动化批量审查。 Claude Max 20x（200美元/月） 为Opus 5提供高并发弹性算力，但Anthropic未公开固定的Token或额度上限。Opus 5具备极高的一次性通过率，在大型工程重构中能大幅减少来回试错轮次。 2. 任务产出盈亏平衡公式 仅就固定订阅费用（70美元对比200美元）而言，Qwen 3.8-Max只要达到Opus 5 有效采纳任务产出的35% ，在单个完成特性的成本上就更具优势。 然而，以开发者人均时薪50美元计算，只要Opus 5每月能帮工程师节省 2.6小时 （时薪100美元时仅需1.3小时）的手动调试与排错时间，即可完全收回130美元的月费差价。 相关文章 云基础架构成本审计：阿里对比Claude Max 为什么AI供应商刊例价无法直接对比 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # 生产环境LLM成本暴增应急响应手册 · FinOps LLM URL: https://finopsllm.com/zh/research/llm-cost-spike-runbook 生产环境LLM成本暴增应急响应手册 更新于 August 27, 2026 · 首次发布 August 27, 2026 快速结论: 当生产环境LLM成本突发暴增时，切忌盲目更换模型。首要任务是留存证据、核验计费信号，并准确判断异常源自用量、费率、模型组合还是交付效率。科学的响应能在止血的同时完整保留根因分析所需的数据。前15分钟：核实信号并留存现场抓取云供应商账单明细、实时流量、模型组合、Token类型分布、重试次数及近期上线发布记录。将供应商计费与内部网关遥测严格比对，避免因监控前端缺陷触发错误的应急操作。接下来的30分钟：... 当生产环境LLM成本突发暴增时，切忌盲目更换模型。首要任务是留存证据、核验计费信号，并准确判断异常源自用量、费率、模型组合还是交付效率。科学的响应能在止血的同时完整保留根因分析所需的数据。 前15分钟：核实信号并留存现场 抓取云供应商账单明细、实时流量、模型组合、Token类型分布、重试次数及近期上线发布记录。将供应商计费与内部网关遥测严格比对，避免因监控前端缺陷触发错误的应急操作。 接下来的30分钟：安全遏制止血 采取影响面最小的可逆措施：暂停失控工作流、限制高并发智能体、将后台离线计算路由至批处理API，或紧急下线近期变更的功能。严格保障高优先级生产流量与核心业务收入。 排查与终结事故 优先排查用量飙升，其次检查模型升级、Token膨胀、循环重试与上下文激增。对比单次成功任务的p50与p95成本。唯有当指标恢复正常且输出质量维持在SLO之上时，方可解除临时限制。 相关文章 LLM成本监控 智能体支出护栏 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # 控制智能体MCP工具定义造成的Token冗余税 · FinOps LLM URL: https://finopsllm.com/zh/research/mcp-tool-definition-overhead 控制智能体MCP工具定义造成的Token冗余税 更新于 September 19, 2026 · 首次发布 September 19, 2026 快速结论: 将AI智能体接入多个模型上下文协议（Model Context Protocol, MCP）服务器时，模型在阅读用户意图的首个字符前，每轮交互都会被迫吞下数千个输入Token。每个注册的工具都会附加包含函数名称、参数描述、枚举定义和类型约束的完整JSON... 将AI智能体接入多个模型上下文协议（Model Context Protocol, MCP）服务器时，模型在阅读用户意图的首个字符前，每轮交互都会被迫吞下数千个输入Token。每个注册的工具都会附加包含函数名称、参数描述、枚举定义和类型约束的完整JSON Schema。在连接了6个MCP服务（GitHub、Postgres、Slack、Jira、Brave搜索、本地文件系统）的企业工作区中，静态工具前言在每次API调用中就吃掉4,500到12,000个输入Token。在一次30轮的典型任务中，仅模式重复传输就会产生0.35至1.20美元的纯冗余支出。 消除MCP开销的三大架构防线 提示词缓存断点（Prompt Caching Breakpoints）： 在Prompt上下文中将静态MCP工具定义置于所有动态历史记录之前，并在工具定义块末尾设置明确的前缀缓存断点。在Anthropic、OpenAI及Google Gemini等支持缓存的模型上，首轮之后缓存命中可将工具模式的输入Token计费成本削减75%至90%。 动态两阶段工具按需注册： 避免将所有MCP工具无差别全局暴露。使用轻量级路由模型或向量语义索引，依据用户Prompt意图动态识别所需的具体业务域，仅将相关的3至5个工具Schema注入执行智能体的活跃上下文。 Schema压缩与描述精简： 去除工具Schema中冗长的排版缩进，剔除字符串内的Markdown长篇描述，用紧凑的类型定义取代冗余的字段释义。激进的Schema精简通常可在不影响工具调用准确率的前提下，降低35%到50%的工具定义体积。 相关文章 服务器端工具独立账单 提示词缓存经济学 智能体支出护栏 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # 大模型降价并不意味着 AI 账单会自动减少 · FinOps LLM URL: https://finopsllm.com/zh/research/model-price-cuts-routing-budget 大模型降价与动态路由预算 更新于 September 10, 2026 · 首次发布 September 10, 2026 快速结论: 主流厂商竞相下调 Token 单价，但企业的月末发票往往不降反升。这通常是因为业务端借降价契机扩大了输入上下文、放宽了重试限制，或者应用代码仍旧硬编码了老旧昂贵的旗舰模型。降价是重新审视动态路由边界的战略契机。 主流厂商竞相下调 Token 单价，但企业的月末发票往往不降反升。这通常是因为业务端借降价契机扩大了输入上下文、放宽了重试限制，或者应用代码仍旧硬编码了老旧昂贵的旗舰模型。降价是重新审视动态路由边界的战略契机。 相关文章 按成功任务核算成本 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # AI 可观测性系统正在演变成第二份大模型账单 · FinOps LLM URL: https://finopsllm.com/zh/research/observability-second-llm-bill AI 可观测性与第二份大模型账单 更新于 September 9, 2026 · 首次发布 September 9, 2026 快速结论: 为了监控生成内容的一致性与安全合规，许多架构在生产链路后挂载了“大模型裁判 (LLM-as-a-Judge)”或语义分析代理。如果每次线上对话都触发一次大模型质检，监控成本甚至会超过原业务本身的收益。合理的 FinOps 架构必须采用抽样与离线批处理机制遏制这一失控增长。 为了监控生成内容的一致性与安全合规，许多架构在生产链路后挂载了“大模型裁判 (LLM-as-a-Judge)”或语义分析代理。如果每次线上对话都触发一次大模型质检，监控成本甚至会超过原业务本身的收益。合理的 FinOps 架构必须采用抽样与离线批处理机制遏制这一失控增长。 相关文章 大模型评测成本控制策略 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # Opus 5.5的努力水平才是真实价格 · FinOps LLM URL: https://finopsllm.com/zh/research/opus-5-5-effort-level-cost Opus 5.5的努力水平才是真实价格 更新于 September 22, 2026 · 首次发布 September 22, 2026 Claude Opus 5.5的价格是输入令牌每百万$4,输出令牌每百万$20。这比Opus 5便宜20%。价目表只是成本故事较小的一半。较大的一半是 effort 设置,它决定了模型在回答前思考花费多少个令牌。 一个模型,五种价格 Opus 5.5从 low 到 medium 、 high 、 xhigh 和 max 提供努力水平。每个级别是相同的模型,具有相同的令牌单价,但生成令牌数量相差很大。The Decoder报告的独立基准测试发现,五个级别中的四个位于成本-性能帕累托边界上。它还发现,在最大努力下Opus 5.5每个任务使用约119,000个输出令牌,远超竞争模型在最高设置下的使用量。 按每百万 20 美元计算,119,200 个输出 token 在不计输入的情况下就是每任务 2.38 美元。在 medium 档,Artificial Analysis 实测输出 25,700 个 token,即 0.51 美元。计入输入后,max 每任务 5.98 美元,medium 1.34 美元:仅一个请求参数,就让同一模型的每任务成本相差约 4.5 倍。 基于 Artificial Analysis Intelligence Index v4.3.2(十项评测)的实测数据,读取于 2026 年 9 月 22 日。所有行使用同一套基准,可直接比较。 模型与 effort Intelligence Index 每任务成本 每任务输出 token 是否在成本–性能前沿 Opus 5.5 · low 42.3 $0.55 10,200 否 Opus 5.5 · medium 51.2 $1.34 25,700 是 Opus 5.5 · high 53.6 $1.82 35,600 是 Opus 5.5 · xhigh 56.0 $3.46 65,700 是 Opus 5.5 · max 57.6 $5.98 119,200 是 Opus 5 · high (参考) 48.1 $3.61 46,200 否 来源:Artificial Analysis。位于前沿是指 GPT-6 Sol、GPT-6 Astra、Opus 5、Opus 5.5、Fable 5.1 的任何设置都无法以更低成本拿到更高分。Opus 5.5 low 不在前沿上,因为 GPT-6 Sol 的 xhigh 以 0.53 美元拿到 44.1 分。从 xhigh 升到 max,成本增加 73%,得分只多 1.6 分。 中等是Anthropic进行基准测试的设置 Anthropic的主要比较是在默认努力(中等)下进行的。它表示Opus 5.5在中等努力下在知识工作上的性能超过最大努力下的GPT-6 Astra,成本仅为其五分之一。因此,Anthropic自身对该模型的论证是建立在中等基础上的,而最大是例外。一个为了"保险起见"在所有地方都设置最大努力的团队,会为启动基准测试不需要的令牌付费。 如何无需猜测地设置努力水平 默认设置为中等。 使其成为代码中的显式值,而不是可能会在你下方改变的SDK默认值。 按路由提高努力水平,而不是全局提高。 困难的调试、长期规划和最终审查步骤可以证明高等或最大是合理的。分类、提取和常规编辑很少需要。 每个请求都记录努力水平。 不记录的话就无法解释每个请求的成本。支出尖峰配合平稳的请求计数通常表示努力水平改变。 在相同的重新执行任务上比较努力水平。 在每个级别上记录成功率和每个完成任务的输出令牌,当成功停止改进时停止提高努力水平。 在产品允许的地方限制输出。 最大令牌限制限制了最坏的情况。在最大努力下,该限制是避免单个失控任务和多美元请求之间的唯一保障。 从每百万$25降至$20可节省20%。将工作负载从最大努力改为中等努力可节省更多。将努力视为预算项目,就像其他任何项目一样进行所有权和审查。 相关文章 Claude Opus 5.5成本模型 Opus 5.5快速模式经济学 推理模型成本指南 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # Opus 5.5 fast mode: 2倍价格换更快响应 · FinOps LLM URL: https://finopsllm.com/zh/research/opus-5-5-fast-mode-economics Opus 5.5 fast mode经济学 更新于 September 22, 2026 · 首次发布 September 22, 2026 Claude Opus 5.5有两份价单。标准价格是每百万输入token $4,每百万输出token $20。Fast mode是$8和$40,恰好是两倍,输出速度最高可达2.5×。模型完全相同。额外的费用只是换取时间,所以唯一的问题是谁的时间。 溢价购买的是什么 假设一个步骤产生5000个输出token。按标准费率,输出成本是$0.10。Fast mode下是$0.20。如果该步骤在标准速度下耗时60秒,2.5倍加速可减少到约24秒。你多花$0.10节省36秒。 这相当于每减少一小时等待时间花费约$10。步骤长度不会改变比例,因为额外成本和节省时间都随输出token增加。这取决于你的标准模式速度:本例假设约每秒83个输出token,请代入你自己的数字。输入也会翻倍,所以前缀密集的步骤每秒节省的成本会略微增加。 划算的情况 一个在等待交互式代码编写代理的开发者。 按每小时等待时间$10计,fast mode的成本远低于领工资的任何人的时间成本。 客户面向的回答,其中延迟影响转化率。 将速度提升与用户流失对比,而非与token账单。 事故响应,每一分钟都有成本。 纯粹浪费的情况 后台代理、夜间任务和批处理管道。 没人等待,所以额外支出毫无用处。 评估和重放。 这些工作负载正好是那种会成倍增加token计数且按计划运行的。 并行运行的子代理。 墙上时间由最慢的分支和编排器决定,不是由每个调用。 按Anthropic的说法,标准Opus 5.5已比Opus 5快约30%。一些在Opus 5上会为fast mode辩护的延迟投诉可能仅通过升级就能解决。在为更快速度付费前,先衡量标准速度。 需要实施的控制措施 让fast mode成为明确的逐路线决策。 不应该是全局默认值,也不应该是某个工程师激活后就遗忘的开关。 按模式标记支出。 以单价两倍计价的fast mode请求在仅按模型分组的仪表板上看起来就像普通请求。 对输出token的fast mode占比设置警报。 如果在没人等待的路线上增加,说明被激活了不应该被激活的东西。 将努力和速度一起计预算。 最大努力会成倍增加token计数,fast mode会让每个token价格翻倍。这是运行模型成本最高的方式。 相关文章 Claude Opus 5.5成本模型 Opus 5.5努力级别是真实价格 子代理扇出和并发限制 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # 不掩盖质量退化的AI ROI度量框架 · FinOps LLM URL: https://finopsllm.com/zh/research/prove-ai-roi-measurement 不掩盖质量退化的AI ROI度量框架 更新于 August 27, 2026 · 首次发布 August 27, 2026 快速结论: AI的真实ROI绝不能仅靠云账单下降来证明。只有当可衡量的业务成果提升幅度超过了交付该成果所需的全口径AI成本时，ROI才得以成立。严谨的度量需要三组相互关联的记录：可归因支出、有效任务成果，以及防止劣质输出被误判为效率提升的质量底线校验。设立反事实对比基准明确在不实施AI改动时原本会发生的情况：人工处理、旧版模型、历史工作流或暂不上线。必须设定严格的对照组，否则营收增长或成本节省无法归因于AI系... AI的真实ROI绝不能仅靠云账单下降来证明。只有当可衡量的业务成果提升幅度超过了交付该成果所需的全口径AI成本时，ROI才得以成立。严谨的度量需要三组相互关联的记录：可归因支出、有效任务成果，以及防止劣质输出被误判为效率提升的质量底线校验。 设立反事实对比基准 明确在不实施AI改动时原本会发生的情况：人工处理、旧版模型、历史工作流或暂不上线。必须设定严格的对照组，否则营收增长或成本节省无法归因于AI系统。 以有效成果作为分母 度量“单次成功任务成本”而非简单的“单次API调用成本”。在模型调用链中追踪真实结果：已被采纳的客服答复、无差错提取的发票。将重试、工具调用、人工修复和评测流量全部计入分子。 守住质量底线方程 将财务结余与任务成功率、错误率、延迟及下游转化率同步汇报。削减25%成本若导致成功率由92%降至80%，是在摧毁业务价值而非提升ROI。设定不可跌破的质量基线。 汇报可审计的范围区间 呈报保守、基准与乐观情景。将各项支出与云发票完全核对，明确区分已实现的现金节省与未来期权价值，建立经得起审计的ROI汇报体系。 相关文章 单次成功任务成本 LLM成本归因 AI可观测性 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # 为什么AI供应商刊例价无法直接对比 · FinOps LLM URL: https://finopsllm.com/zh/research/provider-prices-not-comparable 为什么AI供应商刊例价无法直接对比：有效任务成本 更新于 August 27, 2026 · 首次发布 August 27, 2026 快速结论: 仅凭每百万Token的刊例价格来挑选AI供应商，往往产生虚假的降本错觉。不同厂商对各类Token的定义、缓存命中扣费规则、上下文窗口计算方式以及工具调用计费大相径庭。唯有针对相同工作负载和质量底线测算单个成功任务的有效成本（Cost per Successful... 仅凭每百万Token的刊例价格来挑选AI供应商，往往产生虚假的降本错觉。不同厂商对各类Token的定义、缓存命中扣费规则、上下文窗口计算方式以及工具调用计费大相径庭。唯有针对相同工作负载和质量底线测算 单个成功任务的有效成本（Cost per Successful Task） ，才具备决策价值。 规范计费度量单位 按供应商、模型、API端点、区域、Token类型、缓存状态及批处理标志建立价目矩阵。输入、输出、缓存读写、思维链推理Token和函数调用费用必须严格分列。 基准化测试工作负载 重放固定的Prompt样本集，保持上下文大小、格式规范和验证测试一致。度量p50与p95延迟、任务完成率、重试次数及输出质量。单价低30%但重试翻倍的模型，完成单次任务的成本反而更高。 计入工程运维成本 供应商套利存在工程代价：API网关维护、路由逻辑编排、可观测性监控和跨云网络出网费。将请求动态路由至同时满足质量门槛与单位成本上限的最优节点。 相关文章 大模型供应商套利与动态路由 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # 每任务真实成本:Opus 5.5 对比 Sol、Astra 和 Fable · FinOps LLM URL: https://finopsllm.com/zh/research/real-cost-per-task-frontier-models 前沿模型的每任务真实成本 更新于 September 22, 2026 · 首次发布 September 22, 2026 标价告诉你一个 token 多少钱,却不告诉你完成一个任务多少钱,因为不同模型完成同样的工作所用的 token 数相差很大。本页把 Claude Opus 5.5、Claude Opus 5、Claude Fable 5.1、GPT-6 Astra 和 GPT-6 Sol 在每个 effort 档位的实测每任务成本和质量得分并排列出。每个数字都有来源,没有任何估算。 简短结论:要达到 47.5 分及以下的任何得分,GPT-6 Sol 都是最便宜的。高于 47.5 分,每个档位都是 Opus 5.5 最便宜。GPT-6 Astra 在 low 以上的设置、Opus 5 和 Fable 5.1 的任何设置都不具成本效率:每一个都在得分和价格上同时输给 Sol 或 Opus 5.5 的某个设置。 方法 所有得分和成本均来自 Artificial Analysis Intelligence Index v4.3.2,查阅于 2026 年 9 月 22 日。该指数包含十项评测:AA-Briefcase、GDPval-AA、AutomationBench-AA、Terminal-Bench 4.0、SciCode、Humanity's Last Exam、GDP.pdf、CritPt、AA-Omniscience 和 AA-LCR。Artificial Analysis 通过各厂商 API 在每个 effort 档位运行每个模型,并记录按标价支付的金额。每任务成本就是每个任务的这笔支出,分为输入和输出。每一行都跑同一套评测,因此可以直接比较。 阅读数字之前有两点限制。第一,该指数只是一种任务组合。你的任务组合会改变成本,所以最后一节讲解如何测量你自己的成本。第二,不同指数版本的得分不可比较,不要把这些数字和更早发布的数字混用。 完整列表:26 个设置 每任务输出 token 是模型写出的 token,包括推理。Artificial Analysis 没有公布 GPT-6 Sol 中间四个设置的输入与输出拆分,因此这些单元格标为 n/a。 模型 Effort Intelligence Index 每任务成本 输入成本 输出成本 每任务输出 token 位于前沿 GPT-6 Sol none 28.1 $0.33 $0.28 $0.05 4,900 否 GPT-6 Sol low 33.9 $0.13 n/a n/a 3,400 是 GPT-6 Sol medium (默认) 39.8 $0.25 n/a n/a 6,500 是 GPT-6 Sol high 42.8 $0.37 n/a n/a 10,200 是 GPT-6 Sol xhigh 44.1 $0.53 n/a n/a 16,000 是 GPT-6 Sol max 47.5 $1.06 $0.74 $0.31 31,200 是 GPT-6 Astra low 45.8 $0.82 $0.60 $0.22 4,400 是 GPT-6 Astra medium 49.6 $1.54 $1.06 $0.48 9,600 否 GPT-6 Astra high 50.9 $1.73 $1.13 $0.59 11,800 否 GPT-6 Astra xhigh 52.4 $2.31 $1.46 $0.85 16,900 否 GPT-6 Astra max 52.7 $3.26 $1.90 $1.36 27,200 否 Claude Opus 5 low 39.4 $1.10 $0.73 $0.37 14,700 否 Claude Opus 5 medium 44.8 $2.19 $1.47 $0.72 29,000 否 Claude Opus 5 high (默认) 48.1 $3.61 $2.46 $1.16 46,200 否 Claude Opus 5 xhigh 49.7 $4.88 $3.36 $1.52 60,700 否 Claude Opus 5 max 50.8 $5.86 $4.05 $1.81 72,500 否 Claude Opus 5.5 low 42.3 $0.55 $0.35 $0.20 10,200 否 Claude Opus 5.5 medium (默认) 51.2 $1.34 $0.82 $0.51 25,700 是 Claude Opus 5.5 high 53.6 $1.82 $1.11 $0.71 35,600 是 Claude Opus 5.5 xhigh 56.0 $3.46 $2.15 $1.31 65,700 是 Claude Opus 5.5 max 57.6 $5.98 $3.60 $2.38 119,200 是 Claude Fable 5.1 low 46.8 $2.37 $1.30 $1.08 21,600 否 Claude Fable 5.1 medium 48.9 $2.98 $1.59 $1.39 27,900 否 Claude Fable 5.1 high 51.2 $3.91 $2.01 $1.90 38,100 否 Claude Fable 5.1 xhigh 53.2 $5.98 $2.96 $3.02 60,500 否 Claude Fable 5.1 max 53.4 $7.63 $3.73 $3.90 78,100 否 位于前沿是指本表中没有其他设置能以更少的钱得到更高的分数。 成本前沿 26 个设置中有 10 个位于前沿。按成本排序,如果只看价格,只有这些设置值得考虑。其余设置都是为相同或更低的得分付出更多。 设置 Intelligence Index 每任务成本 每 1 万个任务 GPT-6 Sol · low 33.9 $0.13 $1,300 GPT-6 Sol · medium 39.8 $0.25 $2,500 GPT-6 Sol · high 42.8 $0.37 $3,700 GPT-6 Sol · xhigh 44.1 $0.53 $5,300 GPT-6 Astra · low 45.8 $0.82 $8,200 GPT-6 Sol · max 47.5 $1.06 $10,600 Claude Opus 5.5 · medium 51.2 $1.34 $13,400 Claude Opus 5.5 · high 53.6 $1.82 $18,200 Claude Opus 5.5 · xhigh 56.0 $3.46 $34,600 Claude Opus 5.5 · max 57.6 $5.98 $59,800 前沿分为两段。从 0.13 美元到 1.06 美元几乎全是 GPT-6 Sol,唯一的例外是 0.82 美元的 GPT-6 Astra low。从 1.34 美元往上只有 Opus 5.5。两段之间的差距很小:Opus 5.5 medium 比 Sol max 高 3.7 分,每任务只贵 0.28 美元。 同等或更高得分下的正面对比 每一组都比较一个较便宜的设置和一个得分相同或更低的较贵设置。 较便宜的设置 较贵的设置 得分差 节省 Opus 5.5 medium: 51.2, $1.34 Opus 5 high: 48.1, $3.61 Opus 5.5+3.1 63% Opus 5.5 medium: 51.2, $1.34 Opus 5 max: 50.8, $5.86 Opus 5.5+0.4 77% Opus 5.5 medium: 51.2, $1.34 Fable 5.1 high: 51.2, $3.91 持平 66% Opus 5.5 high: 53.6, $1.82 GPT-6 Astra max: 52.7, $3.26 Opus 5.5+0.9 44% Opus 5.5 high: 53.6, $1.82 Fable 5.1 max: 53.4, $7.63 Opus 5.5+0.2 76% GPT-6 Sol max: 47.5, $1.06 Opus 5 high: 48.1, $3.61 Opus 5+0.6 71% Opus 5 这一行对尚未迁移的团队很重要。Opus 5 默认使用 high。Opus 5.5 默认使用 medium,在该默认值下得分高 3.1 分,每任务成本低 63%。Anthropic 称 Opus 5.5 比 Opus 5 便宜 40%;在这个指数上实测的差距比这一说法更大。 钱花在哪里:输入,而不是输出 所有模型的输入都占每任务成本的大约一半到四分之三。Opus 5.5 medium 的 1.34 美元中有 0.82 美元是输入,即 61%。GPT-6 Astra max 为 58%,GPT-6 Sol max 为 70%,Fable 5.1 max 为 49%。智能体任务在每一步都会重新发送不断增长的上下文,因此输入支出随步数增长,而不只是随回答长度增长。 这就是为什么 GPT-6 Sol 不推理时反而比 low 更贵:0.33 美元对 0.13 美元,尽管它只写了 4,900 个输出 token。0.33 美元中有 0.28 美元是输入。可能的原因是步骤更多,每一步都重新发送上下文。关闭推理后如果智能体需要更多轮次,它并不会更便宜。 对你的账单来说,这意味着缓存和模型选择同样重要。Opus 5.5 和 GPT-6 Sol 的缓存输入都是每百万 token 0.20 美元。GPT-6 Astra 为 1.00 美元,Opus 5 为 0.50 美元。 token 用量与标价 GPT-6 Astra 是这里最省 token 的模型。在 max 档位它每任务只写 27,200 个输出 token,而 Opus 5.5 max 为 119,200 个。但 Astra 每百万收费 10 美元和 50 美元,是 Opus 5.5 费率的 2.5×。标价胜出:Opus 5.5 high 每任务 1.82 美元、得分 53.6,而 Astra max 为 3.26 美元、得分 52.7。 只有在 Opus 5.5 max 上,啰嗦才真正花钱。它的 119,200 个输出 token 在不计输入时就要 2.38 美元,整个任务要 5.98 美元。这换来了表中最高的 57.6 分,但成本是 medium 的 4.5×。 提高 effort 的边际收益递减 每一行显示提高一个 effort 档位能换来多少指数分,以及每任务的额外成本。 模型 medium → high xhigh → max GPT-6 Sol +48%换 +3.0 分 +100%换 +3.4 分 GPT-6 Astra +12%换 +1.3 分 +41%换 +0.3 分 Claude Opus 5 +65%换 +3.3 分 +20%换 +1.1 分 Claude Opus 5.5 +36%换 +2.4 分 +73%换 +1.6 分 Claude Fable 5.1 +31%换 +2.3 分 +28%换 +0.2 分 对 Fable 5.1 和 GPT-6 Astra 来说,max 几乎换不来什么:多花 28% 和 41%,只多 0.2 和 0.3 分。对 Opus 5.5 来说,升到 max 仍能多 1.6 分,但成本高 73%。只在你已实测额外分数会改变结果的任务上使用 max。 什么时候 GPT-6 Sol max 就够了 指数是平均值,Sol max 与 Opus 5.5 medium 之间的差距在各项评测中并不均匀。Artificial Analysis 的分项得分: 评测 Opus 5.5 medium ($1.34) GPT-6 Sol max ($1.06) Terminal-Bench 4.0 52.5 43.9 AutomationBench-AA 61.2 61.6 GDPval-AA (Elo) 1576 1487 AA-Briefcase (Elo) 1642 1483 Humanity's Last Exam 54.7 47.9 SciCode 59.3 57.6 CritPt 27.7 30.9 AA-LCR 84.3 83.7 在 AutomationBench 和 CritPt 上,GPT-6 Sol 以每任务 1.06 美元对 1.34 美元持平或超过 Opus 5.5 medium。在 Terminal-Bench、知识工作类评测和 Humanity's Last Exam 上,Opus 5.5 大幅领先。工作流自动化可以跑在 Sol 上。终端和编程智能体以及文档密集的知识工作,才是 Opus 5.5 物有所值的地方。 厂商数据与独立数据 厂商数据和独立数据经常不一致,因为它们使用不同的测试框架和设置。Anthropic 公布 Opus 5.5 在 xhigh 下的 Terminal-Bench 4.0 成绩为 66.4%。Artificial Analysis 在相同 effort 下实测为 59.6%。 Effort Opus 5.5 Fable 5.1 low 31.3% 40.4% medium 52.5% 44.9% high 56.6% 52.0% xhigh 59.6% 55.1% max 59.6% 52.0% 排名也会随指数而变。在 Vals AI Index 上,Fable 5.1 以 68.83% 排第一,GPT-6 Astra 以 66.61% 排第三,Opus 5.5 以 66.16% 排第四。那里没有按同一口径公布每任务成本,所以不影响上面的前沿。一个指数只是一种视角。 标价与一个重缓存任务 Digital Applied 在每个模型上计算了一个重缓存智能体任务的价格:8M 缓存读取 token、400K 未缓存输入、600K 缓存写入 token 和 300K 输出 token。结果与前沿一致,只是 GPT-6 Astra 多了一项额外惩罚。 模型 输入 $/MTok 输出 $/MTok 缓存读取 $/MTok 重缓存任务(Digital Applied) GPT-6 Sol $2.00 $10.00 $0.20 $6.90 Claude Opus 5.5 $4.00 $20.00 $0.20 $12.20 Claude Opus 5 $5.00 $25.00 $0.50 $17.25 Claude Fable 5.1 $10.00 $50.00 $0.25 $28.50 GPT-6 Astra (≤272K) $10.00 $50.00 $1.00 $34.50 GPT-6 Astra (>272K) $20.00 $75.00 n/a $61.50 一旦输入超过 272K token,GPT-6 Astra 会对整个请求按每百万 20 美元和 75 美元计费。Opus 5.5 在整个 1M token 窗口内保持单一价格。Opus 5.5 的缓存写入在 5 分钟缓存下为每百万 5 美元,1 小时缓存为 8 美元;批处理按 50% 计费,快速模式价格翻倍。详情请见 Claude Opus 5.5 成本模型 和 Opus 5.5 快速模式的经济账 。 如何测量你自己的每任务成本 按任务而不是按请求记录 token:未缓存输入、缓存输入、缓存写入和输出,在任务的每一步上求和。 抽取几百个真实任务作为样本,在两三个候选设置上重跑,例如 Sol max、Opus 5.5 medium 和 Opus 5.5 high。 用生产环境中相同的检查给每个结果打分,并统计通过的任务数。 用总支出除以通过的任务数。每个成功任务的成本才是要比较的数字,因为便宜但更常失败的设置并不便宜。 选出达到质量门槛的最便宜设置,只把失败的任务交给更高的设置。 当价格或默认 effort 变化时,重新跑一遍。 effort 设置如何改变同一模型的账单,请见 Opus 5.5 的 effort 档位才是真实价格 。 注意事项 所有成本都是在 Artificial Analysis 任务组合上按 API 标价计算的。折扣、批处理价格和你自己的缓存都会改变它们。 Artificial Analysis 将其 Opus 5.5 和 Fable 5.1 条目标为 Default Fallback。在把每一行都视为相同的 API 配置之前,请先查看其方法说明。 得分仅来自指数 v4.3.2。更早的版本使用不同的评测,不可比较。 Digital Applied 的重缓存任务是一个示例负载,不是测量结果。 厂商调整价格或默认值时,数字也会变化。查阅日期为 2026 年 9 月 22 日。 来源 Artificial Analysis Intelligence Index Artificial Analysis: Claude Opus 5.5 Artificial Analysis: Claude Opus 5 Artificial Analysis: Claude Fable 5.1 Artificial Analysis: GPT-6 Astra Artificial Analysis: GPT-6 Sol Digital Applied: GPT-6 Sol vs Claude Opus 5.5 cost benchmarks Digital Applied: Claude Opus 5.5 vs GPT-6 Astra Digital Applied: Is Claude Fable 5.1 still worth it? Digital Applied: Claude Opus 5.5 launch pricing and benchmarks Digital Applied: Opus 5.5 vs Grok 4.7 vs Muse Spark 1.3 cost per task 相关文章 Claude Opus 5.5 成本模型 Opus 5.5 的 effort 档位才是真实价格 Opus 5.5 快速模式的经济账 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # 悄然推高推理成本的智能体重试循环陷阱 · FinOps LLM URL: https://finopsllm.com/zh/research/retry-loop-hidden-spend 悄然推高推理成本的智能体重试循环陷阱 更新于 August 27, 2026 · 首次发布 August 27, 2026 快速结论: 系统自动重试绝不是免费的高可用弹性设计。每一次重试都是一次全额计费的模型调用。自律智能体可以在监控系统察觉异常之前，将一次网络瞬时抖动放大为五次昂贵的全额计费调用。首要的治理手段是度量重试损耗税（Retry... 系统自动重试绝不是免费的高可用弹性设计。每一次重试都是一次全额计费的模型调用。自律智能体可以在监控系统察觉异常之前，将一次网络瞬时抖动放大为五次昂贵的全额计费调用。首要的治理手段是度量 重试损耗税（Retry Tax） ：即重试与备选降级消耗的支出占总推理支出的比例，并按业务流和失败归因进行细分。 全量追踪调用尝试树 完整记录父请求标识、尝试序号、供应商、模型版本、工具调用详情、延迟、错误类型、各类型Token消耗及终态结果。单靠平铺的请求ID无法追踪工具调用所引发的嵌套模型请求。必须建立父子链路血缘，将用户的单次业务意图还原为完整的调用调用树。 区分有价值的重试与纯粹的浪费 针对云厂商限流（Rate Limit）的退避重试往往能挽救高价值业务；而针对Schema校验错误使用完全相同的Prompt进行重复尝试，通常只会换来另一次完全相同的失败。供应商超时、工具入参畸形、上下文超长与质量不达标需要严格分流处理。为每类错误设定明确的尝试上限与升级策略。 在执行循环边界设立多重预算 为单次请求设置Token封顶，为端到端工作流设置金额硬顶，并设定最大物理时钟超时限制。软上限可自动将下一次尝试路由至轻量经济型模型；硬上限必须彻底截断循环并返回可恢复的状态机快照。绝不能寄希望于月底的静态云账单告警来治理几秒内就能烧穿预算的高并发循环。 相关文章 智能体支出护栏 LLM成本监控 成功任务单价 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # SaaS AI积分：度量无法掌控的计费单元 · FinOps LLM URL: https://finopsllm.com/zh/research/saas-ai-credits-metering SaaS AI积分：度量无法掌控的计费单元 更新于 September 2, 2026 · 首次发布 September 2, 2026 快速结论: 云原生FinOps的前提是计量单元清晰可辨：实例小时、请求数或流量。而SaaS供应商的AI积分（Credits）完全不同：它由厂商自定义、自行定价，甚至在合同期内动态调整扣费规则。这种支出兼具用量消耗的不确定性，却缺乏云账单配套的成本管控工具。打破传统管理框架的三大特性计量规则极度不透明：... 云原生FinOps的前提是计量单元清晰可辨：实例小时、请求数或流量。而SaaS供应商的AI积分（Credits）完全不同：它由厂商自定义、自行定价，甚至在合同期内动态调整扣费规则。这种支出兼具用量消耗的不确定性，却缺乏云账单配套的成本管控工具。 打破传统管理框架的三大特性 计量规则极度不透明： 最终用户感知相似的操作，在不同功能模块中消耗的积分可能相差数十倍，且厂商极少公布折算算法。 超额单价无法被市场竞价： 超额用量（Overage）完全由单一厂商定价，企业无法通过切换低成本模型来平抑开销。 席位额度无法跨团队共享或结转： 按席位配发的额度通常当月作废，导致A团队额度浪费的同时，B团队却在产生昂贵的超额账单。 构建企业自有的时序计量 通过厂商的管理API定期抓取原始消耗日志，按员工、部门与业务功能打标沉淀。厂商后台通常只展示当期汇总，而财务分析需要完整的历史趋势图谱。 账单到达前完成成本分摊 将AI积分映射到与云资源相同的成本中心，每月出具内部Showback账单。未分摊的AI支出最终都会沉淀到IT平台基础部门，而该部门恰恰是对业务消耗最无发言权的团队。 相关文章 企业信用卡上的影子AI治理 承诺支出折扣优化指南 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # 大模型服务端工具往往是另一张计费账单 · FinOps LLM URL: https://finopsllm.com/zh/research/server-tools-are-a-separate-invoice 大模型服务端工具往往是另一张计费账单 更新于 September 1, 2026 · 首次发布 September 1, 2026 快速结论: 大多数LLM成本模型只设立了一个单一的计量维度：输入Token、输出Token、每百万Token单价。当API请求的全部工作仅仅是补全生成文本时，这一模型完全正确。但自从云供应商推出服务端原生工具（Server-side Tools）的那一刻起，该假设便彻底失效了。网络实时搜索（Web Search）、网页抓取（Web Fetch）以及代码沙箱执行（Code... 大多数LLM成本模型只设立了一个单一的计量维度：输入Token、输出Token、每百万Token单价。当API请求的全部工作仅仅是补全生成文本时，这一模型完全正确。但自从云供应商推出服务端原生工具（Server-side Tools）的那一刻起，该假设便彻底失效了。 网络实时搜索（Web Search）、网页抓取（Web Fetch）以及代码沙箱执行（Code Execution）均直接运行在云供应商的基础设施之上，其中许多工具在产出Token之外，还额外附带独立的按次调用费。因此，单次智能体交互往往会产生双重收费：一次是工具本身的单次调用费，另一次是工具返回结果作为上下文被后续各轮重复计费的Token费用。 隐性的复利累积效应 最容易被工程团队忽视的是第二笔费用。每一次工具调用的返回结果都会被完整追加到对话历史中，而后续的每一个交互回合都会将全部历史作为输入Token重新发送。在一段漫长的智能体执行链路初期执行十次网页搜索，产生的绝不仅是十次单项费用——而是十次调用费加上其庞大的网页数据载荷在后续每轮交互中被反复重新计费的累计成本。 三大立竿见影的治理控制 对单次任务的工具调用次数设定硬顶： 为单次用户任务设定搜索或抓取次数的绝对上限。大多数触及10次上限的工作流都是在死循环，而非有效探索。 截断并精简注入上下文的内容： 极少有业务场景需要将抓取的整个HTML页面塞入Prompt。在将工具结果追加至历史前进行清洗或摘要，可以有效削减后续所有轮次的输入成本。 缓存固定的前缀结构： 如果系统提示词和工具定义在任务全生命周期内保持静态，利用提示词前缀缓存可消除工具带来的最大重复成本。 相关文章 提示词缓存经济学 单次请求成本KPI LLM成本归因 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # 用户中途离开的流式响应仍在悄悄吞噬预算 · FinOps LLM URL: https://finopsllm.com/zh/research/streaming-abandoned-generations-cost 流式输出与未竟生成的成本控制 更新于 September 9, 2026 · 首次发布 September 9, 2026 快速结论: 流式输出（Streaming）大幅改善了用户交互体验，但也制造了“前端已关闭，后端仍在疯狂计费”的成本黑洞。当用户浏览前两行已解决问题并关闭网页时，若未配置即时中断机制，大模型服务商仍会生成完剩余的数百个 Token 并全额扣款。工程师必须通过 AbortController 链路将中断信号秒级传递至模型网关。 流式输出（Streaming）大幅改善了用户交互体验，但也制造了“前端已关闭，后端仍在疯狂计费”的成本黑洞。当用户浏览前两行已解决问题并关闭网页时，若未配置即时中断机制，大模型服务商仍会生成完剩余的数百个 Token 并全额扣款。工程师必须通过 AbortController 链路将中断信号秒级传递至模型网关。 相关文章 重试循环中的隐性成本 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # 遏制子智能体并发扇出吞噬Token预算 · FinOps LLM URL: https://finopsllm.com/zh/research/subagent-fan-out-concurrency-limits 遏制子智能体并发扇出吞噬Token预算 更新于 September 19, 2026 · 首次发布 September 19, 2026 快速结论: 当自律编排智能体将一项宏观任务拆解为并行子任务，并允许下游工作智能体自主派生新的专用子智能体时，极易发生子智能体并发扇出级联（Fan-out... 当自律编排智能体将一项宏观任务拆解为并行子任务，并允许下游工作智能体自主派生新的专用子智能体时，极易发生 子智能体并发扇出级联（Fan-out Cascades） 。在缺乏硬性并发上限与递归深度约束的环境中，单条语义含糊的用户Prompt即可引爆指数级膨胀：1个主调度器派生6个领域规划器，每个规划器启动4个研究智能体，后者又继续调用深层分析工作流。在生产架构中，不受控的递归委派常在5分钟内烧掉200万至800万Token，导致单笔业务交易突发产生15至80美元的异常账单毛刺。 多智能体舰队的四大生产护栏 最大递归深度硬顶（Depth Caps）： 在调度层设定严格的层级上限。在95%的企业落地场景中，设置 max_depth: 2 （主调度器 → 专用工作智能体）即可完全覆盖业务需求。除非有明确的权限豁免，坚决禁止工作智能体继续派生三级孙代智能体。 根会话共享Token预算池： 禁止赋予子智能体独立的预算配额。在根执行线程上下文分配共享配额（例如总计250,000 Token），并通过链路追踪上下文头部向下透传。子智能体消费时统一扣减全局资金池，一旦归零，全部并行分支立即强制终止。 并发断路器（Circuit Breakers）： 将单个任务活跃的并行子智能体限制在3至5个进程以内。若调度器试图派生超出队列容量的并发实例，强制排队顺序执行或直接驳回拆解请求。 分布式链路追踪与OTLP成本透传： 在智能体消息总线间注入OpenTelemetry Trace ID与Baggage请求头。确保每个子智能体的Span均能聚合至父会话ID，实现对分支级成本异动的秒级洞察。 相关文章 智能体三层预算 LLM成本暴增手册 重试循环与隐性支出 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # 自律智能体必备的三层运行时预算 · FinOps LLM URL: https://finopsllm.com/zh/research/three-agent-budgets 自律智能体必备的三层运行时预算 更新于 August 27, 2026 · 首次发布 August 27, 2026 快速结论: 自律AI智能体（Autonomous Agent）需要的绝不仅仅是月底的云账单超支告警。系统必须在其执行循环内部强制实施三层防御预算：针对单次模型调用的请求预算、针对端到端任务的工作流预算、以及针对业务属主或租户的日预算。每一层预算分别防御不同的技术与系统失效模式。1.... 自律AI智能体（Autonomous Agent）需要的绝不仅仅是月底的云账单超支告警。系统必须在其执行循环内部强制实施三层防御预算：针对单次模型调用的 请求预算 、针对端到端任务的 工作流预算 、以及针对业务属主或租户的 日预算 。每一层预算分别防御不同的技术与系统失效模式。 1. 单次请求预算 请求预算对单次模型交互的Token总数、工具并发扇出数、调用耗时或消费金额设置硬顶。它能有效防范上下文意外膨胀、大模型异常话痨生成、或工具递归调用死锁。必须在向供应商发起请求及分发工具动作前进行校验。达到软上限可自动降级模型，达到硬上限则直接阻断并返回明确拒绝代码。 2. 任务工作流预算 工作流预算跨越多个对话轮次、重试尝试、备选降级与子智能体委派，紧密跟踪单次用户的真实意图。它依赖全局关联ID（Correlation ID）与分布式账本，而非单机进程的本地计数器。一旦账本累计消费触及阈值必须立即叫停，即使每次单独请求都在单次限额之内。这是捕获委派层级过深和死循环的关键防线。 3. 租户日预算 日预算用于限制特定业务团队、租户、独立功能或服务账户在自然日内的累计消耗。它起到资源公平调度与故障爆炸半径隔离的作用。当日预算接近枯竭时，将非紧急计算路由至离线批处理或低成本模型，并为核心高价值业务保留配额。在统一时区自动清零并记录账本流水。 确保预算拒绝具备业务可恢复性 当触发预算熔断时，错误信息应当清晰指明被触发的预算类型、当前累计用量以及允许的恢复策略。返回可断点续跑的状态机快照，而非静默吞掉或抛出空响应。对每笔预算预占、实际扣减、释放及阻断事件生成不可篡改的审计日志，便于财务核对。 相关文章 智能体支出护栏 LLM预算治理 成功任务单价 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # Token单价暴跌，生产AI账单为何不降反升 · FinOps LLM URL: https://finopsllm.com/zh/research/token-prices-bill-keeps-rising Token单价暴跌，生产AI账单为何不降反升 更新于 August 27, 2026 · 首次发布 August 27, 2026 快速结论: 模型供应商下调Token单价并不等同于企业LLM总账单会自动缩水。在真实的生产业务中，用量扩张速度往往远超单价下调幅度：更长的上下文窗口、多步骤自主智能体、更庞大的生成输出、重试机制以及新上线的功能特性，可以在短时间内将40%的降价红利吞噬殆尽。真正的成本诊断不是看哪家供应商更便宜，而是对费率、用量、结构与效率展开四维归因分析。单价只是账单构成的四分之一假设某云厂商将加权Token单价从每百万10... 模型供应商下调Token单价并不等同于企业LLM总账单会自动缩水。在真实的生产业务中，用量扩张速度往往远超单价下调幅度：更长的上下文窗口、多步骤自主智能体、更庞大的生成输出、重试机制以及新上线的功能特性，可以在短时间内将40%的降价红利吞噬殆尽。真正的成本诊断不是看哪家供应商更便宜，而是对费率、用量、结构与效率展开四维归因分析。 单价只是账单构成的四分之一 假设某云厂商将加权Token单价从每百万10美元下调至6美元，但随着业务拓展，企业月用量从1亿暴增至2.2亿Token，实际月度账单将从1,000美元上升至1,320美元。单价下降了40%，但实际应付发票却上升了32%。只展示Token平均单价的技术看板会误报为利好，而财务团队看到的却是一场失控的成本膨胀。 用量、结构与效率的三重乘数 用量（Volume） 指实际消费的Token总量，随请求流量扩张、上下文变长或智能体执行轮次增加而增长。 结构（Mix） 指Token流向了何种模型：高阶推理模型、新部署的地理区域或高上下文功能都会在请求数不变的前提下重塑账单。 效率（Efficiency） 是指达成相同业务产出所付出的边际技术成本：包括重试报错、失败的工具调用、冗余Prompt以及用户根本未阅读的多余生成。 构建周度成本归因桥梁 建立从上一周期到当前周期的周度方差桥梁。以基线账单为基准，依次拆解费率影响、用量增长、模型组合漂移以及工作流交付效率。将指标对齐到“单次成功任务成本”的p50和p95分布，而非全公司粗放的技术平均数。根据占比最大的方差动因实施精准治理。 相关文章 LLM成本监控 单次请求成本产品KPI LLM成本归因 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com --- # 什么是DeepSeek Harness？开源架构与指南 · FinOps LLM URL: https://finopsllm.com/zh/research/what-is-deepseek-harness 什么是DeepSeek Harness？开源架构与成本指南 更新于 August 16, 2026 · 首次发布 August 16, 2026 快速结论: DeepSeek Harness——npm包名为dsh——是DeepSeek... DeepSeek Harness ——npm包名为 dsh ——是DeepSeek AI以MIT开源协议发布的智能体运行环境。本文系统梳理其核心概念、启动流程、系统架构以及在FinOps成本管理中的战略意义。 模型与智能体框架（Harness）的本质区别 大型语言模型本身只负责生成文本和工具调用请求。赋予智能体实际生产力的一切外部机制均由框架处理：构建系统提示词、执行工具调用、实施安全权限限制、记录会话轨迹、控制自主推理循环以及调度子智能体。 即使两家企业调用完全相同的模型底座，其产出质量与月度算力账单也会因框架架构的差异而产生数倍的差距。 全插件化核心架构 DeepSeek Harness构建在 Cordis 微内核之上，所有功能均以插件呈现：模型适配器、工具注册中心、会话日志系统及控制流。这使得团队无需fork核心仓库即可在运行时轻松拦截或替换任意组件。 安装部署与运行模式 最快捷的体验方式是启动本地Web界面： npx @deepseek-ai/dsh web 而在工程流水线与自动化CI/CD中，核心是 无头（Headless）模式 ： pnpm dsh --profile headless "summarize this workspace" 只能在交互模式下运行的框架无法集成到持续集成测试中，未被监控的智能体调用往往是成本黑洞。 运行经济学与成本治理 框架本身遵循MIT协议完全开源免费，但模型推理Token按量计费。实际开销取决于单轮执行步数、上下文载入的工具数量、并发子智能体深度及死循环熔断策略。这些均属于框架层的架构决策。 相关文章 快速入门与配置指南 插件架构深度解析 想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 → 返回 finopsllm.com ---