Add zai-coding-plan provider and make zai point to regular API #899
Conversation
|
Hey @kaofelix , thank you! I also find it a bit confusing that z-ai team's decided that one api key can be used for both. Anyways, +1 for option (2) here. It's fine as soon as it's aligned with |
|
I'm OK with 2 as well! Which means we entirely rip out the zai provider. Can you amend the PR accordingly? Also needs a breaking changes changelog entry in that case. |
|
@badlogic cool, made all the changes! Did a quick test with GLM flash here with thinking on and off to make sure the thinking param still works: https://buildwithpi.ai/session/#2cc3a9696a480de2262751a35e692215 Oops, actually forgot about the breaking change changelog, will do that now |
|
Sorry, I made a lot of changes to pi-ai to support custom providers in extension, so this is now outdated. May I ask you to rebase on main and fix this up? Sorry! |
Add documentation for the new Z.AI GLM Coding Plan provider, including auth configuration, environment variables, and model details (GLM-4.7, GLM-4.6, GLM-4.5 and vision variants). Signed-off-by: assagman <[email protected]>
kaofelix
force-pushed
the
zai-coding-plan-provider
branch
from
6f10c0a to
7034ebe
Compare
|
@badlogic np! Did a rebase with slopus and push forced, will check the diff for anything weird here |
|
I think it looks alright! |
packages/coding-agent/CHANGELOG.md
Outdated
|
|
||
| ### Changed | ||
|
|
||
| - Changed `zai` provider to use the Coding Plan API for better coding performance. |
There was a problem hiding this comment.
aaah, damn, it had to mess with the changelog again, smh
3 participants
Opening this as a draft here just to discuss a few points.
@assagman I will pull your doc changes in here too and adapt them to whatever becomes the final idea here.
Basically what I find annoying is that z.ai API keys work for both API and Coding Plan. The only difference is the endpoint itself. The way it currently is, whenever someone has
ZAI_API_KEYdefined, they will have both providers available, which is a bit noisy for what I assume to be the most cases of people only using one option.The ideas that occurred to me were:
ZAI_CODING_API_KEYso that you know which provider you are configuring. The only caveat is that every other tool I encountered usesZAI_API_KEYfor the configzaiprovider entirely withzai-coding-planI personally prefer 2 as it keeps things simpler while making it more aligned with models.dev and being explicit that we are supporting the Coding Plan specifically and not the regular API. So far, pi only worked with the coding plan anyways, since it always used coding plan endpoints. I can add examples to the docs on how to setup the regular API by hand.
From the fact that it has always been Coding Plan and no one complained, I assume there are not many API users out there. API users tend to prefer other providers and even avoid zai, from what I've seen.