Subak

Inspiration

Enterprise financial planning and analysis (FP&A) is difficult and has a couple of key bottlenecks. It is slow to react because budgeting, historically, hasn't been able to operate at the pace that AI use now demands. FP&A managers also have limited visibility across the company, which makes it hard to properly understand what is going on.

One of the biggest examples we've seen in AI adoption is token spending at enterprise tech companies. It's difficult to manage AI spending across an organization, especially as teams adopt different models. One example is Uber reportedly burning through its annual AI budget in just four months as spending on AI coding tools surged. Finance teams have to ingest information across Slack, emails, messages, spreadsheets, and documentation just to figure out which teams are on track.

There are tools that track token spending after the fact, but it is still hard for finance teams to actively plan for what's coming and allocate budgets dynamically across teams. We built Subak to bring that information together.

The name comes from Bali's subak irrigation system, where farming communities coordinate a shared water supply. That idea resonated with us: different groups depend on the same resource, and distributing it takes cooperation. Subak brings that principle to teams sharing an AI budget.

What it does

Subak helps FP&A teams understand, forecast, and reallocate AI token spending across teams. It combines a Factory Droid agent that reads company context and drafts budget proposals for finance to approve with a forecasting engine that looks at token spending at a macro scale.

This allows finance teams to create aggregated estimates of what different departments and teams across the company are expected to spend in tokens and model usage. They can then account for that by reallocating budgets and seeing which factors are likely contributing to changes in spending.

For example, Research might be preparing a larger evaluation while Product moves a launch back a week. Finance can inspect both teams' outlooks, open the supporting plans, and preview how those changes affect expected spending.

Factory Droid helps investigate those changes and prepare budget proposals. Finance can ask, "We have $50,000 more—prioritize Research," and review the proposed allocations, supporting evidence, and remaining funding gaps. Asking to redistribute existing funding keeps the total budget unchanged. A finance approver makes the final decision, and Subak checks the proposal's arithmetic and supporting information before saving a decision receipt.

How we built it

We start by importing billing CSV/JSON and Codex session JSONL into our FastAPI backend. It removes duplicates, converts cumulative token counters into usage increments, and maps known people and teams. SQLite stores these records alongside company documents and budgets. Forecasting uses explicit coverage and pricing records; token counts alone do not establish a complete bill. Our integrated demo supplies the required forecasting inputs with synthetic company data.

The forecasting engine takes in:

Current and previous usage from individuals and teams across the company.
Context about the company's direction and plans.
Model pricing.

Our Python engine estimates typical usage for each weekday and each week, for every team with sufficient data, using up to the latest 56 complete observed days that pass coverage and maturity checks. It accounts for available staffing or workload measurements, while Factory Droid reads imported Slack messages and company documents to help identify relevant context. A project delay, staffing change, vacation, or revised timeline can all provide context for expected spending. A rule-based interpreter converts supported, dated changes into numerical adjustments. Where compatible workload measurements exist, the engine estimates usage per unit of work; otherwise, it keeps an aggregate view. Supported prices are applied across complete billing pools before allocation to teams, with unavailable costs left explicit.

A backend worker runs the Python package and saves each forecast with its inputs, citations, and calculations. The Next.js, React, and TypeScript dashboard combines recorded usage with the expected remainder of the week. As actual token-spending information comes in, it replaces the corresponding estimates in this live outlook. A saved Monday forecast stays fixed so finance can compare what was expected with what actually happened.

Subak is also designed to get better the more it's used. As more data is gathered, we can better understand how assumptions and changes across a company affect token spending for different teams. The engine can calculate forecasts with and without supported assumptions and factors, then compare the results with actual spending to evaluate and improve accuracy over time.

The Factory Droid SDK gives our assistant 15 scoped backend tools to investigate documents, explain saved forecasts, preview scenarios, and draft budget proposals. The backend verifies quotations, recomputes proposal arithmetic, and checks that the budget and evidence are still current. Finance reviews the proposal and approves the allocation change.

Challenges we ran into

Forecasting token spending was our hardest problem because usage is difficult to estimate. We tackled spending at a macro scale and at a team level, looking on the order of weeks rather than specific prompts, experiments, or days, which are more subject to fluctuation. We also didn't want to predict on the order of months or quarters, when shifts in technology could drastically change what a company is using.

We addressed this by focusing on the company's own usage and context. We also had to account for the distribution of model usage, pricing, and planned adoption of new models by specific teams. A supported workload or model-usage change can adjust the forecast; an ambiguous statement or a model announcement stays context until there is enough information to use it.

Evaluation was also difficult. We don't have access to real company data, so synthetic company data was our next-best alternative, alongside public token-usage experiments. This let us test how the engine responds to known changes and compare forecasts with and without company context. Real enterprise forecasting accuracy still needs to be validated.

Keeping the financial equalities consistent was another challenge. Team allocations need to add up to the company budget, and redistributing existing funding must not change that total. We kept those checks in the backend so every proposal is validated before it can be approved.

Natural-language requests were also difficult to handle. We tightened intent handling in the Droid assistant and kept adding funding separate from transferring existing funding. We kept the interaction in natural language while translating each request into a structured proposal that the backend could validate.

Accomplishments that we're proud of

We're proud of turning a difficult forecasting problem into a useful financial workflow. Subak brings data from across the company into an interface that FP&A teams can use to make informed, accountable decisions.

We're also proud of using Factory Droid to ingest and investigate company context for a novel financial use case, and of building a forecasting engine that we could evaluate and improve on controlled examples. Bringing the context, forecasts, and budget proposals together lets finance teams understand what changed and why before deciding how to respond.

What we learned

Financial workflows are incredibly complicated, which is why we decided to tackle a very constrained version of the problem.

Forecasting involves a lot of different factors, and it's difficult to isolate them. We focused on the most useful unit for a team to plan around, which we settled on as a week.

We learned the value of using agents like Factory Droid to ingest information from different sources and formats and convert it into useful context. This is a recent capability that we're excited to explore and take advantage of further.

On the technical side, we learned that token counts can't always be priced independently. Shared allowances and pricing tiers mean we need to combine usage across a billing pool before calculating costs, including when actual usage replaces an estimate. This keeps the spending totals consistent as new data comes in.

We also learned that managing token spending and measuring and optimizing AI adoption within firms is still a novel and nebulous area. It's something we're excited to continue researching and learning about.

What's next for Subak

Our first priority is to forecast alongside a real company. We want to connect authenticated company sources, strengthen production access controls, and compare preserved forecasts with actual spending over successive weeks. That will help us identify where assumptions break, improve the engine using observed outcomes, and learn whether Subak makes budget reviews faster and easier.

Longer term, we want to extend Subak to autonomous agent teams working on long-running tasks alongside human teams. A budgeting agent could gather workload plans, estimate token use, track spending, and coordinate funding requests. People would set priorities and spending limits; the agent could manage allocations within those permissions and escalate requests that exceed them.