# Till — Full AI-readable Overview ## Summary Till is a hosted control layer for AI provider credentials. It lets an operator connect encrypted provider accounts and issue a disposable, scoped Till key to an AI agent, automation, contractor, demo, or experiment instead of sharing a broad provider credential. Every scoped key has a required maximum number of activations. An activation is a provider request attempt dispatched by Till. A key may also have token, estimated-spend, expiration, and source-IP limits. Till checks the applicable controls, selects a configured provider connection, forwards an accepted request, and returns machine-readable usage and remaining-capacity signals. Till is a controlled customer beta. Public anonymous signup is disabled; new accounts are approved and provisioned manually. The hosted service and the separate `till-ac` Python package are supported. This repository is not presented as a public npm package, Docker image, or supported self-hosting distribution. ## Primary audience and use cases - Developers and small technical teams running AI agents or automated workloads. - Agent runs that need an explicit request, token, or estimated-spend boundary. - Contractors or freelancers who need project-specific, revocable AI access. - Product demos and trials that should operate inside a pre-set envelope. - Teams separating credentials and counters by project for clearer attribution. ## Core product model 1. An operator adds one or more provider connections to a Till tenant. 2. Till stores each provider credential as versioned AES-256-GCM ciphertext. 3. The operator creates a provider-agnostic Till key with a required activation ceiling and any optional controls. 4. The workload sends a supported provider request using the Till key as its bearer credential. 5. Till authenticates the key, selects a configured provider from route/model/default signals, checks limits, and reserves eligible token or spend capacity. 6. Till forwards an accepted request and returns the provider response with Till telemetry headers. 7. The key stops accepting requests when a configured limit is reached, it expires, or it is revoked. Local validation failures do not permanently consume an activation. Once an upstream provider attempt is dispatched, the activation counts even if the provider or network later fails. Token and spend reservations are concurrency guards and settle to provider-reported usage. ## Limits and controls - **Activations (required):** maximum provider request attempts Till may dispatch for the key. - **Tokens (optional):** total input and output token capacity. Eligible generation requests require an explicit output cap so Till can reserve a conservative bound before dispatch. - **Estimated spend (optional):** budget calculated from Till's pricing table and provider-reported usage. Spend-limited requests with unknown model pricing are rejected. Estimates may differ from provider invoices. - **Expiration (optional):** timestamp after which the key is rejected. - **Source IP (optional):** IP or CIDR allowlist applied through Till's trusted-proxy model. - **Revocation:** immediate manual disablement of one key without removing the tenant's provider connections. - **Recovery:** an exhausted or expired key can be reset in place with `POST /admin/keys/:id/reactivate`, or any stopped key replaced with a fresh token that keeps the same config via `POST /admin/keys/:id/clone`; a revoked key cannot be reactivated. ## Supported providers Till supports 12 canonical provider adapters: - OpenAI - Anthropic - Google Gemini - OpenRouter - Mistral - Groq - Together AI - Fireworks AI - Perplexity - DeepSeek - xAI - Cohere New automatic keys are provider agnostic. Routing selects among the provider connections configured for the tenant using an explicit provider override when allowed, provider-native route, model ownership/pricing, and finally the tenant default. Till preserves provider-native paths and request schemas where adapters require them; it is not a universal translation layer for arbitrary APIs. ## Scoped keys and provider connections A scoped Till token is a bearer secret. It contains a random lookup component and an encrypted routing reference. SQLite stores the lookup hash and policy, not the complete token. Legacy fixed-provider tokens may contain an encrypted upstream credential payload. Provider connections are bound to a tenant and provider. Credentials are stored as versioned AES-256-GCM ciphertext with authenticated-data binding and are never returned through the admin API after save. Database contents alone are insufficient to decrypt them because separate application key material is required. The running proxy must decrypt the selected provider credential in process memory to forward a request, so Till is not a zero-knowledge system. ## Usage and capacity signals Till exposes machine-readable information through response headers and `GET /till/validate`, including configured limits, observed usage, remaining capacity, warnings, bottleneck, estimated exhaustion, request impact, provider metadata, health context, and request correlation. Validation is non-consuming and non-cacheable. ## Plans Implemented plan limits are: | Plan | Monthly platform price | Maximum scoped keys | Monthly activations | | --- | ---: | ---: | ---: | | Free | $0 | 3 | 1,000 | | Pro | $59 | 25 | 25,000 | | Scale | $249 | 100 | 250,000 | These prices apply to new subscriptions. Eligible paid beta subscriptions retain their existing founding price under Till's [published price-protection policy](https://till.ac/pricing#founding-price-protection). Till subscriptions cover the hosted control layer. Provider inference is billed separately through the customer's own provider accounts. ## Access and onboarding - Till is in a controlled beta with manually provisioned accounts. - Public anonymous signup is disabled while verified-email onboarding is incomplete. - Prospective customers use the beta-access path on [the Till homepage](https://till.ac/). - Existing authenticated customers use [the dashboard](https://till.ac/dashboard) for keys, provider connections, usage, and billing operations. ## Security and operational boundaries Implemented controls include encrypted provider connections, hashed admin/scoped lookup credentials, transactional limits and reservations, immediate revocation, trusted-proxy handling, request/body/response/time limits, signed Stripe webhooks, immutable production releases, backups, monitoring, and an independent public status site. Till does not currently claim or provide: - Zero-knowledge operation. - A prompt firewall or general secrets manager. - Guaranteed provider-bill equality for Till spend estimates. - High availability, automatic regional failover, or multi-region state. - A complete customer audit log of every proxied action. - Formal compliance certification, a public penetration-test report, or a bug bounty. - Guaranteed uptime, resolution time, service credits, SSO, or default enterprise assurance. - Public self-service signup, supported npm/Docker distribution, or supported self-hosting. See [Till security](https://till.ac/security), [support terms](https://till.ac/support), and [service status](https://status.till.ac/) for current public details. ## Public routes - `GET /` — marketing homepage - `GET /use-cases` — workload and access scenarios - `GET /integrations` — framework and client guidance - `GET /compare` — Till's role alongside secret managers - `GET /pricing` — plan comparison and calculator - `GET /faq` — product, security, pricing, and integration questions - `GET /docs` — customer API guide - `GET /blog` and `GET /blog/:slug` — reviewed, sourced articles - `GET /security`, `/privacy`, `/terms`, `/acceptable-use`, `/subprocessors`, `/support` — trust and policy pages - `GET /sitemap.xml`, `/rss.xml`, `/llms.txt`, `/llms-full.txt` — discovery resources ## Admin and discovery routes - `GET /admin/account` - `GET /admin/providers` - `PUT /admin/providers/:provider` - `PATCH /admin/providers/:provider` - `DELETE /admin/providers/:provider` - `POST /admin/keys` - `GET /admin/keys` - `GET /admin/keys/:id` - `PATCH /admin/keys/:id` - `POST /admin/keys/:id/clone` - `GET /admin/keys/:id/usage` - `POST /admin/keys/:id/reactivate` - `DELETE /admin/keys/:id` - `POST /admin/keys/bulk-revoke` - `GET /admin/keys/stats` - `GET /till/validate` - `GET /till/providers` - `GET /till/pricing` - `GET /health` Billing routes for existing authenticated tenants include `POST /api/checkout`, `POST /api/portal`, `GET /api/checkout-result`, and the signed Stripe webhook endpoint. ## Canonical links - Home: https://till.ac/ - Use cases: https://till.ac/use-cases - Integrations: https://till.ac/integrations - Comparison: https://till.ac/compare - Pricing: https://till.ac/pricing - FAQ: https://till.ac/faq - Documentation: https://till.ac/docs - Blog: https://till.ac/blog - Security: https://till.ac/security - Support: https://till.ac/support - Service status: https://status.till.ac/ - DBH Ventures: https://dbhurley.com/startups