Open engineering challenge 01: where does cross-client AI access break? #7

The claim to test

zhub is designed to publish an AI behind one authenticated, OpenAI-compatible endpoint so different clients can reach it without client-specific glue code. The repository has an end-to-end walkthrough, screenshots, and a documented wire format.

I want to know where that interoperability claim holds—and where it fails in practice.

Try the experiment

1. Set up your own zhub instance following the tutorial. Use a model/provider you are authorized to access.
2. Connect two different clients to the same endpoint. Examples: an HTTP client (curl or PowerShell), Pocket, or an OpenAI-compatible SDK.
3. Send the same basic request through both clients and compare response compatibility, errors, and latency as observed.
4. If practical, repeat with a streaming response or an intentionally invalid test credential to examine failure behavior.

What I would find useful

• Environment: zhub version/commit, OS, provider/model, client names and versions.
• Result: which client worked, which failed, and the smallest steps to reproduce a mismatch.
• Evidence: sanitized request/response shapes, error codes, relevant logs or a screenshot.
• Architectural question: is the failure in client expectations, the compatibility surface, authentication, transport, or documentation?
• Proposed change: one targeted test, doc correction, or code change (a PR is welcome).

A negative result is as valuable as a positive one. Please don't post API keys, zk_ credentials, private addresses, personal data, or unrestricted public endpoints. Test only systems you control or are authorized to assess; no load testing of third-party services.

A thought: If you were designing a universal endpoint for independent AI clients, what compatibility assumption would you challenge first
your thought:?