Today Lens

Turn messy thoughts into a realistic daily plan—and make the first action immediately clear.

Comment

Inspiration

When several tasks compete for attention, the hardest part is often not doing the work—it is deciding what is realistic and where to begin.

I built Today Lens to turn that moment of overload into one concrete first action and a realistic plan shaped by the time and energy actually available.

I joined OpenAI Build Week with only four days remaining and started from the generated Xcode SwiftUI and SwiftData template. The short timeline encouraged a narrow goal: deliver one complete, testable iPhone experience instead of a wide collection of unfinished features.

What it does

Today Lens lets someone:

  1. Write an unstructured brain dump.
  2. Choose how much time and energy they have.
  3. Explicitly select consented Live AI or a fully local Demo Mode.
  4. Receive 3–5 prioritized plan blocks, an explanation of the order, and a prominent First Action.
  5. Save the plan locally and reopen it after terminating and relaunching the app.

The First Action is intentionally smaller than the full first block: it should be something concrete that can be started immediately.

Live AI uses GPT-5.6 Luna through a project-owned Cloudflare Worker. If an eligible network or upstream failure occurs, Today Lens uses a deterministic plan prepared locally before the request. Demo Mode also allows the complete core flow to be evaluated without an account, provider key, or network connection.

How I built it

Today Lens is a native SwiftUI iPhone app with SwiftData persistence. The app owns one PlanPlanner boundary that selects between Live planning and deterministic local generation.

The Live path is:

iPhone → Cloudflare Worker → OpenRouter → GPT-5.6 Luna

The iPhone sends only the brain dump, available minutes, and energy level. It never contains the OpenRouter credential, provider settings, model selector, or server prompt.

The Worker exposes one bounded endpoint, POST /v1/plan. It owns the fixed model and prompt, requests strict JSON Schema output, validates the result again at runtime, returns privacy-safe errors, and keeps content out of operational logs. A shared rate-limit binding acts as a cost fuse.

SwiftData stores each saved plan as an immutable local snapshot. Navigation occurs only after an explicit save succeeds. The latest plan can therefore be reopened after a real process relaunch.

How Codex and GPT-5.6 helped

Building Today Lens with GPT-5.6 was one of the most engaging development experiences I have had. One continuous Codex workflow took the project from an untouched Xcode template to a tested native app, a deployed Worker, Live AI integration, and a TestFlight build.

Codex with GPT-5.6 Sol supported repository research, SwiftUI and SwiftData implementation, Worker development, test design, failure analysis, security review, and visual inspection. Sol Ultra was especially effective for detail-sensitive reviews because its agent-based workflow could investigate separate boundaries and synthesize the evidence.

For the interface, Sol Ultra also produced four visual concept frames across two distinct design directions. I compared the alternatives, and Codex then synthesized their strongest ideas: the lighter Capture composition from one direction and the stronger First Action hierarchy and numbered timeline from the other. That hybrid became the implementation target and was subsequently verified in Simulator and on a physical iPhone.

GPT-5.6 Luna became part of the product itself as the fast and economical runtime planning model. Deterministic Swift code remains responsible for Demo Mode and fallback, keeping the product testable without AI availability.

My role remained product direction, acceptance decisions, credential and deployment control, physical-device testing, and review of every scoped change. The result feels genuinely built together with GPT-5.6 rather than assembled from isolated generated snippets.

Challenges

Several important corrections came from the implementation and review loop:

  • A persistence test initially reopened a disk store while the first SwiftData stack could still be retained. It was rewritten to return only immutable values before creating the second container.
  • An early fallback policy could hide local validation or unknown programming errors as ordinary Live unavailability. The final exhaustive classification falls back only for explicitly approved remote failures.
  • A real Luna response described completing an entire 75-minute block as the “first action.” Controlled English and Ukrainian tests led to two prompt refinements defining it as one imperative 2–5 minute starting step.
  • The Result screen looked stable in Simulator but allowed subtle horizontal rubber-banding on a physical iPhone. Runtime measurements revealed a fractional cross-axis width mismatch, which was fixed without clipping or replacing native navigation gestures.

Accomplishments that I am proud of

  • A complete Capture → Focused Lens Result experience.
  • Explicit and reversible consent before any Live request.
  • A deployed, secret-safe Worker with strict input and output boundaries.
  • Deterministic local generation and automatic operational fallback.
  • Persistence verified across process termination and relaunch.
  • 49 passing iOS tests, including the relaunch UI flow.
  • 54 passing Worker tests with fully mocked, fail-closed provider access.
  • Live structured planning verified with both English and Ukrainian input.
  • A polished numbered plan timeline and a First Action designed to reduce the friction of getting started.

What I learned

The strongest results came from keeping each change small enough to review and verify. Structured model output is valuable, but schema validation alone is not enough—product invariants and semantic behavior still need independent checks.

I also learned how effective AI-assisted development becomes when research, implementation, testing, correction, and product judgment share one continuous context. Codex accelerated the technical work, while physical-device testing and explicit acceptance decisions kept the result grounded in the real user experience.

What's next

After Build Week, I would like to explore:

  • A compact intent-composer Capture experience.
  • Full plan History and search.
  • Replan and completion tracking.
  • Persisted provenance and richer plan management.
  • Stronger production-scale abuse protection.
  • Additional UI localizations.
  • Further evaluation of model quality, latency, and cost across planning scenarios.

Built With

Share this project:

Updates