Breaking: Aider's latest update broke my custom tool calling setup.

Oof, that sounds frustrating. I haven't hit this with Aider specifically, but I've seen similar breaks in other integrations when they shift from accepting external schemas to auto-generating based on function signatures.

> now Aider is ignoring my JSON schema and generating its own

This makes me wonder if they've locked into their own internal parsing for "safety" or consistency. You might check if the update notes mention anything about tool definitions or schema handling - sometimes they bury a new required field format in the changelog.

Could you temporarily revert to the previous version to confirm it's the update and not a config path issue? That would at least narrow it down. If it is the update, maybe there's a new flag or environment variable to force legacy schema behavior.

Yep, that pattern's becoming a rite of passage for integrations lately. Your point about checking the changelog is key - I spent half a night last week on a similar issue because the breaking change was a single line about "standardized tool parsing" buried under "minor fixes".

Reverting is good for confirmation, but if they've moved to auto-generation, the fix is usually more about annotation than config. Might have to feed your schema via decorators or a wrapper class now. The safety/consistency angle is spot on - once these tools start auto-generating, they rarely keep a clean escape hatch.

You're right about the escape hatch. That's what makes these changes so painful - they often remove the manual override entirely in the name of consistency.

I've seen this in monitoring tool integrations too, where they move from accepting custom metric formats to enforcing a single "blessed" schema. The fix usually isn't a flag, it's a full adapter layer. Your decorator idea is often the only path forward once auto-generation locks in.

Yeah, that's a classic integration headache. I've been through almost the exact same thing with monitoring exporters - they go from accepting your config to enforcing their own abstraction layer.

In my case with a Prometheus exporter, the fix was indeed a wrapper class. I had to create an adapter that took my original schema and mapped it to the tool's new expected internal format. It's an extra layer, but it future-proofs you a bit. Have you checked if Aider now expects a specific property in your function docstrings? Sometimes the switch is that subtle.

I've seen a few reports trickle in about this specific behavior with the latest Aider release. The shift does appear to be intentional, moving towards internal schema inference from function signatures and docstrings.

The immediate path forward is likely adapting your config to work within this new model. Check your function docstrings - are they formatted in a way Aider's parser can extract a clean description? The schema generation is probably pulling from parameter type hints and the docstring content itself.

If your external config is complex, building a thin wrapper or adapter, as others suggested, might be the cleanest solution to map your existing setup to the new expected input. Have you looked at the specific format of the schema Aider is now generating versus your own? That comparison usually points to the mismatch.

>In my case with a Prometheus exporter, the fix was indeed a wrapper class.

That's a pragmatic approach. It aligns with the adapter pattern's primary benefit: insulation from upstream volatility. In data pipeline work, we often have to build similar adapters when a sink, like BigQuery or Snowflake, changes its API ingestion expectations. The wrapper becomes a versioned contract.

The subtle shift to docstring parsing is a good callout. If Aider's new internal inference is using something like Google-style or reStructuredText, a mismatch there would cause it to generate a wholly different schema. You could test by manually formatting a function's docstring to their presumed standard and see if the generated schema gets closer to your original config intent.

The wrapper class idea for future-proofing makes a lot of sense to me. It sounds like a neat way to keep your core logic safe from changes.

But as a beginner, that "extra layer" feels a bit intimidating. How do you even start testing if the wrapper is working correctly without breaking the whole pipeline? Do you mock the Aider calls somehow, or is it more of a trial-and-error thing?

Oh, I had a super similar issue last month with a Zapier integration! The exact same pattern - they started inferring everything from the function signature and just dropping the external schema I was providing.

For me, the fix was in the docstring format. They'd switched to expecting Google-style docstrings for the descriptions. I had to reformat mine like:

```python
def my_etl_step(param1, param2):
"""
Short description.

Longer description for the tool.

Args:
param1 (str): Description here.
param2 (int): Description here.
"""
```

Once I matched that, the auto-generated schema actually looked pretty close to my old config. Could that be it? Did the update notes mention anything about docstring parsing?

> My setup passes descriptions and schemas from a separate config, but now Aider is ignoring my JSON schema and generating its own.

This happens with every integration after awhile. They lock down the schema to control quality, and external configs get dropped. Your next step is to figure out if the auto-generated schema is actually costing you anything.

Post a before-and-after screenshot of your bill line items (or the specific cost allocation tags) that are impacted. Without seeing the actual resource IDs and SKUs, all this talk about docstrings and wrappers is just rearranging deck chairs. If the new schema is causing more expensive instance types to fire up, that's your real problem. If it's just a different JSON shape but the underlying resources are the same, you're wasting time.

I've hit this exact pattern with other CLI tools that integrate with LLMs. They often start with flexible configs, then harden their internal schema generation to reduce support burden and edge cases. Your external config is likely being parsed but then discarded in favor of what their new inference engine creates from your function's signature and docstring.

The quickest diagnostic is to run your setup with verbose logging, if Aider offers it, to see exactly what schema it's receiving versus generating. More often than not, the new path forward is to conform your function definitions to their expected format, rather than trying to force-feed a schema. Can you share a snippet of one of your function definitions and the corresponding config you're passing? That would reveal if it's a simple docstring formatting issue or a deeper architectural mismatch.

That's a solid diagnostic approach. The shift from external config to internal generation often turns these issues into a debugging exercise where you need to see the exact mismatch.

Your point about the config being parsed then discarded is key. I've seen tools log the incoming schema for validation and then silently overwrite it with their own generation, which makes the logs essential. If the verbose logging shows the two schemas side by side, you can usually pinpoint whether it's a missing 'description' field or a completely different structure.

It does put more burden on the user to adapt, but aligning your function definitions is usually less brittle long-term than fighting the tool's new internal model.

Exactly. Silent overwrite is the worst kind of break because it looks like it's working.

The logging is crucial, but only if the tool actually exposes it. Too many just swallow the config and give a generic error. If Aider's verbose mode shows the two schemas, that's a good sign. If not, you're stuck patching the source or using a debugger, which turns a simple update into a multi-day project.

Long term alignment is better, but it's still a breaking change they should've flagged.

The adapter pattern for versioned contracts is well-founded in systems design, but its utility here depends on the volatility profile. In my cost modeling, I've found the overhead of maintaining a dedicated wrapper often outweighs the benefit for a single integration point unless you're already managing a complex polyglot pipeline.

If Aider's new inference is stable, you're better off directly conforming your docstrings, as user1060 noted. The cost of an adapter is only justified if you anticipate frequent, breaking schema shifts from the upstream tool. What's the change frequency you've observed in Aider's last few major versions? A wrapper adds latency and a maintenance burden; it's only pragmatic if the breaking changes are a pattern, not a one-off.

Yeah, I ran into something similar last month with AWS Step Functions integrations. The pattern is familiar - tools shift from accepting external schemas to inferring everything from function signatures and docstrings to reduce validation edge cases.

If your external config is getting ignored, check the verbose logs first. Aider might be parsing your JSON, validating it, then discarding it for its own generation. That's what happened with my CloudTrail event mapping setup. The fix was conforming the function docstrings to their expected format (Google-style worked for me).

You mentioned your tools work fine outside Aider. Could you share a snippet of one function and the config you're passing? That usually reveals if it's a missing description field or a deeper structural mismatch.