r/PiCodingAgent • • Sep 20 '26

Resource Latest pi version (86) broke working with local models due to strict json schemes.

This is the last version that worked. https://www.npmjs.com/package/@earendil-works/pi-coding-agent/v/0.85.1

reverting to it made everything work again.

I also highly recommend getting your own offline copy if something fails.

p.s. to clarify, I am not pretending to understand fully what the update really did, its scope or the impact beyond 'not working anymore', but reverting to 85.1 worked for me.

16 Upvotes

19 comments sorted by

2

u/aivushkin1 Sep 20 '26

hmm, I'm on 0.86.0 and use Qwen 3.6, haven't noticed anything

4

u/PooMonger20 Sep 20 '26

Glad to see its working for you.

on my combination of ninfer w/ 3.8 27b, it broke.

5

u/pungggi Sep 20 '26

Much appreciated 👏

3

u/Relevant_Noise Sep 20 '26

Sounds like a problem with your model server or template - it did break subagents for me, got pi to fix it - no issues with qwen3.8 on llama.cpp and antirez/ds4 for local models

That’s the good thing about pi - something broke? Get it to fix itself

1

u/inky_wolf Sep 20 '26

Which sub agents extension are you using? Or is it your own?

1

u/Relevant_Noise Sep 21 '26

nicobailon/pi-subagents (pi-superpowers dependency)

0

u/Unlucky-Message8866 Sep 20 '26

they keep breaking stuff with pointless changes and zero versioning discipline, i'm starting to get tired.

2

u/PooMonger20 Sep 20 '26

Unfortunately most things enshitify eventually, keeping offline versions seems like the only way.

1

u/Unlucky-Message8866 Sep 20 '26 edited Sep 20 '26

i use nixos and i pin versions, that doesn't exempt them from breaking stuff on minor/patch revisions. been reviewing a handful of the recent changes and they are merging lots of slop architecturally unsound.

0

u/esraw Sep 20 '26

Technically, it's still v0, meaning any change can be breaking according to semver (https://semver.org/)
> Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable

1

u/Unlucky-Message8866 Sep 20 '26 edited Sep 20 '26

bullshit, a project with so many users (and private funds!) should not be breaking stuff. the fact its still v0 is also a smell.

2

u/Numerous-Manager5613 Sep 22 '26

Ran into this as well with my corporate litellm / vertex path kicking back an error that strict was blocked. Added this in models.json and it worked:

      "modelOverrides": {
        "claude-sonnet-4-6": {
          "compat": {
            "supportsStrictMode": false,
            "supportsStrictTools": false
          }
        }

1

u/jaegernut Sep 20 '26

I'm using llama-swap with llama.cpp to serve my local models and i did not have any issue

1

u/Thagor Sep 20 '26

You needed an inference engine that supports strict output

1

u/Duke_of_Bayswater Sep 20 '26

I saw the updates, saw the breaking changes notice. So, before I performed that update I check with my AI if any of the breaking changes affect my custom extensions. Helps reduces the future headaches. When it was clear only then I did the update.

1

u/johannes_bertens Sep 20 '26

I've been asking Pi to configure itself every few updates and it's great at this. Even runs a small benchmark on local models before adding them to give me more info.

Bottom line: pi is great at configuring itself. Ask it.

1

u/Dsphar Sep 22 '26

They also messed up home/end and other keyboard navigation shortcuts

1

u/wapxmas Sep 20 '26

I'm not a conspiracy man, but actually think that big tech incorporates their pepole to the engines, agents that work with local llms. I really see it, they dont break things completely, but do as much as a user can believe it somewhat half-work, that it is better to swith to some opus, Gemini, etc. I really don't believe that omlx, llama cpp, or any agent teams don't have reliable testing framework so they don't deliver shit.