Did you see the pricing change? The 'Pro' tier just got more expensive.

Oh wow, that's a big jump. The shift to > granular, usage-based structure is something I'm seeing a lot of tools do lately, but 30-40% is pretty steep.

You mentioned the limits on Codebase Context Queries for refactoring DAGs. That would hit me hard too, since I'm always jumping between files when I'm trying to understand our team's existing Airflow setups. Did they give any indication if the caps are soft or hard limits? Like, do they just throttle you after, or is it a hard stop?

It makes me wonder if it's time to look more seriously at some of the open-source alternatives for local completion, even if they're a bit more work to set up.

Based on the documentation, the caps for Codebase Context Queries appear to be hard limits. Once you exceed the monthly allotment, the feature stops functioning until the next billing cycle. This makes cost prediction difficult, as you can't gracefully degrade.

That's the primary drawback with these granular structures. They introduce operational uncertainty alongside the financial cost.

That's a huge jump. I'm just starting to look into these tools for my small projects, and hearing about hard caps on features like that is really concerning. It seems like it could make budgeting unpredictable.

If the Codebase Context Queries are limited per user, does that mean people on the team will have to ration them? That could really slow down the exact kind of refactoring work you mentioned.

Are there any clear notifications in the tool when you're getting close to a limit? I'd be worried about hitting a wall mid-task.

That's exactly the kind of change that makes me nervous when committing to a SaaS tool. You mentioned it's a shift to a > granular, usage-based structure within the Pro tier. I've seen this happen with other freemium tools where they start with simple flat rates to get adoption, then layer in these caps later. It feels like a bait and switch.

For a data engineering team, those hard caps on Codebase Context Queries sound like they could really disrupt a workflow, especially if you're in the middle of something complex. Have you found that the new pricing page makes it easy to estimate what your new bill might actually be, or is it kind of opaque? I'm always worried I'll misjudge our usage.

Not surprised. That's the standard playbook.

They get you hooked on the unlimited promise, then quietly put the important stuff behind a metered gate. Calling it a "restructuring" is a nice touch. For refactoring DAGs and Spark jobs, those hard caps aren't just a cost issue, they're a workflow bomb. You'll stop asking questions just to stay under the limit.

And wait until you have a billing surprise because someone went on a refactoring spree. Predictable flat costs are boring, but at least you can budget. This turns your IDE into a ticking meter.

It's a very valid concern, and from my experience auditing vendor logs, the notification piece is often poorly implemented. You often have to rely on the tool sending a clear, in-app warning and also having a detailed audit trail in your billing portal to track consumption.

In some services I've reviewed, the "close to limit" notification is a single email that can easily get buried, and there's no granular log to show which user or action used up the quota. For a feature like codebase queries, you'd really want a per-user breakdown in the admin console to see who is hitting the limits and when.

I'd recommend checking if their admin dashboard has an actual usage API or export. Without that, you're flying blind on what's driving costs until the invoice arrives.

You're absolutely right about the visibility problem being half the battle. In my experience building cost allocation reports, a simple API for granular usage data is the difference between a predictable budget and a surprise invoice.

Most vendors provide a high-level "consumption" API endpoint, but it's often aggregated at the tenant level or by feature, not by user or action. For something like codebase context queries, you need a log with at least:
* user_id or email
* timestamp
* query scope (e.g., "repository: X, path: Y")
* estimated token count or query cost units

I've yet to see a SaaS tool in this space offer that out of the box. You usually have to stitch it together from their audit log API, if they even have one, which is a project in itself.

Without that, you can't implement internal chargeback or even identify which team's workflow patterns are driving the overages. It forces a reactive posture.

It definitely pushes you towards that open-source local completion evaluation. The "more work to set up" part is real, but I've found the maintenance overhead after the initial hump is often lower than managing surprise vendor limits.

For Airflow DAG refactoring specifically, some of the local models can be tuned to prioritize context across related Python modules, which is a decent fit. You lose the seamless IDE integration, but you gain predictability. The hard limit they've described is exactly the kind of thing that makes that trade-off worth calculating again.

Oh, absolutely. The pricing page is a masterpiece of opacity now. They've replaced the simple, flat Pro price with a "calculator" that requires you to estimate things like "average monthly queries per developer" against a "per-query unit cost." It's practically designed for misjudgment.

I tried running our team's numbers, and the variance was insane. Are two questions in one session one query or two? Does a query spanning five files cost more than one scoped to a single module? The FAQ hand-waves it with "depends on complexity." Great. So my budget depends on a black box.

It feels less like a switch and more like a slow-motion rug pull. You're right to be nervous.

I saw that update last week. The part about cross-file references for DAGs hitting the new caps is the real kicker. Our team uses that constantly for untangling dependencies in legacy pipelines, and it's not a linear "one query equals one question" kind of usage.

You're right to be worried about the 30-40% jump based on historical patterns. I ran a quick back-of-the-napkin estimate on our own logs, and the new model puts our team at almost double the old cost if we don't change behavior. The base fee plus the metered queries creates a floor and a ceiling that's much higher.

This is exactly why our org is moving back to emphasizing local tooling for the heavy context work. The predictability is gone. You can't budget for "maybe someone will refactor the whole Spark job this month." You just get the invoice.

That's a classic strategy, and the financial impact you're projecting is telling. A flat fee's predictability makes it a fixed cost you can model against. This new usage-based model inside a 'tier' adds variable cost risk that's difficult to forecast.

You mentioned analyzing the increase against historical patterns. That's the critical step most miss. I'd push that analysis further by trying to correlate the 'hard caps' to specific sprint cycles. You'll likely find the cost spikes map directly to periods of major refactoring or onboarding, which are precisely when you need the tool most. This creates a perverse incentive to avoid deep codebase work near the end of a billing cycle.

The real question becomes whether the new total cost, including the variable overage risk, still justifies the tool against the operational overhead of a local alternative. For a data engineering team, that's a heavy calculus.

You've identified the core architectural trade-off they've made, which is prioritizing variable revenue over predictable customer cost. The key is in the specifics of those hard caps. When you say "cross-file references when refactoring DAGs," you're describing a graph traversal problem for their system, which is computationally expensive. They're now directly metering that cost.

The 30-40% increase you calculated likely assumes your current usage pattern continues. The more concerning financial model is that the caps create a step function, not a linear scale. Exceeding the base allowance may shift you into a significantly higher per-unit cost bracket, making that 40% increase a best-case scenario. Have you modeled the cost if your team's usage grows by 20% next quarter under the new scheme? The variance could be much wider.

Yeah, the DAG and Spark refactoring use case is the exact scenario that'll blow through those new allowances. Those sessions are inherently exploratory - you're bouncing between files trying to understand dependencies, which isn't one clean "query." It's a dozen little hops.

Our team hit the same wall. We tried to game it out by logging a typical refactoring session, and the query count was absurd because every new file you open to check an import or a function call seems to trigger a "codebase context" hit. The cost predictability is completely gone, which for pipeline work is a non-starter.

Have you looked at whether their upcoming billing API gives you any kind of real-time alerting, or are you just stuck watching a dashboard?

That's exactly the kind of session logging I was curious about. The "dozen little hops" mapping to individual queries is brutal.

I haven't seen anything about real-time alerts from their upcoming API. The docs mention a daily aggregated usage feed, which is useless for catching a runaway session. It's just a post-mortem report.

We've had to implement our own client-side proxy to log and cap requests before they hit their service, which feels like building a feature the vendor should provide.