Straight answers, including the awkward ones.

It gives the person who owns the AI budget one trustworthy number, a forward view, and a way to act on both. Concretely:

• Unified spend and token usage across Claude, OpenAI, and Gemini, attributed to named teams, projects, and keys.
• A month-end forecast against budget, with days to limit and anomaly flags when usage spikes.
• Right-sizing recommendations that show the accuracy you would give up, not just the money you would save.
• Threshold rules that escalate to the right people, ending in a human approving any action.

Anthropic, OpenAI, and Google first, through their usage and billing APIs. Those three cover the large majority of spend for the companies we are building for.

Longer-tail providers come once the first three are genuinely solid, because a shallow connector that misreports cost is worse than no connector. If you are spending seriously on something else, tell us and it will weigh on the order we build them.

For the budget question, yes. For everything else, no. You will still use each provider's console for key management, rate limits, and support. SpendTower exists because none of those consoles can show you the other providers, and none of them forecasts.

No, and this is a decision rather than a gap. A kill switch that wrongly throttles production is worse than the overspend it prevents. Rules escalate and notify, a person reviews the context, and only that person can approve an action.

If you later want real-time enforcement, an optional inline gateway is on the long-term roadmap as something you opt into deliberately. It is not part of the core product and we will not enable it for you.

Gateways enforce limits inline and are built for developers, but are usually thin on finance-grade attribution and forecasting. Observability tools are excellent at tracing and per-call cost for engineers debugging quality, but they are not built for the person signing the invoice. Cloud FinOps platforms are strong on attribution as an extension of cloud cost, but light on model-level guardrails.

SpendTower assembles the parts each of those leaves out, and aims them at the budget owner. There is a fuller comparison on the home page.

Yes. There is a clickable walkthrough of the full product and a hands-free version that plays the story in about forty seconds. Both use illustrative numbers for a fictional company, not a live account.

No. We read usage and billing metadata: model, token counts, cost, key or project identifier, and timestamp. Prompt and completion content is never requested from the provider and never stored by us.

This falls out of the architecture rather than being a policy promise. Read-only usage and billing APIs do not return prompt content, so there is nothing to leak.

No. Nothing is installed in your application and no traffic is proxied through us. We poll provider APIs on a schedule. If SpendTower is completely down, your production traffic is unaffected, which is a large part of why we chose this design.

A read-only key per provider, scoped to usage and billing only. Credentials are encrypted at rest, decrypted only inside the ingestion path, and never written to logs. You can revoke a key in your provider console at any time and the connector simply stops.

Not today, and we are not going to imply otherwise. SOC 2 readiness is on our roadmap alongside SSO and full role-based access control, and it matters most for larger organisations.

What exists today is encryption in transit and at rest, least-privilege read-only scopes, and tenant isolation enforced at the query layer. If your security review needs something specific in order to proceed, ask us directly and we will tell you plainly whether we have it.

Revoke the provider keys and ask us to delete the account. We remove your organisation's usage records and connection details. Write to hello@spendtower.com and we will confirm when it is done. The privacy policy covers this in more detail.

The target is a populated dashboard on the same day, with under an hour of hands-on setup. Roughly ten minutes per provider to create a read-only key and connect it, then some time mapping keys to teams.

The honest caveat: how far back your first dashboard reaches depends on how much history each provider's API exposes, which varies.

Someone needs permission to create a read-only key in each provider account, which is usually a platform engineer or whoever administers those accounts. It is a short task, not a project. After that, the mapping and budgeting work is finance-side.

By mapping provider API keys and projects to a named team. In the first version that mapping is manual, because it is quick to do once and it is honest about what the provider APIs actually expose.

The goal we hold ourselves to is 90% or more of spend attributed to a named team within two weeks of onboarding. Keys nobody claims show up as unattributed rather than being quietly guessed at.

Email and Slack to start, with thresholds you set per team. The escalation ladder routes by severity, so an early warning goes to the owning team and a budget breach reaches finance and engineering leadership.

Our commitment is within 2% of each provider's own invoice, and reconciliation is built into ingestion rather than bolted on afterwards. If we drift outside that, we would rather show you the gap than quietly smooth it over.

We aim to be within 10% of the actual month-end figure by mid-month, tightening as the month progresses. Forecasting is run-rate based, so a workload that changes shape late in the month will move the projection, which is exactly when the anomaly flags matter.

We do not present a swap without an accuracy estimate beside it, and you approve every change. Recommendations are backed by quality signals, and we track accepted versus reverted over time so the advice stays honest instead of drifting into wishful thinking.

SpendTower does not change a model on your behalf. It shows the tradeoff and leaves the decision with you.

No. Northwind is a fictional company and every figure in the demo, the walkthrough, and the home page illustration is made up to tell the story clearly. Nothing there comes from a customer account.

Pricing is not published yet. We would rather not invent a number before founding partners have shaped what the product actually is.

The principle we are designing to is that realised savings should run at several times whatever SpendTower costs. If it cannot clear that bar for you, it is not worth buying and we would rather find that out early.

• A full year of SpendTower at no cost.
• A direct line to the people building it, not a support queue.
• Real influence over what ships and in what order.
• Your connectors and edge cases prioritised.

The specifics are set out in a separate written agreement before anything starts. Apply on the founding partner page.

Honest feedback, including the parts we will not enjoy hearing, and enough access to understand how your spend actually works. If something we built is not useful, we want to hear that early rather than read it in a churn report.

Mid-market and enterprise companies spending meaningfully across two or more providers, where somebody in finance or platform engineering is already being asked awkward questions about the AI line item. If you are a single developer with one API key, this is not built for you yet and we will say so.

We are not committing to a public date we might miss. Join the waitlist and you will hear directly when it opens. Founding partners get in before the general waitlist.

SpendTower is an early stage company building this in the open with its first customers. Founding partners deal directly with the people writing the code, which is one of the genuine advantages of arriving early.

Email hello@spendtower.com. If you want a conversation rather than a form, that address reaches a person, and you are welcome to bring the awkward questions.

Please tell us at hello@spendtower.com. That includes the comparison table on the home page. If we have characterised a neighbouring category unfairly, we would rather correct it than defend it.