GLM 5.3 in Dikaya: review multi-file API contracts

Minimal API example

Illustrative Python, not an executed model response. The key comes from the environment and automatic retries are disabled. A lost connection can leave both outcome and cost unknown: do not retry blindly.

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://dikaya.cc/v1",
    api_key=os.environ["DIKAYA_API_KEY"],
    max_retries=0,
)
response = client.chat.completions.create(
    model="seller-glm-5-3",
    max_tokens=512,
    messages=[{"role": "user", "content": "Create a checklist for my task. Separate source facts from assumptions."}],
)
print(response.choices[0].message.content)

Define the agreement across files first

Suppose an inventory application receives delivery webhooks. The schema allows an optional warehouse code, the handler replaces missing codes with a default and the client displays null as a special unknown location. Each file looks reasonable on its own, yet the combined behaviour can mislabel stock. Give the model a contract map containing the producer, request schema, validation boundary, stored representation and consumer. State which version of each file belongs to the review.

Write the invariants in ordinary language before supplying implementation details. A missing warehouse code might mean use the account default, whereas an explicit null might be forbidden. Unknown event types might be rejected rather than silently ignored. Those are product decisions, not facts the model should invent. Ask it to report ambiguity when two documents disagree, preserving source references instead of selecting whichever rule makes the patch easier.

Assemble a packet that supports cross-file checks

Include the relevant schema fragment, validation function, handler, storage adapter and consumer type. Keep filenames and stable symbols in the text. Add a representative payload only after removing secrets and identifying it as an example, not a production event. If a shared helper is omitted, provide its interface or ask the model to list the dependency as unresolved. A fictional helper implementation can hide the real contract mismatch.

Large declared context does not bypass browser body or history boundaries, and it does not increase an independent output cap. Prefer a complete narrow path through the application to a partial dump of every directory. When the path is still too large, inspect one contract boundary at a time with a shared invariant list. Ask the response to state exactly which supplied files were checked and which expected dependencies were missing.

Choose effort and output as separate controls

This model declares low, high and max reasoning effort levels. Use only the levels supported by the current model metadata and treat the choice as a request setting, not a guarantee that higher effort will find every mismatch. Keep the supplied files and review question stable if you deliberately compare settings. Without a controlled comparison, different responses can reflect changed inputs rather than the effort parameter.

Set an explicit output budget for findings, tests and a short explanation. A large input window is not an unlimited response allowance, and additional reasoning can affect the budget available for the visible answer. If the review is broad, request the highest-priority contradictions first with a remaining-work list. Do not interpret the word max as maximum correctness, guaranteed completion or a promise about how long the response will take.

Turn each suspected mismatch into a test case

Ask for a matrix covering an absent field, explicit null, an empty string, a valid code and an unknown field. Each row should identify the expected validation result, storage representation and client display. Add duplicate event delivery and out-of-order delivery only if the application’s contract defines them. A useful finding names the exact conflicting lines and a payload that exposes the discrepancy, rather than recommending a generic validation library.

Run the suggested cases against the current code before applying changes. A failing test must demonstrate the stated mismatch, not fail because a fixture omitted a required dependency. Review the smallest proposed patch and check whether it changes previously accepted requests. Generated test commands remain text until executed by you or a separately configured tool-enabled client. The model does not acquire native repository access or command execution from its catalogue entry.

Separate application correctness from request transport

In API use, identify the model as seller-glm-5-3 rather than substituting seller-pro-2. Configure the client for Dikaya and explicitly disable SDK automatic retries when you need deliberate control over attempts; the OpenAI Python README documents max_retries=0. Do not confuse the webhook application’s own deduplication design with a public inference API guarantee. A local review ID is useful for your records but does not establish server-side idempotency.

A known HTTP rejection supplies a definite server response. A connection timeout, aborted body read or interrupted stream can leave the processing outcome unknown. MDN explains the HTTP-versus-network distinction for Fetch, not whether any particular inference was charged. Preserve uncertainty, inspect available state and accounting, and decide manually whether to submit again. Do not use repeated paid calls as an automatic availability probe for this workflow.

Deliver a review another engineer can reproduce

The final review should contain the contract conflict, evidence addresses, reproducing input, expected result and local verification status. Separate checked facts from proposed fixes and open questions. If a screenshot is necessary, remember that images for this model use a separately paid text bridge, not native vision. A textual schema and exact error log are usually more directly inspectable than an intermediate image description.

Opening the article draft does not run the review. Model permissions still apply, a stored draft may take precedence and demo access remains centred on Pro 2 rather than this ID. Check the selector and file packet before sending. Paid browser search can be enabled explicitly for external documentation, but the public API does not include an automatic internet tool. End the task with real test output and unresolved boundaries, not an unqualified claim that the whole integration is correct.

Questions and answers

Why not use the Pro 2 model ID for this guide?

seller-glm-5-3 and seller-pro-2 are distinct public identities. Pro 2 has an approved modified GLM-5.3 foundation description, but that does not merge their settings, image paths or access conditions. Use the exact ID requested for the review and consult its current metadata rather than treating related naming as interchangeability.

Will max effort guarantee a better contract review?

No. Low, high and max are declared request controls, not a measured quality ranking or completion guarantee. Clear invariants and complete source material remain necessary at every setting. If you compare levels, keep the task stable and check findings against reproducible tests instead of scoring responses by their length or confidence.

What should a useful cross-file finding include?

It should identify the disagreeing contract statements, point to the relevant supplied files and give an input that exposes the difference. Include the expected behaviour and a test that can run locally. A general recommendation to improve validation is less actionable than a specific missing-versus-null mismatch with an observable consequence.

Can this model inspect my repository automatically?

Not from an ordinary text API request. It can analyse material you provide and propose commands or tests. Repository tools depend on a separate client and its permissions. Browser uploads and history are bounded, while images use a paid text bridge; none of those features implies native shell execution or unrestricted file access.

Sources

AI-assisted editorial material. Examples are illustrative, not captured model responses or comparative tests. External sources do not replace the service terms.

• Dikaya documentation: API controls and clients
  dikaya.cc
• Dikaya models: public IDs and declared capabilities
  dikaya.cc
• OpenAI Python SDK: retry settings and errors
  github.com
• MDN Fetch: HTTP status and network failure semantics
  developer.mozilla.org