# qlaud — structured index for LLM bots

This is the metadata-rich companion to https://qlaud.ai/llms.txt. For
each public blog post we list title, description, category, author,
publish date, reading time, tags, and canonical URL. Fetch the URL
for full body content.

Every URL below is publicly crawlable and explicitly allowed in
/robots.txt for GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot,
claude-web, anthropic-ai, Google-Extended, Googlebot, PerplexityBot,
Applebot-Extended, CCBot, Bytespider, cohere-ai, Meta-ExternalAgent,
Bingbot, xAI-Bot, MistralAI-User, YouBot, Diffbot, KagiBot, and more.

---

## How I cut my AI app's OpenAI bill 60% with per-user API keys

> A $5,247 bill I couldn't attribute. The naive Postgres approach that didn't scale. The per-user-keys pattern that fixed it — with the actual numbers, code, and the 60% cost reduction in 6 weeks.

- URL: https://qlaud.ai/blog/cut-openai-bill-per-user-keys
- Category: Architecture
- Published: 2026-04-30
- Author: qlaud team — Engineering
- Reading time: 9 minutes
- Tags: openai per user billing, ai cost attribution, ai cost tracking, per user openai api key, openai cost attribution per user, anthropic cost per user, ai app cost surprise, llm gateway, ai usage metering, stripe ai billing

### FAQ preview (6 questions)

**Q: Can I tag OpenAI requests with a user_id and let OpenAI attribute the cost?**

A: Not directly. OpenAI's organization usage view shows aggregate spend; the metadata field on Chat Completions is searchable in the playground but not surfaced as a per-user cost rollup in any first-party billing API. You can build your own rollup by logging every request with token counts and pricing — but that's the rabbit hole this post is about. The shorter path: mint a key per user with a cap, let the gateway do the attribution.

**Q: How is per-user API key attribution different from rate limiting?**

A: Rate limiting bounds requests-per-second; it doesn't bound total spend. A user could send one request per second for 30 days and burn $1,000+ within your rate-limit budget. A hard spend cap stops the bleeding at $10 (or whatever you set) regardless of request rate. Both are useful — caps are the financial backstop, rate limits are the abuse backstop.

**Q: Won't this slow down my requests?**

A: qlaud's edge gateway runs on Cloudflare Workers — added latency is single-digit milliseconds for the auth + cap check, then it forwards to the provider. The native-passthrough path for Anthropic preserves prompt-cache headers verbatim, so cache-heavy workflows actually get faster (cache hits land at edge before the upstream call).

**Q: What about Anthropic and other providers, not just OpenAI?**

A: Same pattern works. Set ANTHROPIC_BASE_URL=https://api.qlaud.ai and your Anthropic SDK becomes a qlaud client. Same for ElevenLabs (xi-api-key), Vercel AI SDK, LangChain, LiteLLM. One per-user key works across every model and provider — your cost rollup unifies them.

**Q: What happens when a user hits their cap mid-stream?**

A: qlaud does a pre-flight check before each request. If the cap is exceeded, the request returns 402 Payment Required immediately. We allow cents-level overdraft on an already-streaming response (killing it mid-token would be jarring) but the next request after that 402s. Your UI catches the 402 and shows the user a 'cap reached, upgrade to keep going' modal.

**Q: Is this overkill for a small app?**

A: If you have 10 users you can probably tolerate the risk. If you have 100+ users — especially anonymous-trial users — one bad actor can drain your wallet faster than you can react. The cost of adding per-user keys is ~30 minutes; the cost of not adding them is whatever your worst user can spend in a weekend.


---

## The hidden infrastructure you build when you ship AI chat

> A chat textarea is a 30-minute build. The persistence, streaming reassembly, dedup, tool-call audit trail, and history endpoint that turn it into a real product is 3+ weeks. A walkthrough of what breaks, in what order, and how to skip most of it.

- URL: https://qlaud.ai/blog/hidden-infrastructure-ai-chat
- Category: Architecture
- Published: 2026-04-30
- Author: qlaud team — Engineering
- Reading time: 11 minutes
- Tags: ai chat persistence, ai chat streaming, openai streaming reassembly, ai conversation history database, ai agent infrastructure, ai app backend, tool calling persistence, stream chunks ai chat, managed ai stack, llm gateway

### FAQ preview (5 questions)

**Q: Why not just use the OpenAI Assistants API for chat persistence?**

A: Assistants API gives you threads + persistence on OpenAI's infra, but only for OpenAI models. The moment you want Anthropic, DeepSeek, or any local model in the same conversation history, you're back to building it yourself. Plus Assistants pricing is unpredictable (file storage + retrieval costs add up). A model-agnostic gateway with persistence is the cleaner long-term architecture.

**Q: Can I use Vercel KV / Supabase for chat persistence and skip the gateway?**

A: Yes — but you still own the streaming reassembly, the deduplication on retries, the tool_use/tool_result audit trail, and the history endpoint. Persistence storage is the easy 20%; reliable streams + tool history is the hard 80%. The gateway approach addresses all of it server-side. The right call depends on whether your competitive advantage is in chat infrastructure (then build it) or in your domain product (then don't).

**Q: What happens to in-flight messages when the user's browser disconnects?**

A: With a roll-your-own setup, the partial response is gone unless you've explicitly buffered it server-side. With qlaud's threads API, the message is captured at the gateway as it streams, persisted, and retrievable on reconnect. The user reloads the page and the message is still there. This is the kind of polish that makes chat apps feel solid vs. feel hacky.

**Q: Do I need a vector database for chat history?**

A: If you want semantic search over past conversations (e.g., 'find all messages where I asked about X'), yes. If you only want last-N-messages context, no — a simple ordered list is enough. qlaud bundles vector search via Cloudflare Vectorize so semantic retrieval is one API call rather than a separate Pinecone integration; for last-N you just hit the messages endpoint with a limit.

**Q: How does this work with tool calls that return errors mid-conversation?**

A: Tool failures are first-class in the persisted history — every tool_use block has a matching tool_result block, including is_error: true and the error message. The model sees the failure on retry and can route around it. This is the 'tool history' part most roll-your-own implementations skip, and it's why 'AI agent loops' end up brittle without it.


---

## qlaud vs OpenRouter: when to pick which

> OpenRouter is a router. qlaud is a router PLUS per-user billing, threads, semantic search, and 100+ vendor MCP connectors — one platform, one bill.

- URL: https://qlaud.ai/blog/qlaud-vs-openrouter
- Category: Product
- Published: 2026-04-28
- Author: qlaud team — Engineering
- Reading time: 8 minutes
- Tags: openrouter alternative, AI gateway, LLM router, per-user billing, MCP catalog, AI tools

### FAQ preview (4 questions)

**Q: Is qlaud just a fork of OpenRouter?**

A: No. qlaud is built from scratch on Cloudflare Workers + Cloudflare AI Gateway. We share the routing pattern (one base URL, many providers, native SDK shapes preserved) but qlaud also includes per-user keys with hard spend caps, a Stripe-backed prepaid wallet, threads + semantic search as a managed primitive, 35 vendor-hosted MCP connectors that auto-enable per end-user, and 12 first-party tool builtins (E2B code execution, web search, image gen, send email, GitHub, Slack, Linear, Notion, etc.). OpenRouter is one layer of what qlaud is.

**Q: Can I migrate from OpenRouter to qlaud without rewriting?**

A: Yes. Both accept the same OpenAI-shape and Anthropic-shape APIs. Swap two env vars (`OPENAI_BASE_URL`, `ANTHROPIC_BASE_URL`) and your existing SDK code keeps working. Model slugs differ slightly per catalog — qlaud uses provider-native model IDs (e.g. `claude-sonnet-4-6`, `gpt-5.4`) so the strings you'd already pass to the official SDK work directly.

**Q: What about pricing — is qlaud's 7% markup more than OpenRouter's?**

A: OpenRouter charges ~5% on inference plus 5.5% on Stripe top-ups (so ~10.5% all-in if you're paying with card). qlaud charges a flat 7% gateway markup on inference, no separate top-up fee. Roughly comparable; the actual difference depends on volume and how you fund. Either way you save vs. integrating each provider's billing separately.

**Q: When should I pick OpenRouter instead?**

A: If you only need raw model routing for an internal team, no per-user billing, no managed tools, no threads — OpenRouter's a clean fit and you'll spin it up faster (no need to learn qlaud's threads/tools surface). The moment your app has end-users you bill, or your model needs to call Linear / GitHub / E2B / web search, qlaud's the more pragmatic platform — those layers are built-in instead of you wiring them yourself.


---

## qlaud vs LiteLLM: same proxy idea, different layer

> LiteLLM is a self-hosted proxy. qlaud is hosted with per-user billing, threads, semantic search, and 100+ tool connectors built in. When to pick which.

- URL: https://qlaud.ai/blog/qlaud-vs-litellm-managed-vs-self-hosted
- Category: Product
- Published: 2026-04-28
- Author: qlaud team — Engineering
- Reading time: 7 minutes
- Tags: litellm alternative, ai proxy comparison, llm gateway, openai compatible proxy, self-hosted ai proxy, managed ai gateway

### FAQ preview (4 questions)

**Q: Can I use both LiteLLM and qlaud together?**

A: Technically yes — point LiteLLM's `litellm_params.api_base` at qlaud and you get LiteLLM's Python interface to qlaud's gateway. But there's no real reason — qlaud already exposes the same OpenAI-compatible interface LiteLLM proxies for, and you'd be paying both layers (LiteLLM hosting cost + qlaud's 7%). Pick one.

**Q: Does LiteLLM support per-user spend caps?**

A: LiteLLM has user-level budgets via its `LiteLLM-User-API-Key` middleware in the Enterprise tier. The Open Source version supports virtual keys + per-team budgets but not the per-user-key + spend-cap-enforced-pre-flight pattern qlaud was built around. If per-end-user billing is core to your app, qlaud is built for it; if you only need internal team budgets and self-hosting, LiteLLM works.

**Q: What about threads, tool catalog, semantic search?**

A: LiteLLM is a routing proxy. It doesn't ship threads (you build that), it doesn't ship a vendor MCP catalog (you wire each integration), it doesn't ship semantic search. qlaud bundles all three as managed primitives. If you only need routing — LiteLLM is a fine choice. If you'd otherwise build the rest yourself, qlaud collapses ~6 weeks of plumbing.

**Q: Is LiteLLM faster because it cuts out a network hop?**

A: Marginally — if you self-host LiteLLM in the same datacenter as your app, you save ~10-30ms vs. a hop to a hosted gateway. qlaud runs on Cloudflare's global edge (300+ PoPs), so the hop usually adds 5-15ms wherever your users are. For most apps the difference is invisible. If you need single-digit-millisecond inference latency, you probably already know it.


---

## 47 tools out of the box: 35 vendor MCP connectors + 12 first-party builtins

> Every qlaud account ships with 100+ vendor MCP connectors and 12 first-party builtins (E2B, web search, image gen, email). Auto-discovered.

- URL: https://qlaud.ai/blog/47-tools-out-of-the-box-mcp-catalog-plus-builtins
- Category: Product
- Published: 2026-04-28
- Author: qlaud team — Engineering
- Reading time: 9 minutes
- Tags: mcp catalog, mcp servers, linear mcp, github mcp, clickup mcp, notion mcp, stripe mcp, e2b code execution, ai tools, ai connectors

### FAQ preview (4 questions)

**Q: Do I have to register each connector before my end-users can use it?**

A: No. Per-user-capable catalog connectors (Linear, GitHub, ClickUp, Asana, Notion, etc.) are default-enabled for every qlaud account. When your model calls qlaud_search_tools("linear issue"), Linear shows up in available_connectors automatically. The end-user gets prompted once via a hosted connect URL to paste their Linear API key, and the tools materialize for that user. Tenant-only connectors (Stripe, Sentry, Datadog — things that need company credentials) you register once via the dashboard.

**Q: Where do credentials live and how are they protected?**

A: Per-user connector credentials are encrypted with AES-256-GCM using a key qlaud holds outside the database, scoped to one (developer, end-user, vendor) tuple. They never enter the chat history — the user pastes them into a qlaud-hosted form via a one-time URL, and the model only ever sees "connected" or "not_connected". Built-in tools where the developer supplies a tenant-shared key (Resend, Brave, OpenAI image gen) are encrypted the same way.

**Q: What's the difference between vendor MCP connectors and first-party builtins?**

A: MCP connectors point at vendor-hosted MCP servers (mcp.linear.app, mcp.clickup.com, etc.). The vendor maintains the tools; qlaud handles auth, discovery, and dispatch. Builtins are tools qlaud implements directly inside the gateway worker (E2B for code execution, Brave for web search, Resend for email, OpenAI for image gen, etc.) — usually because the upstream provider doesn't ship an MCP server but does have a clean REST API. From the model's perspective both look identical.

**Q: Can I add my own custom MCP server or webhook tool?**

A: Yes. POST /v1/mcp-servers with a `server_url` and optional `auth_headers` to register any HTTPS-reachable MCP server (your own internal one, or a long-tail vendor not in our catalog). POST /v1/tools with a `webhook_url` to register a plain HTTPS webhook as a tool — qlaud HMAC-signs the dispatch and your server returns the result. Both paths get the same model-facing surface as catalog tools.


---

## Stop building auth, billing, and a database for your AI app

> The default AI-app stack is Clerk + Stripe + Postgres + a custom proxy. qlaud collapses three of those four into one platform. You write the chat UI.

- URL: https://qlaud.ai/blog/stop-building-ai-app-backend-billing-database
- Category: Architecture
- Published: 2026-04-28
- Author: qlaud team — Engineering
- Reading time: 7 minutes
- Tags: ai app backend, stripe for ai, ai billing, managed ai infrastructure, no database chatbot, per-user keys

### FAQ preview (4 questions)

**Q: Doesn't 'no database' just mean qlaud is your single point of failure?**

A: qlaud's data plane is Cloudflare D1 + Durable Objects + Vectorize across the global edge — the same primitives Cloudflare uses for their own production services. We expose every piece of your data via API: GET /v1/threads/:id/messages dumps the full transcript any time you want it, GET /v1/usage exports billing rollups. If you ever want to migrate off, the data is yours to take. The 'no database' promise is about not running ONE for your AI state — not about lock-in.

**Q: How does this compare to Supabase + the OpenAI SDK?**

A: Supabase gives you Postgres + auth, you still wire metering, spend caps, threads, semantic search, and tool dispatch yourself. That's a quarter of engineering. qlaud gives you all four as managed primitives, you keep Clerk (or Supabase Auth) for sign-in, and ship the actual product. Roughly: Supabase + OpenAI = batteries-not-included; qlaud = batteries-included for the AI layer specifically.

**Q: What if I need a custom DB for non-AI app data?**

A: Use one. qlaud handles AI-specific state (threads, messages, semantic index, tool credentials, wallet). You still need a DB for product data — user profiles, settings, your own business logic. Most apps end up with a small Postgres or SQLite for app state + qlaud for everything AI-shaped. The 'no database' claim is specifically about the chat-backend bit.

**Q: Can I self-host qlaud if I don't want a managed service?**

A: Not currently. qlaud is a hosted service (Cloudflare Workers + D1 + DO). If you specifically need self-hosted (on-prem, air-gapped, regulated environment) the right tool is LiteLLM for routing + your own per-user metering layer. qlaud's value proposition is 'don't run infrastructure for your AI app' — which is the wrong fit if you must run infrastructure.


---

## Build a ChatGPT clone in 200 lines (no database)

> End-to-end Next.js + Clerk + qlaud tutorial: per-user keys, streaming chat with auto-history, semantic search, 100+ connectors live — no Postgres, no Pinecone.

- URL: https://qlaud.ai/blog/build-chatgpt-clone-200-lines-no-database
- Category: Tutorials
- Published: 2026-04-28
- Author: qlaud team — Engineering
- Reading time: 10 minutes
- Tags: build chatbot nextjs, chatgpt clone tutorial, next.js ai chatbot, clerk ai, streaming chat, no database chatbot

### FAQ preview (4 questions)

**Q: How big is the Postgres I'd usually need for a chat app?**

A: For a chat app at any real scale: a `messages` table with `(thread_id, seq, role, content_jsonb, created_at)`, a unique index, a per-user retention cron, GDPR cascade-deletes, an embedding pipeline that fires on every message, and a vector index for semantic search. Maintaining this at scale is a part-time job for one engineer. qlaud handles it as a managed primitive — your code never touches a DB for chat state.

**Q: Does the model see the full thread on every turn?**

A: Yes. POST /v1/threads/:id/messages with just `content` (the new user turn) auto-loads prior messages into the model's context. You don't pass a `messages` array — qlaud assembles it from persisted history. For long threads we apply a sliding-window strategy that keeps the system message + recent turns + relevant retrieval; you can override by passing a full `messages` array if you want explicit control.

**Q: How does pagination work for the chat UI scroll-up?**

A: GET /v1/threads/:id/messages?order=desc&limit=30 returns the latest 30 messages newest-first (the initial paint). For older messages, pass `before_seq` from the previous response: `?order=desc&limit=30&before_seq=12`. The cursor-based shape (instead of offset/limit) means infinite scroll stays consistent even if a new message arrives mid-scroll.

**Q: What about real-time updates if the same thread is open in two tabs?**

A: qlaud doesn't push WebSocket updates for thread mutations (yet). For the same-user-multi-tab case, the cleanest pattern is your client polling /v1/threads/:id/messages?after_seq=last_known on focus, or using BroadcastChannel for cross-tab sync within one browser. Most chat apps don't need cross-tab realtime — it's nice-to-have, not table-stakes.


---

## Per-user AI billing in 5 minutes (without rebuilding metering)

> The four-step playbook with qlaud — mint per-user keys, cap spend, meter usage, bill — using the official SDKs you're already using. Ship in 5 minutes.

- URL: https://qlaud.ai/blog/per-user-ai-billing-in-5-minutes
- Category: Tutorials
- Published: 2026-04-25
- Author: qlaud team — Engineering
- Reading time: 7 minutes
- Tags: per-user billing, AI gateway, usage metering, Stripe, API keys, spending caps

### FAQ preview (4 questions)

**Q: Why not just rate-limit my own OpenAI/Anthropic key?**

A: Provider keys are global. You can't enforce per-user caps, can't see per-user spend, and one runaway user (or a leaked client-side key) can drain your account in minutes. qlaud mints a key per end-user with a hard spend cap enforced at the gateway — over the cap, the request returns 402 before it ever hits the provider.

**Q: Do I need to rewrite my app to use qlaud?**

A: No. qlaud accepts the official SDK request shape from OpenAI, Anthropic, ElevenLabs, Vercel AI SDK, LangChain, LlamaIndex — verbatim. You change one line: the base URL. Your app code, your prompts, your response handling — all unchanged.

**Q: How do I bill the user the markup I want to charge?**

A: qlaud charges you the upstream cost plus a flat 7% gateway fee. Whatever margin you put on top of that is yours — set it in your Stripe / Paddle / Lemon Squeezy product, charge per-token, charge per-feature, charge a flat subscription with a usage allowance. The /v1/usage endpoint gives you per-user cost in micros; you decide what to invoice.

**Q: What if a user goes over their cap mid-request?**

A: qlaud does a pre-flight check before forwarding. If the cap is already exceeded the request returns 402 Payment Required immediately. We tolerate cents-level overdraft on a single in-flight stream rather than killing it mid-response — once the stream finishes the next request is blocked until you raise the cap or top up.


---

## Point your coding agent at qlaud — Claude Code, Codex, Aider, Cline, Cursor

> Point Claude Code, Codex, Aider, Cline, or Cursor at qlaud — one base URL, per-user spend caps, every frontier model. Setup snippets for each agent.

- URL: https://qlaud.ai/blog/use-your-coding-agent-with-qlaud
- Category: Tutorials
- Published: 2026-04-25
- Author: qlaud team — Engineering
- Reading time: 6 minutes
- Tags: Claude Code, Codex, Aider, Cline, Cursor, CLI, agentic coding

### FAQ preview (4 questions)

**Q: Does qlaud work with Claude Code?**

A: Yes — point ANTHROPIC_BASE_URL at https://api.qlaud.ai and ANTHROPIC_API_KEY at your qlaud key. We expose the Anthropic Messages API as native passthrough, so cache_control, image blocks, thinking blocks, and tool_use are preserved exactly. Claude Code can't tell the difference from api.anthropic.com.

**Q: Will I lose context-management or tool features?**

A: No. We forward every Anthropic header (anthropic-beta, anthropic-version) and preserve the full request body. Claude Code's context-management and tool-call features depend on those headers, and they pass through verbatim.

**Q: Why route my coding agent through qlaud at all?**

A: Three reasons. (1) Hard spend cap per key — your agent can't run away with your wallet. (2) Per-key usage breakdown — see exactly which model and which session burned tokens. (3) Multi-provider access from one key — switch from Claude to GPT-5.4 to Kimi K2.6 to DeepSeek V3 by changing only the model string, no SDK or env changes.

**Q: Can I use qlaud for my team and bill each developer separately?**

A: Yes — mint one qlaud key per developer with their own cap, and pull /v1/usage at month-end for a per-developer breakdown. The same pattern works for billing your end-users if you're shipping a product that wraps a coding agent.


---

## Building qlaud on Cloudflare AI Gateway in five days

> How qlaud was built on Cloudflare AI Gateway in five days — architecture, primitives, and the trade-offs that made shipping per-user billing fast.

- URL: https://qlaud.ai/blog/building-qlaud-on-cloudflare-ai-gateway
- Category: Architecture
- Published: 2026-04-25
- Author: qlaud team — Engineering
- Reading time: 8 minutes
- Tags: Cloudflare, AI Gateway, Workers, Durable Objects, D1, serverless

### FAQ preview (3 questions)

**Q: Why not just use OpenRouter?**

A: OpenRouter is great. We use it ourselves as a fallback path for models AIG doesn't directly support. But we wanted: (1) BOTH Anthropic /v1/messages AND OpenAI /v1/chat/completions as equal first-class surfaces — every coding agent and SDK works directly without translation shims, (2) Cloudflare AI Gateway in our control plane for free observability + caching, (3) prepaid wallet semantics that match how indie devs actually budget.

**Q: How does AI Gateway differ from Workers AI?**

A: Workers AI runs open-source inference on Cloudflare's own GPUs — you pay them, they serve the model. AI Gateway is a routing/observability/caching proxy in front of any LLM provider (OpenAI, Anthropic, Groq, DeepSeek, etc.) — you bring your provider key, AIG handles retries, cache, analytics, custom-cost reporting. We use both: AIG for the routing layer, Workers AI as one of the catalog providers.

**Q: Did you really build this in five days?**

A: End-to-end working through Phase 3 (auth + AIG routing + multi-provider catalog + D1 + Stripe wallet + Clerk webhook + dashboard) — yes. The Anthropic↔OpenAI streaming SSE translator was the hardest single piece. The rest is plumbing.


---

## Why Claude Code on DeepSeek V3 costs 30× less than Claude direct

> DeepSeek V3 via qlaud delivers Claude-class agentic coding for ~30x less than Claude direct. The pricing math and cap pattern that make it work.

- URL: https://qlaud.ai/blog/why-claude-code-on-deepseek-costs-30x-less
- Category: Benchmarks
- Published: 2026-04-25
- Author: qlaud team — Engineering
- Reading time: 6 minutes
- Tags: Claude Code, DeepSeek, cost, open models, agentic coding

### FAQ preview (3 questions)

**Q: Is DeepSeek V3 actually as good as Claude 3.5 Sonnet for coding?**

A: On day-to-day refactoring, code review, test generation and Python/TS/Rust tasks: very close. On long-horizon agentic loops with heavy tool use, Claude still has an edge. Most users land on a hybrid — DeepSeek for the bulk, Claude for the hardest 10%.

**Q: Will Claude Code break if I point it at qlaud?**

A: No. Claude Code reads ANTHROPIC_BASE_URL and ANTHROPIC_API_KEY from your environment. We expose the Anthropic Messages API verbatim, including streaming SSE, tool use, and reasoning content blocks. Same UX, different upstream.

**Q: How do reasoning models work over the Anthropic surface?**

A: DeepSeek-R1 emits reasoning_content as a separate stream channel. Our SSE translator opens an Anthropic 'thinking' content block for those deltas, so Claude Code renders the chain-of-thought in its UI just like it would for a real Claude reasoning model.


---