{ "angleSummaries": [ { "angle": "hosting", "summary": "" }, { "angle": "infra-config", "summary": "For a solo-dev/small-team project with two related repos (npm MCP server + Dockerized web app), 2025-2026 practitioner consensus favors keeping infra config (Dockerfile, compose, fly.toml/railway.json) in-repo alongside each app rather than a separate infra repo — separation is mainly justified by privilege/audit needs that don't apply at this scale. On IaC tooling, full Terraform/OpenTofu/Pulumi/SST is widely considered overkill for small projects; the dominant small-team pattern in 2026 is Docker Compose (or plain Dockerfile) + a PaaS config file (fly.toml, railway.json/toml) or a lightweight deploy tool like Kamal 2 (37signals) for self-hosted VPS deploys. If IaC is wanted at all, OpenTofu is now the \"no-regrets default\" for greenfield due to MPL licensing vs Terraform's BSL, while Pulumi/SST are recommended only for TypeScript-heavy AWS-serverless shops — not indie/small-scale Docker deployments. Both fly.toml and railway.json/toml are designed to live per-app in that app's own repo, reinforcing in-repo config as the norm at this scale." }, { "angle": "openrouter", "summary": "" }, { "angle": "gateways", "summary": "Surveyed pricing, hosting model, reliability, caching, budgeting, latency, and AI-SDK compatibility for LiteLLM, Vercel AI Gateway, Cloudflare AI Gateway, Portkey, and Helicone as of mid-2026. Key split: LiteLLM and Portkey both offer truly free, fully self-hostable open-source gateways with virtual keys/budgets/fallback/caching, making them the only real fits for an npm-distributed, local-first MCP server where end users supply their own keys (LiteLLM's clientside/BYOK auth is a direct match; ship the proxy or vendor its config, no vendor account needed). Vercel AI Gateway and Cloudflare AI Gateway are managed-first, zero-markup, pay-as-you-go options tightly coupled to their own platforms (Vercel AI SDK / Cloudflare Workers ecosystem) — good for a small hosted web app already living on those platforms, less suited to redistribution since routing config and API keys are typically vendor-account-scoped, though both do support arbitrary OpenAI-compatible baseURL usage. Helicone is best understood now as an observability layer with an added gateway, recently acquired by Mintlify (announced March 2026) and put into maintenance mode — a material risk factor for any new dependency on it. Latency overhead varies enormously by implementation: compiled gateways add microseconds while Python-based proxies like LiteLLM can add tens to hundreds of ms under load, though LiteLLM's own benchmarks claim single-digit-ms P95 that improves with horizontal scaling. All five now support per-key/team budgets and caching in some form, but maturity differs: Portkey and Cloudflare have the most developed caching (semantic vs edge-geographic), Cloudflare uniquely just added dollar-denominated spend limits, and LiteLLM's budgets/virtual-keys system is the most battle-tested for self-hosted multi-tenant spend tracking." }, { "angle": "direct-apis", "summary": "Direct-provider economics in 2026: all major providers now offer prompt/context caching (75-98% discounts on repeated input) and batch APIs (flat 50% off), which OpenRouter's abstraction layer doesn't always cleanly expose. OpenRouter itself charges no per-token markup on most models (the real cost is a 5.5% credit-purchase fee, or 5% BYOK fee after 1M free requests/month) — except for Anthropic/Claude models, which carry a documented ~100% markup on OpenRouter vs direct, making Claude the clearest case for going direct. General rule of thumb from industry sources: OpenRouter wins for multi-model use, failover, or spend under ~$500/mo; direct wins for single-provider spend over ~$2000/mo where provider-specific rate-limit tiers, caching, and batch discounts compound. Rate-limit tiers (OpenAI, xAI) scale with cumulative spend and unlock automatically, with xAI notably offering up to $175/month in free credits via data-sharing — the most generous of the majors. On SQLite in production: LiteFS/Fly.io has stagnated (LiteFS Cloud sunset Oct 2024, no clear roadmap), so the ecosystem has converged on either (a) Turso/libSQL managed embedded-replica SQLite (generous free tier, cheap paid tiers) or (b) a simpler single-node Fly.io machine + attached volume + Litestream continuous backup to S3-compatible storage, avoiding distributed consensus complexity. Railway's pattern is a containerized sqld (libSQL server) + persistent volume. The dominant real-world answer for small production apps: don't over-engineer distributed SQLite — single-node + Litestream, or managed Turso, are what's actually used." } ], "rawPoolSize": 81, "sourcesRead": [ "https://fly.io/docs/about/pricing/", "https://docs.railway.com/volumes/reference", "https://render.com/docs/disks", "https://vercel.com/kb/guide/is-sqlite-supported-in-vercel", "https://developers.cloudflare.com/containers/faq/", "https://darko.io/posts/self-hosting-with-coolify-and-hetzner/", "https://haloy.dev/blog/self-hosted-deployment-tools-compared", "https://fly.io/docs/reference/configuration/", "https://docs.railway.com/config-as-code/reference", "https://jorijn.com/en/blog/opentofu-vs-terraform-2026-the-fork-finally-diverged/", "https://kitemetric.com/blogs/terraform-vs-pulumi-vs-sst-a-comparative-analysis", "https://www.harness.io/blog/gitops-repo-structure", "https://encore.dev/articles/kubernetes-alternatives", "https://openrouter.ai/pricing" ], "verified": [ { "topic": "hosting", "claim": "Vercel is a poor fit for a SQLite-backed app: Vercel Functions (including Vercel's Docker/OCI container support) run as stateless, ephemeral, auto-scaling compute with no shared persistent filesystem, so a local SQLite file can't be safely written to across concurrent or restarted instances.", "urls": [ "https://vercel.com/kb/guide/is-sqlite-supported-in-vercel", "https://vercel.com/kb/guide/does-vercel-support-docker-deployments" ], "why": "Directly eliminates Vercel (even via Docker) as a hosting option for any app that persists data in a local SQLite file — a foundational constraint the whole hosting shortlist has to route around.", "refutes": 0, "notes": [] }, { "topic": "hosting", "claim": "Fly.io: a minimal always-on machine (shared-cpu-1x/256MB) runs only ~$2.32/month compute, but persistent volumes cost $0.15/GB/month billed hourly even while the machine is stopped, plus (since Jan 2026) $0.08/GB/month for the default 5 retained daily snapshots — so real-world volume cost can run 2-5x the raw provisioned-GB rate.", "urls": [ "https://fly.io/docs/about/pricing/", "https://fly.io/docs/about/cost-management/" ], "why": "Sets the actual all-in dollar cost of the leading small-app PaaS candidate; missing the snapshot multiplier could understate real spend by 2-5x.", "refutes": 0, "notes": [] }, { "topic": "hosting", "claim": "A Hetzner shared-vCPU VPS (4GB RAM) costs ~€4-5/month, and running Coolify or Dokploy on top (largely automated: point it at a server IP and it installs Docker + a reverse proxy) gives full Docker Compose control including bind-mounted host volumes for a SQLite file — at the cost of self-managing OS/security/backups.", "urls": [ "https://darko.io/posts/self-hosting-with-coolify-and-hetzner/", "https://coolify.io/docs/knowledge-base/how-to/webstudio-with-hetzner" ], "why": "Establishes the cheapest, most flexible hosting alternative (self-managed VPS) as a real contender against managed PaaS, directly shaping the cost/control tradeoff in the final recommendation.", "refutes": 1, "notes": [ "Per Hetzner's own price-adjustment notice (effective 15 June 2026), the comparable 4GB shared-vCPU plan (CX23) now costs €5.49/month (~$6.49), not €4-5/month as claimed. Source: https://docs.hetzner.com/general/infrastructure-and-availability/price-adjustment/. The Coolify/Dokploy automation description itself remains accurate per https://darko.io/posts/self-hosting-with-coolify-and-hetzner/." ] }, { "topic": "data-layer", "claim": "Turso's free tier (2026) offers 500M row reads/mo, 10M row writes/mo, 5GB storage across 100 databases, with the first paid tier at $4.99/month; its libSQL embedded-replicas model syncs a local SQLite file from a cloud primary for local-disk-speed reads while keeping a durable cloud copy.", "urls": [ "https://turso.tech/pricing", "https://docs.turso.tech/libsql" ], "why": "Quantifies the cost and mechanics of the leading managed-SQLite alternative, which determines whether it's cheap enough to replace self-managed Litestream/volume persistence.", "refutes": 0, "notes": [] }, { "topic": "infra-config", "claim": "Keeping infra config and application code in one repo (vs. splitting into separate infra/app repos) enables atomic commits across both and is generally considered more suitable and easier to manage for small teams, at the cost of losing privilege separation (anyone with repo access can change both) — a tradeoff that matters more for larger orgs needing audit boundaries.", "urls": [ "https://hungrydevops.substack.com/p/should-you-keep-application-and-infrastructure", "https://www.harness.io/blog/gitops-repo-structure" ], "why": "Directly answers the 'infra-config placement' question (same repo vs. separate) that this research pool is oriented around; the small-team framing matches this project's likely scale.", "refutes": 0, "notes": [] }, { "topic": "infra-config", "claim": "Fly.io's app configuration (builds, env vars, exposed services, disk mounts, release commands) lives in a single fly.toml file per app, designed to sit directly in the app's own repository.", "urls": [ "https://fly.io/docs/reference/configuration/" ], "why": "Concrete evidence for the 'same repo' placement convention on the leading hosting candidate — if false, Fly.io would instead push toward a separate infra repo.", "refutes": 0, "notes": [] }, { "topic": "openrouter", "claim": "OpenRouter passes through provider token pricing with no per-token markup on most models; its real costs are a 5.5% fee on pay-as-you-go credit purchases (5% for crypto) and a 5% BYOK fee on custom-provider-key usage, waived up to a free monthly quota (documented inconsistently as $25k-$200k/month list-price inference on the pricing page vs. 1M free BYOK requests/month in the BYOK docs — worth re-verifying at time of use).", "urls": [ "https://openrouter.ai/pricing", "https://openrouter.ai/docs/guides/overview/auth/byok", "https://tokenmix.ai/blog/openrouter-vs-direct-api-cheaper" ], "why": "This is the core cost model for every OpenRouter-routed model in the stack (Kimi/DeepSeek/GLM/MiniMax/StepFun/ERNIE); getting the fee percentage or free-quota terms wrong directly changes the OpenRouter-vs-direct cost comparison.", "refutes": 0, "notes": [] }, { "topic": "openrouter", "claim": "OpenRouter suffered two acknowledged outages in Feb 2026 (Feb 17 and 19), both from the same root cause — an external caching-layer dependency dropping DB connections, then a surge of simultaneous DB lookups on recovery — causing 80-90% request failure rates during the worst windows.", "urls": [ "https://openrouter.ai/blog/announcements/openrouter-outages-on-february-17-and-19-2026/" ], "why": "A concrete, recent reliability data point bearing on whether to route production traffic solely through OpenRouter or keep direct-API fallbacks for critical models — undercuts a 'route everything through OpenRouter' recommendation.", "refutes": 0, "notes": [] }, { "topic": "direct-apis", "claim": "xAI Grok 4.3 (flagship) is priced at $1.25/1M input and $2.50/1M output, with cached input at just $0.20/1M (~85% off standard input) — the most aggressive caching discount among the major direct-API providers reviewed.", "urls": [ "https://docs.x.ai/developers/models" ], "why": "Establishes Grok's direct-API cost structure, which is what the OpenRouter-vs-direct tradeoff for Grok-backed tools (grok_reason, grok_search, etc.) is actually measured against.", "refutes": 1, "notes": [ "Grok 4.3's raw pricing figures are correct ($1.25/1M input, $2.50/1M output, $0.20/1M cached input ≈ 85% off), per https://docs.x.ai/developers/models and https://docs.x.ai/developers/advanced-api-usage/prompt-caching/usage-and-pricing. But it is NOT the most aggressive caching discount among this project's direct-API providers: OpenAI GPT-5.5 cached input is $0.50/1M vs $5.00/1M standard (90% off, https://developers.openai.com/api/docs/pricing) and Gemini 3.1 Pro cached input is $0.20/1M vs $2.00/1M standard (90% off, https://ai.google.dev/gemini-api/docs/caching). Both beat Grok's ~85% discount, so Grok has the shallowest cache discount of the three direct-API providers (Grok/OpenAI/Gemini) that TachiBot actually reviews for the OpenRouter-vs-direct tradeoff." ] }, { "topic": "gateways", "claim": "LiteLLM's open-source gateway (proxy, admin UI, virtual keys, routing/fallbacks/caching) is free to self-host, but real-world self-hosting carries hidden costs of $100-400/month for a managed DB with backups/HA plus ongoing DevOps/observability/security work that can exceed a managed gateway's cost at scale.", "urls": [ "https://docs.litellm.ai/docs/simple_proxy", "https://www.truefoundry.com/blog/litellm-pricing-guide" ], "why": "Directly bears on whether to add a self-hosted LLM gateway to the infra stack at all — 'free to self-host' is misleading without the $100-400/mo + DevOps-time hidden costs, which would change a build-vs-buy gateway recommendation.", "refutes": 1, "notes": [] } ], "killed": [ { "claim": "Cloudflare Containers use fully ephemeral local disk (filesystem resets to the base image on every sleep/restart), and Cloudflare's real persistence answer is Durable Objects' built-in SQLite storage (1GB/object today, ~10GB at GA) — a different programming model requiring rearchitecture, not a drop-in bind-mounted volume; true container disk snapshots are still 'coming soon' as of 2026.", "corrections": [ "The claim is a mix of accurate and outdated/wrong statements, and the wrong part directly undermines the \"1GB today, ~10GB at GA\" framing.\n\nAccurate parts (confirmed against current docs):\n- Cloudflare Containers disk IS fully ephemeral: the FAQ (developers.cloudflare.com/containers/faq/) states \"All disk is ephemeral. When a Container instance goes to sleep, the next time it is started, it will have a fresh disk as defined by its container image.\"\n- True container-level disk snapshots are still listed as \"coming soon\" in that same FAQ, and the April 13, 2026 Containers/Sandboxes GA changelog (developers.cloudflare.com/changelog/post/2026-04-13-containers-sandbox-ga/) only describes Sandbox SDK backup/restore built on a FUSE overlay to R2 — not native snapshotting, which the changelog itself says will be added later. So \"snapshots still coming soon as of 2026\" checks out.\n\nRefuted part:\n- The \"1GB/object today, ~10GB at GA\" framing for Durable Objects SQLite storage is stale/wrong. SQLite storage in Durable Objects already went GA in April 2025 (Cloudflare changelog: \"SQLite in Durable Objects GA with 10GB storage per object,\" 2025-04-07), and the current limits page (developers.cloudflare.com/durable-objects/platform/limits/) lists 10GB per object as the current limit on the Workers Paid plan today — not a future/GA target. 1GB is simply the Free-plan ceiling, not a \"beta\" precursor to a future 10GB GA bump. So describing 10GB as something arriving \"at GA\" is inaccurate; GA already happened over a year before this claim's context, and 10GB is the present-day figure.\n\nNet effect: the core \"ephemeral disk / rearchitect onto DO / snapshots not yet available\" conclusion is directionally still correct and well-supported, but the specific supporting fact about DO SQLite storage capacity progression is outdated/incorrect as stated, which is enough to refute the claim as written (it misrepresents current capability, understating DO SQLite storage as smaller/less mature than it actually is today).", "SQLite-backed Durable Objects storage is already generally available (GA since April 7, 2025) at 10GB per object on the Workers Paid plan — not a future/upcoming GA target. The 1GB figure applies only to the Workers Free plan (5GB total account storage), not as a \"today\" stage that later becomes 10GB. Sources: https://developers.cloudflare.com/changelog/post/2025-04-07-sqlite-in-durable-objects-ga/ and https://developers.cloudflare.com/durable-objects/platform/limits/. The container-ephemeral-disk and \"snapshots coming soon\" portions of the claim are accurate per https://developers.cloudflare.com/containers/faq/.", "SQLite storage in Durable Objects is already generally available (since 2025-04-07), not still ramping from 1GB to 10GB \"at GA.\" Current limits are 10GB per SQLite-backed Durable Object on the Workers Paid plan (1GB on the Free plan) — this is the live, current limit, not a future GA target. Source: https://developers.cloudflare.com/changelog/2025-04-07-sqlite-in-durable-objects-ga/ and https://developers.cloudflare.com/durable-objects/platform/limits/. The claim's other assertions (ephemeral container disk resetting to base image on restart; true disk snapshots still \"coming soon\") are accurately supported by https://developers.cloudflare.com/containers/faq/." ] }, { "claim": "Fly.io's LiteFS Cloud was sunset in Oct 2024 and LiteFS itself is deprioritized/pre-1.0 with no roadmap, so new projects are steered toward Turso/Cloudflare D1 or the simpler pattern of a single machine + attached volume with Litestream continuously replicating SQLite to S3-compatible object storage (avoiding LiteFS's distributed-consensus complexity).", "corrections": [ "The claim bundles a true, verifiable fact with an overstated/unsupported narrative.\n\nVerified true: LiteFS Cloud (the managed backup/replication service) was indeed sunset on Oct 15, 2024 (confirmed via Fly.io community thread \"Sunsetting LiteFS Cloud\" and Fly docs). LiteFS itself (the open-source FUSE-based distributed SQLite tool) remains pre-1.0 with the docs stating \"APIs may change and features could be removed.\"\n\nNot supported / contradicted: The claim's framing that LiteFS is \"deprioritized with no roadmap\" and that Fly.io is actively \"steering\" new projects away from it toward Turso/D1 or single-node Litestream+S3 \"to avoid LiteFS's distributed-consensus complexity\" is not what the sources say:\n- LiteFS's own repo shows active maintenance (release history continuing into 2025, pushes into 2026), contradicting \"deprioritized with no roadmap.\"\n- Fly's official FAQ frames the choice as use-case based, not deprecation based: \"you'll typically choose Litestream for single-server deployments and LiteFS for multi-server deployments\" — i.e., they're complementary tools for different topologies, not a deprecated-vs-recommended pair.\n- A Fly.io community thread on the exact Litestream single-node pattern cited as a source explicitly states \"LiteFS is the intended future for live replication\" — directly contradicting the idea that LiteFS is a dead-end being steered away from.\n- The first claimed source (tianpan.co forum post) does not actually discuss the LiteFS Cloud sunset, does not compare LiteFS unfavorably to Turso/D1, and makes no recommendation steering readers away from LiteFS — it doesn't support the claim as stated.\n\nSo the underlying sunset date and pre-1.0 status are accurate, but the claim's causal narrative (dead-end technology being abandoned in favor of Turso/D1/Litestream-only) is not supported by the cited sources and is contradicted by Fly's own guidance, which still positions LiteFS as the multi-server replication solution.\nLiteFS Cloud (managed backups) was sunset Oct 15, 2024 — that part is correct (https://community.fly.io/t/sunsetting-litefs-cloud/20829). But LiteFS the open-source project is not \"deprioritized with no roadmap\" being abandoned for Turso/D1 — it remains actively maintained (releases into 2025, repo activity into 2026) and Fly's own FAQ (https://fly.io/docs/litefs/faq/) still recommends it specifically for multi-server deployments (\"choose Litestream for single-server deployments and LiteFS for multi-server deployments\"), while a Fly community thread explicitly calls LiteFS \"the intended future for live replication\" (https://community.fly.io/t/litestream-single-node-deployments-with-attached-volumes/21289). The cited tianpan.co source doesn't discuss the sunset or make any such recommendation at all. The correct picture: pick Litestream+S3 for single-node disaster-recovery-only setups, and LiteFS for multi-node live replication — it's a topology-based choice, not a deprecated-vs-current one; Turso/D1 are separate managed alternatives, not framework replacements Fly is steering users toward.", "Checked both claimed sources directly and neither actually supports the claim as framed:\n\n1. https://tianpan.co/forum/t/sqlite-in-production... — mentions LiteFS only in passing (\"Fly.io's answer to SQLite replication... uses FUSE to intercept filesystem operations\") as one viable option among several. It says NOTHING about LiteFS being deprioritized, pre-1.0-with-no-roadmap, or about steering new projects away from it toward Turso/D1. This source does not support the claim.\n\n2. https://community.fly.io/t/litestream-single-node-deployments-with-attached-volumes/21289 — is a technical Q&A about volume-mount limitations for single-node Litestream deployments; it contains no mention of sunset dates, deprecation, or roadmap status. It also does not support the claim.\n\nSeparately verified against actual primary sources (not the ones cited):\n- LiteFS Cloud (the managed backup add-on) genuinely was sunset — retired Oct 15, 2024, confirmed via Fly.io's own community announcement (community.fly.io/t/sunsetting-litefs-cloud/20829). But Fly.io explicitly stated \"we are not sunsetting LiteFS itself\" — only the Cloud backup service.\n- LiteFS core is indeed still documented as \"pre-1.0\" (fly.io/docs/litefs/: \"still pre-1.0 so APIs may change\"), but Fly's own docs describe it as \"stable and running in production,\" and the GitHub repo (superfly/litefs) shows continued commits/activity into 2025–2026 — contradicting \"deprioritized... with no roadmap.\"\n- Fly.io's sunset announcement did recommend two paths: (a) LiteFS + Litestream backing up to S3-compatible storage (Tigris), which Fly said is their own internal approach, and (b) Turso as a fully-managed alternative. Cloudflare D1 was not part of Fly's own recommendation in that announcement.\n\nNet: the underlying facts about LiteFS Cloud's Oct 2024 sunset and LiteFS's pre-1.0 status are roughly correct, but (a) the two specific sources cited do not actually contain or support this claim — a citation-accuracy failure — and (b) the stronger framing (\"deprioritized... no roadmap... new projects steered toward Turso/D1... avoiding LiteFS's complexity\") overstates what Fly.io has said; Fly.io explicitly continues to support LiteFS+Litestream as its own recommended, non-deprecated pattern, and the project shows ongoing 2025-2026 activity rather than being sidelined with \"no roadmap.\"" ] }, { "claim": "Using Terraform for local/simple Docker container setups is explicitly called overkill; for truly small projects, plain Docker Compose alone is often sufficient, and managed PaaS platforms offer 'just deploy this container' simplicity without needing any IaC tool.", "corrections": [ "The oneuptime.com article does not call Terraform overkill for local/simple Docker setups — it recommends combining Terraform with Docker Compose for exactly those small-to-medium scenarios, and reserves \"overkill\" for Kubernetes, not Terraform. Source: https://oneuptime.com/blog/post/2026-02-23-how-to-use-terraform-with-docker-compose/view (\"The Terraform-Docker Compose combination is particularly useful for development environments, small-to-medium production deployments, and situations where Kubernetes would be overkill.\"). The encore.dev source's claim about PaaS/Cloud Run offering \"just deploy this container\" simplicity is accurately represented: https://encore.dev/articles/kubernetes-alternatives.\n", "The oneuptime.com article actually argues FOR using Terraform with Docker Compose for small-to-medium deployments (it says Kubernetes, not Terraform, would be overkill there), directly contradicting the claim's characterization. See https://oneuptime.com/blog/post/2026-02-23-how-to-use-terraform-with-docker-compose/view. The encore.dev article does support the \"managed PaaS eliminates IaC need\" point (naming Railway/Render/Fly.io) but is a vendor blog promoting a competing product (Encore), so treat as a self-interested source, not neutral confirmation. The practical takeaway — skip Terraform/OpenTofu for a small single-container deploy in favor of plain Docker Compose or a PaaS — is reasonable general practice, but shouldn't be attributed to these two sources as stated.\n\n" ] }, { "claim": "General practitioner guidance: use OpenRouter when multi-model, spending under $500/month, or needing production failover; go direct to the provider when single-provider and spending over $2,000/month, since high single-provider volume unlocks direct rate-limit tiers and caching/batch integration OpenRouter's abstraction doesn't fully expose.", "corrections": [ "The $500/$2,000 thresholds are real and traceable to betterclaw.io's decision framework (\"Monthly LLM spend under $500... Use OpenRouter\"; \"over $2,000... Go direct\"), but that article's own stated reason for going direct at high volume is just the 5.5% OpenRouter credit-purchase fee becoming a large dollar figure, plus a passing mention of direct APIs having \"documented rate limits, priority tiers, and support\" — it never mentions caching or batch-processing integration. The other cited source, llmprice.fyi, contains no dollar thresholds whatsoever and also never discusses caching or batch integration. See https://www.betterclaw.io/blog/openrouter-vs-direct-api-agents and https://www.llmprice.fyi/guides/openrouter-vs-direct-api — the \"caching/batch integration\" rationale in the claim is not supported by either source.\n", "The $500/$2,000 thresholds are real (confirmed on betterclaw.io: \"under $500/month\" → OpenRouter, \"over $2,000/month, production agents\" → go direct; https://www.betterclaw.io/blog/openrouter-vs-direct-api-agents), but they're calibrated for a single company aggregating production-agent spend on its own key, not for TachiBot's BYOK local-first model. Here each user supplies their own keys and pays providers directly regardless of routing; the project already mixes direct APIs (Perplexity/Grok/OpenAI/Gemini) with OpenRouter (DeepSeek/GLM/Kimi/Qwen/MiniMax/StepFun/ERNIE) by design, choosing OpenRouter for access to lab-diverse/exotic models rather than for cost-at-scale reasons. A typical user of this MCP server won't approach $2,000/month on a single provider, so the \"go direct for rate-limit tiers\" trigger the sources describe doesn't map onto this project's actual usage pattern — the rule is true in general but not the right lens for this codebase's sourcing decision." ] }, { "claim": "OpenAI GPT-5.5 is priced at $5.00/1M input and $30/1M output tokens, with prompt caching cutting cached input to $1.25/1M (75% off) for shared prefixes of 1,024+ tokens; the Batch API adds a separate, stacking 50% discount on both input and output.", "corrections": [ "GPT-5.5 cached input pricing is $0.50 per 1M tokens (a 90% discount off the $5.00 standard input rate), not $1.25/1M (75% off) as claimed. Input ($5.00/1M) and output ($30.00/1M) standard rates, and the Batch API's stacking 50% discount on both input and output (to $2.50/$15 per 1M), are correct. Source: https://developers.openai.com/api/docs/pricing (verified via two independent fetches). Note: the second cited source, tokenmix.ai/blog/openai-batch-api-pricing, discusses GPT-5.4 cache+batch stacking economics, not GPT-5.5, so it does not actually substantiate the GPT-5.5 cached-price figure.", "Per the official OpenAI pricing page (https://developers.openai.com/api/docs/pricing): GPT-5.5 is $5.00/1M input and $30.00/1M output tokens (correct in the claim), but cached input is $0.50/1M tokens — a 90% discount — not $1.25/1M (75% off) as claimed. Batch API pricing is $2.50/1M input and $15.00/1M output (50% off standard rates), which is roughly consistent with the claim's Batch discount description, but the cached-input figure is wrong.", "GPT-5.5 cached input is $0.50 per 1M tokens (90% discount off the $5.00 standard input price), not $1.25/1M at 75% off. Standard input/output ($5.00/$30.00 per 1M) and the stacking 50% Batch API discount on input and output are accurate. Source: https://developers.openai.com/api/docs/pricing (fetched directly, corroborated by https://openrouter.ai/openai/gpt-5.5 and other trackers)." ] } ] }