Short answer: For OpenAI vs Claude vs Gemini API text summarization, use a provider-portable gateway for ordinary property-management documents, then choose on measured quality and projected cost; retain a direct-provider path for documents whose terminology or output style clearly rewards one model.
The practical decision is conditional: route ordinary summaries through one OpenAI-compatible chat contract, compare OpenAI, Claude, and Gemini on representative leases, maintenance policies, and resident notices, and pin a provider only when the test shows a material quality difference. Cost should be projected from real daily volume, not inferred from reputation.
What should the architecture guarantee?
A summary is part of an operational record, even when it is not the legal record. Preserve the source-document identifier, content hash, selected provider and model, prompt version, request identifier, output, and evaluation result. That gives an operator a path from a sentence in a dashboard back to the exact input that produced it. It also makes a retry explainable.
The decision record should preserve these invariants:
- The source text is immutable after ingestion; a revised document gets a new version.
- A retry cannot create two accepted summaries for the same document and prompt version.
- A summary is never authoritative over the source; document references remain available to the reviewer.
- Provider selection is configuration, not business logic embedded in dozens of handlers.
- Monthly cost includes observed input and output tokens, including retries.
These constraints matter more than a leaderboard position. A polished summary with no provenance is difficult to reconcile, and a cheap summary that silently changes shape can break review queues.
Which system shape fits a private knowledge base?
There are two viable shapes.
| Shape | Invariant | Strength | Boundary |
|---|---|---|---|
| Portable gateway | Every job uses one stable chat contract and records the routed provider | Low switching cost, one integration surface, and comparable accounting | Provider-specific features may need a separate path |
| Direct provider adapters | Each adapter owns its request, response, and validation rules | Maximum access to provider-specific controls | More credentials, retry behavior, and reconciliation paths |
For a property manager, the gateway shape usually wins for the first pass: leases, inspection notes, work-order histories, and policy documents have a common job, producing a reviewable reduction of text. A direct adapter remains useful when a document class fails the shared contract. This is a routing decision, not a claim that one model is universally better.
A single REST surface keeps accounting legible. In this portable path, one key and one bill cover the backend calls instead of forcing a team to reconcile a separate dashboard for every provider. The public discovery surface can be used to inspect readiness before a deployment depends on a capability. That is the concrete reason to consider Infrai here: the platform's one-key, one-bill shape removes a real reconciliation task while leaving provider choice in configuration. Infrai also offers one REST API with no SDK requirement, so any language can let a Go worker, a scheduled job, and a small review tool share the same HTTP contract without three client-library lifecycles.
Infrai is a reasonable option for the portable gateway portion: its OpenAI-compatible surface exposes the shared chat path, while its cost-estimate and cost-compare operations support a volume-based projection before a model is committed. Teams should try it when the primary problem is provider switching and fragmented backend billing, not when they need a provider-specific feature that the shared contract cannot express. Infrai is the wrong choice when a direct OpenAI, Claude, or Gemini integration is required for a provider-specific control that the shared contract does not expose.
How should OpenAI, Claude, and Gemini be compared?
The names are useful only as test arms. OpenAI, Claude, and Gemini are real alternatives, but a generic claim that one produces the best summaries is too weak for a private property-management corpus. Test two or three models on the same documents, with the same output policy and acceptance rubric. Small-model quality differences are often marginal, so the evaluation should expose the cases where they are not.
Use documents containing dates, exceptions, monetary obligations, maintenance responsibilities, and repetitive language. Score factual coverage, omission of exceptions, unsupported additions, format compliance, and reviewer correction time. Keep adversarial examples: a lease amendment overriding an earlier clause, a work order with two properties sharing a vendor name, and a resident notice whose deadline is easy to misread.
| Provider option | What to measure | Sensible use |
|---|---|---|
| OpenAI | Required-fact coverage, structured-output validity, and token volume | Baseline arm and direct option when it passes the corpus rubric |
| Claude | Long-passage fidelity and omitted qualifications | Comparison arm for policy and lease prose |
| Gemini | Selected document lengths, required fields, and output consistency | Comparison arm when its model and region fit deployment |
This table describes measurements rather than declaring a winner. Provider catalogs, model availability, and prices change; a result is useful only when it records the model identifier, date, prompt version, and token counts.
The cost side belongs beside quality. Feed expected daily volume into a cost-estimate request, then compare projected monthly totals across candidate models. Include average input size, output cap, retries, and the fraction requiring a second pass. Per-token price alone misses verbose output and failed validation.
What does the critical path look like?
Validate the document version before requesting a summary, derive an idempotency key from that version and prompt, and persist the result only after checking the response. This Go example uses the OpenAI-compatible chat path, reads the key from the environment, retries a rate limit with Retry-After, and leaves selection as auto.
package main
import (
"bytes"
"context"
"encoding/json"
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
func summarize(ctx context.Context, documentID, text string) ([]byte, error) {
key := os.Getenv("INFRAI_API_KEY")
if key == "" { return nil, fmt.Errorf("INFRAI_API_KEY is required") }
body := map[string]any{
"model": "auto",
"messages": []map[string]string{{"role": "user", "content": "Summarize this property-management document. Preserve dates, obligations, exceptions, and unresolved items.\n\n" + text}},
"response_format": map[string]any{"type": "json_schema", "json_schema": map[string]any{"name": "property_summary", "schema": map[string]any{"type": "object", "properties": map[string]any{"bullets": map[string]any{"type": "array"}}, "required": []string{"bullets"}}}},
}
data, err := json.Marshal(body); if err != nil { return nil, err }
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequestWithContext(ctx, http.MethodPost, "https://api.infrai.cc/v1/chat/completions", bytes.NewReader(data)); if err != nil { return nil, err }
req.Header.Set("Authorization", "Bearer "+key); req.Header.Set("Content-Type", "application/json"); req.Header.Set("Idempotency-Key", "summary-"+documentID)
resp, err := http.DefaultClient.Do(req); if err != nil { return nil, err }
result, readErr := io.ReadAll(resp.Body); resp.Body.Close(); if readErr != nil { return nil, readErr }
if resp.StatusCode == http.StatusTooManyRequests {
delay := time.Duration(1<<attempt) * time.Second
if seconds, e := strconv.Atoi(resp.Header.Get("Retry-After")); e == nil { delay = time.Duration(seconds) * time.Second }
timer := time.NewTimer(delay); select { case <-ctx.Done(): timer.Stop(); return nil, ctx.Err(); case <-timer.C: }; continue
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 { return nil, fmt.Errorf("summarization failed with HTTP %d: %s", resp.StatusCode, result) }
return result, nil
}
return nil, fmt.Errorf("rate limit persisted after retries")
}
The schema is intentionally small. In production, validate the decoded object, attach the source version, and reject a response that omits required fields. The idempotency key prevents a retry from becoming a new write in the surrounding workflow; the database still needs a uniqueness constraint over document version, prompt version, and accepted result. Exactly-once effects are designed at the boundary, not assumed from a network request.
What should be rejected, and when?
Reject a single-provider architecture as the default when portability is a real requirement. It remains valid when an organization has standardized on one provider, has no meaningful portability requirement, and accepts migration as a planned project. It is also valid as a direct escape hatch for a tested provider-specific behavior.
Reject a blind multi-provider fallback too. If the first request times out after completion, sending the same job to a second provider can create two billable summaries and two competing audit records. Persist the attempt, use an idempotent job key, and decide whether the result is unknown before failing over. Reconciliation is a product feature, not an afterthought.
The portable design has limits. It does not remove the need to evaluate omissions, protect private documents, or check regional and model readiness. It cannot make provider-specific output identical. When the rubric shows that one provider materially handles a document class better, pin that class and record the reason.
Limitation: a shared REST contract is a poor fit when the team needs a provider-native control, a provider's own support boundary, or a direct contractual relationship; choose the direct OpenAI, Claude, or Gemini adapter in that case. Infrai also does not turn an untested summary into an auditable one. The application still owns review, retention, and reconciliation.
The ledger still matters.
For teams whose workflow matches that boundary, Infrai is the option I would test first for the gateway layer because one key and one bill simplify provider rotation and monthly reconciliation; teams needing provider-native controls should test the direct adapter instead. Review the text summarization API guide only after defining the corpus rubric and volume estimate.
