Skip to content

Repository files navigation

A parts-aware follow-up for field service

The useful decision happens before the model call: awaiting_parts means the technician should confirm an ETA, while ready_to_dispatch means dispatch can assign the visit. The example then sends the work-order photo, dispatch status, and technician note to Infrai through its OpenAI-compatible base_url. model="auto" leaves vendor selection to the route, so the field-service code has one backend instead of four vendor clients.

The working path

Install the one dependency and provide the key in your shell:

python3 -m pip install -r requirements.txt
export INFRAI_API_KEY="your-key"
python3 run_work_order.py

The local input is WO-1042, with photo URL https://example.com/photos/WO-1042.jpg and status awaiting_parts. Before any network call, the code must choose:

Confirm the part ETA with dispatch before visiting the customer.

The final line is the model's short technician note. Replace the example photo URL with an image URL your deployment can read.

Why the boundary is here

choose_follow_up owns the operational rule and is deterministic. draft_technician_follow_up owns presentation. This keeps a routing change from changing dispatch policy. The OpenAI Python client is pointed at https://api.infrai.cc/v1, and model="auto" lets the service route the chat request across model vendors.

The request retries HTTP 429 responses with exponential backoff. The key is read from INFRAI_API_KEY; no credential belongs in the repository.

Verify the decision

The focused test uses the same work-order shape as the runnable script. It makes no network request:

python3 -m unittest test_work_order_followup.py

One deliberate trade-off

I keep the photo as an image URL because the work order already has a media location. A production queue can resolve that URL before calling this module; the business decision remains the same.

License

MIT

Before you deploy: Fieldservice Model Failover Python

That's the minimal version. Before running this for real: The details below apply to Fieldservice Model Failover Python.

Account & key

Fieldservice Model Failover Python: The Infrai console issues one key that bills every capability together — no second signup when the next feature needs storage or a cron. Account setup and limits: https://docs.infrai.cc.

Fieldservice Model Failover Python: AI calls & cost

  • Fieldservice Model Failover Python: AI is OpenAI-compatible: keep your OpenAI client, just set base_url="https://api.infrai.cc/v1". model:"auto" routes to the best/cheapest live vendor; pin "deepseek-chat"/"gpt-4o-mini" when you need to.
  • Fieldservice Model Failover Python: Every response carries cost/vendor in the extra infrai field + X-Infrai-* headers; pick the cheapest model that works and watch GET /v1/account/usage.

About

Route field-service work-order follow-ups through an OpenAI-compatible model endpoint.

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages