Dikaya Pro: compare long documents with traceable findings

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-pro",
    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 decision the comparison must support

Imagine a volunteer organization revising its equipment-loan policy. The old version allows collection by a nominated person; the new version changes identification and return procedures. The coordinator needs a change register, not an essay about good governance. Specify the audiences affected, the effective versions and the exact questions: who can collect equipment, what evidence they need and how a late return is handled. These questions provide a meaningful boundary for the analysis.

Ask for three separate categories: wording changes, changed obligations and unclear consequences. A rewritten sentence may preserve the same rule, while one removed exception may substantially alter it. The model should not collapse these categories into a generic list of improvements. This policy workflow is an editorial suggestion, not evidence that Pro has been benchmarked for legal interpretation. Decisions about the organization’s rules remain grounded in the actual documents and its own review process.

Give the text addresses that survive the analysis

Label the sources OLD and NEW, retain section numbers and add paragraph identifiers where the originals lack them. Include a short glossary for terms such as borrower, nominee and custodian. If identical words have different definitions across versions, preserve both definitions rather than normalizing them away. Source labels let a reviewer find a claimed change without searching an entire document for an approximate paraphrase.

Paste clean text or use supported text attachments after checking extraction quality. A two-column PDF copied into alternating fragments can reverse an obligation or detach an exception. Inspect headings, lists and table cells before submission. Clearly delimit document text from your instructions and tell the assistant to treat embedded commands as quoted source material. If appendices were omitted, say so; absence from your packet does not establish absence from the complete policy.

Build the comparison in two inspectable passes

First request an inventory of rules in the old version, each with its source address and a short literal quotation. Check that inventory against the original. Then supply the accepted inventory with the new version and ask where each rule moved, changed or disappeared. This order exposes omissions before they spread into the final change register. It also makes a relocated but unchanged clause less likely to be presented as a newly introduced rule.

For every substantive difference, request the old quotation, new quotation, change category and a question for the policy owner. Keep operational interpretation separate from textual evidence. A clause requiring identification does not specify which documents count unless the text says so. Record that gap as a clarification. Ask for contradictions inside the new version as well: a revised collection rule can conflict with an unchanged checklist several pages later.

Plan around the context actually sent

The declared model context describes an input capability, not a promise that a browser forwards your whole stored conversation. Browser history and JSON body bounds are separate, as are attachment limits. Place the source inventory and current task in the packet that will actually be sent. If the documents exceed the client boundary, divide them by topic while keeping shared definitions available in each relevant block.

Response length is another independent constraint. Ask for a coverage ledger listing processed clause IDs and outstanding sections when the comparison is too large for one output. A concise result can be complete for a narrow question, whereas a long result can still omit the exceptions section. Review the coverage ledger alongside the change register. Do not interpret a fluent conclusion as proof that every page was included or every obligation was checked.

Check evidence before presenting recommendations

Search for every quoted phrase in the supplied version, then examine the surrounding paragraph. A quotation can be exact yet misleading if it omits an exception immediately afterward. Check dates, role names, notification periods and whether a rule is mandatory or discretionary. Give the final reviewer a short list of unresolved items rather than hiding them in footnotes. This is especially useful when the organization needs to ask different owners about collection, storage and returns.

Images sent to Pro use a separately paid text bridge rather than Pro-native vision. For a scanned clause or dense table, a verified text transcription may preserve important qualifications better than an intermediate description. Current web material is separate too: paid browser chat offers explicit search, but public API access does not supply an internet tool automatically. Do not substitute a retrieved general policy for the exact local version being compared.

Keep model selection and request recovery explicit

An integration should send seller-pro and an explicit output cap. The branded Pro tier does not declare low/high/max effort controls, so those settings should not be inferred from neighbouring catalogue entries. If using the OpenAI Python client, configure Dikaya’s base URL and max_retries=0. Its README documents these mechanics and connection-versus-status errors, not a guarantee that every feature of another endpoint is implemented here.

A known HTTP rejection is different from losing the connection before a reliable outcome arrives. Do not tell colleagues that the comparison was unprocessed or uncharged based solely on a timeout. Inspect available state and usage before a deliberate new submission. The article button only prepares a draft, and an existing draft may win precedence. Pro must be enabled and permitted for the account; the Pro 2 demo does not grant Pro access. Check the selector before sending the document packet.

Questions and answers

What is the foundation of Dikaya Pro?

The public information for seller-pro does not identify a foundation. Do not apply the approved modified GLM-5.3 description of seller-pro-2 to Pro. Treat the public ID, declared configuration and your checked results as separate evidence, rather than deriving architecture or performance from the Pro brand name.

Why preserve clause IDs instead of asking for a summary?

Stable IDs make every finding addressable. A reader can locate the old wording, inspect the replacement and challenge a claimed consequence. A general summary can conceal omitted exceptions or relocated clauses. The comparison still needs checking, but traceable references make that check practical without rereading both documents after every statement.

Can Pro read the entire history because its context is large?

Not necessarily. The model’s declared context, the browser’s transmitted history and body, attachment limits and response cap are distinct boundaries. Stored messages are not proof that all of them reached the next request. Include the current inventory and relevant definitions explicitly, and track which sections each analysis actually covers.

Does retrying an API request resume the same comparison?

A new public API request should not be assumed to resume an earlier one or inherit an idempotency guarantee. A network failure may leave the first outcome unknown. Disable automatic SDK retries, inspect available accounting and state, and decide deliberately whether another submission is needed. Keep source versions unchanged while investigating.

Sources

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

• Dikaya API documentation and client boundaries
  dikaya.cc
• Dikaya public model configuration
  dikaya.cc
• OpenAI Python SDK: retries and error handling
  github.com
• MDN Fetch: network and HTTP response handling
  developer.mozilla.org